There are 4 functions that have different logic at level 1 and level 2 that  will affect timings:

Tfm_spm_partition_get_privileged_mode()

Tfm_get_secure_mem_region_attr()

Secure_mem_attr_check()

Tfm_has_access_to_region()

 

I guess the level 1 checks are slightly faster than level 2.

 

Chris

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Tuesday, November 9, 2021 5:45 AM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Another PSoC problem

 

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

 

As Chris mentioned, it should be related with a race condition problem when inserting messages – but the question is why Isolation level 2/3 is not affected, as RPC message handling happen inside PendSV always no spite of isolation levels – or I am wrong with this logic?  -- digging now, will let you know the result. I guess add critical section protection in ‘ipc_messaging’ should help.

 

This heavy test is useful.

 

/Ken

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: Tuesday, November 9, 2021 9:19 PM
To: tf-m@lists.trustedfirmware.org
Subject: Re: [TF-M] Another PSoC problem

 

Behaves the same with IAR.

/Thomas

Den 2021-11-09 kl. 01:54, skrev chris.brand--- via TF-M:

Build command is:

cmake -S . -B output -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DTEST_NS_MULTI_CORE=ON -DTFM_ISOLATION_LEVEL=1

 

The result is a hang at this point:

> Executing 'MULTI_CLIENT_CALL_HEAVY_TEST'

  Description: 'Multiple outstanding NS PSA client calls heavyweight test'

Totally 5 threads for test start

Each thread run 0x20 rounds tests

 

Some experimentation shows that:

It happens with both gcc and armclang (unable to test IAR).

It doesn’t always happen, but does seem to hang more often than it succeeds.

It doesn’t happen with TFM_ISOLATION_LEVEL=2.

 

It looks like this test was passing consistently before 5e68b11764673ee32bae0de8ecf3cde45cc55ea1, so I guess this is another scheduling issue. There’s not a lot of code that differs with TFM_LVL, so I wonder if there’s a race condition that is always present but just doesn’t happen to get hit at TFM_LVL=2…?

 

BTW, being able to build just the one test is extremely useful!

 

Chris Brand

 

Cypress Semiconductor (Canada), Inc.

Sr Prin Software Engr

CSCA CSS ICW SW PSW 1

Office: +1 778 234 0515

Chris.Brand@infineon.com

 

 

 

--

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 Website: www.iar.com
Twitter:
www.twitter.com/iarsystems