2015-08-07 8:08 GMT+09:00 Scott Wood <scottw...@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.masah...@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. -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot