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

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<http://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