OSDev.org

Hi, I've done quite forums on EHCI, I had some problems at first but I fixed them. I'm getting the driver working fine on QEMU, interrupts are fine using IOAPIC, I can detect attached devices, assign an address for them, request their name etc...

- On VBOX, I do not receive interrupts, but if I do a loop to handle interrupt events the driver detects everything without problems.
- On Real Hardware, EHCI Completely shutdowns, the mouse goes off.

QEMU IOAPIC Interrupt Source Overrides(ISO):
0-2, 9-9, 11-11. 11 is the interrupt line of EHC
VBOX IOAPIC ISO:
0-2, 9-9. 10 is the interrupt line of the EHC

On My HP there is more ISO's but it seems like the VBOX one

My kernel have the same IDT on all processor, it is a multiprocessor kernel. It has a table on all processors specifiying the handlers and that stuff, and interrupts are arbitrary attached to processors at non fixed vectors for e.g.

- Driver 1 request IrqControl IRQ Number : 2
- Kernel attaches the IRQ 2 to processor 0 with Interrupt Vector 32
- Driver 2 request IrqControl, IRQ Number : 11
- Kernel attaches the IRQ 11 to processor 1 with Interrupt Vector 32 (since it is free on this processor)

- All the processors reports that are working and calculating cpu time

- Here is the redirection entry of the IOAPIC:
- IOAPIC RedirectionEntry#(EHC int line)
DestinationMode : Physical.
intvector : 32
TriggerMode : 0 (edge sensitive)
Destination : (Target APIC Processor ID)
TriggerMode : 0 (Fixed)

devc1 wrote:VBOX IOAPIC ISO:
0-2, 9-9. 10 is the interrupt line of the EHC

Are you sure it's interrupt line 10? Where are you seeing that number?

It is on the pci configuration (Interrupt Line).

devc1 wrote:It is on the pci configuration (Interrupt Line).

The interrupt line register in the PCI configuration space is only valid for legacy PIC. You need to use ACPI or the legacy MP tables to locate the interrupt line on the IOAPIC. Or, if the hardware supports it, you can use MSI or MSI-X.

I parsed them (see the question). and I do not support
MSI/MSI-x. Will EHC Controller use MSI for interrupts? And if you wan't, can you show me an example of implementing MSI /MSI-X

I tried to unmask all 24 interrupts in the IOAPIC. And I do not get a single interrupt. Only PIT One, I forgot to mension also that RTC interrupts work on Real hardware and QEMU But not VBOX. On QEMU, I keep getting an IRQ 22 maybe it's a timer I don't know.

And when typing "info pic" on QEMU, I get everything that I mapped in the IOAPIC.

devc1 wrote:I parsed them (see the question).

What did you parse? The MADT does not tell you how PCI interrupts are routed to IOAPIC inputs. You need either the ACPI _PRT method or the MP tables.

devc1 wrote:Will EHC Controller use MSI for interrupts?

Maybe. It's not required by the EHCI specification.

devc1 wrote: - On Real Hardware, EHCI Completely shutdowns, the mouse goes off.

The mouse is a low-speed device. If it is connected to the EHCI's root hub (and that root hub is not a Rate Matching Hub), the EHCI will pass this on to one of the companion controllers. You won't get an interrupt from the EHCI. So the EHCI will, in essence, "completely shut down".

Unfortunately, if you are writing an EHCI driver, you also have to write a UHCI (and/or OHCI) driver as well, or connect everything through an external hub, which means you now have to write an External Hub driver.

IMHO, forget about the EHCI and move on to the xHCI. The EHCI is/was more trouble that it was worth.

Ben
- https://www.fysnet.net/the_universal_serial_bus.htm

My mouse is a logitech gaming mouse, it is USB2 (Has a black port), I've also a 16GB USB Hard drive which is also USB2. When i connect the drive to VBOX it shows as "Disk2". I'll try to implement OHCI & UHCI. They may be easier right ?

devc1 wrote:My mouse is a logitech gaming mouse, it is USB2 (Has a black port),

Well, technically, USB 2 incorporates USB 1. Have you read the port status registers? Is that truly a high-speed device? Can you inspect its speed class in an OS in which USB is working?

I've also a 16GB USB Hard drive which is also USB2. When i connect the drive to VBOX it shows as "Disk2". I'll try to implement OHCI & UHCI. They may be easier right ?

I concur with Ben, switch to xHCI. Easier still to implement, and it has no need for companion controllers. The spec is openly available from Intel. The only reason to still use EHCI, OHCI, or UHCI is compatibility, but xHCI has been the standard in PCs for a decade or so.

EHCI is just a weird hack to make USB 2 work. Many things in it are bonkers. For example, when you send a transaction to a device, you must know if it is high speed or any other speed, in order to fill out all the fields correctly. You also must know the deepest USB 2 hub on the way to the device (so traverse up the parents from the device you want to message until you find a USB 2 hub). Whereas xHCI mostly keeps track of that stuff for you.

My computer support EHCI & XHCI & OHCI . I Think I'll try to implement XHCI. The ports I'm connecting my devices to have a black color (which is normally known as USB2).

And there is something also true about interrupts as said (I should parse that ACPI_PRT (PCI Interrupt Routing Table)). On Windows (System Information/IRQs) I Found the the first EHCI Controller on IRQ 16, and the other on IRQ23. instead of IRQ 10/11.

I'll try that, thanks.

devc1 wrote:My computer support EHCI & XHCI & OHCI . I Think I'll try to implement XHCI. The ports I'm connecting my devices to have a black color (which is normally known as USB2).

And there is something also true about interrupts as said (I should parse that ACPI_PRT (PCI Interrupt Routing Table)). On Windows (System Information/IRQs) I Found the the first EHCI Controller on IRQ 16, and the other on IRQ23. instead of IRQ 10/11.

I'll try that, thanks.

xHCI works with USB 2.0 and higher. So no need to worry about that. Hell, it might support 1.x USB devices too. Honestly I'm pretty sure the only devices that still use 1.x are audio devices -- and even then that's a questionable assertion.

Ethin wrote:

devc1 wrote:My computer support EHCI & XHCI & OHCI . I Think I'll try to implement XHCI. The ports I'm connecting my devices to have a black color (which is normally known as USB2).

And there is something also true about interrupts as said (I should parse that ACPI_PRT (PCI Interrupt Routing Table)). On Windows (System Information/IRQs) I Found the the first EHCI Controller on IRQ 16, and the other on IRQ23. instead of IRQ 10/11.

I'll try that, thanks.

xHCI works with USB 2.0 and higher. So no need to worry about that. Hell, it might support 1.x USB devices too. Honestly I'm pretty sure the only devices that still use 1.x are audio devices -- and even then that's a questionable assertion.

More like most input devices (keyboards, touch & mouse) use USB 1. XHCI certainly supports USB 1, but if you have EHCI/OHCI/UHCI hardware only then that is of no help. Using USB hubs might make it unnecessary to implement OHCI/UHCI though.

rdos wrote:

Ethin wrote:

devc1 wrote:My computer support EHCI & XHCI & OHCI . I Think I'll try to implement XHCI. The ports I'm connecting my devices to have a black color (which is normally known as USB2).

And there is something also true about interrupts as said (I should parse that ACPI_PRT (PCI Interrupt Routing Table)). On Windows (System Information/IRQs) I Found the the first EHCI Controller on IRQ 16, and the other on IRQ23. instead of IRQ 10/11.

I'll try that, thanks.

xHCI works with USB 2.0 and higher. So no need to worry about that. Hell, it might support 1.x USB devices too. Honestly I'm pretty sure the only devices that still use 1.x are audio devices -- and even then that's a questionable assertion.

More like most input devices (keyboards, touch & mouse) use USB 1. XHCI certainly supports USB 1, but if you have EHCI/OHCI/UHCI hardware only then that is of no help. Using USB hubs might make it unnecessary to implement OHCI/UHCI though.

I mean, any decently modern computer isn't going to have EHCI or UHCI/OHCI hardware. I know my computer is quite recent but all it has is an xHCI controller, and I think my laptop from 2016 even has only an xHCI controller.

The most common mistake I have noticed most newbies make is that of USB 1 == UHCI/OHCI, USB 2 == EHCI, USB 3 == xHCI. This is simply not, I repeat, not the case. The USB specification supersedes the hardware it describes. The hardware (the controller), is made to accommodate the USB specification, to allow the communication described in the USB specification.

A super-speed, top of the line thumb-drive using "usb attached scsi protocol", aka UASP and streams, transferring sectors faster than anyone could have ever imagined when plugged into a compatible xHCI root hub, should at the very least, enumerate on a UHCI, making it USB 1 compatible. Yes, it won't transfer faster than 12Mhz, but it is still USB 1 compatible. In fact, it may not transfer sectors at all, but as long as it enumerates, it is still USB 1 compliant. (If the thumb-drive doesn't support BBB or CB or whatever older protocol, only supporting UASP, this doesn't make the device USB 1 incompatible. It just means that the firmware doesn't support the old protocol, which is not the device's fault.)

Same goes the other direction, a simple low-speed, two-button mouse, with a ball, (not optical--remember those?), should and will still enumerate/work on a xHCI controller.

The controller is simply the hardware to allow the USB communication to take place. The UHCI/OHCI supporting USB 1, the EHCI supporting 1 and 2, and the xHCI supporting all the features of USB 1, 2, and up to USB 3.x (and now 4).

It would surprise me if your gaming mouse is anything faster than a full-speed device. I can't move the mouse or click a button faster than 12Mhz, can you? :-) Just because it has "USB 2.0 compatible" printed on the box doesn't mean it is a high-speed device. (And I don't mean to direct that at you, I am simply making a point).

To answer your other question about UHCI or OHCI being easier, my answer is yes, easier than EHCI, no, not easier than xHCI. xHCI has very much simplified the task, period.

If you do study the UHCI and/or OHCI, the two have a distinct difference. One is hardware hungry while the other is software hungry.

However, don't be discouraged. I have been working with USB for more than 20 years, and I still enjoy it and learn something new all the time. It has been my most enjoyable part of this hobby.
Ben

I haven't looked at the USB articles on the wiki in a while, but it might be worth adding a section in that article discussing the differences between the various HCI specifications vs. the USB specifications. Maybe they already do cover this and I've just forgotten.