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

[Miquel Raynal <miquel.raynal@xxxxxxxxxxx>]

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?

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?

Thanks,
Miquèl

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