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

[Marek Vasut]

On 6/30/19 3:57 PM, Tom Rini wrote:
> 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.

So can we also add Linux as a submodule ? And glibc ? Maybe busybox too ?

-- 
Best regards,
Marek Vasut