Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Scott Branden]

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:
> > > > > Hi,
> > > > >
> > > > > 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
> > > > > now.
> > > > 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).
> > Ard,
> >
> > 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
> output.
>
> > 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
defconfg).

Regards,
ÂScott