Tablet PC hangs on bzImage
-
@Sebastian-Roth said in Tablet PC hangs on bzImage:
Maybe we just need to figure out the USB IDs of your adapter to make it work. Can you figure those out in Windows device manager? device manager -> right click the ethernet adapter -> properties -> details -> select property Hardware Ids
Ah, thank you. I finally found it.
Under Hardware IDs it showsUSB\VID_0B95&PID_1790&REV_0100
USB\VID_0B95&PID_1790 -
@Zerpie Might be some hope at the horizon. The IDs do match so we just need to figure out why iPXE is not using this native driver but SNP driver stack instead. From my understanding (though I am not an iPXE developer but just have been playing with it for a fair while) iPXE mostly uses native drivers if available.
Looking through the axge.c driver code I found this:
* * Asix 10/100/1000 USB Ethernet driver * * Large chunks of functionality are undocumented in the available * datasheets. The gaps are deduced from combinations of the Linux * driver, the FreeBSD driver, and experimentation with the hardware. */
Sounds promising, hmm?
Seems like a different make target needs to be used to enable the native driver for USB network adapters (ref). Maybe try
make bin-i386-efi/ncm--ecm--axge.efi EMBED=shell.txt
and on boot:ipxe> dhcp net0 ... ipxe> ifstat ...
-
If it’s recognized as USB you may want to turn on
has_usb_nic=1
as a kernel argument.https://wiki.fogproject.org/wiki/index.php?title=USB_NIC_(usb_network_adapter)
Potentially this will get you a bit further already with the default binaries.
-
@Sebastian-Roth said in Tablet PC hangs on bzImage:
Maybe try make bin-i386-efi/ncm–ecm–axge.efi EMBED=shell.txt and on boot:
Once I run that command do I need to move the file over to /tftpboot/i386-efi as well? Will it know to boot from that file? Sorry, I’ve had to put this project on the back burner for a while and now that I’m coming back to it it’s hard to pick up again where I left off.
-
@Zerpie Yes, you need to copy the new binary over. From my point of view it’s easiest to rename it on copy so you won’t have to change DHCP config as well. But be aware that other clients could boot from this as well and might fail.
cp path_to_ipxe_code/src/bin-i386-efi/ncm–ecm–axge.efi /tftpboot/i386-efi/ipxe.efi
-
@Sebastian-Roth Ok so I tried the new binary, but when it drops me to the ipxe shell everything locks up and I’m not able to enter any commands. I can’t even enter a ctrl+alt+del to restart the tablet.
-
@Zerpie Too bad. Not really sure what else we can try. Firmware upgrade for that tablet available by any chance?
Try enabling debug
make bin-i386-efi/ncm--ecm--axge.efi EMBED=shell.txt DEBUG=ncm,ecm,axge
, copy the binary over, try again and see if you get any further output on screen that could help us. -
@Sebastian-Roth said in Tablet PC hangs on bzImage:
Try enabling debug make bin-i386-efi/ncm–ecm–axge.efi EMBED=shell.txt DEBUG=ncm,ecm,axge, copy the binary over, try again and see if you get any further output on screen that could help us.
Same results. It drops me to the ipxe shell and doesn’t accept any input from the keyboard. There’s no firmware upgrade available either.
-
@Zerpie I think we should start looking into other ways of booting this tablet. George posted a great manual on how to build a bootable USB medium:
https://forums.fogproject.org/topic/7727/building-usb-booting-fos-imageSure this is not perfect but give it a try to see if we can get ahead of iPXE not being able to boot this tablet.
-
@Sebastian-Roth That’s a shame. I was hoping we’d be able to find a network boot solution for imaging the tablets as we typically have to image several at once for orders. I haven’t found any imaging or cloning software with network boot/PXE boot that works with this tablets. We’re currently using a USB boot option already which works, but we still have to do one at a time.
-
@Zerpie Did you ever end up trying the
has_usb_nic=1
kernel argument? -
@Zerpie You can also try booting from the ipxe shell, which if isn’t built in to the tablet as a boot option (sometimes it is sometimes it isn’t) then you can make a rEFInd usb disk and add all the ipxe efi boot options. Then you can create a startup.nsh script that will switch to the fs#: of the usb drive and then boot to whichever 32 bit ipxe file ends up working. It would be tricky and still involve usb drives but you could in theory make it work.
Another possibility would be to customize fog’s built in refind for those tablets if that happens to be booted to successfully (i.e. if boot to hard drive from the fog menu is working). You could change the default boot settings, I believe you can add some conditions to it, I know you can do it to have different times of the day have different default boot options. So one possibility would be to add the refind efi shell to the fog refind.conf boot options and make it the default during some time slot you are going to image and just also find a way to link a startup.nsh script. I haven’t actually tested this idea, it’s just another possibility if you want network boot to work. But all of that is nill if none of the ipxe efi boot files get you through bzimage32 boot.
-
There is a couple of points here.
- I’ve seen issues with some 32 bit tablets (the models escape me at the moment), in that they have a 64 bit processor, but the processor has been hardware locked in 32 bit mode. iPXE will detect its a 64 bit process (because it really is) and send the wrong iPXE kernel to the target computer. I have not check, but you might be able to bypass this auto detection by specifically calling out bzImage32 in the host configuration properties.
- FOG doesn’t currently include refind 32 bit at part of the package. Only refind 64 bit is included. This will cause a problem when exiting from the iPXE menu in that the wrong refind kernel will try to boot and fail.
I can’t say that either of these are the specific case here, but I have seen issues before with 32 bit tablets.
-
@Quazz said in Tablet PC hangs on bzImage:
@Zerpie Did you ever end up trying the
has_usb_nic=1
kernel argument?I did. Still no luck.
-
@george1421 @JJ-Fullmer We have been through a lot of debugging with this and after we have hunted down the kernel it turned out to be a stupid network driver issue. iPXE does not seem to use a native driver for the ASIX AX88179 USB 3.0 adapter but the more general SNP. For whatever reason this ASIX chip does not play by the rules and network connection stalls after it started to transfer the first bytes of the kernel binary (seen in wireshark dumps!). Just to give you a quick heads up on what we’ve been into so far.
@Zerpie Would it be an option to use a different USB network adapter? I know you’ve tried three different ones. But maybe there are more out there. Other than that it would be a case of getting into the source code and trying to debug either when this NIC doesn’t want to play propery SNP or try to get the AXGE driver to work… For me it’s very hard to tell which way could be the more promising. Not having your hardware here I can’t even do any testing myself.
EDIT: I just re-read that post in the iPXE forums where I got the information about how to build a binary with native AXGE driver included and saw this:
When building the ipxe target, drivers for usb devices is not included (due to it disabling all other connected USB devices)
Sorry for obviously having overlooked this important information. So I guess it does not hang at all but just sits there waiting for input and is not getting any as USB devices are shut off. So instead of the simple
shell.txt
create a new text filedhcp.txt
with the following content:#!ipxe ifopen net0 dhcp net0 chain tftp://${next-server}/default.ipxe
Then compile and copy the new binary:
make bin-i386-efi/ncm--ecm--axge.efi EMBED=dhcp.txt cp path_to_ipxe_code/src/bin-i386-efi/ncm–ecm–axge.efi /tftpboot/i386-efi/ipxe.efi
-
@Sebastian-Roth Ok I gave that a try and now it’s back what I was getting before.
BzImage_debug... ok Could not select: Exec format error (http://ipxe.org/2e008081) Could not boot: Exec format error (http://ipxe.org/2e008081) Could not boot: Exec format error (http://ipxe.org/2e008081)
And then it just continues to boot into the OS.
-
I probably should have posted this a while back. I’m not sure if it’ll help, but it’ll at least be good to know what we’re working with. The device is a Touch Dynamics Quest 7 Tablet mobile POS (point of sale).
https://www.touchdynamic.com/products/mobile-pos-tablets/quest-tablet-and-premium-dock/
There’s not a whole lot out there about it that I could find.
-
@Zerpie Are you sure we have had the
Exec format error
before? As far as I remember we only got to the point where it would hang on bzImage. Now the exec Format error could actually be what George said, a CPU being pinned to 32 bit mode. In the host’s settings change Kernel setting tobzImage32
and see if that makes a difference… -
@Sebastian-Roth Yup. I got these errors at some point before and posted about it earlier in the thread.
Ok I could have sworn I tried it with bzimage32 set for Host Kernel earlier today, but I just tried it now and I got a little further. It gave me a whole page of text and it looked like it was going to work but then it stopped and I see these lines at the bottom.
Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. Kernel Offset: disabled ---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
-
Ok I still had debug earlyprintk=efi loglevel=7 set in the Host Kernel Arguments so I cleared that out and tried again. I didn’t get the wall of text this time, just the Kernel panic. Here’s everything I see.
Starting init: /sbin/init exists but couldn't execute it (error -8) Starting init: /bin/sh exists but couldn't execute it (error -8) Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. Kernel Offset: disabled ---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.