OSDev.org

Hello again. Well, I still have yet to get USB working. I have completely rewritten my entire experimental code to utilize more precise timing (and to correct some potential errors that I may have previously made).

Since confirming that my BIOS can measure time reasonably well using INT 15 with AH=86, I have been using that exclusively for timing.

Still, I have yet to see the slightest degree of success. I am a little more confident that my initialization steps are correct, but I am still not getting any desirable results.

Earlier today, I made a few discoveries... It seems that the host controller is causing some sort of error every time I tell it to run. Regardless what the first entry in the frame list is, the status register (at base + 2) gets set to 0x0030 just as soon as I set the host controller's least significant bit.

The frame counter (base + 6) indicates an increase of one. So it seems that the host controller is attempting the first entry, causing an error, then halting.

It does not seem to matter what I place in the frame list, nor what I do with the QHs or TDs. The end result is always the same. A process error and a halted host controller.

I have tried with an empty frame list of 1024 entries of 0x00000001. I have tried having each entry point to a QH that contains two 0x00000001s. I have tried having a QH loop infinitely by having it point to itself. I have tried incorporating TDs in various ways.

Basically, I do not think that the problem is the QHs or TDs. I mean, since a frame list full of empty (0x00000001) entries causes the same result.

Is that normal? Is that supposed to happen? A process error occurring when the host controller encounters an entry with its terminate bit set in the frame list (or elsewhere)?

I am sure this is not enough information for you guys to help me resolve this problem, but just to know if a correctly initialized host controller behaves the way I have described above might help to indicate what the general problem might be.

If more information (like code or register values or anything) is need, just let me know!

Hopefully, this thread will not get hijacked like my last one...

Hi, Sounds like your testing in VMWare. If so, then you are probably experiencing a Master Abort. Check the PCI Status Register to see if the Master Abort and Parity bits are set, if so, then your Host System error is due to that. You can build your driver in VMWare up until you need to send a transaction. You will need to begin testing on real hardware for that. Main reason is that you will probably not be able to detect when your drive is connected in VMWare.

What steps are you taking before you send the transaction? How are you linking the TDs, how did you setup the QUEUE? A simple example would be:
That was an example of returning the first 8 bytes of GET_DESCRIPTION. The first control transfer you make after you detect the drive connection.

You should always configure the controller with a dummy TD and QUEUE (The PIIX apparently goes haywire if you don't) and fill the frame list with 1's. When the controller flips to the next frame and sees the 1, it knows then to stop processing the schedule. Next, start the controller and wait for the IRQ or poll for the transaction to complete, check the UHCI STATUS register to make sure your setup worked. Should be 0x20 if OK.

xSMD wrote:Hopefully, this thread will not get hijacked like my last one...

Right, sorry about that. Hopefully my post will help you and make up for it.

I just checked the PCI status register. Its value was 0x0280. So, no aborts or errors or anything. Just one bit indicating that it is fast back-to-back capable and another indicating that the device's DEVSEL timing is medium.

I do not use any sort of emulator. I write directly to a floppy disk, then reboot. Everything I do is on real hardware.

At the moment, I have two QHs. I have every entry in the frame list pointing to the first QH. Both doublewords of that QH point to a second QH, and both doublewords of the second QH point to the first.

No change. The host controller still halts (as indicated by both the status register and the command register) due to a process error (as indicated by the status register). And the frame counter register increments from 0x00 to 0x01.

I do not have the time right now to type up each step that I take when initializing the host controller and the ports. However, I should be able to tonight, perhaps in as few as maybe four or so hours.

It sounds like your linked list is corrupt. I am getting the exact same PCI status 0x280 but no error and I receive the IOC interrupt with no errors. Which makes me believe your linked list is corrupt or maybe your configurations. Please post up your list of what you do to config the PCI and the UHCI before you make your first transaction, then post up your linked list.

First, I write 0x8F00 to the device's legacy register (PCI register C0). I then read the device's command register (PCI register 04), followed by ORing it with 5h and writing the resulting value back to the command register.

So I have attempted to disable SMIs, enable I/O access to the device, and allow the device to be a bus master.

Now, I begin by clearing the host controller status register (at base + 2) with a write of 0xFFFF. I then clear the least significant bit of the host controller command register to halt it.

Once the host controller status register indicates that the host controller has halted (bit 5 set), I reset the host controller by setting bit 1 (and making sure that bit 0 remains cleared, just to be extra safe).

The host controller is supposed to clear bit 1 once it has finished resetting, so I wait for the least two significant bits to be zero.

Next, I set bit 2 for a global reset. After waiting 15 milliseconds (1.5 times the minimum amount/duration required), I clear the three least significant bits (again, ensuring that bit 0 remains cleared, as well as bit 1, just to be safe).

Then, I set bits 4 and 3. I am uncertain about the necessity of this, but Intel's UHCI 1.1 document mentions clearing bit 3 when bit 4 is cleared (or afterwards). So, I have been setting them together, then clearing them together.

Following a 30 millisecond delay (again, 1.5 times the minimum), I completely clear the host controller command register. Once I confirm that the register is 0x0000, I continue.

Now, I clear the interrupt register (at base + 4) and the frame number register (at base + 6). I set the frame list base address via the register at base + 8.

I have checked what BIOS sets the frame modify register (base + C) to. It turns out to be the default of 0x40 on this computer. So, it is at this point that I ensure that this register is set to that value (though it should be following the resets).

To reset the ports, I write 0x020A to both. After confirming that bit 9 (the reset bit) has been set, I wait. Earlier, I was waiting for 10 milliseconds (actually, 1.5 times that, just to be safe). I have since increased the wait to 75 milliseconds (the USB 1.1 specification mentions something about 50 milliseconds, though I cannot remember to what exact cases that applies). Regardless, my delay should more than cover me.

After the delay, I clear the reset bit by writing 0x000A. To be certain that the bit becomes cleared, I loop until it is. Then, I wait for another 75 milliseconds. (Uncertain about how important the timing of things is, I do not want anything stupid like insufficient waiting to interfere with my results.)

Now, I write 0x000F to the port at the front of my desktop computer's case. (I have something plugged into it.) After testing that the enable bit has been set, I continue.

After clearing the host controller status register again (0xFFFF, just to be safe), I set the host controller command register's least significant bit.

A read of the host controller status register will now yield 0x0030, indicating that a process error has occurred and that the host controller has been halted as a result.

At the moment, my frame list contains 0x00007D62 for all 1024 entries. At that address, this QH exists: 0x00007DA200007DA2. At that address, this QH exists: 0x00007D6200007D62. So they infinitely point to one another.

Of course, on my floppy disk, all values have be written as little-endian. So each entry in the frame list actually looks like this on the disk: A2 7D 00 00. I am very used to writing values in little-endian.

so, you haven't setup any transfer descriptors?

If your just trying to setup the "dummy" descriptor you should write a 1 to the td.link pointer then point qh.v at that td, and write 1 to qh.h.

write all 1's to frame list after you write it to FRAME_ADDR, then point fl[0] at qh.v, then wait for the transaction to complete.

If you become bus master, you will have more to worry about (timing) so keep it off for now.

BIOS was setting the bus master bit. However, I am now writing 0x0001 to the PCI command register, thereby clearing that bit and only setting the one to enable I/O access.

Doing so has corrected the problem with the host controller halting due to a process error. However, it still does not appear to be processing anything. The frame counter never increments, TDs (even isochronous ones) never get marked inactive...

The host controller status register remains 0x0000, and the host controller command register is 0x0001. So, it looks like it should be working. But nothing seems to be happening.

As a bus master, the status of the TDs were always marked as 0x85 (active and CRC/time-out error). Now, there is no change. They remain 0x80.

Well, we are at the exact same place at this point. I'll let you know if I come up with a solution. Just make sure your alignment, timing, is correct, and all addresses are physical and accessible. Fix your TDs. Good luck.

Hmm... Do you(both of you) test your code in a virtual machine or real hardware? If a virtual machine, which? I'm still yet to find a solution to my problems in VMware, but in Qemu, it works perfectly...

I test exclusively on real hardware. However, I think Neato uses VMware or something like that.

Hey, Neato, I might be on the trail of a solution. By setting the UHCI device as the only bus master (therefore, by clearing bit 2 of all other devices and setting it only for the UHCI device), I can get the host controller to seemingly function. No more process errors. The frame number register appears to increment as it should.

I am not sure if this is a real solution or just a side-step of an underlying problem. However, for the time being, I am doing it.

Could someone who has USB working let me know if setting the UHCI as the only bus master is truly necessary? Or, is it just by chance that doing so alleviated my process error problem? I mean, is this what you guys (and professional operating systems) do? Is it the only way?

Now, I am finding new problems. Three of them, to be exact. My TDs are causing data buffer errors, bitstuff errors, and the detection of babble. And I am not sure why.

Contrary to how I interpret the UHCI 1.1 documentation, the stall bit in the status byte of each TD is never being set. Just the three mentioned above, and bit 16 (it is reserved and varies between being set and cleared).

I do not know if the cleared state of the stall bit helps to pinpoint the problem or not. Does it? Is it a clue?

Great! I hope you get it working soon.

I am currently re-writing my driver, starting with PCI. I am just going through each line, one by one and checking the status, making sure my writes are working. Really investigating every possibility until it works. I think we may find every wrong way to do it before we finally find the right way, unfortunately. lol

I'll keep you posted if I come up with something.

If IIRC, stall is only set during setup and only if a CRC is issued. You don't have a CRC/Time Out Error, you have the Data Buffer Error, Babbling, and Bitstuff bits set, which means your driver hasn't setup the transaction pipe correctly; the device can't speak to you, so it returns all FFh and then has a seizure. Post up your TDs and QH (if using queues).