Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
LOADER.EFI(8)		    System Manager's Manual		 LOADER.EFI(8)

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 se-
       lected by specifying "efi" using	the console variable.  loader.efi  ex-
       amines 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 ser-
       ial 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  ser-
       ial  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  con-
       soles  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
       Though 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
       And the following flags determine the primary console:

	     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 oth-
       erwise.

   Staging Slop
       The kernel must parse the firmware memory map tables to know what  mem-
       ory  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.

	     Note. BIOS	loaders	on i386	and amd64 put the staging area start-
	     ing at the	physical address 2M, then enable paging	with identical
	     mapping for the low 1G.  The initial port of 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.  Applica-
	     tions like	loader.efi must	only use memory	explicitly allocated
	     using boot	interfaces.  The original way also potentially de-
	     stroyed 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 com-
       mand  produces  a  fault	in the loader.efi environment for testing pur-
       poses, 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
       loader(8), uefi(8)

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.

FreeBSD	13.2		       September 4, 2022		 LOADER.EFI(8)

NAME | DESCRIPTION | FILES | EXAMPLES | SEE ALSO | BUGS

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=loader.efi&manpath=FreeBSD+14.0-RELEASE+and+Ports>

home | help