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