* [U-Boot] [PATCH v3 1/7] ARM: UniPhier: set CONFIG_SYS_MALLOC_F to the global default value
2015-02-20 5:24 [U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config Masahiro Yamada
@ 2015-02-20 5:24 ` Masahiro Yamada
2015-02-20 5:24 ` [U-Boot] [PATCH v3 2/7] malloc_f: fix broken .config caused by CONFIG_SYS_MALLOC_F Masahiro Yamada
` (5 subsequent siblings)
6 siblings, 0 replies; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-20 5:24 UTC (permalink / raw)
To: u-boot
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"
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 2/7] malloc_f: fix broken .config caused by CONFIG_SYS_MALLOC_F
2015-02-20 5:24 [U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config Masahiro Yamada
2015-02-20 5:24 ` [U-Boot] [PATCH v3 1/7] ARM: UniPhier: set CONFIG_SYS_MALLOC_F to the global default value Masahiro Yamada
@ 2015-02-20 5:24 ` Masahiro Yamada
2015-02-20 17:11 ` Simon Glass
2015-02-20 5:24 ` [U-Boot] [PATCH v3 3/7] kconfig: Adjust ordering so that defaults work as expected Masahiro Yamada
` (4 subsequent siblings)
6 siblings, 1 reply; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-20 5:24 UTC (permalink / raw)
To: u-boot
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
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 2/7] malloc_f: fix broken .config caused by CONFIG_SYS_MALLOC_F
2015-02-20 5:24 ` [U-Boot] [PATCH v3 2/7] malloc_f: fix broken .config caused by CONFIG_SYS_MALLOC_F Masahiro Yamada
@ 2015-02-20 17:11 ` Simon Glass
0 siblings, 0 replies; 32+ messages in thread
From: Simon Glass @ 2015-02-20 17:11 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 3/7] kconfig: Adjust ordering so that defaults work as expected
2015-02-20 5:24 [U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config Masahiro Yamada
2015-02-20 5:24 ` [U-Boot] [PATCH v3 1/7] ARM: UniPhier: set CONFIG_SYS_MALLOC_F to the global default value Masahiro Yamada
2015-02-20 5:24 ` [U-Boot] [PATCH v3 2/7] malloc_f: fix broken .config caused by CONFIG_SYS_MALLOC_F Masahiro Yamada
@ 2015-02-20 5:24 ` Masahiro Yamada
2015-02-20 5:24 ` [U-Boot] [PATCH v3 4/7] malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len Masahiro Yamada
` (3 subsequent siblings)
6 siblings, 0 replies; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-20 5:24 UTC (permalink / raw)
To: u-boot
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"
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 4/7] malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len
2015-02-20 5:24 [U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config Masahiro Yamada
` (2 preceding siblings ...)
2015-02-20 5:24 ` [U-Boot] [PATCH v3 3/7] kconfig: Adjust ordering so that defaults work as expected Masahiro Yamada
@ 2015-02-20 5:24 ` Masahiro Yamada
2015-02-20 17:11 ` Simon Glass
2015-02-20 17:11 ` Masahiro YAMADA
2015-02-20 5:24 ` [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration Masahiro Yamada
` (2 subsequent siblings)
6 siblings, 2 replies; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-20 5:24 UTC (permalink / raw)
To: u-boot
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
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 4/7] malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len
2015-02-20 5:24 ` [U-Boot] [PATCH v3 4/7] malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len Masahiro Yamada
@ 2015-02-20 17:11 ` Simon Glass
2015-02-20 17:11 ` Masahiro YAMADA
1 sibling, 0 replies; 32+ messages in thread
From: Simon Glass @ 2015-02-20 17:11 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 4/7] malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len
2015-02-20 5:24 ` [U-Boot] [PATCH v3 4/7] malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len Masahiro Yamada
2015-02-20 17:11 ` Simon Glass
@ 2015-02-20 17:11 ` Masahiro YAMADA
1 sibling, 0 replies; 32+ messages in thread
From: Masahiro YAMADA @ 2015-02-20 17:11 UTC (permalink / raw)
To: u-boot
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.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-20 5:24 [U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config Masahiro Yamada
` (3 preceding siblings ...)
2015-02-20 5:24 ` [U-Boot] [PATCH v3 4/7] malloc_f: add ARCH_MALLOC_F_LEN to specify SoC-default malloc_f_len Masahiro Yamada
@ 2015-02-20 5:24 ` Masahiro Yamada
2015-02-20 16:59 ` Simon Glass
2015-02-24 1:22 ` Scott Wood
2015-02-20 5:25 ` [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD Masahiro Yamada
2015-02-20 5:25 ` [U-Boot] [PATCH v3 7/7] malloc_f: enable SYS_MALLOC_F by default if DM is on Masahiro Yamada
6 siblings, 2 replies; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-20 5:24 UTC (permalink / raw)
To: u-boot
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
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-20 5:24 ` [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration Masahiro Yamada
@ 2015-02-20 16:59 ` Simon Glass
2015-02-24 1:22 ` Scott Wood
1 sibling, 0 replies; 32+ messages in thread
From: Simon Glass @ 2015-02-20 16:59 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-20 5:24 ` [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration Masahiro Yamada
2015-02-20 16:59 ` Simon Glass
@ 2015-02-24 1:22 ` Scott Wood
2015-02-24 7:20 ` Masahiro Yamada
2015-02-24 16:42 ` Simon Glass
1 sibling, 2 replies; 32+ messages in thread
From: Scott Wood @ 2015-02-24 1:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-24 1:22 ` Scott Wood
@ 2015-02-24 7:20 ` Masahiro Yamada
2015-02-25 0:17 ` Scott Wood
2015-02-24 16:42 ` Simon Glass
1 sibling, 1 reply; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-24 7:20 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-24 7:20 ` Masahiro Yamada
@ 2015-02-25 0:17 ` Scott Wood
2015-02-25 6:14 ` Masahiro Yamada
0 siblings, 1 reply; 32+ messages in thread
From: Scott Wood @ 2015-02-25 0:17 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-25 0:17 ` Scott Wood
@ 2015-02-25 6:14 ` Masahiro Yamada
2015-02-25 13:40 ` Simon Glass
2015-02-25 23:29 ` Scott Wood
0 siblings, 2 replies; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-25 6:14 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-25 6:14 ` Masahiro Yamada
@ 2015-02-25 13:40 ` Simon Glass
2015-02-25 23:29 ` Scott Wood
1 sibling, 0 replies; 32+ messages in thread
From: Simon Glass @ 2015-02-25 13:40 UTC (permalink / raw)
To: u-boot
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]
> #endif
>
> I 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-25 6:14 ` Masahiro Yamada
2015-02-25 13:40 ` Simon Glass
@ 2015-02-25 23:29 ` Scott Wood
1 sibling, 0 replies; 32+ messages in thread
From: Scott Wood @ 2015-02-25 23:29 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration
2015-02-24 1:22 ` Scott Wood
2015-02-24 7:20 ` Masahiro Yamada
@ 2015-02-24 16:42 ` Simon Glass
1 sibling, 0 replies; 32+ messages in thread
From: Simon Glass @ 2015-02-24 16:42 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-20 5:24 [U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config Masahiro Yamada
` (4 preceding siblings ...)
2015-02-20 5:24 ` [U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration Masahiro Yamada
@ 2015-02-20 5:25 ` Masahiro Yamada
2015-02-20 17:06 ` Simon Glass
2015-02-20 5:25 ` [U-Boot] [PATCH v3 7/7] malloc_f: enable SYS_MALLOC_F by default if DM is on Masahiro Yamada
6 siblings, 1 reply; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-20 5:25 UTC (permalink / raw)
To: u-boot
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
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-20 5:25 ` [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD Masahiro Yamada
@ 2015-02-20 17:06 ` Simon Glass
2015-02-20 17:54 ` Stephen Warren
0 siblings, 1 reply; 32+ messages in thread
From: Simon Glass @ 2015-02-20 17:06 UTC (permalink / raw)
To: u-boot
+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_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?
Regards,
Simon
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-20 17:06 ` Simon Glass
@ 2015-02-20 17:54 ` Stephen Warren
2015-02-20 18:39 ` Simon Glass
0 siblings, 1 reply; 32+ messages in thread
From: Stephen Warren @ 2015-02-20 17:54 UTC (permalink / raw)
To: u-boot
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?
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.
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-20 17:54 ` Stephen Warren
@ 2015-02-20 18:39 ` Simon Glass
2015-02-21 0:54 ` Masahiro YAMADA
0 siblings, 1 reply; 32+ messages in thread
From: Simon Glass @ 2015-02-20 18:39 UTC (permalink / raw)
To: u-boot
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?
>
>
> 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-20 18:39 ` Simon Glass
@ 2015-02-21 0:54 ` Masahiro YAMADA
2015-02-21 2:28 ` Simon Glass
0 siblings, 1 reply; 32+ messages in thread
From: Masahiro YAMADA @ 2015-02-21 0:54 UTC (permalink / raw)
To: u-boot
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, 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.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-21 0:54 ` Masahiro YAMADA
@ 2015-02-21 2:28 ` Simon Glass
2015-02-21 2:37 ` Masahiro YAMADA
0 siblings, 1 reply; 32+ messages in thread
From: Simon Glass @ 2015-02-21 2:28 UTC (permalink / raw)
To: u-boot
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, 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-21 2:28 ` Simon Glass
@ 2015-02-21 2:37 ` Masahiro YAMADA
2015-02-23 14:02 ` Simon Glass
0 siblings, 1 reply; 32+ messages in thread
From: Masahiro YAMADA @ 2015-02-21 2:37 UTC (permalink / raw)
To: u-boot
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!
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-21 2:37 ` Masahiro YAMADA
@ 2015-02-23 14:02 ` Simon Glass
2015-02-23 17:33 ` Stephen Warren
2015-02-24 13:36 ` Masahiro Yamada
0 siblings, 2 replies; 32+ messages in thread
From: Simon Glass @ 2015-02-23 14:02 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-23 14:02 ` Simon Glass
@ 2015-02-23 17:33 ` Stephen Warren
2015-02-23 17:44 ` Simon Glass
2015-02-24 13:36 ` Masahiro Yamada
1 sibling, 1 reply; 32+ messages in thread
From: Stephen Warren @ 2015-02-23 17:33 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-23 17:33 ` Stephen Warren
@ 2015-02-23 17:44 ` Simon Glass
2015-02-24 5:05 ` Masahiro Yamada
0 siblings, 1 reply; 32+ messages in thread
From: Simon Glass @ 2015-02-23 17:44 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-23 17:44 ` Simon Glass
@ 2015-02-24 5:05 ` Masahiro Yamada
2015-02-24 16:45 ` Stephen Warren
0 siblings, 1 reply; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-24 5:05 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-24 5:05 ` Masahiro Yamada
@ 2015-02-24 16:45 ` Stephen Warren
0 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2015-02-24 16:45 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD
2015-02-23 14:02 ` Simon Glass
2015-02-23 17:33 ` Stephen Warren
@ 2015-02-24 13:36 ` Masahiro Yamada
1 sibling, 0 replies; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-24 13:36 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 7/7] malloc_f: enable SYS_MALLOC_F by default if DM is on
2015-02-20 5:24 [U-Boot] [PATCH v3 0/7] kconfig: turnaround into single .config Masahiro Yamada
` (5 preceding siblings ...)
2015-02-20 5:25 ` [U-Boot] [PATCH v3 6/7] kconfig: remove unneeded dependency on !SPL_BUILD Masahiro Yamada
@ 2015-02-20 5:25 ` Masahiro Yamada
2015-02-20 17:08 ` Simon Glass
6 siblings, 1 reply; 32+ messages in thread
From: Masahiro Yamada @ 2015-02-20 5:25 UTC (permalink / raw)
To: u-boot
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
--
1.9.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [U-Boot] [PATCH v3 7/7] malloc_f: enable SYS_MALLOC_F by default if DM is on
2015-02-20 5:25 ` [U-Boot] [PATCH v3 7/7] malloc_f: enable SYS_MALLOC_F by default if DM is on Masahiro Yamada
@ 2015-02-20 17:08 ` Simon Glass
0 siblings, 0 replies; 32+ messages in thread
From: Simon Glass @ 2015-02-20 17:08 UTC (permalink / raw)
To: u-boot
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 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
> --
> 1.9.1
>
Regards,
Simon
^ permalink raw reply [flat|nested] 32+ messages in thread