ASIX USB to Ethernet
|
2014-09-23, 06:16
(This post was last modified: 2014-09-23 06:59 by jwillis84.)
Post: #39
|
|||
|
|||
RE: ASIX USB to Ethernet
(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. 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 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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)