OSDev.org

bigbob wrote:I have managed to communicate with USB devices thanks to the book "Benjamin David Lunt - USB: The Universal Serial Bus" and the code of PrettyOS (e.g. I use the code of PrettyOS to disable Legacy Support(BIOS), because Lunt's code didn't work on an old computer).
It seems that just an EHCI driver is enough for those who only need (high-speed) mass-storage-devices for their OSs. Even after succesfully disabling the Legacy Support for the EHCI controller, my USB-keyboard remains functioning(without a USB-keyboard driver) probably because UHCI or OHCI controller handles low- and full speed devices. This means that the legacy keyboard driver (I use the one from Brokenthorn) works and there is no need to write UHCI or OHCI USB-keyboard driver. My OS uses no mouse, but I suspect that the situation is the same in case of a mouse too.
For me, it took some time to realize which direction the PID of the Status-TD should have (it is not that clear in Lunt's book):
PID is IN(01b), if there are no data-TDs (as in SetAddress-request) or if there are data-OUT TDs. Otherwise PID is OUT(00b).

Here (at the end of the webpage) there is the USBTest.zip that retrieves the Device Descriptors of devices on EHCI, UHCI or OHCI.
It is written in assembly and in case of an error, the queue and the TDs(Transfer Descriptors) along with the request- and return buffers get printed on the screen. I tested it on two computers with EHCI and UHCI controllers. It's not a big deal but it can help, if you are an assembly programmer.
https://sites.google.com/site/forthoperatingsystem/

Of course, if you have a computer with xHCI (super-speed; that handles all-speed devices), then this post is not for you.

EDIT:
The USB-keyboard remains functioning on a desktop computer, but on a Netbook only the built-in keyboard works and the external USB-keyboard doesn't work.

muazzam wrote: Thanks a lot for help!. I want to write USB mass storage drivers, I read echi specification but it can only describe register 0, 1, 2.. not actual registers ports. How can I get start with programming USB mass storage?. (and also I am assembly language programmer.).

DavidCooper wrote:I've been reading through the same book over the last few months to try to get the full picture of how USB works. I originally read the USB2 specification and was left thinking it was a horrific task that would take years just to understand (all that stuff about ruddy pipes drove me right up the wall), but now I've gone back to it and searched for simple things like "queue head" and "transcriptor", and it turns out that the USB2 specification simply doesn't mention them at all - the very things the OS developer most needs to know simply aren't in it! The trick is to look to the UHCI, OHCI, EHCI and XHCI specifications instead, as well as using Lunt's book to slash the time it takes to understand how to get going.
...
If it turns out that the keyboard and touchpad are connected through EHCI, it would suggest that they are either USB2 devices (which Lunt's book says is unlikely), or they are USB1 devices connected to an internal USB2 hub, which I think might allow them to be handled by the EHCI controller instead of being being passed to a companion controller. Does anyone know if that's how it works? I haven't managed to work that out yet, so it may not be the case, but if it is, it would allow you to postpone the development of your UHCI and OHCI drivers indefinitely and just tell users to plug any USB1 devices into a USB2 hub instead of to a root port, the only downside being that your OS wouldn't do very much on older machines which lack USB2.

DavidCooper wrote:The trick is to look to the UHCI, OHCI, EHCI and XHCI specifications instead, as well as using Lunt's book to slash the time it takes to understand how to get going.

DavidCooper wrote:If it turns out that the keyboard and touchpad are connected through EHCI, it would suggest that they are either USB2 devices (which Lunt's book says is unlikely), or they are USB1 devices connected to an internal USB2 hub, which I think might allow them to be handled by the EHCI controller instead of being being passed to a companion controller. Does anyone know if that's how it works? I haven't managed to work that out yet, so it may not be the case, but if it is, it would allow you to postpone the development of your UHCI and OHCI drivers indefinitely and just tell users to plug any USB1 devices into a USB2 hub instead of to a root port, the only downside being that your OS wouldn't do very much on older machines which lack USB2.

muazzam wrote:

bigbob wrote:I have managed to communicate with USB devices thanks to the book "Benjamin David Lunt - USB: The Universal Serial Bus" and the code of PrettyOS (e.g. I use the code of PrettyOS to disable Legacy Support(BIOS), because Lunt's code didn't work on an old computer).
It seems that just an EHCI driver is enough for those who only need (high-speed) mass-storage-devices for their OSs. Even after succesfully disabling the Legacy Support for the EHCI controller, my USB-keyboard remains functioning(without a USB-keyboard driver) probably because UHCI or OHCI controller handles low- and full speed devices. This means that the legacy keyboard driver (I use the one from Brokenthorn) works and there is no need to write UHCI or OHCI USB-keyboard driver. My OS uses no mouse, but I suspect that the situation is the same in case of a mouse too.
For me, it took some time to realize which direction the PID of the Status-TD should have (it is not that clear in Lunt's book):
PID is IN(01b), if there are no data-TDs (as in SetAddress-request) or if there are data-OUT TDs. Otherwise PID is OUT(00b).

Here (at the end of the webpage) there is the USBTest.zip that retrieves the Device Descriptors of devices on EHCI, UHCI or OHCI.
It is written in assembly and in case of an error, the queue and the TDs(Transfer Descriptors) along with the request- and return buffers get printed on the screen. I tested it on two computers with EHCI and UHCI controllers. It's not a big deal but it can help, if you are an assembly programmer.
https://sites.google.com/site/forthoperatingsystem/

Of course, if you have a computer with xHCI (super-speed; that handles all-speed devices), then this post is not for you.

EDIT:
The USB-keyboard remains functioning on a desktop computer, but on a Netbook only the built-in keyboard works and the external USB-keyboard doesn't work.

Thanks a lot for help!. I want to write USB mass storage drivers, I read echi specification but it can only describe register 0, 1, 2.. not actual registers ports. How can I get start with programming USB mass storage?. (and also I am assembly language programmer.).

iocoder wrote: You need to get (or configure) the base address through PCI configuration space for the controller.

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

bigbob wrote:

muazzam wrote:[
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.

muazzam wrote: So, Is PCI is used to detect hardware?

for(bus 0 to 255)
	for(device 0 to 32)	// device is also called slot
		for(function 0 to 8)
     {
			vID = readPCIWord(bus, device, function, VendorID)	// VendorID is an offset in the PCI-config space
			if (vID==0xFFFF) // no device
				continue
			else
			{
				cc == readPCIByte(bus, device, function, ClassCode)	// Classcode is an offset too
				sc == readPCIByte(bus, device, function, SubClass)	// SubClasscode is an offset too
				if (cc != 0x0C and sc != 0x03)	// USB-controllers have 0x0C as classcode and 0x03 as SubClasscode
					continue
				else
				{
					print("USB-controller found at", bus, device, function)
				}
			}
      }