Hi Charles-
Thank you for the reply.
It appears that using the "on-die ECC" capability of our MICRON NAND SLC 4Gb 8bit FLASH is the ticket.
We are getting better results..
I have one question:
This part has a 64byte OOB area per 2k Block.
>From reading the data sheet.. there are 8 bytes per 512 byte for ECC parity bits.. so in a 2048 byte data block we
have 32 bytes set aside for ECC. There is a 2 byte bad block marker. Leaving 30 bytes for "META DATA"
If things are setup correctly, will YAFFS2 use that area for tags?
You indicated below that YAFFS2 will to its own ECC on it's file system tags, which makes sense because the
part does not provide ECC protection on some of memory set aside for META DATA.
Is there not enough space for YAFFS2 in the OOB area or do we need to mount YAFFS2 with -o "use-inband-tags" ?
Thank you for your time!
On Jul 8, 2012, at 2:59 PM, Charles Manning wrote:
> A lot of questions that will mostly have the worst possible answer... "it
> depends on your platform".
>
> On Friday 06 July 2012 10:58:17 Brent Leever wrote:
>> Hi-
>>
>> We're having some difficulty with file corruption using
>>
>> YAFFS2
>> LINUX 2.6.30
>> MTD (stock (probably) )
>> NAND (we tweaked for out target)
>>
>> ( a flash resident file will suddenly flip a bit or two after R/W
>> operations in other areas of flash, a relatively rare occurrence, but a
>> disaster when it happens )
>
> How rare?
>
>>
>> We are using a MICRON NAND, LARGE PAGE, 8 bit wide, 4Gb, SLC
>>
>> I suspect some incorrect ECC handling...
>>
>> Is it possible these layers are stepping on each other in the OOB as far as
>> ECC data is concerned? ( probably a yes.. )
>
> For yaffs2 All the data ECC handling is in the MTD.
> Yaffs2 does only does ECC on its own tags. That is not going to be causing
> single bit flips in data files.
>>
>> If YAFFS2 is doing ECC, should we insure that MTD/NAND/HW are not? (
>> perhaps this is obviously a yes.. but do you all think this may be
>> happening? )
>
> Yaffs2 is not doing ECC. Yaffs2 leave all data ECC to the driver.
>>
>> If using YAFFS2 and we have enough processor... is it preferable to simply
>> have YAFFS2 do the ECC and disable in all other areas of the FLASH SW
>> STACK?
>>
>> Does MTD have ECC on by default?
> It depends on the environment.
>> Does the HW default ECC on by default?
> Ditto
>
>> If these are on.. will YAFFS2 choke or will it recognize and let the lower
>> layers do ECC stuff?
> Yaffs does not care, it assume the mtd is doing its job properly.
>
>> Does the flag use_nand_ecc below mean that YAFFS will
>> NOT do ECC and rely on the lower layers?
>
> That flag is only relevant to yaffs1 mode of operation.
>
>>
>> What is the best setup here ?
>> What is the most expedient if we don't really care about performance.. we
>> just need data integrity!
>
> It will depend on the hardware and flash you are using.
>
> Generally the more bits you correct, the better result you will get. If your
> system has a NAND controller with BCH then it is wise to use that.
>
>
>>
>> Also.. MTD is setup with USE_BBT if that matters.
>
> Yaffs2 does not care how the mtd manages bad blocks. It just tells the
>
>>
>> Also.. YAFFS2 retires a HUGE amount of blocks on some boards ( 3 ECC errors
>> = retire the block right? )...
>
> This is happening because the mtd is reporting that the blocks are having data
> integrity problems.
>
>>
>> /proc/yaffs output below.. (this is a well behaved board.. just wanted to
>> share the YAFFS setup )
>>
>> THANK YOU ALL!
>
> I would suggest you focus on this as an mtd issue.
>
> -- Charles
>
>> -Brent
>>
>>
>>
>>
>> cat /proc/yaffs
>>
>> -bash-3.00# cat /proc/yaffs
>> Multi-version YAFFS built:May 23 2012 15:15:53
>>
>>
>> Device 0 "AJA Flash Partition 1"
>> start_block.......... 0
>> end_block............ 4095
>> total_bytes_per_chunk 2048
>> use_nand_ecc......... 1
>> no_tags_ecc.......... 0
>> is_yaffs2............ 1
>> inband_tags.......... 0
>> empty_lost_n_found... 1
>> disable_lazy_load.... 0
>> refresh_period....... 500
>> n_caches............. 10
>> n_reserved_blocks.... 5
>> always_check_erased.. 0
>>
>> max file size....... 549755811840
>> data_bytes_per_chunk. 2048
>> chunk_grp_bits....... 0
>> chunk_grp_size....... 1
>> n_erased_blocks...... 3186
>> blocks_in_checkpt.... 2
>>
>> n_tnodes............. 1507
>> n_obj................ 181
>> n_free_chunks........ 241847
>>
>> n_page_writes........ 6443
>> n_page_reads......... 7099
>> n_erasures........... 56
>> n_gc_copies.......... 346
>> all_gcs.............. 77
>> passive_gc_count..... 77
>> oldest_dirty_gc_count 0
>> n_gc_blocks.......... 21
>> bg_gcs............... 21
>> n_retried_writes..... 0
>> n_retired_blocks..... 0
>> n_ecc_fixed.......... 10
>> n_ecc_unfixed........ 2
>> n_tags_ecc_fixed..... 0
>> n_tags_ecc_unfixed... 0
>> cache_hits........... 0
>> n_deleted_files...... 0
>> n_unlinked_files..... 5
>> refresh_count........ 1
>> n_bg_deletions....... 0
>> tags_used............ 508
>> summary_used......... 53364
>
>
(text/plain)