Patchwork [U-Boot,1/2] mkconfig: Make CONFIG_SYS_BOARD_NAME default to the configured target name

login
register
mail settings
Submitter Henrik Nordström
Date Nov. 25, 2012, 11:22 a.m.
Message ID <1353842534.17518.10.camel@home.hno.se>
Download mbox | patch
Permalink /patch/201516/
State Changes Requested
Delegated to: Tom Rini
Headers show

Comments

Henrik Nordström - Nov. 25, 2012, 11:22 a.m.
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(-)
Wolfgang Denk - Nov. 25, 2012, 5:43 p.m.
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
Henrik Nordström - Nov. 25, 2012, 5:55 p.m.
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
Wolfgang Denk - Nov. 25, 2012, 8:01 p.m.
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
Henrik Nordström - Nov. 26, 2012, 8:21 a.m.
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
Wolfgang Denk - Nov. 26, 2012, 9:32 a.m.
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
Tom Rini - Nov. 26, 2012, 9:05 p.m.
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?
Henrik Nordström - Nov. 26, 2012, 9:41 p.m.
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
Tom Rini - Nov. 26, 2012, 9:51 p.m.
-----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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQs+R7AAoJENk4IS6UOR1WM14P/0ZUEk8E7+Qwmn1aGkXfRZBC
3cN06jWVBfio31Ic1HMJJJNoOsHgGLuV9hRI9Gl0U/9o4pvVLtI6tfIQB0rHdkDr
HYwiAeq6fuJV/HE+oOsEt+DKn/NZsQd3U45TL1oK5A53Bfqh56LDuieqJnZ1FE2F
2G2Bi3VfMaP/Fx4VhIJpDrE3UkWZH4uzkjV7B2BeCfPaY02cEUbIsCYksPAUPxat
E9lXgVYE+HThHPfYVZOcDpf+R3NPwfNqT0y7d256bMmxQW6C6W6sJjK0JsmeEQWm
M+drhxaWXihtQ5pOUxSSgW5XOTbvdtJDA+vVLegPG0fjNKpAJStEsYPy2QJeZEzQ
HtTLX7EPuKk55t+vUVB5k5e6BIT8WUSu2nzxi4N9D6pZgE80DdeTIw6Ez+KfR10x
MiPaFpvLq3db7fzIg2GAoCiNppcimZPSBISRZyrUsZTDyXtsEgDqTqOOAcvmO6lY
9nHIFGAHG4QDW76Y1dW4/KkqI9TIwm6oph31sL/IgmhQ0R0TlwTKxV71ia4jwSOg
qSs3O2qK+LvgNCNqPgeLljRML2PdyoWsA17sTcmsh4Na9B1O0rRFEbFBCAiCZsug
toacIVgySbKdLucCHxcD7vS7IGSioVOsa+fPa7wSlKySLMcBxeooMqxR1+cqXsh7
/Kf4StcSqoMr8I7Mitgy
=uk8l
-----END PGP SIGNATURE-----
Henrik Nordström - Nov. 26, 2012, 10:01 p.m.
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
Tom Rini - Nov. 27, 2012, 2:53 p.m.
-----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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQtNPbAAoJENk4IS6UOR1WdekP/0zlJI6EqkPobNlK4TXgfhmQ
cM6dum2kaTjdDhT3nDjnHKO2JpL2BvXrKvkqPjHqbWDg0lfBS0nXpByDv8/AhoNU
wI3NoYqovjDHc2/GfVY1C+Jy/baQSQgp99KYG8WM1RU4+qvLG6bTvabmVgBjRY4q
TVd+HHyuIwtVsRJFU4dMiuZ9dZU53sj7UZjk7YOD+0ayVuMfl6IBKDpchITJzcT+
biLMfgkNMI83gMR+xy/+QNAplC23+IFTM8bP14trm0reOkhNNcPgLREOthJq91Rm
Y5EsRDzOyy51k5+/Qa+Ectp2W/1i6/Fy7OXVIgF0sgOhuAlCjqH+CzfA1hvieRA1
vHqt5z7wVuQks5y+vEQij8kHrNNOj8WvZxUoMYYBOM2u1xLBnYM0Q67L5ynuJKM4
SNRvbTdK3kzLPD6RRxkLntFe3mJLXZ10F8NMvGWtZN1u3U4mF2g8DdnPYytkmEss
vlgPBWdWrWA47fQ9cqf3uDoW57ozG0Dkk/7fqGElGcJWz3KMiRMYBV0NUgaJSvMu
5VFSQRA9gVN1+bEYxL8l88APWAGM+iM1+uyzKjlk80U4MqISYLQRTme8jzCHMlRX
zGPLEXnolKx7rTyjsUnvTJoZHo86YSXp9deNC4eRtIRm/bEJBlj3tuwguMKtiYfA
yZ7zoPMdW2MHxEpWGuuv
=ttY9
-----END PGP SIGNATURE-----

Patch

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