Re: SOC_DIR not populated

Rasmussen, Torsten



I have retested the functionality by relocating SoCs from ${ZEPHYR_BASE}/soc into modules, and this worked as expected.

Both when using `zephyr/module.yml` and `-DSOC_ROOT=<path>`.


So I took one more look at your folder structure and compared to the code, and I noticed you wrote:

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

I notice that both the folder `product` and the files Kconfig.* has `---` (3) dashes in front of them, so I just want to verify that those files are located in the `product` dir and not directly in `arm` dir ?


If they are placed directly in the `arm` dir, then that could explain the behavior, due to this:

osource \"${root}/soc/$(ARCH)/*/Kconfig.defconfig


where you see it will source the files one folder further down from the arch folder.







From: devel@... <devel@...> On Behalf Of Rasmussen, Torsten via
Sent: 6 August, 2020 21:46
To: Dan Kalowsky <dank@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: Re: [Zephyr-devel] SOC_DIR not populated




> Please re-read the original message.  You have a hidden dependency that has been overlooked that causes completely out of tree SOCs to not work.  The setup works fine for in-tree and within the Zephyr source SOCs because of other assumptions in the code.


Seems I was a bit too fast I my reply.



The SOC_DIR shall no longer be exported to Kconfig, cause when Kconfig is executed the first time, then we need ALL soc roots present.

Otherwise we cannot decide the correct SOC to use for the given board.


Thus, a Kconfig file is generated at the build directory here:


and then sourced into Kconfig here:


So the `SOC_DIR` must no longer be exported cause Kconfig cannot hanled a list of dirs..

This is the reason for generating Kconfig files that can then be sourced into Kconfig.


Could you verify the content of:





One question:

> Thus when setting a custom SOC_DIR


Are you setting the `SOC_DIR` yourself ?

The `SOC_DIR` is for the Zephyr build system, the correct way to do this is to set `SOC_ROOT` as described:


as: `cmake -DSOC_ROOT=<path> ….`





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





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

Hi Dan,


Sorry for any trouble the latest changes is causing you.

With it is now possible to provide multiple SoC roots, allowing for greater flexibility.


Please re-read the original message.  You have a hidden dependency that has been overlooked that causes completely out of tree SOCs to not work.  The setup works fine for in-tree and within the Zephyr source SOCs because of other assumptions in the code.



and as you see, the `SOC_DIR` is still populated, but because there can only be a single SOC_DIR, we need to decide on the correct SOC_DIR to use.
To do so, we check for the existence of the SoC under its corresponding arch.


All SoCs in Zephyr are grouped under `soc/${ARCH}/` and this could be the root cause in your case.

Looking again at the code, I suspect you have your SoCs located directly under:




If you can move your SoC into an `${ARCH}` folder, for example:




Then things should work again.



Again, I will encourage you to re-read the original message.  The layout you are requesting to be followed is what has been followed.




If your repo is defined as a Zephyr module, you even have the possibility of adding this into the nodule.yml file:


The values of *_ROOT are all defined in cmake variables.  They have been confirmed to be correctly populated via calls to cmake messages() at the first time of parsing in the boilerplate.cmake file.  If we can focus more on why SOC_DIR is not populated at the time of consumption by kconfig.cmake it would be appreciated. 



Best regards




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




Thanks for the prompt response.  Do please keep me CC'd on this as I am not on the mailing list. 


Torsten the longer version might provide some background context for the debug.  Happy to help where I can.



On Thu, Aug 6, 2020 at 10:40 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Dan,


Assuming you have the latest upstream master, then this might be a regression introduced by:


We are certainly not dropping support for out-of-tree SoCs, in fact we just discussed this recently with Torsten (on copy). He should be able to give more info on the subject.






From: devel@... <devel@...> On Behalf Of Dan Kalowsky via
Sent: 06 August 2020 19:19
To: devel@...
Subject: [Zephyr-devel] SOC_DIR not populated


Hey Zephyr team,


Long time no talk.


Short version:  Using the latest HEAD, I am finding that the kconfig SOC_DIR is not being populated for an out of tree SOC build.  This causes a compilation failure and makes everyone a sad panda.  As this was something that worked perfectly in 2.3 (and for the most part earlier), I was a little surprised to see this no longer working on HEAD.  Was it intentional to remove support for out of tree SOCs, or is this an oversight?  I could not find any documentation supporting either statement in the mailing list or meeting minutes.


Longer version:


I have a Zephyr application with a lot of out of tree pieces.  It kind of looks like the following simplified layout:



- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/




Overall this has worked great in 2.3 (and was functional in 2.2 with some fixes).  Given some of the recent work by Andrew and Tomasz (thanks and hi btw) I was motivated to upgrade to HEAD.  At this point, while building I get informed that the path $(SOC_DIR)/$(ARCH) has some unset variables, which causes the initial setup for cmake/kconfig to fail.  Sure enough, there are empty variables being used.  While investigating, it looks like the current HEAD has three issues for out of tree SOC usage, but I've only been able to "resolve" two of them.  Almost all of it seems to have originated from commit 5f7cc8ded9138b773012b9ffedc744b9475927db.


Issues found:

1) The file cmake/kconfig.cmake no longer sets up to export the SOC_DIR as it used to.  Thus when setting a custom SOC_DIR, nothing is there for the python script to add.  Adding back lines 44 and 88 solves the variables now being set, although the value of SOC_DIR is still nil.  You will need to resolve issue 2 as well to finish this fix.


2) The file cmake/app/boilerplate.cmake has relocated lines of code that set the SOC_DIR variable to a after a section of code that has requirements for them to be set.  Specifically the chunk at 527-541 needs to happen BEFORE the inclusion of kconfig.cmake on line 515.  It is not clear why these lines were moved from the commit or Pull Request, but it does expose a dependency chain that does not seem to be tested/validated in the scripts.  Moving this section alone is not enough, you still need issue 1 resolved for the variables to show up in the script.


3) Even with these changes, which allow me to get further along the compile, there is still one last issue I have not been able to rootcause.   I end up seeing the following error, which appears to munge some of the path:

CMake Error at /home/dkalowsky/product_dev/zephyr/CMakeLists.txt:376 (message):
  Could not find linker script:


Note the // before linker.ld. 


Which brings us to the questions part...


Is Zephyr looking to drop out of tree SOC?  I certainly hope not, but some of the change directions in the commit above give a bit of concern that it might be true.  Note this is tea leaf reading, and I am bad at it.

If not, is there a new layout that should be utilized for out of tree SOC usage?  The documentation still points to the previously existing behavior as being correct.  If it is changing, is there a document that I can reference to update my local application?

If this is all oversight and just bugs, any ideas on what could be causing issue 3?




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



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


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

Join to automatically receive all group messages.