OSDev.org

Hey guys,

I've been working on my UHCI controller code, and I've got it mostly working, but there are a few weird issues when running in VMWare. I did a forum search and found one thread that sounds exactly like my issue here: http://forum.osdev.org/viewtopic.php?f=1&t=21703

That thread ended with no real resolution that I could find.

My first issue is that the frame counter is incrementing about once per second, instead of once per millisecond like the specs say. Everything seems to work, just very slowly. It may take 1-2 seconds before I get a response from the device.

Second, I can only seem to get one TD worth of data from the device. If I set the controller to 64-bytes max payload, I can get 64 bytes from the device in a single TD, but if I chain another TD after it, I get a STALL and CRC error. I've tried toggling the data toggle bit and leaving it the same, and I get the same results.

Specifically, I can do a GET_DESCRIPTOR with one SETUP TD, one IN TD and one Result TD. But if I request more than 32 or 64 bytes, and chain another IN TD, the second IN TD fails with its STALL and CRC error flags set, and no bytes transferred (0x7ff).

I assume these two issues are related, but they could be completely separate. Has anyone figured these issues out yet?

I've tried Windows XP and Arch Linux with the same configuration, and they seem to work fine, so it has to be something in the PCI or UHCI host controller configuration.

Thanks, guys.

Just like the forum post that I linked to above, running the same code in QEMU runs the frame index counter much faster, but my communication doesn't appear to be working, so I'll start troubleshooting in QEMU.

But, in the meantime, here is a VMWare log.

SpyderTL wrote:Just like the forum post that I linked to above, running the same code in QEMU runs the frame index counter much faster, but my communication doesn't appear to be working, so I'll start troubleshooting in QEMU.

But, in the meantime, here is a VMWare log.

This is just a couple of shots in the dark, but you might try them.

1. (as I am sure you know) Each frame has an elapsed time of ~1mS with 1024 frames. This means that each frame will be processed once a second. If you place a packet (multiple QH's and TD's) in only one frame and have the Depth/Breadth bit set for Breadth, the controller may move on to the next frame (at time of interval) and will not come back to the next TD in this frame for approximately 1 second. This can give an impression of a very slow response time. Could it be that VMWare is strict (and presumably correct) on this and will not come back to this frame until a 1 second elapsed time? Where as other emulations are not so strict? (Hope not, since the Bochs emulation should be correct).

2. Could VMWare be suspending the port and you need to resume the port? I admit, I did (and have done) little work on suspend/resume. It is on my list of additions for another edition.

Well, at the moment, I can only think of those two. Check the Depth/Breadth bit of your TD's. If this bit is set for Breadth, the controller (VMWare emulation) will move to the next item within the Queue Head. If this pointer has the T bit set, it will stop execution and wait for SOF. If you have no other frames used, it will be a second (literally) until it comes back to this one. If you are requesting the 18-byte Device Descriptor, which you know may have up to five TD's, this could mean that it would be five seconds before your descriptor is successfully received.

Hope this helps,
Ben

The Frame Index register is only updating around once a second. So I can dump it to screen and it will be the same frame index for about a second, and then it will increment by one. My understanding is that this should increment by around 1000 a second. I'm just guessing that my slow response is related, but I could be wrong.

If it makes any sense for you for troubleshooting, I'm running vmware ESXi. If you had an image, I would be willing to test on my end for you and report the result. PM me if you have any interest.