On 04/22/2013 08:19:18 PM, Kuo-Jung Su wrote:
2013/4/23 Scott Wood <scottw...@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?
> 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.
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.
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
