nrf9160 software architecture (boot, bsd, app) and partitioning

[Martin]

I am trying to port existing software to a custom nrf9160 board.
I am using latest nrf connect sdk updated with git and west.

Could somebody from Nordic comment about the architecture decisions that have been made so far:

- partition of the flash in boot, secure1, nonsecure1, secure2, nonsecure2, scratch, data
- partition of RAM I can not understand yet. From 256kb RAM there is 64kb reserved for secure mode, 64kb for the BSD library and that leaves 128kb for the application
- partition of devices

I was trying to study the structure of the Zephyr code and it seems that it does not take advantage of the TrustZone features yet.
I am aksing me what this 64kb RAM is reserved for in secure mode? Should that be supported by Zephyr in the future? What services should run in the secure space?
Would it make sense to implement crypto key management in secure mode?

The other question is about the size of the memory for the BSD library: 64kb. Can this be changed in the dts files and the pre-built binary library will respect that?
If the application sends and receives all few minutes a small UDP packet 64kb is really a lot.
What was the reason to not publish the BSD library as source code?

Best regards

- Martin 

[Ioannis]

Hi Martin,

Sorry for replying late on this - let me try to answer some of your questions.

Disclaimer : you might want to switch to the latest 0.4.0 release of nRF Connect SDK; several components have been .reworked/improved.

1. Flash partitioning:

Well, first, we have, obviously, tried to follow the generic guidelines of board flash partitioning, i.e. some area in the beginning of Flash is left for MCUboot, followed by the SLOT partitions. We have followed a static partitioning scheme, i.e. the Secure Firmware is located in Slot0, and the Non-Secure Firmware is placed in Slot0_NS. Slot1, Slot1_NS are (supposed to be) used for image swapping, during firmware upgrade. Scratch and file system are placed at the end, as usual.

Note that if you use the nRF Connect SDK "secure boot" sample,  Boot and Slot0 will be configured as Secure areas, leaving all the rest of flash area as non-secure.


2. SRAM partitioning:


You are correct - the lowest 64kB of SRAM are allocated to the Secure firmware (the "Secure Boot" sample, if you use nrf Connect SDK sample). This SRAM is used by the secure boot, while the device is boot up, and is never released to the non-secure application.

Then we statically allocate 64 kB of SRAM as the area to be used by the BSD lib. The reason for that is that the BSD Lib architecture requires a static and fixed area to operate on. And this area needs to be Non-Secure, because the BSD lib runs in the non-secure (application) domain.


The rest of SRAM is the "standard" Zephyr SRAM, used by Zephyr RTOS and your application.


3. Peripherals

By default, a Zephyr application needs some peripherals to provide functions needed by the system and/or your application. E.g. you need an RTC peripheral for system timing, or a UARTE devices for debug/log. Such devices, used by the Non-Secure Zephyr/Application, need to be enabled as Non-Secure "resources" (similarly to SRAM, FLash), according to the TrustZone architecture.


Regarding the rest of your questions: some comments from me:

The Zephyr RTOS has full support of the lower TrustZone functionality, meaning that, there are APIs to

- create non-secure calls

- secure entry functions

- route IRQs to Secure/Non-Secure

- configure non-secure ARM resources from the secure firmware (VTOR, stack pointers, faults, etc.)

Some of  the above elements are utilized in the Secure-Boot sample of nRF Connect SDK.

At the moment Zephyr RTOS does not natively support high level Trusted Execution features (e.g. secure services), but this might change: you might want to check with the Zephyr community, regarding plans to support Trusted execution features.

So, in particular: the 64kB of SRAM reserved in Secure firmware is used by the secure boot sample which boots the device and configures the security attributions for the nRF91 SoC, before jumping to the Non-Secure application. It is currently used for servicing secure interrupts.

Crypto: yes, it would make sense to implement crypto functions in the secure firmware area.

BSD lib: since the library is pre-compiled, and assumes that the memory is allocated to it, tweaking the DTS configuration, to allocate some of this SRAM to the non-secure application does not seem the right thing to do.

Regarding your last question: I need to get a response from the internal team, regarding the reasons for providing the BSD as a pre-compiled library; I will come back to you about this.

Ioannis