coreboot-kgpe-d16/src/arch/arm64/transition.c

78 lines
2.1 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-only */
#include <arch/cache.h>
#include <arch/lib_helpers.h>
#include <arch/mmu.h>
#include <arch/transition.h>
#include <assert.h>
void __weak exc_dispatch(struct exc_state *exc_state, uint64_t id)
{
/* Default weak implementation does nothing. */
}
void exc_entry(struct exc_state *exc_state, uint64_t id)
{
struct elx_state *elx = &exc_state->elx;
struct regs *regs = &exc_state->regs;
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
uint8_t elx_mode;
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
elx->spsr = raw_read_spsr_el3();
elx_mode = get_mode_from_spsr(elx->spsr);
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
if (elx_mode == SPSR_USE_H)
regs->sp = (uint64_t)&exc_state[1];
else
regs->sp = raw_read_sp_el0();
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
elx->elr = raw_read_elr_el3();
exc_dispatch(exc_state, id);
}
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
void transition_to_el2(void *entry, void *arg, uint64_t spsr)
{
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
struct exc_state exc_state;
struct elx_state *elx = &exc_state.elx;
struct regs *regs = &exc_state.regs;
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
regs->x[X0_INDEX] = (uint64_t)arg;
elx->elr = (uint64_t)entry;
elx->spsr = spsr;
/*
* Policies enforced:
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
* 1. We support only transitions to EL2
* 2. We support transitions to Aarch64 mode only
*
* If any of the above conditions holds false, then we need a proper way
* to update SCR/HCR before removing the checks below
*/
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
assert(get_el_from_spsr(spsr) == EL2 && !(spsr & SPSR_ERET_32));
arm64: Correctly unmask asynchronous SError interrupts Arm CPUs have always had an odd feature that allows you to mask not only true interrupts, but also "external aborts" (memory bus errors from outside the CPU). CPUs usually have all of these masked after reset, which we quickly learned was a bad idea back when bringing up the first arm32 systems in coreboot. Masking external aborts means that if any of your firmware code does an illegal memory access, you will only see it once the kernel comes up and unmasks the abort (not when it happens). Therefore, we always unmask everything in early bootblock assembly code. When arm64 came around, it had very similar masking bits and we did the same there, thinking the issue resolved. Unfortunately Arm, in their ceaseless struggle for more complexity, decided that having a single bit to control this masking behavior is no longer enough: on AArch64, in addition to the PSTATE.DAIF bits that are analogous to arm32's CPSR, there are additional bits in SCR_EL3 that can override the PSTATE setting for some but not all cases (makes perfect sense, I know...). When aborts are unmasked in PSTATE, but SCR.EA is not set, then synchronous external aborts will cause an exception while asynchronous external aborts will not. It turns out we never intialize SCR in coreboot and on RK3399 it comes up with all zeroes (even the reserved-1 bits, which is super weird). If you get an asynchronous external abort in coreboot it will silently hide in the CPU until BL31 enables SCR.EA before it has its own console handlers registered and silently hangs. This patch resolves the issue by also initializing SCR to a known good state early in the bootblock. It also cleans up some bit defintions and slightly reworks the DAIF unmasking... it doesn't actually make that much sense to unmask anything before our console and exception handlers are up. The new code will mask everything until the exception handler is installed and then unmask it, so that if there was a super early external abort we could still see it. (Of course there are still dozens of other processor exceptions that could happen which we have no way to mask.) Change-Id: I5266481a7aaf0b72aca8988accb671d92739af6f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37463 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
2019-12-04 07:47:01 +01:00
/* Initialize SCR with defaults for running without secure monitor
(disable all traps, enable all instructions, run NS at AArch64). */
raw_write_scr_el3(SCR_FIEN | SCR_API | SCR_APK | SCR_ST | SCR_RW |
SCR_HCE | SCR_SMD | SCR_RES1 | SCR_NS);
/* Initialize CPTR to not trap anything to EL3. */
raw_write_cptr_el3(CPTR_EL3_TCPAC_DISABLE | CPTR_EL3_TTA_DISABLE |
CPTR_EL3_TFP_DISABLE);
arm64: Make SPSR exception masking on EL2 transition explicit The configuration of SPSR bits that mask processor exceptions is kinda oddly hidden as an implict part of the transition() function right now. It would be odd but not impossible for programs to want to be entered with enabled exceptions, so let's move these bits to be explicitly set by the caller like the rest of SPSR instead. Also clear up some macro names. The SPSR[I] bit is currently defined as SPSR_IRQ_ENABLE, which is particularly unfortunate since that bit actually *disables* (masks) interrupts. The fact that there is an additional SPSR_IRQ_MASK definition with the same value but a different purpose doesn't really help. There's rarely a point to have all three of xxx_SHIFT, xxx_MASK and xxx_VALUE macros for single-bit fields, so simplify this to a single definition per bit. (Other macros in lib_helpers.h should probably also be overhauled to conform, but I want to wait and see how many of them really stay relevant after upcoming changes first.) BRANCH=None BUG=None TEST=None Change-Id: Id126f70d365467e43b7f493c341542247e5026d2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 715600c83aef9794d1674e8c3b62469bdc57f297 Original-Change-Id: I3edc4ee276feb8610a636ec7b4175706505d58bd Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/270785 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10250 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-13 20:19:33 +02:00
/* ELR/SPSR: Write entry point and processor state of program */
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
raw_write_elr_el3(elx->elr);
raw_write_spsr_el3(elx->spsr);
arm64: Correctly unmask asynchronous SError interrupts Arm CPUs have always had an odd feature that allows you to mask not only true interrupts, but also "external aborts" (memory bus errors from outside the CPU). CPUs usually have all of these masked after reset, which we quickly learned was a bad idea back when bringing up the first arm32 systems in coreboot. Masking external aborts means that if any of your firmware code does an illegal memory access, you will only see it once the kernel comes up and unmasks the abort (not when it happens). Therefore, we always unmask everything in early bootblock assembly code. When arm64 came around, it had very similar masking bits and we did the same there, thinking the issue resolved. Unfortunately Arm, in their ceaseless struggle for more complexity, decided that having a single bit to control this masking behavior is no longer enough: on AArch64, in addition to the PSTATE.DAIF bits that are analogous to arm32's CPSR, there are additional bits in SCR_EL3 that can override the PSTATE setting for some but not all cases (makes perfect sense, I know...). When aborts are unmasked in PSTATE, but SCR.EA is not set, then synchronous external aborts will cause an exception while asynchronous external aborts will not. It turns out we never intialize SCR in coreboot and on RK3399 it comes up with all zeroes (even the reserved-1 bits, which is super weird). If you get an asynchronous external abort in coreboot it will silently hide in the CPU until BL31 enables SCR.EA before it has its own console handlers registered and silently hangs. This patch resolves the issue by also initializing SCR to a known good state early in the bootblock. It also cleans up some bit defintions and slightly reworks the DAIF unmasking... it doesn't actually make that much sense to unmask anything before our console and exception handlers are up. The new code will mask everything until the exception handler is installed and then unmask it, so that if there was a super early external abort we could still see it. (Of course there are still dozens of other processor exceptions that could happen which we have no way to mask.) Change-Id: I5266481a7aaf0b72aca8988accb671d92739af6f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37463 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
2019-12-04 07:47:01 +01:00
/* SCTLR: Initialize EL with everything disabled */
raw_write_sctlr_el2(SCTLR_RES1);
/* SP_ELx: Initialize stack pointer */
arm64: Drop checks for current exception level, hardcode EL3 assumption When we first created the arm64 port, we weren't quite sure whether coreboot would always run in EL3 on all platforms. The AArch64 A.R.M. technically considers this exception level optional, but in practice all SoCs seem to support it. We have since accumulated a lot of code that already hardcodes an implicit or explicit assumption of executing in EL3 somewhere, so coreboot wouldn't work on a system that tries to enter it in EL1/2 right now anyway. However, some of our low level support libraries (in particular those for accessing architectural registers) still have provisions for running at different exception levels built-in, and often use switch statements over the current exception level to decide which register to access. This includes an unnecessarily large amount of code for what should be single-instruction operations and precludes further optimization via inlining. This patch removes any remaining code that dynamically depends on the current exception level and makes the assumption that coreboot executes at EL3 official. If this ever needs to change for a future platform, it would probably be cleaner to set the expected exception level in a Kconfig rather than always probing it at runtime. Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-08-04 02:14:45 +02:00
raw_write_sp_el2(elx->sp_elx);
/* Payloads expect to be entered with MMU disabled. Includes an ISB. */
mmu_disable();
/* Eret to the entry point */
trans_switch(regs);
}