[coreboot] AMD cache setup is broken

Arne Georg Gleditsch arne.gleditsch at numascale.com
Thu Sep 9 10:01:49 CEST 2010

"Scott Duplichan" <scott at notabs.org> writes:
> I checked on real hardware, and family 10h msr c001_102a is not shared
> among cores on a die. I suppose it would be OK to do what you say. I 
> imagine that would minimize code changes.

As a minimal change, I did the following:

diff --git a/src/arch/i386/lib/cbfs_and_run.c b/src/arch/i386/lib/cbfs_and_run.c
index 1b86f56..2f90b0c 100644
--- a/src/arch/i386/lib/cbfs_and_run.c
+++ b/src/arch/i386/lib/cbfs_and_run.c
@@ -34,6 +34,12 @@ void cbfs_and_run_core(const char *filename, unsigned ebp)
+	__asm__ volatile (
+	    "rdmsr\n"
+	    "btr $15, %%eax\n"
+	    "wrmsr\n"
+	    :: "c"(0xc001102a) : "eax", "edx");
 	print_debug("Jumping to image.\n");
 	__asm__ volatile (
 		"movl %%eax, %%ebp\n"
diff --git a/src/northbridge/amd/amdmct/mct/mct_d.c b/src/northbridge/amd/amdmct/mct/mct_d.c
index 3693891..fd07fa5 100644
--- a/src/northbridge/amd/amdmct/mct/mct_d.c
+++ b/src/northbridge/amd/amdmct/mct/mct_d.c
@@ -3189,7 +3189,7 @@ static void mct_FinalMCT_D(struct MCTStatStruc *pMCTstat,
 	print_t("\tmct_FinalMCT_D: Clr Cl, Wb\n");
-	mct_ClrClToNB_D(pMCTstat, pDCTstat);
+//	mct_ClrClToNB_D(pMCTstat, pDCTstat);
 	mct_ClrWbEnhWsbDis_D(pMCTstat, pDCTstat);

I can confirm that this removes the earlier observed delays for me.
Obviously, this is AMD-specific code that needs to be hooked in in a
proper manner, but this definately seems to be the culprit.

> The alternative is to remove the two instances where ClLinesToNbDis is
> cleared early, and then clear it at some later time, before AP MSRs
> are synced to the BSP values.  I see the BKDG was finally updated to
> address this situation:

As far as I can see, this bit is cleared in the APs just before they are
stopped in the rom stage.  Aas they'r not in play again until well into
the ram stage, I'm assuming this is ok.  Pushing the ClrClToNB operation
in mct_d to after the BSP is done executing from rom should be
sufficient, and this seems to be confirmed by testing.


More information about the coreboot mailing list