January 2023 - TF-A - lists.trustedfirmware.org

[RFC] Proposed location to host the firmware handoff specification.

by Jose Marinho

Hi, Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback. This activity followed the request of some members of the Arm ecosystem [2]. The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot. The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden. The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data. New types are meant to be added, following the needs and use-cases of the different communities. Thus, these communities should be empowered to request new types! To enable community contributions, the specification must be hosted in a location that is friendly to change requests. We propose to host the spec in trustedfirmware.org (tf.org). Tf.org hosts several open-source projects and already has an open governance model. TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date. Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.). We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed! If anyone has objections, we are happy to consider alternatives and associated trade-offs. Regards [1] https://developer.arm.com/documentation/den0135/latest [2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>

11 months, 3 weeks

10
32
1 0

About kdump hang issue in SDEI dispatch

by Ming Huang

Hi James & TF-A guys, When hest acpi table configure Hardware Error Notification type as Software Delegated Exception(0x0B) for RAS event, kernel RAS interacts with TF-A by SDEI mechanism. On the firmware first system, kernel was notified by TF-A sdei call. The calling flow like as below when fatal RAS error happens: TF-A notify kernel flow: sdei_dispatch_event() ehf_activate_priority() call sdei callback // callback registered by kerenl ehf_deactivate_priority() Kernel sdei callback: sdei_asm_handler() __sdei_handler() _sdei_handler() sdei_event_handler() ghes_sdei_critical_callback() ghes_in_nmi_queue_one_entry() /* if RAS error is fatal */ __ghes_panic() panic() If fatal RAS error occured, panic was called in sdei_asm_handle() without ehf_deactivate_priority executed, which lead interrupt masked. If interrupt masked, system would be halted in kdump flow like this: arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for cmdq arm-smmu-v3 arm-smmu-v3.3.auto: allocated 32768 entries for evtq arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for priq arm-smmu-v3 arm-smmu-v3.3.auto: SMMU currently enabled! Resetting... So interrupt should be restored before panic otherwise kdump will hang. In the process of sdei, a SDEI_EVENT_COMPLETE(or SDEI_EVENT_COMPLETE_AND_RESUME) call should be called before panic for a completed run of ehf_deactivate_priority(). The ehf_deactivate_priority() function restore pmr_el1 to original value(>0x80). The SDEI dispatch flow was broken if SDEI_EVENT_COMPLETE was not be called. This will bring about two issue: 1 Kdump will hang for firmware reporting fatal RAS event by SDEI; (as explain above) 2 For NMI scene，TF-A enable a secure timer, the PPI 29 will trigger periodically. Kernel register a callback for hard lockup. The below code will not be called when panic in kernel callback: TF-A, services/std_svc/sdei/sdei_intr_mgmt.c sdei_intr_handler(): /* * We reach here when client completes the event. * * If the cause of dispatch originally interrupted the Secure world, * resume Secure. * * No need to save the Non-secure context ahead of a world switch: the * Non-secure context was fully saved before dispatch, and has been * returned to its pre-dispatch state. */ if (sec_state == SECURE) restore_and_resume_secure_context(); /* * The event was dispatched after receiving SDEI interrupt. With * the event handling completed, EOI the corresponding * interrupt. */ if ((map->ev_num != SDEI_EVENT_0) && !is_map_bound(map)) { ERROR("Invalid SDEI mapping: ev=%u\n", map->ev_num); panic(); } plat_ic_end_of_interrupt(intr_raw); How to fix above issues? I think the root cause is that kernel broken the SDEI dispatch flow, so kernel should modify to fix these issues. Thanks, Ming

1 year, 1 month

4
10
0 0

PSCI OS-initiated mode

by Wing Li

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

1 year, 1 month

8
18
0 0

[PATCH 1/2] fix(cert-create): move WARN to higher priority than NOTICE

by Baruch Siach

NOTICE messages should require higher LOG_LEVEL than WARN, not the other way around. Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> Change-Id: Iba9c67cafed19be47e7d03198faa98fbf99a10ee --- I still can't upload to review.trustedfirmware.org so I'm once again sending to the list instead. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… --- tools/cert_create/include/debug.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/cert_create/include/debug.h b/tools/cert_create/include/debug.h index ee8f1f51786f..8f7c62eefe2d 100644 --- a/tools/cert_create/include/debug.h +++ b/tools/cert_create/include/debug.h @@ -20,8 +20,8 @@ #define LOG_LEVEL_NONE 0 #define LOG_LEVEL_ERROR 10 -#define LOG_LEVEL_NOTICE 20 -#define LOG_LEVEL_WARNING 30 +#define LOG_LEVEL_WARNING 20 +#define LOG_LEVEL_NOTICE 30 #define LOG_LEVEL_INFO 40 #define LOG_LEVEL_VERBOSE 50 -- 2.39.0

1 year, 2 months

2
2
0 0

[LTS v2.8.0] TF-A patches are now ready for merge

by Varun Wadekar

Hello, As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have started shortlisting the patches for the lts-v2.8 branch. These are the commits that will be merged into the LTS branch. More details can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://developer.trustedfirmware.org/w/tf_a/tf-a_lts_meeting_minutes/track…> 1. c7e698cfd fix(cpus): workaround for Cortex-X3 erratum 2615812 2. c45791b2f fix(layerscape): fix errata a008850 3. fa0105693 fix(nxp-ddr): use CDDWW for write to read delay 4. 00bb8c37e fix(nxp-ddr): apply Max CDD values for warm boot 5. 07d8e34fd fix(nxp-drivers): fix tzc380 memory regions config 6. c0c157a68 fix(ls1046a): 4 keys secureboot failure resolved 7. 50aa0ea7a fix(lx2): init global data before using it 8. 4daeaf341 fix(sptool): add dependency to SP image 9. 5fb6946ad fix(console): fix crash on spin_unlock with cache disabled 10. ff1d2ef38 fix(el3_runtime): restore SPSR/ELR/SCR after esb 11. c42402cdf fix(intel): fix fcs_client crashed when increased param size 12. 0ca1d8fba fix(layerscape): unlock write access SMMU_CBn_ACTLR 13. b87b02cf1 fix(cpus): workaround for Cortex-A710 erratum 2768515 14. 1cfde8222 fix(cpus): workaround for Cortex-X2 erratum 2768515 15. 377846b65 fix(st): include utils.h to solve compilation error 16. 1cbe42a51 fix(el3_runtime): allow SErrors when executing in EL3 17. 1ee7c8232 fix(cpus): workaround for Neoverse N2 erratum 2743089 18. b10afcce5 fix(cpus): workaround for Cortex-A78 erratum 2772019 19. 31747f057 fix(cpus): workaround for Neoverse V1 erratum 2743093 20. fd37982a1 fix(auth): forbid junk after extensions 21. 72460f50e fix(auth): require at least one extension to be present 22. 06c01b085 fix(libc): properly define SCHAR_MIN 23. 89d85ad0a fix(cpus): workaround for Cortex-A710 erratum 2282622 24. abb8f936f fix(auth): avoid out-of-bounds read in auth_nvctr() 25. f5c51855d fix(auth): properly validate X.509 extensions 26. f9c6301d7 fix(cpus): workaround for Cortex-X2 erratum 2282622 27. 60719e4e0 fix(plat/css): fix invalid redistributor poweroff 28. 00230e37e fix(cpus): workaround for Cortex-A78C erratum 2772121 29. aea4ccf8d fix(cpus): workaround for Cortex-A510 erratum 2684597 If there are commits that we missed or that need to be in the LTS branch, please reach out to us. Thanks.

1 year, 2 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 26, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Jan 26, 2023 ⋅ 4pm – 5pm United Kingdom Time Apologies the LTS Update is for this week on 26th January at 4pm GMT Not February session.=====Just a reminder that this week the TF-A Tech Forum is covering a LTS Release update session from the primary maintainers of the TF-A v2.8 LTS branch:Varun WadekarOkash Khawaja Bipin Ravi Thanks AllJoanna========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/Trusted 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 bpeckham(a)google.com mayurvg(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ 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

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Just a reminder that this week the TF-A Tech Forum is covering a LTS Release update session from the primary maintainers of the TF-A v2.8 LTS branch:Varun Wadekar <vwadekar(a)nvidia.com> Okash Khawaja <okash(a)google.com> Bipin Ravi <Bipin.Ravi(a)arm.com>Thanks AllJoanna===============================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/Trusted 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 View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ 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

[TF-A]: Deprecating mbedtls-2.28 support for TF-A 3.0 release

by Govindraj Raja

Hi All, We are in the process of migrating from mbedtls-2.28 support to 3.3 support we plan to deprecate mbedtls-2.28 support for TF-A 3.0 Release but would retain support for both 2.28 and 3.3 for TF-A 2.9 lifetime. There is draft implementation available[1] for code review which cleanups and prepares for mbedtls-3.3 support but retaining backward compatibility for mbedtls-2.28. Please let us know if there any objections to deprecation of mbedtls-2.28 in TF-A 3.0. -- Thanks Govindraj [1]: https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522 <https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522>

1 year, 3 months

1
0
0 0

Query BL31 version from NWd

by Varun Wadekar

Hi, Happy new year! For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value. I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement. Thoughts? -Varun

1 year, 3 months

8
18
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 382954: Concurrent data access violations (MISSING_LOCK) /plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo() ________________________________________________________________________________________________________ *** CID 382954: Concurrent data access violations (MISSING_LOCK) /plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo() 167 dest = (struct constraint_status *)st->value; 168 do { 169 if (dest == NULL) { 170 break; 171 } 172 if (st->type == CONSTRAINT_GET_VALID) { >>> CID 382954: Concurrent data access violations (MISSING_LOCK) >>> Accessing "dest->is_valid" without holding lock "spm_lock". Elsewhere, "constraint_status.is_valid" is accessed with "spm_lock" held 5 out of 6 times. 173 dest->is_valid = cpubuckldo_status; 174 } else if (st->type == CONSTRAINT_COND_BLOCK) { 175 dest->is_cond_block = 0; 176 } else if (st->type == CONSTRAINT_GET_ENTER_CNT) { 177 if (st->id == MT_RM_CONSTRAINT_ID_ALL) { 178 dest->enter_cnt += cpubuckldo_enter_cnt; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A January 2023