[PATCH v7 6/7] test: efi: boot: Set up an image suitable for EFI testing

[Simon Glass]

Hi Tom,

On Tue, 22 Oct 2024 at 19:54, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Oct 22, 2024 at 07:00:35PM +0200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 22 Oct 2024 at 16:02, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Oct 22, 2024 at 02:15:46PM +0200, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 21 Oct 2024 at 19:32, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Mon, Oct 21, 2024 at 08:31:10AM +0200, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sat, 19 Oct 2024 at 11:51, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Sat, Oct 19, 2024 at 09:24:33AM -0600, Simon Glass wrote:
> > > > > > >
> > > > > > > > Create a new disk for use with tests, which contains the new 'testapp'
> > > > > > > > EFI app specifically intended for testing the EFI loader.
> > > > > > > >
> > > > > > > > Attach it to the USB device, since most testing is currently done with
> > > > > > > > mmc.
> > > > > > > >
> > > > > > > > Initially this image will be used to test the EFI bootmeth.
> > > > > > > >
> > > > > > > > Fix a stale comment in prep_mmc_bootdev() while we are here.
> > > > > > > >
> > > > > > > > For now this uses sudo and a compressed fallback file, like all the
> > > > > > > > other bootstd tests. Once this series is in, the patch which moves
> > > > > > > > this to use user-space tools will be cleaned up and re-submitted.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > > > >
> > > > > > > > ---
> > > > > > > > Here is the patch to avoid sudo and CI fallback:
> > > > > > > >
> > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/patch/
> > > > > > > > 20240802093322.15240-1-richard at nod.at/
> > > > > > > >
> > > > > > > > (no changes since v1)
> > > > > > > >
> > > > > > > >  arch/sandbox/dts/test.dts           |   2 +-
> > > > > > > >  test/boot/bootdev.c                 |  18 +++++++++-
> > > > > > > >  test/boot/bootflow.c                |   2 +-
> > > > > > > >  test/py/tests/bootstd/flash1.img.xz | Bin 0 -> 5016 bytes
> > > > > > >
> > > > > > > This I think best illustrates the problem with "BOOTSBOX.EFI". This
> > > > > > > image will work for CI up until I can figure out how to get access to
> > > > > > > free arm64 servers to run some tests on and then it will fail.
> > > > > >
> > > > > > I don't believe so. Why do you think that?
> > > > >
> > > > > Because it includes the BOOTSBOX.EFI x86 binary file, and executes it?
> > > > > Or did I miss where we update the contents to include that file as we
> > > > > just built it (and so why have it included?) ?
> > > >
> > > > It works fine on x86 and I'm sure it will work fine on ARM as well.
> > > > The file is built with the host compiler, just as U-Boot itself is.
> > >
> > > Erm, are you saying the BOOT/EFI/BOOTSBOX.EFI file that's in
> > > test/py/tests/bootstd/flash1.img.xz doesn't need to exist and the test
> > > replaces that, as it goes?
> >
> > No, I'm saying that sandbox uses that file, no matter the host
> > architecture, and I don't need to create different versions of
> > flash1.im.xz for each host architecture.
> >
> > I discussed this with Heinrich and he seems happy enough with the -N
> > flag for his use case. I know how to replicate his use case and am
> > going to try it soon.
>
> Yes, I'm just confused as to how the same BOOTSBOX.EFI binary file can
> be executed as both x86-64 and aarch64. Because:
> $ xz -k -d test/py/tests/bootstd/flash1.img.xz
> $ sudo losetup -fP  test/py/tests/bootstd/flash1.img
> $ sudo mount -o ro /dev/loop18p1 /mnt
> $ file /mnt/EFI/BOOT/BOOTSBOX.EFI
> /mnt/EFI/BOOT/BOOTSBOX.EFI: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows, 5 sections
>
> Seems unlikely to work on an aarch64 host. Which is why I asked if the
> test actually replaced the contents of the file.

Well, yes, for now the .xz is an x86_64 image, but I expect to be able
to get rid of that fallback once my EFI test lands, so it should work
fine on ARM.

Regards,
Simon