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.va...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot