* Number of bytes for spi-nand bad block marker @ 2019-08-12 20:24 Kursad Oney 2020-01-09 16:36 ` Miquel Raynal 0 siblings, 1 reply; 4+ messages in thread From: Kursad Oney @ 2019-08-12 20:24 UTC (permalink / raw) To: linux-mtd Cc: Vignesh Raghavendra, Boris Brezillon, Richard Weinberger, Marek Vasut, Miquel Raynal, Brian Norris, David Woodhouse 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Number of bytes for spi-nand bad block marker 2019-08-12 20:24 Number of bytes for spi-nand bad block marker Kursad Oney @ 2020-01-09 16:36 ` Miquel Raynal 2020-01-09 17:49 ` Kursad Oney 0 siblings, 1 reply; 4+ messages in thread From: Miquel Raynal @ 2020-01-09 16:36 UTC (permalink / raw) To: Kursad Oney Cc: Vignesh Raghavendra, Boris Brezillon, Richard Weinberger, Marek Vasut, linux-mtd, Brian Norris, David Woodhouse 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Number of bytes for spi-nand bad block marker 2020-01-09 16:36 ` Miquel Raynal @ 2020-01-09 17:49 ` Kursad Oney 2020-01-09 17:52 ` Miquel Raynal 0 siblings, 1 reply; 4+ messages in thread From: Kursad Oney @ 2020-01-09 17:49 UTC (permalink / raw) To: Miquel Raynal, David Regan Cc: Vignesh Raghavendra, Boris Brezillon, Richard Weinberger, Marek Vasut, linux-mtd, Brian Norris, David Woodhouse 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Number of bytes for spi-nand bad block marker 2020-01-09 17:49 ` Kursad Oney @ 2020-01-09 17:52 ` Miquel Raynal 0 siblings, 0 replies; 4+ messages in thread From: Miquel Raynal @ 2020-01-09 17:52 UTC (permalink / raw) To: Kursad Oney Cc: Vignesh Raghavendra, Boris Brezillon, Richard Weinberger, Marek Vasut, linux-mtd, Brian Norris, David Woodhouse, David Regan 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-09 17:52 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-12 20:24 Number of bytes for spi-nand bad block marker Kursad Oney 2020-01-09 16:36 ` Miquel Raynal 2020-01-09 17:49 ` Kursad Oney 2020-01-09 17:52 ` Miquel Raynal
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).