[patch] (currently nonworking) attempt at USB host mode for MSM7201

[Andrew de Quincey]

Hi, I've been playing about with this for the last few days. Unfortunately it doesn't work correctly, and I'm running out of ideas to try. Therefore I'm posting my progress so far here in case anyone can shed some light.... Note that this patch is against the HTC Hero kernel source, but I imagine it would work for the G1 which is MSM7201A based as well.

First of all, I don't have the docs for the MSM7201A. However, from looking at the gadget support code, its obviously using the same EHCI USB core as various freescale CPUs. There are docs available for these, such as the MPC5121. The reference manual for that is available here: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5121e&nodeId=0162468rH3DgbNGrmC22FA&fpsp=1&tab=Documentation_Tab

Note that the MSM7201a appears to have a slightly newer core; the REVISION field in the MODULE ID register is newer. I've not yet looked for docs on a newer CPU with this newer core revision, but that will be my next step.

The USB transceiver is an SMSC USB3316. Unfortunately, again, I do not have docs for this. However, register level docs on the USB3320 series (which seems very closely related) are available from here: http://www.smsc.com/index.php?tid=143&pid=211&cid=&tab=4

Additionally, you'll need a specially hacked USB cable which deals with the fact you're using a USB B connector as a usb host, and also supplies power to downstream USB devices (I doubt the hero can /output/ power on the VBUS line. Even if it can, I've no idea how to switch it to do so) . I happened to have one of these made up form my old Nokia N770 so I just repurposed that. There's information about this sort of thing at the openmoko project: http://wiki.openmoko.org/wiki/Specialized_USB_cables

The attached patch adds the necessary glue to get the EHCI host controller running. I've not bothered to implement any gadget/function coexistence code yet, so you'd need to disable those to try it out.

So: the EHCI host controller starts up happily, and can even see devices being plugged in. The problem is it doesn't seem to be able to communicate with the usb devices. I get lots of -EPROTO (-71) errors (as in the attached connect-error.txt file). I've tried everything I can think of, but am hampered by (a) lacking specific documentation and (b) not knowing how the hero/USB port is wired. It's even possible that the hero is missing some vital piece of hardware to support host mode :(

The USB3316 appears to be able to swap the D+/D- lines about by changing a register setting. I've tried this in case I had them the wrong way round; it changed the errors, but didn't really help. Also, note that the openmoko site talks about missing 15k resistors causing exactly this sort of error. However, the USB3316 has these built in, and they're software controllable.

[Andrew de Quincey]

Ok, I've just discovered that I had the D+/D- lines the wrong way round to my hacky device. Its still not working, but its not working better :)

I'm 99% certain the D+/D- lines are correct now because on connection:

[  682.849304] hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s                          
[  683.003051] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101            
[  683.003509] msm_hsusb msm_hsusb: port 1 reset                                               
[  683.058837] msm_hsusb msm_hsusb: irq status 0004 PCD                                        
[  683.062591] msm_hsusb msm_hsusb: GetStatus port 1 status 88001205 POWER sig=se0 PE CONNECT  
[  683.122497] usb 1-1: new high speed USB device using msm_hsusb and address 2     

This is a (for certain) USB 2.0 (High Speed) hub I'm attaching. With the D+/D- lines the wrong way round, it was reported as a low speed device. According to the USB specs, the (electrical) difference between low and full speed devices is which of the D lines a 15k pulldown resistor is on. Since its now registering as a 12Mb/s device initially, this means I have the lines correct.

The important part is the last line: its going further and detecting it as a high speed device post reset. This means the the low level USB protocol signalling and negotiation is working prefectly fine, so all the necessary clocks, data line setup etc *must* be fine.

However, I'm still getting errors when it tries to actually send USB packets:

[  683.122985] msm_hsusb msm_hsusb: submit_async 1 urb cb67e8a0 ep0out len 64, qtd ffc4b060 [qh 00000000]
[  683.123748] msm_hsusb msm_hsusb: irq status 0002 ERR                                                 
[  683.124023] msm_hsusb msm_hsusb: dev0 ep0in qtd token 80400d40 --> status -32                        
[  683.124420] msm_hsusb msm_hsusb: ehci_urb_done 1 urb cb67e8a0 ep0in status -32 len 0/64              
[  683.124694] msm_hsusb msm_hsusb: irq status 0020 IAA 

I'm feeing more hopeful now that I'm certain the D+/D- lines are working ok. Investigation continues....

[Andrew de Quincey]

Success!! It works; just needed to tell the EHCI controller to use coherently allocated DMA memory. I'll send an updated patch soon. My USB keyboard works out of the box; a USB mouse does... sort of... as well :)

I would have typed this on the phone, but google mail on the phone won't let me NOT include the original mail.

[cellurl]

Does this mean future phones will support usb HOST mode?
-jp

[Andrew de Quincey]

> Does this mean future phones will support usb HOST mode?

If they're using similar hardware, there is no technical reason why
not. The current generation all seem to have the requisite hardware
support.

Its up to the manufacturers whether they include the software support
provided by this patch though, something that has not happened up till
now, except for the Droid (its based on a different architecture than
the HTC android phones).

[Bill Gatliff]

Poke! :)

Did you ever post this patch anywhere? I'm using a USB3320 on an
OMAP3530 platform, and seeing very similar behavior. I'm wondering if
it's the same problem...


Thanks!


b.g.

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

[Andrew de Quincey]

On 13 May 2010 21:13, Bill Gatliff <bgat...@gmail.com> wrote:
> Poke!  :)
>
> Did you ever post this patch anywhere?  I'm using a USB3320 on an
> OMAP3530 platform, and seeing very similar behavior.  I'm wondering if
> it's the same problem...

Hi, sorry, I don't have access to any OMAP hardware so I can't really
develop any code for them; from the MSM7201 work its something you'd
definitely need the hardware for to reboot it when it crashes :)