[U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config
Masahiro Yamada (6): ARM: UniPhier: set CONFIG_SYS_MALLOC_F to the global default value malloc_f: fix broken .config caused by CONFIG_SYS_MALLOC_F malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len kconfig: switch to single .config configuration kconfig: remove unneeded dependency on !SPL_BUILD malloc_f: enable SYS_MALLOC_F by default if DM is on
Simon Glass (1): kconfig: Adjust ordering so that defaults work as expected
Kconfig | 32 +--- arch/arm/Kconfig | 7 +- arch/arm/cpu/arm1176/bcm2835/Kconfig | 6 +- arch/arm/cpu/armv7/exynos/Kconfig | 30 ++-- arch/arm/cpu/armv7/omap3/Kconfig | 12 +- arch/arm/cpu/armv7/s5pc1xx/Kconfig | 4 +- arch/arm/cpu/armv7/tegra-common/Kconfig | 20 ++- arch/arm/cpu/armv7/uniphier/Kconfig | 8 - arch/x86/Kconfig | 6 +- board/amcc/canyonlands/Kconfig | 8 - board/compulab/cm_t335/Kconfig | 6 +- board/gumstix/pepper/Kconfig | 6 +- board/isee/igep0033/Kconfig | 6 +- board/phytec/pcm051/Kconfig | 6 +- board/samsung/goni/Kconfig | 6 +- board/samsung/smdkc100/Kconfig | 6 +- board/silica/pengwyn/Kconfig | 6 +- board/ti/am335x/Kconfig | 12 +- common/Kconfig | 1 - config.mk | 5 + configs/ph1_ld4_defconfig | 2 +- configs/ph1_pro4_defconfig | 2 +- configs/ph1_sld8_defconfig | 2 +- doc/README.kconfig | 132 ++++------------ drivers/core/Kconfig | 16 +- drivers/mtd/nand/Kconfig | 6 +- dts/Kconfig | 1 - include/config_uncmd_spl.h | 13 ++ scripts/Makefile.autoconf | 36 +++-- scripts/Makefile.build | 3 +- scripts/Makefile.spl | 10 +- scripts/Makefile.uncmd_spl | 18 +++ scripts/multiconfig.sh | 261 +------------------------------- 33 files changed, 183 insertions(+), 512 deletions(-) create mode 100644 scripts/Makefile.uncmd_spl
It is true that malloc is necessary for Driver Model before relocation, but there is no good reason to reserve the malloc space more than enough. The default value 0x400 works well.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com Reviewed-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
arch/arm/cpu/armv7/uniphier/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index 1a47ac9..8fdef28 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -52,7 +52,7 @@ config SYS_MALLOC_F default y
config SYS_MALLOC_F_LEN - default 0x2000 + default 0x400
config CMD_PINMON bool "Enable boot mode pins monitor command"
Since commit b724bd7d6349 (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to Kconfig), the ".config" created by the configuration has been wrong.
For example, the following is a snippet of the ".config" generated by "make beaver_defconfig":
--------------->8----------------- CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_SYS_MALLOC_F is not set CONFIG_SYS_MALLOC_F_LEN=0x1800 # CONFIG_EXPERT is not set ---------------8<-----------------
CONFIG_SYS_MALLOC_F_LEN is supposed to depend on CONFIG_SYS_MALLOC_F (see the top level Kconfig), but the ".config" above is not actually following that dependency.
This is caused by two mistakes of commit b724bd7d6349.
[1] Wrong default value of CONFIG_SYS_MALLOC_F CONFIG_SYS_MALLOC_F is a boolean option, but its default value is set to 0x400.
[2] Missing "if SYS_MALLOC_F" in the default setting in each Kconfig For example, arch/arm/cpu/armv7/tegra-common/Kconfig has the line "default 0x1800" for SYS_MALLOC_F_LEN. It must be described as "default 0x1800 if SYS_MALLOC_F" to follow the dependency.
Those two bugs together create such a broken ".config".
Unfortunately, even if we correct both [1] and [2], the value of CONFIG_SYS_MALLOC_F_LEN is not set as we expect. The "default 0x1800 if SYS_MALLOC_F" would be simply ignored because the "default 0x400" in the top level Kconfig is parsed first.
Notice that if multiple default lines appear for the same CONFIG, the first one takes precedence.
This commit corrects [1] and [2] so as not to create a broken .config file in any cases. Note that the default values in arch/arm/cpu/armv7/tegra-common/Kconfig and arch/x86/Kconfig are not working at this moment. This will be solved by the next commit.
The default value 0x400 is redundant for OMAP, Exynos, UniPhier, etc. They can be simply removed.
There are still redundant "CONFIG_SYS_MALLOC_F_LEN=0x400" in many defconfig files, but this commit is not touching them.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com ---
Changes in v3: - Drop comments "This is meaningless ..." - Update commit description
Changes in v2: None
Kconfig | 1 - arch/arm/cpu/armv7/exynos/Kconfig | 3 --- arch/arm/cpu/armv7/omap3/Kconfig | 3 --- arch/arm/cpu/armv7/tegra-common/Kconfig | 2 +- arch/arm/cpu/armv7/uniphier/Kconfig | 3 --- arch/x86/Kconfig | 2 +- board/amcc/canyonlands/Kconfig | 4 ---- board/ti/am335x/Kconfig | 3 --- 8 files changed, 2 insertions(+), 19 deletions(-)
diff --git a/Kconfig b/Kconfig index 75bab7f..d40f9ec 100644 --- a/Kconfig +++ b/Kconfig @@ -58,7 +58,6 @@ config CC_OPTIMIZE_FOR_SIZE
config SYS_MALLOC_F bool "Enable malloc() pool before relocation" - default 0x400 help Before relocation memory is very limited on many platforms. Still, we can provide a small malloc() pool if needed. Driver model in diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 2064efa..23869ce 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -83,9 +83,6 @@ config DM_GPIO config SYS_MALLOC_F default y if !SPL_BUILD
-config SYS_MALLOC_F_LEN - default 0x400 if !SPL_BUILD - source "board/samsung/smdkv310/Kconfig" source "board/samsung/trats/Kconfig" source "board/samsung/universal_c210/Kconfig" diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig index 4644098..2e193ab 100644 --- a/arch/arm/cpu/armv7/omap3/Kconfig +++ b/arch/arm/cpu/armv7/omap3/Kconfig @@ -105,9 +105,6 @@ config DM_SERIAL config SYS_MALLOC_F default y if DM && !SPL_BUILD
-config SYS_MALLOC_F_LEN - default 0x400 if DM && !SPL_BUILD - config SYS_SOC default "omap3"
diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig b/arch/arm/cpu/armv7/tegra-common/Kconfig index ee32469..8b51558 100644 --- a/arch/arm/cpu/armv7/tegra-common/Kconfig +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig @@ -21,7 +21,7 @@ config SYS_MALLOC_F default y
config SYS_MALLOC_F_LEN - default 0x1800 + default 0x1800 if SYS_MALLOC_F
config USE_PRIVATE_LIBGCC default y if SPL_BUILD diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index 8fdef28..371b274 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -51,9 +51,6 @@ endchoice config SYS_MALLOC_F default y
-config SYS_MALLOC_F_LEN - default 0x400 - config CMD_PINMON bool "Enable boot mode pins monitor command" default y diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 35d24e4..65909e7 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -80,7 +80,7 @@ config SYS_MALLOC_F default y
config SYS_MALLOC_F_LEN - default 0x800 + default 0x800 if SYS_MALLOC_F
config RAMBASE hex diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index 848e08f..c0dbd18 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -43,8 +43,4 @@ config SYS_MALLOC_F bool default y
-config SYS_MALLOC_F_LEN - hex - default 0x400 - endif diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index a20e0c1..cad10c2 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -50,7 +50,4 @@ config DM_SERIAL config SYS_MALLOC_F default y if DM && !SPL_BUILD
-config SYS_MALLOC_F_LEN - default 0x400 if DM && !SPL_BUILD - endif
Hi Masahiro,
On 19 February 2015 at 22:24, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Since commit b724bd7d6349 (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to Kconfig), the ".config" created by the configuration has been wrong.
For example, the following is a snippet of the ".config" generated by "make beaver_defconfig":
--------------->8----------------- CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_SYS_MALLOC_F is not set CONFIG_SYS_MALLOC_F_LEN=0x1800 # CONFIG_EXPERT is not set ---------------8<-----------------
CONFIG_SYS_MALLOC_F_LEN is supposed to depend on CONFIG_SYS_MALLOC_F (see the top level Kconfig), but the ".config" above is not actually following that dependency.
This is caused by two mistakes of commit b724bd7d6349.
[1] Wrong default value of CONFIG_SYS_MALLOC_F CONFIG_SYS_MALLOC_F is a boolean option, but its default value is set to 0x400.
[2] Missing "if SYS_MALLOC_F" in the default setting in each Kconfig For example, arch/arm/cpu/armv7/tegra-common/Kconfig has the line "default 0x1800" for SYS_MALLOC_F_LEN. It must be described as "default 0x1800 if SYS_MALLOC_F" to follow the dependency.
Those two bugs together create such a broken ".config".
Unfortunately, even if we correct both [1] and [2], the value of CONFIG_SYS_MALLOC_F_LEN is not set as we expect. The "default 0x1800 if SYS_MALLOC_F" would be simply ignored because the "default 0x400" in the top level Kconfig is parsed first.
Notice that if multiple default lines appear for the same CONFIG, the first one takes precedence.
This commit corrects [1] and [2] so as not to create a broken .config file in any cases. Note that the default values in arch/arm/cpu/armv7/tegra-common/Kconfig and arch/x86/Kconfig are not working at this moment. This will be solved by the next commit.
The default value 0x400 is redundant for OMAP, Exynos, UniPhier, etc. They can be simply removed.
There are still redundant "CONFIG_SYS_MALLOC_F_LEN=0x400" in many defconfig files, but this commit is not touching them.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com
Changes in v3:
- Drop comments "This is meaningless ..."
- Update commit description
Changes in v2: None
I think it might have been better for this patch to merge with patch 4, since patch 3 fixes one of these problem. But it's not important.
Reviewed-by: Simon Glass <sjg@chromium.org
From: Simon Glass sjg@chromium.org
At present defaults in arch-specific Kconfig files are ignored if the top-level item comes ahead of it in include order. This means that it is not possible to have a U-Boot default that architectures and boards can override. This does not seem very useful.
Move the include earlier to support this.
Signed-off-by: Simon Glass sjg@chromium.org Reported-by: Masahiro Yamada yamada.m@jp.panasonic.com Reviewed-by: Masahiro Yamada yamada.m@jp.panasonic.com ---
Changes in v3: - The same as what Simon posted http://patchwork.ozlabs.org/patch/441670/ Included in this series to clarify the order
Changes in v2: None
Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Kconfig b/Kconfig index d40f9ec..351e5c9 100644 --- a/Kconfig +++ b/Kconfig @@ -12,6 +12,9 @@ config KCONFIG_OBJDIR string option env="KCONFIG_OBJDIR"
+# Allow defaults in arch-specific code to override any given here +source "arch/Kconfig" + menu "General setup"
config LOCALVERSION @@ -171,8 +174,6 @@ config SYS_CLK_FREQ
endmenu # Boot images
-source "arch/Kconfig" - source "common/Kconfig"
source "dts/Kconfig"
Now the default value of CONFIG_SYS_MALLOC_F_LEN can be overridden by SoC Kconfig file, but we still have to add the same conditional "if SYS_MALLOC_F" to every default. Otherwise, a broken .config file could be generated. It is too painful.
This commit intends to solve it by introducing SoC-default ARCH_MALLOC_F_LEN. This works as follows:
- If ARCH_MALLOC_F_LEN is defined, it overrides the default of SYS_MALLOC_F_LEN. If you have the SoC-optimized value, you might wish to do this.
- If ARCH_MALLOC_F_LEN is not defined, SYS_MALLOC_F_LEN is default to 0x400. This is the global default and it should work well enough in most cases.
- You can still change SYS_MALLOC_F_LEN per board, although you do not probably have to do so. Per-board default should be saved into each defconfig.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com ---
Changes in v3: - Newly added
Changes in v2: None
Kconfig | 1 + arch/arm/cpu/armv7/tegra-common/Kconfig | 5 +++-- arch/x86/Kconfig | 5 +++-- 3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Kconfig b/Kconfig index 351e5c9..cb5a6a8 100644 --- a/Kconfig +++ b/Kconfig @@ -70,6 +70,7 @@ config SYS_MALLOC_F config SYS_MALLOC_F_LEN hex "Size of malloc() pool before relocation" depends on SYS_MALLOC_F + default ARCH_MALLOC_F_LEN if ARCH_MALLOC_F_LEN default 0x400 help Before relocation memory is very limited on many platforms. Still, diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig b/arch/arm/cpu/armv7/tegra-common/Kconfig index 8b51558..c326106 100644 --- a/arch/arm/cpu/armv7/tegra-common/Kconfig +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig @@ -20,8 +20,9 @@ endchoice config SYS_MALLOC_F default y
-config SYS_MALLOC_F_LEN - default 0x1800 if SYS_MALLOC_F +config ARCH_MALLOC_F_LEN + hex + default 0x1800
config USE_PRIVATE_LIBGCC default y if SPL_BUILD diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 65909e7..0e49dd3 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -79,8 +79,9 @@ config DM_SERIAL config SYS_MALLOC_F default y
-config SYS_MALLOC_F_LEN - default 0x800 if SYS_MALLOC_F +config ARCH_MALLOC_F_LEN + hex + default 0x800
config RAMBASE hex
Hi Masahiro,
On 19 February 2015 at 22:24, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Now the default value of CONFIG_SYS_MALLOC_F_LEN can be overridden by SoC Kconfig file, but we still have to add the same conditional "if SYS_MALLOC_F" to every default. Otherwise, a broken .config file could be generated. It is too painful.
This commit intends to solve it by introducing SoC-default ARCH_MALLOC_F_LEN. This works as follows:
If ARCH_MALLOC_F_LEN is defined, it overrides the default of SYS_MALLOC_F_LEN. If you have the SoC-optimized value, you might wish to do this.
If ARCH_MALLOC_F_LEN is not defined, SYS_MALLOC_F_LEN is default to 0x400. This is the global default and it should work well enough in most cases.
You can still change SYS_MALLOC_F_LEN per board, although you do not probably have to do so. Per-board default should be saved into each defconfig.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com
Seems like a reasonable solution to me. I have to admit I prefer to adding another option, but if that is the only way to avoid the broken Kconfig (which I think works fine but could be quite confusing for people) then so be it.
Reviewed-by: Simon Glass sjg@chromium.org
2015-02-20 14:24 GMT+09:00 Masahiro Yamada yamada.m@jp.panasonic.com:
Now the default value of CONFIG_SYS_MALLOC_F_LEN can be overridden by SoC Kconfig file, but we still have to add the same conditional "if SYS_MALLOC_F" to every default. Otherwise, a broken .config file could be generated. It is too painful.
This commit intends to solve it by introducing SoC-default ARCH_MALLOC_F_LEN. This works as follows:
If ARCH_MALLOC_F_LEN is defined, it overrides the default of SYS_MALLOC_F_LEN. If you have the SoC-optimized value, you might wish to do this.
If ARCH_MALLOC_F_LEN is not defined, SYS_MALLOC_F_LEN is default to 0x400. This is the global default and it should work well enough in most cases.
You can still change SYS_MALLOC_F_LEN per board, although you do not probably have to do so. Per-board default should be saved into each defconfig.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com
Sorry, this patch does not work at all. I was completely misunderstanding.
I take it back.
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.
[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.
[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.
[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 admit my mistake with my apology and this commit switches to the single .config configuration.
It is not so difficult to do that:
- Remove unnecessary processings from scripts/multiconfig.sh This file will remain for a while to support the current defconfig format. It will be removed after more cleanups are done.
- Adjust some makefiles and Kconfigs
- 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.
- update doc/README.kconfig
More cleaning up patches will follow this.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com ---
Changes in v3: None Changes in v2: - Fix typos in commit description
Kconfig | 14 -- arch/arm/cpu/armv7/tegra-common/Kconfig | 2 +- arch/arm/cpu/armv7/uniphier/Kconfig | 1 - config.mk | 5 + configs/ph1_ld4_defconfig | 2 +- configs/ph1_pro4_defconfig | 2 +- configs/ph1_sld8_defconfig | 2 +- doc/README.kconfig | 132 ++++------------ drivers/mtd/nand/Kconfig | 2 +- include/config_uncmd_spl.h | 9 ++ scripts/Makefile.autoconf | 36 +++-- scripts/Makefile.build | 3 +- scripts/Makefile.spl | 10 +- scripts/Makefile.uncmd_spl | 16 ++ scripts/multiconfig.sh | 261 +------------------------------- 15 files changed, 108 insertions(+), 389 deletions(-) create mode 100644 scripts/Makefile.uncmd_spl
diff --git a/Kconfig b/Kconfig index cb5a6a8..bdaef56 100644 --- a/Kconfig +++ b/Kconfig @@ -8,10 +8,6 @@ config UBOOTVERSION string option env="UBOOTVERSION"
-config KCONFIG_OBJDIR - string - option env="KCONFIG_OBJDIR" - # Allow defaults in arch-specific code to override any given here source "arch/Kconfig"
@@ -90,16 +86,6 @@ endmenu # General setup
menu "Boot images"
-config SPL_BUILD - bool - depends on $KCONFIG_OBJDIR="spl" || $KCONFIG_OBJDIR="tpl" - default y - -config TPL_BUILD - bool - depends on $KCONFIG_OBJDIR="tpl" - default y - config SUPPORT_SPL bool
diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig b/arch/arm/cpu/armv7/tegra-common/Kconfig index c326106..a3f5282 100644 --- a/arch/arm/cpu/armv7/tegra-common/Kconfig +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig @@ -25,7 +25,7 @@ config ARCH_MALLOC_F_LEN default 0x1800
config USE_PRIVATE_LIBGCC - default y if SPL_BUILD + default y
config DM default y if !SPL_BUILD diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index 371b274..afb3c55 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -68,7 +68,6 @@ config CMD_DDRPHY_DUMP
choice prompt "DDR3 Frequency select" - depends on SPL_BUILD
config DDR_FREQ_1600 bool "DDR3 1600" diff --git a/config.mk b/config.mk index 64c2951..6282919 100644 --- a/config.mk +++ b/config.mk @@ -24,6 +24,11 @@ VENDOR :=
ARCH := $(CONFIG_SYS_ARCH:"%"=%) CPU := $(CONFIG_SYS_CPU:"%"=%) +ifdef CONFIG_SPL_BUILD +ifdef CONFIG_TEGRA +CPU := arm720t +endif +endif BOARD := $(CONFIG_SYS_BOARD:"%"=%) ifneq ($(CONFIG_SYS_VENDOR),) VENDOR := $(CONFIG_SYS_VENDOR:"%"=%) diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig index 86b4b15..fa8d291 100644 --- a/configs/ph1_ld4_defconfig +++ b/configs/ph1_ld4_defconfig @@ -39,4 +39,4 @@ CONFIG_DM_I2C=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y -S:CONFIG_SPL_NAND_DENALI=y +CONFIG_SPL_NAND_DENALI=y diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig index 242bcf9..12f0694 100644 --- a/configs/ph1_pro4_defconfig +++ b/configs/ph1_pro4_defconfig @@ -39,4 +39,4 @@ CONFIG_DM_I2C=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y -S:CONFIG_SPL_NAND_DENALI=y +CONFIG_SPL_NAND_DENALI=y diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig index 8e95f17..e66d166 100644 --- a/configs/ph1_sld8_defconfig +++ b/configs/ph1_sld8_defconfig @@ -39,4 +39,4 @@ CONFIG_DM_I2C=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y -S:CONFIG_SPL_NAND_DENALI=y +CONFIG_SPL_NAND_DENALI=y diff --git a/doc/README.kconfig b/doc/README.kconfig index 69dc459..288d17d 100644 --- a/doc/README.kconfig +++ b/doc/README.kconfig @@ -17,109 +17,45 @@ source directory for a basic specification of Kconfig. Difference from Linux's Kconfig -------------------------------
-The biggest difference between Linux Kernel and U-Boot in terms of the -configuration is that U-Boot has to configure multiple boot images per board: -Normal, SPL, TPL. -Kconfig functions need to be expanded for U-Boot to handle multiple images. -The files scripts/kconfig/* were imported from Linux Kernel and adjusted -for that purpose. +Here are some worth-mentioning configuration targets.
-See below for how each configuration target works in U-Boot: +- silentoldconfig
-- config, nconfig, menuconfig, xconfig, gconfig + This target updates .config, include/generated/autoconf.h and + include/configs/* as in Linux. In U-Boot, it also does the followings + for the compatibility with the old configuration system:
- These targets are used to configure Normal and create (or modify) the - .config file. For SPL configuration, the configutation targets are prefixed - with "spl/", for example "make spl/config", "make spl/menuconfig", etc. - Those targets create or modify the spl/.config file. Likewise, run - "make tpl/config", "make tpl/menuconfig", etc. for TPL. + * create a symbolic link "arch/${ARCH}/include/asm/arch" pointing to + the SoC/CPU specific header directory + * create include/config.h + * create include/autoconf.mk + * create spl/include/autoconf.mk (SPL and TPL only) + * create tpl/include/autoconf.mk (TPL only)
-- silentoldconfig + If we could completely switch to Kconfig in a long run + (i.e. remove all the include/configs/*.h), those additional processings + above would be removed.
- This target updates .config, include/generated/autoconf.h and - include/configs/*. In U-Boot, the same thing is done for SPL, TPL, - if supported by the target board. Depending on whether CONFIG_SPL and - CONFIG_TPL are defined, "make silentoldconfig" iterates three times at most - changing the work directory. - - To sum up, "make silentoldconfig" possibly updates: - - .config, include/generated/autoconf.h, include/config/* - - spl/.config, spl/include/generated/autoconf.h, spl/include/config/* - (in case CONFIG_SPL=y) - - tpl/.config, tpl/include/generated/autoconf.h, tpl/include/config/* - (in case CONFIG_TPL=y) - -- defconfig, <board>_defconfig - - The target "<board>_defconfig" is used to create the .config based on the - file configs/<board>_defconfig. The "defconfig" target is the same - except it checks for a file specified with KBUILD_DEFCONFIG environment. - - Note: - The defconfig files are placed under the "configs" directory, - not "arch/$(ARCH)/configs". This is because "ARCH" is not necessarily - given from the command line for the U-Boot configuration and build. - - The defconfig file format in U-Boot has the special syntax; each line has - "<condition>:" prefix to show which image(s) the line is valid for. - For example, - - CONFIG_FOO=100 - S:CONFIG_FOO=200 - T:CONFIG_FOO=300 - ST:CONFIG_BAR=y - +S:CONFIG_BAZ=y - +T:CONFIG_QUX=y - +ST:CONFIG_QUUX=y - - Here, the "<condition>:" prefix is one of: - None - the line is valid only for Normal image - S: - the line is valid only for SPL image - T: - the line is valid only for TPL image - ST: - the line is valid for SPL and TPL images - +S: - the line is valid for Normal and SPL images - +T: - the line is valid for Normal and TPL images - +ST: - the line is valid for Normal, SPL and TPL images - - So, if neither CONFIG_SPL nor CONFIG_TPL is defined, the defconfig file - has no "<condition>:" part and therefore has the same form as in Linux. - From the example defconfig shown above, three separete configuration sets - are generated and used for creating .config, spl/.config and tpl/.config. - - - Input for the default configuration of Normal - CONFIG_FOO=100 - CONFIG_BAZ=y - CONFIG_QUX=y - CONFIG_QUUX=y - - - Input for the default configuration of SPL - CONFIG_FOO=200 - CONFIG_BAR=y - CONFIG_BAZ=y - CONFIG_QUUX=y - - - Input for the default configuration of TPL - CONFIG_FOO=300 - CONFIG_BAR=y - CONFIG_QUX=y - CONFIG_QUUX=y - -- savedefconfig - - This is the reverse operation of "make defconfig". If neither CONFIG_SPL - nor CONFIG_TPL is defined in the .config file, it works like "savedefconfig" - in Linux Kernel: creates the minimal set of config based on the .config - and saves it into the "defconfig" file. If CONFIG_SPL (and CONFIG_TPL) is - defined, the common lines among .config, spl/.config (and tpl/.config) are - coalesced together with "condition:" prefix for each line as shown above. - This file can be used as an input of "defconfig" target. +- defconfig + + In U-Boot, "make defconfig" is a shorthand of "make sandbox_defconfig" + +- <board>_defconfig + + Now it works as in Linux. + The prefixes such as "+S:" in *_defconfig are deprecated. + You can simply remove the prefixes. Do not add them for new boards.
- <board>_config
This does not exist in Linux's Kconfig. + "make <board>_config" works the same as "make <board>_defconfig". Prior to Kconfig, in U-Boot, "make <board>_config" was used for the - configuration. It is still supported for backward compatibility and - its behavior is the same as "make <board>_defconfig". + configuration. It is still supported for backward compatibility, so + we do not need to update the distro recipes. + + +The other configuration targets work as in Linux Kernel.
Migration steps to Kconfig @@ -137,14 +73,10 @@ based configuration as follows:
Configuration files for use in C sources - include/generated/autoconf.h (generated by Kconfig for Normal) - - spl/include/generated/autoconf.h (generated by Kconfig for SPL) - - tpl/include/generated/autoconf.h (generated by Kconfig for TPL) - include/configs/<board>.h (exists for all boards)
Configuration file for use in makefiles - - include/config/auto.conf (generated by Kconfig for Normal) - - spl/include/config/auto.conf (generated by Kconfig for SPL) - - tpl/include/config/auto.conf (generated by Kconfig for TPL) + - include/config/auto.conf (generated by Kconfig) - include/autoconf.mk (generated by the old config for Normal) - spl/include/autoconfig.mk (generated by the old config for SPL) - tpl/include/autoconfig.mk (generated by the old config for TPL) @@ -215,8 +147,8 @@ TODO CONFIG_SYS_EXTRA_OPTIONS should not be used for new boards.
- In the pre-Kconfig, a single board had multiple entries in the boards.cfg - file with differences in the option fields. The correspoing defconfig files - were auto-generated when switching to Kconfig. Now we have too many + file with differences in the option fields. The corresponding defconfig + files were auto-generated when switching to Kconfig. Now we have too many defconfig files compared with the number of the supported boards. It is recommended to have only one defconfig per board and allow users to select the config options. diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index c242214..ccd8211 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -36,7 +36,7 @@ config NAND_DENALI_SPARE_AREA_SKIP_BYTES
endif
-if SPL_BUILD +if SPL
config SPL_NAND_DENALI bool "Support Denali NAND controller for SPL" diff --git a/include/config_uncmd_spl.h b/include/config_uncmd_spl.h index 9cb7a9a..9f0fe44 100644 --- a/include/config_uncmd_spl.h +++ b/include/config_uncmd_spl.h @@ -20,5 +20,14 @@ #undef CONFIG_CMD_SNTP #undef CONFIG_CMD_TFTPPUT #undef CONFIG_CMD_TFTPSRV +#undef CONFIG_OF_CONTROL + +#ifndef CONFIG_SPL_DM +#undef CONFIG_DM_SERIAL +#undef CONFIG_DM_GPIO +#undef CONFIG_DM_I2C +#undef CONFIG_DM_SPI +#endif + #endif /* CONFIG_SPL_BUILD */ #endif /* __CONFIG_UNCMD_SPL_H__ */ diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf index 8e9d71f..fc970fb 100644 --- a/scripts/Makefile.autoconf +++ b/scripts/Makefile.autoconf @@ -7,9 +7,17 @@ # (= When we move all CONFIGs from header files to Kconfig) # this makefile can be deleted.
-# obj is "include" or "spl/include" or "tpl/include" -# for non-SPL, SPL, TPL, respectively -include $(obj)/config/auto.conf +__all: include/autoconf.mk include/autoconf.mk.dep + +ifeq ($(shell grep -q '^CONFIG_SPL=y' include/config/auto.conf 2>/dev/null && echo y),y) +__all: spl/include/autoconf.mk +endif + +ifeq ($(shell grep -q '^CONFIG_TPL=y' include/config/auto.conf 2>/dev/null && echo y),y) +__all: tpl/include/autoconf.mk +endif + +include include/config/auto.conf
include scripts/Kbuild.include
@@ -22,7 +30,6 @@ CPP = $(CC) -E include config.mk
UBOOTINCLUDE := \ - -I$(obj) \ -Iinclude \ $(if $(KBUILD_SRC), -I$(srctree)/include) \ -I$(srctree)/arch/$(ARCH)/include \ @@ -48,10 +55,10 @@ include/autoconf.mk.dep: FORCE # same CONFIG macros quiet_cmd_autoconf = GEN $@ cmd_autoconf = \ - $(CPP) $(c_flags) -DDO_DEPS_ONLY -dM $(srctree)/include/common.h > $@.tmp && { \ + $(CPP) $(c_flags) $2 -DDO_DEPS_ONLY -dM $(srctree)/include/common.h > $@.tmp && { \ sed -n -f $(srctree)/tools/scripts/define2mk.sed $@.tmp | \ while read line; do \ - if ! grep -q "$${line%=*}=" $(obj)/config/auto.conf; then \ + if ! grep -q "$${line%=*}=" include/config/auto.conf; then \ echo "$$line"; \ fi \ done > $@; \ @@ -60,10 +67,19 @@ quiet_cmd_autoconf = GEN $@ rm $@.tmp; false; \ }
-$(obj)/autoconf.mk: FORCE +include/autoconf.mk: FORCE $(call cmd,autoconf)
-include/autoconf.mk include/autoconf.mk.dep: include/config.h +spl/include/autoconf.mk: FORCE + $(Q)mkdir -p $(dir $@) + $(call cmd,autoconf,-DCONFIG_SPL_BUILD) + +tpl/include/autoconf.mk: FORCE + $(Q)mkdir -p $(dir $@) + $(call cmd,autoconf,-DCONFIG_SPL_BUILD -DCONFIG_TPL_BUILD) + +include/autoconf.mk include/autoconf.mk.dep \ + spl/include/autoconf.mk tpl/include/autoconf.mk: include/config.h
# include/config.h # Prior to Kconfig, it was generated by mkconfig. Now it is created here. @@ -75,10 +91,10 @@ define filechk_config_h done; \ echo #define CONFIG_BOARDDIR board/$(if $(VENDOR),$(VENDOR)/)$(BOARD);\ echo #include <config_defaults.h>; \ + echo #include <config_uncmd_spl.h>; \ echo #include <configs/$(CONFIG_SYS_CONFIG_NAME).h>; \ echo #include <asm/config.h>; \ - echo #include <config_fallbacks.h>; \ - echo #include <config_uncmd_spl.h>; ) + echo #include <config_fallbacks.h>;) endef
include/config.h: scripts/Makefile.autoconf create_symlink FORCE diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 14cf092..ac0554e 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -41,8 +41,9 @@ subdir-ccflags-y :=
# Read auto.conf if it exists, otherwise ignore # Modified for U-Boot --include $(prefix)/include/config/auto.conf +-include include/config/auto.conf -include $(prefix)/include/autoconf.mk +include scripts/Makefile.uncmd_spl
include scripts/Kbuild.include
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index cc189ad..fcacb7f 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -21,13 +21,15 @@ _dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj))
include $(srctree)/scripts/Kbuild.include
-UBOOTINCLUDE := -I$(obj)/include $(UBOOTINCLUDE) - --include $(obj)/include/config/auto.conf +-include include/config/auto.conf -include $(obj)/include/autoconf.mk
+KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD +ifeq ($(CONFIG_TPL_BUILD),y) +KBUILD_CPPFLAGS += -DCONFIG_TPL_BUILD +endif + ifeq ($(CONFIG_TPL_BUILD),y) -export CONFIG_TPL_BUILD SPL_BIN := u-boot-tpl else SPL_BIN := u-boot-spl diff --git a/scripts/Makefile.uncmd_spl b/scripts/Makefile.uncmd_spl new file mode 100644 index 0000000..0bb7d54 --- /dev/null +++ b/scripts/Makefile.uncmd_spl @@ -0,0 +1,16 @@ +# Makefile version of include/config_uncmd_spl.h +# +# Invent a better way + +ifdef CONFIG_SPL_BUILD +CONFIG_OF_CONTROL= + +ifndef CONFIG_SPL_DM +CONFIG_DM_SERIAL= +CONFIG_DM_GPIO= +CONIFG_DM_I2C= +CONFIG_DM_SPI= +CONFIG_DM_SPI_FLASH= +endif + +endif diff --git a/scripts/multiconfig.sh b/scripts/multiconfig.sh index 366e8fa..cc8a787 100755 --- a/scripts/multiconfig.sh +++ b/scripts/multiconfig.sh @@ -2,11 +2,7 @@ # # A wrapper script to adjust Kconfig for U-Boot # -# Instead of touching various parts under the scripts/kconfig/ directory, -# pushing necessary adjustments into this single script would be better -# for code maintainance. All the make targets related to the configuration -# (make %config) should be invoked via this script. -# See doc/README.kconfig for further information of Kconfig. +# This file will be removed after cleaning up defconfig files # # Copyright (C) 2014, Masahiro Yamada yamada.m@jp.panasonic.com # @@ -15,77 +11,23 @@
set -e
-# Set "DEBUG" enavironment variable to show debug messages -debug () { - if [ $DEBUG ]; then - echo "$@" - fi -} - -# Useful shorthands -build () { - debug $progname: $MAKE -f $srctree/scripts/Makefile.build obj="$@" - $MAKE -f $srctree/scripts/Makefile.build obj="$@" -} - -autoconf () { - debug $progname: $MAKE -f $srctree/scripts/Makefile.autoconf obj="$@" - $MAKE -f $srctree/scripts/Makefile.autoconf obj="$@" -} - # Make a configuration target # Usage: # run_make_config <target> <objdir> # <target>: Make target such as "config", "menuconfig", "defconfig", etc. -# <objdir>: Target directory where the make command is run. -# Typically "", "spl", "tpl" for Normal, SPL, TPL, respectively. run_make_config () { - target=$1 - objdir=$2 - # Linux expects defconfig files in arch/$(SRCARCH)/configs/ directory, # but U-Boot has them in configs/ directory. # Give SRCARCH=.. to fake scripts/kconfig/Makefile. - options="SRCARCH=.. KCONFIG_OBJDIR=$objdir" - if [ "$objdir" ]; then - options="$options KCONFIG_CONFIG=$objdir/$KCONFIG_CONFIG" - mkdir -p $objdir - fi - - build scripts/kconfig $options $target -} - -# Parse .config file to detect if CONFIG_SPL, CONFIG_TPL is enabled -# and returns: -# "" if neither CONFIG_SPL nor CONFIG_TPL is defined -# "spl" if CONFIG_SPL is defined but CONFIG_TPL is not -# "spl tpl" if both CONFIG_SPL and CONFIG_TPL are defined -get_enabled_subimages() { - if [ ! -r "$KCONFIG_CONFIG" ]; then - # This should never happen - echo "$progname: $KCONFIG_CONFIG not found" >&2 - exit 1 - fi - - # CONFIG_SPL=y -> spl - # CONFIG_TPL=y -> tpl - sed -n -e 's/^CONFIG_SPL=y$/spl/p' -e 's/^CONFIG_TPL=y$/tpl/p' \ - $KCONFIG_CONFIG + $MAKE -f $srctree/scripts/Makefile.build obj=scripts/kconfig SRCARCH=.. $1 }
do_silentoldconfig () { run_make_config silentoldconfig - subimages=$(get_enabled_subimages) - - for obj in $subimages - do - mkdir -p $obj/include/config $obj/include/generated - run_make_config silentoldconfig $obj - done
# If the following part fails, include/config/auto.conf should be # deleted so "make silentoldconfig" will be re-run on the next build. - autoconf include include/autoconf.mk include/autoconf.mk.dep || { + $MAKE -f $srctree/scripts/Makefile.autoconf || { rm -f include/config/auto.conf exit 1 } @@ -95,14 +37,6 @@ do_silentoldconfig () { # than include/config.h. # Otherwise, 'make silentoldconfig' would be invoked twice. touch include/config/auto.conf - - for obj in $subimages - do - autoconf $obj/include $obj/include/autoconf.mk || { - rm -f include/config/auto.conf - exit 1 - } - done }
cleanup_after_defconfig () { @@ -116,7 +50,6 @@ cleanup_after_defconfig () { # do_board_defconfig <board>_defconfig do_board_defconfig () { defconfig_path=$srctree/configs/$1 - tmp_defconfig_path=configs/.tmp_defconfig
if [ ! -r $defconfig_path ]; then echo >&2 "***" @@ -126,42 +59,17 @@ do_board_defconfig () { fi
mkdir -p arch configs - # defconfig for Normal: - # pick lines without prefixes and lines starting '+' prefix - # and rip the prefixes off. - sed -n -e '/^[+A-Z]*:/!p' -e 's/^+[A-Z]*://p' $defconfig_path \ - > configs/.tmp_defconfig + # prefix "*:" is deprecated. Drop it simply. + sed -e 's/^[+A-Z]*://' $defconfig_path > configs/.tmp_defconfig
run_make_config .tmp_defconfig || { cleanup_after_defconfig exit 1 }
- for img in $(get_enabled_subimages) - do - symbol=$(echo $img | cut -c 1 | tr '[a-z]' '[A-Z]') - # defconfig for SPL, TPL: - # pick lines with 'S', 'T' prefix and rip the prefixes off - sed -n -e 's/^[+A-Z]*'$symbol'[A-Z]*://p' $defconfig_path \ - > configs/.tmp_defconfig - run_make_config .tmp_defconfig $img || { - cleanup_after_defconfig - exit 1 - } - done - cleanup_after_defconfig }
-do_defconfig () { - if [ "$KBUILD_DEFCONFIG" ]; then - do_board_defconfig $KBUILD_DEFCONFIG - echo "*** Default configuration is based on '$KBUILD_DEFCONFIG'" - else - run_make_config defconfig - fi -} - do_board_felconfig () { do_board_defconfig ${1%%_felconfig}_defconfig if ! grep -q CONFIG_ARCH_SUNXI=y .config || ! grep -q CONFIG_SPL=y .config ; then @@ -169,162 +77,11 @@ do_board_felconfig () { exit 1 fi sed -i -e 's/# CONFIG_SPL_FEL is not set/CONFIG_SPL_FEL=y\nCONFIG_UART0_PORT_F=n/g' \ - .config spl/.config + .config }
-do_savedefconfig () { - if [ -r "$KCONFIG_CONFIG" ]; then - subimages=$(get_enabled_subimages) - else - subimages= - fi - - run_make_config savedefconfig - - output_lines= - - # -r option is necessay because some string-type configs may include - # backslashes as an escape character - while read -r line - do - output_lines="$output_lines%$line" - done < defconfig - - for img in $subimages - do - run_make_config savedefconfig $img - - symbol=$(echo $img | cut -c 1 | tr '[a-z]' '[A-Z]') - unmatched= - - while read -r line - do - tmp= - match= - - # "# CONFIG_FOO is not set" should not be divided. - # Use "%" as a separator, instead of a whitespace. - # "%" is unlikely to appear in defconfig context. - save_IFS=$IFS - IFS=% - # coalesce common lines together - for i in $output_lines - do - case "$i" in - [+A-Z]*:$line) - tmp="$tmp%$unmatched" - i=$(echo "$i" | \ - sed -e "s/^([^:]*)/\1$symbol/") - tmp="$tmp%$i" - match=1 - ;; - $line) - tmp="$tmp%$unmatched" - tmp="$tmp%+$symbol:$i" - match=1 - ;; - *) - tmp="$tmp%$i" - ;; - esac - done - - # Restore the default separator for the outer for loop. - IFS=$save_IFS - - if [ "$match" ]; then - output_lines="$tmp" - unmatched= - else - unmatched="$unmatched%$symbol:$line" - fi - done < defconfig - - output_lines="$output_lines%$unmatched" - done - - rm -f defconfig - touch defconfig - - save_IFS=$IFS - IFS=% - - for line in $output_lines - do - case "$line" in - "") - # do not output blank lines - ;; - *) - echo $line >> defconfig - ;; - esac - done - - IFS=$save_IFS -} - -# Some sanity checks before running "make <objdir>/<target>", -# where <objdir> should be either "spl" or "tpl". -# Doing "make spl/menuconfig" etc. on a non-SPL board makes no sense. -# It should be allowed only when ".config" exists and "CONFIG_SPL" is enabled. -# -# Usage: -# check_enabled_sumbimage <objdir>/<target> <objdir> -check_enabled_subimage () { - - case $2 in - spl|tpl) ;; - *) - echo >&2 "***" - echo >&2 "*** "make $1" is not supported." - echo >&2 "***" - exit 1 - ;; - esac - test -r "$KCONFIG_CONFIG" && get_enabled_subimages | grep -q $2 || { - config=CONFIG_$(echo $2 | tr '[a-z]' '[A-Z]') - - echo >&2 "***" - echo >&2 "*** Create "$KCONFIG_CONFIG" with "$config" enabled" - echo >&2 "*** before "make $1"." - echo >&2 "***" - exit 1 - } -} - -# Usage: -# do_others <objdir>/<target> -# The field "<objdir>/" is typically empy, "spl/", "tpl/" for Normal, SPL, TPL, -# respectively. -# The field "<target>" is a configuration target such as "config", -# "menuconfig", etc. do_others () { - target=${1##*/} - - if [ "$target" = "$1" ]; then - objdir= - else - objdir=${1%/*} - check_enabled_subimage $1 $objdir - - if [ -f "$objdir/$KCONFIG_CONFIG" ]; then - timestamp_before=$(stat --printf="%Y" \ - $objdir/$KCONFIG_CONFIG) - fi - fi - - run_make_config $target $objdir - - if [ "$timestamp_before" -a -f "$objdir/$KCONFIG_CONFIG" ]; then - timestamp_after=$(stat --printf="%Y" $objdir/$KCONFIG_CONFIG) - - if [ "$timestamp_after" -gt "$timestamp_before" ]; then - # $objdir/.config has been updated. - # touch .config to invoke "make silentoldconfig" - touch $KCONFIG_CONFIG - fi - fi + run_make_config $1 }
progname=$(basename $0) @@ -340,10 +97,6 @@ case $target in do_board_defconfig ${target%_config}_defconfig;; silentoldconfig) do_silentoldconfig;; -defconfig) - do_defconfig;; -savedefconfig) - do_savedefconfig;; *) do_others $target;; esac
On 19 February 2015 at 22:24, Masahiro Yamada yamada.m@jp.panasonic.com 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.
[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.
[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.
[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 admit my mistake with my apology and this commit switches to the single .config configuration.
It is not so difficult to do that:
- Remove unnecessary processings from scripts/multiconfig.sh
This file will remain for a while to support the current defconfig format. It will be removed after more cleanups are done.
Adjust some makefiles and Kconfigs
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.
update doc/README.kconfig
More cleaning up patches will follow this.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com
Reviewed-by: Simon Glass sjg@chromium.org
I notice with seaboard there is a bit of a code size different. But I don't think this matters.
06: kconfig: switch to single .config configuration arm: (for 1/1 boards) all -839.0 bss +4.0 rodata -27.0 spl/u-boot-spl:all +16.0 spl/u-boot-spl:data +16.0 text -816.0 seaboard : all -839 bss +4 rodata -27 spl/u-boot-spl:all +16 spl/u-boot-spl:data +16 text -816 u-boot: add: 1/-11, grow: 0/-1 bytes: 4/-1352 (-1348) function old new delta __div0 - 4 +4 __aeabi_idiv0 12 - -12 __lshrdi3 24 - -24 __ashldi3 24 - -24 __aeabi_llsr 24 - -24 __aeabi_llsl 24 - -24 __ashrdi3 26 - -26 __aeabi_uidivmod 26 - -26 __aeabi_lasr 26 - -26 __aeabi_idivmod 26 - -26 raise 28 - -28 __udivsi3 604 152 -452 __divsi3 660 - -660 spl-u-boot-spl: add: 0/0, grow: 1/0 bytes: 16/0 (16) function old new delta gdata 184 200 +16
Regards, Simon
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:"...
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?
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.
[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".
[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. 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?
Why do symbols like LOCALVERSION and CC_OPTIMIZE_FOR_SIZE depend on ! SPL_BUILD?
[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?
- 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"?
-Scott
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
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.
BTW, Ian's idea had been already achieved by include/config_uncmd_spl.h
[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
[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.
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.
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.
[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.
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. In 4KB memory footprint, it is impossible to include Driver Model. It would be a really ad-hoc implementation.
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" ?
- 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.
Best Regards Masahiro Yamada
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).
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.
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? :-(
[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.
[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.
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.
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:
#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?
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?
- 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.
-Scott
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
Hi,
On 24 February 2015 at 23:14, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
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] #endifI will post some patches later on.
BTW it would be nice if we could compile the code even if it is not included (e.g with the compile-time IS_ENABLED(CONFIG_...)). Also for driver model I would like it to be supported the same in both SPL and U-Boot proper, to avoid this sort of thing. We are very close to merging the driver model SPL support.
[snip]
Regards, Simon
On Wed, 2015-02-25 at 15:14 +0900, Masahiro Yamada wrote:
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?
So that you can express dependencies in the main U-Boot on SPL symbols, which you said was one of the problems that motivated this change.
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.
Most options are boolean (especially if you ignore hardware description that isn't going to differ between SPL and non-SPL). I think it makes a lot of sense to not want to duplicate them, and especially to not complicate each place that ifdefs on the symbol by having to check for SPL.
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.
That's not what I was suggesting.
I was suggesting something like:
config DM bool "Enable Driver Model" depends on !SPL_BUILD || SPL_DM ...
Then the ifdef would just be
#ifdef CONFIG_DM [Driver Model Code] #else [Non Driver Model Code] #endif
[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?
The fragment would be part of a library of common config tweaks that users can apply -- providing similar convenience as _felconfig but with generic infrastructure.
[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.
Just? And how much makefile crud to check for those options when building? To achieve what?
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_*.
So instead of CONFIG_TPL_* we'd have more hardcoded makefile hackery to disable things in TPL -- and we'd have to duplicate that hackery for SPLs that are just as small as what you're now calling TPL, if you're not going to allow TPL without SPL.
-Scott
Hi Scott,
On Feb 23, 2015 6:23 PM, "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:"...
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?
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.
[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".
[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. 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?
Why do symbols like LOCALVERSION and CC_OPTIMIZE_FOR_SIZE depend on ! SPL_BUILD?
[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.
As Masahiro says this will happen as we remove one by one the various SPL special cases. For example, when driver model supports SPL and U-Boot then we won't need that option - you will either use driver model (or not) for both. I suspect other options will go the same way.
But if things are split into multiple configs it is really hard to compare them and keep them in sync.
Once the dust settles I will be sending a series to remove the special cases around CONFIG_SPL_DM.
How will TPL be handled? Are you going to duplicate all the SPL symbols? Or just avoid ever kconfigizing them?
- 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"?
Regards, Simon
Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com ---
Changes in v3: None Changes in v2: - Fix a typo in commit description
Kconfig | 12 ++---------- arch/arm/Kconfig | 7 +++---- arch/arm/cpu/arm1176/bcm2835/Kconfig | 6 +++--- arch/arm/cpu/armv7/exynos/Kconfig | 26 +++++++++++++------------- arch/arm/cpu/armv7/omap3/Kconfig | 8 ++++---- arch/arm/cpu/armv7/s5pc1xx/Kconfig | 4 ++-- arch/arm/cpu/armv7/tegra-common/Kconfig | 12 ++++++------ arch/arm/cpu/armv7/uniphier/Kconfig | 1 - board/compulab/cm_t335/Kconfig | 6 +++--- board/gumstix/pepper/Kconfig | 6 +++--- board/isee/igep0033/Kconfig | 6 +++--- board/phytec/pcm051/Kconfig | 6 +++--- board/samsung/goni/Kconfig | 6 +++--- board/samsung/smdkc100/Kconfig | 6 +++--- board/silica/pengwyn/Kconfig | 6 +++--- board/ti/am335x/Kconfig | 8 ++++---- common/Kconfig | 1 - drivers/core/Kconfig | 16 ++++++---------- drivers/mtd/nand/Kconfig | 4 ---- dts/Kconfig | 1 - include/config_uncmd_spl.h | 4 ++++ scripts/Makefile.uncmd_spl | 4 +++- 22 files changed, 71 insertions(+), 85 deletions(-)
diff --git a/Kconfig b/Kconfig index bdaef56..a66a97f 100644 --- a/Kconfig +++ b/Kconfig @@ -15,7 +15,6 @@ menu "General setup"
config LOCALVERSION string "Local version - append to U-Boot release" - depends on !SPL_BUILD help Append an extra string to the end of your U-Boot version. This will show up on your boot log, for example. @@ -26,7 +25,6 @@ config LOCALVERSION
config LOCALVERSION_AUTO bool "Automatically append version information to the version string" - depends on !SPL_BUILD default y help This will try to automatically determine if the current tree is a @@ -47,7 +45,6 @@ config LOCALVERSION_AUTO
config CC_OPTIMIZE_FOR_SIZE bool "Optimize for size" - depends on !SPL_BUILD default y help Enabling this option will pass "-Os" instead of "-O2" to gcc @@ -95,23 +92,19 @@ config SUPPORT_TPL config SPL bool depends on SUPPORT_SPL - prompt "Enable SPL" if !SPL_BUILD - default y if SPL_BUILD + prompt "Enable SPL" help If you want to build SPL as well as the normal image, say Y.
config TPL bool depends on SPL && SUPPORT_TPL - prompt "Enable TPL" if !SPL_BUILD - default y if TPL_BUILD - default n + prompt "Enable TPL" help If you want to build TPL as well as the normal image and SPL, say Y.
config FIT bool "Support Flattened Image Tree" - depends on !SPL_BUILD help This option allows to boot the new uImage structrure, Flattened Image Tree. FIT is formally a FDT, which can include @@ -135,7 +128,6 @@ config FIT_SIGNATURE
config SYS_EXTRA_OPTIONS string "Extra Options (DEPRECATED)" - depends on !SPL_BUILD help The old configuration infrastructure (= mkconfig + boards.cfg) provided the extra options field. If you have something like diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 41f3220..700e2a8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -739,9 +739,8 @@ config TEGRA bool "NVIDIA Tegra" select SUPPORT_SPL select SPL - select OF_CONTROL if !SPL_BUILD - select CPU_ARM720T if SPL_BUILD - select CPU_V7 if !SPL_BUILD + select OF_CONTROL + select CPU_V7
config TARGET_VEXPRESS64_AEMV8A bool "Support vexpress_aemv8a" @@ -833,7 +832,7 @@ config ARCH_UNIPHIER select CPU_V7 select SUPPORT_SPL select SPL - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
endchoice
diff --git a/arch/arm/cpu/arm1176/bcm2835/Kconfig b/arch/arm/cpu/arm1176/bcm2835/Kconfig index 94f57d7..7d0fc67 100644 --- a/arch/arm/cpu/arm1176/bcm2835/Kconfig +++ b/arch/arm/cpu/arm1176/bcm2835/Kconfig @@ -1,12 +1,12 @@ if TARGET_RPI
config DM - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
endif diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 23869ce..9e47ed3 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -6,7 +6,7 @@ choice config TARGET_SMDKV310 select SUPPORT_SPL bool "Exynos4210 SMDKV310 board" - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
config TARGET_TRATS bool "Exynos4210 Trats board" @@ -33,32 +33,32 @@ config TARGET_ARNDALE select CPU_V7_HAS_NONSEC select CPU_V7_HAS_VIRT select SUPPORT_SPL - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
config TARGET_SMDK5250 bool "SMDK5250 board" select SUPPORT_SPL - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
config TARGET_SNOW bool "Snow board" select SUPPORT_SPL - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
config TARGET_SMDK5420 bool "SMDK5420 board" select SUPPORT_SPL - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
config TARGET_PEACH_PI bool "Peach Pi board" select SUPPORT_SPL - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
config TARGET_PEACH_PIT bool "Peach Pit board" select SUPPORT_SPL - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
endchoice
@@ -66,22 +66,22 @@ config SYS_SOC default "exynos"
config DM - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
config DM_SPI - default y if !SPL_BUILD + default y
config DM_SPI_FLASH - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config SYS_MALLOC_F - default y if !SPL_BUILD + default y
source "board/samsung/smdkv310/Kconfig" source "board/samsung/trats/Kconfig" diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig index 2e193ab..b3d5ef3 100644 --- a/arch/arm/cpu/armv7/omap3/Kconfig +++ b/arch/arm/cpu/armv7/omap3/Kconfig @@ -94,16 +94,16 @@ config TARGET_TWISTER endchoice
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if DM && !SPL_BUILD + default y if DM
config DM_SERIAL - default y if DM && !SPL_BUILD + default y if DM
config SYS_MALLOC_F - default y if DM && !SPL_BUILD + default y if DM
config SYS_SOC default "omap3" diff --git a/arch/arm/cpu/armv7/s5pc1xx/Kconfig b/arch/arm/cpu/armv7/s5pc1xx/Kconfig index 6288134..bc73813 100644 --- a/arch/arm/cpu/armv7/s5pc1xx/Kconfig +++ b/arch/arm/cpu/armv7/s5pc1xx/Kconfig @@ -5,11 +5,11 @@ choice
config TARGET_S5P_GONI bool "S5P Goni board" - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
config TARGET_SMDKC100 bool "Support smdkc100 board" - select OF_CONTROL if !SPL_BUILD + select OF_CONTROL
endchoice
diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig b/arch/arm/cpu/armv7/tegra-common/Kconfig index a3f5282..2003fc8 100644 --- a/arch/arm/cpu/armv7/tegra-common/Kconfig +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig @@ -28,22 +28,22 @@ config USE_PRIVATE_LIBGCC default y
config DM - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
config DM_SPI - default y if !SPL_BUILD + default y
config DM_SPI_FLASH - default y if !SPL_BUILD + default y
config DM_I2C - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
source "arch/arm/cpu/armv7/tegra20/Kconfig" source "arch/arm/cpu/armv7/tegra30/Kconfig" diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index afb3c55..b6dc75f 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -61,7 +61,6 @@ config CMD_PINMON
config CMD_DDRPHY_DUMP bool "Enable dump command of DDR PHY parameters" - depends on !SPL_BUILD help The command "ddrphy" shows the resulting parameters of DDR PHY training; it is useful for the evaluation of DDR PHY training. diff --git a/board/compulab/cm_t335/Kconfig b/board/compulab/cm_t335/Kconfig index aadbfbc..3a8f304 100644 --- a/board/compulab/cm_t335/Kconfig +++ b/board/compulab/cm_t335/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "cm_t335"
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
endif diff --git a/board/gumstix/pepper/Kconfig b/board/gumstix/pepper/Kconfig index 3099a9e..750db85 100644 --- a/board/gumstix/pepper/Kconfig +++ b/board/gumstix/pepper/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "pepper"
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
endif diff --git a/board/isee/igep0033/Kconfig b/board/isee/igep0033/Kconfig index 2fe2ef1..9a8421e 100644 --- a/board/isee/igep0033/Kconfig +++ b/board/isee/igep0033/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "am335x_igep0033"
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
endif diff --git a/board/phytec/pcm051/Kconfig b/board/phytec/pcm051/Kconfig index 65094cf..bb98715 100644 --- a/board/phytec/pcm051/Kconfig +++ b/board/phytec/pcm051/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "pcm051"
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
endif diff --git a/board/samsung/goni/Kconfig b/board/samsung/goni/Kconfig index 2c5d3fc..006e864 100644 --- a/board/samsung/goni/Kconfig +++ b/board/samsung/goni/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "s5p_goni"
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
endif diff --git a/board/samsung/smdkc100/Kconfig b/board/samsung/smdkc100/Kconfig index 996fe3c..ea87166 100644 --- a/board/samsung/smdkc100/Kconfig +++ b/board/samsung/smdkc100/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "smdkc100"
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
endif diff --git a/board/silica/pengwyn/Kconfig b/board/silica/pengwyn/Kconfig index 6ecda80..2e9a2b3 100644 --- a/board/silica/pengwyn/Kconfig +++ b/board/silica/pengwyn/Kconfig @@ -13,12 +13,12 @@ config SYS_CONFIG_NAME default "pengwyn"
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if !SPL_BUILD + default y
config DM_SERIAL - default y if !SPL_BUILD + default y
endif diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index cad10c2..8c45892 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -39,15 +39,15 @@ config NOR_BOOT NOR for environment.
config DM - default y if !SPL_BUILD + default y
config DM_GPIO - default y if DM && !SPL_BUILD + default y if DM
config DM_SERIAL - default y if DM && !SPL_BUILD + default y if DM
config SYS_MALLOC_F - default y if DM && !SPL_BUILD + default y if DM
endif diff --git a/common/Kconfig b/common/Kconfig index 2ca002d..f82bc88 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -1,5 +1,4 @@ menu "Command line interface" - depends on !SPL_BUILD
config HUSH_PARSER bool "Use hush shell" diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig index f0d6110..75d182d 100644 --- a/drivers/core/Kconfig +++ b/drivers/core/Kconfig @@ -1,6 +1,5 @@ config DM bool "Enable Driver Model" - depends on !SPL_BUILD help This config option enables Driver Model. This brings in the core support, including scanning of platform data on start-up. If @@ -22,31 +21,28 @@ config SPL_DM
config DM_WARN bool "Enable warnings in driver model" + depends on DM + default y help The dm_warn() function can use up quite a bit of space for its strings. By default this is disabled for SPL builds to save space. This will cause dm_warn() to be compiled out - it will do nothing when called. - depends on DM - default y if !SPL_BUILD - default n if SPL_BUILD
config DM_DEVICE_REMOVE bool "Support device removal" + depends on DM + default y help We can save some code space by dropping support for removing a device. This is not normally required in SPL, so by default this option is disabled for SPL. - depends on DM - default y if !SPL_BUILD - default n if SPL_BUILD
config DM_STDIO bool "Support stdio registration" + depends on DM + default y help Normally serial drivers register with stdio so that they can be used as normal output devices. In SPL we don't normally use stdio, so we can omit this feature. - depends on DM - default y if !SPL_BUILD - default n if SPL_BUILD diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index ccd8211..72825c3 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -6,8 +6,6 @@ config SYS_NAND_SELF_INIT This option, if enabled, provides more flexible and linux-like NAND initialization process.
-if !SPL_BUILD - config NAND_DENALI bool "Support Denali NAND controller" select SYS_NAND_SELF_INIT @@ -34,8 +32,6 @@ config NAND_DENALI_SPARE_AREA_SKIP_BYTES of OOB area before last ECC sector data starts. This is potentially used to preserve the bad block marker in the OOB area.
-endif - if SPL
config SPL_NAND_DENALI diff --git a/dts/Kconfig b/dts/Kconfig index 5fe63f8..ca5bd6f 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -9,7 +9,6 @@ config SUPPORT_OF_CONTROL bool
menu "Device Tree Control" - depends on !SPL_BUILD depends on SUPPORT_OF_CONTROL
config OF_CONTROL diff --git a/include/config_uncmd_spl.h b/include/config_uncmd_spl.h index 9f0fe44..a9106f4 100644 --- a/include/config_uncmd_spl.h +++ b/include/config_uncmd_spl.h @@ -29,5 +29,9 @@ #undef CONFIG_DM_SPI #endif
+#undef CONFIG_DM_WARN +#undef CONFIG_DM_DEVICE_REMOVE +#undef CONFIG_DM_STDIO + #endif /* CONFIG_SPL_BUILD */ #endif /* __CONFIG_UNCMD_SPL_H__ */ diff --git a/scripts/Makefile.uncmd_spl b/scripts/Makefile.uncmd_spl index 0bb7d54..343c3fc 100644 --- a/scripts/Makefile.uncmd_spl +++ b/scripts/Makefile.uncmd_spl @@ -1,6 +1,6 @@ # Makefile version of include/config_uncmd_spl.h # -# Invent a better way +# TODO: Invent a better way
ifdef CONFIG_SPL_BUILD CONFIG_OF_CONTROL= @@ -13,4 +13,6 @@ CONFIG_DM_SPI= CONFIG_DM_SPI_FLASH= endif
+CONFIG_DM_DEVICE_REMOVE= + endif
+Stephen
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com
Changes in v3: None Changes in v2:
- Fix a typo in commit description
Kconfig | 12 ++---------- arch/arm/Kconfig | 7 +++---- arch/arm/cpu/arm1176/bcm2835/Kconfig | 6 +++--- arch/arm/cpu/armv7/exynos/Kconfig | 26 +++++++++++++------------- arch/arm/cpu/armv7/omap3/Kconfig | 8 ++++---- arch/arm/cpu/armv7/s5pc1xx/Kconfig | 4 ++-- arch/arm/cpu/armv7/tegra-common/Kconfig | 12 ++++++------ arch/arm/cpu/armv7/uniphier/Kconfig | 1 - board/compulab/cm_t335/Kconfig | 6 +++--- board/gumstix/pepper/Kconfig | 6 +++--- board/isee/igep0033/Kconfig | 6 +++--- board/phytec/pcm051/Kconfig | 6 +++--- board/samsung/goni/Kconfig | 6 +++--- board/samsung/smdkc100/Kconfig | 6 +++--- board/silica/pengwyn/Kconfig | 6 +++--- board/ti/am335x/Kconfig | 8 ++++---- common/Kconfig | 1 - drivers/core/Kconfig | 16 ++++++---------- drivers/mtd/nand/Kconfig | 4 ---- dts/Kconfig | 1 - include/config_uncmd_spl.h | 4 ++++ scripts/Makefile.uncmd_spl | 4 +++- 22 files changed, 71 insertions(+), 85 deletions(-)
[snip]
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 41f3220..700e2a8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -739,9 +739,8 @@ config TEGRA bool "NVIDIA Tegra" select SUPPORT_SPL select SPL
select OF_CONTROL if !SPL_BUILDselect CPU_ARM720T if SPL_BUILDselect CPU_V7 if !SPL_BUILD
select OF_CONTROLselect CPU_V7
Sorry if I have missed something here. On Tegra most unfortunately the SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only reason that Tegra has SPL. Doesn't this change with this commit?
Regards, Simon
On 02/20/2015 10:06 AM, Simon Glass wrote:
+Stephen
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 41f3220..700e2a8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -739,9 +739,8 @@ config TEGRA bool "NVIDIA Tegra" select SUPPORT_SPL select SPL
select OF_CONTROL if !SPL_BUILDselect CPU_ARM720T if SPL_BUILDselect CPU_V7 if !SPL_BUILD
select OF_CONTROLselect CPU_V7Sorry if I have missed something here. On Tegra most unfortunately the SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only reason that Tegra has SPL. Doesn't this change with this commit?
Yes, on Tegra SPL runs on an ARMv4t and main U-Boot on some ARMv7 CPU. The change above is actively incorrect.
The OF_CONTROL change is probably incorrect too; we certainly don't intend to use OF_CONTROL in the SPL (there's really nothing to control in the SPL) - I just don't know if enabling that feature will cause any issue. Things to look out for would be bloat of the SPL binary so that it didn't fit into the space before the main binary's TEXT_BASE, since the two get concatenated together into a single binary that's loaded into RAM, and XIP'd.
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/20/2015 10:06 AM, Simon Glass wrote:
+Stephen
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 41f3220..700e2a8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -739,9 +739,8 @@ config TEGRA bool "NVIDIA Tegra" select SUPPORT_SPL select SPL
select OF_CONTROL if !SPL_BUILDselect CPU_ARM720T if SPL_BUILDselect CPU_V7 if !SPL_BUILD
select OF_CONTROLselect CPU_V7Sorry if I have missed something here. On Tegra most unfortunately the SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only reason that Tegra has SPL. Doesn't this change with this commit?
Yes, on Tegra SPL runs on an ARMv4t and main U-Boot on some ARMv7 CPU. The change above is actively incorrect.
The OF_CONTROL change is probably incorrect too; we certainly don't intend to use OF_CONTROL in the SPL (there's really nothing to control in the SPL)
- I just don't know if enabling that feature will cause any issue. Things to
look out for would be bloat of the SPL binary so that it didn't fit into the space before the main binary's TEXT_BASE, since the two get concatenated together into a single binary that's loaded into RAM, and XIP'd.
This at least is not a problem with this patch.
I'll make some time to take a look at this in the next few days.
Regards, Simon
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/20/2015 10:06 AM, Simon Glass wrote:
+Stephen
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 41f3220..700e2a8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -739,9 +739,8 @@ config TEGRA bool "NVIDIA Tegra" select SUPPORT_SPL select SPL
select OF_CONTROL if !SPL_BUILDselect CPU_ARM720T if SPL_BUILDselect CPU_V7 if !SPL_BUILD
select OF_CONTROLselect CPU_V7Sorry if I have missed something here. On Tegra most unfortunately the SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes, on Tegra SPL runs on an ARMv4t and main U-Boot on some ARMv7 CPU. The change above is actively incorrect.
The OF_CONTROL change is probably incorrect too; we certainly don't intend to use OF_CONTROL in the SPL (there's really nothing to control in the SPL)
- I just don't know if enabling that feature will cause any issue. Things to
look out for would be bloat of the SPL binary so that it didn't fit into the space before the main binary's TEXT_BASE, since the two get concatenated together into a single binary that's loaded into RAM, and XIP'd.
This at least is not a problem with this patch.
I'll make some time to take a look at this in the next few days.
As for CONFIG_OF_CONTROL, I think my answer is already in the git-description. I wrote as follows:
- 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.
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/20/2015 10:06 AM, Simon Glass wrote:
+Stephen
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 41f3220..700e2a8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -739,9 +739,8 @@ config TEGRA bool "NVIDIA Tegra" select SUPPORT_SPL select SPL
select OF_CONTROL if !SPL_BUILDselect CPU_ARM720T if SPL_BUILDselect CPU_V7 if !SPL_BUILD
select OF_CONTROLselect CPU_V7Sorry if I have missed something here. On Tegra most unfortunately the SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, on Tegra SPL runs on an ARMv4t and main U-Boot on some ARMv7 CPU. The change above is actively incorrect.
The OF_CONTROL change is probably incorrect too; we certainly don't intend to use OF_CONTROL in the SPL (there's really nothing to control in the SPL)
- I just don't know if enabling that feature will cause any issue. Things to
look out for would be bloat of the SPL binary so that it didn't fit into the space before the main binary's TEXT_BASE, since the two get concatenated together into a single binary that's loaded into RAM, and XIP'd.
This at least is not a problem with this patch.
I'll make some time to take a look at this in the next few days.
As for CONFIG_OF_CONTROL, I think my answer is already in the git-description. I wrote as follows:
- 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.
So I thnk we are OK. I will give it all a test on Tegra.
Regards, Simon
Hi Simon,
2015-02-21 11:28 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/20/2015 10:06 AM, Simon Glass wrote:
+Stephen
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 41f3220..700e2a8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -739,9 +739,8 @@ config TEGRA bool "NVIDIA Tegra" select SUPPORT_SPL select SPL
select OF_CONTROL if !SPL_BUILDselect CPU_ARM720T if SPL_BUILDselect CPU_V7 if !SPL_BUILD
select OF_CONTROLselect CPU_V7Sorry if I have missed something here. On Tegra most unfortunately the SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, exactly!
Hi Masahiro,
On 20 February 2015 at 19:37, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2015-02-21 11:28 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/20/2015 10:06 AM, Simon Glass wrote:
+Stephen
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote: > > Now CONFIG_SPL_BUILD is not defined in Kconfig, so > "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 41f3220..700e2a8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -739,9 +739,8 @@ config TEGRA > bool "NVIDIA Tegra" > select SUPPORT_SPL > select SPL > - select OF_CONTROL if !SPL_BUILD > - select CPU_ARM720T if SPL_BUILD > - select CPU_V7 if !SPL_BUILD > + select OF_CONTROL > + select CPU_V7
Sorry if I have missed something here. On Tegra most unfortunately the SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, exactly!
This all works fine on Tegra for me. However I like to suggest dropping a few patches in this series.
I don't think it is worth using ARCH_MALLOC_F_LEN. In fact for me the Tegra defconfig looks OK and SPL is built correctly.
My remaining question is about that Tegra seems to want USE_PRIVATE_LIBGCC for SPL but not for U-Boot. I'm not sure why, nor whether it matters. It seems to work find using it for both.
I have pushed my tested tree to u-boot-x86 in branch single-kconfig-for-masahiro.
It contains only these patches:
ARM: UniPhier: set CONFIG_SYS_MALLOC_F to the global default value kconfig: Adjust ordering so that defaults work as expected kconfig: switch to single .config configuration kconfig: remove unneeded dependency on !SPL_BUILD
Perhaps we can look at the others later once we get things moved over? I think the SYS_MALLOC_F thing is not that big a deal and not urgent to resolve if we still have a problem.
Regards, Simon
On 02/23/2015 07:02 AM, Simon Glass wrote:
Hi Masahiro,
On 20 February 2015 at 19:37, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2015-02-21 11:28 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/20/2015 10:06 AM, Simon Glass wrote: > > +Stephen > > Hi Masahiro, > > On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com > wrote: >> >> Now CONFIG_SPL_BUILD is not defined in Kconfig, so >> "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 41f3220..700e2a8 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -739,9 +739,8 @@ config TEGRA >> bool "NVIDIA Tegra" >> select SUPPORT_SPL >> select SPL >> - select OF_CONTROL if !SPL_BUILD >> - select CPU_ARM720T if SPL_BUILD >> - select CPU_V7 if !SPL_BUILD >> + select OF_CONTROL >> + select CPU_V7 > > > Sorry if I have missed something here. On Tegra most unfortunately the > SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only > reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, exactly!
This all works fine on Tegra for me. However I like to suggest dropping a few patches in this series.
I don't think it is worth using ARCH_MALLOC_F_LEN. In fact for me the Tegra defconfig looks OK and SPL is built correctly.
My remaining question is about that Tegra seems to want USE_PRIVATE_LIBGCC for SPL but not for U-Boot. I'm not sure why, nor whether it matters. It seems to work find using it for both.
Depending on the toolchain, we actively need USE_PRIVATE_LIBGCC for SPL, and don't /need/ it for non-SPL. However, enabling USE_PRIVATE_LIBGCC for non-SPL likely won't hurt.
The issue is that the libgcc bundled with most compilers is for ARMv7 (since we tend to use ARMv7 compilers, since the main U-boot is built for ARMv7). That bundled libgcc won't work on the ARMv4 that runs the SPL, so we need USE_PRIVATE_LIBGCC there. The private libgcc bundled with U-Boot should work fine when built for either CPU, so it is OK to always use it, rather than only use it when strictly needed.
Hi Stephen,
On 23 February 2015 at 10:33, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/23/2015 07:02 AM, Simon Glass wrote:
Hi Masahiro,
On 20 February 2015 at 19:37, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2015-02-21 11:28 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote: > > On 02/20/2015 10:06 AM, Simon Glass wrote: >> >> >> +Stephen >> >> Hi Masahiro, >> >> On 19 February 2015 at 22:25, Masahiro Yamada >> yamada.m@jp.panasonic.com >> wrote: >>> >>> >>> Now CONFIG_SPL_BUILD is not defined in Kconfig, so >>> "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant. > > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>> index 41f3220..700e2a8 100644 >>> --- a/arch/arm/Kconfig >>> +++ b/arch/arm/Kconfig >>> @@ -739,9 +739,8 @@ config TEGRA >>> bool "NVIDIA Tegra" >>> select SUPPORT_SPL >>> select SPL >>> - select OF_CONTROL if !SPL_BUILD >>> - select CPU_ARM720T if SPL_BUILD >>> - select CPU_V7 if !SPL_BUILD >>> + select OF_CONTROL >>> + select CPU_V7 >> >> >> >> Sorry if I have missed something here. On Tegra most unfortunately >> the >> SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the >> only >> reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, exactly!
This all works fine on Tegra for me. However I like to suggest dropping a few patches in this series.
I don't think it is worth using ARCH_MALLOC_F_LEN. In fact for me the Tegra defconfig looks OK and SPL is built correctly.
My remaining question is about that Tegra seems to want USE_PRIVATE_LIBGCC for SPL but not for U-Boot. I'm not sure why, nor whether it matters. It seems to work find using it for both.
Depending on the toolchain, we actively need USE_PRIVATE_LIBGCC for SPL, and don't /need/ it for non-SPL. However, enabling USE_PRIVATE_LIBGCC for non-SPL likely won't hurt.
The issue is that the libgcc bundled with most compilers is for ARMv7 (since we tend to use ARMv7 compilers, since the main U-boot is built for ARMv7). That bundled libgcc won't work on the ARMv4 that runs the SPL, so we need USE_PRIVATE_LIBGCC there. The private libgcc bundled with U-Boot should work fine when built for either CPU, so it is OK to always use it, rather than only use it when strictly needed.
Ah yes, I think I knew that once. So in short Masahiro's patch here should be fine.
Regards, Simon
Hi Simon, Stephen,
On Mon, 23 Feb 2015 10:44:54 -0700 Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 23 February 2015 at 10:33, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/23/2015 07:02 AM, Simon Glass wrote:
Hi Masahiro,
On 20 February 2015 at 19:37, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2015-02-21 11:28 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org: > > Hi, > > On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org > wrote: >> >> On 02/20/2015 10:06 AM, Simon Glass wrote: >>> >>> >>> +Stephen >>> >>> Hi Masahiro, >>> >>> On 19 February 2015 at 22:25, Masahiro Yamada >>> yamada.m@jp.panasonic.com >>> wrote: >>>> >>>> >>>> Now CONFIG_SPL_BUILD is not defined in Kconfig, so >>>> "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant. >> >> >> >>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>>> index 41f3220..700e2a8 100644 >>>> --- a/arch/arm/Kconfig >>>> +++ b/arch/arm/Kconfig >>>> @@ -739,9 +739,8 @@ config TEGRA >>>> bool "NVIDIA Tegra" >>>> select SUPPORT_SPL >>>> select SPL >>>> - select OF_CONTROL if !SPL_BUILD >>>> - select CPU_ARM720T if SPL_BUILD >>>> - select CPU_V7 if !SPL_BUILD >>>> + select OF_CONTROL >>>> + select CPU_V7 >>> >>> >>> >>> Sorry if I have missed something here. On Tegra most unfortunately >>> the >>> SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the >>> only >>> reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, exactly!
This all works fine on Tegra for me. However I like to suggest dropping a few patches in this series.
I don't think it is worth using ARCH_MALLOC_F_LEN. In fact for me the Tegra defconfig looks OK and SPL is built correctly.
My remaining question is about that Tegra seems to want USE_PRIVATE_LIBGCC for SPL but not for U-Boot. I'm not sure why, nor whether it matters. It seems to work find using it for both.
Depending on the toolchain, we actively need USE_PRIVATE_LIBGCC for SPL, and don't /need/ it for non-SPL. However, enabling USE_PRIVATE_LIBGCC for non-SPL likely won't hurt.
The issue is that the libgcc bundled with most compilers is for ARMv7 (since we tend to use ARMv7 compilers, since the main U-boot is built for ARMv7). That bundled libgcc won't work on the ARMv4 that runs the SPL, so we need USE_PRIVATE_LIBGCC there. The private libgcc bundled with U-Boot should work fine when built for either CPU, so it is OK to always use it, rather than only use it when strictly needed.
Ah yes, I think I knew that once. So in short Masahiro's patch here should be fine.
Yes, Stephen explained all about my intention.
I think CONFIG_USE_PRIVATE_LIBGCC is also necessary for Raspberry Pi 1 for example.
Moreover, I had already posted this patch: http://patchwork.ozlabs.org/patch/438360/
I'd like to expand the private library to all the ARM boards.
Linux Kernel includes the library in its source tree.
I think it is generally a good idea to reduce the depencendy on particular toolchains. Agree?
Best Regards Masahiro Yamada
On 02/23/2015 10:05 PM, Masahiro Yamada wrote:
Hi Simon, Stephen,
On Mon, 23 Feb 2015 10:44:54 -0700 Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 23 February 2015 at 10:33, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/23/2015 07:02 AM, Simon Glass wrote:
Hi Masahiro,
On 20 February 2015 at 19:37, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2015-02-21 11:28 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote: > > Hi Simon, Stephen, > > > 2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org: >> >> Hi, >> >> On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org >> wrote: >>> >>> On 02/20/2015 10:06 AM, Simon Glass wrote: >>>> >>>> >>>> +Stephen >>>> >>>> Hi Masahiro, >>>> >>>> On 19 February 2015 at 22:25, Masahiro Yamada >>>> yamada.m@jp.panasonic.com >>>> wrote: >>>>> >>>>> >>>>> Now CONFIG_SPL_BUILD is not defined in Kconfig, so >>>>> "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant. >>> >>> >>> >>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>>>> index 41f3220..700e2a8 100644 >>>>> --- a/arch/arm/Kconfig >>>>> +++ b/arch/arm/Kconfig >>>>> @@ -739,9 +739,8 @@ config TEGRA >>>>> bool "NVIDIA Tegra" >>>>> select SUPPORT_SPL >>>>> select SPL >>>>> - select OF_CONTROL if !SPL_BUILD >>>>> - select CPU_ARM720T if SPL_BUILD >>>>> - select CPU_V7 if !SPL_BUILD >>>>> + select OF_CONTROL >>>>> + select CPU_V7 >>>> >>>> >>>> >>>> Sorry if I have missed something here. On Tegra most unfortunately >>>> the >>>> SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the >>>> only >>>> reason that Tegra has SPL. Doesn't this change with this commit? > > > > No. I think behavior is still the same as before. > > In a single .config, we cannot define two CPUs in Kconfig. > > So, we only define CPU_V7, for the main processors. > > For SPL, we override the "CPU" in config.mk > > ifdef CONFIG_SPL_BUILD > ifdef CONFIG_TEGRA > CPU := arm720t > endif > endif > > I know what you might be saying is, this is too ugly. Yes. > > I think we can do a little better with further rafactoring, > but the basic idea is, SPL of Tegra is a special case. >
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, exactly!
This all works fine on Tegra for me. However I like to suggest dropping a few patches in this series.
I don't think it is worth using ARCH_MALLOC_F_LEN. In fact for me the Tegra defconfig looks OK and SPL is built correctly.
My remaining question is about that Tegra seems to want USE_PRIVATE_LIBGCC for SPL but not for U-Boot. I'm not sure why, nor whether it matters. It seems to work find using it for both.
Depending on the toolchain, we actively need USE_PRIVATE_LIBGCC for SPL, and don't /need/ it for non-SPL. However, enabling USE_PRIVATE_LIBGCC for non-SPL likely won't hurt.
The issue is that the libgcc bundled with most compilers is for ARMv7 (since we tend to use ARMv7 compilers, since the main U-boot is built for ARMv7). That bundled libgcc won't work on the ARMv4 that runs the SPL, so we need USE_PRIVATE_LIBGCC there. The private libgcc bundled with U-Boot should work fine when built for either CPU, so it is OK to always use it, rather than only use it when strictly needed.
Ah yes, I think I knew that once. So in short Masahiro's patch here should be fine.
Yes, Stephen explained all about my intention.
I think CONFIG_USE_PRIVATE_LIBGCC is also necessary for Raspberry Pi 1 for example.
I can't remember if it's already set for the Pi. If not, the toolchains I use happen not to need it:-)
Moreover, I had already posted this patch: http://patchwork.ozlabs.org/patch/438360/
I'd like to expand the private library to all the ARM boards.
Linux Kernel includes the library in its source tree.
I think it is generally a good idea to reduce the depencendy on particular toolchains. Agree?
I tend to agree. However, in the past, Wolfgang Denk has argued against (ever?) using that option, claiming people should just use the correct toolchain.
Hi Simon,
On Mon, 23 Feb 2015 07:02:25 -0700 Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On 20 February 2015 at 19:37, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2015-02-21 11:28 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 20 February 2015 at 17:54, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon, Stephen,
2015-02-21 3:39 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 20 February 2015 at 10:54, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/20/2015 10:06 AM, Simon Glass wrote: > > +Stephen > > Hi Masahiro, > > On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com > wrote: >> >> Now CONFIG_SPL_BUILD is not defined in Kconfig, so >> "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant.
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 41f3220..700e2a8 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -739,9 +739,8 @@ config TEGRA >> bool "NVIDIA Tegra" >> select SUPPORT_SPL >> select SPL >> - select OF_CONTROL if !SPL_BUILD >> - select CPU_ARM720T if SPL_BUILD >> - select CPU_V7 if !SPL_BUILD >> + select OF_CONTROL >> + select CPU_V7 > > > Sorry if I have missed something here. On Tegra most unfortunately the > SPL uses ARMv4t and U-Boot proper uses ARMv7. In fact that is the only > reason that Tegra has SPL. Doesn't this change with this commit?
No. I think behavior is still the same as before.
In a single .config, we cannot define two CPUs in Kconfig.
So, we only define CPU_V7, for the main processors.
For SPL, we override the "CPU" in config.mk
ifdef CONFIG_SPL_BUILD ifdef CONFIG_TEGRA CPU := arm720t endif endif
I know what you might be saying is, this is too ugly. Yes.
I think we can do a little better with further rafactoring, but the basic idea is, SPL of Tegra is a special case.
Yes I saw that, I understand now. So SPL_BUILD is no longer available in Kconfig, but is still available in Makefiles, right?
Yes, exactly!
This all works fine on Tegra for me. However I like to suggest dropping a few patches in this series.
I don't think it is worth using ARCH_MALLOC_F_LEN. In fact for me the Tegra defconfig looks OK and SPL is built correctly.
My remaining question is about that Tegra seems to want USE_PRIVATE_LIBGCC for SPL but not for U-Boot. I'm not sure why, nor whether it matters. It seems to work find using it for both.
I have pushed my tested tree to u-boot-x86 in branch single-kconfig-for-masahiro.
It contains only these patches:
ARM: UniPhier: set CONFIG_SYS_MALLOC_F to the global default value kconfig: Adjust ordering so that defaults work as expected kconfig: switch to single .config configuration kconfig: remove unneeded dependency on !SPL_BUILD
Perhaps we can look at the others later once we get things moved over? I think the SYS_MALLOC_F thing is not that big a deal and not urgent to resolve if we still have a problem.
OK. Let's go with these four.
Including SYS_MALLOC_F things makes the point of this series blurred.
I have just posted v5.
Mashiro Yamada
To use Derive Model before relocation, CONFIG_SYS_MALLOC_F must be enabled. This should probably be a common requirement for all the boards with Driver Model implementation. Let's handle it globally rather than per-SoC or per-board.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com ---
Changes in v3: - Newly added
Changes in v2: None
Kconfig | 1 + arch/arm/cpu/armv7/exynos/Kconfig | 3 --- arch/arm/cpu/armv7/omap3/Kconfig | 3 --- arch/arm/cpu/armv7/tegra-common/Kconfig | 3 --- arch/arm/cpu/armv7/uniphier/Kconfig | 3 --- arch/x86/Kconfig | 3 --- board/amcc/canyonlands/Kconfig | 4 ---- board/ti/am335x/Kconfig | 3 --- 8 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/Kconfig b/Kconfig index a66a97f..2ddec81 100644 --- a/Kconfig +++ b/Kconfig @@ -54,6 +54,7 @@ config CC_OPTIMIZE_FOR_SIZE
config SYS_MALLOC_F bool "Enable malloc() pool before relocation" + default y if DM help Before relocation memory is very limited on many platforms. Still, we can provide a small malloc() pool if needed. Driver model in diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 9e47ed3..bd7540a 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -80,9 +80,6 @@ config DM_SPI_FLASH config DM_GPIO default y
-config SYS_MALLOC_F - default y - source "board/samsung/smdkv310/Kconfig" source "board/samsung/trats/Kconfig" source "board/samsung/universal_c210/Kconfig" diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig index b3d5ef3..a38d471 100644 --- a/arch/arm/cpu/armv7/omap3/Kconfig +++ b/arch/arm/cpu/armv7/omap3/Kconfig @@ -102,9 +102,6 @@ config DM_GPIO config DM_SERIAL default y if DM
-config SYS_MALLOC_F - default y if DM - config SYS_SOC default "omap3"
diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig b/arch/arm/cpu/armv7/tegra-common/Kconfig index 2003fc8..b1c4f2a 100644 --- a/arch/arm/cpu/armv7/tegra-common/Kconfig +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig @@ -17,9 +17,6 @@ config TEGRA124
endchoice
-config SYS_MALLOC_F - default y - config ARCH_MALLOC_F_LEN hex default 0x1800 diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index b6dc75f..20e20a5 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -48,9 +48,6 @@ config DCC_MICRO_SUPPORT_CARD
endchoice
-config SYS_MALLOC_F - default y - config CMD_PINMON bool "Enable boot mode pins monitor command" default y diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 0e49dd3..46caa6d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -76,9 +76,6 @@ config DM_GPIO config DM_SERIAL default y
-config SYS_MALLOC_F - default y - config ARCH_MALLOC_F_LEN hex default 0x800 diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index c0dbd18..46efa7a 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -39,8 +39,4 @@ config DM config DM_SERIAL default y
-config SYS_MALLOC_F - bool - default y - endif diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index 8c45892..7cb006f 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -47,7 +47,4 @@ config DM_GPIO config DM_SERIAL default y if DM
-config SYS_MALLOC_F - default y if DM - endif
Hi Masahiro,
On 19 February 2015 at 22:25, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
To use Derive Model before relocation, CONFIG_SYS_MALLOC_F
Driver
must be enabled. This should probably be a common requirement for all the boards with Driver Model implementation. Let's handle it globally rather than per-SoC or per-board.
This seems reasonable to me.
Reviewed-by: Simon Glass sjg@chromium.org
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com
Changes in v3:
- Newly added
Changes in v2: None
Kconfig | 1 + arch/arm/cpu/armv7/exynos/Kconfig | 3 --- arch/arm/cpu/armv7/omap3/Kconfig | 3 --- arch/arm/cpu/armv7/tegra-common/Kconfig | 3 --- arch/arm/cpu/armv7/uniphier/Kconfig | 3 --- arch/x86/Kconfig | 3 --- board/amcc/canyonlands/Kconfig | 4 ---- board/ti/am335x/Kconfig | 3 --- 8 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/Kconfig b/Kconfig index a66a97f..2ddec81 100644 --- a/Kconfig +++ b/Kconfig @@ -54,6 +54,7 @@ config CC_OPTIMIZE_FOR_SIZE
config SYS_MALLOC_F bool "Enable malloc() pool before relocation"
default y if DM help Before relocation memory is very limited on many platforms. Still, we can provide a small malloc() pool if needed. Driver model indiff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 9e47ed3..bd7540a 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -80,9 +80,6 @@ config DM_SPI_FLASH config DM_GPIO default y
-config SYS_MALLOC_F
default ysource "board/samsung/smdkv310/Kconfig" source "board/samsung/trats/Kconfig" source "board/samsung/universal_c210/Kconfig" diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig index b3d5ef3..a38d471 100644 --- a/arch/arm/cpu/armv7/omap3/Kconfig +++ b/arch/arm/cpu/armv7/omap3/Kconfig @@ -102,9 +102,6 @@ config DM_GPIO config DM_SERIAL default y if DM
-config SYS_MALLOC_F
default y if DMconfig SYS_SOC default "omap3"
diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig b/arch/arm/cpu/armv7/tegra-common/Kconfig index 2003fc8..b1c4f2a 100644 --- a/arch/arm/cpu/armv7/tegra-common/Kconfig +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig @@ -17,9 +17,6 @@ config TEGRA124
endchoice
-config SYS_MALLOC_F
default yconfig ARCH_MALLOC_F_LEN hex default 0x1800 diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index b6dc75f..20e20a5 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -48,9 +48,6 @@ config DCC_MICRO_SUPPORT_CARD
endchoice
-config SYS_MALLOC_F
default yconfig CMD_PINMON bool "Enable boot mode pins monitor command" default y diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 0e49dd3..46caa6d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -76,9 +76,6 @@ config DM_GPIO config DM_SERIAL default y
-config SYS_MALLOC_F
default yconfig ARCH_MALLOC_F_LEN hex default 0x800 diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig index c0dbd18..46efa7a 100644 --- a/board/amcc/canyonlands/Kconfig +++ b/board/amcc/canyonlands/Kconfig @@ -39,8 +39,4 @@ config DM config DM_SERIAL default y
-config SYS_MALLOC_F
booldefault yendif diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index 8c45892..7cb006f 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -47,7 +47,4 @@ config DM_GPIO config DM_SERIAL default y if DM
-config SYS_MALLOC_F
default y if DMendif
1.9.1
Regards, Simon
participants (5)
-
Masahiro YAMADA -
Masahiro Yamada
-
Scott Wood -
Simon Glass -
Stephen Warren