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
Add support to the _STANDALONE environment enough bits of the kernel
that we can compile it. We still have a small zstd_shim.c since there
were 3 items that were a bit hard to nail down and may be cleaned up
in the future. These go hand in hand with a number of commits to
sys/sys in the past weeks, should this need be MFCd.
Discussed with: mmacy (in review and on IRC/Slack)
Reviewed by: freqlabs (on openzfs repo)
Differential Revision: https://reviews.freebsd.org/D26218
This was causing build failures in CheriBSD where we were passing -pie
already by default.
Reviewed By: andrew
Differential Revision: https://reviews.freebsd.org/D24787
The EDD v3[1], see table 13, page 33, does define device path as double
qword, that is, 16 bytes, we have only qword.
Also remove edd_device_path_v4 and edd_params_v4 because those are not used,
and there is no size difference in v3 versus v4.
[1] http://www.t13.org/documents/UploadedDocuments/docs2004/d1572r3-EDD3.pdf
MFC after: 2 weeks
- whitespace at end of input line
- skipping paragraph macro: Pp at the end of Sh
- new sentence, new line
- consider using OS macro: Fx
- AUTHORS section without An macro
- skipping paragraph macro: Pp before Ss
In the previous world order, any brand/logo was forced to pull in the
drawer and call drawer.add{Brand,Logo} with the name their brand/logo is
taking and a table describing it.
In the new world order, these files just need to return a table that maps
out graphics types to a table of the exact same format as what was
previously being passed back into the drawer. The appeal here is not needing
to grab a reference back to the drawer module and having a cleaner
data-driven looking format for these. The format has been renamed to 'gfx-*'
prefixes and each one can provide a logo and a brand.
drawer.addBrand/drawer.addLogo will remain in place until FreeBSD 13, as
there's no overhead to them and it's not yet worth the break in
compatibility with any pre-existing brands and logos.
Reviewed by: freqlabs
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24966
OpenZFS will start using some of the kernel timekeeping bits
shortly. This implements the bare minimum of that which currently
is just the time_seconds variable.
Report what console the boot loader is telling the kernel to use:
o Dual (Serial Primary)
o Dual (Video Primary)
o Serial
o Video
This allows the user to interrupt the boot and tweak the cosnole, if
needed, in a trivial way. Useful for installs where the default
selected may not be quite what you want, or when you are running a
dual setup and need to toggle over to the other console being primary.
The 'c'/'C' keys will do the cycling through the consoles. Note:
you'll still have to drop into the loader to set details about serial
consoles. And this doesn't change the console the loader is using.
Reviewed by: kevans@
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D26573
The video on PCI heuristic was broken. It was supposed to infer a
video device when the last element of the path was a PCI DEVICE PATH
node. However, the last node in the device path is an END node, so
this heuristic never fired.
This leads, among other things, to bhyve only producing output in the
serial connection once we leave the boot loader. This restores the
dual headed boot on bhyve + UEFI (as we did in 11.2), but will favor
serial in the absence of other config which may be a change from 11.2.
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D26572
During devswitch probe, we pick boot pool based on boot disk, if the boot
disk happens to have multiple pools in freebsd-zfs partitions, the current
code does pick last pool from boot disk as boot pool. While there is no
way at that stage to test, the more logical approach would be to pick
first matching pool.
This patch is assuming we do pass pool guid pointer with guid value 0,
this will help us to determine, if the guid value is already set or not.
The general suggestion would be not to share disk between different pools.
Reported by: Alexander Leidinger
There was a small window cp was broken. Work around this by using :>
instead of cp /dev/null. Ideally, we'd keep the cp /dev/null in the
build as a regression test, but doing so breaks people that upgraded
during the cp breakage and this is simpler than bootstrapping a
working cp since there's no good __FreeBSD_version sign posts for
that.
Suggested by: lots of people
Too stubborn for his own good: imp
This is the initial set up for PowerPC64LE.
The current plan is for this arch to remain experimental for FreeBSD 13.
This started as a weekend learning project for me and kinda snowballed from
there.
(More to follow momentarily.)
Reviewed by: imp (earlier version), emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26399
I had overthought how to do the FICL_TRUE change. We do not need to
explicitly specify how big the 0 is before the cast to the correct size.
The same change was suggested by both imp@ and Gunther Nikl independently.
Tested on powerpc.
Reported by: imp, Gunther Nikl
Extend the powerpc relative relocation handling from r240782 to a
handful of other architectures. This is needed to properly read
dependency information from kernel modules.
Reviewed by: jhb
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D26365
bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.
By default, the bootonce setting is reset on attempt to boot and the next
boot will use previously active BE.
By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will
be set permanently active.
bootonce dataset name is recorded in boot pool labels, bootenv area.
in case of nextboot, the nextboot_enable boolean variable is recorded in
freebsd:nvstore nvlist, also stored in boot pool label bootenv area.
On boot, the loader will process /boot/nextboot.conf if nextboot_enable
is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf
processing on next boot.
bootonce and nextboot features are usable in both UEFI and BIOS boot.
To use bootonce/nextboot features, the boot loader needs to be updated on disk;
if loader.efi is stored on ESP, then ESP needs to be updated and
for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated
(gpart or other tools).
At this time, only lua loader is updated.
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25512
In D12421, the ability to compile stand/ in little-endian was added, with the
intention to extend loader.kboot to run in Petitboot.
However, no further work was done, as the kernel then gained self-execution
capabilities as Petitboot was taught to load FreeBSD kernels directly.
The FreeBSD installer on powerpc64 (on POWER8 and POWER9) uses
/boot/etc/kboot.conf instead of loader.
As this option does nothing but cause stand/ to be miscompiled and actively
causes confusion, remove it.
(I have a functioning petitboot loader in my local tree, however, it turned
out to be quite inconvient to use due to the current petitboot plugin design
so I put it on hold.)
Reviewed by: emaste, imp, jhibbits
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26430
Currently, the only thing that prevents a functioning 64-bit FICL build is
a few integer types that were intended to be fixed-width.
Changing them to C99 integer types allows building a functioning 64-bit
FICL.
While this isn't applicable to the default settings of any in-tree loaders,
it is necessary for a future Petitboot loader, due to the requirement that
it be compiled as a 64-bit program.
Reviewed by: tsoome, imp (earlier revision)
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26364
This would allow interested parties to do experimental runs with an
environment set appropriately to raise all the warnings throughout the
build; e.g. env WARNS=6 NO_WERROR=yes buildworld.
Not currently touching the numerous instances in ^/tools.
MFC after: 1 week
When building the loader an unneeded .interp section may be added. Move
this to the unused section region so offsets of used sections don't
change.
Obtained from: CheriBSD
Sponsored by: Innovate UK
A bug in the EFI HTTP driver of TianoCore EDK2 causes memory
corruption when an http instance that uses tls is reconfigured,
leading to a crash.
Work around this by forcing a new http instance for each request
instead of reconfiguring the existing one.
The upstream bug report is https://bugzilla.tianocore.org/show_bug.cgi?id=1917
Submitted by: bcran
Reviewed By: imp, kevans, tsoome
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21281
Adjust a couple of printf() lines that deal with dumping out addresses
to cast to uintmax_t.
This allows building a 64-bit libofw for use in things like a future
Petitboot loader for PowerPC64, and other FDT platforms that require
a 64-bit loader binary and want to use forth.
Sponsored by: Tag1 Consulting, Inc.
OZFS is the top of the OpenZFS tree (aka src/sys/contrib/openzfs).
ZFSOSSRC is the path to the OepnZFS sources
ZFSOSINC is the path to the OepnZFS includes
MFC After: 3 days
Move hexdump from stand/common/misc.c to stand/libsa/hexdump.c
(svn cp)
Disable use of pager - causes linking issue for boot1
can be re-enabled by defining HEXDUMP_PAGER.
Reviewed by: stevek, imp
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D26235
Some external code requires a specific set of include paths to work
properly since it emulates the typical environment the code is used
in. Enable this by creating a CFLAGS_EARLY.file variable that can be
used to build this stack. Otherwise the include stack we build for
stand programs may get in the way. Code that uses this feature has to
tolerate the normal stack of inclues being last on the list (and
presumably unused), though.
Generally, it it should only be used for the specific include
directories. Defines and that sort of thing should be done in the
normal CFLAGS variable. There is a global CFLAGS_EARY hook as well for
everything in a Makefile.
Please note that neither zstd nor encryption is
supported by the loader at this instant. This
change makes it safe to use those features in
one's root pool, but not in one's root dataset.
This is a change in preparation for stopping to use lorder.sh (D26044) and
instead assume that we have a linker newer than ~1990. Without lorder.sh
duplicates end up being passed to the linker when building .so files and this
can result in duplicate symbol definition errors.
There is one minor change: libcompiler_rt.a will no longer provide
gcc_personality_v0 and instead we now only have it in libgcc_eh.a/libgcc_s.so.
This matches GCC's behaviour.
Reviewed By: emaste, cem
Differential Revision: https://reviews.freebsd.org/D26042
than command in the loader.conf, the latter needs to be nul terminated,
otherwise garbage trailer left from zfs_nextboot() will be passed to
parse_cmd() together with loader.conf command.
While here, reset cmd to empty string if read() returns error.
Reviewed by: tsoome
It can be useful to know what type of machine we are running on for desktop
related thing.
It also allow us to support all the DMI variable that linux driver can fetch.
MFC after: 1 week
Sponsored by: Sponsored-by: The FreeBSD Foundation
The checkpoints are another way of keeping the state of ZFS.
During the rewind, the pool has to be exported.
This makes checkpoints unusable when using ZFS as root.
Add the option to rewind the ZFS checkpoint at the boot time.
If checkpoint exists, a new option for rewinding a checkpoint will appear in
the bootloader menu.
We fully support boot environments.
If the rewind option is selected, the boot loader will show a list of
boot environments that existed before the checkpoint.
Reviewed by: tsoome, allanjude, kevans (ok with high-level overview)
Differential Revision: https://reviews.freebsd.org/D24920
When building on macOS with sh==zsh, newvers.sh was producing an
unterminated string literal due to \\n being turned as a newline. Fix this
by using a here document instead.
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D26036
Since the make variable STRIP is already used for other purposes, this
uses STRIPBIN (which is also used for the same purpose by install(1).
This allows using LLVM objcopy to strip binaries instead of the in-tree
elftoolchain objcopy. We make use of this in CheriBSD since passing
binaries generated by our toolchain to elftoolchain strip sometimes results
in assertion failures.
This allows working around https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248516
by specifying STRIPBIN=/path/to/llvm-strip
Obtained from: CheriBSD
Reviewed By: emaste, brooks
Differential Revision: https://reviews.freebsd.org/D25988
Fix typo in interp_include() invocation (missing 'p')
Remove setting tftpip, as servip is used by the tftp code in libsa. There
is no separate tftpip global variable any more.
Obtained from: Juniper Networks, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25897
On RISC-V, Clang warns with:
cast to smaller integer type 'unsigned int' from 'void (*)(void *)'
Instead, use %p as the standard format specifier for printing pointers.
Whilst Arm's pointer size is the same as unsigned, it's still cleaner to
use the right thing there too.
Reviewed by: brooks (mentor), emaste
Approved by: brooks (mentor), emaste
Differential Revision: https://reviews.freebsd.org/D25718
I made an attempt to fix this in r362978, but all it really did was
confine the issue to the $MACHINE_CPUARCH == "riscv" case. The real
problem is that LINKER_FEATURES is not defined here, so bsd.linker.mk
needs to be included.
This error with cleandir only occurs when META_MODE is disabled, which
explains why it was missed by both CI and myself.
Note that this effectively reverts r362978.
Reported by: mjg
Reviewed by: imp, kevans (in IRC)
The origin text was: "Syntax for devices is odd."
That is not very helpful.
PR: 199103
Reviewed by: kevans, tsoome
Sponsored by: Klara Inc.
Event: July 2020 Bugathon
Differential Revision: https://reviews.freebsd.org/D25629
Correct a small mistake in r363060's backaout of r362998 by reverse-applying
r362998 by hand to loader.conf.
Differential Revision: https://reviews.freebsd.org/D25606
Because we need to read asize from vdev_tree. We also need to consider
different vdev type difference.
Reviewed by: allanjude
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25586
The DIOCGMEDIASIZE is calculated md->md_sectorsize * md->md_provsize, and
for boot disk, the md_sectorsize is 4k. However, the md_provsize is already
in units of bytes.
Sponsored by: Netflix, Klara Inc.
This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.
I've tested this with the following boot flows:
OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD
OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD
Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required,
as the HSM extension is needed to bring them up explicitly. Because of this,
using BBL as the SBI implementation will not be possible. Additionally, there
are a few recent u-boot changes that are required as well, all of which will be
present in the upcoming v2020.07 release.
Looks good: emaste
Differential Revision: https://reviews.freebsd.org/D25135
The zfs reader development did reach to the point where linking boot1,
we will get errors about duplicate symbols Malloc, Free, Calloc.
We can just use libsa version, just as loader.efi does. The only concern is,
libsa zalloc is using fixed size heap region, I did pick 64MB as other
stage instances are using, but this size is likely not optimal. In any case,
with limited memory setups, we should boot loader.efi directly.
Sponsored by: Netflix, Klara Inc.
The vdev_init() does check for "known" vdev types, the [log] device removal will create "hole"
device, but vdev_init() does not allow it.
Obtained from: illumos
MFC after: 1 week
These are picked out by the amd64-gcc6 build; time() is declared in <time.h>
and delay() is declared in <bootstrap.h>. These are the correct places for
these in stand/, so remove the duplicate declarations and make sure the
delay() consumer in libefi that depended on the extra delay() declaration
includes <bootstrap.h>.
MFC after: 1 week
We should have nextboot feature implemented in libsa zfs code.
To get there, I have created zfs_nextboot() implementation based on
two sources, our current simple textual string based approach with added
structured boot label PAD structure from OpenZFS.
Secondly, all nvlist details are moved to separate source file and
restructured a bit. This is done to provide base support to add nvlist
add/update feature in followup updates.
And finally, the zfsboot/gptzfsboot disk access functions are swapped to use
libi386 and libsa.
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25324
fs_summary_info structure. This change was originally done
by the CheriBSD project as they need larger pointers that
do not fit in the existing superblock.
This cleanup of the superblock eases the task of the commit
that immediately follows this one.
Suggested by: brooks
Reviewed by: kib
PR: 246983
Sponsored by: Netflix
Inject \e[J to erase the initial loader screen. We have two options,
find where out cursor is and use BIOS scroll for data from boot2 or erase the
display and start from origin. Erasing the screen is easier and we also
get the screen buffer initialized.
Sponsored by: Netflix, Klara Inc.
Having libzfs.h wrapped in LOADER_ZFS_SUPPORT check does not really make sense,
because we do need function declarations with C99.
Sponsored by: Netflix, Klara Inc.
On some UEFI implementations the ConsOut EFI variable is not a device
path end type so we never move to the next node. Fix this by always
incrementing the device path node pointer, with a sanity check that
the node length is large enough so no two nodes overlap.
While here return failure on malloc failure rather than a NULL pointer
dereference.
Reviewed by: tsoome, imp (previous version)
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25202
Rework to simplify and impose sane url syntax.
That is we allow for file://[devname[:fstype]]/package
Reviewed by: stevek
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D25134
The filename is nearly always wrong since it's /boot/lua/loader.lua, which
is not useful for diagnostics. The actual errmsg will include a lua filename
if this is relevant.
Dropping "LUA" while we're here because that's almost universally
irrelevant to whatever error follows, unless the error states that it's
actually a lua problem.
Both of these are minor nits that just detract from identifying the
pertinent information.
MFC after: 3 days
The u-boot EFI implementation of the ReadBlocks and WriteBlocks methods
requires that the provided buffer meet the IO alignment requirements of
the underlying disk. Unlike loader.efi, gptboot.efi doesn't check this
requirement, and therefore fails to perform a successful read. Adjust
secbuf's alignment to 4K in hopes that we will always meet this
requirement.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25111
At least one user has landed in a scenario where logo files appear to be
misnamed, and we failed to find them. Our fallback for missing logodefs is
orb/orbbw, based on the color status. In a scenario where we can't locate
the logos, though, this is not ideal. Add in one more layer of fallback
to properly just don't draw any logo if the fan has been jam packed with
foreign material.
PR: 246046
MFC after: 3 days
- Use enc_xform_aes_xts.setkey() directly instead of duplicating the code
now that it no longer calls malloc().
- Rather than bringing back all of xform_userland.h, add a conditional
#include of <stand.h> to xform_enc.h.
- Update calls to encrypt/decrypt callbacks in enc_xform_aes_xts for
separate input/output pointers.
Pointy hat to: jhb
Some time after r338418, I believe with -Os/-Oz -ffunction-sections
-fdata-sections, the bootprog_interp variable that held our "$Interpreter:"
marker started getting strip from all loaders, with exception to userboot
since it used bootprog_interp to determine what flavor of userboot it was.
At some point, it had been brought to my attention that this was no longer
working and I had worked up some potential solutions to use the variable
that involved printing it out. My vague recollection is that this was
rejected, and I forgot to explore the alternatives; I cannot find records of
this discussion anymore.
Fast forward to present day, Andrew reported that it was non-functional and
offered (effectively) this patch (sans comment) to stop the compiler from
optimizing it out by assigning it to a volatile variable. This removes
concerns about user-facing change while retaining the interpreter marker.
Furthermore, it could certainly be uglier.
Reported and tested by: Andrew Gierth <andrew_tao173.riddles.org.uk>
MFC after: 3 days
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.
Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802
The same thing can be achieved using the bs=$SIZE and conv=sync options.
Unlike conv=osync, conv=sync is support on both Linux and macOS.
Reviewed By: imp, jhb (earlier version)
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D24788
When reading less than sector size but from sector boundary,
the vdev_read() will read full sector into the provided buffer
and therefore corrupting memory past buffer end.
MFC after: 2 days
We need to ensure the buffers are aligned before passing them to ReadBlocks.
Assume 512 bytes is enough for now.
Reviewed by: imp
MFC after: 1 month
Sponsored by: Innovate UK
Also, dmabuf appears to only be set for sparc64 case, but there was a
comment at its only use that says it was broken for some apple
adapters. #ifdef it all of that out now that nothing sets it.
Due to the way claiming works, we need to ensure on AIM OFW machines that
we don't have overlapping ranges on any step of the load.
Load boot1.elf at 0x38000 so it will not overlap with anything even if the
entire PReP partition gets loaded by OFW.
Tested on an iBook G4, a PowerBook G4, a PowerMac G5, and qemu pseries.
(qemu pseries is broken without this patch due to the high address used
by lld10.)
Reviewed by: adalava
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D24623
The previous interface was pretty bad, and required the caller to get some
implementation details correct that it really shouldn't need to (e.g.
loader_conf_files handling) and pass in an empty table for it to use.
The new and much improved interface, readConf, is much less of a hack;
hiding these implementation details and just doing the right thing.
config.lua will now use it to process /boot/defaults/loader.conf and the
subsequent loader_conf_files from there, and read-conf will also use it.
This improvement submitted by Olivier (cited below), loader_conf_files
handling from the original patch was changed to just clobber it before
processing and not bother restoring it after the fact following r360505
where it's now guaranteed to evade the loader environment.
PR: 244640
Submitted by: Olivier Certner (olivier freebsd free fr>
This new table should be used for transient values that don't need to end up
in the loader environment. Generally, these will be things that are internal
details that really aren't needed or interesting outside of the config
module (e.g. if we changed how ${module}_* directives work, they might use
this instead).
To start, populate it with loader_conf_files. Any specific value of
loader_conf_files isn't all that interesting; if we're going to export it,
we should really instead export a loader_conf_files that indicates all of
the configuration files we processed. This will be used to reduce
bookkeeping overhead in a future commit that cleans up readConfFiles.
A future change in lualoader may take some liberties with the
loader_conf_files in the name of efficiency; namely, it may start omitting
it from the loader environment entirely so that it doesn't need to worry
about maintaining any specific value.
This variable has historically been incredibly volatile anyways, as it may
get set to completely different values in any given configuration file to
trigger a load of more files.
Document now that we may not maintain it in the future, but perhaps we'll
reserve the right to change our minds and eventually formally export all of
the loader configuration files that were read using this variable.
MFC after: 3 days
While we're here, let's stylize these as functions instead of just raw text.
A future change may allow arbitrary data arguments to be passed some of
these, and the distinction is useful.
This makes sure that config.readConfFiles doesn't see a stale
loader_conf_files from before, in case the newly loaded file doesn't set it.
MFC after: 3 days
This is a straightforward match to the command used by many in forthloader;
it uses the newly-exported config.readConfFiles() to make sure that any
loader_conf_files gets done as appropriate.
PR: 244640
Submitted by: Olivier Certner <olivier freebsd free fr>
MFC after: 3 days
In the process, change it slightly: readConfFiles will take a string like
loader_conf_files in addition to the loaded_files table that it normally
takes. This is to facilitate the addition of a read-conf CLI command, which
will just pass in the single file to read and an empty table.
MFC after: 3 days
We don't actually need to fetch loader_conf_files as much as we do; we've
already fetched it once at the beginning, we only really need to fetch it
again after each file we've processed. If it changes, then we can stash that
off into our local prefiles.
While here, drop a note about the recursion so that I stop trying to
change it. It may very well make redundant some of the work we're doing, but
that's OK.
MFC after: 3 days
These mappings are never visible to userspace as they get replaced when
the amd64 pmap is bootstrapped, but there is no need to set PG_U in the
first place.
Reviewed by: alc, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24547
This stops the compiler from using the x18 register. Some UEFI
implementations assume this will be preserved when calling the Boot
Services.
MFC after: 2 weeks
Sponsored by: Innovate UK
Make menu customizations easier by naming the entries and using the
names to build the table entries.
Reviewed by: kevans
Approved by: mav (mentor)
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D24527
This code was trying to use a pointer value for st_dev, which is definitely
not a pointer. Instead, cast to uintptr_t so it becomes a non-pointer value
before casting it.
Tested: mips-gcc cross compile, mips32 build
prison0's hostuuid will get set by the hostid rc script, either after
generating it and saving it to /etc/hostid or by simply reading /etc/hostid.
Some things (e.g. arbitrary MAC address generation) may use the hostuuid as
a factor in early boot, so providing a way to read /etc/hostid (if it's
available) and using it before userland starts up is desirable. The code is
written such that the preload doesn't *have* to be /etc/hostid, thus not
assuming that there will be newline at the end of the buffer or even the
exact shape of the newline. White trailing whitespace/non-printables
trimmed, the result will be validated as a valid uuid before it's used for
early boot purposes.
The preload can be turned off with hostuuid_load="NO" in /boot/loader.conf,
just as other preloads; it's worth noting that this is a 37-byte file, the
overhead is believed to be generally minimal.
It doesn't seem necessary at this time to be concerned with kern.hostid.
One does wonder if we should consider validating hostuuids coming in
via jail_set(2); some bits seem to care about uuid form and we bother
validating format of smbios-provided uuid and in-fact whatever uuid comes
from /etc/hostid.
Reviewed by: karels, delphij, jamie
MFC after: 1 week (don't preload by default, probably)
Differential Revision: https://reviews.freebsd.org/D24288
