Supporting a second Barebox build to build the MLO/SPL
cover Supporting a second Barebox build to build the MLO/SPL
This patch-set in 4 parts adds support for building a second barebox build (the x-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-boot/ and boot/barebox-xload/.
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.
Pieter Smith (4):
barebox: prepare for x-loader build
barebox: adds option to build x-loader
barebox: user selection of build output images
beaglebone: adds barebox bootloader defconfig
boot/barebox/Config.in | 92 +++++++++++++++++++++++++++ boot/barebox/barebox-boot/barebox-boot.hash | 1 + boot/barebox/barebox-boot/barebox-boot.mk | 89 ++++++++++++++++++++++++++ boot/barebox/barebox-xload/barebox-xload.hash | 1 + boot/barebox/barebox-xload/barebox-xload.mk | 51 +++++++++++++++ boot/barebox/barebox.mk | 60 +---------------- configs/beaglebone_barebox_defconfig | 38 +++++++++++ 7 files changed, 273 insertions(+), 59 deletions(-) create mode 120000 boot/barebox/barebox-boot/barebox-boot.hash create mode 100644 boot/barebox/barebox-boot/barebox-boot.mk create mode 120000 boot/barebox/barebox-xload/barebox-xload.hash create mode 100644 boot/barebox/barebox-xload/barebox-xload.mk create mode 100644 configs/beaglebone_barebox_defconfig
Signature · 1 line
2.1.4
PATCH 1/4 barebox: prepare for x-loader build
No functional changes, but prepares barebox for building with two configurations (similar to package/gcc).
--- boot/barebox/Config.in | 9 ++++ boot/barebox/barebox-boot/barebox-boot.hash | 1 + boot/barebox/barebox-boot/barebox-boot.mk | 80 +++++++++++++++++++++++++++++ boot/barebox/barebox.mk | 60 +--------------------- 4 files changed, 91 insertions(+), 59 deletions(-) create mode 120000 boot/barebox/barebox-boot/barebox-boot.hash create mode 100644 boot/barebox/barebox-boot/barebox-boot.mk
boot/barebox/Config.in +9 -0
@@ -64,6 +64,13 @@ config BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION endif +config BR2_TARGET_BAREBOX_BOOT + bool "Build Barebox bootloader" + default y + help + Build the Barebox bootloader + +if BR2_TARGET_BAREBOX_BOOT choice prompt "Barebox configuration"
@@ -122,3 +129,5 @@ config BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH the same name as the directory name given here. endif + +endif
boot/barebox/barebox-boot/barebox-boot.hash new file +1 -0
@@ -0,0 +1 @@ +../barebox.hash
boot/barebox/barebox-boot/barebox-boot.mk new file +80 -0
80 lines not on this page · raw message
boot/barebox/barebox.mk +1 -59
66 lines not on this page · raw message
Signature · 1 line
2.1.4
PATCH 2/4 barebox: adds option to build x-loader
In reply to Pieter SmithSupport selection of x-loader config, but version, source URL and patches are shared with barebox bootloader build.
--- boot/barebox/Config.in | 47 +++++++++++++++++++++++++++ boot/barebox/barebox-xload/barebox-xload.hash | 1 + boot/barebox/barebox-xload/barebox-xload.mk | 44 +++++++++++++++++++++++++ 3 files changed, 92 insertions(+) create mode 120000 boot/barebox/barebox-xload/barebox-xload.hash create mode 100644 boot/barebox/barebox-xload/barebox-xload.mk
boot/barebox/Config.in +47 -0
@@ -130,4 +130,51 @@ config BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH endif +config BR2_TARGET_BAREBOX_XLOAD + bool "Build Barebox x-loader" + help + Build the Barebox x-loader + +if BR2_TARGET_BAREBOX_XLOAD + +choice + prompt "Barebox x-loader configuration" + default BR2_TARGET_BAREBOX_XLOAD_USE_DEFCONFIG + +config BR2_TARGET_BAREBOX_XLOAD_USE_DEFCONFIG + bool "Using a x-loader defconfig" + +config BR2_TARGET_BAREBOX_XLOAD_USE_CUSTOM_CONFIG + bool "Using a custom x-loader config file" + +endchoice + +config BR2_TARGET_BAREBOX_XLOAD_BOARD_DEFCONFIG + string "X-loader board defconfig" + depends on BR2_TARGET_BAREBOX_XLOAD_USE_DEFCONFIG + help + Name of the board for which Barebox should be built, without + the _defconfig suffix. + + +config BR2_TARGET_BAREBOX_XLOAD_CUSTOM_CONFIG_FILE + string "X-loader configuration file path" + depends on BR2_TARGET_BAREBOX_XLOAD_USE_CUSTOM_CONFIG + help + Path to the barebox configuration file + +config BR2_TARGET_BAREBOX_XLOAD_CONFIG_FRAGMENT_FILES + string "Additional x-loader 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_XLOAD_INSTALL_FILENAME + string "X-loader image filename when installed" + default "MLO" + help + Name to give the image in the output/images directory. + +endif + endif
boot/barebox/barebox-xload/barebox-xload.hash new file +1 -0
@@ -0,0 +1 @@ +../barebox.hash
boot/barebox/barebox-xload/barebox-xload.mk new file +44 -0
44 lines not on this page · raw message
Signature · 1 line
2.1.4
PATCH 3/4 barebox: user selection of build output images
In reply to Pieter SmithA 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).
--- boot/barebox/Config.in | 36 +++++++++++++++++++++++++++++ boot/barebox/barebox-boot/barebox-boot.mk | 13 +++++++++-- boot/barebox/barebox-xload/barebox-xload.mk | 7 ++++++ 3 files changed, 54 insertions(+), 2 deletions(-)
boot/barebox/Config.in +36 -0
@@ -104,6 +104,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 + config BR2_TARGET_BAREBOX_BAREBOXENV bool "bareboxenv tool in target" help
@@ -169,6 +187,24 @@ config BR2_TARGET_BAREBOX_XLOAD_CONFIG_FRAGMENT_FILES A space-separated list of configuration fragment files, that will be merged to the main Barebox configuration file. +choice + prompt "Barebox x-loader image file" + default BR2_TARGET_BAREBOX_XLOAD_USE_DEFAULT_IMAGE + +config BR2_TARGET_BAREBOX_XLOAD_USE_DEFAULT_IMAGE + bool "Using the default x-loader image file" + +config BR2_TARGET_BAREBOX_XLOAD_USE_SPECIFIC_IMAGE + bool "Using a specific x-loader image file" + +endchoice + +config BR2_TARGET_BAREBOX_XLOAD_IMAGE_FILE + string "X-loader image file path" + depends on BR2_TARGET_BAREBOX_XLOAD_USE_SPECIFIC_IMAGE + help + Name of the built x-loader barebox image file + config BR2_TARGET_BAREBOX_XLOAD_INSTALL_FILENAME string "X-loader image filename when installed" default "MLO"
boot/barebox/barebox-boot/barebox-boot.mk +11 -2
@@ -15,6 +15,7 @@ BAREBOX_BOOT_POST_PATCH_HOOKS += $(BAREBOX_POST_PATCH_HOOKS) BAREBOX_BOOT_MAKE_FLAGS = $(BAREBOX_MAKE_FLAGS) BAREBOX_BOOT_MAKE_ENV = $(BAREBOX_MAKE_ENV) BAREBOX_BOOT_INSTALL_IMAGES = $(BAREBOX_INSTALL_IMAGES) +BAREBOX_BOOT_INSTALL_DEST = $(BINARIES_DIR)/barebox.bin ifeq ($(BR2_TARGET_BAREBOX_USE_DEFCONFIG),y) BAREBOX_BOOT_SOURCE_CONFIG = $(BAREBOX_BOOT_DIR)/arch/$(BAREBOX_ARCH)/configs/$(call qstrip,\
@@ -54,14 +55,22 @@ define BAREBOX_BOOT_BUILD_CMDS $(BAREBOX_BOOT_BUILD_CUSTOM_ENV) endef +ifdef BR2_TARGET_BAREBOX_USE_SPECIFIC_IMAGE +define BAREBOX_BOOT_INSTALL_IMAGES_CMDS + cp -L $(@D)/images/$(call qstrip,$(BR2_TARGET_BAREBOX_IMAGE_FILE)) \ + $(BAREBOX_BOOT_INSTALL_DEST) + $(BAREBOX_BOOT_INSTALL_CUSTOM_ENV) +endef +else define BAREBOX_BOOT_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_BOOT_INSTALL_DEST) ; \ else \ - cp $(@D)/barebox.bin $(BINARIES_DIR);\ + cp $(@D)/barebox.bin $(BAREBOX_BOOT_INSTALL_DEST);\ fi $(BAREBOX_BOOT_INSTALL_CUSTOM_ENV) endef +endif ifeq ($(BR2_TARGET_BAREBOX_BAREBOXENV),y) define BAREBOX_BOOT_INSTALL_TARGET_CMDS
boot/barebox/barebox-xload/barebox-xload.mk +7 -0
@@ -33,6 +33,12 @@ define BAREBOX_XLOAD_BUILD_CMDS $(TARGET_MAKE_ENV) $(MAKE) $(BAREBOX_XLOAD_MAKE_FLAGS) -C $(@D) endef +ifdef BR2_TARGET_BAREBOX_XLOAD_USE_SPECIFIC_IMAGE +define BAREBOX_XLOAD_INSTALL_IMAGES_CMDS + cp -L $(@D)/images/$(call qstrip,$(BR2_TARGET_BAREBOX_XLOAD_IMAGE_FILE)) \ + $(BAREBOX_XLOAD_INSTALL_DEST) +endef +else define BAREBOX_XLOAD_INSTALL_IMAGES_CMDS if test -h $(@D)/barebox-flash-image ; then \ cp -L $(@D)/barebox-flash-image $(BAREBOX_XLOAD_INSTALL_DEST) ; \
@@ -40,5 +46,6 @@ define BAREBOX_XLOAD_INSTALL_IMAGES_CMDS cp $(@D)/barebox.bin $(BAREBOX_XLOAD_INSTALL_DEST);\ fi endef +endif $(eval $(kconfig-package))
Signature · 1 line
2.1.4
PATCH 4/4 beaglebone: adds barebox bootloader defconfig
In reply to Pieter Smith* Builds barebox x-loader (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 | 38 ++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 configs/beaglebone_barebox_defconfig
configs/beaglebone_barebox_defconfig new file +38 -0
@@ -0,0 +1,38 @@ +# 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=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_XLOAD=y +BR2_TARGET_BAREBOX_XLOAD_BOARD_DEFCONFIG="am335x_mlo" +BR2_TARGET_BAREBOX_XLOAD_USE_SPECIFIC_IMAGE=y +BR2_TARGET_BAREBOX_XLOAD_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
Signature · 1 line
2.1.4
cover Supporting a second Barebox build to build the MLO/SPL
In reply to Pieter SmithDear Pieter Smith,
Quoted 6 lines · Pieter Smith
Pieter Smith (4):
barebox: prepare for x-loader build
barebox: adds option to build x-loader
barebox: user selection of build output images
beaglebone: adds barebox bootloader defconfig
Quoted 7 lines
boot/barebox/Config.in | 92 +++++++++++++++++++++++++++ boot/barebox/barebox-boot/barebox-boot.hash | 1 + boot/barebox/barebox-boot/barebox-boot.mk | 89 ++++++++++++++++++++++++++ boot/barebox/barebox-xload/barebox-xload.hash | 1 + boot/barebox/barebox-xload/barebox-xload.mk | 51 +++++++++++++++ boot/barebox/barebox.mk | 60 +---------------- configs/beaglebone_barebox_defconfig | 38 +++++++++++
I believe "xload" is really a term tied to the OMAP platforms, but Barebox can have this dual configuration situation for other platforms as well (ex: Atmel). Some other platforms use the term "SPL".
Can we find some better name ?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
cover Supporting a second Barebox build to build the MLO/SPL
Hi Thomas,
Quoted 18 lines · Thomas Petazzoni
Dear Pieter Smith,
Quoted 6 lines · Pieter Smith
Pieter Smith (4):
barebox: prepare for x-loader build
barebox: adds option to build x-loader
barebox: user selection of build output images
beaglebone: adds barebox bootloader defconfigQuoted 7 lines
boot/barebox/Config.in | 92 +++++++++++++++++++++++++++ boot/barebox/barebox-boot/barebox-boot.hash | 1 + boot/barebox/barebox-boot/barebox-boot.mk | 89 ++++++++++++++++++++++++++ boot/barebox/barebox-xload/barebox-xload.hash | 1 + boot/barebox/barebox-xload/barebox-xload.mk | 51 +++++++++++++++ boot/barebox/barebox.mk | 60 +---------------- configs/beaglebone_barebox_defconfig | 38 +++++++++++
Quoted 5 lines
I believe "xload" is really a term tied to the OMAP platforms, but Barebox can have this dual configuration situation for other platforms as well (ex: Atmel). Some other platforms use the term "SPL".
Can we find some better name ?
Yes please, but selecting a use-case agnostic name might be tricky:
U-Boot uses SPL (Secondary Program Loader) to describe a "run from internal SRAM" build as opposed to TPL (Tertiary Program Loader) for the normal "run from external RAM" build. This terminology however is U-Boot specific.
From a pure barebox perspective, there is nothing distinctive about the second build. It is just another defconfig, so there does not seem to be barebox terminology to differentiate between these types of builds. (Barebox even leaves the naming as a configuration option)
From an OMAP perspective, the second build is used to generate the X-loader when booting from NAND or MLO when booting from MMC.
I would have loved to just stick with the boot stage naming, but the stage is very much architecture dependent:
For BBB for example:
1. First-stage bootloader runs from internal hard-coded ROM
2. Second-stage bootloader runs from the internal SRAM (TI MLO) and is generated with a trimmed down configuration.
3. Third-stage bootloader runs from the external RAM and is generated with a full configuration.
But for the QCA4531 and family:
1. First-stage bootloader runs from external serial NOR flash and is generated with a full-blown configuration.
IMHO, let's just go with the suggested U-Boot naming (SPL) and if no barebox developers complain, stick to that.
Agreed?
Quoted 6 lines
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
cover Supporting a second Barebox build to build the MLO/SPL
Hi Thomas,
Quoted 36 lines · Pieter Smith
Hi Thomas,
Quoted 6 lines · Thomas Petazzoni
I believe "xload" is really a term tied to the OMAP platforms, but Barebox can have this dual configuration situation for other platforms as well (ex: Atmel). Some other platforms use the term "SPL".
Can we find some better name ?
Yes please, but selecting a use-case agnostic name might be tricky:
U-Boot uses SPL (Secondary Program Loader) to describe a "run from internal SRAM" build as opposed to TPL (Tertiary Program Loader) for the normal "run from external RAM" build. This terminology however is U-Boot specific.
From a pure barebox perspective, there is nothing distinctive about the second build. It is just another defconfig, so there does not seem to be barebox terminology to differentiate between these types of builds. (Barebox even leaves the naming as a configuration option)
From an OMAP perspective, the second build is used to generate the X-loader when booting from NAND or MLO when booting from MMC.
I would have loved to just stick with the boot stage naming, but the stage is very much architecture dependent:
For BBB for example:
1. First-stage bootloader runs from internal hard-coded ROM
2. Second-stage bootloader runs from the internal SRAM (TI MLO) and is generated with a trimmed down configuration.
3. Third-stage bootloader runs from the external RAM and is generated with a full configuration.
But for the QCA4531 and family:
1. First-stage bootloader runs from external serial NOR flash and is generated with a full-blown configuration.
Quoted 4 lines
IMHO, let's just go with the suggested U-Boot naming (SPL) and if no barebox developers complain, stick to that.
Agreed?
I have a more use-case agnostic suggestion. I can add a KConfig choice to specify the number of barebox configs to build. Until otherwise required, the only valid choices are 1 or 2. To avoid wasting creativity on something guaranteed to raise criticism, the two sub-packages are named:
boot/barebox/barebox-config1
boot/barebox/barebox-config2
In the help I will obviously describe possible use-cases for the two sub-configs, but I will steer clear from giving a generic mechanism a specific name.
What are your thoughts on this?
cover Supporting a second Barebox build to build the MLO/SPL
Quoted 1 line · Pieter Smith
What are your thoughts on this?
Thinking out of the box here: would it be possible to keep a single barebox
package and do everything twice (or more) in the _CMDS, with different output directories?
Granted, that will be a bit tricky w.r.t. the kconfig infra.
Regards,
Arnout
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
cover Supporting a second Barebox build to build the MLO/SPL
Hi Arnout,
Quoted 8 lines · Arnout Vandecappelle
Quoted 1 line · Pieter Smith
What are your thoughts on this?
Thinking out of the box here: would it be possible to keep a single barebox
package and do everything twice (or more) in the_CMDS, with different output directories?Granted, that will be a bit tricky w.r.t. the kconfig infra.
My initial approach was exactly what you are suggesting. It works fine for compiling the images, but it falls apart on other useful make infrastructure that you would want to run at a finer granularity:
Wanting to build barebox with two configs, you would typically want to run %-menuconfig for each of the two. This is not possible if the two builds are not implemented by two separate packages in the buildroot make environment. It simply ends up not being handy if the two build configurations are not addressable as two separate packages.
Quoted 11 lines
Regards,
ArnoutSignature · 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
Regards,
Pieter Smith