SPI8 Peripheral Blocked by RIF (Resource Isolation Framework) on STM32MP257F-EV1 — Cannot Access from Linux

[Radha Kadam]

Hello ST Support Team,

We are working with the STM32MP257F-EV1 evaluation board and have identified a hardware/firmware-level restriction preventing us from using the SPI8 peripheral from the Linux (Cortex-A35) side, despite correct device tree configuration.

Board: STM32MP257F-EV1
OpenSTLinux version: 5.0.15-openstlinux-6.6-yocto-scarthgap-mpu-v26.02.18
Kernel: Linux 6.6.116-stm32mp-r3

The issue:
When we enable the &spi8 node in our device tree (with correct pin configuration, matching the same pattern that successfully works for other SPI peripherals like SPI3), the driver never initializes at all. There is no error message, no warning, and no output anywhere in dmesg — the peripheral simply remains completely silent and unclaimed, as if the device tree node doesn't exist.

What we've already investigated and ruled out:

1. Device tree correctness — confirmed the node, pinctrl, and pin assignments are syntactically and semantically correct, following the identical working pattern used successfully for other SPI buses on this same board
2. Pin conflicts — confirmed no other peripheral or driver claims these same pins
3. RIF (Resource Isolation Framework) investigation — we traced this to the RIF security configuration in the OP-TEE secure firmware layer. Specifically:
   • SPI3's RIF resource ID (24) is granted to the non-secure (Linux) world
   • SPI8's RIF resource ID (29) appears to be denied to the non-secure world by default
4. We reviewed the available OP-TEE and TF-A device tree/configuration files we have access to, but could not find a supported, documented way from the Linux/application side to request or modify this RIF grant for SPI8.

Our question for ST:
Is SPI8 intentionally reserved for secure-world/Cortex-M33 use only on this board by default? If so:

• Is there a supported, documented mechanism to grant SPI8 access to the non-secure (Linux) world, either via device tree configuration, OP-TEE configuration, or another supported path?
• If this is not possible on this board revision, could you confirm this so we can plan around it definitively rather than continuing to investigate a configuration that may be permanently blocked by design?

We're happy to share our device tree files, dmesg output, or any other diagnostic information that would help you assist us.

Thank you for your time.

Best regards,
Radha Kadam

[Christophe Guibout]

Hello ​@Radha Kadam,

I made the following modification on my STM32MP257F-EV1 board with ecosystem-v6.2.0:

-    model = "STMicroelectronics STM32MP257F-EV1 Evaluation Board";
+    model = "STMicroelectronics STM32MP257F-EV1 Evaluation Board spi3 spi8";
     compatible = "st,stm32mp257f-ev1", "st,stm32mp257";
 
@@ -836,5 +836,5 @@ &spi3 {
     pinctrl-0 = <&spi3_pins_a>;
     pinctrl-1 = <&spi3_sleep_pins_a>;
-    status = "disabled";
+    status = "okay";
 };
 
@@ -843,5 +843,5 @@ &spi8 {
     pinctrl-0 = <&spi8_pins_a>;
     pinctrl-1 = <&spi8_sleep_pins_a>;
-    status = "disabled";
+    status = "okay";
 };

And here the output in dmesg where spi driver is probed:

[    0.000000] Machine model: STMicroelectronics STM32MP257F-EV1 Evaluation Board spi3 spi8
[    8.597924] spi_stm32 400c0000.spi: driver initialized (master mode)
[    8.619025] spi_stm32 46020000.spi: driver initialized (master mode)

root@stm32mp2-e3-b8-dc:~# uname -r
6.6.116-g598cc034543f

If SPI8 RIF configuration was secured, you would have seen an IAC in your logs (https://wiki.st.com/stm32mpu/wiki/How_to_analyze_IAC_%26_SERC_errors).

BR,

Christophe