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

[Marek Vasut <marek.vasut@gmail.com>]

On 6/29/19 5:02 PM, 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.

You are free to do so locally, but following this train of thought would
possibly lead to putting Linux kernel sources in the same repository
too, and possible the entire userspace.

Mixing two completely different projects, with different goals, makes
zero sense.

> 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?

I agree with Mark, SPL and U-Boot share a lot of code.

ATF and U-Boot share nothing, in fact, from what I was told, ATF was
designed to be explicitly non-GPL, to make it easier for vendors to take
the ATF code and close source it. Hence, ATF cannot import any U-Boot
code and reimplements everything from scratch.

> 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?

See above.

> This would ultimately avoid out-off-tree ATF builds with associated
> variable exporting during u-boot builds.

See the Linux + userspace argument.

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

U-Boot code should ideally be GPLv2, other licenses should be an exception.

> 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?

IMO the better solution here would be to take the BL2 hardware init code
and put it into SPL. Then you won't need the ATF BL1/BL2 hardware init,
which is the bulk of what ATF does on many platforms.

If you need resident services, BL31, either implement some sort of
PSCI-like support into U-Boot (possibly alongside SPL/TPL/U-Boot
proper), or build it from ATF sources.

-- 
Best regards,
Marek Vasut