[PATCH v2 3/3] efi: Avoid using dm_scan_other()

Heinrich Schuchardt xypron.glpk at gmx.de
Sat Dec 16 23:30:32 CET 2023



Am 16. Dezember 2023 23:14:20 MEZ schrieb Tom Rini <trini at konsulko.com>:
>On Sat, Dec 16, 2023 at 09:57:41PM +0100, Heinrich Schuchardt wrote:
>> On 12/16/23 21:46, Simon Glass wrote:
>> > Hi,
>> > 
>> > On Tue, 21 Nov 2023 at 06:21, Tom Rini <trini at konsulko.com> wrote:
>> > > 
>> > > On Tue, Nov 21, 2023 at 01:18:09PM +0100, Heinrich Schuchardt wrote:
>> > > > On 11/12/23 21:55, Simon Glass wrote:
>> > > > > This function is defined by bootstd so using it precludes using that
>> > > > > feature. Use the board_early_init_r() feature instead.
>> > > > > 
>> > > > > This requires moving quite a lot of code into the board directory, butt
>> > > > > this is the normal place for code called by board_early_init_r()
>> > > > > 
>> > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
>> > > > > ---
>> > > > > 
>> > > > > Changes in v2:
>> > > > > - Drop duplicate acpi_xsdt patch
>> > > > > - Put the board_early_init_r code into board/
>> > > > > 
>> > > > >    board/efi/efi-x86_app/Makefile  |   5 +
>> > > > >    board/efi/efi-x86_app/efi_app.c | 205 ++++++++++++++++++++++++++++++++
>> > > > 
>> > > > Our target should be to enable building the EFI app on all architectures.
>> > > > 
>> > > > Only x86 specific code should be added to board/efi/efi-x86_app/efi_app.c.
>> > > 
>> > > A later enhancement to make U-Boot as an EFI app more generic would be
>> > > good, but outside the scope of this patch which is moving generic code
>> > > out from "lib" and in to "board".
>> 
>> I cannot see that this patch is moving any code our of lib/.
>> 
>> But why should we move generic code into board?
>> 
>> > 
>> > This patch was marked as old /archived in patchwork so has been
>> > forgotten. I have marked it new and non-archived in the hope that it
>> > can be applied to -master soon.
>> 
>> There is nothing x86 specific about the code. Generic code should be in
>> lib/. Please, provide a new version of the patch.
>
>It's not generic EFI code, it's generic "U-Boot as EFI application" code
>and so the whole "board" needs a bit of a clean and re-work as we all
>agree that there shouldn't be anything architecture specific about it,
>only building the binary for the correct architecture. However, we just
>aren't well structured to support that right now. Where on the list of
>priorities does that have to fall rather than just allowing for
>functionality to be tested / used? There's not yet IIRC efi-arm64_app
>but what we have today (and would have had with Simon's patch) should
>have just built and worked.
>

We have /lib/efi/ for that code.

Regards

Heinrich


More information about the U-Boot mailing list