[U-Boot] [PATCH] Kconfig: BOOTCOMMAND: Define default set of boot commands in Kconfig
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de --- cmd/Kconfig | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig index d6d130e..e5c12a9 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -30,6 +30,21 @@ config SYS_PROMPT This string is displayed in the command line to the left of the cursor.
+config BOOTCMD_OVERRIDE + bool "Override default CONFIG_BOOTCOMMAND define" + help + This option allows overriding the CONFIG_BOOTCOMMAND define + from the Kconfig as many boards define their default set of + commands with CONFIG_BOOTCOMMAND. + +config BOOTCOMMAND + string "Default boot commands" + depends on BOOTCMD_OVERRIDE + default "" + help + This string contains the set of u-boot commands to be executed + by default. + menu "Autoboot options"
config AUTOBOOT
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
On 09/11/2017 07:31 PM, Tom Rini wrote:
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
The state of the art: ---------------------
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Rationale: ----------
With this patch I can:
1. Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
2. Have other defconfig - e.g. <my_board>_factory_defconfig, which enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
On 09/11/2017 07:31 PM, Tom Rini wrote:
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
The state of the art:
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Right.
Rationale:
With this patch I can:
- Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
- Have other defconfig - e.g. <my_board>_factory_defconfig, which
enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself. Figuring out some of the "how" will take a little work. And a little re-organization. But that needs doing.
On 09/14/2017 04:55 PM, Tom Rini wrote:
On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
On 09/11/2017 07:31 PM, Tom Rini wrote:
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
The state of the art:
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Right.
Rationale:
With this patch I can:
- Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
- Have other defconfig - e.g. <my_board>_factory_defconfig, which
enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself. Figuring out some of the "how" will take a little work. And a little re-organization. But that needs doing.
Cannot we start with the approach proposed by this commit?
How would you see the rework done?
On Sat, Sep 30, 2017 at 10:20:47PM +0200, Łukasz Majewski wrote:
On 09/14/2017 04:55 PM, Tom Rini wrote:
On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
On 09/11/2017 07:31 PM, Tom Rini wrote:
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
The state of the art:
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Right.
Rationale:
With this patch I can:
- Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
- Have other defconfig - e.g. <my_board>_factory_defconfig, which
enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself. Figuring out some of the "how" will take a little work. And a little re-organization. But that needs doing.
Cannot we start with the approach proposed by this commit?
How would you see the rework done?
I'd like to see something that tries to move CONFIG_BOOTCOMMAND around. Move the distro boot things into include/environment/ and use the post-processed command as value in configs/*_defconfig as fits, or put things into something else in include/environment/ for other repeated but not distro boot commands.
On 10/01/2017 02:41 AM, Tom Rini wrote:
On Sat, Sep 30, 2017 at 10:20:47PM +0200, Łukasz Majewski wrote:
On 09/14/2017 04:55 PM, Tom Rini wrote:
On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
On 09/11/2017 07:31 PM, Tom Rini wrote:
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
The state of the art:
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Right.
Rationale:
With this patch I can:
- Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
- Have other defconfig - e.g. <my_board>_factory_defconfig, which
enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself. Figuring out some of the "how" will take a little work. And a little re-organization. But that needs doing.
Cannot we start with the approach proposed by this commit?
How would you see the rework done?
I'd like to see something that tries to move CONFIG_BOOTCOMMAND around. Move the distro boot things into include/environment/ and use the post-processed command as value in configs/*_defconfig as fits, or put things into something else in include/environment/ for other repeated but not distro boot commands.
The proposed above changes are orthogonal to this patch.
This patch _only_ gives the opportunity to override current BOOTCOMMAND settings. This functionality allows the same code base for two distinct u-boot builds - namely factory (for flashing) and production one.
Such approach is very convenient with OE builds.
Hi Tom,
On Sat, Sep 30, 2017 at 10:20:47PM +0200, Łukasz Majewski wrote:
On 09/14/2017 04:55 PM, Tom Rini wrote:
On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
On 09/11/2017 07:31 PM, Tom Rini wrote:
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
This patch gives an opportunity to override the defined CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of commands defined in board _defconfig file.
Rationale: This change allows having two different u-boot builds - one for production and one (far more larger) for factory setup.
Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
The state of the art:
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Right.
Rationale:
With this patch I can:
- Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
- Have other defconfig - e.g. <my_board>_factory_defconfig, which
enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself. Figuring out some of the "how" will take a little work. And a little re-organization. But that needs doing.
Cannot we start with the approach proposed by this commit?
How would you see the rework done?
I'd like to see something that tries to move CONFIG_BOOTCOMMAND around. Move the distro boot things into include/environment/ and use the post-processed command as value in configs/*_defconfig as fits, or put things into something else in include/environment/ for other repeated but not distro boot commands.
I've not received any reply from you regarding following argument for this patch:
The proposed above changes are orthogonal to this patch.
This patch _only_ gives the opportunity to override current BOOTCOMMAND settings. This functionality allows the same code base for two distinct u-boot builds - namely factory (for flashing) and production one.
Such approach is very convenient with OE builds.
The whole discussion can be find at: https://patchwork.ozlabs.org/patch/812174/
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
On Fri, Oct 27, 2017 at 02:04:53PM +0200, Lukasz Majewski wrote:
Hi Tom,
On Sat, Sep 30, 2017 at 10:20:47PM +0200, Łukasz Majewski wrote:
On 09/14/2017 04:55 PM, Tom Rini wrote:
On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
On 09/11/2017 07:31 PM, Tom Rini wrote:
On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
>This patch gives an opportunity to override the defined >CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of >commands defined in board _defconfig file. > >Rationale: This change allows having two different u-boot >builds - one for production and one (far more larger) for >factory setup. > >Signed-off-by: Lukasz Majewski lukma@denx.de
I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.
The state of the art:
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Right.
Rationale:
With this patch I can:
- Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
- Have other defconfig - e.g. <my_board>_factory_defconfig, which
enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself. Figuring out some of the "how" will take a little work. And a little re-organization. But that needs doing.
Cannot we start with the approach proposed by this commit?
How would you see the rework done?
I'd like to see something that tries to move CONFIG_BOOTCOMMAND around. Move the distro boot things into include/environment/ and use the post-processed command as value in configs/*_defconfig as fits, or put things into something else in include/environment/ for other repeated but not distro boot commands.
I've not received any reply from you regarding following argument for this patch:
The proposed above changes are orthogonal to this patch.
This patch _only_ gives the opportunity to override current BOOTCOMMAND settings. This functionality allows the same code base for two distinct u-boot builds - namely factory (for flashing) and production one.
Such approach is very convenient with OE builds.
The problem I see is that we should instead move CONFIG_BOOTCOMMAND to Kconfig and OE/similar can override bootcmd via .cfg or similar. To that end, I've started the migration at least for distro_bootcmd and some of the cases where it's not just 'run distro_bootcmd' being used. I hope to post it shortly, once I've migrated a few more options.
Hi Tom,
On Fri, Oct 27, 2017 at 02:04:53PM +0200, Lukasz Majewski wrote:
Hi Tom,
On Sat, Sep 30, 2017 at 10:20:47PM +0200, Łukasz Majewski wrote:
On 09/14/2017 04:55 PM, Tom Rini wrote:
On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
On 09/11/2017 07:31 PM, Tom Rini wrote: >On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski >wrote: > >>This patch gives an opportunity to override the defined >>CONFIG_BOOTCOMMAND (at <board_config.h> files) with set of >>commands defined in board _defconfig file. >> >>Rationale: This change allows having two different u-boot >>builds - one for production and one (far more larger) for >>factory setup. >> >>Signed-off-by: Lukasz Majewski lukma@denx.de > >I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND >into Kconfig with some other logic so that distro_bootcmd >stuff works. >
The state of the art:
Many boards use CONFIG_BOOTCOMMAND as a set of commands to be executed at boot time:
bootcmd=CONFIG_BOOTCOMMAND
One notable user of it is config_distro_bootcmd.h
Right.
Rationale:
With this patch I can:
- Setup one set of commands to be executed by default - e.g.:
bootcmd="run boot_mmc"
and
- Have other defconfig - e.g. <my_board>_factory_defconfig,
which enables some extra stuff (like USB, gadget, gpt write, etc) and is used solely for factory flashing.
By having the opportunity to override CONFIG_BOOTCOMMAND in Kconfig, I can use the same code base and just adjust Kconfig for board.
What do you mean by "some other logic"?
Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself. Figuring out some of the "how" will take a little work. And a little re-organization. But that needs doing.
Cannot we start with the approach proposed by this commit?
How would you see the rework done?
I'd like to see something that tries to move CONFIG_BOOTCOMMAND around. Move the distro boot things into include/environment/ and use the post-processed command as value in configs/*_defconfig as fits, or put things into something else in include/environment/ for other repeated but not distro boot commands.
I've not received any reply from you regarding following argument for this patch:
The proposed above changes are orthogonal to this patch.
This patch _only_ gives the opportunity to override current BOOTCOMMAND settings. This functionality allows the same code base for two distinct u-boot builds - namely factory (for flashing) and production one.
Such approach is very convenient with OE builds.
The problem I see is that we should instead move CONFIG_BOOTCOMMAND to Kconfig and OE/similar can override bootcmd via .cfg or similar. To that end, I've started the migration at least for distro_bootcmd and some of the cases where it's not just 'run distro_bootcmd' being used. I hope to post it shortly, once I've migrated a few more options.
I see. Thanks for update on this topic.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
participants (3)
-
Lukasz Majewski -
Tom Rini -
Łukasz Majewski