I'm working on adding IARARM as a toolchain for the Musca S1 (and B1) and I'm running into an issue where the NS image can not properly access the UART.
The NS code loops trying to check the UART status @0x40102030, which holds the value 0x301, as can be seen with the debugger and also from the secure code, but when read by the NS code it returns 0, with no error.
As this code works when building with ARMCLANG and GNUARM, I assume there is some memory protection that gets incorrectly setup when I build with the IAR toolchain, but I'm struggling to find where this gets setup. I assume it is done in the secure image.
Any hints where i should be looking?
Thanks, Thomas
Compare the SAU/MPU (PPC?) regions and the polling CONTRO.nPRIV may show up the problem.
This looks like the current program does not have the permission to access the register, but the protection unit does not return an exception and just access as nop.
Is it work under AN521? If so I can have a try locally.
/Ken
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: Friday, September 24, 2021 5:56 PM To: Ken Liu via TF-M tf-m@lists.trustedfirmware.org Subject: [TF-M] Trouble building Musca S1 with IAR
I'm working on adding IARARM as a toolchain for the Musca S1 (and B1) and I'm running into an issue where the NS image can not properly access the UART.
The NS code loops trying to check the UART status @0x40102030, which holds the value 0x301, as can be seen with the debugger and also from the secure code, but when read by the NS code it returns 0, with no error.
As this code works when building with ARMCLANG and GNUARM, I assume there is some memory protection that gets incorrectly setup when I build with the IAR toolchain, but I'm struggling to find where this gets setup. I assume it is done in the secure image.
Any hints where i should be looking?
Thanks, Thomas --
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
Hi Thomas, Ken,
Also note that there is a hardware bug in Musca-B1 and Musca-S1 that prevents unprivileged access to APB Expansion peripherals (such as the UART). See https://developer.arm.com/documentation/101835/0000/Hardware-bug-software-wo...
As far as I know the workaround in the above doc is not implemented in TF-M. It may be a good idea to add it though.
So if you find that CONTROL.npriv is set to 1 (unprivileged) when executing the IAR build, but set to 0 at the same point in the GCC build, then you are running into this bug. Aligning the privilege levels between IAR and GCC builds would avoid it.
Kind regards, Jamie
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: 24 September 2021 11:32 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Trouble building Musca S1 with IAR
Compare the SAU/MPU (PPC?) regions and the polling CONTRO.nPRIV may show up the problem.
This looks like the current program does not have the permission to access the register, but the protection unit does not return an exception and just access as nop.
Is it work under AN521? If so I can have a try locally.
/Ken
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, September 24, 2021 5:56 PM To: Ken Liu via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Trouble building Musca S1 with IAR
I'm working on adding IARARM as a toolchain for the Musca S1 (and B1) and I'm running into an issue where the NS image can not properly access the UART.
The NS code loops trying to check the UART status @0x40102030, which holds the value 0x301, as can be seen with the debugger and also from the secure code, but when read by the NS code it returns 0, with no error.
As this code works when building with ARMCLANG and GNUARM, I assume there is some memory protection that gets incorrectly setup when I build with the IAR toolchain, but I'm struggling to find where this gets setup. I assume it is done in the secure image.
Any hints where i should be looking?
Thanks, Thomas --
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
Thanks Jamie,
This is indeed the issue.
npriv is 0 at the entry to the NS main() for ARMCLANG and GNUARM but 1 for the IAR build.
I suspect there is something I need to fix in the secure link script to get the SAU setup properly.
Cheers, Thomas
Den 2021-09-24 kl. 13:33, skrev Jamie Fox:
Hi Thomas, Ken,
Also note that there is a hardware bug in Musca-B1 and Musca-S1 that prevents unprivileged access to APB Expansion peripherals (such as the UART). See https://developer.arm.com/documentation/101835/0000/Hardware-bug-software-wo... https://developer.arm.com/documentation/101835/0000/Hardware-bug-software-workaround/S1-Secure-and-Non-secure-privilege-registers-hardware-bug
As far as I know the workaround in the above doc is not implemented in TF-M. It may be a good idea to add it though.
So if you find that CONTROL.npriv is set to 1 (unprivileged) when executing the IAR build, but set to 0 at the same point in the GCC build, then you are running into this bug. Aligning the privilege levels between IAR and GCC builds would avoid it.
Kind regards,
Jamie
*From:*TF-M tf-m-bounces@lists.trustedfirmware.org *On Behalf Of *Ken Liu via TF-M *Sent:* 24 September 2021 11:32 *To:* tf-m@lists.trustedfirmware.org *Cc:* nd nd@arm.com *Subject:* Re: [TF-M] Trouble building Musca S1 with IAR
Compare the SAU/MPU (PPC?) regions and the polling CONTRO.nPRIV may show up the problem.
This looks like the current program does not have the permission to access the register, but the protection unit does not return an exception and just access as nop.
Is it work under AN521? If so I can have a try locally.
/Ken
*From:*TF-M <tf-m-bounces@lists.trustedfirmware.org mailto:tf-m-bounces@lists.trustedfirmware.org> *On Behalf Of *Thomas Törnblom via TF-M *Sent:* Friday, September 24, 2021 5:56 PM *To:* Ken Liu via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org> *Subject:* [TF-M] Trouble building Musca S1 with IAR
I'm working on adding IARARM as a toolchain for the Musca S1 (and B1) and I'm running into an issue where the NS image can not properly access the UART.
The NS code loops trying to check the UART status @0x40102030, which holds the value 0x301, as can be seen with the debugger and also from the secure code, but when read by the NS code it returns 0, with no error.
As this code works when building with ARMCLANG and GNUARM, I assume there is some memory protection that gets incorrectly setup when I build with the IAR toolchain, but I'm struggling to find where this gets setup. I assume it is done in the secure image.
Any hints where i should be looking?
Thanks, Thomas
--
*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.com mailto:thomas.tornblom@iar.comWebsite: www.iar.com http://www.iar.com Twitter: www.twitter.com/iarsystems http://www.twitter.com/iarsystems
tf-m@lists.trustedfirmware.org
-
Jamie Fox -
Ken Liu -
Thomas Törnblom