| Message ID | 1505067902-2530-1-git-send-email-lukma@denx.de |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [U-Boot] Kconfig: BOOTCOMMAND: Define default set of boot commands in Kconfig | expand |
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: > > 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"? 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: >> >> 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"? > > 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: > >> > >>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"? > > > >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: >>>> >>>> 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"? >>> >>> 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: > > >> > > >>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"? > > > > > >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: > > > >> > > > >>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"? > > > > > > > >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: > > > > >> > > > > >>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"? > > > > > > > > > >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
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
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(+)