iPXE, USB3.0 development platform

Currently I'm most familar with using VMware Player as a host platform for developing iPXE code. To work with new USB3.0 hardware I've discovered I'll need to upgrade the host OS I am using for VMware.

In the beginning I was using Windows 7 as the VMware host, and CentOS 5 inside a VMware virtual machine to compile and a second VMware virtual machine to boot from the iPXE.iso image.

This worked well because the Windows 7 (x64) host could "pass-thru" access to PCI and USB host controllers to one of the VMware virtual machines.

But VMware will not "pass-thru" USB 3.0 host controllers because Windows 7 does not contain a native Microsoft USB 3.0 host controller driver. Further VMware mentions specifically one of the Renasas (NEC) chipsets as "tested" and known to work. Fortunately the adapter card I obtained is a Renasas (NEC) chipset card and should work.

This leads me to conclude that to establish a new USB 3.0 development platform for iPXE I will need to upgrade to a Windows 8 (or a Windows 2012) host operating system and a version of VMware Player that supports "pass-thru" for the USB 3.0 host controller. I am debating whether to use a separate hard disk, or to perform some sort of dual boot scenario.. though my intuition is to maintain a separate hard drive for each purpose. Multiboot scenarios are often hazardous to not only the disk contents, but also the integrity of the boot loader for each and complex disk management while focused on virtual machines can get confusing.

After arranging all of this, it will be very interesting, just to confirm or deny that the original UHCI, OHCI or EHCI emulation (will or will not) work with a true xHCI controller type.

I'm given to understand that (it "might") work, but also that (it "might") not work. I tend to think the latter is more likely.

To work, the new Renasas (NEC) chipset would have to have provisions for the same chipset registers present in the earlier OHCI or EHCI controller types and respond as if it were the older adapter card type in some sort of "fall down" or "fall back" position to support older device drivers.. which would be awesome.. and they have the design rights to make such a device. However it might be in conflict with the later xHCI design goals. And so far I have only tested the UHCI functionality of the USB support added to gPXE before porting it over to iPXE.

I have recently obtained [true] EHCI > UHCI and EHCI > OHCI (Legacy PCI) adapter cards for the purpose of testing the code as close to specification as possible. that is I want to make sure not only UHCI but also the OHCI driver works. But I have not had the time, "the playing board is set" as they say but I have lacked the microseconds necessary in my schedule.

I have also recently obtained a [true] xHCI (PCI Express, or PCIe) adapter card for the prupose of testing the functionality of the "existing" xHCI > OHCI (or lack of functionality). But it requires setting up a different motherboard with a different operating system to support VMware USB 3.0  - "pass thru" for the PCIe card. And then creating a virtual machine with a newer version of CentOS with a newer kernel that also supports the USB 3.0 chipset and bus.  This is certainly doable, its just a matter of time.

Then there are individual USB Ethernet device drivers. So far I have only verified the Asix device driver using the 100 Mbps chipset, there is a second using the 1000 Mbps chipset which it appears a cloner of the ipx/usb-device-drivers Git project is already testing. The results of that test will no doubt be USB 2.0 specific, but most interesting.

As far as I can tell, if the Intel or Via version of the xHCI controller truly deviates enough from the specification that a "different" PCIe host controller driver is necessary, it may be unsupported for a while. I think however Linux may have implemented different host controller drivers to support advanced features unique to variants of the xHCI device (Power Management, TOE, VLAN tagging, Bonding, ect..) and for the more mundane and common features.. it is possible a common generic xHCI driver will support both pseudo xHCI > UHCI as well as xHCI > OHCI variants of the xHCI device.. which would be truly awesome.

To get the speed up through the USB stack however, a rewrite of the USB stack paralleling the rewrite for the Linux host controller device drivers may be in order.