From: Andre Przywara <andre.przywara@arm.com>
To: Jagan Teki <jagan@amarulasolutions.com>
Cc: Samuel Holland <samuel@sholland.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
u-boot@lists.denx.de, linux-sunxi@lists.linux.dev
Subject: [PATCH] sunxi: h616: (really) lower SPL stack address to avoid BROM data
Date: Mon, 6 Nov 2023 01:59:30 +0000 [thread overview]
Message-ID: <20231106015930.30439-1-andre.przywara@arm.com> (raw)
When using the USB OTG FEL mode on the Allwinner H616, the BootROM
stores some data at the end of SRAM C. This is also the location where
we place the initial SPL stack, so it will overwrite this data.
We still need the BROM code after running the SPL, so should leave that
area alone.
Interestingly this does not seem to have an adverse effect, I guess on
the "way out" (when we return to FEL after the SPL has run), this data
is not needed by the BROM, for just the trailing end of the USB operation.
However this is still wrong, and we should not clobber BROM data.
Lower the SPL stack address to be situated right below the swap buffers
we use in sunxi-fel: that should be out of the way of everyone else.
This obsoletes a previous commit (eb53e7743c8f) with the same name:
that one was changing the address in an *unused* macro in sunxi_common.h,
so the previous patch didn't have any effect at all.
Fixes: eb53e7743c8f ("sunxi: h616: lower SPL stack address to avoid BROM data")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,
sorry for the blunder with that previous patch!
This issue came up when cleaning up some SPL code: LOW_LEVEL_SRAM_STACK,
as changed in the previous patch, is not used anywhere. I have a patch to
remove that whole section from sunxi-common.h, and will send that as part
of some bigger SPL clean-up series later.
Cheers,
Andre
common/spl/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 25cd18afda7..c521b02f4a3 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -370,7 +370,7 @@ config SPL_STACK
default 0x93ffb8 if ARCH_MX6 && MX6_OCRAM_256KB
default 0x91ffb8 if ARCH_MX6 && !MX6_OCRAM_256KB
default 0x118000 if MACH_SUN50I_H6
- default 0x58000 if MACH_SUN50I_H616
+ default 0x52a00 if MACH_SUN50I_H616
default 0x40000 if MACH_SUN8I_R528
default 0x54000 if MACH_SUN50I || MACH_SUN50I_H5
default 0x18000 if MACH_SUN9I
--
2.35.8
reply other threads:[~2023-11-06 2:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20231106015930.30439-1-andre.przywara@arm.com \
--to=andre.przywara@arm.com \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=samuel@sholland.org \
--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