- TF-A - lists.trustedfirmware.org

by Manish Pandey2

Hi, I am writing this email to find out any legacy platforms supports in TF-A (upstream or downstream) which does not have any NS-EL2 component running. Because NS-EL2 is present but unused EL3 also need to do a minimal initialization of EL2. The side effect of this is, TF-A currently has extra code in generic path (e.g. cm_prepare_el3_exit() ) to cater for these platforms which is not required for most others. The most likely reason why TF-A introduced support for systems without NS-EL2 was because of UEFI implementation for Windows which didn't initialize NS-EL2 properly. Given that the UEFI spec has said "Use the highest 64 bit non secure privilege level available" for a long time now we are safe to assume that any UEFI implementation will handover to windows at NS-EL2. (similar to Linux) Considering that there are very few platforms which need this code and to keep backward compatibility, we propose to introduce a macro like "INIT_UNUSED_NS_EL2" and guard the code under this[1]. Keep this flag default disabled and get rid of it( along with code) altogether in next couple of releases, if we are certain that none of the platforms using it. Please let me know if you are aware of any such platform configuration. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/22716 Thanks Manish

1 year, 2 months

2
2
0 0

EHF + OP-TEE

by brian.neely＠analog.com

Hello, Are EHF and OP-TEE (opteed) designed to work together? I'm seeing some strange behavior when NS interrupts are routed to EL3 as FIQs (due to EHF), but before I dig into it further I wanted to confirm if EHF + OP-TEE is a valid combination. Some background: Our system, which uses OP-TEE, has some "aggregated interrupts" that contain both secure and non-secure sources, for which we wanted to use SDEI to filter and dispatch to Linux (and SDEI requires EHF). Thanks! -Brian

1 year, 2 months

4
4
0 0

Console getc() callback

by Sandrine Bailleux

Hi everyone, As you may know, console drivers in TF-A are required to provide a number of callbacks. One of them is getc() (to read a character from the console). Even though most platform ports provide a valid implementation of it, it does not seem to be called anywhere in the code base today, effectively qualifying it as dead code. I did a bit of git history digging and from what I've seen, the very first public version of TF-A (v0.2!) already had a getc() callback in the Arm PL011 UART driver. So my guess is that all subsequent UART drivers added after that followed the same approach. When the multi-console framework was introduced, it naturally catered for this feature as well. However, taking a step back, I wonder why we introduced getc() in the first place... Unlike other firmwares (like U-boot or EDK2), TF-A does not implement any kind of interactive user shell. And from a security point of view, getc() constitutes an attack vector into TF-A, which might allow an attacker to inject arbitrary data. So keeping this functionality without any valid use case sounds like a bad idea to me. Now, even though getc() is not used in upstream TF-A code right now, I realize there might be downstream / internal test setups which need it. For example, for firmware recovery purposes (receiving a backup firmware over a serial interface) or automated tests setups (some script driving a test session using some communication protocol over a serial interface). Is anyone depending on such use cases? If not, then I suggest we consider removing getc() feature altogether. We could always bring it back when there is a real use case for it (it will survive through git history). At the very least, I would like to disable getc() by default. Enabling it would require setting a build flag. Any thoughts or concerns? Best regards, Sandrine

1 year, 2 months

4
6
0 0

Convert fiptool to Python script

by Varun Wadekar

Hello, We use fiptool extensively to generate the FIP blobs for NVIDIA platforms. But, we encountered the following issues during deployment. 1. fiptool has a dependency on the host machine for OpenSSL and gcc. 2. fiptool resides under the TF-A repo and is used by Hafnium and SPs. This creates a cross-repository dependency. As a workaround, we ship a prebuilt fiptool. But, due to OS dependency, this approach is not scalable across OS versions. E.g. One OS distribution might be using a lower OpenSSL version compared another, creating an incompatibility. I was thinking if converting fiptool to a python script might help resolve these issues. Sptool was converted into a Python script, so was wondering if anyone has tried converting fiptool to a Python script too. -Varun

1 year, 2 months

3
9
0 0

Re: Workaround for ARM Cortex-A78AE Erratum 1941500 is not enabled

by Matthias Rosenfelder

Hi, the code is still incorrect after half a year. It has been changed twice, without fixing it. There was no response to the report I created [1]. If there is no interest / lack of response I may get the impression that my contributions are not welcomed at TF-A. Thus, I decided to not report any issues in the future. Sadly, this is how the open source idea dies - at least for this project. Best Regards, Matthias [1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [Banner]<http://www.nio.io> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. You may NOT use, disclose, copy or disseminate this information. If you have received this email in error, please notify the sender and destroy all copies of the original message and all attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

1 year, 3 months

4
5
0 0

SME support in RMM

by Arunachalam Ganapathy

Hi All, Please review the patch-set that adds the functionality in RMM to manage Scalable Matrix Extension (SME) context. If the CPU supports SME and if Realm accesses FPU/SVE functionality then NS SME state is saved to allow Realm to use FPU/SVE register state. https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%… Brief summary of changes made in different components: RMM: - Introduces SIMD context and exports APIs to the runtime component of RMM to initialize, save, restore, and switch SIMD context. - Adds SME support in RMM to manage NS SME context. Supports SVE+SME config and SME only config. - Handles SVE hint bit passed in RMI SMCs - Handles SME exceptions from Realms https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%… TF-A: - Enables FEAT_SME for RMM - Passes SMCCCv1.3 SVE hint bit in SMC function ID to RMM tf-a-tests: - There are changes in common lib routines for sve, sme so that testcases running in NS-EL2, S-EL1, R-EL1 can use these helper routines. - Adds helper routines to read, write, compare FPU and SVE Z, P, FFR registers - Adds SMCCCv1.3 SVE hint bit support in TFTF framework - Enables SME/SME2 during arch init - Adds SME helper routines and extends SVE lib routines to support streaming SVE mode. https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%… Thanks, Arun

1 year, 3 months

1
0
0 0

Console scope flags/ console switch state - understanding

by Michal Simek

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

1 year, 3 months

4
5
0 0

Re: Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

Hi, The TF-A Tech Forum instance on Sep 21st 2023 is cancelled due to lack of topic. Thanks & Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 14 June 2020 19:21 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: 21 September 2023 17:00-18:00. Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year, 3 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Sep 21, 2023 5pm - 6pm (CEST) (tf-a@lists.trustedfirmware.org)

by olivier.deprez＠arm.com

This event has been canceled with a note: "Hi, The TF-A Tech Forum instance on Sep 21st 2023 is cancelled due to lack of topic. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Sep 21, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 3 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/ddr/stm32mp_ddr_test.c: 134 in stm32mp_ddr_check_size() ________________________________________________________________________________________________________ *** CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/ddr/stm32mp_ddr_test.c: 134 in stm32mp_ddr_check_size() 128 uint32_t stm32mp_ddr_check_size(void) 129 { 130 uint32_t offset = sizeof(uint32_t); 131 132 mmio_write_32(STM32MP_DDR_BASE, DDR_PATTERN); 133 >>> CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "offset < 4294967296UL" is always true regardless of the values of its operands. This occurs as the logical operand of "while". 134 while (offset < STM32MP_DDR_MAX_SIZE) { 135 mmio_write_32(STM32MP_DDR_BASE + offset, DDR_ANTIPATTERN); 136 dsb(); 137 138 if (mmio_read_32(STM32MP_DDR_BASE) != DDR_PATTERN) { 139 break; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 3 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A