[U-Boot] [PATCH v2 07/12] mtd: nand: add Faraday FTNANDC021 NAND controller support
Scott Wood
scottwood at freescale.com
Tue Apr 23 01:11:30 CEST 2013
On 04/21/2013 09:45:00 PM, Kuo-Jung Su wrote:
> Sorry, it's my bad, I forget to clean it up.
> In my private base, it's possible to turn-on ECC support to FTNADC021
> with the following issues:
>
> 1. When ECC is enabled, FTNANDC021 would always do ECC on every data
> block,
> including the blank block(all 0xff).
> What I mean is 'With ECC enabled, we'll have ECC errors on non-ecc
> proected data blocks or even the blank block'.
fsl_ifc_nand is similar -- when we see an uncorrectable error, we check
whether the page is blank.
> 2. FTNANDC021 would stop upon ECC errors, a chip reset is required to
> make it work again.
This sounds bad, though. I assume that this is more than just
resetting the NAND controller -- that you're resetting the entire
system on a chip or similar?
> 3. There are only 4 bytes data + 1 byte Bad Block Info available to
> software,
> and because of the ECC issues above.
> I'll have to use 1 byte of data to tag if this block is 'not
> blank',
> to make it possible to cancel the operation on these blocks
> to prevent the chip to be stopped. (It means that I don't have to
> reset chip)
> And thus if the ECC is enabled, there are only 3 data bytes
> available to software,
> which makes it not possible to support BBT. (BBT requres 4 data
> bytes in OOB)
You could define a custom BBT descriptor that uses fewer bytes.
> So in this patch, I'll prefer ECC disabled.
> BTW, because of the issues above, this chip has been faced out many
> years ago.
> It would only be available to A369 or QEMU, and never in mass
> production.
> And thus I think it's ok to have ECC disabled in this patch.
Why do we need support in U-Boot, then? Couldn't you just have QEMU
model saner hardware? What is A369?
> >> + /* page read */
> >> + for (off = 0; len > 0; len -= 4, off += 4) {
> >> + while (!(NAND_READ(®s->ior) & IOR_READY))
> >> + ;
> >> + *(uint32_t *)(buf + off) = NAND_READ(®s->dr);
> >> + }
> >
> >
> > Why do you need to check IOR_READY here but not in read_byte?
> >
> >
>
> Because there is no any hardware access in 'read_byte'.
> The FTNANDC021 simplily does not support byte access by default.
> (I mean it's possible to update hardware RTL code,
> but it's not the case to A369)
> So I add some tricks to READ_ID, READ_OOB and READ_STATUS.
> The actual hardware access is performed at ftnandc021_cmdfunc(),
> The ftnandc021_read_byte() simpily access the cached data buffer.
OK, so you're assuming that the OOB will never be larger than the
256-byte software buffer?
-Scott
More information about the U-Boot
mailing list