[U-Boot] [PATCH v2 07/12] mtd: nand: add Faraday FTNANDC021 NAND controller support

[Scott Wood <scottwood@freescale.com>]

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(&regs->ior) & IOR_READY))
> >> +                       ;
> >> +               *(uint32_t *)(buf + off) = NAND_READ(&regs->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