USB Help

[iocoder]

[
Can you explain what is PCI? (in simple words). Why do I need PCI?. How to configure PCI? etc.

PCI is a bus, controllers (e.g. IDE, USB, stb) are connected to it.
So, if you want to have USB, then you need to "talk" to the USB-controllers via the PCI-bus (get BASE address, etc)
In my opinion these links are good:
http://wiki.osdev.org/PCI
http://en.wikipedia.org/wiki/PCI_configuration_space

EDIT:
The output of the lspci command from linux explains a lot:
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller
00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 02)
00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02)
01:00.0 Ethernet controller: Atheros Communications Inc. AR8132 Fast Ethernet (rev c0)
02:00.0 Network controller: Atheros Communications Inc. AR2427 802.11bg Wireless Network Adapter (PCI-Express) (rev 01)

e.g. the EHCI controller is on 00:1d.7 (BUS:DEVICE.FUNCTION). This is what your OS should also do: find the device you would like to communicate with on the PCI-bus, because if you know its address (bus:device.function), you can do that.

So, Is PCI is used to detect hardware?

Lemme note that hardware detection is not the *main* use of PCI. As other friends have explained, PCI is the standard local bus of modern computer systems. Local bus is that beautiful bus that allows you to attach hardware devices to your computer. That's it, the main job of PCI is to connect hardware devices to your processor. By logic, if you are a processor and want to know what hardware devices are attached to the computer you live in, you should ask PCI. Also, if you want to contact those devices, you can do this through PCI (I don't think that CPUs and hardware devices know about "telepathy").

[Combuster]

PCI is certainly used to detect hardware. Since the electronics force unique device numbers for each device, and each device has to give you its ID, you can locate all such devices with minimal search effort. This is one of the key advantages over it's predecessor, the ISA bus which could not tell you which devices existed, and neither could it make sure that two devices would not be conflicting with each other.

You don't have to configure the bus itself though. The BIOS does that for you by checking each device and giving each one an unused range of addresses in the CPU's address space. It also makes sure that the chipset sends all accesses to those addresses onto the PCI bus, instead of any other buses the system might have. Because the PCI bus is located deep down after a number of other buses that route traffic, it also means that you can't lightly change any of these settings without making things unreachable.

Therefore as far as most starting OS developers are concerned, hardware detection is the only thing you do specifically with the PCI bus.


On the subject of USB, you will need to at least read these settings to find out which devices live in the PCI space, and to find which physical memory addresses they have been given. You can then check if any of them support an USB interface, and if so, you have just gathered all the information you need to access the USB bus on that particular machine.

[DavidCooper]

I was being overly pessimistic before in assuming I'd lose keyboard when taking control of the EHCI controller. I've now done some experiments and can see that in my netbook the keyboard and trackpad must be wired in by a mechanism such as PS/2 without going through USB at all. Here are those experiments:-

Step 1: set the stop bit to 0 for the EHCI controller. Result: flash drive access via BIOS ceased to function, but keyboard and trackpad continued fine.

Step 2: reset the EHCI controller. Result: keyboard and trackpad continued to function.

Step 3: reboot computer and then plug in a USB keyboard (having never plugged one into this machine before, or at least not while the BIOS has control of it). Result: BIOS immediately set up all four UHCI companion controllers (which were previously not used) and used the first one to access this keyboard.

Step 4: stop and reset the EHCI controller. Result: USB keyboard continued to function.

Step 5: stop the first UHCI controller. Result: USB keyboard stopped functioning. Built-in keyboard and trackpad continued to function.

Step 6: reboot machine and check controllers again. Result: discover that the BIOS has set up all four UHCI controllers without waiting for a USB keyboard to be plugged in, so it has changed some setting somewhere and will likely do this every time from now on.

Conclusion: there's a reasonable chance that a netbook/laptop will still give you keyboard access via the BIOS after you've started tampering with the USB controllers, so you can hack them without having to reboot after every little experiment.

It occurs to me though that if anyone tries to do this work on a machine which lacks PS/2 and they're relying on a USB keyboard instead, it may keep running after they've reset the EHCI controller, but it will have been given a USB address by the BIOS which is known only to the BIOS, so when allocating addresses to other devices, it may be best to start at a number like 64 to avoid conflict if you are planning to leave the BIOS in control of keyboard input, unless the BIOS writers have anticipated this problem and have given the USB keyboard a high number already... But then I may have misunderstood how things work and there may be no such problem: if the companion controllers know nothing of each other's existence and nothing of the EHCI controller, the software in charge of them could be independent too for each, in which case they could assign the same addresses to different devices. The big question is, is each of these controllers allowed to address 127 devices or is it 127 devices in total for all of them collectively, including the EHCI controller they are connected to?

One more issue: Lunt's book mentions ways of taking control of USB controllers away from the BIOS, but I can't find any place where he explains it for EHCI, (though it's hard to tell when working with the ebook version as it's so difficult to navigate around it - get the version printed on paper if you can afford it). In the EHCI specification there is a bit about a register where this can be done (EECP+0h). The second byte in HCCPARAMS gives an offset in the PCI config. space where EECP can be found, and the BIOS can be told to hand over control by setting bit 24 of the dword there and waiting for bit 16 to become 0. I haven't tried doing that yet as I read the wrong byte in HCCPARAMS by mistake and found a zero in it. I don't think it would change any of the results of the experiments at the top of this post though.

[Brendan]

Hi,

It occurs to me though that if anyone tries to do this work on a machine which lacks PS/2 and they're relying on a USB keyboard instead, it may keep running after they've reset the EHCI controller, but it will have been given a USB address by the BIOS which is known only to the BIOS, so when allocating addresses to other devices, it may be best to start at a number like 64 to avoid conflict if you are planning to leave the BIOS in control of keyboard input, unless the BIOS writers have anticipated this problem and have given the USB keyboard a high number already...

Either the OS supports the USB host controller (and therefore disables the legacy BIOS mess, initialises the controller, enumerates USB devices, and uses its own USB keyboard driver if a USB keyboard is present); or the OS doesn't support the USB host controller (and therefore continues using the legacy BIOS mess). There are no other sane options; so you never have to care if resetting the EHCI controller effects the legacy BIOS mess (because you would've disabled the legacy BIOS mess before you reset the EHCI controller), and never have to care what USB address the BIOS might have used for the keyboard.

But then I may have misunderstood how things work and there may be no such problem: if the companion controllers know nothing of each other's existence and nothing of the EHCI controller, the software in charge of them could be independent too for each, in which case they could assign the same addresses to different devices. The big question is, is each of these controllers allowed to address 127 devices or is it 127 devices in total for all of them collectively, including the EHCI controller they are connected to?

Think if it like a little electronic switch that connects the device to one controller or the other *before* an address can be assigned to the device. Each of the controllers are allowed to address 127 devices.


Cheers,

Brendan

[DavidCooper]

Hi Brendan.

Either the OS supports the USB host controller (and therefore disables the legacy BIOS mess, initialises the controller, enumerates USB devices, and uses its own USB keyboard driver if a USB keyboard is present); or the OS doesn't support the USB host controller (and therefore continues using the legacy BIOS mess). There are no other sane options; so you never have to care if resetting the EHCI controller effects the legacy BIOS mess (because you would've disabled the legacy BIOS mess before you reset the EHCI controller), and never have to care what USB address the BIOS might have used for the keyboard.

Agreed - you don't want to go on relying on the BIOS collecting USB keyboard input for you once you've started using the EHCI controller for other things, and you certainly don't want to distribute such a mess of an OS to other users, but while you are developing your USB drivers, you might (in an extreme case where there's no PS/2 keyboard on your machine and you have a pathological dislike of working on emulators), just might try to get away with using one USB keyboard for input under the control of the BIOS while you develop your own driver for another USB keyboard through a different UHCI controller (plugging several USB1 devices into the machine to push the keyboards onto different controllers). It may not work if the BIOS tries to interfere with the controller you take over, but it may be an option worth exploring for some unfortunate bugger who's stuck in that position with no other machine available to work on. Once they've got their own USB keyboard driver working, then they can ditch the BIOS and do things properly.

Think if it like a little electronic switch that connects the device to one controller or the other *before* an address can be assigned to the device. Each of the controllers are allowed to address 127 devices.

Thanks for clearing that up for me and possibly preventing a nasty accident.

I think I remember you mentioning a while back that there's a BIOS call that can be made to switch off all legacy support, but I've never managed to find it. I'm guessing that does the job of letting go of the USB controllers, but is it likely to cause other problems at the same time as it pulls out rugs from under other things?

[djmauretto]

Step 1: set the stop bit to 0 for the EHCI controller. Result: flash drive access via BIOS ceased to function, but keyboard and trackpad continued fine.

Step 2: reset the EHCI controller. Result: keyboard and trackpad continued to function.

Step 5: stop the first UHCI controller. Result: USB keyboard stopped functioning. Built-in keyboard and trackpad continued to function.

Netbook,Laptop and so on, use the EC for Built-in keyboard and trackpad.

EC = embedded controller