Hi, On Fri, May 22, 2015 at 11:13:22PM +0300, Ben Dooks wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 22/05/15 16:50, Felipe Balbi wrote: > > Hi, > > > > On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote: > >> I am trying to get the full-speed USB host working on an custom > >> AM3517 device with the 3.18.12 kernel. The hardware works (a > >> 2.6.37 kernel has been used for testing). > >> > >> Does anyone have any experience of 3.18 (or similarly recent > >> kernel on an AM3517 system) or have any pointers as where to > >> start debugging? The ti-linux-3.14.y does not have any patches > >> that aren't applied to the usb on 3.18.13. > >> > >> The cpu port 1 is connected by a TI TUSB1106 usb transceiver that > >> is directly connected to a full-speed hub (TI USB2046) hub so the > >> OHCI driver is the only one in use. > >> > >> Note, the ohci-omap3 is loaded as a module as this is how their > >> user application expects to be able to shut down usb when it does > >> not need it. > >> > >> The device tree configuration for the usb host: > > > > and what exactly doesn't work ? That old OHCI driver hasn't been > > touched in years, it's no surprise that it stopped working :-( > > > > Anyway, what exactly doesn't work ? No device enumerates ? Do you > > get any IRQs by plugging a new device in ? > > I will check the interrupts when I get back into the office. > > There is only one device (the hub) which isn't enumerating and is > hard-wired on the board.
alright, that makes things a little more difficult :-)
> >>> &usbhshost { status = "okay"; /* just in case it is started
> >>> disabled */
> >>>
> >>> port1-mode = "ohci-phy-6pin-dpdm"; };
> >>>
> >>> &usbhsohci { status = "okay"; };
> >>>
> >>> &usbhsehci { status = "disabled"; /* no ehci on board */ };
> >>
> >>
> >> The usb from the logs is as follows. Some extra debugging has
> >> been added to verify the device-tree settings:
> >>
> >>> [ 0.000000] AM3517 ES1.1 (l2cache sgx neon)
> >>>
> >>>
> >>> [ 0.869706] usbcore: registered new interface driver usbfs
> >>> [ 0.874270] usbcore: registered new interface driver hub
> >>> [ 0.878592] usbcore: registered new device driver usb
> >>> [ 1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB
> >>> TLL Controller [ 1.273000] usbhs_omap 48064000.usbhshost:
> >>> ports 0 [ 1.278291] usbhs_omap 48064000.usbhshost: port 0:
> >>> ohci-phy-6pin-dpdm [ 1.284476] usbhs_omap
> >>> 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5 [
> >>> 1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()
> >>> [ 1.293628] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_resume [ 1.298434] usbhs_omap
> >>> 48064000.usbhshost: sysconfig 0x00001009 [ 1.302730]
> >>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
> >>> [ 1.307668] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_suspend [ 1.310142] stopping usb controller
> >>> [ 1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()
> >>> [ 1.423547] usbhs_omap 48064000.usbhshost: 3 ports
> >>> [ 1.429065] usbhs_omap 48064000.usbhshost: starting TI
> >>> HSUSB Controller [ 1.433831] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_resume [ 1.438625] usbhs_omap
> >>> 48064000.usbhshost: sysconfig 0x00001009 [ 1.442921]
> >>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
> >>> [ 1.448548] usbhs_omap 48064000.usbhshost:
> >>> omap_usbhs_rev1_hostconfig => [ 1.455034] usbhs_omap
> >>> 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d [
> >>> 1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
> >>> [ 1.462337] stopping usb controller
> >>> [ 1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()
> >>> [ 1.575408] usbhs_omap 48064000.usbhshost: populating usb
> >>> sub nodes....
> >>>
> >>> [ 77.609168] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_resume [ 77.613927] usbhs_omap
> >>> 48064000.usbhshost: sysconfig 0x00001009 [ 77.618374]
> >>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
> >>> [ 77.802694] usb usb1: New USB device found, idVendor=1d6b,
> >>> idProduct=0001 [ 77.816003] usb usb1: New USB device strings:
> >>> Mfr=3, Product=2, SerialNumber1 [ 77.827391] usb usb1:
> >>> Product: OHCI Host Controller [ 77.838674] usb usb1:
> >>> Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty ohci_d [
> >>> 77.849913] usb usb1: SerialNumber: 48064400.ohci
> >>>
> >
> > OK, so this is roothub, what happens when a device is plugged to
> > the other end ? Is VBUS charged ? We didn't even enumerate
> > TUSB2046, did you look at its datasheet
> > (http://www.ti.com/lit/ds/symlink/tusb2046b.pdf) ? What is the
> > state of RESETn pin ? Perhaps that's tied to a GPIO and the old TI
> > kernel toggles that ? Anything interesting from usbmon ?
>
> I've gone through the schematics and verified the hub's reset line
> is connected where we think it is (will try and check with a 'scope
> on monday that it is being taken high, the boot-loader starts it low).
>
> The root has just the one device connected, and unfortunately the
> hw designer decided to hard-wire the D+ pull-up to 3.3V instead
> of the transceiver's pull pin.
>
> Not tried usbmon yet. However if the hub is not being detected then
> probably won't show anything either.
>
> I am going to install devmem2 into the root image and use it to poke
> around and see the state of the system at run time.
>
> Thanks for looking in to this.
yeah, no problem. You probably want to first make sure VBUS is alive
behind the HUB (iow, make sure the hub is powered up as you'd expect),
then make sure VBUS is coming out on the other end (the hub's ports).
The make sure RESETn is high as you'd want it to be. After that, then I
guess only register pick-and-poke is left.
cheers
--
balbi
signature.asc
Description: Digital signature
