USB CD Support

Interesting – if 0:0.0 really was the CD drive on your first attempt, then that must mean there’s a bug in SCSIFS that’s causing it to reserve devices which aren’t standard direct-access storage devices. Although that wouldn’t explain why the inquiry result only showed one device connected, and after some quick testing here I can’t find a situation in which SCSIFS ends up with the wrong device reserved.

Anyway, I’ve now uploaded another version of the driver, which should fix Doug’s problems for real this time. It looks like I’d simply forgot that some of the parameters available by CD_GetParameters/CD_SetParameters may be read-only.

I did find that the internal IDE CDROM was using 0.0.0 so it is removed now.
The newest driver has stopped erratic comnnections, and I also have had DADPrint output data related to the Target error I now get.
I’ll delete this later, hopefully. -now deleted

Jeffrey, it might be helpful to make the version strings of CDFSSoftSCSI unique so that I can be certain that a new one has replaced an earlier one. All your modules seem to be version 0.01 (20 Nov 2011) in the three different zip files I’ve downloaded so far. I know the files have different lengths so they must be different, but I can’t easily tell which one is resident.

Jeffrey

Some good news in that the new module now lets me read CD’s , DVD -r and +R discs so thanks for your efforts on this.

However it seems a bit erratic from cold restarting of the Beagleboard for the drive to work but I can cure this if it fails on initial startup by unplugging the drive and reinserting i.e. doing hot plug in. After this the drive work OK though DADPrint shows errors as per below.

Once again thanks for your efforts so far on this.

Doug

CDFSSoftSCSI: driver_code: Op Identify (30) on 0:0.0
CDFSSoftSCSI: driver_code: Op Identify (30) on 0:1.0
CDFSSoftSCSI: driver_code: Op Identify (30) on 0:2.0
CDFSSoftSCSI: driver_code: Op Identify (30) on 0:3.0

Thanks for the info Ron – I’ll have a look through your log and see if I can work out what the problem is.

Jeffrey, it might be helpful to make the version strings of CDFSSoftSCSI unique so that I can be certain that a new one has replaced an earlier one

Point taken – I’ll make sure they all use different version strings from now on.

One further observation, after the Target error illegal request, the drive disappears from -cdfs-cddevices until clicking on the CDFSSoftSCSI module again. BTW I am using the newest driver mentioned 3 hours ago

I have now tried my newer Sony DVD writer, and after a few tries,
I have a Data DVD displaying in the filer and it appears OK so far.

I can remember the Aopen drive not responding well to the Cino Driver
release a while back, so it may be a bad egg, (works ok in linux of course)
and I will leave it to you wether it will be an issue to consider.

I’ll add on here, that the driver is working perfectly on my RiscPC SA 3.7 using an Acard ide-parallelSCSI adapter and an Acorn SCSI podule. Looks fast too. Even more surprising is the (troublesome on usb) Aopen is fine too.
*-cdfs-cddevices shows (for the Sony)
Drive 00 Dev 6 LUN 0 Card 0 Product G170A Capacity 1363Mbyte Firmware 1.75
*devices hows
6 Read-only 1363Mbyte Sony DVD RW AW-6170A 1.75
It is device 6 0n the parallel SCSI bus, host being 7 as per normal.
Xmas has come early this year :-)

Ron

Data DVD displaying in the filer and it appears OK so far.

This sounds like great news :-)

Xmas has come early this year

A RaspberryPi and a Pandora (in my dreams)!

if 0:0.0 really was the CD drive on your first attempt, then that must mean there’s a bug in SCSIFS that’s causing it to reserve devices which aren’t standard direct-access storage devices.

Just to confirm: having just powered the BBxM up tonight, 0:0.0 is the DVD drive and 0:1.0 is the HDD. SCSIFS is 1.22 (14 Oct 2011). The good news is that, having loaded your CDFSSoftSCSI module, a CD is readable without any further ado.

Is there any more diagnostic information you’d like?

Are there any tests you’d like me to perform?

Whereabouts in !System should your CDFSSoftSCSI module go?

All working fine here too!
I’m using a Samsung SE-S084 External USB drive.

Even the Eject option works!

Nice work Jeffrey!!!!!

Seems to work OK with an XBox 360 HDDVD drive on my Iyonix (after I killed CDFaker, loaded the module and configured the drives). Hopefully this will go into the Iyonix ROM too?

(I noticed the internal one no longer worked).

How should the speed compare with the Iyonix ATAPI interface?

Steffen and Jeffrey:

I’m hoping that the next step will be to get CDVDBurn working on BeagleBoards. I note that CDVDBurn has been observed to work (to some extent) on a BB, but any attempt to get CDVDBurn 2.06b to run on my BBxM produces an Abort on Data Transfer, regardless of the setting of alignment exceptions.

Steffen, does it require a later version of CDVDBurn than I appear to have?

And to both of you: what else is necessary to make it work?

If I can be of any help, please just let me know!

Hi Dave, I do have a CDVDBurn version that seems to work on BeagleBoard with some drives, but I have problems making it work with other drives. Symptoms include complete lockups and strange USB errors. I will send you the version that seems to work best on the Beagle.

The original plan was to release a new version of CDVDBurn in 2011 with all the things I developed during the past few years (USB/Beagle support, Blu-Ray support, CD/DVD/Blu-Ray Extractor, Verify, DVD-RAM support). It looks like this plan will fail – to much “real world work” to do. I am not sure how to proceed. Maybe just release it for everyone, and ask those where it works for a donation? It certainly makes little sense to not release anything for the next years because I don’t have the time to finish it properly.

A few posts for me to catch up on. First Dave:

if 0:0.0 really was the CD drive on your first attempt, then that must mean there’s a bug in SCSIFS that’s causing it to reserve devices which aren’t standard direct-access storage devices.

Just to confirm: having just powered the BBxM up tonight, 0:0.0 is the DVD drive and 0:1.0 is the HDD. SCSIFS is 1.22 (14 Oct 2011). The good news is that, having loaded your CDFSSoftSCSI module, a CD is readable without any further ado.

Is there any more diagnostic information you’d like?

Are there any tests you’d like me to perform?

One thought that occured to me a day or two ago is that the CD drivers might be suffering from a similar issue to SCSIFS, where if the USB devices aren’t enumerated fast enough on boot then the system won’t see that the drive is connected. It was easy enough to solve this with booting from USB mass storage devices by just making FileCore retry until the device appears (or escape is pressed), but for detecting CD drives (unless you’re trying to boot from one) I don’t think there’s a simple solution available.

Possible solutions I can think of:

1. Try swapping which ports the drive is connected to
2. Wait until I’ve added CD autodetection/hot-plug support
3. Add something to your boot sequence which will restart the CD modules sometime during startup

One thing I don’t quite understand is why the drive starts working when you simply softload a copy of CDFSSoftSCSI. In my experience loading/reloading a driver won’t cause CDFS to rescan for drives, so perhaps the problem you’re seeing is just a bug in the first version of CDFSSoftSCSI and not down to USB device detection/enumeration being slow.

Whereabouts in !System should your CDFSSoftSCSI module go?

If you want to have it softloaded on startup then just dropping it in the PreDesk should do the trick. Putting it in !System won’t really do much, since AFAIK the boot sequence doesn’t try looking for CD drivers there.

Jess:

Seems to work OK with an XBox 360 HDDVD drive on my Iyonix (after I killed CDFaker, loaded the module and configured the drives). Hopefully this will go into the Iyonix ROM too?

At the moment the SCSI/USB mass storage modules aren’t included in the Iyonix ROM image. They get softloaded during boot instead. So if we added CDFSSoftSCSI to the ROM then we’d also need SCSIdriver and SCSISoftUSB, and if we were to add those two then it would make sense to include the remaining two modules as well (SCSIFS and SCSIFiler). The only problem is that there isn’t much space left in the ROM image (about 76k IIRC).

I think that including the modules in the ROM image is a good idea, but we might have to switch over to compressed ROM images either now or sometime soon in order to make sure we don’t run out of space.

(I noticed the internal one no longer worked).

This will be because of the way that the CD drivers use SCSI device IDs to identify everything, even drivers that don’t use the SCSI stack like ATAPI and CDFaker.

A proper fix would be to wait for full hot-plug support, but in the meantime maybe I can just change the order in which CDFSDriver scans for drives so that device IDs that are least likely to be used by real SCSI devices are checked first.

How should the speed compare with the Iyonix ATAPI interface?

I haven’t done any speed comparisons, but since all the operations will internally go through SCSIdriver, SCSISoftUSB and the USB stack, the driver should get about the same performance as SCSIFS when reading from a (fast) USB drive.

Steffen:

Hi Dave, I do have a CDVDBurn version that seems to work on BeagleBoard with some drives, but I have problems making it work with other drives. Symptoms include complete lockups and strange USB errors. I will send you the version that seems to work best on the Beagle.

You probably should have pestered me a bit to help you investigate those errors :-)

Over the weekend I had a look into the bug that was causing a softlock when my TS-H552 DVD-RW is connected. It looks like there were a few different issues at work:

1. SCSIFS and SCSIdriver were issuing INQUIRY commands with a 5 byte response buffer. The drive didn’t like this and wasn’t responding to the command at all, which seems to be the primary cause of the lockup. So these have now been changed to use standard 36 byte response buffers.
2. I also finally updated the flash in my Iyonix from 5.12 to the latest 5.17 development build, which would have brought in a lot of USB driver fixes. However reflashing your Iyonix with a development build is something I do not recommend – the only reason I did it was so I could properly test that everything was working OK with the Cortex kernel. But for people who do want to reflash, word on the street is that there’ll be a 5.18 stable release sometime in the next couple of months.
3. I also discovered that SCSIdriver completely ignores any specified timeout value if the low-level driver uses background transfers (which will be the case with SCSISoftUSB). So I’ve now added timeout support, which means that most of the time the DVD drive will recover if asked to do something it doesn’t like. But it looks like there’s still a bug somewhere in SCSISoftUSB that stops it from recovering properly after an operation has been cancelled, so that will require some further investigation.
4. Also despite the above fixes, the drive still doesn’t work. It looks like there’s a bug in CDFSSoftSCSI somewhere, so I’ll have to investigate that. But I have at least checked in all the fixes to CDFSSoftSCSI that I made last week.

Since there have been a few fixes made, I’ll see if I can get Steve to upload some new ROM images sometime this week. But don’t be surprised if there’s yet another new ROM in a couple of weeks, containing even more fixes :)

At the moment the SCSI/USB mass storage modules aren’t included in the Iyonix ROM image. They get softloaded during boot instead. So if we added CDFSSoftSCSI to the ROM then we’d also need SCSIdriver and SCSISoftUSB, and if we were to add those two then it would make sense to include the remaining two modules as well (SCSIFS and SCSIFiler). The only problem is that there isn’t much space left in the ROM image (about 76k IIRC). I think that including the modules in the ROM image is a good idea, but we might have to switch over to compressed ROM images either now or sometime soon in order to make sure we don’t run out of space.

That would be useful. The reason I was thinking of was if this is done, it should then be relatively easy to make a special softload to test the bootimage for a Pi. (Hardwired to boot from a USB drive, perhaps with no IDE support)

Hi Jeffrey,

yes, of course I should have tried to get help…so many people have offered help, but I am not even able to supply enough code/information to people so that they can actually help me!

The lockup/error recovery problem I talked about is exactly the problem that I wanted to analyze and isolate via the CD prototype and send it your way – since around GAG meeting (which was in August!). Well, it didn’t happen (yet!). But maybe, due to your fine work with the CDFS driver, you may encounter the same problem and fix it without waiting for me!

I’ve built an OMAP3 ROM from last nights CVS. (Which contains the latest SCSI updates.)

Download Link

EDIT: ROM updated to CVS date 30/11/2011

Steffen:

I will send you the version that seems to work best on the Beagle.

Thanks, Steffen. I had a chance to do a quick test early this afternoon; it wrote a CD-R fine (dog slow, but I had set it to 1x).

I’m writing a DVD-R at the moment with an image that is somewhere in the order of 1 GB. The write (set to 4x) is proceeding at about 2 minutes per percent, which means it will take about 3 hours 20 minutes to complete. Currently it’s at 43%. I may not get to see the results until tomorrow morning. Of course the HDD and the DVD are both on USB, and the ISO image is on the HDD. I can imagine this could be a bottleneck.

Maybe just release it for everyone, and ask those where it works for a donation?

On the strength of what you have sent me this morning, I think I owe you a donation already!

The write (set to 4x) is proceeding at about 2 minutes per percent, which means it will take about 3 hours 20 minutes to complete.

That sounds a tad slow! Only about 83kB/sec. Steffen, how is CDVDBurn reading the ISO file – i.e. once it gets down to the filesystem level, will it be byte reads or (large) block reads? If it’s byte reads (or anything under several K at once) it will be dog slow due to the lack of caching in SCSIFS. Although that’s hardly something that’s your fault.

Rewriting SCSIFS is almost at the top of my todo list, but sadly still a couple of months away :(

Btw: the write completed in a tad over 2 hours. Counting the files, they total about 1.5 GB; somewhat bigger than I thought.

I can read the DVD back in the writer attached to the BB, but not in either of the drives in my Iyonix. I don’t yet know why.

Hey, CDVDBurn should not even be able to write a DVD-R! It should only work with DVD+RW, DVD-RAM, BD-R, BD-RE and DVD-RW, and with a lot of luck DVD+R.

About the performance: if Dave has not reconfigured something, 64 KB blocks at once are read. Simple OS_GBPB calls.

Write speed is currently only set when writing CDs, when writing DVDs/BDs the slowest possible writing speed for the inserted medium is automatically chosen, mainly because the IYONIX IDE subsystem was not fast enough for higher speeds (1x is already around 1.2 MB/s).

Your read problems could be due to incomplete medium fixation, so only a real writer will be able to read it.

Jeff
“I haven’t done any speed comparisons, but since all the operations will internally go through SCSIdriver, SCSISoftUSB and the USB stack, the driver should get about the same performance as SCSIFS when reading from a (fast) USB drive.”

By coincidence I did this test this morning, and 535MB copied from The DVD in 2min35 and the same batch of large files copied from My USBHardDrive in 2min22.
It takes the Dvd a while to wind up to speed so the difference is small.

I am finding at the moment that following the loading of CDFSSoftSCSI, plugging in the usbCDDrive, I repeat issueing -cdfs-cddrives until it returns with the drive and then proceed with normal filer activity.

What are the minimum CDFS related modules required? I’d like to try the Iyonix ones on my RiscPC with parallel SCSI.
Update- I have been able to use the Iyonix CDFS module but not the
Iyonix CDFSFilermodule. I am also using the original CDFSRes module which must be linked to the CDFSFiler module as errors appear.
The old CDFSdriver is no longer required.
A similar speed test shows the RiscPC to be 6 times slower, which I think is in line with previous HD speed comparisons to the Iyonix.

Ron

I’m writing a DVD-R at the moment

Hey, CDVDBurn should not even be able to write a DVD-R!

My apologies for writing the rubbish that I did. I don’t know where my brain was at the time. I wrote a DVD+RW.

As for the speed: I haven’t knowingly reconfigured anything, so I assume we are dealing with 64 kiB blocks.

I’ve put the DVD+RW in an ex-laptop drive connected to an Eee PC; it reads the disc.

@Steffen
Please can you send me the latest CDVDBurn for the BeagleBoard?

rob at robheaton dot co dot uk

Maybe just release it for everyone, and ask those where it works for a donation?

Steffen, CDFaker & CDVDBurn are now contained in the Raspberry Pi disc image proposals. The latter links to CDBurn Lite – is that an option?

Hi Trevor, the idea of CDBurn Lite is certainly still worth considering. However, I think CDVDBurn will live on as “donationware” in the future, so this would be the preferrable option. I’ll try to figure out a way forward in the next few days.

CDFaker: Copyright is still Andy Armstrong. And now Jeffrey has provided a stable C-written base for a CDFSSoft… driver, it would be a good idea to just rewrite CDFaker. Preferrably with support for “large” CDVDBurn-style images.