u-boot: allow to pass a custom configuration file
PATCH 1/1 u-boot: allow to pass a custom configuration file
--- boot/uboot/Config.in | 18 ++++++++++++++++++ boot/uboot/uboot.mk | 3 +++ 2 files changed, 21 insertions(+), 0 deletions(-)
boot/uboot/Config.in +18 -0
@@ -71,6 +71,24 @@ config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION endif choice + prompt "U-Boot configuration" + default BR2_TARGET_UBOOT_USE_DEFCONFIG + +config BR2_TARGET_UBOOT_USE_DEFCONFIG + bool "Using default configuration" + +config BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + bool "Using a custom configuration file" + +endchoice + +config BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE + string "Configuration file path" + depends on BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + help + Path to the customized U-Boot configuration file + +choice prompt "U-Boot binary format" default BR2_TARGET_UBOOT_FORMAT_BIN
boot/uboot/uboot.mk +3 -0
@@ -80,6 +80,9 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_CUSTOM_PATCHES endif define UBOOT_CONFIGURE_CMDS + $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h) $(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_config
Signature · 1 line
1.7.2.5
PATCH 1/1 u-boot: allow to pass a custom configuration file
Dear Eric Jarrige,
boot/uboot/Config.in config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION · line 78
Quoted 6 lines · Eric Jarrige
choice
boot/uboot/Config.in +5
-0+ prompt "U-Boot configuration" + default BR2_TARGET_UBOOT_USE_DEFCONFIG + +config BR2_TARGET_UBOOT_USE_DEFCONFIG + bool "Using default configuration"
I don't think using the word 'defconfig' for U-Boot is appropriate, since 'defconfig' really refers to a kconfig terminology and U-Boot, sadly, doesn't use kconfig.
boot/uboot/uboot.mk UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_CUSTOM_PATCHES · line 88
Quoted 7 lines
define
UBOOT_CONFIGURE_CMDSboot/uboot/uboot.mk +3
-0+ $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h) $(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_config
I am a bit hesitant on the overall feature. The fact that a include/configs/<something>.h file is really a configuration file is pretty fuzzy in U-Boot, especially since now boards are supposed to also be listed in the main boards.cfg file.
Therefore, I'm tempted to say that users who need to do that should instead use patches against U-Boot (to add their own board, including the include/configs/<something>.h file).
But on this one, I believe I can be convinced if there are good arguments :)
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 u-boot: allow to pass a custom configuration file
Hi Thomas,
Quoted 4 lines · Thomas Petazzoni
Dear Eric Jarrige,
On Thu, 19 Sep 2013 13:10:06 +0200, Eric Jarrige wrote:
Quoted 10 lines
boot/uboot/Config.in config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION · line 78
Quoted 6 lines
choice
boot/uboot/Config.in +5
-0+ prompt "U-Boot configuration" + default BR2_TARGET_UBOOT_USE_DEFCONFIG + +config BR2_TARGET_UBOOT_USE_DEFCONFIG + bool "Using default configuration"I don't think using the word 'defconfig' for U-Boot is appropriate, since 'defconfig' really refers to a kconfig terminology and U-Boot, sadly, doesn't use kconfig.
Does the alternate terminology DEFAULT_CONFIG could be more appropriate or acceptable ?
Quoted 14 lines
Quoted 8 lines
define
UBOOT_CONFIGURE_CMDSboot/uboot/uboot.mk +3
-0+ $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h)$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_configI am a bit hesitant on the overall feature. The fact that a include/configs/<something>.h file is really a configuration file is pretty fuzzy in U-Boot, especially since now boards are supposed to also be listed in the main boards.cfg file.
Quoted 6 lines
Therefore, I'm tempted to say that users who need to do that should instead use patches against U-Boot (to add their own board, including the include/configs/<something>.h file).
But on this one, I believe I can be convinced if there are good arguments :)
The file boards.cfg is a source of confusion for me. This file provides the list of boards with some extra information like status of the board and maintainer email address.
Nevertheless the concrete config files are the <BOARD>.h files located in include/config even if U-Boot a C syntax with a list of #define instead of the common kconfig syntax.
You are right, a customization of the U-Boot config file can be done through the use of patches as it could be done for some other packages like Barebox, Busybox or the linux kernel but the BuildRoot feature to support custom config files for the main packages is more than convenient. So the purpose of this patch is to add this feature to the U Boot option as well.
IMHO such a feature could be useful for some other BuildRoot/U-Boot user but may be I wrong. Please let me know.
Best regards,
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130919/a3b7e941/attachment-0001.asc>
PATCH 1/1 u-boot: allow to pass a custom configuration file
Dear Eric Jarrige,
Quoted 6 lines · Eric Jarrige
Quoted 3 lines
I don't think using the word 'defconfig' for U-Boot is appropriate, since 'defconfig' really refers to a kconfig terminology and U-Boot, sadly, doesn't use kconfig.
Does the alternate terminology
DEFAULT_CONFIGcould be more appropriate or acceptable ?
I don't think "default" is really meaningful. Just "Path to the board configuration file" would be sufficient.
Quoted 20 lines
Quoted 13 lines
Quoted 7 lines
define
UBOOT_CONFIGURE_CMDSboot/uboot/uboot.mk +3
-0+ $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h)$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_configI am a bit hesitant on the overall feature. The fact that a include/configs/<something>.h file is really a configuration file is pretty fuzzy in U-Boot, especially since now boards are supposed to also be listed in the main boards.cfg file.
Quoted 6 lines
Therefore, I'm tempted to say that users who need to do that should instead use patches against U-Boot (to add their own board, including the include/configs/<something>.h file).
But on this one, I believe I can be convinced if there are good arguments :)
Quoted 6 lines
The file boards.cfg is a source of confusion for me. This file provides the list of boards with some extra information like status of the board and maintainer email address.
Nevertheless the concrete config files are the <BOARD>.h files located ininclude/configeven if U-Boot a C syntax with a list of #define instead of the common kconfig syntax.
Right, but it looks like nowadays that adding a board configuration requires both adding a include/configs/<BOARD>.h file and an entry in boards.cfg (though I agree that was the 'mkconfig' script is doing is quite obscure).
Quoted 8 lines
You are right, a customization of the U-Boot config file can be done through the use of patches as it could be done for some other packages like Barebox, Busybox or the linux kernel but the BuildRoot feature to support custom config files for the main packages is more than convenient. So the purpose of this patch is to add this feature to the U Boot option as well.
IMHO such a feature could be useful for some other BuildRoot/U-Boot user but may be I wrong. Please let me know.
Well again, the problem I see is that the "board configuration" in U-Boot is not something that is as well isolated as it is in the kernel or Barebox. In the kernel or Barebox, the configuration file is only here to describe *how* you would like the support for a particular board to be built (with network, without, with this or that other driver).
While in U-Boot, the <BOARD>.h file is an *integral* part of the board support itself: it not only defines the configuration you want for this particular build, but also describes the hardware itself. In U-Boot, whether you want the network support or not is mixed with the information of which network device your board has, and how it is connected on the board. So a <BOARD>.h file is typically not standalone, it comes with a new board/<something>/<boardname>/ directory.
That's the reason I'm skeptical that this is useful in practice.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 u-boot: allow to pass a custom configuration file
Hi Thomas,
Quoted 8 lines · Thomas Petazzoni
Dear Eric Jarrige,
Quoted 4 lines · Eric Jarrige
Quoted 3 lines
I don't think using the word 'defconfig' for U-Boot is appropriate, since 'defconfig' really refers to a kconfig terminology and U-Boot, sadly, doesn't use kconfig.
Quoted 5 lines
Quoted 2 lines
Does the alternate terminology
DEFAULT_CONFIGcould be more appropriate or acceptable ?I don't think "default" is really meaningful. Just "Path to the board configuration file" would be sufficient.
ok
Quoted 28 lines
Quoted 21 lines
Quoted 14 lines
Quoted 8 lines
define
UBOOT_CONFIGURE_CMDSboot/uboot/uboot.mk +3
-0+ $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h)$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_configI am a bit hesitant on the overall feature. The fact that a include/configs/<something>.h file is really a configuration file is pretty fuzzy in U-Boot, especially since now boards are supposed to also be listed in the main boards.cfg file.
Quoted 6 lines
Therefore, I'm tempted to say that users who need to do that should instead use patches against U-Boot (to add their own board, including the include/configs/<something>.h file).
But on this one, I believe I can be convinced if there are good arguments :)
Quoted 6 lines
The file boards.cfg is a source of confusion for me. This file provides the list of boards with some extra information like status of the board and maintainer email address.
Nevertheless the concrete config files are the <BOARD>.h files located ininclude/configeven if U-Boot a C syntax with a list of #define instead of the common kconfig syntax.
Quoted 4 lines
Right, but it looks like nowadays that adding a board configuration requires both adding a include/configs/<BOARD>.h file and an entry in boards.cfg (though I agree that was the 'mkconfig' script is doing is quite obscure).
Right, by providing an external config file it is only possible to customize the behaviors of an existing board in U-Boot.
Quoted 17 lines
Quoted 9 lines
You are right, a customization of the U-Boot config file can be done through the use of patches as it could be done for some other packages like Barebox, Busybox or the linux kernel but the BuildRoot feature to support custom config files for the main packages is more than convenient. So the purpose of this patch is to add this feature to the U Boot option as well.
IMHO such a feature could be useful for some other BuildRoot/U-Boot user but may be I wrong. Please let me know.Well again, the problem I see is that the "board configuration" in U-Boot is not something that is as well isolated as it is in the kernel or Barebox. In the kernel or Barebox, the configuration file is only here to describe *how* you would like the support for a particular board to be built (with network, without, with this or that other driver).
Quoted 8 lines
While in U-Boot, the <BOARD>.h file is an *integral* part of the board support itself: it not only defines the configuration you want for this particular build, but also describes the hardware itself. In U-Boot, whether you want the network support or not is mixed with the information of which network device your board has, and how it is connected on the board. So a <BOARD>.h file is typically not standalone, it comes with a new board/<something>/<boardname>/ directory.
Sorry for the confusion, but the purpose of this patch is more way to customize one of the U-Boot config than adding a new board to U-Boot. This will probably change in the future as soon as U-Boot - like Barebox
- fully support the openfirmware device tree architecture.
Quoted 2 lines
That's the reason I'm skeptical that this is useful in practice.
I apologize if you understood to be able to support any new board by just adding a new config file.
I hope to have clarified the purpose of this patch and will submit a new version of this patch with the change discussed here above in the meantime.
Best regards,
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130920/fde647ec/attachment-0001.asc>
PATCH 1/1 u-boot: allow to pass a custom configuration file
In reply to Thomas PetazzoniHi Thomas,
Please forget my previous email that was sadly formated.
Quoted 8 lines · Thomas Petazzoni
Dear Eric Jarrige,
Quoted 4 lines · Eric Jarrige
Quoted 3 lines
I don't think using the word 'defconfig' for U-Boot is appropriate, since 'defconfig' really refers to a kconfig terminology and U-Boot, sadly, doesn't use kconfig.
Quoted 5 lines
Quoted 2 lines
Does the alternate terminology
DEFAULT_CONFIGcould be more appropriate or acceptable ?I don't think "default" is really meaningful. Just "Path to the board configuration file" would be sufficient.
ok
Quoted 28 lines
Quoted 21 lines
Quoted 14 lines
Quoted 8 lines
define
UBOOT_CONFIGURE_CMDSboot/uboot/uboot.mk +3
-0+ $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h)$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_configI am a bit hesitant on the overall feature. The fact that a include/configs/<something>.h file is really a configuration file is pretty fuzzy in U-Boot, especially since now boards are supposed to also be listed in the main boards.cfg file.
Quoted 6 lines
Therefore, I'm tempted to say that users who need to do that should instead use patches against U-Boot (to add their own board, including the include/configs/<something>.h file).
But on this one, I believe I can be convinced if there are good arguments :)
Quoted 6 lines
The file boards.cfg is a source of confusion for me. This file provides the list of boards with some extra information like status of the board and maintainer email address.
Nevertheless the concrete config files are the <BOARD>.h files located ininclude/configeven if U-Boot a C syntax with a list of #define instead of the common kconfig syntax.
Quoted 4 lines
Right, but it looks like nowadays that adding a board configuration requires both adding a include/configs/<BOARD>.h file and an entry in boards.cfg (though I agree that was the 'mkconfig' script is doing is quite obscure).
Right, by providing an external config file it is only possible to customize the behaviors of an existing board in U-Boot.
Quoted 17 lines
Quoted 9 lines
You are right, a customization of the U-Boot config file can be done through the use of patches as it could be done for some other packages like Barebox, Busybox or the linux kernel but the BuildRoot feature to support custom config files for the main packages is more than convenient. So the purpose of this patch is to add this feature to the U Boot option as well.
IMHO such a feature could be useful for some other BuildRoot/U-Boot user but may be I wrong. Please let me know.Well again, the problem I see is that the "board configuration" in U-Boot is not something that is as well isolated as it is in the kernel or Barebox. In the kernel or Barebox, the configuration file is only here to describe *how* you would like the support for a particular board to be built (with network, without, with this or that other driver).
Quoted 8 lines
While in U-Boot, the <BOARD>.h file is an *integral* part of the board support itself: it not only defines the configuration you want for this particular build, but also describes the hardware itself. In U-Boot, whether you want the network support or not is mixed with the information of which network device your board has, and how it is connected on the board. So a <BOARD>.h file is typically not standalone, it comes with a new board/<something>/<boardname>/ directory.
Sorry for the confusion, but the purpose of this patch is more way to customize one of the U-Boot config than adding a new board to U-Boot. This will probably change in the future as soon as U-Boot - like Barebox
- fully support the openfirmware device tree architecture.
Quoted 2 lines
That's the reason I'm skeptical that this is useful in practice.
I apologize if you understood to be able to support any new board by just adding a new config file.
I hope to have clarified the purpose of this patch and will submit a new version of this patch with the change discussed here above in the meantime.
Best regards,
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130920/9ec9b93c/attachment.asc>
PATCH v2 1/1 u-boot: allow to pass a custom configuration file
In reply to Eric Jarrige---
Changes v1 -> v2:
- Fix typo
boot/uboot/Config.in | 18 ++++++++++++++++++ boot/uboot/uboot.mk | 3 +++ 2 files changed, 21 insertions(+), 0 deletions(-)
boot/uboot/Config.in +18 -0
@@ -71,6 +71,24 @@ config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION endif choice + prompt "U-Boot configuration" + default BR2_TARGET_UBOOT_USE_DEFCONFIG + +config BR2_TARGET_UBOOT_USE_DEFCONFIG + bool "Using default board configuration file" + +config BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + bool "Using a custom board configuration file" + +endchoice + +config BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE + string "Configuration file path" + depends on BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + help + Path to the board configuration file + +choice prompt "U-Boot binary format" default BR2_TARGET_UBOOT_FORMAT_BIN
boot/uboot/uboot.mk +3 -0
@@ -80,6 +80,9 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_CUSTOM_PATCHES endif define UBOOT_CONFIGURE_CMDS + $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h) $(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_config
Signature · 1 line
1.7.2.5
PATCH v2 1/1 u-boot: allow to pass a custom configuration file
In reply to Eric Jarrige---
Changes v1 -> v2:
- Fix typo
boot/uboot/Config.in | 18 ++++++++++++++++++ boot/uboot/uboot.mk | 3 +++ 2 files changed, 21 insertions(+), 0 deletions(-)
boot/uboot/Config.in +18 -0
@@ -71,6 +71,24 @@ config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION endif choice + prompt "U-Boot configuration" + default BR2_TARGET_UBOOT_USE_DEFCONFIG + +config BR2_TARGET_UBOOT_USE_DEFCONFIG + bool "Using default board configuration file" + +config BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + bool "Using a custom board configuration file" + +endchoice + +config BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE + string "Configuration file path" + depends on BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + help + Path to the board configuration file + +choice prompt "U-Boot binary format" default BR2_TARGET_UBOOT_FORMAT_BIN
boot/uboot/uboot.mk +3 -0
@@ -80,6 +80,9 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_CUSTOM_PATCHES endif define UBOOT_CONFIGURE_CMDS + $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h) $(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_config
Signature · 1 line
1.7.2.5
PATCH v2 1/1 u-boot: allow to pass a custom configuration file
Quoted 15 lines · Eric Jarrige
Signed-off-by Eric Jarrige <[email protected]>---
Changes v1 -> v2:
- Fix typoboot/uboot/Config.in | 18 ++++++++++++++++++ boot/uboot/uboot.mk | 3 +++ 2 files changed, 21 insertions(+), 0 deletions(-)boot/uboot/Config.in +0
-0
boot/uboot/Config.in config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION · line 78
Quoted 8 lines
boot/uboot/Config.in +5
-0@@ -71,6 +71,24 @@ config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION endif choice + prompt "U-Boot configuration" + default BR2_TARGET_UBOOT_USE_DEFCONFIG + +config BR2_TARGET_UBOOT_USE_DEFCONFIG + bool "Using default board configuration file"
Thomas P. made a remark that you didn't take into account:
Quoted 9 lines
boot/uboot/Config.in +0
-0>> I don't think using the word 'defconfig' for U-Boot is appropriate, >> since 'defconfig' really refers to a kconfig terminology and U-Boot,Quoted 4 lines
Quoted 1 line
sadly, doesn't use kconfig.
Does the alternate terminology
DEFAULT_CONFIGcould be more appropriate or acceptable ?I don't think "default" is really meaningful. Just "Path to the board configuration file" would be sufficient.
Also, it is missing help text. So I propose:
config BR2_TARGET_UBOOT_USE_BUNDLED_CONFIG
bool "Use <boardname>.h in the U-Boot sources" help
Choose this option to use the include/configs/<boardname>.h file in the U-Boot sources as the configuration.
config BR2_TARGET_UBOOT_USE_MODIFIED_CONFIG
bool "Use a modified configuration header file" help
Choose this option to provide a path to a customized header file with the configuration option. Note that this doesn't allow you to create a custom board, only to modify some of configuration variables.
boot/uboot/Config.in config BR2_TARGET_UBOOT_CUSTOM_GIT_VERSION · line 89
Quoted 11 lines
boot/uboot/Config.in +11
-0+ +config BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + bool "Using a custom board configuration file" + +endchoice + +config BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE + string "Configuration file path" + depends on BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG + help + Path to the board configuration file
help
Path to the modified configuration header file. It will be copied to include/configs/<boardname>.h in the U-Boot sources. Note that this doesn't allow you to create a custom board, only to modify some of configuration variables.
Also, instead of adding a choice to choose between bundled or modified
configuration file, you could just have the string option and use the default if it is empty. The first way is what is used in kernel and barebox, the second way is what is done in busybox and uClibc. Well, actually, the latter don't use the default when it's empty, instead they encode the default in the Config.in - but I personally don't like that :-)
Peter, which approach do you prefer?
Quoted 10 lines
boot/uboot/Config.in +2
-0+ +choice prompt "U-Boot binary format" default BR2_TARGET_UBOOT_FORMAT_BINboot/uboot/uboot.mk +0
-0
boot/uboot/uboot.mk UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_CUSTOM_PATCHES · line 85
Quoted 6 lines
boot/uboot/uboot.mk +3
-0@@ -80,6 +80,9 @@ UBOOT_POST_PATCH_HOOKS += UBOOT_APPLY_CUSTOM_PATCHES endif define UBOOT_CONFIGURE_CMDS + $(if $(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG), + cp -pf $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ + $(@D)/include/configs/$(UBOOT_BOARD_NAME).h)
I prefer the following idiom:
ifeq ($(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG),y)
define UBOOT_COPY_CUSTOM_CONFIG_FILE
...
endef
endif
define UBOOT_CONFIGURE_CMDS
$(UBOOT_COPY_CUSTOM_CONFIG_FILE) ...
Peter, please confirm?
Also, I don't like the -f option of cp much because most people don't
know what it means. And finally, I really wouldn't give it a -p. Actually, if it's not recursive, we usually use $(INSTALL). Therefore:
ifeq ($(BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG),y)
define UBOOT_COPY_CUSTOM_CONFIG_FILE
(INSTALL) -m 0644 $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE)) \ $(@D)/include/configs/$(UBOOT_BOARD_NAME).h)
endef
endif
And finally, to completely defuse Thomas's remarks, you could put the
following in the commit log.
"""
Add an option BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE that makes it possible to override the configuration options in the board header file. This avoids the need for manipulating the board header file with sed hacks like is currently done for the BR2_TARGET_UBOOT_NETWORK settings.
Note that this option does not make it possible to add a new board to U-Boot. That still has to be done by patching the source. """
Regards,
Arnout
Quoted 4 lines
boot/uboot/uboot.mk +0
-0$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) \ $(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) \ $(UBOOT_BOARD_NAME)_config
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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F