From mboxrd@z Thu Jan 1 00:00:00 1970 From: scott.branden@broadcom.com (Scott Branden) Date: Fri, 31 Aug 2018 14:28:21 -0700 Subject: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER In-Reply-To: References: <1535563287-24803-1-git-send-email-scott.branden@broadcom.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Olof/Ard, On 18-08-30 09:23 AM, Ard Biesheuvel wrote: > On 30 August 2018 at 17:06, Olof Johansson wrote: >> On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel >> wrote: >>> On 29 August 2018 at 20:59, Scott Branden 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 >>>>> 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 >>>>> 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