summaryrefslogtreecommitdiff
path: root/src/arch/x86/exit_car.S
AgeCommit message (Collapse)Author
2020-03-06src/arch/x86: Convert to SPDX license headerPatrick Georgi
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>
2019-11-03arch/x86: Use the stage argument to implement cbmem_topArthur Heymans
Currently all stages that need cbmem need an implementation of a cbmem_top function. On FSP and AGESA platforms this proves to be painful and a pointer to the top of lower memory if often passed via lower memory (e.g. EBDA) or via a PCI scratchpad register. The problem with writing to lower memory is that also need to be written on S3 as one cannot assume it to be still there. Writing things on S3 is always a fragile thing to do. A very generic solution is to pass cbmem_top via the program argument. It should be possible to implement this solution on every architecture. Instead trying to figure out which files can be removed from stages and which cbmem_top implementations need with preprocessor, rename all cbmem_top implementation to cbmem_top_romstage. TESTED on qemu-x86. Change-Id: I6d5a366d6f1bc76f26d459628237e6b2c8ae03ea Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36144 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2019-09-10AUTHORS: Move src/arch/x86 copyrights into AUTHORS fileMartin Roth
As discussed on the mailing list and voted upon, the coreboot project is going to move the majority of copyrights out of the headers and into an AUTHORS file. This will happen a bit at a time, as we'll be unifying license headers at the same time. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ifd4329905847d9dd06de67b9a443c8ee50c0e7a7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/35177 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-08coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner
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>
2018-05-03arch/x86: Relocate GDT in verstage, romstage, and postcarHannah Williams
In each stage keep GDT in the code region. This accommodates platforms, such as glk, that are executing out of CAR. The gdt is small and loading it is trivial so just do it unconditionally instead of introducing another Kconfig. BUG=b:78656686 Change-Id: I01ded6e9b358b23e04d92bef5263bfe8c2a5ec5a Signed-off-by: Hannah Williams <hannah.williams@intel.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/25895 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Justin TerAvest <teravest@chromium.org>
2017-06-29arch/x86: update assembly to ensure 16-byte alignment into CAaron Durbin
When the C compiler expects 16-byte alignment of the stack it is at the call instruction. Correct existing call points from assembly to ensure the stacks are aligned to 16 bytes at the call instruction. Change-Id: Icadd7a1f9284e92aecd99c30cb2acb307823682c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/20314 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-12-21soc/intel/apollolake: allow ApolloLake SoC to use FSP CAR InitBrenton Dong
FSP v2.0 Driver supports TempRamInit & TempRamExit APIs to initialize & tear down Cache-As-Ram. Add TempRamInit & TempRamExit usage to ApolloLake SoC when CONFIG_FSP_CAR is enabled. Verified on Intel Leaf Hill CRB and confirmed that Cache-As-Ram is correctly set up and torn down using the FSP v2.0 APIs without coreboot implementation of CAR init/teardown. Change-Id: Ifd6fe8398ea147a5fb8c60076b93205bb94b1f25 Signed-off-by: Brenton Dong <brenton.m.dong@intel.com> Reviewed-on: https://review.coreboot.org/17063 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-09-19arch/x86: move postcar main logic into CAaron Durbin
The console_init(), MTRR printing, and loading ramstage logic was previously all in assembly. Move that logic into C code so that future features can more easily be added into the postcar boot flow. BUG=chrome-os-partner:57513 Change-Id: I332140f569caf0803570fd635d894295de8c0018 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16618 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-01arch/x86: Enable postcar consoleLee Leahy
Add a Kconfig value to enable the console during postcar. Add a call to console_init at the beginning of the postcar stage in exit_car.S. TEST=Build and run on Galileo Gen2 Change-Id: I66e2ec83344129ede2c7d6e5627c8062e28f50ad Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/16001 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-01arch/x86: Display MTRRs after MTRR update in postcarLee Leahy
Display the MTRRs after they have been updated during the postcar stage. TEST=Build and run on Galileo Gen2 Change-Id: I1532250cacd363c1eeaf72edc6cb9e9268a11375 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15991 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-27arch/x86: Add bootblock and postcar support for SOC MTRR accessLee Leahy
Quark does not support the rdmsr and wrmsr instructions. Use SOC specific routines to configure the MTRRs on Quark based platforms. Add cpu_common.c as a build dependency to provide access to the routine cpu_phys_address_size. TEST=Build and run on Galileo Gen2 Change-Id: I43b7067c66c5c55b42097937e862078adf17fb19 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15846 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-03-23arch/x86: introduce postcar stage/phaseAaron Durbin
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>