On Sun, Oct 27, 2024 at 06:16:25PM +0100, Simon Glass wrote: > Hi Tom, > > On Thu, 24 Oct 2024 at 19:37, Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Oct 24, 2024 at 06:39:00PM +0200, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, Oct 23, 2024, 20:41 Tom Rini <tr...@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 <tr...@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 <tr...@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 <tr...@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 > > > > > > > > > > > <tr...@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 <s...@chromium.org> > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > Here is the patch to avoid sudo and CI fallback: > > > > > > > > > > > > > > > > > > > > > > > > > > [1] https://patchwork.ozlabs.org/project/uboot/patch/ > > > > > > > > > > > > > 20240802093322.15240-1-rich...@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? > > > > Oh, so replacing the file is blocked on not having sudo in use on these > > tests. That wasn't clear, sorry. > > OK, good, thanks. It's just CI that has this problem, since sudo doesn't work.
To be clear, the push for no-sudo is because of developers who (understandably!) don't want sudo running random things on their machine in order to run U-Boot tests. That it makes CI more consistent is good, too. -- Tom
signature.asc
Description: PGP signature
