Kconfig: add CONFIG_BOARD_REVISION

[mbolivar-nordic]

Propagate the board revision to Kconfig via the environment.

An alternative to: #44131

[mbolivar-nordic]

To try it out, do something like this:

$ west build --cmake-only -p -b nrf9160dk_nrf9160@0.7.0 samples/hello_world/
$ grep BOARD_REVISION build/zephyr/.config
CONFIG_BOARD_REVISION="0.7.0"

Edit: and similarly,

$ west build --cmake-only -p -b nrf52dk_nrf52832 samples/hello_world/
$ grep BOARD_REVISION build/zephyr/.config
CONFIG_BOARD_REVISION=""

[stephanosio]

If we are going to add this as a Kconfig symbol, this would indeed be the correct thing to do.

No strong opinion on whether this should be a Kconfig symbol or just a good old #define BOARD_REVISION; though, I am inclined to say Kconfig is better since you can potentially reuse this to set the defaults for other configs.

[carlescufi]

I like this better.

[nordicjm]

Much simpler and better!

[nashif]

what @stephanosio says...

[mbolivar-nordic]

@nashif I have addressed @stephanosio's comments, including adding a prep work patch moving CONFIG_BOARD to boards/Kconfig to keep everything together.

[tejlmand]

a late arrival comment.
FYI @stephanosio @nashif @carlescufi @mbolivar-nordic

[tejlmand]

@mbolivar-nordic a little late to the game.

I'm sure this is useful but did you notice the fact that the BOARD Kconfig setting is not passed through the environment, but set in the board's Kconfig.

The result of that is that the BOARD value in Kconfig != BOARD value passed to CMake, see for example:

zephyr/boards/arm/nrf5340dk_nrf5340/Kconfig.defconfig

Lines 8 to 9 in a57dee9

	config BOARD
	default "nrf5340dk_nrf5340_cpuapp" if BOARD_NRF5340DK_NRF5340_CPUAPP || BOARD_NRF5340DK_NRF5340_CPUAPP_NS

This means that user can fetch the revision for the board given with -DBOARD=<board>@<rev>, but the board available in Kconfig may not be the same board, for example:
-DBOARD=nrf5340dk_nrf5340_cpuapp_ns@1.2.3 results in:

• CONFIG_BOARD == nrf5340dk_nrf5340_cpuapp
• CONFIG_BOARD_REVISION == 1.2.3

so not sure passing revision this way is wise if we don't cleanup and enforce that CONFIG_BOARD is identical to the board provided by the user with -DBOARD.

[mbolivar-nordic]

so not sure passing revision this way is wise if we don't cleanup and enforce that CONFIG_BOARD is identical to the board provided by the user with -DBOARD.

are you aware of any counterexamples? That would indeed seem like a bug in the board defconfig if CONFIG_BOARD ended up different than BOARD (without the revision), wouldn't you agree?

[tejlmand]

are you aware of any counterexamples? That would indeed seem like a bug in the board defconfig if CONFIG_BOARD ended up different than BOARD (without the revision), wouldn't you agree?

@mbolivar-nordic did you look at the code I linked ?

That is exactly the counter example you are requesting.

A user specifying -DBOARD=nrf5340dk_nrf5340_cpuapp_ns@0.1.2 will have the BOARD = nrf5340dk_nrf5340_cpuapp_ns in CMake, but as BOARD = nrf5340dk_nrf5340_cpuapp in Kconfig, that is without _ns in Kconfig.