[U-Boot] [PATCH 09/15 V5] iMX28: Add GPMI NAND driver

Scott Wood scottwood at freescale.com
Mon Oct 10 23:06:31 CEST 2011


On 09/30/2011 04:39 AM, Marek Vasut wrote:
> +/*
> + * There are several places in this driver where we have to handle the OOB and
> + * block marks. This is the function where things are the most complicated, so
> + * this is where we try to explain it all. All the other places refer back to
> + * here.
> + *
> + * These are the rules, in order of decreasing importance:
> + *
> + * 1) Nothing the caller does can be allowed to imperil the block mark, so all
> + *    write operations take measures to protect it.
> + *
> + * 2) In read operations, the first byte of the OOB we return must reflect the
> + *    true state of the block mark, no matter where that block mark appears in
> + *    the physical page.
> + *
> + * 3) ECC-based read operations return an OOB full of set bits (since we never
> + *    allow ECC-based writes to the OOB, it doesn't matter what ECC-based reads
> + *    return).
> + *
> + * 4) "Raw" read operations return a direct view of the physical bytes in the
> + *    page, using the conventional definition of which bytes are data and which
> + *    are OOB. This gives the caller a way to see the actual, physical bytes
> + *    in the page, without the distortions applied by our ECC engine.

As discussed, #4 is not a "rule" of the Linux/U-Boot NAND interface.  If
it's something you're doing as a hack, then say so -- make it clear that
you're deviating from the normal interface.

Otherwise, Acked-By: Scott Wood <scottwood at freescale.com>

-Scott



More information about the U-Boot mailing list