No functional change: We're allocating a page from EFI, which is always
4k on amd64. So, this should always be 4k. PAGE_SIZE usually is this,
but might not be in some cases. For the end of the stack pointer in the
ist1, it should point the architecture's physical page past where we've
allocated. EFI_PAGE_SIZE more faithfully reflects that here since
PAGE_SIZE might not be exactly that in the future (if we had a larger
logical page than physical page). Since the AllocPage interface is in
EFI_PAGE_SIZE pages always, this seems safer. No functional change since
they are both 2096 today.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D50584
Also, add a comment about the weird reason we even have an archsw here
at all. tl;dr: zfs code uses archsw when it aught not, but this hack
here is easier than fixing that code properly.
Sponsored by: Netflix
This likely used to be needed for some code here, or maybe it's been
here since it was copied from elsewhere that did neeed it. Remove it.
Sponsored by: Netflix
This allows us to change the VERSION_FILE used for loaders
as well as set NEWVERS_DATE and BUILD_UTC to reflect the publish
date of loaders for secure-boot.
Sponsored by: Juniper Networks, Inc.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D50478
At least one instance of u-boot pretending to be EFI
is passing empty rootdev to loader which does not end well.
A simple precaution is harmless.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D50334
The lua boot loader module manuals were getting pulled into search
results for FreeBSD, but not for "boot" or "loader". Reword them to
increase clarity for boot or loader searches, as well as the FreeBSD
search term which we've been scoping to system topic overview manuals.
MFC after: 3 days
Reviewed by: imp, mhorne
Approved by: mhorne (mentor)
Pull Request: https://github.com/freebsd/freebsd-src/pulls/1628
Add cdboot to the reference manual, fixing an undocumented bug where it
is undocumented. There's almost nothing here, but that's better than
"only imp and jhb know what this is".
MFC after: 3 days
Reported by: jhb, imp
Reviewed by: mhorne
Approved by: mhorne (mentor)
Differential Revision: https://reviews.freebsd.org/D50274
While calculating font size based on EDID data, we can end up
selecting too large font and too small terminal. Add check to
prevent it.
Tested by: bz, ziaee
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50258
Some systems boot absurdly slowly, apparently due to problems with
UEFI framebuffer accesses being sluggish. This does not fix the
problem, but at least makes gfx_fb_fill show up as a large block
in boot flamecharts, which will save time when the next user needs
to identify why their system is booting slowly.
PR: 284595
Tested by: Peter Miller
binutils 2.37 seems to have added the knob, so let's just use that
version here (it's not clear if GC'ing start/stop symbols was actually
made the default at the time, and it didn't seem worth it to dig much
further). This fixes misbehavior when built with more recent binutils,
as we do rely on linker sets for loader commands that we use.
Reported by: sjg
Reviewed by: dim, sjg
Differential Revision: https://reviews.freebsd.org/D50252
This word was accidentally removed when gfx bindings were made optional
to remove some overhead not needed for all loaders. This one isn't
graphics related, so we can safely restore it without irritating anyone.
Reported by: sjg
Reviewed by: adrian, imp
Fixes: 9c8bf69a53 ("loader: Only create gfx 4th bindings when [...]")
Spleen 32x64 provides my 14" 2560x1600 display with the ancestral 80x25,
BSD standard console. We already include it in contrib, and it is built
for the runtime vt(4) font directory, but was previously unavailable to
the bootloader. Enable it in the build, selectable in loader.conf with:
screen.font="32x64"
MFC after: 3 days
Reviewed by: adrian, carlavilla, emaste, imp, mhorne, tsoome
Approved by: imp, tsoome (loader)
Approved by: mhorne (mentor)
Differential Revision: https://reviews.freebsd.org/D49768
In an ideal world, we'd get systbl and efi memory map from
/sys/firmware/efi somewhere. They are currently not published,
but may be in the future.
The systab comes from the first call to the EFI entry point and there's
no way to find it otherwise.
Memmap is obtained from BootServices which is long gone. And besides,
it's modified for the runtime entries for the call to
SetVirtualAddresses call in runtime services. Even though that's in
runtime services, it can be called only once.
kexec tools + Pandora (the kexec boot loader embedded in the Linux
kenrel) don't need this because pandora copyies this structure over when
the new kernel is a bzImage. Our current trampoline doesn't do that, so
we have to get it from the current kernel. Even so, we have to pass the
PAs for the memory map to the trampoline which copies this over (in part
so we can boot an modified kernel, otherwise we could put this into an
alternative entry point, but those are hard to manage).
So, we can sig out the PA of the memory map via this method, but some
care is needed. For the initial round, it suffices. However, Linux on
x86 does some odd things with EFI_RUNTIME that need to be preserved (so
this is a temporary measure until we get the /sys/firmware/efi code
working). The Linux kernel keeps this memory around, but it's not clear
how long. It stops referencing it after it converts it to the BIOS e820
memory map array it uses elsewhere. It seems to be OK to use since our
use case is an immediate boot to FreeBSD, not a boot after Linux runs a
while and had a chance to (maybe) overwrite this data.
Migrating to a proper interface that publishes the modified EFI
map in /sys/firmware/efi/memmap is in the future.
Update the trampoline to copy this data before jumping into the kernel.
We use the simple laucnhing interface instead of the bzImage interface
that kexec_file() uses, so there's no last-second chance to use the
boot params data.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D49869
Since the linux kernel doesn't expose enough of the EFI details to
userland via /sys/firmware/efi, write a routine to extract data from the
kernel directly by parsing /proc/kproc and /proc/kallsyms.
Sponsored by: Netflix
Reviewed by: kevans, jhibbits
Differential Revision: https://reviews.freebsd.org/D49868
For the EFI case, we just need to call efi_bi_loadsmap in bi_loadsmap.
If we need to do BIOS again, we'll revisit.
Sponsored by: Netflix
Reviewed by: kevans, jhibbits
Differential Revision: https://reviews.freebsd.org/D49867
Use the segs framework to find a place to land the kernel, with the same
super ugly defaults as aarch64.
Sponsored by: Netflix
Reviewed by: kevans, jhibbits
Differential Revision: https://reviews.freebsd.org/D49866
Use populate_avail_from_iomem and efi_read_from_sysfs from the
refactored work rather than replicating them (imperfectly) here.
Note: memmap might need to be revisited. EFI memory maps are complex on
x86 and we might need to reconstruct it from /sys/firmware/memmap as
well as using that for the BIOS case, should we ever want to support
that again (hardware makes no sense, but many VM hosting services use
that). For now, we're going all in on EFI, though, and will revisit what
to do about BIOS later. The zfsboot project suggests BIOS support isn't
really that hard (but is a distraction atm).
Sponsored by: Netflix
Reviewed by: kevans, jhibbits
Differential Revision: https://reviews.freebsd.org/D49864
Move efi_read_from_pa, efi_set_systbl and efi_bi_loadsmap into efi.c
Move prototype for populate_avail_from_efi as well, though that arrived
previously.
Move efi memory map variables into efi.c.
Add efi_read_from_sysfs, but if 0 it out. We'll want to use it if we can
get the proposed /sys/firmware/efi/memmap data published in the same
format and the code works, it's just that the current
/sys/firmware/efi/runtime-memmap isn't complete enough to use.
Sponsored by: Netflix
Reviewed by: kevans, jhibbits
Differential Revision: https://reviews.freebsd.org/D49863
If we can get an efi memory map, populate_avail_from_efi will create an
avail array. We only use the regiions marked as 'free' to find a place
for the kernel to land. The other regions are also eligible, but usually
too small to materially affect where we'd put the kernel (not to worry,
the kernel will use that memory).
Sponsored by: Netflix
Reviewed by: kevans, jhibbits
Differential Revision: https://reviews.freebsd.org/D49862
AMD64 kernels have an extra 2MB of padding that we need to account
for. So make the padding proper on a per-architecture basis.
Sponsored by: Netflix
Reviewed by: kevans, jhibbits
Differential Revision: https://reviews.freebsd.org/D49861
We've not needed to include link.h in the loader for a long time. I
shoud have removed it in f38658e140 rather than going link.h ->
sys/sys_link.h. It's purely a userland shared library thing. Remove it
now, since it's not needed. Also remove a few headers that are redundant
with stand.h in this environment.
Sponsored by: Netflix
Reviewed by: kevans, andrew, jhibbits
Differential Revision: https://reviews.freebsd.org/D49859
The location of argc argument is a fine limit for the extent of the
stack traceback. We could save the location of return address for the
call to _start_c, but we'd have to move that into MD assembler. While
not hard, it wouldn't improve the traces we can get. And the math to
find it is architecture dependent (though the same for both arm64 and
amd64).
Sponsored by: Netflix
Reviewed by: kevans, andrew, jhibbits
Differential Revision: https://reviews.freebsd.org/D49858
The type that's exposed from sysfs' memory map is 32-bit and so is the
data-type of memory description.
Sponsored by: Netflix
Reviewed by: kevans, andrew, jhibbits
Differential Revision: https://reviews.freebsd.org/D49856
Add '.section .note.GNU-stack,"",%progbits' to all assembler. Newer
versions of clang complain when this isn't present because executable
stacks are going away in the future. We don't need an executable stack
anyway.
Sponsored by: Netflix
Reviewed by: kevans, andrew, emaste, jhibbits
Differential Revision: https://reviews.freebsd.org/D49855
If set to 'none' then the menu isn't displayed.
The 'brand' and 'logo' part are stil displayed.
Differential Revision: https://reviews.freebsd.org/D49820
Reviewed by: imp, kevans
Sponsored by: Beckhoff Automation GmbH & Co. KG
It's used to control if the autoboot part of loader is displayed or not.
Differential Revision: https://reviews.freebsd.org/D49819
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Many of these no-doubt are in upstream, but they are interfering with
the filters I use to judge commits (no traling whitespace). We don't
directly get stuff from upstream. If/when we pull this from contrib
we'll revisit.
Sponsored by: Netflix
We can call init_avail() multiple times. Each time, we want to toss
whatever garbage may have already been there from a prior failed attempt
to find a good memory map.
Sponsored by: Netflix
Start to move the common efi routines into libkboot by moving the efi
memory map walking and implementing a printing routine around it.
Sponsored by: Netflix
The boot loader pads efi_map_header to start the array of
efi_memory_descriptor entries on the 16-byte-aligned boundary after the
header. Since the header isn't naturally 16-byte aligned, we need to do
this.
We should have used the actual UEFI EFI_MEMORY_ATTRIBUTES_TABLE which
used uint32_t's to pass all this data to the kernel (they never needed
to be 64-bit quantities or size_t's even) since these entries and the
total size of the table is small. However, this ship long since sailed
since we've used these structures for a decade and there's little to be
gained by changing them. The table header we pass to the kernel from the
loader has similar names, but the seamntics of the fields are different.
Sponsored by: Netflix
These are needed for the next round of EFI support for amd64 (partially
shared with aarch64, but only partially because the Linux host interfaces
are different to get the same info).
Sponsored by: Netflix
Warner Losh