public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Alison Wang <alison.wang@nxp.com>,
	Michael Walle <michael@walle.cc>, Nishanth Menon <nm@ti.com>,
	Priyanka Singh <priyanka.singh@nxp.com>,
	Peter Hoyes <Peter.Hoyes@arm.com>,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	u-boot@lists.denx.de
Subject: [PATCH 2/6] armv8: Always unmask SErrors
Date: Sun,  9 Jan 2022 17:30:05 +0000	[thread overview]
Message-ID: <20220109173009.25522-3-andre.przywara@arm.com> (raw)
In-Reply-To: <20220109173009.25522-1-andre.przywara@arm.com>

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>
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 9 ---------
 arch/arm/cpu/armv8/start.S                   | 3 +++
 arch/arm/include/asm/system.h                | 1 +
 3 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 3aa1a9c3e5c..0929c58d43f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -74,15 +74,6 @@ ENDPROC(smp_kick_all_cpus)
 ENTRY(lowlevel_init)
 	mov	x29, lr			/* Save LR */
 
-	/* unmask SError and abort */
-	msr daifclr, #4
-
-	/* Set HCR_EL2[AMO] so SError @EL2 is taken */
-	mrs	x0, hcr_el2
-	orr	x0, x0, #0x20			/* AMO */
-	msr	hcr_el2, x0
-	isb
-
 	switch_el x1, 1f, 100f, 100f	/* skip if not in EL3 */
 1:
 
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index b3eef705a53..a26c18329cb 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -130,6 +130,8 @@ pie_fixup_done:
 	b	0f
 2:	mrs	x1, hcr_el2
 	tbnz	x1, #34, 1f			/* HCR_EL2.E2H */
+	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 */
@@ -138,6 +140,7 @@ pie_fixup_done:
 	mov	x0, #3 << 20
 	msr	cpacr_el1, x0			/* Enable FP/SIMD */
 0:
+	msr	daifclr, #0x4			/* Unmask SError interrupts */
 
 #ifdef COUNTER_FREQUENCY
 	branch_if_not_highest_el x0, 4f
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index f75eea16b36..87d1c77e8b1 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -82,6 +82,7 @@
 #define HCR_EL2_RW_AARCH64	(1 << 31) /* EL1 is AArch64                   */
 #define HCR_EL2_RW_AARCH32	(0 << 31) /* Lower levels are AArch32         */
 #define HCR_EL2_HCD_DIS		(1 << 29) /* Hypervisor Call disabled         */
+#define HCR_EL2_AMO_EL2		(1 <<  5) /* Route SErrors to EL2             */
 
 /*
  * ID_AA64ISAR1_EL1 bits definitions
-- 
2.17.6


  parent reply	other threads:[~2022-01-09 17:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-09 17:30 [PATCH 0/6] armv8: fixes and cleanups Andre Przywara
2022-01-09 17:30 ` [PATCH 1/6] cmd: exception: arm64: fix undefined, add faults Andre Przywara
2022-01-09 18:43   ` Heinrich Schuchardt
2022-01-09 19:08   ` Heinrich Schuchardt
2022-01-09 21:31     ` Andre Przywara
2022-01-09 22:19       ` Heinrich Schuchardt
2022-01-09 22:35         ` Andre Przywara
2022-01-09 22:47           ` Mark Kettenis
2022-01-09 23:19             ` Andre Przywara
2022-01-09 23:23               ` Heinrich Schuchardt
2022-01-09 23:49                 ` Andre Przywara
2022-01-10 22:37               ` Mark Kettenis
2022-01-11 10:28                 ` Andre Przywara
2022-01-09 17:30 ` Andre Przywara [this message]
2022-01-09 17:30 ` [PATCH 3/6] armv8: Force SP_ELx stack pointer usage Andre Przywara
2022-01-09 17:30 ` [PATCH 4/6] arm: Clean up asm/io.h Andre Przywara
2022-01-09 21:39   ` Andre Przywara
2022-01-13  6:44     ` Leo Liang
2022-01-09 17:30 ` [PATCH 5/6] armv8: Simplify switch_el macro Andre Przywara
2022-01-09 17:30 ` [PATCH 6/6] armv8: Fix and simplify branch_if_master/branch_if_slave Andre Przywara
2022-01-09 19:14 ` [PATCH 0/6] armv8: fixes and cleanups Michael Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220109173009.25522-3-andre.przywara@arm.com \
    --to=andre.przywara@arm.com \
    --cc=Peter.Hoyes@arm.com \
    --cc=alison.wang@nxp.com \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=michael@walle.cc \
    --cc=nm@ti.com \
    --cc=priyanka.singh@nxp.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox