Board revision Kconfigs in child_image/ACI_NAME folder not working

[anthony32086]

Per the documentation on multi image builds, a child image folder that contains a <board>_<revision>.overlay it will be merged with BOARD.dts but I cannot do the same for Kconfig fragments such as <board>_<revision>.conf

The only way I have found to make this "work" is by making a child_image/<ACI_NAME>/boards/<board>_<revision>.conf but then the default child image prj.conf is not loaded. The current workaround is to copy paste the prj.conf from the child image into child_image/<ACI_NAME> but this is not desired as changes to the child image are not automatically propogated when the SDK is updated.

Is there another solution to this

[Torsten Rasmussen]

Hi anthony32086 

It seems this is a small flaw in the documentation.

Revision specific Kconfig fragments are indeed sourced and follows the pattern for regular board specific fragments without the revision part.
But it follow this pattern:

  # <current-sample> DIRECTORY
  # | - prj.conf
  # | - child_image DIRECTORY
  #     |-- <ACI_NAME> DIRECTORY
  #         |-- boards DIRECTORY
  #         |   |-- <board>.conf (E)            If present, use instead of (C), requires (G).
  #         |   |-- <board>_<rev>.conf          If present, use instead of (C), used in addition to (E) if present
  #         |                                   requires (G).
  #         |-- prj.conf (G) If present, use instead of (A)

which follows your observation.

This comes back to a design decision, and the reason for this is to make it clearer from where configurations are picked up.

Allowing the principle you propose also makes sense, but it becomes harder to predict from where given configurations are being picked up, and as result of this more confusion and thus support is the risk.

Basically, the design is:

• Simple case: Users are mostly fine with the original child image configurations and like to make general adjustments.
  A single `<ACI-name>.conf is allowed in this case.
• Complex case: Users need to do child image and/or board specific adjustments.
  Give user full control of all configuration of the child image. Do not inherit anything.

Therefore child_image only allows a single Kconfig and board independent fragment to be used in addition to the child image default config, that is:

 # <current-sample> DIRECTORY
 # | - prj.conf
 # | - child_image DIRECTORY
 #     |-- <ACI_NAME>.conf (I) Fragment, used together with (A) and (C)

if you really want to follow the pattern you desire, then an alternative is to use the `APPLICATION_CONFIG_DIR`.

For an example, see `nrf_desktop`.

Each board has it's own configuration folder.

https://github.com/nrfconnect/sdk-nrf/tree/main/applications/nrf_desktop/configuration

This again means that the `<ACI_NAME>.conf` effectively becomes board dependent as each image configuration is board specific.

https://github.com/nrfconnect/sdk-nrf/blob/cbe9f34d72abc3fb03ca2810641e8bf539bc2c4a/applications/nrf_desktop/CMakeLists.txt#L19-L20