TF-A-Tests September 2023

tf-a-tests@lists.trustedfirmware.org

2 participants
2 discussions

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

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

2024

2023

2022

2021

2020

2019

2018

TF-A-Tests September 2023