Changed board to secure thingy91_nrf9160 (NOT NS)

RE: Changed board to secure thingy91_nrf9160 (NOT NS)

Didrik Rokhaug — Mon, 16 Jan 2023 16:48:57 GMT

Sorry for the late reply.

[quote user="ArmNewbie"]Regarding the CONFIG_MCUBOOT_SERIAL stuff in thingy91_nrf9160.conf, that is for being able to bootload the nRF9160 via the nRF52840 and the USB on the Thingy:91 right?
Without using the SWD interface and external debug probe?[/quote]

Yes, CONFIG_MCUBOOT_SERIAL is used to enable serial recovery mode, which let you put the device in bootloader-mode and upload a new image over UART.

[quote user="ArmNewbie"]Anyhow, I've created the mcuboot.conf file as you suggested, and now the error from above is now gone, but still the NS boot doesn't seem to work (the sample program doesn't seem to start).[/quote]

Could you try to do an erase-all when you flash, if you haven't done so already?

I tried to create a custom board myself, based on the Thingy:91, following the webinar you linked to. This builds and runs for me:

devzone.nordicsemi.com/.../hello_5F00_custom_5F00_board.zip

RE: Changed board to secure thingy91_nrf9160 (NOT NS)

ArmNewbie — Wed, 11 Jan 2023 14:12:00 GMT

Hi Didrik, and thanks for the clarification, and also pointers to the additional config files!
Regarding the antenna design; we have only static antenna matching (yet), so no RF switches controlled by the MAGPIO lines (so far, but might be added later).

Regarding the CONFIG_MCUBOOT_SERIAL stuff in thingy91_nrf9160.conf, that is for being able to bootload the nRF9160 via the nRF52840 and the USB on the Thingy:91 right?
Without using the SWD interface and external debug probe?
On our custom board we have only the 9160, (and no 52840), so all flashing/debugging is done via a separate nRF9160-DK card connected to the SWD interface via the "Debug out" connector.

Anyhow, I've created the mcuboot.conf file as you suggested, and now the error from above is now gone, but still the NS boot doesn't seem to work (the sample program doesn't seem to start).

I've followed the main bim code with the debugger (.../v2.0.2/bootloader/mcuboot/boot/zephyr/main.c ), and it seems to execute ok from (struct arm_vector_table) vt->reset (in line 277), with the entry address 0x0C345 (that seems correct).
Then when further executing into the main code (in .../modules/tee/tf-m/trusted-firmware-m/secure_fw/spm/cmsis_psa/main.c) it seems to stop in nrf_spu_flashregion_set(), on the first assert() on line 408:

NRFX_ASSERT(!(p_reg->FLASHREGION[region_id].PERM & SPU_FLASHREGION_PERM_LOCK_Msk));

The region_id is 14 (when asserting).

Is it possible based on these details to tell what the problem now might be?

RE: Changed board to secure thingy91_nrf9160 (NOT NS)

Didrik Rokhaug — Tue, 10 Jan 2023 13:48:18 GMT

The Thingy:91 board files will include MCUBoot automatically, to make it possible to run samples unmodified on the Thingy:91 without a debugger.

However, that also means that you get some Kconfig options that were meant to be Thingy:91 specific when you use that board as a starting point for your custom board.

One of those settings is that MCUBoot is enabled automatically, but you don't also get the Thingy:91-specific options for the MCUBoot child image.

To add the extra MCUBoot settings to your project, you can create a <your project directory>/child_image/mcuboot.conf file, with the contents of bootloader\mcuboot\boot\zephyr\boards\thingy91_nrf9160.conf.

In addition, depending on your antenna design, you might need to add the options from nrf\lib\modem_antenna\Kconfig to your project (your main prj.conf, not child_image/mcuboot.conf)

RE: Changed board to secure thingy91_nrf9160 (NOT NS)

ArmNewbie — Tue, 10 Jan 2023 12:02:31 GMT

Thanks for elaborating the details Didrik, it really makes sense, and obvious that both the "secure" and "unsecure" parts are to be built.
I got kind of "blindfolded" by the fact that our custom board fails running an unsecure build, and I kind of "short circuited" that with the error in the build log.
Which obvious are two separate things!
For the record; the Thingy:91 runs fine with the NS build (as expected), but an NS build for the custom board does not (same code).
The error message from the console log is this (e.g. when running a hello_world example project):

*** Booting Zephyr OS build v3.0.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot
E: Protect mcuboot flash failed, cancel startup.

The culprit then points to the board files I guess, and this being not correct.
We have been using your recommendation regarding creating custom board files: www.youtube.com/watch
And have been using the Thingy:91 as basis.
The status now (when building (secure) for the custom board) is that the HW seems to work fine (LED, GPIO, UART, I2C, SPI etc), but the NS builds will not run.
Is it possible to determine anything pointing to the problem from the console output from our board?

-Alf

RE: Changed board to secure thingy91_nrf9160 (NOT NS)

Didrik Rokhaug — Fri, 06 Jan 2023 09:24:30 GMT

Hi,

This is expected.

When the CPU is reset, it will reboot in "secure" mode. You will therefore need some code to be "secure", which can set up the "non-secure" environment, and jump to the "non-secure" application.

(And just to avoid any misunderstanding, having the application run in the "non-secure" domain doesn't make it less secure. It is the separation between the domains that brings the security)

When you build your application as "non-secure", the build system will include the "secure" application automatically (TF-M or SPM depending on the NCS version). In addition, if you have a bootloader enabled (which is the default on the Thingy:91), it will also be built for the "secure" domain.

If you look at the log in more detail, you will see that it first builds the application for the "non-secure" domain (technically, at this point, it only generates the ninja and configuration files), then it changes the board to the "secure" version and builds the SPM and MCUBoot.

-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /Users/alfe/Documents/NRF_side/hello_world

...

Changed board to secure thingy91_nrf9160 (NOT NS)

=== child image spm -  begin ===
loading initial cache file /Users/alfe/Documents/NRF_side/hello_world/build_T/spm/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base).
-- Application: /opt/nordic/ncs/v2.0.2/nrf/samples/spm

...

Changed board to secure thingy91_nrf9160 (NOT NS)

=== child image mcuboot -  begin ===
loading initial cache file /Users/alfe/Documents/NRF_side/hello_world/build_T/mcuboot/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base).
-- Application: /opt/nordic/ncs/v2.0.2/bootloader/mcuboot/boot/zephyr

Best regards,

Didrik