* 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.