Lenovo N24 / USB NIC with ASIX AX88772C chip

bloodwar

ASIX AX88772C USB2.0 TO Fast Ethernet Adapter
USB\VID_0B95&PID_772B&REV_0001
USB\VID_0B95&PID_772B

and

ASIX AX88772C USB2.0 TO Fast Ethernet Adapter #2
USB\VID_0B95&PID_772B&REV_0002
USB\VID_0B95&PID_772B

both were taken with the first nic

Sebastian Roth

@bloodwar If I don’t get that wrong from your pictures the issue happens in iPXE already. But did you still try out the kernel I offered to test? Use the plain normal iPXE binary you got with RC10 and set the host’s kernel parameter to debug earlyprintk=efi loglevel=7. Schedule a job, boot it up and see what you get. This is just to make sure we don’t follow the wrong track. I’ll prepare a fresh iPXE debug binary soon as well. But please test the kernel as well to make sure. Here you can find a picture of what you might see on screen…

bloodwar

Alright what i done so far. i tried setting the kernel from
Host general - Host Kernel
but ended up with
could not select: Exec format error (http://ipxe.org/2e0088081)
could not boot: Exec format error (http://ipxe.org/2e0088081)
so i changed the kernel from
FOG Configuration - fog settings - TFTP Server - TFTP PXE KERNEL
and got
kernel 05 and 06 https://i.imgur.com/6E69hnf.jpg
kernel 07 just freezes at init.xz
kernel 08 https://i.imgur.com/O4cU3kU.jpg

silly question but the host kernel parameter goes under Host Kernel Arguments?

Sebastian Roth

@bloodwar Thanks for testing. Looks great. So we do know that iPXE hands over to the Linux Kernel and it’s stuck somewhere there. We can work this out I hope.

Regarding your questions: You can set the kernel global in FOG Configuration… or just for one single host (“Host Kernel” in Host gerneral settings ). I just tested the later and if works for me. Not sure what went wrong. And yes, kernel parameters go in “Host Kernel Arguments”.

I’ll analyse the kernel code now that I have your pictures and hopefully find out what’s wrong. I’ll get back to you as soon as possible.

Sebastian Roth

@bloodwar Just to make sure we are on the right track I want you to test this 08_bzImage kernel booted as EFI binary straight from a USB key. For that get an empty USB key, format with FAT32/VFAT, create directory strcture BOOT/EFI and copy/rename the kernel image file into that directory so it ends up as EFI/BOOT/BOOTX64.EFI. Can be done on Windows or Linux, doesn’t matter.

Unmount/eject the USB key and boot from that on your client. Please take a picture and post here so we can compare the debug message traces.

bloodwar

results
https://i.imgur.com/sx54w5G.jpg

Sebastian Roth

@bloodwar Great, thanks again for testing. So it’s clear this is not an iPXE issue at all but just a crapy UEFI firmware implementation causing this hang (even if you simply boot the Linux kernel in UEFI mode).

At the stage were things seem to go wrong I see the following comment in the kernel code:

                /*
                 * The memory map changed between efi_get_memory_map() and
                 * exit_boot_services().  Per the UEFI Spec v2.6, Section 6.4:
                 * EFI_BOOT_SERVICES.ExitBootServices we need to get the
                 * updated map, and try again.  The spec implies one retry
                 * should be sufficent, which is confirmed against the EDK2
                 * implementation.  Per the spec, we can only invoke
                 * get_memory_map() and exit_boot_services() - we cannot alloc
                 * so efi_get_memory_map() cannot be used, and we must reuse
                 * the buffer.  For all practical purposes, the headroom in the
                 * buffer should account for any changes in the map so the call
                 * to get_memory_map() is expected to succeed here.
                 */

So the kernel is kind of aware of UEFI implementations that toss with the memory map but unfortunately there seems to be special ones that do even more magic. I’ll try to figure out more about this but I guess it will be very hard to find. Although I have done a fair bit of kernel hacking I am not at all a kernel dev or even close to it. So it’s more or less guessing, trying and reading that I can do.

Sebastian Roth

@bloodwar I just uploaded 09_bzImage for you to test. It skips part of the code that I think could be causing the issue on your device. Let’s see what happens. Try it and post a picture again.

bloodwar

used the usb nic instead of usb boot.
https://i.imgur.com/RSFHzB9.jpg

Sebastian Roth

@bloodwar Ok?!? This is interesting. Shows that I don’t have a clue what the Lenovo N24 UEFI firmware is doing here. So just commenting some code doesn’t help.

Searching the web for whatever I found a post where syslinux people are talking about this as well - http://www.syslinux.org/archives/2015-September/024212.html - The implementation proposed here is trying at least twice so I think this is a bit different to how the Linux kernel is handling it at the moment. I’ll try to implement that and let you know.

Sebastian Roth

@bloodwar Ok here we go, please give 10_bzImage a try…

bloodwar

no go… but i feel like your getting closer to it lol
https://i.imgur.com/NQg48i5.jpg

Sebastian Roth

@bloodwar 11_bzImage will try 10 times. Don’t think this helps but it’s easy to test.

bloodwar

11 results https://i.imgur.com/9b0WwQb.jpg

Sebastian Roth

@bloodwar If we can’t make it work this way yet I’d suggest trying a different combination like GRUB + Linux kernel. For that please download usb.img (same download link - 64 MB), get an empty USB key and dump that image to USB like this:

dd bs=1M if=/tmp/usb.img of=/dev/sdX

Make sure you have the correct device filename - could be /dev/sdb or /dev/sdc… After connecting the USB key to your machine wait 5 seconds for it to settle and the run dmesg | tail to see which device name it has.

If you only have a Windows machine at hand you can also use Win32DiskImager to write that image to your USB key.

Then boot your Lenovo N24 of that USB key and see what happens. It has GRUB debug enabled and should loop at that stop where we seem to have a problem on “exit_boot_services”. Though I am not sure this will help. It’s just a test to see if you can boot the kernel straight from a GRUB USB key.

bloodwar

used Win32DiskImager
usb booted
selected “fog official kernel - /boot/bzimage” and “fog debug kernel - /boot/11_bzimage”

same results on both
https://i.imgur.com/I5uPXH3.jpg

Sebastian Roth

@bloodwar Ok, I forgot to add one parameter and therefore it fails. But booting essentially works. Could you please take a video of the start sequence between the point where you hit ENTER after selecting one of the two kernels and where the kernel messages scroll past. I’d like to see the GRUB debug messages! You could even just take a picture of it if you know exactly which debug messages I mean. On the screen it should say something like loader/i386/linux.c ....

bloodwar

i think this is it… first thing that pops up after you select fog default kernel.
https://i.imgur.com/tw5mYSl.jpg
if not i’ll take a video of it

Sebastian Roth

@bloodwar Please plug the USB key back into a running (Windows) machine and edit the file boot\grub2\grub.cfg and add ,mmap to line number 6, so it looks like this:

set myimage=/boot/bzImage
set mydbgimage=/boot/11_bzImage
set myinit=/boot/init.xz
set myloglevel=7
set pager=1
set debug=linux,mmap
set timeout=-1
insmod all_video
...

Boot from that USB key again - now you need to skip through the pages as there are many messages on screen… Best if you can take a steady video of all this.

bloodwar

https://i.imgur.com/LXbIQfu.jpg

seems to be endless if i hold enter

Lenovo N24 / USB NIC with ASIX AX88772C chip

161

12.0k

17.3k

155.2k