How do I use a custom version of Zephyr with NCS?

[Atilla Byteflyer]

We have our application in a git repository with a minimal west.yml as below. We want for Zephyr and have the manifest import our fork, instead of recursively getting from nrfconnect manifest. What is the syntax for that? I'd rather fork zephyr only and not whole NCS just to change the manifest.

manifest:
 self:
 west-commands: scripts/west-commands.yml

remotes:
 - name: ncs
 url-base: https://github.com/nrfconnect

projects:
 - name: nrf
 repo-path: sdk-nrf
 remote: ncs
 revision: v3.1.0
 import: true

[Einar Thorsrud]

Hi,

The way I understand your question you want to refer to use a nRF Connect SDK release, but refer to another Zephyr tag? One potential approach could be to do as is domein the nRF Connect SDK example application (which demonstrate a workspace application) but instead of referring to nrf, refer to all the compoennts you want (including Zephyr and others), so that you maitain your own west.yml that is based on the one under nrf: west.yml. It may be just as clean to fork nrf repo and do things there though, although I understand that is somehting you want to avoid.

[Atilla Byteflyer]

Solved it this way: Explicitly adding the Zephyr before NCS will override the Zephyr from NCS.

manifest:
 self:
 west-commands: scripts/west-commands.yml

remotes:
 - name: <own remote>
   url-base: https://github.com/<own>
 - name: ncs
   url-base: https://github.com/nrfconnect

projects:
 - name: zephyr
   remote: <own remote>
   repo-path: zephyr
   # always point this to a tag(better) or hash, never a branch!
   revision: <own tag>
   import:
   # Recursively import these from Zephyr
   # Please keep this list sorted alphabetically.
     name-allowlist:
     - ...

- name: nrf
  repo-path: sdk-nrf
  remote: ncs
  revision: v3.1.0
  # recursively import EVERYTHING from NCS.
  # This has lower priority than explicitly listed ones.
  # Zephyr above overrides the zephyr from NCS
  import: true

[Atilla Byteflyer]

Thank you for the pointer. I provided my solution for future reference.

[PaKa]

Out of curisosity, why do you want to do this? All wireless certifications are tied to the Zephyr version version included in nRF Connect SDK so you will now not have any Bluetooth/Matter/Thread qualifications for products.

[Atilla Byteflyer]

Actually I'm using an internal branch based on ncs-v3.1.0 release, because some of the peripheral drivers in Zephyr are lacking. Wither no power management, or happen to lack "compatible" support for the variants we use etc.

Instead of maintaining custom drivers in our external tree, I thought it would be more manageable to fork NCS version of Zephyr, which would also make it easy to contribute back upstream.

Do you have a recommendation in the regulatory sense? Should we keep any custom driver developments (even things like temperature sensors) strictly out-of-tree?