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

[Marek Vasut]

On 6/30/19 3:38 AM, André Przywara wrote:
> On 30/06/2019 00:03, Marek Vasut wrote:
> 
> Marek,
> 
> you seem to be quite defensive in your answer

I am just correcting the mistakes I perceive in the previous email.

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

I suspect I answered those already in the thread.

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

I think s/more/different/

[...]

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

Which is a benefit of one single vendor being in control of everything?
Surely, this single vendor has perfect engineers that make no mistakes,
right? I think we had that before, and it didn't work out very well :)

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

Yes, it's Open Source and it's not Free Software, which is unfortunate.
It allows disasters like vendors taking ATF, reaping all the benefits of
external contributions, but releasing only closed-source blobs and
giving everyone who wants to study the code or change it the finger.

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

Just about like ACPI on x86.

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

I meant more like one company in control of everything, just providing
consumables for developers.

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

I am talking about ATF.

-- 
Best regards,
Marek Vasut