This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Out of tree development: Building issues

Hi, I'm trying to migrate from the nRF9160 DK to our own board, and I'm having some trouble getting the west build system to play nicely. I've essentially started with the obvious choice: copy all of the nrf9160_pca10090 files to a new .../boards/arm/<board_name>/ directory with our board's name and changed all instances of BOARD_NRF9160_PCA10090/nrf9160_pca10090 and BOARD_NRF9160_PCA10090NS/nrf9160_pca10090ns with our board's variants. None of the other configurations or Devicetree setup has changed so far. I also updated our CMakeLists.txt file with:

# Set up the location of our custom boards
set(
    BOARD_ROOT
    ${CMAKE_CURRENT_LIST_DIR}
)

# Use our board
set(
    BOARD <board_name>
)

I'm still having some issues with the build, though. I'm building via "west build -p always ." when in our project's directory. I'm trying to avoid having caching issues by using "-p always" for now. I've also tried this with removing set(BOARD ...) and adding "-b <board_name>" during the build, to no avail. I've noticed a few things happening with this build that are different from builds with the nRF9160 board:

1) I get warnings about configurations not being correct. With the non-secure variant, I get this one:

warning: TRUSTED_EXECUTION_NONSECURE (defined at arch/Kconfig:145) was assigned the value 'y' but
got the value 'n'.

In our new <board_name>ns_defconfig file I've left that line as it was in the nRF9160 non-secure file:

CONFIG_TRUSTED_EXECUTION_NONSECURE=y

2) When buiding, I get the following error:

CMake Error at /mnt/c/git_root/test/zephyr/boards/CMakeLists.txt:13 (add_subdirectory):
add_subdirectory not given a binary directory but the given source
directory "/mnt/c/git_root/test/project/boards/arm/<board_name>" is
not a subdirectory of "/mnt/c/git_root/test/zephyr/boards". When
specifying an out-of-tree source a binary directory must be explicitly
specified.

I haven't seen any kind of direction on this in the docs, either Nordic's or Zephyr's. I can apparently resolve this by putting our board files back in ../zephyr/boards/arm/, but that's not exactly a solution for this.

3) If I build with our board in the zephyr directory, I get past #2 but then get quite a lot of build errors:

[35/181] Building C object zephyr/CMakeFiles/zephyr.dir/drivers/clock_control/nrf_power_clock.c.obj

...

In file included from /mnt/c/git_root/test/zephyr/include/toolchain.h:39,
from /mnt/c/git_root/test/zephyr/include/kernel_includes.h:19,
from /mnt/c/git_root/test/zephyr/include/kernel.h:17,
from /mnt/c/git_root/test/zephyr/soc/arm/nordic_nrf/validate_base_addresses.c:7:
/mnt/c/git_root/test/zephyr/include/toolchain/gcc.h:61:28: error: static assertion failed: ""
61 | #define BUILD_ASSERT(EXPR) _Static_assert(EXPR, "")
| ^~~~~~~~~~~~~~
/mnt/c/git_root/test/zephyr/soc/arm/nordic_nrf/validate_base_addresses.c:24:34: note: in expansion of macro 'BUILD_ASSERT'
24 | #define CHECK_ADDRESS(dts, mdk) BUILD_ASSERT((u32_t)(dts) == (u32_t)(mdk))
| ^~~~~~~~~~~~
/mnt/c/git_root/test/zephyr/soc/arm/nordic_nrf/validate_base_addresses.c:35:1: note: in expansion of macro 'CHECK_ADDRESS'
35 | CHECK_ADDRESS(DT_INST_0_NORDIC_NRF_CLOCK_BASE_ADDRESS, NRF_CLOCK);
| ^~~~~~~~~~~~~
/mnt/c/git_root/test/zephyr/include/toolchain/gcc.h:61:28: error: static assertion failed: ""
61 | #define BUILD_ASSERT(EXPR) _Static_assert(EXPR, "")

And so on. Same thing happens for:

[38/181] Building C object zephyr/CMakeFiles/zephyr.dir/mnt/c/git_root/test/nrf/subsys/spm/spm.c.obj

4) Compared to the nRF9160 build, I've noticed the build system seems to recurse into the spm project when building b0 and mcuboot:

=== child image spm begin ===

...

=== child image spm end ===

=== child image b0 begin ===

...

=== child image spm begin ===

...

=== child image spm end ===

...

=== child image b0 end ===

Any help is greatly appreciated. Right now I'm out of ideas and shooting in the dark by trying random things.

Parents
  • Digging in a little more, it looks like there must be some kind of hidden magic going on for the nrf9160_pca10090/ns board that rewires SPM. The generated .config file for the nrf9160_pca10090 build has this section:

    CONFIG_BOARD="nrf9160_pca10090"
    CONFIG_FLASH_LOAD_SIZE=0x30000
    CONFIG_FLASH_LOAD_OFFSET=0
    CONFIG_SOC="nRF9160_SICA"
    CONFIG_SOC_SERIES="nrf91"
    CONFIG_NUM_IRQS=65
    CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32768
    # CONFIG_WATCHDOG is not set
    # CONFIG_UART_NS16550 is not set
    # CONFIG_GPIO is not set
    CONFIG_ARCH_HAS_CUSTOM_BUSY_WAIT=y
    # CONFIG_CORTEX_M_SYSTICK is not set
    CONFIG_ISR_STACK_SIZE=2048
    CONFIG_CLOCK_CONTROL=y
    CONFIG_NRF_RTC_TIMER=y
    CONFIG_SYS_CLOCK_TICKS_PER_SEC=32768
    CONFIG_SYS_POWER_MANAGEMENT=y
    CONFIG_BUILD_OUTPUT_HEX=y
    CONFIG_FLOAT=y
    CONFIG_TEXT_SECTION_OFFSET=0
    CONFIG_FLASH_SIZE=1024
    CONFIG_FLASH_BASE_ADDRESS=0x0
    CONFIG_SRAM_SIZE=64
    CONFIG_SRAM_BASE_ADDRESS=0x20000000
    # CONFIG_SPI is not set
    # CONFIG_TINYCRYPT is not set
    CONFIG_SOC_GECKO_EMU=y
    CONFIG_BOARD_NRF9160_PCA10090=y
    # CONFIG_BOARD_NRF9160_PCA10090NS is not set

    But when building for our new board:

    CONFIG_BOARD="<board name>"
    CONFIG_FLASH_LOAD_SIZE=0x40000
    CONFIG_FLASH_LOAD_OFFSET=0x40000
    CONFIG_SOC="nRF9160_SICA"
    CONFIG_SOC_SERIES="nrf91"
    CONFIG_NUM_IRQS=65
    CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32768
    # CONFIG_WATCHDOG is not set
    # CONFIG_UART_NS16550 is not set
    # CONFIG_GPIO is not set
    CONFIG_ARCH_HAS_CUSTOM_BUSY_WAIT=y
    # CONFIG_CORTEX_M_SYSTICK is not set
    CONFIG_ISR_STACK_SIZE=2048
    CONFIG_CLOCK_CONTROL=y
    CONFIG_NRF_RTC_TIMER=y
    CONFIG_SYS_CLOCK_TICKS_PER_SEC=32768
    CONFIG_SYS_POWER_MANAGEMENT=y
    CONFIG_BUILD_OUTPUT_HEX=y
    CONFIG_FLOAT=y
    CONFIG_TEXT_SECTION_OFFSET=0
    CONFIG_FLASH_SIZE=1024
    CONFIG_FLASH_BASE_ADDRESS=0x0
    CONFIG_SRAM_SIZE=128
    CONFIG_SRAM_BASE_ADDRESS=0x20020000
    # CONFIG_SPI is not set
    # CONFIG_TINYCRYPT is not set
    CONFIG_SOC_GECKO_EMU=y
    # CONFIG_BOARD_<BOARD_NAME> is not set
    CONFIG_BOARD_<BOARD_NAME>NS=y

    CONFIG_BOARD in both cases grabs the secure board name -- which is expected, since SPM needs to sit in the secure region -- but then they deviate on things that actually depend on the secure/non-secure definitions. Someone must be changing CONFIG_BOARD_NRF9160_PCA10090NS to the non-NS variant specifically...

Reply
  • Digging in a little more, it looks like there must be some kind of hidden magic going on for the nrf9160_pca10090/ns board that rewires SPM. The generated .config file for the nrf9160_pca10090 build has this section:

    CONFIG_BOARD="nrf9160_pca10090"
    CONFIG_FLASH_LOAD_SIZE=0x30000
    CONFIG_FLASH_LOAD_OFFSET=0
    CONFIG_SOC="nRF9160_SICA"
    CONFIG_SOC_SERIES="nrf91"
    CONFIG_NUM_IRQS=65
    CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32768
    # CONFIG_WATCHDOG is not set
    # CONFIG_UART_NS16550 is not set
    # CONFIG_GPIO is not set
    CONFIG_ARCH_HAS_CUSTOM_BUSY_WAIT=y
    # CONFIG_CORTEX_M_SYSTICK is not set
    CONFIG_ISR_STACK_SIZE=2048
    CONFIG_CLOCK_CONTROL=y
    CONFIG_NRF_RTC_TIMER=y
    CONFIG_SYS_CLOCK_TICKS_PER_SEC=32768
    CONFIG_SYS_POWER_MANAGEMENT=y
    CONFIG_BUILD_OUTPUT_HEX=y
    CONFIG_FLOAT=y
    CONFIG_TEXT_SECTION_OFFSET=0
    CONFIG_FLASH_SIZE=1024
    CONFIG_FLASH_BASE_ADDRESS=0x0
    CONFIG_SRAM_SIZE=64
    CONFIG_SRAM_BASE_ADDRESS=0x20000000
    # CONFIG_SPI is not set
    # CONFIG_TINYCRYPT is not set
    CONFIG_SOC_GECKO_EMU=y
    CONFIG_BOARD_NRF9160_PCA10090=y
    # CONFIG_BOARD_NRF9160_PCA10090NS is not set

    But when building for our new board:

    CONFIG_BOARD="<board name>"
    CONFIG_FLASH_LOAD_SIZE=0x40000
    CONFIG_FLASH_LOAD_OFFSET=0x40000
    CONFIG_SOC="nRF9160_SICA"
    CONFIG_SOC_SERIES="nrf91"
    CONFIG_NUM_IRQS=65
    CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32768
    # CONFIG_WATCHDOG is not set
    # CONFIG_UART_NS16550 is not set
    # CONFIG_GPIO is not set
    CONFIG_ARCH_HAS_CUSTOM_BUSY_WAIT=y
    # CONFIG_CORTEX_M_SYSTICK is not set
    CONFIG_ISR_STACK_SIZE=2048
    CONFIG_CLOCK_CONTROL=y
    CONFIG_NRF_RTC_TIMER=y
    CONFIG_SYS_CLOCK_TICKS_PER_SEC=32768
    CONFIG_SYS_POWER_MANAGEMENT=y
    CONFIG_BUILD_OUTPUT_HEX=y
    CONFIG_FLOAT=y
    CONFIG_TEXT_SECTION_OFFSET=0
    CONFIG_FLASH_SIZE=1024
    CONFIG_FLASH_BASE_ADDRESS=0x0
    CONFIG_SRAM_SIZE=128
    CONFIG_SRAM_BASE_ADDRESS=0x20020000
    # CONFIG_SPI is not set
    # CONFIG_TINYCRYPT is not set
    CONFIG_SOC_GECKO_EMU=y
    # CONFIG_BOARD_<BOARD_NAME> is not set
    CONFIG_BOARD_<BOARD_NAME>NS=y

    CONFIG_BOARD in both cases grabs the secure board name -- which is expected, since SPM needs to sit in the secure region -- but then they deviate on things that actually depend on the secure/non-secure definitions. Someone must be changing CONFIG_BOARD_NRF9160_PCA10090NS to the non-NS variant specifically...

Children
No Data
Related