2003-07-05

USB problems

Lawrence W posted this note (warning? rant?) to the FreeDOS mailing list and I thought I should re-post it as a technote:

I thought I should post this as a warning to the group. I have noticed a lot of traffic recently regarding USB support under DOS. As a former USB firmware engineer myself, I think some things should be said for clarification:

1. USB suffers from a horrendous lack of standards. There is a standard for USB mass storage, known as the USB Mass Storage Class. Native BIOS support is provided for this standard on some modern BIOSes. However, only some mass storage devices subscribe to this standard. To support those which do not requires proprietary drivers. That's where USB degenerates into a tornado in a junkyard. You see, it's not like PCI.

You can't easily have 2 or 3 different drivers coexisting peacefully. USB presumes that a single entity is in control of the bus, managing all traffic and invoking higher level drivers as needed. When you install a USB driver under DOS, it can interfere with all other USB devices, and the BIOS, if legacy USB keyboard emulation or USB mass storage support if it is enabled in the setup. (Under Windows, Windows itself is in charge of the bus. Under DOS, there is no such parent entity.)

2. It's great if USB support is available from some third party, but if it's not already obvious: (1) Don't take "hang" reports too seriously, unless they don't happen under identical circumstances under MSDOS. (2) Do not destabilize FreeDOS by adding native USB support. That would ruin its chances to be the stable-as-hell, simpler-than-Linux embedded OS that it can become; let the BIOS take responsibility for USB's woes.

3. USB is such a disaster that the CEO of Via Technologies spearheaded an effort to kill USB 2.0. He failed (mainly because his competitor, Intel, was pushing ahead). 1394 (Firewire) is a much better standard, but hasn't really happened because Apple wanted to play toll collector with its patents, which made the technology severely unattractive.

4. The circumstances of USB success and failure, on a software and hardware level, are so incredibly complex and environmentally dependent that bugs are virtually unsolvable unless one controls the OS, the drivers, and the devices. Look, I can write hostside drivers that are solid. But if the device out there is a piece of junk or fails randomly after 6 hours, there's nothing I can do. It's little wonder that USB often requires multi-thousand-dollar bus analyzers to debug.

5. Hot plugging is a total disaster when you have drivers and BIOS conflicting, not to mention a legacy PC model in which mass storage is not presumed to be hot pluggable.

6. Use IDE and be happy. Or 1394 if you must. By all means, stop using USB and disable it in the BIOS if you want to see stability and performance improve. USB should be viewed as a last resort, if other bus technologies are not available.

Don't get me wrong. I'm all for mobility, compactness, and versatility. Under controlled circumstances, USB can live up to those goals. But we will probably never see the day when USB mass storage is as fast and reliable as IDE mass storage, in the sense that it almost doesn't matter which brand you buy.

Lawrence W adds:

the USB Mass Storage Class standard is at: http://www.usb.org/share-cgi-bin/search (type "mass storage class" in the search dialog).

As you'll discover, there are actually several substandards under this one, which amount to about 4 subtly different flavors of SCSI. Thus even the "standard" ain't a standard!

If you want to leave it to the BIOS, here's the INT 13h spec: http://www.t13.org/docs2002/d1484r2a.pdf

Now, as to a USB stack... it is entirely possible that FreeDOS could include some sort of FreeDOS-only USB stack, which does away with the silly hodgepodge-of-drivers concept, and provides an INT-based calling interface for third parties to use, in the fashion of INT 21h. The distinction, of course, is that the USB INT service would perform rudimentary USB transactions. If FreeDOS (or any OS) is going to go anywhere with USB, it absolutely must have this single-owner paradigm.

That's the easy part. The hard part is getting third party driver writers to care about FreeDOS enough to use the INT interface. Sure, it could live mostly above 1MB. It probably should.

The nice thing is that this driver could be made MSDOS compatible, so it could be back-ported to that OS as well, which would broaden third party interest. I must agree that if enough manufacturers were interested, it would be a really hot idea that would rocket FreeDOS into the Wind River class of embedded OSes.

It must be said, though, that even a USB abstraction layer which knows nothing at all about individual device classes is a MAJOR undertaking. I cannot express to you all how chaotic USB is. It's easier to predict earthquakes than to debug realtime USB phenomena.

At the very least, the interface would need to ship with HID (Human Interface Device) Class support as a service client. The reason is that FreeDOS would wrench the USB controllers out of the BIOS's hands, and would thereby kill legacy keyboard emulation.