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@
Default WARNS to 0 still, since there's still some warnings on other
architectures.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13301
These prototypes were needlessly different from the standard. Fix them
to be the same, and fix the surrounding code after the changes.
Sponsored by: Netflix
Only define the CFLAGS we need.
SSP_CFLAGS is now defined globally, no need to define it here.
Define -D_STANDALONE globally for src/stand builds.
Sponsored by: Netflix
Move kernel includes and libsa includes together at the top of defs.mk
Move all machine specific defines from Makefile.inc to their friends
in defs.mk.
Add comments and remove now useless junk after the move.
Sponsored by: Netflix
Remove the now-useless dependency on ufsread.c. In some cases, it was
on the wrong file. But in all cases, we now automatically generate
.depend files, so we don't need it explicitly.
Sponsored by: Netflix
iPXE does insert stub BLOCK IO protocol handle to rework other issues,
this handle is not usable as it does not provide actual implementation.
We can detect this situation by checking and validating the BlockSize
property, so this update does make sure we have BlockSize at least 512B
and its value is power of 2.
PR: 223969
Reported by: Jeff Pieper
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D13297
The host_open interface was a legitimate mismatch to the userboot
function, while the other pointers didn't need to be non-const.
This makes the powerpc warning free again.
Sponsored by: Netflix
magic number to the kernel in r7 rather than the (currently unused and
irrelevant) width of the metadata pointer, which I believe was intended
for a never-used approach to the 64-bit port. This enables the kernel,
in a future commit, to switch on the cookie to distinguish a real
metadata pointer from loader(8) from garbage left in r6 by some other
boot loader.
MFC after: 3 weeks
either aborts or exits, but never returns. Tag it as a non-returning
function rather than supply a bogus return(0) at the end of main.
CID: 1382885
Sponsored by: Netflix
greater than 2^31-1, then the result will be huge. This is unlikely,
as we don't support that many sections, but out of an abundace of
caution cast to size_t so the multiplication won't overflow
mysteriously when size_t is larger than 32-bits. The resulting code
may be a smidge larger, but this isn't super-space critical code.
CID: 1194216, 1194217, 1194222, 1194223, 1265018, 1265019,1265020,
1265021
Sponsored by: Netflix
Rework the block device handle check to allow more robust device
classification. This is mostly usability issue - it can be quite confusing
for user when no disks are listed with lsdev.
Add more comments about what and why is done.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D13026
riscv doesn't have -msoft-float. For the moment, just don't add
anything. There's no /boot/loader or other bootstrap contained in the
tree for riscv*. However, with real hardware coming next year, there
are plans for one, so keep building at least a minimal libsa and
ficl to prevent bitrot.
Sponsored by: Netflix
HAVE_GPT isn't currently a thing, but HAVE_GELI is. Replace the former
with the latter and remove util.o from the build list (it's picked up
from libsa/libsa32, and that's OK).
Sponsored by: Netflix
simd / no float stuff is centeralized here. Also centralise
-ffreestanding since it is specified everywhere.
This, along with a change to share/mk/bsd.cpu.mk to include -mno-avx2
in CFLAGS_NO_SIMD should fix building for newer machines (eg with
CPUTYPE=haswell) where clang was generating avx2 instructions.
Sponsored by: Netflix
