The machine is a plain UEFI laptop without any support for enabling CSM, or "Legacy Boot".
This is an ongoing project. Right now, booting fails because the EFI boot loader hangs after printing the kernel load address:
entry point at 0x1001000
FreeBSD and Linux both boot on the machine. The following dumps were made on Ubuntu 19.10:
-rw-r--r-- 1 gbe gbe 1610695 Oct 21 20:53 acpidump -rw-r--r-- 1 gbe gbe 101838 Oct 21 20:51 dmesg -rw-r--r-- 1 gbe gbe 29907 Oct 21 20:52 dmidecode
One of the main differences between how OpenBSD and FreeBSD boot seems to be that on FreeBSD, the boot loader is
responsible for entering long mode on
x86_64, while on OpenBSD, that is one of the first things the
kernel does in its
Right now, I'm waiting for a Intel DCI USB debug cable to see where exactly the kernel hangs. This is the user manual for that stuff.
For further debugging, I may have to re-enable DCI in the kernel. This shouldn't matter right now, because the code that seems to cause problems runs way before the code that disables DCI.
The last point where some signal of life can be coaxed out of the kernel + boot loader system is exec_i386.c:158
of the boot loader. That is by disabling the EFI cleanup a few lines above and putting a
After that, the kernel seems to crash before reaching the call of
I tried using a reboot caused by a triple fault to determine where it starts hanging, but the EFI implementation of the machine treats triple faults and reboots via poking the keyboard controller by hanging instead. This indicates that what I'm seeing may be some sort of unhandled triple fault instead of a regular old hang. The debug cable will likely shine some light on the details here.
For reference, the code I used for inducing the triple faults were variations of this:
asm volatile("lidt 0; int3;")