On Sun, Jun 30, 2019 at 04:20:41PM +0200, Marek Vasut wrote: > On 6/30/19 4:17 PM, Tom Rini wrote: > > 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. > > So, U-Boot spits out that it cannot find kernel image and refuses to > boot, do we also import Linux into the codebase because of that ?
It's a build time warning, because we're generating the image that people expect to use to initialize their device and we must not produce images that will brick the system. > But Linux also spits that it cannot find init and refuses to boot. Do we > import systemd/sysvinit/upstart/... because of that ? > > No, we do not. That's what build systems like OE or buildroot or whatnot > are for. If you want to assemble your image by hand, that's also fine, > surely you should be capable of replicating what the documentation / OE > / buildroot recipe suggests. You're not suggesting OE / buildroot for day to day development of U-Boot are you? > > 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. > > IMO ATF is completely separate from U-Boot and can be updated > separately, just like Linux, so I don't see how this would help. > Update the READMEs if you want, that would help the most I think. If you don't see how it would help then I think you need to broaden your development horizons. I can see how "make all" producing an image that won't brick your device being helpful. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
