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
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
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
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
