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
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
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
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
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
