Hi Samarth,
Depending on what you aim for, you could try to use Trusted Services [1] as a "framework" for SP development. Some highlights what benefits going with TS would provide: - examples for S-EL0 SPs (we have numerous SPs in the repo already) - capability to fetch external components. Ability to: - clone a git repository - override dependency info captured in cmake files - use pre-fetched source code - use pre-built binary - a pattern for platform abstraction and portability - a pattern for portability between SPMC implementations - currently we focus on the OP-TEE SPMC, but the project structure could accommodate S-EL1 SPs too. - cmake based build system - established testing methodology - tests to target host machine (x86) natively - tests to target arm HW. (Currently we use FVP).
The current focus is on S-EL0 SPs,.
If what you do is Hafnium specific the existing tight integration of Cactus to the Hafnium infrastructure can be a value which you may wish to build on. Still AFAIK Cactus was designed to be a test payload and I am not sure how well it could be "productized". Others: please chime in if I am mistaken here.
Note: TS is still not a mature project and thus expect some raw edges.
You can find some TS related presentations here: https://developer.trustedfirmware.org/w/trusted-services/public_videos_and_p...
[1]: https://trusted-services.readthedocs.io/en/integration/
/George
-----Original Message----- From: samarthparikh via TF-A-Tests tf-a-tests@lists.trustedfirmware.org Sent: 27 April 2022 13:02 To: tf-a-tests tf-a-tests@lists.trustedfirmware.org Cc: samarthp samarthp@ymail.com Subject: [Tf-a-tests] [cactus] Configuring & mapping mailbox failing
Hi,
We are trying to create a secure partition based on cactus.
In cactus_main.c there is a mapping of rxtx region for SPM_VM_ID_FIRST + 2. In our case, there would be just one sp and so we are doing the same for SPM_VM_ID_FIRST itself but it goes into panic.
On checking TF-A code, in file spmd_main.c the request FFA_RXTX_MAP_SMC64 is not allowed to be invoked from secure world. So, in any case when CONFIGURE_AND_MAP_MAILBOX which internally calls ffa_rxtx_map and which further invokes smc for FFA_RXTX_MAP_SMC64, it will always fail.
So should the RXTX mailbox always be mapped from Normal World? If that is the correct understanding, then we are confused with the use of CONFIGURE_AND_MAP_MAILBOX in cactus_main.c
The purpose for setting up this RXTX channel is mainly because cactus memory sharing test requires it and we are writing a small test to share memory from non-secure world.
Any clarity, suggestions would be helpful.
Regards,
Samarth