Hi Thomas,
(The code snippets are from the commit with hash 5c1756fbab6097f5688583d11dea5d1271d2d774 on https://review.trustedfirmware.org . I only added some comments at certain points)
This symptom is usually caused by a misconfigured MPC.
The MPC initialisation is also called from platform\ext\target\musca_a\spm_hal.c:
---------- 8< ---------- void tfm_spm_hal_init_isolation_hw(void) { /* Configures non-secure memory spaces in the target */ sau_and_idau_cfg(); mpc_init_cfg(); /* <- initialise MPC */ ppc_init_cfg(); } ---------- >8 ----------
Looking at mpc_init_cfg:
---------- 8< ---------- void mpc_init_cfg(void) {
/* ... */
Driver_QSPI_MPC.Initialize(); Driver_QSPI_MPC.ConfigRegion(memory_regions.non_secure_partition_base, memory_regions.non_secure_partition_limit, ARM_MPC_ATTR_NONSECURE); /* ... */
/* Lock down the MPC configuration */ Driver_QSPI_MPC.LockDown();
/* ... */
/* Add barriers to assure the MPC configuration is done before continue * the execution. */ __DSB(); __ISB(); } ---------- 8< ----------
It is possible to change the MPC behaviour, to raise a bus fault on invalid access instead of the RAZ/WI behaviour, by setting the CFG_SEC_RESP bit in the MPC's control register. You should do something like this after Driver_QSPI_MPC initialisation (see https://developer.arm.com/products/architecture/cpu-architecture/m-profile/d... ):
---------- 8< ---------- uint32_t mpc_ctrl; Driver_QSPI_MPC.GetCtrlConfig(&mpc_ctrl); Driver_QSPI_MPC.SetCtrlConfig(mpc_ctrl | 0x10); ---------- 8< ----------
If you don't get the bus fault after this, further troubleshooting is needed.
Regards, Mate
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: 15 February 2019 15:57 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Musca-A SAU setup issues
I am working on porting TF-M to the IAR Embedded Workbench for ARM (EWARM) toolchain and I'm having some issues getting it to start properly.
I started out using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 CMSIS packs and I've had to fix things in all of the packs to make the project build with our compiler, some things just to add our tools, some things that were just gcc:isms that are non standard-C.
The TF-M code is based on a snapshot of https://git.trustedfirmware.org/trusted-firmware-m.git repository of the following hash: 5c1756fbab6097f5688583d11dea5d1271d2d774
I know that some of these packs are old and I'm also working on a port of the bits on trustedfirmware.org, but I would like to bring the old version up first.
The (current) issue I have is that the NS code region becomes inaccessible from the secure part after setting the SAU up and I assume I am missing something.
in tfm_core_init() there are calls to: --- tfm_spm_hal_init_isolation_hw(); configure_ns_code(); ---
tfm_spm_hal_init_isolation_hw() calls sau_and_idau_cfg(), which sets up: --- /* Configures SAU regions to be non-secure */ SAU->RNR = TFM_NS_REGION_CODE; SAU->RBAR = (memory_regions.non_secure_partition_base & SAU_RBAR_BADDR_Msk); SAU->RLAR = (memory_regions.non_secure_partition_limit & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk; ---
After this piece is run, the NS vector table becomes all zeros when viewed from secure mode. This causes the configure_ns_code() call above to fail to pick up the ns_msp and ns_entry addresses, they become 0.
If I swap the calls around so they become: --- configure_ns_code(); tfm_spm_hal_init_isolation_hw(); --- then ns_msp and ns_entry are picked up OK.
How is this supposed to work?
When the SAU is setup I get RAZ/WI when accessing NS memory from S mode, the other way around results is a security violation, which is properly handled by the SecureFault_Handler().
What am I missing?
I run into other problems later, but that may very well a consequence of earlier issues.
Thanks, /Thomas