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

From: Kursad Oney <kursad.oney@broadcom.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	David Regan <david.regan@broadcom.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: Number of bytes for spi-nand bad block marker
Date: Thu, 9 Jan 2020 12:49:00 -0500	[thread overview]
Message-ID: <CAMm8Nh3dccj9iAQvHhXbRcO22ROhoSmQ48bFqCC80+NiBXoTDA@mail.gmail.com> (raw)
In-Reply-To: <20200109173632.618fe684@xps13>

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/