From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Sun, 30 Jun 2019 10:17:26 -0400 Subject: [U-Boot] What if ATF can be part of U-Boot source, like SPL? In-Reply-To: <848513cc-1bb1-2a81-4a50-01bfa73b271d@gmail.com> References: <20190630135703.GZ9388@bill-the-cat> <848513cc-1bb1-2a81-4a50-01bfa73b271d@gmail.com> Message-ID: <20190630141726.GA9388@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: