• State Verified Answer
  • Replies 9 replies
  • Subscribers 86 subscribers
  • Views 618 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 352856
Options

How does TF-M select UART1 pins?

Jayant Tang

Hello DevZone,

I have a confusing question about TF-M. Need  help from a TF-M expert.

In this document, it says that we must disable uart1 in non-secure application, because TF-M use it as secure peripheral.

My question is: how does TF-M select the pins used by uart1_secure?

My board selection is `nrf9160dk/nrf9160/ns`, which is a non-secure board.

I use AI to read the build progress and all the Ninja things. And it told me that TF-M just read the non-secure `zephyr.dts` and use the pin-ctrl of that.

I think this is not reasonable, because uart1 is disabled in my application. There is no reason for TF-M to use the pin-ctrl from a disabled uart.

More general question: how can I choose a peripheral as secure or non-secure in NCS? Should I configure this in Devicetree or Kconfig?

Best regards,

Jayant

Parents Reply Children
  • 0 in reply to Jayant Tang
    Jayant Tang said:
    If it use the same dts as the application, does that means the TF-M only refer to the pin-ctrl part of non-secure `zephyr.dts` ? 

    I'm not sure if I understand this question correctly. The nrf9160dk_nrf9160_common-pinctrl.dtsi file is included in non-secure and secure dts file as you mentioned. So that part is common. Other than that, the files use different dts settings entirely. That's why there are two files to begin with.

  • 0 in reply to Hakon

    Hi,

    Let me describe a scenario: I am creating a custom board in Zephyr with two separate device tree files (.dts) — one for secure world ("board_s.dts") and one for non-secure world ("board_ns.dts"). Instead of using a common pin-control configuration, I define different pin-control settings in each of these files.

    In this case, when building a non-secure firmware with TF-M, which device tree file will TF-M use?

    I assume it should use "board_ns.dts", as that aligns with the build process for non-secure firmware. However, considering the address mapping of peripherals on the AHB/APB bus, all peripherals described in the non-secure device tree are located in the non-secure domain.

    This leads to a conceptual distinction. For example:

    - Including `<nordic/nrf9160ns_sica.dtsi>` (non-secure)
    - vs. including `<nordic/nrf9160_sica.dtsi>` (secure)

    If TF-M, as a secure firmware, relies on pin configurations from a non-secure device tree, that seems inconsistent. Isn’t that correct?

  • 0 in reply to Jayant Tang
    Jayant Tang said:
    In this case, when building a non-secure firmware with TF-M, which device tree file will TF-M use?

    TFM itself will be built with the secure version of the dts file. For the application, the non-secure dts file will be used.

    Jayant Tang said:
    If TF-M, as a secure firmware, relies on pin configurations from a non-secure device tree, that seems inconsistent. Isn’t that correct?

    Yeah, but it does not. TFM does not use a non-secure device tree file at all.

  • 0 in reply to Hakon

    Wow, that is more clear for me.

    You mean when I select `nrf9160dk/nrf9160/ns` for my application, the TF-M will use `nrf9160dk/nrf9160` automatically. Because they are in the same board folder.

    But when I choose the ns for my application, it seems that there is no way to set a `.overlay` devicetree file in sysbuild subfolder to modify the pins of TF-M. Is that correct?

    I remember when in NCS v2.2.0, I can set overlay of SPM in "child_image" subfolder.

Related
Terms of service