iPXE, difficulty in picking xHCI hardware

Since the xHCI spec was produced by the PCI-SIG group out of Oregon in collaboration with a lot of vendors. One of the first and most commonly adopted (aka certified to work) Chipsets that supported an xHCI on a chip was produced by the NEC or 'Renesas' Corporation (who merged in April 2009).

Download of discoveries, and a conundrum. UHCI, OCHI and EHCI controllers were popular during the "Conventional or Legacy PCI era" they supported 10/100 USB to Ethernet adapters. Next Gen 10/100/1000 NICS and 10 Gig NICS needed more bandwidth and PCI Express became the bus of choice.

VMware emulation "pass thru" and Microsoft Windows 8 native xHCI driver tested with and support adapter cards which use the Renesas uPD720200 Chip, which then got later revised as the uPD720201. The major difference being the support of a Debug mode or Debug environment, useful for writing and debugging device drivers.

Renesas Electronics Worlds First Certified USB 3.0 Host Controller - 2009 - uPD720200

Renesas Electronics Worlds First Certified USB 3.0 Host Controller - 2012 - uPD720201

Reports in the early days were however that devices on both sides of the USB 3.0 bus were subject to burnout or "smoking". The candidate cause seemed to be related to the larger possible power draws and current surges through the USB 3.0 ports.

A few manufacturers seem to bolster the USB 3.0 ports by adding "Over Current" protection to their ports independent of the chipsets, SIIG for one.

Alternative chipsets from Intel, TI and others emerged, but not in time to be selected by several USB 3.0 technologies like Virtual Machine emulation pass through or various device drivers for native operating system drivers.

The Linux support for xHCI appeared in kernel 2.6.31 (2009) but is optional and less well known until 2.6.36 (2010) and more mainstream in the 3.0.x (2011) kernel lines.

Thus practically, development platforms for xHCI will require moving beyond CentOS 5.x:

CentOS 6.x - kernel base 2.6.32
CentOS 7.x - kernel base 3.10.0

Although xHCI strived for independent compatibility across the board, it appears there are enough variations in chipset implementation, that there are still different drivers for different chipsets.

Therefore I'm thinking while there are a wide variety of choices, the safest, most widespread (because its been on the market the longest) is probably the Renesas (NEC) chipset, with a bolstered over current port protection design like one of the SIIG Adapter cards.

The Linux kernel usb core support also apparently had to be revamped to support the "higher" possible speeds that USB 3.0 brought, meaning the current USB to Ethernet USB core support in iPXE may not be able to keep up with the data flow without modification to adopt some of the changes in the Linux implementation.

It is somewhat of a catch-22 in that iPXE downloads typically a small boot kernel and disk image in order to transition to a larger full fledged operating system in a steady state, or via an iSCSI or Http(s) or other secure network file system.. and the iPXE USB to Ethernet driver support is long abandonned for native operating system support by the time USB 3.0 Superspeed support is actually used.

But it is the wave of the future, and any unique properties of a PCIe bus driver need to be investigated and accomodated. we cannot even envision why native USB 3.0 speeds of 5 Gbs or higher might be necessary in iPXE in the future.. so it should be incorporated as soon as possible.

Then also, while today USB 2.0 adapters and busses are common. In the future, they will be less common and USB 3.0 will be more common. So the xHCI will be more common, even if used with USB 2.0 Ethernet devices, and then USB 3.0 Ethernet devices. So it would seem to be the right course to take.

With that in mind this card looks particularly well suited:

4-Port USB 3.0 PCIe - JU-P40311-S1



iPXE, new hardware for testing

Just received two Syba PCI cards for testing.
SD-VIA-5U - VIA (UHCI host controller Interface)

SD-V2-5U - NEC (OHCI host controller interface)

Form factor "wise" they look nearly identical

These cards are 4 + 1 which means the internal USB port is actually attached to one of the external ports and cannot be use simultaneously with the other port. So in actuality they are 4 port cards.

The PCI bus is (of course) 32 Bit and 33 Mhz Local Bus spec 2.2, the double notches in the cards indicate they are "Universal PCI cards" meaning they will work in 5 volt or 3.3 volt PCI 32 bit slots.

The boxes indicate they are for Windows 98SE through Windows 7, Linux and OSX (OHCI only).

These were popular and mainstream from 1996 through 2006, and probably lead to their targeted use in the original 2008 code to provide USB Ethernet support for gPXE.

They are rarer to find these days.

Sorting out which card provides UHCI or OHCI by chipset is made difficult because the chipset is only rarely mentioned in the specifications quoted by websites.

Both cards support the EHCI standard, which provides USB 2.0 "Hi-Speed" which can be seen as a [third] device for each card, and is given its own PCI identifier.

I have not decided on a xHCI standard card, which provides USB 3.0 "SuperSpeed"

Using PCITree on Windows [reveals] both cards are detected as being attached to a PCI Bus bridge and assigned function and device numbers.

I have highlighted the PCI vendor and device numbers in gold.

:  0.30.0    0->6 (6)  Subtractive; PCI/PCI; Bridge Device  8086 244e [Intel] 82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge: 82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge // SubIDs 0000 0000 --------------:
:  :  6.02.0        Open Host Controller; USB (Universal Serial Bus); Serial Bus Controller  1033 0035 [NEC] uPD9210/72010xx USB Open Host Controller: uPD9210/72010xx USB Open Host Controller // SubIDs 1033 0035  USB OpenHCI Controller: USB OpenHCI Controller
:  :  6.02.1        Open Host Controller; USB (Universal Serial Bus); Serial Bus Controller  1033 0035 [NEC] uPD9210/72010xx USB Open Host Controller: uPD9210/72010xx USB Open Host Controller // SubIDs 1033 0035  USB OpenHCI Controller: USB OpenHCI Controller
:  :  6.02.2        o. serial bus Device  1033 00e0 [NEC] uPD720100A/101 USB 2.0 Enhanced Host Controller: uPD720100A/101 USB 2.0 Enhanced Host Controller // SubIDs 1033 00e0  USB 2.0 EHCI Controller: USB 2.0 EHCI Controller
:  :  6.03.0        Universal Host Controller; USB (Universal Serial Bus); Serial Bus Controller  1106 3038 [VIA] VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets): VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets) // SubIDs 1106 3038  VIA: no-name
:  :  6.03.1        Universal Host Controller; USB (Universal Serial Bus); Serial Bus Controller  1106 3038 [VIA] VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets): VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets) // SubIDs 1106 3038  VIA: no-name
:  :  6.03.2        o. serial bus Device  1106 3104 [VIA] VT6202/12 USB 2.0 Enhanced Host Controller: VT6202/12 USB 2.0 Enhanced Host Controller // SubIDs 1106 3104  VT6202 USB 2.0 Enhanced Host Controller: VT6202 USB 2.0 Enhanced Host Controller

The really nice thing about Host Controller Devices (HCDs) is that they are completely PCI devices, therefore device drivers for them can be built just like device drivers for any other PCI device.

How the PCI device is used however (after its found and initialized) is completely up to the protocol defined by the makers of that type of device.

For example;

Intel defined "how to use" the UHCI type device for "transmitting" and "receiving" USB style communications through one of its physical ports.

 Universal Host Controller Interface (UHCI) Design Guide

Compaq defined "how to use" the OHCI type device for "transmitting" and "receiving" USB style communications through one of its physical ports.

But in the end, the "communications" on the wire of the USB port is the same. That is independent of the Host Controller Device.

So the device driver for each type of device can be made "generic" by exposing a software "interface" common to both types of cards. That "interface" looks the same to any software that doesn't care what specific hardware card is connected to the USB bus.

A third piece of software called the USB "stack" provides common services to a specific USB device attached to the "end of" the USB bus which is in turn attached to the USB Host Controller Device.

To support a new type of Host Controller Device, only a new Host Controller Device driver needs to be written. All it has to do is expose the familiar software "interface" for the USB "stack" to use.

Thus a UHCI, OHCI, EHCI device can support the same USB "stack" and USB devices attached.

Adding support for a new controller type; xHCI, wHCI, ect.. simply requires writing an HCD device driver.

The older HCDs like UHCI and OHCI were reportedly harder to implement, EHCI was reportedly easier to implement (and it was one specification not two) as is xHCI.

Fortunately the Linux operating system also provides a blueprint or guide that demonstrates how to implement HCD drivers to support these controller types. And it appears that was used when originally implementing support in gPXE, and now iPXE support.


PuTTY, default to the Zenburn color scheme

PuTTY is a terminal emulator for windows, its default color scheme is rather harsh.

An alternative is called Zenburn, you can read about it here: The History of Zenburn

And how to apply it to PuTTY here:  A pleasant color scheme for PuTTY

Normally if you [Save] a Session in which the Colors have been manually set, you also save the hostname or IP of the machine your connected to at that time.

Then loading that [Session] from a shortcut with the "...\putty.exe" @Zenburn-scheme in a Shortcut target area, leads to connecting [only] back to that host. So the Default color scheme has not been changed.


You can save the currently loaded Session scheme to the Special [Default Settings] scheme by first loading a Saved session with the color settings you want, then clicking on the Special name in the list of Saved Schemes [Default Settings] and then clicking the [Save] button.

A new branch in the windows registry will be created to hold the custom Default Settings and any new sessions will use these Default Settings.


iPXE, milestone

RE: ASIX USB to Ethernet 

All bugs I am aware of have been fixed.

If you clone the github project

# git clone -b usb-net-drivers https://github.com/johntwillis/ipxe

Change to ipxe and type 'make' it will proceed to build the default ipxe images.

I used the bin/ipxe.iso image to successfully boot from a USB ASIX Adapter, obtain a dhcp address and download itest.ipxe script file and used that to download a tomrtbt kernel and initrd and then booted from that.

Any further work will be to support more hardware; USB host controller types and USB devices. 
Prior to this there were a few [unknowns] which  took time to discover and fix.
  1. The build would not [automatically] add USB device drivers to the default Make 'target' - it works now, parserom.pl imposed a requirement on the source files to provide USB ID's for supported USB Devices.
  2. The resulting bin/ipxe.iso would work only when providing a Make DEBUG=uhci_hcd parameter - it works without that parameter now, the ohci_hcd host controller driver was competing during linking, ohcd support has been removed for now.
  3. Pegasus USB device driver would not compile - USB ID's in the source were not in a format that could be recognized by the parserom.pl build utility. They have been reformatted and the pegasus driver now compiles.
The code started out as a project several years ago on a previous ancestor branch of the current iPXE project. When iPXE branched from that project, this code was not brought along.

It has now been brought over and brought up to date to work with things the way they currently exist in the iPXE project.

This 'branch' has not been merged back into the main iPXE.org master code tree.

It is my hope that one day it will be.

But for now I would appreciate anyone with an interest in iPXE USB Adapter support to download it, try it out and submit comments.


iPXE, demo of USB Ethernet Adapter support

Checkout from a github fork of iPXE, to which USB Host controller and USB Device support for UHCI has been added and test with an AX88772A (Asix) USB to Ethernet Adapter.

# git clone -b usb-net-drivers https://github.com/johntwillis/ipxe
# vi /ipxe/src/config/config.c
# make bin/asix.iso
# qemu -cdrom bin/asix.iso -bootp -usbdevice host:0b95:772a -net nic -net user -serial file:logfile.log
From USB Device to iPXE boot image, here is how it was all connected for testing.
[USB to Ethernet Adapter]
attached to:>
[Windows 7 desktop]
attached to:>
[VMware Player 5.0.2]
attached to:>
[CentOS 5.10]
attached to:>
attached to:>
attached to:>
[iPXE.iso -> bin/asix.iso]

As per the video the most interesting bit was getting the [Linker] to pull in the [USB Host Stack] modules

There is probably a better way to do this, but this documents what needs to be done, until I can grasp how to make it more automatic.

It should also be noted that the Make [target] by default is [iPXE] which appears to only link in PCI devices or devices that already existed in the code base.

An improvement would be to add the [USB Host Stack] and the USB Device drivers as part of that default target.

UHCI is the Intel version of a USB 1.1 controller.

OHCI is the Compaq version of USB 1.1 controller.

UHCI is implemented and tested in this code and tested in the video.

I do not currently have an OHCI platform on which to test, but will be looking into finding an OHCI pci card.

I have two other USB to Ethernet Adapters, and plan to write USB device drivers for them.

Notice how the target is [ bin/asix.iso ]

The "bin" portion is where to place the resulting target image after compilation and linking.

The "asix" portion is the name of the USB Device driver to "make sure" is in the image, since it is not created by default with simply [ # Make ] or [ # Make bin/ipxe.iso ] it must be targeted "specifically"

The "iso" portion is the resulting image format and designates how it is to be used. The alternative images will probably work, but the target for ".usb" will not work in QEMU unless "Padding" is added to the resulting image. Therefore the ".iso" image format was used for testing.

Also "for testing" the image must be supplied its bootstrap control file via the dhcp option

Tftpd32 by Ph. Jounin
DHCP (tab)
boot file:

Contents of the boot file
kernel root=100 

# qemu -cdrom bin/asix.iso -bootp -usbdevice host:0b95:772a -net nic -net user -serial file:logfile.log

Although the "bootp" option is required for QEMU to follow the image and attempt to boot from network, the actual information in that option is not used.

Likewise the "-net nic" and "-net user" options must be passed but are not used.

The "-serial file:logfile.log" merely captures the debug output from the booting image to a file, so it can be opened in an editor and scrolled through later. The "-serial" option also require the iPXE src/config/console.h file to have the #define CONSOLE_SERIAL option uncomment so that support is compiled in. This is merely for testing, normally it only adds size to the image and if debugging is not taking place it is not useful.

The  -usbdevice host:0b95:772a option is QEMU's mthod of USB Pass through from the CentOS 5.10 "host" through to the SeaBIOS virtual machine.

To compile a [Debug] image which will provide output during the image run.

# Make bin/asix.iso DEBUG=uhci_hcd,usbcore,asix

Can be quite helpful.

In the video a debug version is not compiled.


HP SIM, Schedule and Email Custom Reports

This is a quick walk through on how to Create a Custom Report in HP Systems Insight Manager (with a Custom list of Events based on Systems, Types of Events, and Attributes of the Event. Then how to Schedule running the saved Report using Windows Task Manager.

Then how to check the results for any notable events, if there are none then no other actions is taken; if there are notable events a follow up email is sent to a list of recipents.

The HTML formatted report from the SIM task is included in the body of the email, so that it can be read from an inbox or through a mobile devices inbox. But it can also be sent as an attachment.

It demonstrates several technologies:
  • Systems Insight Manager (SIM) Custom system collections
  • Systems Insight Manager (SIM) Custom event filters
  • Systems Insight Manager (SIM) Custom reporting
  • Windows Task Manager (Scheduling)
  • Batch file processing to kick off a Powershell script (Scripting)
  • Powershell processing to text process an HTML formatted document 
  • Powershell processing to make decisions on the contents of an HTML document
  • Windows Task Manager - Custom event triggering using XPath statements 
  • Powershell processing - to send email and include text or HTML formatted content in the message body or as an attachment

The only applications used in this scenario are HP SIM and the normal services and scripting tools provided with the operating system.

Custom Reports

---{Finding the Collections Manager Page}---
1. To create a [Custom Events "Filter"]
2. Click in Nav over to [Left] Lower Section named [System and Events Collection]
3. Look for Lightly highlighted word [ Customize ... ] click on that
4. This is the [Customize Collections] Manager Page

---{Creating an Events Filter}---
5. At top of white background window find [Show collections of:] click on the drop down that says [Systems[v]]
6. Select [Events]
7. In Button list to right ->
8. Click on [New...]
9. At bottom of main window
A. Below the bar in bold find [New Collection]
B. Select the bubble [Choose members by attributes]
C. Again, Below the bar in bold find [New Collection]
D. -> Search for events
E. -> -> where -> severity -> is -> (any)
F. Use drop downs to change this to
G. -> -> where -> severity -> is not -> Informational
H. Click [<< Add] button

I. A new [or] statement line will appear and can be changed
F. Use drop downs to change this to
J. -> -> where -> cleared state -> is not ->  Cleared
K. Click [Save As Collection...]
L. Name: [ MyEventFilter ]
M. Choose where to put the Collection in the Nav panel
N. Place in:
O. Select bubble - [New collection:]
P. New collection: [Events for Email]
Q. within [Shared]
R. Click [OK] button
S. Browser will refresh both Nav and Main windows
T. A new [Shared][Events][Category ->Events for Email][Collection -> MyEventFilter] will appear

---{Creating a Custom Report}---
U. Top Main window [Menu bar] -> Select [Reports] -> Select [New Report]

---{Adding Target Systems}---
V. Step 1: Select Target Systems
W. Add targets by selecting from -> Select bubble -> Collection
X. Drop down select [Systems by Type]->[All Servers]
Y. Check -> [Select "All Servers" itself
Z. Far right --> Click [Apply] button
a. Step 1: Verify Target Systems

---{Adding Search for Events by Existing Filter}---
b. Right -> Middle buttons
c. Click [Add Event Filter ...]
d. [Add filter by selecting from:]
e. Drop down select
f. [Events for Email] -> [MyEventFilter]
g. Far right click [Apply] button
h. Far right click [Next>] button

---{Adding show "these" fields of the [Target x Filter] Join}---
i. Step 2: Specify Parameters
j. Report name: [MyReport1]
k. [Select items to show in the report] essentially "fields" in the table output
l. Click [Events]
m. Check [System Name, Severity, Type, Received Time]
n. Far right click [Save Report] button

---{Scheduling a Report}---
1. Open a batch file <report.bat> and save the following command
2. "C:\Program Files\HP\Systems Insight Manager\bin\mxreport.exe" -e MyReport1 -x HTML -o C:\reports\summary.html
3. -e <name> execute the saved report named <name>
4. -x <format> save the report in the file format <format>
5. -o <filename> store the output of the report in <filename>
6. Create a Windows Task Scheduler "task" named "MyReport1"
7. General (tab) : Run whether user is logged in or not
8. General (tab) : Run with highest privileges
9. Triggers (tab) : Schedule to suit
A. Actions (tab) : Start a program : Program/script: C:\report\report.bat

---{Automatically emailing a Report}---
1. Create a Windows Task Scheduler "task" named "Email MyReport1"
7. General (tab) : Run whether user is logged in or not
8. General (tab) : Run with highest privileges
9. Triggers (tab) : On an event : Custom event filter : Edit event filter : <enter> XML
  <Query Id="0" Path="Microsoft-Windows-TaskScheduler/Operational">
    <Select Path="Microsoft-Windows-TaskScheduler/Operational">


This "watches" for the completion of a "task" named "\MyReport1" and executes on that event
A. Previously you could email an attachment direct, this is no longer the case in WS2012
B. Open a command script file <sendmail.cmd> and save the following commands
SET ThisScriptsDirectory=%~dp0
SET PowerShellScriptPath=%ThisScriptsDirectory%sendmail.ps1
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%'";
C. Open a powershell script file <sendmail.ps1> and save the following command
$body = Get-Content "C:\reports\summary.html"
$body=$body | select-string -pattern "gif"
if ($body.length -gt 0){
$body = Get-Content "C:\reports\summary.html"
send-mailmessage -from "SIM <sim@mycompany.com>" -to "Admins <admins@mycompany.com>", "Nobody <nobody@lostinspace.com" -subject "SIM - Events in progress" -BodyAsHtml "$body"  -priority Normal -smtpServer smtp-relay.mycompany.com
D. This checks the SIM output for events, if there are no events, no email is sent
E. Actions (tab) : Start a program : Program/script: C:\report\sendmail.cmd


PXE, iPXE adding a USB bus

So after some exploring, and thought.

It appears the best approach is to make sure the Balaji implementation of a USB bus is working and compiled.

Then move on, this is because the USB to Nic driver will need to use that support to identify and probe to communicate with the USB Host controller.

The gPXE code has the new USB bus code here:


The iPXE code has some bus code in the same plus, but no support for a USB bus:


While the PCI bus files appear to have changed, the ISA.C bus files have identical md5sum hash values and have thus not changed.

This suggests whatever the conventions for enumerating and standing up a bus instance are still valid.

So the /gpxe/src/drivers/bus/usb directory was simply copied over to /ipxe/src/drivers/bus

The USB bus code consists of eight files:

hcd.h - a list of USB Packet IDs, it has an #ifndef _GPXE_HCD_H that probably needs to be translated in some way. (edit: this seems to be related to how the Make files used to work, making decisions on whether to compile and link code modules on whether certain Macro environment variables were set or not, iPXE doesn't use that method any more - I don't think - so its not relevant)

message.c - appears to be some functions for building up some structures and then calling a
[ usb_submit_urb ] function and then monitoring it and [ usb_urb_status ] for completion

the [ usb_start_wait_urb ] function builds on this to provide a polling service that submits an urb and waits for the results

[ usb_control_msg ] uses the [sub_start_wait_urb] and takes arguments to target a device, endpoint on the device, a request type, value, index, data and size

[ usb_get_descriptor] appears to get a device descriptor

[ usb_get_device_descriptor] uses the former to accomplish its task

[ usb_set_configuration] sets a device configuration

[ usb_get_configuration] gets a device configuration

[gpxe/usb.h] is referenced, which in gpxe appears in [ /gpxe/src/include/gpxe/usb.h ] so needs to be copied over - this defines some structures to hold usb device and driver data, and is where the last problem encountered actually exists

#define __usb_driver __table (struct usb_driver, usb_drivers, 01)

The prototype for __table in the ipxe code no longer acceptsthree parameters  for instantiating a member, it only takes two parameters

It defines a lot of prototypes and then appears to call:

[int usb_probe] to tell the usb core about a discovered USB device, then

[int usb_dev_init]
[void usb_free_dev]
[int usb_set_address]

[ usb_fill_control_urb]
[ usb_fill_bulk_urb]



The "above" procedure appears to be standard USB bus protocol for initializing the device at the end of a USB cable. It clears the "decks" sets up some Control structures, then gets a "device descriptor" (there can be 'Only One') and then sends a "Configuration" command over to the device to get it ready. "Devices" can have lots of endpoints, and four different ways of addressing called "Pipes" I think they are really "Methods" for communications with varying levels of "Priority" over other types of traffic.. some are "Critical - like setting up the device or Configuring" some are "When you get around to it - like Polling for data" or "Best effort as quick as you can - like Isynchronous" there is something like "Interrupt" but not quite sure where that falls.

Last step is to retrieve the "Configuration" when it comes back you know that its "done" and ready for action.

[gpxe/malloc.h] is referenced, and probably refers to [ /gpxe/src/include/gpxe/malloc.h ]which does exist in [ /ipxe/src/include/ipxe ] but in a different modified form

[gpxe/src/include/gpxe/usb] directory also exists with a single file called ch9.h, these appear to describe USB macros and structures to make it easier to program for USB communications, looks to be lifted direct from Linux code (edit: ch9.h is described in detail in the Book mentioned at the bottom of this blog post, it seems to be a core feature of USB communications described by the Specification itself)

Returning to [ /gpxe/src/drivers/bus/usb ] brings us to file #3

ohci.h (Compaq Open Host Controller Type - simple type) lots of macros and defs describing host controller registers for communications

ohci_hcd.c (ohci Host Controller Driver ->ohci_hcd) resets initializes and defines how to use this controller type, it seems to rely on the PCI_ROM function to "find" a pci_device_id that matches something like "OHCI USB Controller" or "OHCI HCD" and if it does then instantiates a "pci device" driver instance to manage this host controller.. and proceed to probe to initialize it

uhci_hcd.h (uhci Intel Inversal Host Controller Type - complex type) appears to do much the same thing, interesting they did not postfix _hcd.h on to the end of the ohci.h filename

uhci_hcd.c (uhci Intel Inversal Host Controller Type -uhci_hcd) more complex, but structured very much the same, has the PCI_ROM find "UHCI USB Controller" or "UHCI HCD" and create an instance of this driver as a PCI bus device and probe and initialize it

urb.c mostly defines how to perform urb_submits using the real methods fleshed out in the _hcd.c driver files for ohci or uhci - controller interfaces (edit: _hcd -> stands for Host Controller Device "driver" - hcd)

usbcore.c - takes a usb_device table and loops over its list of drivers to see if it can find a usb device driver for a device hanging off its bus. Some DBG commands to print the results if debug is turned on.

It "looks like" the use of gpxe/tables.h and gpxe/usb.h et. al. is sufficiently self contained and referenced that they "could" be copied over and used as they are, the code may work without adapting it. The USB host controllers are treated as PCI devices in the same manner as they were originally.

After the USB controller(s) is initialized, the USB device drivers interact with the usbcore but not with any other system. (except through common net driver interfaces)

The USB drivers communicate over the USB bus, but expose common "net driver" interfaces to the rest of the system code. When they invoke "net driver" communcations functions they are handled by the usbcore to communicate with the USB device hanging off the controller.

I had "thought" I saw USB storage support in the ipxe code base, which could complicate things, since the usb controller should be managed only by one pci usb bus driver. But I could be wrong.

In fact after cloning the github ipxe/ipxe project again the only usb file referenced is here:


Which appears to be a gnu assembler file for "Zip" disk support, possibly part of the bootloader code for bootstraping from that type of media.

The usbdisk.S "might" be a misnomer, "zipdisk.S" may have been the original intent.

So at present there is no pci bus usb host controller support.

Something I had not thought about however, is the usb host controller "pci device driver" needs to interface to the new ipxe pci bus driver.. and its apparent that has changed.

So while the usb host controller driver "might" compile, it might not interface with the pci bus driver code.. I will have to study that.

Useful Links:

Very Useful Links:

This book describes the very complex and layered Linux USB bus system, and how its put together, with diagrams. (Thanks to Jan Axelson for pointing out the level of detail available in this book, and the more appropriate use for this kind of software project!)

Bootstrap Yourself with Linux-USB Stack

This book on page 111 begins to describe the Linux USB stack, which is almost verbatim the stack implemented in gPXE, which has been proven to work.

The Chapter 9 describes the major components and functions calls and what they actually do (as opposed to my guessing). Its a very interesting read.

The book is available through Amazon, (correction) it is available as Kindle book, it is also available through O'Reilly's Safari Online if you have a subscription you can immediately access it online.

It has been pointed out (in the reviews, and in the Book itself) much of the information can be obtained by reading the Linux Kernel source and Documentation on the USB stack.. but I find a book with a narrative much easier to orient oneself.

Bootstrap Yourself with Linux-USB Stack