* mtd: nand: mxc: oobfree layout? [not found] <1214095427.1646097.1353358014121.JavaMail.root@advansee.com> @ 2012-11-20 20:05 ` Benoît Thébaudeau 0 siblings, 0 replies; 4+ messages in thread From: Benoît Thébaudeau @ 2012-11-20 20:05 UTC (permalink / raw) To: Sascha Hauer Cc: Scott Wood, linux-mtd, David Woodhouse, Fabio Estevam, linux-arm-kernel Dear Sascha Hauer, I've seen in the history of mxc_nand.c that you have worked on the nand_ecclayout structs. The following things look abnormal. Can you confirm? - nandv1_hw_eccoob_smallpage and nandv2_hw_eccoob_smallpage: * Why are bytes 0 and 1 in oobfree? These bytes are used for bad block information on the 16-bit variants of these 512-byte-page NANDs. - nandv1_hw_eccoob_largepage: * According to the i.MX31 reference manual, the BI bytes of the spare area buffers are not free to use. So why are bytes 5, 11, 27, 43 and 59 in oobfree? On the contrary, if this note is a mistake in the RM, then why are bytes 21, 37 and 53 not in oobfree? - nandv2_hw_eccoob_smallpage, nandv2_hw_eccoob_largepage and nandv2_hw_eccoob_4k: * Why is byte 6 not in oobfree? Best regards, Benoît ^ permalink raw reply [flat|nested] 4+ messages in thread
* mtd: nand: mxc: oobfree layout? @ 2012-11-20 20:05 ` Benoît Thébaudeau 0 siblings, 0 replies; 4+ messages in thread From: Benoît Thébaudeau @ 2012-11-20 20:05 UTC (permalink / raw) To: linux-arm-kernel Dear Sascha Hauer, I've seen in the history of mxc_nand.c that you have worked on the nand_ecclayout structs. The following things look abnormal. Can you confirm? - nandv1_hw_eccoob_smallpage and nandv2_hw_eccoob_smallpage: * Why are bytes 0 and 1 in oobfree? These bytes are used for bad block information on the 16-bit variants of these 512-byte-page NANDs. - nandv1_hw_eccoob_largepage: * According to the i.MX31 reference manual, the BI bytes of the spare area buffers are not free to use. So why are bytes 5, 11, 27, 43 and 59 in oobfree? On the contrary, if this note is a mistake in the RM, then why are bytes 21, 37 and 53 not in oobfree? - nandv2_hw_eccoob_smallpage, nandv2_hw_eccoob_largepage and nandv2_hw_eccoob_4k: * Why is byte 6 not in oobfree? Best regards, Beno?t ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mtd: nand: mxc: oobfree layout? 2012-11-20 20:05 ` Benoît Thébaudeau @ 2012-11-21 9:25 ` Sascha Hauer -1 siblings, 0 replies; 4+ messages in thread From: Sascha Hauer @ 2012-11-21 9:25 UTC (permalink / raw) To: Benoît Thébaudeau Cc: Fabio Estevam, linux-mtd, Sascha Hauer, Scott Wood, David Woodhouse, linux-arm-kernel On Tue, Nov 20, 2012 at 09:05:18PM +0100, Benoît Thébaudeau wrote: > Dear Sascha Hauer, > > I've seen in the history of mxc_nand.c that you have worked on the > nand_ecclayout structs. The following things look abnormal. Can you confirm? > - nandv1_hw_eccoob_smallpage and nandv2_hw_eccoob_smallpage: > * Why are bytes 0 and 1 in oobfree? These bytes are used for bad block > information on the 16-bit variants of these 512-byte-page NANDs. This is probably a bug. Very few people seem to use 16bit flashes. > - nandv1_hw_eccoob_largepage: > * According to the i.MX31 reference manual, the BI bytes of the spare area > buffers are not free to use. So why are bytes 5, 11, 27, 43 and 59 in > oobfree? On the contrary, if this note is a mistake in the RM, then why > are bytes 21, 37 and 53 not in oobfree? > - nandv2_hw_eccoob_smallpage, nandv2_hw_eccoob_largepage and > nandv2_hw_eccoob_4k: > * Why is byte 6 not in oobfree? Probably bugs aswell. Most people do not use filesystems requiring OOB data anymore, so bugs may stay uncovered for longer. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 4+ messages in thread
* mtd: nand: mxc: oobfree layout? @ 2012-11-21 9:25 ` Sascha Hauer 0 siblings, 0 replies; 4+ messages in thread From: Sascha Hauer @ 2012-11-21 9:25 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 20, 2012 at 09:05:18PM +0100, Beno?t Th?baudeau wrote: > Dear Sascha Hauer, > > I've seen in the history of mxc_nand.c that you have worked on the > nand_ecclayout structs. The following things look abnormal. Can you confirm? > - nandv1_hw_eccoob_smallpage and nandv2_hw_eccoob_smallpage: > * Why are bytes 0 and 1 in oobfree? These bytes are used for bad block > information on the 16-bit variants of these 512-byte-page NANDs. This is probably a bug. Very few people seem to use 16bit flashes. > - nandv1_hw_eccoob_largepage: > * According to the i.MX31 reference manual, the BI bytes of the spare area > buffers are not free to use. So why are bytes 5, 11, 27, 43 and 59 in > oobfree? On the contrary, if this note is a mistake in the RM, then why > are bytes 21, 37 and 53 not in oobfree? > - nandv2_hw_eccoob_smallpage, nandv2_hw_eccoob_largepage and > nandv2_hw_eccoob_4k: > * Why is byte 6 not in oobfree? Probably bugs aswell. Most people do not use filesystems requiring OOB data anymore, so bugs may stay uncovered for longer. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-11-21 9:25 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1214095427.1646097.1353358014121.JavaMail.root@advansee.com>
2012-11-20 20:05 ` mtd: nand: mxc: oobfree layout? Benoît Thébaudeau
2012-11-20 20:05 ` Benoît Thébaudeau
2012-11-21 9:25 ` Sascha Hauer
2012-11-21 9:25 ` Sascha Hauer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.