USB stack on Raspberry Pi

How is the work going on this. Can anyone help? Will ROOL be at the SouthWest show on 25th February? Will the ROOL pen drives be on sale there? Will there be a RPI on show there? Are these all rhetorical questions?

The RISC OS port to RPi is entirely in Adrian Lees’ hands – we’re hoping he can get ROOL a copy so that we can help out but this hasn’t happened thus far. As such, nobody can help with this at the moment.

ROOL are deciding about the South West show – it’s always hard because it’s such a long way and so knocks a lot out of our weekend (and the Friday). Having said that, we’ve not been for a few years so maybe we’re overdue for a visit.

If we go, we’d expect to be selling the USB sticks. We also hope that we’ll have sample RPi hardware that we could show. There are a few other things we could possibly bring along to demo. All in all, the case for us going to the SW Show looks quite strong… :)

Adrian hasn’t been able to spend as much time on this as he’d hoped, so we were wondering if anyone else would be interested in working on the RPi USB driver? It would be particularly helpful if there was anyone with experience of the RISC OS/NetBSD USB stack, as that’s the main area where many of us lack experience.

A rundown of the story so far…

The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).

There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA (Adrian has full access, I have access to a few marketing details but not much more). However, there’s a Linux driver written by Synopsys (dwc_usb). The best place to find this driver is the RPi Linux source tree:
https://github.com/raspberrypi/linux

Specifically
https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host

directories dwc_common_port and dwc_otg.

The Synopsys code is actually under a fairly permissive licence – it’s not GPL, it’s similar to BSD (’don’t sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code to RISC OS.

The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).

I’ve put a local copy of the code (which is not tracking github so will become out of date) here for you to browse:
http://www.cl.cam.ac.uk/~atm26/ephemeral/rpi/
That has doxygen-generated documentation for dwc_otg and dwc_common_port . In particular I recommend reading the first page of the dwc_common_port doxygen.

Therefore a RISC OS port should probably only need provision of relevant changes to dwc_common_port. The main things I can see are:

1. Provision of necessary headers to get it to compile
2. Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes – see my post on multithreading )
3. Interfacing between RISC OS/NetBSD USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.

1 is possible using some external headers that are designed for porting Linux USB (device) drivers to FreeBSD – see linux-kmod-compat website and 20080408 source tarball
I had a brief try building some of the Synopsys code with these headers (on Linux, using GCC, but without Linux system headers) and a good chunk compiles out of the box. However, given the clean-ness of the Synopsys interface it may be simpler just to rewrite it to directly talk to RISC OS, as I think the Linux bits of the headers are only required for the dwc_common_port library.

dwc_common_port includes a variety of crypto functions which I think aren’t used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn’t going to be for plain wired USB. So I think these can be ignored.

So… anyone interested in having a go? We can probably arrange hardware for you if necessary.

However, given the clean-ness of the Synopsys interface it may be simpler just to rewrite it to directly talk to RISC OS, as I think the Linux bits of the headers are only required for the dwc_common_port library.

I think removing/rewriting the Linux bits would be the best option. There’s no point having an extra API translation layer getting in the way.

So… anyone interested in having a go? We can probably arrange hardware for you if necessary.

Well I’m probably the one with the most experience with the USB stack. Not entirely sure if I want to volunteer for this though; it’s not a particularly easy codebase to work with!

ROOL are deciding about the South West show – it’s always hard because it’s such a long way and so knocks a lot out of our weekend (and the Friday). Having said that, we’ve not been for a few years so maybe we’re overdue for a visit.

All in all, the case for us going to the SW Show looks quite strong… :)

Shall you be there on Saturday 25th February?

ROOL are deciding about the South West show – it’s always hard because it’s such a long way

… and it’s even further to come down from Edinburgh, which I shall be doing :)

Edinburgh

Wow! Do you fancy flyposting some trains/stations/motorway services/airports on your way down?

Well I’m probably the one with the most experience with the USB stack. Not entirely sure if I want to volunteer for this though; it’s not a particularly easy codebase to work with!

I would dearly love to be able to make a contribution to the USB stack. However, the reality is that I have never been able to make sense of the existing, working, RISC OS code base. Nor have I ever been able to take over any existing code of any project.

Coding standards are, I feel, woefully lacking in many OSS projects. Good coding standards, adequately enforced, could be a significant contributor to ease of maintenance.

Just wanted to say Yes, ROOL will be at the SW Show. Time for an update of the News page, which still has them on christmas break!

Dave: Both Linux and NetBSD have extensive, extreme, and strict standards for any code that is to be considered merged. You should have no problem with their sources, and I assume CTL/Pace/whoever did not ruin this when they imported the NetBSD code.

NetSurf too has a strict standard for any newly written code, which includes much of the recent additions such as the CSS and HTML parsers. In fact, most large OSS projects I’m aware of do, beyond media-based ones, which are always horrible.

Wow! Do you fancy flyposting some trains/stations/motorway services/airports on your way down?

Not sure what this is about, but shall be setting off down the motorway before anything could reach me by post anyway.

Not to be taken seriously… anyway I was referring to flyposting.

Not to be taken seriously…

Trevor, a combination of your obvious earnest desire to promote RISC OS far and wide and the impossibility of rendering sarcasm in text (without faux-html!) led a few people astray it seems! I have to confess I thought you were serious for a while! ;)

Double-bluff? :-p

Back on topic, I’ll donate something to Update and debug USB stack tonight.

Done the same too. A fair stash of gold there now, how much longer before someone gets tempted.

£784 is not exactly a large amount!

It’s around 1.5 weeks at £15/hour.

It’s an awful lot more than nothing, which is what many RISC OS programmers effectively work for. Definitely enough to inform the tax man about!

It looks like only the developers will have their hands on a Raspberry Pi at the moment so hopefully the USB stack will be sorted out by the time all the compliance testing is done. The delay for compliance testing may therefore be quite good news for the rest of us who just want to run RISC OS on the Pi.

It’s probably already known that the Synopsys drivers burn CPU time. If there are improvements, are they likely to require extensive reworking for RISC OS?

It’s probably already known that the Synopsys drivers burn CPU time. If there are improvements, are they likely to require extensive reworking for RISC OS?

We have ideas about that – it may not be too much of a problem. Fingers crossed.

Yup, you may have noticed that I posted in the Linux kernel mailing list thread linked to by those postings. Arguably RISC OS is in a better position than Linux due to its low level nature… we’ll see what happens.

Nice one – I did consider checking the mailing list but got distracted. I might’ve guessed you guys would be on the ball!

Hoping this is an appropriate thread on which to report it…

USBInfo on the Raspberry Pi seems to get stuck pretty much every time a USB device is removed, and sometimes when one gets added, too. Alt-Break allows it to be stopped. No other damage appears to be done, and USBInfo will run again successfully.