USB woes on the RevB boards

Hi folks,

I've got a little issue with the kernel dropping my USB ethernet
adapter when I'm pulling some traffic on a usb memory device connected
to the same hub.

As this is a revB6 board, it seems like I'm running into
http://code.google.com/p/beagleboard/issues/detail?id=31 where the
connected high speed usb device starves off the full speed ethernet
controller.
The suggested workaround is a bit suboptimal, as it forces the usb 2.0
pen drive to 1.1 speeds.

Is there any other way to work around this on a RevB board? Would
getting a RevC board and using the USB host port provided there fix my
issue?

Cheers,
Kai

I’ve struggled with an identical problem for a long long time. The network connection dropped often and sometimes, the keyboard and mouse ceased to work.

In my case, I had narrowed the problem to a ‘wrong’ USB 2.0 miniA cable that connected the beagle to the hub.

Apparently, miniA cables are rather rare in this world - I still can’t find one here, in India. I got a cheap mini-B cable from a shop that sold mobile accessories and modded it up (shorted the GND and ID pin at the miniA end) and was using this. With this cable, I was facing a lot of the problems I mentioned above.

After some more investigation, I figured that the so called mini USB 2.0 cable is not exactly a high speed cable. From what I learnt, a USB 2.0 cable always has standard color coded cables - Red, White, Green and Black - and has a aluminium shielding. Turned out that cables of this type are tough to find - especially when the shopkeepers don’t have a clue about what the color codes or the shielding mean. The cable I was facing problems with met none of these - neither the color codes nor was there an aluminium shield.

What worked for me was this - I had inquired for and purchased a spare cable for my Transcend USB external hard disk, and then modded it to connect ID and GND. This cable works for me very well now. I’ve even got a stable network connection continously for two days and all my other peripherals work too.

Hope this is the problem you are facing too, and if it is, you now know what to do. :slight_smile:

I've struggled with an identical problem for a long long time. The network
connection dropped often and sometimes, the keyboard and mouse ceased to
work.

In my case, I had narrowed the problem to a 'wrong' USB 2.0 miniA cable that
connected the beagle to the hub.

How did you do the narrowing down?

Apparently, miniA cables are rather rare in this world - I still can't find
one here, in India. I got a cheap mini-B cable from a shop that sold mobile
accessories and modded it up (shorted the GND and ID pin at the miniA end)
and was using this. With this cable, I was facing a lot of the problems I
mentioned above.

I ordered one from the US along with some other parts I got. I'm
pretty sure it's a 'real' miniA cable.

After some more investigation, I figured that the so called mini USB 2.0
cable is not exactly a high speed cable. From what I learnt, a USB 2.0 cable
always has standard color coded cables - Red, White, Green and Black - and
has a aluminium shielding. Turned out that cables of this type are tough to
find - especially when the shopkeepers don't have a clue about what the
color codes or the shielding mean. The cable I was facing problems with met
none of these - neither the color codes nor was there an aluminium shield.

I've not cut my cable open yet, but I figure if it's shielded, it'll
say so. I don't think the color of the cable makes a difference.

Hope this is the problem you are facing too, and if it is, you now know what
to do. :slight_smile:

I'll check this when I get home. If this really is the issue, that
should indeed be fixable.

Cheers,
Kai

I ordered one from the US along with some other parts I got. I'm
pretty sure it's a 'real' miniA cable.

I just checked, and it claims to be a shielded high-speed cable. So I
kind of doubt that's the issue. :frowning:

Cheers,
Kai

General comments:

I've never looked at the USB driver code, but it sounds like it could
be a software problem. Implementing the software side of a USB host
controller is quite complex, particularly when mixing high-speed and
full/low-speed devices. The host controller needs to get correct
information from the specific device or its specific driver to figure
out how much bandwidth to allocate for isochronous and interrupt
transfers, and give those transfers priority over bulk transfers.
Calculating the proper timeouts can also be nasty. Split
transactions, where a high-speed transfer is squeezed in during a full/
low-speed transfer makes things even more complicated.

In other words, there's a lot that can go wrong so it's not surprising
if some untested combinations fail.

John

That would depend on what parts? It sounds like the kernel should have
a generic implementation of this, so I should be able to reproduce
this on a different system using the same ethernet controller and usb
storage, right? Or would that be specific to the beagle?

Cheers,
Kai

Kai,

Again, I've never looked at Linux's USB driver code. In my many years
in the embedded world I have had the luxury of almost always being
able to control hardware directly without having an operating system
getting in my way.

Here is what I hope is interesting information, though probably not
helpful.

My understanding is that Linux on the BeagleBoard uses libusb, which
is a user-mode library for requesting transfers (see
http://en.wikipedia.org/wiki/Libusb). libusb must in turn use Kernel
level device drivers for the actual High-Speed USB OTG and High-Speed
USB Host controllers. At the OMAP 35xx chip level these are
completely separate modules, one from Mentor Graphics and one from
Synopsys (see OMAP 35XX Technical Reference Manual, chapter 23).
Since they are different modules with different software interfaces,
it's not suprising that they (mis)behave differently.

Other computers have other USB controllers. There are several
standard controllers (OHCI, UHCI, EHCI = Open/Universal/Enhanced Host
Controller Interface) which present a standard set of registers to
software. USB controller designers can use one or more of the
standards, write their own from scratch, or add proprietary features
to one or more of the standards. For example, the OMAP 35XX HS Host
port has both EHCI and OHCI. The OMAP 35XX HS OTG port uses Mentor
Graphics' controller and skimming the feature list did not tell me
which standard (if any) it uses.

I think this gives an idea of what software designers are up against
when dealing with USB. And you thought RS-232 was complicated.

John