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 ? -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
