[SOLVED] UHCI Error: PORTSC LINE STATUS

[prajwal]

osdnlo, Thanks for looking into this. I appreciate that source code will be really helpful to debug here. Currently I do not have access to my source code as I am away from Home. I will post the relevant piece by tomorrow.

b/w When I start the Host Controller, it basically points to Frame List which has all it's pointers set to "1" indication there are no TDs/QHs to process
So, question of checking TD status doesn't come into picture here. Before I could setup any TD/QH I see that the Host Controller Status is 0x20 indicating it has halted. If I ignore that (which may not make sense because Status reg is clearly saying HC is halted!!) and continue to setup a TD nothing gets processed and the TD is untouched including status part everything remains same as is.

Thanks again,
- MosMan

[osdnlo]

The controller issues a Halt when it has finished all transactions or if there is an error, and you don't have any errors (that you know of). If you fill the frame list with invalid pointers (i.e., 0x00000001), then you essentially told the controller that nothing is there to process, so stop. You need to put a pointer to your queue head in a frame, set the frame number to that frame, then start the controller. Basically, the controller just sits there waiting for you to start it and you would only do so after you have given it a schedule to follow, never before.

[osdnlo]

I just found this out. If you can use vmware and if you add these lines to your .vmx file:

monitor = "debug"
usb.analyzer.enable = TRUE
usb.analyzer.maxLine = 8192
mouse.vusb.enable = FALSE

You will get debug information regarding the USB. It will be placed in vmware.log in whatever folder vmware starts from. This also works for the free player. It will hex dump the packets and will also show you what commands you have issued and how the controller reacted to it.

[prajwal]

It was a very annoying typo in my code where by mistake I was setting the Software Debug Bit in the CMD Registry which was causing the HC to Halt.
Good news is I am able to start and run the UHCI Controller

As mentioned earlier, out of 4 UHCI PCI entries, the 4th one shows that the device is attached on it (PORTSC value 0x97) and now after reading the device details it is BCM2045 BroadCom Corp device (BlueTooth ?). Now where is the usb pen drive from which I booted my OS ?? Any idea why I am not able to see that device ?

Note: The first three UHCI PCI Device entries show the PORTSC values as 0x80 even after Port Reset.

Also, thanks very much for the help so far

Best Regards,
- MosMan

[jal]

Now where is the usb pen drive from which I booted my OS ?? Any idea why I am not able to see that device?

Is it still on emulation?


JAL

[osdnlo]

Hi mosman. Great job finding the bug. Setting the SWDBG bit will certainly give you those results. Which UHCI controller are you booting from, the 4th? You never mentioned whether or not a device was actually attached in the 4th controller? How are you booting from USB if you cannot find the device attached to any visible controllers? Or can you and then it disappears? Are you still working in an emulated environment?

[prajwal]

Hi, this is on real hardware. I am able to boot from pen drive because I am using GRUB boot loader. I set the boot device in my bios as USB and then I get the Grub prompt.
From there I boot my kernel. not sure if grub is using some bios interrupts to get the job done ! But once my kernel is loaded, control is completely in my kernel.

As mentioned earlier;-
I see 4 UHCI PCI entries and 1 EHCI PCI Entry
I see the device attached on 4th UHCI port (0x95) which I now know that it is BCM2045 which definitely is not pen drive. other 3 UHCI ports show 0x80 -> no device attached.
I do not have EHCI support yet

Thanks,
- MosMan

[osdnlo]

Oh, I see what your asking now. You booted from USB and when you read the status of the 4 controllers, only one shows a connection while the other three do not, and you wonder why the usb pen is not showing connected. Should there be two devices connected? Are you saying that your pen drive is identifying itself incorrectly, even falsely? You keep talking about two devices, yet I am under the assumption that there should be only one. Do you know which controller and port you plug the usb pen drive in? Is it the 4th controller or is that where you plug the other device?

[eddyb]

Hi, this is on real hardware. I am able to boot from pen drive because I am using GRUB boot loader. I set the boot device in my bios as USB and then I get the Grub prompt.
From there I boot my kernel. not sure if grub is using some bios interrupts to get the job done ! But once my kernel is loaded, control is completely in my kernel.

As mentioned earlier;-
I see 4 UHCI PCI entries and 1 EHCI PCI Entry
I see the device attached on 4th UHCI port (0x95) which I now know that it is BCM2045 which definitely is not pen drive. other 3 UHCI ports show 0x80 -> no device attached.
I do not have EHCI support yet

Thanks,
- MosMan

Supposing your usb pen drive is High speed, it will be handled via EHCI. I am not sure about this, but it can be that the EHCI is used by BIOS and it took over the ports. In this case, you must do BIOS handoff(to make it unable to touch EHCI again) and unset configure bit(which changes ports' owner to UHCI).

First of all, can you post the value of the HCCPARAMS register(it's a 32bits register, with offset 8 in the EHCI MMIO)? If the bits 8-15 aren't all 0, then you can do this handoff operation.

[osdnlo]

Supposing your usb pen drive is High speed, it will be handled via EHCI.

Sorry, we are talking about UHCI. He can use a Full-Speed device on a UHCI controller.

[eddyb]

Supposing your usb pen drive is High speed, it will be handled via EHCI.

Sorry, we are talking about UHCI. He can use a Full-Speed device on a UHCI controller.

And I was saying BIOS can use EHCI and make it own all High-Speed devices. Then you have to get that device back, if you want to use UHCI, see?

[prajwal]

osdnlo, I think the device I am seeing on 4th UCHI is the right one. It is a USB bluetooth device which is internally (I mean not thru an external usb socket) connected on UCHI port. Because I do have a Bluttooth BCM2045 installed in my laptop and i see that it is an USB device from the device and driver manager details of windows os

eddyb, ok. This could be a case which I definitely want to give a try. I will do some research on EHCI and particularly about HCCPARAMS and Handoff technique and let know the details soon...

PS: worst I would require to write an EHCI controller driver ! actually it's a good thing though

Thanks a lot for you both.

Regards,
- MosMan

[eddyb]

osdnlo, I think the device I am seeing on 4th UCHI is the right one. It is a USB bluetooth device which is internally (I mean not thru an external usb socket) connected on UCHI port. Because I do have a Bluttooth BCM2045 installed in my laptop and i see that it is an USB device from the device and driver manager details of windows os

eddyb, ok. This could be a case which I definitely want to give a try. I will do some research on EHCI and particularly about HCCPARAMS and Handoff technique and let know the details soon...

PS: worst I would require to write an EHCI controller driver ! actually it's a good thing though

Thanks a lot for you both.

Regards,
- MosMan

I said that about HCCPARAMS to be sure if that EHCI of yours has extended capabilities(the most common is BIOS handoff). Bits 8 to 15 represent EECP(EHCI Extended Capabilities Pointer), an offset in the PCI config space. You could also try to unset Configure Flag bit(it's the one responsible with the port owning) without doing BIOS handoff(the only inconvenient would be that BIOS could try to access EHCI again, but it's improbable).

[osdnlo]

Hi eddyb. I guess I missed that one in the spec. I'm sorry if I am wrong, but it doesn't even make sense as a theory. If I have 4 UHCI controllers in my machine, and then install an EHCI controller too, you're saying that the BIOS will deny the usage of Full-Speed devices via any of my UHCI controllers all of a sudden? So you're saying, if I plug a Full-Speed device in a UHCI port, the BIOS will stop the transaction and prohibit the transfer of data? Why? How does the BIOS do it? Does it watch the port status register of every UHCI port to determine if the device plugged in there is a Full-Speed device? Where did you read this?

[XanClic]

He said "high speed", not "full speed".