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

140 lines
3 KiB
ArmAsm
Raw Normal View History

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
/*
* This file is part of the coreboot project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; version 2 of
* the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <cpu/x86/mtrr.h>
#include <cpu/x86/cr.h>
.section ".module_parameters", "aw", @progbits
/* stack_top indicates the stack to pull MTRR information from. */
soc/intel/apollolake: allow ApolloLake SoC to use FSP CAR Init 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-10-18 22:57:54 +02:00
.global post_car_stack_top
post_car_stack_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
.long 0
.long 0
.text
.global _start
_start:
arch/x86: update assembly to ensure 16-byte alignment into C 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>
2017-06-23 18:14:58 +02:00
/* Assume stack alignment doesn't matter here as chipset_teardown_car
is expected to be implemented in assembly. */
arch/x86: Relocate GDT in verstage, romstage, and postcar 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>
2018-04-27 18:09:04 +02:00
/* Migrate GDT to this text segment */
call gdt_init
arch/x86: Use the stage argument to implement cbmem_top 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-10-23 17:02:50 +02:00
#ifdef __x86_64__
mov %rdi, _cbmem_top_ptr
#else
/* The return argument is at 0(%esp), the calling argument at 4(%esp) */
movl 4(%esp), %eax
movl %eax, _cbmem_top_ptr
#endif
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
/* chipset_teardown_car() is expected to disable cache-as-ram. */
call chipset_teardown_car
/* Enable caching if not already enabled. */
mov %cr0, %eax
and $(~(CR0_CD | CR0_NW)), %eax
mov %eax, %cr0
/* Ensure cache is clean. */
invd
/* Set up new stack. */
soc/intel/apollolake: allow ApolloLake SoC to use FSP CAR Init 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-10-18 22:57:54 +02:00
mov post_car_stack_top, %esp
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
/*
* Honor variable MTRR information pushed on the stack with the
* following layout:
*
* Offset: Value
* ...
* 0x14: MTRR mask 0 63:32
* 0x10: MTRR mask 0 31:0
* 0x0c: MTRR base 0 63:32
* 0x08: MTRR base 0 31:0
* 0x04: Number of variable MTRRs to set
* 0x00: Number of variable MTRRs to clear
*/
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(SOC_SETS_MSRS)
arch/x86: update assembly to ensure 16-byte alignment into C 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>
2017-06-23 18:14:58 +02:00
mov %esp, %ebp
/* Need to align stack to 16 bytes at the call instruction. Therefore
account for the 1 push. */
andl $0xfffffff0, %esp
sub $12, %esp
push %ebp
arch/x86: Add bootblock and postcar support for SOC MTRR access 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-07-24 17:09:40 +02:00
call soc_set_mtrrs
arch/x86: update assembly to ensure 16-byte alignment into C 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>
2017-06-23 18:14:58 +02:00
/* Ignore fixing up %esp since we're setting it a new value. */
arch/x86: Add bootblock and postcar support for SOC MTRR access 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-07-24 17:09:40 +02:00
/* eax: new top_of_stack with setup_stack_and_mtrrs data removed */
movl %eax, %esp
arch/x86: update assembly to ensure 16-byte alignment into C 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>
2017-06-23 18:14:58 +02:00
/* Align stack to 16 bytes at call instruction. */
andl $0xfffffff0, %esp
arch/x86: Add bootblock and postcar support for SOC MTRR access 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-07-24 17:09:40 +02:00
call soc_enable_mtrrs
#else /* CONFIG_SOC_SETS_MSRS */
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
/* Clear variable MTRRs. */
pop %ebx /* Number to clear */
test %ebx, %ebx
jz 2f
xor %eax, %eax
xor %edx, %edx
mov $(MTRR_PHYS_BASE(0)), %ecx
1:
wrmsr
inc %ecx
wrmsr
inc %ecx
dec %ebx
jnz 1b
2:
/* Set Variable MTRRs based on stack contents. */
pop %ebx /* Number to set. */
test %ebx, %ebx
jz 2f
mov $(MTRR_PHYS_BASE(0)), %ecx
1:
/* Write MTRR base. */
pop %eax
pop %edx
wrmsr
inc %ecx
/* Write MTRR mask. */
pop %eax
pop %edx
wrmsr
inc %ecx
dec %ebx
jnz 1b
2:
/* Enable MTRR. */
mov $(MTRR_DEF_TYPE_MSR), %ecx
rdmsr
/* Make default type uncacheable. */
and $(~(MTRR_DEF_TYPE_MASK)), %eax
or $(MTRR_DEF_TYPE_EN), %eax
wrmsr
arch/x86: Add bootblock and postcar support for SOC MTRR access 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-07-24 17:09:40 +02:00
#endif /* CONFIG_SOC_SETS_MSRS */
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: update assembly to ensure 16-byte alignment into C 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>
2017-06-23 18:14:58 +02:00
/* Align stack to 16 bytes at call instruction. */
andl $0xfffffff0, %esp
arch/x86: move postcar main logic into C 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-09-16 23:15:14 +02:00
/* Call into main for postcar. */
call main
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
/* Should never return. */
1:
jmp 1b
Reference in a new issue Copy permalink