[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