On 29/06/2019 16:02, 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.
I am not sure this is really true. If I get you right, you want to mirror and sync the ATF source into the U-Boot tree, which sounds like a pain: - ATF development is quite dynamic, with just shy of 1000 commits alone this year. This would mean constant churn of keeping the source up-to-date. - The overlap of U-Boot and ATF users is not that big: ATF has support for a lot more platforms (most of them typically paired with EDK-2), also provides a lot more code than U-Boot platforms typically use: BL1, BL2, secure payload support, etc. I am not sure a lot of people are happy if we add tons of code lines to the repo which will never be used.
This is what exactly it was done for SPL, if I'm not wrong.
But this SPL/proper code sharing does not come without a price. Think about the problems with DM and the often limited SPL code size, which causes us some headaches. Also I wonder how much code they actually share? Thinking about DRAM init, the separate SPI flash driver for Allwinner and all those #ifdefs everywhere. I am not questioning the current design, but just want to point out that this might not be best thing since sliced bread.
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
Minimal PSCI? TF-A is the full fledged reference implementation of PSCI, it always supports the newest revisions, including Spectre/Meltdown support. This alone is a killer argument for me to use ATF.
, 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?
So do you want to just import the part of ATF that we need? That sounds like a pain to start off first and will even induce more pain once ATF changes something. They are doing constant refactoring and increasing the code sharing, so ripping something out of there will not end well.
This would ultimately avoid out-off-tree ATF builds with associated variable exporting during u-boot builds.
So what is the problem you are seeing with the current approach, exactly? Is it just that it's annoying to have an external binary glued in? I don't buy that this is a real problem.
More over this idea would also help to design a single-step bootloader where it can't depends on out-of-tree sources.
What do you mean with single-step bootloader, exactly? I think it's actually an advantage to have the steps in separate projects. So every platform can use a common ATF, and they have a choice of U-Boot and EDK-2, for instance. Or skip the extra loader altogether, just use the SPL and launch the kernel from ATF directly. I hacked this once for Allwinner based on this: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/r...
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?
Apart from the practical issues I outlined above I don't see the architectural merit of merging in ATF. What actually would make more sense is to merge the SPL into ATF, so that we have a clean separation between platform initialisation and boot loader. But this also has a lot of practical issues, and as mentioned I don't really see that the current process is that painful that it demands such changes.
Cheers, Andre.