[PATCH 1/2] nand: nand_bbt: Export nand_update_bbt
Huang Shijie
b32955 at freescale.com
Mon Aug 27 22:19:33 EDT 2012
于 2012年08月27日 23:25, Artem Bityutskiy 写道:
> On Thu, 2012-08-23 at 11:36 -0400, Huang Shijie wrote:
>>> Why this driver redefined ->block_markbad() at all, it is not supposed
>> For hardware reason, in mx23, the bad block mark is stored in the
>> first byte of the nand page;
>> in mx28/mx50/mx6q, the bad block mark is stored in the first byte of the OOB.
>>
>> That's why the driver redefined the ->block_markbad().
> OK. Would you please tell about the driver some more, I am particularly
> interested how th mx23 case works.
>
> * So the bad block marker is the first byte of the eraseblock set to 0?
yes.
> * What if the user data stars with zero? Or you hide the first NAND page
> from the user?
Please see the picture in the common_nfc_set_geometry().
It's a real nand page layout.
The `M` is metadata, it's about 10 byte len.
The bad block marker is stored in the metadata, not the the
`data` section which save the user's data.
We do not hide the first NAND page.
> * Can you point me to the code where you check if the eraseblock is bad
> or not at the initialization time (sorry, I could find myself,
> by trying to save time).
>
Please see the mx23_boot_init().
When mx23 reads a new nand chip in the first time, it will scan all
the nand chip. If it finds a bad block, it will call the
nand->block_markbad() which
is just the gpmi_block_markbad(). the gpmi_block_markbad() will mark the
first byte
of the nand page to 0 (the mx23 does not support the `swap` feature). So
NAND boot mode,
the ROM of mx23 will check the first byte of the NAND page, if it finds
a 0, it knows that
this is a bad block.
thanks
Huang Shijie
More information about the linux-mtd
mailing list