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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3970 bytes --]

On Thu, Apr 17, 2025 at 06:30:13AM -0500, Nishanth Menon wrote:
> 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.

Thanks Nishanth. As you point out, all of the relevant projects need to
stay in sync for this to be useful and I agree with your position so
this is nak'd here too.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]