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

[Kuo-Jung Su]

2013/4/23 Scott Wood <scottwood at 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?
>

No, that's my bad.
I don't really understand NAND flash protocol 4 years ago, I'm now
re-writing the read/write stuff
with correct column address handling.

> -Scott



--
Best wishes,
Kuo-Jung Su