Loading the kernel and modules can be really slow. Loading before the menu
draws and every time one changes kernel/boot environment is even more
painful.
Defer loading until we either boot, auto-boot, or escape to loader prompt.
We still need to deal with configuration changes as the boot environment
changes, but this is generally much quicker.
This commit strips all ELF loading out of config.load/config.reload so that
these are purely for configuration. config.loadelf has been created to deal
with kernel/module loads. Unloading logic has been ripped out, as we won't
need to deal with it in the menu anymore.
Discussed in part with: allanjude
r329550 introduced config.kernel_loaded. config.load() doesn't provide a
means of overriding the kernel to load, but that likely isn't necessary as
it will not be a common case. When loading the kernel, just attempt to load
the kernel previously loaded and specified in config.kernel_loaded.
If we haven't loaded a kernel yet, config.kernel_loaded will be unset/nil
and the "default"/first kernel found will be loaded. If we've loaded a
kernel, we'll try to load that same kernel again and fallback to the default
kernel if we need to.
This in also in support of upcoming boot environment support.
'nil' means the 'first kernel found in module_path', which is the same
interpretation as passing 'nil' to loadkernel.
Otherwise, it denotes the name of a kernel that we've successfully loaded.
When reloaded later, we will still need to do the full search again to
locate the actual kernel in case things have changed, so just the name is
good enough.
This is in support of upcoming boot environment support. vfs.root.mountfrom
and currdev will be changed, then we will reload configuration and attempt
to reload the currently chosen kernel unless we shouldn't.
In the worst case scenario, we have no passwords to prompt for and we end up
just clearing the screen twice before we draw the menu or proceed with boot.
In the best case scenario, we don't try drawing password prompts amidst a
bunch of kernel/module loading.
This solve problem when booting with efi on armv7
Reviewed by: imp, tsoome
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D14415
Some other points I think we need to be consistent on:
- Spacing around string concatenation (always)
- Test against 'nil' explicitly rather than relying on 'not' for things that
reasonably won't be returning a boolean. e.g. loader.getenv
Eventually this will all get formalized somewhere.
Once we've successfully loaded a kernel, we add its directory to
module_path. If we switch kernels with the kernel selector, we again prepend
the kernel directory to the current module_path and end up with multiple
kernel paths, potentially with mismatched kernel/modules, added to
module_path.
Fix it by caching module_path at load() time and using the cached version
whenever we load a new kernel.
In a similar fashion to FILE, provide thin shims for the standard directory
manipulation functions.
Reviewed by: imp
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D14417
These are the style points that I'd like to try and maintain in our lua
scripts:
- Parentheses around conditionals
- Trailing semicolons, except on block terminators
- s:method(...) instead of string.method(s, ...) where applicable
There's likely more, but that'll get hammered out as we continue.
Prompt for GELI passphrase when geom_eli_passphrase_prompt has been set to
"YES" in loader.conf(5).
This entailed breaking out the password prompt into its own function that
can be reused between the password compare bits and this prompt that simply
takes the entered password and passes it along in the environment as
kern.geom.eli.passphrase.
I've also added a TODO to re-evaluate later if we want the "password
masking" -- it is currently not functional, so one still can't observe the
length of the password typed at the prompt.
This is the procedure that config.loadkernel tries to go through, but
reloading kernel config didn't use this function. Amend config.loadkernel to
take an optional other_kernel.
While here, be a little more verbose ("Trying to load kernel") so that it's
easy to follow where we've gone wrong.
1.) Instead of string.function(s, ...), use s:function(...)
2.) Don't try to concatenate `res`, it was just tested to be nil
3.) Note that "Loading configuration" is configured modules, and be a little
more precise in mentioning what failed ("loading of one or more modules")
An empty module_path to start with isn't ideal, but if all modules are
contained within a kernel directory (which is what we just tested) then it
isn't strictly an error. Don't assume that module_path has a value already.
When we fail to load the kernel, printing the result (which is guaranteed to
be nil) is not intended; print the name of the kernel.
autoboot_delay=NO is documented to wait for input and *not* autoboot, which
is the exact opposite of the current behavior.
Additionally, autoboot_delay=-1 is documented to disallow the user from
interrupting the boot (i.e. autoboot immediately), which was not previously
honored.
This also fixes the case insensitive comparison to be truly case
insensitive. This is kind of nit-picky, but the previous version would only
accept "no" and "NO".
Don't move this into config.reload because we may want to force reloads if
/boot changes out from under us later.
As a caution: changing kernels in lualoader at the moment might not be
loading all of your modules (in my testing, at least) from loader.conf(5).
This is a known problem.
Decimals screw up the escape sequence and the cursor will not get set. Right
now this only affects setting the cursor for drawing "Welcome to FreeBSD" --
the resulting number after our (x+(w/2)-9) calculation gets output as
"14.0."
This should be fixed at the interpreter level, rather than here, but this is
not a widespread problem at the moment so we'll fix it up in further work.
Reported by: David Wolfskill <david@catwhisker.org>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D14375
ffs_sbget() may return a superblock buffer even if it fails, so the
caller must be prepared to free it in this case. Moreover, when tasting
alternate superblock locations in a loop, ffs_sbget()'s readfunc
callback must free the previously allocated buffer.
Reported and tested by: pho
Reviewed by: kib (previous version)
Differential Revision: https://reviews.freebsd.org/D14390
This is a pre-cursor to boot environment support in lualoader. Create a new
menu item type, "carousel_entry", that generally provides a callback to get
the list of items, a carousel_id for storing the current value, and the
standard name/func functions that an entry has.
The difference between this and a normal menu item, functionally, is that
selecting a carousel item will automatically rotate through available items
and wrap back at the beginning when the list is exhausted.
The 'name' function takes the choice index, current choice, and the list of
choices as parameters so that the menu item can decorate the name freely as
desired.
The 'func' function takes the current choice as a parameter, so it can act
accordingly.
The kernel menu item has been rewritten to use the carousel_entry type as
both an example and initial test of its functionality before it is used for
boot environment options.
Noting that we're in lualoader is nice, but it's not a difference we raelly
need to expose to Fred. Re-word it to match the 4th wording and reduce
differences.
This removes a redundant alias that has since been converted into a global
alias. It was converted to a global alias before to ensure that we always
have a way to go up one level in the menu.
Set it based on hint.acpi.0.rsdp. Initially, hint.acpi.0.disabled will be
respected. "Using System Defaults" will override whether it's explicitly
disabled by hint and re-load it based on whether it's present on the system.
Unlike the 4th version, this is not restricted to x86. I have no strong
reasoning for this, so this is definitely open to change.
This submenu is likely going to go away in favor of kernel selection as it
is done in forth at the moment, but for the time being don't descend into it
if we have no kernels available for listing.
OK. We don't really need a bsd.stand.mk, and it was causing a -fPIC
for the toolchain to be added (bogusly) when building on amd64. Pull
all relevant defs back into defs.mk and delete bsd.stand.mk.
This saves about 15-20k on i386 loader and zfsloader which when
combined with Lua give us a lot more stack space in those constrained
environments.
bootp/arp/rarp/rpc all use the sendrecv implementation in net.c. tftp has
its own implementation because it passes an extra parameter into the recv
callback for the received payload type to be held.
These sendrecv implementations are otherwise equivalent, so consolidate
them. The other users of sendrecv won't be using the extra argument to recv,
but this gives us only one place to worry about respecting timeouts and one
consistent timeout behavior.
Tested by: sbruno
Reviewed by: sbruno, tsoome
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14373
metadata load files were consolidated in r329190, and these relocation fixup
bits were inadvertently dropped in the process. Re-add them to fix boot with
ubldr.
Glanced over by: jhibbits
X-MFC-With: r329190
Scan only the BLOCK IO MEDIA once instead of each time for each type of
device (fd, cd and hdd).
Leave the mechanism to free and reprobe all devices if one day we want
to implement a "dev rescan" thing.
Reviewed by: imp, tsoome
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D14334
readip() doesn't, at the moment, properly indicate to callers that it has
timed out. One can tell that it's timed out if errno == EAGAIN when it
returns, but this is not ideal. Restructure it a little bit to explicitly
set errno to ETIMEDOUT if we've exhausted tleft.
I found two places that care about where it timed out or not: sendrecv in
net.c and sendrecv_tftp. Both are structured to pass smaller timeout values
to readip while tracking a larger timeout. Neither of them were able to do
this properly with readip not indicating ETIMEDOUT, so fix it.
While here, straighten out the time (t/t1) usage in sendrecv_tftp.
This would have manifested itself in periodic failures to NFS/TFTP boot for
no apparent reason because MINTMO/MAXTMO were not actually being respected
properly. Problems were not reported with NFS, only TFTP.
Reported by: sbruno
Reviewed by: sbruno, tsoome
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D14350
Summary:
All metadata.c files are very similar, with only trivial changes. Unify them
into a single common file, with minor special-casing where needed.
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D13978
These are the .lua files from from Pedro Souza's 2014 Summer of Code
project. Rui Paulo, Pedro Arthur and Wojciech A. Koszek also
contributed.
Obtained from: https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
Sponsored by: Google Summer of Code
Improve the SoC lua menu code to bring it in line with forth
menu functionality
Submitted by: Zakary Nafziger
Sponsored by: FreeBSD Foundation
Use loader.setenv and loader.unsetenv instead of loader.perform
Convert from include("/boot/foo.lua") to foo = require("foo");
to bring in line with latest lua module conventions.
Enforce a uniform style for the new .lua files:
o hard tab indenation for 8 spaces
o don't have if foo then bar; else bas; end on one line
MFC After: 1 month
Relnotes: yes
Differential Review: https://reviews.freebsd.org/D14295
liblua glues the lua run time into the boot loader. It implements all
the runtime routines that lua expects. In addition, it has a few
standard 'C' headers that nueter various aspects of the LUA build that
are too specific to lua to be in libsa. Many refinements from the
original code to improve implementation and the number of included lua
libraries. Use int64_t for lua_Number. Have "/boot/lua" be the default
module path. Numerous cleanups from the original GSoC project,
including hacking libsa to allow lua to be built with only one change
outside luaconf.h.
Add the final bit of lua glue to bring in liblua and plug into the
multiple interpreter framework, previously committed.
Add LOADER_LUA option, currently off by default.
Presently, this is an experimental option. One must opt-in to using
this by defining WITH_LOADER_LUA and WITHOUT_FORTH. It's been
lightly tested, so keep a backup copy of your old loader handy.
The menu code, coming in the next commit, hasn't been exhaustively
tested. A LUA boot loader is 60k larger than a FORTH one, which is
80k larger than a no-interpreter one. Subtle changes in size
may tip things past some subtle limit (the binary is ~430k now
when built with LUA). A future version may offer coexistance.
Bump FreeBSD version to 1200058 to mark the milestone.
Pedro Souza's 2014 Summer of Code project. Rui Paulo, Pedro Arthur,
Zakary Nafziger and Wojciech A. Koszek also contributed. Warner Losh
reworked it extensively into its current form.
Obtained from: https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
Sponsored by: Google Summer of Code
Relnotes: Yes
MFC After: 1 month
Differential Review: https://reviews.freebsd.org/D14295
r328536 broke symbol loading on amd64 at least (and probably other
arches). r328826 contained the problem to ppc only by adding
pre-processors guards.
Fix this properly by moving the endianness conversion to separate
helper functions, and make the conversion more robust by using sizeof
instead of having to manually code the size of each field.
Finally list the fields in each structure in a macro in order to avoid
code repetition.
Sponsored by: Citrix Systems R&D
Reviewed by: kib emaste wma
Differential revision: https://reviews.freebsd.org/D14267
reflect what scripting language was compiled into the loader. I
anticipate that being able to find this out quickly from the OK prompt
will be useful in troubleshooting in the future.
Since it's not possible to unset a variable easily, create a new
variable 'PIC' to signal that we are creating a shared object that we
want to install. defs.mk refains from defining NO_PIC and ITNERALLIB
when PIC is defined. This unbreaks userboot.so building.
4 space indentation with a mix of tabs and spaces is a hassle. Update
to project-standard hard-tabs with 8-space indentation in these files.
This matches the new code coming in better as well.
As a followup to r328101, ignore relocation tables for ELF object
sections that are not memory resident. For modules loaded by the
loader, ignore relocation tables whose associated section was not
loaded by the loader (sh_addr is zero). For modules loaded at runtime
via kldload(2), ignore relocation tables whose associated section is
not marked with SHF_ALLOC.
Reported by: Mori Hiroki <yamori813@yahoo.co.jp>, adrian
Tested on: mips, mips64
MFC after: 1 month
Sponsored by: DARPA / AFRL
PowerPC Apple hardware, and likely all Open Firmware systems.
The loader would allocate memory for its heap at whatever address Open
Firmware gave it, which would in general be the lowest unallocated address,
usually starting a page or two above 0. As the kernel is linked at 1 MB,
and loader insists on running the kernel at its link address, any heap
larger than 1 MB would overlap the kernel, causing loader memory allocations
to corrupt the kernel and vice versa.
Although r328806 made this problem much worse by increasing the heap size
to 8 MB, causing 88% of the loader heap to overlap with the kernel, the
problem has always existed. The old heap size was 1 MB and, unless that
started exactly at zero, which would cause other problems, some number of
pages of the loader heap still overlapped with the kernel.
This patch solves the issue in two ways and cleans up some related code:
- Moves the loader heap inside of the loader. This guarantees that the
heap will be contiguous with the loader and simplifies the heap
allocation code at no cost, since the heap lives in BSS.
- Moves the loader, previously at 28 MB and dangerously close to the kernel
it loads, a bit higher to 44 MB. This has the effect of breaking loader
on non-embedded PPC machines with < 48 MB of RAM, but we did not support
those anyway.
The fundamental problem is that the way loader loads ELF files is
incredibly fragile, but that can't be fixed without fundamental
architectural changes.
MFC after: 10 days
The cross-endian loader change in r328536 (review D12422) broke symbol
loading on (at least) amd64 kernels. Temporarily paper over the issue
by restricting the cross-endian support to only powerpc, until a proper
fix arrives.
Submitted by: royger
preference to LIBFICL{,32}. LIBFICL{,32} are now always defined, but
LDR_INTERP{,32} is defined empty when building w/o forth (aka the
simple interpreter) and defined to LIBFICL{,32} when we are building
forth.
I had thought that this would be useful. However it was committed too
late, and wound up being unused. It's in the way of future work now,
so retire it rather than bring it forward.
loader scripts. However, that path won't be taken after all it
seems. Remove this code before it decays into uselessness. Also remove
build dependencies on forth no longer needed.
This has never been installed. It was added to the tree disconnected
to the build in FreeBSD 5 (17 years ago) and has never been used as
far as I can tell. The desired improvements never really happened
(despite a couple minor cleanups along the way). It's relevance is
long past, so better to retire it.
MK_CTF, MK_SSP, MK_PROFILE, NO_PIC, and INTERNALLIB are always the
same, so set them in defs.mk. MAN= is common, so set it here too.
This removes a lot of boring repetition from the Makefiles that added
almost no value.
Whether we should be overwriting the loaded FDT module with the 'fixed up'
version or not was questionable when this was added, and now that overlays
are possible this is downright wrong.
Overlays can increase the size of the blob, so writing it back to the
original VA will generally write past the end of the block and start
clobbering other things in memory.
Rip it out- it was questionable to begin with, it's doing bad things now,
and it serves no purpose since the modified blob will be copied into place
rather than relying on this to reflect the changes.
Reviewed by: gonzo
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14130
akin to what Pedro Souza and Wojciech Koszek did in the lua GSoC with
interp.h, interp_simple.c and changes to interp.c and interp_forth.c,
but completely redone from scratch.
This effectively restores the spirit of r326712 (my first attempt to
bring in Pedro's and Wojciech's work) updated for new requirements
that had silently broke their original work. This change also differs
by using fixed function names instead of function pointers to simply
things. Only one interpreter at a time may be compiled in.
Also of note: we take a mutable string, pass it in via a const char *
pointer into intrp_forth's interp_run(). We then cast away the const
to pass into ficlExec since ficl would require extensive changes to
properly const-poison. See Sections 6.5.2.5 and 6.7.3 of C11 standard
noting it's only UB if you modify a const object through a non-const
pointer, but not char [] -> const char * -> char * as here.
Move prototypes to proper section now that we don't have modified
versions of strtol and strtoul in libsa. Add prototypes for new
strtoll and strtoull. Use prototypes copied from stdlib.h instead of
the old hand-rolled ones.
(I forgot to move this file form my lua branch in r328613)
since they suffice. Create xlocale_private.h which provides the most
minimal locale implementation we can get away with. Add strtoll and
strtoull from libc.
On POWER8 with current petitpoot, the loader.kboot might be
run as little-endian application. The FreeBSD kernel is
always big-endian, so the load_elf_* routines must be aware
of proper endianness of all fields.
Submitted by: Wojciech Macek <wma@semihalf.com>
Obtained from: Semihalf
Sponsored by: IBM, QCM Technologies
Differential revision: https://reviews.freebsd.org/D12422
Example overlays seen in other places use a compatible property on root node
of an overlay to specify SOC compatibility. These don't get merged into base
FDT as they're not part of a fragment, but it's expected that consumers of
the overlay may want to check it.
If /compatible on the overlay is missing, just apply it. This is the "I know
what I'm doing" mode for those wanting to whip up a quick overlay and apply
it. An overlay intended for distribution should include /compatible so as
not to break a user's system.
If /compatible on the overlay exists, honor it and cross-check it with
/compatible on the base FDT. If /compatible on the base FDT is missing in
this case, don't apply the overlay rather than risk breaking the system.
Move the COPYOUT of overlay material to before we allocate space for
next_fdtp so that we can avoid the allocation and copy into next_fdtp if we
already know that the overlay can't apply.
This gives way to the possibility of autoloading overlays found in
/boot/overlays, since this provides a means of filtering out overlays not
applicable to the current board.
Reviewed by: gonzo
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D13969
This should have been done as part of r327350, but due to lack of foresight
it came later. In the different places we apply overlays, we duplicate the
bits that check for fdt_overlays in the environment and supplement that with
any other places we need to check for overlays to load. These "other places"
will be loader specific and are not candidates for consolidation.
Provide an fdt_load_dtb_overlays to capture the common logic, allow passing
in an additional list of overlays to be loaded. This additional list of
overlays is used in practice for ubldr to pull in any fdt_overlays passed to
it from U-Boot environment, but it can be used for any other source of
overlays.
These additional overlays supplement loader.conf(5) fdt_overlays, rather
than replace, so that we're not restricted to specifying overlays in only
one place. This is a change from previous behavior where loader.conf(5)
supplied fdt_overlays would cause us to ignore U-Boot environment, and this
seems nonsensical- user should have sufficient control over both of these
aspects, or lack of control for good reasons.
A knob could be considered in the future to ignore U-Boot supplied overlays,
but the supplemental treatment seems like a good start.
Reviewed by: imp (earlier version), gonzo (earlier version)
Differential Revision: https://reviews.freebsd.org/D13993
Specifically reading is done if ffs_sbget() and writing is done
in ffs_sbput(). These functions are exported to libufs via the
sbget() and sbput() functions which then used in the various
filesystem utilities. This work is in preparation for adding
subperblock check hashes.
No functional change intended.
Reviewed by: kib
These were found during bring-up on a new arm64 platform and in an
amd64 VM.
Submitted by: Arshan Khanifar <arshankhanifar_gmail.com>
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14036
This behavior also matches a Linux-ism by allowing fdt_overlays to specify
names of overlays without an extension, e.g. fdt-overlays="sunxi-h3-h5-emac"
If we fail to load the file given by a name in fdt_overlays, try again with
".dtbo" appended to it. This still allows overlays to lack .dtbo extension
if user prefers it and just adds a fallback cushion.
Future work could move this from a hard-coded ".dtbo" to a loader.conf(5)
configuration option.
Reviewed by: gonzo
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D13968
Right now, we'll leak memory when we display a help topic because we
don't free t, s, d that we've just used when breaking out of the loop.
NB: coverity just reported t, but s and d also leak.
CID: 1007776
Always free dev and fstyp before strduping new values to assign to
them. Free them at the end of the loop. This keeps them from leaking
for mal-formed /etc/fstab lines.
CID: 1007777, 1007778, 1007779
Sponsored by: Netflix
When building loader bits, lld fails with the following error:
"ld: error: section: .dynamic is not contiguous with other relro sections"
on both ubldr and EFI loader.
Move .dynamic up to make ld.lld happy, adjust .got as necessary for ubldr.
Tested on: OrangePi One (ld.lld, ubldr)
Tested on: Banana Pi-M3 (ld.lld, ubldr)
Tested on: qemu-armv7 (ld.lld, EFI)
Tested on: qemu-armv7 (ld.bfd, EFI)
Tested on: Raspberry Pi 2 (ld.bfd, ubldr) [manu]
Tested on: Banana Pi-M2 (ld.bfd, ubldr) [manu]
Reviewed by: andrew, emaste, imp
Differential Revision: https://reviews.freebsd.org/D13942
This matches directory structure used commonly in Linux-land, and it's
cleaner than mixing overlays into the existing module paths. Overlays are
still mixed in by specifying fdt_overlays in loader.conf(5).
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D13922
libfdt highlights since 1.4.3:
- fdt_property_placeholder added to create a property without specifying its
value at creation time
- stringlist helper functions added to libfdt
- Improved overlay support
- Various internal cleanup
Also switch stand/fdt over to using libfdt for overlay support with this
update. Our current overlay implementation works only for limited use cases
with overlays generated only by some specific versions of our dtc(1). Swap
it out for the libfdt implementation, which supports any properly generated
overlay being applied to a properly generated base.
This will be followed up fairly soon with an update to dtc(1) in tree to
properly generate overlays.
MFC note: the <stdlib.h> include this update introduces in libfdt_env.h is
apparently not necessary in the context we use this in. It's not immediately
clear to me the motivation for it being introduced, but it came in with
overlay support. I've left it in for the sake of accuracy and because it's
not harmful here on HEAD, but MFC'ing this to stable/11 will require
wrapping the #include in an `#ifndef _STANDALONE` block or else it will
cause build failures.
Tested on: Banana Pi-M3 (ARMv7)
Tested on: Pine64 (aarch64)
Tested on: PowerPC [nwhitehorn]
Reviewed by: manu, nwhitehorn
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D13893
ELF object files can contain program sections which are not supposed
to be loaded into memory (e.g. .comment). Normally the static linker
uses these flags to decide which sections are allocated to loadable
program segments in ELF binaries and shared objects (including kernels
on all architectures and kernel modules on architectures other than
amd64).
Mapping ELF object files (such as amd64 kernel modules) into memory
directly is a bit of a grey area. ELF object files are intended to be
used as inputs to the static linker. As a result, there is not a
standardized definition for what the memory layout of an ELF object
should be (none of the section headers have valid virtual memory
addresses for example).
The kernel and loader were not checking the SHF_ALLOC flag but loading
any program sections with certain types such as SHT_PROGBITS. As a
result, the kernel and loader would load into RAM some sections that
weren't marked with SHF_ALLOC such as .comment that are not loaded
into RAM for kernel modules on other architectures (which are
implemented as ELF shared objects). Aside from possibly requiring
slightly more RAM to hold a kernel module this does not affect runtime
correctness as the kernel relocates symbols based on the layout it
uses.
Debuggers such as gdb and lldb do not extract symbol tables from a
running process or kernel. Instead, they replicate the memory layout
of ELF executables and shared objects and use that to construct their
own symbol tables. For executables and shared objects this works
fine. For ELF objects the current logic in kgdb (and probably lldb
based on a simple reading) assumes that only sections with SHF_ALLOC
are memory resident when constructing a memory layout. If the
debugger constructs a different memory layout than the kernel, then it
will compute different addresses for symbols causing symbols in the
debugger to appear to have the wrong values (though the kernel itself
is working fine). The current port of mdb does not check SHF_ALLOC as
it replicates the kernel's logic in its existing kernel support.
The bfd linker sorts the sections in ELF object files such that all of
the allocated sections (sections with SHF_ALLOCATED) are placed first
followed by unallocated sections. As a result, when kgdb composed a
memory layout using only the allocated sections, this layout happened
to match the layout used by the kernel and loader. The lld linker
does not sort the sections in ELF object files and mixed allocated and
unallocated sections. This resulted in kgdb composing a different
memory layout than the kernel and loader.
We could either patch kgdb (and possibly in the future lldb) to use
custom handling when generating memory layouts for kernel modules that
are ELF objects, or we could change the kernel and loader to check
SHF_ALLOCATED. I chose the latter as I feel we shouldn't be loading
things into RAM that the module won't use. This should mostly be a
NOP when linking with bfd but will allow the existing kgdb to work
with amd64 kernel modules linked with lld.
Note that we only require SHF_ALLOC for "program" sections for types
like SHT_PROGBITS and SHT_NOBITS. Other section types such as symbol
tables, string tables, and relocations must also be loaded and are not
marked with SHF_ALLOC.
Reported by: np
Reviewed by: kib, emaste
MFC after: 1 month
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D13926
is NULL. That's more correct and doesn't depend on the error behavior
of utf8_to_ucs2. In practice, we'll never see this though since we
pass utf8_to_ucs2 a well formed string.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13918
and utf8_to_ucs2, be sure to NULL out the return pointer too, rather
than return a pointer to free memory.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13917
utf8_to_ucs2 in boot1.efi. We need to initialise the ucs2 output string
so it will allocate space, and use the return value to determine if the
call was successful.
Reviewed by: imp
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D13915
If fdt_overlay_apply fails at some stage to apply the overlay to the base,
both the base and overlay may be in an inconsistent state (some fixups
applied, some phandles adjusted, some symbols merged). These can be bad for
a number of reasons, to include user frustration if some fixups applied and
not others. Fail a little safer by making a clean copy of the base FDT for
every overlay that we can simply discard if things go awry.
This also allows us the luxury of simply discarding overlays if we hit some
kind of memory limit or if they're malformed and extremely large for some
reason. We'll now leave a nice error message indicating that some overlays
could not be applied due to size restrictions and we apply what we can.
I note that our overlay implementation has some flaws that might still leave
your system in an unbootable state even if an overlay applies correctly;
please exercise caution in using overlays until we can swap it out for
libfdt's implementation.
Tested on: BananaPi-M3 (armv7)
Tested on: Pine64 (aarch64)
Differential Revision: https://reviews.freebsd.org/D13709
Use simple "foo" rather than "${.CURDIR}/foo" to include Makefile.fat
since the former works when including this Makefile from else
where. Also, use full path from ${BOOTSRC} to the FAT templates for
similar reasons. It doesn't change anything in base FreeBSD, but
allows us to have a custom boot1.efi more easily (though that will be
short-lived for us, it may also be helpful for others).
Sponsored by: Netflix
ifuncs can be only called in the (early boot) kernel environment, so
postpone resolving until early stage of the kernel boot. This commit
is performed in advance to make loaders on most machines updated
before ifuncs appear in the kernels.
Reviewed by: emaste, jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D13838
In the freestanding boot compile environment, standard headers are not
available. Curiously, only building with clang exposed this as compiles
with external GCC still succeeded.
Sponsored by: DARPA / AFRL
The __dmadat variable is a statically allocated I/O buffer. The type is
declared in the ufsread.c source file and clang warns if a variable is
defined before it's type is declared.
Sponsored by: DARPA / AFRL
The beri boot loaders depend on symbols defined in linker scripts or
assembly files. The boot loaders do not care about the type of these
symbols but just want to extract a pointer to them. Older versions of
GCC permitted external symbols to be declared of type 'void' and then
'&foo' generated a void pointer to the memory at the symbol's address.
However, void objects are not valid C and newer versions of GCC error if
these are used. Instead, declare these symbols as being bytes (or
an array of bytes in the cheri_sdcard_vaddr case).
Sponsored by: DARPA / AFRL
Prior to r325114, bsd.init.mk was included after assignments to CFLAGS and
LDFLAGS in these Makefiles. After r325114, bare assignments (= rather than
+=) lost system-assigned default values that are needed when compiling with
an external toolchain. CFLAGS in both Makefiles already uses +=. This
commit changes LDFLAGS to use +=. While here, depend on the LDFLAGS update
in the parent Makefile.inc to set -nostdlib.
Sponsored by: DARPA / AFRL
bool indicating whether the input value represents a valid BCD byte.
The existing bcd2bin() routine will KASSERT if asked to convert a bad value,
but sometimes the kernel has to handle BCD data from untrusted sources, so
this will provide a mechanism to validate data before attempting conversion.
This would be have easier/cleaner if the bcd2bin_data[] array contained an
out-of-range value (such as 0xff) in the infill locations that aren't valid,
but it's a global symbol that might be referenced by out-of-tree code
relying on the current scheme, so I'm leaving that alone.
libfdt will assume a writable fdt overlay blob has been passed in, so make
ours compatible to allow easier review when we try to drop libfdt into
place. overlay from the calling context is writable, making it safe to
simply rip out everything related to copying the overlay blob in
fdt_overlay_apply.
I note here that we still have problems: fdt_overlay_apply, both our version
and libfdt's, may fail and have already clobbered the base fdt to some
extent. Future work will make sure we don't apply a potentially bogus fdt,
instead discarding the base fdt if we had an error.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D13695
strnlen is not used at the moment, but it will be when libfdt gets updated.
Prepare for the not-so-distant future by pulling in strnlen.
Noticed because: segfault in ld.bfd due to strnlen missing
libfdt.h should be included before fdt.h, as hinted at by all of libfdt/;
standard include order being libfdt.h, libfdt_env.h, fdt.h.
The current include order also causes problems when libfdt gets updated, as
fdt.h requires some definitions from libfdt.h.
Differential Revision: https://reviews.freebsd.org/D13688
loader, but not compile as loader (it's building a library), so we
can't just include loader.mk for the defines. Move LOADER_DISK_SUPPORT
back to defs.mk for the moment.
Sponsored by: Netflix
Overlays were previously not applied when U-Boot provides FDT or EFI
provides FDT, only when we load FDT from /boot/dtb given name from U-Boot.
Make all three paths lead to loading fdt_overlays and applying them, so that
fdt_overlays can be expected to Just Work.
Reviewed by: gonzo, imp, manu
Differential Revision: https://reviews.freebsd.org/D13664
In the case of a simple dtbo where fragment uses target-path and the overlay
contains no references, /__fixups__ will not be included by either our dtc
or dtc from ports, but the file still has valid fragments to be applied.
Additional testing found that /__symbols__ might also be omitted if it's
empty, which is not necessarily an error.
Reviewed by: gonzo, imp
Differential Revision: https://reviews.freebsd.org/D13663
fdt_load_dtb_overlays was written to unload previous overlay when a new
valid one is come across. fdt_apply_overlays further down is written to
iterate over all .dtbo's currently loaded and apply them one-by-one. Correct
fdt_load_dtb_overlays to stop dropping valid overlays that were previously
loaded and match expectations.
Reviewed by: gonzo, imp
Differential Revision: https://reviews.freebsd.org/D13659
This patch allows to scan all display modes in boot1 as loader does.
Before system tried to select optimal display mode by sequential scan of
modes and if error then stop scanning. This way is not good, because
if mode N is not present, mode N+1 may exist.
In loader we use conout->Mode->MaxMode to identify maximum number of modes.
This commit is to use same way in boot1 as in loader.
Reported by: Andrey Pustovetov <andrey.pustovetov@gmail.com>
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D13541
removing this argument, and expanding when rc is NULL. This
effectively completes the back out of custom scripts for tftp booted
loaders from r269153 that was started in r292344 with the new path
tricks that obsoleted it.
Submitted by: Netflix
HELP_FILES is a loader only thing, so move it to loader.mk. Only
generate the help file if HELP_FILES is defined. Adjust Makefiles to
new convention. Fix a few cases where ${.CURDIR}/ was missing
resulting in missing bits from the help files.
Sponsored by: Netflix
weren't needed, and their existance interfered with things in subtle
ways. One of these subtle ways was that malloc could be different
based on what files were included when (even within the same .c file,
it turns out). Move to a single malloc implementation as well by
adding the calls to setheap() to gptboot.c and zfsboot.c. Once upon a
time, these boot loaders strove to not use libstand. However, with the
proliferation of features, that striving is too hard for too little
gain and lead to stupid mistakes.
This fixes the GELI-enabled (but not even using) boot environment. The
geli routines were calling libstand malloc but zfsboot.c and gptboot.c
were using the mini libstand malloc, so this failed when we tried to
probe for GELI partitions. Subtle changes in build order when moving
to self-contained stand build in r326593 toggled what it used from one
type to another due to odd nesting of the zfs implementation code that
differed subtly between zfsloader and zfsboot.
Sponsored by: Netflix
This was an experiment that landed in the wrong branch and was pushed
accidentally. It's best if it is ignored because the difference was
due to vers.o being different, not float.o... And it was confirmed to
not fix anything...
Pointy Hat to: imp
temporary workaround. This fixes zfs booting generally, but breaks all
GELI booting by default. Add note to UPDATING to this effect. When the
GELI issues are resolved, this will be reverted.
We need to include ficl.h after the standard includes, rather than
before them. It changes the generated code in ways that haven't been
completely analyized. This restores the old code generation (as
verified by md5 changing back for zfsloader).
This should restore GPT + ZFS and GPT + ZFS + GELI booting that was
broken in r326585 (or would have been if r326584 hadn't broken the
build).
Sponsored by: Netflix
Use _STANDALONE for guard expression in efichar.[ch] and add efi_char typedef.
clean up boot1.c, and replace for loop in efipart.c with ucs2len().
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D13488
Don't print when we can't find a file. Copy it instead to the error
buffer. Higher level routines determine if it's appropriate to print
the error message.
Also, remove dead code (labeled bogusly lost functionality) since we
never used that functionality. Remove unused arg from interact() too.
Sponsored by: Netflix
saved register, but in arm EABI it may be either callee-saved or dedicated
to some special purpose (such as a TLS pointer). It appears clang does not
treat it as a callee-saved register (instead using it as another work
register, similar to r12).
Another important side effect of these changes is that saving an extra
register in the push/pop statements keeps the stack aligned to an 8-byte
boundary during the self_reloc() call, as it always should have been.
As stated in the PR...
Essentially the important caller-saved registers are pushed (r0, r1, r9, lr)
before the relocation call, and popped after. Then r8/r9 are saved as usual
for the syscall trampoline, and lr is stored in r8 (now free) as a
callee-saved value before calling into `main`.
The call to `main` can no longer be a tail call because we must restore r9
especially after main returns (although since we have used r8 to hold lr we
must also restore this).
PR: 224008
Create an interp class. Use it to separate out the different types of
interpreters: forth and simple with function pointers rather than
via #ifdefs.
Obtained from: lua boot loader project
(via https://bsdimp@github.com/bsdimp/freebsd.git lua-bootloader)
Sponsored by: Netflix
the stand environment that's safe to use (and insulated from whatever
build env you might normally have), stop hacking the bzlib and zlib
sources with sed. There's no longer any need.
Sponsored by: Netflix
Building with the standard system headers isn't a perfect match to the
stand environment. Instead, copy over the files we know are safe to
use and constrain what else is used. We use -nostdinc to achieve this.
This also fixes issues with building 32-bit libraries on amd64
sometimes pulling in the wrong cpufunc.h giving an error now that we
stop on errors. It will also enable an easier transition to lua boot.
Sponsored by: Netflix
latter aren't used. Prefer sys/link_elf.h to link.h so we're only
dependent on the kernel tree. The default installation of link.h just
includes this file, and any benefit from that is outweighed by the
hassle it causes. This reduces the footprint of files needed from the
system includes (or sysroot in buildworld).
Sponsored by: Netflix
Previous to the switch from sys/boot to stand/ zfsboot (used for MBR) did
not support GELI. Now that it is compiled with GELI, it is running out of
space.
zfsldr (which loads zfsboot) was modified to load 256kb in r304321
it's going to be removed soon anyway once the final lingering issues
with kboot are resolved. Go ahead and disconnect it from the build a
little early.
Sponsored by: Netflix
OK'd by: nathanw@
