CONFIG_BOOTLOADER_MCUBOOT on custom NRF9160 board

Hi all,

SDK: NRF Connect v2.5.0

We've made a custom PCB with the NRF9160, and we have made a custom board configuration for it.

Our issue seems to appear when trying to enable this flag: CONFIG_BOOTLOADER_MCUBOOT=y.

It fails at generating the build files with: 

CMake Error at /opt/nordic/ncs/v2.5.0/nrf/lib/fprotect/CMakeLists.txt:16 (message): No fprotect backend selected.

But if I use the same project and generate build files for the nrf9160dk_nrf9160_ns, then the project compiles fine, and if I emit the bootloader flag, it also compiles on the custom board.

I've also tried setting CONFIG_FPROTECT=n which doesn't seem to affect anything.

Here's the defconfig we're using for the custom board right now

CONFIG_SOC_SERIES_NRF91X=y
CONFIG_SOC_NRF9160_SICA=y
CONFIG_BOARD_APPARATUS_V2=y

# Enable MPU
CONFIG_ARM_MPU=y

# Enable hardware stack protection
CONFIG_HW_STACK_PROTECTION=y

CONFIG_ARM_TRUSTZONE_M=y

CONFIG_TRUSTED_EXECUTION_NONSECURE=y

# Enable FPU
CONFIG_SHELL_BACKEND_RTT=y

# Enable UARTE
CONFIG_SERIAL=y

# Enable GPIO
CONFIG_GPIO=y

# Enable PINCTRL
CONFIG_PINCTRL=y

# Enable I2C driver
CONFIG_I2C=y

# Enable SPI driver
CONFIG_SPI=y

What are we missing here?

Parents Reply Children
  • The problem is that nrf91.dtsi, which adds the SPU to the device tree, doesn't get included in the devicetree when MCUBoot is built.

    I was able to get it to work by adding the _ns version of the board as well. That way, the application is built for the non-secure domain, and includes nrf91ns.dtsi, while MCUBoot and TF-M is built for the secure domain and include nrf91.dtsi.

    I've attached the board folder I ended up with, but it is adapted to work with the nRF9161 DK, so it won't work out-of-the-box for you. You will both have to ensure that the configurations match your board (e.g. the UART and console settings are changed), and make sure that it uses the nRF9160 files and settings, not the nRF9161.

    intoto_apparatus_v2.zip

Related