summaryrefslogtreecommitdiff
path: root/src/arch/arm64/armv8/cpu.S
AgeCommit message (Collapse)Author
2024-06-05arch/arm64: Support FEAT_CCIDXYidi Lin
ARM SoC supports FEAT_CCIDX after ARMv8.3. The register field description of CCSIDR_EL1 is different when FEAT_CCIDX is implemented. If numsets and associativity from CCSIDR_EL1 are not correct, the system would hang during mmu_disable(). Rather than assuming that FEAT_CCIDX is not implemented, this patch adds a check to dcache_apply_all to use the right register format. Reference: - https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/12770 BUG=b:317015456 TEST=mmu_disable works on the FEAT_CCIDX supported SoC. TEST=manually add mmu_disable to emulation/qemu-aarch64/bootblock.c and verify with the command qemu-system-aarch64 -bios \ ./coreboot-builds/EMULATION_QEMU_AARCH64/coreboot.rom -M \ virt,secure=on,virtualization=on -cpu max -cpu cortex-a710 \ -nographic -m 8192M Change-Id: Ieadd0d9dfb8911039b3d36c9419af4ae04ed814c Signed-off-by: Yidi Lin <yidilin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82635 Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2024-04-22arch/arm64: Add EL1/EL2/EL3 support for arm64David Milosevic
Currently, arch/arm64 requires coreboot to run on EL3 due to EL3 register access. This might be an issue when, for example, one boots into TF-A first and drops into EL2 for coreboot afterwards. This patch aims at making arch/arm64 more versatile by removing the current EL3 constraint and allowing arm64 coreboot to run on EL1, EL2 and EL3. The strategy here, is to add a Kconfig option (ARM64_CURRENT_EL) which lets us specify coreboot's EL upon entry. Based on that, we access the appropriate ELx registers. So, for example, when running coreboot on EL1, we would not access vbar_el3 or vbar_el2 but instead vbar_el1. This way, we don't generate faults when accessing higher-EL registers. Currently only tested on the qemu-aarch64 target. Exceptions were tested by enabling FATAL_ASSERTS. Signed-off-by: David Milosevic <David.Milosevic@9elements.com> Change-Id: Iae1c57f0846c8d0585384f7e54102a837e701e7e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74798 Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: ron minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2020-05-11treewide: Remove "this file is part of" linesPatrick Georgi
Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-06src/arch/arm64: Convert to SPDX license headerPatrick Georgi
This also drops individual copyright notices, all mentioned authors in that part of the tree are already listed in AUTHORS. Change-Id: Ic5eddc961d015328e5a90994b7963e7af83cddd3 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39279 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-12-05arm64: Correctly unmask asynchronous SError interruptsJulius Werner
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-08-26AUTHORS: Move src/arch/arm64 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. Additional changes in this patch: - Make sure files say that they're part of the coreboot project - Move descriptions below the license header Note that the file include/arch/acpi.h is a fantastic example of why moving to the authors file is needed. Excluding the guard statements, it has 8 lines of copyrights for 3 function declarations. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I334baab2b4311eb1bd9ce3f67f49a68e8b73630c Reviewed-on: https://review.coreboot.org/c/coreboot/+/34606 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-06-26arm64: Reimplement mmu_disable() in assemblyJulius Werner
Disabling the MMU with proper cache behavior is a bit tricky on ARM64: you can flush the cache first and then disable the MMU (like we have been doing), but then you run the risk of having new cache lines allocated in the tiny window between the two, which may or may not become a problem when those get flushed at a later point (on some platforms certain memory regions "go away" at certain points in a way that makes the CPU very unhappy if it ever issues a write cycle to them again afterwards). The obvious alternative is to first disable the MMU and then flush the cache, ensuring that every memory access after the flush already has the non-cacheable attribute. But we can't just flip the order around in the C code that we have because then those accesses in the tiny window in-between will go straight to memory, so loads may yield the wrong result or stores may get overwritten again by the later cache flush. In the end, this all shouldn't really be a problem because we can do both operations purely from registers without doing any explicit memory accesses in-between. We just have to reimplement the function in assembly to make sure the compiler doesn't insert any stack accesses at the wrong points. Change-Id: Ic552960c91400dadae6f130b2521a696eeb4c0b1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27238 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-05-30arm64: Align cache maintenance code with libpayload and ARM32Julius Werner
coreboot and libpayload currently use completely different code to perform a full cache flush on ARM64, with even different function names. The libpayload code is closely inspired by the ARM32 version, so for the sake of overall consistency let's sync coreboot to that. Also align a few other cache management details to work the same way as the corresponding ARM32 parts (such as only flushing but not invalidating the data cache after loading a new stage, which may have a small performance benefit). Change-Id: I9e05b425eeeaa27a447b37f98c0928fed3f74340 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19785 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-17arm64: tegra132: tegra210: Remove old arm64/stage_entry.SJulius Werner
This patch removes the old arm64/stage_entry.S code that was too specific to the Tegra SoC boot flow, and replaces it with code that hides the peculiarities of switching to a different CPU/arch in ramstage in the Tegra SoC directories. BRANCH=None BUG=None TEST=Built Ryu and Smaug. !!!UNTESTED!!! Change-Id: Ib3a0448b30ac9c7132581464573efd5e86e03698 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12078 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-16arm64: Implement generic stage transitions for non-Tegra SoCsJulius Werner
The existing arm64 architecture code has been developed for the Tegra132 and Tegra210 SoCs, which only start their ARM64 cores in ramstage. It interweaves the stage entry point with code that initializes a CPU (and should not be run again if that CPU already ran a previous stage). It also still contains some vestiges of SMP/secmon support (such as setting up stacks in the BSS instead of using the stage-peristent one from memlayout). This patch splits those functions apart and makes the code layout similar to how things work on ARM32. The default stage_entry() symbol is a no-op wrapper that just calls main() for the current stage, for the normal case where a stage ran on the same core as the last one. It can be overridden by SoC code to support special cases like Tegra. The CPU initialization code is split out into armv8/cpu.S (similar to what arm_init_caches() does for ARM32) and called by the default bootblock entry code. SoCs where a CPU starts up in a later stage can call the same code from a stage_entry() override instead. The Tegra132 and Tegra210 code is not touched by this patch to make it easier to review and validate. A follow-up patch will bring those SoCs in line with the model. BRANCH=None BUG=None TEST=Booted Oak with a single mmu_init()/mmu_enable(). Built Ryu and Smaug. Change-Id: I28302a6ace47e8ab7a736e089f64922cef1a2f93 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12077 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-04-27arm64: introduce data cache ops by set/way to the level specifiedJoseph Lo
This patchs introduces level specific data cache maintenance operations to cache_helpers.S. It's derived form ARM trusted firmware repository. Please reference here. https://github.com/ARM-software/arm-trusted-firmware/blob/master/ lib/aarch64/cache_helpers.S BRANCH=none BUG=none TEST=boot on smaug/foster Change-Id: Ib58a6d6f95eb51ce5d80749ff51d9d389b0d1343 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b3d1a16bd0089740f1f2257146c771783beece82 Original-Change-Id: Ifcd1dbcd868331107d0d47af73545a3a159fdff6 Original-Signed-off-by: Joseph Lo <josephl@nvidia.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265826 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9979 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-09-23coreboot arm64: Add support for arm64 into coreboot frameworkFurquan Shaikh
Add support for enabling different coreboot stages (bootblock, romstage and ramstage) to have arm64 architecture. Most of the files have been copied over from arm/ or arm64-generic work. Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/197397 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934) This patch is essentially a squash of aarch64 changes made by these patches: d955885 coreboot: Rename coreboot_ram stage to ramstage a492761 cbmem console: Locate the preram console with a symbol instead of a sect 96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3 3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage 25fd2e9 aarch64: Remove CAR definitions from early_variables.h 65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM 9484873 aarch64: Change default exception level to EL2 7a152c3 aarch64: Fix formatting of exception registers dump 6946464 aarch64: Implement basic exception handling c732a9d aarch64/foundation-armv8: Basic bootblock implementation 3bc412c aarch64: Comment out some parts of code to allow build ab5be71 Add initial aarch64 support The ramstage support is the only portion that has been tested on actual hardware. Bootblock and romstage support may require modifications to run on hardware. Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6915 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Furquan Shaikh <furquan@google.com>