[RFC] Add .dts file for Netgear ReadyNAS 102

[RFC] Add .dts file for Netgear ReadyNAS 102

[Arnaud Ebalard]

Hi,

Here is a .dts file for Armada-370-based Netgear ReadyNAS 102. The
purpose of this submission is to get some feedback and also some
directions on how to proceed to get it included at some point.

Regarding the device, I put some information on the various hardware
parts here: http://natisbad.org/NAS2/ . I still have to update the
page now that almost everything is as it should.

With the appended .dts file, all the various parts of the device work
as expected:

 - USB 3.0 rear ports via FL1009 XHCI controller connected to PCIe
   bus (eSATA not tested yet)
 - USB 2.0 front port
 - Gigabit Ethernet port (MAC needs to be set by the system at boot)
 - Backup, Power and Reset buttons
 - LEDS (most set to on but changeable). At the moment, I still have not
   found by which gpio the last one is controlled (activity led).
 - serial port at the rear

 - G762 PWM fan controller on I2C bus: it requires G762 driver which
   is *currently sitting in hwmon maintainer tree* and will be available
   in 3.11. Jason, as a side note I have a short patch for available for
   ReadyNAS Duo v2 .dts file (the device also has a G762). I can hold
   it until rc cycle if you prefer.

 - Intersil ISL 12057 RTC on I2C bus: support for that one is *not
   available upstream yet* but I have an initial working patch which I
   intend to push upstream (same as for G762 driver).

In the end, the main missing part is the NAND but I guess this is the
same for all Aramda 370/XP boards and this is not a big issue as it is
still possible to interact w/ it via u-boot and install a set of
uImage/uInitramfs that way. 

Jason, the tests were done against your for-next branch (with all the
fixes which accumulated in Linux tree from rc7). I will work directly
against Linus tree as soon as the rc- cycle for 3.11 starts. 

Additionally, I don't think this is a problem but my whole toolchain is
an arm-linux-gnueabi- one and the tests were done using a Debian (ho hfp
at all).

Cheers,

a+

Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
---
 arch/arm/boot/dts/Makefile                     |   1 +
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 215 +++++++++++++++++++++++++
 2 files changed, 216 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-370-netgear-rn102.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ae7124c..076ff01 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -97,6 +97,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
 	msm8960-cdp.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
 	armada-370-mirabox.dtb \
+	armada-370-netgear-rn102.dtb \
 	armada-370-rd.dtb \
 	armada-xp-db.dtb \
 	armada-xp-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
new file mode 100644
index 0000000..5a9e129
--- /dev/null
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -0,0 +1,215 @@
+/*
+ * Device Tree file for NETGEAR ReadyNAS 102
+ *
+ * Copyright (C) 2013, Arnaud EBALARD <arno@natisbad.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "armada-370.dtsi"
+
+/ {
+	model = "NETGEAR ReadyNAS 102";
+	compatible = "netgear,readynas-102", "marvell,armada370", "marvell,armada-370-xp";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>; /* 512 MB */
+	};
+
+	soc {
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
+			};
+
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
+			};
+
+			pinctrl {
+				power_led_pin: power-led-pin {
+					marvell,pins = "mpp57";
+					marvell,function = "gpio";
+				};
+				sata1_led_pin: sata1-led-pin {
+					marvell,pins = "mpp15";
+					marvell,function = "gpio";
+				};
+
+				sata2_led_pin: sata2-led-pin {
+					marvell,pins = "mpp14";
+					marvell,function = "gpio";
+				};
+
+				backup_led_pin: backup-led-pin {
+					marvell,pins = "mpp56";
+					marvell,function = "gpio";
+				};
+			};
+
+			gpio_leds {
+				compatible = "gpio-leds";
+				pinctrl-0 = < &power_led_pin
+					      &sata1_led_pin
+					      &sata2_led_pin
+					      &backup_led_pin >;
+				pinctrl-names = "default";
+
+				blue_power_led {
+					label = "rn102:blue:pwr";
+					gpios = <&gpio1 25 1>;  /* GPIO 57 Active Low */
+					linux,default-trigger = "heartbeat";
+				};
+
+				green_sata1_led {
+					label = "rn102:green:sata1";
+					gpios = <&gpio0 15 1>;  /* GPIO 15 Active Low */
+					default-state = "on";
+				};
+
+				green_sata2_led {
+					label = "rn102:green:sata2";
+					gpios = <&gpio0 14 1>;   /* GPIO 14 Active Low */
+					default-state = "on";
+				};
+
+				green_backup_led {
+					label = "rn102:green:backup";
+					gpios = <&gpio1 24 1>;   /* GPIO 56 Active Low */
+					default-state = "on";
+				};
+			};
+
+			gpio_keys {
+				compatible = "gpio-keys";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				button at 1 {
+					label = "Power Button";
+					linux,code = <116>;     /* KEY_POWER */
+					gpios = <&gpio1 30 1>;
+				};
+				button at 2 {
+					label = "Reset Button";
+					linux,code = <0x198>;   /* KEY_RESTART */
+					gpios = <&gpio0 6 1>;
+				};
+				button at 3 {
+					label = "Backup Button";
+					linux,code = <133>;     /* KEY_COPY */
+					gpios = <&gpio1 26 1>;
+				};
+			};
+
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+			};
+
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+
+			/* Waiting for NAND support to appear in armada-370.dtsi
+
+			nand at d0000 {
+				status = "okay";
+
+				partition at 0 {
+				   label = "u-boot";
+				   reg = <0x0000000 0x180000>;
+				   read-only;
+				};
+
+				partition at 180000 {
+				   label = "u-boot-env";
+				   reg = <0x180000 0x20000>;
+				};
+
+				partition at 200000 {
+				   label = "uImage";
+				   reg = <0x0200000 0x600000>;
+				};
+
+				partition at 800000 {
+				   label = "minirootfs";
+				   reg = <0x0800000 0x400000>;
+				};
+
+				partition at c00000 {
+				   label = "ubi";
+				   reg = <0x0c00000 0x7400000>;
+				};
+			};
+
+			*/
+
+			usb at 50000 {
+				status = "okay";
+			};
+
+			clocks {
+			       #address-cells = <1>;
+			       #size-cells = <0>;
+
+			       g762_clk: fixedclk {
+					 compatible = "fixed-clock";
+					 #clock-cells = <0>;
+					 clock-frequency = <8192>;
+			       };
+			};
+
+			i2c at 11000 {
+				compatible = "marvell,mv64xxx-i2c";
+				clock-frequency = <100000>;
+				status = "okay";
+
+				isl12057: isl12057 at 68 {
+					compatible = "isil,isl12057";
+					reg = <0x68>;
+					wakeup-source;
+				};
+
+				g762: g762 at 3e {
+					compatible = "gmt,g762";
+					reg = <0x3e>;
+					clocks = <&g762_clk>; /* input clock */
+					fan_gear_mode = <0>;
+					fan_startv = <1>;
+					pwm_polarity = <0>;
+				};
+			};
+
+			pcie-controller {
+				status = "okay";
+
+				/* Connected to Marvell SATA controller */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
+
+				/* Connected to FL1009 USB 3.0 controller */
+				pcie at 2,0 {
+					/* Port 1, Lane 0 */
+					status = "okay";
+				};
+			};
+		};
+	};
+};
-- 
1.8.3.1

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

Arnaud,

On Sun, Jun 30, 2013 at 10:59:31PM +0200, Arnaud Ebalard wrote:
> Regarding the device, I put some information on the various hardware
> parts here: http://natisbad.org/NAS2/ . I still have to update the
> page now that almost everything is as it should.

Nice!

> With the appended .dts file, all the various parts of the device work
> as expected:
> 
>  - USB 3.0 rear ports via FL1009 XHCI controller connected to PCIe
>    bus (eSATA not tested yet)
>  - USB 2.0 front port
>  - Gigabit Ethernet port (MAC needs to be set by the system at boot)
>  - Backup, Power and Reset buttons
>  - LEDS (most set to on but changeable). At the moment, I still have not
>    found by which gpio the last one is controlled (activity led).
>  - serial port at the rear
> 
>  - G762 PWM fan controller on I2C bus: it requires G762 driver which
>    is *currently sitting in hwmon maintainer tree* and will be available
>    in 3.11. Jason, as a side note I have a short patch for available for
>    ReadyNAS Duo v2 .dts file (the device also has a G762). I can hold
>    it until rc cycle if you prefer.

Nope, post patches when you have them ready.  I am capable of holding
them until -rc1 drops ;-)

>  - Intersil ISL 12057 RTC on I2C bus: support for that one is *not
>    available upstream yet* but I have an initial working patch which I
>    intend to push upstream (same as for G762 driver).
> 
> In the end, the main missing part is the NAND but I guess this is the
> same for all Aramda 370/XP boards and this is not a big issue as it is
> still possible to interact w/ it via u-boot and install a set of
> uImage/uInitramfs that way. 

What's the big blocker for this?  Once this is done, debian should be
able to add support for this board.  After all, upgrading the kernel and
initrd from userspace is a desirable option.

> Jason, the tests were done against your for-next branch (with all the
> fixes which accumulated in Linux tree from rc7). I will work directly
> against Linus tree as soon as the rc- cycle for 3.11 starts. 

hmmm, my latest for-next (20130623) is based against v3.10-rc7, are you
using that?

> Additionally, I don't think this is a problem but my whole toolchain is
> an arm-linux-gnueabi- one and the tests were done using a Debian (ho hfp
> at all).

I do believe there is an active aversion to floating point within the
kernel, you should be fine.  We also don't like C libraries, or
hamsters, apparently.

> Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
> ---
>  arch/arm/boot/dts/Makefile                     |   1 +
>  arch/arm/boot/dts/armada-370-netgear-rn102.dts | 215 +++++++++++++++++++++++++
>  2 files changed, 216 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-370-netgear-rn102.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ae7124c..076ff01 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -97,6 +97,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>  	msm8960-cdp.dtb
>  dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>  	armada-370-mirabox.dtb \
> +	armada-370-netgear-rn102.dtb \
>  	armada-370-rd.dtb \
>  	armada-xp-db.dtb \
>  	armada-xp-gp.dtb \
> diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> new file mode 100644
> index 0000000..5a9e129
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> @@ -0,0 +1,215 @@
> +/*
> + * Device Tree file for NETGEAR ReadyNAS 102
> + *
> + * Copyright (C) 2013, Arnaud EBALARD <arno@natisbad.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "armada-370.dtsi"
> +
> +/ {
> +	model = "NETGEAR ReadyNAS 102";
> +	compatible = "netgear,readynas-102", "marvell,armada370", "marvell,armada-370-xp";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x20000000>; /* 512 MB */
> +	};
> +
> +	soc {
> +		internal-regs {
> +			serial at 12000 {
> +				clock-frequency = <200000000>;
> +				status = "okay";
> +			};
> +
> +			sata at a0000 {
> +				nr-ports = <2>;
> +				status = "okay";
> +			};
> +
> +			pinctrl {
> +				power_led_pin: power-led-pin {
> +					marvell,pins = "mpp57";
> +					marvell,function = "gpio";
> +				};
> +				sata1_led_pin: sata1-led-pin {
> +					marvell,pins = "mpp15";
> +					marvell,function = "gpio";
> +				};
> +
> +				sata2_led_pin: sata2-led-pin {
> +					marvell,pins = "mpp14";
> +					marvell,function = "gpio";
> +				};
> +
> +				backup_led_pin: backup-led-pin {
> +					marvell,pins = "mpp56";
> +					marvell,function = "gpio";
> +				};
> +			};
> +
> +			gpio_leds {
> +				compatible = "gpio-leds";
> +				pinctrl-0 = < &power_led_pin
> +					      &sata1_led_pin
> +					      &sata2_led_pin
> +					      &backup_led_pin >;
> +				pinctrl-names = "default";
> +
> +				blue_power_led {
> +					label = "rn102:blue:pwr";
> +					gpios = <&gpio1 25 1>;  /* GPIO 57 Active Low */
> +					linux,default-trigger = "heartbeat";
> +				};
> +
> +				green_sata1_led {
> +					label = "rn102:green:sata1";
> +					gpios = <&gpio0 15 1>;  /* GPIO 15 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_sata2_led {
> +					label = "rn102:green:sata2";
> +					gpios = <&gpio0 14 1>;   /* GPIO 14 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_backup_led {
> +					label = "rn102:green:backup";
> +					gpios = <&gpio1 24 1>;   /* GPIO 56 Active Low */
> +					default-state = "on";
> +				};
> +			};
> +
> +			gpio_keys {
> +				compatible = "gpio-keys";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				button at 1 {
> +					label = "Power Button";
> +					linux,code = <116>;     /* KEY_POWER */
> +					gpios = <&gpio1 30 1>;
> +				};
> +				button at 2 {
> +					label = "Reset Button";
> +					linux,code = <0x198>;   /* KEY_RESTART */
> +					gpios = <&gpio0 6 1>;
> +				};
> +				button at 3 {
> +					label = "Backup Button";
> +					linux,code = <133>;     /* KEY_COPY */
> +					gpios = <&gpio1 26 1>;
> +				};
> +			};
> +
> +			mdio {
> +				phy0: ethernet-phy at 0 {
> +					reg = <0>;
> +				};
> +			};
> +
> +			ethernet at 74000 {
> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii-id";
> +			};
> +
> +			/* Waiting for NAND support to appear in armada-370.dtsi

I would just leave this out until we get the driver sorted.

thx,

Jason.

> +
> +			nand at d0000 {
> +				status = "okay";
> +
> +				partition at 0 {
> +				   label = "u-boot";
> +				   reg = <0x0000000 0x180000>;
> +				   read-only;
> +				};
> +
> +				partition at 180000 {
> +				   label = "u-boot-env";
> +				   reg = <0x180000 0x20000>;
> +				};
> +
> +				partition at 200000 {
> +				   label = "uImage";
> +				   reg = <0x0200000 0x600000>;
> +				};
> +
> +				partition at 800000 {
> +				   label = "minirootfs";
> +				   reg = <0x0800000 0x400000>;
> +				};
> +
> +				partition at c00000 {
> +				   label = "ubi";
> +				   reg = <0x0c00000 0x7400000>;
> +				};
> +			};
> +
> +			*/
> +
> +			usb at 50000 {
> +				status = "okay";
> +			};
> +
> +			clocks {
> +			       #address-cells = <1>;
> +			       #size-cells = <0>;
> +
> +			       g762_clk: fixedclk {
> +					 compatible = "fixed-clock";
> +					 #clock-cells = <0>;
> +					 clock-frequency = <8192>;
> +			       };
> +			};
> +
> +			i2c at 11000 {
> +				compatible = "marvell,mv64xxx-i2c";
> +				clock-frequency = <100000>;
> +				status = "okay";
> +
> +				isl12057: isl12057 at 68 {
> +					compatible = "isil,isl12057";
> +					reg = <0x68>;
> +					wakeup-source;
> +				};
> +
> +				g762: g762 at 3e {
> +					compatible = "gmt,g762";
> +					reg = <0x3e>;
> +					clocks = <&g762_clk>; /* input clock */
> +					fan_gear_mode = <0>;
> +					fan_startv = <1>;
> +					pwm_polarity = <0>;
> +				};
> +			};
> +
> +			pcie-controller {
> +				status = "okay";
> +
> +				/* Connected to Marvell SATA controller */
> +				pcie at 1,0 {
> +					/* Port 0, Lane 0 */
> +					status = "okay";
> +				};
> +
> +				/* Connected to FL1009 USB 3.0 controller */
> +				pcie at 2,0 {
> +					/* Port 1, Lane 0 */
> +					status = "okay";
> +				};
> +			};
> +		};
> +	};
> +};
> -- 
> 1.8.3.1
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC] Add .dts file for Netgear ReadyNAS 102

[Thomas Petazzoni]

Dear Jason Cooper,

On Tue, 2 Jul 2013 08:46:39 -0400, Jason Cooper wrote:

> > In the end, the main missing part is the NAND but I guess this is the
> > same for all Aramda 370/XP boards and this is not a big issue as it is
> > still possible to interact w/ it via u-boot and install a set of
> > uImage/uInitramfs that way. 
> 
> What's the big blocker for this?  Once this is done, debian should be
> able to add support for this board.  After all, upgrading the kernel and
> initrd from userspace is a desirable option.

The big blocker is that no-one has written  the driver for it. It is
still on our (Free Electrons) TODO-list, but not as a top-priority item
for the moment.

Ezequiel had started to do some preliminary cleanup work on the
pxa3xx-nand driver, with the ultimate goal of making it support Armada
370/XP (because the IP in the Armada 370/XP is apparently an evolution
of the PXA3xx NAND controller), but our priorities shifted to those
other topics. We will back on it some day, but I can't say when at the
moment.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

Thomas,

On Tue, Jul 02, 2013 at 03:14:07PM +0200, Thomas Petazzoni wrote:
> On Tue, 2 Jul 2013 08:46:39 -0400, Jason Cooper wrote:
> > > In the end, the main missing part is the NAND but I guess this is the
> > > same for all Aramda 370/XP boards and this is not a big issue as it is
> > > still possible to interact w/ it via u-boot and install a set of
> > > uImage/uInitramfs that way. 
> > 
> > What's the big blocker for this?  Once this is done, debian should be
> > able to add support for this board.  After all, upgrading the kernel and
> > initrd from userspace is a desirable option.
> 
> The big blocker is that no-one has written  the driver for it. It is
> still on our (Free Electrons) TODO-list, but not as a top-priority item
> for the moment.

Ok.

> Ezequiel had started to do some preliminary cleanup work on the
> pxa3xx-nand driver, with the ultimate goal of making it support Armada
> 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> of the PXA3xx NAND controller), but our priorities shifted to those
> other topics. We will back on it some day, but I can't say when at the
> moment.

Is this under contract?  If so, I don't want to take it from you.  If it
isn't, perhaps Ezequiel and Arnaud could mind-meld?

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Thomas Petazzoni]

Dear Jason Cooper,

On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:

> > The big blocker is that no-one has written  the driver for it. It is
> > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > for the moment.
> 
> Ok.
> 
> > Ezequiel had started to do some preliminary cleanup work on the
> > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > of the PXA3xx NAND controller), but our priorities shifted to those
> > other topics. We will back on it some day, but I can't say when at the
> > moment.
> 
> Is this under contract?  If so, I don't want to take it from you.  If it
> isn't, perhaps Ezequiel and Arnaud could mind-meld?

The big problem is that the Armada 370 and Armada XP datasheets are
still only available under NDA, so it's quite hard for someone to step
up and do this, without access to those datasheets.

It used to be on our TODO-list, but isn't any longer, and I have no
informations about when it will re-appear on our TODO-list at this
point.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Tue, Jul 02, 2013 at 03:38:25PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:
> 
> > > The big blocker is that no-one has written  the driver for it. It is
> > > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > > for the moment.
> > 
> > Ok.
> > 
> > > Ezequiel had started to do some preliminary cleanup work on the
> > > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > > of the PXA3xx NAND controller), but our priorities shifted to those
> > > other topics. We will back on it some day, but I can't say when at the
> > > moment.
> > 
> > Is this under contract?  If so, I don't want to take it from you.  If it
> > isn't, perhaps Ezequiel and Arnaud could mind-meld?
> 
> The big problem is that the Armada 370 and Armada XP datasheets are
> still only available under NDA, so it's quite hard for someone to step
> up and do this, without access to those datasheets.

bummer.

> It used to be on our TODO-list, but isn't any longer, and I have no
> informations about when it will re-appear on our TODO-list at this
> point.

So, Arnaud, how do you feel about tackling the nand driver based on the
sources you have and the pointers above?

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

On Tue, Jul 02, 2013 at 09:44:21AM -0400, Jason Cooper wrote:
> On Tue, Jul 02, 2013 at 03:38:25PM +0200, Thomas Petazzoni wrote:
> > Dear Jason Cooper,
> > 
> > On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:
> > 
> > > > The big blocker is that no-one has written  the driver for it. It is
> > > > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > > > for the moment.
> > > 
> > > Ok.
> > > 
> > > > Ezequiel had started to do some preliminary cleanup work on the
> > > > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > > > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > > > of the PXA3xx NAND controller), but our priorities shifted to those
> > > > other topics. We will back on it some day, but I can't say when at the
> > > > moment.
> > > 
> > > Is this under contract?  If so, I don't want to take it from you.  If it
> > > isn't, perhaps Ezequiel and Arnaud could mind-meld?
> > 
> > The big problem is that the Armada 370 and Armada XP datasheets are
> > still only available under NDA, so it's quite hard for someone to step
> > up and do this, without access to those datasheets.
> 
> bummer.
> 
> > It used to be on our TODO-list, but isn't any longer, and I have no
> > informations about when it will re-appear on our TODO-list at this
> > point.
> 
> So, Arnaud, how do you feel about tackling the nand driver based on the
> sources you have and the pointers above?

BTW if that can help, I already have a working port of the driver that is
present in Marvell's kernel. The port is absolutely ugly, it's plain copy
paste of the HAL parts that I needed until it built and booted. It worked
on my mirabox with 3.8. I know it doesn't work since recently (I believe
since introduction of the mbus driver) though I haven't had time to check
why yet. The advantage of such an ugly work is that I'm sure that it will
never be merged into mainline :-)

Regards,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Tue, Jul 02, 2013 at 03:49:47PM +0200, Willy Tarreau wrote:
> On Tue, Jul 02, 2013 at 09:44:21AM -0400, Jason Cooper wrote:
> > On Tue, Jul 02, 2013 at 03:38:25PM +0200, Thomas Petazzoni wrote:
> > > Dear Jason Cooper,
> > > 
> > > On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:
> > > 
> > > > > The big blocker is that no-one has written  the driver for it. It is
> > > > > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > > > > for the moment.
> > > > 
> > > > Ok.
> > > > 
> > > > > Ezequiel had started to do some preliminary cleanup work on the
> > > > > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > > > > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > > > > of the PXA3xx NAND controller), but our priorities shifted to those
> > > > > other topics. We will back on it some day, but I can't say when at the
> > > > > moment.
> > > > 
> > > > Is this under contract?  If so, I don't want to take it from you.  If it
> > > > isn't, perhaps Ezequiel and Arnaud could mind-meld?
> > > 
> > > The big problem is that the Armada 370 and Armada XP datasheets are
> > > still only available under NDA, so it's quite hard for someone to step
> > > up and do this, without access to those datasheets.
> > 
> > bummer.
> > 
> > > It used to be on our TODO-list, but isn't any longer, and I have no
> > > informations about when it will re-appear on our TODO-list at this
> > > point.
> > 
> > So, Arnaud, how do you feel about tackling the nand driver based on the
> > sources you have and the pointers above?
> 
> BTW if that can help, I already have a working port of the driver that is
> present in Marvell's kernel. The port is absolutely ugly, it's plain copy
> paste of the HAL parts that I needed until it built and booted. It worked
> on my mirabox with 3.8. I know it doesn't work since recently (I believe
> since introduction of the mbus driver) though I haven't had time to check
> why yet. The advantage of such an ugly work is that I'm sure that it will
> never be merged into mainline :-)

Could you post a branch somewhere for us to look at?  Or, just post it
RFC in all it's ugly glory :)  Hopefully, there's enough hints in there
to give us a good idea of what needs changed in pxa33xx-nand.

thx,

Jason.
> 
> Regards,
> Willy
> 

[RFC] Add .dts file for Netgear ReadyNAS 102

[Arnaud Ebalard]

Hi,

Jason Cooper <jason@lakedaemon.net> writes:

>> The big problem is that the Armada 370 and Armada XP datasheets are
>> still only available under NDA, so it's quite hard for someone to step
>> up and do this, without access to those datasheets.
>
> bummer.
>
>> It used to be on our TODO-list, but isn't any longer, and I have no
>> informations about when it will re-appear on our TODO-list at this
>> point.
>
> So, Arnaud, how do you feel about tackling the nand driver based on the
> sources you have and the pointers above?

Sadly, I do not have enough spare time to work on this: at the moment, I
intend to focus on writing a clean driver for ISL 12057 RTC/Alarm chip
and get it accepted for 3.12.

Cheers,

a+

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Tue, Jul 02, 2013 at 07:22:34PM +0200, Arnaud Ebalard wrote:
> Hi,
> 
> Jason Cooper <jason@lakedaemon.net> writes:
> 
> >> The big problem is that the Armada 370 and Armada XP datasheets are
> >> still only available under NDA, so it's quite hard for someone to step
> >> up and do this, without access to those datasheets.
> >
> > bummer.
> >
> >> It used to be on our TODO-list, but isn't any longer, and I have no
> >> informations about when it will re-appear on our TODO-list at this
> >> point.
> >
> > So, Arnaud, how do you feel about tackling the nand driver based on the
> > sources you have and the pointers above?
> 
> Sadly, I do not have enough spare time to work on this: at the moment, I
> intend to focus on writing a clean driver for ISL 12057 RTC/Alarm chip
> and get it accepted for 3.12.

more bummer.  Willy, mind posting what you have?  Arnaud, do you have a
link to the source code for your device?  And have you found the code
they started with?

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Arnaud Ebalard]

Hi,

Jason Cooper <jason@lakedaemon.net> writes:

> On Tue, Jul 02, 2013 at 07:22:34PM +0200, Arnaud Ebalard wrote:
>> Hi,
>> 
>> Jason Cooper <jason@lakedaemon.net> writes:
>> 
>> >> The big problem is that the Armada 370 and Armada XP datasheets are
>> >> still only available under NDA, so it's quite hard for someone to step
>> >> up and do this, without access to those datasheets.
>> >
>> > bummer.
>> >
>> >> It used to be on our TODO-list, but isn't any longer, and I have no
>> >> informations about when it will re-appear on our TODO-list at this
>> >> point.
>> >
>> > So, Arnaud, how do you feel about tackling the nand driver based on the
>> > sources you have and the pointers above?
>> 
>> Sadly, I do not have enough spare time to work on this: at the moment, I
>> intend to focus on writing a clean driver for ISL 12057 RTC/Alarm chip
>> and get it accepted for 3.12.
>
> more bummer.  Willy, mind posting what you have?  Arnaud, do you have a
> link to the source code for your device?  And have you found the code
> they started with?

The code NETGEAR provides for ReadyNAS 102 is a (lightly) modified
version of KW40 LSP release 3.1.0-NQ. This is basically a 3.0.X kernel
(X=6 for Marvell LSP, X=56 in NETGEAR's tarball), with some 1,133,970
(no typo) lines patches on top of it:

 http://www.readynas.com/download/GPL/other/linux-ntgr-3.0.56.tar.xz

A quick look provides the following:

$ wc -l arch/arm/plat-armada/mv_drivers_lsp/mv_mtd/nand_nfc.c 
1761 arch/arm/plat-armada/mv_drivers_lsp/mv_mtd/nand_nfc.c

$ head -10 arch/arm/plat-armada/mv_drivers_lsp/mv_mtd/nand_nfc.c 
/*
 * nand_nfc.c
 *
 * Copyright c 2005 Intel Corporation
 * Copyright c 2006 Marvell International Ltd.
 *
 * This driver is based on the PXA drivers/mtd/nand/pxa3xx_nand.c
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as

Which matches what Thomas wrote in a previous email regarding pwa3xx
base. 

Cheers,

a+

[RFC] Add .dts file for Netgear ReadyNAS 102

[Ezequiel Garcia]

Hi guys,

I feel I might share some of my findings when I worked on this,
in the hope it's useful for anyone.

On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> > 
> > Which matches what Thomas wrote in a previous email regarding pwa3xx
> > base. 
> 
> Yes and indeed I must say that when I read the driver I found some
> similarities with pxa3xx, though it was done differently. I initially
> wanted to try to merge them but of course without the spec it's a huge
> waste of time, especially considering that this is still in the roadmap
> of the Free Electrons guys even though low priority.
> 

I wish I could say I'm going to work on this soon but, as Thomas said,
we have no idea when/if NAND will be prioritized.

On the other side if you look at the driver Willy just posted, merging
the juicy stuff into pxa3xx-nand driver is not for the faint of heart.

Without the spec, is only tougher.

Just a quick hint. As far as I can recall, one of the first items in a
TODO list should be:

 * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
   Willy's posted driver might be helpful to accomplish this;
   provided your eyes don't melt when you look at it :-)

 * once the above is done, bad block management can/should be added.

With these two we're almost there for R/W support.

> Since I'm now flashing a rootfs from within u-boot, support for the
> NAND is of less importance to me than what it used to, but I have no
> problem with helping with my very limited time. I have 3 machines
> with this controller (mirabox, openblocks AX3, and an XP-GP, though

With my latest patches pxa3xx-nand should at least *detect* the NAND
device in XP-GP. Doesn't work for Mirabox, though.

> the AX3 only has NOR IIRC). I can do some tests if you manage to get
> the driver to work again.
> 
> Be very careful when playing with this, the driver expects the partition
> table to be passed from u-boot as "armada_nand", and if it uses the wrong
> partition layout, you can be certain that ubifs will destroy them at the
> first mount attempt. That's how I initially bricked my mirabox and did so
> repeatedly. Better keep a copy before booting the patched kernel!
> 
> Another point, I had to add a new entry for the Micro 8Gb flash of the
> mirabox, maybe you won't need it or maybe you'll need a different one.
> 

Just a note about this. You need that entry because your driver doesn't
support ONFI-detected flash devices. You could workaround that, by
adding support simple command. I did it for pxa3xx-nand recently:

"mtd: nand: pxa3xx: Add address support for READID command"
http://permalink.gmane.org/gmane.linux.drivers.mtd/46606

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

Hi Ezequiel,

On Tue, Jul 02, 2013 at 08:23:12PM -0300, Ezequiel Garcia wrote:
> > Yes and indeed I must say that when I read the driver I found some
> > similarities with pxa3xx, though it was done differently. I initially
> > wanted to try to merge them but of course without the spec it's a huge
> > waste of time, especially considering that this is still in the roadmap
> > of the Free Electrons guys even though low priority.
> 
> I wish I could say I'm going to work on this soon but, as Thomas said,
> we have no idea when/if NAND will be prioritized.
> 
> On the other side if you look at the driver Willy just posted, merging
> the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> 
> Without the spec, is only tougher.

Confirmed :-)

> Just a quick hint. As far as I can recall, one of the first items in a
> TODO list should be:
> 
>  * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
>    Willy's posted driver might be helpful to accomplish this;
>    provided your eyes don't melt when you look at it :-)
> 
>  * once the above is done, bad block management can/should be added.
> 
> With these two we're almost there for R/W support.

Since the driver I posted is poorly commented, I'm not even sure it
will be easy to spot the relevant parts in it.

> > Since I'm now flashing a rootfs from within u-boot, support for the
> > NAND is of less importance to me than what it used to, but I have no
> > problem with helping with my very limited time. I have 3 machines
> > with this controller (mirabox, openblocks AX3, and an XP-GP, though
> 
> With my latest patches pxa3xx-nand should at least *detect* the NAND
> device in XP-GP. Doesn't work for Mirabox, though.

OK good to know!

> > the AX3 only has NOR IIRC). I can do some tests if you manage to get
> > the driver to work again.
> > 
> > Be very careful when playing with this, the driver expects the partition
> > table to be passed from u-boot as "armada_nand", and if it uses the wrong
> > partition layout, you can be certain that ubifs will destroy them at the
> > first mount attempt. That's how I initially bricked my mirabox and did so
> > repeatedly. Better keep a copy before booting the patched kernel!
> > 
> > Another point, I had to add a new entry for the Micro 8Gb flash of the
> > mirabox, maybe you won't need it or maybe you'll need a different one.
> 
> Just a note about this. You need that entry because your driver doesn't
> support ONFI-detected flash devices. You could workaround that, by
> adding support simple command. I did it for pxa3xx-nand recently:
> 
> "mtd: nand: pxa3xx: Add address support for READID command"
> http://permalink.gmane.org/gmane.linux.drivers.mtd/46606

I remember having seen your patches, I didn't know that it allowed
to use such flashes and now it makes sense because I was surprized
about having to add entries for all possible devices while we're
not even certain that two consecutive versions of a board will use
the same brand of NAND devices.

Thanks for sharing these information, Ezequiel!

Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Ezequiel Garcia]

Hi everyone,

On Wed, Jul 03, 2013 at 06:33:30AM +0200, Willy Tarreau wrote:
> 
> On Tue, Jul 02, 2013 at 08:23:12PM -0300, Ezequiel Garcia wrote:
> > > Yes and indeed I must say that when I read the driver I found some
> > > similarities with pxa3xx, though it was done differently. I initially
> > > wanted to try to merge them but of course without the spec it's a huge
> > > waste of time, especially considering that this is still in the roadmap
> > > of the Free Electrons guys even though low priority.
> > 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> > 
> > On the other side if you look at the driver Willy just posted, merging
> > the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> > 
> > Without the spec, is only tougher.
> 
> Confirmed :-)
> 

Just a note on the (lack of) documentation issue.

If there's a brave soul reading this and longing to tackle this,
the pxa3xx SoC documentation *is* publicly available:

http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip

The NAND specifications can be found in the "[...] Vol. II: Memory Controller" document,
inside the above zip file. IMHO, that's the reading entry point in order to
understand pxa3xx-nand driver better.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

Hi Ezequiel,

On Wed, Jul 03, 2013 at 07:33:24PM -0300, Ezequiel Garcia wrote:
> Hi everyone,
> 
> On Wed, Jul 03, 2013 at 06:33:30AM +0200, Willy Tarreau wrote:
> > 
> > On Tue, Jul 02, 2013 at 08:23:12PM -0300, Ezequiel Garcia wrote:
> > > > Yes and indeed I must say that when I read the driver I found some
> > > > similarities with pxa3xx, though it was done differently. I initially
> > > > wanted to try to merge them but of course without the spec it's a huge
> > > > waste of time, especially considering that this is still in the roadmap
> > > > of the Free Electrons guys even though low priority.
> > > 
> > > I wish I could say I'm going to work on this soon but, as Thomas said,
> > > we have no idea when/if NAND will be prioritized.
> > > 
> > > On the other side if you look at the driver Willy just posted, merging
> > > the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> > > 
> > > Without the spec, is only tougher.
> > 
> > Confirmed :-)
> > 
> 
> Just a note on the (lack of) documentation issue.
> 
> If there's a brave soul reading this and longing to tackle this,
> the pxa3xx SoC documentation *is* publicly available:
> 
> http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
>
> The NAND specifications can be found in the "[...] Vol. II: Memory Controller" document,
> inside the above zip file. IMHO, that's the reading entry point in order to
> understand pxa3xx-nand driver better.

Yes I have this one as well, but initially since I was not really sure
about the ressemblance of the two controllers, I did not spend too much
time on it. Now probably it can be useful, especially if we use your
existing work as a complement of information :-)

Best regards,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Thomas Petazzoni]

Hello,

On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:

> I wish I could say I'm going to work on this soon but, as Thomas said,
> we have no idea when/if NAND will be prioritized.
> 
> On the other side if you look at the driver Willy just posted, merging
> the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> 
> Without the spec, is only tougher.
> 
> Just a quick hint. As far as I can recall, one of the first items in a
> TODO list should be:
> 
>  * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
>    Willy's posted driver might be helpful to accomplish this;
>    provided your eyes don't melt when you look at it :-)
> 
>  * once the above is done, bad block management can/should be added.
> 
> With these two we're almost there for R/W support.

Wasn't also part of the TODO-list to make pxa3xx_nand divorce from the
PXA-specific DMA API, and use instead the PXA dmaengine driver, through
the DMA engine API? As far as I remember, this was one of the
prerequisite to be able to re-use the driver in a non-PXA context.
There is a patch that was floating around doing this conversion (I
could dig the relevant link if needed), but of course it needs to be
tested, and we don't have PXA3xx hardware, so making changes to this
driver without breaking it is quite tedious.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC] Add .dts file for Netgear ReadyNAS 102

[Ezequiel Garcia]

On Wed, Jul 03, 2013 at 09:42:03AM +0200, Thomas Petazzoni wrote:
> On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:
> 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> > 
> > On the other side if you look at the driver Willy just posted, merging
> > the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> > 
> > Without the spec, is only tougher.
> > 
> > Just a quick hint. As far as I can recall, one of the first items in a
> > TODO list should be:
> > 
> >  * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
> >    Willy's posted driver might be helpful to accomplish this;
> >    provided your eyes don't melt when you look at it :-)
> > 
> >  * once the above is done, bad block management can/should be added.
> > 
> > With these two we're almost there for R/W support.
> 
> Wasn't also part of the TODO-list to make pxa3xx_nand divorce from the
> PXA-specific DMA API, and use instead the PXA dmaengine driver, through
> the DMA engine API? As far as I remember, this was one of the
> prerequisite to be able to re-use the driver in a non-PXA context.
> There is a patch that was floating around doing this conversion (I
> could dig the relevant link if needed), but of course it needs to be
> tested, and we don't have PXA3xx hardware, so making changes to this
> driver without breaking it is quite tedious.
> 

Well that conversion is not *strictly* needed to get R/W support.
AFAICR, you just need to add some nasty ifdefs around the
mach-pxa-specific headers.

The conversion you mention is needed to have DMA on platforms
other than pxa.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

Hi Thomas,

On Wed, Jul 03, 2013 at 09:42:03AM +0200, Thomas Petazzoni wrote:
> Wasn't also part of the TODO-list to make pxa3xx_nand divorce from the
> PXA-specific DMA API, and use instead the PXA dmaengine driver, through
> the DMA engine API? As far as I remember, this was one of the
> prerequisite to be able to re-use the driver in a non-PXA context.
> There is a patch that was floating around doing this conversion (I
> could dig the relevant link if needed), but of course it needs to be
> tested, and we don't have PXA3xx hardware, so making changes to this
> driver without breaking it is quite tedious.

Thus I think it would make more sense to split the driver (at least at
the beginning) in order not to risk breaking anything. If the driver is
copy-pasted from pxa3xx, the merge will still be doable later when
someone can test it.

Just my two cents, cause I hate breaking working stuff.

Best regards,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Wed, Jul 03, 2013 at 09:07:53PM +0200, Willy Tarreau wrote:
> Just my two cents, cause I hate breaking working stuff.

If you don't break stuff, how else do you find out how many users you
have? :-P

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

On Wed, Jul 03, 2013 at 03:10:24PM -0400, Jason Cooper wrote:
> On Wed, Jul 03, 2013 at 09:07:53PM +0200, Willy Tarreau wrote:
> > Just my two cents, cause I hate breaking working stuff.
> 
> If you don't break stuff, how else do you find out how many users you
> have? :-P

Yeah good point indeed :-)
I continue to discover 2.4 users exactly for this reason !

Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Wed, Jul 03, 2013 at 09:38:01PM +0200, Willy Tarreau wrote:
> On Wed, Jul 03, 2013 at 03:10:24PM -0400, Jason Cooper wrote:
> > On Wed, Jul 03, 2013 at 09:07:53PM +0200, Willy Tarreau wrote:
> > > Just my two cents, cause I hate breaking working stuff.
> > 
> > If you don't break stuff, how else do you find out how many users you
> > have? :-P
> 
> Yeah good point indeed :-)
> I continue to discover 2.4 users exactly for this reason !

hehe, I first read that as a little less than 2 1/2 users... ;-)

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Thomas Petazzoni]

Hello guys,

On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:

> > Yes and indeed I must say that when I read the driver I found some
> > similarities with pxa3xx, though it was done differently. I initially
> > wanted to try to merge them but of course without the spec it's a huge
> > waste of time, especially considering that this is still in the roadmap
> > of the Free Electrons guys even though low priority.
> > 
> 
> I wish I could say I'm going to work on this soon but, as Thomas said,
> we have no idea when/if NAND will be prioritized.

We've got some news. NAND is back into the list of priorities, Ezequiel
should restart working on NAND support relatively soon.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

On Thu, Jul 04, 2013 at 03:59:51PM +0200, Thomas Petazzoni wrote:
> Hello guys,
> 
> On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:
> 
> > > Yes and indeed I must say that when I read the driver I found some
> > > similarities with pxa3xx, though it was done differently. I initially
> > > wanted to try to merge them but of course without the spec it's a huge
> > > waste of time, especially considering that this is still in the roadmap
> > > of the Free Electrons guys even though low priority.
> > > 
> > 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> 
> We've got some news. NAND is back into the list of priorities, Ezequiel
> should restart working on NAND support relatively soon.

Yeah, excellent news! Thanks for keeping us up to date!

Best regards,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Thu, Jul 04, 2013 at 03:59:51PM +0200, Thomas Petazzoni wrote:
> Hello guys,
> 
> On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:
> 
> > > Yes and indeed I must say that when I read the driver I found some
> > > similarities with pxa3xx, though it was done differently. I initially
> > > wanted to try to merge them but of course without the spec it's a huge
> > > waste of time, especially considering that this is still in the roadmap
> > > of the Free Electrons guys even though low priority.
> > > 
> > 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> 
> We've got some news. NAND is back into the list of priorities, Ezequiel
> should restart working on NAND support relatively soon.

Whew!  Thanks for addressing this so quickly Thomas!  Please extend our
thanks to the folks at Marvell as well.

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> Hi,
> 
> On Tue, Jul 02, 2013 at 11:48:08PM +0200, Arnaud Ebalard wrote:
> > > more bummer.  Willy, mind posting what you have?
> 
> Attached. Usual warning "this will destroy your device etc..." comes
> with it.

Thanks Willy!

How much effort would it be to put this pig in drivers/staging?  iirc,
the only rule is that it has to compile...

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

On Wed, Jul 03, 2013 at 04:21:05PM -0400, Jason Cooper wrote:
> On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> > Hi,
> > 
> > On Tue, Jul 02, 2013 at 11:48:08PM +0200, Arnaud Ebalard wrote:
> > > > more bummer.  Willy, mind posting what you have?
> > 
> > Attached. Usual warning "this will destroy your device etc..." comes
> > with it.
> 
> Thanks Willy!
> 
> How much effort would it be to put this pig in drivers/staging?  iirc,
> the only rule is that it has to compile...

I think we should at least get it to work again. Otherwise it's pointless
to pollute the kernel. No way to get any tester if all you get when you
load it is :

  calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
  armada-nand nand.3: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
  drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
  armada-nand: probe of nand.3 failed with error -12

Oh damn, I'm back in the code again trying to fix it now...

Also we must not put it into staging in its current shape as it
patches drivers/mtd. We must first apply Ezequiel's explanation
about the READID command to detect the ONFI flash. I don't know
how long this could take. I remember having noticed this difference
in later drivers that was not there without knowing what it was
about.

What makes me uncomfortable is that we have guys who have started
some clean work and in parallel we're doing some crap which will
discourage Marvell from reprioritizing their work. I'd rather keep
that as an out of tree patch so that nobody there claims that the
NAND driver already exists in the kernel.

Best regards,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Wed, Jul 03, 2013 at 10:35:41PM +0200, Willy Tarreau wrote:
> On Wed, Jul 03, 2013 at 04:21:05PM -0400, Jason Cooper wrote:
> > On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> > > Hi,
> > > 
> > > On Tue, Jul 02, 2013 at 11:48:08PM +0200, Arnaud Ebalard wrote:
> > > > > more bummer.  Willy, mind posting what you have?
> > > 
> > > Attached. Usual warning "this will destroy your device etc..." comes
> > > with it.
> > 
> > Thanks Willy!
> > 
> > How much effort would it be to put this pig in drivers/staging?  iirc,
> > the only rule is that it has to compile...
> 
> I think we should at least get it to work again. Otherwise it's pointless
> to pollute the kernel. No way to get any tester if all you get when you
> load it is :
> 
>   calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
>   armada-nand nand.3: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
>   drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
>   armada-nand: probe of nand.3 failed with error -12
> 
> Oh damn, I'm back in the code again trying to fix it now...

:-)

> Also we must not put it into staging in its current shape as it
> patches drivers/mtd.

Understood.  That's why I was asking.

> We must first apply Ezequiel's explanation
> about the READID command to detect the ONFI flash. I don't know
> how long this could take. I remember having noticed this difference
> in later drivers that was not there without knowing what it was
> about.

Ok.

> What makes me uncomfortable is that we have guys who have started
> some clean work and in parallel we're doing some crap which will
> discourage Marvell from reprioritizing their work. I'd rather keep
> that as an out of tree patch so that nobody there claims that the
> NAND driver already exists in the kernel.

Good point.  I was thinking the exact opposite :-P  "The in tree driver
is crap, we'd better re-prioritize our work before people default to the
crap driver"  However, I agree that your more cynical pov is probably
more correct.

I'd love to see the mirabox etc supported by mainline debian et al, but
it'll have to wait.

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

On Wed, Jul 03, 2013 at 04:44:51PM -0400, Jason Cooper wrote:
> > What makes me uncomfortable is that we have guys who have started
> > some clean work and in parallel we're doing some crap which will
> > discourage Marvell from reprioritizing their work. I'd rather keep
> > that as an out of tree patch so that nobody there claims that the
> > NAND driver already exists in the kernel.
> 
> Good point.  I was thinking the exact opposite :-P  "The in tree driver
> is crap, we'd better re-prioritize our work before people default to the
> crap driver"

Do you really think that people who provide bogus kernel patches to
vendors who sell hardware with unmaintained outdated kernels and many
bugs have anything to care about the quality of the in-kernel driver ?

I'm afraid they simply don't care a dime. I bricked my mirabox a few
days after using it, I hoped to find some JTAG info to write an openocd
driver and found nothing. I asked to apply for an NDA to get access to
this precious data (Most likely the hardware is still in beta and they
don't want the remaining flaws to be unveiled). I did this exactly one
year ago and nothing moved after maybe 20 repeated attempts, nothing
moved. Finally I managed to unbrick it by reversing the boot loader
code and their image generator.

The reality is that they absolutely don't care about their hardware
being supported by mainline since they already have enough customers
who buy their crippled LSP kernel.

> However, I agree that your more cynical pov is probably more correct.
> 
> I'd love to see the mirabox etc supported by mainline debian et al, but
> it'll have to wait.

I would love it too. The platform is good. The mirabox is small and
powerful. The AX3 is absolutely marvelous (no pun intended). I would
love that they once for all understand that they just need to let
developers do the work they barely drafted with their crappy LSP and
become one of the best linux platforms for many SOHO usages. Their
marketing would be better done by their end users and community...
But at the moment, all the makers of these devices have to live with
the idea that their devices are limited by bogus and unstable code
and that their sales suffer from this. Pfff....

OK fixed the driver. The problem was the hard-coded internal register
address which was 0xfeb00000 in previous versions and is 0xfec00000
now.

Now I'm getting this upon modprobe :

calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
armada-nand d00d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
drivers/mtd/nand/armada_nand.c:3324:orion_nfc_probe irq=105
drivers/mtd/nand/armada_nand.c:3332:orion_nfc_probe mmio_base=fecd0000
drivers/mtd/nand/armada_nand.c:3338:orion_nfc_probe base=fecd0000
drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428040a
drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428080a
drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428080a
drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428050a
drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
NAND device: Manufacturer ID: 0x2c, Chip ID: 0x38 (Micron NAND 1GiB 1,8V 8-bit), 1024MiB, page size: 4096, OOB size: 128
Bad block table found at page 262016, version 0x01
Bad block table found at page 261888, version 0x01
6 cmdlinepart partitions found on MTD device armada-nand
Creating 6 MTD partitions on "armada-nand":
0x000000000000-0x000000400000 : "uboot"
0x000000400000-0x000000800000 : "config"
0x000000800000-0x000001000000 : "kernel"
0x000001000000-0x000002000000 : "initrd"
0x000002000000-0x000020000000 : "rootfs"
0x000020000000-0x000040000000 : "pad"
root at mirabox:~# 

I'll tidy up a little bit this ugly thing and resend something to use
as a basis to work on.

Best regards,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

On Wed, Jul 03, 2013 at 11:14:50PM +0200, Willy Tarreau wrote:
> OK fixed the driver. The problem was the hard-coded internal register
> address which was 0xfeb00000 in previous versions and is 0xfec00000
> now.
> 
> Now I'm getting this upon modprobe :
> 
> calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
> armada-nand d00d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
> drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
> drivers/mtd/nand/armada_nand.c:3324:orion_nfc_probe irq=105
> drivers/mtd/nand/armada_nand.c:3332:orion_nfc_probe mmio_base=fecd0000
> drivers/mtd/nand/armada_nand.c:3338:orion_nfc_probe base=fecd0000
> drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428040a
> drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428080a
> drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
> drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
> drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428080a
> drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428050a
> drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
> drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0x38 (Micron NAND 1GiB 1,8V 8-bit), 1024MiB, page size: 4096, OOB size: 128
> Bad block table found at page 262016, version 0x01
> Bad block table found at page 261888, version 0x01
> 6 cmdlinepart partitions found on MTD device armada-nand
> Creating 6 MTD partitions on "armada-nand":
> 0x000000000000-0x000000400000 : "uboot"
> 0x000000400000-0x000000800000 : "config"
> 0x000000800000-0x000001000000 : "kernel"
> 0x000001000000-0x000002000000 : "initrd"
> 0x000002000000-0x000020000000 : "rootfs"
> 0x000020000000-0x000040000000 : "pad"
> root at mirabox:~# 
> 
> I'll tidy up a little bit this ugly thing and resend something to use
> as a basis to work on.

The patch it too large (150kB), last time I received a warning from the ML
because of its size. So I'm putting it here instead :

   http://linux.1wt.eu/kernel/armada-nand/3.10-armada_nand.patch

I've tested it on both my mirabox and the xp-gp board, the same flash is
detected (Micron 1GB) and works on both boards. (BTW, Florian if you read
this, your board has already served its intended purpose :-)).

Among the important things to do that immediately come to mind :

  - implement the READID command as explained by Ezequiel to stop
    patching nand_ids.h

  - remove the hard-coded dependency on INTERNAL_REGS_BASE and
    replace all calls to MV_REG_* with their cleaner equivalents
    found in mvneta.c. This will require passing the nfcCtrl
    pointer all along to have the mmio_base pointer I guess.

  - check if include/linux/mtd/nand.h really needs to be patched
    or if the information put there can be moved somewhere else.

And probably try to help Ezequiel finish the work he began by using
this work as documentation rather than the other way around.

Feel free to host this driver anywhere if you like, I don't have the
time to maintain it, and I don't want to see it merged into the kernel,
we have enough crap and this one certainly qualifies as such.

Oh last important point, I found it in the 2.6.35.9-LSP-1.0.2_gw patch.
If someone finds a more recent one in a more recent kernel, it might be
worth comparing them.

Best regards,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Arnaud Ebalard]

Hi Willy,

Willy Tarreau <w@1wt.eu> writes:

> The patch it too large (150kB), last time I received a warning from the ML
> because of its size.
>
> [snip]
>
> Feel free to host this driver anywhere if you like, I don't have the
> time to maintain it, and I don't want to see it merged into the kernel,
> we have enough crap and this one certainly qualifies as such.

;-)

> Oh last important point, I found it in the 2.6.35.9-LSP-1.0.2_gw patch.
> If someone finds a more recent one in a more recent kernel, it might be
> worth comparing them.

The version in Netgear kernel (a 3.0.56, 25/Apr/2012 KW40 LSP release
3.1.0-NQ) is almost identical to the one in mirabox 2.6.35 kernel
(24/Nov/2011, KW40 LSP release 1.0.2-NQ) if you remove the fixes for
trailing spaces and tabs: 


@@ -1618,7 +1618,9 @@
 		ret = -ENXIO;
 		goto fail_free_irq;
 	}
-	if (mtd_has_partitions()) {
+
+
+#ifdef CONFIG_MTD_CMDLINE_PARTS
 		if (mtd_has_cmdlinepart()) {
 			static const char *probes[] = { "cmdlinepart", NULL };
 			struct mtd_partition *parts;
@@ -1627,12 +1629,11 @@
 			nr_parts = parse_mtd_partitions(mtd, probes, &parts, 0);
 
 			if (nr_parts)
-				return add_mtd_partitions(mtd, parts, nr_parts);
+				return mtd_device_register(mtd, parts, nr_parts);
 		}
-		return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
-	}
-
-	return add_mtd_device(mtd) == 1 ? -ENODEV : 0;
+		return mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
+#endif
+		return (mtd_device_register(mtd, pdata->parts, pdata->nr_parts));
 
 fail_free_irq:
 	free_irq(IRQ_AURORA_NFC, info);
@@ -1661,10 +1662,6 @@
 
 	platform_set_drvdata(pdev, NULL);
 
-	del_mtd_device(mtd);
-#ifdef CONFIG_MTD_PARTITIONS
-	del_mtd_partitions(mtd);
-#endif
 	free_irq(IRQ_AURORA_NFC, info);
 	if (info->use_dma) {
 		dma_free_writecombine(&pdev->dev, info->data_buff_size,
@@ -1675,7 +1672,10 @@
 	clk_disable(info->clk);
 	clk_put(info->clk);
 #endif
-	kfree(mtd);
+	if (mtd) {
+		mtd_device_unregister(mtd);
+		kfree(mtd);
+	}
 	return 0;
 }
 

[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

Hi Arnaud,

On Thu, Jul 04, 2013 at 12:58:10AM +0200, Arnaud Ebalard wrote:
> > Oh last important point, I found it in the 2.6.35.9-LSP-1.0.2_gw patch.
> > If someone finds a more recent one in a more recent kernel, it might be
> > worth comparing them.
> 
> The version in Netgear kernel (a 3.0.56, 25/Apr/2012 KW40 LSP release
> 3.1.0-NQ) is almost identical to the one in mirabox 2.6.35 kernel
> (24/Nov/2011, KW40 LSP release 1.0.2-NQ) if you remove the fixes for
> trailing spaces and tabs: 
> 
> 
> @@ -1618,7 +1618,9 @@
>  		ret = -ENXIO;
>  		goto fail_free_irq;
>  	}
> -	if (mtd_has_partitions()) {
> +
> +
> +#ifdef CONFIG_MTD_CMDLINE_PARTS
>  		if (mtd_has_cmdlinepart()) {
>  			static const char *probes[] = { "cmdlinepart", NULL };
>  			struct mtd_partition *parts;
> @@ -1627,12 +1629,11 @@
>  			nr_parts = parse_mtd_partitions(mtd, probes, &parts, 0);
>  
>  			if (nr_parts)
> -				return add_mtd_partitions(mtd, parts, nr_parts);
> +				return mtd_device_register(mtd, parts, nr_parts);
>  		}
> -		return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
> -	}
> -
> -	return add_mtd_device(mtd) == 1 ? -ENODEV : 0;
> +		return mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
> +#endif
> +		return (mtd_device_register(mtd, pdata->parts, pdata->nr_parts));
>  
>  fail_free_irq:
>  	free_irq(IRQ_AURORA_NFC, info);
> @@ -1661,10 +1662,6 @@
>  
>  	platform_set_drvdata(pdev, NULL);
>  
> -	del_mtd_device(mtd);
> -#ifdef CONFIG_MTD_PARTITIONS
> -	del_mtd_partitions(mtd);
> -#endif
>  	free_irq(IRQ_AURORA_NFC, info);
>  	if (info->use_dma) {
>  		dma_free_writecombine(&pdev->dev, info->data_buff_size,
> @@ -1675,7 +1672,10 @@
>  	clk_disable(info->clk);
>  	clk_put(info->clk);
>  #endif
> -	kfree(mtd);
> +	if (mtd) {
> +		mtd_device_unregister(mtd);
> +		kfree(mtd);
> +	}
>  	return 0;
>  }
 
I had found a 3.5.x version somewhere (don't remember where, maybe an
ubuntu repository) which had the same changes. I had merged the last
hunk above, and other ones were not needed.

Thanks,
Willy

[RFC] Add .dts file for Netgear ReadyNAS 102

[Arnaud Ebalard]

Willy Tarreau <w@1wt.eu> writes:

> What makes me uncomfortable is that we have guys who have started
> some clean work and in parallel we're doing some crap which will
> discourage Marvell from reprioritizing their work.

*FWIW*, +1.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Arnaud Ebalard]

Hi,

Jason Cooper <jason@lakedaemon.net> writes:

>>  - G762 PWM fan controller on I2C bus: it requires G762 driver which
>>    is *currently sitting in hwmon maintainer tree* and will be available
>>    in 3.11. Jason, as a side note I have a short patch for available for
>>    ReadyNAS Duo v2 .dts file (the device also has a G762). I can hold
>>    it until rc cycle if you prefer.
>
> Nope, post patches when you have them ready.  I am capable of holding
> them until -rc1 drops ;-)

That's the one I sent yesterday (the patch tagged RESEND, i.e. w/o the
fixes for space issue in .dts file)


>> Jason, the tests were done against your for-next branch (with all the
>> fixes which accumulated in Linux tree from rc7). I will work directly
>> against Linus tree as soon as the rc- cycle for 3.11 starts. 
>
> hmmm, my latest for-next (20130623) is based against v3.10-rc7, are you
> using that?


Yes, but with just your tree I got some freezes during boot and applying
the additional commits available in Linux tree, this fixed the issue. I
did not spend much the time but I think this is related to
PJ4B_ERRATA_4742 which you do not have in your for-next branch: 

commit 3e0a07f8c401bb43e0f964c5f1285b2cb2028645
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date:   Sun Jun 23 10:17:11 2013 +0100

    ARM: 7773/1: PJ4B: Add support for errata 4742
    
    This commit fixes the regression on Armada 370 (the kernal hang during
    boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
    TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".

    ...


>>  [snip]
>>
>> +
>> +			/* Waiting for NAND support to appear in armada-370.dtsi
>
> I would just leave this out until we get the driver sorted.

ok, will do that in next versions.


>> +			i2c at 11000 {
>> +				compatible = "marvell,mv64xxx-i2c";
>> +				clock-frequency = <100000>;
>> +				status = "okay";
>> +
>> +				isl12057: isl12057 at 68 {
>> +					compatible = "isil,isl12057";
>> +					reg = <0x68>;
>> +					wakeup-source;
>> +				};

My main question is for ISL12057 RTC chip: I guess it's just pointless to
push the .dts file for the RN102 w/o a working RTC clock?

Cheers,

a+

[RFC] Add .dts file for Netgear ReadyNAS 102

[Jason Cooper]

On Tue, Jul 02, 2013 at 07:21:52PM +0200, Arnaud Ebalard wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> 
> >>  - G762 PWM fan controller on I2C bus: it requires G762 driver which
> >>    is *currently sitting in hwmon maintainer tree* and will be available
> >>    in 3.11. Jason, as a side note I have a short patch for available for
> >>    ReadyNAS Duo v2 .dts file (the device also has a G762). I can hold
> >>    it until rc cycle if you prefer.
> >
> > Nope, post patches when you have them ready.  I am capable of holding
> > them until -rc1 drops ;-)
> 
> That's the one I sent yesterday (the patch tagged RESEND, i.e. w/o the
> fixes for space issue in .dts file)

Yep, I have it queued up.

> >> +			i2c at 11000 {
> >> +				compatible = "marvell,mv64xxx-i2c";
> >> +				clock-frequency = <100000>;
> >> +				status = "okay";
> >> +
> >> +				isl12057: isl12057 at 68 {
> >> +					compatible = "isil,isl12057";
> >> +					reg = <0x68>;
> >> +					wakeup-source;
> >> +				};
> 
> My main question is for ISL12057 RTC chip: I guess it's just pointless to
> push the .dts file for the RN102 w/o a working RTC clock?

Not necessarily.  Support for the rtc can be done in a follow on patch
once you have the driver mainlined.

I have a bunch of boards that boot up and think it's 1970...

Afterall, the mirabox doesn't have nand support :-P

thx,

Jason.

[RFC] Add .dts file for Netgear ReadyNAS 102

[Sebastian Hesselbarth]

On 06/30/13 22:59, Arnaud Ebalard wrote:
> Hi,
>
> Here is a .dts file for Armada-370-based Netgear ReadyNAS 102. The
> purpose of this submission is to get some feedback and also some
> directions on how to proceed to get it included at some point.
[...]
> Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
> ---
>   arch/arm/boot/dts/Makefile                     |   1 +
>   arch/arm/boot/dts/armada-370-netgear-rn102.dts | 215 +++++++++++++++++++++++++
>   2 files changed, 216 insertions(+)
>   create mode 100644 arch/arm/boot/dts/armada-370-netgear-rn102.dts
>
[...]
> diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> new file mode 100644
> index 0000000..5a9e129
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> @@ -0,0 +1,215 @@
> +/*
> + * Device Tree file for NETGEAR ReadyNAS 102
> + *
> + * Copyright (C) 2013, Arnaud EBALARD <arno@natisbad.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "armada-370.dtsi"
> +
> +/ {
> +	model = "NETGEAR ReadyNAS 102";
> +	compatible = "netgear,readynas-102", "marvell,armada370", "marvell,armada-370-xp";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x20000000>; /* 512 MB */
> +	};
> +
> +	soc {
> +		internal-regs {
> +			serial at 12000 {
> +				clock-frequency = <200000000>;
> +				status = "okay";
> +			};
> +
> +			sata at a0000 {
> +				nr-ports = <2>;
> +				status = "okay";
> +			};
> +
> +			pinctrl {
> +				power_led_pin: power-led-pin {
> +					marvell,pins = "mpp57";
> +					marvell,function = "gpio";
> +				};
> +				sata1_led_pin: sata1-led-pin {
> +					marvell,pins = "mpp15";
> +					marvell,function = "gpio";
> +				};
> +
> +				sata2_led_pin: sata2-led-pin {
> +					marvell,pins = "mpp14";
> +					marvell,function = "gpio";
> +				};
> +
> +				backup_led_pin: backup-led-pin {
> +					marvell,pins = "mpp56";
> +					marvell,function = "gpio";
> +				};
> +			};
> +
> +			gpio_leds {

Arnaud,

gpio_leds, gpio_keys, and clocks nodes shouldn't be children of
soc/internal-regs. I suggest to move them up as siblings of soc,
memory, and chosen instead.

> +				compatible = "gpio-leds";
> +				pinctrl-0 = < &power_led_pin
> +					      &sata1_led_pin
> +					      &sata2_led_pin
> +					      &backup_led_pin >;
> +				pinctrl-names = "default";
> +
> +				blue_power_led {
> +					label = "rn102:blue:pwr";
> +					gpios = <&gpio1 25 1>;  /* GPIO 57 Active Low */
> +					linux,default-trigger = "heartbeat";
> +				};
> +
> +				green_sata1_led {
> +					label = "rn102:green:sata1";
> +					gpios = <&gpio0 15 1>;  /* GPIO 15 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_sata2_led {
> +					label = "rn102:green:sata2";
> +					gpios = <&gpio0 14 1>;   /* GPIO 14 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_backup_led {
> +					label = "rn102:green:backup";
> +					gpios = <&gpio1 24 1>;   /* GPIO 56 Active Low */
> +					default-state = "on";
> +				};
> +			};
> +
> +			gpio_keys {
> +				compatible = "gpio-keys";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				button at 1 {
> +					label = "Power Button";
> +					linux,code = <116>;     /* KEY_POWER */
> +					gpios = <&gpio1 30 1>;
> +				};
> +				button at 2 {
> +					label = "Reset Button";
> +					linux,code = <0x198>;   /* KEY_RESTART */
> +					gpios = <&gpio0 6 1>;
> +				};
> +				button at 3 {
> +					label = "Backup Button";
> +					linux,code = <133>;     /* KEY_COPY */
> +					gpios = <&gpio1 26 1>;
> +				};
> +			};
> +
> +			mdio {
> +				phy0: ethernet-phy at 0 {
> +					reg = <0>;
> +				};
> +			};
> +
> +			ethernet at 74000 {
> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii-id";
> +			};
> +
> +			/* Waiting for NAND support to appear in armada-370.dtsi
> +
> +			nand at d0000 {
> +				status = "okay";
> +
> +				partition at 0 {
> +				   label = "u-boot";
> +				   reg = <0x0000000 0x180000>;
> +				   read-only;
> +				};
> +
> +				partition at 180000 {
> +				   label = "u-boot-env";
> +				   reg = <0x180000 0x20000>;
> +				};
> +
> +				partition at 200000 {
> +				   label = "uImage";
> +				   reg = <0x0200000 0x600000>;
> +				};
> +
> +				partition at 800000 {
> +				   label = "minirootfs";
> +				   reg = <0x0800000 0x400000>;
> +				};
> +
> +				partition at c00000 {
> +				   label = "ubi";
> +				   reg = <0x0c00000 0x7400000>;
> +				};
> +			};
> +
> +			*/
> +
> +			usb at 50000 {
> +				status = "okay";
> +			};
> +
> +			clocks {
> +			       #address-cells = <1>;
> +			       #size-cells = <0>;
> +
> +			       g762_clk: fixedclk {
> +					 compatible = "fixed-clock";
> +					 #clock-cells = <0>;
> +					 clock-frequency = <8192>;
> +			       };
> +			};
> +
> +			i2c at 11000 {
> +				compatible = "marvell,mv64xxx-i2c";
> +				clock-frequency = <100000>;
> +				status = "okay";
> +
> +				isl12057: isl12057 at 68 {
> +					compatible = "isil,isl12057";
> +					reg = <0x68>;
> +					wakeup-source;
> +				};
> +
> +				g762: g762 at 3e {
> +					compatible = "gmt,g762";
> +					reg = <0x3e>;
> +					clocks = <&g762_clk>; /* input clock */
> +					fan_gear_mode = <0>;
> +					fan_startv = <1>;
> +					pwm_polarity = <0>;
> +				};
> +			};
> +
> +			pcie-controller {
> +				status = "okay";
> +
> +				/* Connected to Marvell SATA controller */
> +				pcie at 1,0 {
> +					/* Port 0, Lane 0 */
> +					status = "okay";
> +				};
> +
> +				/* Connected to FL1009 USB 3.0 controller */
> +				pcie at 2,0 {
> +					/* Port 1, Lane 0 */
> +					status = "okay";
> +				};
> +			};
> +		};
> +	};
> +};
>

[RFC] Add .dts file for Netgear ReadyNAS 102

[Arnaud Ebalard]

Hi,

Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> writes:

>> +			pinctrl {
>> +				power_led_pin: power-led-pin {
>> +					marvell,pins = "mpp57";
>> +					marvell,function = "gpio";
>> +				};
>> +				sata1_led_pin: sata1-led-pin {
>> +					marvell,pins = "mpp15";
>> +					marvell,function = "gpio";
>> +				};
>> +
>> +				sata2_led_pin: sata2-led-pin {
>> +					marvell,pins = "mpp14";
>> +					marvell,function = "gpio";
>> +				};
>> +
>> +				backup_led_pin: backup-led-pin {
>> +					marvell,pins = "mpp56";
>> +					marvell,function = "gpio";
>> +				};
>> +			};
>> +
>> +			gpio_leds {
>
> Arnaud,
>
> gpio_leds, gpio_keys, and clocks nodes shouldn't be children of
> soc/internal-regs. I suggest to move them up as siblings of soc,
> memory, and chosen instead.

Will do that in next round. Thanks for pointing it.

Cheers,

a+