TFM system devicetree usecase

[galak]

This is meant as a top level issue for tracking the TFM (trusted firmware-m) use case for system devicetree.

[galak]

what is the simplest logical configuration we can describe for TFM?

[ioannisg]

In my opinion we need to describe at least:

• Flash partition layout (sizes & starting addresses)
  • for boot loader(s), TF-M firmware and Non-Secure (Zephyr) application
• SRAM partition layout (sizes & starting addresses)
  • at least for TF-M and Non-Secure (Zephyr) application
  • potentially for shared memory regions (due to some shared buffers in multi-core use-cases)
• Peripheral allocation to the different Security domains
  • Secure and Non-Secure peripherals. Applicable for peripherals that may be allocated to any security domains (e.g. not for secure only peripherals, like crypto engines)
  • Potentially, additional resources, such as pins and/or platform-specific HW (e.g. Nordic nRF DPPI channels). This could, theoretically, be done in run-time (using secure services) so it's not mandatory in the initial example.
• HW interrupt allocation to the different Security domains
  • This is related to Peripheral allocation but may, also, be done separately. There's an RFC in Zephyr to get the number of interrupts via DT, now, so we could align and extend that support in SDT
• Core configuration
  • Things like core exception allocation, etc.

[sstabellini]

Answering inline below from a system device tree perspective.

In my opinion we need to describe at least:

• Flash partition layout (sizes & starting addresses)

  • for boot loader(s), TF-M firmware and Non-Secure (Zephyr) application

• SRAM partition layout (sizes & starting addresses)

  • at least for TF-M and Non-Secure (Zephyr) application
  • potentially for shared memory regions (due to some shared buffers in multi-core use-cases)

Both of these are interesting and also came up recently in internal conversations. They are on my TODO.

• Peripheral allocation to the different Security domains

  • Secure and Non-Secure peripherals. Applicable for peripherals that may be allocated to any security domains (e.g. not for secure only peripherals, like crypto engines)

We have it already

• Potentially, additional resources, such as pins and/or platform-specific HW (e.g. Nordic nRF DPPI ch annels). This could, theoretically, be done in run-time (using secure services) so it's not mandatory in the initial example.

It depends on how these "additional resources" are described in device tree

• HW interrupt allocation to the different Security domains

  • This is related to Peripheral allocation but may, also, be done separately. There's an RFC in Zephyr to get the number of interrupts via DT, now, so we could align and extend that support in SDT

This is very interesting and not currently on our TODO. However, it will be needed for Xen too, so I can definitely see adding it to it.

• Core configuration

  • Things like core exception allocation, etc.

We have it