From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Sat, 29 Jun 2019 20:38:58 +0200 Subject: [U-Boot] What if ATF can be part of U-Boot source, like SPL? In-Reply-To: References: Message-ID: <4f38452c-9bea-7cda-9866-42f46eb29d21@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 6/29/19 5:02 PM, 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. You are free to do so locally, but following this train of thought would possibly lead to putting Linux kernel sources in the same repository too, and possible the entire userspace. Mixing two completely different projects, with different goals, makes zero sense. > 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? I agree with Mark, SPL and U-Boot share a lot of code. ATF and U-Boot share nothing, in fact, from what I was told, ATF was designed to be explicitly non-GPL, to make it easier for vendors to take the ATF code and close source it. Hence, ATF cannot import any U-Boot code and reimplements everything from scratch. > 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? See above. > This would ultimately avoid out-off-tree ATF builds with associated > variable exporting during u-boot builds. See the Linux + userspace argument. > 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. U-Boot code should ideally be GPLv2, other licenses should be an exception. > 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? IMO the better solution here would be to take the BL2 hardware init code and put it into SPL. Then you won't need the ATF BL1/BL2 hardware init, which is the bulk of what ATF does on many platforms. If you need resident services, BL31, either implement some sort of PSCI-like support into U-Boot (possibly alongside SPL/TPL/U-Boot proper), or build it from ATF sources. -- Best regards, Marek Vasut