Hi Heinrich, On Mon, Dec 18, 2023 at 3:02 PM Simon Glass <s...@chromium.org> wrote: > > Hi Heinrich, > > On Sat, 16 Dec 2023 at 14:02, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > > On 12/16/23 21:46, Simon Glass wrote: > > > Hi, > > > > > > On Tue, 21 Nov 2023 at 06:21, Tom Rini <tr...@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 <s...@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? > > It isn't really generic > > > > > > > > > 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. > > > > > > > > I believe that having the EFI app support bootstd could be a useful > > > addition. > > > > That was not disputed.
OK, I see now that your objection was putting it into board/ so I sent a new patch for that. It is very strange to have board_early_init_r() calling code in lib though. We should think of a better way. Regards, SImon