- TF-A-Tests - lists.trustedfirmware.org

Trusted Firmware v2.10 Release Announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.10 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM and TF-A OpenCI Scripts/Jobs 2.10 releases involving the tagging of multiple repositories. These went live on 22nd November 2023. Please find references to tags and change logs at the end of this email. Many thanks to the community for the active engagement in delivering this release! Notable Features of the Version 2.10 Release are as follows: TF-A/EL3 Root World * New Features: * Firmware handoff library support * Improvements to BL31 runtime exception handling * Context management refactoring for RME/4 worlds * Gelas, Nevis & Travis CPUs support * V8.9 features enabled (FEAT_ HAFT, RPRFM, LRCPC3, MTE_PERM) TF-A Boot BL1/BL2 * New Features * Trusted Boot support for ECDSA (Elliptic Curve Digital Signature Algorithm) * Migrated to PSA crypto API’s * Improved the GUID Partition Table (GPT) parser. * Various security Improvements and threat Model updates for ARM CCA * Signer id extraction Implementation Hafnium/SEL2 SPM * New Features: * FF-A v1.2: FFA_YIELD with time-out; EL3 SPMDs LSPs communication; memory sharing updates. * Memory region relative base address field support in SP manifests. * Interrupt re-configuration hypervisor calls. * Memory management: S2 PT NS/S IPA split * SMCCCv1.2+ compliance fixes. * Feature parity test improvements, EL3 SPMC and Hafnium (S-EL2 SPMC) TF-RMM/REL2 * New Feature/Support * Fenimore v1.0 EAC5 aligned implementation. * TFTF Enhancements for RME testing * Initial CBMC support * NS SME support in RMM * BTI support for RMM Errata * Errata implemented (1xCortex-X2/ Matterhorn-ELP, 1xCortex-A710/Matterhorn, 1xNeoverse N2/Perseus, 2xNeoverse V2/Demeter, Makalu ELP/Cortex X3, Klein/Cortex-A510) * Fix some minor defects with version in a few errata that applies for some follow up revisions of the CPUs. (Neoverse V1, Cortex-X2, Cortex-A710) TF-A Tests * Core * Added errata management firmware interface tests. * Added firmware handoff tests. * Introduced RAS KFH support test. * SPM/FF-A * Support SMCCCv1.2 extended GP registers set. * Test SMCCC compliance at the non-secure physical instance. * Test secure eSPI interrupt handling. * Test FF-A v1.2 FFA_PARTITION_INFO_GET_REGS interface. * RMM * Added FPU/SVE/SME tests * Added multiple REC single CPU tests. * Added PAuth support in Realms tests. * Added PMU tests. Platform Support * New platforms added: * Aspeed AST2700, NXP IMX93, Intel Agilex5, Nuvoton NPCM845x, QTI MDM9607, MSM8909, MSM8939, ST STM32MP2 Release tags across repositories: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.4.0 Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.10/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver… https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10 https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0 Regards, Olivier.

6 months, 3 weeks

1
1
0 0

Firmware-A v2.10 release code freeze notification

by Olivier Deprez

Hi All, The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023. Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…). Closing out the release takes around 6-10 working days after the code freeze. Preparations tasks for v2.10 release should start in coming month. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. Thanks & Regards, Olivier.

7 months, 1 week

1
3
0 0

PSCI patches fail TF-A-tests on 2 platform configs

by Yann Gautier

Hi, Patrick has sent 2 correction patches for PSCI stack in OSI mode there: https://review.trustedfirmware.org/q/topic:%22fix_psci_osi%22 But when running CI+2, there are 2 platforms for which 2 PSCI OSI tests are failing: fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-cortexa57x4a53x4-debug fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-aemv8a-debug I'm not familiar with those test configs, but when checking lava logs, I see those traces for failing tests: 2024-01-11T14:21:59 > Executing 'CPU suspend to powerdown at level 1 in OSI mode' 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 TEST COMPLETE Failed 2024-01-11T14:22:03 Wrong value: expected 0, got -3 2024-01-11T14:22:03 > Executing 'CPU suspend to powerdown at level 2 in OSI mode' 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Saving system context 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Restoring system context 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 TEST COMPLETE Failed 2024-01-11T14:22:03 Wrong value: expected 0, got -3 The "Resumed from suspend state" message interleaved with "Going into suspend state" seem strange, but I cannot say what could be wrong there. Maybe there is something wrong with the TF-A patches? Or the platforms tests or configs need to be updated? If you have any clue that would be very helpful! Thanks, Yann

11 months, 1 week

1
0
0 0

Re: [TF-A] Console scope flags/ console switch state - understanding

by Belsare, Akshay

Hi, Since the discussion is already going on in TF-A list extending it to TF-A Tests list as well. Does TF-A Tests have test cases for console testing in TF-A? more specifically to test the CRASH console? Regards, Akshay Belsare >-----Original Message----- >From: Michal Simek via TF-A <tf-a(a)lists.trustedfirmware.org> >Sent: Monday, September 18, 2023 2:17 PM >To: tf-a(a)lists.trustedfirmware.org >Subject: [TF-A] Console scope flags/ console switch state - understanding > >Hi, > >I am looking at how console flags are used and setup. >In porting guide I see > >Function : bl31_plat_runtime_setup() [optional] >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >:: > > Argument : void > Return : void > >The purpose of this function is allow the platform to perform any BL31 runtime >setup just prior to BL31 exit during cold boot. The default weak >implementation of this function will invoke ``console_switch_state()`` to switch >console output to consoles marked for use in the ``runtime`` state. > >Some platform are calling it but some of them not (like our Xilinx one). > >Tegra has in tegra_pwr_domain_power_down_wfi() > console_flush(); > console_switch_state(0); > >which is what none other has. >Should console_flush() be called by default all the time when console is >switched and also disabled when system goes down? >Why console_switch_state(CONSOLE_FLAG_RUNTIME) is not called from >bl31_main() when before bl31_plat_runtime_setup() is called we have >console_flush() already? > > > >The second part of this how console scope is setup. >Implementation is clear and set. > >void console_set_scope(console_t *console, unsigned int scope) { > assert(console != NULL); > > console->flags = (console->flags & ~CONSOLE_FLAG_SCOPE_MASK) | >scope; } > >The commit cc5859ca19ff ("Multi-console: Deprecate the >`finish_console_register` >macro") when finish_console_register is called (DCC is exception here) is >setting up CONSOLE_FLAG_BOOT and CONSOLE_FLAG_CRASH by default. > >And most of platforms is calling console registration with calling >console_set_scope() where new flags are recorded BOOT only, >BOOT/RUNTIME, RUNTIME only or BOOT/RUNTIME/CRASH. > >I would like to understand what should be the right behavior. >Why are platforms removing CRASH flag after registration? (I see that a lot of >platforms are having private plat_crash_console_init() but pretty much crash >console is the same with regular console). >Why runtime console is setup directly in bl31_early_platform_setup2 when >guidance is saying that it should be done much later? > >Also commit 63c52d0071ef ("plat/common/crash_console_helpers.S: Fix >MULTI_CONSOLE_API support") removed CONSOLE_FLAG_CRASH from >plat_crash_console_init but only from 64bit version. In 32bit version there is >still there. It suggest that any C code should be called. >Do we really need CONSOLE_FLAG_CRASH? > >Thanks, >Michal > >-- >Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 >w: www.monstr.eu p: +42-0-721842854 >Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx >Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx >Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs TF-A maintainer - Xilinx >ZynqMP/Versal/Versal NET SoCs >-- >TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email >to tf-a-leave(a)lists.trustedfirmware.org

1 year, 3 months

1
0
0 0

Standalone python version of generate_test_list.pl?

by Jim Ray

Hello, There's an effort inside of Google to make builds more hermetic across the board. One of the challenges we ran into was supporting the transitive dependencies of generate_test_list.pl, namely XML::LibXML. Since this isn't in the perl standard library, we have to add what amounts to an entire sysroot with a bunch of dependencies just to support this one library. Not impossible (and to be clear, this is the route that we went with), but not ideal either. Another approach that we explored was rewriting generate_test_list.pl in python. XML parsing is in python's standard library and many of our engineers are more familiar with it, so we thought this would be a reasonable choice. We wrote the script, and it seems to work (with some caveats that I'll discuss below). However, we don't want to diverge from upstream, hence why I'm here :). The script is approximately the same length as the original script and supports all of the same features and checking, with one catch. The standard library's XML parsing module doesn't support entity expansion, which is a feature used in many places within TFTF (see, for example, tests-standard.xml). This is done for security reasons and I haven't found a way around it without resorting to xml parsers outside of the standard library (which kinda defeats the purpose). To resolve this, we use xincludes instead, meaning that tests-standard.xml (for example) would have to be rewritten to use the new syntax. For example, tests-standard.xml would look like the following: <document> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="tests-tftf-validation.xml"/> ... rest of includes here... </document> Any thoughts on this? If you're okay with this approach we can put our CL up for review. We also experimented with doing some hand-parsing to support entity expansion and I suspect that there's *some* way to convince entity expansion to occur within the standard library, but wanted to take your temperature on the above changes before pursuing those further. Thanks, Jim

1 year, 7 months

3
4
0 0

TF-A V2.9 Bundle Release

by Joanna Farley

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.9 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium and TF-A OpenCI Scripts/Jobs 2.9 releases involving the tagging of multiple repositories. Aligned but not yet part of the release is Trusted Firmware-A Realm Management Monitor v0.3.0. These went live on 23rd May 2023. I would like to thank all of the contributors for their excellent work and achievements since the last release. Thanks Joanna Notable Features of the Version 2.9 Release are as follows: TF-A/EL3 Root World * New Features: * Support for PSCI OS initiated mode * Architecture feature support for FEAT_TCR2, FEAT_GCS, FEAT_HCX, FEAT_SME2, FEAT_PIE/POR, FEAT_MPAM. * System registers access trap handler * Introduction to dynamic detection of features * Refactoring: * Context management * RAS extension exception handling and crash reporting. * Distinguish between BL2 as TF-A entry point or BL2 running at EL3 exception level. * General Support * CPU Support for Chaberton and Blackhawk for TC2023 * Eighteen (18) Errata Mitigations for Cortex X2/X3/A710/A510/A78/A78C and Neoverse N2/V1 family CPU’S * Errata Management Firmware Interface implementation supported for version 1.0 of the public specification TF-A Boot BL1/BL2 * New Feature/Support * Support for Trusted Boot rooted into RSS RoT on TC2022 platform. * Support for PSA attestation scheme with Measured Boot rooted into RSS on TC2022 platform * Migration to mbedTLS 3.x as the default cryptography library retaining backwards compatibility with mbedTLS 2.x * Improvements and hardening of Arm CCA boot and attestation support. * Hardening efforts in the X.509 certificate parser, including a security fix (TFV-10 CVE-2022-47630) Hafnium/SEL2 SPM * FF-A v1.2 ALP0 Specification Early Adoption Support * Implemented ppartition info get ABI using GP registers. * Group0 secure interrupt handling delegation. * Improved console log ABI. * FF-A v1.1 REL0 Specification Support * Interrupt handling (S-EL0 partition signalling, added action to Other-S-Int, allow a physical interrupt to be routed to a specified PE). * Memory sharing (structures updates supporting FF-A backwards compatibility, share/lend/donate memory to multiple borrowers, normal/secure fragmented memory sharing). * Power management (events relayed to the SPMC and removed limitations). * Indirect messaging (buffer synchronization and ownership transfer rules). * General Support * SPMC manifest to declare non-secure and secure system memory address ranges. * Hardened SP manifest memory regions boot time validation. * CI migration to LLVM/clang 15.0.6 * Removal of non-VHE build and test configurations. * Added EL3 SPMC test configurations using the Hafnium's CI infrastructure. TF-A Tests * New Test Support * Errata Management Firmware Interface testing * FF-A v1.1 feature testing * Realm Management Extension feature testing * New Architecture Specific feature testing related to v8.8 * 1 new platform port (RD-N2-Cfg3) TF-RMM/REL2 * New Feature/Support * Added support to create Realms which can make use of SVE, if present in hardware. * Refactor and improved the Stage 1 translation table library lib/xlat API to better fit RMM usage. * Add PMU support for Realms as described by RMM v1.0 Beta0 specification. * Support getting DRAM info from the Boot manifest dynamically at runtime. * RMM can now support the 2nd DDR bank on FVP * Define a unit test framework using CppUTest for RMM. * Added unit tests for granule, slot-buffer and Stage 1 translation table lib xlat. * Improvements to fake-host and unit tests framework. * Build improvements in RMM Platform Support * 1 new platform added, the Allwinner T507 SoC * 26 platforms updated from 14 providers * 17 different driver updates OpenCI * First release done solely relying on Trustedfirmware.org OpenCI Patch Statistics Across all Repositories * 1403 Patches merged since v2.8 November 2022 release Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes from the previous release. TF-A [4], TF-A Test [5], Hafnium [6], TF-A OpenCI Scripts [7] and TF-A OpenCI Jobs [8] repositories are available along with the compatible TF-RMM repository [9] and changelog [10]. [1] https://trustedfirmware-a.readthedocs.io/en/v2.9/change-log.html#id1 [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… [3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.9/change-log.html#vers… [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.9 [5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.9 [6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.9 [7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.9 [8] https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.9 [9] https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.3.0 [10] https://tf-rmm.readthedocs.io/en/tf-rmm-v0.3.0/about/change-log.html#v0-3-0

1 year, 7 months

1
0
0 0

TF-A v2.9 Release Schedule

by Joanna Farley

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

1 year, 8 months

1
0
0 0

Question about SMMU testing

by Lee, Jaehyuk

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

1 year, 8 months

3
3
0 0

Re: [TF-A] Re: PSCI OS-initiated mode

by Wing Li

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 >

1 year, 9 months

6
10
0 0

Any manuals for SMMUv3 Test Engine?

by Chenxu Wang

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

2 years

3
3
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A-Tests