Nice to see some discussion...
On Thursday 12 June 2003 06:40, William Watson wrote:
> Brad,
>
> Actually, the blockStatus is NOT covered by the spares ECC. The 16 "spare"
> bytes for each page include 6 bytes of ECC on the 512 data bytes, the page
> status byte, the block status byte, and eight bytes of spares, with their
> own internal ECC. The block and page status bytes are the only two bytes
> not involved in ECC in any way.
Yes that is correct.
>
>
> FWIW, I've noticed that the ECC codes used by YAFFS (and SmartMedia, etc.)
> are neither particularly strong nor efficient in their use of bits. In a
> message one week ago, "J.D. Bakker" said he (she?) knew his way around
> error correcting codes. Perhaps could we get someone to look into a code
> that detects more multi-bit errors or a smaller code that frees up some
> more of the spares bytes for use by YAFFS2. I'm not an ECC expert, so
> perhaps someone could explain the benefit of the current ECC. It looks
> like it uses 6 bytes to cover the 512 data bytes where 3 would suffice.
> Maybe SmartMedia did that as a legacy from code to handle old parts with
> only 256 data bytes per page (2 MByte parts), but YAFFS aims for larger
> parts than those.
The use of ECC bits in SmartMedia/mtd/yaffs is certainly not the Hamming
minimum. However, this strategy is more robust as it detects the difference
between corrupt data and corrupt ECC as well as being fairly immune to being
confused by multi-bit errors. The SmartMedia ECC is cheap to implement in
both hardware and software. It is also important, IMHO to preserve
compatability with exisiting ECC hardware solutions. {Sidebar: BTW, the ECC
on the tags uses a Hamming code which can detect and repair single bit
errors, but will get confused by multi-bit errors. I think I will replace
this with a more robust SmartMedia-like ECC in YAFFS2}.
YAFFS2 requires more tag bytes than can be provided by a single ECC block
(unless you did major shaving). This makes 2xspares (ie what you get with
1kBytes of data) the minimum block size,
>
> Mind, investigating the ECC doesn't help support large NAND arrays, or
> support parallel operation on multiple NAND chips. (J.D. Bakker mentioned
> those as goals.) The latter would take some fairly serious work on
> yaffs_guts. It would break one core assumption that each NAND operation
> completes or fails before another starts.
YAFFS is inherently single threaded right now so "logically parallel"
operations probably would not do much to help performance. In those cases,
maybe running each device as a single mount point would probably be simpler.
However "physically parallel" operations would probably.be of benefit (ie.
use 4 devices and make chuunk size 2K so you write 512B pages in parallel to
each other or use the paraleel bitplane operations of some devices in the
same way).
-- CHarles
---------------------------------------------------------------------------------------
This mailing list is hosted by Toby Churchill open software (
www.toby-churchill.org).
If mailing list membership is no longer wanted you can remove yourself from the list by
sending an email to
yaffs-request@toby-churchill.org with the text "unsubscribe"
(without the quotes) as the subject.
(text/plain)