OSDev.org

This is one of those "Strange behaving hardware that annoys us" threads.

These days I started coding a EHCI driver for Pedigree, in addition to the UHCI driver. I was using VirtualBox to test it. I coded the restart and basic register initialization (0x3f for USBINTR - meaning all interrupts enabled, even if get none - and 1 for CONFIGFLAG). The surprise came when I read the PORTSC registers: all 8 were 0x3000(power on + owned by companion controller). They have that value even if I reset the ports or try to unset the port owner bit. No trick that I've found in linux source(mainly reading from USBCMD register to flush) worked.
In conclusion, I ask for your help, hoping there's someone here who knows about this problem .

Thanks,
eddyb.

Isn't the EHCI controller only supposed to control ports that are connected to USB 2.0 High-speed device?

(Incidentally, does Pedigree have an OHCI controller yet? That would be a lot more useful; one thing I've wondered is why everyone seems to implement UHCI when it's less common...)

Sure, it controls only the ports that work in High-speed mode. But consider that I was doing my tests in VirtualBox, with my webcam connected(also a strange thing: playing with the devices wasn't triggering any IRQ, even if they were all enabled). As for OHCI and UHCI: qemu uses UHCI by default on x86 and all the PCs I have here got UHCIs as companion controllers.

Now I started this driver, I have to finish it . I just wonder why can't hardware behave according to the spec?!

Looking around I've found tatOS. I tried it in VirtualBox, to see how it works. What do you know? It showed 0x3000 for the first 4 ports(it only checks for the first 4).
This makes me think VirtualBox may be the problem. I'll try a linux distro and see how it behaves.

EDIT: DSL works just fine in VirtualBox. I think there's some trick in the linux driver that I haven't noticed yet.

It seems it works in VMware. So this is a VirtualBox-specific problem. I hope someone knows how to make it work in VirtualBox, anyway.

eddyb,

Thanks for trying tatOS. I have tested a couple dozen machines with success and like you found one that refused to show anything but 0x1000 on PORTSC.

When you get this one figured out we will elevate you to the status of USB genius.

Good luck,
TomT

http://code.google.com/p/tatos/

Are you sure you mean 0x1000(Power on)? My problem was the Owner bit being set after I wrote 1 to CONFIGFLAG.
Now I've stumbled across another problem: VMware doesn't set the two lower bits(connected and connect status change) when i connect/disconnect an USB device even if it triggers a port change IRQ.

Btw: in tatOS you don't reset the ports. In VMware(and it's actually what the specs say), you need to do so, in order to get them enabled. And I liked your well-commented code, it's easier to understand if I read the comments rather than the ASM code .

EDIT: I see you reset ports, actually. It wasn't in the file I was looking .

Endless debugging and I still can't get UHCI(yeah, I'm trying to make UHCI "perfect") to send an IRQ in VMware. Changing the USBLEGSUP register in the PCI config space doesn't help(I mainly tried to unset PIRQ enable bit, but simply does nothing). You can guess how EHCI behaves .

Same here, I cannot get VMWare to detect when I connect a device either. It just simply does not set them at all I suppose. I thought VMWare would be a great VM to develop the USB driver on but I suppose the best machine is the real one in this case.

eddyb,

I had a chance to boot my sons laptop over the weekend. This is the one where I cannot detect anything connected on the first 4 ports. This is an HP Pavillion and it has an Intel 82801 ICH9 chipset with (2) EHCI controllers built in.

My initusbcontroller routine currently depends on the bios to find the bus:dev:fun of the device. And so I only detect one ehci controller and further only check 4 ports PORTSC 0-3.

Even though this particular laptop only has 2 usb ports, the ICH9 with two EHCI controllers is wired to support up to 12 PORTSC registers, identified as PORT0->PORT11. Some of the PORTSC registers are connected to ehci-0 and the others are connected to ehci-1, apparently.

Bottom line here is that tatOS needs to be more robust to support a device like this one. Need to be able to check more PORTSC registers, need to be able to access one or the other ehci.

Hope this helps you.

TomT

Did you initialize the EHCI controller before the UHCI controller?

Who, me? I initialize only EHCI if is present.

And did you check for EECP and if you need to negotiate control over the EHCI controller away from the BIOS?

Edit: I would also disable all USB interrupts for now, if your code is only polling for right now, so you can rule out any interrupt-related issues for certain...

Hah, polling? As I want to get a fully working async+interrupt transactions system, that'd be a downgrade . Also, I'm trying now to get rid of BIOS(or whatever is keeping it from sending an IRQ) from UHCI, so I can make it work in VMware.

Isn't Interrupt transactions meant ONLY for HID devices? IIRC, it isn't like the IOC is a hardware interrupt, it is set by the controller and you poll for it to change, am I right?