* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC
@ 2014-09-05 6:23 klightspeed at killerwolves.net
2014-09-05 15:41 ` Ezequiel Garcia
0 siblings, 1 reply; 4+ 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] 4+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC
2014-09-05 6:23 [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC klightspeed at killerwolves.net
@ 2014-09-05 15:41 ` Ezequiel Garcia
2014-09-05 20:49 ` Arnaud Ebalard
0 siblings, 1 reply; 4+ 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] 4+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC
2014-09-05 15:41 ` Ezequiel Garcia
@ 2014-09-05 20:49 ` Arnaud Ebalard
2014-09-06 2:18 ` Ben Peddell
0 siblings, 1 reply; 4+ 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] 4+ messages in thread
* [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC
2014-09-05 20:49 ` Arnaud Ebalard
@ 2014-09-06 2:18 ` Ben Peddell
0 siblings, 0 replies; 4+ 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] 4+ messages in thread
end of thread, other threads:[~2014-09-06 2:18 UTC | newest]
Thread overview: 4+ 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 15:41 ` Ezequiel Garcia
2014-09-05 20:49 ` Arnaud Ebalard
2014-09-06 2:18 ` Ben Peddell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).