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