On Sun, Jun 30, 2019 at 4:03 PM Marek Vasut marek.vasut@gmail.com 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 ?
If we continue to import Linux subsystem, we don't need to import Linux ;). We need a good rsync
Michael
-- Best regards, Marek Vasut