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(®s->ior) & IOR_READY))
>> + ;
>> + *(uint32_t *)(buf + off) = NAND_READ(®s->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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
