Re: [PATCH 1/2] nand: nand_bbt: Export nand_update_bbt

[Huang Shijie <b32955@freescale.com>]

于 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