On Sat, Mar 28, 2026 at 01:03:15AM +0100, Marek Vasut wrote: > On 3/16/26 6:10 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. > Either drop this patch and wait for V2, or I will send a follow up ?
Sigh, I forgot about my own feedback here even, I'll revert this in next shortly, sorry. -- Tom
signature.asc
Description: PGP signature
