The ARM TrustZone monitor mode can trap aborts in monitor mode. The monitor mode always executes in the secure world or context. How can we know what address and reason caused a fault in the normal world when it traps to the monitor mode instruction abort and data fault vectors?
相关问题
- Avoid cmake to add the flags -search_paths_first a
- AOSP Build TARGET_PRODUCT fails
- Perform a horizontal logical/bitwise AND operation
- Can variables inside packed structures be read ato
- Can run ARM/rpi images in Docker on Windows but no
相关文章
- socket() returns 0 in C client server application
- Why are i2c_smbus function not available? (I2C – E
- Problem with time() function in embedded applicati
- avoiding text relocations when mixing c/c++ and as
- Interrupt handling on an SMP ARM system with a GIC
- In linux, how to do system calls through GNU ARM a
- Using NEON multiply accumulate on iOS
- Decoding BLX instruction on ARM/Thumb (IOS)
It is worth noting that only external aborts can be configured to be taken in monitor mode, so MMU access faults will not be trapped.
As for the main question: the state of all Secure/Non-secure banked registers while in monitor mode is controlled by the state of the cp15 Secure Configuration Register NS bit: when it is set, you access Non-secure versions, and when it is clear you access Secure versions.
The following is some inline
gcc
code which allows any secure world mode to inspect theseCP15
registers.