]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
MFC r338219, r338250: FDT in Loader fixes
authorkevans <kevans@FreeBSD.org>
Wed, 3 Oct 2018 17:17:38 +0000 (17:17 +0000)
committerkevans <kevans@FreeBSD.org>
Wed, 3 Oct 2018 17:17:38 +0000 (17:17 +0000)
commitdb594663f4733f66bb28a4cadbb2694150dec667
tree20c1f37475fffb11bde57821a5645e3c2bd89c36
parent128e98b2c8f402f8bad0dd76cf88dc3efe545b8d
MFC r338219, r338250: FDT in Loader fixes

r338219:
fdt_fixups: relocate the /chosen node after applying fixups

As indicated by the comment, any fixups applied (which might include
overlays) can invalidate the previously located node by adding nodes or
setting/adding properties. The later fdt_setprop of fixup-applied property
would then fail because of the bad/wrong node offset.

This would have generally been harmless, but potentially caused multiple
applications of fixups and caused a little bit of bloat.

r338250:
efiloader: Setup FDT in autoload to fix overlays clobbering kenv

manu found in the noted PR that overlays seemed to be clobbering the kenv
and killing the boot. Further inspection revealed that one can `fdt ls` at
the loader prompt for a successful boot, but autoboot breaks it.

In the autoboot case, first setup of FDT is happening in the middle of
bi_load, which triggers loading of the DTBO from /boot.

This is bad, bad, bad. Files in the loader are loaded somewhere in the
middle of the address space one after another. bi_load starts building the
needed kernel bootinfo immediately after the highest-addr loaded file. File
loads in the middle of bi_load suddenly clobber bootinfo and everything goes
off the rails.

The solution to this is to use take advantage of arch_autoload to setup FDT
in efiloader compiled with LOADER_FDT_SUPPORT. This matches how it works in
ubldr land, and is how it should have worked when overlay support was added
to efiloader since fdt_setup_fdtp now has the potential to load files
(courtesy of fdt_platform_load_dtb).
stand/efi/loader/autoload.c
stand/fdt/fdt_loader_cmd.c