Hi
There have been some reports of GCC11 not booting on some AGESA fam15 platforms and on Intel ironlake.
I confirmed that on my X201 (ironlake). The system hangs at an endless loop during heci init. The code generated doing that part is not wrong, which makes me think that other code in that 5k+ LOC file is incorrectly generated. Figuring out what is going on: whether that gcc revision is broken or our code is going to take some time. Clang (with some patches to get it to build) does result in a booting image btw. Also my fedora35 gcc11 has the same issue.
My initial approach for figuring out what function is incorrectly generated is to move them over in a separate file and replace the .o file with a gcc8 generated .o file. That approach will take some time for sure as there are a lot of functions in that 5K LOC file.
Another suggestion was to bisect gcc, which is more straightforward.
Any suggestions for a faster/better approach?
I'm suggesting reverting gcc while this issue is being sorted out. One issue with this however is that older GCC don't build anymore with my fedora gcc11 toolchain. However this can likely easily be fixed using docker. GCC 8.3 was the previous revision we used but there have been a lot of releases in between so those could be considered too.
Kind regards
Arthur
Hi
It looks like alignment on a packed struct being cast two times to different integers was the root cause for the ironlake platform. https://review.coreboot.org/c/coreboot/+/61938 fixed the issue.
Kind regards
On Mon, Feb 14, 2022 at 9:12 AM Arthur Heymans arthur@aheymans.xyz wrote:
Hi
There have been some reports of GCC11 not booting on some AGESA fam15 platforms and on Intel ironlake.
I confirmed that on my X201 (ironlake). The system hangs at an endless loop during heci init. The code generated doing that part is not wrong, which makes me think that other code in that 5k+ LOC file is incorrectly generated. Figuring out what is going on: whether that gcc revision is broken or our code is going to take some time. Clang (with some patches to get it to build) does result in a booting image btw. Also my fedora35 gcc11 has the same issue.
My initial approach for figuring out what function is incorrectly generated is to move them over in a separate file and replace the .o file with a gcc8 generated .o file. That approach will take some time for sure as there are a lot of functions in that 5K LOC file.
Another suggestion was to bisect gcc, which is more straightforward.
Any suggestions for a faster/better approach?
I'm suggesting reverting gcc while this issue is being sorted out. One issue with this however is that older GCC don't build anymore with my fedora gcc11 toolchain. However this can likely easily be fixed using docker. GCC 8.3 was the previous revision we used but there have been a lot of releases in between so those could be considered too.
Kind regards
Arthur
-
Arthur Heymans