But it needs to be the CPU reset pin, on the generic board reset which is just a GPIO.
If you cant find it then simply desolder the NOR
Ah, my Bad. Thought it would do to pull Reset of the Flash to GND.
Cpu Reset.. Trying to find it. Cant locate the spec sheet. Only found this (that repo has more interesting files). If correct, it should be A92, CHIP_PWD_L, "chip power on Reset" . Will See if I can get to it.
Update:
Phew 
- Found CHIP_PWD_L on the back of the PCB as a "through-hole" but apparently leading nowhere.
- Managed to solder a wire (rather a "hair" of a wire) to it (what a T I N Y little bugger...)
- Indeed plugging that to GND resets the chip - and helps to get the flash talking....
- Howerver, getting different dumps every single time
- Will improve the wiring next time I can free some time, it's all "fly wires" around 40cm plus jumpers from their 16pin plug to the header on the ch341a. Crappy, I know, but thought I'd give it a first shot... and missed
Here is the Pin A92 in the chip / top of PCB. Couldn't put two pics in one post as a new user.
Maybe it helps someone some day.
Why dont you simply desolder the NOR?
Its the classic 8 pin package, really easy to desolder with hot air
1 Like
It is 16 pin (but should be desoldered just as easy), and I first want to try the minimum invasive way. Also, there is some very tiny buggers next to it I don't want to come off.
Its not really invasive, if it does not have a huge thermal pad underneath then it will come really easy.
Its that or you find the CPU Reset pin
1 Like
I found the CPU Reset Pin, see post 22 above. It is A92, marked green in the pics above. I tested it successfully :
- connected TTL from the router (next to the flash) to ch341a (in UART/TTL mode, jumper on 2-3) and watched the console in "cuteterm". It boots to the error 3039. Once I then touch GND with the wire I soldered to A92, it repeats that boot.
- When permanently on GND (I'm plugging the A92-wire into the GND hole of the non-connected 2nd TTL row above the flash), CPU stays "down" and the ch341a (in programmer mode, jumper on 1-2) is recognized even with the router board attached (whereas with A92 not on GND it fails/"drops out" once 3.3v are connected to the router board).
SO, with A92 I think that part is sorted.
As said, problem now is that I get different dumps at every readout attempt. Would think that either
- router board still draws power or causes signal distortion (drains?)
- wires from clip to ch341a cause distortions (common problem with long / poor / unshielded wires I read)
- Flash is bad
- Mix of 1/2/3
- Will try sorting 2 out. Want to check as far as possible if "Onboard" is doable, in case others come to this point ever.
- If new wiring doesn't help will go for the desoldering.
Will report...
What software are you using with CH341A?
You should not get different dumps if NOR is properly identified,
I personally use flashrom as its rock stable, support CH341A and tons of flash IC-s
Flashrom, on Ubuntu. Detects the rom correctly, both with -c and without -c parameter. Seven dumps worked without problem, each taking about 5min to complete. First 3 or 4 were done with the router connected, the unplugged the ch341a once and plugged it in again for the other 3 or 4.
No error messages... only the md5 of each dump differs.
Have not yet done dumps with -V(V(V)) though.
Hm, that is really weird.
I have not had the issue with differing dumps in Flashrom, its gotta be some interference then.
Skipped the wire stuff, desoldered the flash. Now on an adaptor board directly in the ZIF on the ch341a.
- Still getting different dumps every time (about 15-25 bytes different between the 4 dumps I compared, all up to an offset of 00098xxx - can't remember the exact max offset right now...that is to say: things beyond that address seem to match, whatever is in there... )
- Tried flashrom with Ubuntu and fedora on two identical laptops, and on one of them also with asprogrammer on W10.
- very bad... flash f*cked?
- will try to hook the flash directly to the SPI interface on my cubietruck next. Found some posts saying their ch341a was crap and using a raspi as the SPI Master worked like a charm for them on the same flash module. Maybe my ch341a is crap...
Off to bed ¦-0
Keeping the complete history of this thread in mind (particularly that it died while recovering, with SBL1 being defective) - and assuming that you're now confident about the connections to the flash, I'd venture that your flash (hardware) is indeed shot. If you can recover (at least) the calibration data (ideally also the pins, passwords, etc. of the OEM firmware), replacing it shouldn't be too much of a problem.
1 Like
Any hint at what offset those "box specific factory defaults" (serial, passwords, ssid) can be found? And where the calibration data lives? I've spotted some strings "readable" (like path names, texts of messages) when scrolling through a dump. But guess the stuff we are after is more like "arbitrary letters and numbers" not straight forward "eye catching".
Finally found time to hook the flash to spi2 / spidev on my cubietruck...hoped to find that ch341a was flawed and cubie would do better... unfortunately not, getting different dumps each time, even with lowest clock speeds of 5MHz only.
So, now using hexdump to then look at the files and compare them somehow. @slh do you have any hints for me how to identify the radio calibration data?
And then I need to find out how to get a new, clean rom file out of a AVM firmware... and back in...
Would then give writing to that flash a try.
And get me a new flash off e.ay...or any other sources (or hints for compatible replacements?)
I haven't played with AVM devices in a long time…
Should be your first reference, if you have a working 4040 (which I think you mentioned, otherwise you'll have to ask another 4040 user), you can start with that partition map.
If I understand it correctly, the first 6 partitions (SBL1, MIBIB, QSEE, CDT, DDRPARAMS, APPSBLENV, urlader), so the first 1'170'432 bytes should be identical on all devices and can be recovered from any working 4040 running OpenWrt.
The crucial partitions you really want to recover from the affected 4040, are urlader_config (this contains ART), tffs1, tffs2 (not quite sure about the last partition, called jffs2 - I'd recover it, if possible).
uboot/ firmware shouldn't matter, this you can recovery from AVM- or OpenWrt firmwares.
I'd use a dump of a working 4040, and then only replace the unique partitions (urlader_config, tffs1, tffs2) first before flashing.
some progress...
Repeated the soldering job to get a "reset wire" onto the "good" 4040 I have (did I mention that is a HELL of a tiny little pad to solder to? - I wonder if in that multi-layer-board that isn't leading to any of the test pads...really it should).
After some detours managed to dump its flash without de-soldering. Three dumps in a row, all with same checksum - good! The trick was: Use a cubietruck, hook the SPI clamp to the ch341a, but not the 3.3V. Hook that to the 3.3V pins on one of cubietrucks pin rows. This allows ch341a to stay "online" as a USB device, with the cubietruck mainboard powering the fritzbox (in reset mode, of course). Do all this with the cubietruck shut down. Once the wires are in place, power the cubietruck up. It appeared to me that I needed to let the setup settle for a minute or two, as if some caps on the fritzbox need charging before it becomes stable even in reset mode. Then, flashrom did it's job. (Might work with a raspi, too; Edit: and should of course also work with SPI/spidev of the raspi/cubietruck also, i.e. without the ch341a - but wanted to try this "mixed" approach, also because I still had / have the "bad" flash module hooked up on spi2 of cubie, so got both connected simultaneously )
Okay, so I have the roms, and from the ttl console boot log of the good box I know where the partitions would be
[22:37:59:265] [ 1.209239] Creating 5 MTD partitions on "spi0.0":
[22:37:59:265] [ 1.214669] 0x000000000000-0x000000120000 : "urlader"
[22:37:59:265] [ 1.220977] 0x000000120000-0x0000001a0000 : "tffs (1)"
[22:37:59:288] [ 1.225993] 0x0000001a0000-0x000000220000 : "tffs (2)"
[22:37:59:288] [ 1.230967] 0x000000220000-0x000002000000 : "rootfs_kernel_spi"
[22:37:59:288] [ 1.236150] 0x000001f00000-0x000002000000 : "jffs2"
There is only "urlader", but no "urlader_config". Is the latter specific to a box which is already running openWRT?
Next, used some "dd" magic to cut those partitions from the "bad" dump, and from the "good" one.
The other bad news is: using binwalk on the bad tffs1 / 2 files, I get "nothing", whereas for the same files from the "good" box I get lots of "Zlib compressed Data" findings. It seems as if in the bad flash some sections got written first and others later, and in the good flash these sections are the other way round. Hard to explain without hex-dumping it all here. I could get that into order as it seems. What is in those sections is definitely serial numbers, default passwords, MAC addresses etc., pretty obvious. So "copying" those from bad to good would be easy.
But what about that ART data - I can't make sense of those offsets yet, sorry, Looked at the sources of fritz_cal_extract to understand the parameters. Could steal them from the link you provided - but what would be my "infile" that I should feed to it if I have no "urlader_config" partition?
Well, maybe sleep will shade some light 
1 Like
Some more progress.
Assuming (yes, I know... makes an A of u and me) that the openwrt dts partition "urlader_config" merely "graps" a section out of flash which is what we are after, I cut that segment from my good and bad dumps like so:
dd if=bad01.dmp of=url_cfg-bad.bin bs=1 count=$((0x00002400)) skip=$((0x0011dc00)) status=progress
Next, I guessed fritz_cal_extract should be happy reading this chunk maybe. So, got me the fritz_tools (well, just cloned the openwrt repo) and built them.
Now, feeding the dumps from above into fritz_cal_extract like so:
./fritz_cal_extract -i 1 -s 0x400 -e 0x207 -l 12064 -o ../bad/fri-cal-ex-bad.out ../bad/url_cfg-bad.bin
Then, looking at the output files with "strings" gives very similar results starting with FB4040_2G_CAL0_V2 ... which sounds like something, does it?
$ strings ../bad/fri-cal-ex-bad.out
FB4040_2G_CAL0_V2
riQI6
siRI5
sZII8
wZLI;
yhZK8(
ypZR80
yyyy
and after that they are quite similar, some section differ in several characters... but it's all non-human-readable stuff (to me at least), so I can't say what these bytes actually say. Need to push them through some other tool?
I've hex-dumped those files; hexdump bad/fri-cal-ex-bad.out > bad/fri-cal-ex-bad.hex -C
Here's the diff of the two. Only a few sections with a few chars/bytes different each. The "rambo approach" would be to stich together stuff from good and bad "as is" - but I'd like to understand whether the diffs are "flash fault" results, or actual config values encoded somehow.
$ diff bad/fri-cal-ex-bad.hex good/fri-cal-ex-good.hex
1c1
< 00000000 20 2f a0 1c 01 01 7c ff 4d e6 ee 45 00 00 00 00 | /....|.M..E....|
---
> 00000000 20 2f bc 47 01 01 7c ff 4d 13 75 36 00 00 00 00 | /.G..|.M.u6....|
42,43c42,43
< 00000300 00 00 00 00 c6 ab ad 96 9b 82 82 61 71 4e de ad |...........aqN..|
< 00000310 be 92 a5 78 93 66 79 4a be aa 9b 87 8a 72 69 51 |...x.fyJ.....riQ|
---
> 00000300 00 00 00 00 d6 ac b5 92 a5 80 8a 62 79 4d de a9 |...........byM..|
> 00000310 c6 95 ad 7c 93 62 79 48 be aa 9b 87 8a 72 69 51 |...|.byH.....riQ|
45,46c45,46
< 00000330 b7 aa 29 27 00 c6 a8 ad 93 9b 7d 8a 68 71 4b d6 |..)'......}.hqK.|
< 00000340 a8 be 95 a5 7a 93 68 79 4b be a9 9b 87 8a 73 5a |....z.hyK.....sZ|
---
> 00000330 aa b1 29 27 00 d6 a9 b5 90 a5 7d 93 68 79 4a de |..)'......}.hyJ.|
> 00000340 ac be 92 ad 80 93 65 79 4a be a9 9b 87 8a 73 5a |......eyJ.....sZ|
48,49c48,49
< 00000360 f8 b6 aa 27 2a 00 ce ad ad 93 9b 7f 8a 6a 71 4d |...'*........jqM|
< 00000370 d6 a9 be 96 a5 7c 8a 61 79 4f be a6 9b 8a 79 68 |.....|.ayO....yh|
---
> 00000360 f8 aa b1 27 2a 00 de a9 be 94 a5 7b 93 67 79 49 |...'*......{.gyI|
> 00000370 de a8 c6 96 ad 7e 93 64 79 49 be a6 9b 8a 79 68 |.....~.dyI....yh|
51c51
< 00000390 f8 f8 b6 aa 27 27 00 00 00 00 00 00 00 00 00 00 |....''..........|
---
> 00000390 f8 f8 aa b1 27 27 00 00 00 00 00 00 00 00 00 00 |....''..........|
88,91c88,91
< 000006a0 00 00 c7 a6 69 82 42 6c 22 56 12 47 c2 a1 6f 81 |....i.Bl"V.G..o.|
< 000006b0 4f 70 19 4a 0b 3b bd aa 71 99 46 87 28 72 18 60 |Op.J.;..q.F.(r.`|
< 000006c0 99 ab 5b 99 39 87 20 73 13 61 c7 a3 66 7d 3f 68 |..[.9. s.a..f}?h|
< 000006d0 20 53 10 43 a3 95 76 83 32 5e 1a 4b 0b 3c c6 a9 | S.C..v.2^.K.<..|
---
> 000006a0 00 00 b5 9b 5b 77 36 62 1a 4d 0b 3e b7 9d 67 7c |....[w6b.M.>..g||
> 000006b0 4a 6c 16 48 07 38 bd aa 71 99 46 87 28 72 18 60 |Jl.H.8..q.F.(r.`|
> 000006c0 99 ab 5b 99 39 87 20 73 13 61 b3 98 58 73 32 5e |..[.9. s.a..Xs2^|
> 000006d0 17 4a 09 3b c3 a0 70 80 4f 6f 17 4a 08 3a c6 a9 |.J.;..p.Oo.J.:..|
93,94c93,94
< 000006f0 1c 66 c4 a2 69 7f 42 6a 23 55 13 46 a5 96 7a 85 |.f..i.Bj#U.F..z.|
< 00000700 36 61 1d 4f 0d 40 a7 a6 69 98 48 8a 2b 77 1b 68 |6a.O.@..i.H.+w.h|
---
> 000006f0 1c 66 b1 94 5a 72 35 5d 19 49 0a 3a c2 9d 71 7e |.f..Zr5].I.:..q~|
> 00000700 31 5b 19 49 0a 3a a7 a6 69 98 48 8a 2b 77 1b 68 |1[.I.:..i.H.+w.h|
345,346c345,346
< 00002780 a2 a1 a1 a1 64 64 00 00 00 00 00 00 bc bd b8 b8 |....dd..........|
< 00002790 9c 9d 97 97 a1 a2 a1 a1 64 64 00 00 00 00 00 00 |........dd......|
---
> 00002780 a1 a1 a1 a1 64 64 00 00 00 00 00 00 bd bd b8 b8 |....dd..........|
> 00002790 9d 9c 97 97 a2 a1 a1 a1 64 64 00 00 00 00 00 00 |........dd......|
446,448c446,448
< 00002e60 22 22 28 28 1c 1c 28 36 2e 3c 22 30 fe 00 08 00 |""((..(6.<"0....|
< 00002e70 fa 00 06 00 00 00 00 00 00 00 00 00 03 00 00 00 |................|
< 00002e80 3c 57 06 01 00 00 00 00 00 00 00 00 00 00 00 00 |<W..............|
---
> 00002e60 22 22 28 28 1c 1c 28 36 2e 3c 22 30 ee 00 08 00 |""((..(6.<"0....|
> 00002e70 f6 00 03 00 00 00 00 00 00 00 00 00 03 00 00 00 |................|
> 00002e80 2d 7d 06 01 00 00 00 00 00 00 00 00 00 00 00 00 |-}..............|
Using fritz_tffs_read like so
./fritz_tffs_read -i ../bad/tffs2-bad.bin -a -b
i can read all MAC, Serial, default passwords etc from all tffs1 and tffs2 values for the good and bad units. The "Bad" contains a line
crash=[0]1eb9ee17,5c023d4f,1[1]0,0,0[2]0,0,0[3]0,0,0
in those files, and no "language" line (obvious - it was never set up, so no language value has been selected and hence not stored)
So, "Rambo Time", stitch it together?
@slh, would appreciate if you had another hint for me what to make of the "config data", and whether it's what I'm after (and maybe how to read it properly?)... Couldn't find any examples where it was "decoded".
Edit: Looking through my "good" ttl console boot log again... there are occurrences of
FB4040_2G_CAL0_V2
and
FB4040_5G_CAL1_V5
but the latter does not appear in the "strings" output for the "fritz_cal_extract" output files.
So, is there another section to be extracted from the roms containing data for the 5GHZ (5G) Modules?
I don't see why you'd need to solder on the good 4040, after all you could just extract the mtds from a running system (at least on OpenWrt, no idea about Fritz!OS). In my last posts I summarized the partitions that should be common to all 4040s - and those that should be unique to each device. If possible (as in not corrupted on your broken device), I'd restore the unique partitions as-is into a working dump.
Disclaimer: I really don't have any experience with the 4040 or similar AVM devices, so this advice will have to remain rather generic.
hi slh,
thanks for your reply. I soldered because I wanted to get a full, genuine dump. I wasn't aware of any way to get that out of a running fritzbox running fritzos. Probably so easy...Maybe possible when on the ttl console... but really, all this is not my home ground. Knowing how to get to the flash from the "bad" one, I thought I can repeat that at least maybe - and I could.
Okay, Rambo Time. I'm stitching together
- bootloader part 1 from "good",
- then the (assumed) config section out of boot loader from "bad"
- then the rest of the boot loader from "good";
- and then tffs1 and tffs2 from the "bad" which seem to read out fine;
- then rootfs from the good again.
We'll see. Can't get much more than not being able to write to the flash in the first place, and a non-booting box second; and maybe non-working WLAN. Not much to loose anyhow
And I have a nice "good" one with a "reset for flashing" wire - if anyone needs one?