- TF-A - lists.trustedfirmware.org

by François Ozog

Hi Following a discussion with Civil Infrastructure Project TSC, there is a watchdog protection issue with EFI: the time between the call to ExitBootService and Linux kernel takes over watchdog service is not covered by any watchdog protection. The EFI specification for BS.SetWatchdogTimer is very flexible as it states "perform a platform specific action that must eventually cause the platform to be reset.". So we could naively implement a solution that would arm platform hardware watchdog in addition to EFI timer. Assuming watchdog period is long enough that it cover the time for Linux to take over the hardware watchdog, there is nothing to be done in EFI Stub to benefit from the new protection. But this scheme fails to handle FF-A update capsules which can take a long time. So either the period is long enough to support that or we need a FF-A watchdog service. Based on Siemens feedback, time to update can last 20 minutes. StandAloneMM may also need such a protection so FF-A watchdog service seems desired. I'd be happy to receive feedback on the problem itself (watchdog in EFI) and on the possible solution (FF-A based). Cheers FF

3 years, 10 months

4
5
0 0

Tech Forum, Thursday 2021/07/01, 16:00-17:00 GMT: New FVP_R Platform

by Gary Morrison

Hello TF-A partners! As you may know, Arm recently announced the v8-R64 Architecture (AArch64 R-class cores), notably the Cortex R-82. v8-R64 has generated a lot of interest in the R-cores community, in part because of its vastly-increased address space and performance, and also because of its ability to run rich operating systems like Linux alongside more traditional RTOSes. Of course, great hardware requires great firmware to succeed! So, we are upstreaming a new platform into TF-A to support v8-R64, called "fvp_r." It's certainly reasonable to ask, "why support v8-R64 as a platform under the A-cores' trusted firmware?" The answer is simply that v8-R64 cores are far more similar with v8-A cores than different. Therefore, most of the trusted firmware code for v8-R64 cores is in-common with v8-A cores. If a separate trusted-firmware project were created for them, we would have a huge parallel-maintenance headache! Also, SystemReady IR certification for v8-R64 cores requires compliance with EBBR, and building from a TF-A framework puts us on the path toward that goal. The immediate firmware requirement for v8-R64, however, is not the entirety of TF-A. The immediate requirement for the fvp_r platform is to let the partner/customer dictate the nature of the run-time environment, and for TF to "trusted-boot" their environment. Therefore, the patch that we're upstreaming boots up only through BL1, and BL1 is adapted to load the customer/partner custom-defined run-time system. On 1 July, the Arm team who are upstreaming the fvp_r platform, will host a Tech Forum session wherein we'll provide an overview, and medium level of detail on: * The differences between v8-A and v8-R64 (again, more similar than different!), * The impacts of these differences upon BL1, and * Changes to BL1 to boot a partner/customer run-time system. * We'll then detail the nature of the patches involved - which patches provide what functionality. * Provide some suggestions for making the review of these patches easier. ________________________________ 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<mailto:tf-a@lists.trustedfirmware.org> Who * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org<mailto:tf-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

3 years, 10 months

1
0
0 0

Missing CPU workaround warning message

by Pali Rohár

Hello! If TF-A for Marvell Armada 3720 platform is compiled in debug mode then at runtime it prints following warning messages: WARNING: BL1: cortex_a53: CPU workaround for 855873 was missing! WARNING: BL1: cortex_a53: CPU workaround for 1530924 was missing! These lines are not printed in non-debug mode. It is an issue?

3 years, 10 months

1
0
0 0

Re: [TF-A] PL011 clock handling between TF-A and Linux

by Soby Mathew

Hi Michal, The general security rule of thumb is, any UART `owned` by Secure world ( including EL3) should not be accessible/or controlled by Non Secure and this includes control of the clocks as well. Hence sharing of UART / management of Secure world UART clocks by Linux seems problematic to me. There are 3 types of consoles needed in TF-A. The first one is the cold boot console, the second one is runtime console and the 3rd is crash console. The cold boot console is initially owned by Secure world as part boot process and once execution is transferred to Non Secure, the ownership of the UART also is transferred. Regarding clock expectations, the runtime UART is always expected to be ON but then this depends on the TF-A build config as it is very rare to have any runtime logs from Secure world and hence this config may be restricted to development builds of TF-A. For the crash console, the clocks don’t need to enabled all the time and any init needed can be performed as part of plat_crash_console_init(). HTH, Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Michal > Simek via TF-A > Sent: Tuesday, June 22, 2021 2:03 PM > To: Varun Wadekar <vwadekar(a)nvidia.com>; Michal Simek > <michal.simek(a)xilinx.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux > > Hi Varun, > > do you have any links to that calls in Linux clk API? I expect the same hooks > should be added also to reset. > > And is TF-A informs your special firmware that for example serial driver is > used by TF-A to increate refcount? > > Thanks, > Michal > > On 6/22/21 2:03 PM, Varun Wadekar wrote: > > Hi Michal, > > > > Tegra platforms manage clocks/resets by special firmware. The firmware > internally manages refcount of users as you described. > > > > AFAIR, we placed calls to the firmware in the linux clk APIs to achieve this. > There was an effort to leverage runtime_pm for this too. > > > > I think we wont be able to add guidance to TF-A for clock management as > most of it is platform dependent. We can add a generic guideline saying that > a certain driver expects the platform to manage the clock/reset for the IP. > > > > -Varun > > > > -----Original Message----- > > From: Michal Simek <michal.simek(a)xilinx.com> > > Sent: Tuesday, June 22, 2021 7:24 AM > > To: Varun Wadekar <vwadekar(a)nvidia.com>; Michal Simek > > <michal.simek(a)xilinx.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux > > > > External email: Use caution opening links or attachments > > > > > > Hi Varun, > > > > Xilinx is also managing it by special firmware. There is a concept of > protected-clocks documented via DT binding which is used by Qualcomm. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr > > ee/Documentation/devicetree/bindings/clock/clock-bindings.txt?h=next-2 > > 0210621#n172 > > > > Are you also using this feature or simply don't let Linux know about these > clocks at all or simulate it via fixed-clock or so? > > Or any registration is in place that firmware keep refcount of users and > don't let it change unless there is only one user of that clock? > > > > Thanks, > > Michal > > > > On 6/21/21 6:41 PM, Varun Wadekar wrote: > >> Hi Michal, > >> > >> AFAIK, TF-A does not publish guidelines for clocks/resets for shared IP. It > is left to the platforms. > >> > >> For Tegra platforms, the clocks/reset are managed by a central entity. TF- > A is expected to co-ordinate with this entity. Unfortunately, PL011 does not > fall in this category and is expected to be kept on by the previous bootloader. > >> > >> -Varun > >> > >> -----Original Message----- > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > >> Michal Simek via TF-A > >> Sent: Monday, June 21, 2021 2:24 PM > >> To: tf-a(a)lists.trustedfirmware.org > >> Subject: [TF-A] PL011 clock handling between TF-A and Linux > >> > >> External email: Use caution opening links or attachments > >> > >> > >> Hi, > >> > >> recently we have hit the case where Linux has pl011 driver and using it as > a console. The same console is also used by TF-A. If you look at > implementation details Linux pl011 driver has in pl011_console_write() > clk_enable/clk_disable calls. > >> I can't see any clock handling for PL011 in TF-A that's why I guess that TF-A > expectation is that clocks are enabled and must be enabled all the time > because pl011 is also used as crashed console. > >> That's why I would like to check with you what's the clock expectation in > these shared IP cases. > >> Do you have a requirement that firmware should keep refcount of IP > users and never disable clock when only one requires it? > >> > >> Thanks, > >> Michal > >> -- > >> TF-A mailing list > >> TF-A(a)lists.trustedfirmware.org > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > >> t > >> s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> > vwadekar%40nvidia.com%7C9d5af04d3aba49b18cc808d935465267%7C43083 > d1572 > >> > 7340c1b7db39efd9ccc17a%7C0%7C0%7C637599398425726681%7CUnknown% > 7CTWFpb > >> > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn > >> > 0%3D%7C1000&sdata=%2BXFRPZTttom4rvT%2FmEcQnbgSa276PYuKbvo > H4VujRk8 > >> %3D&reserved=0 > >> > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 10 months

3
3
0 0

Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset"

by Olivier Deprez

Hi, See few comments inline [OD] Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 16 June 2021 11:41 To: tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hello, We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms [OD] Just to be clear, is this about SEL0 partitions using an SEL1 shim (as per https://review.trustedfirmware.org/q/topic:%22db%252Fsel0%22+(status:open%2… )? and recently hit an issue, where the “entrypoint-offset” field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the “entrypoint-offset” field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the “entrypoint-offset”, we must manually update it. This needs to be fixed. We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the “entrypoint-offset” past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal. Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling. [OD] We had an attempt (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8536) to move the entry point farther in the image such that we can support 64KB granules in the Stage-1 translation regime. This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. Cheers. [1] 14. FF-A manifest binding to device tree — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-…>

3 years, 11 months

2
8
0 0

Re: [TF-A] PL011 clock handling between TF-A and Linux

by Varun Wadekar

Hi Michal, AFAIK, TF-A does not publish guidelines for clocks/resets for shared IP. It is left to the platforms. For Tegra platforms, the clocks/reset are managed by a central entity. TF-A is expected to co-ordinate with this entity. Unfortunately, PL011 does not fall in this category and is expected to be kept on by the previous bootloader. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Michal Simek via TF-A Sent: Monday, June 21, 2021 2:24 PM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] PL011 clock handling between TF-A and Linux External email: Use caution opening links or attachments Hi, recently we have hit the case where Linux has pl011 driver and using it as a console. The same console is also used by TF-A. If you look at implementation details Linux pl011 driver has in pl011_console_write() clk_enable/clk_disable calls. I can't see any clock handling for PL011 in TF-A that's why I guess that TF-A expectation is that clocks are enabled and must be enabled all the time because pl011 is also used as crashed console. That's why I would like to check with you what's the clock expectation in these shared IP cases. Do you have a requirement that firmware should keep refcount of IP users and never disable clock when only one requires it? Thanks, Michal -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

3 years, 11 months

2
3
0 0

PL011 clock handling between TF-A and Linux

by Michal Simek

Hi, recently we have hit the case where Linux has pl011 driver and using it as a console. The same console is also used by TF-A. If you look at implementation details Linux pl011 driver has in pl011_console_write() clk_enable/clk_disable calls. I can't see any clock handling for PL011 in TF-A that's why I guess that TF-A expectation is that clocks are enabled and must be enabled all the time because pl011 is also used as crashed console. That's why I would like to check with you what's the clock expectation in these shared IP cases. Do you have a requirement that firmware should keep refcount of IP users and never disable clock when only one requires it? Thanks, Michal

3 years, 11 months

1
0
0 0

PIE in tf-a

by virtuoho virtuoho

Hello tf experts, I've been studying the PIE support in TF-A recently, and there is one thing I'm confused about. One is GOT table entry, is there any difference between this and .rela.dyn? I have done some homework, but I didn't find the answer. If someone can tell me, thanks a lot. It looks like the current got segment is only 8 byte, so why must I need this section? Which kind of code will put into this section?

3 years, 11 months

1
0
0 0

TF-A] CANCELLED: TF-A Tech Forum Agenda @ Thr 17th June 2021 16:00-1700 BST

by Joanna Farley

Apologies we don't have any topics to present this week so I am cancelling the TF-A Tech forum for 17th June 2021. We do however we have an exciting topic coming up for Thursday 1st July 2021 which we will share more about nearer the time. In addition I’ll also like to promote this separate Linaro and Arm CCA Tech Event - Deep dive into Arm Confidential Compute Architecture the details of which can be found here https://www.linaro.org/events/linaro-and-arm-cca-tech-day-deep-dive-into-ar… Registration is free for this event which will begin at 14:00 UTC on June 23rd . Thanks all. Joanna

3 years, 11 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "Apologies we don't have any topics to present this week so I am cancelling the Tech forum for 17th June 2021 however we have an exciting topic coming up for Thursday 1st July 2021 which we will share near the time." Title: TF-A Tech Forum 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   When: Thu Jun 17, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 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://calendar.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 organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 11 months

1
0
0 0

SP manifest: avoid manual updates to "entrypoint-offset"

by Varun Wadekar

Hello, We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms and recently hit an issue, where the "entrypoint-offset" field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the "entrypoint-offset" field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the "entrypoint-offset", we must manually update it. This needs to be fixed. We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the "entrypoint-offset" past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal. Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling. Cheers. [1] 14. FF-A manifest binding to device tree - Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-…>

3 years, 11 months

1
0
0 0

Test Post

by Arjun Khare

Test (sorry for the noise)

3 years, 11 months

1
0
0 0

Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID

by Achin Gupta

Hi Francois, The blobs are passed in memory only when the primary core boots. The linear id is required when both primaries and secondaries boot. Secondly, the linear id is used to reference per-cpu structures in memory during very early initialisation. Putting the linear id in a memory structure would either require a per-cpu structure (chicken and egg) or a read-only global structure (to avoid complicated locks with the MMU turned off). It seems to me that the linear id should be passed in an unused register specified by the partition manifest. Passing it in the blob list seems a bit counter intuitive to me but happy to understand your thoughts better. cheers, Achin ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 14 June 2021 16:29 To: Lukas Hanel <lukas.hanel(a)trustonic.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID This looks like a good candidate for the bloblist discussion we have on other mail thread. Why not aggregating "topology" metadata in a block rather than passing "random" information elements in registers? On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi, in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235 The idea here is to pass the core linear id in the x3 register in the boot of secondary cores. In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community. For Kinibi, one binary should run on a multitude of platforms. For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime. In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD. Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code. For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner. There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest. That way, you could change what register the linear id, if at all, should be transferred in. A first tour of the CI showed that there seem to be no consequences to hafnium and optee. I guess, question to the mailing list, is there something that this patch breaks? Greetings, Lukas Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog

3 years, 11 months

2
1
0 0

Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID

by François Ozog

This looks like a good candidate for the bloblist discussion we have on other mail thread. Why not aggregating "topology" metadata in a block rather than passing "random" information elements in registers? On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi, > > in this PR, I propose a first change to the SPMD to better support Kinibi, > the TEE from Trustonic. > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235 > > The idea here is to pass the core linear id in the x3 register in the boot > of secondary cores. > > In the past, the Kinibi SPD was not public and so some requirements to > TF-A were not visible to the wider community. > For Kinibi, one binary should run on a multitude of platforms. > For that reason, many platform-specific settings are shared by TF-A with > Kinibi: at boot, in registers and in a boot datastructure, and at runtime. > > In the line of work of making Kinibi compatible with FFA APIs, I moved > some bits from the Kinibi SPD to the SPMD. > Instead of sharing such patches only with our customers, we would like to > upstream the patches to the generic code. > > For this particular patch, it is really simple and changes the interface > SPMD-to-SPMC in a somewhat adhoc manner. > There is some discussion within ARM to standardize such behavior and to > propose configuration options, i.e. within a manifest. > That way, you could change what register the linear id, if at all, should > be transferred in. > > A first tour of the CI showed that there seem to be no consequences to > hafnium and optee. > I guess, question to the mailing list, is there something that this patch > breaks? > > Greetings, > Lukas > > > Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia > Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS > Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998 > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

3 years, 11 months

1
0
0 0

Support for Kinibi in ATF/SPMD - linear ID

by Lukas Hanel

Hi, in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235 The idea here is to pass the core linear id in the x3 register in the boot of secondary cores. In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community. For Kinibi, one binary should run on a multitude of platforms. For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime. In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD. Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code. For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner. There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest. That way, you could change what register the linear id, if at all, should be transferred in. A first tour of the CI showed that there seem to be no consequences to hafnium and optee. I guess, question to the mailing list, is there something that this patch breaks? Greetings, Lukas Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France - SAS au capital de 3 038 000EUR - RCS Grasse - SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998

3 years, 11 months

1
0
0 0

Re: [TF-A] please fix incomplete distclean Makefile target

by Manish Pandey2

Hi, Can you try below steps, try with fresh pull? 1. Login with your github account on https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a 2. git clone "ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a 3. git push <remote-name> HEAD:refs/for/integration 4. While pushing if it complains about git hooks, run scp -p -P 29418 <user>@review.trustedfirmware.org:hooks/commit-msg "trusted-firmware-a/.git/hooks/" and amend your commit (it will give you this hint) ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Nicolas Boulenguez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 April 2021 13:02 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; 'Benjamin Copeland' <ben.copeland(a)linaro.org> Subject: Re: [TF-A] please fix incomplete distclean Makefile target raghu.ncstate(a)icloud.com: > Are you pushing ssh://<username>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? > Note that 29418 port. That tripped me up initially. It is not clear from your earlier emails where you cloned from(review.trustedfirmware.org or git.trustedfirmware.org). [α] links to [β] which recommends # git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a" I had an existing repository (most contributors probably do) and used 'git add remote' and 'git fetch' instead. [α] recommends # git push <remote-name> HEAD:refs/for/integration%<topic-branch> As expected, the host requires a password. # git push ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? -> fatal: invalid refspec 'HEAD:refs/for/integration?' Anyhow, the host would require an SSH key. [α] https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ [β] https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 11 months

2
1
0 0

Re: [TF-A] issue with vsnprintf() and unsigned_num_print()

by Varun Wadekar

HI Hiren, Can you please add more color to “even if I provide large enough string to hold the number, it does not print it”? Are you saying that the library prints a partial value? If the calculation is off by 1, I assume, the library should at least print a partial value. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Hiren Mehta via TF-A Sent: Saturday, May 29, 2021 9:41 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] issue with vsnprintf() and unsigned_num_print() External email: Use caution opening links or attachments Hi All, We are using the snprintf() (which uses vsnprintf() and unsigned_num_print()) from libc of ATF version 2.4 and running into an issue for printing a number into a string where even if I provide large enough string to hold the number, it does not print it. I don't see that issue with it when I try to print a string using the same snprintf(). I understand that, as per the documentation use of snprintf is "banned or discouraged". But for the use case, that we are using for, it is safe enough to use it assuming that it does it what it is supposed to do. I am not sure if this is a known bug or what, but upon a further inspection, I found that there seems be a small bug in the unsigned_num_print() for one of the 'if' condition given below which is causing the issue in terms of calculating the available space in the string. if (*chars_printed < n) { .... do the prinring.... } I believe it is supposed to be if (*chars_printed <= n) { ----------------->> Notice '<=' instead of '<' } Any comment on whether this is on purpose or really a small bug? The calling routine (vsnprintf) is already reducing 'n' by 1 for the terminating null character. Thank you very much for your support. -hiren

3 years, 11 months

2
2
0 0

Re: [TF-A] TF-A Tech Forum Agenda @ Thr 3rd June 2021 16:00-1700 BST

by François Ozog

Hi food for thought for tomorrow's call: Passing information on what is plugged into the DIMM slots may not be as straightforward as it sounds. You can plug pure DRAM, NVDIMMs or pure flash (from Diablo technologies, acquired by RAMBus in 2019). The pure flash is a module where there is a few MB as bounce buffers to flash located on the DIMM itself. The largest element was 1TB on a single DIMM. So passing a C structure that details the size of the DIMM fails to fully describe NVDIMM and Flash on DIMM. Those two things required complex Passing a DT fragment that describes the plugged module is generic and can describe both the bounce buffers and the registers needed to access the flash on DIMM. In the future you may find associative memory or whatever AI based modules. Bottom line, using DT fragment to describe memory is flexible for the three existing cases and future proof. The document shows that for a 2 DIMM representation and associated SPDs, the additional cost is 88 bytes. 32 are fixed cost, 56 are somewhat name size dependent and some related to FDT format. There is no need for a full libfdt to actually produce that serialized data on a hob. So in my view, the benefit of having an alignment, version and evolution proof structure that comes with DT fragment by far exceeds the cost of a few bytes saved, even in the context of SRAM size. Cheers FF On Wed, 2 Jun 2021 at 17:33, Joanna Farley via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > The next TF-A Tech Forum is scheduled for Thu 3rd June 2021 16:00 – 17:00 > (BST). > > > > Agenda: > > - Discussion Session: Static and Dynamic Information Handling in TF-A > (Session 2) > - Lead by Manish Pandy and Madhukar Pappireddy > - On tech forum this week, we would like to continue discussions on > HOB list design. > - The topics which we would like to cover is > 1. Evaluate different proposals of passing information through > boot phases. > 2. If we don't get an agreement on one solution fit for all then > we would try to get consensus for Infra segment platform(to solve original > problem mentioned by Harb) > 3. Try to get an agreement on size of tags and how "hybrid and > tag only" HOB list can co-exist together? > > > > > > Thanks > > > > Joanna > > > > > *You have been invited to the following event.* TF-A Tech Forum > > *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) > > 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 > > +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>. > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

3 years, 11 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 3rd June 2021 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 3rd June 2021 16:00 – 17:00 (BST). Agenda: * Discussion Session: Static and Dynamic Information Handling in TF-A (Session 2) * Lead by Manish Pandy and Madhukar Pappireddy * On tech forum this week, we would like to continue discussions on HOB list design. * The topics which we would like to cover is * Evaluate different proposals of passing information through boot phases. * If we don't get an agreement on one solution fit for all then we would try to get consensus for Infra segment platform(to solve original problem mentioned by Harb) * Try to get an agreement on size of tags and how "hybrid and tag only" HOB list can co-exist together? Thanks Joanna You have been invited to the following event. TF-A Tech Forum 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) 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 +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>.

3 years, 11 months

1
0
0 0

Re: [TF-A] Linux kernel set the hypervisor vector table through ATF

by Marc Zyngier

On Tue, 01 Jun 2021 14:34:05 +0100, Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote: > > Marc Zyngier <maz(a)kernel.org> 于2021年6月1日周二下午6:09写道： > > > > On Tue, 01 Jun 2021 10:53:49 +0100, > > Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote: > > > > > > Mark Rutland <mark.rutland(a)arm.com> 于2021年6月1日周二下午5:19写道： > > > > > > > > On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote: > > > > > Hi All, > > > > > when Linux kernel boot from EL1, there is no method to let > > > > > kernel to enter EL2 to enable hypervisor. so I want to add an SMC > > > > > interface between kernel and EL3 ATF to let kernel can set the > > > > > hypervisor vector table, then can enter EL2 to enable hypervisor, as > > > > > shown in [1]. > > > > > Do you agree? Otherwise there is no method to enter EL2 hypervisor > > > > > when kernel boot from EL1, because the hypervisor vector > > > > > table(vbar_el2) is unknown. > > > > > > > > The kernel already supported being booted at EL2, where it will install > > > > itself as the hypervisor (and will drop to EL1 if required). EL2 is the > > > > preferred boot mode, as we document in: > > > > > > > > https://www.kernel.org/doc/html/latest/arm64/booting.html > > > > > > > > ... where we say: > > > > > > > > | The CPU must be in either EL2 (RECOMMENDED in order to have access to > > > > | the virtualisation extensions) or non-secure EL1. > > > > > > > > We *strongly* prefer this over adding new ABIs to transition from EL1 to > > > > EL2. Please boot the kernel at EL2 if you want to use KVM. > > > > > > Thanks for the answer. > > > If use KVM, it should boot from EL2. But if the hypervisor is not > > > KVM, such as Jailhouse hypervisor and some Chip manufacturer boot the > > > host kernel from EL1(not follow above rule), it seems there is not way > > > to enter the Jailhouse hypervisor. > > > > We only deal with two cases: > > - either the kernel uses its own, built-in hypervisor: it boots at > > EL2, and installs itself. > > > > - or there is a pre-existing hypervisor, and the kernel boots at EL1. > > > > In the past, Jailhouse used the exact same entry points as KVM. What > > has changed? > > Jailhouse use the __hyp_stub_vectors vector table[1] in linux > kernel arch/arm64/kernel/hyp-stub.S to re-set his own's hypervisor > vector table, but if linux kernel is boot from EL1，it can not use the > entry points(__hyp_stub_vectors). I agree Linux kernel is recommended > boot from EL2, but some custer's boards not follow this rule. So Jailhouse doesn't have this problem when used as intended. > > [1]: > ENTRY(__hyp_stub_vectors) > ventry el2_sync_invalid // Synchronous EL2t > ventry el2_irq_invalid // IRQ EL2t > ventry el2_fiq_invalid // FIQ EL2t > ventry el2_error_invalid // Error EL2t > > ventry el2_sync_invalid // Synchronous EL2h > ventry el2_irq_invalid // IRQ EL2h > ventry el2_fiq_invalid // FIQ EL2h > ventry el2_error_invalid // Error EL2h > > ventry el1_sync // Synchronous 64-bit EL1 > ventry el1_irq_invalid // IRQ 64-bit EL1 > ventry el1_fiq_invalid // FIQ 64-bit EL1 > ventry el1_error_invalid // Error 64-bit EL1 > > ventry el1_sync_invalid // Synchronous 32-bit EL1 > ventry el1_irq_invalid // IRQ 32-bit EL1 > ventry el1_fiq_invalid // FIQ 32-bit EL1 > ventry el1_error_invalid // Error 32-bit EL1 > ENDPROC(__hyp_stub_vectors) > > > > > Finally, if you can change the firmware to install the EL2 vectors, > > you can also change it to enter the kernel at EL2. I suggest you do > > that instead. > > I agree with you, but needs to change customer‘s board, I will try to > discuess with customer. In both cases, you'll need to change your customer's firmware. It seems to me that there is no reason for the arm64 boot protocol to change and adopt weird, wonderful and proprietary privilege escalation methods. Thanks, M. -- Without deviation from the norm, progress is not possible.

3 years, 11 months

1
0
0 0

Re: [TF-A] Linux kernel set the hypervisor vector table through ATF

by Marc Zyngier

On Tue, 01 Jun 2021 10:53:49 +0100, Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote: > > Mark Rutland <mark.rutland(a)arm.com> 于2021年6月1日周二下午5:19写道： > > > > On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote: > > > Hi All, > > > when Linux kernel boot from EL1, there is no method to let > > > kernel to enter EL2 to enable hypervisor. so I want to add an SMC > > > interface between kernel and EL3 ATF to let kernel can set the > > > hypervisor vector table, then can enter EL2 to enable hypervisor, as > > > shown in [1]. > > > Do you agree? Otherwise there is no method to enter EL2 hypervisor > > > when kernel boot from EL1, because the hypervisor vector > > > table(vbar_el2) is unknown. > > > > The kernel already supported being booted at EL2, where it will install > > itself as the hypervisor (and will drop to EL1 if required). EL2 is the > > preferred boot mode, as we document in: > > > > https://www.kernel.org/doc/html/latest/arm64/booting.html > > > > ... where we say: > > > > | The CPU must be in either EL2 (RECOMMENDED in order to have access to > > | the virtualisation extensions) or non-secure EL1. > > > > We *strongly* prefer this over adding new ABIs to transition from EL1 to > > EL2. Please boot the kernel at EL2 if you want to use KVM. > > Thanks for the answer. > If use KVM, it should boot from EL2. But if the hypervisor is not > KVM, such as Jailhouse hypervisor and some Chip manufacturer boot the > host kernel from EL1(not follow above rule), it seems there is not way > to enter the Jailhouse hypervisor. We only deal with two cases: - either the kernel uses its own, built-in hypervisor: it boots at EL2, and installs itself. - or there is a pre-existing hypervisor, and the kernel boots at EL1. In the past, Jailhouse used the exact same entry points as KVM. What has changed? Finally, if you can change the firmware to install the EL2 vectors, you can also change it to enter the kernel at EL2. I suggest you do that instead. Thanks, M. -- Without deviation from the norm, progress is not possible.

3 years, 11 months

1
0
0 0

Re: [TF-A] Linux kernel set the hypervisor vector table through ATF

by Mark Rutland

On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote: > Hi All, > when Linux kernel boot from EL1, there is no method to let > kernel to enter EL2 to enable hypervisor. so I want to add an SMC > interface between kernel and EL3 ATF to let kernel can set the > hypervisor vector table, then can enter EL2 to enable hypervisor, as > shown in [1]. > Do you agree? Otherwise there is no method to enter EL2 hypervisor > when kernel boot from EL1, because the hypervisor vector > table(vbar_el2) is unknown. The kernel already supported being booted at EL2, where it will install itself as the hypervisor (and will drop to EL1 if required). EL2 is the preferred boot mode, as we document in: https://www.kernel.org/doc/html/latest/arm64/booting.html ... where we say: | The CPU must be in either EL2 (RECOMMENDED in order to have access to | the virtualisation extensions) or non-secure EL1. We *strongly* prefer this over adding new ABIs to transition from EL1 to EL2. Please boot the kernel at EL2 if you want to use KVM. Thanks, Mark. > > > > [1]: > el1_sync: > cmp x0, #SMC_SET_VECTORS > b.ne 2f > msr vbar_el2, x1 > b 9f > > 2: cmp x0, #SMC_SOFT_RESTART > b.ne 3f > mov x0, x2 > mov x2, x4 > mov x4, x1 > mov x1, x3 > br x4 // no return > > 3: cmp x0, #SMC_RESET_VECTORS > beq 9f // Nothing to reset! > > ldr x0, =SMC_STUB_ERR > eret > > 9: mov x0, xzr > eret > ENDPROC(el1_sync) > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

3 years, 11 months

1
0
0 0

issue with vsnprintf() and unsigned_num_print()

by Hiren Mehta

Hi All, We are using the snprintf() (which uses vsnprintf() and unsigned_num_print()) from libc of ATF version 2.4and running into an issue for printing a number into a string where even if I provide large enough string to hold the number, it does not print it. I don't see that issue with it when I try to print a string using the same snprintf().I understand that, as per the documentation use of snprintf is "banned or discouraged". But for the use case,that we are using for, it is safe enough to use it assuming that it does it what it is supposed to do. I am not sure if this is a known bug or what, but upon a further inspection, I found that there seems be a small bugin the unsigned_num_print() for one of the 'if' condition given below which is causing the issue in terms of calculatingthe available space in the string. if (*chars_printed < n) { .... do the prinring....} I believe it is supposed to be if (*chars_printed <= n) { ----------------->> Notice '<=' instead of '<' } Any comment on whether this is on purpose or really a small bug? The calling routine (vsnprintf) is already reducing 'n' by 1 for the terminating null character. Thank you very much for your support.-hiren

3 years, 11 months

1
0
0 0

Re: [TF-A] zynqmp: How to inform the bl33 about RAM reservation?

by Samuel Holland

On 4/19/21 11:11 AM, Jan Kiszka via TF-A wrote: > On 19.04.21 17:21, Michal Simek wrote: >> On 4/18/21 8:44 PM, Jan Kiszka wrote: >>> when SPD or DEBUG is enabled, TF-A is moved to RAM on the zynqmp (as it >>> longer fits into OCM). U-Boot happens to avoid that region, but the >>> kernel's DTB has no reservation entry, and Linux will trigger an >>> exception when accessing that region during early boot. >>> >>> Can we improve this - without requiring the user to manually add a >>> reservation to the DTB? Should we unconditionally reserve >>> 0x1000..0x7ffff in all BL33 DTBs? Or is there a chance to communicate >>> that need? Or some way to detect in BL33 whether it is needed? >> >> Normally this ddr region should be also protected by security IPs that >> NS has no access there. >> It means in Xilinx flow this can be (and should be) propagated via >> device-tree generator to final DTS file that you don't need to touch it >> by hand. >> I am not aware about any way that NS can query secure world what memory >> can be used. And not sure if there is any standard way to do so. >> > > OK, understood. But then, to be safe, shouldn't the upstream "static" > default DT contain an exclusion of that region so that it won't get > stuck if it is in use? Would block half a meg, but when you have a > custom platform that does not need that, you can and will provide your > own DT anyway. Ideally, the static DTS is a description of the hardware only, and not of runtime constraints imposed by the firmware. If BL31 needs to reserve some memory, it can add that reservation to the DTB at runtime. The fdt_add_reserved_memory() function is available for this purpose. For an example, see the code used by the rpi4[0] or sun50i_h616[1] platforms. If you later load a DTB from disk for use by Linux, you will need to copy the reserved-memory nodes from the U-Boot DTB to the loaded DTB. Regards, Samuel [0]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/rpi/r… [1]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/allwi…

3 years, 11 months

3
2
0 0

Re: [TF-A] MEM_PROTECT for secure world?

by Sandrine Bailleux

Hi Okash, Varun, Sorry I've not had a chance to properly read this email thread yet so apologies if my comment is irrelevant. I just wanted to point out that TF-A Tests provide some tests for MEM_PROTECT [1] and MEM_PROTECT_CHECK [2] SMC interfaces, in case that helps clarifying their intended usage. Cheers, Sandrine [1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime… [2] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime…

3 years, 11 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A