(2014-08-19 20:09)tohtoris Wrote:  Hi jwillis84,

I would be interest to try out pxe booting a Lenovo Yoga 2 pro with asix based Lenovo usb dongle.

I tried building you ipxe branch on a 64bit Ubuntu 14.04 but ran in to a problem.

Code:

git clone -b usb-net-drivers https://github.com/johntwillis/ipxe
cd ipxe/src/
make bin/ipxe.iso ####    same result with make bin/asix.iso
....
.....
[BUILD] bin/tg3_phy.o
[BUILD] bin/asix.o
drivers/net/usb/asix.c: In function ‘asix_get_phy_addr’:
drivers/net/usb/asix.c:151:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  DBG("asix_get_phy_addr() returning 0x%04x\n", *((uint16_t *)buf));
  ^
drivers/net/usb/asix.c: In function ‘asix_poll’:
drivers/net/usb/asix.c:281:20: error: variable ‘packet’ set but not used [-Werror=unused-but-set-variable]
  uint8_t *buffer, *packet;
                    ^
drivers/net/usb/asix.c: In function ‘asix_88178_probe’:
drivers/net/usb/asix.c:410:6: error: variable ‘gpio0’ set but not used [-Werror=unused-but-set-variable]
  int gpio0 = 0;
      ^
cc1: all warnings being treated as errors
make: *** [bin/asix.o] Virhe 1
antti@vonwright:~/devel/ipxe/src$

Would you happen to have any idea what could be wrong?

(2014-08-19 20:09)tohtoris Wrote:  Hi jwillis84,

I would be interest to try out pxe booting a Lenovo Yoga 2 pro with asix based Lenovo usb dongle.

I tried building you ipxe branch on a 64bit Ubuntu 14.04 but ran in to a problem.

Would you happen to have any idea what could be wrong?

(2014-09-02 08:28)jwillis84 Wrote:  I just pushed changes to the Git repository, it will now finish compiling on 64bit Ubuntu 14.04.1 LTS.

(2014-09-08 17:31)jwillis84 Wrote:  Currently the driver will not recognize your device and load.

The line above says your device id should be:

USB_ROM(0x17ef, 0x7203, "asix", "Lenovo U2L 100-Y1", 0),

In the ipxe/src/drivers/usb/net/usb/asix.c source code file.

The USB_ROM strings are used to "recognize" a device that is connected to the USB host controller.

(2014-09-09 06:36)tohtoris Wrote:  Hi, just a quick reply

(2014-09-08 17:31)jwillis84 Wrote:  Currently the driver will not recognize your device and load.

The line above says your device id should be:

USB_ROM(0x17ef, 0x7203, "asix", "Lenovo U2L 100-Y1", 0),

In the ipxe/src/drivers/usb/net/usb/asix.c source code file.

The USB_ROM strings are used to "recognize" a device that is connected to the USB host controller.

I tried making the following change by myself to src/drivers/net/usb/asix.c

Code:

static struct usb_device_id asix_88772_ids[] = {
        USB_ROM(0x2001, 0x3c05, "asix", "DLink DUB-E100", 0),
        USB_ROM(0x0b95, 0x772a, "asix", "ASIX AX88772A", 0),
        USB_ROM(0x17ef, 0x7203, "asix", "Lenovo U2L 100-Y1", 0),
};

Maybe I added the string to a wrong place or something else also needs changes, but with this modification I still got same results. I+ ll take a look at this again later.

By the way here's another asix adapter for you from my colleques desk

Code:

[333676.600058] usb 1-7: new high-speed USB device number 7 using ehci-pci
[333676.738255] usb 1-7: New USB device found, idVendor=0b95, idProduct=1790
[333676.738263] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[333676.738267] usb 1-7: Product: AX88179
[333676.738271] usb 1-7: Manufacturer: ASIX Elec. Corp.
[333676.738274] usb 1-7: SerialNumber: 00000000000241
[333677.170272] ax88179_178a 1-7:1.0 eth1: register 'ax88179_178a' at usb-0000:00:1d.7-7, ASIX AX88179 USB 3.0 Gigabit Ethernet, 1a:2b:3c:4d:62:f3
[333677.172493] usbcore: registered new interface driver ax88179_178a

(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?

(2014-09-12 04:08)jwillis84 Wrote:  

(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.

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?

(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.

Quote:[87658.231359] usb 3-2.4: new high-speed USB device number 30 using xhci_hcd
[87658.272752] usb 3-2.4: New USB device found, idVendor=05ac, idProduct=1402
[87658.272758] usb 3-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[87658.272763] usb 3-2.4: Product: Apple USB Ethernet Adapter
[87658.272766] usb 3-2.4: Manufacturer: Apple Inc.
[87658.272769] usb 3-2.4: SerialNumber: 2D8CB1
[87658.633762] asix 3-2.4:1.0 eth1: register 'asix' at usb-0000:08:00.0-2.4, ASIX AX88772 USB 2.0 Ethernet, 487:05:e9:40:52
[87663.795160] asix 3-2.4:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xCDE1

(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.

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

(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.