On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson <tpear...@raptorengineeringinc.com> wrote: > On 03/16/2015 09:23 AM, Aaron Durbin wrote: >> >> On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson >> <tpear...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot