[SOLVED] UHCI Error: PORTSC LINE STATUS

[prajwal]

Hello,

I have written an UHCI Host controller driver with support for Mass bulk storage only.
When I run this under Qemu, it works totally fine.
Under the real hardware, I have the following problem:-

Initially, the port status (PORTSC) is 0x97.
After Host reset, it is 0x93
Now when I do PortReset it becomes 0x95
After this the UHCI Controller Status reads as 0x20 -> indicating that the controller has stopped/halted (though I have stared it before port reset)

To check, I restarted the controller after port reset and when I send any GetDesc or SetAddress request they all fail because the controller status = 0x20 again -> indicating that the host controller is halted.

On Qemu, the port status is initially 0x83, then after port reset it becomes 0x85.

Why is the Line Status bit 4 set on real hardware ?

More Details:
On the real hardware I see 4 UHCI Controllers, 1 EHCI Controller
PCI details for UHCI Controllers:- Bus: 0, Device: 29 and Function = 1,2,3,4 respectively
I see that Port Status is 0x80 on Function 1,2,3 and it is 0x93 on Functon 4
I have disabled Legacy and SMI by writting 0 to LEGSUP PCI registry for Function 4 where I find the device status as attached (i.e 0x93) . Though the UCHI doc mentions LEGSUP is for function 2 which I do not understand well

Please help...

Thanks,
- MoMan

[prajwal]

Ok. After going thru another post "UHCI Host Controller Error?" by xSMD I set 0x0001 to PCI Command Registry i.e, Earlier it was set as Bus Master which I now removed.

Now, I see that the port status is 0x85 after port reset and the host controller status is 0x0. But the frames are not getting processed. Frame counter is not moving.
Same state where the other post is

[XanClic]

Ok. After going thru another post "UHCI Host Controller Error?" by xSMD I set 0x0001 to PCI Command Registry i.e, Earlier it was set as Bus Master which I now removed.

Bus master capability is enabled via 0x0004.

[prajwal]

To clarify again:-

When I enable Bus Master capability by setting 0x4 + IO which is 0x1 ==> 0x0005 into PCI command registry, I get the initial error which is Port Status = 0x95 and the host controller status = 0x20 indicating it has halted.

When I just set IO which is 0x1 into PCI command registry I see that port status = 0x85 (which is good), and the Host Controller status = 0x00 ( good ) and not halted. BUT the frame counter doesn't move, nothing gets processed from the frame

[Gigasoft]

I think it needs the Bus Master bit set to do any data transfers, so when it's not set it just stalls. Are the frame addresses aligned?

[prajwal]

Agree. But I see that when I read back the value from PCI registry for LEGSUP is still having LEGSUP and SMI enabled though I have written values to disable LEGSUP and SMI into PCI LEGSUP registry !

Any idea why my writes to PCI registry for LEGSUP could be failing ?

[osdnlo]

Based on your descriptions, it sounds like you are a little confused. Your problems could come from a wide variety of issues. Some registers require writes of 1 where some do not in order to clear a bit. When the HC is halted alone, that does not mean an error has occurred. You will need to check the status dword of your TDs for TD errors. Your controller didn't report any errors, and neither did the port status. I don't know why you are starting the controller to run before you reset it. That is like starting your car, shutting it off, then starting it again. You have too many starts there. What is you current status so far?

[prajwal]

not sure if little or confused too much Sorry for long writeup but please bear and help me on this.

I am resetting the controller first. GC Reset, HC Reset and others as per UHCI document

I am able to clear LEGSUP reg with value 0 now indicating that SMI and Legacy support is disabled

I can see 4 UHCI PCI entries and 1 EHCI PCI entry

The Port status (PORTSC REG) for first 3 UHCI PCI device is 0x80 indicating no device is attached

The Port status (PORTSC REG) of the 4ht UHCI PCI device is 0x97. 0x9X indicates that there is a line/bus error.

I am reading this PORTSC before resetting and starting the controller

After Resetting and Starting the controller the PORTSC value changes to 0x95 inficating that Device is connected and Port enabled but there is still a line error/bus error. But the Host Controller Status (USBSTS) is 0x20 indication host controller is halted.

The Host controller status remains 0x00 for around 50 ms after Starting but turns 0x20 then.

There is no point in checking TDs and QHs as non of them are processed

In addition, all 4 UCHI PCI device PCI_COMMAND register value = 0x5 indicating it has Bus master enabled and IO enabled

I have not written EHCI driver to see what's on EHCI PCI entry. Could this problem be something related with EHCI ?

In addition, when I disable 4th UHCI PCI entry as Bus Master, I see that Host Controller status remains 0x00 after starting and PORTSC value is 0x85 but non of the TDs/QHs get processed. Frame counter is not moving

I am really lost at this point. Any help is very much appreciated

Thanks very much,
- MosMan

[osdnlo]

If you aren't reseting the ports and then enabling them after your GRESET then your transaction will be ignored because the port is disabled. Reset the port and enable it, then start the HC. Read the td status anyway, see if it changes.

[osdnlo]

I don't think you should spend too much time worrying about Bus Master. If you look at your devices using something like PCI32 for Windows or do whatever you do for linux to see the PCI devices, you will notice that each UHCI and maybe the EHCI and maybe all functions are Bus Master by default, possibly made that way by the BIOS. You shouldn't even need to set the Bus Master. From my tests, I noticed the same results that you mentioned caused by malformed link pointers. Thus, I am afraid that for further assistance, you will need to post up your code because I think your issue warrants it considering that you aren't returning any errors because your TDs aren't being changed, frame num stays 0, etc. This tells me that your packets are broken and that's a code issue.

[pcmattman]

If you look at your devices using something like PCI32 for Windows or do whatever you do for linux to see the PCI devices, you will notice that each UHCI and maybe the EHCI and maybe all functions are Bus Master by default, possibly made that way by the BIOS.

And what happens if the BIOS sets them up without bus master on? What if it does something incorrectly, leaving the device in an unknown state?

These questions are the reason why you make certain your driver ensures bus master is enabled (and the device is setup right), so you aren't leaving anything to chance.

[osdnlo]

If you want, then make a check for it, but don't assume it's always off and don't think that you need to disable Bus Master on other controllers in order to make your code work.

[XanClic]

If the current discussion is just about "bus master or not"... My UHCI driver seems to work for now (does device enumeration only) and I know it only works when I set the bus master flag. If I disable it, the device doesn't work.

[prajwal]

Ok... I agree the Bus Master is already enabled. Let me not worry about that. But the real problem is the momemt I start Host Controller it is stopping with USBSTS registry value = 0x20 indicating that HC Halted. I did try to reset PORTSC even before GRESET but no luck

Host Controller simply stops immediately after I start it. The PORTSC status reads as 0x97, USBSTS reads as 0x20

How to know the cause for Host Controller Halt condition ? What could be wrong ?

Just a note again: It works fine with QEMU !!

[osdnlo]

Hi mosman. Looks like the port is getting disabled after you start the schedule. Why not post up some code, it would be a lot easier to debug your routine if we can actually see it. It most likely is a CRC/Time Out error causing the problem with your TDs. Have you tried to read the td.status fields yet? Even if the schedule is rejected, at least the TD that caused it will change to reflect the error.