How to add custom board to Nordic Connect SDK and/or Zephyr?

Hello Michael,

You have a couple of options here and I’m going to mention the ones I assume you might be most interested in:

1. You can install the NCS manually and upgrade versions via a terminal. Thus, custom boards added to e.g. the ../ncs repository will not disappear. I’m running NCS on an Ubuntu distribution and have all my custom boards in ../ncs/zephyr/boards, which is the smoothest solution for me. However, this option does not cover that different board versions can be connected to different or a specific NCS version.
2. You can add the custom board files to your application root. See chapter "Add a custom board" of this webinar.
3. You can use nRF Connect for VS Code to add custom boards. In general, I strongly recommend you using this tool for development and debugging, so using its custom board functionality might come along as a natural choice.

I hope this will help you.

Regards,

Markus

Hello Markus,

thank you very much for your answer.

I totally agree that your 3 suggestions work perfectly fine and for customer-specific boards we are always using option 3.

I now understand that my wording was not precise enough.

The boards I was talking about are public evaluation boards, which are available to everyone via distribution, for example the PAN1781 EVB using the nRF52820: https://www.mouser.de/new/panasonic/panasonic-enw89857axkf-evaluation-board/

So we really like to include these boards into Zephyr directly, so that people can choose them immediately after installing the latest Nordic Connect SDK from the list of boards when creating a build configuration for a project.

So the question is if we can / should create a pull request against the Nordic Connect SDK and then the change travels upstream into Zephyr or if we should create a pull request against Zephyr directly.

If the latter is preferred, the question is: how to actually do this when using Nordic Connect SDK? The problem with for example v1.9.1 is that it seems that the Zephyr repository included in the Nordic Connect SDK is not a public release version of Zephyr.

Best regards
Michael.

Hi Michael,

Please submit a PR against upstream Zephyr first, that's a typical way we introduce Zephyr changes into NCS. We'll get them on the next upmerge after your PR is merged, if you manage to do this within next few weeks, it should end up in our next release.

As for the way to achieve that when you're developing in NCS environment, you need to use a bit of git expertise to proceed. You can't simply create an upstream PR from a branch from sdk-zephyr, as this will not give the results we expect (we have downstream only patches in sdk-zephyr, renderring it impracticable to create PRs upstream directly).

You need to create a fresh branch first from the upstream Zephyr main (you'd need to add a new remote to zephyr repository instance if you don't have one yet). Once you have a branch based on vanilla Zephyr, you can chery-pick your commits into the branch. Finally, please use that branch to create an upstream PR, following https://docs.zephyrproject.org/latest/contribute/index.html#contribution-guidelines.

Hello Robert,

thank you very much for your answer.

The approach you describe is well understood and we will proceed like that once we have finished our internal development.

It is a little bit unlucky that the delta between the original Zephyr and the Zephyr in Nordic Connect SDK is quite big and it does not seem possible to simply use latest-and-greatest Zephyr with Nordic Connect SDK directly, in order to check if our addition works with that version correctly, too.

Because of this, we are going to create a patch that has never been tested against the Zephyr version we are going to contribute to. Do you agree?

But since these are "just" board files I guess it is ok, because there are not dependencies to other parts of Zephyr.

But I am wondering how other people that want to contribute to Zephyr through Nordic Connect SDK handle this problem.

Best regards
Michael.

Hi,

We do our best to upmerge Zephyr regularly, however, due to the complexity of the process (Zephyr is a very fast-moving project) we can't do this too often, its quite time-consuming operation to align sdk-nrf content with Zephyr changes.

I don't think there should be any issues with pushing board definitions written for sdk-zehpyr to upstream, it's always an author's responsibility to make sure changes are compatible with vanilla Zephyr. Upstream reviewers should be able to help and catch any issues with that.

Hi,

We do our best to upmerge Zephyr regularly, however, due to the complexity of the process (Zephyr is a very fast-moving project) we can't do this too often, its quite time-consuming operation to align sdk-nrf content with Zephyr changes.

I don't think there should be any issues with pushing board definitions written for sdk-zehpyr to upstream, it's always an author's responsibility to make sure changes are compatible with vanilla Zephyr. Upstream reviewers should be able to help and catch any issues with that.