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 <[email protected]>

Quoted 4 lines · Lukasz Majewski

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.

Quoted 4 lines

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 <[email protected]>

I don't get it, sorry. We need to move CONFIG_BOOTCOMMAND into Kconfig with some other logic so that distro_bootcmd stuff works.

Quoted 6 lines · Tom Rini

Quoted 4 lines · Lukasz Majewski

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.

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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"?

Quoted 19 lines · Łukasz Majewski

Quoted 6 lines · Tom Rini

Quoted 4 lines · Lukasz Majewski

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.

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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:
---------------------

Quoted 6 lines

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.

Quoted 19 lines

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.

Quoted 1 line

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.

Quoted 50 lines · Tom Rini

Quoted 19 lines · Łukasz Majewski

Quoted 6 lines · Tom Rini

Quoted 4 lines · Lukasz Majewski

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.

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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:
---------------------

Quoted 6 lines

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.

Quoted 20 lines

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"?

Quoted 3 lines

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?

Quoted 58 lines · Łukasz Majewski

Quoted 48 lines · Tom Rini

Quoted 19 lines · Łukasz Majewski

Quoted 6 lines · Tom Rini

Quoted 4 lines · Lukasz Majewski

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.

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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:
---------------------

Quoted 6 lines

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.

Quoted 19 lines

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.

Quoted 5 lines

Quoted 1 line

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?

Quoted 1 line

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.

Quoted 60 lines · Tom Rini

Quoted 50 lines · Łukasz Majewski

Quoted 20 lines · Tom Rini

Quoted 6 lines · Lukasz Majewski

Quoted 5 lines

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.

Quoted 9 lines

Quoted 5 lines

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 <[email protected]>

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:
---------------------

Quoted 6 lines

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.

Quoted 20 lines

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.

Quoted 5 lines

Quoted 1 line

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?

Quoted 1 line

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.

Hi Tom,

Quoted 61 lines · Łukasz Majewski

Quoted 60 lines · Tom Rini

Quoted 50 lines · Łukasz Majewski

Quoted 20 lines · Tom Rini

Quoted 6 lines · Lukasz Majewski

Quoted 5 lines

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.

Quoted 9 lines

Quoted 5 lines

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 <[email protected]>

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:
---------------------

Quoted 6 lines

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.

Quoted 20 lines

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.

Quoted 5 lines

Quoted 1 line

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?

Quoted 8 lines

Quoted 1 line

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.

Quoted 85 lines

Hi Tom,

Quoted 64 lines · Łukasz Majewski

Quoted 63 lines · Tom Rini

Quoted 53 lines

Quoted 22 lines · Łukasz Majewski

Quoted 11 lines · Tom Rini

Quoted 8 lines · Lukasz Majewski

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.

Quoted 6 lines

Quoted 1 line

Signed-off-by Lukasz Majewski <[email protected]>

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:
---------------------

Quoted 6 lines

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.

Quoted 20 lines

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.

Quoted 5 lines

Quoted 1 line

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?

Quoted 8 lines

Quoted 1 line

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.

Quoted 1 line

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.