Re: NAND technical review

Jonathan Larmour wrote:
>>> Does your implementation _require_ a BBT in its current 
>>> implementation? For simpler NAND usage, it may be overkill e.g. an 
>>> application where the number of rewrites is very small, so the 
>>> factory bad markers may be considered sufficient.
>>
>> This is a bit hairy in my opinion, and one reason is that there is no 
>> Standard Layout for the spare areas. One case where a BBT is forced: 
>> my BlackFin NFC can be used to boot from NAND, but it enforces a spare 
>> layout that is incompatible with MTD or anybody. It is even 
>> incompatible with most chips' specification that the first byte of 
>> spare in the first page of the block is the Bad Block Marker. 
>> BlackFin's boot layout uses this first byte in a way that suits it, 
>> and it may be 0 -- which would otherwise mean Bad Block.
> 
> I infer that your layer can cope with that? I didn't see the handling 
> for that in io_nand_chip_bad_block.c.

Well, I think I didn't answer this appropriately after all. This is not 
a chip issue but a controller issue (I am the needle stuck in the 
groove). The issue is that the BlackFin NFC (in its boot mode only!) 
enforces a deviant spare layout, which introduces an incompatibility 
between controller and any chips: the booting controller thinks it can 
arbitrarily use byte 0 of the first page's spare, and for chips that is 
usually the bad-block marker.

One observation: the BlackFin NFC boots from page 0 (on block 0) and 
NAND chips usually guarantee that block 0 is not bad. Chips may even 
have a specified higher write-count-before-errors for block 0 than the 
other blocks. I think the chip manufacturers' motivation is to 
facilitate special handling of block 0: boot code, FIS, BBT, anything...

Another observation: even though block 0 is not bad whatever the marker 
written by the boot code, it ought to be marked BAD_RESERVED in the BBT 
to avoid accidental erasure.

Rutger