Not working on U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017 - 07:43:44 -0700)

[0xFelix]

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?

[Leo-PL]

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.

@0xFelix do you still have your bricked unit? If so, I'd like to get my hands on it somehow :-)

[0xFelix]

Indeed I still have it. Now I know why I've kept it for so long... in the name of science. ;-)

You can have it. How do we get it to you?

[Leo-PL]

@0xFelix I live in Poland, so we'll have to arrange shipping somehow. I've heard stories of Polish Post not working well when receiving stuff from Deutsche Post, so I have to investigate a bit, how to handle that properly. Of course, I'll cover the shipping costs.

Alternatively, I have some relatives in Germany, who could get the unit to me on next visit. Could you contact me on private email for details? Edit: too bad that CCC this year is remote-only again, otherwise we could possibly meet there.

[0xFelix]

@Leo-PL I've sent you a mail.

Yeah, too bad. That would have been great.

[jarojed]

Hi guys, my MR33 license just finished and I found that issue. Unfortunately no NAND programmer in my garage.

till have your bricked unit? If so, I'd like to get my hands on

@Leo-PL , Hi, I'm from Poland as well (Toruń/Bydgoszcz) if you don't mind I can deliver mine still working unit to you in order to write old enough u-boot :-) I'm away from home now but as it was working connected to the Internet till the end of the license I assume it has 2017.07 already.

Cheers, Jaro

[Leo-PL]

Hi guys, my MR33 license just finished and I found that issue. Unfortunately no NAND programmer in my garage.

till have your bricked unit? If so, I'd like to get my hands on

@Leo-PL , Hi, I'm from Poland as well (Toruń/Bydgoszcz) if you don't mind I can deliver mine still working unit to you in order to write old enough u-boot :-) I'm away from home now but as it was working connected to the Internet till the end of the license I assume it has 2017.07 already.

Cheers, Jaro

So you do want me to flash it for you, right?

[jarojed]

Hi guys, my MR33 license just finished and I found that issue. Unfortunately no NAND programmer in my garage.

till have your bricked unit? If so, I'd like to get my hands on

@Leo-PL , Hi, I'm from Poland as well (Toruń/Bydgoszcz) if you don't mind I can deliver mine still working unit to you in order to write old enough u-boot :-) I'm away from home now but as it was working connected to the Internet till the end of the license I assume it has 2017.07 already. Cheers, Jaro

So you do want me to flash it for you, right?

Yes, I've sent you email.

[Leo-PL]

MR33 from @0xFelix arrived yesterday, thank you so much! I've already desoldered and dumped NAND, its contents are left intact. Cisco u-boot blew the fuses for sure. Before desoldering IPQ4029, I'll add the missing button on the bottom side, and do some poking and prodding around the connectors. I suspect that J5 is used for QDL, for factory programming, J13 is for JTAG, and P1 is debug connector for Bluetooth. There is an unpopulated switch, SW2 on bottom layer, which might be used to force the unit into QDL mode. Getting the Firehose loader for this will be an entirely different topic, though - this is usually a very well guarded secret.

The board will also serve well for Bluetooth development, once I get appropriate connector for P1 header, with J7 acting as UART connector for CC2650.

[halmartin]

@Leo-PL did you already desolder the IPQ4029? I have a copy of the signed SBL and u-boot that will probably work on that MR33.

[Leo-PL]

@halmartin not yet, thankfully! But I have desoldered the NAND and still have a programmer handy. Please contact me via email. Could you double check if pkhash used to sign your SBL1 matches one in Cisco U-boot sources, somehow? I haven't yet located the USB testpoints, let alone Sahara loader, let alone signed one matching that pkhash, so far, so recovery would still require desoldering NAND as of now.

[Leo-PL]

I found that fuse content lies in board/qca/arm/common/sec_dat.h, however I have yet to make sense of it.

[Leo-PL]

I got an image from @halmartin. Flashed and soldered in, but the unit did not boot. I need to double check the OOB layout, and also if I didn't damage the board beforehand, while replacing serial headers with a normal-height ones. No output, even from SBL1, orange LED stays lit all the time.

@halmartin do you know how the exact board type is detected by U-boot? If it is actually detected runtime, @mveplus' board could be used to at least check if SBL1 works, as SBL1 itself should not blow the fuses. And I'm pretty sure this wasn't due to soldering, as joints turned out very nicely. Anyway, I desoldered the NAND once more and I consider socketing the board, at the moment.

[Flole998]

If the key it's signed with is not the one that's burned into the CPU (or if it has been essentially put in "self destruction mode" which exists on some CPUs aswell) then it won't boot.

[Leo-PL]

According to @halmartin all Meraki IPQ4029 devices share U-boot code, and this is visible in the sources as well. However, we can't be certain that the fuses file included in GPL sources actually matches one in the production binary, which was used to blow them in the first place. Also, the customization of Qualcomm chips in that matter is quite flexible, with multiple certificates used to differentiate between manufactures, devices and even single images. Cisco might have used that.

[halmartin]

@Leo-PL the u-boot code is largely the same, from what I can tell, the Z3 u-boot release includes some additional set up for the onboard switch but is otherwise very similar.

Unfortunately, I see now that the Z3 (fuzzy_cricket) has a device-specific signing certificate :disappointed:

Since the MR33 is officially not supporting secure boot they do not upgrade the SBL and QSEE to signed versions when they burn the certificate, so I guess this was a poison pill.

[Leo-PL]

This was my guess from before firmware for Z3 appeared as well.

Press F to pay respects, then. Still I wonder, if MR33 keys are not some kind of test keys.

But for MR33 this also means, that:

• if we locate factory USB connection any Firehose NAND loader will work for flashing,
• JTAG is not disabled, as it is disabled by the same fuses as secure boot. So, having the pinout for IPQ4019 available on the 'net - very similar to IPQ4029 - I think that now it may be the time to actually desolder the chip. I'll still wait a bit, though for any ideas to come up.

Also, no wonder, that Cisco did not upgrade SBL1 and QSEE in the field, as they did not care to introduce dual-boot feature for those, and backup partitions for every part of boot chain, U-boot included - which they did update in the field - are empty. Only OS uses proper redundant boot.

[drws]

@Leo-PL I'm preparing to flash a MR33 with an FT2232H board and I found your fork from 2019. You mentioned some improvements in a comment earlier this year so I'm wondering if that repository contains everything needed for a working flasher? Would you be so kind to explain the process in more detail?

[Leo-PL]

@drws it's still not fully ready - I had to do some hackery mid-flight. Erase/write timing seems wrong, and so I had to erase the U-boot and UBI regions a few times first, and then program them a few times, so the data actually matched. Or maybe, this was a power supply thing - I'm not sure. If possible, get your hands on TL866II+ ;-)

[ziswiler]

get your hands on TL866II+

Or just go with a Teensy++ 2.0 (10 bucks on AliExpress) and a 360-Clip (30 bucks on AliExpress) soldered to it as @chunkeey outlined above (BTW: Thanks @chunkeey!). That way I was easily able to make 5 devices work which previously were on too new U-Boot versions.

[Leo-PL]

+1 for 360 clip if you have one. If you have only a ZIF socket plus hot-air station, this will work too. I used this for 5 units in total as well - however, I might have damaged NAND from one of four units I did recently by ESD. Now it sometimes misbehaves after sysupgrade, so I kept it with me. Good news is, that since i have a spare NAND chip, I might replace it later, and also improve my NANDReader_FTDI fork write support.

@drws if you'd like to go with that method, please ping me - I'll try to dig out the commands I used to program the required segments. This is how my programmer looks like:

[drws]

While I understand that TL866II+ and Teensy with breakout are more reliable solutions, I'm still interested in the FT2232H since it's the lowest cost. I only have a single unit to revive and I understand that erase and flash procedures need to be done and verified carefully.

@Leo-PL I'll probably manage either way and am in no hurry. I'll be grateful if you can provide me with commands. Also if you choose to improve the code I'll wait and test the new version when it's ready. It would be really cool to have another low-cost flasher option.

Regarding the physical connections, I see there are both desoldering and in-circuit solutions. Is there some limitation to FT2232H programming the chip in-circuit if I manage to tap the needed pins/traces correctly?

[ziswiler]

FT2232H since it's the lowest cost

Okay, but a Teensy is just 10 bucks!

Regarding the physical connections, I see there are both desoldering and in-circuit solutions. Is there some limitation to FT2232H programming the chip in-circuit if I manage to tap the needed pins/traces correctly?

Exactly, that's the real issue and a 360-Clip just does cost 30 bucks :smirk:.

[exetico]

Are there anyone from Denmark in this thread, with the proper hardware for U-Boot flash?

If so, kindly ping me if you would like to help with two devices with newer U-Boot version 👍 (so it can be downgraded)

[Leo-PL]

While I understand that TL866II+ and Teensy with breakout are more reliable solutions, I'm still interested in the FT2232H since it's the lowest cost. I only have a single unit to revive and I understand that erase and flash procedures need to be done and verified carefully.

@Leo-PL I'll probably manage either way and am in no hurry. I'll be grateful if you can provide me with commands. Also if you choose to improve the code I'll wait and test the new version when it's ready. It would be really cool to have another low-cost flasher option.

Regarding the physical connections, I see there are both desoldering and in-circuit solutions. Is there some limitation to FT2232H programming the chip in-circuit if I manage to tap the needed pins/traces correctly?

@drws Okay, I'll try to dig the commands out. My mid-flight hackery was based on recompilation of tool, to disable erase and disable write between the steps. Of course you can use 360-clip with FT2232H as well, or with any other programmer. I just happen to have had ZIF socket already, which was around 12$ at the usual suspects.

Of course, since my solution is pretty flaky at the moment, be sure to back up whole flash first and ensure with binwalk, that the data read by programmer actually makes sense.

[drws]

Okay, but a Teensy is just 10 bucks!

Unfortunately it's more 15-20$ or around 15€, but that's not the problem. It is that I don't want to have/support/learn multitude of development boards. I can borrow an FT2232H board just for this project. But in general there are hundreds of options available and I try to minimize the different hardware used in my projects by selecting the one with best P/P, hackability and future support. Teensy is a candidate, but it's irritating me with its high price and P/P. I can build a 10-node wireless sensor network with ESP32 boards for the price of 2-3 Teensys. And what bothers me the most with Teensy is its ridiculous as well as confusing nomenclature, which is basically a misuse of versioning standards for marketing purposes.

Exactly, that's the real issue and a 360-Clip just does cost 30 bucks smirk.

These breakouts are great business I see. My limit to not take up soldering would be under 5€ and even that seems a bit high for a plastic socket. If tapping is the only issue I'll make an effort for some nice pictures when I get to it :)

[halmartin]

@drws It's great that you like your FT2232H board and think it's the best P/P. Instead of demanding other people furnish instructions and code to work with your favourite tool, maybe you could contribute code and instructions to use FT2232H as a flasher.

It is your choice to ignore the advice provided, but no one here is responsible to create a solution for you when multiple alternatives exist.

I would be willing to flash your MR33 for you, but I suspect shipping cost to France is above your budget for this project.

[drws]

@Leo-PL

I was thinking of both rereading and rewriting/reverifying until two reads match. Binwalk is a great suggestion for a triple-check. Also please don't invest too much time since I'm still not 100% sure what tool I'm going to use for the project. I asked for commands since I am interested in the example in any case, but only if you don't have to dig too much :)

@halmartin

It's great that you like your FT2232H board

I've edited my previous comment to better reflect what I meant. I can get one for the revival of this single MR33 unit I menitoned. I'm otherwise not really what you would call an FTDI fan.

and think it's the best P/P

I never said FT2232H is the best P/P and we both know this doesn't even make sense in comparison with general-purpose devices such as Teensies. I did mention the cheap ESP-series in that context as an example.

Instead of demanding other people furnish instructions and code

That's a serious allegation. I only (politely, as opposed to some) explained my logic in a discussion while not demanding anything. I haven't even decided against Teensy yet, I've only explained why I don't already have it.

It is your choice to ignore the advice provided

Actually it's the opposite. It has provided me with a strong point for buying a Teensy for having it as a hackable flasher. It's cheap in that regard.

no one here is responsible to create a solution for you when multiple alternatives exist

That goes without saying! And not only that, no one here is responsible to create a solution even if there aren't any existing ones.

I would be willing to flash your MR33 for you, but I suspect shipping cost to France is above your budget for this project.

It's not. And if I wanted the easiest and cheapest way out that was kindly offered before, but it's going to be a great exercise. In any case thank you for your offer, but not the attitude.

It would be really cool to have another low-cost flasher option.

And that's it. No hidden agenda, no deeper meaning, no conspiracy theories behind. Just a bit of enthusiasm. And I even deliberately put another in it, just to be clear it would be redundant.

[Leo-PL]

@drws I think that I should probably separate the write and erase operations, as mtd-utils do, this way it'll keep the internal implementation simpler. When I have more time, I'll probably do it, having yet another alternative way to flash the device is always good.

[Leo-PL]

@drws In case you still need it, it seems I forgot to push the code for write support. Now I did. https://github.com/Leo-PL/NANDReader_FTDI/tree/with-write As to why write and erase seem to need to be repeated I have a suspicion - look at the diff and you'll see it yourself. This wasn't my code, btw, just cherry-picked it and fixed the segfault ;-) So, this definitely needs finishing.

[Leo-PL]

@drws did you have any chance to test my hack? ;-) I noticed in the past, that R/!B pin on the schematic is missing a pullup, and I'm not sure if FT2232 correctly provides it - so I added one to my programmer. Going to test this shortly.

I also tried https://github.com/dmikushin/nandflasher recently - but this won't detect my chip at all, while the C++ implementation does, despite the fact that hardware is identical - modulo !CE pin, which should be hardwired to ground anyway.

Edit: I did some hackery in https://github.com/Leo-PL/NANDReader_FTDI/commit/9592f0219fa8ad9911afad9198f9829be18f434c that seems to make it work - I've got two erase successful and writeback cycles so far. Adding a proper pull-up resistor to R/B line also seems to be required for it to work properly.

[drws]

@Leo-PL Unfortunately it appears I won't be able to since I lent my FT2232 board and apparently it is going to be needed for some time. I will probably not be buying another. Now I'm looking around if I can get my hands on a TL866II+ and thinking about buying the Teensy. In any case a big thank you for your developments ;)

[Leo-PL]

Finally got the time to desolder the IPQ4029 from dead MR33, now I can trace out where that debug ports lead to. I took extra care to not sever any of BGA connections.

I also wonder if IPQ4019 from dead MF286D could be transplanted here, IIRC they do have some differences in the radio path. I might actually try that when I'm done with the tracing.

[BitToaster]

Atleast I can't get it to brick.

:~/Downloads/MR33 $ sudo ./ubootwrite/ubootwrite.py --write=mr33-uboot.bin --serial=/dev/ttyS0
Uploading image
Prompt is 'RNING! THIS CONSOLE IS LOGGED! UNAUTHORIZED ACCESS FORBIDDEN!
<Meraki> '
Found an error, so aborting
Uploading image
Prompt is 'RNING! THIS CONSOLE IS LOGGED! UNAUTHORIZED ACCESS FORBIDDEN!
<Meraki> '
Found an error, so aborting
Uploading image
Prompt is 'RNING! THIS CONSOLE IS LOGGED! UNAUTHORIZED ACCESS FORBIDDEN!
<Meraki> '
Found an error, so aborting
Uploading image
^CTraceback (most recent call last):
  File "./ubootwrite/ubootwrite.py", line 221, in <module>
    main()
  File "./ubootwrite/ubootwrite.py", line 216, in main
    upload(ser, options.write, int(options.size, 0), int(options.addr, 0), options.verbose, debug, options.shell)
  File "./ubootwrite/ubootwrite.py", line 170, in upload
    ret = memwrite(ser, path, size, start_addr, verbose, debug, shell)
  File "./ubootwrite/ubootwrite.py", line 93, in memwrite
    prompt = getprompt(ser, start_addr, verbose, shell)
  File "./ubootwrite/ubootwrite.py", line 36, in getprompt
    buf = ser.read(256);
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 483, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt

Thanks for all your hard work on this project. I have an MR33 with that has been in a box since 2020 and I cannot get this to work.

[Leo-PL]

You need to start this script right before powering the device on. And before that PLEASE check U-boot version to avoid killing your device permanently. I almost had an heart attack, when I managed to cause one of my MR33 to not respond while attempting to unbrick it after flashing a botched OpenWrt image. Also, what I've found out is, that pull-down on RX pin is really strong and my FT232R adapter could not drive it properly. even with high drive strength enabled. PL2303 worked instead.

[Cossey]

get your hands on TL866II+

Or just go with a Teensy++ 2.0 (10 bucks on AliExpress) and a 360-Clip (30 bucks on AliExpress) soldered to it as @chunkeey outlined above (BTW: Thanks @chunkeey!). That way I was easily able to make 5 devices work which previously were on too new U-Boot versions.

Hey, was this Teensy++ 2.0 modded for 3.3v? (It should have the voltage regulator at the bottom). I am looking at acquiring a 360 clip so i can get uboot installed for openwrt.

[ziswiler]

Hey, was this Teensy++ 2.0 modded for 3.3v?

No, I externally fed in the 3.3 volts back then but meanwhile acquired such LDOs which I could stuff one in an envelope for you if in need. And don't forget to cut that voltage rail's trace as outlined.

[Cossey]

Thank you @ziswiler, I may have to take you up on that offer since I have none and stock probably won't be available anytime soon. Reach out to me when you have a spare moment and let me know how much it'll cost (check my GH profile for my email). I am in New Zealand.

Also I am looking at this which I assume will mean I should follow this photo. Do I ignore the only connect when no voltage regulator is present on teensy message and connect the teensy 3.3 up to pins 12 and 37? I assume the instructions say not to due to them being written for use on the PS3?

Thanks in advance.

[rileyg98]

After much stuffing about with a TI866II Plus, a 360-clip, and a huge number of socket-socket jumpers on the NAND08 TSOP48 converter (and finding the wiring was not how i imagined, for those who stumble on this in future, outside on a NAND08 TSOP48 adapter are odd numbered pins. 1 is top left outer, 2 top left inner, 47 is top right outer and 48 is top right inner. Bottom right outer is 25. You count from there, basically.) i was able to get usbjtag's uboot to be loaded (as it's the only one that appears to have OOB data). I couldn't get my UART to successfully send xyzzy though, but this appears to be a fault in my FTDI232RL USB UART adapter. Ended up flashing usbjtag's ubi file, as I for some reason couldn't get the mtd and ubi emulation working in Linux, and managed to boot a (probably quite old) version of openwrt.

Edit: Don't do this. the UBI file may work but it's not your devices ART data. It was indeed my UART converter, I hooked a teensy up to UART and I can type.

Edit 2: Teensy 2.0 can't sustain the 115200 baud at 3.3v (that, or 16mhz isn't enough). I had a knockoff Uno that I flipped into reset to use its USB to UART bridge to upload the uboot.

[Cossey]

Edit 2: Teensy 2.0 can't sustain the 115200 baud at 3.3v (that, or 16mhz isn't enough). I had a knockoff Uno that I flipped into reset to use its USB to UART bridge to upload the uboot

Flashing via the 360-clip? Does this mean I need to feed in 3.3v externally for flashing uboot onto device via 3.3v teensy++ 2?

[ziswiler]

Flashing via the 360-clip? Does this mean I need to feed in 3.3v externally for flashing uboot onto device via 3.3v teensy++ 2?

At least that is also how I went about this, yes. Remember, there would be space on the Teensy to solder such regulator but I just fed it in externally.

[rileyg98]

Edit: Oops. I didn't use my Teensy 2.0 to flash via the 360-clip. I used a TI866II Pro to do that. I tried the Teensy to do the serial connection.

[Cossey]

At least that is also how I went about this, yes. Remember, there would be space on the Teensy to solder such regulator but I just fed it in externally.

Am I correct to assume then that the NAND is 5v tolerant for the voltage passing through the 360 clip @ziswiler, if I was to feed 3.3v externally but not have the regulator on the Teensy?

What did you use to feed it in externally? Ill be ordering in the 360 clip soon. At the moment I am using the access point in the Meraki grace period a few times until I flash.

On another note, has anyone looked into utilizing that other radio to do spectrum scanning and possibly even to also contain specific access points like Meraki does? Due to the density in my area I would love to "encourage" some neighboring access points to change channels.

[ziswiler]

Am I correct to assume then that the NAND is 5v tolerant for the voltage passing through the 360 clip @ziswiler, if I was to feed 3.3v externally but not have the regulator on the Teensy?

No, I don't think so. It really needs the Teensy modified for 3.3 volts! And, yes, one needs to set it explicitly to run at 8 MHz. If feeding in the 3.3 volts externally like I did one still needs to cut the trace as 5 volts may destroy the NAND part.

https://www.pjrc.com/teensy/3volt.html

I used the signal booster edition which, together with 8 MHz, worked flawless for me.

https://www.psdevwiki.com/ps3/Teensy%2B%2B_2.0#NANDway_Signal_Booster_Edition

What did you use to feed it in externally?

Lazy me I just used a piece of trusted hardware at work a Toradex Colibri Evaluation Board (;-p).

Ill be ordering in the 360 clip soon. At the moment I am using the access point in the Meraki grace period a few times until I flash.

Some folks discouraged connecting it to the Internet as it might update to even later potentially fused/locked version. Not sure.

On another note, has anyone looked into utilizing that other radio to do spectrum scanning and possibly even to also contain specific access points like Meraki does? Due to the density in my area I would love to "encourage" some neighboring access points to change channels.

Not really, no. So far I just kept that one turned off completely, sorry.

[rileyg98]

Some folks discouraged connecting it to the Internet as it might update to even later potentially fused/locked version. Not sure.

I don't believe the underlying hardware supports further fusing/locking in a manner to prevent our use of an old (but still, iirc, signed) u-boot on the NAND flash. I also believe these are definitely nearing an EOL and it's not likely worth Cisco's time to lock us out further.

No, I don't think so. It really needs the Teensy modified for 3.3 volts! And, yes, one needs to set it explicitly to run at 8 MHz. If feeding in the 3.3 volts externally like I did one still needs to cut the trace as 5 volts may destroy the NAND part.

Definitely. I cut my Teensy to do the 3.3v conversion. It's worth it. If you are in Australia or NZ, I can send you a voltage regulator (or you can find them quite cheaply on Aliexpress) as I bought 10.

I was kinda lazy myself as well and as I had the TI866II+ or whatever it is, I just used that and once I got the transposed pins on my adapter sorted it worked very well. I'd be willing to help out if any Aussies ware after a flash of their NAND chips using a 360-clip. I've got the partition files and stuff now for XGPro so it's no trouble.

[halmartin]

I don't believe the underlying hardware supports further fusing/locking in a manner to prevent our use of an old (but still, iirc, signed) u-boot on the NAND flash.

The SoC in the MR33 supports secure boot, but Cisco didn't ship them with anything burned into the QFPROM and thus far hasn't decided to field-update the units to enforce secure boot. If they did, the old SBL, QSEE and u-boot releases you have won't boot and the unit will be a brick.

[drws]

My MR33 was finally liberated with OpenWrt. Instead of tapping the numerous needed lines I've desoldered the flash chip and used a TL866II+ with a TSSOP adapter. The chip is not glued or anything as someone suggested, but GND lines work practically as a heatsink. Some time (preheating) is needed for the chip to come off, as has also already been mentioned.

After dumping the data I prepared a modified image with the old U-Boot with:

# dd if=S34ML01G2-original.bin bs=$((0x738000)) count=1 >  S34ML01G2-modified.bin
# dd if=ubootmr332012.bin      bs=660k          count=1 >> S34ML01G2-modified.bin
# dd if=S34ML01G2-original.bin bs=8245248       skip=1  >> S34ML01G2-modified.bin

The OpenWrt Wiki provides updated instructions for the MR33. A Python 3-compatible ubootwrite is now available and I can confirm that new(er) OpenWrt versions can be flashed directly without first flashing the v18.06.1. Also, OpenSSH 9.0's scp now uses SFTP by default so OpenWrt images need to be transferred with scp -O. And the Wiki links to another interesting MR33-flashing adventure.

[JasonN3]

@Leo-PL, were you ever able to trace out the debug lines? I don't have a clip to flash the NAND, but I do have some microcontrollers that I've been able to use as extremely cheap JTAG programmers, which is how I flashed an MR18 I have. I was hoping to do the same with the MR33 I have but I haven't been able to find the JTAG pinout.

[Leo-PL]

@JasonN3 what I mapped out so far is as follows:

Pin     Location        Function        Voltage
A17     J5-7            JTAG TCK        3.3
B17     J5-6            JTAG TDI        3.3
C17     J5-3            JTAG TMS        3.3
A18     J5-10           JTAG TDO        3.3
B18     J5-2            JTAG RST_N      3.3
C18     <unknown>       JTAG TRST_N     3.3
-       J5-5            GND             -

Still looking for USB pins. J5 is the Tag-Connect footprint, with ordering like this:

|---------------|
| O           O ----|
|    2 4 6 8 10 o   |
| o                 |
|    1 3 5 7 9  o   |
| O           O ----| J5
|---------------|
     ^

I'm not sure, though, if it is enabled by boot mode pins. Other pins on J5 look unused to my eye.

[Leo-PL]

After a whole night of poking the dead board from @0xFelix with multimeter, here's what I found:

J5 (JTAG Tag-Connect footprint)
Pin     Location        Function        Voltage
-       J5-1            JTAG VREF       3.3
B18     J5-2            JTAG RST_N      3.3
C17     J5-3            JTAG TMS        3.3
-       J5-5            GND             -
B17     J5-6            JTAG TDI        3.3
A17     J5-7            JTAG TCK        3.3
A18     J5-10           JTAG TDO        3.3
C18     <unknown>       JTAG TRST_N     3.3

J13 (Factory programming connector)
Pin     Location        Function                Voltage
-       J13-1           Board power             12
AD9     J13-2           U29 I2C0 SCL            3.3
AE8     J13-4           U29 I2C0 SDA            3.3
AB24    J13-6           GPIO36/BOOT_CONFIG[3]   3.3
AB25    J13-8           GPIO37/BOOT_CONFIG[4]   3.3
AA25    J13-10          GPIO40                  3.3
P25     J13-12          GPIO67                  3.3
-       J13-13          GND                     -
AG17    J13-14          USB2_DM                 -
-       J13-15          GND                     -
AF17    J13-16          USB2_DP                 -
Y26     J13-17          GPIO41                  3.3
W24     J13-18          GPIO46                  3.3
Y27     J13-19          GPIO45                  3.3
W25     J13-20          GPIO47                  3.3

U7 (NAND Flash)
Pin     Location        Function                Voltage
U25     U7-18           GPIO55/BOOT_CONFIG[9]   3.3 //4.7k pull-down to GND
N24     U7-16           GPIO62/BOOT_CONFIG[11]  3.3 //4.7k pull-up to Vdd

SW2 (Reset switch)
Pin     Location        Function        Voltage
A16     SW2-1           CHIP_PWD_L      3.3 //10k pull-up to Vdd

These are quite the good news. N24 pulled up to Vdd means that JTAG should be enabled permanently, though we need to know how to talk with the CPU DAP, to make use of it.

When the unit is bricked, it should enumerate in Qualcomm EDL "9008" mode, through USB2_{DP,DM} lines in J13. We still need a loader to access it, though. Then tools like https://github.com/bkerler/edl/ could be used to read/write the NAND without soldering. By pulling U25 pin high, which doubles as NAND_WE_N pin we can force a working unit to enter EDL mode as well - by shorting it to ground while booting. This obviously needs to be released afterwards, to access the NAND contents.

I'm puzzled, what is the function of J13 pins 17-20. Basing on IPQ4019 datasheet they look random, unlike other boot_config pins. Having no IPQ4029 datasheet, I assume the pinout and boot configuration are the same.

Could anyone dump the contents of EEPROM and NAND from MR74? It seems to have a way more relaxed boot chain w.r.t. secure boot support, as in - it doesn't seem to have the quirk causing MR33 units to brick themselves. CC'ing in @clayface.

@halmartin, BTW, do you have any board photos of Z3? I wonder if the same debug ports are available in it, as in MR33.

I think I'll try to somehow solder in the IPQ4029 back on the board, or try to put an IPQ4019 pulled from broken ZTE MF286D there, but no estimate on that so far, as I need to get a BGA stencil to reball the chip first.

@mveplus I recall you have a unit with socketed NAND, maybe you can try connecting the USB lines and check if the unit enumerates with NAND Flash removed?

[halmartin]

do you have any board photos of Z3? I wonder if the same debug ports are available in it, as in MR33.