From: Kursad Oney <kursad.oney@broadcom.com>
To: linux-mtd@lists.infradead.org
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
Boris Brezillon <bbrezillon@kernel.org>,
Richard Weinberger <richard@nod.at>,
Marek Vasut <marek.vasut@gmail.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Number of bytes for spi-nand bad block marker
Date: Mon, 12 Aug 2019 16:24:57 -0400 [thread overview]
Message-ID: <CAMm8Nh0+BgomkSMrDHgzA5SkQZczp5CVAJefE79z=vfoPrui_Q@mail.gmail.com> (raw)
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/
next reply other threads:[~2019-08-12 20:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-12 20:24 Kursad Oney [this message]
2020-01-09 16:36 ` Number of bytes for spi-nand bad block marker Miquel Raynal
2020-01-09 17:49 ` Kursad Oney
2020-01-09 17:52 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMm8Nh0+BgomkSMrDHgzA5SkQZczp5CVAJefE79z=vfoPrui_Q@mail.gmail.com' \
--to=kursad.oney@broadcom.com \
--cc=bbrezillon@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).