Skip to contentSkip to conversation

Bad ecc layout in drivers/mtd/nand/spi/xtx.c

RFC Lothar Waßmann 2 participants 2 messages Jul 4, 2023 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

Hi,

while trying to add support for the 'XT26G01C' variant of the XTX SPI-nand chip I noticed a flaw in the ECC layout of the existing driver.
According to the XT26G01A datasheet the first eight bytes of the OOB area are not protected by ECC:

Offset      ECC  Bytes  Area               Description
800H 807H    No      8  Spare 4, Group E   This Area is not covered by internal ECC,

800H is reserved for bad block mark
808H 82FH Yes 40 Spare 5 , Group F User Meta Data Area covered by internal ECC.
830H 83FH No 16 Spare 6 , Group G ECC_EN=1: this area contains Internal ECC Data, Read-Only,
Programming to this area will be ignored ECC_EN=0: this area is writable for user

But the driver defines bytes 1..47 as user OOB area:

|static int xt26g0xa_ooblayout_free(struct mtd_info *mtd, int section,
|				   struct mtd_oob_region *region)
|{
|	if (section)
|		return -ERANGE;
|
|	region->offset = 1;
|	region->length = 47;
|
|	return 0;
|}

IMO this should be:
| region->offset = 8;
| region->length = 40;
to have the whole user oob area protected by ECC.

Obviously this cannot simply be changed in the driver because it would break access to flash that was programmed with the current parameters. Since the data structures that provide the oob layout are completely static and cannot be modified at runtime (e.g. depending on some DTB property) the only way I see to provide a layout with ECC protection for the whole user metadata would be a Kconfig option to select one or the other layout at compile time.

Any comments or better ideas?

Lothar Waßmann

Signature · 13 lines
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | [email protected]
___________________________________________________________

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
maintainer
#1 lore raw

Hi Lothar,

Thanks for the report.

[email protected] wrote on Tue, 4 Jul 2023 12:37:43 +0200:

Quoted 41 lines

Hi,

while trying to add support for the 'XT26G01C' variant of the XTX SPI-nand chip I noticed a flaw in the ECC layout of the existing driver.
According to the XT26G01A datasheet the first eight bytes of the OOB area are not protected by ECC:

Offset      ECC  Bytes  Area               Description
800H 807H    No      8  Spare 4, Group E   This Area is not covered by internal ECC,

800H is reserved for bad block mark
808H 82FH Yes 40 Spare 5 , Group F User Meta Data Area covered by internal ECC.
830H 83FH No 16 Spare 6 , Group G ECC_EN=1: this area contains Internal ECC Data, Read-Only,
Programming to this area will be ignored ECC_EN=0: this area is writable for user

But the driver defines bytes 1..47 as user OOB area:

|static int xt26g0xa_ooblayout_free(struct mtd_info *mtd, int section,
|				   struct mtd_oob_region *region)
|{
|	if (section)
|		return -ERANGE;
|
|	region->offset = 1;
|	region->length = 47;
|
|	return 0;
|}

IMO this should be:
| region->offset = 8;
| region->length = 40;
to have the whole user oob area protected by ECC.

Obviously this cannot simply be changed in the driver because it would break access to flash that was programmed with the current parameters. Since the data structures that provide the oob layout are completely static and cannot be modified at runtime (e.g. depending on some DTB property) the only way I see to provide a layout with ECC protection for the whole user metadata would be a Kconfig option to select one or the other layout at compile time.

Quoted 1 line

Any comments or better ideas?

These offsets do not reflect the protected area but the user area, which can be used (at the users own risks). Somehow the only real user is jffs2 upstream, and jffs2 was meant to be replaced a long time ago by UBI which actually workaround-ed this limitation by not using the OOB area at all. We do not have a real way to distinguish what is ECC protected or not in the OOB area.

So unless you want to solve a real problem, I would advise to keep it as it is.

Thanks,
Miquèl