ASIX USB to Ethernet

[jwillis84]

(2014-09-11 22:14)kfortner Wrote:  John,

I am not using an ISO to PXE boot but undionly. Does any of this work help undionly work for USB?

Catching up.. iPXE (with this USB support) will now compile to any image type you like. It was a problem compiling to the USB image type because I was using VMware player to test the image and did not realize the image it created was of the proper type for a VMware boot.

Essentially if the resulting USB image doesn't end up with a specific number of bytes or virtual "tracks" VMware Player will ignore it and fail to boot.

I've been defaulting to the .iso image format simply to avoid the extra step of "padding" the resulting image so that the USB image type will boot properly in VMware Player. The same could be true for some hardware types trying to boot from the USB image.. which might explain why some USB devices can be booted from, but other USB devices cannot be booted from when using the image. (I've always had variable results with USB boot devices and chocked that up to the USB thumb drive quality versus the USB emulation support for that USB device in the BIOS of the particular laptop or desktop I was using.. this revelation might explain a lot..)

Setting that issue to the side for a moment.

If the USB image boots for you, iPXE will search for any PCI devices that correspond to a UHCI or OHCI host controller for USB and start them up.

iPXE will then start the built-in USB Stack (this code added to iPXE) and probe any USB devices connected to the USB2.0 ports.

If it finds a USB Ethernet Adapter that it "recognizes" it will then load an iPXE USB device driver for that Adapter and next create a normal Ethernet device type in the iPXE kernel space.

At this point iPXE resume control and treats the device like any other Ethernet device, it does not distinguish between device types once the Ethernet device "exists" in kernel space.

I have not tried UNDI support within iPXE.

About 14 years ago I was very interested in UNDI support for providing a device driver to support installing Windows 2000/2003.

Essentially UNDI leaves a "stub" of a driver running in memory that augments the BIOS routines and presents a "Universal" Ethernet device that the corresponding UNDI driver in windows operating system can recognize and attach to, combining "forces" the two merge into a custom driver that lets the "Installer" or even the full "Operating System" boot from the network.

They were popular for "boot from net" devices around the SunRay time I believe and LTSP.

In theory iPXE could have UNDI support.. I think it does.. but I have never tested it.

In my mind its rather like booting iPXE to load the driver, scooping out the brains to leave a Zombie body and then pouring in a new operating system.. sounds creepy when you look it.. but also cool that you can do it.

At the time everything bootable was 16 bit, and even Windows had to jump back and forth between 32 bit mode and 16 bit mode to use the BIOS routines for UNDI.. they were generally only written in 16 bit code.

Today, 14 years later.. I think they would have overcome many of those limitations.. and I would guess the UNDI would leave the USB components running in memory to continue providing network service.. to iPXE this code just looks like weird but familar PCI driver code.

I'm sorry I can't answer your question directly.

I just don't know.

Thinking simply.. I think it should support UNDI if the UNDI feature is working with other PCI device drivers.

I don't have a specific test scenario in mind so I can't promise to test it for you.

I would "guess" your looking to support either an embedded OS, or an installer OS like WinPE.

If the iPXE boot loader is all you have to keep upgrading, to add support for strange and new USB Ethernet devices with the latest greatest USB chipsets, then the embedded OS, or installer OS can remain stable and strictly configured to use the iPXE UNDI support.. and never have to see a hardware driven upgrade ever again.

That's a big win.

iPXE is a small code base to test and maintain, an embedded OS or installer OS often is huge, lumbering.. and delicate.. they barely survive the install process before crashing or otherwise going off the rails.

If you could bring my imagination down to earth and give me a little more information what your targeting or expecting.. I might be able to dream up a way of testing the UNDI support your seeking.