Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: > * Pali Rohár [150218 11:07]: > > On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote: > > > > */ +// 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. > > ... > > > > 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. > > > > 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 200.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 Anyway, here are original Nokia board data (2.6.28) for smc91x ethernet: https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L42 https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L274 Can you check if it match with our data in DT file? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Thursday 19 February 2015 05:50:48 Tony Lindgren wrote: > * Pali Rohár [150218 15:58]: > > On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: > > > Of course it's always possible to do do a > > > omap3-n900-qemu.dts if 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 Missing lot of omap stuff (in mainline qemu) which linaro have not sent to mainline yet... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150218 15:58]: > On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: > > Of course it's always possible to do do a omap3-n900-qemu.dts > > if 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150218 11:07]: > On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote: > > > */ +//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. ... > > 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. > > 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 200.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote: > * Pali Rohár [150218 11:07]: > > On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote: > > > > */ +// 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. > > ... > > > > 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. > > > > 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 200.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 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... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote:
> * Pali Rohár [150218 07:23]:
> > 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
> > >
> > > --- a/arch/arm/boot/dts/omap3-n900.dts
> > > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > > @@ -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
> > >
> > > */
> >
> > Hello Tony,
> >
> > to make smc ethernet working in n900 qemu I needed to apply
> > this patch:
> >
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts
> > b/arch/arm/boot/dts/omap3-n900.dts index ff36fbe..d96eeb8
> > 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -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.
>
> > With this patch I see in dmesg:
> >
> > [ 20.577911] smc91x 200.ethernet (unnamed net_device)
> > (uninitialized): smc91x: smc_probe [ 20.580535] smc91x
> > 200.ethernet (unnamed net_device) (uninitialized):
> > smc91x: bank signature probe returned 0x3300
> > [ 20.585327] smc91x 200.ethernet (unnamed net_device)
> > (uninitialized): smc91x: revision = 0x3391 [ 20.590087]
> > smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
> > [ 20.593627] smc91x 200.ethernet
> > (unnamed net_device) (uninitialized): smc_reset [
> > 20.596832] smc91x 200.ethernet (unnamed net_device)
> > (uninitialized): smc_phy_detect [ 20.611938] smc91x
> > 200.ethernet (unnamed net_device) (uninitialized):
> > smc91x: smc_shutdown [ 20.615875] smc91x 200.ethernet
> > eth0: SMC91C11xFD (rev 1) at d08be000 IRQ 166 [
> > 20.618682]
> > [ 20.621124] smc91x 200.ethernet eth0: Ethernet addr:
> > 52:54:00:12:34:56 [ 20.624938] smc91x 200.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
> > 0x
> > [ 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
Yes, I can send proper git format-patch, but first let me know if
that change does not break your HW...
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150218 07:23]:
> 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
> >
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -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
> > */
>
> Hello Tony,
>
> to make smc ethernet working in n900 qemu I needed to apply this patch:
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts
> index ff36fbe..d96eeb8 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -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.
> With this patch I see in dmesg:
>
> [ 20.577911] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: smc_probe
> [ 20.580535] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: bank signature probe
> returned 0x3300
> [ 20.585327] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: revision = 0x3391
> [ 20.590087] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
> [ 20.593627] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc_reset
> [ 20.596832] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc_phy_detect
> [ 20.611938] smc91x 200.ethernet (unnamed net_device) (uninitialized):
> smc91x: smc_shutdown
> [ 20.615875] smc91x 200.ethernet eth0: SMC91C11xFD (rev 1) at d08be000
> IRQ 166
> [ 20.618682]
> [ 20.621124] smc91x 200.ethernet eth0: Ethernet addr: 52:54:00:12:34:56
> [ 20.624938] smc91x 200.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 0x
> [ 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
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
>
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -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
> */
Hello Tony,
to make smc ethernet working in n900 qemu I needed to apply this patch:
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index ff36fbe..d96eeb8 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -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 200.ethernet (unnamed net_device) (uninitialized):
smc91x: smc_probe
[ 20.580535] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc91x: bank signature probe
returned 0x3300
[ 20.585327] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc91x: revision = 0x3391
[ 20.590087] smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre
[ 20.593627] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc_reset
[ 20.596832] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc_phy_detect
[ 20.611938] smc91x 200.ethernet (unnamed net_device) (uninitialized):
smc91x: smc_shutdown
[ 20.615875] smc91x 200.ethernet eth0: SMC91C11xFD (rev 1) at d08be000
IRQ 166
[ 20.618682]
[ 20.621124] smc91x 200.ethernet eth0: Ethernet addr: 52:54:00:12:34:56
[ 20.624938] smc91x 200.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 0x
[ 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.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150108 01:04]: > 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 DEVICEreq 42 value index > > 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 DEVICEreq 82 value index > > length > > [ 2.309] SETUP: WR STD INTERFACE > > SET_INTERFACE value index 0002 length > > [ 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? Probably it was built with some debug flags enabled, at least I don't think those can be enabled otherwise. > 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': 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
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 DEVICEreq 42 value index > 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 DEVICEreq 82 value index > length > [ 2.309] SETUP: WR STD INTERFACE > SET_INTERFACE value index 0002 length > [ 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 -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Wed 2015-01-07 08:40:06, Tony Lindgren wrote:
> * Nishanth Menon [150107 07:47]:
> > On 01/07/2015 03:57 AM, Pavel Machek wrote:
> > > On Tue 2015-01-06 08:59:03, Tony Lindgren wrote:
> > >> * Pavel Machek [150106 00:03]:
> > >>> On Mon 2015-01-05 15: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
> > >>>
> > >>> 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.
> > >>
> > >>> 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 0x?
> > >
> > > 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=14194620311&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 0x using 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Wed 2015-01-07 08:40:06, Tony Lindgren wrote:
> * Nishanth Menon [150107 07:47]:
> > On 01/07/2015 03:57 AM, Pavel Machek wrote:
> > > On Tue 2015-01-06 08:59:03, Tony Lindgren wrote:
> > >> * Pavel Machek [150106 00:03]:
> > >>> On Mon 2015-01-05 15: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
> > >>>
> > >>> 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.
> > >>
> > >>> 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 0x?
> > >
> > > 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=14194620311&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 0x using something like:
Interesting.
> $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > /tmp/zImage
> $ 0x -m /tmp/zImage -l -b
I'm doing something similar, with difference that I also pass
commandline using -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.
Ok, I'll try with defconfig, and am sending you my .config in case it
depends on it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
config.gz
Description: application/gzip
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Hi! > >> 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 0x? > > > > 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=14194620311&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: <20141110150915.gh31...@atomide.com> Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Nishanth Menon [150107 07:47]:
> On 01/07/2015 03:57 AM, Pavel Machek wrote:
> > On Tue 2015-01-06 08:59:03, Tony Lindgren wrote:
> >> * Pavel Machek [150106 00:03]:
> >>> On Mon 2015-01-05 15: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
> >>>
> >>> 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.
> >>
> >>> 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 0x?
> >
> > 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=14194620311&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 0x using something like:
$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > /tmp/zImage
$ 0x -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 DEVICEreq 42 value index 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 DEVICEreq 82 value index length
[ 2.309] SETUP: WR STD INTERFACE SET_INTERFACE value index 0002
length
[ 2.363] Boot requested (normal mode)
[ 2.367] Serial console enabled
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] 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.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
[0.00] Machine model: Nokia N900
[0.00] cma: Reserved 16 MiB at 0x8e80
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] PERCPU: Embedded 11 pages/cpu @cfc36000 s14912 r8192 d21952
u45056
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 64704
[0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait
console=ttyO2,115200
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 223700K/261120K available (6215K kernel code, 674K
rwdata, 2360K rodata, 428K init, 8221K bss, 21036K reserved, 16384K
cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff0
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On 01/07/2015 03:57 AM, Pavel Machek wrote:
> On Tue 2015-01-06 08:59:03, Tony Lindgren wrote:
>> * Pavel Machek [150106 00:03]:
>>> On Mon 2015-01-05 15: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
>>>
>>> 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.
>>
>>> 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 0x?
>
> 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=14194620311&r=1&w=2 Apologies on not following
up on the thread, got distracted.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Tue 2015-01-06 08:59:03, Tony Lindgren wrote:
> * Pavel Machek [150106 00:03]:
> > On Mon 2015-01-05 15: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
> >
> > 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.
>
> > 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 0x?
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.
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 53f3ca0..82f4597 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -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 {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Aaro Koskinen [150106 13:59]: > Hi, > > On Tue, Jan 06, 2015 at 11:54:55AM -0800, Tony Lindgren wrote: > > 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. > > 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Hi, On Tue, Jan 06, 2015 at 11:54:55AM -0800, Tony Lindgren wrote: > 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150106 12:37]: > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Tue 2015-01-06 12:17:59, Tony Lindgren wrote:
> * Tony Lindgren [150106 12:01]:
> > * Aaro Koskinen [150106 11:47]:
> > > Hi,
> > >
> > > On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote:
> > > > * Pavel Machek [150106 00:03]:
> > > > > On Mon 2015-01-05 15: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
> > > > >
> > > > > 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.
> > > >
> > > > > 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.
> > >
> > > Tested-by: Aaro Koskinen
> >
> > OK good to hear, thanks for testing.
> >
> > > 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.
>
> 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Tuesday 06 January 2015 21:17:59 Tony Lindgren wrote:
> * Tony Lindgren [150106 12:01]:
> > * Aaro Koskinen [150106 11:47]:
> > > Hi,
> > >
> > > On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren
wrote:
> > > > * Pavel Machek [150106 00:03]:
> > > > > On Mon 2015-01-05 15: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
> > > > >
> > > > > 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.
> > > >
> > > > > 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.
> > >
> > > Tested-by: Aaro Koskinen
> >
> > OK good to hear, thanks for testing.
> >
> > > 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.
>
> 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
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Tony Lindgren [150106 12:01]:
> * Aaro Koskinen [150106 11:47]:
> > Hi,
> >
> > On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote:
> > > * Pavel Machek [150106 00:03]:
> > > > On Mon 2015-01-05 15: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
> > > >
> > > > 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.
> > >
> > > > 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.
> >
> > Tested-by: Aaro Koskinen
>
> OK good to hear, thanks for testing.
>
> > 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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Tuesday 06 January 2015 20:44:43 Aaro Koskinen wrote:
> Hi,
>
> On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote:
> > * Pavel Machek [150106 00:03]:
> > > On Mon 2015-01-05 15: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
> > >
> > > 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.
> >
> > > 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.
>
> Tested-by: Aaro Koskinen
>
> 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
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Aaro Koskinen [150106 11:47]:
> Hi,
>
> On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote:
> > * Pavel Machek [150106 00:03]:
> > > On Mon 2015-01-05 15: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
> > >
> > > 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.
> >
> > > 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.
>
> Tested-by: Aaro Koskinen
OK good to hear, thanks for testing.
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Hi,
On Tue, Jan 06, 2015 at 08:59:03AM -0800, Tony Lindgren wrote:
> * Pavel Machek [150106 00:03]:
> > On Mon 2015-01-05 15: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
> >
> > 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.
>
> > 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.
Tested-by: Aaro Koskinen
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Tony Lindgren writes:
> 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
Tested-by: Kevin Hilman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pavel Machek [150106 00:03]:
> On Mon 2015-01-05 15: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
>
> 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.
> 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?
> [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
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.
Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -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 */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Tuesday 06 January 2015 16:03:54 Sebastian Reichel wrote: > Hi Pali, > > On Tue, Jan 06, 2015 at 12:09:15AM +0100, Pali Rohár wrote: > > 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 I do not know, but n900 support is part of linaro qemu version. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Hi Pali, On Tue, Jan 06, 2015 at 12:09:15AM +0100, Pali Rohár wrote: > 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 signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
On Mon 2015-01-05 15: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
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
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -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 */
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
* Pali Rohár [150105 15:12]: > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Just to note that smc91x ethernet support is also in qemu n900
emulation. Later I will try if it work with upstream kernel...
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
>
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -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
> */
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[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.
Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -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 */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
