Allow device-tree compiler know SoC and CPU used

[KozhinovAlexander]

This pull request introduces logic to automatically extract and use board qualifiers from the BOARD_QUALIFIERS variable in CMake. If BOARD_QUALIFIERS matches a specific pattern, it splits the value and sets preprocessor flags for the SOC and CPU, making the build process more dynamic and configurable.

Enhancements to board qualifier handling:

• Added logic to detect if BOARD_QUALIFIERS contains both SOC and CPU information (in the format SOC/CPU), splits them, converts them to uppercase, and appends corresponding preprocessor flags to DTS_EXTRA_CPPFLAGS.Allow device-tree compiler know SoC and CPU used.

With this change device-tree compiler will become information about SoC variant and CPU being used during generation of defines from device-tree.
This change is advantageous, because it shall allow usage of C-preprocessor directives within .dts/.dtsi files s.t. following form of includes becomes possible:

#if defined(DTS_CPU_M7)
#include <a/path/to/file/with/cortex_m7_defines>
#endif

// or

#if defined(DTS_SOC_STM32H745XX)
#include <a/path/to/file/with/stm32h745xx_defines>
#elif defined(DTS_SOC_STM32G4XX)
#include <a/path/to/file/with/stm32g4xx_defines>
#endif

Testing could be done with similiar patch:

diff --git a/dts/arm/st/h7/stm32h745Xi_m7.dtsi b/dts/arm/st/h7/stm32h745Xi_m7.dtsi
index 0e79c0150f3..bc554307bba 100644
--- a/dts/arm/st/h7/stm32h745Xi_m7.dtsi
+++ b/dts/arm/st/h7/stm32h745Xi_m7.dtsi
@@ -7,6 +7,14 @@
 #include <mem.h>
 #include <st/h7/stm32h745.dtsi>
 
+#if defined(DTS_CPU_M7)
+#warning "Defined DTS_CPU_M7"
+#endif
+
+#if defined(DTS_SOC_STM32H745XX)
+#warning "Defined DTS_SOC_STM32H745XX"
+#endif
+
 /delete-node/ &flash1;
 
 / {

[Copilot]

Pull Request Overview

This pull request adds automatic extraction of SOC and CPU information from the BOARD_QUALIFIERS CMake variable to provide preprocessor definitions for device tree compilation. The change enables conditional compilation in device tree files using SOC and CPU-specific preprocessor directives.

• Parses BOARD_QUALIFIERS when it matches the pattern "SOC/CPU" format
• Extracts and converts SOC and CPU names to uppercase for preprocessor flags
• Appends -DDTS_SOC_<name> and -DDTS_CPU_<name> flags to DTS_EXTRA_CPPFLAGS

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Incorrect list indices used for extracting SOC and CPU names. For a string 'SOC/CPU' split by '/', the SOC should be at index 0 and CPU at index 1, not indices 1 and 2.

Suggested change

	list(GET BOARD_QUALIFIERS_LIST 1 SOC_NAME)
	list(GET BOARD_QUALIFIERS_LIST 2 CPU_NAME)
	list(GET BOARD_QUALIFIERS_LIST 0 SOC_NAME)
	list(GET BOARD_QUALIFIERS_LIST 1 CPU_NAME)

[decsny]

I am not sure this is needed, it seems like a messy bandaid for some platform that has a bad #include hierarchy. You shouldn't need to know the target with macros because your base DTS should only be pulling in DTSI that are valid for that target, and those should only pull in valid ones, etc. This is going to make a giant incomprehensible mess of DTS files if people start #ifdef'ing includes instead of properly #include'ing the right things in the first place. If you need help fixing your platform #includes see my suggestion on #95577 and another example on dba69f3

[KozhinovAlexander]

@decsny Thank you for your comment.
You're right about right include structure especially from vendor's drivers.
Your approach with correct include structure expects vendors to change their driver's include structure completely, which either may take lot of time or lot of effort.
As you already mentioned the DTS compiler will be executed on the the correct board qualifiers, which is currently done anyway implicitly. I am only proposing this information to be passed to dts compiler explicit.

[decsny]

@decsny Thank you for your comment. You're right about right include structure especially from vendor's drivers. Your approach with correct include structure expects vendors to change their driver's include structure completely, which either may take lot of time or lot of effort. As you already mentioned the DTS compiler will be executed on the the correct board qualifiers, which is currently done anyway implicitly. I am only proposing this information to be passed to dts compiler explicit.

And I am saying, what you are proposing is a vehicle to add technical debt of confusing DTSI configuring and include paths. I think this would also make things very difficult on tools that a lot of people have for IDEs and DT shells and whatnot to figure out the correct configurations, because adding #ifdef around #includes will cause just exponential complications is my bet. I don't know, but I just don't want to see #ifdef around including DTSI files. If somebody needs to rework their DTSI because they did it improperly, then that's what they have to do, I don't want to add a mechanism to keep piling on that debt, it's not the right solution.

[KozhinovAlexander]

@decsny Thank you for your comment. You're right about right include structure especially from vendor's drivers. Your approach with correct include structure expects vendors to change their driver's include structure completely, which either may take lot of time or lot of effort. As you already mentioned the DTS compiler will be executed on the the correct board qualifiers, which is currently done anyway implicitly. I am only proposing this information to be passed to dts compiler explicit.

And I am saying, what you are proposing is a vehicle to add technical debt of confusing DTSI configuring and include paths. I think this would also make things very difficult on tools that a lot of people have for IDEs and DT shells and whatnot to figure out the correct configurations, because adding #ifdef around #includes will cause just exponential complications is my bet. I don't know, but I just don't want to see #ifdef around including DTSI files. If somebody needs to rework their DTSI because they did it improperly, then that's what they have to do, I don't want to add a mechanism to keep piling on that debt, it's not the right solution.

Thank you. I understand your opinion and also agree - making less technical debt is always the best choice. I just had the idea I see best match between implementation time and yield it brings.
Maybe someone else with deep Zephyr knowledge would give here a comment too? Having multiple references is always good.

[decsny]

maybe @dottspina can comment about how this might affect toolings since he is the author and maintainer of DTSH

[nordicjm]

this is not at all how things are meant to work and is going to completely break in future e.g. if SIP support is merged, a dts file should have no knowledge of the soc

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tejlmand]

I just had the idea I see best match between implementation time and yield it brings.

which is a reasonable goal.
But the problem with this PR is that it will set a precedence and allow new SoCs / boards to use a broken pattern, thus it will add to our tech debt and not help us reduce it.

Plus, once introduced, then it will be harder to deprecate and remove again when users, especially downstream, will be depending on this possibility.

[KozhinovAlexander]

@decsny @nordicjm @tejlmand I see clear no with reasonable arguments. Therefore I will close this PR. Thank you all for your time and review.