| Message ID | 1385896995-16803-1-git-send-email-eballetbo@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <eballetbo@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.petazzoni@free-electrons.com> > Reported-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > Signed-off-by: Enric Balletbo i Serra <eballetbo@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 <pekon@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 <javier@dowhile0.org> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 0x00000000 has totlen 0xc != normal 0x0 [ 10.444671] jffs2: CLEANMARKER node found at 0x00020000 has totlen 0xc != normal 0x0 [ 10.472290] jffs2: mtd->read(0x100 bytes from 0x40000) returned ECC error [ 10.480743] jffs2: mtd->read(0x100 bytes from 0x60000) returned ECC error [ 10.489013] jffs2: mtd->read(0x100 bytes from 0x80000) returned ECC error [ 10.497283] jffs2: mtd->read(0x100 bytes from 0xa0000) returned ECC error [ 10.505126] jffs2: mtd->read(0x100 bytes from 0xc0000) returned ECC error [ 10.513458] jffs2: mtd->read(0x100 bytes from 0xe0000) returned ECC error [ 10.521667] jffs2: mtd->read(0x100 bytes from 0x100000) returned ECC error [ 10.529968] jffs2: mtd->read(0x100 bytes from 0x120000) returned ECC error [ 10.538269] jffs2: mtd->read(0x100 bytes from 0x140000) returned ECC error [ 10.546295] jffs2: mtd->read(0x100 bytes from 0x160000) returned ECC error [ 10.554534] jffs2: mtd->read(0x100 bytes from 0x180000) returned ECC error [ 10.563323] jffs2: mtd->read(0x100 bytes from 0x1a0000) returned ECC error [ 10.571685] jffs2: mtd->read(0x100 bytes from 0x1c0000) returned ECC error [ 10.579986] jffs2: mtd->read(0x100 bytes from 0x1e0000) returned ECC error [ 10.588287] jffs2: mtd->read(0x100 bytes from 0x200000) returned ECC error [ 10.596313] jffs2: mtd->read(0x100 bytes from 0x220000) returned ECC error [ 10.604522] jffs2: mtd->read(0x100 bytes from 0x240000) returned ECC error [ 10.613037] jffs2: mtd->read(0x100 bytes from 0x260000) returned ECC error [ 10.621307] jffs2: mtd->read(0x100 bytes from 0x280000) returned ECC error [ 10.629608] jffs2: mtd->read(0x100 bytes from 0x2a0000) returned ECC error [ 10.637908] jffs2: mtd->read(0x100 bytes from 0x2c0000) returned ECC error [ 10.645843] jffs2: mtd->read(0x100 bytes from 0x2e0000) 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 foo10 foo3 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 <pekon@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 0x00000000 has totlen 0xc != normal 0x0 [ 19.810455] jffs2: CLEANMARKER node found at 0x00020000 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 foo10 foo3 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
Hi, CCing Pekon Gupta <pekon@ti.com> 2013/12/2 Thomas Petazzoni <thomas.petazzoni@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 0x00000000 has totlen 0xc != normal 0x0 > [ 10.444671] jffs2: CLEANMARKER node found at 0x00020000 has totlen 0xc != normal 0x0 > [ 10.472290] jffs2: mtd->read(0x100 bytes from 0x40000) returned ECC error > [ 10.480743] jffs2: mtd->read(0x100 bytes from 0x60000) returned ECC error > [ 10.489013] jffs2: mtd->read(0x100 bytes from 0x80000) returned ECC error > [ 10.497283] jffs2: mtd->read(0x100 bytes from 0xa0000) returned ECC error > [ 10.505126] jffs2: mtd->read(0x100 bytes from 0xc0000) returned ECC error > [ 10.513458] jffs2: mtd->read(0x100 bytes from 0xe0000) returned ECC error > [ 10.521667] jffs2: mtd->read(0x100 bytes from 0x100000) returned ECC error > [ 10.529968] jffs2: mtd->read(0x100 bytes from 0x120000) returned ECC error > [ 10.538269] jffs2: mtd->read(0x100 bytes from 0x140000) returned ECC error > [ 10.546295] jffs2: mtd->read(0x100 bytes from 0x160000) returned ECC error > [ 10.554534] jffs2: mtd->read(0x100 bytes from 0x180000) returned ECC error > [ 10.563323] jffs2: mtd->read(0x100 bytes from 0x1a0000) returned ECC error > [ 10.571685] jffs2: mtd->read(0x100 bytes from 0x1c0000) returned ECC error > [ 10.579986] jffs2: mtd->read(0x100 bytes from 0x1e0000) returned ECC error > [ 10.588287] jffs2: mtd->read(0x100 bytes from 0x200000) returned ECC error > [ 10.596313] jffs2: mtd->read(0x100 bytes from 0x220000) returned ECC error > [ 10.604522] jffs2: mtd->read(0x100 bytes from 0x240000) returned ECC error > [ 10.613037] jffs2: mtd->read(0x100 bytes from 0x260000) returned ECC error > [ 10.621307] jffs2: mtd->read(0x100 bytes from 0x280000) returned ECC error > [ 10.629608] jffs2: mtd->read(0x100 bytes from 0x2a0000) returned ECC error > [ 10.637908] jffs2: mtd->read(0x100 bytes from 0x2c0000) returned ECC error > [ 10.645843] jffs2: mtd->read(0x100 bytes from 0x2e0000) 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 foo10 foo3 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 <pekon@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 0x00000000 has totlen 0xc != normal 0x0 > [ 19.810455] jffs2: CLEANMARKER node found at 0x00020000 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 foo10 foo3 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, >From: Enric Balletbo Serra [mailto:eballetbo@gmail.com] >CCing Pekon Gupta <pekon@ti.com> > >>2013/12/2 Thomas Petazzoni <thomas.petazzoni@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
Dear Gupta, Pekon, On Mon, 2 Dec 2013 14:56:09 +0000, 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
>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] >>On Mon, 2 Dec 2013 14:56:09 +0000, 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all, 2013/12/2 Gupta, Pekon <pekon@ti.com>: >>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] >>>On Mon, 2 Dec 2013 14:56:09 +0000, 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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.
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
>From: Thomas Petazzoni [mailto:thomas.petazzoni@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +0000, 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
On 12/02/2013 11:13 AM, Gupta, Pekon wrote: >> From: Thomas Petazzoni [mailto:thomas.petazzoni@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.
Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@ti.com> wrote: >>From: Thomas Petazzoni [mailto:thomas.petazzoni@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: > Hi Pekon, > > On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@ti.com> wrote: >>> From: Thomas Petazzoni [mailto:thomas.petazzoni@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.
On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini <trini@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 <pekon@ti.com> wrote: >>>> From: Thomas Petazzoni [mailto:thomas.petazzoni@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/02/2013 11:46 AM, Javier Martinez Canillas wrote: > On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini <trini@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 <pekon@ti.com> wrote: >>>>> From: Thomas Petazzoni [mailto:thomas.petazzoni@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.
>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] >Dear Gupta, Pekon, > >On Mon, 2 Dec 2013 16:13:56 +0000, 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Pekon On Mon, Dec 2, 2013 at 6:05 PM, Gupta, Pekon <pekon@ti.com> wrote: >>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] >>Dear Gupta, Pekon, >> >>On Mon, 2 Dec 2013 16:13:56 +0000, 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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/02/2013 12:05 PM, Gupta, Pekon wrote: >> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] >> Dear Gupta, Pekon, >> >> On Mon, 2 Dec 2013 16:13:56 +0000, 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.
>> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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".
On Mon, 2013-12-02 at 17:05 +0000, 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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>;
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.petazzoni@free-electrons.com> Reported-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Enric Balletbo i Serra <eballetbo@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(-)