[prev in list] [next in list] [prev in thread] [next in thread] 

List:       yaffs
Subject:    [Yaffs] Problems with Refreshing Blocks with ECC Corrections
From:       Trent Lillehaugen <trent.lillehaugen () red ! com>
Date:       2011-08-10 16:31:32
Message-ID: DF72ECD76D0B92498817A7D3A97DEE840EFB8E2858 () LFEXCH01 ! red ! local
[Download RAW message or body]

I am using YAFFS with the direct interface for an embedded system.

There are two YAFFS partitions:
/image
/data

A typical boot cycle is as follows:
- Bootloader mounts /image as read only
- Bootloader copies executable from /image to RAM
- Bootloader unmounts /image
- Bootloader starts application
- Application mounts /data as read/write
- Application does stuff
- Application unmounts /data
- Application shutsdown system

I would expect YAFFS to refresh blocks in the /image partition that start s=
howing ECC errors that are corrected, but I do not see this occurring.

To test, I modified our NAND driver to inject 1-bit read errors on a specif=
ic page.  I see that our integration with YAFFS correctly identifies that t=
he page has an ECC correction and that YAFFS marks it for priority garbage =
collection.  To ensure that some garbage collection occurs I am calling 'ya=
ffs_BackgroundGarbageCollect' before unmounting.

Stepping through the 'yaffs_BackgroundGarbageCollect' call I see that the b=
lock containing the page with ECC correction is not moved to another block =
because in 'yaffs_GarbageCollectBlock', 'maxCopies' is set to 5 and in this=
 case more than 5 pages are in use.

I don't see how blocks will ever be refreshed correctly in this scenario.

Are my expectations incorrect?
I am forgetting to call something or calling something incorrectly?
Is there any way (without modifying the YAFFS code) to force refreshes even=
 on a heavily used block?

Thanks,

Trent

This e-mail is the property of RED Digital Cinema Camera Company. It is int=
ended only for the person or entity to which it is addressed and may contai=
n information that is privileged, confidential, or otherwise protected from=
 disclosure. Distribution or copying of this e-mail, or the information con=
tained herein, to anyone other than the intended recipient is prohibited.


[prev in list] [next in list] [prev in thread] [next in thread]