Tag Archives: QCA8334

Meraki MX85 hardware overview

The Meraki MX85 SD-WAN appliance (codename “Box Wine”) is the replacement to the Meraki MX84 and offers 4 WAN uplink ports (2 SFP, 2 Gigabit Ethernet, 1 w/PoE), 10 LAN ports (8 Gigabit Ethernet, 2 SFP), a dedicated Gigabit Ethernet port for management, and a USB 3.0 port for external cellular modems¹.

Inside the Meraki MX85

Here is a summary of the MX85 specs:

  • NXP LayerScape LS1046A (ARM A72, 4 cores @ 1.8GHz)
  • 8GB DDR4 RAM (Samsung K4AAG165WA-BCWE x4, soldered)
  • 16GB of EMMC flash (SanDisk SDINBDA6-16G)
  • Winbond W25Q64JVSIQ (x2)
  • Aikido/Cisco TAM hardware root-of-trust (Microchip SmartFusion2 M2S010)
  • Qualcomm QCA8337-AL3C 7-port Gigabit Ethernet Switch (x2, PDF datasheet)
  • Qualcomm QCA8334-AL3C 4-port Gigabit Ethernet Switch (PDF datasheet)
  • Atheros AR8033-AL1A Gigabit Ethernet PHY (dedicated management port)
  • Microchip PD69104B1 PSE controller (PoE WAN port)
  • UMEC UP1501D-54 150W power supply

Meraki tries to be the Apple of SMB networking, and frequently uses premium materials like aluminum in their product designs (MS220, MS320, MS225, MS350, MX84). This is a bit silly for something that sits in a rack, but it is the brand image they were trying to cultivate.

The MX85 does not appear to use any aluminum in the chassis. Like the budget-oriented MS120 series, the entire MX85 chassis is made of steel. Meraki marketing will tell you this was for better cooling and is definitely not related to any cost reduction.

Meraki engineers even included thermal pads and metal spacers on top of the SFP ports (and below the PCB) to dissipate heat through the chassis. You could be forgiven for assuming they are SFP+ ports (they are not) with so much attention given to heat dissipation.

All for a device which consumes less power at idle than the (also) passively-cooled MX84, and no longer includes a spinning hard drive.

Unlike previous products, Meraki use glue to secure the front panel ribbon cable


The UART header is J3 on the MX85 and follows the standard Meraki UART pinout (1: VCC, 2: Tx, 3: Rx, 4: GND) at 3.3V and 115200 baud.

Note: R6 and R7 are 0 ohm resistors which (dis)connect Tx and Rx lines of the SoC to the UART header. R6/R7 are not populated by default. You must populate them, or bridge the pads, for the UART header to function.


The U-Boot release on the MX85 is 2018.09julia-spl-boxwine and, like all other recent Meraki products, it does not allow interrupting boot.

U-Boot SPL 2018.09julia-spl-boxwine (Mar 17 2021 - 20:02:01 +0000)
Initializing DDR....using SPD
DDR clock (MCLK cycle 952 ps) is slower than DIMM(s) (tCKmax 750 ps) can support.
Trying to boot from BOOTROM


U-Boot 2018.09julia-spl-boxwine (Mar 17 2021 - 20:02:01 +0000)

SoC:  LS1046AE Rev1.0 (0x87070010)
Clock Configuration:
       CPU0(A72):1800 MHz  CPU1(A72):1800 MHz  CPU2(A72):1800 MHz  
       CPU3(A72):1800 MHz  
       Bus:      700  MHz  DDR:      2100 MT/s  FMAN:     800  MHz
Reset Configuration Word (RCW):
       00000000: 0e150012 10000000 00000000 00000000
       00000010: 33330000 00b00012 40000000 c1000000
       00000020: 00000000 00000000 00000000 00018ffc
       00000030: 20004504 01003000 00000096 00000001
Model: LS1046A RDB Board
Board: LS1046ARDB, boot from Invalid setting of SW5
CPLD:  V0.0
PCBA:  V0.0
SERDES Reference Clocks:
SD1_CLK1 = 100.00MHZ, SD1_CLK2 = 100.00MHZ
I2C:   ready
DRAM:  Detected UDIMM Fixed DDR on board
DDR clock (MCLK cycle 952 ps) is slower than DIMM(s) (tCKmax 750 ps) can support.
7.9 GiB (DDR4, 64-bit, CL=15, ECC off)
SEC0: RNG instantiated
PPA Firmware: Version LSDK-18.09
GPIO:	initialized
setting up RGB LED controller lp5562....
Using SERDES1 Protocol: 13107 (0x3333)
Using SERDES2 Protocol: 0 (0x0)
SERDES2[PRTCL] = 0x0 is not valid
NAND:  0 MiB
MMC:   FSL_SDHC: 0
EEPROM: meraki_MX85 600-102010
In:    serial
Out:   serial
Err:   serial
Net:   Invalid SerDes protocol 0x3333 for LS1046ARDB
Fman1: Uploading microcode version 108.4.9
Could not get PHY for MDIO2: addr 8
Failed to connect
Could not get PHY for MDIO2: addr 9
Failed to connect
Could not get PHY for MDIO1: addr 9
Failed to connect
PCIe0: pcie@3400000 disabled
PCIe1: pcie@3500000 disabled
PCIe2: pcie@3600000 disabled
FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5 [PRIME], FM1@DTSEC6, FM1@DTSEC9, FM1@DTSEC10

As we can see from the above ECC off output, the MX85 is using non-ECC RAM. This is a downgrade from the MX84 which did use ECC memory.

The MX85 also contains the Cisco TAM, implemented using a SmartFusion2 M2S010. The TAM is used for secure boot.

## Starting application at 0x82120000 ...
bootselect
## Application terminated, rc = 0x0
## Starting application at 0x82120000 ...

----Security Versions----
SecureBoot:  R6.3.66-f6737c7-20200623
SB Core:     F01257R21.038ae8d0b2020-05-15
Microloader: MK0007R01.0105062020
SF: Detected SPI Generic with page size 256 Bytes, erase size 4 KiB, total 16 MiB

----SecureBoot Registers----
system_invalid:            0
boot_check_count_error:    0
boot_done:                 1
boot_ok:                   1
boot_check_count_golden:   0
boot_check_count_upgrade:  2
boot_status_golden:        0
boot_status_upgrade:       1
first_bootloader:          1

----Upgrade----
boot_error:                0
boot_check_count_error_vc: 0
boot_check_count_error:    0
boot_timeout_vc:           0
boot_timeout:              0
boot_cs_good:              1
boot_config_error:         0
boot_version_error:        0
boot_config_error_code:    0
boot_error_code:           0
boot_cs_good:              1
boot_version_error:        0
boot1_cs_key_type:         1
boot1_cs_return_code:      0
boot1_cs_key_index:        5
boot2_cs_return_code:      0
boot2_cs_key_index:        5
boot2_cs_key_type:         1

----Other Registers----
fpga_version:      0090

Reading whitelist from TAM
whitelist.bin: 740 bytes

Converting whitelist to signature fdt
BOX-WINE_LDWM-rel
wired-arm64-AP-SECP384R1_1-rel
wired-arm64-OD-SECP384R1_1-rel
wired-arm64-RT-SECP384R1_1-rel
wrote 558 bytes to 0000000082330000
## Application terminated, rc = 0x0
** File not found part.new **
87760567 bytes read in 4176 ms (20 MiB/s)
## Loading kernel from FIT Image at a0000000 ...
   Using 'conf@3' configuration
   Verifying Hash Integrity ... sha384,secp384r1:wired-arm64-RT-SECP384R1_1-rel+ OK
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0xa000012c
     Data Size:    10563592 Bytes = 10.1 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x80080000
     Entry Point:  0x80080000
     Hash algo:    sha1
     Hash value:   186b252be8c267ec7b20b072de98fe3d51c93c7f
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at a0000000 ...
   Using 'conf@3' configuration
   Verifying Hash Integrity ... sha384,secp384r1:wired-arm64-RT-SECP384R1_1-rel+ OK
   Trying 'ramdisk@1' ramdisk subimage
     Description:  meraki-image
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0xa0a13224
     Data Size:    76964193 Bytes = 73.4 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   a1f027fbf5acbf81befdb6ce746fee76adf132d5
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at a0000000 ...
   Using 'conf@3' configuration
   Verifying Hash Integrity ... sha384,secp384r1:wired-arm64-RT-SECP384R1_1-rel+ OK
   Trying 'fdt@3' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0xa538fb0c
     Data Size:    46124 Bytes = 45 KiB
     Architecture: AArch64
     Load Address: 0x90000000
     Hash algo:    sha1
     Hash value:   dd869c604072a7e29f37cc6cb4e1c9c398a46295
   Verifying Hash Integrity ... sha1+ OK
   Loading fdt from 0xa538fb0c to 0x90000000
   Booting using the fdt blob at 0x90000000
   Loading Kernel Image ... OK
   Using Device Tree in place at 0000000090000000, end 000000009001e42b
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
WARNING failed to get smmu node: FDT_ERR_NOTFOUND
WARNING failed to get smmu node: FDT_ERR_NOTFOUND
*** din = 0x0000000000000000

All ahead full! Goodbye!

All head full! Screw all attempts to boot any other software on this device! Let the LIC-MX85-SEC-3Y embrace your wallet!

To anyone still wondering: no, there will never be OpenWrt support for this device.


Idle power consumption: ~15W

The power supply in the MX85 is the same model (UMEC UP1501D-54) found in the MS220-8P and the MS120-8FP. It is rated for 2.7A at +56VDC

UMEC UP1501D-54 label


Model Codename Part number
MX85 Box Wine 600-102010

The codename of the MX85 might be “wines” there are multiple references to both in the bootloader and firmware.


¹: USB modems with MX/Z series devices running firmware MX 18 or newer will be limited to best effort support and will not be receiving any future firmware fixes or improvements. Meraki documentation

It would seem that Meraki prefers their customers purchase an MG41 or MG51 than plug in their own USB LTE modem. Better margins and less to support, win-win!


The GPL source code for the MX85 was requested from Meraki in May 2024. At the time of writing Meraki has not provided any of the requested source code.