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>
diff --git a/src/vendorcode/amd/agesa/f15/gcccar.inc b/src/vendorcode/amd/agesa/f15/gcccar.inc
index 423d404..3627da6 100644
--- a/src/vendorcode/amd/agesa/f15/gcccar.inc
+++ b/src/vendorcode/amd/agesa/f15/gcccar.inc
@@ -1004,7 +1004,7 @@
mov $CU_CFG3, %ecx # MSR:C001_102B
_RDMSR
- bts $(COMBINE_CR0_CD - 32), %eax # Set CombineCr0Cd bit
+ bts $(COMBINE_CR0_CD - 32), %edx # Set CombineCr0Cd bit
_WRMSR
fam15_disable_stack_hook_exit: