Notice how this bootloader looks similar to the one for FreeBSD 4.x. Ah, nostalgia.
I let the timer count down to naught.
All looks promising until the kernel is out of the cage.
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.
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.
Now, all I miss is ZFS combined with UEFI booting.
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.
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/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.
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.
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.