OpenBSD on a Dell XPS 13 7390

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 start function.

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 printf there.

After that, the kernel seems to crash before reaching the call of cn_init in init_x86_64.

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;")
		

$Author: gbe $ $Date: 2019/10/24 18:28:16 $ $Revision: 1.10 $