Hi Alan,
Looks like this is the still classic case, but unfortunately that there is no defined design at the current stage.
Heard you were working on an solution for this, and got some issues when non-secure preempts secure execution, since your scheduler works in thread mode so cannot update secure context while scheduling – please correct me if my understanding
is wrong. Is this mail a follow up or another thread just focus on discussion of the cooperative scheduling document?
BR
/Ken
From: DeMars, Alan <ademars@ti.com>
Sent: Friday, March 20, 2020 2:27 AM
To: Ken Liu <Ken.Liu@arm.com>
Cc: 'tf-m@lists.trustedfirmware.org' <tf-m@lists.trustedfirmware.org>
Subject: RE: SPM_IDLE
Ken,
Our use case is to support a “secure driver”:
-
A peripheral can only be accessed in secure mode.
-
The peripheral is configured and a hardware process is triggered within the peripheral.
-
When the process completes, a secure interrupt is triggered.
-
The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished.
Alan
Hi Alan,
It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable?
/Ken
Mention is made to “SPM_IDLE” in the Cooperative Scheduling Rules document:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBuild/artifact/build-docs/tf-m_documents/install/doc/user_guide/html/docs/design_documents/tfm_cooperative_scheduling_rules.html
I’m struggling to understand section 8.3.5 which references SPM_IDLE but doesn’t really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS
thread is waiting for an asynchronous event in the secure service it has called.
Alan