Add macros to ease our life with independent CONFIGs between U-Boot and SPL
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest0 of 15 patches 0 repliesNew
- v10 of 16 patches 0 repliesSuperseded
Patches in v2 No applies recorded yet
None of the 15 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [U-Boot] [PATCH v2 00/15] Add macros to ease our life with independent CONFIGs between U-Boot and SPL
Quoted 7 lines · Simon Glass
Hi,
Quoted 2 lines · Masahiro Yamada
I hope this series will make our life easier.
Quoted 8 lines
I agree. This seems like a clever solution to the problem.
As you probably saw on the other thread, Scott Wood suggested that separate configs for U-Boot proper and SPL are better. There are definitely arguments either way.
I feel that joining them up has a few advantages:
- Single configuration step (no multiple 'make menuconfig' steps)
How often do people use menuconfig versus a board's defconfig? Even when they do, do they need to modify the SPL's config or just the main U-Boot?
Quoted 1 line
- Supports the common case where there is no need for a separate SPL option
With separate configs there would not be separate options. With a unified config there are separate SPL options, even if it doesn't require a separate makefile line.
Quoted 1 line
- Single configuration file to maintain / patch
For defconfigs it was already merged.
Quoted 2 lines
- Avoids needing to create options that depend on SPL, or !SPL and thus exist in SPL but not in U-Boot proper (I find this confusing)
Instead you have special SPL symbols that exist but don't mean anything in U- Boot proper...
Quoted 6 lines
The $(SPL) syntax may be a little clumsy but it is pretty clear what is going on. Also if we come up with something else in the future it should be fairly easy to revisit the sits and change them.
I believe the common case is that most board options are the same for SPL and U-Boot proper.
Most SPLs have a command shell and all the associated bells and whistles selected, plus a full set of drivers?
Quoted 2 lines
By my count we have about 40
CONFIG_SPL_..._SUPPORT optoins at present.
Those were added before we had split configs. With split configs they could go away.
Quoted 3 lines
Compared to the thousands
of options int the source this is fairly small. So we should optimise for the common case.
40 versus zero? What special thing would need to be done to the "thousands of options" with split configs?
How is TPL supposed to be handled? Are the various SPL options that are set one way #ifdef CONFIG_TPL_BUILD and differently if not doomed to stay in the board config file and never get kconfigized?
-Scott