summaryrefslogtreecommitdiff
path: root/src/arch/x86/include
diff options
context:
space:
mode:
authorAaron Durbin <adurbin@chromium.org>2016-03-18 12:21:23 -0500
committerAaron Durbin <adurbin@chromium.org>2016-03-23 14:24:30 +0100
commit7f8afe063139f6fc7076a3e4edf6093a953792dc (patch)
treeb7d0c8d6372abe5b96bc37068e3e132ab97b8ea7 /src/arch/x86/include
parent2b239485358ec063a4803f248c88378076810e24 (diff)
arch/x86: introduce postcar stage/phase
Certain chipsets don't have a memory-mapped boot media so their code execution for stages prior to DRAM initialization is backed by SRAM or cache-as-ram. The postcar stage/phase handles the cache-as-ram situation where in order to tear down cache-as-ram one needs to be executing out of a backing store that isn't transient. By current definition, cache-as-ram is volatile and tearing it down leads to its contents disappearing. Therefore provide a shim layer, postcar, that's loaded into memory and executed which does 2 things: 1. Tears down cache-as-ram with a chipset helper function. 2. Loads and runs ramstage. Because those 2 things are executed out of ram there's no issue of the code's backing store while executing the code that tears down cache-as-ram. The current implementation makes no assumption regarding cacheability of the DRAM itself. If the chipset code wishes to cache DRAM for loading of the postcar stage/phase then it's also up to the chipset to handle any coherency issues pertaining to cache-as-ram destruction. Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
Diffstat (limited to 'src/arch/x86/include')
-rw-r--r--src/arch/x86/include/arch/cpu.h37
1 files changed, 37 insertions, 0 deletions
diff --git a/src/arch/x86/include/arch/cpu.h b/src/arch/x86/include/arch/cpu.h
index f50901fe73..5c26bcf74d 100644
--- a/src/arch/x86/include/arch/cpu.h
+++ b/src/arch/x86/include/arch/cpu.h
@@ -15,6 +15,7 @@
#define ARCH_CPU_H
#include <stdint.h>
+#include <stddef.h>
#include <rules.h>
/*
@@ -246,6 +247,42 @@ static inline void get_fms(struct cpuinfo_x86 *c, uint32_t tfms)
* cache-as-ram.
*/
void asmlinkage car_stage_entry(void);
+
+/*
+ * Support setting up a stack frame consisting of MTRR information
+ * for use in bootstrapping the caching attributes after cache-as-ram
+ * is torn down.
+ */
+
+struct postcar_frame {
+ uintptr_t stack;
+ uint32_t upper_mask;
+ int max_var_mttrs;
+ int num_var_mttrs;
+};
+
+/*
+ * Initialize postcar_frame object allocating stack size in cbmem
+ * with the provided size. Returns 0 on success, < 0 on error.
+ */
+int postcar_frame_init(struct postcar_frame *pcf, size_t stack_size);
+
+/*
+ * Add variable MTRR covering the provided range with MTRR type.
+ */
+void postcar_frame_add_mtrr(struct postcar_frame *pcf,
+ uintptr_t addr, size_t size, int type);
+
+/*
+ * Load and run a program that takes control of execution that
+ * tears down CAR and loads ramstage. The postcar_frame object
+ * indicates how to set up the frame. If caching is enabled at
+ * the time of the call it is up to the platform code to handle
+ * coherency with dirty lines in the cache using some mechansim
+ * such as platform_prog_run() because run_postcar_phase()
+ * utilizes prog_run() internally.
+ */
+void run_postcar_phase(struct postcar_frame *pcf);
#endif
#endif /* ARCH_CPU_H */