GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/arch/x86/postcar_loader.c

236 lines
5.8 KiB
C
Raw Normal View History

src/arch/x86: Convert to SPDX license header This also drops individual copyright notices, all mentioned authors in that part of the tree are listed in AUTHORS. Change-Id: Ib5a92bb46ff2b9d2928aae3763daec71747044c2 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39284 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-03-04 15:10:45 +01:00
/* SPDX-License-Identifier: GPL-2.0-only */
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>
2016-03-18 18:21:23 +01:00
arch/x86: Add <arch/romstage.h> Start with moving all postcar_frame related function declarations here from <arch/cpu.h>. Change-Id: I9aeef07f9009e44cc08927c85fe1862edf5c70dc Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34911 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-16 19:34:25 +02:00
#include <arch/romstage.h>
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>
2016-03-18 18:21:23 +01:00
#include <cbmem.h>
#include <console/console.h>
CPU: Declare cpu_phys_address_size() for all arch Resource allocator and 64-bit PCI BARs will need it and PCI use is not really restricted to x86. Change-Id: Ie97f0f73380118f43ec6271aed5617d62a4f5532 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17733 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-06 13:00:05 +01:00
#include <cpu/cpu.h>
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>
2016-03-18 18:21:23 +01:00
#include <cpu/x86/msr.h>
#include <cpu/x86/mtrr.h>
arch/x86: Cache the TSEG region at the top of ram This patch adds new API for enabling caching for the TSEG region and setting up required MTRR for next stage. BUG=b:140008206 TEST=Build and boot CML-Hatch. Change-Id: I59432c02e04af1b931d77de3f6652b0327ca82bb Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34995 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2019-08-22 08:00:52 +02:00
#include <cpu/x86/smm.h>
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>
2016-03-18 18:21:23 +01:00
#include <program_loading.h>
arch/x86,soc/intel: Drop RESET_ON_INVALID_RAMSTAGE_CACHE If stage cache is enabled, we should not allow S3 resume to load firmware from non-volatile memory. This also adds board reset for failing to load postcar from stage cache. Change-Id: Ib6cc7ad0fe9dcdf05b814d324b680968a2870f23 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37682 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-12-18 18:40:48 +01:00
#include <reset.h>
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>
2016-03-18 18:21:23 +01:00
#include <rmodule.h>
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
#include <romstage_handoff.h>
#include <stage_cache.h>
prog_loader: Associate TS_END_ROMSTAGE timestamp with postcar if exist This patch adds timestamp for "end of romstage" with postcar if platform has selected postcar as dedicated stage. If postcar stage doesn't exist then "end of romstage" timestamp will get call while starting of ramstage as exist today. TEST=It's been observed that "end of romstage" timestamp doesn't appear in "cbmem -t" log when ramstage is not getting executed. As part of this fix "end of romstage" timestamp is showing in "cbmem -t" log on Intel platform where POSTCAR is a dedicated stage. Change-Id: I17fd89296354b66a5538f85737c79145232593d3 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31608 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-02-25 16:01:22 +01:00
#include <timestamp.h>
security/vboot: Removed vboot_prepare from vboot_locator When prog_locate() is called in the stage VBOOT is starting from and the image to be loaded is not the target image vboot_prepare() may be called too early. To prevent this vboot_prepare() is removed from the vboot_locator structure. This allows more control over the start of the vboot logic. To clarify the change the vboot_prepare() has been renamed to vboot_run_logic() and calls to initialize vboot have been added at the following places: postcar_loader: when VBOOT starts in ROMSTAGE romstage_loader: when VBOOT starts in BOOTBLOCK ramstage_loader: when VBOOT starts in ROMSTAGE BUG=N/A TEST=tested on facebook fbg1701 Change-Id: Id5e8fd78458c09dd3896bfd142bd49c2c3d686df Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36543 Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-01 10:22:22 +01:00
#include <security/vboot/vboot_common.h>
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>
2016-03-18 18:21:23 +01:00
static inline void stack_push(struct postcar_frame *pcf, uint32_t val)
{
uint32_t *ptr;
pcf->stack -= sizeof(val);
ptr = (void *)pcf->stack;
*ptr = val;
}
postcar_loader: Support LATE_CBMEM_INIT boards Create postcar_frame object without placing stack in CBMEM. This way same cache_as_ram.inc code can be used unmodified. Change-Id: Ic5ed404ce268ee881e9893dd434534231aa2bc88 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17700 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-02 18:47:07 +01:00
static void postcar_frame_prepare(struct postcar_frame *pcf)
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>
2016-03-18 18:21:23 +01:00
{
msr_t msr;
msr = rdmsr(MTRR_CAP_MSR);
postcar_loader: Support LATE_CBMEM_INIT boards Create postcar_frame object without placing stack in CBMEM. This way same cache_as_ram.inc code can be used unmodified. Change-Id: Ic5ed404ce268ee881e9893dd434534231aa2bc88 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17700 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-02 18:47:07 +01:00
pcf->upper_mask = (1 << (cpu_phys_address_size() - 32)) - 1;
arch/x86: Fix typo with MTRR Change-Id: I67a470c2c2a659d5355fdd0939d0572c1ff3e291 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/21519 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-09-12 09:36:49 +02:00
pcf->max_var_mtrrs = msr.lo & MTRR_CAP_VCNT;
pcf->num_var_mtrrs = 0;
postcar_loader: Support LATE_CBMEM_INIT boards Create postcar_frame object without placing stack in CBMEM. This way same cache_as_ram.inc code can be used unmodified. Change-Id: Ic5ed404ce268ee881e9893dd434534231aa2bc88 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17700 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-02 18:47:07 +01:00
}
int postcar_frame_init(struct postcar_frame *pcf, size_t stack_size)
{
void *stack;
arch/x86: Adjust size of postcar stack With VBOOT=y && VBOOT_MEASURED_BOOT=y message digest will be allocated from the stack and 1 KiB reserve used with the recent platforms was no longer sufficient. The comment of LZMA scratchpad consuming stack was obsolete for postcar, so these can be reduced to same 4 KiB. Change-Id: Iba1fb5bfad6946f316feac2d8c998a782142a56a Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33775 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2019-06-28 09:08:51 +02:00
/*
* Use default postcar stack size of 4 KiB. This value should
* not be decreased, because if mainboards use vboot, 1 KiB will
* not be enough anymore.
*/
if (stack_size == 0)
stack_size = 4 * KiB;
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>
2016-03-18 18:21:23 +01:00
stack = cbmem_add(CBMEM_ID_ROMSTAGE_RAM_STACK, stack_size);
if (stack == NULL) {
printk(BIOS_ERR, "Couldn't add %zd byte stack in cbmem.\n",
stack_size);
return -1;
}
postcar_loader: Support LATE_CBMEM_INIT boards Create postcar_frame object without placing stack in CBMEM. This way same cache_as_ram.inc code can be used unmodified. Change-Id: Ic5ed404ce268ee881e9893dd434534231aa2bc88 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17700 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-02 18:47:07 +01:00
postcar_frame_prepare(pcf);
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>
2016-03-18 18:21:23 +01:00
pcf->stack = (uintptr_t)stack;
pcf->stack += stack_size;
return 0;
}
void postcar_frame_add_mtrr(struct postcar_frame *pcf,
uintptr_t addr, size_t size, int type)
{
arch/x86: Utilize additional MTRRs in postcar_frame_add_mtrr In the current implementation of postcar_frame_add_mtrr, if provided size is bigger than the base address alignment, the alignment is considered as size and covered by the MTRRs ignoring the specified size. In this case the callee has to make sure that the provided size should be smaller or equal to the base address alignment boundary. To simplify this, utilize additonal MTRRs to cover the entire size specified. We reuse the code from cpu/x86/mtrr/mtrr.c. Change-Id: Ie2e88b596f43692169c7d4440b18498a72fcba11 Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16509 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-09-07 16:48:17 +02:00
/*
* Utilize additional MTRRs if the specified size is greater than the
* base address alignment.
*/
while (size != 0) {
uint32_t addr_lsb;
uint32_t size_msb;
uint32_t mtrr_size;
arch/x86: Fix typo with MTRR Change-Id: I67a470c2c2a659d5355fdd0939d0572c1ff3e291 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/21519 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-09-12 09:36:49 +02:00
if (pcf->num_var_mtrrs >= pcf->max_var_mtrrs) {
arch/x86: Utilize additional MTRRs in postcar_frame_add_mtrr In the current implementation of postcar_frame_add_mtrr, if provided size is bigger than the base address alignment, the alignment is considered as size and covered by the MTRRs ignoring the specified size. In this case the callee has to make sure that the provided size should be smaller or equal to the base address alignment boundary. To simplify this, utilize additonal MTRRs to cover the entire size specified. We reuse the code from cpu/x86/mtrr/mtrr.c. Change-Id: Ie2e88b596f43692169c7d4440b18498a72fcba11 Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16509 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-09-07 16:48:17 +02:00
printk(BIOS_ERR, "No more variable MTRRs: %d\n",
arch/x86: Fix typo with MTRR Change-Id: I67a470c2c2a659d5355fdd0939d0572c1ff3e291 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/21519 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-09-12 09:36:49 +02:00
pcf->max_var_mtrrs);
arch/x86: Utilize additional MTRRs in postcar_frame_add_mtrr In the current implementation of postcar_frame_add_mtrr, if provided size is bigger than the base address alignment, the alignment is considered as size and covered by the MTRRs ignoring the specified size. In this case the callee has to make sure that the provided size should be smaller or equal to the base address alignment boundary. To simplify this, utilize additonal MTRRs to cover the entire size specified. We reuse the code from cpu/x86/mtrr/mtrr.c. Change-Id: Ie2e88b596f43692169c7d4440b18498a72fcba11 Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16509 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-09-07 16:48:17 +02:00
return;
}
addr_lsb = fls(addr);
size_msb = fms(size);
/* All MTRR entries need to have their base aligned to the mask
* size. The maximum size is calculated by a function of the
* min base bit set and maximum size bit set. */
if (addr_lsb > size_msb)
mtrr_size = 1 << size_msb;
else
mtrr_size = 1 << addr_lsb;
printk(BIOS_DEBUG, "MTRR Range: Start=%lx End=%lx (Size %x)\n",
addr, addr + mtrr_size, mtrr_size);
stack_push(pcf, pcf->upper_mask);
stack_push(pcf, ~(mtrr_size - 1) | MTRR_PHYS_MASK_VALID);
stack_push(pcf, 0);
stack_push(pcf, addr | type);
arch/x86: Fix typo with MTRR Change-Id: I67a470c2c2a659d5355fdd0939d0572c1ff3e291 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/21519 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-09-12 09:36:49 +02:00
pcf->num_var_mtrrs++;
arch/x86: Utilize additional MTRRs in postcar_frame_add_mtrr In the current implementation of postcar_frame_add_mtrr, if provided size is bigger than the base address alignment, the alignment is considered as size and covered by the MTRRs ignoring the specified size. In this case the callee has to make sure that the provided size should be smaller or equal to the base address alignment boundary. To simplify this, utilize additonal MTRRs to cover the entire size specified. We reuse the code from cpu/x86/mtrr/mtrr.c. Change-Id: Ie2e88b596f43692169c7d4440b18498a72fcba11 Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16509 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-09-07 16:48:17 +02:00
size -= mtrr_size;
addr += mtrr_size;
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>
2016-03-18 18:21:23 +01:00
}
}
arch/x86: Introduce postcar_frame_add_romcache() Provide a common implementation to add an MTRR entry for memory- mapped boot ROMs. Change-Id: I9fabc6b87fb36dc3d970805eb804cd950b8849d4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/26577 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-27 14:32:27 +02:00
void postcar_frame_add_romcache(struct postcar_frame *pcf, int type)
{
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
if (!CONFIG(BOOT_DEVICE_MEMORY_MAPPED))
arch/x86: Introduce postcar_frame_add_romcache() Provide a common implementation to add an MTRR entry for memory- mapped boot ROMs. Change-Id: I9fabc6b87fb36dc3d970805eb804cd950b8849d4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/26577 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-27 14:32:27 +02:00
return;
postcar_frame_add_mtrr(pcf, CACHE_ROM_BASE, CACHE_ROM_SIZE, type);
}
arch/x86: unexpose postcar_frame_common_mtrrs() The only caller is contained within the postcar_loader compilation unit. Therefore, remove postcar_frame_common_mtrrs() from the global symbol namespace. Change-Id: I90d308669d13eb2bebf1eca4d47e3f3b4f178714 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41101 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-04-29 22:20:05 +02:00
static void postcar_frame_common_mtrrs(struct postcar_frame *pcf)
arch/x86: Add postcar_frame_common_mtrrs() As most platforms will share the subset of enabling both low RAM WB and high ROM WP MTRRs, provide them with a single function. Add possibility for the platform to skip these if required. Change-Id: Id1f8b7682035e654231f6133a42909a36e3e15a1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34809 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-09 10:41:15 +02:00
{
if (pcf->skip_common_mtrr)
return;
/* Cache the ROM as WP just below 4GiB. */
postcar_frame_add_romcache(pcf, MTRR_TYPE_WRPROT);
}
soc/intel: Use common romstage code This provides stack guards with checking and common entry into postcar. The code in cpu/intel/car/romstage.c is candidate for becoming architectural so function prototype is moved to <arch/romstage.h>. Change-Id: I4c5a9789e7cf3f7f49a4a33e21dac894320a9639 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34893 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-17 19:51:08 +02:00
/* prepare_and_run_postcar() determines the stack to use after
* cache-as-ram is torn down as well as the MTRR settings to use. */
void prepare_and_run_postcar(struct postcar_frame *pcf)
{
if (postcar_frame_init(pcf, 0))
die("Unable to initialize postcar frame.\n");
fill_postcar_frame(pcf);
postcar_frame_common_mtrrs(pcf);
run_postcar_phase(pcf);
/* We do not return here. */
}
arch/x86/postcar: unexpose postcar_commit_mtrrs() symbol postcar_commit_mtrrs() isn't used outside the postcar_loader compilation unit. Make it static to reduce API surface area. Additionally the return value was not being utilized. Modify the return type to be void to align with the current usage. Change-Id: If07f34467941d00de731489867e485cfff80ea63 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35130 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2019-08-28 04:22:40 +02:00
static void postcar_commit_mtrrs(struct postcar_frame *pcf)
arch/x86: Always compile postcar library in romstage postcar_loader.c has a useful library of funtions for setting up stack and MTRRs. Make it available in romstage irrespective of CONFIG_POSTCAR_STAGE for use in stack setup after Dram init. The final step of moving the used and max MTRRs on to stack is moved to a new function, that can be used outside of postcar phase. Change-Id: I322b12577d74268d03fe42a9744648763693cddd Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16331 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-26 17:38:50 +02:00
{
/*
* Place the number of used variable MTRRs on stack then max number
* of variable MTRRs supported in the system.
*/
arch/x86: Fix typo with MTRR Change-Id: I67a470c2c2a659d5355fdd0939d0572c1ff3e291 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/21519 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-09-12 09:36:49 +02:00
stack_push(pcf, pcf->num_var_mtrrs);
stack_push(pcf, pcf->max_var_mtrrs);
arch/x86: Always compile postcar library in romstage postcar_loader.c has a useful library of funtions for setting up stack and MTRRs. Make it available in romstage irrespective of CONFIG_POSTCAR_STAGE for use in stack setup after Dram init. The final step of moving the used and max MTRRs on to stack is moved to a new function, that can be used outside of postcar phase. Change-Id: I322b12577d74268d03fe42a9744648763693cddd Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16331 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-26 17:38:50 +02:00
}
arch/x86 postcar: Fix use with stage_cache Postcar failed when loading from stage_cache, if romstage did not pass same pcf->stack on normal and resume paths. Change-Id: I853afb1fbdb942fd671d89950911c850c96e3af3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21444 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-09-05 21:43:05 +02:00
static void finalize_load(uintptr_t *stack_top_ptr, uintptr_t stack_top)
{
*stack_top_ptr = stack_top;
/*
* Signal to rest of system that another update was made to the
* postcar program prior to running it.
*/
prog_segment_loaded((uintptr_t)stack_top_ptr, sizeof(uintptr_t),
SEG_FINAL);
}
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
static void load_postcar_cbfs(struct prog *prog, struct postcar_frame *pcf)
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>
2016-03-18 18:21:23 +01:00
{
struct rmod_stage_load rsl = {
.cbmem_id = CBMEM_ID_AFTER_CAR,
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
.prog = prog,
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>
2016-03-18 18:21:23 +01:00
};
security/vboot: Removed vboot_prepare from vboot_locator When prog_locate() is called in the stage VBOOT is starting from and the image to be loaded is not the target image vboot_prepare() may be called too early. To prevent this vboot_prepare() is removed from the vboot_locator structure. This allows more control over the start of the vboot logic. To clarify the change the vboot_prepare() has been renamed to vboot_run_logic() and calls to initialize vboot have been added at the following places: postcar_loader: when VBOOT starts in ROMSTAGE romstage_loader: when VBOOT starts in BOOTBLOCK ramstage_loader: when VBOOT starts in ROMSTAGE BUG=N/A TEST=tested on facebook fbg1701 Change-Id: Id5e8fd78458c09dd3896bfd142bd49c2c3d686df Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36543 Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-01 10:22:22 +01:00
vboot_run_logic();
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
if (prog_locate(prog))
post_code: add post code for failure to load next stage Add a new post code, POST_INVALID_ROM, used when coreboot fails to locate or validate a resource that is stored in ROM. BUG=b:124401932 BRANCH=sarien TEST=build coreboot for sarien and arcada platforms Change-Id: Ie6de6590595d8fcdc57ad156237fffa03d5ead38 Signed-off-by: Keith Short <keithshort@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32770 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2019-05-07 00:12:57 +02:00
die_with_post_code(POST_INVALID_ROM,
"Failed to locate after CAR program.\n");
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>
2016-03-18 18:21:23 +01:00
if (rmodule_stage_load(&rsl))
post_code: add post code for failure to load next stage Add a new post code, POST_INVALID_ROM, used when coreboot fails to locate or validate a resource that is stored in ROM. BUG=b:124401932 BRANCH=sarien TEST=build coreboot for sarien and arcada platforms Change-Id: Ie6de6590595d8fcdc57ad156237fffa03d5ead38 Signed-off-by: Keith Short <keithshort@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32770 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2019-05-07 00:12:57 +02:00
die_with_post_code(POST_INVALID_ROM,
"Failed to load after CAR program.\n");
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>
2016-03-18 18:21:23 +01:00
/* Set the stack pointer within parameters of the program loaded. */
if (rsl.params == NULL)
post_code: add post code for failure to load next stage Add a new post code, POST_INVALID_ROM, used when coreboot fails to locate or validate a resource that is stored in ROM. BUG=b:124401932 BRANCH=sarien TEST=build coreboot for sarien and arcada platforms Change-Id: Ie6de6590595d8fcdc57ad156237fffa03d5ead38 Signed-off-by: Keith Short <keithshort@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32770 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2019-05-07 00:12:57 +02:00
die_with_post_code(POST_INVALID_ROM,
"No parameters found in after CAR program.\n");
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>
2016-03-18 18:21:23 +01:00
arch/x86 postcar: Fix use with stage_cache Postcar failed when loading from stage_cache, if romstage did not pass same pcf->stack on normal and resume paths. Change-Id: I853afb1fbdb942fd671d89950911c850c96e3af3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21444 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-09-05 21:43:05 +02:00
finalize_load(rsl.params, pcf->stack);
arch/x86: notify the system when the postcar parameter was updated While rmodule_load() calls arch_segment_loaded() when it's done loading any pieces of code which further modify it, like changing parameters within the program itself, need to notify the rest of the system. Change-Id: Ia3374b58488120ba6279592a77d7f9c6217f1215 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14213 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-31 20:36:33 +02:00
stage_cache: Make empty inline function if CONFIG_NO_STAGE_CACHE enable This patch removes CONFIG_NO_STAGE_CACHE check from caller function and add empty inline function incase CONFIG_NO_STAGE_CACHE is enable. Change-Id: I8e10ef2d261f9b204cecbeae6f65fda037753534 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33394 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2019-06-11 14:22:06 +02:00
stage_cache_add(STAGE_POSTCAR, prog);
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
}
arch/x86: Cache the TSEG region at the top of ram This patch adds new API for enabling caching for the TSEG region and setting up required MTRR for next stage. BUG=b:140008206 TEST=Build and boot CML-Hatch. Change-Id: I59432c02e04af1b931d77de3f6652b0327ca82bb Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34995 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2019-08-22 08:00:52 +02:00
/*
* Cache the TSEG region at the top of ram. This region is
* not restricted to SMM mode until SMM has been relocated.
* By setting the region to cacheable it provides faster access
* when relocating the SMM handler as well as using the TSEG
* region for other purposes.
*/
void postcar_enable_tseg_cache(struct postcar_frame *pcf)
{
uintptr_t smm_base;
size_t smm_size;
smm_region(&smm_base, &smm_size);
postcar_frame_add_mtrr(pcf, smm_base, smm_size,
MTRR_TYPE_WRBACK);
}
arch/x86,soc/intel: Drop RESET_ON_INVALID_RAMSTAGE_CACHE If stage cache is enabled, we should not allow S3 resume to load firmware from non-volatile memory. This also adds board reset for failing to load postcar from stage cache. Change-Id: Ib6cc7ad0fe9dcdf05b814d324b680968a2870f23 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37682 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-12-18 18:40:48 +01:00
static void postcar_cache_invalid(void)
{
printk(BIOS_ERR, "postcar cache invalid.\n");
board_reset();
}
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
void run_postcar_phase(struct postcar_frame *pcf)
{
struct prog prog =
include/program_loading: Add POSTCAR prog type Now postcar is a standalone stage give it a proper type. Change-Id: Ifa6af9cf20aad27ca87a86817e6ad0a0d1de17c8 Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-on: https://review.coreboot.org/29545 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2018-11-08 10:39:39 +01:00
PROG_INIT(PROG_POSTCAR, CONFIG_CBFS_PREFIX "/postcar");
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
postcar_commit_mtrrs(pcf);
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
if (!CONFIG(NO_STAGE_CACHE) &&
arch/x86 postcar: Fix use with stage_cache Postcar failed when loading from stage_cache, if romstage did not pass same pcf->stack on normal and resume paths. Change-Id: I853afb1fbdb942fd671d89950911c850c96e3af3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21444 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-09-05 21:43:05 +02:00
romstage_handoff_is_resume()) {
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
stage_cache_load_stage(STAGE_POSTCAR, &prog);
arch/x86/postcar: add comment clarifying reason for finalize_load() Certain platforms need to pass different stack pointer values to postcar depending on S3 resume or not. Add comments to ease the reader in understanding the point. If different stack values weren't needed the program was already cached in stage cache with the correct value. Change-Id: I7202c62e6202a14416cb49ad5348740174747c7d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/25795 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Justin TerAvest <teravest@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2018-04-23 22:55:09 +02:00
/* This is here to allow platforms to pass different stack
parameters between S3 resume and normal boot. On the
platforms where the values are the same it's a nop. */
arch/x86 postcar: Fix use with stage_cache Postcar failed when loading from stage_cache, if romstage did not pass same pcf->stack on normal and resume paths. Change-Id: I853afb1fbdb942fd671d89950911c850c96e3af3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21444 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-09-05 21:43:05 +02:00
finalize_load(prog.arg, pcf->stack);
arch/x86,soc/intel: Drop RESET_ON_INVALID_RAMSTAGE_CACHE If stage cache is enabled, we should not allow S3 resume to load firmware from non-volatile memory. This also adds board reset for failing to load postcar from stage cache. Change-Id: Ib6cc7ad0fe9dcdf05b814d324b680968a2870f23 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37682 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-12-18 18:40:48 +01:00
if (prog_entry(&prog) == NULL)
postcar_cache_invalid();
arch/x86 postcar: Fix use with stage_cache Postcar failed when loading from stage_cache, if romstage did not pass same pcf->stack on normal and resume paths. Change-Id: I853afb1fbdb942fd671d89950911c850c96e3af3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21444 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-09-05 21:43:05 +02:00
} else
arch/x86: cache postcar in stage cache Stash and reload postcar stage in the stage cache for increased S3 resume speed. It's impact is small (2 ms or so), but there's no need to go to the boot media on resume to reload something that was already loaded. This aligns with the same paths we take on ramstage as well. Change-Id: I4313794826120853163c7366e81346858747ed0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17649 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29 22:52:08 +01:00
load_postcar_cbfs(&prog, pcf);
prog_loader: Associate TS_END_ROMSTAGE timestamp with postcar if exist This patch adds timestamp for "end of romstage" with postcar if platform has selected postcar as dedicated stage. If postcar stage doesn't exist then "end of romstage" timestamp will get call while starting of ramstage as exist today. TEST=It's been observed that "end of romstage" timestamp doesn't appear in "cbmem -t" log when ramstage is not getting executed. As part of this fix "end of romstage" timestamp is showing in "cbmem -t" log on Intel platform where POSTCAR is a dedicated stage. Change-Id: I17fd89296354b66a5538f85737c79145232593d3 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31608 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-02-25 16:01:22 +01:00
/* As postcar exist, it's end of romstage here */
timestamp_add_now(TS_END_ROMSTAGE);
console,boot_state: Exclude printk() from reported times Use monotonic timer to accumulate the time spent in console code. For bootblock and romstage, only stage total is reported. For ramstage each boot_state is reported individually. Change-Id: Id3998bab553ff803a93257a3f2c7bfea44c31729 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36574 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-11-02 13:12:18 +01:00
console_time_report();
Program loading: Handoff cbmem_top via calling arguments There are a lot of different implementations to pass information from romstage to ramstage. These could all be unified by passing this information via cbmem. Often however these methods exist for that very purpose. This solves this by passing cbmem_top via the programs arguments. Change-Id: Id2031f7bb81ce65fc318313c270eb1fbae3b2114 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36272 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-10-23 17:07:15 +02:00
prog_set_arg(&prog, cbmem_top());
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>
2016-03-18 18:21:23 +01:00
prog_run(&prog);
}
Reference in a new issue Copy permalink