public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] axs103: add support of generic OHCI USB 1.1 controller
Date: Thu, 17 Dec 2015 16:08:34 +0100	[thread overview]
Message-ID: <201512171608.34689.marex@denx.de> (raw)
In-Reply-To: <1450359146.3218.3.camel@synopsys.com>

On Thursday, December 17, 2015 at 02:32:26 PM, Alexey Brodkin wrote:
> Hi Marek,
> 
> On Thu, 2015-12-17 at 05:01 +0100, Marek Vasut wrote:
> > On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
> > > Hi Marek,
> > 
> > Hi!
> > 
> > > On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
> > > > On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
> > > > > This commit adds support of USB 1.1 storage media on AXS103 board.
> > > > > For some yet unknown reason USB 2.0 doesn't work on AXS103 board
> > > > > issuing messages like this:
> > > > > ------------------------>8-------------------
> > > > > AXS# usb start
> > > > > starting USB...
> > > > > USB0:   USB EHCI 1.00
> > > > > scanning bus 0 for devices... EHCI timed out on TD -
> > > > > token=0x80008c80 unable to get device descriptor (error=-1)
> > > > > 1 USB Device(s) found
> > > > > ------------------------>8-------------------
> > > > 
> > > > Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
> > > 
> > > Thanks for that tip but it made no difference to me.
> > > I need to look deeper into that problem.
> > 
> > I remember seeing that stuff multiple times before, but it might be a
> > different issue. It was usually triggered by some sort of corruption
> > during the transfer. On ARM, that was often caused by cache issues.
> 
> Believe me I know how much of a grief caches bring so the first thing I do
> when seeing unexpected behavior I disable caches :)
> 
> > > Just a bit of a context here.
> > > 
> > > I'm playing with ARC SP board which consists of 2 parts:
> > >  [1] Baseboard with all peripherals and their connectors
> > >  [2] Daughterboard with CPU and DDR
> > > 
> > > Baseboard is connected to CPU-board via AXI tunnel.
> > > 
> > > And when CPU-board is the one with ASIC based on ARC770
> > > that runs at 700 MHz I see USB 2.0 working perfectly fine.
> > > 
> > > But if I use CPU-board that sports FPGA with ARC HS38 CPU
> > > running at 75 MHz I see the first asynchronous tarnsaction
> > > on US 2.0 never happens.
> > 
> > Connect signaltap or chipscope ? :)
> 
> Well I don't have either of those tools sitting on my desk but
> if absolutely required I'll do that :)
> 
> > > In particular in ehci_submit_async() after we enable async. schedule
> > > setting CMD_ASE command STS_ASS gets set but then token's status
> > > stays active forever i.e. following is always true:
> > > --------------------->8---------------------
> > > QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE
> > > --------------------->8---------------------
> > > 
> > > Note USB host controller, phy and usb dongle are exactly the same.
> > > And USB 1.1 (OHCI) works perfectly fine at the same time.
> > 
> > Try adding #define DEBUG at the first line of common/usb.c , so we can
> > get some more debugging info. Also adding the same into common/usb_hub.c
> > helps.
> 
> Did that and here's my log:
> 
> --------------------->8---------------------
> starting USB...
> USB0:   ehci_register: dev='ehci at 0xe0040000', ctrl=9fd94100, hccr=e0040000,
> hcor=e0040010, init=0 Register 1111 NbrPorts 1
> USB EHCI 1.00
> scanning bus 0 for devices... ehci_submit_control_msg:
> dev='ehci at 0xe0040000', udev=9fd7c000, udev->dev='ehci at 0xe004000 req=6
> (0x6), type=128 (0x80), value=256, index=0
> USB_DT_DEVICE request
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=5 (0x5), type=0 (0x0), value=1,
> index=0
> USB_REQ_SET_ADDRESS
> Len is 0
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80),
> value=256, index=0
> USB_DT_DEVICE request
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80),
> value=512, index=0
> USB_DT_CONFIG config
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80),
> value=512, index=0
> USB_DT_CONFIG config
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=9 (0x9), type=0 (0x0), value=1,
> index=0
> USB_REQ_SET_CONFIGURATION
> Len is 0
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80),
> value=768, index=0
> USB_DT_STRING config
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80),
> value=769, index=1
> USB_DT_STRING config
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7c000,
> udev->dev='ehci at 0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80),
> value=770, index=1
> USB_DT_STRING config
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496,
> index=0
> USB_DT_HUB config
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496,
> index=0
> USB_DT_HUB config
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=0 (0x0), type=160 (0xa0), value=0,
> index=0
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=8,
> index=1
> Len is 0
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0,
> index=1
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0,
> index=1
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=16,
> index=1
> Len is 0
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=4,
> index=1
> Len is 0
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0,
> index=1
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=20,
> index=1
> Len is 0
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd7b100,
> udev->dev='usb_hub', portnr=1 dev=9fd7b100, pipe=80000083,
> buffer=9fd7ae00, length=64, req=9fd7ad00 req=6 (0x6), type=128 (0x80),
> value=256 (0x100), index=0
> EHCI timed out on TD - token=0x80008c80
> dev=0, usbsts=0x1, p[1]=0x1005, p[2]=0x0
> unable to get device descriptor (error=-1)
> ehci_submit_control_msg: dev='ehci at 0xe0040000', udev=9fd94380,
> udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=1,
> index=1
> Len is 0
> 1 USB Device(s) found
> AXS#
> --------------------->8---------------------
> 
> Makes any sense?

Am I reading it correctly that the root hub (the one built into the controller)
is misbehaving here ?

> Note in case of ARC770 the log is very similar except the fact that it goes
> further to successful device detection.
> 
> -Alexey

  reply	other threads:[~2015-12-17 15:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 16:05 [U-Boot] [PATCH] axs103: add support of generic OHCI USB 1.1 controller Alexey Brodkin
2015-12-16 16:52 ` Marek Vasut
2015-12-16 19:54   ` Alexey Brodkin
2015-12-17  4:01     ` Marek Vasut
2015-12-17 13:32       ` Alexey Brodkin
2015-12-17 15:08         ` Marek Vasut [this message]
2015-12-17 15:24           ` Alexey Brodkin
2015-12-21 20:34           ` Alexey Brodkin
2015-12-21 22:18             ` Marek Vasut
2015-12-23 11:59               ` Alexey Brodkin
2015-12-24  9:51                 ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201512171608.34689.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox