From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: eagle.alexander923@gmail.com, Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH master v2 3/5] ARM64: switch to CONFIG_BAREBOX_MEMORY_OFFSET
Date: Wed, 27 May 2026 14:15:22 +0200 [thread overview]
Message-ID: <20260527121649.3365172-4-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20260527121649.3365172-1-a.fatoum@pengutronix.de>
In preparation for using the barebox proper malloc area in PBL too,
switch over ARM64 to CONFIG_BAREBOX_MEMORY_OFFSET as this allows
calculating the malloc area start without needing to know the eventual
size of barebox proper itself.
The switch for ARM32 is more involved, so that's omitted for now without
a comment explaining why. Once we have migrated the xload code to not
use the malloc area for second stage placement and weeded out the
bugs[1], we should be good to go[1].
[1]: On a Beagle Bone Black, despite first stage being moved out of
malloc area, I get a data abort before barebox_pbl_start...
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
arch/arm/Kconfig | 3 ++-
arch/arm/cpu/start.c | 10 ++++++++++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 53bddd55e179..c7a883338b0b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -20,7 +20,6 @@ config ARM
select ARCH_HAS_DMA_WRITE_COMBINE
select HAVE_EFI_LOADER if MMU # for payload unaligned accesses
select PBL_IMAGE_ELF
- select ARCH_HAS_MALLOC_SIZE
default y
config ARCH_LINUX_NAME
@@ -34,10 +33,12 @@ config ARCH_MKIMAGE_NAME
config ARM32
def_bool CPU_32
+ select ARCH_HAS_MALLOC_SIZE
config ARM64
def_bool CPU_64
select ARCH_HAS_RELR
+ select ARCH_HAS_BAREBOX_MEMORY_OFFSET
config ARCH_TEXT_BASE
hex
diff --git a/arch/arm/cpu/start.c b/arch/arm/cpu/start.c
index bbcf465be4db..6a9941275c12 100644
--- a/arch/arm/cpu/start.c
+++ b/arch/arm/cpu/start.c
@@ -156,6 +156,15 @@ __noreturn void barebox_non_pbl_start(unsigned long membase,
armv7r_mpu_init_coherent(malloc_end, REGION_8MB);
}
+#ifdef CONFIG_ARM64
+ malloc_start = barebox_malloc_base(membase, memsize);
+#else
+ /* TODO: migrate ARM32 to barebox_malloc_base(), once legacy xload
+ * code has been migrated to loadables; On boards like the beaglebone,
+ * a separate first stage barebox loads the second stage into RAM
+ * and executes it from there, so reusing the malloc area in second
+ * stage PBL will mangle the second stage code.
+ */
/*
* Maximum malloc space is the Kconfig value if given
* or 1GB.
@@ -169,6 +178,7 @@ __noreturn void barebox_non_pbl_start(unsigned long membase,
if (malloc_end - malloc_start > SZ_1G)
malloc_start = malloc_end - SZ_1G;
}
+#endif
pr_debug("initializing malloc pool at 0x%08lx (size 0x%08lx)\n",
malloc_start, malloc_end - malloc_start);
--
2.47.3
next prev parent reply other threads:[~2026-05-27 12:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 12:15 [PATCH master v2 0/5] ARM64: unify pbl and proper malloc area start Ahmad Fatoum
2026-05-27 12:15 ` [PATCH master v2 1/5] arch: introduce new CONFIG_ARCH_HAS_MALLOC_SIZE Ahmad Fatoum
2026-05-27 12:15 ` [PATCH master v2 2/5] arch: introduce CONFIG_BAREBOX_MEMORY_OFFSET Ahmad Fatoum
2026-05-27 12:15 ` Ahmad Fatoum [this message]
2026-05-27 12:15 ` [PATCH master v2 4/5] ARM64: configs: drop CONFIG_MALLOC_SIZE=0x0 as it's now the default Ahmad Fatoum
2026-05-27 12:15 ` [PATCH master v2 5/5] ARM64: place PBL malloc area at start of barebox proper malloc area Ahmad Fatoum
2026-05-27 13:12 ` Alexander Shiyan
2026-05-28 11:04 ` Ahmad Fatoum
2026-05-28 12:17 ` Alexander Shiyan
2026-05-28 12:50 ` Ahmad Fatoum
2026-05-28 10:55 ` [PATCH master v2] fixup! " Ahmad Fatoum
2026-05-28 12:16 ` Alexander Shiyan
2026-05-28 11:09 ` [PATCH master v2 0/5] ARM64: unify pbl and proper malloc area start Sascha Hauer
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=20260527121649.3365172-4-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=eagle.alexander923@gmail.com \
/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