[U-Boot] [PATCH 1/2] mkconfig: Make CONFIG_SYS_BOARD_NAME default to the configured target name
This change makes CONFIG_SYS_BOARD_NAME globally available as the configured target name, avoiding the need to define manually for boards having multiple targets sharing the same board implementation. --- include/config_fallbacks.h | 4 ++++ mkconfig | 1 + 2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h index bfb9680..a1b2b54 100644 --- a/include/config_fallbacks.h +++ b/include/config_fallbacks.h @@ -26,4 +26,8 @@ #define CONFIG_EXT4_WRITE #endif
+#ifndef CONFIG_SYS_BOARD_NAME +#define CONFIG_SYS_BOARD_NAME CONFIG_SYS_TARGET +#endif + #endif /* __CONFIG_FALLBACKS_H */ diff --git a/mkconfig b/mkconfig index 7c9aa74..ddce037 100755 --- a/mkconfig +++ b/mkconfig @@ -173,6 +173,7 @@ done echo "#define CONFIG_SYS_ARCH "${arch}"" >> config.h echo "#define CONFIG_SYS_CPU "${cpu}"" >> config.h echo "#define CONFIG_SYS_BOARD "${board}"" >> config.h +echo "#define CONFIG_SYS_TARGET "${BOARD_NAME}"" >> config.h
[ "${vendor}" ] && echo "#define CONFIG_SYS_VENDOR "${vendor}"" >> config.h
Dear Henrik Nordström,
In message 1353842534.17518.10.camel@home.hno.se you wrote:
This change makes CONFIG_SYS_BOARD_NAME globally available as the configured target name, avoiding the need to define manually for boards having multiple targets sharing the same board implementation.
include/config_fallbacks.h | 4 ++++ mkconfig | 1 + 2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h index bfb9680..a1b2b54 100644 --- a/include/config_fallbacks.h +++ b/include/config_fallbacks.h @@ -26,4 +26,8 @@ #define CONFIG_EXT4_WRITE #endif
+#ifndef CONFIG_SYS_BOARD_NAME +#define CONFIG_SYS_BOARD_NAME CONFIG_SYS_TARGET +#endif
#endif /* __CONFIG_FALLBACKS_H */ diff --git a/mkconfig b/mkconfig index 7c9aa74..ddce037 100755 --- a/mkconfig +++ b/mkconfig @@ -173,6 +173,7 @@ done echo "#define CONFIG_SYS_ARCH "${arch}"" >> config.h echo "#define CONFIG_SYS_CPU "${cpu}"" >> config.h echo "#define CONFIG_SYS_BOARD "${board}"" >> config.h +echo "#define CONFIG_SYS_TARGET "${BOARD_NAME}"" >> config.h
I don't see what the difference is between CONFIG_SYS_BOARD (which is the board name) and CONFIG_SYS_BOARD_NAME ?
In any case, documentation for CONFIG_SYS_BOARD_NAME is missing.
Best regards,
Wolfgang Denk
sön 2012-11-25 klockan 18:43 +0100 skrev Wolfgang Denk:
echo "#define CONFIG_SYS_BOARD "${board}"" >> config.h +echo "#define CONFIG_SYS_TARGET "${BOARD_NAME}"" >> config.h
I don't see what the difference is between CONFIG_SYS_BOARD (which is the board name) and CONFIG_SYS_BOARD_NAME ?
CONFIG_SYS_BOARD is the board config name, which may differ from the board name given to make.
CONFIG_SYS_BOARD_NAME is set to the name in boards.cfg.
To illustrate using existing boards in boards.cfg look at for example the spear boards.
spear300 arm arm926ejs spear300 spear spear spear3xx_evb:spear300 spear300_nand arm arm926ejs spear300 spear spear spear3xx_evb:spear300,nand [...] spear320_usbtty_nand arm arm926ejs spear320 spear spear spear3xx_evb:spear320,usbtty,nand
CONFIG_SYS_BOARD is spear3xx_evb on all 16 of these as they are the same "board" with only different CONFIG_.. parameters set via boards.cfg.
CONFIG_SYS_BOARD_NAME is the first column, unique on each.
In any case, documentation for CONFIG_SYS_BOARD_NAME is missing.
This should go in README?
Regards Henrik
Dear Henrik Nordström,
In message 1353866129.28559.50.camel@home.hno.se you wrote:
I don't see what the difference is between CONFIG_SYS_BOARD (which is the board name) and CONFIG_SYS_BOARD_NAME ?
CONFIG_SYS_BOARD is the board config name, which may differ from the board name given to make.
CONFIG_SYS_BOARD_NAME is set to the name in boards.cfg.
To illustrate using existing boards in boards.cfg look at for example the spear boards.
spear300 arm arm926ejs spear300 spear spear spear3xx_evb:spear300 spear300_nand arm arm926ejs spear300 spear spear spear3xx_evb:spear300,nand [...] spear320_usbtty_nand arm arm926ejs spear320 spear spear spear3xx_evb:spear320,usbtty,nand
CONFIG_SYS_BOARD is spear3xx_evb on all 16 of these as they are the same "board" with only different CONFIG_.. parameters set via boards.cfg.
CONFIG_SYS_BOARD_NAME is the first column, unique on each.
I think you should avoid doing that. It's ugly, and I see no real advantages for it.
In any case, documentation for CONFIG_SYS_BOARD_NAME is missing.
This should go in README?
Yes.
Best regards,
Wolfgang Denk
sön 2012-11-25 klockan 21:01 +0100 skrev Wolfgang Denk:
I think you should avoid doing that. It's ugly, and I see no real advantages for it.
Avoid using the same board config file for multiple boards even when they differ only in one config parameter or in the SoC model mounted on the board?
Regards Henrik
Dear Henrik Nordström,
In message 1353918095.10834.9.camel@home.hno.se you wrote:
sön 2012-11-25 klockan 21:01 +0100 skrev Wolfgang Denk:
I think you should avoid doing that. It's ugly, and I see no real advantages for it.
Avoid using the same board config file for multiple boards even when they differ only in one config parameter or in the SoC model mounted on the board?
No. Avoid introducing yet another CONFIG_SYS_*_NAME.
Best regards,
Wolfgang Denk
On Mon, Nov 26, 2012 at 10:32:41AM +0100, Wolfgang Denk wrote:
Dear Henrik Nordstr??m,
In message 1353918095.10834.9.camel@home.hno.se you wrote:
s??n 2012-11-25 klockan 21:01 +0100 skrev Wolfgang Denk:
I think you should avoid doing that. It's ugly, and I see no real advantages for it.
Avoid using the same board config file for multiple boards even when they differ only in one config parameter or in the SoC model mounted on the board?
No. Avoid introducing yet another CONFIG_SYS_*_NAME.
I think part of the solution is that in the environment now we have board_name for the unique run-time-determined board we are on (which defaults to CONFIG_SYS_BOARD). In each of these Allwiner SoCs do we have the ability to tell at run-time what we are on, or only build-time?
mån 2012-11-26 klockan 14:05 -0700 skrev Tom Rini:
I think part of the solution is that in the environment now we have board_name for the unique run-time-determined board we are on (which defaults to CONFIG_SYS_BOARD). In each of these Allwiner SoCs do we have the ability to tell at run-time what we are on, or only build-time?
Only build-time. There is no hardware board ID of any kind on the boards. But it mostly matters for SPL to know you have the right SPL for the board, and cosmetics to have main u-boot report the right board model (not important).
But the more I think about it I think we will move all the important board parameters to a configuration header added to the SPL binary image, and we will then also add board name there. There is simply too many boards needing slightly different parameters but almost the same.
Regards Henrik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/26/12 16:41, Henrik Nordström wrote:
mån 2012-11-26 klockan 14:05 -0700 skrev Tom Rini:
I think part of the solution is that in the environment now we have board_name for the unique run-time-determined board we are on (which defaults to CONFIG_SYS_BOARD). In each of these Allwiner SoCs do we have the ability to tell at run-time what we are on, or only build-time?
Only build-time. There is no hardware board ID of any kind on the boards. But it mostly matters for SPL to know you have the right SPL for the board, and cosmetics to have main u-boot report the right board model (not important).
But the more I think about it I think we will move all the important board parameters to a configuration header added to the SPL binary image, and we will then also add board name there. There is simply too many boards needing slightly different parameters but almost the same.
This is why, sooner rather than later I believe, we need to come up with a good way to pass device trees in and around, asap. An SPL that contains a device tree for the correct board (and passes along to U-Boot which could in turn pass along to the kernel if it's a full tree) would solve your problem, yes?
- -- Tom
mån 2012-11-26 klockan 16:51 -0500 skrev Tom Rini:
This is why, sooner rather than later I believe, we need to come up with a good way to pass device trees in and around, asap. An SPL that contains a device tree for the correct board (and passes along to U-Boot which could in turn pass along to the kernel if it's a full tree) would solve your problem, yes?
Yes, if it can be made to fit. The SPL have to fit within 24KB code+data and we are already at 20KB for the MMC/SD version. Size still unknown for NAND SPL with the MTD driver still in very early stages. Can probably shave off a fair bit by removing console output from the SPL but prefer not to.
Regards Henrik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/26/12 17:01, Henrik Nordström wrote:
mån 2012-11-26 klockan 16:51 -0500 skrev Tom Rini:
This is why, sooner rather than later I believe, we need to come up with a good way to pass device trees in and around, asap. An SPL that contains a device tree for the correct board (and passes along to U-Boot which could in turn pass along to the kernel if it's a full tree) would solve your problem, yes?
Yes, if it can be made to fit. The SPL have to fit within 24KB code+data and we are already at 20KB for the MMC/SD version. Size still unknown for NAND SPL with the MTD driver still in very early stages. Can probably shave off a fair bit by removing console output from the SPL but prefer not to.
It should all be doable, even from MMC/SD, with that size limitation. The only issue might be that we would want to use a small initial device tree and merge or replace with a full tree we read off of MMC/SD (or NAND or whatever).
- -- Tom
participants (3)
-
Henrik Nordström -
Tom Rini -
Wolfgang Denk