[U-Boot] Status of fsl_elbc_nand driver and 4k page NAND / 4bit ECC

[Scott Wood <scottwood@freescale.com>]

On 05/08/2012 03:07 PM, Rafael Beims wrote:
> Based on your response, would it be OK to implement the marker in the
> bbt as something like Liu Shuo suggested ('M', 'B', 'b', 't', 0) and
> then do the scanning as follows:

I'd leave the BBT marker alone, and have the migration marker be located
elsewhere in the OOB that doesn't conflict with a BBT.  That way the BBT
code is untouched and the marker scanner only needs to consider one kind
of marker.

> Scan the bbt checking for the migrated flag as described. If we just
> find the default bbt marker, continue searching in the next block
> downwards to verify if we can find another marker indicating the
> migration (and completely independent of the bbt in this case).

Basically yes, except decouple it from the BBT.  The BBT code works as
always, and the migration marker code scans as described above.  If they
happen to be in the same block, fine -- the scanning code doesn't care
either way; only the marking code needs to know which to do.

> This second marker in this case would have to be written in a new
> block, or would it be OK to write it in a new page?
> It seems to me that a new block would be more appropriate, because you
> mentioned that a developer would like to erase the bbt sometimes, and
> that would imply the erasure of the entire block.

Right.

> What are your thought's about this suggestion?
> What would be an appropriate marker for the second block? It seems
> that the usual (at least for the bbt) is a marker with a character
> sequence. Should I just create a different character sequence and
> write it in the oob of the first page of the next block to indicate
> "developer" migration?

I tend to prefer random numbers over short strings for magic numbers, to
reduce the odds of collision, but whichever.  Just pick an offset into
the OOB that doesn't conflict with ECC or the BBT marker.

-Scott