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

[André Przywara]

On 29/06/2019 16:02, 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.

I am not sure this is really true. If I get you right, you want to
mirror and sync the ATF source into the U-Boot tree, which sounds like a
pain:
- ATF development is quite dynamic, with just shy of 1000 commits alone
this year. This would mean constant churn of keeping the source up-to-date.
- The overlap of U-Boot and ATF users is not that big: ATF has support
for a lot more platforms (most of them typically paired with EDK-2),
also provides a lot more code than U-Boot platforms typically use: BL1,
BL2, secure payload support, etc. I am not sure a lot of people are
happy if we add tons of code lines to the repo which will never be used.

> This is what exactly it was done for SPL, if I'm not wrong.

But this SPL/proper code sharing does not come without a price. Think
about the problems with DM and the often limited SPL code size, which
causes us some headaches. Also I wonder how much code they actually
share? Thinking about DRAM init, the separate SPI flash driver for
Allwinner and all those #ifdefs everywhere.
I am not questioning the current design, but just want to point out that
this might not be best thing since sliced bread.

> 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

Minimal PSCI? TF-A is the full fledged reference implementation of PSCI,
it always supports the newest revisions, including Spectre/Meltdown
support. This alone is a killer argument for me to use ATF.

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

So do you want to just import the part of ATF that we need? That sounds
like a pain to start off first and will even induce more pain once ATF
changes something. They are doing constant refactoring and increasing
the code sharing, so ripping something out of there will not end well.

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

So what is the problem you are seeing with the current approach,
exactly? Is it just that it's annoying to have an external binary glued
in? I don't buy that this is a real problem.

> More over this idea would also help to design a single-step bootloader
> where it can't depends on out-of-tree sources.

What do you mean with single-step bootloader, exactly? I think it's
actually an advantage to have the steps in separate projects. So every
platform can use a common ATF, and they have a choice of U-Boot and
EDK-2, for instance. Or skip the extra loader altogether, just use the
SPL and launch the kernel from ATF directly. I hacked this once for
Allwinner based on this:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi3.rst#n216

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

Apart from the practical issues I outlined above I don't see the
architectural merit of merging in ATF.
What actually would make more sense is to merge the SPL into ATF, so
that we have a clean separation between platform initialisation and boot
loader. But this also has a lot of practical issues, and as mentioned I
don't really see that the current process is that painful that it
demands such changes.

Cheers,
Andre.