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

["André Przywara" <andre.przywara@arm.com>]

On 30/06/2019 00:03, Marek Vasut wrote:

Marek,

you seem to be quite defensive in your answer, but I was just talking
against merging ATF into U-Boot, not against U-Boot - I think we agree
on this. I don't think there is much of a point in comparing ATF and
U-Boot, as the two do not compete against each other. They just
complement each other nicely, hence we use ATF and save us the burden of
having to reprogram something in U-Boot.

> On 6/29/19 8:49 PM, André Przywara wrote:
>> 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.
> 
> I don't think ATF development is anywhere near as dynamic as U-Boot,
> there's over 1000 commits in each U-Boot release, with quarterly release
> cycle.

Wasn't comparing, just saying that it's nothing you want to sync
regularly. Unlike libfdt, for instance.

>> 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),
> 
> Can you elaborate on how you came to this conclusion ? Last time I
> counted (a few days ago, in ATF master), the upstream ATF supported some
> low tens of boards, upstream U-Boot around a thousand. And then there's
> the part where ATF is ARM-centric while U-Boot is platform-agnostic.

I now see that my wording was unclear: ATF supports more platforms than
those that also use U-Boot. So you pull in code that you will never need.

>> 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.
> 
> BL1 is bootrom, right ? BL2 is hardware initialization, which is roughly
> doing the same thing as U-Boot SPL. Secure payload support was in U-Boot
> for a very long time too.

I was just pointing out that ATF and U-Boot are quite different and
there is very little (if at all) overlap. So if you pull in ATF, you
pull in all those BLx code that you don't need. And since ATF is heavily
sharing code between the stages, you can't easily rip one out.

>>> 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.
> 
> Maybe you should take a look at some other platform(s), rather than draw
> conclusion from one platform, that's not a good statistical practice.
> SoCFPGA for example uses the same drivers in SPL as it does in U-Boot,
> same for TI, and I can go on.
> 
> Allwinner has severe SRAM limitations, so there it cannot be helped that
> it needs custom driver. I don't see how using ATF would make any
> difference here.

I didn't say it would, I was merely saying that the SPL code sharing is
not always as big as one might think, and that this code sharing comes
at a price - the ifdef hell, for instance. So it might not serve as a
picture book example of perfect integration - especially since the
experience with integrating ATF would be much worse. But as mentioned
below here, I am not fighting this SPL model.

>> I am not questioning the current design, but just want to point out that
>> this might not be best thing since sliced bread.
> 
> It would certainly help if we could have one, or a few, bootloader
> project(s) and work on those few, to make them great. Currently there
> are many, each with a limited developer community. Adding more does not
> help, it only increases the fragmentation and the mess.

And that's exactly the point of ATF: You can use the tested PSCI code,
the secure GIC setup and all those core errata workarounds and spare
yourself from wrongly implementing this on your own.
Also ATF is not a bootloader, it explicitly leaves out that part.

>>> 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.
> 
> So ARM creates new PSCI version, ARM implements it into ARM trusted
> firmware, and then presents it to the users as the latest greatest.

Yes, that's the definition of a reference implementation. And it's Open
Source with a permissive license.

> That sounds a bit like the old windows development model -- one company
> does everything and then presents it to developers for them to consume.

PSCI is an interface, with a publicly available spec. You can go ahead
and implement it yourself - and U-Boot does. And by using PSCI, you win
so much, because SMP in *any* kernel suddenly becomes very straightforward.
So if you mean with "Windows model" that there is a standard that makes
everyone's life easier by providing compatibility and well defined
interfaces - I agree. For everything else I fail to see how it would
compare.

> My recent impression of ATF development is there is no community around
> ATF, so I presume there is no interest from collecting any feedback on
> the PSCI development from people outside of ARM, is that right ?

ATF and PSCI are two quite separate things, it's just that the former
implements the latter.
And I am not sure how the community aspect relates to the feedback
process. Section 1.1 in the PSCI PDF tells you about how to report back
any comments.

Anything in particular you want to discuss about PSCI? Happy to make
contacts.

Cheers,
Andre.