USB interrupt in pipes: BeagleBoard vs Iyonix

I’ve just been playing with some Bluetooth dongles on RISC OS. Commands are sent out via the control pipe. Each command should result in an event message on the interrupt in endpoint.

I’ve been doing most of the experiments on the Iyonix. However, every time a message comes in on the interrupt endpoint, the DeviceFS call reports that the message is 1 less than the buffer’s size (1024), regardless of the fact that the messages themselves are various lengths, no more than 16 bytes.

I just copied the app over to the BeagleBoard, which reports the correct message lengths in each case.

BB: USBDriver 0.50 (23 Nov 2010), EHCIDriver 0.16 (18 Jul 2010)

Iyonix: USBDriver 0.47 (22 Feb 2006), EHCIDriver 0.14 (15 May 2005), OHCIDriver 0.29 (31 Dec 2005)

Clearly the Iyonix versions are earlier than the BB’s.

What are the latest versions that will run on the Iyonix?

The latest versions (i.e. whatever’s in CVS) should work fine on the Iyonix. But when trying to test them recently I found that I couldn’t get them to softload properly (i.e. USB stopped working and/or the machine had died), so using a ROM softload may be your best bet.

Although I have made changes to the code which pads short packets, I’m fairly certain that the anti-padding code should only enable itself if you explicitly ask for it. See this post for info about my changes. I’m fairly certain there’s also a newsgroup posting or email somewhere from Dan Ellis describing how to workaround the packet padding in older versions of the module, by reading a value from a magic offset from a pointer :(.

Of course it’s also possible that the interrupt transfers are now reporting the correct size due to the massive update I did a while ago to bring the EHCIDriver in line with the (then) latest NetBSD version.

The latest versions (i.e. whatever’s in CVS) should work fine on the Iyonix.

OK, thanks, Jeffrey.

But when trying to test them recently I found that I couldn’t get them to softload properly (i.e. USB stopped working and/or the machine had died)

I’m aware that there is a magic sequence to stopping and starting the modules – someone (possibly John Ballance) told me it several years ago – but I may have difficulty finding it again.

so using a ROM softload may be your best bet.

That would be a challenge. Anyway, I need to establish for certain that the newer modules work in the Iyonix before I try that.

What is the function of the MUSBDriver module? The BeagleBoard has it but the Iyonix doesn’t.

Also, why does the BeagleBoard have a SCSISoftUSB module, but the Iyonix doesn’t – yet a USB stick on the Iyonix comes up as SCSIFS?

The latest versions (i.e. whatever’s in CVS) should work fine on the Iyonix. But when trying to test them recently I found that I couldn’t get them to softload properly (i.e. USB stopped working and/or the machine had died)

I’ve not exhaustively tested all the possibilities yet, but so far I’m finding the same. The question is why that should happen. One possibility is that they aren’t as compatible as we think. Other than that… does it need a time delay between shutting something down and starting up its replacement? Or does shutting something down immediately trigger its reload, so we haven’t really shut it down?

Or what? All plausible ideas will be accepted!

I suspect that the EHCIDriver module, at least, is not Iyonix compatible – in the sense that I’ve just used Zap on the BB to get a copy of the module and copied it across to the Iyonix. Although I can RmKill and RmReinit the EHCIDriver module from ROM, I can’t RmKill it and RmLoad the BB version. I’ve seen an AODT and once an undefined instruction.

A similar thing goes for USBDriver: I can RMKill it and RMReinit it, but I can’t RMKill it and RMLoad the BB’s version. That simply stiffs the Iyonix.

What is the function of the MUSBDriver module? The BeagleBoard has it but the Iyonix doesn’t.

It’s the driver I wrote for the USB controller used by the OTG port. Wiki docs here.

Also, why does the BeagleBoard have a SCSISoftUSB module, but the Iyonix doesn’t – yet a USB stick on the Iyonix comes up as SCSIFS?

At a guess, I’d say that when SCSISoftUSB was first introduced there wasn’t enough space left in the Iyonix ROM image for it (and the other SCSI modules) to squeeze in. So instead of having them in ROM, the Iyonix softloads them during the boot sequence.

One possibility is that they aren’t as compatible as we think.

Running an Iyonix ROM image built from the latest code in CVS works fine (or at least it did a few months ago when I first found that USB softloads didn’t work). But if you use the same source tree to build softloadable versions of the modules then it’s likely that you won’t be able to get them to softload properly. I can’t remember if I thought to try softloading USB modules on the beagleboard (to check if it was a generic softload issue or just something Iyonix specific). But in terms of “does the latest code work at all?”, the answer is yes, it does.

Other than that… does it need a time delay between shutting something down and starting up its replacement? Or does shutting something down immediately trigger its reload, so we haven’t really shut it down?

I tried inserting delays in a few different places inbetween shutting down/restarting the modules and it didn’t seem to help.

I’ve just used Zap on the BB to get a copy of the module and copied it across to the Iyonix

That will always fail, for at least one of the following reasons:

• C modules that get built into ROM images will be staticly linked with the copy of SCL that’s in that particular ROM image. Softloading such a module, even on the machine you ripped it out of, is practically impossible.
• Since the module was getting built into a ROM image, the compiler will have been instructed to not worry about maintaining compatability with CPUs other than the one in use by the target machine. So the module probably contains one or more ARMv6+ instructions
• A while ago, when I updated EHCIDriver to the latest BSD sources, I had to make some backwards-incompatible changes to the interfaces that the USB drivers use to communicate with each other. Although if it was this that was preventing the module from working then you should get a nice friendly error message instead of a horrible crash.

Some notes:

I made V0.49 to run on the Iyonix. But two persons noted trouble. It may be that the sequence of killing the USB modules is important.

My FTDI driver works fine with V0.49 on BB xM and Iyonix but not V0.50. It seems that v0.50 contains one changed line influencing the padding (my FTDI in the moment relies on padding, which is not very clever, I have to correct but the BB xM Ethernetport was more important).

It seems that my corrections to docmentation and one bug in enumration are still not implemented in V0.50. I shall try to update the source accordingly again as the branches have been merged a while ago.