UEFI booting FreeBSD/amd64 stable/10 in VirtualBox 4.3.24

VirtualBox 4.3.24 is out, so I wanted to try out the UEFI version of the latest FreeBSD/amd64 stable/10 snapshot. It didn’t go well until I realised something important, however strange it may be.

The boot loader has finished loading the kernel.

Notice how this bootloader looks similar to the one for FreeBSD 4.x. Ah, nostalgia. :P

I let the timer count down to naught.

The kernel is now in charge.

All looks promising until the kernel is out of the cage.

Oh, that’s bad, the kernel crashed.

Sadly, there’s no debug info to give any clues. The crash might be due to Oracle’s implementation of UEFI. Up to this point, the VM was assigned only 2 GiB of memory.

Looking at the project page for FreeBSD’s UEFI support, led me to PR 193672. If we just give the VM enough memory, then the graphical output system is happy, and the kernel finally boots.

4 GiB of memory should suffice.

This made me speculate on the possible causes:

The frame buffer needs its fair share of base memory.
I.e., there’s no dedicated memory for the frame buffer, at least not in Oracle’s implementation, and maybe not in the UEFI spec at all.
Whatever size I set for the simulated graphics subsystem bears no relevance. In this case, the VM has been given 128 MiB of video memory, and 3D acceleration has been enabled.
The 3D acceleration has no relevance either.
The frame buffer could be mapped to such high physical addresses that they are only accessible when sufficient memory is present/installed.
There is no remapping of the frame buffer’s address space to lower physical addresses, and/or an automatic reduction of the frame buffer’s size, when there is less than an ideal amount of base memory available.

Lo and behold, the kernel can finally boot.

The FreeBSD installer is ready to serve.

Now, all I miss is ZFS combined with UEFI booting.

Update 2015-03-07

In the mean time have I had the pleasure of continuing my UEFI experiments at home using VirtualBox and FreeBSD/amd64 stable/10 r279507. The VT console runs pretty fast and gives us a console geometry of 128×48 when VirtualBox gives the VM a graphical geometry of 1024×768. Compare that to the traditional 80×25 console geometry.

Setting VBoxInternal2/EfiGopMode to 2, changes the graphical geometry to 1280×1024, and results in a console geometry of 160×64. A text mode giving only 80×25 is something the future’s kids might never see nor hear of.

VBoxManage setextradata "VM name" VBoxInternal2/EfiGopMode 2

See https://www.virtualbox.org/manual/ch03.html#efividmode for more information.

For some reason X.org only displays 1024×768, whereas it earlier adapted to the full screen size of the VM, e.g. 1280×1024. This happens regardless of BIOS firmware or UEFI firmware on VirtualBox, and despite having everything from emulators/virtualbox-ose-additions installed and running.

Yes, I did try setting VBoxInternal2/UgaHorizontalResolution and VBoxInternal2/UgaVerticalResolution, but to no avail.

VBoxManage setextradata "VM name" VBoxInternal2/UgaHorizontalResolution 1280
VBoxManage setextradata "VM name" VBoxInternal2/UgaVerticalResolution   1024

Here’s the memory map according to the sysctl machdep.efi_map when the VM is given 8 GiB of base memory:

machdep.efi_map:
                   Type     Physical      Virtual   #Pages Attr
     ConventionalMemory 000000000000          0x0 000000a0 UC WC WT WB
     ConventionalMemory 000000100000          0x0 00001f00 UC WC WT WB
       BootServicesData 000002000000          0x0 00000600 UC WC WT WB
     ConventionalMemory 000002600000          0x0 0003d9fc UC WC WT WB
             LoaderData 00003fffc000          0x0 00000004 UC WC WT WB
     ConventionalMemory 000040000000          0x0 0009c000 UC WC WT WB
       BootServicesData 0000dc000000          0x0 00000020 UC WC WT WB
     ConventionalMemory 0000dc020000          0x0 000001a1 UC WC WT WB
             LoaderData 0000dc1c1000          0x0 00002000 UC WC WT WB
       BootServicesData 0000de1c1000          0x0 000003e3 UC WC WT WB
     ConventionalMemory 0000de5a4000          0x0 00000011 UC WC WT WB
             LoaderData 0000de5b5000          0x0 00000201 UC WC WT WB
             LoaderCode 0000de7b6000          0x0 0000004a UC WC WT WB
             LoaderData 0000de800000          0x0 0000004c UC WC WT WB
             LoaderCode 0000de84c000          0x0 0000000f UC WC WT WB
       BootServicesData 0000de85b000          0x0 00000184 UC WC WT WB
    RuntimeServicesCode 0000de9df000          0x0 0000000d UC WC WT WB RUNTIME
       BootServicesData 0000de9ec000          0x0 00000100 UC WC WT WB
     ConventionalMemory 0000deaec000          0x0 0000003f UC WC WT WB
       BootServicesData 0000deb2b000          0x0 00000ec1 UC WC WT WB
     ConventionalMemory 0000df9ec000          0x0 00000003 UC WC WT WB
       BootServicesCode 0000df9ef000          0x0 0000017d UC WC WT WB
    RuntimeServicesCode 0000dfb6c000          0x0 00000030 UC WC WT WB RUNTIME
    RuntimeServicesData 0000dfb9c000          0x0 00000024 UC WC WT WB RUNTIME
               Reserved 0000dfbc0000          0x0 00000004 UC WC WT WB
      ACPIReclaimMemory 0000dfbc4000          0x0 00000008 UC WC WT WB
          ACPIMemoryNVS 0000dfbcc000          0x0 00000004 UC WC WT WB
       BootServicesData 0000dfbd0000          0x0 00000400 UC WC WT WB
    RuntimeServicesData 0000dffd0000          0x0 00000020 UC WC WT WB RUNTIME
     ConventionalMemory 000100000000          0x0 00120000 UC WC WT WB

This list doesn’t mention any memory particularly reserved for the frame buffer, except for the 16384 octets long region marked Reserved, starting at physical address 0xdfbc0000. It’s still out in the blue the real reason for the kernel crashing when there’s little memory available/installed.

Update 2015-03-17

Judging from the attachment 147929 belonging to the PR 194063, it appears as if the EFI frame buffer on HP laptops is mapped to the physical address of 3 GiB.

The address 0xC0000000 bytes being equal to 3221225472 bytes, with 3221225472 bytes ÷ 1024 bytes/KiB = 3145728 KiB, and 3145728 KiB ÷ 1024 KiB/MiB = 3072 MiB, and finally, 3072 MiB ÷ 1024 MiB/GiB = 3 GiB.

With the frame buffer’s size being 0x408000 bytes = 4227072 bytes, 4227072 bytes ÷ 1024 bytes/KiB = 4128 KiB, and the frame buffers dimensions being 1366×768. This should give (4227072 bytes ÷ 1366 columns) ÷ 768 rows ∼ 4.03 bytes/(columns×rows).

This certainly strengthens my theory of the EFI frame buffer being permanently mapped to a high physical address in the range from 3 GiB and above. Thus, we must ensure the system has been given enough base memory to enable the frame buffer in the first place.

Update 2015-03-18

I was able to UEFI boot Microsoft Windows 10 Technical Preview Enterprise 9926 64-bit in VirtualBox 4.3.26. The aim is to attempt dual booting Windows 10 64-bit and FreeBSD/amd64 stable/10 on an emulated UEFI+GPT system. More should soon follow.