Re: Number of bytes for spi-nand bad block marker

[Miquel Raynal <miquel.raynal@xxxxxxxxxxx>]

Hi Kursad,

Kursad Oney <kursad.oney@xxxxxxxxxxxx> 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@xxxxxxxxxxx> wrote:
> >
> > Hi Kursad,
> >
> > Kursad Oney <kursad.oney@xxxxxxxxxxxx> 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

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