Hi Akshay

Yes, there is a test [1] to exercise crash console in TF-A. The test is performed with the help tf-a-ci-scripts, wherein a patch is applied in bl31_main() which induces a panic(). Look at CI run [2] artefacts, where UART1 log captures the console log for crash

[1] https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/19026
[2] https://ci.trustedfirmware.org/job/tf-a-builder/2538538/artifact/

Thanks
Manish Pandey

From: Belsare, Akshay via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 20 September 2023 12:21
To: Michal Simek <monstr@monstr.eu>; tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>; tf-a-tests@lists.trustedfirmware.org <tf-a-tests@lists.trustedfirmware.org>
Subject: [TF-A] Re: Console scope flags/ console switch state - understanding
 
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@lists.trustedfirmware.org>
>Sent: Monday, September 18, 2023 2:17 PM
>To: tf-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@lists.trustedfirmware.org To unsubscribe send an email
>to tf-a-leave@lists.trustedfirmware.org
--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org