[PATCH v1 0/4] k3: migrate SPL_TEXT_BASE to new address

[Andrew Davis]

On 4/16/25 10:05 AM, Nishanth Menon wrote:
> On 19:18-20250416, Anshul Dalal wrote:
>> On Wed Apr 16, 2025 at 4:54 PM IST, Nishanth Menon wrote:
>>> On 13:00-20250416, Anshul Dalal wrote:
>>>> The change to ATF's PRELOADED_BL33_BASE[1] requires respective changes to
>>>> SPL_TEXT_BASE on u-boot side. This is necessary to allow the ATF to jump
>>>> directly to linux kernel (like in falcon mode) which requires a 2MiB aligned
>>>> load address[2]. The current address ATF jumps to is 0x80080000 which is not
>>>> 2MiB aligned.
>>>>
>>>> Therefore in parallel to the ATF change, this patch set makes the corresponding
>>>> changes to u-boot. To maintain backwards compatibility with older ATF builds
>>>> (that still use older address of 0x80080000), the patch set also adds a
>>>> jump-stub which modifies the execution as follows:
>>>>
>>>> Old ATF -> 0x80080000 -> 0x822000000 (Main domain SPL or kernel image)
>>>>             jump stub    SPL_TEXT_BASE
>>>>
>>>> With the following instructions loaded by the jump-stub:
>>>> ADDR       | Instruction
>>>> 0x80080000 |   mov x15, CONFIG_SPL_TEXT_BASE (0x822000000)
>>>> 0x80080004 |   br x15
>>>>
>>>> Depends on:
>>>>   * [PATCH v3] configs: set SPL_TEXT_BASE by default for k3 platforms
>>>>     https://lore.kernel.org/u-boot/20250415095028.446254-1-anshuld@ti.com/
>>>>
>>>> [1]:
>>>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/37447
>>>> [2]:
>>>> "The Image must be placed text_offset bytes from a 2MB aligned base
>>>> address anywhere in usable system RAM and called there."
>>>> - Documentation/arch/arm64/booting.rst (linux kernel)
>>>>
>>>> Anshul Dalal (4):
>>>>    spl: Kconfig: k3: set SPL_TEXT_BASE to 0x82200000
>>>>    mach-k3: add a jump stub to support older ATF builds
>>>>    binman: k3: add jump-stub to tispl.bin
>>>>    binman: k3: add jump-stub as loadable
>>>
>>>
>>> 	How about u-boot documentation?
>>
>> I will update that in the next revision along with any feedback I
>> receive on this patch.
> 
> IMHO, This change is too intrusive and impacts downstream customers
> including inflight production devices.
> 

Could you elaborate a little?

They do not even need to update their TF-A version, if they want to
use their current version they simply recompile it with a single
extra build flag:

PRELOADED_BL33_BASE=0x822000000

They should have no reason not to be able to do this. But even *if*
they cannot do that, the whole point of the jump-stub here is to
save them even having to do a simple compile.

IMHO "downstream customers including inflight production devices"
should not be a reason to block good and useful changes here in
upstream. But again, this change doesn't break anything for them in
the first place, so why bring that up?

Andrew