[PATCH] arm: relocate: Introduce data-only relocation mode

[Tom Rini]

On Mon, Mar 16, 2026 at 05:53:44PM +0100, Marek Vasut wrote:
> On 3/16/26 3:50 PM, Tom Rini wrote:
> 
> Hello Tom,
> 
> > > +config SKIP_RELOCATE_CODE
> > > +	bool "Skips relocation of U-Boot code to end of RAM"
> > > +	help
> > > +	  Skips relocation of U-Boot code to the end of RAM, but still does
> > > +	  relocate data to the end of RAM. This is mainly meant to relocate
> > > +	  data to read-write portion of the RAM, while the code remains in
> > > +	  read-only portion of the RAM from which it is allowed to execute.
> > > +	  This split configuration is present on various secure cores.
> > 
> > Is this really configurable, or is this determined by the SoC? This
> > feels like something a board should be select'ing rather than
> > configuring and I do worry about boards abusing this in the same of some
> > possibly dubious speed-up rather than the intented and valid use case.
> 
> On R-Car X5H, the Cortex-M core U-Boot port selects this, the Cortex-A core
> U-Boot port does NOT select this. So, this is neither SoC level
> configuration nor board level configuration, this is SoC CPU core level
> configuration. I can definitely hide this symbol and conditionally select it
> on SoC level.

At the high level, this sounds similar to the TI K3 platforms where we
have a Cortex-R build and a Cortex-A build and so (ARCH_K3 && CPU_V7R)
is valid in Kconfig. I assume there something similar in this situation,
so yes please, thanks.

> > [snip]
> > > diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> > > index 6ee58f4edfe..b6a648708f4 100644
> > > --- a/arch/arm/lib/relocate.S
> > > +++ b/arch/arm/lib/relocate.S
> > > @@ -79,6 +79,15 @@ ENDPROC(relocate_vectors)
> > >   ENTRY(relocate_code)
> > >   relocate_base:
> > >   	adr	r3, relocate_base
> > > +
> > > +#ifdef CONFIG_SKIP_RELOCATE_CODE
> > > +	mov r4,	#CONFIG_SKIP_RELOCATE_CODE_DATA_OFFSET
> > 
> > Spacing. But if there's no other comments and propmting the user is
> > correct, I can fix when applying.
> Fixed in V2 .

Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260316/2c40f690/attachment.sig>