mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: anis chali <chalianis1@gmail.com>, s.hauer@pengutronix.de
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 7/7] efi: payload: add options for FDT force and initrd direct install
Date: Fri, 5 Sep 2025 21:18:56 +0200	[thread overview]
Message-ID: <20815bf1-dd84-4e96-915b-ddbbe5163ab7@pengutronix.de> (raw)
In-Reply-To: <2d921c4127fd496c668ab5ef1a6ee874352ef25d.camel@gmail.com>

Hi,

On 9/5/25 12:30 AM, anis chali wrote:
> 
> Hello Ahmad,
> 
>>> ---
>>>  efi/Kconfig | 17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>
>> diff --git a/efi/Kconfig b/efi/Kconfig
>>> index 84f670fd23d3..c3811574920d 100644
>>> --- a/efi/Kconfig
>>> +++ b/efi/Kconfig
>>> @@ -50,4 +50,21 @@ config EFI_PAYLOAD_DEFAULT_PATH
>>>  
>>>  endif
>>>  
>>> +config EFI_FDT_FORCE
>>> +	bool "Force EFI provided FDT"
>>> +	default n
>>>
>>
>> n is the default
>>
>> +	help
>>> +	  with this options we keep the fdt passed by EFI in the
>>> +	  system configuration table, EFI has to suppot FDT otherwise
>>> +	  an empty fdt will be generated when linux boots by efi.
>>>
>>
>> These things should be runtime configurable and not in Kconfig.
>> Why can't you take a user-supplied FDT if there is one and otherwise
>> fall back to of_get_fixed_tree_for_boot() as fallback?
> 
> The reason why I ignore a user supplied fdt is the secure boot, in that case
> I only accept a signed fit image fdt or keep the efi supplied fdt which is
> already in the configuration tables so we can trust it, it is probably signed
> and verified by efi.

There's CONFIG_BOOTM_FORCE_SIGNED_IMAGES that should be used to disallow
booting unsigned images. If that option is disabled, we should give the
user the runtime choice to select which initrd and which device tree to use.

> concerning the of_get_fixed_tree_for_boot, I think we can not
> use it at least for now because, maybe I'm wrong but we didn't implement any code
> to tell barebox to use efi.dtb, we only implemented code to extract the fdt from
> configuration tables and write to /efi.dtb.

Ah, that's correct of course. Maybe we should just register the EFI dtb
as the barebox device tree... We will need to avoid things like
detecting the memory banks, but apart from that it would be useful to
e.g. probe drivers that are not exposed by the EFI firmware.

Anyways, even without that, of_get_fixed_tree_for_boot() should still be
used, so the user can specify a device tree.

>> +config EFI_INITRD_INSTALL
>>> +	bool "Install the initramfs by barebox"
>>> +	default n
>>> +	help
>>> +	  with this option barebox will install the initrd to the
>>> +	  system configuration table, same as what kernel do after
>>> +	  calling read file2 boot services, in this case the initrd
>>> +	  will be read directly by the kernel as an initramfs.
>>>
>>
>> Same thing, why can't we check for data->initrd and use that?
> to answer your question, the same reason as for fdt, in case of secure boot
> we ignore user supplied initrd. I think booti or bootm do the same thing, in
> secure boot mode they ignore overrides.

Maybe I am missing the big picture here, please apply the review
feedback so far and send a v2, then we can look into this again.

> concerning the EFI_INITRD_INSTALL, it is an option to early install the initrd 
> in barebox, instead of exposing a boot service protocol to linux, then linux calls back
> to barebox to get the initrd data and after that installing it to the system configuration
> data, I added this code in the begining to debug and after that I implemented as what did by grub2, u-boot...etc.

I am not familiar with the EFI protocols. I will read up on it and
compare for v2.

Thanks for your patches!
Ahmad

> 
> Thank you for your support, 
> 
> 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 |




      reply	other threads:[~2025-09-06  0:13 UTC|newest]

Thread overview: 22+ 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
2025-09-05 19:04       ` Ahmad Fatoum
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-09-05 19:10       ` Ahmad Fatoum
2025-09-05 19:24   ` Ahmad Fatoum
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
2025-09-05 19:18       ` Ahmad Fatoum [this message]

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=20815bf1-dd84-4e96-915b-ddbbe5163ab7@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=chalianis1@gmail.com \
    --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