ASIX USB to Ethernet

[jwillis84]

Code:

Bus 001 Device 003: ID 17ef:7203 Lenovo

[273388.525211] usb 1-7: New USB device found, idVendor=17ef, idProduct=7203

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.

Basically ipxe "starts" the host controller, then probes for what is attached, it gets id strings back from the connected devices and checks its inventory of drivers, of which the asix.c driver is "one". When it finds a match, it loads that driver and uses it to "start" the device and produces an ethernet interface in ipxe kernel space, which the normal network drivers then see and try to perform dhcp to initialize.. and the rest "as they say" is history.. things just work.

I'll add the string to the source code this evening and push it to git hub.

Your feedback was valuable, and extends the reach of this driver to provide service for other users that have a device like yours.

Its also interesting in that your device is a 1000 Mbps device [ AX88772 ] or 1 Gig Ethernet adapter, where I have only tested with an [ AX 88178 ] which is a 100 Mbps device.

Currently the USB stack for ipxe was designed with 100 Mbps in mind. Since it is based on the Linux USB stack it should only run at USB 2.0 speeds. In theory this should not be a problem, but in practice "anything" could happen. So your results will be very interesting.

iPXE generally is a bootstrapper.. meaning it downloads only a few hundered MBytes before starting another kernel and disk image with more sophisticated USB device drivers.. so speed isn't a major concern.

I am looking into a USB3.0 host controller driver and was going to look into verifying AX88772 support in the near future, but ther are so many branching directions in which I could focus my efforts, pursuing all of them at the same time.. just isn't practical.

USB2.0 host controllers were based on the EHCI device with companion controllers, UHCI and OHCI and pretty much worked transparently as UHCI or OHCI if there wasn't an EHCI driver available.

USB3.0 host controllers got a complete redesign when that spec came out, and Linux rewrote the USB stack it provided to support the higher speeds. The XHCI device was an attempt to cleanup and simplify the device driver requirements, but it appears the vendors successfully (to them) made each implementation of XHCI unique to the vendors that more than one XHCI device driver will be necessary.

Exasperating...

I tend to agree that more USB2.0 device drivers are far more important at this instance in time, but reality is more XHCI host controllers will be appearing on laptop and desktop motherboards in the near future.