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

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Kursad Oney <kursad.oney@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 17:36:32 +0100	[thread overview]
Message-ID: <20200109173632.618fe684@xps13> (raw)
In-Reply-To: <CAMm8Nh0+BgomkSMrDHgzA5SkQZczp5CVAJefE79z=vfoPrui_Q@mail.gmail.com>

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/