February 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.…>

2 years

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

2 years, 2 months

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

2 years, 2 months

8
18
0 0

[PATCH] fix(mmc): remove redundant reset_to_idle call

by Baruch Siach

mmc_enumerate() is the only caller of mmc_send_op_cond(). mmc_enumerate() calls mmc_reset_to_idle() just before calling mmc_send_op_cond(). No need to do that again in mmc_send_op_cond(). Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> Change-Id: Ib8c8ed1a559e3fecb315245f91bb3dc1f547d820 --- Sending the patch to the list once again. review.trustedfirmware.org does not work for me. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… --- drivers/mmc/mmc.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 2b727d4e7696..57f47482013a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -452,11 +452,6 @@ static int mmc_send_op_cond(void) int ret, n; unsigned int resp_data[4]; - ret = mmc_reset_to_idle(); - if (ret != 0) { - return ret; - } - for (n = 0; n < SEND_OP_COND_MAX_RETRIES; n++) { ret = mmc_send_cmd(MMC_CMD(1), OCR_SECTOR_MODE | OCR_VDD_MIN_2V7 | OCR_VDD_MIN_1V7, -- 2.39.2

2 years, 2 months

2
1
0 0

Is NS_BL1U necessary to do FWU ?

by Jun.Chen(陳奕昕)

Hi, In ARM TBBR, there is a requirement “R0100_TBBR_AFM_FLASHING” (The AP firmware must switch to the Non-Trusted world for executing the SoC firmware loader), But there is no requirement for secure boot as long as I finish chain if ROT verification. So, can I implement FWU in BL2 which is verified and load from BL1 (ROM)? For example, BL1(ROM) -> Load and verify BL2U with new image from SD to secure RAM -> execute BL2U in Secure RAM then write new image to NAND flash Best regards, Jun

2 years, 2 months

2
3
0 0

Updated invitation: TF-A Tech Forum @ Thu Mar 9, 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 Mar 9, 2023 ⋅ 4pm – 5pm United Kingdom Time Reserving this session for a TF-A RAS support update in an evolving Arm architecture.A more detailed agenda will be issued closer to the event.---------------------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

2 years, 2 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 8am - 9am (PST) (tf-a@lists.trustedfirmware.org)

by wingers＠google.com

This event has been updated Changed: location TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 8am – 9am Pacific Time - Los Angeles Location US-MTV-1015-1-S-Silicon (2) [GVC, Phone] https://www.google.com/maps/search/US-MTV-1015-1-S-Silicon+(2)+%5BGVC,+Phon… Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah, Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why OS-initiated mode?3. Implementation details and testing in TF-AThanks 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 don.harbin(a)linaro.org sudeep.holla(a)arm.com Souvik Chakravarty wingers(a)google.com ajaysp(a)google.com peckham(a)google.com Mahesh Sivasubramanian cozette(a)google.com mkshah(a)qti.qualcomm.com ulf.hansson(a)linaro.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

2 years, 2 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 Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah, Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why OS-initiated mode?3. Implementation details and testing in TF-AThanks 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 don.harbin(a)linaro.org sudeep.holla(a)arm.com Souvik Chakravarty wingers(a)google.com ajaysp(a)google.com peckham(a)google.com Mahesh Sivasubramanian cozette(a)google.com mkshah(a)qti.qualcomm.com ulf.hansson(a)linaro.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

2 years, 2 months

1
0
0 0

Checking SIP Service Calls range

by Michal Simek

Hi, I have one question about SIP Service Calls range and it's range checking. Based on DEN0028E SIP Service Calls ranges are 0x82000000-0x8200FFFF SMC32: SiP Service Calls 0xC2000000-0xC200FFFF SMC64: SiP Service Calls That's the ranges which we are using for implementing SOC specific SMC handlers and I found that in past it was also added code which is out of this range. Specifically in Xilinx ZynqMP you can see code like this if (is_em_fid(smc_fid)) { return em_smc_handler(smc_fid, x1, x2, x3, x4, cookie, handle, flags); } where EM range is 0x820e0001- 0x820e0003 is out of our range which is assigned to us. But there is no failure at all that we are out of ranged in spec. Shouldn't this be enforced by core itself? That's why I just wanted to know your opinion about it. We will definitely implement better masking to find out that 0x00fe0000 are all zeros. But that bit 16 is based on DEN0028E related to smcccv1.3 which I think we are not supporting now that's why should be 0 too. But definitely some information about this bit should be useful. 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

2 years, 2 months

2
2
0 0

[LTS v2.8.0] Trusted Firmware-A LTS v2.8.0 Release Announcement

by Varun Wadekar

External email: Use caution opening links or attachments We are pleased to announce the release of the Trusted Firmware-A LTS version 2.8.0 [1]. To help with the verification and stability of the release, we also created side branches for Trusted Firmware-A Tests [2] and TF-A OpenCI Scripts/Jobs [3]. These went live on 13th February 2023. The trusted-firmware-a repository is now open again. On behalf of the TF-A LTS project maintainers, I would like to thank the Trustedfirmware.org TF-A Project community for the support and guidance. Notable features of the TF-A LTS Version 2.8.0 Release are as follows: TF-A Project Repository * Resolved issues * Workarounds for the following CPU errata * Cortex-A510 erratum 2684597 * Cortex-A710 erratum 2282622 * Cortex-A710 erratum 2768515 * Cortex-A78 erratum 2772019 * Cortex-A78 erratum 2779479 * Cortex-A78C erratum 2772121 * Cortex-X2 erratum 2282622 * Cortex-X2 erratum 2768515 * Cortex-X3 erratum 2615812 * Neoverse N2 erratum 2743089 * Neoverse V1 erratum 2743093 * Neoverse V1 errata 2779461 * Mitigations for the security advisory #10 * Critical bug fixes for the following platforms * Arm/CSS * Intel * Layerscape * LS1046a * LX2 * NXP * ST Patch Statistics * 35 Patches merged since v2.8 Nov 2022 release Please refer to the TF-A LTS [1] changelog for the complete summary of changes. [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/chang… [2] tf-a-tests.git - Trusted Firmware-A Tests<https://git.trustedfirmware.org/TF-A%2Ftf-a-tests.git/log/?h=refs%2Fheads%2…> [3] tf-a-ci-scripts.git - Trusted Firmware A (TF-A) CI scripts<https://git.trustedfirmware.org/ci%2Ftf-a-ci-scripts.git/log/?h=refs%2Fhead…> [4] tf-a-job-configs.git - Trusted Firmware A (TF-A) Jenkins job configs<https://git.trustedfirmware.org/ci%2Ftf-a-job-configs.git/log/?h=refs%2Fhea…>

2 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A February 2023