1. Article purpose[edit source]
This article aims to provide tips to analyze and debug:
2. RIF configuration dump in Linux kernel[edit source]
Debug entries in /sys/kernel/debug/stm32_firewall/ are available to dump the RIF configuration.
Note: For now, only the RIFSC dump is available.
To dump the configuration, simply execute cat /sys/kernel/debug/stm32_firewall/rifsc in the Linux Kernel shell. You should see an output similar to this one with the values corresponding to your RIF configuration:
=============================================
RIFSC dump
=============================================
=============================================
RISUP dump
=============================================
| Peripheral name || Firewall ID || N/SECURE || N/PRIVILEGED || CID filtering || Semaphore mode || SCID || SEMWL |
| TIM1 || 0 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| TIM2 || 1 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| TIM3 || 2 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| TIM4 || 3 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| TIM5 || 4 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| TIM6 || 5 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| TIM7 || 6 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
| TIM8 || 7 || NSEC || NPRIV || disabled || disabled || 0 || 0x0 |
...
3. IAC debug[edit source]
Receiving an IAC interrupt is _ALWAYS_ caused by an insufficient access right. It can be cause by CID filtering, secure level filtering or privilege filtering.
3.1. Peripheral IAC[edit source]
Upon receiving such signal when accessing a peripheral, the platform will panic and output a trace similar to this one:
E/TC:0 stm32_iac_itr:188 IAC exceptions [159:128]: 0x10000000 E/TC:0 stm32_iac_itr:192 IAC exception ID: 156
Here, the trace gives you the ID of the hardware block onto which the IAC occurred (ID: 156).
You can either: dump the RIFSC configuration in the Linux kernel shell or lookup in the RIFSC chapter (Index of RIF peripheral table) of the STM32MP2x STM32 MPU reference manuals to identify which hardware block it corresponds to.
3.2. Memory IAC[edit source]
When an IAC occurs on a memory, whether it's block-based(RISAB) or page-based(RISAF), different information is displayed (in hexadecimal):
DUMPING DATA FOR risaf@420d0000 E/TC:0 stm32_risaf_dump_erroneous_data:212 ===================================================== E/TC:0 stm32_risaf_dump_erroneous_data:213 Status register (IAESR0): 1 E/TC:0 stm32_risaf_dump_erroneous_data:221 ----------------------------------------------------- E/TC:0 stm32_risaf_dump_erroneous_data:222 Faulty address (IADDR0): 82000000 E/TC:0 stm32_risaf_dump_erroneous_data:230 ===================================================== E/TC:0 Panic at core/arch/arm/plat-stm32mp2/main.c:196 <access_violation_action>
Here, you can see the faulty address that was attempted to be accessed, with a dump of the RISAF_IAESRx register that allows to identify which CID, with which secure/privilege level tried to access in read/write mode this address.
RISAL protected memories is a light-version of the RISAF and does not benefit of such feature.
4. SERC debug[edit source]
Receiving an [[SERC internal peripheral|SERC] interrupt is _EITHER_ caused by:
- Access to a hardware block under reset.
- Access to a hardware block that is not clocked.
The SERC also generates a bus error. Therefore, a bus error and a SERC interrupt are generated at the same time.
The trace printed upon receiving a SERC, unlike the one for the IAC is similar for both peripheral and memory hardware blocks.