FritzBox 4040 - bricked? "Boot error ocuured!." Any chances left?

Hardware Questions and Recommendations
1

Hi there,

apologies for double-posting, but this is my last hope, so wanted to make sure it's not burried and overlooked.

Posted this in a rather old thread the other day because there member "shaotangyu" in post 96 had the same very rare error message

"Boot error ocuured!. Error Code: 3039"

Note the typo in "ocuured" which is absolutely unique - g**gle finds 5 hits in total if forced to search for the exact match of "Boot error ocuured!." instead of the correction it suggests. Unfortunately shaotangyu didn't find a fix he replied.

The 2nd g**gle hit leads to a 2nd thread on here (with a different 4-digit error code) - but what the guys discuss there is beyond my options (I think - got only half of what they do).

Been using openWRT on my good old Linksys for ages (man, getting old!)

Now I have fried my FritzBox 4040 using the "recovery" tool provided by AVM. Seemed to update well, reported success, then lights went dark on the box, end of story.

Been through a lot before I came here now. Unit still creates various LED signals when LAN cables get connected to the individual ports. But there's no way to detect it any longer in the early boot phase.

I've then connected its TTL connector to the one of my CubieTruck and managed to get some (though apparently not all) boot console output - but that ends in above error message.
Any chances?
Fingers crossed, any and all hints greatly appreciated!

Here's what I get on the TTL:

Format: Log Type - Time(microsec) - Message - Optional Info
[... ***here a lot seems to be missing*** ...]
D -         6 - pm_device_init, Delta
B -    775403 - boot_flash_init, Start
D -     54255 - boot_flash_init, Delta
B -    833831 - boot_config_data_table_init, Start
D -      3815 - boot_config_data_table_init, Delta - (419 Bytes)
B -    841039 - clock_init, Start
D -      7583 - clock_init, Delta
B -    853147 - CDT version:2,Platform ID:8,Major ID:1,Minor ID:0,Subtype:0
B -    856643 - sbl1_ddr_set_params, Start
B -    861637 - cpr_init, Start
D -         2 - cpr_init, Delta
B -    866026 - Pre_DDR_clock_init, Start
D -         4 - Pre_DDR_clock_init, Delta
D -     13162 - sbl1_ddr_set_params, Delta
B -    879866 - pm_driver_init, Start
D -         2 - pm_driver_init, Delta
B -    950219 - sbl1_wait_for_ddr_training, Start
D -        29 - sbl1_wait_for_ddr_training, Delta
B -    966004 - Image Load, Start
B -    967232 - Boot error ocuured!. Error code: 3039

And that's the final line.

***: see shaotangyu's post linked above, at the end of his code snippet: he's got around 15 or so more lines at the start of that "final section" he recorded - can try by other means to get those lines from my box if it would help?

Anyone?
Cheers.

2

Disclaimer: I have no experience with the Fritz!Box 4040, nor any other AVM devices running OpenWrt.

Extrapolating from a different ipq40xx device, it looks a lot like your boot failure happens way before u-boot (which does provide you with some recovery mechanisms) gets loaded. If that's indeed the case, and assuming that EVA and ADAM2 don't provide some fallback recovery mechanisms beyond that (I'd keep trying with AVM's recovery tool, keeping an eye on the serial console for some hints), it would really not look very good… (NAND is difficult to recover).

3

Thanks for your response slh.

You are correct, this is way before EVA kicks in. A "normal" TTL Output can be found here (under the Wrt Header, but up to EVA it does not make any difference whether it is the AVM Original FW or wrt).

I can give it more tries with the recovery tool, sure, but as the initial boot loader obviously fails to get to EVA, I think there is no point. My understanding is that any recovery or other flash tool works only via that EVA ftp transfer mode, and not before.

Little hope . . . unless there is a way to re-flash anything needed to pump EVA back into the box.

4

What you are seing is output of the SBL1, code 3039 means it cant load the high level bootloader.
So your bootloader is corrupted or missing.

As far as recovery goes, SBL does not offer any, its up to you to reflash the storage medium with a working full backup or just the bootloader.

5

Reflash the storage... certainly requires special equipment not "at hand" and way more expensive than a new box, right?

6

If router has a SPI-NOR then its cheap, but if its NAND then its expensive

7

If what I got as a response in a German forum is correct:

FB4040 = IPQ4018 = 32MiB NOR-Flash
I can confirm that there is the 4018 in the unit.
And if I read the spec sheet right it is SPI.
(Only IPQ4019 supports NAND)

8

If its 32MiB of NOR like OpenWrt wiki says, they you can use the cheap CH341A programmers with flashrom to reflash just the bootloader

9

Wiki seems right, there is a Macronix MX25L25635F(MI-10G) flash chip in 16-pin format on the board.
To use that Ch341a I'd have to de-solder that one I guess.
Not my regular business...I'd probably do another (read: the final) nail to the coffin trying to.

10

If you dont have a 16pin clamp then yes

11

Just a very strong recommendation, before flashing anything, make sure to have a full backup - in particular the radio calibration data (ART) is unique to your device and irreplaceable.

12

How would I get that backup with the unit doing "nothing"? Dump the damaged flash? Sounds as if in the end I'll be in deep trouble hacking together bits and bytes. I think I'll call it "dead".

13

If you go the external flashing route (which is reasonable with SPI-NOR flash), you can dump the existing flash with your ch341a flasher, before writing a new image. Then you'll need to insert the critical parts (at least ART, maybe MAC addresses, WPS pins, etc.) of your (hopefully just partially-) broken flash into the image you're going to write into the chip.

If you can't recover the radio calibration data, you WLAN will remain broken.

--
Obviously this is only economically viable, if you 'just' need to buy the SOIC clamp and ch341a flasher (and can wait for the slow route shipping from China) - and have at least some basic soldering experience and equipment. If you have to buy all the small things, you quickly exceed the price of a working (at least used) device.

1 Like
14

So...got the gear together more or less. Why not throw a little more time + money at the toy and learn along the way.

There's a good guide here on how to generally do it, using a similar MX25L chip with smaller mem capacity, but also "L" which means that guy also had a 3.3V flash chip.

  • CH341a, which I yet have to modify from 5V to 3.3V; note that "C4 / 472" on the PCB schematic in that post really is labelled C3 on the PCB, see replies #21 + #22 over there - confirmed!
  • 16pin clamp and 16-pin adaptor to connect it to the ZIF socket - but I have to adjust the cabling to the pin layout I believe.

So, three things I have yet to get in line:

  1. How to align the clamp cabling to the ZIF socket pin layout. Looking at the MX25L datasheet and the CH341a information I believe correct, this is work in progress.

  2. Voltage: Can I really use the CH341a with the MX25L chip (after modding it for 3.3V)? What puzzles me is that in the discussions about the CH341a people have measured that (even though it provides 3.3Vcc to the ZIF even without the mod) it fires ~4.7V at the signal pins without the above 5->3.3V mod, and around 3 with the mod. On the other hand, the MX25L datasheet says the max voltages are -0.5 to +0.5V (OH point 5, not 5 point OH!) and at signal transitions it may overshoot to +-2.0V for 20ms or so (Section 12, p.90). So, if even after the mod the CH341a signal levels are up to 3.3V, that shouldn't work and should fry my flash mem, right? No? Confused!

  3. Should I get through 1+2, and get the mem dumped, how will I identify the "ART data"? @slh, do you have a link for me describing what I will see in that flash dump and how to sort it out? I'd have another known-good 4040 unit at hand, but it wouldn't be my first choice to risk that one trying to dump it's mem, too.

Much appreciate further hints!

15

First dump the whole flash of the broken device (twice, to check for transmission errors). The offsets for ART are in the DTS (sorry, I'm on a mobile device right now and can't provide a link) and/ or displayed in dmesg while booting the working unit (no need to open it).

16

pin assignment figured... get set...ready....go...FAIL.
Damn motherboard of the router pulls I don't know how much power through VCC. Makes little ch341a "die" in the USB port it is in. I can see it disappear in journalctl on the host the moment I connect VCC to the router motherboard. It comes back as if it were freshly plugged in the moment I disconnect VCC from the router.
The router comes with a 1.4A/12V PSU. So I guess it tries pulling over VCC from the ch341a >800mA (which is the max that the 5>3.3V regulator "AMS 1117 3.3 xjs68" on the ch341a can do). Or more than my laptop wants to put out through its USB port.

Stuck? I don't want to lift the pin2 of the flash chip from the mobo of the router.
Ideas to get more amps to the router via VCC?

  • use a powered USB hub in front of the CH341a?
  • power the router's "VCC" from another 3.3V source (and then of course DO NOT connect VCC coming from the ch341a)
  • can I "back-power" the router through its USB ports? should prevent it from booting, but might bring 3.3V "backwards" to anything that draws power? and of course, DO NOT connect VCC to ch341a then.
  • read about using the "wake on lan" feature somewhere, but that was in connection with some thinkpads I think. Not sure if the fritzbox would be okay with such an approach (on which I'd have to find details yet).

TBC. I'll call it a day.
But: "I'll be back" :mechanical_arm: :fist_right: :gun: :robot:

17

You need to desolder it and program it removed from the board, otherwise you need to pull the CPU reset to low

18

Pulling "cpu Reset" to "low" (i.e. GND, right?) would not prevent the VCC power flow, right? Pulling it to low is just another Jumper wire, would be nice if it were that easy.

1 Like
19

Yeah, to GND.
It would indeed prevent high current draw, as the SoC would pernamently be in reset state and therefore draw almost no current.

20

Does not work. Same situation even with Reset on gnd.