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-ansh...@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
