Threaded Mode | Linear Mode

jwillis84 · (This post was last modified: 2014-09-23 06:59 by jwillis84.)

(2014-09-21 12:13)robinsmidsrod Wrote: jwillis84: iPXE has an UNDI driver, and is able to take advantage of an existing PXE firmware when loaded via it (that is what undionly.kpxe does). iPXE also provide its native drivers as an UNDI interface when booting via USB/CD/ROM. So you can have iPXE on both sides of the equation. What undionly.kpxe does it uses the generic networking interface that the firmware provides and use it as a "virtual" network device.

Sometimes this doesn't work quite right, because the underlying firmware has bugs. The UNDI driver in iPXE does a lot of crazy stuff to try to work around various firmware bugs, but sometimes it's just not possible to make it work. In that case you'll either need to use a native iPXE driver or get a firmware update for your PXE-enabled NIC.

When a USB NIC comes with PXE support in it, iPXE should be able to run via undionly.kpxe. But that all depends on the quality of the PXE firmware on the USB NIC. That is why I'm looking closely at your project, as it might help us to finally get basic support for USB NICs, just as we have basic support for WiFi NICs (although we only support Atheros and Realtek).

Keep up the good work! I hope someone will have time to review your code soon. Maybe you should ask Mareo again. I recall him saying he would have time in a couple of weeks, but that's a while ago now, so maybe he's got some spare time on his hands.

Yes, I think we are on similar lines of thought.

I have not actually looked at what iPXE undionly.kpxe actually does, I've merely read up on discussions about it in the forums. So my information is second hand.

The existing USB support that has been tested as working for the ASIX driver is available, but its a question of what undionly.kpxe and undionly.kkpxe does with it.

UNDI originally exposed either the original underlying BIOS firmware support for an UNDI virtual interface, or alternatively stayed in memory to provide an UNDI interface based on the booting PXE bootloader. Peter Anvin would probably have a better grasp upon it than I since he wrote PXELinux and I believe it did provide some kind of UNDI support.

A different way of behaving though is to put a priority on exposing the BIOS firmware support for the UNDI virtual interface by turning control over to the next kernel to boot in the chain, or by cleaning up the system and then turning control over to the next kernel in the boot chain. (One is cleaner than the other and might lead to less problems) That is what I think .kpxe and .kkpxe does based on the forum conversations I read.. but those posters could have misunderstood UNDI and/or may have not read the code for themselves.

Ultimately I just need to look at the code.

(2014-09-23 06:16)jwillis84 Wrote: Ultimately I just need to look at the code.

Ok I've found the start of the UNDI support in ipxe/src/arch/i386/drivers/net/undi.c and undionly.c

Michael Brown c2007

undionly.c code has a note about two types of build

make bin/undionly.kpxe

make bin/undi.dsk

The first one is pure UNDI without regard to bus type, I would guess that's for when there is UNDI support in the BIOS firmware.

The second one is for UNDI+plus with "other" drivers, I would guess that's for when there is no UNDI support in the BIOS firmware for the devices that iPXE supports... like USB Ethernet devices

Checking the bin/undi.dsk.tmp.map the usb bus appears to be getting compiled in, but I don't see an entry for the asix.o driver, could be it needs to be told to add in that driver or drivers, so that the iPXE resident UNDI can load an iPXE driver to support the new USB bus being compiled into the undi.dsk image.

I'll have to spend more time figuring out how the build system decides what to compile into the undi.dsk image type, I would guess its a special Makefile list somewhere.

As ignorant as I am, stumbling around in the codebase.. I almost feel like leaving bread crumbs..

(2014-09-15 15:16)kfortner Wrote:
(2014-09-12 21:42)jwillis84 Wrote:
Quote:What I am trying to accomplish is to PXE boot into a WinPE environment to then run a set of code that deploys the operating system to the target system from the WinPE environment. Today this works great on PCI based NICs, but for USB NICs the undionly.kpxe does not seem to work. I am dynamically building the iPXE boot script using a PHP script and the iPXE web call to determine what WinPE deployment environment to use. Is there a way to use the ISO build of iPXE to make the same call to my PHP and then chain boot to WinPE from the ISO of iPXE?

That's a scenario I can test.

It would be helpful to know which WinPE version, or the target OS.

We are up to WinPE version 5.1 which spans Thirteen "released" versions.

As a Guess I'll look at testing WinPE 3.0 or WinPE 3.1 since Microsoft seems to be "burning" anything Win Eight related and taking chisel and hammer to all the monuments. If your using something post 3.1 please let me know.. and you have my condolences.

I'm guessing some people already have access to WinPE 6.0 but I do not.. should be available with two weeks however. I can't wait to dig into it.

[As for boot from ISO over http and then chain load?] Yes I do think that will work.. but you would still need something local, in ROM, NVRAM, SD card, USB or a USB DVDROM to bootstrap the whole process.. and at that point why not just boot PXE and load WinPE into a ramdisk and continue from there.

Like I said.. I got the USB image booting in VMware.. it just took an extra step.. and was trivial to do.. i didn't want to bog down the focus on USB support in the Git repo to address the USB image issue.. I felt it was some one elses problem

the BIOS looks at the USB MMD devices like NVRAM, USB Flash or SD Cards and either supports them as bootable or not.. they load iPXE which loads a USB host controller driver and then probes for attached USB Ethernet devices.. if it finds one.. that loads an iPXE USB Ethernet device driver..

.. and then I presume if properly configured.. iPXE loads the next stage boot loader from the network (WinPE ntloader?) into RAM.. then releases its memory and jumps to the ntloader.. which boots from its ramdisk, looks for the iPXE undi device driver signature in memory, and loads the WinPE undi device driver.. they mate.. and become the UNDI driver for WinPE that just happens to be attached to a USB Ethernet device already started.. and continue to pass traffic

I don't really know if the current undionly.kpxe support is completely in 32 bit space, or if somehow it expects the replacement kernel to "adopt" the iPXE driver code and provide runtime cycles for it.. the old 16 bit version kind of left it running in 16 bit space as a Terminate Stay Resident stub that got calls and woke up to process network traffic and went to sleep while the 32 bit OS was running.. it was more a high load "polling" mechanism flipping back and forth to catch and resend missed packets. I feel almost certain they do it a different way now.

You would almost need a kind of virtual machine environment that shared the environment back and forth.. the new OS in one vm, the old UNDI driver code running in a second.. and they mtually communicate through the UND Interface.. I just don't know .. but its intensely interesting (of course that Apes or Mimicks the original TSR model and used the DOS and Windows environment as virtual machines.

I will look into it.

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.

That is very interesting that it pulled an IP.. I seem to recall having a second nic be detected in addition to the one I thought I was booting from and after it failed on the asix it tried to dhcp from that.. unfortunately it was vmware virtual nic and wasn't of practical use.

But that is promising, maybe your right that it is some other subsystem failing. Were I in your shoes I would be using Wireshark to observe the traffic and make sure of what I was seeing, and maybe even witnessing what is failing in the protocol or timing. I guess that assumes you have one end in a virtual machine.. or a passive hub, or monitor port on a switch where you can observe the network traffic.