On Sun, Nov 03, 2024 at 04:56:40PM +0100, Heinrich Schuchardt wrote:
On 11/3/24 16:50, Tom Rini wrote:
On Sun, Nov 03, 2024 at 04:45:41PM +0100, Heinrich Schuchardt wrote:
On 11/3/24 08:12, Heinrich Schuchardt wrote:
The lib_test_uuid_to_le test fails on 32-bit systems. But we never caught this in our CI because we never ran any of our C unit tests on 32-bit.
Enable CONFIG_UNIT_TEST on qemu_arm_defconfig.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
configs/qemu_arm_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig index d042aea49bb..cc4f4540fd5 100644 --- a/configs/qemu_arm_defconfig +++ b/configs/qemu_arm_defconfig @@ -67,3 +67,4 @@ CONFIG_TPM2_MMIO=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y CONFIG_TPM=y +CONFIG_UNIT_TEST=y
Before merging this patch we also have to fix the lib_test_dynamic_uuid which fails on 32-bit.
Is it the test, or is it the UUID changes? I didn't go so far as to revert the UUID changes when I hit this on Pi 3 32b, just poked Caleb on irc.
While on 64-bit the expected GUID is generated (both on sandbox and qemu-riscv64_smode_defconfig), the generated GUID on 32-bit does not match the expected value. The generated GUID should be the same irrespective of the system.
Once we have fixed 32-bit little endian, we should start testing big endian.
Right. What I mean is, did this work prior to Caleb's UUID series that was merged with: commit 35394e1ea77ba0ad971d9115bd965a2403c0e031 Merge: 9eb0d731d800 7de51622a2cf Author: Tom Rini trini@konsulko.com Date: Fri Sep 13 08:20:25 2024 -0600
Merge tag 'efi-next-20241024' of https://source.denx.de/u-boot/custodians/u-boot-efi into n ext
Or has it always been wrong? To me, Patrick's report implies that it used to work.