- 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 months

10
32
1 0

Canceled event: TF-A Tech Forum @ Thu May 4, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday May 4, 2023 ⋅ 4pm – 5pm United Kingdom Time 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

2 years, 10 months

1
0
0 0

Allow platforms to deny CPU power off request

by Varun Wadekar

Hello, We have a use case where we want to deny the CPU power off from a certain PE. The current lib/psci does not provide a way for a platform to do this. We have support to return an error from svc_off, but this does not cover the scenario where svc_off is NULL. There are multiple ways of handling this scenario. 1. Introduce a new platform function to check if CPU_OFF is allowed on the core 2. Return an error code from the pwr_domain_off() handler and unwind the CPU_OFF request 3. Something else. Any suggestions? -Varun

2 years, 10 months

3
4
0 0

Canceled event with note: TF-A Tech Forum @ Thu Apr 20, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "The original topic for this TechForum will be held on a future date. No alternative topic has been identified for this session so cancelling." TF-A Tech Forum Thursday Apr 20, 2023 ⋅ 4pm – 5pm United Kingdom Time This session will no longer take place on this date. It will be rescheduled.This slot is now free for another session although nothing has yet been identified.======================================Reserving for a discussion on Signer-id Extraction Design for Manish Badarkhe. More details of this session will be sent closer to the session date.-----------------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 moritzf(a)google.com ~~//~~ 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, 10 months

1
0
0 0

Deprecation of Arm CryptoCell-712/713 drivers

by Sandrine Bailleux

Hello, This is a courtesy notification that we plan to deprecate Arm CryptoCell-712 and CryptoCell-713 drivers in TF-A release v2.9, with the goal to remove their source code from the tree in the following TF-A release after that. This won't affect any upstream platforms beyond Arm Ltd platforms (under plat/arm/ folder). If you have any concerns with this, please raise them by Monday, April 24th. Best regards, Sandrine

2 years, 10 months

1
0
0 0

TF-A with TRUSTED_BOARD_BOOT failed when using mbedtls-3.4.0

by Chen-Yu Yang

Hi, I'm using TF-A 2.8 on mt7986 board, enable TRUSTED_BOARD_BOOT using mbedtls-3.4.0, TF-A BL2 hanged when loading BL31, it seems that BL2 failed to get correct oid in function get_ext(drivers/auth/mbedtls/mbedtls_x509_parser.c) after calling mbedtls_oid_get_numeric_string mbedtls_oid_get_numeric_string in 3.4.0 uses %c to print part of oid, (https://github.com/Mbed-TLS/mbedtls/blob/v3.4.0/library/oid.c#L864) but seems that ATF libc's snprintf doesn't support %c format, which causes mbedtls_oid_get_numeric_string to return incorrect oid oid_str dump in get_ext oid_str=%c.49.6.1.4.1.4128.2100.1 (mbedtls_oid_get_numeric_string) oid_str=1.3.6.1.4.1.4128.2100.1 (TRUSTED_FW_NVCOUNTER_OID) I try to change snprintf format %c to %u in mbedtls_oid_get_numeric_string, TF-A boots successfully Thanks

2 years, 11 months

3
3
0 0

Re: Question about the Memory Encryption Engine on FVP

by Sandrine Bailleux

Hi, Concerning the following Fast Model Component: https://developer.arm.com/documentation/100964/1121/Fast-Models-components/… This component is already publicly documented although it is not integrated yet into the AEM FVP. The main usage is to identify software mis-programming, where the same Physical address is accessed through more than one Physical Address Space (PAS). As such, it is intended as a development / debugging tool only. If such a mis-programming scenario happened then the memory page corresponding to the accessed physical address would get corrupted. Notice memory encryption is not yet supported in TF-A's SW stacks. You won't find a reference for this feature in TF-A / TF-a-tests just now. Best regards, Sandrine

2 years, 11 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 20, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Apr 20, 2023 ⋅ 4pm – 5pm United Kingdom Time This session will no longer take place on this date. It will be rescheduled.This slot is now free for another session although nothing has yet been identified.======================================Reserving for a discussion on Signer-id Extraction Design for Manish Badarkhe. More details of this session will be sent closer to the session date.-----------------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 moritzf(a)google.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

2 years, 11 months

1
0
0 0

Is TF-A going to support MBEDTLS_AESCE_C option in mbedtls-3.4.0?

by Chen-Yu Yang

Hi, I'm working in TF-A 2.8 with mbedtls, I notice that mbedtls-3.4.0 starts to support AES crypto extension(MBEDTLS_AESCE_C) for some security reasons, I upgrade mbedtls from 2.28.0 to 3.4.0, and try to enable MBEDTLS_AESCE_C in TF-A. I fail to compile mbedtls aesce.c in TF-A build environment. I use CROSS_COMPILE=aarch64-gcc-7.5.0. It seems that AESCE needs some std libraries(e.g. arm_neon.h) supported by aarch64 gcc, while TF-A disables std libraries, and some compile flags(e.g. -mgeneral-regs-only) are conflict with current TF-A. I wonder is TF-A going to support MBEDTLS_AESCE_C option? Thanks

2 years, 11 months

2
2
0 0

Question about the Memory Encryption Engine on FVP

by Chenxu Wang

Hi all, I want to test the memory encryption functions in Arm CCA. Currently, I find that Arm FVP supports a PVMemoryProtectionEngine. Thus, can I use this engine in current TF-A or TF-A-Tests? If yes, how to use this engine? Sincerely, WANG Chenxu

2 years, 11 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 20, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Apr 20, 2023 ⋅ 4pm – 5pm United Kingdom Time Reserving for a discussion on Signer-id Extraction Design for Manish Badarkhe. More details of this session will be sent closer to the session date.-----------------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, 11 months

1
0
0 0

TF-A code documentation

by Michal Simek

Hi, I have talked to a couple of people to figure out what TF-A project is using for code documentation. Because I see at least in our platform that our documentation is somewhere between doxygen and kernel-doc but actually with a lot of mismatches. Sanbrine mentioned sending an email to the mailing list to start to have discussion about it. That's why I want to know the official code documentation format and how we should be checking that everything matches to make sure that documentation is not out of sync from code itself. When this is clear I will ask my team to fix all these issues. 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 ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

2 years, 11 months

5
8
0 0

FEAT_SVE enablement in TF-A

by Jayanth Dodderi Chidanand

Hello all, We are sending this note to notify you of one of the breaking changes related to the enablement of FEAT_SVE in TF-A. This mainly impacts platforms which are configurable (FVP, QEMU, Total Compute). FEAT_SVE has now been moved under the Feature detection mechanism wherein a CPU feature macro can have 3 possible states * 0: FEAT_STATE_DISABLED * 1: FEAT_STATE_ALWAYS ( Always enabled, no runtime check) * 2: FEAT_STATE_CHECK (Dynamically check based on ID registers, done each time when feature registers are being accessed) For platforms which have a single configuration, it's better to choose either disabled or enabled (as it is a bit faster as there is no dynamic check). For platforms which can have different HW configurations, it makes sense to put them under FEAT_STATE_CHECK(=2), so that they will boot with any configuration of HW. Keeping this in mind, all configurable platforms (FVP, QEMU, TC) have been modified to adopt dynamic detection(FEAT_STATE_CHECK) for FEAT_SVE. [1] SVE Patch Reference: [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20306 Best regards, Jayanth

2 years, 11 months

1
0
0 0

rk3399 issue: no DMA in Linux with mainline TF-A and U-Boot SPL

by Christoph Fritz

Hello Kever, on a rk3399, booting current U-Boot SPL with mainline TF-A leads to missing DMA (and no sound) on Linux. However, when using rockchip its so called mini-loader (rk3399_miniloader_v1.26.bin) and their BL31 (rk3399_bl31_v1.35.elf) to boot, DMA works perfectly fine. Tested on a custom rk3399 board and on ROCK Pi4. Attached to this mail are two boot logs with some debug prints: - good_amba_log.txt (DMA works) - no_amba_log.txt (no DMA device) The main difference I can spot between the two logs is that on Linux (drivers/amba/bus.c) AMBA_CID (0xb105f00d) cannot be found. Instead, only some CORESIGHT_CIDs (presumably for debugging) and four 0x00000000 CIDs are detected. As a result, the "PL330 DMAC-241330" driver does not load. My theory is that DMA needs to be allowed somewhere in the undocumented syscon- registers, similar to what U-Boot is already doing for eMMC in arch_cpu_init() (arch/arm/mach-rockchip/rk3399/rk3399.c). Any ideas? Or maybe I'm just missing some configuration? Since multiple software projects are involved (TF-A, OP-TEE, U-Boot, Linux), I Cc'ed a bit. Thanks -- Christoph

2 years, 11 months

3
4
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "No topics this week so cancelling." TF-A Tech Forum Thursday Apr 6, 2023 ⋅ 4pm – 5pm United Kingdom Time 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

2 years, 11 months

1
0
0 0

TF-A TechForum 6th April

by Joanna Farley

Hi Folks, I’ve just updated the Techforum session information (Slides and Recording) from the RAS Handing session last week on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ which will be deployed soon once the patch is approved. The next TF-A Tech forum is due on Thursday 6th April at 4pm BST. At this time I don’t have any topics for that session. If anybody in the community has anything they would like to present please do reach out to me. Thanks Joanna

2 years, 11 months

1
0
0 0

Workaround for ARM Cortex-A78AE Erratum 1941500 is not enabled

by matthias.rosenfelder＠nio.io

Hi, according to the current erratum document for the ARM Cortex-A78AE [0], the workaround for erratum 1941500 says: "This erratum can be avoided by setting CPUECTLR_EL1[8] to 1." However, the current code on branch "master" (git hash 5906d97a832b6f6 ) at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a… executes a "bic" instruction with an immediate, which is a synthetic instruction to clear the bit, instead of setting it. Moreover, the comment above says "Set bit 8 in ECTLR_EL1", which is inconsistent to the code. The equivalent workaround for the Cortex-A78 non-AE (erratum 1941498) uses the correct "orr" (bitwise-or) instruction to set the bit: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a… Please confirm if this is an error. Thank you. Best Regards, Matthias [0] "Arm Cortex-A78AE (MP105) Software Developer Errata Notice", Document version: v14.0, Document ID: SDEN-1707912, https://developer.arm.com/documentation/SDEN1707912/latest

2 years, 11 months

1
0
0 0

Question about configuring Juno R2 GPU SMMU in TF-A

by Chenxu Wang

Hi all, I try to enable the smmu of Juno R2 development board but face two great challenges. I am working on them and I still need some hints. Here are my problems: 1. By reading the SMMUv1 manuals I find that several registers are related to secure state (e.g., SMMU_sCR0). But in my TF-A and the latest version I can only find the SMMUv3 configurations, not SMMUv1/2. Thus, how to config these registers? Any reference? 2. For the non-secure GPU SMMU regs, I try to map and read them based on the Juno R2 manual. I know the GPU SMMU is a MMU-400, and its mmio is in 0x2b40_0000 - 0x2b40_ffff. Then in EL1 I first do ioremap(0x2b400000,0x10000) and then ioread32(). However I get the SError as "Bad mode in Error handler detected on CPU1, code 0xbf000002". I also try to do it in EL2 (with a hvc call and reading in the handler), but cannot get any valid number and still get SError when exiting EL2. But when I access the other smmus (e.g., a PCIe SMMU, in 0x2b50_0000), it works fine. Thus, is there something to prevent the Non-secure World from accessing the GPU SMMU MMIO? My source codes are downloaded from the arm-reference-platforms, in which Linux is v4.14.59 and TF-A is v2.1. Can someone help me? Sincerely, WANG Chenxu

2 years, 11 months

1
1
0 0

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

by joanna.farley＠arm.com

This event has been updated with a note: "Updated agenda" Changed: description TF-A Tech Forum Thursday Mar 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Discussion Topic: RAS Refactoring Presented by: Manish Pandey and Soby MathewTopics to be discussed 1. Introduction to philosophies of handling RAS errors(FFH/KFH) 2. Discussing exceptions caused by synchronization barriers at execption boundries 3. Refactoring and enhancements in TF-A(along with various build macros) 4. Tests introduced 5. Future work----------------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 bpeckham(a)google.com moritzf(a)google.com kh3195(a)columbia.edu 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, 11 months

1
0
0 0

About Unmask the SError in serror_aarch64

by Ming Huang

Hi Jeenu, vector_entry serror_aarch64 + msr daifclr, #DAIF_ABT_BIT Why the SError must be unmask in serror_arrch64? We found unmask SError will lead TF-A panic with output "Unhandled Exception in EL3". --------------------------------------------------------------------------------------log: Detected DPC, skip AER core[64] mm(925) return: 2 [ 109.883159] pcieport 0000:b0:00.0: DPC: containment event, status:0x0005 source:0xb000 [ 109.891195] pcieport 0000:b0:00.0: DPC: ERR_FATAL detected [ 109.896776] igb 0000:b1:00.0 ens51f0: PCIe link lost [root(a)localhost.localdomain /root/hm] #[ 110.068410] pcieport 0000:b0:00.0: pciehp: Slot(51): Link Down/Up ignored (recovered by DPC) [ 110.076988] igb 0000:b1:00.0: enabling device (0000 -> 0002) Unhandled Exception in EL3. x30 = 0x00000000ff013b84 x0 = 0x0000000000000000 x1 = 0xffff800011e7500c x2 = 0x0000000000000000 x3 = 0xffff800011e75004 x4 = 0xffff800011a82000 x5 = 0x000000000000000c x6 = 0x00000000000000fb x7 = 0xffff800011441e80 x8 = 0x0000000000000000 x9 = 0xffff800010655270 x10 = 0x00000000ffff8000 x11 = 0xffff800011701e80 x12 = 0x0000000000000001 x13 = 0xffff800010c08cc0 x14 = 0x0000000000000c80 x15 = 0x0000000000000001 x16 = 0x67692070552f6e77 x17 = 0x7228206465726f6e x18 = 0x0000000000000030 x19 = 0xffff04000032de80 x20 = 0xffff04000032dea0 x21 = 0xffff040002c2f000 x22 = 0xffff000809280000 x23 = 0xffff00080a217800 x24 = 0xffff800011853f80 x25 = 0xffff040002c2e0c8 x26 = 0xffff800011923de8 x27 = 0xffff000817fc8740 x28 = 0x0000000000000000 x29 = 0xffff80001e9ebb00 scr_el3 = 0x000000000403073d sctlr_el3 = 0x0000000030cd183f cptr_el3 = 0x0000000000000100 tcr_el3 = 0x0000000080843514 daif = 0x00000000000003c0 mair_el3 = 0x00000000004404ff spsr_el3 = 0x00000000624002cd elr_el3 = 0x00000000ff013d84 ttbr0_el3 = 0x00000000ff093001 esr_el3 = 0x00000000be000011 far_el3 = 0x7abce97e90b5fee1 spsr_el1 = 0x0000000000000000 elr_el1 = 0x0000000000000000 spsr_abt = 0x0000000000000000 spsr_und = 0x0000000000000000 spsr_irq = 0x0000000000000000 spsr_fiq = 0x0000000000000000 sctlr_el1 = 0x0000000030d00800 actlr_el1 = 0x0000000000000000 cpacr_el1 = 0x0000000000000000 csselr_el1 = 0x0000000000000002 sp_el1 = 0x0000000000000000 esr_el1 = 0x0000000000000000 ttbr0_el1 = 0x0000000000000000 ttbr1_el1 = 0x0000000000000000 mair_el1 = 0x0000000000000000 amair_el1 = 0x0000000000000000 tcr_el1 = 0x0000000000000000 tpidr_el1 = 0xffff800f6e6f1000 tpidr_el0 = 0x00000000f6e1ede0 tpidrro_el0 = 0x0000000000000000 par_el1 = 0xff000000f4214b80 mpidr_el1 = 0x0000000081000000 afsr0_el1 = 0x0000000000000000 afsr1_el1 = 0x0000000000000000 contextidr_el1 = 0x0000000000000000 vbar_el1 = 0x0000000000000000 cntp_ctl_el0 = 0x0000000000000000 cntp_cval_el0 = 0x000000010b938e04 cntv_ctl_el0 = 0x0000000000000000 cntv_cval_el0 = 0x0000000000000000 cntkctl_el1 = 0x0000000000000000 sp_el0 = 0xffff000809280000 isr_el1 = 0x0000000000000040 cpupwrctlr_el1 = 0x0000000000000000 -------------------------------------------------------------------------------------- Remove the above line(mask SError), TF-A continue execute with some useful output. --------------------------------------------------------------------------------------log: Detected DPC, skip AER core[64] mm(925) return: 2 [ 278.193642] pcieport 0000:b0:00.0: DPC: containment event, status:0x0005 source:0xb000 [ 278.201680] pcieport 0000:b0:00.0: DPC: ERR_FATAL detected [ 278.207262] igb 0000:b1:00.0 ens51f0: PCIe link lost [root(a)localhost.localdomain /root/hm] #[ 278.378416] pcieport 0000:b0:00.0: pciehp: Slot(51): Link Down/Up ignored (recovered by DPC) [ 278.386993] igb 0000:b1:00.0: enabling device (0000 -> 0002) ERROR: Excepton received on 0x81000000, spsr_el3:82401009,reason:0 esr_el3:0xbe000411 ue_cnt:0x0 Exception Class = 2f: SError interrupt. Print cpu register: |-elr_el3: ffff8000106550f8 |-far_el3: 7abce97e92b57fe1 |-scr_el3: 403073d |-sctlr_el3: 30cd183f |-LR: ffff800010655270 |-SP: ffff0008091d1200 |-x0: 0000000000000000 x1: ffff800011e7500c |-x2: 0000000000000000 x3: ffff800011e75004 |-x4: ffff800011a82000 x5: 000000000000000c |-x6: 00000000000000fb x7: ffff800011441e80 |-x8: 0000000000000000 x9: ffff800010655270 |-x10: 00000000ffff8000 x11: ffff800011701e80 |-x12: 0000000000000001 x13: ffff800010c08cc0 |-x14: 0000000000000c80 x15: 0000000000000001 |-x16: 67692070552f6e77 x17: 7228206465726f6e |-x18: 0000000000000030 x19: ffff040005a7e100 |-x20: ffff040005a7e120 x21: ffff040001e9f000 |-x22: ffff0008091d1200 x23: ffff000809cdf800 |-x24: ffff800011853f80 x25: ffff040001e9e0c8 |-x26: ffff800011923de8 x27: ffff000807549140 |-x28: 0000000000000000 x29: ffff80001cc9bb00 INFO: mpidr:81000000, stop s-wtd. Return to lower EL by SDEI ->Core[0](0x81000000) received intr=0(exception), cnt=0x1 RTC: 2023-03-08 10:15:38 ERROR: Excepton received on 0x81000000, spsr_el3:620003c5,reason:2 esr_el3:0x80000011 ue_cnt:0x0 Exception Class = 17: SMC instruction execution in AArch64 state, when SMC is not disabled. Print cpu register: |-elr_el3: ff01a430 |-far_el3: 7abce97e92b57fe1 |-scr_el3: 4000e3c |-sctlr_el3: 30cd183f |-LR: ff208570 |-SP: ff631d80 |-x0: 00000000c4000061 x1: 0000000000000000 |-x2: 0000000000000000 x3: 0000000000000000 |-x4: 0000000000000000 x5: 0000000000000000 |-x6: 0000000000000000 x7: 0000000000000000 |-x8: 0000000000000000 x9: 0000000000000002 |-x10: 0000000000000002 x11: 0000000000000000 |-x12: 0000000000000002 x13: 0000000000000002 |-x14: 0000000000000001 x15: 00000000000000ff |-x16: 00000000ffa97650 x17: 00000000000000f8 |-x18: 0000000000000000 x19: 0000000000000001 |-x20: 0000000000000000 x21: 00000000ff20c240 |-x22: 00000000ff20c25a x23: 8000000000000009 |-x24: 0000000076726473 x25: 00000000ff20d1e0 |-x26: 00000000ffbdcc10 x27: 00000000ff631ef8 |-x28: 00000000ffbff328 x29: 00000000ff631d80 INFO: mpidr:81000000, stop s-wtd. Have report fatal Exception Class = 17: SMC instruction execution in AArch64 state, when SMC is not disabled. Print cpu register: -------------------------------------------------------------------------------------- Regards, Ming

2 years, 11 months

3
4
0 0

commit to tf-a-ci-scripts

by Ruth Glushkin

I have already created patch in tf-a for review, added plat Nuvoton npcm845x, gerrit topic No. 20088. How should I upload a scripts patch to support new added platform? In documentation I didn't found how exactly should I send a scripts patch. Thank you in advance. Margarita Glushkin

2 years, 11 months

3
5
0 0

adding Nuvoton npcm845x platform

by Ruth Glushkin

Commit No: 71b6e2217052057744a1dedaef1c540f3c98e703 feat(plat): added support to Nuvoton npcm845x chip Please review. Margarita Glushkin

2 years, 11 months

2
1
0 0

RFE: GIC workaround for NVIDIA erratum T241-FABRIC-4

by Varun Wadekar

Hi, I would like to get some feedback on the gicv3 workaround [1] for NVIDIA erratum T241-FABRIC-4. The commit description describes the erratum and the fix in detail. The patch is only to start a dialogue and gather feedback on the way forward. Please advise. Thanks. [1] fix(gicv3): workaround for NVIDIA erratum T241-FABRIC-4 (I04e33ba6) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19969>

2 years, 12 months

1
1
0 0

Re: Post-boot loading of OP-TEE

by 梅建强(禹夜)

Hi, experts, I have another two other questions about this issue. (1) What should I do if the current optee to load already exists or I want to update optee? The most straightforward way I could think of is to reclaim the memory currently used by optee, then reload the optee image and initialize it. (2) optee may use multiple cores. When and how to process the initialization of multiple cores? Do you have any solutions or ideas? Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月11日(星期六) 21:44 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Re: Post-boot loading of OP-TEE Hi, experts, If I want to apply the code to the S-EL2 framework (Hafnium as SPMC), What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save? I'm not clear about the details of the process, can you give me some help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年1月9日(星期一) 15:39 收件人：tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Post-boot loading of OP-TEE Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… > [3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 > Thanks, Jens

3 years

2
1
0 0

Re: Post-boot loading of OP-TEE

by 梅建强(禹夜)

Hi, experts, If I want to apply the code to the S-EL2 framework (Hafnium as SPMC), What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save? I'm not clear about the details of the process, can you give me some help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年1月9日(星期一) 15:39 收件人：tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Post-boot loading of OP-TEE Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… > [3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 > Thanks, Jens

3 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A