ECC and multi page read write support

[David Woodhouse]

miguel at cetuc.puc-rio.br said:
> . By  allowing multi sector access, it may not be possible to  check/
> generate ECC for all sectors being accessed, unless we  access an
> integral multiple of sectors.

As far as the DiskOnChip is concerned, that's an integral restriction of 
the hardware - ECC is supported only on 512-byte sectors, not on other 
sizes. That's one of the reasons why some people may end up continuing to 
use NFTL on the DiskOnChip rather than switching to JFFS.

JFFS, before it's used on NAND flash, is going to have to do write 
gathering so that it doesn't violate the restrictions on the number of 
writes per page. At that time, if we're going to use the hardware ECC - 
which I'm not sure we _can_ do - then we can make it write only one page at 
a time so we don't necessarily need to support multi-page write_ecc().

Multipage read_ecc() could be useful though, although again not absolutely 
necessary, because it could be handled elsewhere.


miguel at cetuc.puc-rio.br said:
>    3) The read_ecc do have the same eccbuf parameter. IMHO, this
> doesn't make much sense, as the ECC data written to the OOB is of  no
> use to the user module.

You're right. It probably makes more sense to have the ECC correction
handled entirely within the DiskOnChip code. It should have some way of
signalling to the caller that an error was found and corrected, though.


miguel at cetuc.puc-rio.br said:
>    The read_ecc is more "atomic" than write_ecc because the ECC  data
> must be read just after the sector data itself, or the syndrom  could
> be wrong if another process accesses the DoC in the mean  time.

The DiskOnChip driver has to handle that itself. CFI flash can read 'wrong' 
data if you try to read from it while it's in the middle of a write, too. 
It's a simple case of preventing conflicting concurrent access. 


miguel at cetuc.puc-rio.br said:
> 
>    1) we maintain the eccbuf in write_ecc and provide read_ecc with  a
> offset into OOB where it will find the ECC data.
>    2) we hardcode the position of ECC data in offset zero of OOB as
> M-Systems do.

I have no preference here. NFTL will obviously be happy if you hard-code it 
to zero. It depends on how we're going to do JFFS-on-NAND. It's probably 
simpler just to declare that JFFS will use zero too, and hard-code it. We 
can always change that later if we really have to.

It would have been nice if we could have used the ECC engine for individual 
JFFS nodes within a page - storing the syndromes in different places within 
the OOB area. I don't think the hardware lets us to that though - although 
we could pad the writes with 0xff, the reads wouldn't work.




--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org