This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
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