From: anis chali <chalianis1@gmail.com>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>, s.hauer@pengutronix.de
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 4/7] arm: efi: add a generic efi machine.
Date: Thu, 04 Sep 2025 20:16:53 -0400 [thread overview]
Message-ID: <892fde210361fd699c91fd27410a01b84c6d94c7.camel@gmail.com> (raw)
In-Reply-To: <c7d7bfa9-c165-4ad0-a4a2-76c0de24c56c@pengutronix.de>
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.
> 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?
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???
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.
>
> + 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.
Cheers,
Anis C.
next prev parent reply other threads:[~2025-09-05 2:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-31 3:55 [PATCH 1/7] drivers: video: efi-gop: fix null reference pointer chalianis1
2025-08-31 3:55 ` [PATCH 2/7] efi: video: gop: remove dependency to x86 chalianis1
2025-09-02 9:20 ` Ahmad Fatoum
2025-08-31 3:55 ` [PATCH 3/7] efi: payload: initrd: implement efi initrd media protocol chalianis1
2025-08-31 3:55 ` [PATCH 4/7] arm: efi: add a generic efi machine chalianis1
2025-09-03 7:14 ` Sascha Hauer
2025-09-04 8:20 ` Ahmad Fatoum
2025-09-05 0:16 ` anis chali [this message]
2025-08-31 3:55 ` [PATCH 5/7] lib: fdt: add lib fdt padding size chalianis1
2025-08-31 3:55 ` [PATCH 6/7] efi: payload: add support for efi stub boot and fit image chalianis1
2025-09-03 7:11 ` Sascha Hauer
[not found] ` <CAL+1fyD6Jevxx_wP00caRoXe0yRmM6uScJN8W3fkRVNVfLRj1Q@mail.gmail.com>
[not found] ` <aLksEfZ3-YiEL-xN@pengutronix.de>
[not found] ` <CAL+1fyA5FtjLfRDbF-dpxr=T6kL=hrF8pr6wJk5aR1X=5CEFUg@mail.gmail.com>
2025-09-04 6:48 ` Sascha Hauer
2025-09-04 6:55 ` Ahmad Fatoum
2025-09-04 9:03 ` Ahmad Fatoum
2025-09-04 22:44 ` anis chali
2025-08-31 3:55 ` [PATCH 7/7] efi: payload: add options for FDT force and initrd direct install chalianis1
2025-09-04 9:19 ` Ahmad Fatoum
2025-09-04 22:30 ` anis chali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=892fde210361fd699c91fd27410a01b84c6d94c7.camel@gmail.com \
--to=chalianis1@gmail.com \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox