AnsweredAssumed Answered

How can I make an image of NAND boot sector, for mass programming?

Question asked by Yesser Labania on Mar 30, 2017
Latest reply on Apr 18, 2018 by Birger Bauch

Hello all,

I'm sorry that the question above isn't every descriptive, but the matter at hand is a bit complex, so bear with me


We have:

- A custom board based on the iMX28-evk

- Linux 4.7.2 built with buildroot 2016.08.01

- u-Boot 2016.07 (with SPL)

- NAND flash: Micron MT29F4G08ABADAWP (512 MB)


Everything works perfectly except the installation of the boot loader on the NAND

Our Current Solution is to use the MFGTools with an (Kernel 2.6) image generated from ltib which has kobs-ng.

kobs-ng installs a image, then u-boot takes care of the rest (flashing kernel, rootfs, ...)


What we would like to have

a raw u-boot image to be flashed on the NANDs by the manufacturer. And that does not seem to work at all as generating such image yielded un-bootable NANDs.


Note: All relevant files and program outputs are attached


What we have tried (nandImage is my image file name):


# cat /dev/mtd0 > nandImage

then erase nand

# cat nandImage > /dev/mtd0


# nandwrite -o nandImage /dev/mtd0

Does not work, looking at the file (attached) it turns out after long research that some meta bytes (aka ecc ??) are missing.

After reboot, the system does not boot and I get a CPU code:


same with /dev/mtdblock0

I get an input/output error

After reboot: CPU code 0x80508002

# nanddump -o -f nandImage /dev/mtd0

then erase nand

# nandwrite -o nandImage /dev/mtd0

The file (attached) also does not seem to have the ecc or meta bytes. or something else is wrong with it. admittedly I didn't know what exactly to look for

# nanddump -f nandImage -n -o /dev/mtd0

# nandwrite -n -o /dev/mtd0 nandImage

giving the switch -n would mean withough ecc. This WORKS

Apparently, if I did write the image after reading it, the ecc bytes are still there, nandwrite would not touch them and the system boots BUT (next method)

# nanddump -f nandImage -n -o /dev/mtd0

# nandwrite -n -o /dev/mtd0 SomeNullFilledFile

# nandwrite -n -o /dev/mtd0 nandImage

Does not work !

Which meant that the ecc bytes are the problem

I also hacked the kobs-ng to write to a file instead of a nand (source attached).The resulting file (attached) looked ok (I guess !), as I saw the offset of the ecc but flashing it with all possible writing commands mentioned above didn't work either !


What Works:

- Sending the chip to the manufacturer and they would read it raw and write the data to other NANDs, but that is no solution.



- There is a difference between raw reading and reading from the kernel through the iMX28 processor !

- nanddump, nandwrite, cat, and dd all work perfectly with other mtd partitions !!!!!!!!!!!! (What's that about !)

- Side note: kobs-ng (built with buildroot) and used to flash same as before does not work



buildroot has an option to generate a "u-boot.nand (Freescale i.MX28)" image (using mxsboot, in u-Boot/tools)

but the image size is weird although I did give the NAND's parameters correctly (or so I think):

NAND Page size = 2048

NAND OOB size = 64

NAND Erase size = 131072 (128 KB)


bootloader partition (mtd0) size = 2 MB size = 392.3 KB ----------- OK

u-boot.nand size = 3,1 MB ----------- NOT OK !

Interestingly, the image generated by the hacked kobs is 832.1 KB


Google search didn't help much


So after this long post the questions are:

1) What is the right way (or solution to my methods) to get a raw image of the NANDS's boot loaded partition such that it can be written on other chips (without having to send a chip to the manufacturer )

2) Why doesn't kobs-ng work in kernel 4.7.2, and what should I do to get to work ?


Please excuse any mistakes, or missing info, I'll be glad to provide further details.

Your help is highly appreciated !




looking that source of mxsboot, I found out that there is a macro defining the maximum size of the boot stream which defaults to 1MB.

file: u-boot_source_tree/tools/mxsboot.c

* Each of the U-Boot bootstreams is at maximum 1MB big.
* TWEAK this if, for some wild reason, you need to boot bigger image.

#define     MAX_BOOTSTREAM_SIZE     (1 * 1024 * 1024)

- Setting this to 512KB (still a bit bigger than my real boot stream size) made the NAND image a good fitting 2 MB

- Checking the image with a hex editor, I do see the meta bytes, the headers for imx28 (FCB ...) and they seem to be ok

- I now realize that there is a difference between ecc and meta bytes.

- I still could not write the resulting image using nandwrite or cat such that it would boot !

- I have attached the new nand image (called "mxsboot.nand")

- I actually don't have a chip programmer, so I can't tell if writing this image using one of those devices would result in a bootable NAND chip


imx28 mainline_linux

4.7 kernel uboot; kobs-ng nand boot

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to:

Original Attachment has been moved to: