Make NAND_BBT_NO_OOB_BBM configurable or let the gpmi driver decide?

[Daniel Glöckner]

Hi Miquel,

Am 24.02.22 um 17:03 schrieb Miquel Raynal:
> dg at emlix.com wrote on Thu, 24 Feb 2022 16:55:27 +0100:
>> Am 24.02.22 um 16:29 schrieb Miquel Raynal:
>>> dg at emlix.com wrote on Wed, 23 Feb 2022 11:59:02 +0100:  
>>>> Am 22.02.22 um 23:02 schrieb Han Xu:>>> Could you please describe more details about what kind of error, how to  
>>>>> reproduce it and on which kernel version?    
>>>>
>>>> You need a flash that has one bad block where programming the BBM sets
>>>> NAND_STATUS_FAIL in its status register. The latest kernels should still
>>>> have problems when this happens in a UBI.  
>>>
>>> I believe we should try to tackle "why" this happens more than try to
>>> workaround its consequences. Can you give more details about why we get
>>> this status?  
>>
>> Uhm, the block is bad, broken. It shows the same behavior even after
>> power cycling. The other blocks are ok. I don't think it is our fault
>> that it died so early.
> 
> But why after a power cycle are we trying to write the BBM?

I did not want to imply that Linux tries to write the block after every
power cycle. UBI notices that the block is broken once and manages to
mark it as bad in the BBT, so after power cycle it will not try to write
to that block again. What I wanted to say is that manual testing of the
block after power cycling shows that the block remains unusable.

The problem is that UBI switches to read-only mode after it marked the
block as bad in the BBT because the redundant BBM in the OOB of the
block could not be written. And we don't want to get into a situation
where we have to reboot the system, especially if it is because of
something we don't need.

We could change nand_block_markbad_lowlevel to return success as long
as updating the BBT succeeds, if you think that this is the correct
approach.

> Is it that there are too many ECC errors and so when reading the block it
> is declared bad and the system tries to set the BBM/BBT bit? Or is it
> already marked bad somewhere and something silly happens which at
> some point tries to re-write the BBM?

I guess when programming the BBM fails with an error in the status
register the same probably happened when UBI tried to write data to the
block.

> Are you using fastmap? do you use a BBT?

Yes and yes. The fact that we use a BBT is why we want to set
NAND_BBT_NO_OOB_BBM.

Best regards,

  Daniel

-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke
Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner