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 <lu...@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: w...@denx.de
pgprzxfZmUUfN.pgp
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot