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

[Nishanth Menon]

On 14:51-20250417, Anshul Dalal wrote:
> On Thu Apr 17, 2025 at 1:21 AM IST, Nishanth Menon wrote:
> > On 11:38-20250416, Andrew Davis wrote:
> >> > > > 	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
> >
> > For folks who are trying to boot linux from TFA, they could do the same.
> 
> This change would allow us to support both standard boot flow and falcon
> mode from the same upstream source. With the only downside being the

Other than trivial usecases, no you cannot. There is a lot of
monkeying of dtb that u-boot does with mac address, HS-FS based dt node
enable/disable etc. In effect, at a product level it ends up as a different
flow.

> slight overhead added by the jump-stub (~1.7KiB added to tispl.bin and
> two extra instructions to jump to u-boot from older ATF builds).

The boot flow is already a complex flow at the moment. If we go down
this road, U-boot will have no choice but to support both variants of
TFA for all eternity - any fallacy that people will upgrade U-boot and
TFA baselines in sync is wrong.

> 
> And we can remove the stub altogether once all the customers have
> migrated over to the new address.

When would we know? There are gazillion usage models we are not aware
of. U-boot is not the only game in town for bootloaders. Barebox, and
other bootloader ecosystems will also need to pony up, that too hand in
hand with migration to new address proposed in TFA.

> 
> In addition to that this also frees up the bottom of DDR which allows us
> to more easily support low memory systems (512MiB or less) as we can use
> the freed up space for more tightly packing OP-TEE, DM etc.  instead of
> having the binaries loaded at scattered addresses like we do now.

Now, we are suggesting an entire memory map revamp impacting more
s/w components. For platforms with low DDR capabilities (e.g.
PocketBeagle2), please do the necessary changes when introducing to
mainline.

> 
> >> 
> >> 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?
> >
> > I dont see a specific value here. U-boot just works. For folks who want
> > direct TFA to kernel jump (which is a niche fast boot usecase), go ahead
> > and use TFA with the mentioned build option.
> 

IMHO, there is a simpler alternate solution - build TFA, dtb etc in the
model of your desire. let us leave the defaults be.

I will let Tom and other U-boot maintainers make their choice, as TFA
maintainer, I have already rejected the approach. it is already
PRELOADED_BL33_BASE ?= 0x80080000 which allows for override at build
time instead of all the massive rework and downstream ecosystem impact.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D