mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Alexander Shiyan <eagle.alexander923@gmail.com>,
	Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH master v3 3/5] ARM64: switch to CONFIG_BAREBOX_MEMORY_OFFSET
Date: Thu, 28 May 2026 13:02:17 +0200	[thread overview]
Message-ID: <20260528110401.3920904-4-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20260528110401.3920904-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




  parent reply	other threads:[~2026-05-28 11:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28 11:02 [PATCH master v3 0/5] ARM64: unify pbl and proper malloc area start Ahmad Fatoum
2026-05-28 11:02 ` [PATCH master v3 1/5] arch: introduce new CONFIG_ARCH_HAS_MALLOC_SIZE Ahmad Fatoum
2026-05-28 11:02 ` [PATCH master v3 2/5] arch: introduce CONFIG_BAREBOX_MEMORY_OFFSET Ahmad Fatoum
2026-05-28 11:02 ` Ahmad Fatoum [this message]
2026-05-28 11:02 ` [PATCH master v3 4/5] ARM64: configs: drop CONFIG_MALLOC_SIZE=0x0 as it's now the default Ahmad Fatoum
2026-05-28 11:02 ` [PATCH master v3 5/5] ARM64: place PBL malloc area at start of barebox proper malloc area Ahmad Fatoum
2026-05-28 16:35   ` Alexander Shiyan
2026-05-28 11:09 ` [PATCH master v3 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=20260528110401.3920904-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