[PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[klightspeed]

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

[PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[klightspeed]

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

Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[Ezequiel Garcia]

(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

Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[Arnaud Ebalard]

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

Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[Ben Peddell]

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