[coreboot] GCC update broke AMD Fam10h boot

[Aaron Durbin]

On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson
<tpearson at raptorengineeringinc.com> wrote:
> On 03/16/2015 09:23 AM, Aaron Durbin wrote:
>>
>> On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
>> <tpearson at raptorengineeringinc.com>  wrote:
>>>
>>> All,
>>>
>>> Just a heads up as there is no bugtracker for this project.  GIT commit
>>> 53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2,
>>> breaks
>>> ramstage on AMD Fam10h systems (ramstage loads, sends its 0x39 POST code,
>>> but then goes into an infinite loop).  Downgrading the GCC version
>>> repairs
>>> the boot failure.
>>>
>>> Not sure if you want to revert that commit until someone can figure out
>>> what
>>> changed to cause the problem.
>>
>>
>> Could post ramstage.elf from the two different builds somewhere? I'd
>> like to take a peak at what is in there.
>
>
> Sure:
> https://raptorengineeringinc.com/coreboot/built.tar.bz2
>
> Other oddities:
> GCC 4.8.3:
> normal/romstage                0x7ff80    stage        97345
> normal/ramstage                0x97c40    stage        154869
>
> GCC 4.9.2:
> normal/romstage                0x7ff80    stage        94773
> normal/ramstage                0x97240    stage        173942
>
> Note in particular, judging from the file sizes, that something seems to
> have been relocated from romstage to ramstage by the new gcc version.
>

I noticed you had CONFIG_COVERAGE selected in both the builds. Could
you try not having that selected? I wonder if something changed in the
compiler on that front. But... I think I found a bigger issue.



$ nm ./gcc4.8.3/ramstage.debug | sort | grep -C 4 _bs_init_
00146fc4 r pch_intel_wifi
00146fd0 R cpu_drivers
00146fd0 R epci_drivers
00146fd0 r model_10xxx
00146fdc R _bs_init_begin
00146fdc r cbmem_bscb
00146fdc R ecpu_drivers
00146ff0 r gcov_bscb
0014702c R _bs_init_end
0014702c R pnp_conf_mode_870155_aa
00147034 R pnp_conf_mode_a0a0_aa
0014703c R pnp_conf_mode_8787_aa
00147044 R pnp_conf_mode_7777_aa

$ nm ./gcc4.9.2/ramstage.debug | sort | grep -C 4 _bs_init_
001465c4 r pch_intel_wifi
001465d0 R cpu_drivers
001465d0 R epci_drivers
001465d0 r model_10xxx
001465dc R _bs_init_begin
001465dc R ecpu_drivers
001465e0 r cbmem_bscb
00146600 r gcov_bscb
0014663c R _bs_init_end
00146640 R pnp_conf_mode_870155_aa
00146648 R pnp_conf_mode_a0a0_aa
00146650 R pnp_conf_mode_8787_aa
00146658 R pnp_conf_mode_7777_a

The boot state callbacks place the whole structure for each entry
between _bs_init_begin and _bs_init_end. For both binaries the size of
0x14.

For the 4.8.3 compiled ramstage I see:
(gdb) p/x 0x0014702c - 0x00146fdc
$12 = 0x50
For the 4.9.2 compiled ramstage I see:
(gdb) p/x 0x014663c - 0x01465dc
$14 = 0x60

0x60 is not a multiple of 0x14 -- which is means things aren't cool.

Looking at the symbols it appears the compiler is aligning those
structures to 32-bytes for some reason...

A quick hack is add ALIGN(32) to the linker script before
_bs_init_begin: src/arch/x86/ramstage.ld

But I think we'll need to store pointers to the structures in order to
properly handle the situation where the compiler is effectively making
alignment/size decisions for some reason.

-Aaron



>
> --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645
> http://www.raptorengineeringinc.com