Some info about the BSM in the following thread.
https://forums.servethehome.com/ind...gbe-switch-information-requested.47247/page-2
https://forums.servethehome.com/ind...gbe-switch-information-requested.47247/page-2
Wedge 400 48-Port
- Thread starter tritron
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
I have two of the AC versions, and count me in for anyone working on the BSM. Let me know what kind of a$$istance it might take to get a working BSM. It is sad that Celestica put all the work into pushing this on OCP, then abandoned it. I imagine a few thousand of these will hit the used market, and they will just be trashed.
Ill tear mine down tomorrow afternoon and post some photos for you. As far as I can tell as of last time I tore it down I have everything intact minus the one module that I need to have made. From test fits it accepts a standard 2280 m.2 nvme with no issue.
I was able to build a partially working onie iso based on the accton minipack machine with a few modifications. It detects the nvme and installs itself. Haven't tested anything beyond that.
It is complaining about a missing serial number repeatedly. Unfortunately curl doesn't seem to be installed and all the system info is only accessible through the rest api.
It is complaining about a missing serial number repeatedly. Unfortunately curl doesn't seem to be installed and all the system info is only accessible through the rest api.
Code:
ONIE:/ # onie-syseeprom
TlvInfo Header:
Id String: TlvInfo
Version: 1
Total Length: 74
TLV Name Code Len Value
-------------------- ---- --- -----
Product Name 0x21 8 WEDGE400
Part Number 0x22 9 20-002823
Serial Number 0x23 13 FE-----------
Base MAC Address 0x24 6 34:AD:61:--:--:--
MAC Addresses 0x2A 2 143
Manufacturer 0x2B 3 CLS
Vendor Name 0x2D 13 Meta/Facebook
CRC-32 0xFE 4 0x37A01D06
Checksum is valid.
ONIE:/ #I work on OpenBMC professionally and just picked up two Wedge400s to play with in my home lab. A few quick notes:
I grabbed some M.2 breakout boards to prototype this simpler single-ROM design before committing to a custom PCB. I’m hoping to have the BMC booting by the end of the weekend, and I’ll post my OpenBMC repo/image and notes once it’s all working.
- eMMC: Mostly just holds the RW (rwfs) partition. Many systems drop eMMC and store this in SPI flash instead to cut cost and improve security.
- FRU: Used by EntityManager to map configs to hardware. If configs expect a specific FRU, you can usually fix it by editing the probe entries in EntityManager.
- Second flash: Nice to have, but not required.
I grabbed some M.2 breakout boards to prototype this simpler single-ROM design before committing to a custom PCB. I’m hoping to have the BMC booting by the end of the weekend, and I’ll post my OpenBMC repo/image and notes once it’s all working.
Quick update on the Wedge400 BMC work:
- Built a simple single 1 Gb NOR flash setup, since that’s what the machine config is currently set up to use.
- The minimum size is about 256 Mb, but that leaves very little space for the RW partition (/mnt/data0).
- A 512 Mb device is probably the sweet spot — enough for a full experience while keeping cost down.
- Dual NOR flash is optional but not really necessary for home lab use, since frequent firmware updates aren’t expected after initial setup.
- Only needed minor tweaks to the Facebook OpenBMC repo to disable eMMC.
- The BMC did boot a couple of times, but then consistently failed in U-Boot — pointing to a signal integrity issue in my prototype.
- Lowering the clock frequency resolved the U-Boot load issues, allowing the BMC to fully boot.
Which 1Gbit NOR are you using? I tried a W25Q01JVSFIM but it's not supported in the default kernel and failed to boot.
I'm using the 2025.08 release of ONIE as my base. I stared with the Accton Minipack machine and made few modifications to make it work on the wedge400. The worst part was getting the system info from the BMC and translating it to TLV in shell. I've attached a zip of the machine folder and the schematic for my board. The 100nF caps are for decoupling both the flash chips and eeprom chip, and are placed physically near them. Please excuse the crudity of this model. I didn't have time to build it to scale or paint it.
I'm using the 2025.08 release of ONIE as my base. I stared with the Accton Minipack machine and made few modifications to make it work on the wedge400. The worst part was getting the system info from the BMC and translating it to TLV in shell. I've attached a zip of the machine folder and the schematic for my board. The 100nF caps are for decoupling both the flash chips and eeprom chip, and are placed physically near them. Please excuse the crudity of this model. I didn't have time to build it to scale or paint it.
I used the Winbond W25Q01JVIQ flash chip.
The W25Q01JVSFIM is actually supported in both U-Boot and the kernel used in the default Wedge400 image (see spi-nor-ids.c).
That said, I’ve never been able to get the W25Q##JVIM parts working reliably. They require manually setting the Quad Enable (QE) bit in the status register, but even after confirming with a Dediprog that QE was set correctly, they still failed for me.
The following parts have worked out of the box in my setup:
- W25Q01JVIQ
- W25Q512JVIQ
Thanks for sharing the files! I was able to get ONIE up and running on my system. Next, I’ll be digging into the various EEPROMs accessible to the CPU. There’s a FRU shared between the COMe and BMC that holds the serial number, but that bus isn’t showing up in ONIE. It’s possible we can also pull this info from the CPLD or the EC (TI Snowflake).
----
I’ve shifted focus to bringing up a SONiC image. The Wedge400 uses a unique DOM FPGA PCIe memory-mapped interface for QSFP transceiver access. By contrast:
- The Accton Minipack also has DOM FPGAs, but they sit behind an IO Bridge FPGA, so access is handled differently.
- The Minipack supports multiple sleds (PIMs), which further segment the QSFP transceivers by slot.
- The Minipack’s COMe has a direct I²C path (via a USB-to-I²C bridge) to every QSFP bus — something the Wedge400 lacks.
Status Update
Next Steps
- Built a minimal working platform that brings up SONiC, loads syncd, and initializes the switch.
- Set up a basic test between two Wedge400s — able to ping across the QSFP-DD ports.
- Tested a few ports so far, and they link up cleanly with another SONiC switch.
- Confirmed the Wedge400 DOM FPGA is nearly identical to the Accton Minipack version. The Minipack spec maps directly to the Wedge400 PCIe memory register space.
- Wrote a Python class to expose the DOM FPGA interface to SONiC daemons — front panel LEDs now light up on active ports.
- Located the official Wedge400 design files (schematics + Gerbers for the BSM) here. These can be sent directly to a board house for fabrication.
- Verified that only a single flash chip + a few pull-ups are required to build a working BSM.
- For my setup, I’ll continue using the 1 Gb NOR flash parts.
Next Steps
- Write a kernel driver to expose transceiver EEPROMs via sysfs (leveraging existing PDDF drivers as reference).
- Implement PSU and SFP daemon interfaces.
- Consolidate all changes into a working branch to share back with the community.
I got two of the DC variants.
Has anyone been able to confirm the eBay seller's claim that the DC variant uses Cisco's silicon rather than Broadcom? ("The Wedge400-AC-F uses Broadcom's Tomahawk 3 ASIC, while the Wedge400-DC-F utilizes Cisco's Silicon One ASIC.")
The original spec references both the AC and DC variants and makes no mentions of Cisco, and the public info I saw indicates the Cisco variant came later and was referred to as "Wedge 400C". But I could just be biased since I'd be hoping for that result for compatibility reasons...
Questions about powering these babies -
I somehow found one AC power supply for sale on eBay. Any reason inserting it into the DC-F version would not work? Do we really think these are different other than the PSUs they came with initially?
Has anyone found a good and cost effective 12v DC supply to use to power these via the DC PEM? Seems like most common PSUs could be made to work since it should work with 11.8 – 12.8 Vdc as input. Unless I'm missing something important?
Has anyone been able to confirm the eBay seller's claim that the DC variant uses Cisco's silicon rather than Broadcom? ("The Wedge400-AC-F uses Broadcom's Tomahawk 3 ASIC, while the Wedge400-DC-F utilizes Cisco's Silicon One ASIC.")
The original spec references both the AC and DC variants and makes no mentions of Cisco, and the public info I saw indicates the Cisco variant came later and was referred to as "Wedge 400C". But I could just be biased since I'd be hoping for that result for compatibility reasons...
Questions about powering these babies -
I somehow found one AC power supply for sale on eBay. Any reason inserting it into the DC-F version would not work? Do we really think these are different other than the PSUs they came with initially?
Has anyone found a good and cost effective 12v DC supply to use to power these via the DC PEM? Seems like most common PSUs could be made to work since it should work with 11.8 – 12.8 Vdc as input. Unless I'm missing something important?
I think it should say on the label WEDGE400C-DC-F somewhere. The PCI IDs for the switching chips should be viewable from ONIE or any linux distro(have to modify grub for serial console of 57600). If not, you can open it up and check.
As for the power supplies, the 400C design specification says that the AC PSU is an option.
The BMC firmware and ONIE installer should be the same as the non-C.
As for the power supplies, the 400C design specification says that the AC PSU is an option.
The BMC firmware and ONIE installer should be the same as the non-C.
Last edited:
Side note:
The serial connection is setup weird.
The front console port is connected to the BMC and defaults to 9600.
The BMC talks to the SCM at 57600.
You can SSH into the BMC and use the sol.sh command to use the faster serial link.
Another side note:
Theres a mini network switch inside that connects two of the front ports, the BMC, and SCM.
The serial connection is setup weird.
The front console port is connected to the BMC and defaults to 9600.
The BMC talks to the SCM at 57600.
You can SSH into the BMC and use the sol.sh command to use the faster serial link.
Another side note:
Theres a mini network switch inside that connects two of the front ports, the BMC, and SCM.
- Located the official Wedge400 design files (schematics + Gerbers for the BSM) here. These can be sent directly to a board house for fabrication.
Also @jls5177 - any ETA for posting a branch on github or somewhere for collaboration?
Last edited:
This seems to have gerber files for the BSM.