Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Apr 2014 23:07:16 +0200
From:      Milan Obuch <milan@obuch.sk>
To:        Andreas Tobler <andreast-list@fgznet.ch>
Cc:        freebsd-arm@FreeBSD.org, Ian Lepore <ian@FreeBSD.org>
Subject:   Re: MARVELL BOARD: RD-88F6281A -CURRENT
Message-ID:  <20140406230716.13113e35@zeta.dino.sk>
In-Reply-To: <5341BC93.6080105@fgznet.ch>
References:  <53406D94.5020605@fgznet.ch> <1396732234.81853.334.camel@revolution.hippie.lan> <53407B53.4040807@fgznet.ch> <1396737091.81853.339.camel@revolution.hippie.lan> <5341AE1C.4040207@fgznet.ch> <1396815052.81853.346.camel@revolution.hippie.lan> <5341BC93.6080105@fgznet.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 06 Apr 2014 22:44:03 +0200
Andreas Tobler <andreast-list@fgznet.ch> wrote:

> On 06.04.14 22:10, Ian Lepore wrote:
> > On Sun, 2014-04-06 at 21:42 +0200, Andreas Tobler wrote:
> >> On 06.04.14 00:31, Ian Lepore wrote:
> >>> On Sat, 2014-04-05 at 23:53 +0200, Andreas Tobler wrote:

[ snip ]

> >>>> Sure, now I 'hang' in an other area.
> >>>>
> >>>> mge0: <Marvell Gigabit Ethernet controller> mem 0x72000-0x73fff
> >>>> irq 12,13,14,11,46 on simplebus0
> >>>> mge0: Ethernet address: 00:d0:b8:1e:3b:df
> >>>> mge0: attaching PHYs failed
> >>>> --> hangs
> >>>> According to the u-boot env I have two eth's and only the second
> >>>> is wired and used.
> >>>>
> >>>> From u-boot:
> >>>> Net:   egiga0, egiga1 [PRIME]
> >>>>
> >>>> Now my questions, how do I enable verbose boot? On PowerPC I
> >>>> know I have to do it in boot/loader.conf, here too?
> >>>>
> >>>> I guess my hardware is different from an eval board, so I expect
> >>>> I'd need a customized dts, no? If so, how do I get the
> >>>> information out of the u-boot?
> >>>> Again, thx a lot!
> >>>> Andreas
> >>>
> >>> You're probably not even using loader(8) but rather launching the
> >>> kernel directly (only newer arm systems and newer versions of
> >>> u-boot use loader).  That means things like tunables and
> >>> bootverbose have to be hacked into the kernel, at least for now
> >>> to make some progress.  The initarm_early_init() routine in
> >>> arm/mv/mv_machdep.c is a good place to throw in a bootverbose=1.
> >>
> >> Ok. I did it in sys/kern/init_main.c
> >>
> >>> For disabling egiga0 just add status="disabled" to its entry in
> >>> the dts file.  Have a look at the dreamplug dts files for an
> >>> example of setting up egiga1, but I'm not sure everything will be
> >>> exactly the same.  You may need to transplant the phy0 entry from
> >>> egiga0 into egiga1 for that box.
> >>
> >> Good start, thanks.
> >>
> >>> The 'bdinfo' command in u-boot sometimes shows lots of good info,
> >>> sometimes not so much.
> >>
> >> Hm, this command is not available in my env.
> >> Anyway, I figured to play with the regs in the enet dts section
> >> and I managed to get it up. Unfortunately I don't get any dhcp
> >> requests to the server, so no ack can be given. I'll play around.
> >>
> >> Sending DHCP Discover packet from interface mge0
> >> (00:d0:b8:1e:3b:df) ....
> >> DHCP/BOOTP timeout for server 255.255.255.255
> >> ....
> >>
> >> Thanks again!
> >> Andreas
> > 
> > I just realized that there's likely to be dts source for that box in
> > linux, and sure enough:
> > 
> > https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
> > 
> > There should be a lot of good clues in there, although we're not
> > quite so compatible that you can necessarily just paste linux dts
> > code into our dts files.
> 
> Yep, this is the place where I got the reg info, to change from xx to
> 0xb to get the interface attached. But nevertheless, I do not see any
> packets coming from this board. The tftpboot works, the dhcp-server
> works too, tested with ppc netboot. But this board does not really
> send out DHCPREQUESTS to the DHCP server.
> 
> But maybe I hunt in the wrong place, I have to compare the other
> entries. Right now I concentrated on the eth0/1 part.
> 
> Thanks.
> Andreas
> 

Maybe you need to check pin multiplexer setup. If eth1 is not connected
to pins, there is no connectivity. Some time ago I did have just this
problem - no packets on the wire, but it looked like mge1 interface
works well... after I found multiplexed pin setup, all was clear to me.

Milan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140406230716.13113e35>