2013/4/23 Scott Wood <scottw...@freescale.com>: > 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? >
No, that's my bad. I don't really understand NAND flash protocol 4 years ago, I'm now re-writing the read/write stuff with correct column address handling. > -Scott -- Best wishes, Kuo-Jung Su _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot