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 <scottw...@freescale.com> -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
