[U-Boot] AT91: NAND OOB and ECC in U-Boot vs Linux
The AT91 Linux kernel patches for versions 2.6.27 or later use a separate atmel_nand.c driver that implements some OOB and ECC options that are not exactly the same as those in the standard kernel NAND driver (nand_base.c , etc.). AT91 based boards can use the CONFIG_MTD_NAND_ATMEL option to enable the atmel_nand driver together with CONFIG_MTD_NAND_ATMEL_ECC_HW, CONFIG_MTD_NAND_ATMEL_ECC_SOFT or CONFIG_MTD_NAND_ATMEL_ECC_NONE for the desired ECC. The OOB layout used by that driver appears to be different.
The NAND support in U-Boot appears to be based on the standard kernel NAND driver without the atmel_nand driver options.
Could this create the potential for incompatibilities when a NAND filesystem is created by U-Boot for mounting from a Linux kernel using the atmel_nand driver? Are there any kernel config options to avoid to make filesystems initialized with the U-Boot "nand write.jffs2" command fully compatible with the kernel MTD NAND drivers?
Thanks, Jesus Alvarez
On 22:41 Tue 17 Mar , Jesus Alvarez wrote:
The AT91 Linux kernel patches for versions 2.6.27 or later use a separate atmel_nand.c driver that implements some OOB and ECC options that are not exactly the same as those in the standard kernel NAND driver (nand_base.c , etc.). AT91 based boards can use the CONFIG_MTD_NAND_ATMEL option to enable the atmel_nand driver together with CONFIG_MTD_NAND_ATMEL_ECC_HW, CONFIG_MTD_NAND_ATMEL_ECC_SOFT or CONFIG_MTD_NAND_ATMEL_ECC_NONE for the desired ECC. The OOB layout used by that driver appears to be different.
The NAND support in U-Boot appears to be based on the standard kernel NAND driver without the atmel_nand driver options.
Could this create the potential for incompatibilities when a NAND filesystem is created by U-Boot for mounting from a Linux kernel using the atmel_nand driver? Are there any kernel config options to avoid to make filesystems initialized with the U-Boot "nand write.jffs2" command fully compatible with the kernel MTD NAND drivers?
yes if they do not use the same ECC algo they will see the data corrupted and they will try to fix it
Best Regards, J.
yes if they do not use the same ECC algo they will see the data corrupted and they will try to fix it
Thanks for your response. Yet I could not find CONFIG_ options in U-Boot equivalent to the atmel_nand options in the kernel. It seems like the U-Boot NAND writes and the kernel NAND writes (when CONFIG_MTD_NAND_ATMEL is selected) will use different logic for ECC and OOB layout.
Should the U-Boot "nand write.jffs2" command be avoided with AT91 targets using post-2.6.27 kernels? Or are there U-Boot CONFIG_ options compatible with the atmel_nand options in the current kernels?
Regards, Jesus Alvarez
Jesus Alvarez <jalvarez <at> micromint.com> writes:
The AT91 Linux kernel patches for versions 2.6.27 or later use a separate atmel_nand.c driver that implements some OOB and ECC options that are not exactly the same as those in the standard kernel NAND driver (nand_base.c , etc.). AT91 based boards can use the CONFIG_MTD_NAND_ATMEL option to enable the atmel_nand driver together with CONFIG_MTD_NAND_ATMEL_ECC_HW, CONFIG_MTD_NAND_ATMEL_ECC_SOFT or CONFIG_MTD_NAND_ATMEL_ECC_NONE for the desired ECC. The OOB layout used by that driver appears to be different.
CONFIG_MTD_NAND_ATMEL_ECC_SOFT is fully compatible with u-boot management of NAND flash. Indeed CONFIG_MTD_NAND_ATMEL_ECC_HW uses a different layout of OOB (ecc just after data, at bad block notification location). If you use this option in Linux, you will have to make sure that u-boot supports it.
Regards,
participants (3)
-
Jean-Christophe PLAGNIOL-VILLARD -
Jesus Alvarez -
Nicolas Ferre