0xFFFF/doc/dumping

Dumping the firmware:

This technique consists on reconstructing a firmware image dumping
pieces at certain offsets of the device internal memory.

Technical details:

 * The internal flash memory is exposed to the system as MTD devices.
 * Is possible to dump the individual sections of a flashed firmware.
 *
 * READ src/local.c for detailed information.

   mtd0 - contains xloader and secondary pieces of the bootloaders
          0x00000 - xloader.bin    (size is 0x03600)
          0x04000 - secondary.bin  (size is 0x15400)
          0x1FFFF - eof

   mtd1 - looks like there's a pool ConF structures

   mtd2 - starts with NOLO img\x5c\x13 and \x00 padding
          0x00800 - zImage

          > NOLO is a four byte marker, next four bytes
          > can vary since it is kernel image size

   mtd3 - initfs.jffs2 (2M) aka 0x200000 vs 0x3900000

   mtd4 - rootfs.jffs2 (a fucking copy of the above rootfs?)

For dumping mtd partition is used tool nanddump. Here is example how to dump
kernel image without padding to file zImage:

 $ nanddump -o -b -s 0x00000800 -l 0x001FF800 -f zImage /dev/mtd2

Params means:
-o - "Omit oob data"
-b - "Omit bad blocks"
-s - "Start address"
-l - "Length"
-f - "Output file"

Please note that some new versions of nanddump have some options removed and
some are enabled by default. Before using check params of your nanddump version.


// Extra notes //

[MTD] NAND Consolidate oobinfo handling

The info structure for out of band data was copied into
the mtd structure. Make it a pointer and remove the ability
to set it from userspace. The position of ecc bytes is
defined by the hardware and should not be changed by software.

// The oob stuff

In mtd3 the OOB data is 64 bytes aka 0x40, and this oob stuff
appears every 2KB aka 0x800 bytes.

/*
 * Obsolete legacy interface. Keep it in order not to break userspace
 * interfaces
 */
struct nand_oobinfo {
        uint32_t useecc;
        uint32_t eccbytes;
        uint32_t oobfree[8][2];
        uint32_t eccpos[32];
};