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 3/6] armv8: Force SP_ELx stack pointer usage
Date: Sun, 9 Jan 2022 17:30:06 +0000 [thread overview]
Message-ID: <20220109173009.25522-4-andre.przywara@arm.com> (raw)
In-Reply-To: <20220109173009.25522-1-andre.przywara@arm.com>
In ARMv8 we have the choice between two stack pointers to use: SP_EL0 or
SP_ELx, which is banked per exception level. This choice is stored in
the SP field of PState, and can be read and set via the SPSel special
register. When the CPU takes an exception, it automatically switches to
the SP_ELx stack pointer.
Trusted Firmware enters U-Boot typically with SPSel set to 1, so we use
SP_ELx all along as our sole stack pointer, both for normal operation and
for exceptions.
But if we now for some reason enter U-Boot with SPSel cleared, we will
setup and use SP_EL0, which is fine, but leaves SP_ELx uninitialised.
When we now take an exception, we try to save the GPRs to some undefined
location, which will usually end badly.
To make sure we always have SP_ELx pointing to some memory, set SPSel
to 1 in the early boot code, to ensure safe operation at all times.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm/cpu/armv8/start.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index a26c18329cb..47a612883c5 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -196,6 +196,7 @@ 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
#ifdef CONFIG_SYS_RESET_SCTRL
--
2.17.6
next prev parent reply other threads:[~2022-01-09 17:32 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 ` [PATCH 2/6] armv8: Always unmask SErrors Andre Przywara
2022-01-09 17:30 ` Andre Przywara [this message]
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-4-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