Cisco Meraki MX64/MX65 image support

For Developers
641

I'm still using a 24.10 PoE enabled variant at present.

642

Is the 25.12.0 release candidate using nftables ?

643

There's a lot of bugs at present, no worth running as a daily unless you want to go reporting every issue.

644

I hope I'm not intruding by adding to this thread. I had a crappy time trying to get my MX64 (A0) to boot using the notes from a Pull request that I found. I managed to get to the point where it's booting from the USB drive and I finally got a UART and can see that it's loading the initial image, but then it sits at the following screen and basically stops. I used the image at Cisco Meraki MX64/MX65 image support - #198 by clayface since I have an A0 board. Previously when I tried this, I got the thing about not having a bootm compatible image, so I hope that was the right thing to grab!

Should I be using a different initial install image? I've got openwrt-bcm53xx-generic-meraki_mx64_a0-initramfs.bin

   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x90a6500c
   Uncompressing Kernel Image ...
645

Yay! I finally found the correct bootm image (by searching backwards in time through this thread) and can get it to install the initial firmware. But when I try to do the upgrade, I get this:

root@OpenWrt:/tmp# sysupgrade openwrt-bcm53xx-generic-meraki_mx64_a0-squashfs.sy
supgrade.bin
Thu Jan  1 00:07:32 UTC 1970 upgrade: Device meraki,mx64-a0 not supported by this image
Thu Jan  1 00:07:32 UTC 1970 upgrade: Supported devices: meraki,mx64,a0
Image check failed.

Notice that one says mx64-a0 and one says mx64,a0. So I'm stuck again. Did I miss the correct file somewhere again?

646

Nevermind. I just did a --force on the sysupgrade and it looks like I'm in business!

647

Did I brick my MX64?

I did this part without issue I think:

BusyBox v1.7.2 (2016-02-24 18:16:57 PST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cat /sys/block/mtdblock0/ro
1
#
# devmem 0x18000000
0x3F05CF1E
# wget http://192.168.1.100/mtd-rw.ko
Connecting to 192.168.1.100 (192.168.1.100:80)
mtd-rw.ko            100% |*******************************| 52496  --:--:-- ETA
#
# insmod mtd-rw.ko i_want_a_brick=1
#
# dmesg
mtd-rw: mtd0: setting writeable flag
#
# wget http://192.168.1.100/mtd
Connecting to 192.168.1.100 (192.168.1.100:80)
mtd                  100% |*******************************|  7846  --:--:-- ETA
#
# chmod +x mtd
#
# wget http://192.168.1.100/uboot_mx64
Connecting to 192.168.1.100 (192.168.1.100:80)
uboot_mx64           100% |*******************************|   573k 00:00:00 ETA
#
# ./mtd write uboot_mx64 /dev/mtd0
Unlocking /dev/mtd0 ...
Writing from uboot_mx64 to /dev/mtd0 ...  [w]
#
#

At this point I powered it off, connected the usb with openwrt-bcm5862x-generic-meraki_mx64-initramfs-kernel.bin on it, but the led only flicked white quickly then stayed orange, so I connected the ttl serial, rx,tx,gnd pins only, 115200-8-n-1, and i get no output at all completely blank.

Tried the usual boot interruption keys, pressing the reset button etc but no output at all. I did a loopback test on the ttl-serial and that si working fine. tried swapping tx/rx just incase but nope..

Would a bricked device result in no serial output like this?

648

When you boot the initramfs from the USB drive you need to press the reset button while you power it on. For some weird reason I did not get any output on serial either until it starts booting the initramfs.

649

That’s interesting to hear, unfortunately yes I had the usb inserted and tried holding the reset button as it booted up, the orange light never changes from orange, have tried holding the reset button for various amounts of time. Will try again fat vs fat32. Is it looking for the exact filename for initramfs or anything *.bin? I might have had openwrt.bin on the usb stick the very first time i inserted it , wonder if that has caused the issue.

650

I'm not sure if the fat version makes a difference. I used a 512 MB fat16 (dos) partition on a 8GB USB drive. Uboot will look for a specific filename as far as I understand: openwrt-bcm53xx-generic-meraki_mx64-initramfs.bin

I don't think the initramfs is available for download from the openwrt downloads section so you will have to build it yourself. The one I built did not have luci included so after it started I had to use ssh to do the final sysupgrade to make the install permanent.

The device is a bit of a pain to flash but once it works it does have a large amount of ram and storage space for additional packages.

651

I managed to flash a mr33 Ap but this MX is causing a lot of trouble. What I did was download the uboot and initramfs from here and use those, I didn't build anything, once I could get into uboot I planned to flash the official build on the openwrt site https://github.com/clayface/U-boot-MX64-20190430_MX64

652

I don't know if those initramfs files work. There have been some changes between clayface initial work and leo-pl getting the device officially supported. I did build the 24.10.5 initramfs and know that it works with the git instructions.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7ad9988287965be2119df320cfc645b0a8b9d94e

653

Do you still have your build files? Any chance you could share them. I'm fairly sure mine is bricked but I could give it another try with a known working initramfs

654

I'll try to find a free file share somewhere. Link I previously posted did not seem to work. Try this link instead:

https://limewire.com/d/v2gtE#lGCBP02jpU

655

Legend thanks!

656

Well I cant believe it but It worked! thanks again.

657

Cool. Nice to hear that another bit of Meraki e-waste has been avoided.

658

I don’t have any direct experience with the MX64, but other Meraki devices (like the MX84 and MS225) don’t play nice with some USB to UART adapters. There seems to be an issue with leaking current from the UART adapter keeping some part of the SoC active, and thus when you try to power up the device with the UART adapter already connected, the device doesn’t boot. I have observed this issue using CH340 and PL2303 based UART adapters.

My solution for these devices has just been to unplug the USB to UART adapter from USB (to remove power) and only plug in the USB side a second or two after the target device has been powered up. This consistently results in the device booting correctly, with the expected UART output, although you will miss the very first boot ROM messages.

FWIW, I have an older BusPirate v3 which doesn’t have this issue, so I use that when I absolutely need to see the first boot UART output.

659

Is it possible to enable isolate feature on a port as part of DSA?


Root@OpenWrt:~# bridge link set dev lan1 isolated on
Error: bridge: bridge flag offload is not supported.

Or which ways for asymmetric (lan1-lan2, lan1-3 not isolated, lan2-3 isolated) port isolation exist for this model? Ports staying in the same subnet.

660

Yesterday I used this method to flash my mx64a0.

Indeed, and the console remains working after a hot reboot.

@clayface Could you make your u-boot builds try to boot the file loaded from the usb drive with bootbk automatically after bootm fails, so that initramfs-kernel.bin files provided by your https://github.com/clayface/U-boot-MX64-20190430_MX64 can also be used?

Furthermore, your u-boot currently only support loading initramfs-kernel.bin files from usb drives, but that does not always succeed (at least loading FIT from usb drives and then bootm-ing it fails me during the whole night), so could you add tftp capability as well?

I also have some questions:

Currently the rootfs_data can only take around 360MiB, but there are UBI volumes named "part.old", "part.safe", "board-config", "storage", "diagnostic1" occupying half of the flash, "storage" even has a UBIFS in it, likely leftover of the vendor OS. so:

  1. "board-config" seems containing the mac address as in mx60, so it had better be retained, butDevice tree shows that the mac address is stored in a dedicated flash chip on the i2c bus, so are other these leftover volumes, especially the largest "storage" (512MiB), useful after installing openwrt?
  2. Are there any leftover volumes worth retaining as a recovery method?
  3. Which leftover volumes could be removed securely without breaking openwrt as well as the potential recovery method above?

The used space of "storage" is quite small, so at least I might be able to shrink it to 128 LEBs (31MiB) by backup, removing, recreating and restoring, to free its space for the future updates without breaking the leftover of the vendor OS.