PXE Boot HP X2 210 (Hybrid tablet Windows 10 Pro)

[Sebastian Roth]

@Matthieu-Jacquart Here we go, get the new kernel image called bzImage_mj (just making up those extensions). Looking forward to what we will see.

[Matthieu Jacquart]

@Sebastian-Roth Oh my personalized kernel, nice

Here you are

[Sebastian Roth]

Ok, this is exactly where it hangs: http://lxr.free-electrons.com/source/arch/x86/boot/compressed/eboot.c#L473 (memcpy but allocation of memory seams fine further up in the code)

We’ll see if iPXE devs can help with this or we will need to get in contact with kernel devs as well. I am following this and will keep you all posted.

@Matthieu-Jacquart Meanwhile I’d ask you to try booting the bzImage_mj straight as UEFI binary from a USB stick to see if this works. We cannot use GRUB in between to check (I was told by Michael Brown) because “GRUB has the ability […] to treat the kernel as a bzImage rather than an EFI executable. This enters the kernel via a different path, which probably bypasses the code we’re looking at in eboot.c”

This can be done on Linux and Windows:

1. Get an empty USB Stick, partition with one full primary partition (most probably already done!)
2. Format with FAT32
3. Create X:\EFI\BOOT (or /mnt/EFI/BOOT)
4. copy and rename ‘bzImage_mj’ to X:\EFI\BOOT\bootx64.efi (or /mnt/EFI/BOOT/bootx64.efi
5. Grap your tablet and boot of the USB stick in UEFI mode

If you get past the setup_efi_pci issue you will run into a kernel panic. But that’s ok. We just want to see if there is any difference booting the same kernel in real UEFI mode directly or via iPXE.

[Matthieu Jacquart]

@Sebastian-Roth Ok done, I have exactly same screem than with ipxe boot

[Sebastian Roth]

@Matthieu-Jacquart Thanks a lot for your fast reaction. I somehow thought/hoped this wouldn’t be the case and that it had something to do with iPXE. But from what we see now current main kernel is not able to directly EFI boot on your tablet. I really wonder why we don’t find other people having the same issue. Maybe this is still very new and most people use GRUB (bypassing the kernels efi_init)?!? I am trying to get in contact with kernel devs on this. But I cannot promise anything. Might take some hours but could be weeks as well. I just don’t know. But I am sure we are spot on the issue (which is the main factor for getting it fixed).

[Sebastian Roth]

@Matthieu-Jacquart Just had the idea to try older kernels as well. Would you mind? Just download some older versions and put it on USB as done before. Lets see if any of these works. I doubt it - but it’s valuable information for the kernel devs!

http://sourceforge.net/projects/freeghost/files/KernelList/Kernel.TomElliott.4.1.2.64/download
http://sourceforge.net/projects/freeghost/files/KernelList/Kernel.TomElliott.3.19.3.64/download
http://sourceforge.net/projects/freeghost/files/KernelList/Kernel.TomElliott.3.17.4.64/download

[Matthieu Jacquart]

@Sebastian-Roth Tested but none of them work, screen stays black…

[Sebastian Roth]

Fine then, waiting for some answers. Keeping my fingers crossed. Here if you want to follow:

http://forum.ipxe.org/showthread.php?tid=7938
http://article.gmane.org/gmane.linux.kernel.efi/7361

[Matthieu Jacquart]

@Sebastian-Roth Thanks ! I cross all my fingers too…

[Sebastian Roth]

Michael from the iPXE team asked if I could add some statements to print memory addresses. So I did. Please try booting bzImage_ad via iPXE and from USB stick and take a picture of both. Will be interesting to see if addresses are different. And hopefully Michael can interpret those numbers.

[Tom Elliott]

I found an interesting thing today while trying to narrow down on the kernel panics and testing theories of mine to what that issue may be.

My guess, most of the kernel panic’s are due to e1000e driver, though the physical nic is stated not to pose a problem, vmware e1000e does cause a kernel panic for me.

While trying to figure this out, I noticed my screens had a ton more info that most others. Thinking it was just differences in the loglevel fields, I decided to test it by setting my loglevel to 0. When I did this the value was blank in db and to browser there was a MORE messages than with loglevel set to 4. I fixed this issue as I want to always have a value defined, and in doing so it actually gave the proper value.

Why here do I write this? Because with a loglevel=0 set, it doesn’t return ANYTHING to the screen.

Can you update the loglevel setting on your server to the highest value? Maybe we’ll actually see info.

[Sebastian Roth]

@Tom-Elliott Interesting find but I think this is not the case here. The screen stayed mostly blank even when Matthieu typed all the kernel parameters by hand (loglevel=7!). The kernel on his HP tablet freezes very early and we were able to get some output by adding statements to the kernel code. If you have 10 minutes read through the last 30 posts to see what we are up to.

[Matthieu Jacquart]

@Sebastian-Roth ok done, but I saw no difference (I put loglevel to 7 in fog interface, just in case)

USB

iPXE

[Tom Elliott]

@Sebastian-Roth Very true. I just was hoping to see default behavior play a little bit better.

[Sebastian Roth]

@Matthieu-Jacquart Ok, got some news. Hope you are still keen to keep on trying out things. Will be several tests and I will post a short message for each to not mix things up.

First please move your original ipxe.efi binary, download this (DEBUG=efi_wrap with some added dump code within HandleProtocol function) and put in place. This is with full embedded script so you don’t have to type all the commands in iPXE shell. Hope we still see the output! Boot your tablet on this using any of the kernels. Doesn’t really matter which one as they all fail on the same issue. Please take a picture of the screen when it freezes. Don’t need a video or several pictures of the whole process.

[Sebastian Roth]

Ok, then I started to think about quick fixing the issue right in the kernel. The first try is to entirely skip the EFI PCI setup thing. I had the idea because when EFI boot was added to the kernel this PCI setup was not part of it but added later. From what I understand about this the setup code is mostly just loading optional PCI ROM BARs. Skipping this some PCI devices won’t work in the worst case I hope.

You might want to leave the debug ipxe.efi in place - shouldn’t hurt - and use bzImage_sp. There might be other things happening. I have no idea. I booted this kernel in my virtual QEMU test environment fine and hopefully it will boot up on your tablet just as well.

[Matthieu Jacquart]

@Sebastian-Roth Ok, I’ll test this on monday ! Great thanks

[Sebastian Roth]

And number three. Another kernel fix that might address the issue a bit better than just skipping the whole EFI PCI setup. Again, I am not sure what’s the outcome of this. But it can’t be much worse than what we have now. Possibly this check can prevent the issue on your tablet. Try bzImage_rb that you find in the same shared gdrive folder.

[Sebastian Roth]

@Matthieu-Jacquart Seams like we are pushing this quite far. Michael from iPXE now contacted people at HP (responsible for that particular UEFI firmware build) to see what they might know about this. Might be a firmware bug. We will see.

From the things I posted the ipxe.efi binary with more dump code added is the most important! This might be helpful information. Please get into this first on Monday.

And there is one more thing that just came to my mind. Have you tried all these things on one of your tablets only? Could you please do the USB stick test on at least two or three other devices to make sure we see the same issue and address/size values on all of them!!!

[Matthieu Jacquart]

@Sebastian-Roth From beginning I always made each test on 2 tablets, I hope it’s good enough

ok first one with ipxe file (DEBUG=efi_wrap…)