From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 23 Apr 2013 17:57:10 -0500
Subject: [U-Boot] [PATCH v2 07/12] mtd: nand: add Faraday FTNANDC021
 NAND controller support
In-Reply-To: <CAK65tU7dF2Y3rvyuvg1yeZ9Y+fJUo+fJ4xf49QEk_uXNFJyJzg@mail.gmail.com>
	(from dantesu@gmail.com on Mon Apr 22 20:19:18 2013)
Message-ID: <1366757830.5825.14@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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?

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