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

[Michael Hunold]

What is the canonical way to get a custom nRF52-based board into Nordic Connect SDK and/or Zephyr?

We have developed a couple of custom evaluation boards for nRF52820, nRF52833 and nRF52840 and we have created the matching board configuration files.

Naturally now we'd like to have them included in upcoming versions of the Nordic Connect SDK. But how to proceed?

Maybe there is a documentation or a howto that we missed that you can point us to?

We have checked Nordic Connect SDK release v1.9.1 which contains Zephyr v2.7.99-ncs1-1.

Should we go directly for the inclusion into Zephyr? If so, how do we achieve that with the version that is included in the Nordic Connect SDK? It seems that for the Zepyhr version included in the Nordic Connect SDK all git information is gone and it's difficult to judge which version we should actually target.

Or should we go for inclusion through Nordic Connect SDK, maybe because these boards are based on nRF52? If so, how does this work and to whom should we address a pull request?

Can you please give us some hints on how to proceed? Thanks!

[Michael Hunold]

Robert Lubos said:

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 understand.

In the meantime we managed to upstream the board definitions for our Panasonic boards, please refer to https://github.com/zephyrproject-rtos/zephyr/pull/44875/commits The commits were merged on June, 28th.

On https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/releases/release-notes-changelog.html the following is mentioned:

The Zephyr fork in nRF Connect SDK (sdk-zephyr) contains all commits from the upstream Zephyr repository up to and including fb802fb6c0af80dbd383e744065bcf1745ecbc66, plus some nRF Connect SDK specific additions.

Unfortunately that commit id is already from June, 08th, which means that our board definitions are not included.

Can you please check if you are planning to upmerge Zephyr again before the next big Nordic Connect SDK release? Also do you have a hint when this next big release is due?

I am asking because our product marketing and demo / sample developers are waiting to update all our demos and documentation to move from using the "nrf52840dk_nrf52840" board files etc. (and explaining the differences to our boards) to using our custom board definitions.

Thanks and best regards!

[Sigurd]

Michael Hunold said:

Can you please check if you are planning to upmerge Zephyr again before the next big Nordic Connect SDK release? Also do you have a hint when this next big release is due?

We did a upmerge this week. As far as I can see, your board files are now in our Zephyr fork: https://github.com/nrfconnect/sdk-zephyr/tree/main/boards/arm , and should be part of the next nRF Connect SDK release (v2.1.0)

[Michael Hunold]

Sigurd said:

We did a upmerge this week. As far as I can see, your board files are now in our Zephyr fork: https://github.com/nrfconnect/sdk-zephyr/tree/main/boards/arm , and should be part of the next nRF Connect SDK release (v2.1.0)

Thank you very much, that is good news for us!

Unfortunately we had a small mistake in one of our board files which we have recently fixed: https://github.com/zephyrproject-rtos/zephyr/pull/49660

I know that you probably cannot comment on the internal release schedule of nRF Connect SDK, but maybe you can tell me if you are planning another upmerge or if you can cherry-pick this fix for the v2.1.0 release.

Thanks, Michael.

[Sigurd]

Michael Hunold said:

but maybe you can tell me if you are planning another upmerge or if you can cherry-pick this fix for the v2.1.0 release.

We are on v2.1.0-rc2 (release candidate 2) now, and very very close to the v.2.1.0 release. At this point in time only bugfixes for critical issues will be merged before the release.

[Michael Hunold]

Sigurd said:

At this point in time only bugfixes for critical issues will be merged before the release.

To be honest we actually consider this as a critical bugfix.

For this evaluation board the default availability of the 32kHz slow clock was removed and we got this wrong initially.

That means if somebody uses that board in their board configuration to build a project, that project won't even start up on their board because the clock setup never finishes.

It would be great if you could vote for this as a critical bugfix and pull this in for the v2.1.0 release.

[Sigurd]

Michael Hunold said:

It would be great if you could vote for this as a critical bugfix and pull this in for the v2.1.0 release.

I asked the team, but it was unfortunately too late. We are tagging v.2.1.0 any second now. There might be a "dev-tag" release not too long after v.2.1.0, so it might be possible to get the fix into that release.