|
API meeting agenda: 2020-08-18
Peter A. Bigot
Carles has asked me to stand in for him again in coordinating this week's API telecon.
Topics include:
https://github.com/zephyrproject-rtos/zephyr/pull/25049 on USB include files, which I propose to move from Triage to In Progress.
https://github.com/zephyrproject-rtos/zephyr/pull/27624 which records my recollection of the consensus decision on certain API design policies. Please add comments on the PR.
https://github.com/zephyrproject-rtos/zephyr/pull/25851 for JEDEC Serial Flash Discoverable Parameters inspection to confirm that it will support the various QSPI driver initiatives that are ongoing.
A status update on those QSPI driver initiatives.
Any other topics requested on the #api channel on slack or at the start of the meeting.
If time allows, a check on the status of in-progress issues and PRs in https://github.com/zephyrproject-rtos/zephyr/projects/18.
We are less than three weeks away from 2.4 feature freeze. If you have enhancements or new capabilities you want in 2.4, please mark them with the 2.4 milestone on github.
If you want a PR or issue to be tracked in this meeting, please add it to the GitHub project. If it's already there and you want it discussed in the next meeting, please say so via the #api channel on slack.
Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-meeting
https://github.com/zephyrproject-rtos/zephyr/projects/18
|
||||||||
|
|
||||||||
|
Re: [LWM2M] Client example - QEMU x86
Guillaume PAQUET <guillaume.paquet@...>
Robert, Thanks again for your help. It works fine. I just flush dev tap0 and it is ok now in IPv4 and IPv6. There is just one issue in strdup allocation. Default size is too small (we need more than 4 buffers, for ref I put 100. i don't try less) CONFIG_LOG_STRDUP_BUF_COUNT=100 Rgds, Guillaume
On Mon, Aug 17, 2020 at 4:47 PM Guillaume PAQUET <guillaume.paquet@...> wrote:
--
Pour la planète, n'imprimez ce mail que si c'est nécessaire
|
||||||||
|
|
||||||||
|
Re: [LWM2M] Client example - QEMU x86
Guillaume PAQUET <guillaume.paquet@...>
Hi Robert, I think I saw what is wrong for me. I have bad configuration on tap0. Indeed, I have not the good inet addr. Here is my output : tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.7.1 netmask 255.255.255.255 broadcast 192.168.7.255 inet6 fe80::36:65ff:fe12:f27 prefixlen 64 scopeid 0x20<link> inet6 2001:db8::2 prefixlen 64 scopeid 0x0<global> ether 02:36:65:12:0f:27 txqueuelen 1000 (Ethernet) RX packets 33899 bytes 4153906 (4.1 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 38604 bytes 86555696 (86.5 MB) TX errors 0 dropped 10 overruns 0 carrier 0 collisions 0 Thanks for this. I'll let you know Rgds, Guillaume
On Mon, Aug 17, 2020 at 4:33 PM Lubos, Robert <Robert.Lubos@...> wrote:
--
Pour la planète, n'imprimez ce mail que si c'est nécessaire
|
||||||||
|
|
||||||||
|
Re: [LWM2M] Client example - QEMU x86
Lubos, Robert
Hi Guillaume,
I’ve just verified the sample with current master (4bd247af700a88df3d5f2cca60e46b5669b4aa71), and it works fine on my machine.
Please double check if:
$ sudo ./loop-slip-tap.sh ********SLIP started on ``/tmp/slip.dev'' slipfd and inslip reopened ip neigh flush dev tap0 Cannot find device "tap0" opened tap device ``/dev/tap0'' ifconfig tap0 up ip -6 route add 2001:db8::/64 dev tap0 ip -6 addr add 2001:db8::2/64 dev tap0 ip route add 192.0.2.0/24 dev tap0 ip addr add 192.0.2.2/24 dev tap0 ifconfig tap0
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.0.2.2 netmask 255.255.255.0 broadcast 0.0.0.0 inet6 fe80::207d:e5ff:fef5:83b8 prefixlen 64 scopeid 0x20<link> inet6 2001:db8::2 prefixlen 64 scopeid 0x0<global> ether 22:7d:e5:f5:83:b8 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
You may also monitor the traffic on the tap0 interface with wireshark easily.
Regards, Robert From: devel@... [mailto:devel@...]
On Behalf Of Guillaume PAQUET via lists.zephyrproject.org
Hi,
Sorry for bad manipulation, my previous mail was not finished ... So to complete it, I run ./loop-socat.sh and sudo ./loop-slip-tap.sh in net-tools to be able to run QEMU x86 properly.
Thanks for your help
Rgds
Guillaume
On Mon, Aug 17, 2020 at 11:20 AM Guillaume PAQUET <guillaume.paquet@...> wrote:
--
|
||||||||
|
|
||||||||
|
Re: [LWM2M] Client example - QEMU x86
Guillaume PAQUET <guillaume.paquet@...>
Hi, So to complete it, I run ./loop-socat.sh and sudo ./loop-slip-tap.sh in net-tools to be able to run QEMU x86 properly. Thanks for your help Rgds Guillaume
On Mon, Aug 17, 2020 at 11:20 AM Guillaume PAQUET <guillaume.paquet@...> wrote:
--
Pour la planète, n'imprimez ce mail que si c'est nécessaire
|
||||||||
|
|
||||||||
|
[LWM2M] Client example - QEMU x86
Guillaume PAQUET <guillaume.paquet@...>
Hello Zephyr Community, I am Guillaume Paquet, I worked for STIMIO company and I am now working for SMILE company, specialised in Linux Open Source Embedded topics. I tried to run LWM2M client demo on QEMU x86 target : https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/lwm2m_client I tried to connect to local leshan server but I don't achieve to register. i have always the following error [00:00:37.230,000] <dbg> net_lwm2m_engine.lwm2m_engine_get: path:0/0/1, buf:0x00144373, buflen:1 [00:00:37.230,000] <dbg> net_lwm2m_engine.lwm2m_engine_get: path:0/0/10, buf:0x001443b2, buflen:2 [00:00:37.230,000] <dbg> net_lwm2m_engine.lwm2m_engine_get: path:1/0/1, buf:0x0013dea0, buflen:4 [00:00:37.230,000] <inf> net_lwm2m_rd_client: RD Client started with endpoint 'qemu_x86' with client lifetime 30 [00:00:37.230,000] <dbg> net_lwm2m_engine.lwm2m_parse_peerinfo: Parse url: coap://192.0.2.2 [00:00:37.230,000] <dbg> net_lwm2m_rd_client.sm_send_registration: registration sent [192.0.2.2] [00:00:39.590,000] <inf> net_lwm2m_engine: Resending message: 0x0013b4a0 [00:00:44.280,000] <inf> net_lwm2m_engine: Resending message: 0x0013b4a0 [00:00:53.660,000] <inf> net_lwm2m_engine: Resending message: 0x0013b4a0 [00:01:12.420,000] <wrn> net_lwm2m_rd_client: Registration Timeout [00:01:12.420,000] <dbg> net_lwm2m_client_app.rd_client_event: Disconnected [00:01:12.420,000] <dbg> net_lwm2m_client_app.rd_client_event: Registration failure! I only activated IPv4 (I also tried IPv6 and it does not work too). Maybe I missed something in configuration. For information, I run ./loop-socat.sh a --
Pour la planète, n'imprimez ce mail que si c'est nécessaire
|
||||||||
|
|
||||||||
|
Zephyr Project Code Guideline - A Couple Notes
Hibberd, Amber M <amber.m.hibberd@...>
Hi All,
Just wanted to send out a communication to highlight a few things regarding the Zephyr Project Coding Guideline (CG): -The CG has been published to the Zephyrproject.org documentation, here: https://docs.zephyrproject.org/latest/guides/coding_guidelines/index.html#coding-guidelines -There is a Github label created to use for finding / submitting PRs. It is: area: Code Guideline. -By searching you can find some compliance activity already started. -The Safety WG is working to publish a violation report to be used as reference in this interim time as we work to identify and integrate a scanning tool into our CI. An update will be coming in a couple weeks. Let me know if you have any questions / would like more information. Thank you! -Amber Amber Hibberd Software Engineering Manager Firmware & Microcontroller Operating System (FMOS) IAGS > IPAT Intel Corporation | OR-JF1-2 Pole B17
|
||||||||
|
|
||||||||
|
Zephyr Project: Dev Meeting - Thu, 08/13/2020 3:00pm-4:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: Dev Meeting When: Thursday, 13 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 13
Kumar Gala
Here’s the agenda topics for this week:
* Zephyr Testing via Emu: - https://github.com/zephyrproject-rtos/zephyr/issues/27531 * Any PR/issues w/dev-review tag * Any topics anyone else has. - k
|
||||||||
|
|
||||||||
|
Zephyr: Toolchain Working Group - Thu, 08/13/2020
#cal-notice
devel@lists.zephyrproject.org Calendar <noreply@...>
Zephyr: Toolchain Working Group When: Where: Description: Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r
________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
||||||||
|
|
||||||||
|
Zephyr: Toolchain Working Group - Thu, 08/13/2020 2:00pm-3:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr: Toolchain Working Group When: Thursday, 13 August 2020, 2:00pm to 3:00pm, (GMT+00:00) UTC Where:Microsoft Teams Meeting An RSVP is requested. Click here to RSVP Organizer: Maureen Helm Description: Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r
________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
||||||||
|
|
||||||||
|
Zephyr Toolchain Working Group Meeting – 13 August 2020
Rasmussen, Torsten
Let’s get started on a new round of meetings.
Agenda
Feel free to send a mail, if you would like additional topics to be discussed.
Best regards
Torsten T. Rasmussen
Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r ________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll) Conference ID: 682 738 030# Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
||||||||
|
|
||||||||
|
Zephyr Project: APIs - Tue, 08/11/2020 4:00pm-5:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 11 August 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC Where:Microsoft Teams Meeting An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18 ________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
||||||||
|
|
||||||||
|
Zephyr support for ARM Cortex-A7
#custom_board
emkey <apollo3344@...>
Hello,
I am trying to use Zephyr in my current project. Unfortunately, I can not find any sample project, which is based on a ARM Cortex A7 architecture. Mainly, my idea was to use an already available board project as a template and port it to the needs of my custom board. Is there anything, which I can do now? Do maybe plans from the Zephyr community exists, to support the Cortex A7 architecture in future ? Waiting for your kind reply and many thanks in advance. Best regards, Mehmet
|
||||||||
|
|
||||||||
|
Re: SOC_DIR not populated
Rasmussen, Torsten
Hi,
Thanks for the confirmation of the patch. And thanks for the update.
I was waiting for confirmation before sending update on mailing list.
See more comments below.
/Torsten
From: Dan Kalowsky <dank@...>
Sorry for the delay in response, got pulled into other duties and was not able to follow up on this in the immediate time frame.
On Thu, Aug 6, 2020 at 11:27 PM Rasmussen, Torsten <Torsten.Rasmussen@...> wrote:
Thank you for this PR. More importantly, thank you for fixing the documentation in the follow up PR and pointing out that this is a breaking change for others.
One additional note that should be added here, when using the files as corrected to build, they fail to find the linker.ld file found in the soc_a in the example.
The fix is to change the arm/product/CMakeLists.txt file like so:
- add_subdirectory(${SOC_SERIES}) + add_subdirectory(${CONFIG_SOC_SERIES})
This seems to allow everything to work correctly in the compile time frame. You may want to include that detail as well if it is correct. Note the demo repo needs to be cleaned up to compile anything at all, don't trust it. This seems odd because I believed that Zephyr dropped the CONFIG_ prefix from everything internally before using it, yet in this case the variable has data only when prefixed.
No, all Kconfig settings in CMake must be accessed using `CONFIG_<name>`. https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/app/boilerplate.cmake#L532 I would discourage using `SOC_SERIES` directly and instead do the proper `CONFIG_SOC_SERIES` but I will not remove `SOC_SERIES` possibility without a good reason, cause users may depend on it.
Which is the case for `SOC_ROOT/arch/soc` included CMake files.
For other usage, such as if a CMakeLists.txt file is included as a `add_subdirectory()` after `find_package(Zephyr)` then `SOC_SERIES` cannot be used due to CMake scoping, and `CONFIG_SOC_SERIES` must be used. That has not changed, so I would like to know how you get those CMake files included, to understand if there is an issue hidden somewhere. This should not have changed behavior with the changes introduced by https://github.com/zephyrproject-rtos/zephyr/pull/26715 .
I had no problem with linking when building for nrf52840dk_nrf52840 board, but I had to set `import:true` in the west.yml to get Nordic hal headers. But you might be looking at code that you have not pushed to the repo. At least I don’t see any board using the `soc_a` SoC.
Thank you for the history. From my island, I don't see this as a correct usage/behavior, but I am clearly in the minority.
See note above.
-- "Do you expect me to talk?"
|
||||||||
|
|
||||||||
|
Re: SOC_DIR not populated
Dan Kalowsky <dank@...>
Sorry for the delay in response, got pulled into other duties and was not able to follow up on this in the immediate time frame. On Thu, Aug 6, 2020 at 11:27 PM Rasmussen, Torsten <Torsten.Rasmussen@...> wrote:
Thank you for this PR. More importantly, thank you for fixing the documentation in the follow up PR and pointing out that this is a breaking change for others. One additional note that should be added here, when using the files as corrected to build, they fail to find the linker.ld file found in the soc_a in the example. The fix is to change the arm/product/CMakeLists.txt file like so: - add_subdirectory(${SOC_SERIES}) + add_subdirectory(${CONFIG_SOC_SERIES}) This seems to allow everything to work correctly in the compile time frame. You may want to include that detail as well if it is correct. Note the demo repo needs to be cleaned up to compile anything at all, don't trust it. This seems odd because I believed that Zephyr dropped the CONFIG_ prefix from everything internally before using it, yet in this case the variable has data only when prefixed.
Thank you for the history. From my island, I don't see this as a correct usage/behavior, but I am clearly in the minority.
See note above. "Do you expect me to talk?" "No Mr. Bond, I expect you to die."
|
||||||||
|
|
||||||||
|
API meeting: agenda
Carles Cufi
Hi all,
Agenda for tomorrow: - Extend LED API - PR: https://github.com/zephyrproject-rtos/zephyr/pull/26101 - [RFC] API change - Device structure attribute renaming - PR: https://github.com/zephyrproject-rtos/zephyr/pull/25798 - [RFC] API change: Device - Const-ify device driver instances. - PR: https://github.com/zephyrproject-rtos/zephyr/pull/24873 Additional items in the "Triage" column in the GitHub project may be discussed if time permits. If you want an item included in the meeting, please add it to the GitHub project. Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit Regards, Carles
|
||||||||
|
|
||||||||
|
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@...>
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:
> 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.
> 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)
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.
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.
> 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
> 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.
"Do you expect me to talk?"
|
||||||||
|
|
||||||||
|
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:
Sorry if the crudely generated ascii art was not clear enough. The Kconfig* files are in the product directory.
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.
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.
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.
That would be a typo on my part. Everything is set via the *_ROOT values, set in the application/src/CMakeLists.txt file.
-- "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
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@...>
Torsten,
On Thu, Aug 6, 2020 at 11:48 AM Rasmussen, Torsten <Torsten.Rasmussen@...> wrote:
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.
Again, I will encourage you to re-read the original message. The layout you are requesting to be followed is what has been followed.
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.
"Do you expect me to talk?"
|
||||||||
|
|
+33 6 14 76 11 80 
