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.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 next
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