[commit] r6591 - trunk/src/mainboard/amd/persimmon

[repository service]

Author: mjones
Date: Mon May 16 00:06:09 2011
New Revision: 6591
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6591

Log:
Enable rom cache early to reduce boot time.

Signed-off-by: Scott Duplichan 
Acked-by: Marc Jones

Modified:
   trunk/src/mainboard/amd/persimmon/agesawrapper.c
   trunk/src/mainboard/amd/persimmon/romstage.c

Modified: trunk/src/mainboard/amd/persimmon/agesawrapper.c
==============================================================================
--- trunk/src/mainboard/amd/persimmon/agesawrapper.c	Mon May 16 00:05:00 2011	(r6590)
+++ trunk/src/mainboard/amd/persimmon/agesawrapper.c	Mon May 16 00:06:09 2011	(r6591)
@@ -157,13 +157,6 @@
   PciData = (AMD_APU_SSID<<0x10)|AMD_APU_SVID;
   LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader);

-
-  /* Set ROM cache onto WP to decrease post time */
-  MsrReg = (0x0100000000 - CONFIG_ROM_SIZE) | 5;
-  LibAmdMsrWrite (0x20C, &MsrReg, &StdHeader);
-  MsrReg = (0x1000000000 - CONFIG_ROM_SIZE) | 0x800;
-  LibAmdMsrWrite (0x20D, &MsrReg, &StdHeader);
-
   Status = AGESA_SUCCESS;
   return (UINT32)Status;
 }

Modified: trunk/src/mainboard/amd/persimmon/romstage.c
==============================================================================
--- trunk/src/mainboard/amd/persimmon/romstage.c	Mon May 16 00:05:00 2011	(r6590)
+++ trunk/src/mainboard/amd/persimmon/romstage.c	Mon May 16 00:06:09 2011	(r6591)
@@ -47,6 +47,11 @@
   u32 val;
   u8 reg8;

+  // all cores: allow caching of flash chip code and data
+  // (there are no cache-as-ram reliability concerns with family 14h)
+  __writemsr (0x20c, (0x0100000000ull - CONFIG_ROM_SIZE) | 5);
+  __writemsr (0x20d, (0x1000000000ull - CONFIG_ROM_SIZE) | 0x800);
+
   // all cores: set pstate 0 (1600 MHz) early to save a few ms of boot time
   __writemsr (0xc0010062, 0);

[Peter Stuge]

repository service wrote:
> Log:
> Enable rom cache early to reduce boot time.
> +++ trunk/src/mainboard/amd/persimmon/romstage.c	Mon May 16 00:06:09 2011	(r6591)
> @@ -47,6 +47,11 @@
>    u32 val;
>    u8 reg8;
> // all cores: allow caching of flash chip code and data
> // (there are no cache-as-ram reliability concerns with family 14h)
> __writemsr (0x20c, (0x0100000000ull - CONFIG_ROM_SIZE) | 5);
> __writemsr (0x20d, (0x1000000000ull - CONFIG_ROM_SIZE) | 0x800);

Is this something that we should have in component code rather than
mainboard code?

And when would it be suitable to *not* allow caching, if ever? I'm
thinking if this should be an option anywhere, or not.

//Peter

[Stefan Reinauer]

On 5/15/11 4:52 PM, Peter Stuge wrote:
> repository service wrote:
> > Log:
> > Enable rom cache early to reduce boot time.
> > +++ trunk/src/mainboard/amd/persimmon/romstage.c	Mon May 16 00:06:09 2011	(r6591)
> > @@ -47,6 +47,11 @@
> >     u32 val;
> >     u8 reg8;
> > // all cores: allow caching of flash chip code and data
> > // (there are no cache-as-ram reliability concerns with family 14h)
> > __writemsr (0x20c, (0x0100000000ull - CONFIG_ROM_SIZE) | 5);
> > __writemsr (0x20d, (0x1000000000ull - CONFIG_ROM_SIZE) | 0x800);
>
> Is this something that we should have in component code rather than
> mainboard code?
>
> And when would it be suitable to *not* allow caching, if ever? I'm
> thinking if this should be an option anywhere, or not.

Yes, I think this should be added to the cache as ram code instead.

[Scott Duplichan]

Stefan Reinauer wrote:

]>> +  // all cores: allow caching of flash chip code and data
]>> +  // (there are no cache-as-ram reliability concerns with family 14h)
]>> +  __writemsr (0x20c, (0x0100000000ull - CONFIG_ROM_SIZE) | 5);
]>> +  __writemsr (0x20d, (0x1000000000ull - CONFIG_ROM_SIZE) | 0x800);
]> Is this something that we should have in component code rather than
]> mainboard code?
]>
]> And when would it be suitable to *not* allow caching, if ever? I'm
]> thinking if this should be an option anywhere, or not.

Hello Peter,
This is a good question. For amd family 14h, caching of the flash chip
is appropriate at all times (though we could remove it before OS launch
to free an MTRR pair).

The situation on family 10h is different. For family 10h, cached rom code
goes into L1, and then into L2 also. Because L2 is used for cache as
ram, excessive instruction caching can cause cache as ram failure.
For family 10h, agesa code provides an AllocateExecutionCache function
that limits instruction caching to a safe amount if too much is requested.
The function does not clear cache before enabling it, so the rule is
no instruction caching before calling AllocateExecutionCache.

For family 14h (and also 15h), rom code is cached in L1 only. This solves
the problem of rom chip caching causing cache as ram problems. It is 
important to use attribute WP when caching the rom chip, because that
is what causes the new L1-only behavior to be invoked.

Note that family 12h (Llano) has the family 10h behavior.

]Yes, I think this should be added to the cache as ram code instead.

Hello Stefan,

The code already exists in agesa function AllocateExecutionCache. The
early code is an attempt reduce boot time. In the past, I found systems
with many cores are where early cache enable really helps. Agesa and
some BIOS launch the cores serially, and launching 48 cores could take
significantly longer without the early cache enable. Even if cores 
are launched in parallel, uncached flash memory reads could cause a
flood of requests to the flash chip.

Thanks,
Scott