2013/4/24 Scott Wood <scottw...@freescale.com>: > 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? > >
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
