| Message ID | 1353842534.17518.10.camel@home.hno.se |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
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 -----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-----
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 -----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-----
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