<Dummy response to get the email through to the mailing list>
From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>
Sent: Wednesday, September 2, 2020 3:43 PM
To: tf-a(a)lists.trustedfirmware.org
Cc: Varun Wadekar <vwadekar(a)nvidia.com>
Subject: GCC compiler option to support "xpaci" instruction
Hi,
We are using gcc-arm-9.2 toolchain and see that this is not supporting the "xpaci" instruction.
Is there any compiler flag that has to be included to support this?
Reference code that uses "xpaci" when PAUTH is enabled -
https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch…
Thanks,
Kalyani
Hi @Olivier<mailto:Olivier.Deprez@arm.com>,
We have been trying to use Cactus as SPMC on Tegra194 (pre 8.4) platforms and have faced the following issues.
1. Cactus_main.c - During cold boot, Cactus checks if the ffa-id for the instance of Cactus == SPM_VM_ID_FIRST. It issues FFA_ID_GET SMC to TF-A which returns the spmc_id in return. But on pre-8.4 platforms the value does not match SPM_VM_ID_FIRST and so the system assumes that the device is running on a post-8.4 CPU. The problem is that TF-A returns the spmc_id for this SMC, which seems incorrect. I don't understand why Cactus needs to know its own VM_ID on pre-8.4 CPUs. Can we assume that only one SPMC can run on pre-8.4?
2. Cactus_ffa_tests.c - The ` ffa_partition_info_get_test` incorrectly queries the partition info for secondary and tertiary VMs on pre-8.4 CPUs.
3. In general the boot tests that execute within Cactus seem incorrect to me. Some tests expect the presence of a non-secure world payload, which is not available at this point in the boot. This leads to numerous crashes and asserts during boot.
4. Cactus incorrectly uses a hard-coded address 0x7300000 as the RX/TX memory base. It should be using a platform defined value instead. We do not support this memory address on Tegra194.
5. The debug UART in Cactus needs rework too. Right now, it only supports PL011 as the UART driver.
6. TF-A SPMD forwards some SMCs to the non-secure world without checking if a non-secure world payload exists. This causes crashes during cold boot.
Please let me know if you have commits for any or all of these issues. We have some WIP commits that we can push to gerrit for review, if required.
Thoughts?
-Varun
Hello arm expects,
While reading the tf-a spec about the section "3.5.1 Register state".
It described that "The MMU must be disabled for a partition that does
not run in S-EL0".
Does this mean that the S-EL1 SP need to create their own page table
and enable the MMU itself. I wonder in this way, it is not very friendly
to a SP developer.
Since the SP can be a verify simple binary, maybe a single driver which
can benefited from the isolation from other partitions.
So in the pointer of developing a single driver. I think it do not need
to care about the MMU configuration. It will be more friendly to be as
easy as developing a user-land binary. The SPMC(SEL2) can do this
configure for the SEL1's page-tables and enable MMU for SEL1 before jump
into the SP.
So I want to discuss here to understand the meaning behind it.
Cheers,
Feng
