TF-A Community,
This is to notify that we are planning to target the Trusted Firmware-A 2.9 release during the middle of May 2023 as part of the regular 6 month cadence.
The aim is to consolidate all TF-A work since the 2.8 release. As part of this, a release candidate tag is targeted to be created and release activities commence from 10th May 2023 across all TF-A repositories.
Essentially we will not merge any major enhancements from this date until the release is made.
Please ensure any patches desired to make the 2.9 release are submitted in good time to be complete by 9th May 2023.
Any major enhancement patches still open after that date will not be merged until after the release.
This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Job. In addition a TF-RMM repository release will be made that is compatible with v2.9.
We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start normally completing within 7-10 working days.
Regards
Joanna Farley
HI, tf-a-test community,
I have one question about the smmuv3 testing on fvp.
Below is the SMMUV3 related parameters passed to fvp suggested in https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem… to enable 3rd world options for RME (CCA).
pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3
pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B
pci.pci_smmuv3.mmu.root_register_page_offset=0x20000
What I want to try with fvp with SMMU is generating transactions from the peripheral devices through the SMMU to access some memory ranges.
I found that FVP doesn’t have any peripherals connected through the SMMU, shown in the dts file in the linux repository for FVP, except PCIe (i.e., pci: pci@40000000 in fvp-base-revc.dts)
Is there any way that I can attach any peripherals through the SMMU or generate transactions to SMMU directly to make SMMU walks the stream table, which allows the device to access memories?
I checked the spm/cactus/cactus_tests/cactus_tests_smmuv3.c
But seems that this test case is not executable on the fvp? I got the “FFA_VERSION” not supported error message.
Moreover, it seems that this test just send command to emulated smmutesting engine and do memcopy operation.
I cannot understand how does it work even without initializing stream table (as far as I know it is initialized with kernel driver).
Sincerely
Jaehyuk
Hi Dan,
Thanks for your feedback!
I've tested these patches with our platform, but have not tested with any
upstream platforms. I added tests for the OS-initiated mode code path in
TF-A-Tests [1] that we can run against upstream platforms to verify. I'm
not sure how I can get a hold of an upstream platform board; it'd be much
appreciated if perhaps maintainers of upstream platforms could help run the
tests?
In theory, any platform that supports CPU_SUSPEND would be able to support
both platform-coordinated mode and OS-initiated mode, since the power state
coordination happens either in the PSCI library implementation or in an
HLOS.
Wing
[1] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/17684
On Fri, Nov 11, 2022 at 9:43 AM Okash Khawaja <okash(a)google.com> wrote:
> Hi Dan,
>
> The idea with OSI mode is that HLOS will have more awareness about
> power sequences and hence will be able to optimise power usage better
> (e.g. using heuristics) if it had more control. This means having HLOS
> which contains right modules for a specific platform and specific use
> case, if we want to do a power/perf comparison between OSI and
> plat-coordinated modes.
>
> On Fri, Nov 11, 2022 at 5:08 PM Dan Handley via TF-A
> <tf-a(a)lists.trustedfirmware.org> wrote:
> >
> > Hi Wing
> >
> > Thanks for your contribution. Are there any upstream platforms that
> these patches have been tested with? If so, it would be good to have
> visibility of the sw stack under test. Ideally, there would be at least 1
> platform that supported both platform-coordinated mode and OS-initiated
> mode, so that a fair power/performance comparison can be done.
> >
> >
> >
> > Regards
> >
> > Dan.
> >
> >
> >
> > From: Wing Li via TF-A <tf-a(a)lists.trustedfirmware.org>
> > Sent: 10 November 2022 05:53
> > To: tf-a(a)lists.trustedfirmware.org; tf-a-tests(a)lists.trustedfirmware.org
> > Subject: [TF-A] PSCI OS-initiated mode
> >
> >
> >
> > Hi,
> >
> > The PSCI specification defines two different power state coordination
> modes for CPU_SUSPEND that can be used to put a core or a group of cores
> into a low-power state. These modes are the platform-coordinated mode
> (default) and the OS-initiated mode (optional). OS-initiated mode is
> currently not supported by TF-A, while both modes are supported by the
> Linux Kernel.
> >
> > Requesting reviews for the patches [1] adding support for OS-initiated
> mode in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
> comments are much appreciated.
> >
> > Thanks in advance!
> >
> > Wing
> >
> > [1] https://review.trustedfirmware.org/q/topic:psci-osi
> >
> > --
> > TF-A mailing list -- tf-a(a)lists.trustedfirmware.org
> > To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org
>
Hi All,
I find that in spm/cactus/cactus_tests/smmuv3_test_engine.h, the
tf-a-tests clearly shows some MMIO interfaces for the SMMUv3 Test
Engine. But, I need help finding a manual about these MMIO interfaces.
For example, in this .h file, it says the offset of the start address
is in 0x28 (BEGIN_OFF), but I cannot find which manual defines it. It
refers to the "SMMUv3TestEngine - trace" Section on FVP manual, but I
still cannot find the mapping in this section. Actually I don't know
how to "understand" the trace Section.
I also try to dump the FVP model but I can not find it. It only has
SMMU configurations, but not this engine.
Can someone help me?
Sincerely,
WANG Chenxu
Hi,
The PSCI specification defines two different power state coordination modes
for CPU_SUSPEND that can be used to put a core or a group of cores into a
low-power state. These modes are the platform-coordinated mode (default)
and the OS-initiated mode (optional). OS-initiated mode is currently not
supported by TF-A, while both modes are supported by the Linux Kernel.
Requesting reviews for the patches [1] adding support for OS-initiated mode
in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
comments are much appreciated.
Thanks in advance!
Wing
[1] https://review.trustedfirmware.org/q/topic:psci-osi
Hi all --
I was wondering what the intended procedure was for adding and running
platform-specific TF-A tests?
I see a plat/ directory in the tf-a-test/tftf/tests directory, so I assume
I should use that, but I don't see a way to actually point to it normally.
Has anyone tried this before?
I did get it working in a hacky way[0], but I was hoping that there was an
intended path.
My use-case is to test some platform-specific hardware from TF-A.
Thanks!
Ross
[0] I added a `tests-platform.mk` pseudo test that looks in the plat
directory for a platform.mk, just like for finding the platform's .c
sources. Then it looks for the test pointed to by PLAT_TESTS.
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
