[PATCH v7 0/7] efi: Add a test for EFI bootmeth
The test coverage for the EFI bootmeth is incomplete since it does not actually boot the application.
This series creates a simple test for this purpose. It includes a few patches to make this work:
- Revert of an unreviewed patch to change the sandbox efi filename - Hang in sandbox virtio due to EFI probing all block devices
Other necessary fixes have already been applied.
Changes in v7: - Add a revert of the un-reviewed patch, instead of just changing it - Just do the minimal update for the sandbox filename - Update commit message - Drop patches already applied - Drop patch 'Disable ANSI output for tests' - Rebase on -master
Changes in v6: - Drop the patch to disable sandbox virtio blk with EFI - Add new patch to disable the sandbox virtio blk device - Deal with sandbox CONFIG_LOGF_FUNC - Rebase on -next - Drop patches previously applied - Drop mention of helloworld since it is no-longer used by this test
Changes in v4: - Add efi_loader tag to some patches - Split out non-EFI patches into a different series
Changes in v2: - Add many new patches to resolve all the outstanding test issues
Simon Glass (7): test: boot: Update bootflow_iter() for console checking Revert "efi_loader: correctly identify binary name" efi_loader: sandbox: Use a different filename for sandbox efi_loader: Add a test app sandbox: virtio: Disable the sandbox virtio blk device test: efi: boot: Set up an image suitable for EFI testing test: efi: boot: Add a test for the efi bootmeth
arch/Kconfig | 3 +- arch/sandbox/dts/test.dts | 2 +- include/efi_default_filename.h | 25 +--------- lib/efi_loader/Kconfig | 10 ++++ lib/efi_loader/Makefile | 1 + lib/efi_loader/testapp.c | 68 ++++++++++++++++++++++++++++ test/boot/bootdev.c | 18 +++++++- test/boot/bootflow.c | 64 +++++++++++++++++++++++++- test/py/tests/bootstd/flash1.img.xz | Bin 0 -> 5016 bytes test/py/tests/test_ut.py | 52 ++++++++++++++++++--- 10 files changed, 209 insertions(+), 34 deletions(-) create mode 100644 lib/efi_loader/testapp.c create mode 100644 test/py/tests/bootstd/flash1.img.xz
This test checks console output so should have the UTF_CONSOLE flag. Add it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
test/boot/bootflow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index 154dea70a59..cc894e804a4 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -370,7 +370,7 @@ static int bootflow_iter(struct unit_test_state *uts)
return 0; } -BOOTSTD_TEST(bootflow_iter, UTF_DM | UTF_SCAN_FDT); +BOOTSTD_TEST(bootflow_iter, UTF_DM | UTF_SCAN_FDT | UTF_CONSOLE);
#if defined(CONFIG_SANDBOX) && defined(CONFIG_BOOTMETH_GLOBAL) /* Check using the system bootdev */
This patch was applied without sandbox review. It has changed how sandbox works and the original author has not been willing to discuss alternatives.
This reverts commit 3a0654ecd0d6a39406e6fe91f7a40ce589594ae9.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v7: - Add a revert of the un-reviewed patch, instead of just changing it
include/efi_default_filename.h | 41 +++++++++++++--------------------- 1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/include/efi_default_filename.h b/include/efi_default_filename.h index 77932984b55..13b9de8754a 100644 --- a/include/efi_default_filename.h +++ b/include/efi_default_filename.h @@ -5,7 +5,6 @@ * file name is defined in this include. * * Copyright (c) 2022, Heinrich Schuchardt xypron.glpk@gmx.de - * Copyright (c) 2022, Linaro Limited */
#ifndef _EFI_DEFAULT_FILENAME_H @@ -15,42 +14,32 @@
#undef BOOTEFI_NAME
-#ifdef CONFIG_SANDBOX - #if HOST_ARCH == HOST_ARCH_X86_64 #define BOOTEFI_NAME "BOOTX64.EFI" -#elif HOST_ARCH == HOST_ARCH_X86 -#define BOOTEFI_NAME "BOOTIA32.EFI" -#elif HOST_ARCH == HOST_ARCH_AARCH64 -#define BOOTEFI_NAME "BOOTAA64.EFI" -#elif HOST_ARCH == HOST_ARCH_ARM -#define BOOTEFI_NAME "BOOTARM.EFI" -#elif HOST_ARCH == HOST_ARCH_RISCV32 -#define BOOTEFI_NAME "BOOTRISCV32.EFI" -#elif HOST_ARCH == HOST_ARCH_RISCV64 -#define BOOTEFI_NAME "BOOTRISCV64.EFI" -#else -#error Unsupported UEFI architecture #endif
-#else +#if HOST_ARCH == HOST_ARCH_X86 +#define BOOTEFI_NAME "BOOTIA32.EFI" +#endif
-#if defined(CONFIG_ARM64) +#if HOST_ARCH == HOST_ARCH_AARCH64 #define BOOTEFI_NAME "BOOTAA64.EFI" -#elif defined(CONFIG_ARM) +#endif + +#if HOST_ARCH == HOST_ARCH_ARM #define BOOTEFI_NAME "BOOTARM.EFI" -#elif defined(CONFIG_X86_64) -#define BOOTEFI_NAME "BOOTX64.EFI" -#elif defined(CONFIG_X86) -#define BOOTEFI_NAME "BOOTIA32.EFI" -#elif defined(CONFIG_ARCH_RV32I) +#endif + +#if HOST_ARCH == HOST_ARCH_RISCV32 #define BOOTEFI_NAME "BOOTRISCV32.EFI" -#elif defined(CONFIG_ARCH_RV64I) +#endif + +#if HOST_ARCH == HOST_ARCH_RISCV64 #define BOOTEFI_NAME "BOOTRISCV64.EFI" -#else -#error Unsupported UEFI architecture #endif
+#ifndef BOOTEFI_NAME +#error Unsupported UEFI architecture #endif
#endif
From: Simon Glass sjg@chromium.org Date: Sat, 19 Oct 2024 09:24:29 -0600
This patch was applied without sandbox review. It has changed how sandbox works and the original author has not been willing to discuss alternatives.
This reverts commit 3a0654ecd0d6a39406e6fe91f7a40ce589594ae9.
Signed-off-by: Simon Glass sjg@chromium.org
This breaks EFI booting from removable media in a cross-compiled U-Boot. And you still end up with the same HOST_ARCH-dependent BOOTEFI_NAME for sandbox, so no, this didn't change how sandbox works.
Changes in v7:
- Add a revert of the un-reviewed patch, instead of just changing it
include/efi_default_filename.h | 41 +++++++++++++--------------------- 1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/include/efi_default_filename.h b/include/efi_default_filename.h index 77932984b55..13b9de8754a 100644 --- a/include/efi_default_filename.h +++ b/include/efi_default_filename.h @@ -5,7 +5,6 @@
- file name is defined in this include.
- Copyright (c) 2022, Heinrich Schuchardt xypron.glpk@gmx.de
*/
- Copyright (c) 2022, Linaro Limited
#ifndef _EFI_DEFAULT_FILENAME_H @@ -15,42 +14,32 @@
#undef BOOTEFI_NAME
-#ifdef CONFIG_SANDBOX
#if HOST_ARCH == HOST_ARCH_X86_64 #define BOOTEFI_NAME "BOOTX64.EFI" -#elif HOST_ARCH == HOST_ARCH_X86 -#define BOOTEFI_NAME "BOOTIA32.EFI" -#elif HOST_ARCH == HOST_ARCH_AARCH64 -#define BOOTEFI_NAME "BOOTAA64.EFI" -#elif HOST_ARCH == HOST_ARCH_ARM -#define BOOTEFI_NAME "BOOTARM.EFI" -#elif HOST_ARCH == HOST_ARCH_RISCV32 -#define BOOTEFI_NAME "BOOTRISCV32.EFI" -#elif HOST_ARCH == HOST_ARCH_RISCV64 -#define BOOTEFI_NAME "BOOTRISCV64.EFI" -#else -#error Unsupported UEFI architecture #endif
-#else +#if HOST_ARCH == HOST_ARCH_X86 +#define BOOTEFI_NAME "BOOTIA32.EFI" +#endif
-#if defined(CONFIG_ARM64) +#if HOST_ARCH == HOST_ARCH_AARCH64 #define BOOTEFI_NAME "BOOTAA64.EFI" -#elif defined(CONFIG_ARM) +#endif
+#if HOST_ARCH == HOST_ARCH_ARM #define BOOTEFI_NAME "BOOTARM.EFI" -#elif defined(CONFIG_X86_64) -#define BOOTEFI_NAME "BOOTX64.EFI" -#elif defined(CONFIG_X86) -#define BOOTEFI_NAME "BOOTIA32.EFI" -#elif defined(CONFIG_ARCH_RV32I) +#endif
+#if HOST_ARCH == HOST_ARCH_RISCV32 #define BOOTEFI_NAME "BOOTRISCV32.EFI" -#elif defined(CONFIG_ARCH_RV64I) +#endif
+#if HOST_ARCH == HOST_ARCH_RISCV64 #define BOOTEFI_NAME "BOOTRISCV64.EFI" -#else -#error Unsupported UEFI architecture #endif
+#ifndef BOOTEFI_NAME +#error Unsupported UEFI architecture #endif
#endif
2.34.1
Sandbox is a separate architecture in U-Boot. We want to create binaries which can run no matter what host architecture is in use.
Create a special filename for sandbox, to avoid needing different code paths when creating the file in CI.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v7: - Just do the minimal update for the sandbox filename
include/efi_default_filename.h | 32 +++++++++++--------------------- 1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/include/efi_default_filename.h b/include/efi_default_filename.h index 13b9de8754a..6806c0daa88 100644 --- a/include/efi_default_filename.h +++ b/include/efi_default_filename.h @@ -14,31 +14,21 @@
#undef BOOTEFI_NAME
-#if HOST_ARCH == HOST_ARCH_X86_64 -#define BOOTEFI_NAME "BOOTX64.EFI" -#endif - -#if HOST_ARCH == HOST_ARCH_X86 -#define BOOTEFI_NAME "BOOTIA32.EFI" -#endif - -#if HOST_ARCH == HOST_ARCH_AARCH64 +#ifdef CONFIG_SANDBOX +#define BOOTEFI_NAME "BOOTSBOX.EFI" +#elif defined(CONFIG_ARM64) #define BOOTEFI_NAME "BOOTAA64.EFI" -#endif - -#if HOST_ARCH == HOST_ARCH_ARM +#elif defined(CONFIG_ARM) #define BOOTEFI_NAME "BOOTARM.EFI" -#endif - -#if HOST_ARCH == HOST_ARCH_RISCV32 +#elif defined(CONFIG_X86_64) +#define BOOTEFI_NAME "BOOTX64.EFI" +#elif defined(CONFIG_X86) +#define BOOTEFI_NAME "BOOTIA32.EFI" +#elif defined(CONFIG_ARCH_RV32I) #define BOOTEFI_NAME "BOOTRISCV32.EFI" -#endif - -#if HOST_ARCH == HOST_ARCH_RISCV64 +#elif defined(CONFIG_ARCH_RV64I) #define BOOTEFI_NAME "BOOTRISCV64.EFI" -#endif - -#ifndef BOOTEFI_NAME +#else #error Unsupported UEFI architecture #endif
Add a simple app to use for testing. This is intended to do whatever it needs to for testing purposes. For now it just prints a message and exits boot services.
There was a considerable amount of discussion about whether it is OK to call exit-boot-services and then return to U-Boot. This is not normally done in a real application, since exit-boot-services is used to completely disconnect from U-Boot. However, since this is a test, we need to check the results of running the app, so returning is necessary. It works correctly and it provides a nice model of how to test the EFI code in a simple way.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v7: - Update commit message
lib/efi_loader/Kconfig | 10 ++++++ lib/efi_loader/Makefile | 1 + lib/efi_loader/testapp.c | 68 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 79 insertions(+) create mode 100644 lib/efi_loader/testapp.c
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 69b2c9360d8..6ced29da719 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -565,6 +565,16 @@ config BOOTEFI_HELLO_COMPILE No additional space will be required in the resulting U-Boot binary when this option is enabled.
+config BOOTEFI_TESTAPP_COMPILE + bool "Compile an EFI test app for testing" + default y + help + This compiles an app designed for testing. It is packed into an image + by the test.py testing frame in the setup_efi_image() function. + + No additional space will be required in the resulting U-Boot binary + when this option is enabled. + endif
source "lib/efi/Kconfig" diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index 00d18966f9e..87131ab911d 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -20,6 +20,7 @@ apps-$(CONFIG_EFI_LOAD_FILE2_INITRD) += initrddump ifeq ($(CONFIG_GENERATE_ACPI_TABLE),) apps-y += dtbdump endif +apps-$(CONFIG_BOOTEFI_TESTAPP_COMPILE) += testapp
obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o obj-$(CONFIG_EFI_BOOTMGR) += efi_bootmgr.o diff --git a/lib/efi_loader/testapp.c b/lib/efi_loader/testapp.c new file mode 100644 index 00000000000..feb444c92e9 --- /dev/null +++ b/lib/efi_loader/testapp.c @@ -0,0 +1,68 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Hello world EFI application + * + * Copyright 2024 Google LLC + * Written by Simon Glass sjg@chromium.org + * + * This test program is used to test the invocation of an EFI application. + * It writes a few messages to the console and then exits boot services + */ + +#include <efi_api.h> + +static const efi_guid_t loaded_image_guid = EFI_LOADED_IMAGE_PROTOCOL_GUID; + +static struct efi_system_table *systable; +static struct efi_boot_services *boottime; +static struct efi_simple_text_output_protocol *con_out; + +/** + * efi_main() - entry point of the EFI application. + * + * @handle: handle of the loaded image + * @systab: system table + * Return: status code + */ +efi_status_t EFIAPI efi_main(efi_handle_t handle, + struct efi_system_table *systab) +{ + struct efi_loaded_image *loaded_image; + efi_status_t ret; + efi_uintn_t map_size; + efi_uintn_t map_key; + efi_uintn_t desc_size; + u32 desc_version; + + systable = systab; + boottime = systable->boottime; + con_out = systable->con_out; + + /* Get the loaded image protocol */ + ret = boottime->open_protocol(handle, &loaded_image_guid, + (void **)&loaded_image, NULL, NULL, + EFI_OPEN_PROTOCOL_GET_PROTOCOL); + if (ret != EFI_SUCCESS) { + con_out->output_string + (con_out, u"Cannot open loaded image protocol\r\n"); + goto out; + } + + /* UEFI requires CR LF */ + con_out->output_string(con_out, u"U-Boot test app for EFI_LOADER\r\n"); + +out: + map_size = 0; + ret = boottime->get_memory_map(&map_size, NULL, &map_key, &desc_size, + &desc_version); + con_out->output_string(con_out, u"Exiting boot sevices\n"); + + /* exit boot services so that this part of U-Boot can be tested */ + boottime->exit_boot_services(handle, map_key); + + /* now exit for real */ + ret = boottime->exit(handle, ret, 0, NULL); + + /* We should never arrive here */ + return ret; +}
This is not implemented so cannot actually be used to read blocks. Disable it until it is implemented, to avoid causing a hang with EFI, which probes every available BLK device.
Signed-off-by: Simon Glass sjg@chromium.org Issue: https://source.denx.de/u-boot/u-boot/-/issues/37 ---
(no changes since v6)
Changes in v6: - Drop the patch to disable sandbox virtio blk with EFI - Add new patch to disable the sandbox virtio blk device
arch/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/Kconfig b/arch/Kconfig index 8f1f4667012..c39efb4d0a2 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -212,7 +212,8 @@ config SANDBOX imply VIRTIO_MMIO imply VIRTIO_PCI imply VIRTIO_SANDBOX - imply VIRTIO_BLK + # Re-enable this when fully implemented + # imply VIRTIO_BLK imply VIRTIO_NET imply DM_SOUND imply PCI_SANDBOX_EP
On Sat, Oct 19, 2024 at 09:24:32AM -0600, Simon Glass wrote:
This is not implemented so cannot actually be used to read blocks. Disable it until it is implemented, to avoid causing a hang with EFI, which probes every available BLK device.
Signed-off-by: Simon Glass sjg@chromium.org Issue: https://source.denx.de/u-boot/u-boot/-/issues/37
Reviewed-by: Tom Rini trini@konsulko.com
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 test/py/tests/test_ut.py | 52 ++++++++++++++++++++++++---- 5 files changed, 65 insertions(+), 9 deletions(-) create mode 100644 test/py/tests/bootstd/flash1.img.xz
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index 9bf44ae3b0b..f40fd5a2b16 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -1512,7 +1512,7 @@ flash-stick@1 { reg = <1>; compatible = "sandbox,usb-flash"; - sandbox,filepath = "testflash1.bin"; + sandbox,filepath = "flash1.img"; };
flash-stick@2 { diff --git a/test/boot/bootdev.c b/test/boot/bootdev.c index 369105ca4cf..c892854b227 100644 --- a/test/boot/bootdev.c +++ b/test/boot/bootdev.c @@ -221,6 +221,10 @@ static int bootdev_test_order(struct unit_test_state *uts) /* Use the environment variable to override it */ ut_assertok(env_set("boot_targets", "mmc1 mmc2 usb")); ut_assertok(bootflow_scan_first(NULL, NULL, &iter, 0, &bflow)); + + /* get the usb device which has a backing file (flash1.img) */ + ut_asserteq(0, bootflow_scan_next(&iter, &bflow)); + ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow)); ut_asserteq(5, iter.num_devs); ut_asserteq_str("mmc1.bootdev", iter.dev_used[0]->name); @@ -260,7 +264,11 @@ static int bootdev_test_order(struct unit_test_state *uts) ut_assertok(bootflow_scan_first(NULL, NULL, &iter, 0, &bflow)); ut_asserteq(2, iter.num_devs);
- /* Now scan past mmc1 and make sure that the 3 USB devices show up */ + /* + * Now scan past mmc1 and make sure that the 3 USB devices show up. The + * first one has a backing file so returns success + */ + ut_asserteq(0, bootflow_scan_next(&iter, &bflow)); ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow)); ut_asserteq(6, iter.num_devs); ut_asserteq_str("mmc2.bootdev", iter.dev_used[0]->name); @@ -322,6 +330,10 @@ static int bootdev_test_prio(struct unit_test_state *uts)
/* 3 MMC and 3 USB bootdevs: MMC should come before USB */ ut_assertok(bootflow_scan_first(NULL, NULL, &iter, 0, &bflow)); + + /* get the usb device which has a backing file (flash1.img) */ + ut_asserteq(0, bootflow_scan_next(&iter, &bflow)); + ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow)); ut_asserteq(6, iter.num_devs); ut_asserteq_str("mmc2.bootdev", iter.dev_used[0]->name); @@ -339,6 +351,10 @@ static int bootdev_test_prio(struct unit_test_state *uts) bootflow_iter_uninit(&iter); ut_assertok(bootflow_scan_first(NULL, NULL, &iter, BOOTFLOWIF_HUNT, &bflow)); + + /* get the usb device which has a backing file (flash1.img) */ + ut_asserteq(0, bootflow_scan_next(&iter, &bflow)); + ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow)); ut_asserteq(7, iter.num_devs); ut_asserteq_str("usb_mass_storage.lun0.bootdev", diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index cc894e804a4..0a819998ebd 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -533,7 +533,7 @@ static int prep_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev,
order[2] = mmc_dev;
- /* Enable the mmc4 node since we need a second bootflow */ + /* Enable the requested mmc node since we need a second bootflow */ root = oftree_root(oftree_default()); node = ofnode_find_subnode(root, mmc_dev); ut_assert(ofnode_valid(node)); diff --git a/test/py/tests/bootstd/flash1.img.xz b/test/py/tests/bootstd/flash1.img.xz new file mode 100644 index 0000000000000000000000000000000000000000..9148b91a20c1f0acb54449b124d1408961e92507 GIT binary patch literal 5016 zcmeI0cTf{r8pRVz9+4n5AV?_EgQ1BO;n5K(kx-;pUwkwL0tBUqlz==yF+ikBDAExL zQWT{~2Sq?y06~gW5eP+U$nMPkwKMCEzInSlv*Z7F=Fa`i`OZ1tr78#8*Z}|x3nSGR z=>Wn&ZU6ufAUmH=qlqxW9033y>XG5m*pL}cy$rvQVYbMeTPGAi$9qqfMnd47Jp+<S zIxLcX-gdy?;z*~}QgHUO>b8@aTLW9^ZgBe#gV-u~nri0|VMr5lA6KhSV}ds3x_d!R zK70s*W-GN^=;}ze2DKy`8Bp8a3s-y^i!J>$OdpXOt?{Uc-H+4p?j<BRmf`kr@RkOb z#nr%a+fVcMj7<BT<4=wb&7}i+1?+`%_9rcV-IGFt)xzJvuYasj+h}W$aV}-mF#cWV z0q02?Tk;;}mhB#MFO491k+tL~bm}lePR6P^F?uU1qWM~zn8n@>UP+#@pmNRUwJ*{D zGJt0<ec}SEe@BuyWsjlSn3!f77C4m?PYr2;FS!1eCM{1>cjopJaH2B8t_BV*T|(V? zQE{)kaF4zAwh?({NItl!v80%xP5j+-km~m0FjHOI&3eSrr0=y}ILxn<Dj+V+FtA;? zkfwXZQuFzB-RUPwyo#9fJZ3vFLqjRnRXx{Cjj$``T7)LJeniuGCW|XG2Di@RTK-7v z%@LmQG%VY9Q*iQk{IX5!h|sU6x5>&A^gJ={@<k08%TNsA;LO8|NDKjWvI9|*L4$MB z+7n%gV=Mx1tAg1*_I$;8%e5KZC}1lz<@sfc9Rl028JFGGi3IeoQhBA1Rw!e4KbgZ> zcWW%yKY}Nl<I~z}t_$|PJU0<-g!)ivhK&n#A9YhnK-3N*Q`%=WA+6TycBy`{rYBep zuUe97ouG<2ucIu+XU;2LR8g8yklNz3;<k<<Au8XakMkm_=cM5gt`}-7tJ^bCnR7tn zBe3b$z#jhsLv05PN&NHU+npZ4f?Y<fTmv;LxJ0w1oHl!Nb^<(FgZXuRy)xXYp~*LD z3L*PG^Lc*574Eh7oi!F-PcV5j<eaGzxJ8`ao#8ImP6c^lrB7Shz+u!o#+lun*$NN4 ze+u>1tu^^*#UCxf;bJ&NSo@TX5>5e+pT?chViS8Qddj*v2(zyvvS5|tWhS65&b1s# ztq%uj(ECDcNKU@WQlPgiVOeS{T^}+v^G!^rLMD_i<okVaaHNxvN%DKEC_OJjtJ`fy zKFE0k6@0_k?{_0d-|8&uGq1;2=W4>2e;x1$aOEia;LV&Z930_1Thek8ad0!1k*%M3 z_Q0A`8vzaWYYX7vQ=^y;COH>9zmbcNam0;YlMB3IVMi><k<II&(g=3_UBMw^HCFC+ z@)H?uigXDBXA74rM>ftHk8xY%(%}{iymL<`3XMZW+f8a2?SETgT0;aAgL=a#3!1KX z^cLebMqp!W-R{zh?QA#i^JT<kvfv0(8ry`yg<(qzh1_zt_{3BP*1~C5OmS7q)YTXx zPX4FbYU!lv4)?BM&@_$q$I|V>ju!<g<X?nd#FT-)ZWn*qLX7tafjq@`!P?D{S5IGJ zuvsiPZc%MJ!b8(+vK$@C`6S1;#b%n~3cgfSaXr-V3RSy1Czll1NJTo9Lb$}O7Z-C- zx?3&7@!8q&vQI%h9&~esojd+AF!$PiZ2Gn^%Tq%h_1PQ80p&ToqgoX4NUYYmH|n;P ztuS}UI)h4dAc_9_X4%0uX8Ct>o5tn8#754Z(}^I`q<{*5Rey^jYGXyHJRh;{p1ikj zc9Dqls^pvK0YX|_7#zPTf!*b82Bk?#z3fQBiu4q*qMiE6{UF>)MUAS7qBGw*k4&SI zpAJ7@{r3j-*FNfpyz$Rntz!RCiAZAuN`Ei6|5Fa%9ZzPgnpH&FE1=r9f!*ynU>LRk zs^i2fv8m7Ts$<41M5$$$O!aU5TsIe9FH*b*iXYp#Gs1FO^Y+cMC@x{|f&W>e{yEir zH?4mW<^(Pg@=wM6Kq2~v;(m_kcZ=>Pupg}4KY{%zU`U3zZ->A?w~ha5Y7#LChpCq# zjLs}(gwV(qHKH0PIq==G%UE&4)cV#zQp!hu3P)N#5~J*rP#)Mrnf2FEJB=>p2`NB0 zxrbCGW-cOk>(@E=<>XoI^r+-qsU_Hbj=2C;jaT42`)4Nl?$<AeJrorX|6Ggdh?op? zoEJg?^i<Tb`^gBPlWi0Ad}h<6eb;Olmg82pe%EB`<o%Hrcp--3u;QdeNlf1~)~}X+ z2_`kvu^$BMA*_~WOoBRm2Y2qwq_--k{wDL%<F=&7bN=H4xn;G>A9Ao502gVwPUdyH zk|c8N(S#6;Vbf5B1-#i5rvvuH#*!j4W%J!DHrzLL7Y}2FiA;&kE{gOSUX)eQM58e% zxzCf&=qNe#7eNq+P!z(uHeIWDRQiY=vVq^N5#m=JF!q>=l3~T}x`dQCQkTnB7Jyp9 z9<Ke9SBS3!ukGU#4CI-@!yY10$Hu`~TkU;%B9<w_?}51x8UCnvkWast$>!$S*si%Y z#K@3yE)2HKtuQf<(p%-MP;{u#ln=wpQ1YA#gF=REU4Ysw)eE4nJR61Dj5RfBZ~dM* zSMp96hovw!v!`3u@q#5n+3D*c)52Q{z19NhVU|dnO=-{cW*eIX_2Q97jaK23vWBG7 z@m-4+V3|8nS|8n5(7fuqxU~m1hiT=)sP4+=FIXUT1|kn%EzpMCxRuaG>(_h94n9E@ z^-0~gvKr&93iu$m=JxNvH`Z>5eVq0gWqPV|6Dd^9zrpc%XLqFfRKYs#OhX;3>Jm;b zh)!B^-RF<)Tr}SWQrPsyLGNqxRRqOIG#PiTgwEoM7^!y@5qBOR-Cf%U)jHUm7=x1n zabX0NS!nxd?gq)JryA$B@Ibw^qlg)E=DN@e$6aC^s8+O<N*T+sZtE3VJS6CHR;Hfb zj6!OYV>_{x@AiR~<_W*A<j@8rZy})!cUSg4dNp5pXk>_j#gJdl-^e|Hn)_#5WHWmA z*>1210pl<x|1SJEm1hL6rCToRBa2%(;ktp6={I?DPoB?_h#?1Y%pMU_Pnn5X#zFHB zkD8>k_~Sa)Oa|ASTX<>*J$=fQh1r%Sk4yV+%E8c2*ol{zZAGEORz}_=pJYbILT?~9 zx@Ww_ZY!Phs9}DZ;|(-K7u0?|<x*!^Q((Pp0U@L0j5%*kym>tedsc3u1!ajplM14D z?)FvVYF1EAD}VwEmh!>y)l!<B_<wT8$jHNU{OnXe*r~#qv;d5N2DZJiLI6N8ou4Vd g!6FL)+!7BD4?iLFVyT<d=5|Q;_y0ElgRR})0MlW=WB>pF
literal 0 HcmV?d00001
diff --git a/test/py/tests/test_ut.py b/test/py/tests/test_ut.py index 39aa1035e34..f647e2f0af2 100644 --- a/test/py/tests/test_ut.py +++ b/test/py/tests/test_ut.py @@ -28,21 +28,22 @@ def mkdir_cond(dirname): if not os.path.exists(dirname): os.mkdir(dirname)
-def setup_image(cons, mmc_dev, part_type, second_part=False): +def setup_image(cons, devnum, part_type, second_part=False, basename='mmc'): """Create a 20MB disk image with a single partition
Args: cons (ConsoleBase): Console to use - mmc_dev (int): MMC device number to use, e.g. 1 + devnum (int): Device number to use, e.g. 1 part_type (int): Partition type, e.g. 0xc for FAT32 second_part (bool): True to contain a small second partition + basename (str): Base name to use in the filename, e.g. 'mmc'
Returns: tuple: str: Filename of MMC image str: Directory name of 'mnt' directory """ - fname = os.path.join(cons.config.source_dir, f'mmc{mmc_dev}.img') + fname = os.path.join(cons.config.source_dir, f'{basename}{devnum}.img') mnt = os.path.join(cons.config.persistent_data_dir, 'mnt') mkdir_cond(mnt)
@@ -78,16 +79,17 @@ def mount_image(cons, fname, mnt, fstype): u_boot_utils.run_and_log(cons, f'sudo chown {getpass.getuser()} {mnt}') return loop
-def copy_prepared_image(cons, mmc_dev, fname): +def copy_prepared_image(cons, devnum, fname, basename='mmc'): """Use a prepared image since we cannot create one
Args: cons (ConsoleBase): Console touse - mmc_dev (int): MMC device number + devnum (int): device number fname (str): Filename of MMC image + basename (str): Base name to use in the filename, e.g. 'mmc' """ infname = os.path.join(cons.config.source_dir, - f'test/py/tests/bootstd/mmc{mmc_dev}.img.xz') + f'test/py/tests/bootstd/{basename}{devnum}.img.xz') u_boot_utils.run_and_log(cons, ['sh', '-c', f'xz -dc {infname} >{fname}'])
def setup_bootmenu_image(cons): @@ -549,6 +551,43 @@ def test_ut_dm_init(u_boot_console): with open(fn, 'wb') as fh: fh.write(data)
+ +def setup_efi_image(cons): + """Create a 20MB disk image with an EFI app on it""" + devnum = 1 + basename = 'flash' + fname, mnt = setup_image(cons, devnum, 0xc, second_part=True, + basename=basename) + + loop = None + mounted = False + complete = False + try: + loop = mount_image(cons, fname, mnt, 'ext4') + mounted = True + efi_dir = os.path.join(mnt, 'EFI') + mkdir_cond(efi_dir) + bootdir = os.path.join(efi_dir, 'BOOT') + mkdir_cond(bootdir) + efi_src = os.path.join(cons.config.build_dir, + f'lib/efi_loader/testapp.efi') + efi_dst = os.path.join(bootdir, 'BOOTSBOX.EFI') + with open(efi_src, 'rb') as inf: + with open(efi_dst, 'wb') as outf: + outf.write(inf.read()) + except ValueError as exc: + print(f'Falled to create image, failing back to prepared copy: {exc}') + + finally: + if mounted: + u_boot_utils.run_and_log(cons, 'sudo umount --lazy %s' % mnt) + if loop: + u_boot_utils.run_and_log(cons, 'sudo losetup -d %s' % loop) + + if not complete: + copy_prepared_image(cons, devnum, fname, basename) + + @pytest.mark.buildconfigspec('cmd_bootflow') @pytest.mark.buildconfigspec('sandbox') def test_ut_dm_init_bootstd(u_boot_console): @@ -559,6 +598,7 @@ def test_ut_dm_init_bootstd(u_boot_console): setup_cedit_file(u_boot_console) setup_cros_image(u_boot_console) setup_android_image(u_boot_console) + setup_efi_image(u_boot_console)
# Restart so that the new mmc1.img is picked up u_boot_console.restart_uboot()
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.
This is also an ext4 image and while the specification only says SHOULD for being FAT32 there are practical problems with using ext4 and not FAT32 for us (some missing features in our ext4 implementation that prevent variables from working) and so should be done as FAT32 and not ext4.
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?
BTW it would be good to get CI running on arm. I believe Linaro might have some servers. I keep thinking of getting an Ampere device but so far have resisted as it is UEFI with closed firmware...
This is also an ext4 image and while the specification only says SHOULD for being FAT32 there are practical problems with using ext4 and not FAT32 for us (some missing features in our ext4 implementation that prevent variables from working) and so should be done as FAT32 and not ext4.
OK I'll update it.
IMO FAT32 is one of the things that will kill EFI eventually, if they don't sort it out. It just isn't reliable enough for commercial use, unless no one ever writes to it.
Regards, Simon
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?) ?
BTW it would be good to get CI running on arm. I believe Linaro might have some servers. I keep thinking of getting an Ampere device but so far have resisted as it is UEFI with closed firmware...
The problem is more, for GitLab, getting anyone to maintain and provide a runner and then for Azure, waiting for Microsoft to include some in the free tier. I think for the former, at one point I was thinking about using one of Oracle's always-free tier ones and for a small enough subset of things (like a host tools and a sandbox run) it might be fine.
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.
BTW it would be good to get CI running on arm. I believe Linaro might have some servers. I keep thinking of getting an Ampere device but so far have resisted as it is UEFI with closed firmware...
The problem is more, for GitLab, getting anyone to maintain and provide a runner and then for Azure, waiting for Microsoft to include some in the free tier. I think for the former, at one point I was thinking about using one of Oracle's always-free tier ones and for a small enough subset of things (like a host tools and a sandbox run) it might be fine.
OK. I suspect Ilias might be able to help.
Regards, Simon
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?
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.
Regards, Simon
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.
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.
Regards, Simon
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.
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
On Thu, Oct 24, 2024 at 06:39:00PM +0200, Simon Glass wrote:
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?
Oh, so replacing the file is blocked on not having sudo in use on these tests. That wasn't clear, sorry.
Hi Tom,
On Thu, 24 Oct 2024 at 19:37, Tom Rini trini@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 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?
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.
Regards, Simon
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 trini@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 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?
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.
Add a simple test of booting with the EFI bootmeth, which runs the app and checks that it can call 'exit boot-services' (to check that all the device-removal code doesn't break anything) and then exit back to U-Boot.
This uses a disk image containing the testapp, ready for execution by sandbox when needed.
The unwanted ANSI output is still a problem when running this test.
Signed-off-by: Simon Glass sjg@chromium.org
--- Note that this uses the same mechanism as for the other images which are created. Once this series lands I will update[1] and revisit.
[1] https://patchwork.ozlabs.org/project/uboot/patch/ 20240802093322.15240-1-richard@nod.at/
Changes in v7: - Drop patches already applied - Drop patch 'Disable ANSI output for tests' - Rebase on -master
Changes in v6: - Deal with sandbox CONFIG_LOGF_FUNC - Rebase on -next - Drop patches previously applied - Drop mention of helloworld since it is no-longer used by this test
Changes in v4: - Add efi_loader tag to some patches - Split out non-EFI patches into a different series
Changes in v2: - Add many new patches to resolve all the outstanding test issues
test/boot/bootflow.c | 60 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index 0a819998ebd..b7f4b6371ee 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -13,6 +13,7 @@ #include <cli.h> #include <dm.h> #include <efi_default_filename.h> +#include <efi_loader.h> #include <expo.h> #ifdef CONFIG_SANDBOX #include <asm/test.h> @@ -31,6 +32,9 @@ extern U_BOOT_DRIVER(bootmeth_android); extern U_BOOT_DRIVER(bootmeth_cros); extern U_BOOT_DRIVER(bootmeth_2script);
+/* Use this as the vendor for EFI to tell the app to exit boot services */ +static u16 __efi_runtime_data test_vendor[] = u"U-Boot testing"; + static int inject_response(struct unit_test_state *uts) { /* @@ -1213,3 +1217,59 @@ static int bootflow_android(struct unit_test_state *uts) return 0; } BOOTSTD_TEST(bootflow_android, UTF_CONSOLE); + +/* Test EFI bootmeth */ +static int bootflow_efi(struct unit_test_state *uts) +{ + /* disable ethernet since the hunter will run dhcp */ + test_set_eth_enable(false); + + /* make USB scan without delays */ + test_set_skip_delays(true); + + bootstd_reset_usb(); + + ut_assertok(bootstd_test_drop_bootdev_order(uts)); + ut_assertok(run_command("bootflow scan", 0)); + ut_assert_skip_to_line( + "Bus usb@1: scanning bus usb@1 for devices... 5 USB Device(s) found"); + + ut_assertok(run_command("bootflow list", 0)); + + ut_assert_nextlinen("Showing all"); + ut_assert_nextlinen("Seq"); + ut_assert_nextlinen("---"); + ut_assert_nextlinen(" 0 extlinux"); + ut_assert_nextlinen( + " 1 efi ready usb_mass_ 1 usb_mass_storage.lun0.boo /EFI/BOOT/BOOTSBOX.EFI"); + ut_assert_nextlinen("---"); + ut_assert_skip_to_line("(2 bootflows, 2 valid)"); + ut_assert_console_end(); + + ut_assertok(run_command("bootflow select 1", 0)); + ut_assert_console_end(); + + systab.fw_vendor = test_vendor; + + ut_asserteq(1, run_command("bootflow boot", 0)); + ut_assert_nextline( + "** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi"); + if (IS_ENABLED(CONFIG_LOGF_FUNC)) + ut_assert_skip_to_line(" efi_run_image() Booting /\EFI\BOOT\BOOTSBOX.EFI"); + else + ut_assert_skip_to_line("Booting /\EFI\BOOT\BOOTSBOX.EFI"); + + /* TODO: Why the \r ? */ + ut_assert_nextline("U-Boot test app for EFI_LOADER\r"); + ut_assert_nextline("Exiting boot sevices"); + if (IS_ENABLED(CONFIG_LOGF_FUNC)) + ut_assert_nextline(" do_bootefi_exec() ## Application failed, r = 5"); + else + ut_assert_nextline("## Application failed, r = 5"); + ut_assert_nextline("Boot failed (err=-22)"); + + ut_assert_console_end(); + + return 0; +} +BOOTSTD_TEST(bootflow_efi, UTF_CONSOLE);
participants (3)
-
Mark Kettenis -
Simon Glass -
Tom Rini