Actually, I want to simply use the Cactus OS as the initial test
environment, and finally replace it. Because Cactus is easier to understand
(but OP-TEE is more complex).
Also, I want to use the Hafnium (with SEL2 extension) to manage the
multiple Cactus OSes, and route the "SMC" calls to the corresponding OS.
According to your words, I think I should
(1) Create a service to receive SMC calls from Normal World OS, which
includes specific smc_fid, like this.
(2) In the handler, "ERET" it to Hafnium, and then "ERET" to specific
Cactus OSes according to the smc_fid
(3) Modify the Cactus OS to handle it.
Is it right? If NOT, I may consider to use OP-TEE.
Olivier Deprez <Olivier.Deprez(a)arm.com> 于2021年9月27日周一 下午3:37写道：
> Few background questions to understand the request better:
> -Is the intent to enable the SEL2 arch extension, or use the legacy model
> without secure virtualization?
> -Do you intend to use Cactus as an initial test environment with a final
> goal is to replace it by a real TOS?
> -If the ask is about how to write a TA, did you consider existing
> solutions like OP-TEE and relevant documentation?
> In general TA refers to a SW component running at SEL0 on top of a TOS at
> What you call "Cactus OS" is really just a sample test payload running at
> It's not a TOS in terms of loading Trusted Applications, providing
> services (system calls), managing memory and IPC.
> The starting point should be the FF-A specification (
> You can repurpose Cactus to host a service at SEL1, which can be called by
> the NWd (TFTF test framework).
> There is normally no need to modify EL3.
> The below sample illustrate the message passing between TFTF at NS EL2,
> and Cactus at SEL1:
> Please also have a look at the component documentation:
> Depending on what you want to achieve, there are also solutions around
> SEL0 partitions (not involving a TOS), or the Trusted Services project.
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chenxu
> Wang via TF-A <tf-a(a)lists.trustedfirmware.org>
> Sent: 27 September 2021 05:44
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] How to write a Trsuted Application?
> Hi all,
> I want to write a TA which will be called from the Normal World and be
> handled by a specific Trusted OS. Currently, I am using 3 Cactus OS
> (provided by TF-A-Tests) in SEL1, and a Hafnium in SEL2. Here is my partial
> building cmd
> make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1
> ARM_ARCH_MINOR=4 PLAT=fvp DEBUG=1
> SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json all fip
> I have created some EL3 services at services/std_svc, but have not created
> a TA.
> In my view, to call the TA, I think I should pass (1) the ID of the TA
> (but I am not sure how to get the ID) (2) several parameters, which may be
> loaded into registers. Here may be a calling process.
> ldr x0,=0xdeadbeef // loading ID
> ldr x1,=0x11111 // input parameters
> ldr x2,=0x22222 // input parameters
> smc #0
> Then I think I should write a corresponding handler (of the TA) in Cactus
> OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA.
> However, I don't know how to do it. Can you provide some useful examples?
> Wang Chenxu
I want to write a TA which will be called from the Normal World and be
handled by specific Cactus OS.
Specifically, to call the TA, I think I should pass (1) the ID of the TA
(but I am not sure how to get the ID) (2) several parameters, which may be
loaded into registers. Here may be a calling process.
ldr x0,=0xdeadbeef // loading ID
ldr x1,=0x11111 // input parameters
ldr x2,=0x22222 // input parameters
Then I think I should write a corresponding handler (of the TA) in Cactus
OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA.
However, I don't know how to do it. Can you provide some useful examples?