Re: [Yaffs] bit error rates --> a vendor speaks

[Vitaly Wool <vwool@ru.mvista.com>]

Hi folks,

just two small notes from my side.
First, FWIW, YAFFS2 never writes OOB w/o data and that looks more proper 
than JFFS2 style which means cleanmarkers for an empty page.
YAFFS2 just needs means to be agnostic about how OOB bytes are placed 
within a page.

Next, I took a look at rtc_from4.c and I'm not sure how to follow this 
method if the NAND controller just doesn't have means to give the 
caclulated ECC back to user. Thomas, could you please elaborate on that?

Best regards,
  Vitaly

Thomas Gleixner wrote:

>Charles,
>
>On Thu, 2006-02-16 at 14:32 +1300, Charles Manning wrote:
>  
>
>>1) ECC on tags....  Tags are so small that a single-bit correction is probably 
>>enough. Multibit is probably a good thing to investigate.
>>2) More OOB being used for multi-bit schemes will probably mean less space 
>>available for tags.
>>    
>>
>
>We really should start to think seriously about oob usage for arbitrary
>data storage at all. I know that YAFFS(2) depends on that, but looking
>at the required mess in the code to keep this up for all the 9999
>variants of ECC/RS whatever mechanisms, bad block marking schemes ...
>
>Some words about Reed Solomon.
>
>Reed Solomon needs hardware support for performance reasons. Efficient
>usage of Reed Solomon requires a different Data / RS-code layout:
>
>512 Byte Data
>8 Byte RS Code
>512 Byte Data
>8 Byte RS Code
>512 Byte Data
>8 Byte RS Code
>512 Byte Data
>8 Byte RS Code
>32 Byte OOB
>
>This layout is supported already (see rtc_from4.c). It requires usage of
>flash based bad block tables.
>
>	tglx
>
>
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
>  
>