* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 6:23 ` klightspeed 0 siblings, 0 replies; 16+ messages in thread From: klightspeed at killerwolves.net @ 2014-09-05 6:23 UTC (permalink / raw) To: linux-arm-kernel The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC (strength = 4), while the pxa3xx NAND driver by default uses Hamming ECC (strength = 1). This patch changes the ECC mode on these machines to match that of the bootloader and of the stock firmware, so that for example updating the kernel is possible without requiring a serial connection. This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding) Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> --- arch/arm/boot/dts/armada-370-netgear-rn102.dts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts index d6d572e..285524f 100644 --- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts @@ -143,6 +143,10 @@ marvell,nand-enable-arbiter; nand-on-flash-bbt; + /* Use Hardware BCH ECC */ + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; + partition at 0 { label = "u-boot"; reg = <0x0000000 0x180000>; /* 1.5MB */ -- 1.8.5.5 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 6:23 ` klightspeed 0 siblings, 0 replies; 16+ messages in thread From: klightspeed @ 2014-09-05 6:23 UTC (permalink / raw) To: linux-arm-kernel, Arnaud Ebalard Cc: Ben Peddell, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Jason Cooper, devicetree, linux-kernel The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC (strength = 4), while the pxa3xx NAND driver by default uses Hamming ECC (strength = 1). This patch changes the ECC mode on these machines to match that of the bootloader and of the stock firmware, so that for example updating the kernel is possible without requiring a serial connection. This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding) Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> --- arch/arm/boot/dts/armada-370-netgear-rn102.dts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts index d6d572e..285524f 100644 --- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts @@ -143,6 +143,10 @@ marvell,nand-enable-arbiter; nand-on-flash-bbt; + /* Use Hardware BCH ECC */ + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; + partition@0 { label = "u-boot"; reg = <0x0000000 0x180000>; /* 1.5MB */ -- 1.8.5.5 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 6:23 ` klightspeed 0 siblings, 0 replies; 16+ messages in thread From: klightspeed @ 2014-09-05 6:23 UTC (permalink / raw) To: linux-arm-kernel, Arnaud Ebalard Cc: Mark Rutland, devicetree, Ben Peddell, Jason Cooper, Pawel Moll, Ian Campbell, linux-kernel, Rob Herring, Kumar Gala, Russell King The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC (strength = 4), while the pxa3xx NAND driver by default uses Hamming ECC (strength = 1). This patch changes the ECC mode on these machines to match that of the bootloader and of the stock firmware, so that for example updating the kernel is possible without requiring a serial connection. This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding) Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> --- arch/arm/boot/dts/armada-370-netgear-rn102.dts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts index d6d572e..285524f 100644 --- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts @@ -143,6 +143,10 @@ marvell,nand-enable-arbiter; nand-on-flash-bbt; + /* Use Hardware BCH ECC */ + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; + partition@0 { label = "u-boot"; reg = <0x0000000 0x180000>; /* 1.5MB */ -- 1.8.5.5 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC 2014-09-05 6:23 ` klightspeed (?) (?) @ 2014-09-05 15:41 ` Ezequiel Garcia -1 siblings, 0 replies; 16+ messages in thread From: Ezequiel Garcia @ 2014-09-05 15:41 UTC (permalink / raw) To: klightspeed Cc: Thomas Petazzoni, devicetree, Jason Cooper, Arnaud Ebalard, linux-kernel, linux-mtd, Gregory Clement, Brian Norris, linux-arm-kernel (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) On 05 Sep 04:23 PM, klightspeed@killerwolves.net wrote: > The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC > (strength = 4), while the pxa3xx NAND driver by default uses > Hamming ECC (strength = 1). > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, and the kernel is just taking the legacy ECC. The flash specs makes no mention to ONFI, so probably no ONFI here. > This patch changes the ECC mode on these machines to match that > of the bootloader and of the stock firmware, so that for example > updating the kernel is possible without requiring a serial > connection. > > This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC > strength and step size devicetree binding) > > Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> Looks good to me, since Arnaud reports this is the correct ECC scheme: http://natisbad.org/NAS2/index.html#hw-nand Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Thanks for the fix, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 15:41 ` Ezequiel Garcia 0 siblings, 0 replies; 16+ messages in thread From: Ezequiel Garcia @ 2014-09-05 15:41 UTC (permalink / raw) To: klightspeed Cc: linux-arm-kernel, Arnaud Ebalard, Jason Cooper, devicetree, linux-kernel, linux-mtd, Brian Norris, Thomas Petazzoni, Gregory Clement (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) On 05 Sep 04:23 PM, klightspeed@killerwolves.net wrote: > The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC > (strength = 4), while the pxa3xx NAND driver by default uses > Hamming ECC (strength = 1). > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, and the kernel is just taking the legacy ECC. The flash specs makes no mention to ONFI, so probably no ONFI here. > This patch changes the ECC mode on these machines to match that > of the bootloader and of the stock firmware, so that for example > updating the kernel is possible without requiring a serial > connection. > > This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC > strength and step size devicetree binding) > > Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> Looks good to me, since Arnaud reports this is the correct ECC scheme: http://natisbad.org/NAS2/index.html#hw-nand Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Thanks for the fix, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 15:41 ` Ezequiel Garcia 0 siblings, 0 replies; 16+ messages in thread From: Ezequiel Garcia @ 2014-09-05 15:41 UTC (permalink / raw) To: klightspeed-aslSrjg9ejhWX4hkXwHRhw Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnaud Ebalard, Jason Cooper, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris, Thomas Petazzoni, Gregory Clement (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) On 05 Sep 04:23 PM, klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org wrote: > The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC > (strength = 4), while the pxa3xx NAND driver by default uses > Hamming ECC (strength = 1). > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, and the kernel is just taking the legacy ECC. The flash specs makes no mention to ONFI, so probably no ONFI here. > This patch changes the ECC mode on these machines to match that > of the bootloader and of the stock firmware, so that for example > updating the kernel is possible without requiring a serial > connection. > > This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC > strength and step size devicetree binding) > > Signed-off-by: Ben Peddell <klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org> Looks good to me, since Arnaud reports this is the correct ECC scheme: http://natisbad.org/NAS2/index.html#hw-nand Acked-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> Thanks for the fix, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 15:41 ` Ezequiel Garcia 0 siblings, 0 replies; 16+ messages in thread From: Ezequiel Garcia @ 2014-09-05 15:41 UTC (permalink / raw) To: linux-arm-kernel (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) On 05 Sep 04:23 PM, klightspeed at killerwolves.net wrote: > The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC > (strength = 4), while the pxa3xx NAND driver by default uses > Hamming ECC (strength = 1). > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, and the kernel is just taking the legacy ECC. The flash specs makes no mention to ONFI, so probably no ONFI here. > This patch changes the ECC mode on these machines to match that > of the bootloader and of the stock firmware, so that for example > updating the kernel is possible without requiring a serial > connection. > > This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC > strength and step size devicetree binding) > > Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> Looks good to me, since Arnaud reports this is the correct ECC scheme: http://natisbad.org/NAS2/index.html#hw-nand Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Thanks for the fix, -- Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC 2014-09-05 15:41 ` Ezequiel Garcia (?) (?) @ 2014-09-05 20:49 ` Arnaud Ebalard -1 siblings, 0 replies; 16+ messages in thread From: Arnaud Ebalard @ 2014-09-05 20:49 UTC (permalink / raw) To: Ezequiel Garcia Cc: Thomas Petazzoni, devicetree, klightspeed, Jason Cooper, linux-kernel, linux-mtd, Gregory Clement, Brian Norris, linux-arm-kernel Hi, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> writes: > (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) > > On 05 Sep 04:23 PM, klightspeed@killerwolves.net wrote: >> The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC >> (strength = 4), while the pxa3xx NAND driver by default uses >> Hamming ECC (strength = 1). >> > > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, > and the kernel is just taking the legacy ECC. The flash specs makes no > mention to ONFI, so probably no ONFI here. > >> This patch changes the ECC mode on these machines to match that >> of the bootloader and of the stock firmware, so that for example >> updating the kernel is possible without requiring a serial >> connection. >> >> This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC >> strength and step size devicetree binding) >> >> Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> > > Looks good to me, since Arnaud reports this is the correct ECC scheme: > http://natisbad.org/NAS2/index.html#hw-nand > > Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > > Thanks for the fix, w/o the patch, you can write data to the flash using userland tools from mtd-utils package (flash_erase and nandwrite); data can then be read again using userland tools (say using dd). But - as reported by Ben - if you nandwrite an uImage from userland, here is what you indeed get from u-boot when you try and boot that image: root@humble:~# flash_erase /dev/mtd2 0 0 Erasing 128 Kibyte @ 5e0000 -- 100 % complete root@humble:~# nandwrite -p /dev/mtd2 /tmp/uImage-3.16.1.rn102 Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Writing data to block 4 at offset 0x80000 ... reboot ... Marvell>> nand read 0x1200000 0x200000 0x600000 NAND read: device 0 offset 0x200000, size 0x600000 6291456 bytes read: OK Marvell>> bootm 0x1200000 ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-08-14 13:33:46 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4423998 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! Now, w/ the patch submitted by Ben, here is what you get: With the patch applied, this indeed works has ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-09-05 20:25:34 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4424067 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... i.e. it works. So, thanks for reporting this, Ben. I must confess I got used to update my kernels from u-boot and did not take enough attention to that aspect when I updated the .dts to add access to NAND after Ezequiel wrote the NAND driver. I will take a look at RN104 and RN2120 to check if something similar is needed for those two. FWIW, you can add my: Tested-by: Arnaud Ebalard <arno@natisbad.org> Additionally, Ezequiel, would anything prevent pushing the patch to stable team (nand entry in .dts was added in 3.14): Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Cheers, a+ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 20:49 ` Arnaud Ebalard 0 siblings, 0 replies; 16+ messages in thread From: Arnaud Ebalard @ 2014-09-05 20:49 UTC (permalink / raw) To: Ezequiel Garcia Cc: klightspeed, linux-arm-kernel, Jason Cooper, devicetree, linux-kernel, linux-mtd, Brian Norris, Thomas Petazzoni, Gregory Clement Hi, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> writes: > (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) > > On 05 Sep 04:23 PM, klightspeed@killerwolves.net wrote: >> The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC >> (strength = 4), while the pxa3xx NAND driver by default uses >> Hamming ECC (strength = 1). >> > > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, > and the kernel is just taking the legacy ECC. The flash specs makes no > mention to ONFI, so probably no ONFI here. > >> This patch changes the ECC mode on these machines to match that >> of the bootloader and of the stock firmware, so that for example >> updating the kernel is possible without requiring a serial >> connection. >> >> This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC >> strength and step size devicetree binding) >> >> Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> > > Looks good to me, since Arnaud reports this is the correct ECC scheme: > http://natisbad.org/NAS2/index.html#hw-nand > > Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > > Thanks for the fix, w/o the patch, you can write data to the flash using userland tools from mtd-utils package (flash_erase and nandwrite); data can then be read again using userland tools (say using dd). But - as reported by Ben - if you nandwrite an uImage from userland, here is what you indeed get from u-boot when you try and boot that image: root@humble:~# flash_erase /dev/mtd2 0 0 Erasing 128 Kibyte @ 5e0000 -- 100 % complete root@humble:~# nandwrite -p /dev/mtd2 /tmp/uImage-3.16.1.rn102 Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Writing data to block 4 at offset 0x80000 ... reboot ... Marvell>> nand read 0x1200000 0x200000 0x600000 NAND read: device 0 offset 0x200000, size 0x600000 6291456 bytes read: OK Marvell>> bootm 0x1200000 ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-08-14 13:33:46 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4423998 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! Now, w/ the patch submitted by Ben, here is what you get: With the patch applied, this indeed works has ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-09-05 20:25:34 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4424067 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... i.e. it works. So, thanks for reporting this, Ben. I must confess I got used to update my kernels from u-boot and did not take enough attention to that aspect when I updated the .dts to add access to NAND after Ezequiel wrote the NAND driver. I will take a look at RN104 and RN2120 to check if something similar is needed for those two. FWIW, you can add my: Tested-by: Arnaud Ebalard <arno@natisbad.org> Additionally, Ezequiel, would anything prevent pushing the patch to stable team (nand entry in .dts was added in 3.14): Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Cheers, a+ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 20:49 ` Arnaud Ebalard 0 siblings, 0 replies; 16+ messages in thread From: Arnaud Ebalard @ 2014-09-05 20:49 UTC (permalink / raw) To: Ezequiel Garcia Cc: klightspeed-aslSrjg9ejhWX4hkXwHRhw, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris, Thomas Petazzoni, Gregory Clement Hi, Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes: > (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) > > On 05 Sep 04:23 PM, klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org wrote: >> The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC >> (strength = 4), while the pxa3xx NAND driver by default uses >> Hamming ECC (strength = 1). >> > > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, > and the kernel is just taking the legacy ECC. The flash specs makes no > mention to ONFI, so probably no ONFI here. > >> This patch changes the ECC mode on these machines to match that >> of the bootloader and of the stock firmware, so that for example >> updating the kernel is possible without requiring a serial >> connection. >> >> This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC >> strength and step size devicetree binding) >> >> Signed-off-by: Ben Peddell <klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org> > > Looks good to me, since Arnaud reports this is the correct ECC scheme: > http://natisbad.org/NAS2/index.html#hw-nand > > Acked-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > Thanks for the fix, w/o the patch, you can write data to the flash using userland tools from mtd-utils package (flash_erase and nandwrite); data can then be read again using userland tools (say using dd). But - as reported by Ben - if you nandwrite an uImage from userland, here is what you indeed get from u-boot when you try and boot that image: root@humble:~# flash_erase /dev/mtd2 0 0 Erasing 128 Kibyte @ 5e0000 -- 100 % complete root@humble:~# nandwrite -p /dev/mtd2 /tmp/uImage-3.16.1.rn102 Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Writing data to block 4 at offset 0x80000 ... reboot ... Marvell>> nand read 0x1200000 0x200000 0x600000 NAND read: device 0 offset 0x200000, size 0x600000 6291456 bytes read: OK Marvell>> bootm 0x1200000 ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-08-14 13:33:46 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4423998 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! Now, w/ the patch submitted by Ben, here is what you get: With the patch applied, this indeed works has ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-09-05 20:25:34 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4424067 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... i.e. it works. So, thanks for reporting this, Ben. I must confess I got used to update my kernels from u-boot and did not take enough attention to that aspect when I updated the .dts to add access to NAND after Ezequiel wrote the NAND driver. I will take a look at RN104 and RN2120 to check if something similar is needed for those two. FWIW, you can add my: Tested-by: Arnaud Ebalard <arno-LkuqDEemtHBg9hUCZPvPmw@public.gmane.org> Additionally, Ezequiel, would anything prevent pushing the patch to stable team (nand entry in .dts was added in 3.14): Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Cheers, a+ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 20:49 ` Arnaud Ebalard 0 siblings, 0 replies; 16+ messages in thread From: Arnaud Ebalard @ 2014-09-05 20:49 UTC (permalink / raw) To: linux-arm-kernel Hi, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> writes: > (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) > > On 05 Sep 04:23 PM, klightspeed at killerwolves.net wrote: >> The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC >> (strength = 4), while the pxa3xx NAND driver by default uses >> Hamming ECC (strength = 1). >> > > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, > and the kernel is just taking the legacy ECC. The flash specs makes no > mention to ONFI, so probably no ONFI here. > >> This patch changes the ECC mode on these machines to match that >> of the bootloader and of the stock firmware, so that for example >> updating the kernel is possible without requiring a serial >> connection. >> >> This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC >> strength and step size devicetree binding) >> >> Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> > > Looks good to me, since Arnaud reports this is the correct ECC scheme: > http://natisbad.org/NAS2/index.html#hw-nand > > Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > > Thanks for the fix, w/o the patch, you can write data to the flash using userland tools from mtd-utils package (flash_erase and nandwrite); data can then be read again using userland tools (say using dd). But - as reported by Ben - if you nandwrite an uImage from userland, here is what you indeed get from u-boot when you try and boot that image: root at humble:~# flash_erase /dev/mtd2 0 0 Erasing 128 Kibyte @ 5e0000 -- 100 % complete root at humble:~# nandwrite -p /dev/mtd2 /tmp/uImage-3.16.1.rn102 Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Writing data to block 4 at offset 0x80000 ... reboot ... Marvell>> nand read 0x1200000 0x200000 0x600000 NAND read: device 0 offset 0x200000, size 0x600000 6291456 bytes read: OK Marvell>> bootm 0x1200000 ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-08-14 13:33:46 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4423998 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! Now, w/ the patch submitted by Ben, here is what you get: With the patch applied, this indeed works has ## Booting kernel from Legacy Image at 01200000 ... Image Name: Linux-3.16.1.rn102 Created: 2014-09-05 20:25:34 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4424067 Bytes = 4.2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... i.e. it works. So, thanks for reporting this, Ben. I must confess I got used to update my kernels from u-boot and did not take enough attention to that aspect when I updated the .dts to add access to NAND after Ezequiel wrote the NAND driver. I will take a look at RN104 and RN2120 to check if something similar is needed for those two. FWIW, you can add my: Tested-by: Arnaud Ebalard <arno@natisbad.org> Additionally, Ezequiel, would anything prevent pushing the patch to stable team (nand entry in .dts was added in 3.14): Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Cheers, a+ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC 2014-09-05 20:49 ` Arnaud Ebalard (?) (?) @ 2014-09-06 2:18 ` Ben Peddell -1 siblings, 0 replies; 16+ messages in thread From: Ben Peddell @ 2014-09-06 2:18 UTC (permalink / raw) To: Arnaud Ebalard, Ezequiel Garcia Cc: Thomas Petazzoni, devicetree, Jason Cooper, linux-kernel, linux-mtd, Gregory Clement, Brian Norris, linux-arm-kernel On 06 Sep 2014 at 06:49, Arnaud Ebalard wrote: > FWIW, you can add my: > > Tested-by: Arnaud Ebalard <arno@natisbad.org> > > Additionally, Ezequiel, would anything prevent pushing the patch to > stable team (nand entry in .dts was added in 3.14): > > Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding") The devicetree binding is not currently in linux-stable/linux-3.14.y ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-06 2:18 ` Ben Peddell 0 siblings, 0 replies; 16+ messages in thread From: Ben Peddell @ 2014-09-06 2:18 UTC (permalink / raw) To: Arnaud Ebalard, Ezequiel Garcia Cc: linux-arm-kernel, Jason Cooper, devicetree, linux-kernel, linux-mtd, Brian Norris, Thomas Petazzoni, Gregory Clement On 06 Sep 2014 at 06:49, Arnaud Ebalard wrote: > FWIW, you can add my: > > Tested-by: Arnaud Ebalard <arno@natisbad.org> > > Additionally, Ezequiel, would anything prevent pushing the patch to > stable team (nand entry in .dts was added in 3.14): > > Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding") The devicetree binding is not currently in linux-stable/linux-3.14.y ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-06 2:18 ` Ben Peddell 0 siblings, 0 replies; 16+ messages in thread From: Ben Peddell @ 2014-09-06 2:18 UTC (permalink / raw) To: Arnaud Ebalard, Ezequiel Garcia Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris, Thomas Petazzoni, Gregory Clement On 06 Sep 2014 at 06:49, Arnaud Ebalard wrote: > FWIW, you can add my: > > Tested-by: Arnaud Ebalard <arno-LkuqDEemtHBg9hUCZPvPmw@public.gmane.org> > > Additionally, Ezequiel, would anything prevent pushing the patch to > stable team (nand entry in .dts was added in 3.14): > > Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding") The devicetree binding is not currently in linux-stable/linux-3.14.y -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-06 2:18 ` Ben Peddell 0 siblings, 0 replies; 16+ messages in thread From: Ben Peddell @ 2014-09-06 2:18 UTC (permalink / raw) To: linux-arm-kernel On 06 Sep 2014 at 06:49, Arnaud Ebalard wrote: > FWIW, you can add my: > > Tested-by: Arnaud Ebalard <arno@natisbad.org> > > Additionally, Ezequiel, would anything prevent pushing the patch to > stable team (nand entry in .dts was added in 3.14): > > Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file") Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding") The devicetree binding is not currently in linux-stable/linux-3.14.y ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC @ 2014-09-05 6:18 klightspeed 0 siblings, 0 replies; 16+ messages in thread From: klightspeed @ 2014-09-05 6:18 UTC (permalink / raw) To: linux-arm-kernel, Arnaud Ebalard Cc: Ben Peddell, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, Jason Cooper, devicetree, linux-kernel The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC (strength = 4), while the pxa3xx NAND driver by default uses Hamming ECC (strength = 1). This patch changes the ECC mode on these machines to match that of the bootloader and of the stock firmware, so that for example updating the kernel is possible without requiring a serial connection. This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding) Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> --- arch/arm/boot/dts/armada-370-netgear-rn102.dts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts index d6d572e..285524f 100644 --- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts @@ -143,6 +143,10 @@ marvell,nand-enable-arbiter; nand-on-flash-bbt; + /* Use Hardware BCH ECC */ + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; + partition@0 { label = "u-boot"; reg = <0x0000000 0x180000>; /* 1.5MB */ -- 1.8.5.5 ^ permalink raw reply related [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-09-06 2:19 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-05 6:23 [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC klightspeed at killerwolves.net 2014-09-05 6:23 ` klightspeed 2014-09-05 6:23 ` klightspeed 2014-09-05 15:41 ` Ezequiel Garcia 2014-09-05 15:41 ` Ezequiel Garcia 2014-09-05 15:41 ` Ezequiel Garcia 2014-09-05 15:41 ` Ezequiel Garcia 2014-09-05 20:49 ` Arnaud Ebalard 2014-09-05 20:49 ` Arnaud Ebalard 2014-09-05 20:49 ` Arnaud Ebalard 2014-09-05 20:49 ` Arnaud Ebalard 2014-09-06 2:18 ` Ben Peddell 2014-09-06 2:18 ` Ben Peddell 2014-09-06 2:18 ` Ben Peddell 2014-09-06 2:18 ` Ben Peddell -- strict thread matches above, loose matches on Subject: below -- 2014-09-05 6:18 klightspeed
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.