I became aware of the Meraki MX84 from Lathe Abusaid’s blog post about tearing down the hardware. After setting up an eBay alert and waiting, I finally won a job lot which included an MX84.
Here is a quick summary of the MX84 specs:
- Intel Atom C2358 CPU (2C/2T, 1.74GHz)
- 4GB DDR3 ECC RAM (H5TC4G83CFR-PBA)
- Internal SATA port (1TB Western Digital Green)
- External USB2.0 port
- 13 Network interfaces (Vitesse VSC7425: 11 Gigabit Ethernet, 2 SFP)
- 16MB SPI flash, 1GB NAND flash (Phison PS2251, USB on motherboard)
- Fanless
- Open frame 12V 2.5A power supply
The device runs Linux 3.18.131.
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC Transaction Router (rev 02) 00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 1 (rev 02) 00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 3 (rev 02) 00:0b.0 Co-processor: Intel Corporation Atom processor C2000 QAT (rev 02) 00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02) 00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02) 00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus 2.0 (rev 02) 00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03) 00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03) 00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03) 00:14.3 Ethernet controller: Intel Corporation Ethernet Connection I354 1.0 GbE Backplane (rev 03) 00:16.0 USB controller: Intel Corporation Atom processor C2000 USB Enhanced Host Controller (rev 02) 00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI SATA2 Controller (rev 02) 00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI SATA3 Controller (rev 02) 00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02) 00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
The MX84 uses coreboot as the bootloader (coreboot-af6fa06-dirty-Liteon_GRM1001_MFG_v4.0.0; bootlog) and the ROM has the following layout:
00000000:00010000 reserved 00010000:0070ffff bk1 00710000:00dfffff bk2 00e00000:00ffffff coreboot
The cbfs contains the following:
FMAP REGION: COREBOOT mx84.bin: 16384 kB, bootblocksize 1024, romsize 16777216, offset 0xe00000 alignment: 64 bytes, architecture: x86 Name Offset Type Size Comp cmos_layout.bin 0xe00000 cmos_layout 1352 none fallback/romstage 0xe00580 (unknown) 25820 none fallback/ramstage 0xe06ac0 (unknown) 61965 none fallback/payload 0xe15d40 simple elf 20349 none config 0xe1ad00 raw 4310 none revision 0xe1be00 raw 712 none (empty) 0xe1c100 null 1261208 none mrc.cache 0xf4ffc0 mrc_cache 65536 none cpu_microcode_blob.bin 0xf60000 microcode 84992 none (empty) 0xf74c40 null 45912 none fsp.bin 0xf7ffc0 spd 389120 none (empty) 0xfdf000 null 134040 none
coreboot was built with an ELF payload (miles) which by default loads and jumps into the bootkernel FIT image (dts here) located at 0x10000. A secondary bootkernel exists on flash at offset 0x710000.
Let us revisit those Intel I354 interfaces. As a networking appliance, the MX84 has a lot of network interfaces.
There are 13 network interfaces on the front (Management, Internet 1 & 2, Ethernet 3-10, and 2 SFP cages) so there should be a switch inside the MX84 or we would expect to see more than four interfaces in lspci.
In this case, the switch is the VSC7425, and even if you use the 3.18.131 kernel from Meraki, you won’t have any connectivity because all four of the I354 interfaces connect directly to the VSC7425
The stock Meraki firmware uses a binary called vtss_poca_d to initialise and configure the VSC7425, which does so using a proprietary Vitesse framework (PDF).
vtss_poca_d is a static binary, so could we use it with a newer kernel such as 5.10.146 found in OpenWrt 22.03?
$ vtss_poca_d mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:0 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:1 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:2 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:3 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:0 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:1 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:2 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:3 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:0 failed: Not supported mdio_write16: SIOCSMIIREG on eth0 phy:0 reg:1 failed: Not supported mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:2 failed: Not supported mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:3 failed: Not supported mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:2 failed: Not supported mdio_read16: SIOCGMIIREG on eth0 phy:0 reg:3 failed: Not supported
Nope! As such, it is very unlikely this device will ever be supported by OpenWrt.
You may have noticed that the MX84 is based on the Atom C2000, a CPU which suffers from the AVR54 errata. When I first received my MX84, there was no output on UART and the power consumption was a suspiciously consistent 6W, all the hallmarks of a device dead from AVR54. There are numerous instructions for how to revive a Synology NAS with a dead Atom, but no such instructions exist for the MX84.
Fortunately for me, there was a photo from Lathe Abusaid’s blog post which provided a crucial hint. It appears that the MX84 unit photographed in their teardown includes a 100 Ohm resistor between pins 1 (LPC clock) and 9 (3.3V) of header J7.
This solution appears to have been chosen because it was the most convenient for Cisco, however note that pin 9 of J7 appears to be a GPIO output which, depending on the coreboot payload, may not always be active high. I would suggest instead soldering to pin 8 of the unpopulated SOIC8 nearby (U47), which will provide 3.3V regardless of the payload GPIO configuration.
That being said, here is a photo of the resistor fix to J7 that I just advised against doing, taken before realizing pin 9 was a GPIO
After soldering the pull-up resistor, the LPC clock is back on pin 1 of J7:
Oscilloscope output of the LPC clock on pin 1 of J7 after adding a 100Ω resistor
There is an unpopulated footprint for a Micro-USB port on the left side of the motherboard. By default the D-/D+ are not connected, as the 0 Ohm resistors are unpopulated (they are instead populated on R467/R468 connecting the Phison ps2303q to the Atom CPU). I believe this port was used during development to easily swap the USB drive connected to the SoC.
One question I had about the MX84 was: why coreboot? It seems that this design is based on Intel’s “Mohon Peak” reference platform. From the Intel customer reference board (CRB) documentation (PDF):
The embedded firmware ecosystem has developed an example boot loader solution
for the CRB that uses the FSP kit. This solution is based on the open source Coreboot
project at coreboot.org. While Intel does not endorse or support boot loader solutions
based on the Coreboot project, the example Coreboot-based boot loader provides a
good teaching model for how to integrate the Intel FSP into a complete boot loader
solution.
Now it is clear why Meraki chose to use coreboot, that is simply the bootloader reference provided by Intel for Mohon Peak. Other manufacturers who made Atom C2000 products also used coreboot (such as the VeloCloud 520-AC).
Meraki provided the coreboot source code in December 2022, after a delay of more than 12 months. The coreboot source code for the MX84 is available on GitHub.
Meraki hardware commanding the premium that it does, if you are considering buying an MX84: don’t. The VeloCloud 520-AC (C2358) and 540-AC (C2558) are available for ~$30 on eBay and have the C0 revision which doesn’t suffer from AVR54.
If you already own an MX84 and want to poke around, here is a buildroot based firmware that you flash to SPI. The firmware will boot, initialize the switch, DHCP, and start an SSH server (the root password is the device serial without hyphens). Note that it is initramfs based, so no changes are persisted.
Caveat emptor: VeloCloud devices have an issue with the igb/I354 compatibility, meaning that only the two SFP cages are functional. However, that is two more interfaces than you will get from the MX84 (zero) with any other kernel.