Checked dumps, it is identical despite -n flag
Flashed, but nothing changed ((
Last idea is add '--bb=dumpbad' parameter for dump bad blocks, otherwise I'm out of ideas.
Alright, the NAND wiki example shows "correctED bitflips" in the command line output but "not correctABLE bitflips" turned up when I nanddumped without -n flag on my EA7500. Does this matter?
I think it is because NAND in good condition and doesn't contain any bitflips at all.
Also there is a /dev/mtdxro for each /dev/mtdx, should we try those ro(read only) dumps?
Edit: never mind, dumping /dev/mtdxro will give an error nanddump: error!: mtd_get_dev_info failed
Checked md5sum, all partitions identical to previous one.
Seems to be now I have exactly copy of flash from your router, but it not booted.
Need some check, may be I've damaged some parts on PCB while soldering, otherwise I don't know what is it.
Yep, I've already pretty sure that it not worth this effort, but it is curiosity 
I've hooked up logic analyzer to NAND, and now able to see on what stage boot sequence fails.
Presumably SBL1 has some sign and checked by SoC during boot. SBL1 from another router with similar model doesn't work.
At start SoC reads 523 bytes from page 0.
First bytes contains sequence which equal across different routers, even 8500
D1 DC 4B 84 34 10 D7 73 5A 43 0B 7D
End (0x200 - 0x20B) contains in my case
FF 7A 87 08 27 57 A8 B0 54 12 73 FF
but in dump from @abij it is
7A 87 08 27 FF FF FF FF FF FF FF FF
My router with another dump stop booting right after read first 523 bytes, but with original dump it continues.
Next it reads first 523 bytes from pages 1, 2 and 3.
Then it reads 523 bytes from page 5 (which contains really code), and seems to be verified it as well.
After that it reads page 5 again, but at this time entirely 2048+64 bytes.
And as I lost my spare bytes it reads 0xFF for all 64 bytes, and stop booting. Presumably because wrong ECC.
I've tried to combine first 4 pages from my dump and other pages from another, but it seems to be checking sign on step when read 523 bytes from page 5.
So my router fully dead, maybe until I figure out how to calculate ECC data which I lost for my stupidity 
But I assume there is a good news for @abij
I've compared my original u-boot dump with dump from your 7500 and it is identical, perhaps u-boot is not signed and can be reprogrammed.
But full clone of NAND from another router maybe not work like as in my case.
better you find uboot sourcecode, and generate your personal version.
For me main problem in SBL1 at least.
Suppose uboot is not signed, then I need to know how much other partitions have been damaged in order to restore the router, methodwise and datawise. At the moment I don't know what kind of tools I need in order to inspect the actual data loss on the NAND chip. I remember maybe 10mb or 20mb have been written with the empty $loadaddr env. If 20mb was the case, then maybe the original data on the chip is completely gone.
Hmm, I just realized, if your u-boot really overwrote something at address 0x0, then it completely destroyed SBL1, which is a important for boot sequence and as I found is perhaps unique for particular router.
Interesting update, I was wrong bout unique SBL1 per router.
Recently I've got dump from another user and it is almost identical with those dumped by @abij earlier.
Seems to be SBL1/2/3 shared with multiple routers in same production batch / hw revision.
So, theoretically there is router which can help me ))
My ea7500v1 is imported from US and has s/n 18L10C6C518659, MAC C0562735607E.
If anyone has another one with closest values, feel free to write me
PS: I've spot presumably the main difference, in devinfo partiotion my has modelNumber=EA7500, but two others modelNumber=EA7500-HK and modelNumber=EA7500-UK.
Perhaps US model has a different set of bootloaders.
HI, you want to find someone has EA7500v1 and halp you, but this Topic shows EA8500 in title.
Seems to be I steal this topic from @abij
But he needs dump for his router as well.
I don't think 7500 owners with working routers would open this topic anyway.
I've found on this forum some other members with 7500 and PM it in case they can help.
Hi, couple days ago I finally can recover my EA7500v1.
Thanks for guy who developed https://pypi.org/project/qcom-nandc-pagify/ and described how SBL partitions works.
What I have done.
Need direct connection to NAND flash. On EA7500v1/EA8500 it is possible by using testpoints on PCB, which is even labeled by manufacturer.
I've superglued pinheaders onto PCB, and after that soldering wires between them and testpoints.
On this picture I've labeled which is which.
If you have programmer capable to flash 8bit parallel NAND flash, it is easy.
I've try to do it on cheap and used for this purpose raspberry pi b+ which just laying around.
I found project which is implemented bitbang nand flasher. I forked and adapted for my particular Spansion S34MS01G2 nand flash.
Connections described in source file. GPIO layout can be found there https://pinout.xyz/
BUSY GPIO3
ALE GPIO4
CLE GPIO5
RE GPIO6
CS GND
WE GPIO7
IO0:IO7 GPIO8:GPIO15
And of course ground from RPI needs to be connected to router's GND. In my case it can be accessed on UART pinheaders.
About power supply, NAND should be supplied by 1.8V, but RPI is a 3.3V.
From electrical point of view it is wrong, but in my case I didn't connect any power to router at all, I discovered that NAND seems to be powered through pull-up resistors from RPI, and 1.8 rail on router was about 1.9v, seems reasonable.
Reading and writing operation was remarkably well, and I decided to leave it without additional supply.
After wiring you can check connection by running
./rpi-raw-nand-v3 150 read_id
Program reads ID from flash and should recognize it as S34MS01G2
If all works fine you should dump existing content of flash, just in case.
./rpi-raw-nand-v3 150 read_full 0 7936 backup.bin
This dumps from mtd0 up to mtd12
You should always use read_full instead read_data, at least for qualcomm propietary partitions, as OOB contains actual data.
Recovering process is a bit messy, as you need dumps from someone who can dump mtd0-mtd12 from working router, but qualcomm nand driver in 5.4 kernel has a bug. Driver removes ECC from dump, but not all, leaves some chunks of it. I've wrote script for recovering actual data and stripping all unnecessary parts.
On the other hand nand driver in 5.10 kernel can correctly dump from mtd0 to mtd8, but corrupts mtd9 (u-boot). So in my case preferred method was get full dumps from 5.4 kernel router.
On working router you need to install nand-utils package and run commands
nanddump -f /tmp/dumpmtd0.bin -o -n /dev/mtd0
nanddump -f /tmp/dumpmtd1.bin -o -n /dev/mtd1
nanddump -f /tmp/dumpmtd2.bin -o -n /dev/mtd2
nanddump -f /tmp/dumpmtd3.bin -o -n /dev/mtd3
... and so on
Then feed this dumps into strip_ecc.py script and you've got clean data.
After that we need to prepare raw data for flasher by adding ECC and other Qualcomm specific things.
qcom-nandc-pagify --infile mtd0_strip.bin --outfile mtd0_ecc.bin --ecc rs_sbl
qcom-nandc-pagify --infile mtd1_strip.bin --outfile mtd1_ecc.bin --ecc rs_sbl
qcom-nandc-pagify --infile mtd2_strip.bin --outfile mtd2_ecc.bin --ecc rs_sbl
... and so on
Flashing new data.
You should always try to save your mtd8 (ART) partition as it contains unique calibration data for this particular device.
As wel as mtd12 which contains serial number and other no so important stuff.
Before you can write into NAND it needs to be erased. Erasing performed by big blocks, in this case by 64 pages. Each page is a 2048 byte.
For example if you need restore SBL1, you need to erase pages from 0 to 127. Is is first two blocks.
./rpi-raw-nand-v3 150 erase_blocks 0 2
Then you can write new data onto it
./rpi-raw-nand-v3 150 write_full 0 128 mtd0_ecc.bin
Partitions table from EA7500v1
No Name Start Start page Start block Size Size pages Size blocks ECC
0 SBL1 0 0 0 0x40000 128 2 RS_SBL
1 MIBIB 0x40000 128 2 0x140000 640 10 RS_SBL
2 SBL2 0x180000 768 12 0x140000 640 10 RS_SBL
3 SBL3 0x2c0000 1408 22 0x280000 1280 20 RS_SBL
4 DDRCONFIG 0x540000 2688 42 0x120000 576 9 RS_SBL
5 SSD 0x660000 3264 51 0x120000 576 9 RS_SBL
6 TZ 0x780000 3840 60 0x280000 1280 20 RS_SBL
7 RPM 0xa00000 5120 80 0x280000 1280 20 RS_SBL
8 ART 0xc80000 6400 100 0x140000 640 10 RS
9 APPSBL 0xdc0000 7040 110 0x100000 512 8 RS_SBL
10 u_env 0xec0000 7552 118 0x40000 128 2 RS
11 s_env 0xf00000 7680 120 0x40000 128 2 RS
12 devinfo 0xf40000 7808 122 0x40000 128 2 RS
In this table I place page and blocks numbers, for writing and erasing.
Don't substitute page numbers in erase_blocks command!
In ECC column shown which format was used in partition. Description and differences between them, you can find in qcom-nandc-pagify docs.
For successfully boot in U-Boot you need all chain from SBL1 up to RPM plus APPSBL.
Recovering process can be observed by hooking logic analyzer/oscilloscope up to one of the nand's data pin.
This is a chart I've captured on my router and marked what partitions loading. If boot process fails after some stage, you can figure which is caused.
In my repo https://github.com/iglooom/rpi-tsop48-nand/tree/master/qca-sbl-dumps/raw-nand-dumps you can find raw NAND dumps which I've dumped from working router after recovery. You can simply flash it by external flasher.
I can't check is this dumps can work on 8500, but as I upgraded RAM on my 7500 I've flash mtd4 exactly from 8500 dump and it recognized 512M. So, it seems to be should work on real 8500 too.
And after all of that I've performed some tests, and it seems to be impossible to correctly flash this partitions from OpenWRT, it always corrupted by driver in some way.
Read-only flag on those not a coincidence, don't try this at home
3 Likes
Initially I thought it can be posted on wiki, but not sure now, as it is not a complete guide to unbricking, and it rather difficult too.
@abij if you eventually can repeat this, maybe you can write instruction more user-friendly, and more english-speaking
And yep, I was wrong about SBL signing, it is not a secureboot. It just kinda bug in kernel which can't write and read correctly and produces difference between routers.
1 Like
I can help posting that to the wiki, as a regular maintainer for the EA7500 + EA9500 + EA8300 wikis. 
Do you agree with?
1 Like
Yes, sure, thank you!
1 Like
And I finally figure out how we can obtain correct dumps from working router on ipq806x without soldering or doing some hacks.
I've discovered for myself command 'ipq_nand' in u-boot, this command can switch between SBL and usual ECC formats, so we can dump SBL partitions from u-boot.
Here is how I done this
nand device nand0
ipq_nand sbl
nand read $loadaddr 0 0xc80000
tftpput $loadaddr 0xc80000 192.168.1.254:dumpmtd0-7.bin
nand read $loadaddr 0xdc0000 0x100000
tftpput $loadaddr 0x100000 192.168.1.254:dumpmtd9.bin
ipq_nand linux
nand read $loadaddr 0xc80000 0x140000
tftpput $loadaddr 0x140000 192.168.1.254:dumpmtd8.bin
nand read $loadaddr 0xf40000 0x40000
tftpput $loadaddr 0x40000 192.168.1.254:dumpmtd11.bin
This is clean dumps only with data, with correctly stripped ECC, it can be passed to qcom-nandc-pagify and you have get dumps suitable for external flashers.
2 Likes
Will you able to ask RadioOperator to dump his 8500 mtd0 - 12 partitions using what you have just found? Maybe I can try them on my 8500?