You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the initialisation of the vmpu in the procedure vmpu_init_post:
The MPU is enabled by vmpu_arch_init() which calls vmpu_mpu_lock()
Box configurations are loaded and regions are programmed for box 0 by vmpu_load_box()
This means that the MPU is enabled at (1) and subsequently has regions programmed at (2). At (1), only static regions will have been programmed. In particular, higher-numbered regions will still have their reset value (UNKNOWN); hence, this is architecturally UNPREDICTABLE.
A fix is to move the call to vmpu_mpu_lock() after vmpu_load_box(). This guarantees that all RBAR/RASR registers have been written-to (by vmpu_mpu_invalidate()) before the MPU is enabled.
Found using ArchEx.
The text was updated successfully, but these errors were encountered:
See issue ARMmbed#380.
Move call to vmpu_mpu_lock() after vmpu_load_box(). This guarantees that all
RBAR/RASR registers have been written-to (by vmpu_mpu_invalidate()) before the
MPU is enabled.
During the initialisation of the vmpu in the procedure
vmpu_init_post
:vmpu_arch_init()
which callsvmpu_mpu_lock()
vmpu_load_box()
This means that the MPU is enabled at (1) and subsequently has regions programmed at (2). At (1), only static regions will have been programmed. In particular, higher-numbered regions will still have their reset value (UNKNOWN); hence, this is architecturally UNPREDICTABLE.
A fix is to move the call to
vmpu_mpu_lock()
aftervmpu_load_box()
. This guarantees that all RBAR/RASR registers have been written-to (byvmpu_mpu_invalidate()
) before the MPU is enabled.Found using ArchEx.
The text was updated successfully, but these errors were encountered: