| Message ID | 87fvvzfh70.fsf@natisbad.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@12000 { > + clock-frequency = <200000000>; > + status = "okay"; > + }; > + > + sata@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@1 { > + label = "Power Button"; > + linux,code = <116>; /* KEY_POWER */ > + gpios = <&gpio1 30 1>; > + }; > + button@2 { > + label = "Reset Button"; > + linux,code = <0x198>; /* KEY_RESTART */ > + gpios = <&gpio0 6 1>; > + }; > + button@3 { > + label = "Backup Button"; > + linux,code = <133>; /* KEY_COPY */ > + gpios = <&gpio1 26 1>; > + }; > + }; > + > + mdio { > + phy0: ethernet-phy@0 { > + reg = <0>; > + }; > + }; > + > + ethernet@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@d0000 { > + status = "okay"; > + > + partition@0 { > + label = "u-boot"; > + reg = <0x0000000 0x180000>; > + read-only; > + }; > + > + partition@180000 { > + label = "u-boot-env"; > + reg = <0x180000 0x20000>; > + }; > + > + partition@200000 { > + label = "uImage"; > + reg = <0x0200000 0x600000>; > + }; > + > + partition@800000 { > + label = "minirootfs"; > + reg = <0x0800000 0x400000>; > + }; > + > + partition@c00000 { > + label = "ubi"; > + reg = <0x0c00000 0x7400000>; > + }; > + }; > + > + */ > + > + usb@50000 { > + status = "okay"; > + }; > + > + clocks { > + #address-cells = <1>; > + #size-cells = <0>; > + > + g762_clk: fixedclk { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <8192>; > + }; > + }; > + > + i2c@11000 { > + compatible = "marvell,mv64xxx-i2c"; > + clock-frequency = <100000>; > + status = "okay"; > + > + isl12057: isl12057@68 { > + compatible = "isil,isl12057"; > + reg = <0x68>; > + wakeup-source; > + }; > + > + g762: g762@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@1,0 { > + /* Port 0, Lane 0 */ > + status = "okay"; > + }; > + > + /* Connected to FL1009 USB 3.0 controller */ > + pcie@2,0 { > + /* Port 1, Lane 0 */ > + status = "okay"; > + }; > + }; > + }; > + }; > +}; > -- > 1.8.3.1 > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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, 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.
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
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.
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@12000 { > + clock-frequency = <200000000>; > + status = "okay"; > + }; > + > + sata@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@1 { > + label = "Power Button"; > + linux,code = <116>; /* KEY_POWER */ > + gpios = <&gpio1 30 1>; > + }; > + button@2 { > + label = "Reset Button"; > + linux,code = <0x198>; /* KEY_RESTART */ > + gpios = <&gpio0 6 1>; > + }; > + button@3 { > + label = "Backup Button"; > + linux,code = <133>; /* KEY_COPY */ > + gpios = <&gpio1 26 1>; > + }; > + }; > + > + mdio { > + phy0: ethernet-phy@0 { > + reg = <0>; > + }; > + }; > + > + ethernet@74000 { > + status = "okay"; > + phy = <&phy0>; > + phy-mode = "rgmii-id"; > + }; > + > + /* Waiting for NAND support to appear in armada-370.dtsi > + > + nand@d0000 { > + status = "okay"; > + > + partition@0 { > + label = "u-boot"; > + reg = <0x0000000 0x180000>; > + read-only; > + }; > + > + partition@180000 { > + label = "u-boot-env"; > + reg = <0x180000 0x20000>; > + }; > + > + partition@200000 { > + label = "uImage"; > + reg = <0x0200000 0x600000>; > + }; > + > + partition@800000 { > + label = "minirootfs"; > + reg = <0x0800000 0x400000>; > + }; > + > + partition@c00000 { > + label = "ubi"; > + reg = <0x0c00000 0x7400000>; > + }; > + }; > + > + */ > + > + usb@50000 { > + status = "okay"; > + }; > + > + clocks { > + #address-cells = <1>; > + #size-cells = <0>; > + > + g762_clk: fixedclk { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <8192>; > + }; > + }; > + > + i2c@11000 { > + compatible = "marvell,mv64xxx-i2c"; > + clock-frequency = <100000>; > + status = "okay"; > + > + isl12057: isl12057@68 { > + compatible = "isil,isl12057"; > + reg = <0x68>; > + wakeup-source; > + }; > + > + g762: g762@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@1,0 { > + /* Port 0, Lane 0 */ > + status = "okay"; > + }; > + > + /* Connected to FL1009 USB 3.0 controller */ > + pcie@2,0 { > + /* Port 1, Lane 0 */ > + status = "okay"; > + }; > + }; > + }; > + }; > +}; >
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
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 >
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@11000 { >> + compatible = "marvell,mv64xxx-i2c"; >> + clock-frequency = <100000>; >> + status = "okay"; >> + >> + isl12057: isl12057@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+
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+
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@11000 { > >> + compatible = "marvell,mv64xxx-i2c"; > >> + clock-frequency = <100000>; > >> + status = "okay"; > >> + > >> + isl12057: isl12057@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.
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.
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+
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,
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+
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
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
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.
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
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.
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
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.
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.
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
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.
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.
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@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
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@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
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.
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
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; }
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
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
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
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.
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@12000 { + clock-frequency = <200000000>; + status = "okay"; + }; + + sata@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@1 { + label = "Power Button"; + linux,code = <116>; /* KEY_POWER */ + gpios = <&gpio1 30 1>; + }; + button@2 { + label = "Reset Button"; + linux,code = <0x198>; /* KEY_RESTART */ + gpios = <&gpio0 6 1>; + }; + button@3 { + label = "Backup Button"; + linux,code = <133>; /* KEY_COPY */ + gpios = <&gpio1 26 1>; + }; + }; + + mdio { + phy0: ethernet-phy@0 { + reg = <0>; + }; + }; + + ethernet@74000 { + status = "okay"; + phy = <&phy0>; + phy-mode = "rgmii-id"; + }; + + /* Waiting for NAND support to appear in armada-370.dtsi + + nand@d0000 { + status = "okay"; + + partition@0 { + label = "u-boot"; + reg = <0x0000000 0x180000>; + read-only; + }; + + partition@180000 { + label = "u-boot-env"; + reg = <0x180000 0x20000>; + }; + + partition@200000 { + label = "uImage"; + reg = <0x0200000 0x600000>; + }; + + partition@800000 { + label = "minirootfs"; + reg = <0x0800000 0x400000>; + }; + + partition@c00000 { + label = "ubi"; + reg = <0x0c00000 0x7400000>; + }; + }; + + */ + + usb@50000 { + status = "okay"; + }; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + g762_clk: fixedclk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <8192>; + }; + }; + + i2c@11000 { + compatible = "marvell,mv64xxx-i2c"; + clock-frequency = <100000>; + status = "okay"; + + isl12057: isl12057@68 { + compatible = "isil,isl12057"; + reg = <0x68>; + wakeup-source; + }; + + g762: g762@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@1,0 { + /* Port 0, Lane 0 */ + status = "okay"; + }; + + /* Connected to FL1009 USB 3.0 controller */ + pcie@2,0 { + /* Port 1, Lane 0 */ + status = "okay"; + }; + }; + }; + }; +};
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