Supporting building a second Barebox config

No functional changes, but prepares barebox for building with two configurations (similar to package/gcc).

Signed-off-by Pieter Smith <[email protected]>

---
 boot/barebox/Config.in                | 71 +++++++++++++++++++-----------
 boot/barebox/barebox-1/barebox-1.hash |  1 +
 boot/barebox/barebox-1/barebox-1.mk   | 81 +++++++++++++++++++++++++++++++++++
 boot/barebox/barebox.mk               | 61 +-------------------------
 4 files changed, 129 insertions(+), 85 deletions(-)
 create mode 120000 boot/barebox/barebox-1/barebox-1.hash
 create mode 100644 boot/barebox/barebox-1/barebox-1.mk

boot/barebox/Config.in +46 -25

index 39cb5d2..ed120af 100644
@@ -64,9 +64,52 @@ config BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION
 
 endif
 
+config BR2_TARGET_BAREBOX_BAREBOXENV
+       bool "bareboxenv tool in target"
+       help
+         Install bareboxenv tool in target.
+
+config BR2_TARGET_BAREBOX_CUSTOM_ENV
+       bool "Generate an environment image"
+       help
+         Generate a custom environment image. This environment will
+         contain the variables and scripts to be used at boot by
+         barebox.
+
+config BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH
+       string "Environment path"
+       depends on BR2_TARGET_BAREBOX_CUSTOM_ENV
+       help
+         Path to the directory containing the custom barebox
+         environment. Depending on your setup, it will probably be
+         based on either the content of the defaultenv or
+         defaultenv-2 directories in the barebox source code, plus
+         the additions needed. The output will be an image in the
+         barebox devfs format, stored in the images directory, with
+         the same name as the directory name given here.
 
 choice
-       prompt "Barebox configuration"
+       prompt "Number of Barebox configurations"
+       default BR2_TARGET_BAREBOX_SINGLE_CONFIG
+
+config BR2_TARGET_BAREBOX_ONE_CONFIG
+       select BR2_TARGET_BAREBOX_1
+       bool "Build 1 config"
+       help
+         Build only one barebox config.
+         Useful for building the traditional TPL (Tertiary Program
+         Loader).
+
+endchoice
+
+config BR2_TARGET_BAREBOX_1
+       bool "Barebox configuration 1"
+       default y
+
+if BR2_TARGET_BAREBOX_1
+
+choice
+       prompt "Type of configuration"
        default BR2_TARGET_BAREBOX_USE_DEFCONFIG
 
 config BR2_TARGET_BAREBOX_USE_DEFCONFIG

@@ -78,7 +121,7 @@ config BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG
 endchoice
 
 config BR2_TARGET_BAREBOX_BOARD_DEFCONFIG
-       string "board defconfig"
+       string "Board defconfig"
        depends on BR2_TARGET_BAREBOX_USE_DEFCONFIG
        help
          Name of the board for which Barebox should be built, without

@@ -97,28 +140,6 @@ config BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES
          A space-separated list of configuration fragment files,
          that will be merged to the main Barebox configuration file.
 
-config BR2_TARGET_BAREBOX_BAREBOXENV
-       bool "bareboxenv tool in target"
-       help
-         Install bareboxenv tool in target.
-
-config BR2_TARGET_BAREBOX_CUSTOM_ENV
-       bool "Generate an environment image"
-       help
-         Generate a custom environment image. This environment will
-         contain the variables and scripts to be used at boot by
-         barebox.
-
-config BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH
-       string "Environment path"
-       depends on BR2_TARGET_BAREBOX_CUSTOM_ENV
-       help
-         Path to the directory containing the custom barebox
-         environment. Depending on your setup, it will probably be
-         based on either the content of the defaultenv or
-         defaultenv-2 directories in the barebox source code, plus
-         the additions needed. The output will be an image in the
-         barebox devfs format, stored in the images directory, with
-         the same name as the directory name given here.
+endif
 
 endif

boot/barebox/barebox-1/barebox-1.hash new file +1 -0

new file mode 120000
index 0000000..b6462b8
@@ -0,0 +1 @@
+../barebox.hash
\ No newline at end of file

boot/barebox/barebox-1/barebox-1.mk new file +81 -0

new file mode 100644
index 0000000..3374ece
@@ -0,0 +1,81 @@
+################################################################################
+#
+# barebox-1
+#
+################################################################################
+
+BAREBOX_1_VERSION = $(BAREBOX_VERSION)
+BAREBOX_1_SITE = $(BAREBOX_SITE)
+BAREBOX_1_SITE_METHOD = $(BAREBOX_SITE_METHOD)
+BAREBOX_1_SOURCE = $(BAREBOX_SOURCE)
+BAREBOX_1_DEPENDENCIES = $(BAREBOX_DEPENDENCIES)
+BAREBOX_1_LICENSE = $(BAREBOX_LICENSE)
+BAREBOX_1_LICENSE_FILES = $(BAREBOX_LICENSE_FILES)
+BAREBOX_1_POST_PATCH_HOOKS += $(BAREBOX_POST_PATCH_HOOKS)
+BAREBOX_1_MAKE_FLAGS = $(BAREBOX_MAKE_FLAGS)
+BAREBOX_1_MAKE_ENV = $(BAREBOX_MAKE_ENV)
+BAREBOX_1_INSTALL_IMAGES = $(BAREBOX_INSTALL_IMAGES)
+
+ifeq ($(BR2_TARGET_BAREBOX_USE_DEFCONFIG),y)
+BAREBOX_1_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_TARGET_BAREBOX_BOARD_DEFCONFIG))_defconfig
+else ifeq ($(BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG),y)
+BAREBOX_1_KCONFIG_FILE = $(call qstrip,$(BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE))
+endif
+
+BAREBOX_1_KCONFIG_FRAGMENT_FILES = $(BAREBOX_KCONFIG_FRAGMENT_FILES)
+BAREBOX_1_KCONFIG_EDITORS = $(BAREBOX_KCONFIG_EDITORS)
+BAREBOX_1_KCONFIG_OPTS = $(BAREBOX_MAKE_FLAGS)
+
+ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
+define BAREBOX_1_BUILD_BAREBOXENV_CMDS
+       $(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS) -o $(@D)/bareboxenv \
+               $(@D)/scripts/bareboxenv.c
+endef
+endif
+
+ifeq ($(BR2_TARGET_BAREBOX_CUSTOM_ENV),y)
+BAREBOX_1_ENV_NAME = $(notdir $(call qstrip,\
+       $(BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH)))
+define BAREBOX_1_BUILD_CUSTOM_ENV
+       $(@D)/scripts/bareboxenv -s \
+               $(call qstrip, $(BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH)) \
+               $(@D)/$(BAREBOX_1_ENV_NAME)
+endef
+define BAREBOX_1_INSTALL_CUSTOM_ENV
+       cp $(@D)/$(BAREBOX_1_ENV_NAME) $(BINARIES_DIR)
+endef
+endif
+
+define BAREBOX_1_BUILD_CMDS
+       $(BAREBOX_1_BUILD_BAREBOXENV_CMDS)
+       $(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_1_MAKE_FLAGS) -C $(@D)
+       $(BAREBOX_1_BUILD_CUSTOM_ENV)
+endef
+
+define BAREBOX_1_INSTALL_IMAGES_CMDS
+       if test -h $(@D)/barebox-flash-image ; then \
+               cp -L $(@D)/barebox-flash-image $(BINARIES_DIR)/barebox.bin ; \
+       else \
+               cp $(@D)/barebox.bin $(BINARIES_DIR);\
+       fi
+       $(BAREBOX_1_INSTALL_CUSTOM_ENV)
+endef
+
+ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
+define BAREBOX_1_INSTALL_TARGET_CMDS
+       cp $(@D)/bareboxenv $(TARGET_DIR)/usr/bin
+endef
+endif
+
+# Checks to give errors that the user can understand
+# Must be before we call to kconfig-package
+ifeq ($(BR2_TARGET_BAREBOX_2)$(BR_BUILDING),yy)
+# We must use the user-supplied kconfig value, because
+# BAREBOX_1_KCONFIG_DEFCONFIG will at least contain the
+# trailing _defconfig
+ifeq ($(or $(BAREBOX_1_KCONFIG_FILE),$(call qstrip,$(BR2_TARGET_BAREBOX_BOARD_DEFCONFIG))),)
+$(error No Barebox config. Check your BR2_TARGET_BAREBOX_BOARD_DEFCONFIG or BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE settings)
+endif
+endif
+
+$(eval $(kconfig-package))

boot/barebox/barebox.mk +1 -61

index 7715daf..55bd187 100644
@@ -55,66 +55,7 @@ endif
 BAREBOX_MAKE_FLAGS = ARCH=$(BAREBOX_ARCH) CROSS_COMPILE="$(TARGET_CROSS)"
 BAREBOX_MAKE_ENV = $(TARGET_MAKE_ENV)
 
-ifeq ($(BR2_TARGET_BAREBOX_USE_DEFCONFIG),y)
-BAREBOX_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_TARGET_BAREBOX_BOARD_DEFCONFIG))_defconfig
-else ifeq ($(BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG),y)
-BAREBOX_KCONFIG_FILE = $(call qstrip,$(BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE))
-endif
-
 BAREBOX_KCONFIG_FRAGMENT_FILES = $(call qstrip,$(BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES))
 BAREBOX_KCONFIG_EDITORS = menuconfig xconfig gconfig nconfig
-BAREBOX_KCONFIG_OPTS = $(BAREBOX_MAKE_FLAGS)
-
-ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
-define BAREBOX_BUILD_BAREBOXENV_CMDS
-       $(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS) -o $(@D)/bareboxenv \
-               $(@D)/scripts/bareboxenv.c
-endef
-endif
-
-ifeq ($(BR2_TARGET_BAREBOX_CUSTOM_ENV),y)
-BAREBOX_ENV_NAME = $(notdir $(call qstrip,\
-       $(BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH)))
-define BAREBOX_BUILD_CUSTOM_ENV
-       $(@D)/scripts/bareboxenv -s \
-               $(call qstrip, $(BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH)) \
-               $(@D)/$(BAREBOX_ENV_NAME)
-endef
-define BAREBOX_INSTALL_CUSTOM_ENV
-       cp $(@D)/$(BAREBOX_ENV_NAME) $(BINARIES_DIR)
-endef
-endif
-
-define BAREBOX_BUILD_CMDS
-       $(BAREBOX_BUILD_BAREBOXENV_CMDS)
-       $(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_MAKE_FLAGS) -C $(@D)
-       $(BAREBOX_BUILD_CUSTOM_ENV)
-endef
-
-define BAREBOX_INSTALL_IMAGES_CMDS
-       if test -h $(@D)/barebox-flash-image ; then \
-               cp -L $(@D)/barebox-flash-image $(BINARIES_DIR)/barebox.bin ; \
-       else \
-               cp $(@D)/barebox.bin $(BINARIES_DIR);\
-       fi
-       $(BAREBOX_INSTALL_CUSTOM_ENV)
-endef
-
-ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
-define BAREBOX_INSTALL_TARGET_CMDS
-       cp $(@D)/bareboxenv $(TARGET_DIR)/usr/bin
-endef
-endif
-
-# Checks to give errors that the user can understand
-# Must be before we call to kconfig-package
-ifeq ($(BR2_TARGET_BAREBOX)$(BR_BUILDING),yy)
-# We must use the user-supplied kconfig value, because
-# BAREBOX_KCONFIG_DEFCONFIG will at least contain the
-# trailing _defconfig
-ifeq ($(or $(BAREBOX_KCONFIG_FILE),$(call qstrip,$(BR2_TARGET_BAREBOX_BOARD_DEFCONFIG))),)
-$(error No Barebox config. Check your BR2_TARGET_BAREBOX_BOARD_DEFCONFIG or BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE settings)
-endif
-endif
 
-$(eval $(kconfig-package))
+include $(sort $(wildcard boot/barebox/*/*.mk))
--

2.5.0

No functional changes, but prepares barebox for building with two configurations (similar to package/gcc).

Signed-off-by Pieter Smith <[email protected]>

---
 boot/barebox/Config.in                | 71 +++++++++++++++++++-----------
 boot/barebox/barebox-1/barebox-1.hash |  1 +
 boot/barebox/barebox-1/barebox-1.mk   | 81 +++++++++++++++++++++++++++++++++++
 boot/barebox/barebox.mk               | 61 +-------------------------
 4 files changed, 129 insertions(+), 85 deletions(-)
 create mode 120000 boot/barebox/barebox-1/barebox-1.hash
 create mode 100644 boot/barebox/barebox-1/barebox-1.mk

boot/barebox/Config.in +0 -0

index 39cb5d2..ed120af 100644
@@ -64,9 +64,52 @@ config BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION
 
 endif
 

choice

boot/barebox/Config.in +2 -1

-	prompt "Barebox configuration"
+	prompt "Number of Barebox configurations"
+	default BR2_TARGET_BAREBOX_SINGLE_CONFIG

boot/barebox/Config.in +9 -0

+
+config BR2_TARGET_BAREBOX_1
+	bool "Barebox configuration 1"
+	default y
+
+if BR2_TARGET_BAREBOX_1
+
+choice
+	prompt "Type of configuration"
 	default BR2_TARGET_BAREBOX_USE_DEFCONFIG
 
 config BR2_TARGET_BAREBOX_USE_DEFCONFIG

boot/barebox/Config.in +0 -0

 	depends on BR2_TARGET_BAREBOX_USE_DEFCONFIG
 	help
 	  Name of the board for which Barebox should be built, without

@@ -97,28 +140,6 @@ config BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES
 	  A space-separated list of configuration fragment files,
 	  that will be merged to the main Barebox configuration file.
 

boot/barebox/barebox-1/barebox-1.mk new file +6 -0

new file mode 100644
index 0000000..3374ece
@@ -0,0 +1,81 @@
+################################################################################
+#
+# barebox-1
+#
+################################################################################
+

boot/barebox/barebox-1/barebox-1.mk new file +26 -0

+
+ifeq ($(BR2_TARGET_BAREBOX_USE_DEFCONFIG),y)
+BAREBOX_1_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_TARGET_BAREBOX_BOARD_DEFCONFIG))_defconfig
+else ifeq ($(BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG),y)
+BAREBOX_1_KCONFIG_FILE = $(call qstrip,$(BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE))
+endif
+
+BAREBOX_1_KCONFIG_FRAGMENT_FILES = $(BAREBOX_KCONFIG_FRAGMENT_FILES)
+BAREBOX_1_KCONFIG_EDITORS = $(BAREBOX_KCONFIG_EDITORS)
+BAREBOX_1_KCONFIG_OPTS = $(BAREBOX_MAKE_FLAGS)
+
+ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
+define BAREBOX_1_BUILD_BAREBOXENV_CMDS
+	$(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS) -o $(@D)/bareboxenv \
+		$(@D)/scripts/bareboxenv.c
+endef
+endif
+
+ifeq ($(BR2_TARGET_BAREBOX_CUSTOM_ENV),y)
+BAREBOX_1_ENV_NAME = $(notdir $(call qstrip,\
+	$(BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH)))
+define BAREBOX_1_BUILD_CUSTOM_ENV
+	$(@D)/scripts/bareboxenv -s \
+		$(call qstrip, $(BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH)) \
+		$(@D)/$(BAREBOX_1_ENV_NAME)
+endef

boot/barebox/barebox-1/barebox-1.mk new file +9 -0

+
+define BAREBOX_1_INSTALL_IMAGES_CMDS
+	if test -h $(@D)/barebox-flash-image ; then \
+		cp -L $(@D)/barebox-flash-image $(BINARIES_DIR)/barebox.bin ; \
+	else \
+		cp $(@D)/barebox.bin $(BINARIES_DIR);\
+	fi
+	$(BAREBOX_1_INSTALL_CUSTOM_ENV)
+endef

On 01/20/16 23:43, Pieter Smith wrote:

I wonder if it wouldn't be possible to keep barebox.mk unchanged, and just add
at the end (after the kconfig-package):

include boot/barebox/barebox-2/barebox-2.mk

That's not entirely similar to gcc, but it's more consistent with what it
means. You always have the barebox package, and you have an optional extra barebox-2 package which is a kind of submodule of barebox. Note however that we currently don't have this pattern at all, so it could be controversial. But I think it will simplify the patch a lot, and also simplify the logic.

So in that case, you'd have a first patch that adds the required refactorings
in barebox.mk so the same variables are useable for barebox-2, and a second patch that adds barebox-2 (and patches 3 and 4 stay the same of course).

This is complicated stuff, thanks for working on this, and sorry that it's
taking so long!

Regards,
Arnout

[snip]

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Quoted 1 line · Arnout Vandecappelle

On 01/20/16 23:43, Pieter Smith wrote:

[snip]

Quoted 11 lines

I wonder if it wouldn't be possible to keep barebox.mk unchanged, and just add
at the end (after the kconfig-package):

include boot/barebox/barebox-2/barebox-2.mk

That's not entirely similar to gcc, but it's more consistent with what it
means. You always have the barebox package, and you have an optional extra barebox-2 package which is a kind of submodule of barebox. Note however that we currently don't have this pattern at all, so it could be controversial. But I think it will simplify the patch a lot, and also simplify the logic.

Quoted 3 lines

So in that case, you'd have a first patch that adds the required refactorings
in barebox.mk so the same variables are useable for barebox-2, and a second patch that adds barebox-2 (and patches 3 and 4 stay the same of course).

Yes. Thanks. A lot less messy. I started looking into this. It seems doable. It might be neater to still split a barebox-common.mk to avoid a long list of variable copies. Give me a day on this.

Quoted 15 lines

This is complicated stuff, thanks for working on this, and sorry that it's
taking so long!

Regards,
Arnout

[snip]

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

- Pieter

Quoted 14 lines · Pieter Smith

Quoted 1 line · Arnout Vandecappelle

On 01/20/16 23:43, Pieter Smith wrote:

[snip]

Quoted 11 lines

I wonder if it wouldn't be possible to keep barebox.mk unchanged, and just add
at the end (after the kconfig-package):

include boot/barebox/barebox-2/barebox-2.mk

That's not entirely similar to gcc, but it's more consistent with what it
means. You always have the barebox package, and you have an optional extra barebox-2 package which is a kind of submodule of barebox. Note however that we currently don't have this pattern at all, so it could be controversial. But I think it will simplify the patch a lot, and also simplify the logic.

Quoted 7 lines

Quoted 3 lines

So in that case, you'd have a first patch that adds the required refactorings
in barebox.mk so the same variables are useable for barebox-2, and a second patch that adds barebox-2 (and patches 3 and 4 stay the same of course).

Yes. Thanks. A lot less messy. I started looking into this. It seems doable. It might be neater to still split a barebox-common.mk to avoid a long list of variable copies. Give me a day on this.

Thanks for the suggestion. It is shaping up nicely. There is one aspect that I would appreciate input on: To all but completely eliminate duplication in the makefiles for the two packages, I am wrapping all the current functionality in boot/barebox/barebox.mk in a parameterized barebox-package function. E.g.:

  define barebox-package
  $(1)_VERSION = $$(call qstrip,$$(BR2_TARGET_BAREBOX_VERSION))
  ...
  $$(eval $$(kconfig-package))
  endef
  $(eval $(call barebox-package,BAREBOX))

And the whole of boot/barebox/barebox-2/barebox-2.mk becomes:

  $(eval $(call barebox-package,BAREBOX_2))

This however cannot avoid Config.in duplication, but the barebox-2 makefile inherits all future barebox makefile improvements. The catch is that existing barebox patches will have merge conflicts.

I already tied up with Yegor on the embedded custom environment patch-set, which he is willing to rebase + solve the merge conflicts. We can then submit the series with Yegor's patch and a barebox defconfig for the Beaglebone Black as per your suggestion.

Do you think this is acceptable?

Quoted 16 lines

Quoted 15 lines

This is complicated stuff, thanks for working on this, and sorry that it's
taking so long!

Regards,
Arnout

[snip]

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Quoted 1 line

- Pieter

- Pieter

On 02/29/16 08:47, Pieter Smith wrote:

Quoted 13 lines

Thanks for the suggestion. It is shaping up nicely. There is one aspect that I would appreciate input on: To all but completely eliminate duplication in the makefiles for the two packages, I am wrapping all the current functionality in boot/barebox/barebox.mk in a parameterized barebox-package function. E.g.:

  define barebox-package
  $(1)_VERSION = $$(call qstrip,$$(BR2_TARGET_BAREBOX_VERSION))
  ...
  $$(eval $$(kconfig-package))
  endef
  $(eval $(call barebox-package,BAREBOX))

Quoted 3 lines

And the whole of boot/barebox/barebox-2/barebox-2.mk becomes:

  $(eval $(call barebox-package,BAREBOX_2))

No, I don't think we want this, because it hides a lot of what barebox-2 is
doing internally. It's OK and actually better (in my opinion) if barebox-2.mk is just a long list like:

BAREBOX_2_VERSION = $(BAREBOX_VERSION)
BAREBOX_2_SITE = $(BAREBOX_SITE)

BAREBOX_2_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)

...
$(eval $(kconfig-package))

Regards,
Arnout

Quoted 1 line · Arnout Vandecappelle

On 02/29/16 08:47, Pieter Smith wrote:

[snip]

Quoted 13 lines

Quoted 13 lines

Thanks for the suggestion. It is shaping up nicely. There is one aspect that I would appreciate input on: To all but completely eliminate duplication in the makefiles for the two packages, I am wrapping all the current functionality in boot/barebox/barebox.mk in a parameterized barebox-package function. E.g.:

  define barebox-package
  $(1)_VERSION = $$(call qstrip,$$(BR2_TARGET_BAREBOX_VERSION))
  ...
  $$(eval $$(kconfig-package))
  endef
  $(eval $(call barebox-package,BAREBOX))

Quoted 7 lines

Quoted 3 lines

And the whole of boot/barebox/barebox-2/barebox-2.mk becomes:

  $(eval $(call barebox-package,BAREBOX_2))

No, I don't think we want this, because it hides a lot of what barebox-2 is
doing internally. It's OK and actually better (in my opinion) if barebox-2.mk is just a long list like:

Pity. This quite elegantly solved my concerns. barebox and barebox-2 differ only in menuconfig and barebox environment configuration space. The rest should always be identical.

Quoted 2 lines

BAREBOX_2_VERSION = $(BAREBOX_VERSION)
BAREBOX_2_SITE = $(BAREBOX_SITE)

This shouldn't change much in future, so I can still do the variable copying if you prefer.

Quoted 1 line

BAREBOX_2_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)

This will not work. Both the BAREBOX_BUILD_CMDS and BAREBOX_INSTALL_IMAGES_CMDS need parameterization. I can solve this with with:
1. A scaled down version of the above barebox-package function to generate the boilerplate, or
2. Parameterizable functions and duplicated boilerplate.

IMHO reducing duplication always improves clarity and maintenance, so I would go for option 1.

What has your preference?

Quoted 7 lines

...
$(eval $(kconfig-package))

Regards,
Arnout

[snip]

I would like to:
1. Ensure that all improvements to barebox propagate to barebox-2 in future.
2. Avoid having something error-prone to resolve the above. IMHO using a review process to keep two pieces of code in sync is quite error-prone and an unnecessary cognitive burden on developers.

- Pieter

[Adding other core devs in CC, see the beginning and the end]

On 03/02/16 08:50, Pieter Smith wrote:

Quoted 8 lines

Quoted 1 line

BAREBOX_2_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)

This will not work. Both the BAREBOX_BUILD_CMDS and BAREBOX_INSTALL_IMAGES_CMDS need parameterization. I can solve this with with:
1. A scaled down version of the above barebox-package function to generate the boilerplate, or
2. Parameterizable functions and duplicated boilerplate.

Quoted 4 lines

IMHO reducing duplication always improves clarity and maintenance, so I would go for option 1.

What has your preference?

The BUILD_CMDS can be parameterized without using functions, by using
$($(PKG)_...) variables instead of $(BAREBOX_2_...). That's what I tried to show in my first reply:

define BAREBOX_BUILD_CMDS

	$($(PKG)_BUILD_BAREBOXENV_CMDS)
	$(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_MAKE_FLAGS) -C $(@D)
	$($(PKG)_BUILD_CUSTOM_ENV)

endef
BAREBOX_2_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)

BAREBOX_2_BUILD_BAREBOXENV_CMDS and BAREBOX_2_BUILD_CUSTOM_ENV will not be set, so those parts are removed. The rest should be identical for barebox-2, but if you do need something else you can add something like $($(PKG)_EXTRA_FLAGS).

Quoted 5 lines

I would like to:
1. Ensure that all improvements to barebox propagate to barebox-2 in future.
2. Avoid having something error-prone to resolve the above. IMHO using a review process to keep two pieces of code in sync is quite error-prone and an unnecessary cognitive burden on developers.

There isn't really much to keep in sync between the two, only when you suddenly
add _INSTALL_STAGING_CMDS for instance you'd have to update barebox-2.mk to copy that as well.

There are two reasons why I prefer the copying of variables:

1. I think that functions are a bit more difficult to understand.
2. I'm considering to add infrastructure that facilitates the pattern of copying variables, something like

$(eval $(call inherit-package,barebox))

which would expand to

BAREBOX_2_VERSION ?= BAREBOX_VERSION
BAREBOX_2_SITE ?= BAREBOX_SITE
...
BAREBOX_2_BUILD_CMDS ?= BAREBOX_BUILD_CMDS

so that in the end the barebox-2.mk does indeed become nothing more than a single eval line, and that the same approach can easily be used for other packages.

However, this is just my opinion, other developers may see it differently,
hence the CC.

On Wed, Mar 02, 2016 at 07:12:57PM +0100, Arnout Vandecappelle wrote:

Quoted 3 lines

The BUILD_CMDS can be parameterized without using functions, by using
$($(PKG)_...) variables instead of $(BAREBOX_2_...). That's what I tried to show in my first reply:

Off course, silly me... I've been making use of this since forever. It works because of the eval in $(eval $(kconfig-package)). I'll do it this way.

Quoted 10 lines

define BAREBOX_BUILD_CMDS

	$($(PKG)_BUILD_BAREBOXENV_CMDS)
	$(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_MAKE_FLAGS) -C $(@D)
	$($(PKG)_BUILD_CUSTOM_ENV)

endef
BAREBOX_2_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)

BAREBOX_2_BUILD_BAREBOXENV_CMDS and BAREBOX_2_BUILD_CUSTOM_ENV will not be set, so those parts are removed. The rest should be identical for barebox-2, but if you do need something else you can add something like $($(PKG)_EXTRA_FLAGS).

I agree with not needing the additional BAREBOX_2_BUILD_BAREBOXENV_CMDS and BAREBOX_2_INSTALL_BAREBOXENV_CMDS (why would you need to install bareboxenv to the rootfs twice), but I would like to keep the BAREBOX_2_BUILD_CUSTOM_ENV and the built-in variant in Yegor's pending patch-set. They allow customization of the barebox environment, and therefore the boot behavior.

Quoted 2 lines

However, this is just my opinion, other developers may see it differently,
hence the CC.

Off course. Your opinion is held in rather high regard, so I would like to have at least one of the regular barebox developers on board. ;-)

Quoted 1 line · Pieter Smith

On Wed, Mar 02, 2016 at 07:12:57PM +0100, Arnout Vandecappelle wrote:

[snip]

Quoted 18 lines

Quoted 3 lines

The BUILD_CMDS can be parameterized without using functions, by using
$($(PKG)_...) variables instead of $(BAREBOX_2_...). That's what I tried to show in my first reply:

Off course, silly me... I've been making use of this since forever. It works because of the eval in $(eval $(kconfig-package)). I'll do it this way.

Quoted 10 lines

define BAREBOX_BUILD_CMDS

	$($(PKG)_BUILD_BAREBOXENV_CMDS)
	$(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_MAKE_FLAGS) -C $(@D)
	$($(PKG)_BUILD_CUSTOM_ENV)

endef
BAREBOX_2_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)

BAREBOX_2_BUILD_BAREBOXENV_CMDS and BAREBOX_2_BUILD_CUSTOM_ENV will not be set, so those parts are removed. The rest should be identical for barebox-2, but if you do need something else you can add something like $($(PKG)_EXTRA_FLAGS).

Quoted 5 lines

I agree with not needing the additional BAREBOX_2_BUILD_BAREBOXENV_CMDS and BAREBOX_2_INSTALL_BAREBOXENV_CMDS (why would you need to install bareboxenv to the rootfs twice), but I would like to keep the BAREBOX_2_BUILD_CUSTOM_ENV and the built-in variant in Yegor's pending patch-set. They allow customization of the barebox environment, and therefore the boot behavior.

I am having some trouble with this. I am not able to handle ifdef-space diversity in this way. Ifdef-space diversity is used to determine how barebox should be configured, whether / how the barebox environment should be built, and to print user-friendly config errors. The ifdef logic is not all trivial (almost half of the makefile logic), so I would like to avoid duplicating it between barebox and barebox-2. The only way I know of to avoid this duplication is by extracting the logic info a definition and using $(eval), which is exactly what you want to avoid.

Also, for two of the ifdef-space diversity sections, $(PKG) seems to be undefined at the time of evaluation. Getting to the bottom of this is proving quite taxing. I can get around this by doing an $(eval $(call ...,BAREBOX)), which looks a lot like my initial suggestion.

I am getting to the point where I am just going to duplicate the ifdef sections and leave the consistency burden with future reviewers. I understand your concern that some developers do not understanding $(eval) all that well, but this is like trying to solve the problem with my shoelaces tied.

[snip]

Quoted 5 lines

Quoted 2 lines

However, this is just my opinion, other developers may see it differently,
hence the CC.

Off course. Your opinion is held in rather high regard, so I would like to have at least one of the regular barebox developers on board. ;-)

Is there anyone else we can prod to weigh in on this? Please have a look at the templated proposal and confirm your opinion on $(eval):
https://github.com/smipi1/bbb_buildroot/tree/barebox_2nd_config_build-v4-templated.

[snip]

- Pieter

On 03/05/16 14:16, Pieter Smith wrote:

Quoted 8 lines

I am having some trouble with this. I am not able to handle ifdef-space diversity in this way. Ifdef-space diversity is used to determine how barebox should be configured, whether / how the barebox environment should be built, and to print user-friendly config errors. The ifdef logic is not all trivial (almost half of the makefile logic), so I would like to avoid duplicating it between barebox and barebox-2. The only way I know of to avoid this duplication is by extracting the logic info a definition and using $(eval), which is exactly what you want to avoid.

Ah yes, I didn't realize that. Indeed, for those things there is no way to
handle them with $(PKG).

Actually I would like those things to move to kconfig-package, but that would
be dragging things a bit too far for this series.

So yes, your idea of $(call barebox-package) looks good. One small remark that
you can already fix before submitting: in the patch that adds the barebox-package function, say explicitly in the commit message if anything has changed except for $ -> $$ and BAREBOX -> $(1). That'll make review easier.

Quoted 21 lines · Pieter Smith

No functional changes, but prepares barebox for building with two configurations (similar to package/gcc).

Signed-off-by Pieter Smith <[email protected]>

---
 boot/barebox/Config.in                | 71 +++++++++++++++++++-----------
 boot/barebox/barebox-1/barebox-1.hash |  1 +
 boot/barebox/barebox-1/barebox-1.mk   | 81 +++++++++++++++++++++++++++++++++++
 boot/barebox/barebox.mk               | 61 +-------------------------
 4 files changed, 129 insertions(+), 85 deletions(-)
 create mode 120000 boot/barebox/barebox-1/barebox-1.hash
 create mode 100644 boot/barebox/barebox-1/barebox-1.mk

boot/barebox/Config.in +0 -0

index 39cb5d2..ed120af 100644
@@ -64,9 +64,52 @@ config BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION
 
 endif
 

[snip]

Quoted 11 lines

choice

boot/barebox/Config.in +8 -1

-	prompt "Barebox configuration"
+	prompt "Number of Barebox configurations"
+	default BR2_TARGET_BAREBOX_SINGLE_CONFIG
+
+config BR2_TARGET_BAREBOX_ONE_CONFIG
+	select BR2_TARGET_BAREBOX_1
+	bool "Build 1 config"
+	help
+	  Build only one barebox config.

boot/barebox/Config.in config BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION · line 103

Quoted 4 lines

boot/barebox/Config.in +4 -0

+	  Useful for building the traditional TPL (Tertiary Program
+	  Loader).
+
+endchoice

There is no need for this choice. You always need barebox-1 anyway. So you can
actually keep the Config.in as it is, and add the second barebox configuration at the end.

Quoted 15 lines

boot/barebox/Config.in +9 -0

+
+config BR2_TARGET_BAREBOX_1
+	bool "Barebox configuration 1"
+	default y
+
+if BR2_TARGET_BAREBOX_1
+
+choice
+	prompt "Type of configuration"
 	default BR2_TARGET_BAREBOX_USE_DEFCONFIG
 
 config BR2_TARGET_BAREBOX_USE_DEFCONFIG

@@ -78,7 +121,7 @@ config BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG
 endchoice
 

boot/barebox/Config.in config BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG · line 124

Quoted 3 lines

boot/barebox/Config.in +1 -1

 config BR2_TARGET_BAREBOX_BOARD_DEFCONFIG
-	string "board defconfig"
+	string "Board defconfig"

Why change the capitalisation? Should be a separate patch.

Quoted 7 lines

boot/barebox/Config.in +0 -0

 	depends on BR2_TARGET_BAREBOX_USE_DEFCONFIG
 	help
 	  Name of the board for which Barebox should be built, without

@@ -97,28 +140,6 @@ config BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES
 	  A space-separated list of configuration fragment files,
 	  that will be merged to the main Barebox configuration file.
 

[snip]

Quoted 12 lines

boot/barebox/barebox-1/barebox-1.mk new file +6 -0

new file mode 100644
index 0000000..3374ece
@@ -0,0 +1,81 @@
+################################################################################
+#
+# barebox-1
+#
+################################################################################
+

boot/barebox/barebox-1/barebox-1.mk line 16

Quoted 10 lines

boot/barebox/barebox-1/barebox-1.mk new file +10 -0

+BAREBOX_1_VERSION = $(BAREBOX_VERSION)
+BAREBOX_1_SITE = $(BAREBOX_SITE)
+BAREBOX_1_SITE_METHOD = $(BAREBOX_SITE_METHOD)
+BAREBOX_1_SOURCE = $(BAREBOX_SOURCE)
+BAREBOX_1_DEPENDENCIES = $(BAREBOX_DEPENDENCIES)
+BAREBOX_1_LICENSE = $(BAREBOX_LICENSE)
+BAREBOX_1_LICENSE_FILES = $(BAREBOX_LICENSE_FILES)
+BAREBOX_1_POST_PATCH_HOOKS += $(BAREBOX_POST_PATCH_HOOKS)
+BAREBOX_1_MAKE_FLAGS = $(BAREBOX_MAKE_FLAGS)
+BAREBOX_1_MAKE_ENV = $(BAREBOX_MAKE_ENV)

MAKE_FLAGS and MAKE_ENV are only used in the commands below, so no need to
define a barebox-1 version.

boot/barebox/barebox-1/barebox-1.mk line 17

Quoted 1 line

boot/barebox/barebox-1/barebox-1.mk new file +1 -0

+BAREBOX_1_INSTALL_IMAGES = $(BAREBOX_INSTALL_IMAGES)

This is just YES, it's a bit silly to add an extra variable for that.

BAREBOX_1_BUILD_CMDS and BAREBOX_2_BUILD_CMDS are very similar. You can
refactor them as follows (I think):

define BAREBOX_BUILD_CMDS

	$($(PKG)_BUILD_BAREBOXENV_CMDS)
	$(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_MAKE_FLAGS) -C $(@D)
	$($(PKG)_BUILD_CUSTOM_ENV)

endef
BAREBOX_1_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)
BAREBOX_2_BUILD_CMDS = $(BAREBOX_BUILD_CMDS)

Since BAREBOX_2_BUILD_BAREBOXENV_CMDS isn't defined, that line will just
disappear, leaving just the make command for barebox-2.

Same for the others below.

Note that introducing the $(PKG) bits should be a separate patch, not together
with the move to barebox-1.

Quoted 14 lines

boot/barebox/barebox-1/barebox-1.mk new file +13 -0

+
+define BAREBOX_1_INSTALL_IMAGES_CMDS
+	if test -h $(@D)/barebox-flash-image ; then \
+		cp -L $(@D)/barebox-flash-image $(BINARIES_DIR)/barebox.bin ; \
+	else \
+		cp $(@D)/barebox.bin $(BINARIES_DIR);\
+	fi
+	$(BAREBOX_1_INSTALL_CUSTOM_ENV)
+endef
+
+ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
+define BAREBOX_1_INSTALL_TARGET_CMDS
+	cp $(@D)/bareboxenv $(TARGET_DIR)/usr/bin

boot/barebox/barebox-1/barebox-1.mk line 72

Quoted 6 lines

boot/barebox/barebox-1/barebox-1.mk new file +6 -0

+endef
+endif
+
+# Checks to give errors that the user can understand
+# Must be before we call to kconfig-package
+ifeq ($(BR2_TARGET_BAREBOX_2)$(BR_BUILDING),yy)

BAREBOX_1 here.

I wonder if it wouldn't be possible to keep barebox.mk unchanged, and just add
at the end (after the kconfig-package):

include boot/barebox/barebox-2/barebox-2.mk

That's not entirely similar to gcc, but it's more consistent with what it
means. You always have the barebox package, and you have an optional extra barebox-2 package which is a kind of submodule of barebox. Note however that we currently don't have this pattern at all, so it could be controversial. But I think it will simplify the patch a lot, and also simplify the logic.

So in that case, you'd have a first patch that adds the required refactorings
in barebox.mk so the same variables are useable for barebox-2, and a second patch that adds barebox-2 (and patches 3 and 4 stay the same of course).

This is complicated stuff, thanks for working on this, and sorry that it's
taking so long!

Regards,
Arnout

[snip]

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Support selection of secondary config, but version, source URL and patches are shared with barebox bootloader build.

Signed-off-by Pieter Smith <[email protected]>

---
 boot/barebox/Config.in                | 60 ++++++++++++++++++++++++++++++++++-
 boot/barebox/barebox-2/barebox-2.hash |  1 +
 boot/barebox/barebox-2/barebox-2.mk   | 54 +++++++++++++++++++++++++++++++
 3 files changed, 114 insertions(+), 1 deletion(-)
 create mode 120000 boot/barebox/barebox-2/barebox-2.hash
 create mode 100644 boot/barebox/barebox-2/barebox-2.mk

boot/barebox/Config.in +59 -1

index ed120af..f848afe 100644
@@ -100,11 +100,20 @@ config BR2_TARGET_BAREBOX_ONE_CONFIG
          Useful for building the traditional TPL (Tertiary Program
          Loader).
 
+config BR2_TARGET_BAREBOX_TWO_CONFIGS
+       select BR2_TARGET_BAREBOX_1
+       select BR2_TARGET_BAREBOX_2
+       bool "Build 2 configs"
+       help
+         Build two barebox configurations.
+         Useful for building an SPL (Secondary Program Loader) in addition to
+         the traditional TPL (Tertiary Program Loader), such as the X-Loader
+         or MLO for Texas Instruments processors.
+
 endchoice
 
 config BR2_TARGET_BAREBOX_1
        bool "Barebox configuration 1"
-       default y
 
 if BR2_TARGET_BAREBOX_1
 

@@ -142,4 +151,53 @@ config BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES
 
 endif
 
+if BR2_TARGET_BAREBOX_TWO_CONFIGS
+
+config BR2_TARGET_BAREBOX_2
+       bool "Barebox configuration 2"
+
+if BR2_TARGET_BAREBOX_2
+
+choice
+       prompt "Type of configuration"
+       default BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+
+config BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+       bool "Using a defconfig"
+
+config BR2_TARGET_BAREBOX_2_USE_CUSTOM_CONFIG
+       bool "Using a custom config file"
+
+endchoice
+
+config BR2_TARGET_BAREBOX_2_BOARD_DEFCONFIG
+       string "Board defconfig"
+       depends on BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+       help
+         Name of the board for which Barebox should be built, without
+         the _defconfig suffix.
+
+
+config BR2_TARGET_BAREBOX_2_CUSTOM_CONFIG_FILE
+       string "Configuration file path"
+       depends on BR2_TARGET_BAREBOX_2_USE_CUSTOM_CONFIG
+       help
+         Path to the barebox configuration file
+
+config BR2_TARGET_BAREBOX_2_CONFIG_FRAGMENT_FILES
+       string "Additional configuration fragment files"
+       help
+         A space-separated list of configuration fragment files,
+         that will be merged to the main Barebox configuration file.
+
+config BR2_TARGET_BAREBOX_2_INSTALL_FILENAME
+       string "Destination image filename in output/images"
+       default "MLO"
+       help
+         Name to give the image in the output/images directory.
+
+endif
+
+endif
+
 endif

boot/barebox/barebox-2/barebox-2.hash new file +1 -0

new file mode 120000
index 0000000..b6462b8
@@ -0,0 +1 @@
+../barebox.hash
\ No newline at end of file

boot/barebox/barebox-2/barebox-2.mk new file +54 -1

new file mode 100644
index 0000000..a735f67
@@ -0,0 +1,54 @@
+################################################################################
+#
+# barebox-2
+#
+################################################################################
+
+BAREBOX_2_VERSION = $(BAREBOX_VERSION)
+BAREBOX_2_SITE = $(BAREBOX_SITE)
+BAREBOX_2_SITE_METHOD = $(BAREBOX_SITE_METHOD)
+BAREBOX_2_SOURCE = $(BAREBOX_SOURCE)
+BAREBOX_2_DEPENDENCIES = $(BAREBOX_DEPENDENCIES)
+BAREBOX_2_LICENSE = $(BAREBOX_LICENSE)
+BAREBOX_2_LICENSE_FILES = $(BAREBOX_LICENSE_FILES)
+BAREBOX_2_POST_PATCH_HOOKS += $(BAREBOX_POST_PATCH_HOOKS)
+BAREBOX_2_MAKE_FLAGS = $(BAREBOX_MAKE_FLAGS)
+BAREBOX_2_MAKE_ENV = $(BAREBOX_MAKE_ENV)
+BAREBOX_2_INSTALL_IMAGES = $(BAREBOX_INSTALL_IMAGES)
+BAREBOX_2_INSTALL_DEST = $(BINARIES_DIR)/$(call qstrip,$(BR2_TARGET_BAREBOX_2_INSTALL_FILENAME))
+
+ifeq ($(BR2_TARGET_BAREBOX_2_USE_DEFCONFIG),y)
+BAREBOX_2_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_TARGET_BAREBOX_2_BOARD_DEFCONFIG))_defconfig
+else ifeq ($(BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG),y)
+BAREBOX_2_KCONFIG_FILE = $(call qstrip,$(BR2_TARGET_BAREBOX_2_CUSTOM_CONFIG_FILE))
+endif
+
+BAREBOX_2_KCONFIG_FRAGMENT_FILES = $(BAREBOX_KCONFIG_FRAGMENT_FILES)
+BAREBOX_2_KCONFIG_EDITORS = $(BAREBOX_KCONFIG_EDITORS)
+BAREBOX_2_KCONFIG_OPTS = $(BAREBOX_MAKE_FLAGS)
+
+define BAREBOX_2_BUILD_CMDS
+       $(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_2_MAKE_FLAGS) -C $(@D)
+endef
+
+define BAREBOX_2_INSTALL_IMAGES_CMDS
+       if test -h $(@D)/barebox-flash-image ; then \
+               cp -L $(@D)/barebox-flash-image $(BAREBOX_2_INSTALL_DEST) ; \
+       else \
+               cp $(@D)/barebox.bin $(BAREBOX_2_INSTALL_DEST);\
+       fi
+endef
+
+
+# Checks to give errors that the user can understand
+# Must be before we call to kconfig-package
+ifeq ($(BR2_TARGET_BAREBOX_2)$(BR_BUILDING),yy)
+# We must use the user-supplied kconfig value, because
+# BAREBOX_2_KCONFIG_DEFCONFIG will at least contain the
+# trailing _defconfig
+ifeq ($(or $(BAREBOX_2_KCONFIG_FILE),$(call qstrip,$(BR2_TARGET_BAREBOX_2_BOARD_DEFCONFIG))),)
+$(error No Barebox config. Check your BR2_TARGET_BAREBOX_2_BOARD_DEFCONFIG or BR2_TARGET_BAREBOX_2_CUSTOM_CONFIG_FILE settings)
+endif
+endif
+
+$(eval $(kconfig-package))
--

2.5.0

Support selection of secondary config, but version, source URL and patches are shared with barebox bootloader build.

Signed-off-by Pieter Smith <[email protected]>

---
 boot/barebox/Config.in                | 60 ++++++++++++++++++++++++++++++++++-
 boot/barebox/barebox-2/barebox-2.hash |  1 +
 boot/barebox/barebox-2/barebox-2.mk   | 54 +++++++++++++++++++++++++++++++
 3 files changed, 114 insertions(+), 1 deletion(-)
 create mode 120000 boot/barebox/barebox-2/barebox-2.hash
 create mode 100644 boot/barebox/barebox-2/barebox-2.mk

boot/barebox/Config.in +10 -1

index ed120af..f848afe 100644
@@ -100,11 +100,20 @@ config BR2_TARGET_BAREBOX_ONE_CONFIG
 	  Useful for building the traditional TPL (Tertiary Program
 	  Loader).
 
+config BR2_TARGET_BAREBOX_TWO_CONFIGS
+	select BR2_TARGET_BAREBOX_1
+	select BR2_TARGET_BAREBOX_2
+	bool "Build 2 configs"
+	help
+	  Build two barebox configurations.
+	  Useful for building an SPL (Secondary Program Loader) in addition to
+	  the traditional TPL (Tertiary Program Loader), such as the X-Loader
+	  or MLO for Texas Instruments processors.
+
 endchoice
 
 config BR2_TARGET_BAREBOX_1
 	bool "Barebox configuration 1"
-	default y
 
 if BR2_TARGET_BAREBOX_1
 

boot/barebox/Config.in +13 -0

+
+if BR2_TARGET_BAREBOX_2
+
+choice
+	prompt "Type of configuration"
+	default BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+
+config BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+	bool "Using a defconfig"
+
+config BR2_TARGET_BAREBOX_2_USE_CUSTOM_CONFIG
+	bool "Using a custom config file"
+

boot/barebox/Config.in +22 -0

+config BR2_TARGET_BAREBOX_2_CUSTOM_CONFIG_FILE
+	string "Configuration file path"
+	depends on BR2_TARGET_BAREBOX_2_USE_CUSTOM_CONFIG
+	help
+	  Path to the barebox configuration file
+
+config BR2_TARGET_BAREBOX_2_CONFIG_FRAGMENT_FILES
+	string "Additional configuration fragment files"
+	help
+	  A space-separated list of configuration fragment files,
+	  that will be merged to the main Barebox configuration file.
+
+config BR2_TARGET_BAREBOX_2_INSTALL_FILENAME
+	string "Destination image filename in output/images"
+	default "MLO"
+	help
+	  Name to give the image in the output/images directory.
+
+endif
+
+endif
+
 endif

Quoted 2 lines · Pieter Smith

Support selection of secondary config, but version, source URL and patches are shared with barebox bootloader build.

So, if you remove the choice, then this config should stay and be called
something like "build second Barebox configuration", with the help text from BR2_TARGET_BAREBOX_TWO_CONFIGS.

And if the option of keeping barebox and just adding barebox-2 works out, then
this can also go into a separate Config.in file in the barebox-2 directory, which is source'd from here.

Also, it should be a menuconfig instead, since there are 5 entries.

Quoted 17 lines

boot/barebox/Config.in +17 -0

+
+if BR2_TARGET_BAREBOX_2
+
+choice
+	prompt "Type of configuration"
+	default BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+
+config BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+	bool "Using a defconfig"
+
+config BR2_TARGET_BAREBOX_2_USE_CUSTOM_CONFIG
+	bool "Using a custom config file"
+
+endchoice
+
+config BR2_TARGET_BAREBOX_2_BOARD_DEFCONFIG
+	string "Board defconfig"

boot/barebox/Config.in config BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES · line 180

Quoted 6 lines

boot/barebox/Config.in +6 -0

+	depends on BR2_TARGET_BAREBOX_2_USE_DEFCONFIG
+	help
+	  Name of the board for which Barebox should be built, without
+	  the _defconfig suffix.
+
+

Spurious line here.

Regards,
Arnout

A non-default image can be selected as the barebox build output in the images/ directory. This typically is needed to select the appropriate image generated by multi-platform support defconfigs (E.g. am335x).

Signed-off-by Pieter Smith <[email protected]>

---
 boot/barebox/Config.in              | 36 ++++++++++++++++++++++++++++++++++++
 boot/barebox/barebox-1/barebox-1.mk | 13 +++++++++++--
 boot/barebox/barebox-2/barebox-2.mk |  7 +++++++
 3 files changed, 54 insertions(+), 2 deletions(-)

boot/barebox/Config.in +36 -0

index f848afe..fe76f8a 100644
@@ -149,6 +149,24 @@ config BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES
          A space-separated list of configuration fragment files,
          that will be merged to the main Barebox configuration file.
 
+choice
+       prompt "Barebox image file"
+       default BR2_TARGET_BAREBOX_USE_DEFAULT_IMAGE
+
+config BR2_TARGET_BAREBOX_USE_DEFAULT_IMAGE
+       bool "Using the default image file"
+
+config BR2_TARGET_BAREBOX_USE_SPECIFIC_IMAGE
+       bool "Using a specific image file"
+
+endchoice
+
+config BR2_TARGET_BAREBOX_IMAGE_FILE
+       string "Image file path"
+       depends on BR2_TARGET_BAREBOX_USE_SPECIFIC_IMAGE
+       help
+         Name of the built barebox image file in the barebox images directory
+
 endif
 
 if BR2_TARGET_BAREBOX_TWO_CONFIGS

@@ -190,6 +208,24 @@ config BR2_TARGET_BAREBOX_2_CONFIG_FRAGMENT_FILES
          A space-separated list of configuration fragment files,
          that will be merged to the main Barebox configuration file.
 
+choice
+       prompt "Barebox image file"
+       default BR2_TARGET_BAREBOX_2_USE_DEFAULT_IMAGE
+
+config BR2_TARGET_BAREBOX_2_USE_DEFAULT_IMAGE
+       bool "Using the default image file"
+
+config BR2_TARGET_BAREBOX_2_USE_SPECIFIC_IMAGE
+       bool "Using a specific image file"
+
+endchoice
+
+config BR2_TARGET_BAREBOX_2_IMAGE_FILE
+       string "Image file path"
+       depends on BR2_TARGET_BAREBOX_2_USE_SPECIFIC_IMAGE
+       help
+         Name of the built barebox image file in the barebox images directory
+
 config BR2_TARGET_BAREBOX_2_INSTALL_FILENAME
        string "Destination image filename in output/images"
        default "MLO"

boot/barebox/barebox-1/barebox-1.mk +11 -2

index 3374ece..8441842 100644
@@ -15,6 +15,7 @@ BAREBOX_1_POST_PATCH_HOOKS += $(BAREBOX_POST_PATCH_HOOKS)
 BAREBOX_1_MAKE_FLAGS = $(BAREBOX_MAKE_FLAGS)
 BAREBOX_1_MAKE_ENV = $(BAREBOX_MAKE_ENV)
 BAREBOX_1_INSTALL_IMAGES = $(BAREBOX_INSTALL_IMAGES)
+BAREBOX_1_INSTALL_DEST = $(BINARIES_DIR)/barebox.bin
 
 ifeq ($(BR2_TARGET_BAREBOX_USE_DEFCONFIG),y)
 BAREBOX_1_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_TARGET_BAREBOX_BOARD_DEFCONFIG))_defconfig

@@ -52,14 +53,22 @@ define BAREBOX_1_BUILD_CMDS
        $(BAREBOX_1_BUILD_CUSTOM_ENV)
 endef
 
+ifdef BR2_TARGET_BAREBOX_USE_SPECIFIC_IMAGE
+define BAREBOX_1_INSTALL_IMAGES_CMDS
+       cp -L $(@D)/images/$(call qstrip,$(BR2_TARGET_BAREBOX_IMAGE_FILE)) \
+               $(BAREBOX_1_INSTALL_DEST)
+       $(BAREBOX_1_INSTALL_CUSTOM_ENV)
+endef
+else
 define BAREBOX_1_INSTALL_IMAGES_CMDS
        if test -h $(@D)/barebox-flash-image ; then \
-               cp -L $(@D)/barebox-flash-image $(BINARIES_DIR)/barebox.bin ; \
+               cp -L $(@D)/barebox-flash-image $(BAREBOX_1_INSTALL_DEST) ; \
        else \
-               cp $(@D)/barebox.bin $(BINARIES_DIR);\
+               cp $(@D)/barebox.bin $(BAREBOX_1_INSTALL_DEST);\
        fi
        $(BAREBOX_1_INSTALL_CUSTOM_ENV)
 endef
+endif
 
 ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y)
 define BAREBOX_1_INSTALL_TARGET_CMDS

boot/barebox/barebox-2/barebox-2.mk +7 -1

index a735f67..71e0266 100644
@@ -31,6 +31,12 @@ define BAREBOX_2_BUILD_CMDS
        $(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_2_MAKE_FLAGS) -C $(@D)
 endef
 
+ifdef BR2_TARGET_BAREBOX_2_USE_SPECIFIC_IMAGE
+define BAREBOX_2_INSTALL_IMAGES_CMDS
+       cp -L $(@D)/images/$(call qstrip,$(BR2_TARGET_BAREBOX_2_IMAGE_FILE)) \
+               $(BAREBOX_2_INSTALL_DEST)
+endef
+else
 define BAREBOX_2_INSTALL_IMAGES_CMDS
        if test -h $(@D)/barebox-flash-image ; then \
                cp -L $(@D)/barebox-flash-image $(BAREBOX_2_INSTALL_DEST) ; \

@@ -38,6 +44,7 @@ define BAREBOX_2_INSTALL_IMAGES_CMDS
                cp $(@D)/barebox.bin $(BAREBOX_2_INSTALL_DEST);\
        fi
 endef
+endif
 
 
 # Checks to give errors that the user can understand
--

2.5.0

A non-default image can be selected as the barebox build output in the images/ directory. This typically is needed to select the appropriate image generated by multi-platform support defconfigs (E.g. am335x).

Signed-off-by Pieter Smith <[email protected]>

---
 boot/barebox/Config.in              | 36 ++++++++++++++++++++++++++++++++++++
 boot/barebox/barebox-1/barebox-1.mk | 13 +++++++++++--
 boot/barebox/barebox-2/barebox-2.mk |  7 +++++++
 3 files changed, 54 insertions(+), 2 deletions(-)

boot/barebox/Config.in +9 -0

index f848afe..fe76f8a 100644
@@ -149,6 +149,24 @@ config BR2_TARGET_BAREBOX_CONFIG_FRAGMENT_FILES
 	  A space-separated list of configuration fragment files,
 	  that will be merged to the main Barebox configuration file.
 
+choice
+	prompt "Barebox image file"
+	default BR2_TARGET_BAREBOX_USE_DEFAULT_IMAGE
+
+config BR2_TARGET_BAREBOX_USE_DEFAULT_IMAGE
+	bool "Using the default image file"
+
+config BR2_TARGET_BAREBOX_USE_SPECIFIC_IMAGE
+	bool "Using a specific image file"

Quoted 3 lines · Pieter Smith

A non-default image can be selected as the barebox build output in the images/ directory. This typically is needed to select the appropriate image generated by multi-platform support defconfigs (E.g. am335x).

If we deprecate barebox pre-2012.10, then we can simplify this a lot:

config BR2_TARGET_BAREBOX_IMAGE_FILE
string "Image file path"
default "barebox-flash-image"
help
Name of the built barebox image file in the barebox images directory

Even if we don't want to deprecate barebox pre-2012.10, I'd prefer to keep this
simple config and do the handling of legacy barebox.bin in the .mk file. For pre-2012.10, you'd have to explicitly set it to barebox.bin instead (which should be mentioned in the help text then).

We should find a good way to deal with the images/ part of the path, however.
This could e.g. be done in the .mk file, by checking both the top dir and the images dir.

Regards,
Arnout

Quoted 4 lines · Arnout Vandecappelle

Quoted 3 lines · Pieter Smith

A non-default image can be selected as the barebox build output in the images/ directory. This typically is needed to select the appropriate image generated by multi-platform support defconfigs (E.g. am335x).

[snip]

Quoted 9 lines

If we deprecate barebox pre-2012.10, then we can simplify this a lot:

config BR2_TARGET_BAREBOX_IMAGE_FILE
string "Image file path"
default "barebox-flash-image"
help
Name of the built barebox image file in the barebox images directory

Quoted 4 lines

Even if we don't want to deprecate barebox pre-2012.10, I'd prefer to keep this
simple config and do the handling of legacy barebox.bin in the .mk file. For pre-2012.10, you'd have to explicitly set it to barebox.bin instead (which should be mentioned in the help text then).

ACK. Done. I solved this with the above default and help text pointing the user to use 'barebox.bin' for older versions. I'm just waiting for Yegor, and then I'll repost.

Right now a user-friendly warning is generated if an old config is used and this config item has not yet been set.

I can have the makefile also generate a
hint for older barebox versions if the image filename isn't found:
- Do you think the additional complexity is warranted?

Quoted 4 lines

We should find a good way to deal with the images/ part of the path, however.
This could e.g. be done in the .mk file, by checking both the top dir and the images dir.

ACK. Done. In v4 I first try the build ./ directory, and then ./images.

Quoted 2 lines

Regards,
Arnout

[snip]

- Pieter

On 02/29/16 09:38, Pieter Smith wrote:

Quoted 7 lines

ACK. Done. I solved this with the above default and help text pointing the user to use 'barebox.bin' for older versions. I'm just waiting for Yegor, and then I'll repost.

Right now a user-friendly warning is generated if an old config is used and this config item has not yet been set.

If you give it a default value, it _will_ be set for old configs.

Quoted 3 lines

I can have the makefile also generate a
hint for older barebox versions if the image filename isn't found:
- Do you think the additional complexity is warranted?

Yes, that's worth it.

Regards,
Arnout

Quoted 1 line · Arnout Vandecappelle

On 02/29/16 09:38, Pieter Smith wrote:

[snip]

Quoted 5 lines

Quoted 5 lines

ACK. Done. I solved this with the above default and help text pointing the user to use 'barebox.bin' for older versions. I'm just waiting for Yegor, and then I'll repost.

Quoted 4 lines

Quoted 2 lines

Right now a user-friendly warning is generated if an old config is used and this config item has not yet been set.

If you give it a default value, it _will_ be set for old configs.

If the user remembers to run defconfig. If he doesn't, the error is quite vague.

Quoted 6 lines

Quoted 4 lines

I can have the makefile also generate a
hint for older barebox versions if the image filename isn't found:
- Do you think the additional complexity is warranted?

Yes, that's worth it.

ACK. Will do.

Quoted 2 lines

Regards,
Arnout

[snip]

- Pieter

Quoted 13 lines · Pieter Smith

Quoted 1 line · Arnout Vandecappelle

On 02/29/16 09:38, Pieter Smith wrote:

[snip]

Quoted 8 lines

Quoted 7 lines

ACK. Done. I solved this with the above default and help text pointing the user to use 'barebox.bin' for older versions. I'm just waiting for Yegor, and then I'll repost.

Right now a user-friendly warning is generated if an old config is used and this config item has not yet been set.

Quoted 3 lines

Quoted 1 line

If you give it a default value, it _will_ be set for old configs.

If the user remembers to run defconfig. If he doesn't, the error is quite vague.

When you update buildroot and run 'make', there should be an implicit run of
'make oldconfig', which will update all the automatic symbols and ask for any new ones. TBH I don't completely understand how it works, but it happens like that for me.

Quoted 14 lines · Arnout Vandecappelle

Quoted 13 lines · Pieter Smith

Quoted 1 line · Arnout Vandecappelle

On 02/29/16 09:38, Pieter Smith wrote:

[snip]

Quoted 8 lines

Quoted 7 lines

ACK. Done. I solved this with the above default and help text pointing the user to use 'barebox.bin' for older versions. I'm just waiting for Yegor, and then I'll repost.

Right now a user-friendly warning is generated if an old config is used and this config item has not yet been set.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

If you give it a default value, it _will_ be set for old configs.

If the user remembers to run defconfig. If he doesn't, the error is quite vague.

When you update buildroot and run 'make', there should be an implicit run of
'make oldconfig', which will update all the automatic symbols and ask for any new ones. TBH I don't completely understand how it works, but it happens like that for me.

I was troubleshooting with make barebox-2, which doesn't perform an auto-defconfig. The error was unintelligible because some variables were resolving to empty strings. I therefore added a check which offers a similar prompt to what is currently done at the end of barebox.mk.

If nobody has a serious gripe with this, I would prefer to keep the check.

[snip]

- Pieter

* Builds barebox MLO and the barebox bootloader.
* Barebox integrates a perfectly good device-tree for the bbb, so no dtb is being generated with the kernel.

Signed-off-by Pieter Smith <[email protected]>

---
 configs/beaglebone_barebox_defconfig | 39 ++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 configs/beaglebone_barebox_defconfig

configs/beaglebone_barebox_defconfig new file +39 -1

new file mode 100644
index 0000000..b4fd67b
@@ -0,0 +1,39 @@
+# architecture
+BR2_arm=y
+BR2_cortex_a8=y
+BR2_ARM_EABIHF=y
+
+# system
+BR2_TARGET_GENERIC_HOSTNAME="beaglebone"
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyO0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/beaglebone/post-image.sh"
+
+# filesystem
+BR2_PACKAGE_AM33X_CM3=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
+
+# lock down headers to avoid breaking with new defaults
+BR2_KERNEL_HEADERS_VERSION=y
+BR2_DEFAULT_KERNEL_VERSION="3.12.10"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y
+
+# bootloader
+BR2_TARGET_BAREBOX_TWO_CONFIGS=y
+BR2_TARGET_BAREBOX=y
+BR2_TARGET_BAREBOX_BOARD_DEFCONFIG="am335x"
+BR2_TARGET_BAREBOX_USE_SPECIFIC_IMAGE=y
+BR2_TARGET_BAREBOX_IMAGE_FILE="barebox-am33xx-beaglebone.img"
+BR2_TARGET_BAREBOX_2=y
+BR2_TARGET_BAREBOX_2_BOARD_DEFCONFIG="am335x_mlo"
+BR2_TARGET_BAREBOX_2_USE_SPECIFIC_IMAGE=y
+BR2_TARGET_BAREBOX_2_IMAGE_FILE="barebox-am33xx-beaglebone-mlo.img"
+
+# kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_LATEST_VERSION=y
+BR2_LINUX_KERNEL_USE_DEFCONFIG=y
+BR2_LINUX_KERNEL_DEFCONFIG="omap2plus"
+BR2_LINUX_KERNEL_ZIMAGE=y
--

2.5.0

* Builds barebox MLO and the barebox bootloader.
* Barebox integrates a perfectly good device-tree for the bbb, so no dtb is being generated with the kernel.

Signed-off-by Pieter Smith <[email protected]>

---
 configs/beaglebone_barebox_defconfig | 39 ++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 configs/beaglebone_barebox_defconfig

configs/beaglebone_barebox_defconfig new file +26 -0

new file mode 100644
index 0000000..b4fd67b
@@ -0,0 +1,39 @@
+# architecture
+BR2_arm=y
+BR2_cortex_a8=y
+BR2_ARM_EABIHF=y
+
+# system
+BR2_TARGET_GENERIC_HOSTNAME="beaglebone"
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyO0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/beaglebone/post-image.sh"
+
+# filesystem
+BR2_PACKAGE_AM33X_CM3=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
+
+# lock down headers to avoid breaking with new defaults
+BR2_KERNEL_HEADERS_VERSION=y
+BR2_DEFAULT_KERNEL_VERSION="3.12.10"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y
+
+# bootloader
+BR2_TARGET_BAREBOX_TWO_CONFIGS=y
+BR2_TARGET_BAREBOX=y
+BR2_TARGET_BAREBOX_BOARD_DEFCONFIG="am335x"

Quoted 29 lines · Pieter Smith

* Builds barebox MLO and the barebox bootloader.
* Barebox integrates a perfectly good device-tree for the bbb, so no dtb is being generated with the kernel.

Signed-off-by Pieter Smith <[email protected]>

---
 configs/beaglebone_barebox_defconfig | 39 ++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 configs/beaglebone_barebox_defconfig

configs/beaglebone_barebox_defconfig new file +13 -0

new file mode 100644
index 0000000..b4fd67b
@@ -0,0 +1,39 @@
+# architecture
+BR2_arm=y
+BR2_cortex_a8=y
+BR2_ARM_EABIHF=y
+
+# system
+BR2_TARGET_GENERIC_HOSTNAME="beaglebone"
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyO0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/beaglebone/post-image.sh"
+
+# filesystem

configs/beaglebone_barebox_defconfig line 21

Quoted 8 lines

configs/beaglebone_barebox_defconfig new file +8 -0

+BR2_PACKAGE_AM33X_CM3=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
+
+# lock down headers to avoid breaking with new defaults
+BR2_KERNEL_HEADERS_VERSION=y
+BR2_DEFAULT_KERNEL_VERSION="3.12.10"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y

Quoted 5 lines

configs/beaglebone_barebox_defconfig new file +5 -0

+
+# bootloader
+BR2_TARGET_BAREBOX_TWO_CONFIGS=y
+BR2_TARGET_BAREBOX=y
+BR2_TARGET_BAREBOX_BOARD_DEFCONFIG="am335x"

configs/beaglebone_barebox_defconfig line 36

Quoted 10 lines

configs/beaglebone_barebox_defconfig new file +10 -0

+BR2_TARGET_BAREBOX_USE_SPECIFIC_IMAGE=y
+BR2_TARGET_BAREBOX_IMAGE_FILE="barebox-am33xx-beaglebone.img"
+BR2_TARGET_BAREBOX_2=y
+BR2_TARGET_BAREBOX_2_BOARD_DEFCONFIG="am335x_mlo"
+BR2_TARGET_BAREBOX_2_USE_SPECIFIC_IMAGE=y
+BR2_TARGET_BAREBOX_2_IMAGE_FILE="barebox-am33xx-beaglebone-mlo.img"
+
+# kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_LATEST_VERSION=y

Kernel version should be locked down as well.

configs/beaglebone_barebox_defconfig line 39

Quoted 3 lines

configs/beaglebone_barebox_defconfig new file +3 -0

+BR2_LINUX_KERNEL_USE_DEFCONFIG=y
+BR2_LINUX_KERNEL_DEFCONFIG="omap2plus"
+BR2_LINUX_KERNEL_ZIMAGE=y

Perhaps add a comment here that the dtb from barebox will be used.

Regards,
Arnout

Quoted 1 line

Quoted 3 lines · Pieter Smith

* Builds barebox MLO and the barebox bootloader.
* Barebox integrates a perfectly good device-tree for the bbb, so no dtb is being generated with the kernel.

configs/beaglebone_barebox_defconfig line 36

Quoted 3 lines

configs/beaglebone_barebox_defconfig new file +3 -0

+# kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_LATEST_VERSION=y

Kernel version should be locked down as well.

configs/beaglebone_barebox_defconfig line 39

Quoted 3 lines

configs/beaglebone_barebox_defconfig new file +3 -0

+BR2_LINUX_KERNEL_USE_DEFCONFIG=y
+BR2_LINUX_KERNEL_DEFCONFIG="omap2plus"
+BR2_LINUX_KERNEL_ZIMAGE=y

Perhaps add a comment here that the dtb from barebox will be used.

Regards,
Arnout

Quoted 4 lines · Arnout Vandecappelle

Quoted 3 lines · Pieter Smith

* Builds barebox MLO and the barebox bootloader.
* Barebox integrates a perfectly good device-tree for the bbb, so no dtb is being generated with the kernel.

[snip]

Quoted 5 lines

configs/beaglebone_barebox_defconfig line 36

Quoted 3 lines

configs/beaglebone_barebox_defconfig new file +3 -0

+# kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_LATEST_VERSION=y

Kernel version should be locked down as well.

ACK. Will do.

Quoted 5 lines

configs/beaglebone_barebox_defconfig line 39

Quoted 3 lines

configs/beaglebone_barebox_defconfig new file +3 -0

+BR2_LINUX_KERNEL_USE_DEFCONFIG=y
+BR2_LINUX_KERNEL_DEFCONFIG="omap2plus"
+BR2_LINUX_KERNEL_ZIMAGE=y

Perhaps add a comment here that the dtb from barebox will be used.

A comment in the defconfig file? Not that I am against it, but will anybody actually read it?

On 02/29/16 09:44, Pieter Smith wrote:

Quoted 2 lines

A comment in the defconfig file? Not that I am against it, but will anybody actually read it?

Look at the other defconfig files, most of them have comments in them. That's
mostly for people who update the defconfigs, but also for newcomers who take a look at them to make it easier to understand.

This patch-set in 4 parts adds support for building barebox with up to 2 configurations. It can be used to build the barebox x-loader or MLO (also called Secondary Program Loader) in addition to the standard barebox build (Tertiary Program Loader). This implements the design proposed in
http://elinux.org/Buildroot#Todo_list:
1. Have boot/barebox/ containing the common stuff.
2. Add two separate packages boot/barebox-1/ and boot/barebox-2/.
3. There is only one version selection, but each package allows to define the configuration to be used.
4. Design is a little bit like package/gcc, where we have multiple gcc builds, but share a lot of common definitions between the packages.

To demonstrate that it works as advertized, the last patch adds a defconfig for the beaglebone black that makes use of the added functionality.

Hi Pieter,

Quoted 12 lines · Pieter Smith

This patch-set in 4 parts adds support for building barebox with up to 2 configurations. It can be used to build the barebox x-loader or MLO (also called Secondary Program Loader) in addition to the standard barebox build (Tertiary Program Loader). This implements the design proposed in
http://elinux.org/Buildroot#Todo_list:
1. Have boot/barebox/ containing the common stuff.
2. Add two separate packages boot/barebox-1/ and boot/barebox-2/.
3. There is only one version selection, but each package allows to define the configuration to be used.
4. Design is a little bit like package/gcc, where we have multiple gcc builds, but share a lot of common definitions between the packages.

Quoted 2 lines

To demonstrate that it works as advertized, the last patch adds a defconfig for the beaglebone black that makes use of the added functionality.

I've applied the patches and built both MLO and barebox.bin binaries. The patches are working as expected.

I have following use case: I have one board, but want provide different environment scripts per project. These scripts should be stored in BR2_EXTERNAL folder. I'd like to also embed them into barebox.bin. How can I do it in BR?

Yegor

Quoted 15 lines · Yegor Yefremov

Hi Pieter,

Quoted 12 lines · Pieter Smith

This patch-set in 4 parts adds support for building barebox with up to 2 configurations. It can be used to build the barebox x-loader or MLO (also called Secondary Program Loader) in addition to the standard barebox build (Tertiary Program Loader). This implements the design proposed in
http://elinux.org/Buildroot#Todo_list:
1. Have boot/barebox/ containing the common stuff.
2. Add two separate packages boot/barebox-1/ and boot/barebox-2/.
3. There is only one version selection, but each package allows to define the configuration to be used.
4. Design is a little bit like package/gcc, where we have multiple gcc builds, but share a lot of common definitions between the packages.

Quoted 5 lines

Quoted 2 lines

To demonstrate that it works as advertized, the last patch adds a defconfig for the beaglebone black that makes use of the added functionality.

I've applied the patches and built both MLO and barebox.bin binaries. The patches are working as expected.

Glad to hear it.

Quoted 4 lines

I have following use case: I have one board, but want provide different environment scripts per project. These scripts should be stored in BR2_EXTERNAL folder. I'd like to also embed them into barebox.bin. How can I do it in BR?

If I understand you correctly, you would like to customize the barebox environment integrated into barebox.bin on a per-project basis. This is something I spent a few hours looking into, but I have not found an adequate solution. It may be easier to bake a new buildroot environment and flash that.

Will this satisfy your use-case?

Quoted 34 lines · Pieter Smith

Quoted 15 lines · Yegor Yefremov

Hi Pieter,

Quoted 12 lines · Pieter Smith

This patch-set in 4 parts adds support for building barebox with up to 2 configurations. It can be used to build the barebox x-loader or MLO (also called Secondary Program Loader) in addition to the standard barebox build (Tertiary Program Loader). This implements the design proposed in
http://elinux.org/Buildroot#Todo_list:
1. Have boot/barebox/ containing the common stuff.
2. Add two separate packages boot/barebox-1/ and boot/barebox-2/.
3. There is only one version selection, but each package allows to define the configuration to be used.
4. Design is a little bit like package/gcc, where we have multiple gcc builds, but share a lot of common definitions between the packages.

Quoted 5 lines

Quoted 2 lines

To demonstrate that it works as advertized, the last patch adds a defconfig for the beaglebone black that makes use of the added functionality.

I've applied the patches and built both MLO and barebox.bin binaries. The patches are working as expected.

Glad to hear it.

Quoted 4 lines

I have following use case: I have one board, but want provide different environment scripts per project. These scripts should be stored in BR2_EXTERNAL folder. I'd like to also embed them into barebox.bin. How can I do it in BR?

If I understand you correctly, you would like to customize the barebox environment integrated into barebox.bin on a per-project basis. This is something I spent a few hours looking into, but I have not found an adequate solution. It may be easier to bake a new buildroot environment and flash that.

Quoted 1 line

Will this satisfy your use-case?

I've found a solution: http://patchwork.ozlabs.org/patch/583444/

The question is should enable both inetrnel and external env image? I think we should keep both in parallel.

Yegor