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

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

[Jagan Teki]

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?

Jagan,
Amarula Solutions India.

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

[Mark Kettenis]

> From: Jagan Teki <jagan@amarulasolutions.com>
> Date: Sat, 29 Jun 2019 20:32:00 +0530
> 
> 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 disagree.  This strategy often leads to diverging codebases where
local improvements are not fed back upstream and/or not picking up
bug- and security fixes from upstream.

It also means that developers of non-ARM U-Boot platforms will have to
check out the full ATF 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?

SPL and U-Boot proper share a lot of code.  I'd say it is totally
different.

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

I don't see this as a huge issue.  For OpenBSD we already have the
(small) build infrastructure to handle this.

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

I don't think this makes a lot of sense.  Apart from what I wrote
above, some platforms use U-Boot as a payload for ATF (or TF-A as it
is called now) instead of the other way around.  It also makes it
difficult to do development on platforms where ATF sources have not
yet been upstreamed.

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

[Marek Vasut]

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

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

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

[Marek Vasut]

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.

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

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

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

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

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 ?

[...]

-- 
Best regards,
Marek Vasut

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

[André Przywara]

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.

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

[Wolfgang Denk]

Dear Jagan,

In message <CAMty3ZDwHbkNr28m8Q1Q_F716S1tCU0Fhn3aurpWvkK58WyCXA@mail.gmail.com> you 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?

You are wrong.  SPL has always been U-Boot internal code.

It may be true that some "external" early boot stages (line xloader)
have been replaced by SPL, but in no case such external code was
adaptes as is, and in the cases I am aware of this was original
U-Boot code anyway which hat just been forked off and maintained
out-of-tree.

But SPL is native U-Boot code only.

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

If U-Boot included a copy of the ATF code, it would have been forked
of the mainline ATF code at some point, so it is still out of tree.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Absolute: Independent, irresponsible. An absolute monarchy is one  in
which  the  sovereign  does  as  he pleases so long as he pleases the
assassins. Not many absolute monarchies are left, most of them having
been replaced by limited monarchies, where the soverign's  power  for
evil (and for good) is greatly curtailed, and by republics, which are
governed by chance.                                  - Ambrose Bierce

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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190630/157b4e8f/attachment.sig>

[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

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

[Michael Nazzareno Trimarchi]

On Sun, Jun 30, 2019 at 4:03 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>
> 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 ?
>

If we continue to import  Linux subsystem, we don't need to import
Linux ;). We need
a good rsync

Michael

> --
> Best regards,
> Marek Vasut

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

[Tom Rini]

On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> 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 ?

Just as you suggested Jagan look at other SoCs and how they assemble
images, I think you also need to take a wider look around.  The concept
of "take U-Boot, other firmware blobs, combine and mangle that" is
somewhat widely used.  It's not just sunxi that spits out a "can't find
ATF, this image won't boot!" warning.  If we can cleanly and solve that
by easy for users to add git submodules to their tree (I am _not_ saying
mainline U-Boot add submodules, to be clear) and they then get
functional images, that will help a lot of different groups.  We have a
lot of README files today in-tree telling people to jump through hoops
to get ATF and put it somewhere and run another tool on top.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190630/c1e0326b/attachment.sig>

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

[Marek Vasut]

On 6/30/19 4:17 PM, Tom Rini wrote:
> On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
>> 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 ?
> 
> Just as you suggested Jagan look at other SoCs and how they assemble
> images, I think you also need to take a wider look around.  The concept
> of "take U-Boot, other firmware blobs, combine and mangle that" is
> somewhat widely used.  It's not just sunxi that spits out a "can't find
> ATF, this image won't boot!" warning. 

So, U-Boot spits out that it cannot find kernel image and refuses to
boot, do we also import Linux into the codebase because of that ?

But Linux also spits that it cannot find init and refuses to boot. Do we
import systemd/sysvinit/upstart/... because of that ?

No, we do not. That's what build systems like OE or buildroot or whatnot
are for. If you want to assemble your image by hand, that's also fine,
surely you should be capable of replicating what the documentation / OE
/ buildroot recipe suggests.

> If we can cleanly and solve that
> by easy for users to add git submodules to their tree (I am _not_ saying
> mainline U-Boot add submodules, to be clear) and they then get
> functional images, that will help a lot of different groups.  We have a
> lot of README files today in-tree telling people to jump through hoops
> to get ATF and put it somewhere and run another tool on top.

IMO ATF is completely separate from U-Boot and can be updated
separately, just like Linux, so I don't see how this would help.
Update the READMEs if you want, that would help the most I think.

-- 
Best regards,
Marek Vasut

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

[Tom Rini]

On Sun, Jun 30, 2019 at 04:20:41PM +0200, Marek Vasut wrote:
> On 6/30/19 4:17 PM, Tom Rini wrote:
> > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> >> 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 ?
> > 
> > Just as you suggested Jagan look at other SoCs and how they assemble
> > images, I think you also need to take a wider look around.  The concept
> > of "take U-Boot, other firmware blobs, combine and mangle that" is
> > somewhat widely used.  It's not just sunxi that spits out a "can't find
> > ATF, this image won't boot!" warning. 
> 
> So, U-Boot spits out that it cannot find kernel image and refuses to
> boot, do we also import Linux into the codebase because of that ?

It's a build time warning, because we're generating the image that
people expect to use to initialize their device and we must not produce
images that will brick the system.

> But Linux also spits that it cannot find init and refuses to boot. Do we
> import systemd/sysvinit/upstart/... because of that ?
> 
> No, we do not. That's what build systems like OE or buildroot or whatnot
> are for. If you want to assemble your image by hand, that's also fine,
> surely you should be capable of replicating what the documentation / OE
> / buildroot recipe suggests.

You're not suggesting OE / buildroot for day to day development of
U-Boot are you?

> > If we can cleanly and solve that
> > by easy for users to add git submodules to their tree (I am _not_ saying
> > mainline U-Boot add submodules, to be clear) and they then get
> > functional images, that will help a lot of different groups.  We have a
> > lot of README files today in-tree telling people to jump through hoops
> > to get ATF and put it somewhere and run another tool on top.
> 
> IMO ATF is completely separate from U-Boot and can be updated
> separately, just like Linux, so I don't see how this would help.
> Update the READMEs if you want, that would help the most I think.

If you don't see how it would help then I think you need to broaden your
development horizons.  I can see how "make all" producing an image that
won't brick your device being helpful.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190630/620b7987/attachment.sig>

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

[Marek Vasut]

On 6/30/19 4:29 PM, Tom Rini wrote:
> On Sun, Jun 30, 2019 at 04:20:41PM +0200, Marek Vasut wrote:
>> On 6/30/19 4:17 PM, Tom Rini wrote:
>>> On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
>>>> 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 ?
>>>
>>> Just as you suggested Jagan look at other SoCs and how they assemble
>>> images, I think you also need to take a wider look around.  The concept
>>> of "take U-Boot, other firmware blobs, combine and mangle that" is
>>> somewhat widely used.  It's not just sunxi that spits out a "can't find
>>> ATF, this image won't boot!" warning. 
>>
>> So, U-Boot spits out that it cannot find kernel image and refuses to
>> boot, do we also import Linux into the codebase because of that ?
> 
> It's a build time warning, because we're generating the image that
> people expect to use to initialize their device and we must not produce
> images that will brick the system.

Some systems without serial console would be considered bricked if Linux
doesn't boot too, so that's really not a good argument.

If you ignore build-time warning and your system fails to boot, well,
there is no helping you.

>> But Linux also spits that it cannot find init and refuses to boot. Do we
>> import systemd/sysvinit/upstart/... because of that ?
>>
>> No, we do not. That's what build systems like OE or buildroot or whatnot
>> are for. If you want to assemble your image by hand, that's also fine,
>> surely you should be capable of replicating what the documentation / OE
>> / buildroot recipe suggests.
> 
> You're not suggesting OE / buildroot for day to day development of
> U-Boot are you?

I think you can roll a script which will build ATF for you, surely
that's not hard.

If you ignore the build process warnings and the result bricks your
system, there's really no helping here.

And since we're on the topic of bundling blobs, shall we also add a
submodule for intel fsp for example ? Since that's needed for x86 and
without that, the platform won't boot. And what if some blobs are still
tracked in SVN or only available as HTTP(s) downloads ?

>>> If we can cleanly and solve that
>>> by easy for users to add git submodules to their tree (I am _not_ saying
>>> mainline U-Boot add submodules, to be clear) and they then get
>>> functional images, that will help a lot of different groups.  We have a
>>> lot of README files today in-tree telling people to jump through hoops
>>> to get ATF and put it somewhere and run another tool on top.
>>
>> IMO ATF is completely separate from U-Boot and can be updated
>> separately, just like Linux, so I don't see how this would help.
>> Update the READMEs if you want, that would help the most I think.
> 
> If you don't see how it would help then I think you need to broaden your
> development horizons.  I can see how "make all" producing an image that
> won't brick your device being helpful.

I worked with ATF on NXP, R-Car and Xilinx platforms and got over 100
patches in it. I don't see any from you. I think you should slow down.

Each of the platforms have different ways of deploying the ATF binaries,
and they are generally not tied to U-Boot in any way. So I really don't
see how this would help, compared to following documentation and copying
the ATF binary over (if needed). A few lines of script can do just that.

-- 
Best regards,
Marek Vasut

[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

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

[Simon Glass]

Hi,

On Tue, 2 Jul 2019 at 11:42, Marek Vasut <marek.vasut@gmail.com> wrote:
>
> 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.

I have been avoiding this thread but today I attended a talk on ATF
and ARM's approach in general. ARM seems to be moving towards an
approach of providing increasingly complex source code to add more
layers of security software to fully round out two mostly separate
worlds (secure and normal).

Oddly enough Intel was also there talking about how they are breaking
things down into pieces and slowly releasing more things into the open
source world.

I came away with the impression that the two companies are going in
different directions. ARM seems to be heading where Intel was and
Intel is heading back. This is a gross simplification of course.

To me it seems that the following scenario might play out:

1. ARM releases new ATF versions as source drops that firmware
projects like U-Boot expected to take. In fact, not even U-Boot...this
is just users picking up whatever they find

2. ATF keeps getting more complex, adding its own drivers for serial,
storage, etc., duplicating and perhaps conflicting with those in
U-Boot

3. Over time we end up with binary blobs on ARM that are every bit as
impenetrable as what Intel used to have

4. Firmware security and open-sourceness suffers, overall.

One approach might be for ATF to split into a library which can be
linked into a new U-Boot phase and a driver/init bit that could be
used for other bootloaders, whatever they might be.

But in the meantime, I think it makes more sense to incorporate the
relevant parts of ATF into U-Boot and maintain them there, only for
the platforms that U-Boot supports. If ATF starts using GUIDs and the
like, we at least have somewhere to hide :-)

So overall I support Jagan's proposal based on the current status quo.

Regards,
Simon

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

[Masahiro Yamada]

On Sun, Jun 30, 2019 at 11:20 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>
> On 6/30/19 4:17 PM, Tom Rini wrote:
> > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> >> 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 ?
> >
> > Just as you suggested Jagan look at other SoCs and how they assemble
> > images, I think you also need to take a wider look around.  The concept
> > of "take U-Boot, other firmware blobs, combine and mangle that" is
> > somewhat widely used.  It's not just sunxi that spits out a "can't find
> > ATF, this image won't boot!" warning.
>
> So, U-Boot spits out that it cannot find kernel image and refuses to
> boot, do we also import Linux into the codebase because of that ?
>
> But Linux also spits that it cannot find init and refuses to boot. Do we
> import systemd/sysvinit/upstart/... because of that ?
>
> No, we do not. That's what build systems like OE or buildroot or whatnot
> are for. If you want to assemble your image by hand, that's also fine,
> surely you should be capable of replicating what the documentation / OE
> / buildroot recipe suggests.


I agree with Marek.
U-Boot should be independent.

I do not like the git-submodule approach.
Jagan's proposal..., no way!




--
Best Regards
Masahiro Yamada

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

[Andre Przywara]

On Tue, 3 Sep 2019 19:17:14 -0700
Simon Glass <sjg@chromium.org> wrote:

Hi Simon,

> On Tue, 2 Jul 2019 at 11:42, Marek Vasut <marek.vasut@gmail.com> wrote:
> >
> > 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.  
> 
> I have been avoiding this thread but today I attended a talk on ATF
> and ARM's approach in general. ARM seems to be moving towards an
> approach of providing increasingly complex source code to add more
> layers of security software to fully round out two mostly separate
> worlds (secure and normal).
> 
> Oddly enough Intel was also there talking about how they are breaking
> things down into pieces and slowly releasing more things into the open
> source world.
> 
> I came away with the impression that the two companies are going in
> different directions. ARM seems to be heading where Intel was and
> Intel is heading back. This is a gross simplification of course.
> 
> To me it seems that the following scenario might play out:
> 
> 1. ARM releases new ATF versions as source drops that firmware
> projects like U-Boot expected to take. In fact, not even U-Boot...this
> is just users picking up whatever they find
> 
> 2. ATF keeps getting more complex, adding its own drivers for serial,
> storage, etc., duplicating and perhaps conflicting with those in
> U-Boot

A bit like U-Boot, ATF can look quite differently on the various platforms:
- There are platforms like Arm's Juno or the fastmodel, where ATF does some loading. This is mostly for features like secure boot or secure payloads (OP-Tee). Typically we don't even use U-Boot primarily on those platforms (but EDK II instead).
- There are platforms (low end SoCs like Allwinner, Rockchip, for instance) which don't do any loading at all, actually rely on other code (SPL?) to load ATF itself.

So I don't see how this would duplicate effort or even conflict.

> 3. Over time we end up with binary blobs on ARM that are every bit as
> impenetrable as what Intel used to have

I am not quite sure I follow how you come from 2. to 3. Was there something in the presentation (I guess OSFC?) you are referring to?
In contrast to the x86 world the firmware is actually Open Source based, so you actually have a realistic chance to rebuild and/or verify it. If this is not true in a particular case, poke your vendor.
 
> 4. Firmware security and open-sourceness suffers, overall.
> 
> One approach might be for ATF to split into a library which can be
> linked into a new U-Boot phase and a driver/init bit that could be
> used for other bootloaders, whatever they might be.
> 
> But in the meantime, I think it makes more sense to incorporate the
> relevant parts of ATF into U-Boot and maintain them there, only for
> the platforms that U-Boot supports. If ATF starts using GUIDs and the
> like, we at least have somewhere to hide :-)

What are the relevant parts, exactly? Do you want to rip them out? Use git submodules?
For reasons I detailed before, I doubt the viability of the practical aspect alone.

But on top of that, I see that ATF and U-Boot address two separate areas: CPU initialisation and secure world management on one side, and a very versatile bootloader running in the non-secure world on the other. Keeping them separate allows a clean separation and lets each project focus on its core functionality.

I understand that this separation is not always as clear or as well implemented on every platform, but at least we should aim at this.

Cheers,
Andre,

> So overall I support Jagan's proposal based on the current status quo.
> 
> Regards,
> Simon

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

[Marek Vasut]

On 9/4/19 7:32 PM, Andre Przywara wrote:

[...]

>> I have been avoiding this thread but today I attended a talk on ATF
>> and ARM's approach in general. ARM seems to be moving towards an
>> approach of providing increasingly complex source code to add more
>> layers of security software to fully round out two mostly separate
>> worlds (secure and normal).
>>
>> Oddly enough Intel was also there talking about how they are breaking
>> things down into pieces and slowly releasing more things into the open
>> source world.
>>
>> I came away with the impression that the two companies are going in
>> different directions. ARM seems to be heading where Intel was and
>> Intel is heading back. This is a gross simplification of course.
>>
>> To me it seems that the following scenario might play out:
>>
>> 1. ARM releases new ATF versions as source drops that firmware
>> projects like U-Boot expected to take. In fact, not even U-Boot...this
>> is just users picking up whatever they find
>>
>> 2. ATF keeps getting more complex, adding its own drivers for serial,
>> storage, etc., duplicating and perhaps conflicting with those in
>> U-Boot
> 
> A bit like U-Boot, ATF can look quite differently on the various platforms:
> - There are platforms like Arm's Juno or the fastmodel, where ATF does some loading. This is mostly for features like secure boot or secure payloads (OP-Tee). Typically we don't even use U-Boot primarily on those platforms (but EDK II instead).
> - There are platforms (low end SoCs like Allwinner, Rockchip, for instance) which don't do any loading at all, actually rely on other code (SPL?) to load ATF itself.
> 
> So I don't see how this would duplicate effort or even conflict.

So why don't we put all the platform init code into U-Boot SPL, which
already has all the loading code and only load this ATF BL31 with SPL?

>> 3. Over time we end up with binary blobs on ARM that are every bit as
>> impenetrable as what Intel used to have
> 
> I am not quite sure I follow how you come from 2. to 3. Was there something in the presentation (I guess OSFC?) you are referring to?
> In contrast to the x86 world the firmware is actually Open Source based, so you actually have a realistic chance to rebuild and/or verify it. If this is not true in a particular case, poke your vendor.

I thought ATF was designed to be BSD-licensed to allow vendors to take
all the open source contributions, benefit from it, but also allow the
vendors to never release their changes if they so desire.

It seems like some platforms even went down this path already and only
released blobs, hence, no security fixes etc.

>> 4. Firmware security and open-sourceness suffers, overall.
>>
>> One approach might be for ATF to split into a library which can be
>> linked into a new U-Boot phase and a driver/init bit that could be
>> used for other bootloaders, whatever they might be.
>>
>> But in the meantime, I think it makes more sense to incorporate the
>> relevant parts of ATF into U-Boot and maintain them there, only for
>> the platforms that U-Boot supports. If ATF starts using GUIDs and the
>> like, we at least have somewhere to hide :-)
> 
> What are the relevant parts, exactly? Do you want to rip them out? Use git submodules?
> For reasons I detailed before, I doubt the viability of the practical aspect alone.
> 
> But on top of that, I see that ATF and U-Boot address two separate areas: CPU initialisation and secure world management on one side, and a very versatile bootloader running in the non-secure world on the other. Keeping them separate allows a clean separation and lets each project focus on its core functionality.
> 
> I understand that this separation is not always as clear or as well implemented on every platform, but at least we should aim at this.
Shouldn't the "secure world" management be as open as possible then ?

-- 
Best regards,
Marek Vasut

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

[Tom Rini]

On Wed, Sep 04, 2019 at 11:51:41AM +0900, Masahiro Yamada wrote:
> On Sun, Jun 30, 2019 at 11:20 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >
> > On 6/30/19 4:17 PM, Tom Rini wrote:
> > > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> > >> 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 ?
> > >
> > > Just as you suggested Jagan look at other SoCs and how they assemble
> > > images, I think you also need to take a wider look around.  The concept
> > > of "take U-Boot, other firmware blobs, combine and mangle that" is
> > > somewhat widely used.  It's not just sunxi that spits out a "can't find
> > > ATF, this image won't boot!" warning.
> >
> > So, U-Boot spits out that it cannot find kernel image and refuses to
> > boot, do we also import Linux into the codebase because of that ?
> >
> > But Linux also spits that it cannot find init and refuses to boot. Do we
> > import systemd/sysvinit/upstart/... because of that ?
> >
> > No, we do not. That's what build systems like OE or buildroot or whatnot
> > are for. If you want to assemble your image by hand, that's also fine,
> > surely you should be capable of replicating what the documentation / OE
> > / buildroot recipe suggests.
> 
> 
> I agree with Marek.
> U-Boot should be independent.
> 
> I do not like the git-submodule approach.
> Jagan's proposal..., no way!

To repeat myself, as I said in the thread at the time, I still do not
believe integration of ATF sources in-to U-Boot to be the right
approach.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190904/32cc207c/attachment.sig>

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

[André Przywara]

On 04/09/2019 18:56, Marek Vasut wrote:
> On 9/4/19 7:32 PM, Andre Przywara wrote:

Hi Marek,

>>> I have been avoiding this thread but today I attended a talk on ATF
>>> and ARM's approach in general. ARM seems to be moving towards an
>>> approach of providing increasingly complex source code to add more
>>> layers of security software to fully round out two mostly separate
>>> worlds (secure and normal).
>>>
>>> Oddly enough Intel was also there talking about how they are breaking
>>> things down into pieces and slowly releasing more things into the open
>>> source world.
>>>
>>> I came away with the impression that the two companies are going in
>>> different directions. ARM seems to be heading where Intel was and
>>> Intel is heading back. This is a gross simplification of course.
>>>
>>> To me it seems that the following scenario might play out:
>>>
>>> 1. ARM releases new ATF versions as source drops that firmware
>>> projects like U-Boot expected to take. In fact, not even U-Boot...this
>>> is just users picking up whatever they find
>>>
>>> 2. ATF keeps getting more complex, adding its own drivers for serial,
>>> storage, etc., duplicating and perhaps conflicting with those in
>>> U-Boot
>>
>> A bit like U-Boot, ATF can look quite differently on the various platforms:
>> - There are platforms like Arm's Juno or the fastmodel, where ATF does some loading. This is mostly for features like secure boot or secure payloads (OP-Tee). Typically we don't even use U-Boot primarily on those platforms (but EDK II instead).
>> - There are platforms (low end SoCs like Allwinner, Rockchip, for instance) which don't do any loading at all, actually rely on other code (SPL?) to load ATF itself.
>>
>> So I don't see how this would duplicate effort or even conflict.
> 
> So why don't we put all the platform init code into U-Boot SPL, which
> already has all the loading code and only load this ATF BL31 with SPL?

But this is what we actually do on those platforms: SPL is loaded by the
BootROM, PLLs and bus clocks are set up in SPL, then DRAM and MMC are
initialised, then we load U-Boot proper and ATF BL31.
BL31 does SMP init and errata workaround, and stays resident in EL3 to
provide PSCI services.

This BL31-only model is considered a perfectly fine way of using ATF.

>>> 3. Over time we end up with binary blobs on ARM that are every bit as
>>> impenetrable as what Intel used to have
>>
>> I am not quite sure I follow how you come from 2. to 3. Was there something in the presentation (I guess OSFC?) you are referring to?
>> In contrast to the x86 world the firmware is actually Open Source based, so you actually have a realistic chance to rebuild and/or verify it. If this is not true in a particular case, poke your vendor.
> 
> I thought ATF was designed to be BSD-licensed to allow vendors to take
> all the open source contributions, benefit from it, but also allow the
> vendors to never release their changes if they so desire.

BSD was simply chosen because basically every vendor said they would not
(be able to) use GPL licensed code for their firmware.
So it was BSD license or no (Open Source) firmware at all.
You might find that sad (I do), but that's what it is.

> It seems like some platforms even went down this path already and only
> released blobs, hence, no security fixes etc.

If you don't control the platform (servers), then you still have some
power as a customer to ask for releasing the firmware source. AFAIK this
is well understood by the vendors, as it is a good selling point against
x86.
And what I meant above is that this is in contrast to x86, where most of
the firmware ("BIOS") is proprietary and consists of many third-party
parts. So even when your system vendor wanted, it couldn't possibly
publish the code. With the core firmware being Open Source, you have a
much better chance of getting the source.
If the vendor doesn't want to give code away, it would just use
proprietary code anyway, probably of much worse quality.

>>> 4. Firmware security and open-sourceness suffers, overall.
>>>
>>> One approach might be for ATF to split into a library which can be
>>> linked into a new U-Boot phase and a driver/init bit that could be
>>> used for other bootloaders, whatever they might be.
>>>
>>> But in the meantime, I think it makes more sense to incorporate the
>>> relevant parts of ATF into U-Boot and maintain them there, only for
>>> the platforms that U-Boot supports. If ATF starts using GUIDs and the
>>> like, we at least have somewhere to hide :-)
>>
>> What are the relevant parts, exactly? Do you want to rip them out? Use git submodules?
>> For reasons I detailed before, I doubt the viability of the practical aspect alone.
>>
>> But on top of that, I see that ATF and U-Boot address two separate areas: CPU initialisation and secure world management on one side, and a very versatile bootloader running in the non-secure world on the other. Keeping them separate allows a clean separation and lets each project focus on its core functionality.
>>
>> I understand that this separation is not always as clear or as well implemented on every platform, but at least we should aim at this.

> Shouldn't the "secure world" management be as open as possible then ?

"as open as possible", yes. As mentioned above, this might probably be
as good as it can get.

Cheers,
Andre.

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

[Marek Vasut]

On 9/5/19 2:54 AM, André Przywara wrote:
> On 04/09/2019 18:56, Marek Vasut wrote:
>> On 9/4/19 7:32 PM, Andre Przywara wrote:
> 
> Hi Marek,

Hi,

>>>> I have been avoiding this thread but today I attended a talk on ATF
>>>> and ARM's approach in general. ARM seems to be moving towards an
>>>> approach of providing increasingly complex source code to add more
>>>> layers of security software to fully round out two mostly separate
>>>> worlds (secure and normal).
>>>>
>>>> Oddly enough Intel was also there talking about how they are breaking
>>>> things down into pieces and slowly releasing more things into the open
>>>> source world.
>>>>
>>>> I came away with the impression that the two companies are going in
>>>> different directions. ARM seems to be heading where Intel was and
>>>> Intel is heading back. This is a gross simplification of course.
>>>>
>>>> To me it seems that the following scenario might play out:
>>>>
>>>> 1. ARM releases new ATF versions as source drops that firmware
>>>> projects like U-Boot expected to take. In fact, not even U-Boot...this
>>>> is just users picking up whatever they find
>>>>
>>>> 2. ATF keeps getting more complex, adding its own drivers for serial,
>>>> storage, etc., duplicating and perhaps conflicting with those in
>>>> U-Boot
>>>
>>> A bit like U-Boot, ATF can look quite differently on the various platforms:
>>> - There are platforms like Arm's Juno or the fastmodel, where ATF does some loading. This is mostly for features like secure boot or secure payloads (OP-Tee). Typically we don't even use U-Boot primarily on those platforms (but EDK II instead).
>>> - There are platforms (low end SoCs like Allwinner, Rockchip, for instance) which don't do any loading at all, actually rely on other code (SPL?) to load ATF itself.
>>>
>>> So I don't see how this would duplicate effort or even conflict.
>>
>> So why don't we put all the platform init code into U-Boot SPL, which
>> already has all the loading code and only load this ATF BL31 with SPL?
> 
> But this is what we actually do on those platforms: SPL is loaded by the
> BootROM, PLLs and bus clocks are set up in SPL, then DRAM and MMC are
> initialised, then we load U-Boot proper and ATF BL31.
> BL31 does SMP init and errata workaround, and stays resident in EL3 to
> provide PSCI services.

Then why is there so much init code in ATF plat/ and drivers/ ? I think
that should rather be in the U-Boot SPL instead of being duplicated in ATF.

> This BL31-only model is considered a perfectly fine way of using ATF.
> 
>>>> 3. Over time we end up with binary blobs on ARM that are every bit as
>>>> impenetrable as what Intel used to have
>>>
>>> I am not quite sure I follow how you come from 2. to 3. Was there something in the presentation (I guess OSFC?) you are referring to?
>>> In contrast to the x86 world the firmware is actually Open Source based, so you actually have a realistic chance to rebuild and/or verify it. If this is not true in a particular case, poke your vendor.
>>
>> I thought ATF was designed to be BSD-licensed to allow vendors to take
>> all the open source contributions, benefit from it, but also allow the
>> vendors to never release their changes if they so desire.
> 
> BSD was simply chosen because basically every vendor said they would not
> (be able to) use GPL licensed code for their firmware.
> So it was BSD license or no (Open Source) firmware at all.
> You might find that sad (I do), but that's what it is.

There are quite a few GPL licensed bootloaders and they are doing quite
fine I think, so it's not that clear cut.

>> It seems like some platforms even went down this path already and only
>> released blobs, hence, no security fixes etc.
> 
> If you don't control the platform (servers), then you still have some
> power as a customer to ask for releasing the firmware source. AFAIK this
> is well understood by the vendors, as it is a good selling point against
> x86.

Every single time I asked a vendor for changes to BSD-licensed sources,
I either got silent treatment or was told off. Hence, I am not a fan of
BSD license at all.

> And what I meant above is that this is in contrast to x86, where most of
> the firmware ("BIOS") is proprietary and consists of many third-party
> parts. So even when your system vendor wanted, it couldn't possibly
> publish the code. With the core firmware being Open Source, you have a
> much better chance of getting the source.
> If the vendor doesn't want to give code away, it would just use
> proprietary code anyway, probably of much worse quality.

Considering how many various blobs recent ARM64 systems are growing
(e.g. DDR4 init is usually a blob, some "secure" firmwares are blobs and
so on), I don't think BSD licensed bootloader will help here.

>>>> 4. Firmware security and open-sourceness suffers, overall.
>>>>
>>>> One approach might be for ATF to split into a library which can be
>>>> linked into a new U-Boot phase and a driver/init bit that could be
>>>> used for other bootloaders, whatever they might be.
>>>>
>>>> But in the meantime, I think it makes more sense to incorporate the
>>>> relevant parts of ATF into U-Boot and maintain them there, only for
>>>> the platforms that U-Boot supports. If ATF starts using GUIDs and the
>>>> like, we at least have somewhere to hide :-)
>>>
>>> What are the relevant parts, exactly? Do you want to rip them out? Use git submodules?
>>> For reasons I detailed before, I doubt the viability of the practical aspect alone.
>>>
>>> But on top of that, I see that ATF and U-Boot address two separate areas: CPU initialisation and secure world management on one side, and a very versatile bootloader running in the non-secure world on the other. Keeping them separate allows a clean separation and lets each project focus on its core functionality.
>>>
>>> I understand that this separation is not always as clear or as well implemented on every platform, but at least we should aim at this.
> 
>> Shouldn't the "secure world" management be as open as possible then ?
> 
> "as open as possible", yes. As mentioned above, this might probably be
> as good as it can get.

I would very much prefer for those security components to have
guaranteed source availability, but with BSD license, this is not gonna
happen.

-- 
Best regards,
Marek Vasut

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

[André Przywara]

On Thu, 5 Sep 2019 14:26:41 +0200
Marek Vasut <marek.vasut@gmail.com> wrote:

Hi,

> On 9/5/19 2:54 AM, André Przywara wrote:
> > On 04/09/2019 18:56, Marek Vasut wrote:  
> >> On 9/4/19 7:32 PM, Andre Przywara wrote:  
> >>>> I have been avoiding this thread but today I attended a talk on ATF
> >>>> and ARM's approach in general. ARM seems to be moving towards an
> >>>> approach of providing increasingly complex source code to add more
> >>>> layers of security software to fully round out two mostly separate
> >>>> worlds (secure and normal).
> >>>>
> >>>> Oddly enough Intel was also there talking about how they are breaking
> >>>> things down into pieces and slowly releasing more things into the open
> >>>> source world.
> >>>>
> >>>> I came away with the impression that the two companies are going in
> >>>> different directions. ARM seems to be heading where Intel was and
> >>>> Intel is heading back. This is a gross simplification of course.
> >>>>
> >>>> To me it seems that the following scenario might play out:
> >>>>
> >>>> 1. ARM releases new ATF versions as source drops that firmware
> >>>> projects like U-Boot expected to take. In fact, not even U-Boot...this
> >>>> is just users picking up whatever they find
> >>>>
> >>>> 2. ATF keeps getting more complex, adding its own drivers for serial,
> >>>> storage, etc., duplicating and perhaps conflicting with those in
> >>>> U-Boot  
> >>>
> >>> A bit like U-Boot, ATF can look quite differently on the various platforms:
> >>> - There are platforms like Arm's Juno or the fastmodel, where ATF does some loading. This is mostly for features like secure boot or secure payloads (OP-Tee). Typically we don't even use U-Boot primarily on those platforms (but EDK II instead).
> >>> - There are platforms (low end SoCs like Allwinner, Rockchip, for instance) which don't do any loading at all, actually rely on other code (SPL?) to load ATF itself.
> >>>
> >>> So I don't see how this would duplicate effort or even conflict.  
> >>
> >> So why don't we put all the platform init code into U-Boot SPL, which
> >> already has all the loading code and only load this ATF BL31 with SPL?  
> > 
> > But this is what we actually do on those platforms: SPL is loaded by the
> > BootROM, PLLs and bus clocks are set up in SPL, then DRAM and MMC are
> > initialised, then we load U-Boot proper and ATF BL31.
> > BL31 does SMP init and errata workaround, and stays resident in EL3 to
> > provide PSCI services.  
> 
> Then why is there so much init code in ATF plat/ and drivers/ ? I think
> that should rather be in the U-Boot SPL instead of being duplicated in ATF.

Anything in particular you are looking at?
ATF handles more platforms that those just using the BL31 only approach.
Also there are platforms that don't even support U-Boot.
So those have more code in their plat/ directory, and bring their own
drivers.

> > This BL31-only model is considered a perfectly fine way of using ATF.
> >   
> >>>> 3. Over time we end up with binary blobs on ARM that are every bit as
> >>>> impenetrable as what Intel used to have  
> >>>
> >>> I am not quite sure I follow how you come from 2. to 3. Was there something in the presentation (I guess OSFC?) you are referring to?
> >>> In contrast to the x86 world the firmware is actually Open Source based, so you actually have a realistic chance to rebuild and/or verify it. If this is not true in a particular case, poke your vendor.  
> >>
> >> I thought ATF was designed to be BSD-licensed to allow vendors to take
> >> all the open source contributions, benefit from it, but also allow the
> >> vendors to never release their changes if they so desire.  
> > 
> > BSD was simply chosen because basically every vendor said they would not
> > (be able to) use GPL licensed code for their firmware.
> > So it was BSD license or no (Open Source) firmware at all.
> > You might find that sad (I do), but that's what it is.  
> 
> There are quite a few GPL licensed bootloaders and they are doing quite
> fine I think, so it's not that clear cut.

For which platforms? Servers? High end network appliances?

> >> It seems like some platforms even went down this path already and only
> >> released blobs, hence, no security fixes etc.  
> > 
> > If you don't control the platform (servers), then you still have some
> > power as a customer to ask for releasing the firmware source. AFAIK this
> > is well understood by the vendors, as it is a good selling point against
> > x86.  
> 
> Every single time I asked a vendor for changes to BSD-licensed sources,
> I either got silent treatment or was told off. Hence, I am not a fan of
> BSD license at all.

Yes, I can see that from your response and the answers down here ;-)
But as mentioned before: GPL was not an option for those components.

Cheers,
Andre.

> 
> > And what I meant above is that this is in contrast to x86, where most of
> > the firmware ("BIOS") is proprietary and consists of many third-party
> > parts. So even when your system vendor wanted, it couldn't possibly
> > publish the code. With the core firmware being Open Source, you have a
> > much better chance of getting the source.
> > If the vendor doesn't want to give code away, it would just use
> > proprietary code anyway, probably of much worse quality.  
> 
> Considering how many various blobs recent ARM64 systems are growing
> (e.g. DDR4 init is usually a blob, some "secure" firmwares are blobs and
> so on), I don't think BSD licensed bootloader will help here.
> 
> >>>> 4. Firmware security and open-sourceness suffers, overall.
> >>>>
> >>>> One approach might be for ATF to split into a library which can be
> >>>> linked into a new U-Boot phase and a driver/init bit that could be
> >>>> used for other bootloaders, whatever they might be.
> >>>>
> >>>> But in the meantime, I think it makes more sense to incorporate the
> >>>> relevant parts of ATF into U-Boot and maintain them there, only for
> >>>> the platforms that U-Boot supports. If ATF starts using GUIDs and the
> >>>> like, we at least have somewhere to hide :-)  
> >>>
> >>> What are the relevant parts, exactly? Do you want to rip them out? Use git submodules?
> >>> For reasons I detailed before, I doubt the viability of the practical aspect alone.
> >>>
> >>> But on top of that, I see that ATF and U-Boot address two separate areas: CPU initialisation and secure world management on one side, and a very versatile bootloader running in the non-secure world on the other. Keeping them separate allows a clean separation and lets each project focus on its core functionality.
> >>>
> >>> I understand that this separation is not always as clear or as well implemented on every platform, but at least we should aim at this.  
> >   
> >> Shouldn't the "secure world" management be as open as possible then ?  
> > 
> > "as open as possible", yes. As mentioned above, this might probably be
> > as good as it can get.  
> 
> I would very much prefer for those security components to have
> guaranteed source availability, but with BSD license, this is not gonna
> happen.
> 

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

[Matteo Carlini]

Hi Simon and all,

> I have been avoiding this thread but today I attended a talk on ATF and
> ARM's approach in general.

For the benefits of others, that was me talking at the OSFC conference (video and slides should appear soon here: https://osfc.io/talks/trustedfirmware-org-a-collaborative-effort-into-firmware-security-and-the-path-towards-standardized-open-source-firmware-on-arm).
Had a chat with Simon and Jagan afterwards, so repeating my answers here for the records.

> ARM seems to be moving towards an approach
> of providing increasingly complex source code to add more layers of security
> software to fully round out two mostly separate worlds (secure and normal).

The requirement of having more complex source code running in the Secure world comes from our partners (SoC vendors, ODMs, OSVs...Google included).
For example, multi-tenancy in the Secure world (the possibility of running multiple Trusted OSs owned by different vendors) on an Android phone is a real requirement raised by many manufacturers and by Google. Arm is trying to fulfil this requirement by providing both an architecture and a clean reference implementation to support this and to protect the Normal world from attacks (malicious code) running in the Secure world.
Worth noticing that all will be developed, reviewed and tested in public as part of the TrustedFirmware.org project, the new "home" of Trusted Firmware-A (TF-A, the former Arm Trusted Firmware).

> I came away with the impression that the two companies are going in
> different directions. ARM seems to be heading where Intel was and Intel is
> heading back. This is a gross simplification of course.

As explained verbally, Arm is going into the same direction it has always gone: open source every piece of software running on an Arm platform (from the very first line of code), including all the Power Management software implementation (PSCI into Trusted Firmware, SCMI into the SCP firmware project - https://github.com/ARM-software/SCP-firmware) and encouraging all our partners to do the same for their platforms ports.
You can run a full open source software stack on any Arm platform that has upstream support available and the direction is not going to change with more software running in the Secure world (Secure EL2 included)...it will just be some more open source software.

> 1. ARM releases new ATF versions as source drops that firmware projects like
> U-Boot expected to take. In fact, not even U-Boot...this is just users picking
> up whatever they find

That's an accurate description (apart from the fact that releases will be tagged by the TrustedFirmware.org community project, not by Arm as such). We have the Linux Kernel model in mind (despite the BSD license topic) and the requirement to reliably point to a precise Trusted Firmware version running on an Arm device, as much as you do with the Kernel. This is practically impossible today due to the number of different implementations deployed on every device by different manufacturers. And that's the problem we are trying to fix.

> 2. ATF keeps getting more complex, adding its own drivers for serial, storage,
> etc., duplicating and perhaps conflicting with those in U-Boot

Apart from platforms support, the additional software to be developed in the Secure world is meant to implement Arm architecture and Arm specifications, not to bloat the code with unnecessary drivers...moreover, as Andre pointed out, Trusted Firmware runs on many non-U-Boot platforms, so there *might* be overlaps for things that are needed elsewhere.

> 3. Over time we end up with binary blobs on ARM that are every bit as
> impenetrable as what Intel used to have
> 4. Firmware security and open-sourceness suffers, overall.

That's definitely not our goal. We'd like to ease the audit/certification process and ultimately the security of the highest privileged firmware running on Arm, by encouraging our partners to adopt a clean EL3 (and in the future Secure EL2) generic firmware (ideally a specific x.y version) and moving all their proprietary/platform code elsewhere in lowest exception levels. That's the goal of the architecture we are working on (described in my talk) and we believe it would ultimately help the Arm firmware security ecosystem in general.
If by doing so, partners will still end up deploying binary blobs (signed, certified, whatever), these would be built from the corresponding open source project.
I don't see how the situation would be any worst that it is today with proprietary EL3 firmware binaries deployed everywhere (despite all the originating core code being upstream!). From my point of view, it could only evolve towards a more open situation...every partner that we gain on this approach will be a partner bought into more open firmware and increased security.

> But in the meantime, I think it makes more sense to incorporate the relevant
> parts of ATF into U-Boot and maintain them there, only for the platforms
> that U-Boot supports.
[...]
> So overall I support Jagan's proposal based on the current status quo.

Bear in mind that TF-A is undergoing huge developments and it's definitely a well alive and dynamic project, it's not a stable library as libfdt to be copied and held for years with little maintenance.
We are adding support for all new Arm architectural security features (Armv8.3 Pointer Authentication, Armv8.5 BTI, Armv8.4 Secure EL2) for devices that will come out soon on the market.
Any out of tree fork would need to be maintained quite frequently and stay closely up to date with all recent changes.

The way we cope with the process of building and combining multiple firmware projects in Arm is to have some build/manifest scripts that pulls everything together from appropriate repos and build it in the right order with the proper options (have a look at the instructions here https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/about/docs/user-guide.rst)

An alternate idea Simon have briefly proposed verbally to me is to harmonise TF-A and U-boot around the Kconfig build system. Simon feel free to expose it properly.
We are currently investigating the use of Kconfig for TF-A since the current build system is not scalable any longer, so that's something we can surely discuss together with the TF-A community.

And...yes, there's an ever growing community around Trusted Firmware, both for A-class and M-class, that goes well beyond Arm and very much favour collaboration and feedbacks from adopters, contributors, partners...you can reach the TF-A one here tf-a at lists.trustedfirmware.org, others here https://lists.trustedfirmware.org/mailman/listinfo.

Thanks
Matteo

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.