Cisco Meraki MX64/MX65 image support

For Developers
376

Can confirm, not USB media. This was my first attempt at troubleshooting, formated to FAT 1GB mbr partition, used more than 1 USB drive to test. shaw256sum confirms.

Tried env default from uboot menu, no change.

Correct in your initramfs there's nothing under /lib/modules to modprobe.

I'm hesitant to erase and re-load the uboot environment as this chances bricking the device.

I'm wondering if the bad blocks reporting in bootlog is indicative of where the issue lies:

[ 1.179677] nand: 1024 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224
[ 1.187453] iproc_nand 18026000.nand-controller: detected 1024MiB total, 256KiB blocks, 4KiB pages, 27B OOB, 8-bit, BCH-24 (1KiB sector)
[ 1.179677] nand: 1024 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224
[ 1.187453] iproc_nand 18026000.nand-controller: detected 1024MiB total, 256KiB blocks, 4KiB pages, 27B OOB, 8-bit, BCH-24 (1KiB sector)
[ 1.200444] Bad block table found at page 262080, version 0x01
[ 1.206915] Bad block table found at page 262016, version 0x01
[ 1.219655] 7 fixed-partitions partitions found on MTD device brcmnand.0

Can you compare the sha256sum from the other mtd partitions?:
root@OpenWrt:~# sha256sum /dev/mtd0
342b68d1687a955255cd85dbeb6aa524a0d492cb43436b6a0d04aa3b1f1aef67 /dev/mtd0
root@OpenWrt:~# sha256sum /dev/mtd1
042b389daa71074fbad77c32375c01cca1e7153827e773131383c93f4dabc343 /dev/mtd1
root@OpenWrt:~# sha256sum /dev/mtd2
cc495db758c31cb3ffc87d491bed32b132f3d4faaa0e2391e13ed7d0a08c321d /dev/mtd2
root@OpenWrt:~# sha256sum /dev/mtd3
62a40424aea5e906f2c89f16f93d0868a3df6d992ac993a43953c7a944d185fb /dev/mtd3
root@OpenWrt:~# sha256sum /dev/mtd4
2962892d6b133903323b030661dfcd4f9373dda50fc0cadcc229d86860d03895 /dev/mtd4
root@OpenWrt:~# sha256sum /dev/mtd5
042b389daa71074fbad77c32375c01cca1e7153827e773131383c93f4dabc343 /dev/mtd5

This stuff is over my head so I'm struggling to come up with ways to troubleshoot. I've built a dev environment but unsure what all to select in the make config.

I can try to do some troubleshooting with the old clayface initramfs, but it kernel panics so time is limited to be able to attempt this. At boot, nothing shows up in ifconfig.

Crazy idea, what if usb storage is included in an intramfs image ... that would simplify the project for all going forward as we could write the sysupgrade bin directly?

377

This is bad block table written at the factory - which is good to have :wink:
As for sha256sums, u-boot and u-boot-env match, bootkernel1 and bootkernel2 contain old OpenWrt kernels, so they naturally won't. Shmoo is DDR calibration, that's individual per device, and nvram isn't used by U-boot nor OpenWrt.

Just now I've looked at the boot log once again...

[    0.662890] i2c_dev: i2c /dev entries driver
[    0.667415] bcm-iproc-i2c 18038000.i2c: bus set to 100000 Hz
[    1.146979] random: crng init done
[   54.266961] bcm-iproc-i2c 18038000.i2c: transaction timed out
[   54.274237] bcm-iproc-i2c 18038000.i2c: bus is busy

and gotcha!

Check the I2C bus on your device for shorts on the EEPROM - and for pullup voltage ond clock and data. This sounds like a hardware failure indeed!

378

I've successfully upgraded my MX64 A0 to the latest version but the kernel version is still incompatible with most of the KMOD packages, specify the wireguard/openvpn packages.
I've checked the repositories but it is unable to retrieve from the one set for this kernel version (error 8)
Is there any chance this will be fixed?
Appreciate all the work you're doing!

379

This is super unfortunate, and could be for when I was trying to connect my TTYL device late night on the 16th. One of my ttyl devices stopped working after I had connected one of the power wires ... this could surely be the cause of the error we're seeing...

shit ... onto the MX64 devices I have, I was really looking forward to having 10 usable network ports.

Thanks so much for your help anyways, fings crossed I can get my hands on a cheap or free MX65 again in future to restart this process.

380

No worries - if it's only dead memory chip - it's recoverable, it only contains serial number and the MAC address. I can share dump of mine, that you can edit and write to a new chip yourself.
Edit: see mx65_24c64.bin on the google drive. I've replaced the MAC (at 0x66) with 0x123456789ABC (hex) and the serial number (at 0x7C) with ABCDEFGHIJKL (ASCII).

I've attached kmods and other nonshared packages in packages.tar.zstd. See there. Also, yes - opkg will complain about kernel dependencies if you download official feeds, so clear its cache before installing kernel-related stuff manually.

381

No worries - if it's only dead memory chip - it's recoverable, it only contains serial number and the MAC address. I can share dump of mine, that you can edit and write to a new chip yourself.
Edit: see mx65_24c64.bin on the google drive. I've replaced the MAC (at 0x66) with 0x123456789ABC (hex) and the serial number (at 0x7C) with ABCDEFGHIJKL (ASCII).

If you can elaborate on this (aka mansplain) I'll give it a crack.
What command will I be writing, and is this from uboot? Who knows if it'll come back to life at all. fings crossed..

382

I used vbindiff as a crude hex editor to replace the values in the binary dump of EEPROM - you can do the same thing with values from bottom label of the device. But first you need to get an AT24C64 (or compatible) chip in SOIC8 case, like this one: https://www.digikey.pl/en/products/detail/microchip-technology/AT24C64D-SSHM-T/2507878 - and then preferably use an external programmer if you (or some of your friends) have one.

I'm unsure if the write-protect flag is set on the board itself by pulling the !WP pin low, but I think I can build you a special firmware that will allow you to write to the chip from under Linux (and complete bootup with network in the first place).

Let's wait a few days, until I return home and have my tools at hand, so I can check a few bits on my device before proceeding. An electrical multimeter at your side is going to be useful, too.

Changing the topic to the LEDs for a while: do you recall which LED patterns were used by the stock firmware? I've managed to expose LAN LEDs to userspace, but I'd like to configure them in line with factory firmware - default settings use only a single LED per port, and I'm not sure if it was meant to be this way.

383

nah man, if it requires soldering chips or programming on the hardware level like that then I'm ok to fold on this device. If it were a matter of just writing a uboot back onto the board through a command prompt to try and revert it to stock, sure but, I'm not into re-writing chips in this method. I lack the steady hands and hardware to be able to redo chips the size of the ones on this board.

I'd happily ship it to you for your dev pile, but I'm in Canada and suspect the shipping would be ridiculous.

I do have a multimeter if you're curious as I am and I can probe the device, at this stage maybe hit me in DM as we're blowing up this thread pretty good :slight_smile:

384

Definitely it will. Maybe then someone closer could pick it up ;-]
Lets' go to DMs for the hardware stuff when I'm back home, as I don't even have a T8 screwdriver here to open my device up - and consider this thread finished here.

So, back to main topic:

And also, new test builds in the google drive! This time with PoE and LAN LEDs!

1 Like
385

I get this error when I try to upload the package:
"Collected errors:

  • pkg_init_from_file: Malformed package file /tmp/upload.ipk."
    The opkg install command failed with code 255 .
386

And also, new test builds in the google drive! This time with PoE and LAN LEDs!

Good news, I installed WRT on my MX64W.
Speedtest 798 down 668 up.

I followed the directions from: bcm53xx: add support for Cisco Meraki MX64/MX65 by Leo-PL · Pull Request #16634 · openwrt/openwrt (github.com)

When it came to boot from USB, I was not able to get any network connection, after Downloading the newer 2 file to USB from Leo's Google Drive,
openwrt-bcm53xx-generic-meraki_mx64-initramfs.bin
openwrt-bcm53xx-generic-meraki_mx64-squashfs.sysupgrade.bin

Everything came online as expected!

Is there any additional testing I can do to assist the project going to full support on MX64 ?

387

It just got merged: https://github.com/openwrt/openwrt/pull/16634#event-14772293282

If there are any fixups needed for the network on MX64's, please let me know - because I don't have any, so I have to rely on external tests.

5 Likes
388

Fantastic news! Thanks for Your work, sincerly.

2 Likes
389

Tremendous news! Great Work!!
How can the wiki get updated, now, so people can download the newest binaries? Or is the intention to build each time?

390

You can ask for a wiki account to do some updates, I think there is a pinned topic on the forum. I'd appreciate that.

@Ansuel we need you here. I made a patch after uncovering some secret knowledge, that MX65's internal QCA8337 switches are interconnected via RGMII.
I made a patch to try it out: https://gist.github.com/Leo-PL/934f87295521f3073c079216e5d60e27 - but after applying it, there are no signs of probe of each other. Do I think correctly, that both switches need to reside in one DSA tree (now they do not) for this to work? Do you think qca8k could handle that?

1 Like
391

mhhh i feel dome dsa-member property are needed to say to the dsa subsystem they are interconnected and also I assume some changes are required on the code to support that confdiguration...

Any chance you have the original firmware where you can dump the register?

1 Like
392

Maybe @clayface does, I got my units pre-flashed with early builds of OpenWrt.
I think I'll try moving both switch definitions into single tree - there is dsa,member for each one, but specifying separate trees per switch IC.

Another (polite) request: could you take a look at qca8k LED patches for device, before I send them to LKML?

TL;DR I needed to move the PHYs to internal MDIO for the LEDs to get the right names, because upper MDIO bus didn't hold a textual ID.

393

that won't work... they are still different switch that needs to be configured separately... just the port 6 should not be configured as cpu port...

394

DT bindings allow specifying of tag protocol on a given port - maybe that's a chance. Currently both qca8k's use port 0 as kinda CPU ports (using ethernet binding but no cpu label) attached to main bcm switch - which, I think allows the kernel to perform double DSA tagging. I'll try that when I have some more time to tinker and a USB-UART on hand. I have to say, that this really tickles my curiosity.

395

Just installed a snapshot from the OpenWrt downloads section on my MX65. Thanks a lot for getting this included in OpenWrt.