On 11/3/24 17:12, Tom Rini wrote:
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.schucha...@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 <tr...@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.
The functionality and the failing test were added by the series.
Best regards
Heinrich
