2015-08-07 8:08 GMT+09:00 Scott Wood scottwood@freescale.com:
On Mon, 2015-08-03 at 07:59 -0600, Simon Glass wrote:
Hi,
On 1 August 2015 at 07:14, Masahiro Yamada yamada.masahiro@socionext.com wrote:
I hope this series will make our life easier.
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?
It often happened when I changed SoC-specific features.
- 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.
- Single configuration file to maintain / patch
For defconfigs it was already merged.
Yes, with mysterious "+S:" prefixes. Internally, it was divided into separate defconfigs by a shell script before going into Kconfig.
- 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...
True, but on the contrary, CONFIG options without CONFIG_SPL_ is meaningful for SPL.
For example,
common/spl/spl_nand.c is only linked into SPL, but it references CONFIG_SYS_TEXT_BASE.
SPL needs CONFIG_SPL_TEXT_BASE to link itself, and also wants to know CONFIG_SYS_TEXT_BASE for loading the U-boot proper image.
The single .config is sometimes helpful for inter-action between U-boot proper and SPL.
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?
Simon did not go as far as saying that.
The command shell should be available on U-Boot proper, I think.
But, yeah, Freescale finally enabled the command shell on SPL.
commit ed39218238cf8ca312b0a14a83848af055394c68 (common: spl: Add interactive DDR debugger support for SPL image)
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.
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?
At some point, the order of SPL and TPL should be swapped.
TPL (Tiny Program Loader) -> SPL -> U-Boot
Then, TPL will become an ad-hoc loader, disabling most of CONFIGs. Implementation is Do-It-Yourself things under you board directory or somewhere.