As previously discussed in this thread:
I have requested the source code for many of their devices that I own, and the average time for them to provide source code is over a year at this point. Be prepared to be patient, they seem to enjoy dragging their heels on these requests.
Typical Cisco
Finally got the U-Boot sources. It's available here https://dl.meraki.net/U-boot-MR46-20240530.tar.bz2
Seems to have the same bug.
board/qca/arm/common/meraki_dev_boot.c
static int do_meraki_qca_boot(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
{
/* unsupported boards */
switch(get_meraki_product_id()) {
case MERAKI_BOARD_STINKBUG:
case MERAKI_BOARD_LADYBUG:
case MERAKI_BOARD_NOISY_CRICKET:
case MERAKI_BOARD_YOWIE:
case MERAKI_BOARD_BIGFOOT:
case MERAKI_BOARD_SASQUATCH:
case MERAKI_BOARD_WOOKIE:
printf("Secure boot is not supported on this model\n");
return 0;
default:
break;
}
do_update_uboot_keepalive();
if ((run_command("ubi check bootcustom", 0) == CMD_RET_SUCCESS) &&
(run_command("ubifsmount ubi0:bootcustom", 0) == CMD_RET_SUCCESS)) {
run_command("run check_load_boot_scr", 0);
}
do_part_dev_boot();
env_set("part","part.safe");
run_command("run boot_signedpart",0);
env_set("part","part.old");
run_command("run boot_signedpart",0);
run_command("reset",0);
return 0;
}
So after this u-boot source can we say that there is a chance for openwrt on this hardware or no chance?
Yes
U-Boot 2018.01-RELEASE-gb0bd058b3f (Nov 25 2019 - 16:41:18 -0800)
DRAM: 1020 MiB
Setting bus to 0
Valid chip addresses: 56
Meraki Product (major num): 1
NAND: ONFI device found
256 MiB
Using default environment
In: serial@78B3000
Out: serial@78B3000
Err: serial@78B3000
Device Tree: QCA, IPQ807x-AC01
machid: 8010009
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=0", size 237 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 1900, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 236/96, WL threshold: 4096, image sequence number: 2086049366
ubi0: available PEBs: 1845, total reserved PEBs: 55, PEBs reserved for bad PEB handling: 40
Read 0 bytes from volume part.safe to 50000000
No size specified -> Using max size (507904)
## Loading kernel from FIT Image at 50000000 ...
Using 'config_1' configuration
Trying 'kernel-1' kernel subimage
Description: Kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x500000c4
Data Size: 238990 Bytes = 233.4 KiB
Architecture: ARM
OS: Linux
Load Address: 0x4a900000
Entry Point: 0x4a900000
Hash algo: sha1
Hash value: f6d107506d6147554a84fd2d30674b9d2d207664
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 50000000 ...
Using 'config_1' configuration
Trying 'fdt-1' fdt subimage
Description: Device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x5003a740
Data Size: 91874 Bytes = 89.7 KiB
Architecture: ARM
Load Address: 0x4b900000
Hash algo: sha1
Hash value: 0694fa5a917c7397cd10aeb40df6104ec4fec94f
Verifying Hash Integrity ... sha1+ OK
Loading fdt from 0x5003a740 to 0x4b900000
Booting using the fdt blob at 0x4b900000
Uncompressing Kernel Image ... OK
Using Device Tree in place at 4b900000, end 4b9196e1
Using machid 0x8010009 from environment
Starting kernel ...
U-Boot 2018.01-DEVEL (Aug 27 2024 - 17:36:41 +0000)
DRAM: 1020 MiB
Setting bus to 0
Valid chip addresses: 56
Meraki Product (major num): 1 (minor num): 0
NAND: ONFI device found
256 MiB
Using default environment
In: serial@78B3000
Out: serial@78B3000
Err: serial@78B3000
Device Tree: QCA, IPQ807x-AC01
machid: 8010009
set_meraki_kernel_config -> config_1
Net: MAC0 addr:98:18:d3:e5:0:0
PHY: QCA 8033
PHY ID1: 0xffff
PHY ID2: 0xffff
PHY: QCA 8033
PHY ID1: 0xffff
PHY ID2: 0xffff
EDMA ver 1 hw init
eth0
Autoboot in 5 seconds
AXE #
Same situation as Z3. You need an external programmer to modify I2C EEPROM and NAND.
Warning: IO is 1.8V, 3.3V will lead to permanent damage!
I did not succeed to program them in-circuit using 1.8V level shifter. The I2C EEPROM is 3.3V tolerant out of circuit but NAND flash is not. I was also unable to source 1.8V ONFI NAND from any Western distributors.
How about this?
It might work. I only have an MR36, which uses a TSOP48 package.
From the FCC photos, it appears that other models are using BGA63 packages. Someone should confirm the model/specs of the BGA NAND used before you order anything on my word.
Again, someone with the hardware should confirm the part number used by the BGA flash.
The MR{3,4,5}6 series have 256MB of flash, not 128MB as the MR33/Z3 had. The FCC internal photos of the MR56 show a Winbond W29N02KZBJBE
I've got a MR56 in pieces.
The NAND chip is a Spansion S34ML02G200BHV000 and what I assume is the EEPROM is a ST M24C64-W
If you would like more board shots let me know.
I've also ordered some tools to try pull an image from the NAND, they might take a couple weeks to arrive.
But first - could someone please tell me where to hook up the UART?
Hi @hmartin
Have you gotten any further in your quest to conquer these devices? Thanks!
These 802.11ax devices are still relatively new, and are not that affordable to purchase used. They are lower on my priority list than upstreaming support for EOL devices like the Z3 which are plentiful and cheap (and more quickly destined to become e-waste as companies refresh their hardware).
The U-Boot source code is available, and I have documented how to modify the EEPROM contents to bypass secure boot, allowing someone to chain load an unlocked U-Boot build and start OpenWrt development. Kindly stop bumping for updates from me.
@hmartin I have a bunch of MR46. I would be willing to donate one to science. I don't think I can DM through these forums, so message me if you would.
I very much appreciate the offer; in the mean time I won an auction for an MR46 from eBay. Just have to wait for it to arrive via international shipping.
I also had someone reach out to me from another platform about donating an MR76, so I should be set for hardware and just need to sit down and find time to port OpenWrt
For what it's worth, I imported the U-Boot version for the MR46 (via the download link pasted upthread) into GitHub here: https://github.com/rkboni/U-boot.MR46
BTW: I finally got the MR44 sources from Cisco Meraki as well after almost half a year!
int ipq_board_usb_init(void) { return 0; } __weak in board_init.c maybe there is USB connection on board and allow boot from that USB ?
I got hold of another MR56 and a MR36.
The NAND in the second MR56 is a Winbond W29N02GZBJBF (or maybe E on the end) chip. The EEPROM is the same, an ST M24C64 chip.
The MR36 has a Spansion S34MS02G200TFI00 TSOP-48 NAND chip and probably a Fairchild FM24C64 EEPROM.
All appear to be booting different builds
Original MR56
[ 32.067460] boot 57 build 29-202305102255-G37027122-rel-greek board axe mac A8:46:9D:31:CF:8E
Second MR56
[ 30.841761] boot 18 build 28-202201122347-G0bb4b028-rel-gland board axe mac A8:46:9D:32:F0:FC
MR36
[ 25.129463] boot 274 build 30-202405212318-G10151e4d-Lb81a0b22-jenkins-rel-string board axe mac A8:46:9D:2C:19:52
All three devices have the same IMAGE_VARIANT_STRING
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.3.1-00147
S - IMAGE_VARIANT_STRING=HAACANAZA
S - OEM_IMAGE_VERSION_STRING=CRM
S - Boot Config, 0x000002e5
all have the same U-Boot version
U-Boot 2018.01-RELEASE-gb0bd058b3f (Nov 25 2019 - 16:41:18 -0800)
and all are booting the Axes kernel which appears to be similar (the same?) as the MR46.
I can't see any obvious USB connections on the boards of the MR56 and MR36.
Both have unpopulated pads like these which are labeled J1 and J16 on the MR56, and JP1 and JP2 on the MR36.
The larger looks like it could be pads for a 20-pin JTAG connector.
The smaller could be USB? I don't have enough expertise to test.
