ASIX USB to Ethernet

[jwillis84]

[/quote]

I am currently using WinPE 5.1, and from my experience on the ASIX USB, undionly.kpxe will load, and pull an IP, but either the http file transfer or wimboot process will fail out.
[/quote]

I haven't finished looking into this yet, but came across mention of a "second type" of undionly target called the undionly.kkpxe

You might try compiling to that target type

# make bin/undionly.kkpxe

And see if that works

I'm a little alarmed at what I have read about the undionly.kpxe support -- I may misunderstand it.. but from what I have read, people say its meant to remove the undionly.kpxe driver from memory once it has copied the boot image over the network using the combined (iPXE-undionly)/(BIOS undi) driver .. so that the boot loader its about to chain to can fully access the UNDI support in the BIOS.. since we know the BIOS does not have "general" USB Ethernet adapter driver support that will not work. It might work if (a) the BIOS has an UNDI driver interface built into it (b) the USB Ethernet adapter being used "just happens" to be supported by the BIOS for PXE booting (which if it did why bother with iPXE, other than to provide nicer menus)

The .kkpxe target type seems to avoid releasing the memory allocated to the iPXE code.. or does it in a different way.. but I don't think iPXE provides a generic UNDI interface that a secondary bootloader could bond with.. rather it seems to be all about using the UNDI driver interface in the BIOS (if there is support for UNDI).

UNDI in a way depends on two virtual machines, be that BIOS Interrupts or a service running as a virtual machine to expose an UNDI interface that an UNDI driver can access to get network services. The UNDI interface was specified a long long time ago.. we've moved way beyond Terminate Stay Resident and mere BIOS Network interrupts to provide a generic UNDI interface.. I would have thought.. but maybe I am wrong.

If the UNDI support in iPXE is really the top-half of the driver in the iPXE bootloader or OS trying to run on the hardware.. then its only going to provide support if there is already an UNDI interface in the BIOS for iPXE.

Chaining "network" drivers is sort of what UNDI does, like Chaining "bootloaders".. I'm not 100 percent sure.. but I don't think iPXE is in the business of loading its drivers to provide a generic UNDI interface.. it would then have to stay resident and accept calls from the top-layer UNDI driver and return control back and forth.. not impossible, but probably not very stable.

It's as if what you'd like were an UNDI "bus" driver, that finds UNDI support, then re-exposes that to the subsequent bootloader to come "after" iPXE, but if the BIOS already had UNDI support.. you wouldn't need iPXE.

More likely you'd like iPXE to "stay resident" and provide it's USB bus and USB device driver support, then expose a generic "UNDI" interface that a subsequent bootloader could bond with and continue. In that way iPXE would become a BIOS "add-on" ROM providing a UNDI interface for a BIOS that natively "has no" UNDI support.

If it is that way, then what your seeking in an UNDI "bus driver" kind of like the USB "bus driver" to provide a place later "UNDI device" drivers could "plug-in" for service.

What really makes me think this is not possible without a new project to add a "UNDI" bus driver to supply the "interface" is that I read several people saying ".kpxe" [get's out of the way] and [ only one driver is compiled into the .kpxe image ]