BeagleBoard USB speed

I was looking again last night at a couple of aspects of the BeagleBoard port’s USB speed.

The good news: my !PTP application transfers from the camera much faster than the Iyonix does. The BB has a USB stick as HardDisc0 whereas the Iyonix has a rotating drive, so I wasn’t quite comparing like with like, but it looks good.

The bad news: the BB seems to take an age to discover USB devices. Explanations and solutions welcome!

Which port are you using? The USB host port or the OTG port? I’ve got one hub that works fine with the OTG port but, for unknown reasons, fails to report any port status change events when used with the host port. Which means device insertion/removal only gets detected once every 20 seconds or so when the USB stack manually queries each hub. I’m not quite sure, but I think the hub behaved in the same manner when I tried it with my Iyonix (using one of the EHCI ports – AKA USB 2 - AKA the same as the BB’s USB host. I haven’t tried it with the OHCI (USB 1) ports yet).

I did take a quick look at this a couple of weeks ago, but after seeing the reams of debug text that are produced by the debug USB libraries I quickly decided I’d rather do something else :(

I’m using the host port and a 7 port USB hub. It’s interesting that you suggest that the hub may influence the detection delay; I have another 7 port hub that I can try instead – it’s the one I use all the time on the Iyonix and so I know it doesn’t suffer from the delay there. More news tonight.

I have looked at the Iyonix USB code several times, but each time I’m defeated by how badly it’s written, and by not having any idea of the structure of all the (many) pieces. I also know of another person who is interested in working to update the stack. Can you suggest anywhere we can refer to in order to understand the structure?

Can you suggest anywhere we can refer to in order to understand the structure?

Not really. If you’re lucky you might be able to find some documentation in one of the BSD distributions. Otherwise you’re just going to have to work it out by reading the source code (especially since it’s been pulled apart and messed around with to integrate it with RISC OS), and by reading the USB 2 spec – which I’d say is of critical importance if you’re going to do any big updates to the driver. Without understanding how USB is meant to work you’ll be clueless when you encounter your first protocol-related bug. It may also give you some clues as to why the stack is structured how it is.

When I get a chance I’ll try writing a wiki page about how the stack is structured. I suspect I know more about the stack than anyone else at the moment, since I’ve worked with both the higher & lower levels a fair bit recently.

Also, if anyone is tempted to try updating the stack to the latest version, I’d actually suggest trying to compile it using GCC instead of Norcroft. Norcroft’s handling of packed structs is too buggy to be trusted, and packed structs are vital for the USB driver. Plus you won’t have to fix any GCC-isms that Norcroft may complain about. AFAIK the only downside to using GCC is that it won’t be possible to staticly link against the SCL when creating ROM modules. (Although, thinking about it further, you’re also likely to run into problems linking with any other libraries that are used – e.g. DebugLib – since they’d have to be made available in GCC format too)

My apologies for my delay in replying. I swapped hubs with the Iyonix. The one I moved from the Iyonix to the BB is a D-Link DUB-H7 and has always allowed the Iyonix to report new devices immediately, but not on the BB: something approaching 20 seconds delay. The no-name hub that I moved from BB to Iyonix was giving up to 20 seconds delay on the BB, but allows the Iyonix to report new devices almost immediately.

The long delay remains with the BB, I’m sorry to say.

OK, I’ll take a deeper look into the issue at some point.