On Mon, Oct 28, 2024 at 11:01:05PM +0100, Heinrich Schuchardt wrote: > On 10/28/24 22:34, Tom Rini wrote: > > On Mon, Oct 28, 2024 at 10:24:58PM +0100, Heinrich Schuchardt wrote: > > > On 10/28/24 17:48, Tom Rini wrote: > > > > The dynamic UUID test checks for the sandbox specific capsule UUID to be > > > > used, so we can only perform this test on sandbox currently. > > > > > > The tested function is gen_v5_guid(). This function is used to generated > > > capsule UUIDs. It receives the test data provided in > > > dynamic_uuid_test_data > > > test_data[]: > > > > > > * compatible string > > > * image name > > > > > > The generated UUID is compared to a UUID provided in the test data. > > > > > > By chance the chosen test data contains the string 'sandbox'. > > > > > > It is not obvious why this test should depend on running on the sandbox. > > > > > > Where did it fail for you? > > > > On Pi 3, I forget if it was rpi_3 or rpi_arm64_defconfig (with tweaks > > like enabling CONFIG_UNIT_TEST). > > > > On qemu_arm64_defconfig the tests runs fine: > > => ut lib lib_test_dynamic_uuid > Test: lib_test_dynamic_uuid: uuid.c > Failures: 0 > > Missing CONFIG_SANDBOX cannot be the cause of the issue that you observed.
Hunh, OK. Lets for now go with it being related to the 32bit UUID problem: https://lore.kernel.org/u-boot/[email protected] and that it was on 32bit Pi only where I saw that failure, as indeed I don't on 64bit Pi now. Thanks! -- Tom
signature.asc
Description: PGP signature
