1. devel@lists.zephyrproject.org
   Date   
Re: SOC_DIR not populated

Rasmussen, Torsten
 

Hi,

 

Find answers inline.

And for convenience, a link to the fix: https://github.com/dkalowsk/broked_zephyr/pull/1

 

/torsten

 

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

 

Trying to respond to both replies in the same email here...

 

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

Hi,

 

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 ?

 

> Sorry if the crudely generated ascii art was not clear enough.  The Kconfig* files are in the product directory.

 

No problem. Just wanted to rule out any such issues.

 

 

 

> 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.

 

> I will not claim to know what problem you were encountering or trying to solve.  From my limited viewpoint, the above statement feels like it is based on an incorrect assumption. 

> If, as the application developer, I provide an SOC_ROOT value, I do not care about any of the other possible soc directories that can be encountered.

> The code for the soc I want selected and used is in the directory I specified by setting the SOC_ROOT value.  Again, I do not know what issue you were trying to solve

> (it was not clear to me from the pull request) or where the new functionality is needed, but I do ask that you please not break the behavior that has been working for sometime in 2.2 and 2.3.

 

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.

https://github.com/zephyrproject-rtos/zephyr/pull/10267

 

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

https://github.com/zephyrproject-rtos/zephyr/issues/25215

 

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)
endif()

 

With https://github.com/zephyrproject-rtos/zephyr/pull/26715 all ROOTs have been unified on how they are used.

Also, the Zephyr module `module.yml` file has been updated to support those roots directly.

 

This allows to place SoCs out-of-tree in a common way and have that SoC available together with all other SoCs.

 

I have posted a fix for your code here:

https://github.com/dkalowsk/broked_zephyr/pull/1

 

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

 

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

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/kconfig.cmake#L9-L22

 

and then sourced into Kconfig here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L6

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L11

 

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.

 

I agree that Kconfig cannot handle a list of dirs.  That was not a problem previously, as a SOC_DIR was selected BEFORE kconfig was called to generate everything.  By moving the selection of the SOC_DIR to a later position in the code, specifically after including the kconfig.cmake file, you introduce the problem you cite.  From my examination, there appears to be no technical reason for the relocation of the code to select the SOC_DIR. 

 

 Could you verify the content of:

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.defconfig

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.arch

 

> I'll do one better.  You may recreate the issue yourself and validate all the data you want.

> 

> 

> This will not ever compile as I have hastily thrown together bits from the Zephyr tree and wrote some quick hackish kconfigs. 

> Those typos and errors are not of interest to fix for this discussion.  But this does re-create the error I am raising in parsing

> the kconfig files even on just running menuconfig.  See the README for details on the steps needed to reproduce it.

 

Thanks. Much easier to spot the issue, and others can see the fix if they have a similar setup.

https://github.com/dkalowsk/broked_zephyr/pull/1

 

 

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:

https://docs.zephyrproject.org/latest/application/index.html#soc-definitions

 

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

 

> That would be a typo on my part.  Everything is set via the *_ROOT values, set in the application/src/CMakeLists.txt file. 

 

Also what I assumed.

But good to get such things ruled out early.

 

 

 

/torsten

 

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

 

Torsten,

 

 

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 https://github.com/zephyrproject-rtos/zephyr/pull/26715 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:

```

${YOUR_PRIVATE_REPO}/soc/your_soc

```

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

```

${YOUR_PRIVATE_REPO}/soc/arm/your_soc

```

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:

https://docs.zephyrproject.org/latest/guides/modules.html#build-settings

 

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

 

Torsten

 

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

 

Charles,

 

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."



--

"Do you expect me to talk?"
"No Mr. Bond, I expect you to die."
Re: SOC_DIR not populated

Dan Kalowsky <dank@...>
 

Trying to respond to both replies in the same email here...

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

Hi,

 

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 ?


Sorry if the crudely generated ascii art was not clear enough.  The Kconfig* files are in the product directory.
 

 

> 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.


I will not claim to know what problem you were encountering or trying to solve.  From my limited viewpoint, the above statement feels like it is based on an incorrect assumption.  If, as the application developer, I provide an SOC_ROOT value, I do not care about any of the other possible soc directories that can be encountered.  The code for the soc I want selected and used is in the directory I specified by setting the SOC_ROOT value.  Again, I do not know what issue you were trying to solve (it was not clear to me from the pull request) or where the new functionality is needed, but I do ask that you please not break the behavior that has been working for sometime in 2.2 and 2.3.
 

 

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

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/kconfig.cmake#L9-L22

 

and then sourced into Kconfig here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L6

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L11

 

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.


I agree that Kconfig cannot handle a list of dirs.  That was not a problem previously, as a SOC_DIR was selected BEFORE kconfig was called to generate everything.  By moving the selection of the SOC_DIR to a later position in the code, specifically after including the kconfig.cmake file, you introduce the problem you cite.  From my examination, there appears to be no technical reason for the relocation of the code to select the SOC_DIR. 
 

 Could you verify the content of:

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.defconfig

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.arch


I'll do one better.  You may recreate the issue yourself and validate all the data you want.


This will not ever compile as I have hastily thrown together bits from the Zephyr tree and wrote some quick hackish kconfigs.  Those typos and errors are not of interest to fix for this discussion.  But this does re-create the error I am raising in parsing the kconfig files even on just running menuconfig.  See the README for details on the steps needed to reproduce it.

 

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:

https://docs.zephyrproject.org/latest/application/index.html#soc-definitions

 

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


That would be a typo on my part.  Everything is set via the *_ROOT values, set in the application/src/CMakeLists.txt file. 


 

 

/torsten

 

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

 

Torsten,

 

 

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 https://github.com/zephyrproject-rtos/zephyr/pull/26715 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:

```

${YOUR_PRIVATE_REPO}/soc/your_soc

```

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

```

${YOUR_PRIVATE_REPO}/soc/arm/your_soc

```

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:

https://docs.zephyrproject.org/latest/guides/modules.html#build-settings

 

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

 

Torsten

 

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

 

Charles,

 

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."



--
"Do you expect me to talk?"
"No Mr. Bond, I expect you to die."
Re: SOC_DIR not populated

Rasmussen, Torsten
 

Hi,

 

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.

 

/torsten

 

 

 

 

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

 

Hi,

 

> 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:

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/kconfig.cmake#L9-L22

 

and then sourced into Kconfig here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L6

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L11

 

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:

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.defconfig

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.arch

 

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:

https://docs.zephyrproject.org/latest/application/index.html#soc-definitions

 

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

 

 

/torsten

 

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

 

Torsten,

 

 

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 https://github.com/zephyrproject-rtos/zephyr/pull/26715 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:

```

${YOUR_PRIVATE_REPO}/soc/your_soc

```

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

```

${YOUR_PRIVATE_REPO}/soc/arm/your_soc

```

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:

https://docs.zephyrproject.org/latest/guides/modules.html#build-settings

 

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

 

Torsten

 

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

 

Charles,

 

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."
Re: SOC_DIR not populated

Dan Kalowsky <dank@...>
 

Torsten,


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 https://github.com/zephyrproject-rtos/zephyr/pull/26715 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:

```

${YOUR_PRIVATE_REPO}/soc/your_soc

```

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

```

${YOUR_PRIVATE_REPO}/soc/arm/your_soc

```

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:

https://docs.zephyrproject.org/latest/guides/modules.html#build-settings


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

 

Torsten

 

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

 

Charles,

 

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."
Converting Linux drivers to zephyr

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,
I am looking for help/hints/directions/advice regarding converting Linux device drivers to zephyr? I am mostly interested in sensors.
I would appreciate the input of anyone with experience doing this. A general conversion "recipe" would be very helpful to many, I think.
Kind regards
Abderrezak
Re: SOC_DIR not populated

Dan Kalowsky <dank@...>
 

Charles,

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."
Re: SOC_DIR not populated

Rasmussen, Torsten
 

Hi,

 

> 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:

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/kconfig.cmake#L9-L22

 

and then sourced into Kconfig here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L6

https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/Kconfig#L11

 

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:

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.defconfig

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc

${CMAKE_BINARY_DIR}/Kconfig/Kconfig.soc.arch

 

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:

https://docs.zephyrproject.org/latest/application/index.html#soc-definitions

 

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

 

 

/torsten

 

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

 

Torsten,

 

 

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 https://github.com/zephyrproject-rtos/zephyr/pull/26715 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:

```

${YOUR_PRIVATE_REPO}/soc/your_soc

```

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

```

${YOUR_PRIVATE_REPO}/soc/arm/your_soc

```

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:

https://docs.zephyrproject.org/latest/guides/modules.html#build-settings

 

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

 

Torsten

 

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

 

Charles,

 

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."
Re: SOC_DIR not populated

Rasmussen, Torsten
 

Note, I will also look into a fix that allows out of tree socs to be located directly under the `${SOC_ROOT}/soc` folder.

 

/torsten

 

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

 

Hi Dan,

 

Sorry for any trouble the latest changes is causing you.

With https://github.com/zephyrproject-rtos/zephyr/pull/26715 it is now possible to provide multiple SoC roots, allowing for greater flexibility.

 

This can be seen here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/app/boilerplate.cmake#L543-L548

 

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:

```

${YOUR_PRIVATE_REPO}/soc/your_soc

```

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

```

${YOUR_PRIVATE_REPO}/soc/arm/your_soc

```

Then things should work again.

 

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

https://docs.zephyrproject.org/latest/guides/modules.html#build-settings

 

Best regards

 

Torsten

 

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

 

Charles,

 

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."
Re: SOC_DIR not populated

Rasmussen, Torsten
 

Hi Dan,

 

Sorry for any trouble the latest changes is causing you.

With https://github.com/zephyrproject-rtos/zephyr/pull/26715 it is now possible to provide multiple SoC roots, allowing for greater flexibility.

 

This can be seen here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/app/boilerplate.cmake#L543-L548

 

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:

```

${YOUR_PRIVATE_REPO}/soc/your_soc

```

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

```

${YOUR_PRIVATE_REPO}/soc/arm/your_soc

```

Then things should work again.

 

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

https://docs.zephyrproject.org/latest/guides/modules.html#build-settings

 

Best regards

 

Torsten

 

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

 

Charles,

 

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:

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."
Re: SOC_DIR not populated

Carles Cufi
 

Hi Dan,

 

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

https://github.com/zephyrproject-rtos/zephyr/pull/26715

 

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.

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Dan Kalowsky via lists.zephyrproject.org
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:

 

application/

- board/

- soc/

-- Kconfig

-- arm/

--- product/

--- Kconfig

--- Kconfig.defconfig

--- Kconfig.soc

--- CMakeLists.txt

---- soc_a/

---- soc_b/

- dts/

- src/

zephyr/

modules/

 

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

 

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."
SOC_DIR not populated

Dan Kalowsky <dank@...>
 

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:

application/
- board/
- soc/
-- Kconfig
-- arm/
--- product/
--- Kconfig
--- Kconfig.defconfig
--- Kconfig.soc
--- CMakeLists.txt
---- soc_a/
---- soc_b/
- dts/
- src/
zephyr/
modules/

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 kconfig.py 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:
  '/home/dkalowsky/product_dev/application/soc/arm//linker.ld'.

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."
Zephyr Project: Dev Meeting - Thu, 08/06/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 6 August 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________
Dev-Review Meeting Agenda Aug 6

Kumar Gala
 

Here’s the agenda topics for this week:

* Continue discussion on CONFIG_MULTITHREADING=n
- Do we continue to support it and what functionality should be expected to work in that mode:
https://github.com/zephyrproject-rtos/zephyr/issues/9808
https://github.com/zephyrproject-rtos/zephyr/issues/8393
https://github.com/zephyrproject-rtos/zephyr/issues/26796
https://github.com/zephyrproject-rtos/zephyr/issues/8496

…

https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aissue+is%3Aopen+CONFIG_MULTITHREADING

* Any PR/issues w/dev-review tag
* Any topics anyone else has.

- k
Updated Event: Zephyr: Toolchain Working Group #cal-invite

devel@lists.zephyrproject.org Calendar <devel@...>
 

Zephyr: Toolchain Working Group

When:
Thursday, 13 August 2020
2:00pm to 3:00pm
(UTC+00:00) UTC
Repeats: Every 2 weeks on Thursday, through Thursday, 17 December 2020

Where:
Microsoft Teams Meeting

Organizer: Maureen Helm

An RSVP is requested. Click here to RSVP

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

Calendar
Calendar

RFC: API change - make all device instance constant

Tomasz Bursztyka
 

RFC: API change - Device structure attribute renaming

Tomasz Bursztyka
 

Hello,

I am proposing to rename 3 attributes of struct device.
These attributes names have legacy roots which do not make sense
anymore.

See: https://github.com/zephyrproject-rtos/zephyr/issues/27397

and the proposed PR:
https://github.com/zephyrproject-rtos/zephyr/pull/25798

Tomasz
Re: Latest Progress....[Zephyr-devel] Python Interpreter for Zephyr

Muhammad Muh <muhammad.muh83@...>
 

Hi Mr Jamie, 

Thank you very much for your kind response and helping me. It is requested to please guide me as how to correctly set up the flash storage system for nrf52840 dk. I will be grateful. 

Best Regards.

From: Jamie Mccrae <Jamie.Mccrae@...>
Sent: Wednesday, August 5, 2020 4:12 PM
To: muhammad.muh83@... <muhammad.muh83@...>; Maureen Helm (OSS) <maureen.helm@...>; jrosenth@... <jrosenth@...>
Cc: devel@... <devel@...>
Subject: RE: Latest Progress....[Zephyr-devel] Python Interpreter for Zephyr
 

Hi Muhammad,

Have you enabled the flash storage system and correctly set it up for your module?

Thanks,
Jamie

 

From: devel@... <devel@...> On Behalf Of Muhammad Muh via lists.zephyrproject.org
Sent: 03 August 2020 06:54
To: Maureen Helm (OSS) <maureen.helm@...>; jrosenth@...
Cc: devel@...
Subject: Latest Progress....[Zephyr-devel] Python Interpreter for Zephyr

 

Dear Maureen and Jrosenth,

 

Thank you very much for your kind help. I am using the latest version of Zephyr (as shown in bold in the following code) and also I downloaded the micropython in the Zephyr Project Folder from "git clone https://github.com/micropython/micropython.git". Now I want to run a blink led example to test the Micropython functionality by using the example given in the link "https://github.com/micropython/micropython/tree/master/ports/zephyr". When I run the "make" command I am getting the following error as shown at the end of the following code. Please note I am using nrf52840 dk. Request to please advise.

 

make BOARD=nrf52840dk_nrf52840

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.

Warning: FROZEN_DIR is deprecated in favour of FROZEN_MANIFEST

mkdir -p outdir/nrf52840dk_nrf52840 && cmake -DBOARD=nrf52840dk_nrf52840 -Boutdir/nrf52840dk_nrf52840 -H.

Including boilerplate (Zephyr base): /home/muhammad/zephyrproject/zephyr/cmake/app/boilerplate.cmake

-- Application: /home/muhammad/zephyrproject/micropython/ports/zephyr

-- Zephyr version: 2.3.99 (/home/muhammad/zephyrproject/zephyr)

-- Found Python3: /usr/bin/python3.7 (found suitable exact version "3.7.5") found components: Interpreter

-- Board: nrf52840dk_nrf52840

-- Found toolchain: zephyr (/home/muhammad/zephyr-sdk-0.11.3)

-- Found west: /home/muhammad/.local/bin/west (found suitable version "0.7.2", minimum required is "0.7.1")

-- Found dtc: /home/muhammad/zephyr-sdk-0.11.3/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")

-- Found BOARD.dts: /home/muhammad/zephyrproject/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts

-- Generated zephyr.dts: /home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/zephyr.dts

-- Generated devicetree_unfixed.h: /home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/include/generated/devicetree_unfixed.h

Parsing /home/muhammad/zephyrproject/zephyr/Kconfig

Loaded configuration '/home/muhammad/zephyrproject/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'

Merged configuration '/home/muhammad/zephyrproject/micropython/ports/zephyr/prj.conf'

Configuration saved to '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/.config'

Kconfig header saved to '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/include/generated/autoconf.h'

 

warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but

got the value 'n'. Check these unsatisfied dependencies: (!ENTROPY_HAS_DRIVER) (=n). See

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_TEST_RANDOM_GENERATOR.html and/or look

up TEST_RANDOM_GENERATOR in the menuconfig/guiconfig interface. The Application Development Primer,

Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be

helpful too.

 

-- The C compiler identification is GNU 9.2.0

-- The CXX compiler identification is GNU 9.2.0

-- The ASM compiler identification is GNU

-- Found assembler: /home/muhammad/zephyr-sdk-0.11.3/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc

-- Cache files will be written to: /home/muhammad/.cache/zephyr

-- Configuring done

-- Generating done

-- Build files have been written to: /home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840

make --no-print-directory -C outdir/nrf52840dk_nrf52840 outputexports CMAKE_COMMAND=: >outdir/nrf52840dk_nrf52840/Makefile.export

make -C outdir/nrf52840dk_nrf52840 syscall_list_h_target kobj_types_h_target

make[1]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[3]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Scanning dependencies of target parse_syscalls_target

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 25%] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 50%] Built target parse_syscalls_target

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Scanning dependencies of target syscall_list_h_target

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 75%] Generating include/generated/syscall_dispatch.c, include/generated/syscall_list.h

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[100%] Built target syscall_list_h_target

make[3]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[3]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 66%] Built target parse_syscalls_target

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Scanning dependencies of target kobj_types_h_target

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[100%] Generating include/generated/kobj-types-enum.h, include/generated/otype-to-str.h

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[100%] Built target kobj_types_h_target

make[3]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[1]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.

Warning: FROZEN_DIR is deprecated in favour of FROZEN_MANIFEST

GEN build/genhdr/qstr.i.last

main.c:108:63: error: missing binary operator before token "("

108 | #elif defined(CONFIG_FLASH_MAP) && FLASH_AREA_LABEL_EXISTS(storage)

| ^

make: *** [../../py/mkrules.mk:89: build/genhdr/qstr.i.last] Error 1

make: *** Deleting file 'build/genhdr/qstr.i.last'

 

Best Regards

Links:

You receive all messages sent to this group.

View/Reply Online (#7227) | Reply To Sender | Reply To Group | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [jamie.mccrae@...]

_._,_._,_

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
West v0.7.3 released

Bolivar, Marti
 

Hello,

I'm announcing the release of west v0.7.3.

https://pypi.org/project/west/0.7.3/
https://github.com/zephyrproject-rtos/west/tree/v0.7.3

To upgrade:

Ubuntu: pip3 install --user west==0.7.3
Windows/macoS: pip3 install west==0.7.3

This is a bugfix release from v0.7.2. The main bug fixed causes 'west
update' to fail in some situations when manifest imports are used.

For details about this bug, see:

https://github.com/zephyrproject-rtos/west/pull/415

For details about manifest imports, see:

https://docs.zephyrproject.org/latest/guides/west/manifest.html#manifest-imports

Full commit list since v0.7.2:

Martí Bolívar (5):
conftest: make it more os.PathLike friendly
app: fix import error followed by update
app/project: add missing f for f-string
lint: flake8 fixes
West v0.7.3

Thanks,
Martí
Re: Latest Progress....[Zephyr-devel] Python Interpreter for Zephyr

lairdjm
 

Hi Muhammad,

Have you enabled the flash storage system and correctly set it up for your module?

Thanks,
Jamie

 

From: devel@... <devel@...> On Behalf Of Muhammad Muh via lists.zephyrproject.org
Sent: 03 August 2020 06:54
To: Maureen Helm (OSS) <maureen.helm@...>; jrosenth@...
Cc: devel@...
Subject: Latest Progress....[Zephyr-devel] Python Interpreter for Zephyr

 

Dear Maureen and Jrosenth,

 

Thank you very much for your kind help. I am using the latest version of Zephyr (as shown in bold in the following code) and also I downloaded the micropython in the Zephyr Project Folder from "git clone https://github.com/micropython/micropython.git". Now I want to run a blink led example to test the Micropython functionality by using the example given in the link "https://github.com/micropython/micropython/tree/master/ports/zephyr". When I run the "make" command I am getting the following error as shown at the end of the following code. Please note I am using nrf52840 dk. Request to please advise.

 

make BOARD=nrf52840dk_nrf52840

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.

Warning: FROZEN_DIR is deprecated in favour of FROZEN_MANIFEST

mkdir -p outdir/nrf52840dk_nrf52840 && cmake -DBOARD=nrf52840dk_nrf52840 -Boutdir/nrf52840dk_nrf52840 -H.

Including boilerplate (Zephyr base): /home/muhammad/zephyrproject/zephyr/cmake/app/boilerplate.cmake

-- Application: /home/muhammad/zephyrproject/micropython/ports/zephyr

-- Zephyr version: 2.3.99 (/home/muhammad/zephyrproject/zephyr)

-- Found Python3: /usr/bin/python3.7 (found suitable exact version "3.7.5") found components: Interpreter

-- Board: nrf52840dk_nrf52840

-- Found toolchain: zephyr (/home/muhammad/zephyr-sdk-0.11.3)

-- Found west: /home/muhammad/.local/bin/west (found suitable version "0.7.2", minimum required is "0.7.1")

-- Found dtc: /home/muhammad/zephyr-sdk-0.11.3/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")

-- Found BOARD.dts: /home/muhammad/zephyrproject/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts

-- Generated zephyr.dts: /home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/zephyr.dts

-- Generated devicetree_unfixed.h: /home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/include/generated/devicetree_unfixed.h

Parsing /home/muhammad/zephyrproject/zephyr/Kconfig

Loaded configuration '/home/muhammad/zephyrproject/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'

Merged configuration '/home/muhammad/zephyrproject/micropython/ports/zephyr/prj.conf'

Configuration saved to '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/.config'

Kconfig header saved to '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840/zephyr/include/generated/autoconf.h'

 

warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but

got the value 'n'. Check these unsatisfied dependencies: (!ENTROPY_HAS_DRIVER) (=n). See

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_TEST_RANDOM_GENERATOR.html and/or look

up TEST_RANDOM_GENERATOR in the menuconfig/guiconfig interface. The Application Development Primer,

Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be

helpful too.

 

-- The C compiler identification is GNU 9.2.0

-- The CXX compiler identification is GNU 9.2.0

-- The ASM compiler identification is GNU

-- Found assembler: /home/muhammad/zephyr-sdk-0.11.3/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc

-- Cache files will be written to: /home/muhammad/.cache/zephyr

-- Configuring done

-- Generating done

-- Build files have been written to: /home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840

make --no-print-directory -C outdir/nrf52840dk_nrf52840 outputexports CMAKE_COMMAND=: >outdir/nrf52840dk_nrf52840/Makefile.export

make -C outdir/nrf52840dk_nrf52840 syscall_list_h_target kobj_types_h_target

make[1]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[3]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Scanning dependencies of target parse_syscalls_target

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 25%] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 50%] Built target parse_syscalls_target

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Scanning dependencies of target syscall_list_h_target

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 75%] Generating include/generated/syscall_dispatch.c, include/generated/syscall_list.h

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[100%] Built target syscall_list_h_target

make[3]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[3]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[ 66%] Built target parse_syscalls_target

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Scanning dependencies of target kobj_types_h_target

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[4]: Entering directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[100%] Generating include/generated/kobj-types-enum.h, include/generated/otype-to-str.h

make[4]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

[100%] Built target kobj_types_h_target

make[3]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[2]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

make[1]: Leaving directory '/home/muhammad/zephyrproject/micropython/ports/zephyr/outdir/nrf52840dk_nrf52840'

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.

Warning: FROZEN_DIR is deprecated in favour of FROZEN_MANIFEST

GEN build/genhdr/qstr.i.last

main.c:108:63: error: missing binary operator before token "("

108 | #elif defined(CONFIG_FLASH_MAP) && FLASH_AREA_LABEL_EXISTS(storage)

| ^

make: *** [../../py/mkrules.mk:89: build/genhdr/qstr.i.last] Error 1

make: *** Deleting file 'build/genhdr/qstr.i.last'

 

Best Regards

Links:

You receive all messages sent to this group.

View/Reply Online (#7227) | Reply To Sender | Reply To Group | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [jamie.mccrae@...]

_._,_._,_
RFC: removing eeprom_slave as driver in Zephyr

Peter A. Bigot
 

The eeprom_slave driver accessed under CONFIG_I2C_EEPROM_SLAVE implements the I2C follower (slave) driver API. This device isn't an actual hardware driver: it's a virtual EEPROM that stores data in an instance-specific RAM buffer, with the data exposed on an I2C bus as a I2C follower device that can be controlled by another device acting as a leader (master) on that same bus.

As such it's a reasonable example of how to write an I2C follower driver, but it's not clear that it has a real use in applications: the sole in-tree reference is in the i2c_slave_api test.

Unless this driver has real-world applications I intend to move this from the drivers directory into the source directory for the test that uses it.  Consequently CONFIG_I2C_EEPROM_SLAVE and the device it provided will no longer be supported.

If you have a use for this driver or other concerns about this please comment at: https://github.com/zephyrproject-rtos/zephyr/issues/27303

Peter