• 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

  • 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

    Hello thank you for your reply :-)

    NCS, by design, only works with a Zephyr fork. This is exactly the problem. Why nor create stable NCS/SDK-NRF releases that would be fully compatible with Zephyr upstream?

    Current situation does not really attract Zephyr developers to Nordic solutions.

    Nordic is creating pretty separate project that moves aside and lags more and more from Zephyr upstream. This creates Linux like situation of different self-incompatible distributions (yes I am from the BSD school where OS is also the distribution).

    There are features such as NUS that are highly demanded directly in Zephyr either as part of the upstream or as the module.. they can work with bare-metal Zephyr.. it worked for me. I do not understand why would Nordic not want to share the code with the upstream?

    It was Nordic that convinced me to move away from ARM MBED to ZEPHYR as platform independent RTOS that gives me flexibility and easy vendor switch. Now I have this surprise moment where I am forced to work on a Nordic only fork. Not really the flexible and portable way.

    I am aware that development branch may not be compatible with Zephyr upstream until some commits land into upstream, but master / release branch can and should be compatible with the upstream.

    Please consider sharing Nordic modules with Zephyr upstream and/or make Nordic SDK modules compatible with bare-metal Zephyr upstream (even as separate modules/remote).

    Thank you for your time, please consider as important compatibility requirement :-)

    Tomek

  • 0 in reply to CeDeROM

    Here is the Zephyr GitHub Ticket: https://github.com/zephyrproject-rtos/zephyr/issues/36242

    Copy below:

    Allright, so the v1.5.1 sdk-nrf does not build with upstream Zephyr. Later master can build BLE NUS SHELL with upstream Zephyr, until TFM is introduced that depends on sdk-zephyr fork.

    I can see SDK-NRF v1.6.0 is in RC stage. Please make v1.6.0 release build with Zephyr Upstream. I can see how lucky I was at first to get things "just running" ;-)

  • 0 in reply to CeDeROM

    Hi!

    Many NCS maintainers switch a single workspace back and forth between a vanilla upstream Zephyr workspace and NCS by changing the manifest.path west configuration option and running west update whenever they need to. Applications require a pristine build after doing this.

    Your claim that our modified fork moves more and more away from and behind the upstream is incorrect. While certain things in NCS are indeed quite far from how upstream works (partition manager and multi-image build system in particular), it is not at all the case that we are getting behind upstream. We sync regularly with upstream. 

    I have shared your feedback with the NCS developers, but that's really all I can do at this point. 

    Please let me know if there's anything else I can do for you.

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

Related
Terms of service