Target Capabilities / Board Directory Layout Capabilities

[galak]

Starting this thread to discuss what features we want to support based on the layout of the boards directory.

Today we support/assume:

1. <BOARD> is expected to match a <BOARD>_defconfig in boards/<ARCH>/<BOARD_DIR_NAME>
2. Determining the ARCH of the board based on the directory path (its assumed that boards/<ARCH>/<BOARD_DIR_NAME> is the layout
3. <ARCH> is assumed as the direct parent of <BOARD_DIR_NAME>
   [ I want the assumption of 3. to be that <ARCH> is the name right before "boards" - See PR cmake: prework towards supporting board groups #12377 ]

[galak]

• Want to support grouping of boards that are 'common' (typically same board vendor) that would share code between the board (might be DTS files, might be actual .c/.h files)

[SebastianBoe]

I want the assumption of 3. to be that <ARCH> is the name right before "boards"

You mean that you want ARCH to be the direct subdirectory of "boards", right? So, ARCH is after "boards" in a path, not before, or?

[carlescufi]

@SebastianBoe right, so:

boards/<arch>[/<family>]/<board name>

[carlescufi]

My take on this is that we should enforce the layout described below:

boards/<arch>[/<family>][/<sub-family>].../<board name>

So that we ensure that ARCH is always located after boards/ and BOARD_DIR_NAME is the leaf of the hierarchy above.

[pabigot]

One thing I understood @nashif to want is standardized names for things other than boards.

I would like dts as a standard name to be used within (sub-)family directories to hold device-tree source include files shared among members of the (sub-)family. This allows me to support #12195 with this technique.

It may be appropriate to expect this to be located immediately below boards/<arch>/<family> so that the include path is always "<family>/dts/[/sub-family].../<dtsi>". This is consistent with the top-level ${ZEPHYR_BASE}/dts directory.

There may be other directories to hold Kconfig fragments and other things that aren't device tree; I can't propose names for them.

[galak]

My take on this is that we should enforce the layout described below:

boards/<arch>[/<family>][/<sub-family>].../<board name>

So that we ensure that ARCH is always located after boards/ and BOARD_DIR_NAME is the leaf of the hierarchy above.

Does or have any particular definition, or you thinking its completely up to the user (which is my current thought)?

[galak]

One thing I understood @nashif to want is standardized names for things other than boards.

I would like dts as a standard name to be used within (sub-)family directories to hold device-tree source include files shared among members of the (sub-)family. This allows me to support #12195 with this technique.

It may be appropriate to expect this to be located immediately below boards/<arch>/<family> so that the include path is always "<family>/dts/[/sub-family].../<dtsi>". This is consistent with the top-level ${ZEPHYR_BASE}/dts directory.

There may be other directories to hold Kconfig fragments and other things that aren't device tree; I can't propose names for them.

I was thinking we'd leave the structure of where to find such files unspecified. We would add -isystem ${ZEPHYR_BASE}/boards/${ARCH} to the search path for DTS.

[carlescufi]

Does or have any particular definition, or you thinking its completely up to the user (which is my current thought)?

Up to the user. I don't think we can mandate clear rules, it really is difficult and depends on the particular board family.

[carlescufi]

Conclusion from the development meeting today: not solved yet, for now we keep the boards/<arch>/<board name> layout until the board structure is discussed in more detail.
Common device tree files need to be copied to each board folder.

[galak]

I'm expanding this to include "target" capabilities as well.

@agross-linaro and I had a discussion around what was needed for secure/non-secure (TEE) and figured this all played together.

The idea we had was around defining what specifies a TARGET. What we have today is:

TARGET:

• BOARD (required)
• SHIELD (optional) [should support multiple]
• CORE (optional, but for cases of AMP, so M0/M4 for something like lpcxpresso54114, or for something like ARDUINO_101 x86/arc) [needs flushing out on naming convention]
• TEE (optional, SECURE or NON_SECURE) /* TEE - Trusted Execution Environment */

[galak]

• SHIELD (optional) [should support multiple]

@nashif and @MaureenHelm gave example of CORE on a SHIELD (example is KW41Z "shield")

Also, example of Quark SE C1000 Dev board:

https://docs.zephyrproject.org/latest/boards/x86/quark_se_c1000_devboard/doc/board.html

[nashif]

illustration:

[mbolivar]

• TEE (optional, SECURE or NON_SECURE) /* TEE - Trusted Execution Environment */

Will that scale?

[nashif]

closing in favor of #51831