On Wed, Aug 11, 2021 at 08:11:41AM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 11 Aug 2021 at 08:02, Tom Rini trini@konsulko.com wrote:
On Wed, Aug 11, 2021 at 06:56:31AM -0600, Simon Glass wrote: [snip]
Having thought a bit more, perhaps we have the wrong attitude to Kconfig. The CONFIG() macro I am talking about works by building an xxx or SPL_xxx config. If we have separate autoconf.h files for each phase (autoconf_spl.h etc.) then we don't actually need this. We just need to include the correct file. Any SPL_xxx config can be written as xxx. Similarly the Makefile rules can drop the $(P) I was proposing.
We can, in fact, generate separate autoconf.h files for each phase today, with no other changes. Unless I am missing something...?
If we can spit out {spl_,tpl_,}autoconf.h files that might help a bit. But would it help with the recent case of SPL has SATA+AHCI+!PCI while full U-Boot has SATA+AHCI+!PCI AND SATA+AHCI+PCI ? Today we can't support the SPL case without adding the handful of SPL_xxx symbols so that we can say we have SATA+AHCI without PCI.
My thought is that:
- where there is no SPL_xxx symbol, it we would have CONFIG_xxx=y in
all autoconf.h files
- where there is an SPL_xxx symbol, it we would only have it in
spl_autoconf.h if the SPL_xxx symbol is enabled
So it does not reduce the power/flexibility of what we have to cover all cases. It is just a phase-specific way of presenting the configs to the build, so we can do:
obj-$(CONFIG_FOO) += foo.o
as well as
if (CONFIG(FOO))
I'm still thinking about Kconfig. To me it seems that separating the phases so completely is giving up quite a bit. There is no-longer a unified build, so dependencies between phases may become a problem. I think in fact our problem is the use of SPL_ and TPL_ prefixes on Kconfigs, which you have highlighted. Perhaps we just shouldn't do that. It would be nice if kconfig could support multiple interrelated build phases and output a separate autoconf.h for each one.
What are the dependencies we have between phases? You've mentioned bloblist, but to me that's like BOARD_INIT and MISC_INIT_R and all of the other things you need to have select'd on a platform because they're non-optional.
And I'm really not seeing now how we would support the example I gave as for them SPL with SATA+AHCI+PCI is not desired nor possible. I asked. The answer was no, don't want it. Or do you really just mean that if we had spl_autoconf.h the only thing that would change is that we would never test on CONFIG_SPL_xxx only CONFIG_xxx, but we would still need to Kconfig SPL_xxx?