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

[ylab]

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 imx28_ivt_linux.sb (Kernel 2.6) image generated from ltib which has kobs-ng.

kobs-ng installs a u-boot.sb 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):

Method	Result
# cat /dev/mtd0 > nandImage then erase nand # cat nandImage > /dev/mtd0 or # 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: 0x80508002
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.

Deductions/Notes:

- 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 u-boot.sb same as before does not work

Also:

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

u-boot.sb 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 !

Yesser

EDIT:

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: mxsboot.nand.zip

Original Attachment has been moved to: hacked-kobs.zip

Original Attachment has been moved to: nandwrite-o.txt.zip

Original Attachment has been moved to: nandDump-o.txt.zip

Original Attachment has been moved to: nandDump-o.zip

Original Attachment has been moved to: HackedKobsImage.nand.zip

Original Attachment has been moved to: nandDump-n.zip

Original Attachment has been moved to: catImage.nand.zip

Original Attachment has been moved to: kobs-ng-kernel-4.7.2-uboot.sb.txt.zip

Original Attachment has been moved to: u-boot.sb.zip

Original Attachment has been moved to: buildroot-Image.nand.zip

Original Attachment has been moved to: nandDump-n.txt.zip

[bba]

Dear Yesser, we are also working at this problem. Currently the only way is dumping the NAND flash by the gang programmer and using this image for flash pre-programming. But these only works, if the boot partition does not contain any bad blocks. Some notes:

- FCB and DBBT have to be adjusted by gang programmer for each NAND device ! (done by kobs-ng)

- We have tried to dump the boot partition using nanddump

nanddump -o -f mtd0-oob.bin /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x04000000...
ECC: 1 uncorrectable bitflip(s) at offset 0x00000000
ECC: 1 uncorrectable bitflip(s) at offset 0x00020000
ECC: 1 uncorrectable bitflip(s) at offset 0x00040000
ECC: 1 uncorrectable bitflip(s) at offset 0x00060000

- The reason for the uncorrectable bitflips is, the iMX6ul use a different ECC algorithm on the FCB area

nanddump -n -o -f mtd0-oob-noecc.bin /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x04000000...

- But these image does not boot using gang programmer. We have compared both images and found differences each 512 byte. Opposite to the behavior on eMMC the gang programmer use physical page numbering and the linux mtd layer use logical page numbering. In case of eMMC the gang programmer and the linux mtd layer are using logical page numbers.

[ylab · Accepted solution]

Solved

[fear_nada]

Hello friend, how did you solve this problem?
I also can not write raw image to nand and boot.

[ylab]

Bump...