From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Mon, 22 Apr 2013 18:11:30 -0500
Subject: [U-Boot] [PATCH v2 07/12] mtd: nand: add Faraday FTNANDC021
 NAND controller support
In-Reply-To: <CAK65tU4ZS1FsmOhg4Ge93DG=ikJBTuxSVxyLFVEC2Ss8ShhwUw@mail.gmail.com>
	(from dantesu@gmail.com on Sun Apr 21 21:45:00 2013)
Message-ID: <1366672290.10399.9@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/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.

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

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

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

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