EHCI and xHCI support?

[volkertb]

What a funny coincidence, @crazii! :laughing:

Last Sunday, I was testing your other software SBEMU on a Mac Mini from 2011, booted in natively in DOS through Legacy BIOS mode, and I ran into the exact same problem that you are apparently trying to solve with USBDDOS.

Basically, SBEMU loads fine, but when I try to start DOS games, they don't respond to keyboard input. Also USB mice are not detected by CuteMouse, and likely not by other DOS mouse drivers either.

And then I saw this project come by in my GitHub feed just this evening.

I tried using a similar open source solution developed by Bret Johnson. However, his solution doesn't support protected mode games, and only supports UHCI controllers.

At least your project supports both UHCI and OHCI. And initially, when EHCI (USB 2.0) was introduced, motherboards and PCI cards with USB 2.0 controllers would come with both an EHCI and a UHCI or OHCI "companion controller".

However, Bret explained something interesting on his website:

Unfortunately, at the end of 2009, Intel introduced their P55 series of motherboard chipset, which does not work the way their old chipsets did. Instead of integrating EHCI and UHCI companion host controllers, the P55 has an EHCI controller (or controllers) and an integral multi-port USB 2.0-compatible hub (or hubs). Most modern ECHI controllers use hubs instead of companion controllers, and XCHI controllers are yet again different than all the earlier host controllers. Bottom line is that it may or may not work for you.

And indeed, the Mac Mini from 2011 on which I tried to run USBDDOS apparently has the same problem. It does report an on-board UHCI controller next to the EHCI controller, but none of the peripherals that I have connected to USB get routed to the UHCI controller. All of them, even the lower speed ones, such as the keyboard and the mouse, end up being attached to the EHCI controller.

In Linux, the output of the lsusb -t command makes this clear:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 12M
            |__ Port 3: Dev 8, If 0, Class=Vendor Specific Class, Driver=btusb, 12M
            |__ Port 3: Dev 8, If 1, Class=Wireless, Driver=btusb, 12M
            |__ Port 3: Dev 8, If 2, Class=Vendor Specific Class, Driver=btusb, 12M
            |__ Port 3: Dev 8, If 3, Class=Application Specific Interface, Driver=, 12M
        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 3: Dev 5, If 0, Class=Vendor Specific Class, Driver=rtl8821au, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
        |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 2: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 2: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 3: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M

Bus 01 and Bus 04 are UHCI root hubs, neither of which have any USB devices connected to them. Instead, all the physically plugged-in USB devices become visible on Bus 02 and Bus 03, both of which are EHCI root hubs.

Then there is the xHCI controller, which was introduced in USB 3.0, which completely does away with the concept of legacy companion controllers.

So it looks like supporting only UHCI and OHCI is not enough to make USBDDOS work with motherboards and laptops released after 2009. For those, EHCI support and xHCI support will really have to be added.

The question is: how easy would it be to add such support to USBDDOS?

Thanks for considering, and also thanks for working on this and keeping DOS (and DOS gaming) alive on modern hardware! :sweat_smile:

[crazii]

Not for now, maybe later. Currently the mouse driver of USBDDOS has problem on some PC (i.e. some p4 laptop without ps2 port). There will be random inputs that happens randomly. It need to be fixed first.

AFAIK ECHI controllers always have UHCI/OHCI companion controller to have 1.x support, but driver will prefer 2.0 if possible, you can attach a 1.0 device to see the connection. I don't know about xHCIs which don't have companion controllers, if without them, how they operate with legacy 1.x devices needs to be investigated.

[crazii]

Also USBDDOS doesn't use any DPMI features to support PM games (no port trapping), So I believe Bret Johnson's USB driver will work for PM games. You can test & confirm that. DPMI is used in USBDDOS only to utilize PM memory and consume little conventional memory, to preserve enough memory for real mode dos programs. (maybe putting more info in readme will be better). The only exception is the RetroWave driver which uses port trapping to emulate ADlib(388h), but that is optional.

[crazii]

Sorry I wasn't reading carefully, you said you already used low speed (1.x, like 'full speed') devices to test. there's also a interesting link form MS: https://techcommunity.microsoft.com/t5/microsoft-usb-blog/reasons-to-avoid-companion-controllers/ba-p/270710

I don't intend to play games on modern PCs, (p4 will be my last choice), but I think to add ECHI and xHCI is a good idea.

[volkertb]

Indeed. I was testing with a USB mouse and a PS/2 keyboard hooked up through a PS/2 USB adapter, and neither the mouse nor the adapter were routed to the on-board UHCI controller, as you can see in the output I shared above. They all appeared on the EHCI controller, which was the likely reason why neither USBDDOS nor Bret Johnson's drivers detected any connected USB keyboards or mice. Apparently, neither EHCI controllers from 2010 onwards nor xHCI controllers have UHCI or OHCI companion controllers anymore.

So for most PCs and laptops manufactured after 2009, support for UHCI and OHCI alone won't work.

The thing is that to my knowledge, there are no EHCI or xHCI USB drivers for DOS yet, at least no open source ones. Supposedly there is a closed-source one out there somewhere, but I haven't tried it. (And I'm not sure if it also supports xHCI besides EHCI.) I wonder how hard it would be to add such support. Could existing drivers from the Linux or BSD kernels be ported over? Had it been trivial, it would likely have been done already. (Same as with SBEMU. :wink:)

[crazii]

It is not an easy work. Especially for debugging, you have to restart frequently when the driver hangs, that's why I prefer VM (VirtualBox) to debug, it restarts fast. Now that I've got some experience on OHCI & UHCI, that might ease it a little bit.

The mouse driver bug of USBDDOS is fixed but I found another bug and may try to fix it. I have a ThinkPad T540p bought around the year 2016, I think it has HUBs instead of companion controllers as you said. But its screen was broken last year, due to a Linux video driver bug. After it is repaired I might start looking into the ECHI stuff.

[volkertb]

It is not an easy work. Especially for debugging, you have to restart frequently when the driver hangs, that's why I prefer VM (VirtualBox) to debug, it restarts fast. Now that I've got some experience on OHCI & UHCI, that might ease it a little bit.

In that case, it's a good thing that support for EHCI and xHCI USB controllers was added to the Open Source Edition of VirtualBox 7. :slightly_smiling_face:

I have a ThinkPad T540p bought around the year 2016, I think it has HUBs instead of companion controllers as you said. But its screen was broken last year, due to a Linux video driver bug. After it is repaired I might start looking into the ECHI stuff.

Oh wow, that sucks. :confused: Thankfully, it's really rare for software to be able to break hardware like that. The Thinkpad T540p has two USB 2.0 ports and two USB 3.0 ports , which means that it has both an EHCI controller and an xHCI controller, so you should be able to test it with both, once you have it fixed.

I'm wondering... How hard would it be to extract the USB driver core from the Linux kernel sources? I tried doing the same with some of the sound drivers, and it wasn't easy to untangle the sources and reuse them in a portable manner. I reckon it won't be much easier with USB host controller drivers.

[Torinde]

Supposedly there is a closed-source one out there somewhere

DOSUSB - xHCI, EHCI, UHCI and OHCI. There are also some storage drivers from various manufacturers, some with unclear license/distribution status.

[volkertb]

@crazii So I thought I'd try "extracting" the EHCI driver code from the Linux kernel sources into a DOS test project. Just see if I could make some code that could interact with an EHCI controller, perhaps query it for some data, so not even a driver yet.

I thought I'd just start with copying over the header files until I'd have all the necessary header files that were being included, after which I'd try figuring out what implementation code from the C sources I could copy over, which header definitions I could just stub out, and which stuff I would have to port. I figured I would just start including ehci.h, then add <linux/usb/ehci_def.h>, <linux/usb/ehci-dbgp.h>, etc.

But just getting all the needed header files turned out to be a rabbit hole. Each header file would reference one or more other header files, and so on, which would snowball quickly.

Just the type definition headers keep referring to other headers, often different once depending on architecture...

What would be a smarter way to go about this?

(I recently tried extracting and porting driver sources from Linux and FreeBSD to DOS in a similar way, and that also went nowhere, for the same reason.)

[crazii]

There's no easy way to do that. It's best to use defines and types only from the ECHI spec, and for other system types/functions, you define it yourself instead of using system headers.

[crazii]

I tested USBDDOS with T540p and it doesn't recognize the controller, but the laptop's BIOS has good legacy emulation for USB mouse, games works well with only CuteMouse. Then the screen starts to flash&delay within a few minutes before I was going to do more tests. ECHI on VirtualBox may not have HUBs, it has companion controller, so I can debug with VirtualBox for the basic ECHI function, but the compatibility with 1.x devices (transfer rate matching via HUBs) may need to wait for the T540p or another real pc.

EDIT: I tested USBDDOS/USBDDOSP with duke3d for hours (and also for fun), it seems it is stable now. I will start looking at the ECHI stuff in a few days maybe.

[crazii]

Supposedly there is a closed-source one out there somewhere

DOSUSB - xHCI, EHCI, UHCI and OHCI. There are also some storage drivers from various manufacturers, some with unclear license/distribution status.

About DOSUSB, I think most people here will pass.

USBDDOS may need a opensource license too. The problem is the original code is from google code with an unclear license, and I cannot get access to google code or any other google sites for now. Good thing is that the original code seems abandoned for years and USBDDOS has changed so much that, it is almost totally different from the original code.

[volkertb]

There's no easy way to do that. It's best to use defines and types only from the ECHI spec, and for other system types/functions, you define it yourself instead of using system headers.

Yeah, that makes sense. It's pretty clear which symbols and headers are specific to EHCI, and which ones are more system-wide. I won't have time for it throughout the week, but maybe I'll play with that a little more in the coming weekend.

Thanks.

[Torinde]

About DOSUSB, I think most people here will pass.

Agree. Still, its documentation, screenshots, etc. are interesting and may have links/details that will help understanding some USB aspects.

[Torinde]

original code is from google code with an unclear license

License: New BSD License Content License: Creative Commons 3.0 BY (link at Google Code is dead, so here is it at Creative Commons)

Is that sufficient to make a license for USBDDOS?

[volkertb]

The "Modified BSD License", a.k.a. the "3-Clause BSD License", is compatible with GPLv2.

See https://www.gnu.org/licenses/license-list.en.html#ModifiedBSD

So no problem, and nothing unclear about it.

But I am puzzled why the USBDDOS source code is apparently licensed under the GNU Affero General Public License, as opposed to the regular (non-Affero) GPL, since I can't think of any realistic scenario where the USBDDOS would be used to host a website or web service.

But regular GPL apparently includes a clause that says it may be combined with Affero GPL software (as long as it's the same version number, I assume?)

Speaking of GPL versions: GPLv3 is a can of worms and not necessarily compatible with all GPLv2 code (it depends on whether or not the GPLv2 license on the code includes the optional "or later" clause).

Yeah, software licenses are confusing, I know. 🫠

By the way, does this seemingly forgotten project on Google Code actually already support EHCI?

[volkertb]

@Torinde By the way, I downloaded the archived sources from that Google Code project and did a search in the code for the text EHCI, but it looks like the author only had made some preparations in the code with the intent to actually implement EHCI support at some point later, which apparently never ended up happening.

It might still provide some useful examples, though.

[Torinde]

Can you upload the code here? Or maybe use the "Export to GitHub" button. @crazii mentioned he can't access that website.

[crazii]

By the way, does this seemingly forgotten project on Google Code actually already support EHCI?

I don't remember there's any EHCI code. You can confirm the source youself.

[crazii]

I've done the EHCI code and tested on a P3 laptop (EHCI+OHCI companion) and it works. Now I'm testing it with T540p for which I replaced the LCD screen last night.

[volkertb]

For reference (and for those of you who can't access Google sites), here is the downloaded archive from that usb-driver-under-dos project:

source-archive.zip

[volkertb]

By the way, does this seemingly forgotten project on Google Code actually already support EHCI?

I don't remember there's any EHCI code. You can confirm the source youself.

I did, and indeed, there only appear to be some references and preparatory work that made it clear that the developer at the time intended for it to be added in the future.

[volkertb]

I've done the EHCI code and tested on a P3 laptop (EHCI+OHCI companion) and it works. Now I'm testing it with T540p for which I replaced the LCD screen last night.

That is amazing, crazii! Once again, you're about to a achieve a historic "first": the first working open-source EHCI-compatible USB driver for DOS. :rocket: This will be useful for a lot of retro DOS enthusiasts. :relaxed:

Do you think xHCI will be comparable in terms of effort?

[crazii]

xHCI will wait when it is more stable. While testing EHCI on the P3 laptop I found there's still freeze which is not seen on a P4 laptop, there's bugs that need to be fixed.

[Torinde]

xHCI - one additional device type that can be supported by it is USB Attached SCSI protocol (UASP).

[volkertb]

@Torinde UASP is technically not exclusive to xHCI. It's an improved device class for external drives that offers increased performance over the USB Mass Storage class. UASP is basically "SCSI over USB". But it can also work over USB 2.0 (EHCI).