Now that the minor issues preventing zfs.c from using CFLAGS_EARLY have
been fixed, use that mechanism like everything else that needs the
OpenZFS spl headers. This simplifies things somewhat. Update comments to
document why zfs.c is still special, though in different ways.
Note: We also use the fact that NEED_SOLARIS_BOOLEAN is only defined in
an environment where the solaris compat boolean stuff will be defined
prior to this point (eg, when we're building zfs.c in libsa), but not in
other environments (like when we're building mkimage and stand-alone
boot loaders that don't use libsa). These latter uses should be changed
to use the same ZFS compile env, but aren't as part of this commit.
This has to be done in the same change as the ZFS_EARLY change to not
break zfs.c building for one commit affecting bisectabiltiy.
Sponsored by: Netflix
Reviewed by: tsoome, delphij
Differential Revision: https://reviews.freebsd.org/D35894
Constrain CFLAGS for ZFS: don't add anything globally. Add the includes
to only the files that need them. Add -DHAS_ZSTD_ZFS to zfs.c (which
includes zfsimpl.c which includes zfssubr.c both of which need this
defined). Also add it to efi/boot1/Makefile since zfs_module.c also
includes zfsimple.c.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D35887
Various GELI sources need bootstrap.h and disk.h. In theory they
shouldn't need anything outside of libsa, but disk.h and bootstrap.h are
currently required.
This fixes the build with MK_LOADER_ZFS=no.
Obtained from: CheriBSD
Fixes: eaf7aabddc stand: geli CFLAGS tightening
Sponsored by: DARPA
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D35861
In theory they shouldn't need anything outside of libsa, but disk.h and
bootstrap.h are currently required. Future work wil address this issue.
This fixes the build with MK_LOADER_ZFS=no. ZFS's Makefile.inc adds
these flags globally to CFLAGS when it should not. This masked the
problem because the tools/boot/universe.sh didn't build MK_LOADER_ZFS=no
as part of its regressions. Future work will also fix this.
Obtained from: CheriBSD
Fixes: 84bf2bbbec stand: constrain zlib/gzip CFLAGS better
Sponsored by: DARPA
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D35860
With clang 15, the following -Werror warning is produced:
stand/i386/boot2/boot2.c:358:6: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
This is because parse() is declared with a (void) argument list, and
defined with an empty argument list. Make the definition match the
declaration.
MFC after: 3 days
Create a wrapper for the mount system call. To ensure a sane early boot
environment and to gather data we need for kexec, we may need to mount
some special filesystems.
Sponsored by: Netflix
Early in boot, we need to create the normal stdin/out/err env for the
boot loader to run in. To do that, we need to open the console and
duplicate the file descriptors which requires dup(2). Implement a
wrapper as host_dup.
Sponsored by: Netflix
Linux's /dev/fd is implemented inside of /proc/self/fd, so we may need
to create a symlink to it early in boot. "/dev/fd" and "/dev/std*" might
not be strictly required for the boot loader, but should be present for
maximum flexibility.
Sponsored by: Netflix
Add host_getpid() so we can know if we're running as init(8) or not. If
we are, we may chose to do early system setup / sanity operations.
Sponsored by: Netflix
Implement stat(2) and fstat(2) in terms of newfstatat and newfstat
system calls respectively (assume we have a compat #define when
there's no newfstat and just a regular fstat and do so for ppc).
Snag struct kstat (the Linux kernel stat(2), et al interface) from musl
and attribute properly.
Sponsored by: Netflix
Add the common O_ constants for the open, fcntl, etc system calls. They
are different than FreeBSD's. While they can differ based on
architecture, they are constant for architectures we care about, and
those architectures use the 'generic' version so future architectures
will also work.
Sponsored by: Netflix
Fallback to currdev when NULL is passed in when 'rootdev' is NULL. Other
getdevs do this. Additional features are needed here still, though.
Sponsored by: Netflix
Split _start into _start and _start_c (inspired by musl and the powerpc
impl is copied from there). This allows us to actually get the command
line arguments on all the platforms. We have a very simplified startup
that supports only static linking.
Sponsored by: Netflix
with grab_faults, we can try to print out the trace of function calls.
Without symbol table, we can not translate addresses to function names,
but even addresses can help to track the bugs.
For loader functions, print out absolute address, so it could be
searched from objdump -d output.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D35433
Add comments describing the weird nesting things we have to do to live
inside the ZFS world. Also fix a stale comment by moving nvlist.c to an
early user.
Sponsored by: Netflix
Add the necessary glue to get blake3 building for the boot loaded as
well as connected to the ZFS system so it is useful.
On some platforms, we create references to blake3_sse2_impl and
blake3_sse41_impl ops structs to utilize SIMD. These aren't present on
x86 (since we dind't ask for them), but are on aarch64 with no
implementation. Since we don't want SIMD in the boot loader, have these
all return 'unsupported' always. This should be fixed upstream to allow
more flexibility in this selection, but for now we use this hack to not
modify the sys/contrib/openzfs with difficult to maintain hacks while
an upstreamable solution is found.
tsoome@ did the implementation bits in sys/cddl/boot, and I did the
Makefile work and the aweful blake3_impl_hack.c.
Co-author: tsoome@freebsd.org
Sponsored by: Netflix
Reviewed by: kevans (earlier version)
Differential Revision: https://reviews.freebsd.org/D35750
We no longer need to use this to get zfs_zstd.c compiling, so delete it.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D35750
Now that we have the ability to work around all the issues that
zstd_stub.c worked around, compile zfs_std.c directly.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D35750
sys/blake3.h is not safe to include in a standalone environment. It
assumes, unwisely, that there's only kernel or userland. The userland
choice is bad due to imperfections in how we handle stdlib.h in this
environment (we wind up including the host's stdlib.h, it expects a
standard FreeBSD setup which the gymnastics we've done to create a
OpenSolaris/Illumos-like environment interfere with). Thankfully, in
this case we can just pretend to be the kernel for a little bit by
defining _KERNEL and the undefing it after we exit.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D35750
There's a number of issues with including zfs_context.h from a
standalone environment. First, sys/uio_imp.h isn't at all safe for this
environment, so define its guard #defines so that its contents are
skipped. Next, there's a problem including string.h to get the mem*
routines, so just define them here. ZFS_MODULE_PARAM_ARGS isn't defined
properly. I had wanted to define it when I was upstreaming changes to
include/os/freebsd/spl/sys/zfs_context.h, but they ran into resistance
so I'm defining that here now (it is also defined in zstd_shim.c, but
that will disappear once the issues it works around are
cleared). Finally, sys/sysmacros.h has to be included now before
sys/atomic.h, but upstream includes it after so include it here so that
the guards make the out-of-order includes in upstream irrelevant.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D35750
OpenZFS is based on having a number of layers of include files that
define things and include the next layer. Insert a later at the start
for files in libsa/zfs/spl so we can override issues with upstream
OpenZFS while we work to get the issues corrected upstream.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D35750
Add a note that veriexec / bearssl builds will pollute the CFLAGS in a
way that's somewhat hard to fix, so I'm just noting it for now.
Sponsored by: Netflix
Only add -DWEAK_REFS to sha256.c and sha512.c instead of
everything. Remove redundant include that's not needed.
Minor formatting tweak.
Sponsored by: Netflix
CFLAGS+= here affects *ALL* libsa files being built. However, this is
only needed for zfs.c, so define it only for this. Also, use the defines
from defs.mk. Move all the zfs.c include hacks together. Also, move the
-Wformat -Wall warnings that were added to CFLAGS+= to the individual
files instead for the same reason.
Sponsored by: Netflix
ZFSSRC is the top level directory where the ZFS sources come from. Don't
reuse it for a list of ZFS sources. Instead, use ZFS_SRC
Sponsored by: Netflix
Given that hints set this way don't work when a static kenv is compiled
into the kernel. acpi.rsdp has been set for this for the past 6 years,
and all kernels in that time have used it in preference to the hints. As
such, we no longer hints.*, so remove them.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D35634
Several years ago, x86 moved from using hints to communicate this
information to using the simpler acpi.rsdp variables. If one compiles
static hints into the kernel, then these hints are ignored. We can
remove this when we branch FreeBSD 15. Thought about BURN_BRIDGES
here, but it's too messy.
Sponsored by: Netflix
Reviewed by: andrew, jhb
Differential Revision: https://reviews.freebsd.org/D35632
With the introduction of llvm14, the powerpc* loader used on ofw/pseries
for 32 and 64 bit architectures puts the .data.rel.ro section after
.data section. This caused a crash kernel didn't boot. Bisect pointed to
change https://reviews.llvm.org/D111717 but problem could be fixed by
adding a section description to make it appear in the expected order.
This patch is based on discussion at:
https://github.com/llvm/llvm-project/issues/56306
MFC after: 1 day
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
In some cases ubldr would try to mount a disk device before
the archsw struct was filled with functions pointers.
This would result in a NULL pointer derefrence of the arch_getdev field.
Fix that filling the archsw functions earlier.
Note that this matches the EFI behavoiur.
Reviewed by: imp, mw
Sponsored by: Stormshield
Obtained from: Semihalf
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35670
geli_probe_and_attach() does pick geli_devsw structure for
encrypted disks, the implementation depends on device
name "disk" when device type is DEVT_DISK, but geli_devsw is
setting name field "gelidisk".
PR: 264282
Submitted by: yamagi@yamagi.org
Reported by: yamagi@yamagi.org
MFC after: 2 weeks
Detect the end of the disk condition. This may happpen when
disk image is truncated and the reads are addressing blocks past
image end.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35432
panic() is using multiple services - attempting to read
keyboard, accessing time functions and finally, exiting the loader.
Protect all the accessed listed above. Note, when BS are off,
we really can not just exit the loader, we only can reboot.
MFC after: 1 week
The check fails in kernels compiled with KASAN because AddressSanitizer
inserts redzones around global variables, so the size of the "kernphys"
symbol is 32 rather than 8. Thus we fall back to copying even though
it's not necessary.
Simply remove the size check. I didn't want to extend the symbol size
check since there's no guarantee that AddressSanitizer will always emit
32 bytes for "kernphys".
Reviewed by: kib
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35448
Notable upstream pull request merges:
#12321 Fix inflated quiesce time caused by lwb_tx during zil_commit()
#13244 zstd early abort
#13360 Verify BPs as part of spa_load_verify_cb()
#13452 More speculative prefetcher improvements
#13466 Expose zpool guids through kstats
#13476 Refactor Log Size Limit
#13484 FreeBSD: libspl: Add locking around statfs globals
#13498 Cancel in-progress rebuilds when we finish removal
#13499 zed: Take no action on scrub/resilver checksum errors
#13513 Remove wrong assertion in log spacemap
Obtained from: OpenZFS
OpenZFS commit: b9d98453f9
When reading the UEFI memory map we pass in a pointer to the memory to
hold the map. Unfortunately it wasn't initialised before the first use
so clang decided it was undefined behaviour so the entire loop was
removed. This leads to everything in bi_load after this to also be
removed as dead code.
The next function after bi_load in the binary is efi_copy_init. The
above caused us to enter efi_copy_init with a return address of the
start of the function. Because of this it would enter an infinite
loop of calling the function, allocating memory, then returning to
the start of the function.
PR: 264021
head_errlog is new format for errlog, but we do not really
use errlog, so we can just mark it supported, to enable reading
from pool.
MFC after: 1 week
Move declarations into a new nvlist.h rather than putting everything in
libzfs.h. This makes this nvlist code easier to reuse elsewhere. In
particular, the nvlist implementation in sys/contrib/libnv does not
provide XDR encoding, but this is needed when reading from or writing to
ZFS pools.
Also:
- Remove references to boolean_t. It has to be a 32-bit int here, so
just reference the underlying type.
- Add includes needed when compiling the nvlist code outside of stand/.
No functional change intended.
Reviewed by: tsoome
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35255
When adding an entry to an nvlist, the data buffer might need to be
resized. When this happens, the XDR encoder's notion of the buffer size
also needs to be updated, otherwise the operation may erroneously fail.
Reviewed by: tsoome, imp
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35254
The loader.efi man page describes UEFI-specific loader details, but not
general loader information.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Get amd64 compiling. However, the current kboot supports an old way of
enumerating memory and the new way needs to be incorporated as well. The
powerpc folks could use either, it seems and newer powerpc platforms
need some changes for kboot to work anyway.
This commit includes the linker script, trampoline code to start the new
kernel, Linux system calls and the necessary configuration glue needed
to build the binaries.
This includes a quick hack to get multiboot support, but we need to
really share these defines. The multiiboot2.h is the minimum needed to
build. We have multiboot information in three places now, so a
refactoring is in order.
This should be considered, at best, preliminary and experimental for
anybody wishing to try it out.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D35100
Turns out there is a libsa.3. It's a bit out of date, but we reference
it in a number of places so we should install it. We need to do the DO32
dance because this Makefile is included twice and we don't want it
installing twice.
Sponsored by: Netflix
This mirrors dmu_read_impl(), zeroing out the tail end of the buffer and
clipping the read to what's contained by the block that exists.
This fixes an issue that arose during the 13.1 release process; in
13.1-RC1 and later, setting up GELI+ZFS will result in a failure to
boot. The culprit is this, which causes us to fail to load geom_eli.ko
as there's a residual portion after the single datablk that should be
zeroed out.
PR: 263407
Reviewed by: tsoome
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D35019
We don't need it for userboot, but it avoids issues with BIND_NOW, so
just provide it. time(3) isn't defined but ends up being provided by
libc linked into the host process, which is generally fine.
PR: 262920
Reviewed by: imp, jhb
MFC after: 3 days
Diferential Revision: https://reviews.freebsd.org/D34758
Printing device followed by interface matches, e.g., edk2. Note that
this is only a fallback, many firmware implementations will provide the
protocol that we'll use to format device paths.
Reviewed by: imp, tsoome
Sponsored by: Ampere Computing
Submitted by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D34539
- Add SPDX tag
- Add a files section describing different locations related to the
loader
- Add an example explaining how to install a new loader.efi to ESP
- Reference uefi(8)
Reviewed by: tsoome
Reviewed by: Pau Amma <pauamma@gundo.com>
Reviewed by: Jose Luis Duran <jlduran@gmail.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D34592
The console escape code standard (ECMA-48) specifies color #3 (escape
code 33) as yellow. A brown console color is an artifact of the VGA
palette, which replaces dim (but not bright) yellow with brown.
Reviewed by: adrian, imp
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34531
For historical reasons console color number 3 may be either yellow (most
consoles) or brown (VGA palette). The console escape code standard
uses "yellow", but teken color name constants appear to be based on the
VGA scheme and use TC_BROWN for color 3. Even so, the palette table
used 50,50,0 as the RGB percentage tuple, resulting in a dim yellow for
framebuffer consoles at the time teken was introduced.
Amusingly, in 19e2ce2d83 the comment on the palette entry was changed
from "brown" to "dark yellow" but the colour itself was changed from
a pure yellow to being somewhat brown.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Accept "bright" or "light" prefix for named colors.
For numeric colors, update error message to specify that values 0 to 15
are allowed, and verify that values are in that range.
Reviewed by: imp, tsoome (both earlier version)
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34512
Notable upstream pull request merges:
#9078: log xattr=sa create/remove/update to ZIL
#11919: Cross-platform xattr user namespace compatibility
#13014: Report dnodes with faulty bonuslen
#13016: FreeBSD: Fix zvol_cdev_open locking
#13019: spl: Don't check FreeBSD rwlocks for double initialization
#13027: Fix clearing set-uid and set-gid bits on a file when
replying a write
#13031: Add enumerated vdev names to 'zpool iostat -v' and
'zpool list -v'
#13074: Enable encrypted raw sending to pools with greater ashift
#13076: Receive checks should allow unencrypted child datasets
#13098: Avoid dirtying the final TXGs when exporting a pool
#13172: Fix ENOSPC when unlinking multiple files from full pool
Obtained from: OpenZFS
OpenZFS commit: a86e089415
If module_verbose is set to a value below MODULE_VERBOSE_TWIDDLE
call twiddle_divisor(UINT_MAX).
This makes more sense here than when we are loading the kernel.
Sponsored by: Juniper Networks, Inc.
UEFI provides a protocol for accessing randomness. This is a good way
to gather early entropy, especially when there's no driver for the RNG
on the platform (as is the case on the Marvell Armada8k (MACCHIATObin)
for now).
If the entropy_efi_seed option is enabled in loader.conf (default: YES)
obtain 2048 bytes of entropy from UEFI and pass is to the kernel as a
"module" of name "efi_rng_seed" and type "boot_entropy_platform"; if
present, ingest it into the kernel RNG.
Submitted by: Greg V
Reviewed by: markm, kevans
Approved by: csprng (markm)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D20780
Set module_verbose to control the printing of information
about loaded modules and kernel:
0 MODULE_VERBOSE_SILENT None
1 MODULE_VERBOSE_SIZE Pathname and size
2 MODULE_VERBOSE_TWIDDLE as for 1 but also twiddle for progress
3 MODULE_VERBOSE_FULL extra detail
When the loader is verifying modules we already have a
running indication of progress and module_verbose=0 makes sense.
Reviewed by: rpokala
Differential Revision: https://reviews.freebsd.org/D34245
ld.bfd in binutils 2.34+ now reports an error in more cases for custom
ldscripts that do not place PHDRs in a LOAD segment. However, EFI
binaries are not dynamic binaries which need PHDRs, so pass
--no-dynamic-linker to disable this check.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D34124
The text after .error et al is emitted verbatim.
Reviewed by: sjg
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33904
- Use AES_XTS_IV_LEN instead of the key length as the IV length.
- Use G_ELI_IVKEYLEN as the size of the zeroed iv[] array in
g_eli_crypto_cipher() to match geli_io().
PR: 261172
Reported by: Malcolm Matalka <mmatalka@gmail.com>, mikael
Reviewed by: markj
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33884
This helps mesuring what's happening when we load the kernel/modules/mfsroot.
This also adds TSENTER2 which uses the third argument of TSRAW, same
as in the kernel.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33699
The saf1761 OTG support was only for mips targets (BERI?). Retire it.
Sponsored by: Netflix
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D33706
Shortlinks occupy the space of both di_db and di_ib when used. However,
everywhere that wants to read or write a shortlink takes a pointer do
di_db and promptly runs off the end of it into di_ib. This is fine on
most architectures, if a little dodgy. However, on CHERI, the compiler
can optionally restrict the bounds on pointers to subobjects to just
that subobject, in order to mitigate intra-object buffer overflows, and
this is enabled in CheriBSD's pure-capability kernels.
Instead, clean this up by inserting a union such that a new di_shortlink
can be added with the right size and element type, avoiding the need to
cast and allowing the use of the DIP macro to access the field. This
also mirrors how the ext2fs code implements extents support, with the
exact same structure other than having a uint32_t i_data[] instead of a
char di_shortlink[].
Reviewed by: mckusick, jhb
Differential Revision: https://reviews.freebsd.org/D33650
Just have the MD code provide syscall and have generic code for the
rest.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D33515
Split the powerpc specific parts into kboot/arch/powerpc64. More may be
needed here.
Sponsored by: Netflix
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D33514
As the first step at making this more generic, move kboot to top level.
Sponsored by: Netflix
Reviewed by: luporl, tsoome
Differential Revision: https://reviews.freebsd.org/D33513
tftp_open reads the first block so copy it in the cached data.
If we have more than one block (i.e. we called tftp_read before
tftp_preload) simply just reset the transfer.
Reported by: mmel
Reviewed by: mmel, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33697
shadow FB size could be rather large and depends on resolution,
instead of using heap, allocate dedicated space outside of heap.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D33600
MFC after: 2 weeks
On boot we don't need to perform any CPU cache management when the IDC
and DIC fields in the ctr_el0 register are set. Add a command to tell
loader to ignore these fields. This could be useful, for example, if the
hardware is misreporting the values and we are missing a quirk to enable
it.
It is not expected this will be needed, but is only intended as a
workaround to ensure the kernel can still boot.
Sponsored by: The FreeBSD Foundation
In the arm64 loader we need to syncronise the I and D caches. On some
newer CPUs the I and D caches are coherent so we don't need to perform
these operations.
While here remove the arguments to cpu_inval_icache as they are unneeded.
Reported by: cperciva
Tested by: cperciva
Sponsored by: Innovate UK
Kernel needs physical frame buffer address and size, which Block
Transfer-only Graphics Output Protocol instances do not have.
Some recent ASUS boards like PRIME Z690M-PLUS D4 and PRIME H570-Plus
report two GOPs, out of which the second one support ConOut protocol,
that made it preferable, but is BLT-only, that made console unusable.
Discussed with: tsoome (previous version)
MFC after: 1 week
Otherwise on fs like tftp where no directory listing is possible we fail
on the .dir method.
Reviewed by: imp, kevans
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33414
Use %j to it works on 64 and 32 bits system.
Reviewed by: imp, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33430
The preload method will transfer the whole file in a buffer and cache it
so read/lseek operations are faster.
Reviewed by: imp, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33410
When we load an ELF file (kernel or module) we do seek(2) a lot to
parse/load the different sections of the ELF file.
Protocol like TFTP suffers a lot from this as there is no resume or
a way to start the tranfer from a specified offset in the file.
fs_preload is added to help those protocol.
Call preload just after opening the ELF file that we need to load so
the underlying method can cache the hole file and then read/lseek operations
are faster.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33409
getsecs is very costly, reuse the values we got before.
Fetching a ~30MB kernel with the tftp command use to take ~26 seconds
and now it's ~18 seconds.
Reviewed by: imp, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33408
When we load a kernel or module we open/close it a few times.
Since we're using the same port number each time and that we requested
the same file the ACK that we send are valid on the server side and the
server send us the file multiple times.
This makes tftp loading time very inconsistant due to the UDP "flood" that
we have to process.
Reviewed by: imp, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33407
readtest will simply load the file in memory, useful for timing
loading on some filesystems.
Reviewed by: tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33411
tftp-hpa sends NAK with tftp error set to 0 when trying to get
a directory and this is the first thing that loader tries to do
and this make it hangs.
Reviewed by: imp, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33406
We never use 'dev' after fetching it from the varargs list. Skip the
whole bother of fetching it, or setting up the meachinery to fetch it.
Sponsored by: Netflix
Build uboot ubldr and friends like we build efi binaries
o move everything to be under stand/uboot
o md code goes in arch/$ARCH
o move everything over from the library
- Had to rename console.c, disk.c and module.c due to conflicts
o update version to 1.5 to reflect the new way of building
This results in a more consistent build system and should represent no
functional change, apart from powerpc version getting new help
file. Also, moved to exlcuding uboot on powerpc64le by using
BROKEN_OPTION instead of the incidental exclusion we had before due to
Makefile reorgs.
Sponsored by: Netflix
Feedback by: stevek, jrtc27
Differential Revision: https://reviews.freebsd.org/D33362
All these files are the same, modulo one comment. Move them all into
common/gfx_fb_stub.c and adjust Makefiles accordingly.
Sponsored by: Netflix
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D33428
Store whether or not we found a vbefb module (eg, a tg supported kernel)
in the preloaded_file structure. This automatically resets on reload and
eliminates load_elf knowing about any gfx_* interface. Restrict this to
i386, which is the only place it's used. Update libi386 to check in the
preloaded_file struct. Eliminate this from the teken_gfx
structure. Rewrite the parsing code to be more inline. Check this from
the same place we check for a relocatable amd64 kernel.
Sponsored by: Netflix
Reviewed by: manu, tsoome
Differential Revision: https://reviews.freebsd.org/D33427
Reading from Write Combining memory can be very-very slow. Try to use
shadow buffer to avoid such reads.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33305
As part of decommissioning mips support, remove the boot loader
support. Do this in advance of other boot loader work to limit the
amount of work that will be thrown away.
Sponsored by: Netflix
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D33377
The elf loader needs to know how to reach into the gfx_fb code, so
simplify how we include files to find that stuff.
Sponsored by: Netflix
Reviewed by: manu, tsoome
Differential Revision: https://reviews.freebsd.org/D33376
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
The STDSB macro is passed to the ffs_sbget() routine to fetch a
UFS/FFS superblock "from the stadard place". It was identically defined
in lib/libufs/libufs.h, stand/libsa/ufs.c, sys/ufs/ffs/ffs_extern.h,
and sys/ufs/ffs/ffs_subr.c. Delete it from these four files and
define it instead in sys/ufs/ffs/fs.h. All existing uses of this macro
already include sys/ufs/ffs/fs.h so no include changes need to be made.
No functional change intended.
Sponsored by: Netflix
Add ofwbus, iicbus and spibus to pnpautoload so modules under those
buses will be loaded.
On my rockpro64 now :
OK pnpautoload -v
Autoloading modules for simplebus
Using DTB provided by EFI at 0x8100000.
Autoloading modules for ofwbus
/boot/kernel/rk_spi.ko text=0x14b2 text=0xd4c data=0x4d0+0x8 syms=[0x8+0xa98+0x8+0x807]
/boot/kernel/dwwdt.ko text=0x12e2 text=0x78c data=0x4c8+0x10 syms=[0x8+0x990+0x8+0x6e1]
Autoloading modules for iicbus
Autoloading modules for spibus
/boot/kernel/mx25l.ko text=0x1613 text=0x114c data=0x6e8+0x8 syms=[0x8+0xa08+0x8+0x665]
loading required module 'fdt_slicer'
/boot/kernel/fdt_slicer.ko text=0x95e text=0x340 data=0x290 syms=[0x8+0x6c0+0x8+0x4a0]
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
When the timer drops from double to single digits, a spare 'e' is left
on the end of the line as we don't overwrite it. Include an extra space
at the end to account for this and overwrite the leftover character.
PR: 259429
MFC after: 3 days
Reviewed by: emaste
If CAS detects that radix is not supported, set radix_mmu to 0
to avoid the kernel trying to use it and panic.
MFC after: 2 weeks
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Fix boot1 and loader on PowerPC64 little-endian (LE).
Due to endian issues, boot1 couldn't find the UFS boot partition
and loader wasn't able to load the kernel. Most of the issues
happened because boot1 and loader were BE binaries trying to access
LE UFS partitions and because loader expects the kernel ELF image
to use the same endian as itself.
To fix these issues, boot1 and loader are now built as LE binaries
on PPC64LE. To support this, the functions that call OpenFirmware
were enhanced to correctly perform endian conversion on its input
and output arguments and to change the CPU into BE mode before
making the calls, as OpenFirmware always runs in BE. Besides that,
some other small fixes were needed.
Submitted by: bdragon (initial version)
Reviewed by: alfredo, jhibbits
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D32160
net_open() does replace f_devdata with pointer to netdev_sock,
this will cause memory leak when device is closed, but also does
alter the devopen() logic.
We should store &netdev_sock to dev->d_opendata instead, this
would preserve and follow the devopen() logic.
Fixes network boot on aarch64 (tested by bz).
Reviewed-by: imp
MFC After: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32227
As Radix MMU with superpages enabled is now stable, make it the
default choice on supported hardware (POWER9 and above), since its
performance is greater than that of HPT MMU.
Reviewed by: alfredo, jhibbits
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D30797
Pass the ivlen along through, and just drop this KASSERT() if we're
building _STANDALONE for the time being.
Fixes: 1833d6042c ("crypto: Permit variable-sized IVs ...")
Prior to this commit, the loader would perform readaheads of up to
128 kB; when booting on a UFS filesystem this resulted in a series
of 160 kB reads (32 kB request + 128 kB readahead).
This commit allows readaheads to be longer, subject to a total I/O
size limit of 256 kB; i.e. 32 kB read requests will have added
readaheads of up to 224 kB.
In my testing on an EC2 c5.xlarge instance, this change reduces the
boot time by roughly 80 ms.
Reviewed by: tsoome
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D32251
The loader bcache attempts to determine whether readahead is useful,
increasing or decreasing its readahead length based on whether a
read could be serviced out of the cache. This resulted in two
unfortunate behaviours:
1. A series of consecutive 32 kB reads are requested and bcache
performs 16 kB readaheads. For each read, bcache determines that,
since only the first 16 kB is already in the cache, the readahead
was not useful, and keeps the readahead at the minimum (16 kB) level.
2. A series of consecutive 32 kB reads are requested and bcache
starts with a 32 kB readahead resulting in a 64 kB being read on
the first request. The second 32 kB request can be serviced out of
the cache, and bcache responds by doubling its readahead length to
64 kB. The third 32 kB request cannot be serviced out of the cache,
and bcache reduces its readahead length back down to 32 kB.
The first syndrome converts a series of 32 kB reads into a series of
(misaligned) 32 kB reads, while the second syndrome converts a series
of 32 kB reads into a series of 64 kB reads; in both cases we do not
increase the readahead length to its limit (currently 128 kB) no
matter how many consecutive read requests are made.
This change avoids this problem by tracking the "unconsumed
readahead" length; readahead is deemed to be useful (and the
read-ahead length is potentially increased) not only if a request was
completely serviced out of the cache, but also if *any* of the request
was serviced out of the cache and that length matches the amount of
unconsumed readahead. Conversely, we now only reduce the readahead
length in cases where there was unconsumed readahead data.
In my testing on an EC2 c5.xlarge instance, this change reduces the
boot time by roughly 120 ms.
Reviewed by: imp, tsoome
MFC after: 1 week
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D32250
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
Lua bindings appeared in FreeBSD 12.0. Delete the authors section of the
man page, since it's unclear who wrote different parts of the man
page.
Noted by: Trond Endrestol
Sponsored by: Netflix
Create a man page per loader. Loader(8) will have information common to
all of them, while loader_${INTERP}(8) will have information relevant to
that specific loader. Rewrite loader(8) to give an overview and point to
the appropriate man page. Rewrite each of the loader_${INTER}(8) man
pages to contain only the relevant information to that loader. Put all
the common commands, environment variables, etc in loader_simp(8) and
refernce that from the loader_lua or loader_4th man pages. The
loader_lua(8) could use more details about the Lua
integration. Additional organization may be benefitial.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D31340
Booting FreeBSD on an EC2 c5.xlarge instance, the loader "twiddles"
810 times over the course of 510 ms, a rate of 1.59 kHz. Even accepting
that many systems are slower than this particular VM and will take
longer to boot (especially if using spinning-rust disks), this seems
like an unhelpfully large amount of twiddling when compared to the
~60 Hz frame rate of many displays; printing the twiddles also consumes
roughly 10% of the boot time on the aforementioned VM.
Setting the default globaldiv to 16 dramatically reduces the time spent
printing twiddles to the console while still twiddling at roughly 100
Hz; this should be ample even for systems which take longer to boot and
consequently twiddle slower.
Note that this can adjusted via the twiddle_divisor variable in
loader.conf, but that file is not processed until nearly halfway
through the loader's runtime.
Reviewed by: allanjude, jrtc27, kevans
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: <https://reviews.freebsd.org/D32163>
Now that the loader tslog code doesn't call printf, we can profile
printf using TSLOG. On an EC2 c5.xlarge instance, we spend roughly
45 ms here (out of roughly 500 ms), presumably due to the time spent
writing output to the console.
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
After b4cb3fe0e3, loader started crashing on PowerPC64, with a
Program Exception (700) error. The problem was that archsw was
used before being initialized, with the new mount feature. This
change fixes the issue by initializing archsw earlier, before
setting currdev, that triggers the mount.
Reviewed by: tsoome
MFC after: 1 month
X-MFC-With: b4cb3fe0e3
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D32027
Use radix_mmu environment variable to select between Hash or Radix
MMU, when performing the CAS method call. This matches kernel's
behavior, by selecting Hash MMU by default and Radix if radix_mmu
is not zero, to make sure that both loader and kernel always select
the same MMU.
The device tree is queried to detect Radix/GTSE support and to
find out if CAS is supported, making the old CPU version and HV
bit checks unnecessary now.
Reviewed by: jhibbits
MFC after: 2 weeks
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D31951
The behavior remains the same, but lualoader now uses the more concise
verbiage that forthloader used. This is particularly important because
the previous line would exceed the right boundary of the menu and run
straight into space that would typically be allowed for the logo.
This makes it slightly easier to port logos from forthloader to
lualoader.
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
Because lld 13 and higher default to garbage collecting start/stop
symbols when using --gc-sections, the linker sets used in the i386 boot
loaders will disappear. This leads to the loaders not recognizing any
commands, and failure to boot.
Until we have a good set of linker scripts for the loaders, work around
it by disabling the start-stop-gc feature.
MFC after: 1 week
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
This pushes the bulk of the rx servicing into a single loop that's only
slightly convoluted, and it addresses a problem with rx handling in the
process. If we hit a tx interrupt while we're processing, we'd
previously drop the frame on the floor completely and ultimately
timeout, increasing boot time on particularly busy hosts as we keep
having to backoff and resend.
After this patch, we don't seem to hit timeouts at all on zoo anymore
though loading a 27M kernel is still relatively slow (~1m20s).
Reviewed by: tsoome
Triage by: Ash Gokhale <ashfixit gmail com>
Sponsored By: National Bureau of Economic Research
Sponsored by: Klara, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31512
When we quit pager, the return value 1 is returned and command_more()
interprets it as error.
when lua loader gets error from command, it will try to
interpret it once more, so we get the same file shown once more.
There is no reason why we should return error from command_more().
MFC after: 1 week
Scrolling screen will leave "trail" of chars from first column.
Apparently caused by cursor location mismanagement.
Make sure we do not [attempt to] set cursor out of the screen.
MFC after: 1 week
The change makes block caching algorithm to work better for remote
media on low-BW/high-delay links.
This cuts boot time over IP KVMs noticeably, since the initialization
stage reads bunch of small 4th (and now lua) files that are not in
the same cache stripe (usually), thus wasting lot of bandwidth and
increasing latency even further.
The original regression came in 2017 with revision 87ed2b7f5. We've
seen increase of time it takes for the loader to get to the kernel
loading from under a minute to 10-15 minutes in many cases.
Reviewed by: tsoome
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D31623
The Xen kernel has no symbol tables, so calling lookup_symbol against
it triggers the following Divide by Zero fault:
Loading Xen kernel...
/boot/xen data=0x2809c8+0x149638 |
!!!! X64 Exception Type - 00(#DE - Divide Error) CPU Apic ID - 00000000 !!!!
Fix lookup_symbol to prevent the #DE fault from happening if the
symbol table is not loaded and also fix loadfile_raw to mark multiboot
kernels as relocatable, since the only multiboot kernel supported is
Xen and was already unconditionally booted as relocatable.
Fixes: f75caed644 ('amd64 UEFI loader: stop copying staging area to 2M physical')
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D31507
Summary:
Open file list is currently created as statically allocated array (64 items).
Once this array is filled up, loader will not be able to operate with files.
In most cases, this mechanism is good enough, but the problem appears, when
we have many disks with zfs pool(s). In current loader implementation, all
discovered zfs pool configurations are kept in memory and disk devices open -
consuming the open file array. Rewrite the open file mechanism to use
dynamically allocated list.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D31364
There's no need to build both pie and non-pie .o's for stand. There's
some other build thing with MK_BEAR_SSL=yes and/or MK_LOADER_VERIEXEC=yes
that causes the pie build to fail that the 'ar' stage now. Since we don't
need the PIE stuff and the non-PIE stuff, disable PIE for the boot loader.
Reviewed by: emaste
Sponsored by: Netflix
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
It is more idiomatic. CFLAGS is only augmented with $SSP_CFLAGS when
$MK_SSP != "no".
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31401
The userboot/test program links against the default userspace libraries
(e.g. shared libgcc_s.so) that will be instrumented if WITH_ASAN is set.
All other programs link against libsa instead of libc and therefore can't
use the sanitizer runtime library. To fix the stand/ build with
sanitizers, we disable MK_ASAN/MK_UBSAN if -nostdlib is found in the
LDFLAGS (i.e. we are using libsa instead of libc).
Reviewed By: imp, tsoome
Differential Revision: https://reviews.freebsd.org/D31047
servip is set from bootp bp_siaddr (if present) and rootip is
set immediately from servip in tha sane bootp code.
However, the common/dev_net.c does only set rootip (based on
url processing etc). Therefore, we should also use rootip in tftp
reader.
Fixes hung tftp based boot when bp_siaddr is not provided.
MFC after: 1 week
disable-device fooX will set hint.foo.X.disabled=1 as a way to easily
disable a device attaching during boot.
Reviewed by: tsoome
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D31297
Large nextboot.conf files (over 80 bytes) are not read correctly by the
Forth loader, causing file parsing to abort, and nextboot configuration
fails to apply.
Simple repro:
nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shutdown -r now
That will cause the bug to cause a parse failure but shouldn't otherwise
affect the boot. Depending on your loader configuration, you may also
have to set beastie_disable and/or reduce the number of modules loaded
to see the error on a small console screen. 12.0 or CURRENT users will
also have to explicitly use the Forth loader instead of the Lua loader.
The error will look something like:
Warning: syntax error on file /boot/loader.conf.local
foo="xxxxxxxxxxxxxxnextboot_enable="YES"
^
/boot/support.4th has crude file I/O buffering, which uses a buffer
'read_buffer', defined to be 80 bytes by the 'read_buffer_size'
constant. The loader first tastes nextboot.conf, reading and parsing
the first line in it for nextboot_enable="YES". If this is true, then
it reopens the file and parses it like other loader .conf files.
Unfortunately, the file I/O buffering code does not fully reset the
buffer state in the reset_line_reading word. If the last file was read
to the end, that doesn't matter; the file buffer is treated as empty
anyway. But in the nextboot.conf case, the loader will not read to the
end of file if it is over 80 bytes, and the file buffer may be reused
when reading the next file. When the file is reread, the corrupt text
may cause file parsing to abort on bad syntax (if the corrupt line has
<>2 quotes in it), the wrong variable to be set, no variable to be set
at all, or (if the splice happens to land at a line ending) something
approximating normal operation.
The bug is very old, dating back to at least 2000 if not before, and is
still present in 12.0 and CURRENT r345863 (though it is now hidden by
the Lua loader by default).
Suggested one-line attached. This does change the behavior of the
reset_line_reading word, which is exported in the line-reading
dictionary (though the export is not documented in loader man pages).
But repo history shows it was probably exported for the PNP support
code, which was never included in the loader build, and was removed 5
months ago.
One thing that puzzles me: how has this bug gone unnoticed/unfixed for
nearly 2 decades? I find it hard to believe that nobody's tried to do
something interesting with nextboot, like load a kernel and filesystem,
which is what I'm doing.
Tested by: Gary Jennejohn
PR: 239315
MFC After: 3 weeks
Reviewed by: imp (and correctly applied this time)
Differential Revision: https://reviews.freebsd.org/D31328
CPUTYPE?=native causes -march=native to be added to the command
line. When the host machine is haswell, this causes some versions of
clang to generate code that can't execute in the efi boot loader
environment. Set _CPUCFLAGS= to undo what's done bsd.cpu.mk. bsd.cpu.mk
is included too early to control with NO_CPU_CFLAGS here. The only other
option is to put that in all the Makefiles, and this is less tedious and
error prone.
PR: 194641
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D31187
MFC After: 1 week
loader_simp is a much simplified version of loader that will process a
linear sequence of commands from loader.rc. It has neither Forth nor Lua
built in and is much smaller. Document it. This is largely copied from
loader.8 since it implements those built-in commands. Future revisions
will fix this duplication.
Sponsored by: Netflix
boot.4th was a thing for only a few months around FreeBSD 3.1. The
correct name has been loader.4th for a long time.
MFC After: 2 days
Sponsored by: Netflix
These issues have low impact because they require precise circumstances
to trigger one of them. The disk must be > 2 TiB in size and either:
- The primary GPT header is dammaged.
- The freebsd-boot partiton is located farther than the first 2 TiB of
the disc and one of its sectors takes place at a lba value that makes
the higher 32 bits of this very value change.
Errors and corrections folow:
- decl and incl don't affect CF, so replace with subl/addl $1
- repe uses %cx, so move size to it with movw
- moving a 64-bit value with %cx of 2 (should be 4) so addresses
> 2TB will work.
PR: 233180
Reviewed by: imp@ (applied patch using description in bug)
Differential Revision: https://reviews.freebsd.org/D31100
The current code bumps lastaddr twice for the symbol table
location. However, the first bump is bogus and results in wasted
space. Remove it.
PR: 110995
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D31017
Document "NO" special value for the autoboot_delay and move the
description to loader.conf.5.
imp reworked some of the wording from danger's patch.
Reviewed by: imp
PR: 85128
Differential Revision: https://reviews.freebsd.org/D11887
Large nextboot.conf files (over 80 bytes) are not read correctly by the
Forth loader, causing file parsing to abort, and nextboot configuration
fails to apply.
Simple repro:
nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shutdown -r now
That will cause the bug to cause a parse failure but shouldn't otherwise
affect the boot. Depending on your loader configuration, you may also
have to set beastie_disable and/or reduce the number of modules loaded
to see the error on a small console screen. 12.0 or CURRENT users will
also have to explicitly use the Forth loader instead of the Lua loader.
The error will look something like:
Warning: syntax error on file /boot/loader.conf.local
foo="xxxxxxxxxxxxxxnextboot_enable="YES"
^
/boot/support.4th has crude file I/O buffering, which uses a buffer
'read_buffer', defined to be 80 bytes by the 'read_buffer_size'
constant. The loader first tastes nextboot.conf, reading and parsing
the first line in it for nextboot_enable="YES". If this is true, then
it reopens the file and parses it like other loader .conf files.
Unfortunately, the file I/O buffering code does not fully reset the
buffer state in the reset_line_reading word. If the last file was read
to the end, that doesn't matter; the file buffer is treated as empty
anyway. But in the nextboot.conf case, the loader will not read to the
end of file if it is over 80 bytes, and the file buffer may be reused
when reading the next file. When the file is reread, the corrupt text
may cause file parsing to abort on bad syntax (if the corrupt line has
<>2 quotes in it), the wrong variable to be set, no variable to be set
at all, or (if the splice happens to land at a line ending) something
approximating normal operation.
The bug is very old, dating back to at least 2000 if not before, and is
still present in 12.0 and CURRENT r345863 (though it is now hidden by
the Lua loader by default).
Suggested one-line attached. This does change the behavior of the
reset_line_reading word, which is exported in the line-reading
dictionary (though the export is not documented in loader man pages).
But repo history shows it was probably exported for the PNP support
code, which was never included in the loader build, and was removed 5
months ago.
One thing that puzzles me: how has this bug gone unnoticed/unfixed for
nearly 2 decades? I find it hard to believe that nobody's tried to do
something interesting with nextboot, like load a kernel and filesystem,
which is what I'm doing.
PR: 239315
Reviewed by: imp
When calling file_findfile with only a type it returns
the first file matching the type. But in fdt_apply_overlays we
then iterate on the next files and try loading them as dtb overlays.
Fix this by checking the type one more time.
Sponsored by: Diablotin Systems
Reported by: Mark Millard <marklmi@yahoo.com>
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)
This adds tslog_init, which allocates a 2MB buffer for recording
timestamped events; and tslog_publish, which takes the buffer and
passes it to the kernel as a "preloaded module". These functions
will be used in a later commit.
Reviewed by: kevans
At present this only supports x86, due to the use of the rdtsc
instruction; and is inert unless a buffer is allocated and passed to
the tslog code (which will be done by a future commit).
Reviewed by: kevans
Caller functions expect __elfN(loadimage) to return a value of zero on
failure and the file size on success.
PR: 256390
Reviewed by: markj
MFC after: 2 weeks
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
A bug in the loader's bzipfs & gzipfs filesystems caused compressed
kernel and modules not to work on EFI systems with a veriexec-enabled
loader. Since the size of files in these filesystems are not known
_a priori_ `stat` would initialize the size to -1 and the loader would
then hang in an infinite loop while trying to seek (read) to the end
of file since the loop termination condition compares the current
offset to that negative target position.
Reviewers: vangyzen, imp, Bret Ketchum (Bret.Ketchum@dell.com)
Differential Revision: https://reviews.freebsd.org/D30414
Sponsored by: Dell EMC Isilon
MFC to: stable/12, stable/13
MFC after: 1 week
The gfx_fb_drawrect() is drawing rectangle by pixels, this can be very
slow on some systems. Use Blt() video fill primitive instead.
Testing done: Tested on mac mini 2012 where the issue was revealed
Reviewed by: yuripv
MFC after: 1 week
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
According to comments in the Makefile, to make pxeboot work we need to
have crt0.o first. This is needed because the simplified loader in
pxeboot assumes that the startup code is at offset 0 in this binary. In
normal booting, the start address can be obtained from headers of the
binary, but since pxeboot encodes this as a pure binary, it has no way
of knowing where that is and assumes 0. Added comments to that effect
in the Makefile.
We've done this by adding it to OBJS before all the other .o's are
added. However, there's a problem. This also adds it to the CLEANFILES
variable, which causes it to be removed from multiple places. The
dependencies may also cause it to be re-built at a time that's after
boot2 is built. This causes installs to fail because at install time
boot2 is considered to be out of date and the programs to rebuild it are
no longer in the path.
Cope with this problem by just adding it to LDFLAGS instead.
Glanced at by: kevans ("I thought that went in ages ago")
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28876
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
As we output spaces around the menu title, we should also check,
if the title is actually empty string.
PR: 255299
Submitted by: Jose Luis Duran
Reported by: Jose Luis Duran
MFC after: 1 week
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
Add a dummy vendor menu entry on the main welcome menu. Vendors can override
this in their local.lua file to create whatever sub-menu they need for their
products.
Also fix the adding a 'welcome' entry as well based on a suggestion from Kyle.
Silly option menu code also from Kyle. They seem to work for me, but any
transcription error is likely mine.
Reviewed by: kevans@ (the vendor stuff)
LLVM12 complains if you change the symbol binding:
`error: _longjmp changed binding to STB_GLOBAL`
In this case LLVM actually ignored the weak directive and used the
later .global, but GNU as would mark the symbol as weak.
None of the other architectures mark the libsa _setjmp as weak so
just drop this directive.
This warning is very rarely useful (inline is a hint and not mandatory).
This flag results in many warnings being printed when compiling C++
code that uses the standard library with GCC.
This flag was originally added in back in r94332 but the flag is a no-op
in Clang ("This diagnostic flag exists for GCC compatibility, and has no
effect in Clang"). Removing it should make the GCC build output slightly
more readable.
Reviewed By: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D29235
When drawing cursor, we should store original display
content because there may be image data we would like to restore
when the cursor is removed.
PR: 254054
Reported by: Jose Luis Duran
MFC after: 3 days
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
Parentheses added to HASZERO macro to avoid a GCC warning, and formatted
with clang-format as we have adopted these and don't consider them
'contrib' code.
Obtained from: musl (snapshot at commit 4d0a82170a25)
Reviewed by: kib (libc integration), mjg (both earlier)
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17630
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
MIPS BERI boot loader is built with -mno-abicalls and -fno-pic
so prevent adding PIE-related build flags.
Fix build after 9a227a2fd6 ("Enable PIE by default on 64-bit architectures")
Obtained from: Semihalf
Sponsored by: Stormshield
Bootloaders for powerpc are not built as position independent
code. Since bsd.prog.mk is used for building, when PIE is enabled,
the PIE flags are added and that causes the build to fail.
Adding MK_PIE=no stops bsd.prog.mk from adding PIE specific flags.
Submitted by: Dawid Gorecki <dgr@semihalf.com>
Reviewed by: emaste
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D28893
When performing buildworld for MIPS with PIE enabled, the build fails
with "position-independent code requires '-mabicalls'" message.
-mno-abicalls and -fno-pic flags are explicitly set in MIPS ubldr
makefile, so to work around this problem, set MK_PIE=no for MIPS
ubldr.
Submitted by: Dawid Gorecki <dgr@semihalf.com>
Reviewed by: emaste
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D28370
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
Notable upstream changes:
778869fa1 Fix reporting of mount progress
e7adccf7f Disable use of hardware crypto offload drivers on FreeBSD
03e02e5b5 Fix checksum errors not being counted on repeated repair
64e0fe14f Restore FreeBSD resource usage accounting
11f2e9a49 Fix panic if scrubbing after removing a slog device
MFC after: 2 weeks
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
While I was there:
- Fix some typos
- Fix an excessive argument "indent" reported by mandoc -Tlint
- Replace a dead link with the one suggested by
https://www.uefi.org/uefi
Submitted by: linimon (in part)
Reviewed by: bcr
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27774
We use ascii box chars with serial console because we do not know
if terminal can draw unixode box chars. Same problem is about userboot
console.
MFC after: 5 days
The VT screen buffer size is calculated based on our default
built in (8x16) font.
With high-resolution display, we want to use at least 8x16 font,
or we will have large unused areas on screen.
MFC after: 1 week
BORDER_PIXELS is left over from picking up the source from illumos
port. Since FreeBSD VT does not use border in terminal size
calculation, there is no reason why should loader use it.
MFC after: 1 week
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
All callers of bi_load64 pass 0 as the addr parameter, so just remove
it and always calculate the last load address from the module chain.
No functional change.
Sponsored by: Citrix Systems R&D
Reviewed by: tsoome, imp
Differential revision: https://reviews.freebsd.org/D28412
According to the Lua 5.4 manual section 6.4.1 ("Patterns"), the interaction
between ranges and classes is not defined and hyphens must be specified at
either the beginning or the end of a set if they are not escaped.
Move all such occurrences to the beginning.
Reported-by: _parv (twitter)
MFC-after: 3 days
This eliminates a lot of stat() calls that happen when lualoader renders the
menu with the default settings, and greatly speeds up rendering on my
laptop.
ftype is nil if loader/loader.efi hasn't been updated yet, falling back to
lfs.attributes() to test.
This is technically incompatible with lfs, but not in a particularly
terrible way.
Reviewed-by: cem
MFC-after: 4 days
Differential Revision: https://reviews.freebsd.org/D27542
There's a currently ad-hoc protocol to hand off the FreeBSD kernel
payload between the loader and the kernel itself when Xen is in the
middle of the picture. Such protocol wasn't very resilient to changes
to the loader itself, because it relied on moving metadata around to
package it using a certain layout. This has proven to be fragile, so
replace it with a more robust version.
The new protocol requires using a xen_header structure that will be
used to pass data between the FreeBSD loader and the FreeBSD kernel
when booting in dom0 mode. At the moment the only data conveyed is the
offset of the start of the module metadata relative to the start of the
module itself.
This is a slightly disruptive change since it also requires a change
to the kernel which is contained in this patch. In order to update
with this change the kernel must be updated before updating the
loader, as described in the handbook. Note this is only required when
booting a FreeBSD/Xen dom0. This change doesn't affect the normal
FreeBSD boot protocol.
This fixes booting FreeBSD/Xen in dom0 mode after
3630506b9d.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D28411
This is all code only run on ARMv4 and ARMv5. Support for these have
been dropped from FreeBSD.
Differential Revision: https://reviews.freebsd.org/D28314
While loading kernel, we check if vt/vbe backend support is included in
kernel and set the tg_kernel_supported flag in gfx_state. unload
command needs to reset this flag to allow next load to perform
this check with new kernel.
Reported by: jhb
On i386, after 6c7a932d0b, the vbefb vt
driver was no longer detected by the loader, if any kernel module was
loaded after the kernel itself.
This was caused by the parse_vt_drv_set() function being called multiple
times, resetting the detection flag. (It was called multiple times,
becuase i386 .ko files are shared objects like the kernel proper, while
this is not the case on amd64.)
Fix this by skipping the set_vt_drv_set lookup if vbefb was already
detected.
Reviewed by: tsoome
efi, like the various ${MACHINE} directories, should have a dependency on
the enabled interpreters.
The general rule here is that any top-level directory that has a program at
any depth within that includes loader.mk should add ${INTERP_DEPENDS} added
to its dependencies so that the appropriate ficl/lua bits are ready before
they begin.
Note that the only directories in-tree that require it but will not get it
in a more appropriate manner are i386 (on amd64), efi, and userboot. i386
and userboot are handled explicitly in Makefile.amd64 where they are added
to S.yes.
Reported-by: bcran
MFC-after: 3 days
lualoader was previously not processing \ as escapes; this commit fixes
that and does better error checking on the value as well.
Additionally, loader.conf had some odd restrictions on values that make
little sense. Previously, lines like:
kernel=foo
Would simply be discarded with a malformed line complaint you might not
see unless you disable beastie.
lualoader tries to process these as well as it can and manipulates the
environment, while forthloader did minimal processing and constructed a
`set` command to do the heavy lifting instead. The lua approach was
re-envisioned from building a `set` command so that we can appropriately
reset the environment when, for example, boot environments change.
Lift the previous restrictions to allow unquoted values on the right hand
side of an expression. Note that an unquoted value is effectively:
[A-Za-z0-9-][A-Za-z0-9-_.]*
This commit also stops trying to weirdly limit what it can handle in a
quoted value. Previously it only allowed spaces, alphanumeric, and
punctuation, which is kind of weird. Change it here to grab as much as it
can between two sets of quotes, then let processEnvVar() do the needful and
complain if it finds something malformed looking.
My extremely sophisticated test suite is as follows:
<<EOF
X_01_simple_string="simple"
X_02_escaped_string="s\imple"
X_03_unquoted_val=3
X_04_unquoted_strval=simple_test
X_05_subval="${X_03_unquoted_val}"
X_06_escaped_subval="\${X_03_unquoted_val}"
X_07_embedded="truth${X_03_unquoted_val}"
X_08_escaped_embedded="truth\${X_03_unquoted_val}"
X_09_unknown="${unknown_val}"
X_10_unknown_embedded="truth${unknown_val}"
X_11_crunchy="crunch$unknown_val crunch"
X_12_crunchy="crunch${unknown_val}crunch"
Y_01_badquote="te"lol"
Y_02_eolesc="lol\"
Y_02_noteolesc="lol\\"
Y_03_eolvar="lol$"
Y_03_noteolvar="lol\$"
Y_04_badvar="lol${"
exec="echo Done!"
EOF
Future work may provide a stub loader module in userland so that we can
formally test the loader scripts rather than sketchy setups like the above
in conjunction with the lua-* tools in ^/tools/boot.
There is no need to keep multiple copies of the relocation code. The
amd64 code works on arm64 with a few small changes to relocation types.
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D28213
Handle malloc failures in vbe_init().
If it should so happen and we do get malloc failure in vbe_init(),
use original mode list.
Replace nitems with nentries to have naming consistency and avoid
confusion with nitems() macro.
Reported by: yuripv, rpokala
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.
This fixes the positioning of the "Welcome to FreeBSD" heading, which was
misplaced after the recent update to Lua 5.4. The issue was previously
masked by a compatibility knob in Lua 5.3 that would cause float-tagged
numbers to render faithfully without the decimal component. Lua 5.4 dropped
that and ensures that it always prints a decimal component, even if it has
to append a ".0" to the value.
Standard division produces a "float", floor division (//) can be used to
guarantee an integer. Floating point operations have been completely ripped
out of the liblua compiled for the bootloader, so this is a nop. This is
decidedly better than trying to hack out the float tag entirely.
Reported-by: mjg, probably others
MFC-after: 3 days
Caller is not interested in symlinks follow them.
Throw an error if too many links encountered.
Reviewed by: stevek
Sponsored by: Juniper Networks
--This line, and those below, will be ignored--
> Description of fields to fill in above: 76 columns --|
> PR: If a GNATS PR is affected by the change.
> Differential Revision: https://reviews.freebsd.org/D### (*full* phabric URL needed).
> Submitted by: If someone else sent in the change.
> Reviewed by: If someone else reviewed your modification.
> Approved by: If you needed approval for this commit.
> Obtained from: If the change is from a third party.
> MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email.
> MFH: Ports tree branch name. Request approval for merge.
> Relnotes: Set to 'yes' for mention in release notes.
> Security: Vulnerability reference (one per line) or description.
> Sponsored by: If the change was sponsored by an organization.
> Empty fields above will be automatically removed.
Change-Id: I4ef92ff256f503c620dc5bba79ed93b32cb2330d
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.
hw.vga.textmode is directing VT VGA backend to use text mode.
The default screen mode for BIOS loader is text, and default
screen mode for VT VGA backend is graphics (unless we are running on
hypervisor or hw.vga.textmode is set to 1). Using hw.vga.textmode
for loader does remove possibility to have graphical mode VT VGA with
text mode loader.
screen.textmode can have possible values "0" to disable text mode,
and "1" to set text mode.
Instead of trying to set reasonable register values, save significant
register values, then prepare for font upload and then restore
registers from saved data.
This seems to fix text mode for most cases where text mode breakage
was reported.
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
Previously having ficl/liblua in LIB32LIST with their respective option
turned OFF would be relatively harmless, as we wouldn't act on it unless we
were building the non-32 variant. As of ac5f382a9d, however, these are
now used for dependencies in some cases and must reflect what's actually
going to be built.
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
loader_conf_dirs is the supporting mechanism for the included
/boot/loader.conf.d directory. When lualoader finishes processing all of
the loader_conf_files it finds after walking /boot/defaults/loader.conf,
it will now check any and all loader_conf_dirs and process files ending
in ".conf" as if they were a loader.conf.
Note that loader_conf_files may be specified in a loader.conf.d config
file, but loader_conf_dirs may *not*. It will only be processed as specified
in /boot/defaults/loader.conf and any loader_conf_files that were loaded
from there.
Reviewed by: allanjude, freqlabs, rpokala, tsoome
Includes suggestion from: imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25608
luacheck rightfully complains that i is unused in the show-module-options
loop at the end (it was used for some debugging in the process).
We've added a new pager module that's compiled in, so declare that as an
acceptable global.
This effectively dumps everything lualoader knows about to the console using
the libsa pager; that particular lua interface was added in r368591.
A pager stub implementation has been added that just dumps the output as-is
as a compat shim for older loader binaries that do not have lpager. This
stub should be moved into a more appropriate .lua file if we add anything
else that needs the pager.
Without this we risk having the .interp section be placed earlier in the
file and mess with section offsets; in particular it has been seen to be
placed at the start of the file and cause the PE/COFF header to not be
at address 0. This is the same fix as was done for arm64 in r365578.
Reviewed by: mhorne, imp
Approved by: mhorne, imp
Differential Revision: https://reviews.freebsd.org/D27603
For the first second otime and ntime are equal so no message gets
printed. Instead we should print the countdown right from the start,
although we do it at the end of the first iteration so that if a key has
already been pressed then the message is suppressed.
Reviewed by: imp
Approved by: imp
Differential Revision: https://reviews.freebsd.org/D26935
This is nearly a 1:1 mapping of the pager API from libsa. The only real
difference is that pager.output() will accept any number of arguments and
coerce all of them to strings for output using luaL_tolstring (i.e. the
__tostring metamethod will be used).
The only consumer planned at this time is the upcoming "show-module-options"
implementation.
MFC after: 1 week
Specifically, we have:
- enable-module
- disable-module
- toggle-module
These can be used to add/remove modules to be loaded or force modules to be
loaded in spite of modules_blacklist. In the typical case, a user is
expected to use them to recover an issue happening due to a module directive
they've added to their loader.conf or because they discover that they've
under-specified what to load.
MFC after: 1 week
The integer arrays are encoded in nvlist as counted array <count, i0, i1...>,
loader xdr_array() is missing the count. This will affect the pool import when
there are hole devices in pool.
Also fix the new data add and print functions.
Follow-up to r353959 and r368070: do the same for other architectures.
arm32 already seems to use its own .fnstart/.fnend directives, which
appear to be ARM-specific variants of the same thing. Likewise, MIPS
uses .frame directives.
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D27387
Pad in forth is used as "scratchpad" and internal implementations
should not use it. Ficl does not really follow this rule and this can fire back.
emit has no need to use pad, we can use local variable instead.
i386 and the rest of supported architectures by defining KERNLOAD in the
vmparam.h and getting rid of magic constant in the linker script, which albeit
documented via comment but isn't programmatically accessible at a compile time.
Use KERNLOAD to eliminate another (matching) magic constant 100 lines down
inside unremarkable TU "copy.c" 3 levels deep in the EFI loader tree.
Reviewed by: markj
Approved by: markj
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D27355
We don't have NEON available in the boot loader, so we have to disable
it. OpenZFS included ZSTD which used the wrong symbol to bring in neon
support. Change to use the code that's been submitted upstream as a
pull request to both.
__ARM_NEON is the proper symbol, defined in ARM C Language Extensions
Release 2.1 (https://developer.arm.com/documentation/ihi0053/d/). Some
sources suggest __ARM_NEON__, but that's the obsolete spelling from
prior versions of the standard.
OpenZFS Pull Request: https://github.com/openzfs/zfs/pull/11055
ZSTD Pull Request: https://github.com/facebook/zstd/pull/2356
We are using asize property from pool label and we do not depend
on partition data to find last two pool labels and to validate LBA for disk IO.
This does allow us to re-enable support for partitionless disk setups.
In some environments is difficult to access bootp/dhcp
configuration as "standard user". Add a command that allows to set
or display the URI of the network server used as "net:" device.
Currently only tftp and nfs protocols are supported.
Typical usage pattern is:
netserver tftp://192.168.168.1/path_to_obj_dir/arm.armv7/sys/GENERIC/
boot net:kernel
Reviewed by: imp, kevans
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D26736
On startup the arm64 efi loaders need to know PC-relative addresses.
Previously we used the adr instruction to find this address, however this
instruction is limited to +/- 1MiB.
Switch to adrp to find the 4k page the address is within and an add to
set the bottom 12 bits. This lets us address +/- 4GiB which should be
large enough for now.
Reported by: imp
MFC after: 2 weeks
Sponsored by: Innovate UK
The OpenZFS code that uses the BMI instructions is broken. Forcibly
disable them to prevent their use. When enabled, the build breaks.
This fixes the build when compiled for a core with BMI instructions.
This is the same fix committed in r364777, for the same issue.
Submitted by: Jung-uk Kim
