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

[Kuo-Jung Su <dantesu@gmail.com>]

2013/4/24 Scott Wood <scottwood@freescale.com>:
> On 04/22/2013 08:19:18 PM, Kuo-Jung Su wrote:
>>
>> 2013/4/23 Scott Wood <scottwood@freescale.com>:
>> > On 04/21/2013 09:45:00 PM, Kuo-Jung Su wrote:
>> >> 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.
>
>
> OK, so what's the downside to resetting the chip on an ECC error?
> Performance when reading a bunch of blank pages?
>
>

1. I'm lazy and coward.
2. It do impact the performance very much, because the ECC error is currently
   detected by a ~200ms NAND flash command timeout.

Now I plan to enable ECC in the next patch, and I'll check
if it's possible to detect ECC error more directly and cancel command wait.

P.S:
Both the RTL and datasheet of FTNANDC021 are buggy,
and the IP designer has quit from Faraday years.
I have to do it by trial and error.... so I'll always say 'I'll try....'

>> > 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])
>
>
> The NAND code has been updated since then (currently corresponds to Linux
> 3.0), though I'm not sure what the problem would have been even back then.
>
>

That sounds good!
But I've found that BBT support has been dropped from default settings of Linux
by myself years ago, I simply forget it.
It means that I don't even need to create a customized BBT header.

P.S:
The BBT was turned on to accelerate bad block scan in old days.
Because the former driver written by one of my colleague, always read
a full page rather than oob only. It takes +5 min to scan bad blocks
from 256MB flash.
However the driver has been re-written with reading oob only at
several years ago,
it now takes < 1 sec to scan bad blocks from 512MB flash, so I drop
the BBT support by then.

>> 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.
>
>
> It could still be a problem during evaluation, though I guess you don't
> support MLC NAND chips which would need it the most.  I won't block it, but
> at least make sure it prints a prominent warning message.
>

Don't worry about that, I've made my mind to enable ECC at next patch.
Sorry for the mess that I've done.

> -Scott


--
Best wishes,
Kuo-Jung Su