Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 01 Sep 2013 12:44:53 -0600
From:      Ian <hippie@damnhippie.dyndns.org>
To:        "army.of.root" <army.of.root@gmail.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: dockstar (kirkwood) EHCI needs "usb start" in u-boot or it will hang
Message-ID:  <1378061093.1111.358.camel@revolution.hippie.lan>
In-Reply-To: <52235263.5080503@googlemail.com>
References:  <52235263.5080503@googlemail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2013-09-01 at 16:42 +0200, army.of.root wrote:
> Hi,
> 
> I just spent an hour trying to get my dockstar to boot a head kernel.
> 
> I switched from putting the kernel on a usb drive to booting it via tftp from 
> u-boot for convienience purposes.
> The usb drive boot script in u-boot obviously starts up the usb subsystem, but 
> I left it out for the tftp routine.
> 
> This resulted in a hanging Kernel on this output:
> 
> > ehci0: <Marvell Integrated USB 2.0 controller> mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0
> > usbus0: EHCI version 1.0
> > usbus0: stop timeout
> > usbus0: set host controller mode
> > usbus0 on ehci0
> >
> 
> After having a joyful moment of clarity and adding the command "usb start" to 
> my tftp uboot script, the issue was resolved.
> 
> 
> Is this expected behavior?
> 
> Or am I missing a kernel option (various combinations did not help including 
> the default DOCKSTAR config)?

Strange, it's not like that on my similar DreamPlug system...

Marvell>> usb info
USB is stopped. Please issue 'usb start' first.
Marvell>> run netboot
BOOTP broadcast 1
...
FreeBSD 10.0-CURRENT #7 r254449M: Thu Aug 29 12:19:59 MDT 2013

root@revolution.hippie.lan:/local/build/staging/freebsd/dp10/obj/arm.arm/local/build/staging/freebsd/dp10/src/sys/DP-NFSROOT arm
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
CPU: Feroceon 88FR131 rev 1 (Marvell core)
  Little-endian DC enabled IC enabled WA disabled DC streaming enabled
  BTB disabled L2 enabled L2 prefetch enabled
  WB enabled EABT branch prediction enabled
  16KB/32B 4-way instruction cache
  16KB/32B 4-way write-back-locking-C data cache
real memory  = 536870912 (512 MB)
avail memory = 515407872 (491 MB)
SOC: Marvell 88F6281 rev A1, TClock 200MHz
  Instruction cache prefetch disabled, data cache prefetch disabled
  256KB 4-way set-associative write-through unified L2 cache
...
ehci0: <Marvell Integrated USB 2.0 controller> mem 0xf1050000-0xf1050fff
irq 48,19 on simplebus0
usbus0: EHCI version 1.0
usbus0: stop timeout
usbus0: set host controller mode
usbus0 on ehci0
mvs0: <Marvell 88F6281 SATA controller> mem 0xf1080000-0xf1085fff irq 21
on simplebus0


It boots fine from there until it runs into the initrandom and tmpfs
problems we've been having on armv5 platforms.  If I ^C may through
those things and get logged on, I can run usbconfig and see devices.

I looked at the u-boot code for marvell ehci and it just initializes the
decode window registers before calling the stock ehci code.  That's also
what happens in the kernel, in arm/mv/common.c.  The thing I can't quite
figure out about the kernel code is the strange power management stuff
for marvell.  But I don't see the u-boot code doing any power management
stuff at all (maybe I just missed it).

-- Ian





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