UBIFS seeing corrupt blank pages when image flashed via u-boot

[Gupta, Pekon]

Hi Artem,

>From: Artem Bityutskiy [mailto:artem.bityutskiy at linux.intel.com]
>>On Wed, 2014-01-15 at 21:29 +0000, Gupta, Pekon wrote:
>> Hi Artem,
>>
>> >From: Artem Bityutskiy [mailto:artem.bityutskiy at linux.intel.com]
>> <snip>
>> >Conclusion: all UBIFS needs is a way to ask the driver - is this NAND
>> >page blank or not? UBIFS does not really has to compare to all 0xFFs.
>> >
>> Thanks for details. Yes, I understand the concept in general that you
>> want to recover last bit of user-data written on NAND (without corruption).
>>
>> Now, as NAND driver itself does differentiation between and erased-page
>> v/s programmed-page. Can we use different error codes to pass this
>> information to upper layers like;
>
>I thought the ECC is something which could be used to differentiate.
>
(I think you confused this thread with other mail thread going with Brian,
 that one is purely about how to implement detection of erased-page).

However, *assuming NAND driver can identify erased-page correctly*,
I don't want  UBI/UBIFS to re-check the read_buf for 0xff again, because
 underlying NAND driver has already identified as erased-page, and
fixed the data before passing it to above MTD layer.

So, I'm proposing that NAND driver returns following error-codes
to indicate the results of its finding to MTD and UBI layers, so they
don't have to re-check data again.

>
>> *For MTD layer*
>> 0: data valid, length of data is determined by 'read_len'  (currently)
>> -EUCLEAN: correctable bit-flips found, data is valid
>> -EBADMSG: un-correctable bit-flips, data *may-be* invalid.
>> -ENODATA: detected erased-page. *Actual* data determined by read_len.
>> -ENOMSG:  detected erased-page with bit-flips. *Actual* data determined by read_len.
>
>Not sure this is a good idea. If NAND driver cannot do the
>differentiation, then it should not be done by the MTD layer, I think.
>

[...]

>Then just improve UBI and UBIFS and make the function which compares
>buffers with all 0xFFs allow for bit-flips. We know the maximum possible
>bit-flips per min. I/O unit, right? Just allow for that amount.
>
I think UBI/UBIFS layer should be kept independent of ECC details.
So, adding checks for (bit-flip count < ecc.strength) in UBI/UBIFS is not good.

My aim is that UBI/UBIFS should be able to classify its ubi_io_read() in 
any of the following baskets with least possible CPU cycles.
- no data (with or without correctable bit-flips)
- valid data (with or without correctable bit-flips)
- invalid data (un-correctable bit-flips)

with regards, pekon