Date: Sat, 23 Mar 2013 20:40:48 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Jeff Penn <jeff@jrpenn.demon.co.uk> Cc: freebsd-arm@FreeBSD.org Subject: Re: Net booting current snapshot on openrd and sheevaplug Message-ID: <1364092848.1157.165.camel@revolution.hippie.lan> In-Reply-To: <20130323231302.GA60043@jrpenn.demon.co.uk> References: <20130323183037.GA39897@beastie.jrpenn.demon.co.uk> <1364067518.1157.163.camel@revolution.hippie.lan> <20130323231302.GA60043@jrpenn.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2013-03-23 at 23:13 +0000, Jeff Penn wrote:
> On Sat, Mar 23, 2013 at 01:38:38PM -0600, Ian Lepore wrote:
> > On Sat, 2013-03-23 at 18:30 +0000, Jeff Penn wrote:
> > > I'm having problems net booting following the instruction on the
> > > wiki. The kernel networking is failing on an openrd ultimate. My
> > > sheevaplug gets as far as completing the DHCP request, but does not
> > > generate any NFS traffic. Both systems run Debian, ruling out hardware.
>
> > Netbooting works on my similar DreamPlug systems using -current. I'm
> > using the DREAMPLUG-1001 dts file and kernel config that are checked in,
> > but with the BOOTP and NFSROOT options added.
> >
> > For the OpenRD it looks like the problem is that it can't find the phy.
> > I've seen these *Plug systems use either 0 and 1 or 8 and 24 as the phy
> > addresses for mge0 and mge1 respectively; you might try changing those
> > in the dts file. In theory a phy address of -1 should work for mge0 to
> > have it probe for a phy, but that's from looking at the code, I've never
> > tried it.
>
> This got me a bit further, I'm still experimenting with values. I've
> tried setting the reg in sys/boot/fdt/dts/db88f6281.dts and rebuilding
> the kernel (I'm not a developer). The boot gets further and is now
> failing to transmit a DHCP request (dmesg below). I'll spend more time
> on this next week.
>
> enet0: ethernet@72000 {
> #address-cells = <1>;
> #size-cells = <1>;
> model = "V2";
> compatible = "mrvl,ge";
> reg = <0x72000 0x2000>;
> ranges = <0x0 0x72000 0x2000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <12 13 14 11 46>;
> interrupt-parent = <&PIC>;
> phy-handle = <&phy0>;
>
> mdio@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "mrvl,mdio";
>
> phy0: ethernet-phy@0 {
> reg = <0xFFFFFFFF>;
> };
> };
> };
>
> > For the Sheeva, I'm not sure what would lead to those RPC timeouts, I've
> > never seen that happen. I've got all these options for nfs root:
> >
> > options NFSCL
> > options NFSLOCKD
> > options NFS_ROOT
> > options BOOTP
> > options BOOTP_NFSROOT
> > options BOOTP_NFSV3
> > options BOOTP_WIRED_TO=mge0
>
> Those are in the default kernel configs for both systems.
>
> thanks
> Jeff
>
> .....
> mge0: <Marvell Gigabit Ethernet controller> mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0
> mge0: Ethernet address: f0:ad:4e:00:61:58
> miibus0: <MII bus> on mge0
> e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
> e1000phy1: <Marvell 88E1149 Gigabit PHY> PHY 1 on miibus0
> e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
> ifmedia_match: multiple match for 0x20/0xfffffff
> uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0
> uart0: console (115740,n,8,1)
> uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0
> cesa0: <Marvell Cryptographic Engine and Security Accelerator> mem 0xf1030000-0xf103ffff irq 22 on simplebus0
> ehci0: <Marvell Integrated USB 2.0 controller> mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0
> usbus0: EHCI version 1.0
> usbus0: set host controller mode
> usbus0 on ehci0
> mvs0: <Marvell 88F6281 SATA controller> mem 0xf1080000-0xf1085fff irq 21 on simplebus0
> mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS
> mvsch0: <Marvell SATA channel> at channel 0 on mvs0
> mvsch1: <Marvell SATA channel> at channel 1 on mvs0
> pcib0: <Marvell Integrated PCI/PCI-E Controller> mem 0xf1040000-0xf1041fff irq 44 on fdtbus0
> pcib0: PCI IO/Memory space exhausted
> device_attach: pcib0 attach returned 12
> cryptosoft0: <software crypto>
> Timecounters tick every 10.000 msec
> usbus0: 480Mbps High Speed USB v2.0
> ugen0.1: <Marvell> at usbus0
> uhub0: <Marvell EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
> bootpc_init: wired to interface 'mge0'
> mge0: Timeout on link-up
> mge0: Timeout on link-up
> Sending DHCP Discover packet from interface mge0 (f0:ad:4e:00:61:58)
What was the value before you changed it to -1? It looks like it probed
and found both 0 and 1, maybe that confused it. If the value wasn't
zero originally, I'd say change it to that. If that amounts to changing
it back to what it was, the problem must be elsewhere.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1364092848.1157.165.camel>