coreboot-kgpe-d16/src/vendorcode/amd
Konstantin Aladyshev 7fcbbb09fd AGESA: Fix bug in AMD_DISABLE_STACK_FAMILY_HOOK_F15
_RDMSR instruction loads the contents of a 64-bit model specific register (MSR)
specified in the ECX register into registers EDX:EAX.
The EDX register is loaded with the high-order 32 bits of the MSR
and the EAX register is loaded with the low-order 32 bits.

EDX:EAX = MSR[ECX]

So bit 49 will be contained in EDX register.

Buggy code instead of bit 49 (CombineCr0Cd) sets bit [49-32=17] (PfcStrideDis).
PfcStrideDis bit disables stride prefetch generation. This leads to memory
bandwidth loss.

_________

Supermicro H8QGI board

After applying this change i observed huge memory bandwidth increase in tests
that runs on small amount of cores. But unfortunately it doesn't affect
overall bandwidth results on 4P system with 48 cores.
So i think that in this system leading limiting factor is
AMD HT-ASSIST feature (Probe filter).

But right now it is not working. System stucks in Linux boot. I have done
some experiments and figured out that stuck happens when system have cores in
compute unit (CU) other than CU with BSC (boot strap core).
CU is two cores (primary and seconary) that shares some things (L2 cache, FPU ...)
So with probe filter i can boot Linux with one (BSC)
or two (BSC + secondary core in its CU) cores.
And with this configuration i can see memory bandwidth on 1 core (or two cores)
close to original bios.

Change-Id: I5a95f5b753d600c70d3c93d36fecc687610c61cd
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2588
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-08 07:25:15 +01:00
..
agesa AGESA: Fix bug in AMD_DISABLE_STACK_FAMILY_HOOK_F15 2013-03-08 07:25:15 +01:00
cimx GPLv2 notice: Unify all files to just use one space in »MA 02110-1301« 2013-03-01 10:16:08 +01:00
Makefile.inc Change AMD vendorcode build 2011-12-02 08:59:26 +01:00