[PATCH 4/7] arm: efi: add a generic efi machine.

[Ahmad Fatoum]

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/20250904081626.93182-1-a.fatoum@pengutronix.de/

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 |