New patch to review for coreboot: a40d098 haswell: include TSEG region in cacheable memory

[Stefan Reinauer]

Stefan Reinauer ([e-mail]) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2690

-gerrit

commit a40d0983aaa1e958178024597a372378d2123342
Author: Aaron Durbin 
Date:   Fri Dec 21 21:22:07 2012 -0600

haswell: include TSEG region in cacheable memory

The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG
    region is setup as cacheable through the MTTRs, accesses to the TSEG
    region before SMM relocation are cached. This allows for the setup of
    SMM relocation to be faster by caching accesses to the future TSEG
    (SMRAM) memory.

MC MAP: TOM: 0x140000000
    MC MAP: TOUUD: 0x18f600000
    MC MAP: MESEG_BASE: 0x13f000000
    MC MAP: MESEG_LIMIT: 0x7fff0fffff
    MC MAP: REMAP_BASE: 0x13f000000
    MC MAP: REMAP_LIMIT: 0x18f5fffff
    MC MAP: TOLUD: 0xafa00000
    MC MAP: BGSM: 0xad800000
    MC MAP: BDSM: 0xada00000
    MC MAP: TESGMB: 0xad000000
    MC MAP: GGC: 0x209

TSEG->BGSM:
       PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4
    BGSM->TOLUD:
       PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5

Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
    Setting variable MTRR 1, base: 2048MB, range:  512MB, type WB
    Setting variable MTRR 2, base: 2560MB, range:  256MB, type WB
    Adding hole at 2776MB-2816MB
    Setting variable MTRR 3, base: 2776MB, range:    8MB, type UC
    Setting variable MTRR 4, base: 2784MB, range:   32MB, type UC
    Zero-sized MTRR range @0KB
     Allocate an msr - basek = 00400000, sizek = 0023d800,
    Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB
    Setting variable MTRR 6, base: 6144MB, range:  256MB, type WB
    Adding hole at 6390MB-6400MB
    Setting variable MTRR 7, base: 6390MB, range:    2MB, type UC

MTRR translation from MB to addresses:

MTRR 0: 0x00000000 -> 0x80000000 WB
    MTRR 1: 0x80000000 -> 0xa0000000 WB
    MTRR 2: 0xa0000000 -> 0xb0000000 WB
    MTRR 3: 0xad800000 -> 0xae000000 UC
    MTRR 4: 0xae000000 -> 0xb0000000 UC

I'm not a fan of the marking physical address space with MTRRs as being
    UC which is PCI space, but it is technically correct.

Lastly, drop a comment describing AP startup flow through coreboot.

Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182
    Signed-off-by: Aaron Durbin 
---
 src/northbridge/intel/haswell/northbridge.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/northbridge/intel/haswell/northbridge.c b/src/northbridge/intel/haswell/northbridge.c
index d6869c1..55c9c6b 100644
--- a/src/northbridge/intel/haswell/northbridge.c
+++ b/src/northbridge/intel/haswell/northbridge.c
@@ -340,7 +340,8 @@ static void mc_add_dram_resources(device_t dev)
     *       cacheable and reserved
     * - SMM_DEFAULT_BASE + SMM_DEFAULT_SIZE -> 0xa0000 : cacheable
     * - 0xc0000 -> TSEG : cacheable
-	 * - TESG -> TOLUD: not cacheable with standard MTRRs and reserved
+	 * - TESG -> BGSM: cacheable with standard MTRRs and reserved
+	 * - BGSM -> TOLUD: not cacheable with standard MTRRs and reserved
     * - 4GiB -> TOUUD: cacheable
     *
     * The default SMRAM space is reserved so that the range doesn't
@@ -354,6 +355,10 @@ static void mc_add_dram_resources(device_t dev)
     * is not omitted the mtrr code will setup the area as cacheable
     * causing VGA access to not work.
     *
+	 * The TSEG region is mapped as cacheable so that one can perform
+	 * SMRAM relocation faster. Once the SMRR is enabled the SMRR takes
+	 * precedence over the existing MTRRs covering this region.
+	 *
     * It should be noted that cacheable entry types need to be added in
     * order. The reason is that the current MTRR code assumes this and
     * falls over itself if it isn't.
@@ -386,9 +391,17 @@ static void mc_add_dram_resources(device_t dev)
    size_k = (unsigned long)(mc_values[TSEG_REG] >> 10) - base_k;
    ram_resource(dev, index++, base_k, size_k);

-	/* TSEG -> TOLUD */
+	/* TSEG -> BGSM */
    resource = new_resource(dev, index++);
    resource->base = mc_values[TSEG_REG];
+	resource->size = mc_values[BGSM_REG] - resource->base;
+	resource->flags = IORESOURCE_MEM | IORESOURCE_FIXED |
+	                  IORESOURCE_STORED | IORESOURCE_RESERVE |
+	                  IORESOURCE_ASSIGNED | IORESOURCE_CACHEABLE;
+
+	/* BGSM -> TOLUD */
+	resource = new_resource(dev, index++);
+	resource->base = mc_values[BGSM_REG];
    resource->size = mc_values[TOLUD_REG] - resource->base;
    resource->flags = IORESOURCE_MEM | IORESOURCE_FIXED |
                      IORESOURCE_STORED | IORESOURCE_RESERVE |
@@ -580,6 +593,15 @@ static const struct pci_driver mc_driver_hsw_ult __pci_driver = {

static void cpu_bus_init(device_t dev)
 {
+	/*
+	 * This calls into the gerneic initialize_cpus() which attempts to
+	 * start APs on the APIC bus in the devicetree.  No APs get started
+	 * because there is only the BSP and placeholder (disabled) in the
+	 * devicetree. initialize_cpus() also does SMM initialization by way
+	 * of smm_init(). It will eventually call cpu_initialize(0) which calls
+	 * dev_ops->init(). For Haswell the dev_ops->init() starts up the APs
+	 * by way of intel_cores_init().
+	 */
    initialize_cpus(dev->link_list);
 }