2025-05-29 2:11 AM
Starting kernel ...
I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
E/TC:0 stm32_iac_itr:180 IAC exceptions [159:128]: 0x400
E/TC:0 stm32_iac_itr:185 IAC exception ID: 138
E/TC:0 Panic at /usr/src/debug/optee-os-stm32mp/3.19.0-stm32mp-r2-r0/core/drivers/firewall/stm32_iac.c:200 <stm32_iac_itr>
E/TC:0 TEE load address @ 0x82000000
E/TC:0 Call stack:
E/TC:0 0x8200831c
E/TC:0 0x82030254
E/TC:0 0x82021024
E/TC:0 0x8202f198
E/TC:0 0x82013fd4
E/TC:0 0x820017dc
How can I confirm the RIF configuration of OpteeOS to resolve this issue?
Solved! Go to Solution.
2025-06-02 1:22 AM
Hello @bugman ,
If you want to confirm the RISAF configuration at runtime, you can always set
CFG_STM32_PANIC_ON_IAC_EVENT=n in OP-TEE. Therefore, the platform won't panic on an IAC. Then, you can dump the RIF configuration in the kernel using the debugfs entry. You can have a look at https://wiki.st.com/stm32mpu/wiki/How_to_analyze_IAC_%26_SERC_errors . If you don't have this RISAF available for dump in the debugfs, you need to activate the node in the linux board device-tree file.
However, I'm surprised that you don't have a more detailed dump with the faulty address (Similar to the example in the wiki)? Have you omitted that in the log? Else, maybe the non-TDCID/non-delegated CID software is accessing the RISAF registers directly and that's forbidden.
Regards,
Gatien
2025-06-02 1:22 AM
Hello @bugman ,
If you want to confirm the RISAF configuration at runtime, you can always set
CFG_STM32_PANIC_ON_IAC_EVENT=n in OP-TEE. Therefore, the platform won't panic on an IAC. Then, you can dump the RIF configuration in the kernel using the debugfs entry. You can have a look at https://wiki.st.com/stm32mpu/wiki/How_to_analyze_IAC_%26_SERC_errors . If you don't have this RISAF available for dump in the debugfs, you need to activate the node in the linux board device-tree file.
However, I'm surprised that you don't have a more detailed dump with the faulty address (Similar to the example in the wiki)? Have you omitted that in the log? Else, maybe the non-TDCID/non-delegated CID software is accessing the RISAF registers directly and that's forbidden.
Regards,
Gatien
2025-06-04 10:46 PM
After check optee DTS, it is found that PCIe is disabled in the RISAF. It can be resolved by re - enabling it,thanks
2025-06-19 10:40 PM
Hi bugman,
I’ve encountered the same issue. Would you mind showing me how to configure this in CubeMX?
2025-06-20 12:43 AM
Hello @Steven-LIN ,
If you want to be able to access the PCIE region with the PCIE master and the Cortex-A35: select at least Read/Write for the CID1 (CID of the Cortex A35).
If you have configured the RIF so that CID filtering is enabled on the slave port of the PCIE(RISUP) and the master port of the PCIE(RIMU) is in inheritance mode(default), then you'll have to select also the CID specified for the RISUP.
If you have configured the RIF so that CID filtering is enabled on the slave port of the PCIE(RISUP) and the master port of the PCIE(RIMU) is not in inheritance mode (CIDSEL), then you'll have to select also the CID specified for the RIMU.
Else, if CID filtering is disabled on the PCIE RISUP, then please select CID0 as the RIMU of the PCIE will hold CID0 on the bus.
Regarding secure and privilege rights, I let you decide what's fitting your case. If it's for PCIE in Linux kernel, I suggest not to select secure.