[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.
>
>

Good, I'm not alone....

>> 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?
>
>

No, just reset the NAND controller. Since it's simply a peripheral device
attached to the bus, and supports only PIO mode.

>> 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.
>
>

As far as I know, it's O.K to Linux, but requires some source file updated
to u-boot in old release. (i.e. u-boot-2009.01, which was the original
target release to FTNANDC021)
I'll check if it's now O.K to do that in u-boot. (I means no source
code needs to be modified, except FTNANDC021.[ch])

>> 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?
>
>

A369 is a short for 'Faraday A369 SoC Evaluation Platform' with IC
design companies as
its target customers, which means A369 should never be the ASIC used
in mass production.
And the FTNANDC021 is actually designed for SSD applications, the
general software (e.g. linux)
is never put into consideration during IP/CHIP design process.

It's an an accident that the FTNANDC021 get integrated into the A369.
Although the NAND controller of A369 is considered a bad chip, the
NAND flash is still a primary storage
to A369. So it still needs to be integrated to U-Boot to make
everything work correctly.

The QEMU model for A369 is out several month ago, its primary target
is to provide ROM code development
environment for myself.
However 80% of the peripheral chips have been modeled at the end. (The
20% is MPEG4/H.264 and SATA)

It's now known to work properly with U-boot, eCos, Linux and even Android Linux.
So I integrate the QEMU model into my open-source Faraday SDK, and thus
the QEMU modeled A369 would be the primary target platform from now on.

That's why I think the ECC function is optional to FTNANDC021, and the
reason why I want it to be integrated to U-Boot.

BTW, I'm still struggling for QEMU contribution. So all the stuff are
still available at my own github account only.
And of course, they're not the up-to-date source tree, because the
github is actually my secondary storage.

P.S: My github account is 'dantesu1218', there you could find the
stuff described above.
If you really want to have a try on it, I'll suggest starting from
'falinux', it's a copy-cat of uClinuc & buildroot.
Which means user only needs to run 'make menuconfig', falinux would
gather all the stuff for him.

>> >> +       /* 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



--
Best wishes,
Kuo-Jung Su