USB CD Support

I have tried searching the forums, but found very little..

Is there any support for USB CD/DVD drives in RISC OS? I’ve just bought a USB DVD drive for my netbook, and wondered if it would work with the BeagleBoard.

If there is no support at the moment, does anyone have any pointers where I could start to get USB CD/DVD drives working.

Cheers.

I think Steffen Huber might already be attempting to add USB CD/DVD drive support to RISC OS - take a look at his posts in this TIB thread. So if you’re interested in this it’s probably worth getting in contact with him. I know practically nothing about what needs to be done, so there’s probably little point asking me any questions :)

Ah! Thanks Jeffrey, I’ll send Steffen an Email. Does anyone know if the USB CD drive for the A9home came with it’s own CDFS? Or was it built into the RISC OS ROM?

Unfortunately, I didn’t have enough time to get to the bottom of the problem. Fact is that SCSISoftUSB usually just hangs the machine whenever a SCSI_Op is done to access a USB CD/DVD drive. And to be honest even after staring at the various USB parts for several hours I have no idea where the problem really lies.

I have very little time at the moment to try again, but I am prepared to explain CD/DVD stuff (e.g. provide example code to access SCSI CD drives) to everyone who wants to have a go.

Steffen, I have tried to Email you, though my Email has been playing up over the last week. Any light you can shed on USB CD support would be much appreciated.

Rob, USB CD-ROM on the A9home comes with it’s own CDFS. This is sofloaded and not in the current 4.42 ROM build.

Sorry, missed the “A9” part of your question, Rob – and thanks Paul for triggering it again.

The A9 has a specific CDFSSoft* driver for CD support because the Simtec USB stack has no generic low level mass storage driver available – with MassFS, the low-level stuff is encapsulated into the filecore client itself.

Basically, the Simtec USB philosophy was always to integrate the low level stuff into the higher level drivers. This is a good idea to avoid problems with non-specific bug reports. But it is a bad idea wrt universal usage.

With the Castle USB stack, we have a generic mass storage driver working with the SCSI Switcher (SCSISoftUSB), which provides the usual SCSI_Op support. On top of that, a bog-standard SCSIFS client is used as the filecore client. And theoretically, if SCSISoftUSB would work correctly, every other SCSI-aware application or module would also work: CDBurn, CDVDBurn, MOFS, CDFSSoftSCSI2…

When trying to get CD stuff working, I started with low-level SCSI_Op calls against SCSISoftUSB, because those are the basis for all SCSI-aware applications, and I know a lot about them because of C(DV)DBurn of course. And it just does not work. It does not even properly do a Mode Sense, a Request Sense or a Read command when faced with a CD/DVD drive.

When trying to get CD stuff working, I started with low-level SCSI_Op calls against SCSISoftUSB, because those are the basis for all SCSI-aware applications, and I know a lot about them because of C(DV)DBurn of course. And it just does not work. It does not even properly do a Mode Sense, a Request Sense or a Read command when faced with a CD/DVD drive.

What are the failure symptoms? Is anything returned over the USB?

I have a USB CD drive, and I have a USB analyser. You may wish to e-mail me some code. Sadly the USB analyser is full speed only, but I do have a USB1.1 hub to slow things down for the analyser.

Hi Dave, the symptoms are a complete lockup of the system until the drive is removed. I didn’t manage to nicely package up some test code for you, this will unfortunately have to wait until I return from my two week holiday.

As a proof-of-concept, to check whether the USB stack is generally compatible with USB CD drives, I knocked up a quick BASIC test program to execute various commands (e.g. read data) on my Samsung USB CD/DVD drive (this is an 8-2-80 device, Bulk-only, MMC2). Worked fine. Will try more devices tomorrow. So the good news is that I will be able to (easily?) add USB support to CDVDBurn. And it will be reasonably easy to knock up a CDFSSoftUSB driver. The bad news is that I have still no idea why SCSISoftUSB does not work out of the box. I will have to dig deeper.

...USB stack is generally compatible… (this is an 8-2-80 device…)

Good news – better than my efforts connecting a RiscPC HDD via an IDE-USB adapter !

I appreciate that you’re working on this, Steffen (and I’m sure, many others).

A while ago, I bought an external USB DVD writer mostly in the hope that someday, I might be able to use it for the BeagleBoard.

Part of that includes learning about the CD-ROM interface, and the result of your experiments shows that RISC OS, today, does have the ability to communicate with USB CD-ROM drives.

I’ve also got a laptop I could use it for. :)

My “test more devices” idea was a flop. My old Iomega ZipCD does not work anymore (which is a shame, because it is (or better was!) a 8-6-80 device), and my IDE-USB adapter connected to various DVD writers somehow stalls the USB system. Must try it on my PC if it is even supposed to work.

Concerning CD/DVD support for the BeagleBoard: is CDFS missing in the BeagleBoard ROM image? Trevor sent me a rommodules dump after reporting an “SWI unknown” from the CDFSSoftFaker module, and I haven’t seen it. Any specific reasons for leaving it out?

is CDFS missing in the BeagleBoard ROM image?

It’s currently missing in my system but is available under module zipfiles . I’ve had no reason to add it so far, that’s all.

Concerning CD/DVD support for the BeagleBoard: is CDFS missing in the BeagleBoard ROM image? Trevor sent me a rommodules dump after reporting an “SWI unknown” from the CDFSSoftFaker module, and I haven’t seen it. Any specific reasons for leaving it out?

Yes, the various CDFS modules are missing from the ROM image. There’s no point in including them if there’s no hardware for them to talk to! AFAIK you should just be able to softload the required modules from the modules download page. Once your USB CD/DVD driver is working we should be able to add the modules to the ROM image.

Hi Jeffrey, CDFS can also be used (via the CDFSSoftFaker module) to mount ISO images, which might be a handy functionality for BeagleBoard owners, because it would allow “indirect” CD/DVD access by extracting the image on another machine and mounting it on the BeagleBoard. A small utility to extract an image from a USB CD/DVD drive is also much easier to do than a full-blown CDFSSoftUSB driver.

But you are of course correct to suggest softloading as an easy solution – I was not aware of this download option and feared that they were not yet ARMv7 ready,

OK, I’ll add the required modules to the ROM image sometime in the next day or two.

I finally got round to dragging my USB CD-ROM drive out of the drawer and connected it up to my Iyonix. Unlike Steffen’s, mine is 8-6-80; the device is seen as a USB 2.0 IDE Adapter by Genesys Logic Inc. with VID:PID 05E3:0701. However, even when a CD-ROM is in the drive, no drive icon appears on the icon bar.

It makes me want to try some experiments. A long time ago, I wanted to write some BASIC functions to access USB SCSI devices at a low level, but it’s yet another of the long list of things I never got round to.

It also makes me want to buy a USB DVD writer to try out. I don’t suppose anyone has any ideas of what would be good? (presumably goodness would be measured by adherence to a standard way of doing things…)

Is there a step (or a short set of steps) missing from RISC OS that would take me from an 8-6-80 UDF-formatted device to an icon on the icon bar?

Dave,

it would be very surprising to see a CDFS icon popping up when connecting a USB CD drive, because CDFS is a very static, configuration-driven thingy – you can’t even properly change the number of CD drives without reinitialising (in the correct order!) all CDFS-related modules. Knowing the way the CDFS API works, how it handles the softloadable drivers and how it assigns its drive IDs – very hard to change. I would have to think about that.

Then you would have to teach CDFS how to read UDF - which is an even harder job. Look at the CDFS source code and be very afraid.

Anyway, expect an email with my efforts soon.

Some news…my Iomega ZipCD USB is apparently broken beyond repair. But I had some success with various drives (Toshiba-Samsung, LG, Lite-On) and a generic USB 2.0 IDE adapter, also by Genesys Logic Inc. like Dave reported. It also reports 8:6:80.

Scanning the USB bus for devices already works, however finding out which endpoints exist for which device does not work yet (this DeviceFS_CallDevice SWI syntax has to be the worst ever seen!). Once this works, and no other obstacles appear, I expect to have a USB-enabled CDVDBurn version ready in a few days. Testers welcome. Once CDVDBurn works, I will tackle the CDFSSoftUSB driver.

Shame about the ZipCD but glad to hear that you’re optimistic about CDVDBurn! If I can borrow a USB CD drive, I’ll be in touch about testing.

How are you enumerating the endpoints?

When I’ve done this, I’ve not used DeviceFS_CallDevice at all, but to use the descriptors in the service call block returned by the Connected or Attach service calls. This is still quite hard work, but probably easier that requesting the descriptors using CallDevice.

Is it possible just to use the special field in the DeviceFS file path to specify the endpoints?

Hi James, yes, I tried an overly complicated way via DeviceFS_CallDevice and failed. But rereading the docs, I have now found an easier (and working!) way via the “Report connected drivers” service call – I already did this to scan for all devices, and now noticed that it already contains not only the DeviceFS device name, but also all device descriptors, config descriptos, interface descriptors and endpoint descriptors.

Currently, I am just opening the bulk in and out endpoints as “files” and use OS_GBPB to send/receive things. Is there a significantly faster way to communicate? Are USB device users expected to only keep those files open during communication?

I’d certainly keep the files open during communication, not least to avoid anyone else opening them. EtherUSB opens the files when it spots a supported device and keeps them open until the module is killed or the device unplugged.

In the case of EtherUSB, everything is happing at quite a low level so it directly reads and writes to the stream’s buffer which can be done using the buffer manager service routine. I’d expect this to be quicker than using OS_GBPB as it is fewer layers of abstraction, however I’ve not profiled it to see whether it is worth doing. usb.h and usb.c in the EtherUSB sources show what I did.

I’ve never been sure whether the method I used is the best way, it is a convoluted mix of FS calls, DeviceFS, BufferManager and UpCalls. Also, I never figured out how to reliably find out when a packet has being sent and I can write the next one to the DeviceFS buffer. Blocking wasn’t really an option for a network driver.

Will this be a Wimp task or a module?

At the moment (CDVDBurn), it will be a WIMP task. The nice thing about communicating with a mass-storage device via SCSI/ATAPI commands is that you know exactly when data transfer will happen and when it is finished. It is always send command/receive reply, and it is usually clear how many bytes the reply will have.

So I hope the USB communication is a lot less complex than you describe. We will see how fast it can go compared to the very suboptimal PIO Mode 0 ATAPI-connected drives.