You are welcome.
Good news to know that it can works.
Thanks, Edison
From: Thomas Törnblom thomas.tornblom@iar.com Sent: Monday, December 16, 2019 3:48 PM To: Edison Ai (Arm Technology China) Edison.Ai@arm.com; 'tf-m@lists.trustedfirmware.org' tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] MPU issues, was Re: Regression test issues with IAR port
Thanks Edison,
That was indeed the cause. I found that there were some IAR specific runtime libraries that also needed to be placed in TFM_UNPRIV_CODE. I guess they are the equivalent of armlib and libtfmsprt.a for ARMCLANG.
Cheers, Thomas Den 2019-12-13 kl. 09:13, skrev Edison Ai (Arm Technology China):
Hi Thomas,
What I can see from your description is that the problem should is caused the MPU configure.
You are working on the isolation level 2 model by using ConfigRegressionIPCTfmLevel2 configure file.
In isolation level 2, PSA FF says this: "the PSA Root of Trust is also protected from access by the Application Root of Trust". You can see more detail about the isolation information from PSA FF with this link: https://pages.arm.com/psa-resources-ff.html?_ga=2.156169596.61580709.1542617....
So, we need to configure MPU(MSUCA_A board which you are using) for APP RoT to limit the source the APP RoT can access in isolation level 2.
You can see from code:
__attribute__((naked, section("SFN")))
psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout)
{
__ASM volatile("SVC %0 \n"
"BX LR \n"
: : "I" (TFM_SVC_PSA_WAIT)); }
The psa_wait() is put in the "SFN" region, and the "SFN" region in put in the "TFM_UNPRIV_CODE" section. You can see the information about the "TFM_UNPRIV_CODE" in platform/ext/common/armclang/tfm_common_s.sct.
You can refer tfm_spm_mpu_init() in platfrom/ext/target/musca_a/spm_hal.c. There are some MPU region we need to configure for APP RoT in isolation level 2, include the "TFM_UNPRIV_CODE".
If you are interested, you can see some detail about the design of isolation level 2 from here: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isola...
Please check this first. If cannot work, please feel free to tell us.
Thanks,
Edison
-----Original Message-----
From: TF-M tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M
Sent: Friday, December 13, 2019 4:25 AM
To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
Subject: [TF-M] MPU issues, was Re: Regression test issues with IAR port
Next issue.
For some reason the secure image runs into a MemManage exception fairly early in the irq test of the ConfigRegressionIPCTfmLevel2 config and I have not yet been able to figure out why.
It happens in the psa_wait() call in:
---
int32_t tfm_irq_test_1_init(void)
{
tfm_enable_irq(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ);
#ifdef TFM_PSA_API
psa_signal_t signals = 0;
while (1) {
signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK);
---
The exact point of the exception is the SVC call in:
---
__attribute__((naked, section("SFN")))
psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout)
{
__ASM volatile("SVC %0 \n"
"BX LR \n"
: : "I" (TFM_SVC_PSA_WAIT)); }
---
The cause is IACCVIOL, "The processor attempted an instruction fetch from a location that does not permit execution."
The stack frame indicates that it happened on the SVC instruction, but I as far as I can see none of the MPU regions maps the address so I assumed it should be allowed as it should be handled by the background map, which should allow secure access.
If I don't enable the mpu (just skipping the enable call) then all tests run without problems.
I have tried to compare it with an image built with ARMCLANG, and I don't see anything obviously different. The regions are roughly the same, all regions with fixed addresses are the same, the enable bits are the same and the SVC handler is not mapped to any MPU region there either. I wish there were an MPU status register that would tell exactly what region was causing the exception.
The odd thing is that there is an SVC call in the tfm_enable_irq() call prior to the psa_wait() call, and that works.
This is on a Musca A by the way.
Ideas?
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com mailto:thomas.tornblom@iar.commailto:thomas.tornblom@iar.com
Website: www.iar.comhttp://www.iar.com http://www.iar.comhttp://www.iar.com
Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems http://www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
--
TF-M mailing list
TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com Website: www.iar.comhttp://www.iar.com Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems