NAME
loader.efi
—
UEFI kernel loader
DESCRIPTION
On UEFI systems, loader.efi
loads the
kernel.
boot1.efi(8) is used to load
loader.efi
when it is placed within a UFS or ZFS
file system. Alternatively, loader.efi
is used
directly when configured with
efibootmgr(8), or when placed directly as the default boot
program as described in
uefi(8). When a system is built using
bsdinstall(8), loader.efi
will be
used directly.
Console Considerations
The EFI BIOS provides a generic console. In
loader.efi
this is selected by specifying
“efi” using the console
variable.
loader.efi
examines the
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
UEFI
environment variable to guess what the “efi” console points
to. loader.efi
will output its prompts and menus to
all the places specified by ConOut. However, the
FreeBSD kernel has a limitation when more than one
console is present. The kernel outputs to all configured consoles. Only the
primary console will get the log messages from the
rc(8) system, and prompts for things like
geli(8) passwords. If loader.efi
finds a video device first, then loader.efi
tells
the kernel to use the video console as primary. Likewise, if a serial device
is first in the ConOut
list, the serial port will be
the primary console.
If there is no ConOut
variable, both
serial and video are attempted. loader.efi
uses the
“efi” console for the video (which may or may not work) and
“comconsole” for the serial on COM1
at
the default baud rate. The kernel will use a dual console, with the video
console primary if a UEFI graphics device is detected, or the serial console
as primary if not.
On x86 platforms, if you wish to redirect the loader's output to a
serial port when the EFI BIOS doesn't support it, or to a serial port that
isn't the one the EFI BIOS redirects its output to, set
console
to “comconsole”. The default
port is COM1
with an I/O address of 0x3f8.
comconsole_port
is used to set this to a different
port address. comconsole_speed
is used to set the of
the serial port (the default is 9600). If you have
console
set to “efi,comconsole” you
will get output on both the EFI console and the serial port. If this causes
a doubling of characters, set console
to
“efi”, since your EFI BIOS is redirecting to the serial port
already.
If your EFI BIOS redirects the serial port, you may need to tell
the kernel which address to use. EFI uses ACPI's UID to identify the serial
port, but loader.efi
does not have an ACPI parser,
so it cannot convert that to an I/O port. The
FreeBSD kernel initializes its consoles before it
can decode ACPI resources. The FreeBSD kernel will
look at the hw.uart.console
variable to set its
serial console. Its format should be described in
uart(4) but is not. Set it to
“io:0x3f8,br:115200” with the proper port address. PCI or
memory mapped ports are beyond the scope of this man page.
The serial ports are assigned as follows on IBM PC compatible systems:
Windows Name | I/O Port Address | Typical FreeBSD device |
COM1 | 0x3f8 | /dev/uart0 |
COM2 | 0x2f8 | /dev/uart1 |
COM3 | 0x3e8 | /dev/uart2 |
COM4 | 0x2e8 | /dev/uart3 |
COM3
and COM4
can vary.
Primary Console
The primary console is set using the boot flags. These command line arguments set corresponding flags for the kernel. These flags can be controlled by setting loader environment variables to “yes” or “no”. Boot flags may be set on the command line to the boot command. Inside the kernel, the RB_ flags are used to control behavior, sometimes in architecturally specific ways and are included to aid in discovery of any behavior not covered in this document.
boot flag | loader variable | Kernel RB_ flag |
-a |
boot_askme |
RB_ASKNAME |
-c |
boot_cdrom |
RB_CDROM |
-d |
boot_ddb |
RB_KDB |
-r |
boot_dfltroot |
RB_DFLTROOT |
-D |
boot_multiple |
RB_MULTIPLE |
-m |
boot_mute |
RB_MUTE |
-g |
boot_gdb |
RB_GDB |
-h |
boot_serial |
RB_SERIAL |
-p |
boot_pause |
RB_PAUSE |
-P |
boot_probe |
RB_PROBE |
-s |
boot_single |
RB_SINGLE |
-v |
boot_verbose |
RB_VERBOSE |
Flags | Kernel Flags | Kernel Consoles | Primary Console |
none | 0 | Video | Video |
-h |
RB_SERIAL | Serial | Serial |
-D |
RB_MULTIPLE | Serial, Video | Video |
-Dh |
RB_SERIAL | RB_MULTIPLE | Serial, Video | Serial |
loader.efi
does not implement the probe
-P
functionality where we use the video console if a
keyboard is connected and a serial console otherwise.
Staging Slop
The kernel must parse the firmware memory map tables to know what
memory it can use. Since it must allocate memory to do this,
loader.efi
ensures there's extra memory available,
called “slop”, after everything it loads (the kernel, modules
and metadata) for the kernel to bootstrap the memory allocator.
By default, amd64 reserves 8MB. The
staging_slop
command allows for tuning the slop
size. It takes a single argument, the size of the slop in bytes.
amd64 Nocopy
loader.efi
will load the kernel into
memory that is 2MB aligned below 4GB. It cannot load to a fixed address
because the UEFI firmware may reserve arbitrary memory for its use at
runtime. Prior to FreeBSD 13.1, kernels retained the
old BIOS-boot protocol of loading at exactly 2MB. Such kernels must be
copied from their loaded location to 2MB prior starting them up. The
copy_staging
command is used to enable this copying
for older kernels. It takes a single argument which can be one of
- disable
- Force-disable copying staging area to 2M.
- enable
- Force-enable copying staging area to 2M.
- auto
- Selects the behaviour based on the kernel's capability of boostraping from non-2M physical base. The kernel reports this capability by exporting the symbol kernphys.
Arm64 loaders have operated in the ‘nocopy’ mode
from their inception, so there is no copy_staging
command on that platform. Riscv, 32-bit arm and arm64 have always loaded at
any 2MB aligned location, so do not provide
copy_staging
.
loader.efi
followed the same scheme for handing
control to the kernel, since it avoided modifications for the loader/kernel
hand-off protocol, and for the kernel page table bootstrap.
This approach is incompatible with the UEFI specification, and as
a practical matter, caused troubles on many boards, because UEFI firmware is
free to use any memory for its own needs. Applications like
loader.efi
must only use memory explicitly allocated
using boot interfaces. The original way also potentially destroyed UEFI
runtime interfaces data.
Eventually, loader.efi
and the kernel were
improved to avoid this problem.
amd64 Faults
Because it executes in x86 protected mode, the amd64 version of
loader.efi
is susceptible to CPU faults due to
programmer mistakes and memory corruption. To make debugging such faults
easier, amd64 loader.efi
can provide detailed
reporting of the CPU state at the time of the fault.
The
grab_faults
command installs a handler for faults
directly in the IDT, avoiding the use of the UEFI debugging interface
EFI_DEBUG_SUPPORT_PROTOCOL.RegisterExceptionCallback
().
That interface is left available for advanced debuggers in the UEFI
environment. The ungrab_faults
command tries to
deinstall the fault handler, returning TSS and IDT CPU tables to their
pre-installation state. The fault
command produces a
fault in the loader.efi
environment for testing
purposes, by executing the ud2
processor
instruction.
FILES
- /boot/loader.efi
- The location of the UEFI kernel loader within the system.
EFI System Partition
loader.efi
is installed on the ESP (EFI
System Partition) in one of the following locations:
- efi/boot/bootXXX.efi
- The default location for any EFI loader (see
uefi(8) for values to replace
‘
XXX
’ with). - efi/freebsd/loader.efi
- The location reserved specifically for the FreeBSD EFI loader.
The default location for the ESP mount point is documented in hier(7).
EXAMPLES
Updating loader.efi on the ESP
The following examples shows how to install a new
loader.efi
on the ESP.
First, find the partition of type “efi”:
# gpart list | grep -Ew '(Name|efi)' 1. Name: nvd0p1 type: efi 2. Name: nvd0p2 3. Name: nvd0p3 4. Name: nvd0p4 1. Name: nvd0
The name of the ESP on this system is nvd0p1.
Second, let's mount the ESP, copy
loader.efi
to the special location reserved for
FreeBSD EFI loaders, and unmount once finished:
# mount_msdosfs /dev/nvd0p1 /boot/efi # cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi # umount /boot/efi
SEE ALSO
BUGS
Systems that do not have a ConOut
variable
set are not conformant with the standard, and likely have unexpected
results.
Non-x86 serial console handling is even more confusing and less well documented.
Sometimes when the serial port speed isn't set, 9600 is used. Other times the result is typically 115200 since the speed remains unchanged from the default.