7f8afe0631
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>
10 lines
300 B
Makefile
10 lines
300 B
Makefile
ramstage-y += lapic.c
|
|
ramstage-y += lapic_cpu_init.c
|
|
ramstage-y += secondary.S
|
|
romstage-$(CONFIG_UDELAY_LAPIC) += apic_timer.c
|
|
ramstage-$(CONFIG_UDELAY_LAPIC) += apic_timer.c
|
|
bootblock-y += boot_cpu.c
|
|
verstage-y += boot_cpu.c
|
|
romstage-y += boot_cpu.c
|
|
ramstage-y += boot_cpu.c
|
|
postcar-y += boot_cpu.c
|