ECC and multi page read write support

ECC and multi page read write support

[Miguel Freitas]

    Hi,

    I'd like to discuss some points on ECC and multi page before 
applying Rogelio's patch to the new driver. I think we need to better 
define the API conforming to this. obs: I prefer the word "sector" for 
a 512 bytes unit because some devices have only 256-byte page.
    First (dumb) question, why is the multi page read needed? 
Excuse for not being an expert in character devices, I think it's great 
to have a driver which do not have such restrictions. But I don't 
know exactly what for.

    There are some problems with multi page x ECC:

    1) The read / write routines can work on subsector data, ie, they 
can read/write less than a sector. This of course implies in no ECC 
generation at all, cause the ECC has to be calculated from all 512 
bytes sectors (there is a warning on this in the new code). 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.
    2) I particularly like the write_ecc API, as mtd_info.html says: 
"the write_ecc function places the generated ECC data into eccbuf". 
So it's up to user module to decide what to do with ECC data, ie, 
where in OOB it will be placed. Unfortunately, writing to multiple 
sectors will generate multiple ECC data, so the user must know how 
many sectors are being written and record ECC data for the 
respective sectors.
    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. We should decide if the correction of 
data is to be made inside the read_ecc or if the _ECC syndrom_ 
(generated by after reading data + ECC data, not ECC data itself) 
should be returned. If we decide to return the syndrom, we will have 
the same problem as (2). David may give us a insight on this based 
on his experience with other drivers.

   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. Unlike the writing sequence, which can be  
write_ecc(buf,eccbuf) followed by write_oob(eccbuf), we cannot do 
read_ecc(buf) followed by read_oob(eccbuf) expecting that 
syndrom registers will be correct. The read_oob operation must be 
executed inside the read_ecc. So, the flexibility added from 
write_ecc returning the ECC data is limited by the fact that it must 
be placed somewhere in OOB.

   I have 2 ideas for the API:

   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. This way, write_ecc can automatically write the ECC 
in OOB. read_ecc can read, check and return corrected data. We 
will not need any other parameter in read_ecc/write_ecc. Someone 
must point that user modules may want to write additional OOB data, 
but remember that it still possible by writing less than 16 bytes to a 
particular OOB offset.

    Anyway, we can always implement subsector read with ECC by 
reading an entire sector, correcting the data and returning only the 
information asked by the user. A subsector read without ECC 
doesn't need to read a full sector, so no performance degradation 
will occur in this case. This solution cannot be done when writting 
subsector, as we can only record ECC in OOB one time (we would 
need to erase a block to do it again).


    Comments?? :)

Regards,

Miguel Freitas
Center for Telecommunications Studies
CATHOLIC UNIVERSITY - BRASIL
e-mail: miguel@cetuc.puc-rio.br
phone/fax#:+55-21-540-8854


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

Re: ECC and multi page read write support

[David Woodhouse]

miguel@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@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@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@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@infradead.org