Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

From: Scott Branden
Date: Fri Aug 31 2018 - 17:28:37 EST

Hi Olof/Ard,

On 18-08-30 09:23 AM, Ard Biesheuvel wrote:
On 30 August 2018 at 17:06, Olof Johansson <olof@xxxxxxxxx> wrote:
On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel
<ard.biesheuvel@xxxxxxxxxx> wrote:
On 29 August 2018 at 20:59, Scott Branden <scott.branden@xxxxxxxxxxxx> wrote:
Hi Olof,

On 18-08-29 11:44 AM, Olof Johansson wrote:

On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden
<scott.branden@xxxxxxxxxxxx> wrote:
Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
parameter to function with efi loader.

Required to boot on existing bootloaders that do not support devicetree
provided by the platform or by the bootloader.

Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for the
DTB loader")
Signed-off-by: Scott Branden <scott.branden@xxxxxxxxxxxx>
Why did Ard create an option for this if it's just going be turned on
in default configs? Doesn't make sense to me.

It would help to know what firmware still is crippled and how common
it is, since it's been a few years that this has been a requirement by
Broadcom NS2 and Stingray in current development and production need this
option in the kernel enabled in order to boot.
And these production systems run mainline kernels in a defconfig configuration?

The simply reality is that the DTB loader has been deprecated for a
good reason: it was only ever intended as a development hack anyway,
and if we need to treat the EFI stub provided DTB as a first class
citizen, there are things we need to fix to make things works as
expected. For instance, GRUB will put a property in the /chosen node
for the initramfs which will get dropped if you boot with dtb=.

Don't be surprised if some future enhancements of the EFI stub code
depend on !EFI_ARMSTUB_DTB_LOADER. On UEFI systems, DTBs [or ACPI
tables] are used by the firmware to describe itself and the underlying
platform to the OS, and the practice of booting with DTB file images
(taken from the kernel build as well) conflicts with that view. Note
that GRUB still permits you to load DTBs from files (and supports more
sources than just the file system the kernel Image was loaded from).

Maybe a WARN() splat would be more useful as a phasing-out method than
removing functionality for them that needs to be reinstated through
changing the config?

We don't have any of that in the stub, and inventing new ways to pass
such information between the stub and the kernel proper seems like a
cart-before-horse kind of thing to me. The EFI stub diagnostic
messages you get on the serial console are not recorded in the kernel
log buffer, so they only appear if you actually look at the serial

Once the stub and the boot method is there, it's hard to undo as we
can see here. Being loud and warn might be more useful, and set a
timeline for hard removal (12 months?).

The dtb= handling is still there, it is just not enabled by default.
We can keep it around if people are still using it. But as I pointed
out, we may decide to make new functionality available only if it is
disabled, and at that point, we'll have to choose between one or the
other in defconfig, which is annoying.
dtb= handling does need to be enabled in the only defconfig
upstreamed though. ARM64 maintainers have mandated a single
defconfig upstreamed up this point. If another incompatible
efistub is needed in the future then 2 kernel images would need
to be built to support booting on all platforms.

Scott; an alternative for you is to do a boot wrapper that bundles a
DT and kernel, and boot that instead of the kernel image (outside of
the kernel tree). Some 32-bit platforms from Marvell use that. That
way the kernel will just see it as a normally passed in DT.
The EFI stub is the boot wrapper? Everything works perfectly today
with the upstream kernel (with the defconfig fix of the efistub regression).
We support a single kernel image booting with multiple DTs
(selected in UEFI and passed in via dtb= on command line).

Or use GRUB. It comes wired up in all the distros, and let's you load
a DT binary from anywhere you can imagine, as opposed to the EFI stub
which can only load it if it happens to reside in the same file system
(or even directory - I can't remember) as the kernel image. Note that
the same reservations apply to doing that - the firmware is no longer
able to describe itself to the OS via the DT, which is really the only
conduit it has available on an arm64 system..
Ard, GRUB is not a requirement to boot the kernel. But, it sounds like
using GRUB may be a solution to your problem? You could use GRUB
and leave the efistub alone then (or at least leave dtb= in the upstream