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

Need a mechanism to easily define platform-independent SMC FIDs

by Julius Werner

Hi, I would like to restart a discussion that we already had a few years ago on a thread called "SMC to intentionally trigger a panic in TF-A" (https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…) but that petered out without any real resolution (and resulted in me ultimately not implementing the feature I was hoping to add). Basically, we are repeatedly stumbling over the problem that we have a use case for some platform-independent SMC API that we want to implement in TF-A, but don't have an appropriate SMC FID range to put it. My request from a few years ago was about implementing a call to intentionally trigger a panic in TF-A for test-automation purposes. Today we came up with a use case where a Trusted OS wants to query BL31 about the location of a shared log buffer: https://review.trustedfirmware.org/20478 . Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard, Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific to a single silicon vendor, OEM or trusted OS implementation, so they are not good targets to implement APIs that would make sense to be shared among multiple of these. In theory, the Standard range would probably be the right target to implement calls that are independently useful for multiple platforms / OSes... but as far as I understand, adding a new call to that range requires petitioning Arm to update the SMC calling convention itself, which is a ridiculously high bar to implement a small utility API. In practice, the only choice we have for implementing these kinds of calls is to let every OEM, SiP or TOS assign its own (different) FID for it and then write separate SMC handlers for each in TF-A that all end up calling the same underlying function... which creates a lot of unnecessary code duplication and identifier soup (especially in the case of SMCs for the non-secure OS which would then be implemented by a platform-independent Linux driver that needs a big mapping table to decide which FID to use on which platform for the same API). I think it would be very useful if there was another range of easily allocatable FIDs that developers could just add to with a simple TF-A CL without having to go through a huge specification update process. There are still 41 OENs unused in the Arm SMCCC, and I don't think any new ones were added in the 10 years that the specification existed... so we are really not going to run out of them any time soon. If we could get even one of those OENs for this purpose, we would have 64K FIDs to use up for our small, simple platform-independent API needs, which should last us a long while. We could maybe call it the "Secure Monitor range" and say the FIDs are specific to a certain implementation of Secure Monitor (e.g. TF-A). Then there could just be a header file in the TF-A sources that serves as the authoritative FID assignment table for TF-A, and anyone with a sufficiently useful idea (subject to TF-A maintainer review) for a platform-independent API like this could add it there by just uploading a patch. I recently argued for a similar "simple tag allocation" concept on https://github.com/FirmwareHandoff/firmware_handoff and it found support there, so I hope I'll be able to convince you that it would be useful for SMC FIDs as well?

7 months

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

MISRA-C violation for unused functions in Trusted Firmware-A(TFA) code

by nithing1999＠gmail.com

It is observed that several unused functions are present in Trusted Firmware-A code, is it possible to mask those unused functions or leave them as it is to fix MISRA-C Violations? If these functions are not appearing in symbol table, then no need to take actions on violations reported in these functions? Please suggest.

1 year, 2 months

4
6
0 0

External Abort and SError Handling with RAS enabled

by Bharat Bhushan

Hi All, SCR_EL3.EA define whether to route External Abort and SError Interrupt to EL3 or EL2/1. ATF have a compile time flag to HANDLE_EA_EL3_FIRST_NS to program SCR_EL3.EA. Below text from ATF documentation. - ``HANDLE_EA_EL3_FIRST_NS``: When set to ``1``, External Aborts and SError Interrupts, resulting from errors in NS world, will be always trapped in EL3 i.e. in BL31 at runtime. When set to ``0`` (default), these exceptions will be trapped in the current exception level (or in EL1 if the current exception level is EL0). Have question related to forwarding of these errors when External Abort and SError Interrupt are routed to EL3. In this case will ATF forward Asynchronous SError Interrupt to Linux via RAS? Thanks -Bharat

1 year, 2 months

2
3
0 0

MISRA-C Violations for function like macros in Trusted Firmware-A(TFA) code

by nithing1999＠gmail.com

It is observed that functions like macros like NOTICE, WARN and assert are present in the Trusted Firmware-A code. MISRA-C standard treats these as violations. shall we take these as deviation? please suggest. TFA Guidelines recommends using logging macros. So can we make deviations or need to change the MACRO into function.

1 year, 2 months

3
2
0 0

MISRA-C violation for Device Tree (FDT) in Trusted Firmware-A (TFA) code.

by Nithin G

Hello, It is observed that device tree functions are present under lib/libfdt/... in Trusted Firmware-A code, but this device tree are not present in symbol table and also if we remove this device tree functions in code, board was successfully booting. However, while doing Coverity build to fix MISRA-C violations getting violations from this device tree code. So, is it possible to leave those violations please suggest? And when it will be enabled, please suggest. Thanks & Regards Nithin G

1 year, 2 months

2
2
0 0

Techforum for 24th August CANCELLED

by Joanna Farley

Hi Everyone, I have cancelled the TF-A techforum for latter today as we have no topic scheduled to be discussed. Calendar cancellations have been sent. Apologies for the late notification. Joanna

1 year, 3 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "Cancelling as we have no topics for today. Apologies for the late cancellation. Joanna" TF-A Tech Forum Thursday Aug 24, 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

1 year, 3 months

1
0
0 0

Question about Secondary CPU boot with spintable

by 빈성욱

Hi I ported TF-A and OPTEE on multi-core SoC, and I checked that xtest passed on CPU0 without failure. However, I'm failing in secondary CPU boot, and I'd like to get some help. I'm using ARMv8, and I'm using spintable as CPU enable method (not using PSCI FW). TF-A is in EL3. What I did ... 1. I released secondary CPU reset from bl31_early_platform_setup2() during primary CPU cold booting - set secondary CPU's RVBAR to bl31_entrypoint - release secondary CPU reset 2. I implemeneted plat_secondary_cold_boot_setup(), which is spining until linux kernel updates cpu-release-addr. Once linux kernel updates cpu-release-addr, then it changes EL to EL1 and jumps to secondary_startup() in linux 3. But secondary core goes to panic. It seems to happen when linux invokes optee_probe() Should I initialize some contexts (e.g. optee ..)? If so, where should I implement the corresponding codes? I'm wondering if I'm missing something, and I'd like to get some advice Thanks, --Bin

1 year, 3 months

6
7
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "Cancelling this weeks TF-A Tech Forum. No topics ready to present and many people out on vacation." TF-A Tech Forum Thursday Aug 10, 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

1 year, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A August 2023