From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 10 Oct 2011 16:06:31 -0500 Subject: [U-Boot] [PATCH 09/15 V5] iMX28: Add GPMI NAND driver In-Reply-To: <1317375574-23713-1-git-send-email-marek.vasut@gmail.com> References: <1317254841-23708-1-git-send-email-marek.vasut@gmail.com> <1317375574-23713-1-git-send-email-marek.vasut@gmail.com> Message-ID: <4E935E57.1080408@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 -Scott