u-boot/arch/arm/cpu/armv8/start.S

375 lines
8.5 KiB
ArmAsm
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0+ */
/*
* (C) Copyright 2013
* David Feng <fenghua@phytium.com.cn>
*/
#include <asm-offsets.h>
#include <config.h>
#include <linux/linkage.h>
#include <asm/macro.h>
#include <asm/armv8/mmu.h>
/*************************************************************************
*
* Startup Code (reset vector)
*
*************************************************************************/
.globl _start
_start:
#if defined(CONFIG_LINUX_KERNEL_IMAGE_HEADER)
#include <asm/boot0-linux-kernel-header.h>
#elif defined(CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK)
/*
* Various SoCs need something special and SoC-specific up front in
* order to boot, allow them to set that in their boot0.h file and then
* use it here.
*/
#include <asm/arch/boot0.h>
#else
b reset
#endif
.align 3
.globl _TEXT_BASE
_TEXT_BASE:
.quad CONFIG_TEXT_BASE
/*
* These are defined in the linker script.
*/
.globl _end_ofs
_end_ofs:
.quad _end - _start
.globl _bss_start_ofs
_bss_start_ofs:
.quad __bss_start - _start
.globl _bss_end_ofs
_bss_end_ofs:
.quad __bss_end - _start
reset:
/* Allow the board to save important registers */
b save_boot_params
.globl save_boot_params_ret
save_boot_params_ret:
#if CONFIG_POSITION_INDEPENDENT && !defined(CONFIG_SPL_BUILD)
/* Verify that we're 4K aligned. */
adr x0, _start
ands x0, x0, #0xfff
b.eq 1f
0:
/*
* FATAL, can't continue.
* U-Boot needs to be loaded at a 4K aligned address.
*
* We use ADRP and ADD to load some symbol addresses during startup.
* The ADD uses an absolute (non pc-relative) lo12 relocation
* thus requiring 4K alignment.
*/
wfi
b 0b
1:
/*
* Fix .rela.dyn relocations. This allows U-Boot to be loaded to and
* executed at a different address than it was linked at.
*/
pie_fixup:
adr x0, _start /* x0 <- Runtime value of _start */
ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */
subs x9, x0, x1 /* x9 <- Run-vs-link offset */
beq pie_fixup_done
adrp x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
add x2, x2, #:lo12:__rel_dyn_start
adrp x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */
add x3, x3, #:lo12:__rel_dyn_end
pie_fix_loop:
ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */
ldr x4, [x2], #8 /* x4 <- addend */
cmp w1, #1027 /* relative fixup? */
bne pie_skip_reloc
/* relative fix: store addend plus offset at dest location */
add x0, x0, x9
add x4, x4, x9
str x4, [x0]
pie_skip_reloc:
cmp x2, x3
b.lo pie_fix_loop
pie_fixup_done:
#endif
#if defined(CONFIG_ARMV8_SPL_EXCEPTION_VECTORS) || !defined(CONFIG_SPL_BUILD)
.macro set_vbar, regname, reg
msr \regname, \reg
.endm
adr x0, vectors
#else
.macro set_vbar, regname, reg
.endm
#endif
/*
* Could be EL3/EL2/EL1, Initial State:
* Little Endian, MMU Disabled, i/dCache Disabled
*/
switch_el x1, 3f, 2f, 1f
3: set_vbar vbar_el3, x0
mrs x0, scr_el3
orr x0, x0, #0xf /* SCR_EL3.NS|IRQ|FIQ|EA */
msr scr_el3, x0
msr cptr_el3, xzr /* Enable FP/SIMD */
b 0f
2: mrs x1, hcr_el2
tbnz x1, #HCR_EL2_E2H_BIT, 1f /* HCR_EL2.E2H */
armv8: Always unmask SErrors The ARMv8 architecture describes the "SError interrupt" as the fourth kind of exception, next to synchronous exceptions, IRQs, and FIQs. Those SErrors signal exceptional conditions from which the system might not easily recover, and are normally generated by the interconnect as a response to some bus error. A typical situation is access to a non-existing memory address or device, but it might be deliberately triggered by a device as well. The SError interrupt replaces the Armv7 asynchronous abort. Trusted Firmware enters U-Boot (BL33) typically with SErrors masked, and we never enable them. However any SError condition still triggers the SError interrupt, and this condition stays pending, it just won't be handled. If now later on the Linux kernel unmasks the "A" bit in PState, it will immediately take the exception, leading to a kernel crash. This leaves many people scratching their head about the reason for this, and leads to long debug sessions, possibly looking at the wrong places (the kernel, but not U-Boot). To avoid the situation, just unmask SErrors early in the ARMv8 boot process, so that the U-Boot exception handlers reports them in a timely manner. As SErrors are typically asynchronous, the register dump does not need to point at the actual culprit, but it should happen very shortly after the condition. For those exceptions to be taken, we also need to route them to EL2, if U-Boot is running in this exception level. This removes the respective code snippet from the Freescale lowlevel routine, as this is now handled in generic ARMv8 code. Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-02-11 11:29:35 +00:00
orr x1, x1, #HCR_EL2_AMO_EL2 /* Route SErrors to EL2 */
msr hcr_el2, x1
set_vbar vbar_el2, x0
mov x0, #0x33ff
msr cptr_el2, x0 /* Enable FP/SIMD */
b 0f
1: set_vbar vbar_el1, x0
mov x0, #3 << 20
msr cpacr_el1, x0 /* Enable FP/SIMD */
0:
armv8: Always unmask SErrors The ARMv8 architecture describes the "SError interrupt" as the fourth kind of exception, next to synchronous exceptions, IRQs, and FIQs. Those SErrors signal exceptional conditions from which the system might not easily recover, and are normally generated by the interconnect as a response to some bus error. A typical situation is access to a non-existing memory address or device, but it might be deliberately triggered by a device as well. The SError interrupt replaces the Armv7 asynchronous abort. Trusted Firmware enters U-Boot (BL33) typically with SErrors masked, and we never enable them. However any SError condition still triggers the SError interrupt, and this condition stays pending, it just won't be handled. If now later on the Linux kernel unmasks the "A" bit in PState, it will immediately take the exception, leading to a kernel crash. This leaves many people scratching their head about the reason for this, and leads to long debug sessions, possibly looking at the wrong places (the kernel, but not U-Boot). To avoid the situation, just unmask SErrors early in the ARMv8 boot process, so that the U-Boot exception handlers reports them in a timely manner. As SErrors are typically asynchronous, the register dump does not need to point at the actual culprit, but it should happen very shortly after the condition. For those exceptions to be taken, we also need to route them to EL2, if U-Boot is running in this exception level. This removes the respective code snippet from the Freescale lowlevel routine, as this is now handled in generic ARMv8 code. Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-02-11 11:29:35 +00:00
msr daifclr, #0x4 /* Unmask SError interrupts */
#if CONFIG_COUNTER_FREQUENCY
branch_if_not_highest_el x0, 4f
ldr x0, =CONFIG_COUNTER_FREQUENCY
msr cntfrq_el0, x0 /* Initialize CNTFRQ */
#endif
4: isb
/*
* Enable SMPEN bit for coherency.
* This register is not architectural but at the moment
* this bit should be set for A53/A57/A72.
*/
#ifdef CONFIG_ARMV8_SET_SMPEN
switch_el x1, 3f, 1f, 1f
3:
mrs x0, S3_1_c15_c2_1 /* cpuectlr_el1 */
orr x0, x0, #0x40
msr S3_1_c15_c2_1, x0
arm64: issue ISB after updating system registers ARM Architecture reference manual clearly states that PE pipeline should be flushed after changes to some system registers. Refer to paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI 0487B.a). Failing to issue instruction synchronization barrier can lead to spurious errors, like synchronous exception when accessing FPU registers. This is very prominent on CPUs with long instruction pipeline, like ARM Cortex A72. This change fixes the following U-Boot panic: "Synchronous Abort" handler, esr 0x1fe00000 elr: 00000000800948cc lr : 0000000080091e04 x0 : 00000000801ffdc8 x1 : 00000000000000c8 x2 : 00000000800979d4 x3 : 00000000801ffc60 x4 : 00000000801ffd40 x5 : ffffff80ffffffd8 x6 : 00000000801ffd70 x7 : 00000000801ffd70 x8 : 000000000000000a x9 : 0000000000000000 x10: 0000000000000044 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 000000008008b2e0 x17: 0000000000000000 x18: 00000000801ffec0 x19: 00000000800957b0 x20: 00000000000000c8 x21: 00000000801ffdc8 x22: 000000008009909e x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000801ffc50 Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0) While executing instruction str q0, [sp, #112] in vsnprintf() prologue. This panic was observed only on Cortex A72 so far. This patch places ISBs on other strategic places as well. Also, this probably is the right fix for the issue workarounded in the commit 45f41c134baf ("ARM: uniphier: add weird workaround code for LD20") Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Suggested-by: Julien Grall <julien.grall.oss@gmail.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> CC: Tom Rini <trini@konsulko.com> CC: Masahiro Yamada <yamada.masahiro@socionext.com> CC: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-06-24 01:05:19 +00:00
isb
1:
#endif
/* Apply ARM core specific erratas */
bl apply_core_errata
/*
* Cache/BPB/TLB Invalidate
* i-cache is invalidated before enabled in icache_enable()
* tlb is invalidated before mmu is enabled in dcache_enable()
* d-cache is invalidated before enabled in dcache_enable()
*/
/* Processor specific initialization */
bl lowlevel_init
#if defined(CONFIG_ARMV8_SPIN_TABLE) && !defined(CONFIG_SPL_BUILD)
branch_if_master x0, master_cpu
b spin_table_secondary_jump
/* never return */
#elif defined(CONFIG_ARMV8_MULTIENTRY)
branch_if_master x0, master_cpu
/*
* Slave CPUs
*/
slave_cpu:
wfe
ldr x1, =CPU_RELEASE_ADDR
ldr x0, [x1]
cbz x0, slave_cpu
br x0 /* branch to the given address */
#endif /* CONFIG_ARMV8_MULTIENTRY */
master_cpu:
msr SPSel, #1 /* make sure we use SP_ELx */
bl _main
/*-----------------------------------------------------------------------*/
WEAK(apply_core_errata)
mov x29, lr /* Save LR */
/* For now, we support Cortex-A53, Cortex-A57 specific errata */
/* Check if we are running on a Cortex-A53 core */
branch_if_a53_core x0, apply_a53_core_errata
/* Check if we are running on a Cortex-A57 core */
branch_if_a57_core x0, apply_a57_core_errata
0:
mov lr, x29 /* Restore LR */
ret
apply_a53_core_errata:
#ifdef CONFIG_ARM_ERRATA_855873
mrs x0, midr_el1
tst x0, #(0xf << 20)
b.ne 0b
mrs x0, midr_el1
and x0, x0, #0xf
cmp x0, #3
b.lt 0b
mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */
/* Enable data cache clean as data cache clean/invalidate */
orr x0, x0, #1 << 44
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
arm64: issue ISB after updating system registers ARM Architecture reference manual clearly states that PE pipeline should be flushed after changes to some system registers. Refer to paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI 0487B.a). Failing to issue instruction synchronization barrier can lead to spurious errors, like synchronous exception when accessing FPU registers. This is very prominent on CPUs with long instruction pipeline, like ARM Cortex A72. This change fixes the following U-Boot panic: "Synchronous Abort" handler, esr 0x1fe00000 elr: 00000000800948cc lr : 0000000080091e04 x0 : 00000000801ffdc8 x1 : 00000000000000c8 x2 : 00000000800979d4 x3 : 00000000801ffc60 x4 : 00000000801ffd40 x5 : ffffff80ffffffd8 x6 : 00000000801ffd70 x7 : 00000000801ffd70 x8 : 000000000000000a x9 : 0000000000000000 x10: 0000000000000044 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 000000008008b2e0 x17: 0000000000000000 x18: 00000000801ffec0 x19: 00000000800957b0 x20: 00000000000000c8 x21: 00000000801ffdc8 x22: 000000008009909e x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000801ffc50 Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0) While executing instruction str q0, [sp, #112] in vsnprintf() prologue. This panic was observed only on Cortex A72 so far. This patch places ISBs on other strategic places as well. Also, this probably is the right fix for the issue workarounded in the commit 45f41c134baf ("ARM: uniphier: add weird workaround code for LD20") Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Suggested-by: Julien Grall <julien.grall.oss@gmail.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> CC: Tom Rini <trini@konsulko.com> CC: Masahiro Yamada <yamada.masahiro@socionext.com> CC: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-06-24 01:05:19 +00:00
isb
#endif
b 0b
apply_a57_core_errata:
#ifdef CONFIG_ARM_ERRATA_828024
mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */
/* Disable non-allocate hint of w-b-n-a memory type */
orr x0, x0, #1 << 49
/* Disable write streaming no L1-allocate threshold */
orr x0, x0, #3 << 25
/* Disable write streaming no-allocate threshold */
orr x0, x0, #3 << 27
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
arm64: issue ISB after updating system registers ARM Architecture reference manual clearly states that PE pipeline should be flushed after changes to some system registers. Refer to paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI 0487B.a). Failing to issue instruction synchronization barrier can lead to spurious errors, like synchronous exception when accessing FPU registers. This is very prominent on CPUs with long instruction pipeline, like ARM Cortex A72. This change fixes the following U-Boot panic: "Synchronous Abort" handler, esr 0x1fe00000 elr: 00000000800948cc lr : 0000000080091e04 x0 : 00000000801ffdc8 x1 : 00000000000000c8 x2 : 00000000800979d4 x3 : 00000000801ffc60 x4 : 00000000801ffd40 x5 : ffffff80ffffffd8 x6 : 00000000801ffd70 x7 : 00000000801ffd70 x8 : 000000000000000a x9 : 0000000000000000 x10: 0000000000000044 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 000000008008b2e0 x17: 0000000000000000 x18: 00000000801ffec0 x19: 00000000800957b0 x20: 00000000000000c8 x21: 00000000801ffdc8 x22: 000000008009909e x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000801ffc50 Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0) While executing instruction str q0, [sp, #112] in vsnprintf() prologue. This panic was observed only on Cortex A72 so far. This patch places ISBs on other strategic places as well. Also, this probably is the right fix for the issue workarounded in the commit 45f41c134baf ("ARM: uniphier: add weird workaround code for LD20") Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Suggested-by: Julien Grall <julien.grall.oss@gmail.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> CC: Tom Rini <trini@konsulko.com> CC: Masahiro Yamada <yamada.masahiro@socionext.com> CC: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-06-24 01:05:19 +00:00
isb
#endif
#ifdef CONFIG_ARM_ERRATA_826974
mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */
/* Disable speculative load execution ahead of a DMB */
orr x0, x0, #1 << 59
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
arm64: issue ISB after updating system registers ARM Architecture reference manual clearly states that PE pipeline should be flushed after changes to some system registers. Refer to paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI 0487B.a). Failing to issue instruction synchronization barrier can lead to spurious errors, like synchronous exception when accessing FPU registers. This is very prominent on CPUs with long instruction pipeline, like ARM Cortex A72. This change fixes the following U-Boot panic: "Synchronous Abort" handler, esr 0x1fe00000 elr: 00000000800948cc lr : 0000000080091e04 x0 : 00000000801ffdc8 x1 : 00000000000000c8 x2 : 00000000800979d4 x3 : 00000000801ffc60 x4 : 00000000801ffd40 x5 : ffffff80ffffffd8 x6 : 00000000801ffd70 x7 : 00000000801ffd70 x8 : 000000000000000a x9 : 0000000000000000 x10: 0000000000000044 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 000000008008b2e0 x17: 0000000000000000 x18: 00000000801ffec0 x19: 00000000800957b0 x20: 00000000000000c8 x21: 00000000801ffdc8 x22: 000000008009909e x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000801ffc50 Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0) While executing instruction str q0, [sp, #112] in vsnprintf() prologue. This panic was observed only on Cortex A72 so far. This patch places ISBs on other strategic places as well. Also, this probably is the right fix for the issue workarounded in the commit 45f41c134baf ("ARM: uniphier: add weird workaround code for LD20") Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Suggested-by: Julien Grall <julien.grall.oss@gmail.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> CC: Tom Rini <trini@konsulko.com> CC: Masahiro Yamada <yamada.masahiro@socionext.com> CC: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-06-24 01:05:19 +00:00
isb
#endif
#ifdef CONFIG_ARM_ERRATA_833471
mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */
/* FPSCR write flush.
* Note that in some cases where a flush is unnecessary this
could impact performance. */
orr x0, x0, #1 << 38
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
arm64: issue ISB after updating system registers ARM Architecture reference manual clearly states that PE pipeline should be flushed after changes to some system registers. Refer to paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI 0487B.a). Failing to issue instruction synchronization barrier can lead to spurious errors, like synchronous exception when accessing FPU registers. This is very prominent on CPUs with long instruction pipeline, like ARM Cortex A72. This change fixes the following U-Boot panic: "Synchronous Abort" handler, esr 0x1fe00000 elr: 00000000800948cc lr : 0000000080091e04 x0 : 00000000801ffdc8 x1 : 00000000000000c8 x2 : 00000000800979d4 x3 : 00000000801ffc60 x4 : 00000000801ffd40 x5 : ffffff80ffffffd8 x6 : 00000000801ffd70 x7 : 00000000801ffd70 x8 : 000000000000000a x9 : 0000000000000000 x10: 0000000000000044 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 000000008008b2e0 x17: 0000000000000000 x18: 00000000801ffec0 x19: 00000000800957b0 x20: 00000000000000c8 x21: 00000000801ffdc8 x22: 000000008009909e x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000801ffc50 Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0) While executing instruction str q0, [sp, #112] in vsnprintf() prologue. This panic was observed only on Cortex A72 so far. This patch places ISBs on other strategic places as well. Also, this probably is the right fix for the issue workarounded in the commit 45f41c134baf ("ARM: uniphier: add weird workaround code for LD20") Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Suggested-by: Julien Grall <julien.grall.oss@gmail.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> CC: Tom Rini <trini@konsulko.com> CC: Masahiro Yamada <yamada.masahiro@socionext.com> CC: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-06-24 01:05:19 +00:00
isb
#endif
#ifdef CONFIG_ARM_ERRATA_829520
mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */
/* Disable Indirect Predictor bit will prevent this erratum
from occurring
* Note that in some cases where a flush is unnecessary this
could impact performance. */
orr x0, x0, #1 << 4
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
arm64: issue ISB after updating system registers ARM Architecture reference manual clearly states that PE pipeline should be flushed after changes to some system registers. Refer to paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI 0487B.a). Failing to issue instruction synchronization barrier can lead to spurious errors, like synchronous exception when accessing FPU registers. This is very prominent on CPUs with long instruction pipeline, like ARM Cortex A72. This change fixes the following U-Boot panic: "Synchronous Abort" handler, esr 0x1fe00000 elr: 00000000800948cc lr : 0000000080091e04 x0 : 00000000801ffdc8 x1 : 00000000000000c8 x2 : 00000000800979d4 x3 : 00000000801ffc60 x4 : 00000000801ffd40 x5 : ffffff80ffffffd8 x6 : 00000000801ffd70 x7 : 00000000801ffd70 x8 : 000000000000000a x9 : 0000000000000000 x10: 0000000000000044 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 000000008008b2e0 x17: 0000000000000000 x18: 00000000801ffec0 x19: 00000000800957b0 x20: 00000000000000c8 x21: 00000000801ffdc8 x22: 000000008009909e x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000801ffc50 Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0) While executing instruction str q0, [sp, #112] in vsnprintf() prologue. This panic was observed only on Cortex A72 so far. This patch places ISBs on other strategic places as well. Also, this probably is the right fix for the issue workarounded in the commit 45f41c134baf ("ARM: uniphier: add weird workaround code for LD20") Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Suggested-by: Julien Grall <julien.grall.oss@gmail.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> CC: Tom Rini <trini@konsulko.com> CC: Masahiro Yamada <yamada.masahiro@socionext.com> CC: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-06-24 01:05:19 +00:00
isb
#endif
#ifdef CONFIG_ARM_ERRATA_833069
mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */
/* Disable Enable Invalidates of BTB bit */
and x0, x0, #0xE
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
arm64: issue ISB after updating system registers ARM Architecture reference manual clearly states that PE pipeline should be flushed after changes to some system registers. Refer to paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI 0487B.a). Failing to issue instruction synchronization barrier can lead to spurious errors, like synchronous exception when accessing FPU registers. This is very prominent on CPUs with long instruction pipeline, like ARM Cortex A72. This change fixes the following U-Boot panic: "Synchronous Abort" handler, esr 0x1fe00000 elr: 00000000800948cc lr : 0000000080091e04 x0 : 00000000801ffdc8 x1 : 00000000000000c8 x2 : 00000000800979d4 x3 : 00000000801ffc60 x4 : 00000000801ffd40 x5 : ffffff80ffffffd8 x6 : 00000000801ffd70 x7 : 00000000801ffd70 x8 : 000000000000000a x9 : 0000000000000000 x10: 0000000000000044 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000000 x15: 0000000000000000 x16: 000000008008b2e0 x17: 0000000000000000 x18: 00000000801ffec0 x19: 00000000800957b0 x20: 00000000000000c8 x21: 00000000801ffdc8 x22: 000000008009909e x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000801ffc50 Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0) While executing instruction str q0, [sp, #112] in vsnprintf() prologue. This panic was observed only on Cortex A72 so far. This patch places ISBs on other strategic places as well. Also, this probably is the right fix for the issue workarounded in the commit 45f41c134baf ("ARM: uniphier: add weird workaround code for LD20") Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Suggested-by: Julien Grall <julien.grall.oss@gmail.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> CC: Tom Rini <trini@konsulko.com> CC: Masahiro Yamada <yamada.masahiro@socionext.com> CC: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-06-24 01:05:19 +00:00
isb
#endif
b 0b
ENDPROC(apply_core_errata)
/*-----------------------------------------------------------------------*/
WEAK(lowlevel_init)
mov x29, lr /* Save LR */
#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
branch_if_slave x0, 1f
ldr x0, =GICD_BASE
bl gic_init_secure
1:
#if defined(CONFIG_GICV3)
ldr x0, =GICR_BASE
bl gic_init_secure_percpu
#elif defined(CONFIG_GICV2)
ldr x0, =GICD_BASE
ldr x1, =GICC_BASE
bl gic_init_secure_percpu
#endif
#endif
#ifdef CONFIG_ARMV8_MULTIENTRY
branch_if_master x0, 2f
/*
* Slave should wait for master clearing spin table.
* This sync prevent salves observing incorrect
* value of spin table and jumping to wrong place.
*/
#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
#ifdef CONFIG_GICV2
ldr x0, =GICC_BASE
#endif
bl gic_wait_for_interrupt
#endif
/*
* All slaves will enter EL2 and optionally EL1.
*/
adr x4, lowlevel_in_el2
ldr x5, =ES_TO_AARCH64
bl armv8_switch_to_el2
lowlevel_in_el2:
#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
adr x4, lowlevel_in_el1
ldr x5, =ES_TO_AARCH64
bl armv8_switch_to_el1
lowlevel_in_el1:
#endif
#endif /* CONFIG_ARMV8_MULTIENTRY */
2:
mov lr, x29 /* Restore LR */
ret
ENDPROC(lowlevel_init)
WEAK(smp_kick_all_cpus)
/* Kick secondary cpus up by SGI 0 interrupt */
#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
ldr x0, =GICD_BASE
b gic_kick_secondary_cpus
#endif
ret
ENDPROC(smp_kick_all_cpus)
/*-----------------------------------------------------------------------*/
ENTRY(c_runtime_cpu_setup)
#if defined(CONFIG_ARMV8_SPL_EXCEPTION_VECTORS) || !defined(CONFIG_SPL_BUILD)
/* Relocate vBAR */
adr x0, vectors
switch_el x1, 3f, 2f, 1f
3: msr vbar_el3, x0
b 0f
2: msr vbar_el2, x0
b 0f
1: msr vbar_el1, x0
0:
#endif
ret
ENDPROC(c_runtime_cpu_setup)
WEAK(save_boot_params)
b save_boot_params_ret /* back to my caller */
ENDPROC(save_boot_params)