USB devices not working on systems with legacy BIOS

[eugenio]

Hi all,

We have detected that USB devices connected to a PC with legacy BIOS (no EFI/UEFI BIOS) are non functional once iPXE exits. A USB keyboard connected to the system does not work, so the user can not select options on the Windows boot menu (for example in order to select the safe boot mode option).

We think that this could happen if iPXE does not relase ownership of the USB host controller back to the BIOS of the system.

Thanks in advance.

Eugenio

[NiKiZe]

for reference this relates to the discussion at http://forum.ipxe.org/showthread.php?tid...0#pid13480

Default builds of iPXE does not have USB support enabled.
So to get this kind of issue you need to have built something "special" so it might be a good idea to share you exact build command and configuration.

The only way to use USB is for the system to load it's own drivers since there is no standard for using already existing "drivers" in regards to USB, (and for the few platform where such interfaces exist it is unusable slow)

So when iPXE starts and has USB drivers enabled it loads it's own stack to access USB devices, and loads it own drivers for keyboard. (for anyone else reading note that there is no mass storage support)
Once iPXE exits "all" drivers are shut down and any other software is free to do whatever it want's to do.

In BIOS mode AFAIK there is no call that can be made to get original drivers to re-enumerate the bus.

So this is not an issue of releasing the USB controller, but rather that BIOS can not reclaim the controller regardless of what iPXE does or not.


As a work-around my suggestion is to instead use the iPXE menu system, and wimboot with different BCD files to get the menu options you want. The alternative is to not use USB enabled iPXE, or using a PS/2 based keyboard instead of USB.

[eugenio]

(2017-02-14 12:57)NiKiZe Wrote:  for reference this relates to the discussion at http://forum.ipxe.org/showthread.php?tid...0#pid13480

In BIOS mode AFAIK there is no call that can be made to get original drivers to re-enumerate the bus.

So this is not an issue of releasing the USB controller, but rather that BIOS can not reclaim the controller regardless of what iPXE does or not.

Please take a look at an Intel document tittled Enhanced Host Controller Interface Specification for Universal Serial Bus.

As per the specification all EHCI host controllers have a register used to identify extended capabilities. One of those "extended capabilities" is a synchronization mechanism used to handoff ownership of the USB host controller from BIOS to the operating system.

If the Pre-OS to OS handoff synchronization capability is available, the OS (or iPXE in this case) is also able to handoff ownership of the USB host controller back to BIOS. If iPXE writes clears bit 24 at USBLEGSUP register, the USB host controller will issue an SMI that will be catched by the BIOS code. At that time the BIOS will know that it can regain ownership of the USB host controller hardware.

Taking a look at EHCI source code in iPXE, you can see that there is a function called ehci_remove that calls another funcion called ehci_legacy_release. The comments in the source for ehci_legacy_release read as "Release ownership back to BIOS." and its code writes 0 at USBLEGSUP register if iPXE detected that Pre-OS to OS handoff synchronization mechanism is available.

Eugenio

[NiKiZe]

(2017-02-14 14:18)eugenio Wrote:  Please take a look at an Intel document tittled Enhanced Host Controller Interface Specification for Universal Serial Bus.

As per the specification all EHCI host controllers have a register used to identify extended capabilities. One of those "extended capabilities" is a synchronization mechanism used to handoff ownership of the USB host controller from BIOS to the operating system.

If the Pre-OS to OS handoff synchronization capability is available, the OS (or iPXE in this case) is also able to handoff ownership of the USB host controller back to BIOS. If iPXE writes clears bit 24 at USBLEGSUP register, the USB host controller will issue an SMI that will be catched by the BIOS code. At that time the BIOS will know that it can regain ownership of the USB host controller hardware.

Taking a look at EHCI source code in iPXE, you can see that there is a function called ehci_remove that calls another funcion called ehci_legacy_release. The comments in the source for ehci_legacy_release read as "Release ownership back to BIOS." and its code writes 0 at USBLEGSUP register if iPXE detected that Pre-OS to OS handoff synchronization mechanism is available.

Eugenio

Awesome! Sounds like you have a patch tested and ready to be sent to the ipxe-dev mailing list?

[eugenio]

(2017-02-14 17:58)NiKiZe Wrote:  Awesome! Sounds like you have a patch tested and ready to be sent to the ipxe-dev mailing list?

No, I do not have any patch to send to the ipxe-dev mailing list.
The functions that I talk about in my earlier post are functions written by Mr. Michael Brown. The problem we have is that it seems that the code that releases ownership of the USB host controller is not working.

It could be a failure of the BIOS of the systems we are testing on, or it could be some other reason.

I will debug the EHCI code to see if I could find the root cause for this problem.

Eugenio

[NiKiZe]

(2017-02-15 08:41)eugenio Wrote:  No, I do not have any patch to send to the ipxe-dev mailing list.
The functions that I talk about in my earlier post are functions written by Mr. Michael Brown. The problem we have is that it seems that the code that releases ownership of the USB host controller is not working.

It could be a failure of the BIOS of the systems we are testing on, or it could be some other reason.

I will debug the EHCI code to see if I could find the root cause for this problem.

Since you seem to have quite good knowledge about how it works, what is going on, and a possible fix. And it also sounds like you have the technical know how to implement a fix, I would suggest that you try to change code and send a patch, witch is quite common practice in the open source community, regardless of who actually wrote the code in the first place. (To be honest I don't think the issue and your suggested fix is more understood then by yourself)

Feel free to join #ipxe on the freenode irc network, maybe we can help you better that way.