Number of bytes for spi-nand bad block marker

Number of bytes for spi-nand bad block marker

[Kursad Oney]

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.

Thanks!
kursad

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

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

[Miquel Raynal]

Hi Kursad,

Kursad Oney <kursad.oney@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?

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/

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

[Kursad Oney]

Hi Miquèl,

On Thu, Jan 9, 2020 at 11:36 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Kursad,
>
> Kursad Oney <kursad.oney@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.

> Thanks,
> Miquèl

Thanks!
Kursad

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

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

[Miquel Raynal]

Hi Kursad,

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

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