• State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 87 subscribers
  • Views 1231 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 271486
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrfconnect/sdk-nrf/modules/trusted-firmware-m/Kconfig and Kconfig.tfm | Nordic SDK not compatible with Zephyr Upstream

CeDeROM

Hello world :-)

As there is no Issues section in sdk-nrf I will post my question here. After west update I cannot build my firmware anymore. I am using v2.6.0 Zephyr and master sdk-nrf. This file seems to have showed up 5 hours ago.

If you look at trusted firmware config sdk-nrf/modules/trusted-firmware-m/Kconfig line 42 relates to a non existent file Kconfig.tfm:

source "$(ZEPHYR_BASE)/modules/trusted-firmware-m/Kconfig.tfm"

https://github.com/nrfconnect/sdk-nrf/blob/32171ea926bb228a81d2edb8aad8d7c8867f2864/modules/trusted-firmware-m/Kconfig#L42

Update: Problem does not occur in v1.5.1.

Update: I have now problem building my firmware because of NUS log related errors.

I can see that Nordic SDK is not ready to work together with bare metal Zephyr in the same workspace :-( I hope this is not by design. I have to use modified fork provided by sdk-nrf.. and this fork gets more and more away from and behind the upstream. I am not sure if this is the good way to go. Please adhere Nordic SDK to Zephyr Upstream.

Tomek

Parents
  • 0

    Hi!

    You need to use the nRF Connect SDK Zephyr fork when working with NCS.

    I can't really help you any further as these issues aren't showing up in the workspace we intend for you to use with NCS. 

    Best regards,

    Heidi

  • 0 in reply to Heidi

    Hey there  :-) I cannot reply to your last response below to follow the discussion so here so here goes the reply :-)

    Thanks for sharing the problem to SDK NRF developers. I hope stable parts and modules useful to others will land into the Zephyr upstream (i.e. NUS BLE SHELL). You may also want to separate stuff that works with Zephyr upstream from the under-development stuff in sdk-nrf, I know this is additional work burden, this is why pushing into the upstream seems simplest solution.

    Looking at sdk-zephyr releases v2.6.0-rc1 showed up 5 days ago, while v2.6.0 release it out. Previous release was 2.4.99 and 2.4.0 while. 2.5.0 is totally skipped.

    The only difference I found so far is the BLE BUS SHELL and time routines. However working on a fork implies risk that code may not be reusable on other platforms this is why we prefer to work on the upstream not a fork. If you sync and push features to the upstream then no problem I was afraid you may want to create your own fork distribution.

    Thank you for your time :-)

Reply
  • 0 in reply to Heidi

    Hey there  :-) I cannot reply to your last response below to follow the discussion so here so here goes the reply :-)

    Thanks for sharing the problem to SDK NRF developers. I hope stable parts and modules useful to others will land into the Zephyr upstream (i.e. NUS BLE SHELL). You may also want to separate stuff that works with Zephyr upstream from the under-development stuff in sdk-nrf, I know this is additional work burden, this is why pushing into the upstream seems simplest solution.

    Looking at sdk-zephyr releases v2.6.0-rc1 showed up 5 days ago, while v2.6.0 release it out. Previous release was 2.4.99 and 2.4.0 while. 2.5.0 is totally skipped.

    The only difference I found so far is the BLE BUS SHELL and time routines. However working on a fork implies risk that code may not be reusable on other platforms this is why we prefer to work on the upstream not a fork. If you sync and push features to the upstream then no problem I was afraid you may want to create your own fork distribution.

    Thank you for your time :-)

Children
No Data
Related
Terms of service