Number of bytes for spi-nand bad block marker

Miquel Raynal miquel.raynal at bootlin.com
Thu Jan 9 09:52:18 PST 2020


Hi Kursad,

Kursad Oney <kursad.oney at broadcom.com> wrote on Thu, 9 Jan 2020
12:49:00 -0500:

> Hi Miquèl,
> 
> On Thu, Jan 9, 2020 at 11:36 AM Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> >
> > Hi Kursad,
> >
> > Kursad Oney <kursad.oney at broadcom.com> wrote on Mon, 12 Aug 2019
> > 16:24:57 -0400:
> >  
> > > Hi,
> > >
> > > The spi-nand driver in both linux and u-boot check 2 bytes for bad
> > > block markers in spinand_isbad(). However, the datasheet for
> > > W25N01GVxxIG says 'A “Bad Block Marker” is a non-FFh data byte stored
> > > at Byte 0 of Page 0 for each bad block. An additional marker is also
> > > stored in the first byte of the 64-Byte spare area.' which is
> > > basically one byte for BBM in spare.
> > >
> > > Boris says they have used the same pattern for parallel NAND because
> > > some NANDs are interfaces through a 16-bit bus.
> > >
> > > Here is the situation I am facing: We rolled our own own spi-nand
> > > kernel/bootloader drivers before the kernel spi-nand driver was
> > > integrated, and set BBM size to 1 byte for this type of flash. This
> > > means the 2nd byte is available for use. Some devices in the field
> > > utilize the extra byte for the jffs2 clean marker.
> > >
> > > We would like to migrate to the mainline drivers but this presents an
> > > issue. When we flash an image with the mainline u-boot spi-nand
> > > driver, it thinks the cleaned jffs2 blocks are "bad blocks" since one
> > > of the bytes includes the clean marker.
> > >
> > > Marek suggested we do a one-time upgrade script where we rewrite the
> > > OOB but it's a risky operation, especially in the field. Boris asked
> > > me to email the MTD list and continue the discussion here. I
> > > appreciate any opinions/suggestions.  
> >
> > Sorry for the very very late reply.
> >
> > How did you manage this situation?
> >  
> 
> No problem with the late reply. I am adding David Regan on copy who is
> more familiar with our SPI-NAND driver and the plans going forward.
> 
> > As you have a very specific need which is not actually related to
> > hardware support but more a problem of coherence between your old
> > drivers and mainline, what about writing support for 1-byte BBM in
> > spi-nand? If it is too invasive I don't think it can be mainlined, but
> > at least you could use a mainline driver with a small change on top of
> > it on your old-running in-the-field boards?
> >  
> 
> Yes, exactly. I think this might be the way we will go forward. As for
> mainlining, there were questions about whether this is something that
> can/should be done in the device tree or as a Kconfig or some other
> way. If there is an acceptable solution, we can implement and send it
> for a review.

I don't know what would be the "less worse". Maybe it won't be mainline
at all. But you can share as an RFC what you've done, that might help
others!

Thanks,
Miquèl



More information about the linux-mtd mailing list