Seeing a regression in functionality across multiple devices. I did a bit of bisecting, here's the path:
Thu May 5 19:37:22 2022 -0400 working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0 no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0 unrecognized opcode `csrs sstatus,a5', extension `zicsr' required
Wed Oct 12 14:59:51 2022 +0200 broke: e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr issue)
Mon Dec 19 08:45:26 2022 -0500 broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0
Mon Jan 2 09:36:13 2023 -0500 broke: 582e3c9fb2337c2f49faa73ac86dde25f4d56901 gcc 12.2.0 Working boots our EFI loader fine. Broke boots see similar Load Access faults multiple platforms (qemu, unmatched, StarFive): StarFive VisionFive 2:
SATP: 0x80000000000fbe03 Calling ExitBootServices. So long, EFI! clk u5_dw_i2c_clk_core already disabled clk u5_dw_i2c_clk_apb already disabled Unhandled exception: Load access fault EPC: 00000000fe6dc496 RA: 00000000fe6dc488 TVAL: 0000000000000000 EPC: 000000003e98e496 RA: 000000003e98e488 reloc adjusted
SP: 00000000ff73b868 GP: 0000000000000000 TP: 0000000000000001 T0: 00000000fbf28135 T1: 0000000000000008 T2: 0000000000000000 S0: 0000000000000021 S1: 0000000000000000 A0: 0000000000000021 A1: 0000000000000000 A2: 0000000000000001 A3: 00000000ff73b968 A4: 0000000000000001 A5: 00000000000001ff A6: 0000000000000020 A7: 000000000000000a S2: 00000000ff73b968 S3: ffffffc0020940c6 S4: 00000000fe713c80 S5: 00000000ff73be94 S6: 00000000ff73beb8 S7: 00000000ff73beb0 S8: 00000000ff73bea8 S9: 00000000ff73be98 S10: 00000000fe6fc288 S11: 00000000fe713c70 T3: 0000000074757074 T4: ffffffffffffffe8 T5: 0000000000000000 T6: 00000000fbf2810d
Code: 0b31 0793 1ff0 c763 02a7 842a 5863 00a0 (609c) UEFI image [0x00000000fe6d0000:0x00000000fe720fff] pc=0xc496 '/efibootbootriscv64.efi' My questions:
* Is GCC 12.2 known broken / unreliable for riscv64 builds of u-boot? * Has anything else changed around memory management on riscv64 between May 2022 and Oct 2022
-- Alex
January 4, 2023 9:35 AM, "Alex" kallisti5@unixzen.com wrote:
Seeing a regression in functionality across multiple devices. I did a bit of bisecting, here's the path:
EEh. Just added another data point. The breakage for us happens on the gcc 11.3.0 upgrade of u-boot, not the 12.2.0 upgrade of u-boot.
Thu May 5 19:37:22 2022 -0400 working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0 broke: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.3.0 (rebuild) no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0 unrecognized opcode `csrs sstatus,a5', extension `zicsr' required
Wed Oct 12 14:59:51 2022 +0200 broke: e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr issue)
Mon Dec 19 08:45:26 2022 -0500 broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 11.1.0 (gets further) broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0 (errors out sooner)
Maybe the fact that the gcc 11.1.0 u-boot binary boots our EFI loader consistently is just a fluke.
I know adding some printf statements into our efi bootloader changes the behavior and solves some memory access errors / Load Access Faults... so probably something with our memory layout?
-- Alex
On 1/4/23 16:34, Alex wrote:
Seeing a regression in functionality across multiple devices. I did a bit of bisecting, here's the path:
Thu May 5 19:37:22 2022 -0400 working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0 no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0 unrecognized opcode `csrs sstatus,a5', extension `zicsr' required
Wed Oct 12 14:59:51 2022 +0200 broke: e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr issue)
Mon Dec 19 08:45:26 2022 -0500 broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0
Mon Jan 2 09:36:13 2023 -0500 broke: 582e3c9fb2337c2f49faa73ac86dde25f4d56901 gcc 12.2.0
Working boots our EFI loader fine.
Broke boots see similar Load Access faults multiple platforms (qemu, unmatched, StarFive):
StarFive VisionFive 2:
SATP: 0x80000000000fbe03 Calling ExitBootServices. So long, EFI! clk u5_dw_i2c_clk_core already disabled clk u5_dw_i2c_clk_apb already disabled Unhandled exception: Load access fault EPC: 00000000fe6dc496 RA: 00000000fe6dc488 TVAL: 0000000000000000 EPC: 000000003e98e496 RA: 000000003e98e488 reloc adjusted
SP: 00000000ff73b868 GP: 0000000000000000 TP: 0000000000000001 T0: 00000000fbf28135 T1: 0000000000000008 T2: 0000000000000000 S0: 0000000000000021 S1: 0000000000000000 A0: 0000000000000021 A1: 0000000000000000 A2: 0000000000000001 A3: 00000000ff73b968 A4: 0000000000000001 A5: 00000000000001ff A6: 0000000000000020 A7: 000000000000000a S2: 00000000ff73b968 S3: ffffffc0020940c6 S4: 00000000fe713c80 S5: 00000000ff73be94 S6: 00000000ff73beb8 S7: 00000000ff73beb0 S8: 00000000ff73bea8 S9: 00000000ff73be98 S10: 00000000fe6fc288 S11: 00000000fe713c70 T3: 0000000074757074 T4: ffffffffffffffe8 T5: 0000000000000000 T6: 00000000fbf2810d
Code: 0b31 0793 1ff0 c763 02a7 842a 5863 00a0 (609c) UEFI image [0x00000000fe6d0000:0x00000000fe720fff] pc=0xc496 '/efi\boot\bootriscv64.efi'
My questions:
- Is GCC 12.2 known broken / unreliable for riscv64 builds of u-boot?
- Has anything else changed around memory management on riscv64 between
May 2022 and Oct 2022
-- Alex
Hello Alex,
I am not aware of a compiler problem.
The crash above occurs in bootriscv64.efi, not in U-Boot.
Analysis would require the code of that binary and instructions how to recreate the problem on QEMU.
Best regards
Heinrich
On 1/4/23 16:49, Heinrich Schuchardt wrote:
On 1/4/23 16:34, Alex wrote:
Seeing a regression in functionality across multiple devices. I did a bit of bisecting, here's the path:
Thu May 5 19:37:22 2022 -0400 working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0 no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0 unrecognized opcode `csrs sstatus,a5', extension `zicsr' required
Wed Oct 12 14:59:51 2022 +0200 broke: e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr issue)
Mon Dec 19 08:45:26 2022 -0500 broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0
Mon Jan 2 09:36:13 2023 -0500 broke: 582e3c9fb2337c2f49faa73ac86dde25f4d56901 gcc 12.2.0
Working boots our EFI loader fine.
Broke boots see similar Load Access faults multiple platforms (qemu, unmatched, StarFive):
StarFive VisionFive 2:
SATP: 0x80000000000fbe03 Calling ExitBootServices. So long, EFI! clk u5_dw_i2c_clk_core already disabled clk u5_dw_i2c_clk_apb already disabled Unhandled exception: Load access fault EPC: 00000000fe6dc496 RA: 00000000fe6dc488 TVAL: 0000000000000000 EPC: 000000003e98e496 RA: 000000003e98e488 reloc adjusted
SP: 00000000ff73b868 GP: 0000000000000000 TP: 0000000000000001 T0: 00000000fbf28135 T1: 0000000000000008 T2: 0000000000000000 S0: 0000000000000021 S1: 0000000000000000 A0: 0000000000000021 A1: 0000000000000000 A2: 0000000000000001 A3: 00000000ff73b968 A4: 0000000000000001 A5: 00000000000001ff A6: 0000000000000020 A7: 000000000000000a S2: 00000000ff73b968 S3: ffffffc0020940c6 S4: 00000000fe713c80 S5: 00000000ff73be94 S6: 00000000ff73beb8 S7: 00000000ff73beb0 S8: 00000000ff73bea8 S9: 00000000ff73be98 S10: 00000000fe6fc288 S11: 00000000fe713c70 T3: 0000000074757074 T4: ffffffffffffffe8 T5: 0000000000000000 T6: 00000000fbf2810d
Code: 0b31 0793 1ff0 c763 02a7 842a 5863 00a0 (609c) UEFI image [0x00000000fe6d0000:0x00000000fe720fff] pc=0xc496 '/efi\boot\bootriscv64.efi'
My questions:
- Is GCC 12.2 known broken / unreliable for riscv64 builds of u-boot?
- Has anything else changed around memory management on riscv64 between
May 2022 and Oct 2022
-- Alex
Hello Alex,
I am not aware of a compiler problem.
The crash above occurs in bootriscv64.efi, not in U-Boot.
Analysis would require the code of that binary and instructions how to recreate the problem on QEMU.
Best regards
Heinrich
Analysis of Haiku's efi.map file together with Alex showed that the problem related to calling Haiku's vprintf() function after ExitBootServices() which tries to invoke U-Boot's Simple Text Output Protocol which is illegal after ExitBootServices().
Best regards
Heinrich
participants (3)
-
Alex -
Alexander von Gluck IV
-
Heinrich Schuchardt