I have a router whose uboot (on /dev/mtd0) is corrupted due to an unexpected power outage during its flashing. Since JTAG is disabled on the device, I will need to desolder its NAND chip and program it in an external programmer. The question is how to get the NAND dump from another working device:
Extract the full dump from a working NAND chip in an external programmer. This requires desoldering of the NAND chip from another working device (more effort).
Can I use nanddump to dump every mtd partition and then concatenate them to produce a full dump? It seems that most NAND programmer will not work with a partial dump (aka only mtd0 dump). E.g. "cat mtd0_dump.bin mtd1_dump.bin mtd2_dump.bin > full_nand_dump.bin"
You need to take into account padding between partitions, and the address of where a partition starts.
The uboot partition should be readonly 99% of the time, it shouldn't get easily corrupted by ungraceful shutdowns. Not sure what happened there, did you make sure the chip isn't actually malfunctioning?
Where is the missing 1 MB? 8 MB + 1016 MB = 1024 MB / 1 GB.
Is that partition table correct, though? Non-volatile storage hardware manufacturers usually make use of KB (kilo), MB (mega) and GB (giga), rather than KiB (kibi), MiB (mebi) and GiB (gibi), which would give roughly 954 MiB of storage space (assuming no bad sectors).
In the output from /proc/mtd, the sizes are typically interpreted using KiB (Kibibytes) and MiB (Mebibytes) for the following reasons:
Memory Specifications: Memory sizes in /proc/mtd are usually represented in powers of 2, aligning with the binary nature of memory allocation in computing.
Common Practice in Linux: Linux kernel interfaces and system files like /proc often utilize binary prefixes (KiB, MiB) to describe memory and storage sizes, which reflect actual hardware addressing and memory allocation.
• In the context of the provided /proc/mtd output, the units are interpreted as KiB (Kibibytes) and MiB (Mebibytes). Therefore, for instance, 0x00100000 should be interpreted as 1 MiB (1,024 KiB = 1,048,576), not 1,000 KB.
No, the sizes in the /proc/mtd table are in bytes, which isn't a factor when converting to either XiB or XB.
As for the rest, why exactly are you lecturing me on base 1000 units and base 1024 units when it's pretty clear I know about them from just reading my post above?
Your device specification shows an 1 GB flash chip. Non-volatile memory manufacturers (such as the ones manufacturing HDDs or SSDs), generally use base 1000, but it seems NAND and NOR manufacturers use base 1024, which is also used for volatile memory manufacturers.
Sorry, there was no lecturing intention in the previous post at all; it was just some repetitive habit. For non-volatile memory devices sold to regular consumers, I believe vendors might want to “cheat” by using the base-1000 system to present artificially larger capacities. However, they may use the base-1024 system for commercial or professional products.
Thanks a lot for the table. However, for the mtd6 partition, should its size be 1015 MiB (0x3f700000) instead of 1016 MiB as you showed? Is it possible that the "missing 1 MiB" is left unpartitioned at the end of the NAND chip?