Custom board revision/extension with new Zephyr hardware model

I'm upgrading from SDK version v2.4 to v2.7 which introduces the new Zephyr hardware model and I'm struggling with the transition. I have two custom revisions is based off of the nrf5340dk:

In my v2.4 project I added the following to my CMakeLists.txt:

set(REVISIONS "foo_v4" "bar_v1")
if (NOT DEFINED BOARD_REVISION)
    string(REGEX MATCH "nrf5340dk_nrf5340_cpuapp@([a-zA-Z0-9_]+)" _ ${BOARD})
    set(BOARD_REVISION ${CMAKE_MATCH_1})
endif()
if (NOT BOARD_REVISION IN_LIST REVISIONS)
    message(FATAL_ERROR "${BOARD_REVISION} is invalid. Accepted revisions: ${REVISIONS}")
endif()

I then added the following files:

build/
  nrf5340dk_nrf5340_cpuapp_bar_v1.conf
  nrf5340dk_nrf5340_cpuapp_bar_v1.overlay
  nrf5340dk_nrf5340_cpuapp_foo_v4.conf
  nrf5340dk_nrf5340_cpuapp_foo_v4.overlay

Then I built with: west build -b nrf5340dk_nrf5340_cpuapp@foo_v4 --build-dir build/foo_v4

This worked great.

After updating to v2.7 I tweaked my CMakeLists.txt to match the new string, I tried to build with: west build -b nrf5340dk@foo_v4/nrf5340/cpuapp --build-dir=build/foo_v4

but I get the following error:

Invalid board revision: foo_v4

Board 'nrf5340dk' does not define any revisions.

Looking at the "Board Extensions" section of the documentation it seems like this should still be valid: docs.zephyrproject.org/.../board_porting.html

Parents
  • Hi dethredic,

    You shouldn't have to tweak CMakeLists.txt to make use of the board revision feature.

    I wonder if it's just because you haven't updated the nrf5340dk board's YAML file? See: Board Porting Guide — Zephyr Project Documentation.

    If you are concerned about changing the SDK files too much, perhaps you can consider using custom board files.

    Hieu

  • My application is a "freestanding application", so changing the SDK isn't a viable option since every developer on the project would need follow suit. I would also lose these changes when updating the SDK. Is there maybe a way to override / extend the board's YAML file from my application?

    I liked the idea of just using a revision of the nrf5340dk because:

    1. It's way simpler, only 2 files are needed to tweak some pins / add some configs
    2. I would get updates / fixes automatically as the SDK gets updated

    If there is no longer a way to use a custom revision without updating the SDK then I guess I will bite the bullet and implement a custom board

  • I haven't looked into overriding YAML file yet. However, if the changes are simple like just some pins and configs, and you don't mind tweaking CMake, then there is an alternative. You can add a CMake argument, and tweak CMakeLists.txt to include new Devicetree or Kconfig overlay files based on that argument.

    Is this an alternative for you?

    Talking about biting the bullet, using a workspace application is an option too. Though I can see that the downsides from updating the SDK are all still there.

  • I think that would work, at least as a short term solution. Are you suggesting that I ignore the official revision field and just add a custom "REVISION" (or similar) cmake that will set DTC_OVERLAY_FILE/ EXTRA_CONF_FILE?

  • I got this working, but it feels super hacky:

    set(REVISIONS "foo_v4" "bar_v1")
    if (NOT MY_CUSTOM_REVISION IN_LIST REVISIONS)
        message(FATAL_ERROR "Revision '${MY_CUSTOM_REVISION}' is invalid. Accepted revisions: ${REVISIONS}")
    endif()
    
    set(DTC_OVERLAY_FILE ${CMAKE_CURRENT_SOURCE_DIR}/boards/nrf5340dk_nrf5340_cpuapp_${MY_CUSTOM_REVISION}.overlay)
    set(EXTRA_CONF_FILE ${CMAKE_CURRENT_SOURCE_DIR}/boards/nrf5340dk_nrf5340_cpuapp_${MY_CUSTOM_REVISION}.conf)

    Then I can build with

    west build -b nrf5340dk/nrf5340/cpuapp -- -DMY_CUSTOM_REVISION=foo_v4

    Any suggestions on a better way to do this without creating a new board would be welcome

  • Yes, exactly something like that. Since we are doing something different from the concept called Revision in Zephyr, it might be better to use a different term though. Perhaps variant, or model.

    This is of course not what most projects do usually, so I understand why you call it a little hacky.

    If you want a more mainstream solution, for the Kconfig part, you can create a new Kconfig for just the project and add a "Kconfig description 'overlay'" to set the default value of other configs differently.
    But I can't think of anything for Devicetree...

    By the way, regarding the setup that works for you in 2.4, are the overlay files under the "build" folder or the "boards" folder? I think it should be "boards?"

  • The overlay files are in the "boards" folder, just a typo.

    I still find it a little unfortunate that applications can't define a custom revision anymore. I'll think about it over the weekend and maybe see how much work creating new boards is going to be.

Reply Children
Related