[U-Boot] What if ATF can be part of U-Boot source, like SPL?

[Tom Rini]

On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote:

> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
> 
> This is what exactly it was done for SPL, if I'm not wrong. So can we
> do the same thing for ATF on ARM64 SoCs?
> 
> We are using ATF (on Allwinner) to switch EL3 to EL2 for start loading
> U-Boot proper and minimal PSCI, PMIC initialization. So assuming the
> functionality of ATF (like here) is limited so the code it require can
> be limited too, so why can't this code to be part of U-Boot tree?
> 
> This would ultimately avoid out-off-tree ATF builds with associated
> variable exporting during u-boot builds.
> 
> More over this idea would also help to design a single-step bootloader
> where it can't depends on out-of-tree sources.
> 
> Code sync from ATF source to U-Boot can be possible in-terms licensing
> point-of-view since ATF licensed under BSD-3-Clause.
> 
> I'm thinking this can be a worth-idea to look at it and I'm sure It
> may require some hard changes and other things to consider but just
> posted to understand how hard or feasible or meaningful it is?
> 
> Feel free for any comments?

Given that we have "TPL" and "SPL", my "pie in the sky" wish would be
for the ability to build different U-Boots to fill the different aspects
of the aarch64 boot flow.

That said, patches that would in turn allow for users to locally add ATF
as a git submodule and then build that, if cleanly done, could be
interesting.  But must not impact the normal build flow.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190630/157b4e8f/attachment.sig>