When should we have a new BeagleBoard ROM image?

The updated EHCI driver is now in CVS. Here’s an OMAP3 ROM with the new driver, if people who were having trouble with hubs want to confirm that it works (it certainly seems to work for me).

I don’t expect to have enough free time any time soon to try and bring the rest of the USB stack up to date, so if anyone else feels like giving it a go they’re welcome to try. But do make it easy on yourself and use a visual diff/merge tool, otherwise you’ll just make too many mistakes when trying to apply patches and resolve differences. Meld looks to be OK for this kind of work, although it was a tad slow on the larger files.

Jeffrey, I can confirm that after a soft reboot (using ctrl-shift-f12 and clicking reboot) the hub gets properly reset and I don’t need to unplug my USB network anymore. Well done! Thanks!

I can also confirm that the delay on plugging anything into the hub is now much shorter than before. Thank you, Jeffrey!

It’s still only a small sample, but my BeagleBoard hasn’t frozen waiting for HardDisc0 since using the new driver, so I think you may well have solved another problem.

At one point I was seeing a hang on boot if I had a hub + keyboard connected to the OTG port. This confused me a bit, since I’m sure I must have tested that config when I first got host mode working. But with the new version of the driver everything seems to be OK, and I’ve been able to boot with 8 or so devices connected at once without problems. So either the changes have fixed it, or it’s something else (enabling debugging, perhaps – stranger things have happened)

I managed to reproduce this bug over the weekend! It looks like it’s a very timing-specific issue, or there’s an uninitialised variable somewhere, or both. After reproducing it I tried enabling debugging, and the problem went away. So then I tried disabling debugging, and the problem still didn’t occur. So then I removed the DADebug module (which I’d added to collect the debug output) and the problem re-appeared. So then I had a few fun hours of adding minimal bits of debug output to the code to try and track down where the hang was occuring – too much debug output, or debug output in the wrong place, and the hang would vanish. Too little output and I wouldn’t know where to look next. Eventually I tracked it down to a control transfer that was failing to complete. Even though the transfer had a timeout specified, the function that was doing the waiting wasn’t honouring the timeout and was just blocking indefinitely – so I’ll have to check if it’s a bug in my code (I’m not sure whether handling timeouts is my responsibility) or whether it’s a bug in the core USBDriver code (for not honouring the timeout when it should have done).

Hopefully once this bug is fixed it will also solve the problems other people have had with the machine hanging when plugging something into the OTG port.

Finding the cause of this hang is the kind of situation where JTAG would have been a life saver. If all goes to plan I should be ordering the Blackhawk adapter this week, once I’ve heard back from Direct Insight as to whether it’s the USB100v2 or USB100v2D that they’ve got in stock. This is an important distinction, because the beagleboard is too cramped to plug an adapter straight onto the board. The v2D comes with a ribbon cable but the v2 does not, so I may need to buy my own cable.

Hopefully once this bug is fixed it will also solve the problems other people have had with the machine hanging when plugging something into the OTG port.

That sounds very interesting :-) – Is there something to test or am I too early in asking ?

Is there something to test or am I too early in asking ?

Too early. I’ve got some code to handle the timeouts, but it doesn’t seem to work yet, and debugging it is a bit tricky due the timing-specific nature of the issue. I suspect MUSBDriver’s naive handling of transfers is partly to blame for the problems I’m having. But if I rewrite the code too much I may end up being incapable of recreating the timeout issue that I’m trying to fix! :P

On the subject of the OTG port, if I wanted to use it for eg. a simple keyboard/mouse, would a cable like this be what I’m needing?

If I had an external HDD, which was separately powered, would I be able to plug that in to the OTG port using a suitable cable?

(All assuming the hanging bug is squashed)

On the subject of the OTG port, if I wanted to use it for eg. a simple keyboard/mouse, would a cable like this be what I’m needing?

Looks like the right cable to me.

If I had an external HDD, which was separately powered, would I be able to plug that in to the OTG port using a suitable cable?

Yes.

Just be aware that the OTG port can only supply somewhere around 100-150mA of power, so unless you’re connecting something simple like a keyboard or mouse you’ll need a powered hub.

Looks like the right cable to me.

Great, will get one ordered so it has time to come round the globe!

Just be aware that the OTG port can only supply somewhere around 100-150mA of power, so unless you’re connecting something simple like a keyboard or mouse you’ll need a powered hub.

It’s got a separate PSU, so shouldn’t need to draw much current from the USB port (he says, hopefully!)

The latest batch of MUSBDriver fixes are in CVS, and there’s a new ROM image here

This new version will handle transfer timeouts, so the machine shouldn’t hang when plugging in troublesome devices. But it doesn’t seem to be a complete solution to the problem I have with having a hub + keyboard connected on boot – the machine will boot, but often the keyboard will have failed to initialise and will need to be *USBReset or manually re-plugged to start working. Since this is a very timing-specific issue I thought it would be better to make a release now rather than spend another week or two trying to determine what causes the keyboard to timeout and why the stack isn’t able to fix it itself.

I’ll be doing some more stress testing of the driver of the next few days, mainly to look into a problem Uwe mentioned in an email to do with zip file extraction, but apart from that I’m hoping I’ll finally find the time to try porting the Linux DSS driver to RISC OS so we can see if it fixes the IGEP video problems.

I had some minutes time yesterday, so to get a first impression I checked some usb memory sticks that used not to work and found no change. The keyboard did initialise without problems, but got blocked by one of the sticks. Unplugging the stick did not help – but I forgot to unplug the keyboard for double checking (its a wireless one and the dongle is inside the case…) I will give it another try this evening including stress test (unpacking archives) and check if communication with my davicom ethernet adapter now works (I currently do not have the reportedly working on revC Logilink Adapter).

Update (1): I started unpacking the riscos-omap download I fetched a while ago to try and compile it. While doing so, to add system stress, I checked on my davicom-etherusb project, changed this and that and recompiled it on the BeagleBoard and there are still problems issuing commands. While I write this, Copying of the archive is still running….

Update (2): Bad news, It got stuck. I have a broken directory error for file no. 10004 while merging the castle tree into the RISCOS directory. (though the zip archive I unpacked from is correct there, unzip generated a broken directory while unpacking.)

Why has the BeagleROM moved from its “traditional” place in the “ROM releases” page? Is the “Rom Omap 5” the new name for it? Do we expect that the ROOL site will no longer be the host site for the most up to date BeagleROM?

Why has the BeagleROM moved from its “traditional” place in the “ROM releases” page?

Because I accidentally named the zip archive incorrectly (put a dash instead of a dot in one location). The default behaviour of our ROM releases page is to list any files that have been uploaded which are not “known about” at the bottom of the page.

Is the “Rom Omap 5” the new name for it?

That’s just a side-effect of the file having the wrong name.

Do we expect that the ROOL site will no longer be the host site for the most up to date BeagleROM?

The Beagle ROM is a work in progress. We try to track developments and do builds then upload the results periodically, but as we’re not the ones doing the development, Jeffrey can usually upload a ROM image himself in a more timely manner. I expect this will continue as-is for the time being. Once we’ve improved our autobuild system, we may be able to host a weekly or nightly ROM image.

Of course, once we move from the beta stage for all this – and on to ‘official’ ROM releases – then the ROOL site will certainly be the primary hosting location for the images.

Update (2): Bad news, It got stuck. I have a broken directory error for file no. 10004 while merging the castle tree into the RISCOS directory. (though the zip archive I unpacked from is correct there, unzip generated a broken directory while unpacking.)

Looks like I need to do some more testing of MUSBDriver, then.

Can you try unpacking the archive again, but this time without trying your ethernet adaptor at the same time? I just want to rule out the possibility that the broken directory was caused by a bug in your driver (we all know how bad RISC OS’s memory protection is!)

Why has the BeagleROM moved from its “traditional” place in the “ROM releases” page? Is the “Rom Omap 5” the new name for it?

Looks like a clerical error. The zip filename is rom-omap-5.17.zip, while the others are named rom-foo.5.17.zip – note the dot being swapped for a dash. So whatever script generates that web page got confused and didn’t know what category to put the file in.

Do we expect that the ROOL site will no longer be the host site for the most up to date BeagleROM?

I don’t. I sent them my RPCEmu autobuilder stuff a couple of weeks ago, so once they’ve had a chance to set it up on the server we can expect the ROM images + disc image to be updated on a daily/hourly basis. Hopefully it won’t be long until the other downloads (module softloads, apps, etc.) are updated in a similar manner.

I sent them my RPCEmu autobuilder stuff a couple of weeks ago, so once they’ve had a chance to set it up on the server we can expect the ROM images + disc image to be updated on a daily/hourly basis. Hopefully it won’t be long until the other downloads (module softloads, apps, etc.) are updated in a similar manner.

Exactly. Pretty much everything could be rebuilt daily (hourly would be pushing it, given the builds would probably take more than an hour to complete and we’d thrash our host’s CPU when running the autobuilder process – RPCemu isn’t very friendly with CPU loading right now).

One problem we’re up against is that the server hosting our website isn’t suitable for running the autobuilder process on. We do have access to other servers so what we might do is run the autobuilder in one location and then upload any results (if the build was successful) to the ROOL webserver at the end of the process.

It’s a sufficiently useful step that I will certainly be spending some time getting this working. The only issue is that I have the small matter of taking some holiday coming up! :) So I expect I’ll look into this in September.

Can you try unpacking the archive again, but this time without trying your ethernet adaptor at the same time?

Sure, though this will take some time :-) – I’ll report as soon as possible.

I got bad news concerning the logilink adapter that works with revC – still not working and no change in functionality – it seems it was something not influenced by your changes that is not working – Does it make sense to connect the serial cable for collecting debug output? I did not try because I have to rearrange my setup for that.

On the other hand, I am not sure if it makes sense to continue debugging of the musb driver, as there are not so many early adopters like me with a revB board – just a thought.

Update: Bad news again, I left the system on its own, working through the build process after unpacking the tar/gz2 archive of the omap tree. It got stuck finding garbage in some source files and produced even more garbage in the build log file. – I’ll check with a different usb stick next… :-(

Does it make sense to connect the serial cable for collecting debug output?

You could try, although you’d have to recompile the ROM image to enable USB debugging (or I guess a softload would work… but either way you’ll have to recompile some code :)) The MUSBDriver wiki page has a rough guide to follow for building a debug version and getting the debug output.

One thing that could be stopping the logilink adaptor from working is if it needs endpoints with a max packet size of over 512. Do you know if this is the case? At the moment all the FIFOs are fixed at 512 bytes, but I can easily change the code to leave a couple of 1K FIFOs available for anything that needs it.

On the other hand, I am not sure if it makes sense to continue debugging of the musb driver, as there are not so many early adopters like me with a revB board – just a thought.

I do want to get all the bugs ironed out, and to implement all the missing features (e.g. proper FIFO allocation). But my ideal development strategy for the OMAP port would be to do a first pass of all the big features and then come back later to fix all the bugs. Part of this is to keep things interesting to me, part of it is to try and make sure the system is in a usable state for software developers (e.g. first-pass APIs for VFP context switching, APIs for access to the hardware overlays, APIs for DSP access), and part of it is in the hope that something will happen that will save me from having to fix all the bugs myself ;)

So if you’re able to work with MUSBDriver as it is now then I’ve got no problem with running off and working on something else. Like that bastard bug that’s causing the video signal to fail on IGEP boards! :(

Update: Bad news again, I left the system on its own, working through the build process after unpacking the tar/gz2 archive of the omap tree. It got stuck finding garbage in some source files and produced even more garbage in the build log file. – I’ll check with a different usb stick next… :-(

Yes, trying a different stick would be a good idea. Recently Dave Higton had me pulling my hair out over his reports of his beagleboard randomly hanging, and it turned out it was a bad USB stick :)

Yes, trying a different stick would be a good idea. Recently Dave Higton had me pulling my hair out over his reports of his beagleboard randomly hanging, and it turned out it was a bad USB stick :)

I think I ought to add some more information at this point… :-)

When I swapped sticks, it didn’t hang for several days. That’s when I posted that the stick solved the problem. Alas, the hangs did come back later. That’s an inherent danger in drawing conclusions for any random process – the sample size must be adequate (and even then the certainty won’t be 100%). “Random doesn’t mean even” is a short phrase (learned from the csa newsgroups) that’s worth remembering, i.e. randomly spaced events are certainly not evenly spaced.

And if anyone has suggestions for a USB stick that has had lots of use on a BeagleBoard and has never hung, I’d be happy to buy one. In the hope that I’ll get one that behaves identically, of course. The manufacturers keep changing the internal designs. Or should that be infernal…

Last bit of info: the ROM image from a few weeks back seems to have produced the biggest reduction in the number of hangs. I’ve had one, or maybe two (I can’t remember), but that’s all, and it’s much reduced. I haven’t tried the ROM from a few days ago.

Well, the point is that my system never hangs with the usb sticks I use, only when trying new/different hardware. So I would not expect too much from the double check. I want to double check too with my SD card reader when my kids find it again.

At the moment I can build / compile with rpcemu though my PC is a little aged, but still somewhat faster than the RiscPC and I have to use FAT32 in between.

Smaller projects, I can compile on the BeagleBoard which works very swift when using RAMDisc. But for the kernel the 128MB of the revB board is too small to use RAMdisc – and seemlingly I cannot even transfer the sources to the board.

So if you’re able to work with MUSBDriver as it is now then I’ve got no problem with running off and working on something else. Like that bastard bug that’s causing the video signal to fail on IGEP boards! :(

To sum it up, I can develop nothing that is ‘big’ or concerning USB on or for the beagleboard so I might as well give the internal SD a second try…

So I’d say ‘go for it!’ I think I can wait for the second round – or buy a XM Board when they are avaliable.

Alas, the hangs did come back later.

You know just what to say to make me happy ;-)

And if anyone has suggestions for a USB stick that has had lots of use on a BeagleBoard and has never hung, I’d be happy to buy one. In the hope that I’ll get one that behaves identically, of course. The manufacturers keep changing the internal designs. Or should that be infernal…

Since I only have the one USB stick, which I’m keeping FAT formatted for file transfer with other machines, I’ve mainly been using a 2GB Transcend SD card in a Transcend-branded SDHC card reader. The only fault is that I’ve managed to break the outer casing by gripping it too tightly (or perhaps it was already broken – there are fragile plastic clips holding it together)

One of the USB fixes that I merged in from the NetBSD sources was a fix for VIA’s dodgy EHCI implementations that sometimes fail to write back the transfer status before firing off an interrupt. If the CPU was fast enough it could end up thinking that the transfer was still in progress when actually it had actually completed. Apparently this bug was most evident as a stall in the mass storage drivers, so it could be the same problem you’re seeing. When I get a chance I’ll try enabling the fix for the OMAP build and upload a ROM for you to test with.

To sum it up, I can develop nothing that is ‘big’ or concerning USB on or for the beagleboard so I might as well give the internal SD a second try…

Dave has just started to look at writing the SD/MMC driver himself, so perhaps you two can join forces.

https://www.riscosopen.org/forum/forums/3/topics/445

I’ve mainly been using a 2GB Transcend SD card in a Transcend-branded SDHC card reader

For info, I’ve never had any hangs with the Integral reader listed here either.

Dave has just started to look at writing the SD/MMC driver himself, so perhaps you two can join forces.

I’ve not got very far; I’ve issued CMD0 and CDM5 OK, but I see a command timeout after CMD8. All co-operation welcome!

@Dave & Jeffrey: Thanks, I have send a request on the other thread .

@Trevor: have you checked for correctness? I also had no hangs, but there were errors in the data when unpacking big archives.

So card readers seem to be the right choice currently?

Is there anyone else who tried, say, to unpack riscos on either medium who can share information on that?