Re: SOC_DIR not populated

Rasmussen, Torsten



Thanks for the confirmation of the patch.

And thanks for the update.


I was waiting for confirmation before sending update on mailing list.


See more comments below.





From: Dan Kalowsky <dank@...>
Sent: 11 August, 2020 0:37
To: Rasmussen, Torsten <Torsten.Rasmussen@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: Re: [Zephyr-devel] SOC_DIR not populated


Sorry for the delay in response, got pulled into other duties and was not able to follow up on this in the immediate time frame.




On Thu, Aug 6, 2020 at 11:27 PM Rasmussen, Torsten <Torsten.Rasmussen@...> wrote:



Find answers inline.

And for convenience, a link to the fix:


Thank you for this PR.  More importantly, thank you for fixing the documentation in the follow up PR and pointing out that this is a breaking change for others.


One additional note that should be added here, when using the files as corrected to build, they fail to find the linker.ld file found in the soc_a in the example.


The fix is to change the arm/product/CMakeLists.txt file like so:


- add_subdirectory(${SOC_SERIES})

+ add_subdirectory(${CONFIG_SOC_SERIES})


This seems to allow everything to work correctly in the compile time frame.  You may want to include that detail as well if it is correct.  Note the demo repo needs to be cleaned up to compile anything at all, don't trust it.  This seems odd because I believed that Zephyr dropped the CONFIG_ prefix from everything internally before using it, yet in this case the variable has data only when prefixed.


No, all Kconfig settings in CMake must be accessed using `CONFIG_<name>`.
Only the `SOC_SERIES` is a little special, as that is copied into a local variable (history goes before my time).

I would discourage using `SOC_SERIES` directly and instead do the proper `CONFIG_SOC_SERIES` but I will not remove `SOC_SERIES` possibility without a good reason, cause users may depend on it.

But using `SOC_SERIES` should work for files included as part of Zephyr CMake boilerplate (everything that is happening as part of `find_package(Zephyr)`).

Which is the case for `SOC_ROOT/arch/soc` included CMake files.


For other usage, such as if a CMakeLists.txt file is included as a `add_subdirectory()` after `find_package(Zephyr)` then `SOC_SERIES` cannot be used due to CMake scoping, and `CONFIG_SOC_SERIES` must be used.

That has not changed, so I would like to know how you get those CMake files included, to understand if there is an issue hidden somewhere.

This should not have changed behavior with the changes introduced by .


I had no problem with linking when building for nrf52840dk_nrf52840 board, but I had to set `import:true` in the west.yml to get Nordic hal headers.

But you might be looking at code that you have not pushed to the repo.

At least I don’t see any board using the `soc_a` SoC.


Ok, a little bit of history.

Originally, all ROOTs where a single root only, including BOARD_ROOT.

Now, this for sure has its limitation, as people would like to be able to specify more than one root in order to support both in- and out-of-tree BOARDS, SOC, DTS, and so on.

So BOARD_ROOT was the first to be cleaned up.


so there has been request for other ROOTs to be extended to support multiple roots.


There are also several users with out-of-tree SoCs, who are using both Zephyr SoCs and out-of-tree SoCs, and everyone must make there own way of ensuring that their SOC_ROOT gets set correctly.

I have seen this as a common approach:

if(BOARD STREQUAL my_custom_soc_board)
  set(BOARD_ROOT some/out/of/tree/soc/path)


Thank you for the history.  From my island, I don't see this as a correct usage/behavior, but I am clearly in the minority. 



Let me know if there are still issues with the linker script location.


See note above.




"Do you expect me to talk?"
"No Mr. Bond, I expect you to die."

Join to automatically receive all group messages.