ARM: dts: Revert disabling of smc91x for n900
PATCH 1/1 ARM: dts: Revert disabling of smc91x for n900
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b ("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins") 7d2911c43815 ("net: smc91x: Fix gpios for device tree based booting")
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
arch/arm/boot/dts/omap3-n900.dts +0 -3
@@ -702,9 +702,6 @@ ethernet@gpmc { compatible = "smsc,lan91c94"; - - status = "disabled"; - interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */
Just to note that smc91x ethernet support is also in qemu n900 emulation. Later I will try if it work with upstream kernel...
Quoted 19 lines · On Tuesday 06 January 2015 00:02:29 Tony Lindgren wrote:
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>
arch/arm/boot/dts/omap3-n900.dts line 707
Quoted 9 lines
arch/arm/boot/dts/omap3-n900.dts +0
-3@@ -702,9 +702,6 @@ ethernet@gpmc { compatible = "smsc,lan91c94"; - - status = "disabled"; - interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ reg = <1 0x300 0xf>; /* 16 byte IO range at offset
0x300
Quoted 1 line
*/
Signature · 2 lines
Pali Rohár [email protected]
Quoted 2 lines · Pali Rohár
Just to note that smc91x ethernet support is also in qemu n900 emulation. Later I will try if it work with upstream kernel...
Oh cool, I did not know that :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
Quoted 8 lines
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>
Normally, the early development boards should have separate dts file (then include common parts), no?
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
[Plus of course, obviouse question is: where can I get one of those boards? :-)]
Pavel
Quoted 12 lines
arch/arm/boot/dts/omap3-n900.dts +0
-3@@ -702,9 +702,6 @@ ethernet@gpmc { compatible = "smsc,lan91c94"; - - status = "disabled"; - interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Pali,
Quoted 2 lines · Pali Rohár
Just to note that smc91x ethernet support is also in qemu n900 emulation. Later I will try if it work with upstream kernel...
$ qemu-system-arm --machine '?' | grep n900 || echo "No N900 support" No N900 support
Is there work going on to mainline the n900 patches for qemu?
-- Sebastian
Quoted 7 lines · On Tuesday 06 January 2015 16:03:54 Sebastian Reichel wrote:
Hi Pali,
Quoted 3 lines · Pali Rohár
Just to note that smc91x ethernet support is also in qemu n900 emulation. Later I will try if it work with upstream kernel...
Quoted 6 lines
$ qemu-system-arm --machine '?' | grep n900 || echo "No N900 support" No N900 supportIs there work going on to mainline the n900 patches for qemu?
-- Sebastian
I do not know, but n900 support is part of linaro qemu version.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")
Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Quoted 2 lines
[Plus of course, obviouse question is: where can I get one of those boards? :-)]
Another planet a long time ago :)
Regards,
Tony
8< ----------------
From: Tony Lindgren <[email protected]>
Date: Tue, 6 Jan 2015 08:49:57 -0800
Subject: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b ("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins") 7d2911c43815 ("net: smc91x: Fix gpios for device tree based booting")
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems. And it's also available supposedly in some versions of qemu.
arch/arm/boot/dts/omap3-n900.dts +1 -3
@@ -700,11 +700,9 @@ }; }; + /* Ethernet is on some early development boards and qemu */ ethernet@gpmc { compatible = "smsc,lan91c94"; - - status = "disabled"; - interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */
Quoted 6 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
Quoted 8 lines
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>
Aaro Koskinen
Tested-byHi,
Quoted 20 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
Quoted 8 lines
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Seems to work fine with normal n900.
I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default?
A.
Quoted 29 lines · Aaro Koskinen
Hi,
Quoted 26 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Quoted 6 lines
Quoted 2 lines
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Seems to work fine with normal n900.
Tested-by Aaro Koskinen <[email protected]>
OK good to hear, thanks for testing.
Quoted 4 lines
I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default?
You need to write the eeprom with ethtool from Linux, something like this:
Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do:
# cat mac | ethtool -E eth0 offset 0x40 length 6
Then ethtool -e eth0 should show you the configuration.
Regards,
Tony
Quoted 37 lines · On Tuesday 06 January 2015 20:44:43 Aaro Koskinen wrote:
Hi,
Quoted 25 lines · Tony Lindgren
Quoted 12 lines · Pavel Machek
Quoted 11 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 6 lines
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Seems to work fine with normal n900.
Quoted 8 lines
Tested-by Aaro Koskinen <[email protected]>I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default?
A.
Should not kernel generate some random mac address if driver does not provide one?
You can try to set (temporary) mac address to if with ifconfig:
$ ifconfig eth0 hw ether <mac>
Signature · 2 lines
Pali Rohár [email protected]
Quoted 47 lines · Tony Lindgren
Quoted 29 lines · Aaro Koskinen
Hi,
Quoted 26 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Quoted 6 lines
Quoted 2 lines
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Seems to work fine with normal n900.
Tested-by Aaro Koskinen <[email protected]>OK good to hear, thanks for testing.
Quoted 4 lines
I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default?
You need to write the eeprom with ethtool from Linux, something like this:
Quoted 7 lines
Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do:
# cat mac | ethtool -E eth0 offset 0x40 length 6Then ethtool -e eth0 should show you the configuration.
Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly..
Regards,
Tony
Quoted 5 lines · On Tuesday 06 January 2015 21:17:59 Tony Lindgren wrote:
Quoted 4 lines · Tony Lindgren
Quoted 3 lines · Aaro Koskinen
Hi,
On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren
Quoted 54 lines · wrote:
Quoted 46 lines
Quoted 28 lines
Quoted 28 lines · Pavel Machek
Quoted 12 lines · Tony Lindgren
Quoted 11 lines
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Quoted 7 lines
Quoted 3 lines
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Seems to work fine with normal n900.
Tested-by Aaro Koskinen <[email protected]>OK good to hear, thanks for testing.
Quoted 4 lines
I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default?
You need to write the eeprom with ethtool from Linux, something like this:
Quoted 7 lines
Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do:
# cat mac | ethtool -E eth0 offset 0x40 length 6Then ethtool -e eth0 should show you the configuration.
Quoted 7 lines
Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly..
Regards,
Tony
N900 uboot support is broken, see my email on uboot ML with bisected commits:
http://lists.denx.de/pipermail/u-boot/2015-January/200154.html
Signature · 2 lines
Pali Rohár [email protected]
Quoted 52 lines · Tony Lindgren
Quoted 51 lines · Tony Lindgren
Quoted 29 lines · Aaro Koskinen
Hi,
Quoted 26 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Quoted 6 lines
Quoted 2 lines
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Seems to work fine with normal n900.
Tested-by Aaro Koskinen <[email protected]>OK good to hear, thanks for testing.
Quoted 4 lines
I also tested with a development board, eth0 seemed to appear, but couldn't configure the MAC address with busybox ifconfig. How should it be done, I guess the interface does not have any MAC by default?
You need to write the eeprom with ethtool from Linux, something like this:
Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do:
Quoted 7 lines
Quoted 3 lines
# cat mac | ethtool -E eth0 offset 0x40 length 6Then ethtool -e eth0 should show you the configuration.
Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly..
Nice :-). If you have u-boot working, could you try to do generic board conversion? We are a tiny bit past a deadline on that one.
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 10 lines · Pali Rohár
Quoted 4 lines · On Tuesday 06 January 2015 21:17:59 Tony Lindgren wrote:
Oh and I have some u-boot patches that I'll post that allow booting n900 with bootz and to use smsc91x tftp booting. I'll try to post those shortly..
N900 uboot support is broken, see my email on uboot ML with bisected commits:
http://lists.denx.de/pipermail/u-boot/2015-January/200154.html
Oh my patches are against 2014-10 or something like that. No idea about the recent regression.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 7 lines · Tony Lindgren
Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do:
# cat mac | ethtool -E eth0 offset 0x40 length 6Then ethtool -e eth0 should show you the configuration.
Does any other eeprom data need to be set? It seems to be all 0xff. I generated a mac from /dev/random and it shows up fine in those offsets and with ifconfig, but I still can't get a link up:
ifconfig: SIOCSIFFLAGS: Cannot assign requested address
A.
Quoted 9 lines · Aaro Koskinen
Hi,
Quoted 6 lines · Tony Lindgren
Run u-boot/tools/gen_eth_addr to generate a random local mac, then swap the bytes for it for big endian. Enter them into a file with hexedit in big endian order. Then just do:
# cat mac | ethtool -E eth0 offset 0x40 length 6
Quoted 7 lines
Quoted 1 line
Then ethtool -e eth0 should show you the configuration.
Does any other eeprom data need to be set? It seems to be all
0xff. I generated a mac from/dev/randomand it shows up fine in those offsets and with ifconfig, but I still can't get a link up:ifconfig: SIOCSIFFLAGS: Cannot assign requested address
Chances are you did not swap the mac address bits around and it's trying to use a reserved mac address now? The mac needs to be the other way around..
Regards,
Tony
Quoted 20 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
Quoted 8 lines
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Actually... how do you manage your n900 to boot? Does it also boot from 0xffff?
I believe I'm hitting dtb size limit (again), and 3.19-rc3 does not boot unless I somehow make dtb smaller... like the patch below.
---
make dtb smaller so that it boots.
arch/arm/boot/dts/omap3-n900.dts +0 -44
@@ -140,14 +140,6 @@ >; }; - ethernet_pins: pinmux_ethernet_pins { - pinctrl-single,pins = < - OMAP3_CORE1_IOPAD(0x20b4, PIN_INPUT_PULLDOWN | MUX_MODE4) /* gpmc_ncs3.gpio_54 */ - OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE4) /* dss_data16.gpio_86 */ - OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4) /* uart3_rts_sd.gpio_164 */ - >; - }; - gpmc_pins: pinmux_gpmc_pins { pinctrl-single,pins = <
@@ -700,42 +692,6 @@ }; }; - ethernet@gpmc { - compatible = "smsc,lan91c94"; - - status = "disabled"; - - interrupt-parent = <&gpio2>; - interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ - reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */ - bank-width = <2>; - pinctrl-names = "default"; - pinctrl-0 = <ðernet_pins>; - power-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>; /* gpio86 */ - reset-gpios = <&gpio6 4 GPIO_ACTIVE_HIGH>; /* gpio164 */ - gpmc,device-width = <2>; - gpmc,sync-clk-ps = <0>; - gpmc,cs-on-ns = <0>; - gpmc,cs-rd-off-ns = <48>; - gpmc,cs-wr-off-ns = <24>; - gpmc,adv-on-ns = <0>; - gpmc,adv-rd-off-ns = <0>; - gpmc,adv-wr-off-ns = <0>; - gpmc,we-on-ns = <12>; - gpmc,we-off-ns = <18>; - gpmc,oe-on-ns = <12>; - gpmc,oe-off-ns = <48>; - gpmc,page-burst-access-ns = <0>; - gpmc,access-ns = <42>; - gpmc,rd-cycle-ns = <180>; - gpmc,wr-cycle-ns = <180>; - gpmc,bus-turnaround-ns = <0>; - gpmc,cycle2cycle-delay-ns = <0>; - gpmc,wait-monitoring-ns = <0>; - gpmc,clk-activation-ns = <0>; - gpmc,wr-access-ns = <0>; - gpmc,wr-data-mux-bus-ns = <12>; - }; }; &mcspi1 {
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 33 lines · Pavel Machek
Quoted 20 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
Quoted 8 lines
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Actually... how do you manage your n900 to boot? Does it also boot from
0xffff?
Quoted 6 lines
I believe I'm hitting dtb size limit (again), and 3.19-rc3 does not boot unless I somehow make dtb smaller... like the patch below.
---
make dtb smaller so that it boots.
I am using chained boot (NOLO->u-boot->kernel (zImage +dtb concatenated) on a real n900
I have the same issue as well. using omap2plus_defconfig. I was able to bisect next tags as follows: next-20141128 worked, next-20141201 stopped booting and the change was new dts addition, removing the dts addition helped next-20141201 boot as well.
Current state:
https://github.com/nmenon/kernel-test-logs/blob/next-20150107/omap2plus_defconfig/n900.txt#L447
https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc3/omap2plus_defconfig/n900.txt#L448
I had complained originally here:
http://marc.info/?t=141946203100001&r=1&w=2 Apologies on not following up on the thread, got distracted.
Signature · 2 lines
Regards, Nishanth Menon
Quoted 51 lines · Nishanth Menon
Quoted 33 lines · Pavel Machek
Quoted 20 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
Quoted 8 lines
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Actually... how do you manage your n900 to boot? Does it also boot from
0xffff?Quoted 6 lines
I believe I'm hitting dtb size limit (again), and 3.19-rc3 does not boot unless I somehow make dtb smaller... like the patch below.
---
make dtb smaller so that it boots.
I am using chained boot (NOLO->u-boot->kernel (zImage +dtb concatenated) on a real n900
I have the same issue as well. using
omap2plus_defconfig. I was able to bisect next tags as follows: next-20141128 worked, next-20141201 stopped booting and the change was new dts addition, removing the dts addition helped next-20141201 boot as well.Current state:
Quoted 8 lines
https://github.com/nmenon/kernel-test-logs/blob/next-20150107/omap2plus_defconfig/n900.txt#L447
https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc3/omap2plus_defconfig/n900.txt#L448
I had complained originally here:
http://marc.info/?t=141946203100001&r=1&w=2 Apologies on not following up on the thread, got distracted.
Hmm strange a plain omap2plus_defconfig kernel boots just fine here. Also boots fine with appended DTB and 0xFFFF using something like:
$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > /tmp/zImage $ 0xFFFF -m /tmp/zImage -l -b
My boot log is appended in case that provides any clues. Note that I'm only loading it with -l and not flashing it though.
Regards,
Tony
...
[ 1.943] getting value of option 'R&D flags set' [ 1.948] SETUP: WR VND DEVICE req 42 value 0000 index 0000 length 001b [ 1.956] Image 'kernel' won't fit to the partition, still loading it (4814592 bytes, while maximum is 2097152 bytes) [ 1.967] Receiving kernel (length 4814592) [ 2.298] Image successfully received [ 2.302] SETUP: WR VND DEVICE req 82 value 0000 index 0000 length 0000 [ 2.309] SETUP: WR STD INTERFACE SET_INTERFACE value 0000 index 0002 length 0000 [ 2.363] Boot requested (normal mode) [ 2.367] Serial console enabled [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.19.0-rc1 (tmlind@sampyla) (gcc version 4.9.2 ( 4.9.2-10) ) #1148 SMP Wed Jan 7 08:27:45 PST 2015 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] Machine model: Nokia N900 [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] Memory policy: Data cache writeback [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [ 0.000000] PERCPU: Embedded 11 pages/cpu @cfc36000 s14912 r8192 d21952 u45056 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64704 [ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 223700K/261120K available (6215K kernel code, 674K rwdata, 2360K rodata, 428K init, 8221K bss, 21036K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0868204 (8577 kB) [ 0.000000] .init : 0xc0869000 - 0xc08d4000 ( 428 kB) [ 0.000000] .data : 0xc08d4000 - 0xc097ca28 ( 675 kB) [ 0.000000] .bss : 0xc097ca28 - 0xc1184140 (8222 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts [ 0.000000] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000030] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65536000000000ns [ 0.000061] OMAP clocksource: 32k_counter at 32768 Hz [ 0.001647] Console: colour dummy device 80x30 [ 0.001739] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.001739] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.001770] ... MAX_LOCK_DEPTH: 48 [ 0.001800] ... MAX_LOCKDEP_KEYS: 8191 [ 0.001800] ... CLASSHASH_SIZE: 4096 [ 0.001831] ... MAX_LOCKDEP_ENTRIES: 32768 [ 0.001831] ... MAX_LOCKDEP_CHAINS: 65536 [ 0.001861] ... CHAINHASH_SIZE: 32768 [ 0.001861] memory used by lock dependency info: 5167 kB [ 0.001892] per task-struct memory footprint: 1152 bytes [ 0.001922] Calibrating delay loop... 496.43 BogoMIPS (lpj=2482176) [ 0.106933] pid_max: default: 32768 minimum: 301 [ 0.107604] Security Framework initialized [ 0.107940] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.107971] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.113647] Initializing cgroup subsys memory [ 0.113800] Initializing cgroup subsys devices [ 0.113952] Initializing cgroup subsys freezer [ 0.114105] Initializing cgroup subsys blkio [ 0.114257] Initializing cgroup subsys perf_event [ 0.114410] CPU: Testing write buffer coherency: ok [ 0.116790] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.117126] Setting up static identity map for 0x805e7ee0 - 0x805e7f50 [ 0.123565] Brought up 1 CPUs [ 0.123596] CPU: All CPU(s) started in SVC mode. [ 0.129669] devtmpfs: initialized [ 0.133514] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 [ 0.251525] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp [ 0.254882] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp [ 0.343383] omap_hwmod: mcbsp2: cannot be enabled for reset (3) [ 0.368804] pinctrl core: initialized pinctrl subsystem [ 0.520080] NET: Registered protocol family 16 [ 0.534118] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.538330] cpuidle: using governor ladder [ 0.538391] cpuidle: using governor menu [ 0.541290] Reprogramming SDRC clock to 332000000 Hz [ 0.561035] OMAP GPIO hardware version 2.5 [ 0.581329] irq: no irq domain found for /ocp/pinmux@48002030 ! [ 0.582611] irq: no irq domain found for /ocp/pinmux@48002030 ! [ 0.617950] omap-gpmc 6e000000.gpmc: could not find pctldev for node /ocp/pinmux@48002030/pinmux_gpmc_pins, deferring probe [ 0.618041] platform 6e000000.gpmc: Driver omap-gpmc requests probe deferral [ 0.631927] No ATAGs? [ 0.631988] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.637176] Reserving DMA channels 0 and 1 for HS ROM code [ 0.637237] OMAP DMA hardware revision 4.0 [ 0.761474] omap-dma-engine 48056000.dma-controller: OMAP DMA engine driver [ 0.769653] SCSI subsystem initialized [ 0.772430] usbcore: registered new interface driver usbfs [ 0.772796] usbcore: registered new interface driver hub [ 0.773040] usbcore: registered new device driver usb [ 0.774902] omap_i2c 48070000.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i2c1_pins, deferring probe [ 0.774963] platform 48070000.i2c: Driver omap_i2c requests probe deferral [ 0.775146] omap_i2c 48072000.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i2c2_pins, deferring probe [ 0.775207] platform 48072000.i2c: Driver omap_i2c requests probe deferral [ 0.775360] omap_i2c 48060000.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i2c3_pins, deferring probe [ 0.775390] platform 48060000.i2c: Driver omap_i2c requests probe deferral [ 0.783599] Switched to clocksource 32k_counter [ 1.078643] NET: Registered protocol family 2 [ 1.081787] TCP established hash table entries: 2048 (order: 1, 8192 bytes) [ 1.082061] TCP bind hash table entries: 2048 (order: 4, 73728 bytes) [ 1.083251] TCP: Hash tables configured (established 2048 bind 2048) [ 1.083831] TCP: reno registered [ 1.083892] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 1.084228] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 1.086212] NET: Registered protocol family 1 [ 1.088867] RPC: Registered named UNIX socket transport module. [ 1.088928] RPC: Registered udp transport module. [ 1.088928] RPC: Registered tcp transport module. [ 1.088958] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 1.091400] hw perfevents: enabled with armv7_cortex_a8 PMU driver, 5 counters available [ 1.101806] futex hash table entries: 256 (order: 2, 16384 bytes) [ 1.102233] audit: initializing netlink subsys (disabled) [ 1.102661] audit: type=2000 audit(1.080:1): initialized [ 1.110931] VFS: Disk quotas dquot_6.5.2 [ 1.111236] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.115966] NFS: Registering the id_resolver key type [ 1.116638] Key type id_resolver registered [ 1.116668] Key type id_legacy registered [ 1.117004] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. [ 1.125732] io scheduler noop registered [ 1.125793] io scheduler deadline registered [ 1.125976] io scheduler cfq registered (default) [ 1.131042] pinctrl-single 48002030.pinmux: 284 pins at pa fa002030 size 568 [ 1.132049] pinctrl-single 48002a00.pinmux: 46 pins at pa fa002a00 size 92 [ 1.133605] pinctrl-single 480025d8.pinmux: 18 pins at pa fa0025d8 size 36 [ 1.144012] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.158020] omap_uart 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 223, base_baud = 3000000) is a OMAP UART1 [ 1.162597] omap_uart 49020000.serial: ttyO2 at MMIO 0x49020000 (irq = 224, base_baud = 3000000) is a OMAP UART2 [ 1.953918] console [ttyO2] enabled [ 2.005004] brd: module loaded [ 2.034637] loop: module loaded [ 2.045440] mtdoops: mtd device (mtddev=name/number) must be supplied [ 2.079437] usbcore: registered new interface driver asix [ 2.085571] usbcore: registered new interface driver ax88179_178a [ 2.092285] usbcore: registered new interface driver cdc_ether [ 2.098907] usbcore: registered new interface driver smsc95xx [ 2.105285] usbcore: registered new interface driver net1080 [ 2.111541] usbcore: registered new interface driver cdc_subset [ 2.118103] usbcore: registered new interface driver zaurus [ 2.124481] usbcore: registered new interface driver cdc_ncm [ 2.132568] usbcore: registered new interface driver cdc_wdm [ 2.139099] usbcore: registered new interface driver usb-storage [ 2.145874] usbcore: registered new interface driver usbtest [ 2.156066] mousedev: PS/2 mouse device common for all mice [ 2.166717] i2c /dev entries driver [ 2.170562] Driver for 1-wire Dallas network protocol. [ 2.181427] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec [ 2.190826] Driver 'mmcblk' needs updating - please use bus_type methods [ 2.201782] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517 [ 2.209716] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral [ 2.218811] omap_hsmmc 480b4000.mmc: unable to get vmmc regulator -517 [ 2.226135] platform 480b4000.mmc: Driver omap_hsmmc requests probe deferral [ 2.236785] ledtrig-cpu: registered to indicate activity on CPUs [ 2.244781] usbcore: registered new interface driver usbhid [ 2.250701] usbhid: USB HID core driver [ 2.257781] oprofile: using arm/armv7 [ 2.262847] TCP: cubic registered [ 2.266571] Initializing XFRM netlink socket [ 2.271331] NET: Registered protocol family 17 [ 2.276245] NET: Registered protocol family 15 [ 2.281585] Key type dns_resolver registered [ 2.286590] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva [ 2.294311] omap2_set_init_voltage: unable to set vdd_mpu_iva [ 2.300445] omap2_set_init_voltage: unable to find boot up OPP for vdd_core [ 2.307861] omap2_set_init_voltage: unable to set vdd_core [ 2.316528] platform cpufreq-dt.0: Driver cpufreq-dt requests probe deferral [ 2.332305] ThumbEE CPU extension supported. [ 2.337036] Registering SWP/SWPB emulation handler [ 2.342132] SmartReflex Class3 initialized [ 2.356750] omap-gpmc 6e000000.gpmc: GPMC revision 5.0 [ 2.365081] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d08c0000, freq 83 MHz [ 2.376556] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [ 2.381561] OneNAND version = 0x0031 [ 2.387603] Scanning device for bad blocks [ 2.520599] 6 ofpart partitions found on MTD device omap2-onenand [ 2.527099] Creating 6 MTD partitions on "omap2-onenand": [ 2.532867] 0x000000000000-0x000000020000 : "bootloader" [ 2.549591] 0x000000020000-0x000000080000 : "config" [ 2.561737] 0x000000080000-0x0000000c0000 : "log" [ 2.573150] 0x0000000c0000-0x0000002c0000 : "kernel" [ 2.585357] 0x0000002c0000-0x0000004c0000 : "initfs" [ 2.597259] 0x0000004c0000-0x000010000000 : "rootfs" [ 2.630493] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <[email protected]> [ 2.642761] smc91x 2000300.ethernet eth0: SMC91C94 (rev 9) at d0806300 IRQ 81 [ 2.650451] [ 2.652038] smc91x 2000300.ethernet eth0: Ethernet addr: xx:xx:xx:xx:xx:xx [ 2.686737] twl 0-0048: PIH (irq 295) chaining IRQs 296..304 [ 2.693664] twl 0-0048: power (irq 301) chaining IRQs 304..311 [ 2.705352] twl_rtc 48070000.i2c:twl@48:rtc: Enabling TWL-RTC [ 2.720214] twl_rtc 48070000.i2c:twl@48:rtc: rtc core: registered 48070000.i2c:twl@48 as rtc0 [ 2.816497] twl4030_gpio twl4030-gpio: gpio (irq 296) chaining IRQs 312..329 [ 2.838165] input: twl4030_pwrbutton as /devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:pwrbutton/input/input0 [ 2.858551] input: TWL4030 Keypad as /devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:keypad/input/input1 [ 2.956573] omap_i2c 48070000.i2c: bus 0 rev3.3 at 2200 kHz [ 2.981903] omap_i2c 48072000.i2c: bus 1 rev3.3 at 100 kHz [ 2.991973] omap_i2c 48060000.i2c: bus 2 rev3.3 at 400 kHz [ 3.115447] input: gpio_keys as /devices/platform/gpio_keys/input/input2 [ 3.128417] twl_rtc 48070000.i2c:twl@48:rtc: setting system clock to 2000-01-01 00:04:44 UTC (946685084) [ 3.138549] sr_init: No PMIC hook to init smartreflex [ 3.144500] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [ 3.153991] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [ 3.263702] VUSB3V1: disabling [ 3.269073] VUSB1V8: disabling [ 3.275421] VUSB1V5: disabling [ 3.280303] VCSI: disabling [ 3.289428] Waiting for root device /dev/mmcblk0p2... [ 3.432678] mmc1: switch to bus width 2 failed [ 3.438171] mmc1: switch to bus width 1 failed [ 3.442993] mmc1: new high speed MMC card at address 0001 [ 3.453186] mmcblk0: mmc1:0001 MMC32G 29.8 GiB [ 3.459167] mmcblk0boot0: mmc1:0001 MMC32G partition 1 512 KiB [ 3.466308] mmcblk0boot1: mmc1:0001 MMC32G partition 2 512 KiB [ 3.481109] mmcblk0: p1 p2 p3 p4 [ 3.525909] EXT3-fs (mmcblk0p2): recovery required on readonly filesystem [ 3.533142] EXT3-fs (mmcblk0p2): write access will be enabled during recovery [ 9.212371] kjournald starting. Commit interval 5 seconds [ 9.239501] EXT3-fs (mmcblk0p2): recovery complete [ 9.245086] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode [ 9.253295] VFS: Mounted root (ext3 filesystem) readonly on device 179:2. [ 9.278625] devtmpfs: mounted [ 9.289184] Freeing unused kernel memory: 428K (c0869000 - c08d4000)
INIT: version 2.86 booting
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi!
Quoted 23 lines
Quoted 6 lines
Quoted 2 lines
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Actually... how do you manage your n900 to boot? Does it also boot from
0xffff?Quoted 6 lines
I believe I'm hitting dtb size limit (again), and 3.19-rc3 does not boot unless I somehow make dtb smaller... like the patch below.
---
make dtb smaller so that it boots.
I am using chained boot (NOLO->u-boot->kernel (zImage +dtb concatenated) on a real n900
I have the same issue as well. using
omap2plus_defconfig. I was able to bisect next tags as follows: next-20141128 worked, next-20141201 stopped booting and the change was new dts addition, removing the dts addition helped next-20141201 boot as well.Current state:
Quoted 8 lines
https://github.com/nmenon/kernel-test-logs/blob/next-20150107/omap2plus_defconfig/n900.txt#L447
https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc3/omap2plus_defconfig/n900.txt#L448
I had complained originally here:
http://marc.info/?t=141946203100001&r=1&w=2 Apologies on not following up on the thread, got distracted.
Actually, I noticed this some time ago, and there's some additional discussion at
Subject: Re: dtb size limit? was Re: Tiny dts change breaks boot on n900
Message-ID: <[email protected]>
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 57 lines · Tony Lindgren
Quoted 56 lines · Nishanth Menon
Quoted 33 lines · Pavel Machek
Quoted 20 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
Quoted 8 lines
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Actually... how do you manage your n900 to boot? Does it also boot from
0xffff?Quoted 6 lines
I believe I'm hitting dtb size limit (again), and 3.19-rc3 does not boot unless I somehow make dtb smaller... like the patch below.
---
make dtb smaller so that it boots.
I am using chained boot (NOLO->u-boot->kernel (zImage +dtb concatenated) on a real n900
I have the same issue as well. using
omap2plus_defconfig. I was able to bisect next tags as follows: next-20141128 worked, next-20141201 stopped booting and the change was new dts addition, removing the dts addition helped next-20141201 boot as well.Current state:
https://github.com/nmenon/kernel-test-logs/blob/next-20150107/omap2plus_defconfig/n900.txt#L447
https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc3/omap2plus_defconfig/n900.txt#L448
Quoted 6 lines
Quoted 3 lines
I had complained originally here:
http://marc.info/?t=141946203100001&r=1&w=2 Apologies on not following up on the thread, got distracted.Hmm strange a plain
omap2plus_defconfigkernel boots just fine here. Also boots fine with appended DTB and0xFFFFusing something like:
Interesting.
Quoted 2 lines
$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > /tmp/zImage $ 0xFFFF -m /tmp/zImage -l -b
I'm doing something similar, with difference that I also pass commandline using -b.
Quoted 2 lines
My boot log is appended in case that provides any clues. Note that I'm only loading it with -l and not flashing it though.
Ok, I'll try with defconfig, and am sending you my .config in case it depends on it.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 57 lines · Tony Lindgren
Quoted 56 lines · Nishanth Menon
Quoted 33 lines · Pavel Machek
Quoted 20 lines · Tony Lindgren
Quoted 10 lines · Pavel Machek
Quoted 9 lines · Tony Lindgren
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Quoted 8 lines
Quoted 5 lines
Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>Normally, the early development boards should have separate dts file (then include common parts), no?
Quoted 8 lines
In this case it won't matter. The GPMC hardware is there, the probe just fails if no smsc91x is found.
Quoted 2 lines
Could you at least add a note to the dts file what is it? Because I always thought it is a bug.
Sure, updated patch below. Can somebody please test boot it on a production n900 too to make sure it no longer causes issues?
Actually... how do you manage your n900 to boot? Does it also boot from
0xffff?Quoted 6 lines
I believe I'm hitting dtb size limit (again), and 3.19-rc3 does not boot unless I somehow make dtb smaller... like the patch below.
---
make dtb smaller so that it boots.
I am using chained boot (NOLO->u-boot->kernel (zImage +dtb concatenated) on a real n900
I have the same issue as well. using
omap2plus_defconfig. I was able to bisect next tags as follows: next-20141128 worked, next-20141201 stopped booting and the change was new dts addition, removing the dts addition helped next-20141201 boot as well.Current state:
https://github.com/nmenon/kernel-test-logs/blob/next-20150107/omap2plus_defconfig/n900.txt#L447
https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc3/omap2plus_defconfig/n900.txt#L448
Quoted 6 lines
Quoted 3 lines
I had complained originally here:
http://marc.info/?t=141946203100001&r=1&w=2 Apologies on not following up on the thread, got distracted.Hmm strange a plain
omap2plus_defconfigkernel boots just fine here. Also boots fine with appended DTB and0xFFFFusing something like:
I tried omap2plus_defconfig + my smaller DTB, and I stare at blank screen where kernel messages should be (no serial cable here, sorry).
I reverted my "smaller DTB" changes, and now I'm staring at nokia logo, followed by backlight off.
Strange.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 6 lines · On Wednesday 07 January 2015 17:40:06 Tony Lindgren wrote:
[ 1.943] getting value of option 'R&D flags set' [ 1.948] SETUP: WR VND DEVICE req 42 value 0000 index 0000 length 001b [ 1.956] Image 'kernel' won't fit to thepartition, still loading it (4814592 bytes, while maximum is 2097152 bytes)
Quoted 8 lines
[ 1.967] Receiving kernel (length 4814592) [ 2.298] Image successfully received [ 2.302] SETUP: WR VND DEVICE req 82 value 0000 index 0000 length 0000 [ 2.309] SETUP: WR STD INTERFACE SET_INTERFACE value 0000 index 0002 length 0000 [ 2.363] Boot requested (normal mode) [ 2.367] Serial console enabled
Tony, how did you get above verbose log from NOLO bootloader? Is there any switch of R&D flag for it?
NOLO in qemu (on serial console) show few messages...
[ 0.179] Loading kernel image info Loading kernel (202 kB)... done in 27 ms (7457 kB/s) [ 0.202] Loading initfs image info [ 0.203] Total bootup time 286 ms [ 0.206] Serial console enabled
Signature · 2 lines
Pali Rohár [email protected]
Quoted 16 lines · Pali Rohár
Quoted 6 lines · On Wednesday 07 January 2015 17:40:06 Tony Lindgren wrote:
[ 1.943] getting value of option 'R&D flags set' [ 1.948] SETUP: WR VND DEVICE req 42 value 0000 index 0000 length 001b [ 1.956] Image 'kernel' won't fit to thepartition, still loading it (4814592 bytes, while maximum is 2097152 bytes)
Quoted 8 lines
[ 1.967] Receiving kernel (length 4814592) [ 2.298] Image successfully received [ 2.302] SETUP: WR VND DEVICE req 82 value 0000 index 0000 length 0000 [ 2.309] SETUP: WR STD INTERFACE SET_INTERFACE value 0000 index 0002 length 0000 [ 2.363] Boot requested (normal mode) [ 2.367] Serial console enabled
Quoted 2 lines
Tony, how did you get above verbose log from NOLO bootloader? Is there any switch of R&D flag for it?
Probably it was built with some debug flags enabled, at least I don't think those can be enabled otherwise.
Quoted 7 lines
NOLO in qemu (on serial console) show few messages...
[ 0.179] Loading kernel image info Loading kernel (202 kB)... done in 27 ms (7457 kB/s) [ 0.202] Loading initfs image info [ 0.203] Total bootup time 286 ms [ 0.206] Serial console enabled
Looks like I have:
$ flasher --query-rd-mode flasher v2.5.2 (Oct 21 2009)
Suitable USB device not found, waiting.
USB device found found at bus 003, device address 060.
Found device RX-51, hardware revision 0010
NOLO version 1.4.14
Version of 'sw-release': <no version>
The device is in R&D mode
R&D flags (0x0196): no-omap-wd, no-ext-wd, serial-console, no-charging, force-power-key
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 28 lines · On Tuesday 06 January 2015 00:02:29 Tony Lindgren wrote:
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>arch/arm/boot/dts/omap3-n900.dts +0
-3@@ -702,9 +702,6 @@ ethernet@gpmc { compatible = "smsc,lan91c94"; - - status = "disabled"; - interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300
Quoted 1 line
*/
Hello Tony,
to make smc ethernet working in n900 qemu I needed to apply this patch:
arch/arm/boot/dts/omap3-n900.dts +2 -1
@@ -770,7 +770,8 @@ compatible = "smsc,lan91c94"; interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ - reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */ +// reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */ + reg = <1 0x0 0xf>; /* 16 byte IO range at offset 0x300 */ bank-width = <2>; pinctrl-names = "default"; pinctrl-0 = <ðernet_pins>;
With this patch I see in dmesg:
[ 20.577911] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: smc_probe [ 20.580535] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: bank signature probe returned 0x3300 [ 20.585327] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: revision = 0x3391 [ 20.590087] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <[email protected]> [ 20.593627] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc_reset [ 20.596832] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc_phy_detect [ 20.611938] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: smc_shutdown [ 20.615875] smc91x 2000000.ethernet eth0: SMC91C11xFD (rev 1) at d08be000 IRQ 166 [ 20.618682] [ 20.621124] smc91x 2000000.ethernet eth0: Ethernet addr: 52:54:00:12:34:56 [ 20.624938] smc91x 2000000.ethernet eth0: No PHY found
(and eth0 exists in ifconfig)
If I do not apply my patch I got this error message:
[ 22.134704] smc91x 2000300.ethernet (unnamed net_device) (uninitialized): smc91x: bank signature probe returned 0x0000 [ 22.140014] smc91x: not found (-19).
and no ethernet device was registered.
With 2.6.28 kernel with N900 patches (but smc91x is unmodified!) ethernet device is working fine.
Signature · 2 lines
Pali Rohár [email protected]
Quoted 40 lines · Pali Rohár
Quoted 28 lines · On Tuesday 06 January 2015 00:02:29 Tony Lindgren wrote:
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>arch/arm/boot/dts/omap3-n900.dts +0
-3@@ -702,9 +702,6 @@ ethernet@gpmc { compatible = "smsc,lan91c94"; - - status = "disabled"; - interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300Quoted 1 line
*/
Hello Tony,
to make smc ethernet working in n900 qemu I needed to apply this patch:
arch/arm/boot/dts/omap3-n900.dts +0
-0
arch/arm/boot/dts/omap3-n900.dts line 777
Quoted 9 lines
arch/arm/boot/dts/omap3-n900.dts +2
-1@@ -770,7 +770,8 @@ compatible = "smsc,lan91c94"; interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ - reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */ +// reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */ + reg = <1 0x0 0xf>; /* 16 byte IO range at offset 0x300 */ bank-width = <2>; pinctrl-names = "default"; pinctrl-0 = <ðernet_pins>;
Oh cool, the 0x300 offset is there mostly to suppress warnings about non-standard location.
Quoted 19 lines
With this patch I see in dmesg:
[ 20.577911] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: smc_probe [ 20.580535] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: bank signature probe returned 0x3300 [ 20.585327] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: revision = 0x3391 [ 20.590087] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <[email protected]> [ 20.593627] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc_reset [ 20.596832] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc_phy_detect [ 20.611938] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: smc_shutdown [ 20.615875] smc91x 2000000.ethernet eth0: SMC91C11xFD (rev 1) at d08be000 IRQ 166 [ 20.618682] [ 20.621124] smc91x 2000000.ethernet eth0: Ethernet addr: 52:54:00:12:34:56 [ 20.624938] smc91x 2000000.ethernet eth0: No PHY found(and eth0 exists in ifconfig)
If I do not apply my patch I got this error message:
Quoted 7 lines
[ 22.134704] smc91x 2000300.ethernet (unnamed net_device) (uninitialized): smc91x: bank signature probe returned 0x0000 [ 22.140014] smc91x: not found (-19).and no ethernet device was registered.
With 2.6.28 kernel with N900 patches (but smc91x is unmodified!) ethernet device is working fine.
OK that's good news. Care to do a patch to set the offset 0x0 with added comment that qemu needs it? I'll test to make sure it works on the real hardware as well.
Regards,
Tony
Quoted 24 lines · On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote:
Quoted 23 lines · Pali Rohár
Quoted 22 lines · On Tuesday 06 January 2015 00:02:29 Tony Lindgren wrote:
Revert "ARM: dts: Disable smc91x on n900 until bootloader dependency is removed". We've now fixed the issues that caused problems with uninitialized hardware depending on the bootloader version. Mostly things got fixed with the following commits:
9a894953a97b("ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins")7d2911c43815("net: smc91x: Fix gpios for device tree based booting")Note that this only affects the early development boards with Ethernet that we still have in a few automated boot test systems.
Signed-off-by Tony Lindgren <[email protected]>arch/arm/boot/dts/omap3-n900.dts +0
-0@@ -702,9 +702,6 @@ ethernet@gpmc {
Quoted 8 lines
Quoted 8 lines
arch/arm/boot/dts/omap3-n900.dts
Quoted 8 lines
arch/arm/boot/dts/omap3-n900.dts +0
-3compatible = "smsc,lan91c94"; - - status = "disabled"; -arch/arm/boot/dts/omap3-n900.dts +0
-0interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54
*/
Quoted 1 line
Quoted 1 line
Quoted 1 line
reg = <1
0x3000xf>; /* 16 byte IO range at
offset
Quoted 16 lines
Quoted 16 lines
Quoted 3 lines
0x300*/
Hello Tony,
to make smc ethernet working in n900 qemu I needed to apply this patch:
(quoted diff) +0
-0
b/arch/arm/boot/dts/omap3-n900.dtsindex ff36fbe..d96eeb8 100644arch/arm/boot/dts/omap3-n900.dts +0
-0@@ -770,7 +770,8 @@
Quoted 5 lines
arch/arm/boot/dts/omap3-n900.dts
Quoted 5 lines
arch/arm/boot/dts/omap3-n900.dts +0
-1compatible = "smsc,lan91c94"; interrupt-parent = <&gpio2>; interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */ - reg = <1 0x300 0xf>; /* 16 byte IO range at offset
0x300
Quoted 1 line
arch/arm/boot/dts/omap3-n900.dts line 775
Quoted 1 line
arch/arm/boot/dts/omap3-n900.dts +0
-0*/ +// reg = <1 0x300 0xf>; /* 16 byte IO range at
offset
Quoted 1 line
Quoted 1 line
0x300*/ + reg = <10x00xf>; /* 16 byte IO range
at
Quoted 44 lines
arch/arm/boot/dts/omap3-n900.dts line 777
Quoted 5 lines
offset
0x300*/arch/arm/boot/dts/omap3-n900.dts +0
-0bank-width = <2>; pinctrl-names = "default"; pinctrl-0 = <ðernet_pins>;Oh cool, the
0x300offset is there mostly to suppress warnings about non-standard location.Quoted 30 lines
With this patch I see in dmesg:
[ 20.577911] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: smc_probe [ 20.580535] smc91x 2000000.ethernet (unnamed net_device) (uninitialized): smc91x: bank signature probe returned 0x3300 [ 20.585327] smc91x 2000000.ethernet (unnamed net_device)(uninitialized): smc91x: revision =
0x3391[ 20.590087]smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
<[email protected]> [ 20.593627] smc91x 2000000.ethernet
(unnamednet_device) (uninitialized):smc_reset[ 20.596832] smc91x 2000000.ethernet (unnamednet_device)
(uninitialized):smc_phy_detect[ 20.611938] smc91x
2000000.ethernet (unnamednet_device) (uninitialized):
smc91x:smc_shutdown[ 20.615875] smc91x 2000000.ethernet
eth0: SMC91C11xFD (rev 1) atd08be000IRQ 166 [ 20.618682][ 20.621124] smc91x 2000000.ethernet eth0: Ethernet addr:52:54:00:12:34:56 [ 20.624938] smc91x 2000000.ethernet
eth0: No PHY found(and eth0 exists in ifconfig)
If I do not apply my patch I got this error message:
[ 22.134704] smc91x 2000300.ethernet (unnamed net_device) (uninitialized): smc91x: bank signature probe returned 0x0000 [ 22.140014] smc91x: not found (-19).Quoted 4 lines
and no ethernet device was registered.
With 2.6.28 kernel with N900 patches (but smc91x is unmodified!) ethernet device is working fine.
Quoted 7 lines
OK that's good news. Care to do a patch to set the offset
0x0with added comment that qemu needs it? I'll test to make sure it works on the real hardware as well.Regards,
Tony
Yes, I can send proper git format-patch, but first let me know if that change does not break your HW...
Signature · 2 lines
Pali Rohár [email protected]
Quoted 3 lines · On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote:
Quoted 2 lines · Pali Rohár
Quoted 1 line · On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote:
Quoted 1 line
*/ +// reg = <1
0x3000xf>; /* 16 byte IO range
at
Quoted 4 lines
Quoted 4 lines
offset
Quoted 1 line
Quoted 1 line
0x300*/ + reg = <10x00xf>; /* 16 byte IO
range
Quoted 32 lines
Quoted 11 lines
at
Quoted 8 lines
arch/arm/boot/dts/omap3-n900.dts line 777
Quoted 5 lines
offset
0x300*/arch/arm/boot/dts/omap3-n900.dts +0
-0bank-width = <2>; pinctrl-names = "default"; pinctrl-0 = <ðernet_pins>;Oh cool, the
0x300offset is there mostly to suppress warnings about non-standard location....
Quoted 6 lines
Quoted 3 lines
OK that's good news. Care to do a patch to set the offset
0x0with added comment that qemu needs it? I'll test to make sure it works on the real hardware as well.Yes, I can send proper git format-patch, but first let me know if that change does not break your HW...
Yes using reg = <1 0
0xf> works, it just adds this extra warning:smc91x 2000000.ethernet (unnamed
net_device) (uninitialized):
smc91x: IOADDRd09d6000doesn't match configuration (300).And I'm pretty sure that can be fixed by setting the EEPROM offset to 0 instead of the default
0x300. People with smc91x most likely want to write at least the MAC address to the EEPROM, so might as well set the offset to zero then too.
Quoted 6 lines
Of course it's always possible to do do a
omap3-n900-qemu.dtsif larger changes are needed :)Regards,
Tony
I would like to avoid using separate DTS for qemu. When we have only one DTS file (for both qemu and real HW), we can test for regression in qemu and we are sure that we have same software configuration...
Signature · 2 lines
Pali Rohár [email protected]
Quoted 13 lines · Pali Rohár
Quoted 1 line · On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote:
Quoted 1 line
*/ +// reg = <1
0x3000xf>; /* 16 byte IO range atoffset
Quoted 1 line
Quoted 1 line
0x300*/ + reg = <10x00xf>; /* 16 byte IO rangeat
Quoted 8 lines
arch/arm/boot/dts/omap3-n900.dts line 777
Quoted 5 lines
offset
0x300*/arch/arm/boot/dts/omap3-n900.dts +0
-0bank-width = <2>; pinctrl-names = "default"; pinctrl-0 = <ðernet_pins>;Oh cool, the
0x300offset is there mostly to suppress warnings about non-standard location.
...
Quoted 6 lines
Quoted 3 lines
OK that's good news. Care to do a patch to set the offset
0x0with added comment that qemu needs it? I'll test to make sure it works on the real hardware as well.Yes, I can send proper git format-patch, but first let me know if that change does not break your HW...
Yes using reg = <1 0 0xf> works, it just adds this extra warning:
smc91x 2000000.ethernet (unnamed net_device) (uninitialized):
smc91x: IOADDR d09d6000 doesn't match configuration (300).
And I'm pretty sure that can be fixed by setting the EEPROM offset to 0 instead of the default 0x300. People with smc91x most likely want to write at least the MAC address to the EEPROM, so might as well set the offset to zero then too.
Of course it's always possible to do do a omap3-n900-qemu.dts if larger changes are needed :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Pali Rohár
Quoted 2 lines · On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote:
Of course it's always possible to do do a
omap3-n900-qemu.dtsif larger changes are needed :)I would like to avoid using separate DTS for qemu. When we have only one DTS file (for both qemu and real HW), we can test for regression in qemu and we are sure that we have same software configuration...
Agreed, and I'd rather take the extra warning on rare to find hardware to avoid an etra .dts file.
Are there any reasons whey the n900 qemu support could not be in the mainline qemu btw?
Regards,
Tony
Quoted 13 lines · On Thursday 19 February 2015 05:50:48 Tony Lindgren wrote:
Quoted 8 lines · Pali Rohár
Quoted 2 lines · On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote:
Of course it's always possible to do do a
omap3-n900-qemu.dtsif larger changes are needed :)I would like to avoid using separate DTS for qemu. When we have only one DTS file (for both qemu and real HW), we can test for regression in qemu and we are sure that we have same software configuration...
Agreed, and I'd rather take the extra warning on rare to find hardware to avoid an etra .dts file.
Quoted 6 lines
Are there any reasons whey the n900 qemu support could not be in the mainline qemu btw?
Regards,
Tony
Missing lot of omap stuff (in mainline qemu) which linaro have not sent to mainline yet...
Signature · 2 lines
Pali Rohár [email protected]
Quoted 39 lines · On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote:
Quoted 17 lines · Pali Rohár
Quoted 1 line · On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote:
Quoted 1 line
*/ +// reg = <1
0x3000xf>; /* 16 byte IO range atoffset
Quoted 1 line
Quoted 1 line
0x300*/ + reg = <10x00xf>; /* 16 byte IO rangeat
Quoted 8 lines
arch/arm/boot/dts/omap3-n900.dts line 777
Quoted 5 lines
offset
0x300*/arch/arm/boot/dts/omap3-n900.dts +0
-0bank-width = <2>; pinctrl-names = "default"; pinctrl-0 = <ðernet_pins>;Oh cool, the
0x300offset is there mostly to suppress warnings about non-standard location....
Quoted 6 lines
Quoted 3 lines
OK that's good news. Care to do a patch to set the offset
0x0with added comment that qemu needs it? I'll test to make sure it works on the real hardware as well.Yes, I can send proper git format-patch, but first let me know if that change does not break your HW...
Yes using reg = <1 0
0xf> works, it just adds this extra warning:smc91x 2000000.ethernet (unnamed
net_device) (uninitialized):
smc91x: IOADDRd09d6000doesn't match configuration (300).And I'm pretty sure that can be fixed by setting the EEPROM offset to 0 instead of the default
0x300. People with smc91x most likely want to write at least the MAC address to the EEPROM, so might as well set the offset to zero then too.
Quoted 6 lines
Of course it's always possible to do do a
omap3-n900-qemu.dtsif larger changes are needed :)Regards,
Tony
Anyway, here are original Nokia board data (2.6.28) for smc91x ethernet:
Can you check if it match with our data in DT file?
Signature · 2 lines
Pali Rohár [email protected]