Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On Mon, 2013-12-02 at 17:05 +, Gupta, Pekon wrote: (2) Also selection of ecc-scheme mainly depends on NAND device parameter (like density, page-size, oobsize) which remain constant for a device (all NAND partitions). Thus all partitions should use *same* ecc-scheme preferable highest possible available with NAND device kernel. It was pointed out earlier in the thread that there are chips for which it is not constant throughout the device (i.e. the boot block is special, presumably implemented differently in hardware). (3) Kernel uses same driver instance to handle all MTD partitions, so if one partition uses HAM1 while other uses BCH8, and both are simultaneously mounted, then it would be difficult for driver to switch ecc-schemes while doing interleaved Read/Write between the partitions. (though it can be added in framework, but then it's too much over-head). Don't think of it as switching back and forth for every access, but rather having dynamic dispatch to the proper code for any given access. I'm not sure that partitions are the right place to implement this, as they're a higher level abstraction. If the NAND chip says that 1-bit correction is good enough for certain blocks but not others, then that's chip-level information that the driver ought to know about independently of partitioning. OTOH, that doesn't provide the ability to manage compatibility with entities that use stronger correction than is needed (or different ways of achieving the same level of correction), but it could be a simpler way to solve the basic problem of boot blocks being special. -Scott -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Javier Martinez Canillas, On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 525e6d9..9043e97 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -59,7 +59,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; Tested this with 3.13-rc1, and it somewhat works, but causes some ECC error messages: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 10.423736] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 10.444671] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 10.472290] jffs2: mtd-read(0x100 bytes from 0x4) returned ECC error [ 10.480743] jffs2: mtd-read(0x100 bytes from 0x6) returned ECC error [ 10.489013] jffs2: mtd-read(0x100 bytes from 0x8) returned ECC error [ 10.497283] jffs2: mtd-read(0x100 bytes from 0xa) returned ECC error [ 10.505126] jffs2: mtd-read(0x100 bytes from 0xc) returned ECC error [ 10.513458] jffs2: mtd-read(0x100 bytes from 0xe) returned ECC error [ 10.521667] jffs2: mtd-read(0x100 bytes from 0x10) returned ECC error [ 10.529968] jffs2: mtd-read(0x100 bytes from 0x12) returned ECC error [ 10.538269] jffs2: mtd-read(0x100 bytes from 0x14) returned ECC error [ 10.546295] jffs2: mtd-read(0x100 bytes from 0x16) returned ECC error [ 10.554534] jffs2: mtd-read(0x100 bytes from 0x18) returned ECC error [ 10.563323] jffs2: mtd-read(0x100 bytes from 0x1a) returned ECC error [ 10.571685] jffs2: mtd-read(0x100 bytes from 0x1c) returned ECC error [ 10.579986] jffs2: mtd-read(0x100 bytes from 0x1e) returned ECC error [ 10.588287] jffs2: mtd-read(0x100 bytes from 0x20) returned ECC error [ 10.596313] jffs2: mtd-read(0x100 bytes from 0x22) returned ECC error [ 10.604522] jffs2: mtd-read(0x100 bytes from 0x24) returned ECC error [ 10.613037] jffs2: mtd-read(0x100 bytes from 0x26) returned ECC error [ 10.621307] jffs2: mtd-read(0x100 bytes from 0x28) returned ECC error [ 10.629608] jffs2: mtd-read(0x100 bytes from 0x2a) returned ECC error [ 10.637908] jffs2: mtd-read(0x100 bytes from 0x2c) returned ECC error [ 10.645843] jffs2: mtd-read(0x100 bytes from 0x2e) returned ECC error [ 10.654113] jffs2: notice: (851) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # # # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK This is with a JFFS2 image flashed after doing nandecc sw in U-Boot. Just a note that this binding property got renamed for v3.13 on commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc Author: Pekon Gupta pe...@ti.com Date: Thu Oct 24 18:20:18 2013 +0530 mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes so users using current v3.12 kernel or older should use ti,nand-ecc-opt = sw; instead. However, this works perfectly fine, with the same JFFS2 image, flashed in the same way in U-Boot: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 19.789306] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 19.810455] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 19.850860] jffs2: notice: (802) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi, CCing Pekon Gupta pe...@ti.com 2013/12/2 Thomas Petazzoni thomas.petazz...@free-electrons.com: Dear Javier Martinez Canillas, On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 525e6d9..9043e97 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -59,7 +59,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; Tested this with 3.13-rc1, and it somewhat works, but causes some ECC error messages: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 10.423736] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 10.444671] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 10.472290] jffs2: mtd-read(0x100 bytes from 0x4) returned ECC error [ 10.480743] jffs2: mtd-read(0x100 bytes from 0x6) returned ECC error [ 10.489013] jffs2: mtd-read(0x100 bytes from 0x8) returned ECC error [ 10.497283] jffs2: mtd-read(0x100 bytes from 0xa) returned ECC error [ 10.505126] jffs2: mtd-read(0x100 bytes from 0xc) returned ECC error [ 10.513458] jffs2: mtd-read(0x100 bytes from 0xe) returned ECC error [ 10.521667] jffs2: mtd-read(0x100 bytes from 0x10) returned ECC error [ 10.529968] jffs2: mtd-read(0x100 bytes from 0x12) returned ECC error [ 10.538269] jffs2: mtd-read(0x100 bytes from 0x14) returned ECC error [ 10.546295] jffs2: mtd-read(0x100 bytes from 0x16) returned ECC error [ 10.554534] jffs2: mtd-read(0x100 bytes from 0x18) returned ECC error [ 10.563323] jffs2: mtd-read(0x100 bytes from 0x1a) returned ECC error [ 10.571685] jffs2: mtd-read(0x100 bytes from 0x1c) returned ECC error [ 10.579986] jffs2: mtd-read(0x100 bytes from 0x1e) returned ECC error [ 10.588287] jffs2: mtd-read(0x100 bytes from 0x20) returned ECC error [ 10.596313] jffs2: mtd-read(0x100 bytes from 0x22) returned ECC error [ 10.604522] jffs2: mtd-read(0x100 bytes from 0x24) returned ECC error [ 10.613037] jffs2: mtd-read(0x100 bytes from 0x26) returned ECC error [ 10.621307] jffs2: mtd-read(0x100 bytes from 0x28) returned ECC error [ 10.629608] jffs2: mtd-read(0x100 bytes from 0x2a) returned ECC error [ 10.637908] jffs2: mtd-read(0x100 bytes from 0x2c) returned ECC error [ 10.645843] jffs2: mtd-read(0x100 bytes from 0x2e) returned ECC error [ 10.654113] jffs2: notice: (851) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # # # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK This is with a JFFS2 image flashed after doing nandecc sw in U-Boot. Just a note that this binding property got renamed for v3.13 on commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc Author: Pekon Gupta pe...@ti.com Date: Thu Oct 24 18:20:18 2013 +0530 mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes so users using current v3.12 kernel or older should use ti,nand-ecc-opt = sw; instead. However, this works perfectly fine, with the same JFFS2 image, flashed in the same way in U-Boot: Pekon, the old ti,nand-ecc-opt = sw should be replaced by ti,nand-ecc-opt = ham1 ? Should be the same ? In that case, why this different behavior ? # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 19.789306] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 19.810455] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 19.850860] jffs2: notice: (802) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK Best regards, Thomas -- Thomas Petazzoni, CTO, Free
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi, From: Enric Balletbo Serra [mailto:eballe...@gmail.com] CCing Pekon Gupta pe...@ti.com 2013/12/2 Thomas Petazzoni thomas.petazz...@free-electrons.com: Dear Javier Martinez Canillas, On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). [...] Pekon, the old ti,nand-ecc-opt = sw should be replaced by ti,nand-ecc-opt = ham1 ? Should be the same ? In that case, why this different behavior ? In addition, please use HAM1 ecc-scheme on mainline u-boot also to flash. (following patches were accepted by domain maintainer 'Scott Woods'). http://lists.denx.de/pipermail/u-boot/2013-November/167548.html So, Kernel ham1 and u-boot ham1 should be in sync.. Once above is clean, you may like to pull another set of patches below (these are kernel equivalent of driver optimization for u-boot driver) http://lists.denx.de/pipermail/u-boot/2013-November/167445.html Also, for JFFS2, please erase the flash using -j option. '-j' option adds a clean marker to erased blocks. with regards, pekon
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Gupta, Pekon, On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote: A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). The crucial point here is that the interaction between the bootloader and the kernel. The use case I have is that I'm flashing a filesystem image from the bootloader, and mounting it from the kernel. Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in legacy mode (no Device Tree) works fine. Using the same 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, because the kernel disagrees with the bootloader on the ECC scheme to use. So I'm not saying that Hamming is better than BCH, certainly not. I'm just saying that changing ECC scheme in the kernel without looking at the more global picture of what support the bootloaders are offering is not nice. At least, the bootloader should provide a command, or option, to be able to use an ECC scheme that is compatible with what the kernel expects. The current result is that booting a mainline kernel with DT on existing bootloaders simply breaks existing configurations. Pekon, the old ti,nand-ecc-opt = sw should be replaced by ti,nand-ecc-opt = ham1 ? Should be the same ? In that case, why this different behavior ? In addition, please use HAM1 ecc-scheme on mainline u-boot also to flash. (following patches were accepted by domain maintainer 'Scott Woods'). http://lists.denx.de/pipermail/u-boot/2013-November/167548.html So, Kernel ham1 and u-boot ham1 should be in sync.. Once above is clean, you may like to pull another set of patches below (these are kernel equivalent of driver optimization for u-boot driver) http://lists.denx.de/pipermail/u-boot/2013-November/167445.html Also, for JFFS2, please erase the flash using -j option. '-j' option adds a clean marker to erased blocks. As said, I'm erasing/flashing from U-Boot, so flash_eraseall options are not really useful here :) Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote: A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). The crucial point here is that the interaction between the bootloader and the kernel. The use case I have is that I'm flashing a filesystem image from the bootloader, and mounting it from the kernel. Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in legacy mode (no Device Tree) works fine. Using the same 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, because the kernel disagrees with the bootloader on the ECC scheme to use. So I'm not saying that Hamming is better than BCH, certainly not. I'm just saying that changing ECC scheme in the kernel without looking at the more global picture of what support the bootloaders are offering is not nice. At least, the bootloader should provide a command, or option, to be able to use an ECC scheme that is compatible with what the kernel expects. Yes, there is a way to change ecc-scheme in u-boot.. Also, you can modify to any ecc-scheme in u-boot using CONFIG_NAND_OMAP_ECCSCHEME as documented in doc/README.nand Also your board should boot seamlessly from mainline u-boot in sync with mainline kernel. As per my knowledge following patch is already in mainline u-boot. And touches your board as well. (omap3_igep00x0.h) http://lists.denx.de/pipermail/u-boot/2013-November/167550.html AFAIK these patches should be in u-boot mainline. Though I have taken at-most care that no existing board should break. But, I'm sorry if there is something broken in between the u-boot and Kernel builds. Let me know if I can help in fixing that somehow. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi all, 2013/12/2 Gupta, Pekon pe...@ti.com: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote: A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). The crucial point here is that the interaction between the bootloader and the kernel. The use case I have is that I'm flashing a filesystem image from the bootloader, and mounting it from the kernel. Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in legacy mode (no Device Tree) works fine. Using the same 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, because the kernel disagrees with the bootloader on the ECC scheme to use. So I'm not saying that Hamming is better than BCH, certainly not. I'm just saying that changing ECC scheme in the kernel without looking at the more global picture of what support the bootloaders are offering is not nice. At least, the bootloader should provide a command, or option, to be able to use an ECC scheme that is compatible with what the kernel expects. Yes, there is a way to change ecc-scheme in u-boot.. Also, you can modify to any ecc-scheme in u-boot using CONFIG_NAND_OMAP_ECCSCHEME as documented in doc/README.nand Also your board should boot seamlessly from mainline u-boot in sync with mainline kernel. As per my knowledge following patch is already in mainline u-boot. And touches your board as well. (omap3_igep00x0.h) http://lists.denx.de/pipermail/u-boot/2013-November/167550.html AFAIK these patches should be in u-boot mainline. Though I have taken at-most care that no existing board should break. But, I'm sorry if there is something broken in between the u-boot and Kernel builds. Let me know if I can help in fixing that somehow. with regards, pekon Thanks for the explanations to all. Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. Best regards, Enric -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Enric Balletbo Serra, On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote: Thanks for the explanations to all. Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 10:51 AM, Thomas Petazzoni wrote: Dear Enric Balletbo Serra, On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote: Thanks for the explanations to all. Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Tom Rini, On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Of course, ideally, we should also be able to tell the kernel about the ECC scheme on a per-partition basis. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Which as I was saying, is a bit of shame. There is technically nothing that makes the ECC scheme something that needs to be applied globally on the entire flash. And we see real practical cases where being able to specify a different ECC scheme per partition would make sense: when the ROM code uses a weaker ECC scheme than the one used for most other partitions. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 11:13 AM, Gupta, Pekon wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. Right, on OMAP3 (and related) we have the issue of ROM only doing 1bit ECC, but being used with parts that require more, so what I said above is important. OMAP4/am335x/later ship with ROM that groks at least BCH16. With my U-Boot hat on, I really don't want to encourage people to come up with designs that require on the fly switching because.. But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Exactly. The kernel hasn't, and I get the feeling won't, support this case of needing different ECC schemes for different areas of the NAND, so we'll continue to be in the position of the Linux for flashing everything but bootloader or custom hacks to the kernel. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? By the way, a couple of years ago we wrote a small user-space utility to write the SPL from Linux when a different ECC scheme than the 1-bit hamming understand by the Boot ROM is used. The writeloader [0] utility access the NAND mtd partition as raw and manually writes the ECC in the OOB using the MTD_MODE_RAW and MEMWRITEOOB ioctls. So with minor hacks, you should be able to bring-back 'nandecc'. But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. with regards, pekon Best regards, Javier [0]: http://git.isee.biz/?p=pub/scm/writeloader.git -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? We (I) had killed off all of the mainline users of the nandecc command, once everyone was using the same 1bit scheme layout. None of the people that had mixed HAM1/BCH4 at the time wanted to work upstream on it. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini tr...@ti.com wrote: On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? We (I) had killed off all of the mainline users of the nandecc command, once everyone was using the same 1bit scheme layout. None of the people that had mixed HAM1/BCH4 at the time wanted to work upstream on it. I see, so.. what's the solution then :-) We can push Enric's patch and change to HAM1 in the kernel so Thomas (and others) can write everything from U-boot (SPL, rootfs, etc) but I think is safer to use BCH8 since the NAND requires at least a 4-bit ECC. But doing that we can no longer write the SPL from neither U-Boot nor the kernel. Yes, this can be made from user-space using ISEE's writeloader utility and afair there is one from TI too written in C# but this is not very convenient for users. I believe Thomas is right and the correct approach is to change the OMAP NAND and GPMC drivers to support a per MTD partition ECC scheme but we need a temporal solution until someone implements this. -- Tom Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 11:46 AM, Javier Martinez Canillas wrote: On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini tr...@ti.com wrote: On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? We (I) had killed off all of the mainline users of the nandecc command, once everyone was using the same 1bit scheme layout. None of the people that had mixed HAM1/BCH4 at the time wanted to work upstream on it. I see, so.. what's the solution then :-) We can push Enric's patch and change to HAM1 in the kernel so Thomas (and others) can write everything from U-boot (SPL, rootfs, etc) but I think is safer to use BCH8 since the NAND requires at least a 4-bit ECC. We _need_ to bring this back in U-Boot (so please just link to this thread somewhere in the patch that brings the command back), for omap3/etc at least. But doing that we can no longer write the SPL from neither U-Boot nor the kernel. Yes, this can be made from user-space using ISEE's writeloader utility and afair there is one from TI too written in C# but this is not very convenient for users. I believe Thomas is right and the correct approach is to change the OMAP NAND and GPMC drivers to support a per MTD partition ECC scheme but we need a temporal solution until someone implements this. I would argue that yes, Linux should also support on the fly ECC schemes per partition (with some sort of default too, so you can say everything is BCH_X except ..). But I'm not one of the people that needs to be convinced of this, and I assume there was a thread about this problem from before, so someone should dig it up and avoid / address the problems from before, or at least try and re-start the discussion and see if people have changed there mind as the problem is here again, and if we ignore it again will show up again in 5 years when we need BCH16 on the bootloader part, but BCH64 on the rest of the block. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? Yes, agree .. But this is only because we have mis-match in ecc-scheme between ROM-code (while reading SPL) v/s rest of system. However, if you continue using 'HAM1' for *both* u-boot and kernel you should not face any issue. And with latest patch on u-boot your board file should also remain unchanged. [...] But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Which as I was saying, is a bit of shame. There is technically nothing that makes the ECC scheme something that needs to be applied globally on the entire flash. No, I don't think that kernel needs to ever dynamically switch ecc-schemes. This feature should be limited only to u-boot (or bootloaders) because: (1) Adding support for dynamic switching of ecc-schemes will require all code to be compiled in driver which increases the kernel driver footprint. (example adding BCH8_SW means you need to compile in lib/bch.c) (2) Also selection of ecc-scheme mainly depends on NAND device parameter (like density, page-size, oobsize) which remain constant for a device (all NAND partitions). Thus all partitions should use *same* ecc-scheme preferable highest possible available with NAND device kernel. (3) Kernel uses same driver instance to handle all MTD partitions, so if one partition uses HAM1 while other uses BCH8, and both are simultaneously mounted, then it would be difficult for driver to switch ecc-schemes while doing interleaved Read/Write between the partitions. (though it can be added in framework, but then it's too much over-head). In my opinion, kernel driver should be free from all over-heads, And should be *as lite as possible, while continuing to be strong in catching bit-flips.* Because there are lot of file-system layers over it, to handle more severe failures. Example: even if you use HAM1 and report un-correctable errors, still UBIFS has too much redundancy of critical metadata, that it can still recover your volume. Therefore, I preferred having ecc-scheme selectable via DT (static) for kernel. However these are purely my opinions based on my assessments. And we see real practical cases where being able to specify a different ECC scheme per partition would make sense: when the ROM code uses a weaker ECC scheme than the one used for most other partitions. This constrain of changing ecc-scheme has come because ROM code ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders) is used to between bridge gaps between ROM code and kernel. - This could have been avoided, if u-boot still supported 'nandecc' OR - ROM code had mechanism to change its ecc-scheme based on some Boot-mode setting (sysboot pins on board). So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi Pekon On Mon, Dec 2, 2013 at 6:05 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? Yes, agree .. But this is only because we have mis-match in ecc-scheme between ROM-code (while reading SPL) v/s rest of system. However, if you continue using 'HAM1' for *both* u-boot and kernel you should not face any issue. And with latest patch on u-boot your board file should also remain unchanged. [...] But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Which as I was saying, is a bit of shame. There is technically nothing that makes the ECC scheme something that needs to be applied globally on the entire flash. No, I don't think that kernel needs to ever dynamically switch ecc-schemes. This feature should be limited only to u-boot (or bootloaders) because: I don't think so. There are cpu that can be boot only using some ecc scheme but for a lot of reason you should require to have for the filesystem a different ecc scheme (1) Adding support for dynamic switching of ecc-schemes will require all code to be compiled in driver which increases the kernel driver footprint. (example adding BCH8_SW means you need to compile in lib/bch.c) It depends on the system that you are using and sometime increase the kernel size is less important that guarantee system consistency (2) Also selection of ecc-scheme mainly depends on NAND device parameter (like density, page-size, oobsize) which remain constant for a device (all NAND partitions). Thus all partitions should use *same* ecc-scheme preferable highest possible available with NAND device kernel. same as above. It can be a limitation on the bootrom (3) Kernel uses same driver instance to handle all MTD partitions, so if one partition uses HAM1 while other uses BCH8, and both are simultaneously mounted, then it would be difficult for driver to switch ecc-schemes while doing interleaved Read/Write between the partitions. (though it can be added in framework, but then it's too much over-head). agree Michael In my opinion, kernel driver should be free from all over-heads, And should be *as lite as possible, while continuing to be strong in catching bit-flips.* Because there are lot of file-system layers over it, to handle more severe failures. Example: even if you use HAM1 and report un-correctable errors, still UBIFS has too much redundancy of critical metadata, that it can still recover your volume. Therefore, I preferred having ecc-scheme selectable via DT (static) for kernel. However these are purely my opinions based on my assessments. And we see real practical cases where being able to specify a different ECC scheme per partition would make sense: when the ROM code uses a weaker ECC scheme than the one used for most other partitions. This constrain of changing ecc-scheme has come because ROM code ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders) is used to between bridge gaps between ROM code and kernel. - This could have been avoided, if u-boot still supported 'nandecc' OR - ROM code had mechanism to change its ecc-scheme based on some Boot-mode setting (sysboot pins on board). So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 12:05 PM, Gupta, Pekon wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? Yes, agree .. But this is only because we have mis-match in ecc-scheme between ROM-code (while reading SPL) v/s rest of system. However, if you continue using 'HAM1' for *both* u-boot and kernel you should not face any issue. And with latest patch on u-boot your board file should also remain unchanged. I'm sorry, this is wrong. When the hardware says you MUST use BCH8 or more for a given chip using HAM1 you will have issues. And chips that say you must use BCH4/8/16 are why we get into this issue. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. Forgot to mention, one more way of updating boot-loaders with different ecc-scheme via kernel. This can be helpful when: - you want to remotely upgrade your u-boot, but your kernel is statically build with different ecc-scheme. - In production environment, where you boot multiple devices in parallel (using say NFS boot), and then flash multiple devices without bothering about ecc-schemes.. *Method* (1) Flash the u-boot image on one *sample* device selecting appropriate ecc-scheme which ROM code understands. (2) Dump the complete image along with OOB appended (as a binary) (3) Use this binary image (with OOB included) to flash other devices from kernel as *raw* data (that means kernel will not append ECC while writing data, it will blindly write the image as-it-is on the partition). This way the ECC with which u-boot image was built in (1) will get programmed, irrespective of what kernel supports.. - I have seen at-least one customer going into production this way. - And I have been using this often too, though with older mtd-utils. Hope this helps .. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 12:46 PM, Gupta, Pekon wrote: So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. Forgot to mention, one more way of updating boot-loaders with different ecc-scheme via kernel. This can be helpful when: - you want to remotely upgrade your u-boot, but your kernel is statically build with different ecc-scheme. - In production environment, where you boot multiple devices in parallel (using say NFS boot), and then flash multiple devices without bothering about ecc-schemes.. *Method* (1) Flash the u-boot image on one *sample* device selecting appropriate ecc-scheme which ROM code understands. (2) Dump the complete image along with OOB appended (as a binary) (3) Use this binary image (with OOB included) to flash other devices from kernel as *raw* data (that means kernel will not append ECC while writing data, it will blindly write the image as-it-is on the partition). This way the ECC with which u-boot image was built in (1) will get programmed, irrespective of what kernel supports.. - I have seen at-least one customer going into production this way. - And I have been using this often too, though with older mtd-utils. There are many ways to in essentially work around this problem, given the ability to raw write (including OOB) from the kernel and from u-boot. This doesn't change the general problem of we have cases where we need part of the NAND with one scheme, another part of it with a different one. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Legacy board files for IGEP Processor Boards used 1-bit Hamming ECC layout but new DT uses BCH8 software layout. This breaks the backward compatibility for people that used board files before and switch to DT and have the problem that they can't flash the rootfs using the bootloader. This patch sets the ECC layout to 1-bit Hamming ECC in order to maintain this compatibility. Reported-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Reported-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com --- arch/arm/boot/dts/omap3-igep0020.dts | 2 +- arch/arm/boot/dts/omap3-igep0030.dts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 525e6d9..9043e97 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -59,7 +59,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi Enric, Thanks a lot for fixing this. When adding NAND support for the IGEP boards I used as a base the example from Documentation/devicetree/bindings/mtd/gpmc-nand.txt and I wrongly assumed that bch8 was also the ECC scheme used in the legacy IGEP board file. Sorry for the inconvenience. On Sun, Dec 1, 2013 at 12:23 PM, Enric Balletbo i Serra eballe...@gmail.com wrote: Legacy board files for IGEP Processor Boards used 1-bit Hamming ECC layout but new DT uses BCH8 software layout. This breaks the backward compatibility for people that used board files before and switch to DT and have the problem that they can't flash the rootfs using the bootloader. This patch sets the ECC layout to 1-bit Hamming ECC in order to maintain this compatibility. Reported-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Reported-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com --- arch/arm/boot/dts/omap3-igep0020.dts | 2 +- arch/arm/boot/dts/omap3-igep0030.dts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 525e6d9..9043e97 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -59,7 +59,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; Just a note that this binding property got renamed for v3.13 on commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc Author: Pekon Gupta pe...@ti.com Date: Thu Oct 24 18:20:18 2013 +0530 mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes so users using current v3.12 kernel or older should use ti,nand-ecc-opt = sw; instead. gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; -- 1.8.1.2 -- Acked-by: Javier Martinez Canillas jav...@dowhile0.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
