Re: Make NAND_BBT_NO_OOB_BBM configurable or let the gpmi driver decide?

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Daniel Glöckner" <dg@emlix.com>
Cc: "Han Xu" <han.xu@nxp.com>,
	linux-mtd@lists.infradead.org,
	"Lothar Waßmann" <LW@KARO-electronics.de>,
	"Brian Norris" <computersforpeace@gmail.com>
Subject: Re: Make NAND_BBT_NO_OOB_BBM configurable or let the gpmi driver decide?
Date: Thu, 24 Feb 2022 17:03:57 +0100	[thread overview]
Message-ID: <20220224170357.1f99a77a@xps13> (raw)
In-Reply-To: <0a5497bf-7716-e8c8-7e79-7df6602d5104@emlix.com>

Hi Daniel,

dg@emlix.com wrote on Thu, 24 Feb 2022 16:55:27 +0100:

> Am 24.02.22 um 16:29 schrieb Miquel Raynal:
> > dg@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? 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?

Are you using fastmap? do you use a BBT?

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/