Hi Anis, On 9/5/25 2:16 AM, anis chali wrote: > Hi, > >> Thinking about it, this doesn't really fit into the existing model. >> We have CONFIG_EFI_PAYLOAD, which when enabled gives _all_ images >> an EFI stub. >> >> I think it's better to just give CPU_V7 and CPU_V8 prompts. > Don't understand.
See https://lore.kernel.org/all/[email protected]/ This way you can just enable CPU_V8 and keep all SoCs disabled to build barebox for UEFI. >> Then they can be enabled for the barebones EFI-only use case alongside >> CONFIG_EFI_PAYLOAD. CONFIG_EFI_PAYLOAD should have its depends on >> COMPILE_TEST removed as last patch in your series then I think (or >> before last if you add a dedicated efi_defconfig). > So we keep a specific kconfig variant that will be selected using > efi_defconfig > file and not merging the multi_v8_defconfig with the efi_payload config in > the makefile > Is it what you mean? While multi_v8_efi_defconfig is nice to have, I see the utility now in having an efi_v8_defconfig (or efi_{payload,app}_v8_defconfig?) that disables all other boards, because they aren't needed. The new efi_*_v8_defconfig would just enable CPU_V8 and CONFIG_EFI_PAYLOAD and this way we don't need an extra machine. > will this defconfig serve only arm64 or should we think about it more > globally to > be used with what ever cpu or arch and in that case maybe we can just keep > the same > startegy than merguing between configs and this time we will take the > efi_payload config > and add the selected arch from the environment variable ARCH??? Let's just add a single efi_v8_defconfig for now and think about merging later. > especially the efi payload is not more than an application compiled on a > given architecture and > and is loadable by efi, so it should never change the hardware state and stay > hardware agnostic. Agreed. ISA should be the only dependency in the optimal case. >> + bool "EFI on ARM64" >>> >> >> Generally, we should call it EFI payload to differentiate from >> EFI loader (firmware) > Ack, will change it for "Arm 64 EFI Payload", but maybe see think it with > what I just said > before. > >> Symbol doesn't exist on ARM. >> >> + select HAVE_EFI_PAYLOAD >>> >> >> Already selected by CPU_64 > Ack > >> + select EFI_PAYLOAD >>> + select BOOTM_FITIMAGE >>> >> >> select means it can't be deselected, which is not needed here. > Ok, it makes sense, bootm fit is not required. > >> >> + select CLOCKSOURCE_EFI >>> + select DRIVER_VIDEO_EFI_GOP >>> >> >> It's reasonable to disable GOP if the device is headless anyway. >> You can give the DRIVER_VIDEO_EFI_GOP a default y though if you like, >> because many (most?) users will likely want to use GOP. > Ok, will make it as just default but not select with kconfig. > >> Point is moot with above suggested change though. >> >> + depends on 64BIT >>> + default y if ARCH_MULTIARCH >>> >> > Ack. > > Maybe if you have a couple of minutes to just summarize what need to be done > and have some plan for efi payload stuff, it is very apperciated the time you > spend supporting, I didn't know anything about barebox a few weeks ago, but I > noticed that it is really a very good quality code, maintainable, it will an > excellent replacement for all the efi payloads, it could also be an excellent > choice > if we need to build the same software stack on different and mixed closed > architectures > products where the efi is the only supported bootloader. The current EFI_PAYLOAD support for ARM is similar to the kernel's, it modifies the normal image(s) to add an EFI stub and images can then be booted in two different ways: Executing the first instruction or by parsing the PE header and executing it from within an EFI environment. Because CONFIG_EFI_PAYLOAD is invasive in this manner and affects all images generated, I don't want it selected by a separate subarchitecture, because it doesn't reflect its global effect. That's why I prefer having CPU_V8 and CPU_V7 symbols with a prompt and then CONFIG_EFI_PAYLOAD will just EFI stub all images. Now with EFI_PAYLOAD enabled, we are missing out on a way to boot an EFI-stubbed kernel from within barebox. Currently, we only support the legacy handover protocol, which is not standard, x86-only and can be disabled in newer kernels. barebox needs a spec-conforming boot method that can be used on ARM and that can also be used on x86 later. FIT image support is good to have, but it's a separate manner from being able to just boot an EFI stubbed kernel with a normal bootm -r /boot/initrd.gz -o /efi.dtb /boot/Image.gz With that in place, I think we should have everything for barebox to be a viable EFI bootloader on ARM as it's on x86. Cheers, Ahmad > > Cheers, > > Anis C. > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
