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