Add .dts file for Netgear ReadyNAS 102
RFC 1/1 Add .dts file for Netgear ReadyNAS 102
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+
--- 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
arch/arm/boot/dts/Makefile +1 -0
@@ -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 \
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +215 -0
215 lines not on this page · raw message
Signature · 1 line
1.8.3.1
Arnaud,
Quoted 3 lines · Arnaud Ebalard
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!
Quoted 12 lines
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
Quoted 5 lines
- 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 ;-)
Quoted 8 lines
- 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.
Quoted 3 lines
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?
Quoted 3 lines
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.
Quoted 143 lines
Signed-off-by Arnaud Ebalard <[email protected]>--- 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.dtsarch/arm/boot/dts/Makefile +1
-0@@ -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 \arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +118
-0@@ -0,0 +1,215 @@ +/* + * Device Tree file for NETGEAR ReadyNAS 102 + * + * Copyright (C) 2013, Arnaud EBALARD <[email protected]> + * + * 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>;
arch/arm/boot/dts/armada-370-netgear-rn102.dts line 128
Quoted 10 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +10
-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.
Quoted 96 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +87
-0+ + 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"; + }; + }; + }; + }; +};Signature · 8 lines
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
Dear Jason Cooper,
Quoted 8 lines · Jason Cooper
Quoted 4 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Thomas,
Quoted 6 lines · Thomas Petazzoni
Quoted 5 lines · Jason Cooper
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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,
Quoted 13 lines · Jason Cooper
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 17 lines · Thomas Petazzoni
Dear Jason Cooper,
Quoted 13 lines · Jason Cooper
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 25 lines · Jason Cooper
Quoted 17 lines · Thomas Petazzoni
Dear Jason Cooper,
Quoted 13 lines · Jason Cooper
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
bummer.
Quoted 3 lines
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
Quoted 35 lines · Willy Tarreau
Quoted 25 lines · Jason Cooper
Quoted 17 lines · Thomas Petazzoni
Dear Jason Cooper,
Quoted 13 lines · Jason Cooper
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
bummer.
Quoted 3 lines
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?
Quoted 7 lines
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.
Quoted 4 lines
Regards,
Willy
Hi,
Quoted 4 lines · Jason Cooper
Quoted 3 lines
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.
Quoted 8 lines
bummer.
Quoted 3 lines
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+
Quoted 14 lines · Arnaud Ebalard
Hi,
Quoted 10 lines · Jason Cooper
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 2 lines
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,
Quoted 18 lines · Jason Cooper
Quoted 17 lines · Arnaud Ebalard
Hi,
Quoted 12 lines · Jason Cooper
Quoted 3 lines
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.
Quoted 3 lines
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?
Quoted 7 lines
Quoted 3 lines
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+
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi guys,
I feel I might share some of my findings when I worked on this, in the hope it's useful for anyone.
Quoted 10 lines · Willy Tarreau
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 12 lines
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,
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
Hi Ezequiel,
Quoted 6 lines · Ezequiel Garcia
Quoted 5 lines
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.
Quoted 7 lines
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 :-)
Quoted 10 lines
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 12 lines
Quoted 11 lines
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.
Quoted 6 lines
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
Hi everyone,
Quoted 11 lines · Willy Tarreau
Quoted 9 lines · Ezequiel Garcia
Quoted 5 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
Hi Ezequiel,
Quoted 24 lines · Ezequiel Garcia
Hi everyone,
Quoted 11 lines · Willy Tarreau
Quoted 9 lines · Ezequiel Garcia
Quoted 5 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
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
Hello,
Quoted 11 lines · Ezequiel Garcia
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:
Quoted 7 lines
* 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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 21 lines · Thomas Petazzoni
Quoted 11 lines · Ezequiel Garcia
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:
Quoted 7 lines
* 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.
Quoted 9 lines
Wasn't also part of the TODO-list to make
pxa3xx_nanddivorce 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.
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
Hi Thomas,
Quoted 8 lines · Thomas Petazzoni
Wasn't also part of the TODO-list to make
pxa3xx_nanddivorce 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
Quoted 1 line · Willy Tarreau
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.
Quoted 5 lines · Jason Cooper
Quoted 1 line · Willy Tarreau
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
Quoted 9 lines · Willy Tarreau
Quoted 5 lines · Jason Cooper
Quoted 1 line · Willy Tarreau
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.
Hello guys,
Quoted 9 lines · Ezequiel Garcia
Quoted 6 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 11 lines · Thomas Petazzoni
Hello guys,
Quoted 7 lines · Ezequiel Garcia
Quoted 6 lines
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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 11 lines · Thomas Petazzoni
Hello guys,
Quoted 7 lines · Ezequiel Garcia
Quoted 6 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 7 lines · Willy Tarreau
Hi,
Quoted 1 line · Arnaud Ebalard
Quoted 1 line
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.
Quoted 6 lines · Jason Cooper
Quoted 5 lines · Willy Tarreau
Hi,
Quoted 1 line · Arnaud Ebalard
Quoted 1 line
more bummer. Willy, mind posting what you have?
Quoted 7 lines
Quoted 2 lines
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
Quoted 19 lines · Willy Tarreau
Quoted 6 lines · Jason Cooper
Quoted 5 lines · Willy Tarreau
Hi,
Quoted 1 line · Arnaud Ebalard
Quoted 1 line
more bummer. Willy, mind posting what you have?
Quoted 7 lines
Quoted 2 lines
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 :
Quoted 6 lines
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 -12Oh damn, I'm back in the code again trying to fix it now...
:-)
Quoted 2 lines
Also we must not put it into staging in its current shape as it patches
drivers/mtd.
Understood. That's why I was asking.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 9 lines · Jason Cooper
Quoted 5 lines
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.
Quoted 4 lines
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
Quoted 33 lines · Willy Tarreau
OK fixed the driver. The problem was the hard-coded internal register address which was
0xfeb00000in previous versions and is0xfec00000now.Now I'm getting this upon modprobe :
calling
drivers/mtd/nand/armada_nand.c:3227orion_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, version0x01
Bad block table found at page 261888, version0x01
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:~#
Quoted 2 lines
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 Willy,
Quoted 8 lines · Willy Tarreau
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.
;-)
Quoted 3 lines
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,
Quoted 50 lines · Arnaud Ebalard
Quoted 3 lines
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:
(quoted diff) +7
-10@@ -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,
Review line 1680
Quoted 10 lines
(quoted diff) +4
-1@@ -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
Quoted 3 lines · Willy Tarreau
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.
Hi,
Quoted 8 lines · Jason Cooper
Quoted 5 lines
- 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)
Quoted 6 lines
Quoted 3 lines
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 <[email protected]> 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".
...
Quoted 6 lines
Review
Quoted 4 lines
[snip]
(quoted diff) +2
-0+ + /* Waiting for NAND support to appear in armada-370.dtsiI would just leave this out until we get the driver sorted.
ok, will do that in next versions.
Quoted 10 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts line 186
Quoted 10 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +10
-0+ 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+
Quoted 8 lines · Arnaud Ebalard
Quoted 6 lines · Jason Cooper
Quoted 5 lines
- 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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +5
-0+ i2c at 11000 { + compatible = "marvell,mv64xxx-i2c"; + clock-frequency = <100000>; + status = "okay"; +
Quoted 8 lines
Quoted 5 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts line 186
Quoted 5 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +5
-0+ 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.
Quoted 5 lines · 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.
[...]
Quoted 7 lines
Signed-off-by Arnaud Ebalard <[email protected]>--- 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
[...]
Quoted 58 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +52
-0@@ -0,0 +1,215 @@ +/* + * Device Tree file for NETGEAR ReadyNAS 102 + * + * Copyright (C) 2013, Arnaud EBALARD <[email protected]> + * + * 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";
arch/arm/boot/dts/armada-370-netgear-rn102.dts line 62
Quoted 10 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +10
-0+ 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.
Quoted 154 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +153
-0+ 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"; + }; + }; + }; + }; +};
Hi,
Quoted 25 lines · Sebastian Hesselbarth
Quoted 12 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +12
-0+ 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";arch/arm/boot/dts/armada-370-netgear-rn102.dts line 62
Quoted 10 lines
arch/arm/boot/dts/armada-370-netgear-rn102.dts new file +10
-0+ marvell,function = "gpio"; + }; + + backup_led_pin: backup-led-pin { + marvell,pins = "mpp56"; + marvell,function = "gpio"; + }; + }; + + gpio_leds {Arnaud,
Quoted 3 lines
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+