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




--
Best Regards
Masahiro Yamada