Hi Scott,
On Tue, 24 Feb 2015 18:17:59 -0600 Scott Wood scottwood@freescale.com wrote:
On Tue, 2015-02-24 at 16:20 +0900, Masahiro Yamada wrote:
Hi Scott,
On Mon, 23 Feb 2015 19:22:51 -0600 Scott Wood scottwood@freescale.com wrote:
On Fri, 2015-02-20 at 14:24 +0900, Masahiro Yamada wrote:
When Kconfig for U-boot was examined, one of the biggest issues was how to support multiple images (Normal, SPL, TPL). There were actually two options, "single .config" and "multiple .config". After some discussions and thought experiments, I chose the latter, i.e. to create ".config", "spl/.config", "tpl/.config" for Normal, SPL, TPL, respectively.
It is true that the "multiple .config" strategy provided us the maximum flexibility and helped to avoid duplicating CONFIGs among Normal, SPL, TPL, but I have noticed some fatal problems:
[1] It is impossible to share CONFIG options across the images. If you change the configuration of Main image, you often have to adjust some SPL configurations correspondingly. Currently, we cannot handle the dependencies between them. It means one of the biggest advantages of Kconfig is lost.
Sharing can happen in the defconfig with "+S:"...
Yes, it can as for "make *_defconfig".
If we modify some options in .config for example by "make menuconfig", we also modify some in spl/.config correspondingly.
Users are responsible for configure .config and spl/.config in sync in the sane combination.
What sort of dependencies are people wanting? Would it be possible to modify kconfig to import SPL .config into the main config (or vice versa?) with a name prefix so that dependencies could happen, without sacrificing the ability to set symbols independently?
To have independent symboles coexist in a single .config, I can only suggest to duplicate options like CONFIG_FOO=0x100 CONFIG_SPL_FOO=0x200 CONFIG_TPL_FOO=0x300
What I meant was a way to keep the configs separate, but automatically import the CONFIG_FOO from the SPL .config as CONFIG_SPL_FOO (or some other prefix that doesn't conflict with SPL-specific options).
What is the benefit of doing this?
Or as Ian suggested, have only the main config be user-editable, but still let select/depends turn certain things on/off for the auto-generated SPL config.
I guess it is possible for boolean options, but impossible to set hex/int options independently.
How many hex/int options are there, that need to be different in SPL versus the main U-Boot? Having a few CONFIG_SPL_xxx for those is better than having a bunch.
OK. But, I do not think we need to tweak the Kconfig just for saving boolean options.
BTW, Ian's idea had been already achieved by include/config_uncmd_spl.h
So, the answer is to avoid kconfig and go back to using the preprocessor for configuration? :-(
I am not saying I prefer the preprocessor.
Indeed, include/config_uncmd_spl.h is ugly, so I'd like to propose a better solution.
If we introduce CONFIG_SPL_DM, for example, the ifdef conditional in source files will be like this:
#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_DM)) || \ (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_DM))
[Driver Model Code]
#else [Non Driver Model Code] #endif
This is too ugly to be written in each conditional.
So, I want to describe like this:
#if IS_ENABLED_CONFIG(DM) [Driver Model Code] #else [Non Driver Model Code] #endif
I will post some patches later on.
[2] It is too painful to change both ".config" and "spl/.config". Sunxi guys started to work around this problem by creating a new configuration target. Commit cbdd9a9737cc (sunxi: kconfig: Add %_felconfig rule to enable FEL build of sunxi platforms.) added "make *_felconfig" to enable CONFIG_SPL_FEL on both images. Changing the configuration of multiple images in one command is a generic demand. The current implementation cannot propose any good solution about this.
How about defconfig fragments? Instead of having script infrastructure specifically for CONFIG_SPL_FEL, merge a fragment containing "+S:CONFIG_SPL_FEL".
Do you mean something like this? U-boot proper : common/.config + .config SPL : common/.config + spl/.config TPL : common/.config + tpl/.config
No, I meant having a fragment containing only "+S:CONFIG_SPL_FEL" that could be merged into any other config.
So, the fragment is something like the _common_ .config, right?
[3] Kconfig files are getting ugly and difficult to understand. Commit b724bd7d6349 (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to Kconfig) has sprinkled "if !SPL_BUILD" over the Kconfig files.
It seems like the root cause of this sprinkling is wanting to use default y to avoid touching a bunch of defconfig files, but not wanting to do the default y at the toplevel Kconfig. Maybe better tooling for bulk defconfig updates would help.
Yes. If we could move the default settings into defconfig files (and defconfig is just for that purpose), this problem would go away. But, in the duscussion with Simon and Alexey, we understood maintaining many defconfigs in sync is a pain.
I think that's a problem that needs to be solved regardless of SPL.
Agree. I think we can live the defaults in Kconfig, but I am still searching for a different solution.
In any case, couldn't you do CONFIG_SPL_DM currently, by making DM depend on "!SPL_BUILD || SPL_DM", without fundamentally changing the SPL kconfig infrastructure?
As for the Driver Model options, the dependency descriptions will get ugly, but we won't carry them so long. In a long run, all the boards will be converted and eventually CONFIG_DM will bocome the default.
...so it's not a very good example of why the current situation must change.
Right, but we still have many other options that can be enabled on SPL.
Why do symbols like LOCALVERSION and CC_OPTIMIZE_FOR_SIZE depend on ! SPL_BUILD?
These two options are used by the top-level Makefile and it is automatically propagated to spl/*.
It is harmless to define them again in spl/.config, but meaningless.
...so not all of the existing !SPL_BUILD instances in Kconfig need to be there.
[4] The build system got more complicated than it should be. To adjust Linux-originated Kconfig to U-Boot, the helper script "scripts/multiconfig.sh" was introduced. Writing a complicated text processor is a shell script sometimes caused problems.
Now I believe the "single .config" will serve us better. With it, all the problems above would go away. Instead, we will have to add some CONFIG_SPL_* (and CONFIG_TPL_*) options such as CONFIG_SPL_DM, but we will not have much. Anyway, this is what we do now in scripts/Makefile.spl.
I had been hoping that the split configs would let us get rid of many of the CONFIG_SPL_* options that we already have.
How will TPL be handled? Are you going to duplicate all the SPL symbols? Or just avoid ever kconfigizing them?
Not all, but I expect some duplicated CONFIG_TPL_* such as CONFIG_TPL_TEXT_BASE.
I'm not talking about TEXT_BASE. I'm talking about stuff like this:
We have to add some CONFIG_TPL_*, but we will just have 20.
#ifdef CONFIG_TPL_BUILD #define CONFIG_SPL_NAND_BOOT #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NAND_INIT #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_I2C_SUPPORT #define CONFIG_SPL_NAND_SUPPORT #define CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT #define CONFIG_SPL_COMMON_INIT_DDR #define CONFIG_SPL_MAX_SIZE (128 << 10) #define CONFIG_SPL_TEXT_BASE 0xf8f81000 #define CONFIG_SYS_MPC85XX_NO_RESETVEC #define CONFIG_SYS_NAND_U_BOOT_SIZE (832 << 10) #define CONFIG_SYS_NAND_U_BOOT_DST (0x11000000) #define CONFIG_SYS_NAND_U_BOOT_START (0x11000000) #define CONFIG_SYS_NAND_U_BOOT_OFFS ((128 + 128) << 10) #elif defined(CONFIG_SPL_BUILD) #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TEXT_BASE 0xff800000 #define CONFIG_SPL_MAX_SIZE 4096 #define CONFIG_SYS_NAND_U_BOOT_SIZE (128 << 10) #define CONFIG_SYS_NAND_U_BOOT_DST 0xf8f80000 #define CONFIG_SYS_NAND_U_BOOT_START 0xf8f80000 #define CONFIG_SYS_NAND_U_BOOT_OFFS (128 << 10) #endif
If symbols like CONFIG_SPL_I2C_SUPPORT or CONFIG_SPL_COMMON_INIT_DDR get kconfigized, how would you handle them being in TPL but not SPL?
We can add CONFIG_TPL_* if necessary. As I said, if we swap the order of SPL and TPL, we will be able to save CONFIG_TPL_* defines.
Currently, U-Boot runs SPL, TPL, and U-Boot proper in this order, but in hindsight, it might have been better to run TPL, SPL, and U-Boot proper, in this order.
TPL is just makefile infrastructure for inserting an extra stage. It doesn't refer to the contents.
In 4KB memory footprint, it is impossible to include Driver Model. It would be a really ad-hoc implementation.
"Is", not "would be". And this applies to some SPL targets without TPL as well.
In the former order, we need CONFIG_TPL_DM, but in the latter, we can save it.
I know TPL means "Third Program Loader", but can we perhaps swap the order if we assume TPL is the abbreviation of "Tiny Program Loader" ?
If you redefine TPL to mean SPL that doesn't use certain code, you'll end up with targets that have TPL but no SPL. Are you sure this is simplifying anything?
Sorry, I can't get it. What I expect is like follows:
CONFIG_TPL still depends on CONFIG_SPL.
We have three options for the boot procedure:
[1] U-Boot-proper (CONFIG_SPL is not defined)
[2] SPL + U-Boot-proper (CONFIG_SPL is defined)
[3] TPL + SPL + U-Boot-proper (CONFIG_SPL and CONFIG_TPL are defined)
The image size: TPL < SPL < U-Boot-proper
Driver Model and some other features are available on SPL if CONFIG_SPL_* is defined.
Almost no systematic infrastructure is available on TPL, so we will have very small number of CONFIG_TPL_*.
- Add some entries to include/config_uncmd_spl.h and the new file scripts/Makefile.uncmd_spl. Some CONFIG options that are not supported on SPL must be disabled because one .config is shared between SPL and U-Boot proper going forward. I know this is not a beautiful solution and I think we can do better, but let's see how much we will have to describe them.
How is uncmd_spl better than "!SPL_BUILD"?
We can use Kconfig as it is in Linux.
Not after this patch.
Right, I need to do more cleanups for that.
Best Regards Masahiro Yamada