Hi Tom,
On Wed, Oct 23, 2024, 20:41 Tom Rini trini@konsulko.com wrote:
On Wed, Oct 23, 2024 at 05:39:07AM +0200, Simon Glass wrote:
Hi Tom,
On Tue, 22 Oct 2024 at 19:54, Tom Rini trini@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@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@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@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@chromium.org > > > > > > > > --- > > > > Here is the patch to avoid sudo and CI fallback: > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/patch/ > > > > 20240802093322.15240-1-richard@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.
So lets just re-work things to get this right from the start then please.
My understanding was that I offered to tidy up and send [1] after this series lands?
Regards, Simon