Move direct call of ExitBootServices to efi_exit_boot_services. This
function sets boot_services_active to false so callers don't have to do
it everywhere (though currently only loader/bootinfo.c is affected).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D32226
This makes GOP not probed on some situation (AMD Card on PCIe slot
with EDK2 as we have a SERIAL_IO_PROTOCOL compatible uart).
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D32992
Sponsored by: Beckhoff Automation GmbH & Co. KG
Printing the EFI_HANDLE pointer isn't very useful.
If the handle have a IMAGE_DEVICE_PATH or a DEVICE_PATH protocol print it.
This makes it easier to see which devices are present and what protocol they
expose.
Reviewed by: imp, tsoome
Differential Revision: https://reviews.freebsd.org/D32991
Sponsored by: Beckhoff Automation GmbH & Co. KG
Turn the presence or absence of boot services into a positive bool (and
change its type to bool). Move declaration to efi.h in the global
variables section.
Sponsored by: Netflix
Reviewed by: tsoome, kib
Differential Revision: https://reviews.freebsd.org/D31814
Booting on an EC2 c5.xlarge instance, this reduces the number of I/Os
performed from 609 to 432, reduces the total number of blocks read
from 61963 to 60797, and reduces the time spent in the loader by 39 ms.
Note that b4cb3fe0e3 allowed the bcache to be retained for most of
the boot process, but relies on mounting filesystems; this commit
allows the bcache to be retained at the start of the boot process,
before the root filesystem has been located.
Reviewed by: imp, tsoome
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D32239
The definition for 'ST' is in efilib.h, so we don't need extern ST here.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D32225
We want to keep our root file system open to preserve bcache segment
between file accesses, thus reducing physical disk IO.
Reviewed by: imp, allanjude, kevans (previous version)
Differential Revision: https://reviews.freebsd.org/D30848
MFC after: 1 month
When Boot Services (BS) are switched off, we can not use BS
functions any more. Since drawn console does implement our own
Blt(), we can use it to draw the console.
However, SimpleTextOutput protocol based console output must be
blocked.
Tested by inserting printf() after ExitBootServices() call.
MFC after: 1 week
We need to round it up to 2M, for instance. Having staging area too small
might cause the first resize to use negative size for memmove()/memcpy(),
which kills loader.
Tested by: Harry Schmalzbauer <freebsd@omnilan.de>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
The definition can be overridden by users, and before f75caed644 it
was in MBs. Make the symbol' unit MB, to be compatible with users
customizations.
Reported and tested by: Harry Schmalzbauer <freebsd@omnilan.de>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
On amd64, add a possibility to activate kernel with staging area in place.
Add 'copy_staging' command to control this. For now, by default the
old mode of copying kernel to 2M phys is retained. It is going to be
changed in several weeks.
On amd64, add some slop to the staging area to satisfy both requirements
of the kernel startup allocator, and to have space for minor staging data
increase after the final size is calculated. Add a new command
'staging_slop' to control its size.
Improve staging area resizing, in particular, reallocate it anew if
we cannot grow it neither down nor up.
Reviewed by: kevans, markj
Discussed with: emaste (the delivery plan)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31121
In my initial testing, these are the functions which showed up as
being worth instrumenting. More may be added later.
common/console.c: cons_probe
common/gfx_fb.c: read_list, insert_font, autoload_font
common/interp.c: interact
common/interp_lua.c: interp_init, interp_run
efi/libefi/efipart.c: efipart_readwrite
i386/libi386/biosdisk.c: bd_init, bd_open, bd_edd_io, bd_chs_io, bd_io
libsa/open.c: open
libsa/read.c: read
libsa/twiddle.c: twiddle
Note that profiling interp_run may be of questionable utility as it
may depend on user behaviour (e.g. pressing keys).
Reviewed by: kevans (earlier version)
It exist on all ARMv8+ CPUs, and other boot loaders rely on it being
present.
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D30410
There is no need to call it evert 10ms when we need 1s granularity.
Update to update the time every second.
Reviewed by: imp, manu, tsoome
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D30227
When VECTX is enabled as a kernel option and non-EFI loaders are
built, many reads will fail due to the mis-match of whether
LOADER_VERIEXEC_VECTX or not in readin.h. Source that includes
bootstrap.h must ensure the kernel option agrees with the compile
time CFLAGS in the various make related files.
Submitted by: bret_ketchum@dell.com (original revision)
Reviewed by: sjg, bdrewery, dab, bret_ketchum@dell.com
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29993
Until now, the boot image can be embedded into the loader with
/sys/tools/embed_mfs.sh, and memory disk (MD) is already supported
in loader source. But due to memory disk (MD) driver isn't registered
to the loader yet, the boot image can't be boot from embedded memory
disk.
Reviewed by: dab, tsoome
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29512
Add a man page for gptboot.efi. Describe when and how to use this as it differs
from the BIOS cases. Include cross reference for the preferred method described
in efibootmgr(8) as well as cross links in both gptboot(8) and gptboot.efi(8) to
the other.
This man page was heavily copied from the gptboot.8 man page by Warren Block.
They are different enough to need separate man pages for clarity, but there's
enough similarity that I worry about the duplication. In the really long term,
gptboot(8) will disappear, so having the same info here will help when that
day comes. In the short to medium term, the information is likely to not
change in gptboot(8) and any changes to gptboot.efi(8) will be easier to
make in a separate copy.
loader.efi(8) needs a complete rewrite from scratch, otherwise I'd have
referenced gptboot.efi(8) from there.
Suggetions from: cress@, mhorne@
Reviewed by: rpokala@
Differential Revision: https://reviews.freebsd.org/D29591
This makes bi_load_efi_data cleaner to add common acpi setup code.
Reviewed by: imp, tsoome
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D28936
Calculate font size from 16 density independent pixels (dp) by using:
size = 16 * ppi/160 * display_factor
We are specifying font size 16dp, and assuming 1dp = 160ppi.
Also apply scaling factor 2 (display_factor).
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28849
Check whether we have reached the end of the buffer using search_size
instead of MULTIBOOT_SEARCH, which is the maximum defined by the
specification, but the file can be shorter than that.
This prevents printing a harmless error message when loading a file
that is smaller than MULTIBOOT_SEARCH.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Fixes: adda2797eb ('stand/multiboot2: add support for booting a Xen dom0 in UEFI mode')
Add a missing space in one error message.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Fixes: adda2797eb ('stand/multiboot2: add support for booting a Xen dom0 in UEFI mode')
If we start with console set to comconsole, the local
console (vidconsole, efi) is never initialized and attempt to
use the data can render the loader hung.
Reported by: Kamigishi Rei
MFC after: 3 days
Do not attempt to add MODINFOMD_MODULEP to the kernel medatada on
arches that don't have it defined.
This fixes the build for arches different than amd64 after
7d3259775c.
Sponsored by: Citrix Systems R&D
Reported by: lwhsu, arichardson
Add some basic multiboot2 infrastructure to the EFI loader in order to
be capable of booting a FreeBSD/Xen dom0 when booted from UEFI.
Only a very limited subset of the multiboot2 protocol is implemented
in order to support enough to boot into Xen, the implementation
doesn't intend to be a full multiboot2 capable implementation.
Such multiboot2 functionality is hooked up into the amd64 EFI loader,
which is the only architecture that supports Xen dom0 on FreeBSD.
The options to boot a FreeBSD/Xen dom0 system are exactly the same as
on BIOS, and requires setting the xen_kernel and xen_cmdline options
in loader.conf.
Sponsored by: Citrix Systems R&D
Reviewed by: tsoome, imp
Differential revision: https://reviews.freebsd.org/D28497
This mirrors the functionality of the BIOS amd64 bi_load function,
that stashes the absolute address of the module metadata. This is
required for booting as a Xen dom0 that does relocate the modulep and
the loaded modules, and thus requires adjusting the offset.
No functional change introduced, further patches will make use of this
functionality for Xen dom0 loading.
Sponsored by: Citrix Systems R&D
Reviewed by: imp
Differential revision: https://reviews.freebsd.org/D28496
Xen requires that UEFI BootServices are enabled in order to boot, so
introduce a new parameter to bi_load in order to select whether BS
should be exited.
No functional change introduced in this patch, as all current users of
bi_load request BS to be exited. Further changes will make use of this
functionality.
Note the memory map is still appended to the kernel metadata, even
when it could be modified by further calls to the Boot Services, as it
will be used to detect if the kernel has been booted from UEFI.
Sponsored by: Citrix Systems R&D
Reviewed by: tsoome, imp
Differential revision: https://reviews.freebsd.org/D28495
Conout does contian the default output device name.
ConOutDev does contain all possible output device names, so we can
use it as fallback, when there is no ConOut.
PR: 253253
Even if it didn't behave well previously this is fixed.
Tested on: OrangePi One (armv7 u-boot) (serial only and serial + HDMI)
Tested on: Pine64-LTS (aarch64 u-boot) (serial only and serial + HDMI)
Tested on: Honeycomb (aarch64 EDK2) (serial only)
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D28153
Some systems may provide multiple GOP instances and not all are
bound to hardware. The current loader is picking up the first GOP,
which may not be usable. Instead we load the GOP handle array,
and test every handle to have registered ConOut protocol. If ConOut is
present, we can use this GOP handle to open GOP protocol.
We do select font based on desired terminal size, we do query
UEFI terminal size with conout->QueryMode(), but by mistake, the fallback
values are used.
Pass gfx_state to efi_find_framebuffer(), so we can pick between
GOP and UGA in efi_find_framebuffer(), also we can then
set up struct gen_fb in gfx_state from efifb and isolate efi fb data
processing into framebuffer.c.
This change does allow us to clean up efi_cons_init() and reduce
BS->LocateProtocol() calls.
A little downside is that we now need to translate gen_fb back to
efifb in bootinfo.c (for passing to kernel), and we need to add few
-I options to CFLAGS.
Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.
Export variables:
screen.height
screen.width
screen.depth
Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.
Probably something else I forgot...
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420
buildworld already runs the stand build in parallel[1], so make it easier to
identify ordering issues by properly establishing dependencies or adding
.WAIT where needed.
Everything in stand/ relies on libsa, either directly or indirectly, because
libsa build is where the stand headers get installed and it gets linked in
most places.
Interpreters depend on their libs, machine dirs usually depend on top-level
libs that are getting built and at least one of the interpreter flavors.
For i386, order btx/libi386/libfirewire before everything else using a
big-ol-.WAIT hammer. btx is the most common dependency, but the others are
used sporadically. This seems to be where the race reporting on the mailing
list is- AFAICT, the following sequence is happening:
1.) One of the loaders gets built based on stale btx/btxldr
2.) btx/btxldr gets rebuilt
3.) installworld triggers loader rebuild because btx was rebuilt after
This seems like the most plausible explanation, as they've verified system
time and timestamps.
While we're here, let's switch stand/ over to a completely parallel build so
we can work out these kinds of issues in isolation rather than in the middle
of a larger build.
Reviewed by: bdragon, sjg, tsoome
Tested by: bdragon (-j1024, no failures, significant speed improvement)
Differential Revision: https://reviews.freebsd.org/D23411
