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

[Kursad Oney <kursad.oney@xxxxxxxxxxxx>]

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.

> Thanks,
> Miquèl

Thanks!
Kursad

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