Re: [coreboot] GCC update broke AMD Fam10h boot

[Timothy Pearson]

On 03/16/2015 09:23 AM, Aaron Durbin wrote:
> On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
>   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.

GCC update broke AMD Fam10h boot

[Aaron Durbin]

On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson
 wrote:
> On 03/16/2015 09:23 AM, Aaron Durbin wrote:
> > On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
> >   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
>