LEDE-MR33

LEDE-MR33 copied to clipboard

Seems like Cisco blocks the old method of getting a serial prompt in this uboot version?

The ubootwrite.py script is sending xyzzy, but no prompt appears.

Maybe CONFIG_AUTOBOOT_STOP_STR was changed?

Where can one obtain the latest GPL sources of Meraki's uboot?

Update:

I tried pressing space instead on boot... Resulted in the device saying:

Secure boot NOT enabled! Blowing fuses... Resetting now.

It is dead now, won't boot and the orange LED stays lit.

Maybe Cisco is not so keen on replacing this device's firmware afterall.

Looks like this is now reflected in the flashing documentation in Google Drive. Is there any chance this will be solved, and is there something we can do to help?

@Ordspilleren best thing to do at this point is to request the latest u-boot GPL source from Meraki. This should hopefully show us what Blowing fuses... Resetting now. actually does to the device.

I got the U-boot source from Meraki. From at quick look at the code, the whole Blowing fuses... Resetting now. ordeal seems to be related to the Qualcomm QFPROM. I am not qualified enough to figure out much more, or the solution for that matter. Here's a link for the source: https://drive.google.com/file/d/1fIs0rZI2a6UOqal6JS4nxI-Ld4co0O_B/view

My Meraki licence expires this year, I wait hopeful that the 2017.07 version of U-Boot is able to be flashed before then! Unfortunately this is beyond my ability.

Looks like what you're doing there is enabling secureboot. xyzzy should still work (with secureboot disabled) though, at least it seems like that in the code/config, I only had a brief look at the source though.

Some fuses are write once and can never be deactivated (at least not in software), I don't know if that fuse is one of those.

In the 20170427 u-boot sources the file include/configs/ipq40xx_cdp.h contains CONFIG_AUTOBOOT_STOP_STR set to xyzzy and in the newer u-boot sources of @Ordspilleren CONFIG_AUTOBOOT_STOP_STR is completely absent. So I guess they disabled it on purpose.

Instead the newer ipq40xx_cdp.h file defines new u-boot commands including boot_meraki_qca. This function forces secure boot and also "blew" the fuse on my device. (Looking at the code this should make no difference and it should already have been blown on my device, maybe for devices upgrading from older u-boot versions?) Devices with 20170427 u-boot seemingly do not use secure boot and are therefore able to run arbitrary code while devices with the newer u-boot only run signed code?

any news on the issue? I'm stuck on"uploading image" no prompt...

If it's really an efuse then you blow it once and that's it, no way to recover.

What you can always do when secureboot is inactive is desolder the flash and replace the uboot.

I found this document on Secure boot :https://www.qualcomm.com/media/documents/files/secure-boot-and-image-authentication-technical-overview.pdf Looks like secure boot has a efuse location for a root certificate hash to validate boot images. When you fail to boot a secure image it blows the fuses with the root cert.. or thats how i read the above. Not sure if Cisco even uses it though as it seems to mention that you can store certificates in ROM as well.

Has anyone managed to JTAG the MR33? I've got a couple of fresh ones and I would like to backup the firmware so that I can "roll-back" the Meraki bootloader later when it gets updated.. I suspect that the pinout is the 10x2 holes on the side, but I'm getting weird readings on my multi-meter and the traces don't seem to line up whats specified in the standard ARM 20-pin JTAG Layout...

Guys, any news? My version is: U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017 - 07:43:44 -0700)

What did you do so far? Already pressed space and seen Secure boot NOT enabled! Blowing fuses... Resetting now.? In that case its already bricked, most likely forever. If you havent seen that yet the easiest way is most likely to replace uboot.

any news on the issue? I'm stuck on"uploading image" no prompt...

Did you work this out?

I have the same issue. Verbose mode gives me "Waiting for prompt.." then nothing.

I've tried setting the baud rate, data bits and stop bit, but still nothing. Have verified that I have a working serial connection in/out.

I never got this working. I blew two rasperryPi's and then the AP itself trying to JTAG in and dump the memory so that I could flash it back if necessacary... Not that it means it doesn't work, jus tthat im not very good at soldering and double checking cable pinouts :(

Any update on this?

The method I mentioned above still works. Desolder flash, replace uboot, solder it on again.

The method I mentioned above still works. Desolder flash, replace uboot, solder it on again.

@Flole998 are there any instructions on this? I've never flashed a NAND flash chip before, removing it should be ok, I have a heat gun but only really done this many years ago. Also, is it the chip under the tape?

There are datasheets available that tell you everything you need to know about that flash. The basic steps are dump, seperate OOB/ECC, modify, calculate new ECC and write back.

What might work aswell is to short the flash when uboot tries to load the kernel, depending on it's configuration it might fall back to a console.

Was this tested anywhere?

As I'm not familiar with how wear leveling, etc works. But I have two MR33 - one running OpenWRT, one on stock software (fortunately still 2y of license to wait for any developments).

I thought about booting modded one into initrd and then hot-swapping flash and reflashing it from linux - would this work? (let's skip physical part of swapping flash in the answer)

If I understand correctly, in this kind of environment software (uboot/linux kernel) is responsible for all the leveling/ecc stuff, not memory controller like on flash drives?

Actually I've done it before, it's been quite some time ago though. I'm not sure if someone else has done it or if this is documented somewhere.

I've heard of hot-swapping flash causing a brick before, however that was on a different device.

What could work is cloning the other NAND if you don't want to do the modifications manually, if it contains calibration data though that would need to be written back afterwards.

The thing is, I've waited until the boot process finishes and I accidentally tried to exit out of screen using CTRL+C, and this gave me a Meraki> prompt. Now I don't know at which step that it causes the fuse to blow. Is it once it reboots with the uploaded openwrt u-boot and realises it's not signed or something? Because I've replicated what I've done on the same device over several reboots and I always get the prompt.

Also, I took a full back up when I successfully flashed another MR33 yesterday of MTD. Is this useful for the MR33 with the newer firmware?

@Flole998 sorry to bothering you, can I use mr33-uboo.bin from this source? https://drive.google.com/drive/folders/1jJa8LzYnY830v3nBZdOgAk0YQK6OdbSS address should be ? 0x000000700000-0x000000900000 : "u-boot" or gerneric processes can be the same?

1.Create a full dump of the SPI Flash, and store it in a safe place
2.Erase and Clear 0x0-0x3ffff on the SPI Flash
3.Flash U-Boot to 0x0
4.Proceed to the OpenWRT Install Procedure

referrer : https://openwrt.org/toh/aruba/aruba_ap-105

The basic process is the same, yes. Just that this is not a SPI Flash and the address is obviously different. But dumping, replacing and writing back are the correct steps, just that in this case I desoldered the Flash because I don't want the CPU to interfere with my programming operation.

If you observe the boot process when you're connected via UART, it will tell you

On Wed, 15 Jan 2020, 12:27 Richard L. Alhama, [email protected] wrote:

hi how would you determine the uboot version without running ubootwrite.py?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riptidewave93/LEDE-MR33/issues/13?email_source=notifications&email_token=ABBTB3CX4PL2IUH65CHMJO3Q536KTA5CNFSM4GMEISR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAEQDI#issuecomment-574638093, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBTB3CBZO2SKL2HZVVJC5LQ536KTANCNFSM4GMEISRQ .

connect terminal to uart port and you must see on the begining of the boot process, like this

"U-Boot 2012.07-g97ab7f1 [local,local] (Oct 06 2016 - 13:07:25)" ...

If you observe the boot process when you're connected via UART, it will tell you … On Wed, 15 Jan 2020, 12:27 Richard L. Alhama, @.***> wrote: hi how would you determine

I have U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017). Guess I have to hone my soldering skills then.

Thanks

Hi guys,

Is there a way to know the bootloader version (without opening) by booting the MR33 and checking firmware version by example ?

Thanks

I've tried even unsoldering the flash chip, but without success - looks like it's glued and then soldered.

So the only idea I've got is clamp on tsop-48 (https://www.aliexpress.com/item/32838230005.html?spm=a2g0s.9042311.0.0.27424c4dsE1VcC) and then writing old uboot.

If it's glued down and they didn't put too much glue on it you can just remove it with a heatgun.

The problem with those clamps is that the CPU must be held in reset and the pins for the flash must not be pulled in either direction (low or high), otherwise the CPU will interfere and you will get weird results.