[PATCH 0/2] ARM: mvebu: Use Hardware BCH ECC for RN104 and RN2120

[PATCH 0/2] ARM: mvebu: Use Hardware BCH ECC for RN104 and RN2120

[Arnaud Ebalard]

Hi,

Following Ben's report and fix for RN102, I did some tests
on RN104 and RN2120 (they have the same Hynix H27U1G8F2BTR
flash and setup) and came up w/ the exact same fixes for
their respective .dts files. With those patches, it is now
possible to update kernel from userland and u-boot will
happily load and boot it on those devices.

Both patches should be candidates for stable, I guess.

Cheers,

a+

Arnaud Ebalard (2):
  ARM: mvebu: Netgear RN104: Use Hardware BCH ECC
  ARM: mvebu: Netgear RN2120: Use Hardware BCH ECC

 arch/arm/boot/dts/armada-370-netgear-rn104.dts | 4 ++++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 4 ++++
 2 files changed, 8 insertions(+)

-- 
2.1.0

--
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

[PATCH 1/2] ARM: mvebu: Netgear RN104: Use Hardware BCH ECC

[Arnaud Ebalard]

The bootloader on the Netgear ReadyNAS RN104 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. That way, it is
now possible to update the kernel from userland (e.g. using
standard tools from mtd-utils package); u-boot will happily
load and boot it.

The issue was initially reported and fixed by Ben Pedell for
RN102. The RN104 shares the same Hynix H27U1G8F2BTR NAND
flash and setup. This patch is based on Ben's fix for RN102.

Fixes: 0373a558bd79 ("ARM: mvebu: Enable NAND controller in ReadyNAS 104 .dts file")
Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding")
Signed-off-by: Arnaud Ebalard <arno-LkuqDEemtHBg9hUCZPvPmw@public.gmane.org>
---
 arch/arm/boot/dts/armada-370-netgear-rn104.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-netgear-rn104.dts b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
index f7eb110f43d4..d49e8f24a1c9 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn104.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
@@ -165,6 +165,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 */
-- 
2.1.0


--
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 1/2] ARM: mvebu: Netgear RN104: Use Hardware BCH ECC

[Thomas Petazzoni]

Dear Arnaud Ebalard,

On Sat, 06 Sep 2014 22:49:25 +0200, Arnaud Ebalard wrote:

> Fixes: 0373a558bd79 ("ARM: mvebu: Enable NAND controller in ReadyNAS 104 .dts file")
> Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding")

Maybe it's worth noting that it's not a build dependency: your commit
changing the Device Tree files can perfectly be applied without the
NAND ECC strength and step size bindings. Of course, it will have no
effect on an older kernel that doesn't support those bindings, but it
will not cause a build failure.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe 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 1/2] ARM: mvebu: Netgear RN104: Use Hardware BCH ECC

[Arnaud Ebalard]

Hi Thomas,

Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:

> On Sat, 06 Sep 2014 22:49:25 +0200, Arnaud Ebalard wrote:
>
>> Fixes: 0373a558bd79 ("ARM: mvebu: Enable NAND controller in ReadyNAS 104 .dts file")
>> Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding")
>
> Maybe it's worth noting that it's not a build dependency: your commit
> changing the Device Tree files can perfectly be applied without the
> NAND ECC strength and step size bindings. Of course, it will have no
> effect on an older kernel that doesn't support those bindings, but it
> will not cause a build failure.

Yes. To be more explicit, if the patches are candidates for stable, I
think they are only useful for 3.16.y (3.16 is the first kernel with
5b3e507820c6). As you point, backporting down to 3.14 would not hurt
but would only be decorative.

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

[PATCH 2/2] ARM: mvebu: Netgear RN2120: Use Hardware BCH ECC

[Arnaud Ebalard]

The bootloader on the Netgear ReadyNAS RN2120 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. That way, it is
now possible to update the kernel from userland (e.g. using
standard tools from mtd-utils package); u-boot will happily
load and boot it.

The issue was initially reported and fixed by Ben Pedell for
RN102. The RN2120 shares the same Hynix H27U1G8F2BTR NAND
flash and setup. This patch is based on Ben's fix for RN102.

Fixes: ad51eddd95ad ("ARM: mvebu: Enable NAND controller in ReadyNAS 2120 .dts file")
Depends-on: 5b3e507820c6 ("mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding")
Signed-off-by: Arnaud Ebalard <arno-LkuqDEemtHBg9hUCZPvPmw@public.gmane.org>
---
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 0cf999abc4ed..c5ed85a70ed9 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -223,6 +223,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 */
-- 
2.1.0

--
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 0/2] ARM: mvebu: Use Hardware BCH ECC for RN104 and RN2120

[Jason Cooper]

On Sat, Sep 06, 2014 at 10:48:44PM +0200, Arnaud Ebalard wrote:
> Hi,
> 
> Following Ben's report and fix for RN102, I did some tests
> on RN104 and RN2120 (they have the same Hynix H27U1G8F2BTR
> flash and setup) and came up w/ the exact same fixes for
> their respective .dts files. With those patches, it is now
> possible to update kernel from userland and u-boot will
> happily load and boot it on those devices.
> 
> Both patches should be candidates for stable, I guess.
> 
> Cheers,
> 
> a+
> 
> Arnaud Ebalard (2):
>   ARM: mvebu: Netgear RN104: Use Hardware BCH ECC
>   ARM: mvebu: Netgear RN2120: Use Hardware BCH ECC
> 
>  arch/arm/boot/dts/armada-370-netgear-rn104.dts | 4 ++++
>  arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 4 ++++
>  2 files changed, 8 insertions(+)

I've applied both patches to mvebu/fixes and flagged them for stable,
v3.14+.  I removed the 'Depends' line from each, as Thomas mentioned,
there is no build dependency between these dts changes and the code
supporting it (as it should be).

thx,

Jason.
--
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