On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson tpearson@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@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