[...]
ROM when loading firmware, copies back the value at metadata[0] to BI offset in page data. The following figure shows how the factory bad block marker is preserved.
...this is insane. It seems that they want you to swap this byte even in good blocks, so that you put the byte of real data that should go somewhere in the middle of the last 512-byte ECC chunk at offset zero in the page. This means that it will show up as a bad block when normal (but new-layout-using) software looks at it, which is why you need scrub. Ew.
How many blocks are being loaded by this mechanism? Just block zero (which is normally supposed to be guaranteed good anyway...)? Or multiple blocks?
The first block, then the 64th block, 128th block and 192th block (in default layout).
Any chance you could blow the NAND_MEMBLOCK_MARKER_RESERVE fuse? :-)
No, they are one-time programable. Delivering a "damaged" chip isn't a good practice.
Otherwise, I guess you do need to scrub. Have you complained to Freescale sales/support?
In fact no. The BootROM is "broken" and I doubt they will be willing to do anything about it.
But we want to write a block in our own format, so we need to scrub (wipe the block completely).
Erase always wipes the block completely, if it erases at all. Scrub in this context just means that U-Boot ignores the bad block indications (marker or table). Otherwise it would avoid erasing bad blocks, so that they stay bad, and you won't have scrubbed the entire region requested.
I work for the PowerPC side of Freescale, in case you're wondering why I'm unfamiliar with this. :-)
Interesting ... does everyone work for the PowerPC side of Freescale or is there some other reason why I never met anyone working for the ARM side of Freescale ? ;-)
They exist, but don't seem to engage Open Source development communities to the same degree.
-Scott
Cheers