- TF-A - lists.trustedfirmware.org

by Loh, Tien Hock

Hi, I'm maintaining TF-A for Intel SoCFPGA platform. Would it be possible if we should have the option to run BL33 (u-boot in our case) in EL3? The Intel SoCFPGA platform u-boot used to handle all SMC calls: SPL u-boot (EL3) -> u-boot (EL3) And we have since move to use TF-A's BL31, thus boot became SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2) Main reason is that some users would like to keep u-boot at EL3 as they do not care about security, and some users wanted to run some debugging read/write to secure region in u-boot shell. Thanks Tien Hock

4 years, 1 month

1
0
0 0

suspend to ram on rk3399 theobroma puma

by Mika Penttilä

Hi all! We are developing a product around the rk3399 Theobroma Q7 module. For power savings, we need S3 sleep (suspend-to-ram). As far as I know, the heart of this is in ATF code. We have linux kernel 5.4, which starts the process nicely, drives down all the other cores and finally calls for the psci suspend. We have wakeup on irq, and it sure wakes up, but does a reset from the very beginning. So no context saving resume. I have tried the newest on the ATF git, with a newish mainline uboot. I suppose the role of uboot is not that important here. What should I look at to find the problem? Has someone got the Q7 module done S3 ok? Finally, how do I get some debug uart output from ATF code? Thanks for any hints! Mika Penttilä

4 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 370380: Code maintainability issues (UNUSED_VALUE) /plat/xilinx/versal/pm_service/pm_svc_main.c: 96 in pm_setup() ________________________________________________________________________________________________________ *** CID 370380: Code maintainability issues (UNUSED_VALUE) /plat/xilinx/versal/pm_service/pm_svc_main.c: 96 in pm_setup() 90 int status, ret = 0; 91 92 status = pm_ipi_init(primary_proc); 93 94 if (status < 0) { 95 INFO("BL31: PM Service Init Failed, Error Code %d!\n", status); >>> CID 370380: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "status" to "ret" here, but that stored value is overwritten before it can be used. 96 ret = status; 97 } else { 98 pm_up = true; 99 } 100 101 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 2 months

1
0
0 0

Re: [TF-A] [Hafnium] Getting Started page: problem with the command under "Getting the source code"

by Gyorgy Szing

Hi, Just my two cents: - I suggest using $() instead of the backtick operator to enhance readability. This means f=`git rev-parse --git-dir` becomes f=$(git rev-parse --git-dir) - use {} to group commands instead of () (no sub-shell is needed) - stop processing if curl fails (hence second {} block) - if the repo path has spaces, then some quotes are missing So finally the command would become: git clone --recurse-submodules https://git.trustedfirmware.org/hafnium/hafnium.git && { cd hafnium && f="$(git rev-parse --git-dir)"; curl -Lo "$f/hooks/commit-msg" https://review.trustedfirmware.org/tools/hooks/commit-msg && { chmod +x "$f/hooks/commit-msg"; git submodule --quiet foreach "cp \"\$toplevel/$f/hooks/commit-msg\" \"\$toplevel/$f/modules/\$path/hooks/commit-msg\"" ; } ; } /George -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via Hafnium Sent: 21 April 2021 19:12 To: Rebecca Cran <rebecca(a)bsdio.com>; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] Getting Started page: problem with the command under "Getting the source code" Hi, Ah sorry for that; looks like there's some variable escape problem. I tried this with success, let me know if it works for you. I will update the doc page then. git clone --recurse-submodules https://git.trustedfirmware.org/hafnium/hafnium.git && (cd hafnium && f=`git rev-parse --git-dir`; curl -Lo $f/hooks/commit-msg https://review.trustedfirmware.org/tools/hooks/commit-msg; chmod +x $f/hooks/commit-msg; git submodule --quiet foreach "cp \$toplevel/$f/hooks/commit-msg \$toplevel/$f/modules/\$path/hooks/commit-msg") If you don't require the git hooks a simpler way to clone the project can be: git clone "https://review.trustedfirmware.org/hafnium/hafnium"; cd hafnium git submodule update --init Regards, Olivier. ________________________________________ From: Rebecca Cran <rebecca(a)bsdio.com> Sent: 21 April 2021 16:33 To: Olivier Deprez; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] Getting Started page: problem with the command under "Getting the source code" It now exits with the message: cp: cannot stat '/home/rebecca/src/uefi/tmp/hafnium//hooks/commit-msg': No such file or directory fatal: run_command returned non-zero status for driver/linux . -- Rebecca Cran On 4/21/21 2:23 AM, Olivier Deprez wrote: > Hi Rebecca, > > Thanks for reporting. > > Can you try with the updated command: > https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/r > efs/changes/31/9731/1/docs/GettingStarted.md > > Thanks, Olivier. > > > ________________________________________ > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Rebecca Cran via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 21 April 2021 04:39 > To: hafnium(a)lists.trustedfirmware.org > Subject: [Hafnium] Getting Started page: problem with the command under "Getting the source code" > > On the Getting Started document > (https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/ > HEAD/docs/GettingStarted.md) there's a command listed to get the > source code: > > git clone --recurse-submodules > https://git.trustedfirmware.org/hafnium/hafnium.git && (cd hafnium && > f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f > https://review.trustedfirmware.org/tools/hooks/commit-msg ; chmod +x > $f ; for m in `git rev-parse --git-dir`/modules/*; do cp $f > $m/hooks/commit-msg; done) > > > However, on my system it's erroring out because the 'hooks' directory > it tries to write to doesn't exist: > > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left Speed > 100 2174 100 2174 0 0 4221 0 --:--:-- --:--:-- > --:--:-- 4221 > cp: cannot create regular file '.git/modules/driver/hooks/commit-msg': > No such file or directory > cp: cannot create regular file '.git/modules/project/hooks/commit-msg': > No such file or directory > cp: cannot create regular file > '.git/modules/third_party/hooks/commit-msg': No such file or directory > > > -- > Rebecca Cran > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium > -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 2 months

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Apr 22, 2021 8am - 9am (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been canceled with this note: "Cancelled per Joanna" 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 Apr 22, 2021 8am – 9am Mountain Standard Time - Phoenix 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

4 years, 2 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 22nd April 2021 16:00-1700 BST CANCELLED

by Joanna Farley

Hi Everyone, I am cancelling this weeks TF-A Tech Forum as I don’t have any areas to present/discuss. I would encourage any contributors that wants to present or lead a discussion subject to please let me know as we are always looking for topics of interest to the project community to run sessions on. Cancellations of the calendar invite will come from trustedformware.org. Thanks Joanna

4 years, 2 months

1
0
0 0

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

by François Ozog

Hi There is a discussion started by Harb from Ampere about standardizing information from secure firmware to BL33: look at HOB in the object. A side aspect of the HOB is: DT shall be used wisely for things that are really static. Dynamic (such as plugged DIMMs) or configurable aspects (secure memory size) should be controllable by a single authoritative entity. On a number of platforms, the definition of secure memory size is "copied" in at least for different independent projects which make it a nightmare for product makers to choose a size for the trusted application they want to onboard. Cheers FF On Tue, 20 Apr 2021 at 07:49, Jan Kiszka via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > On 20.04.21 02:51, Samuel Holland wrote: > > 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. > > > > I know the RPi4 model (just had to debug it [3]). But I wonder if that > is possible on the zynqmp as well. Are we passing a DT to BL33 here > already and, thus, could inject that reservation? > > Jan > > > 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] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9316 > -- > 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

4 years, 2 months

1
0
0 0

Re: [TF-A] [RFC] TF-A threat model

by Varun Wadekar

Hi, This looks promising. Can you also create a list of guidelines resulting from the analysis? We can then roll them up as coding guidelines or design guidelines or to-do for platforms. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Zelalem Aweke via TF-A Sent: Friday, April 16, 2021 8:15 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [RFC] TF-A threat model External email: Use caution opening links or attachments Hi All, We are releasing the first TF-A threat model document. This release provides the baseline for future updates to be applied as required by developments to the TF-A code base. Please review the document provide comments here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9627<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Thanks, Zelalem

4 years, 2 months

2
2
0 0

Re: [TF-A] platform g12a: CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035

by Manish Pandey2

Hi, >From git log g12a platform was first introduced in 2019 and never has any further changes, also there is no documentation for this platform, so from platform perspective not sure if you are doing everything right or not ? However, i have some generic comments 1. There is no such macro DISABLE_PEDANTIC 2. Which CPU you have in Odroid-C4 boards(is it Cortext-A55?), You probably need to add cpu lib file in platform.mk file In file plat/amlogic/g12a/platform.mk BL31_SOURCES += lib/cpus/aarch64/cortex_a53.S \ lib/cpus/aarch64/cortex_a55.S thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Matwey V. Kornilov via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 19 April 2021 16:47 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] platform g12a: CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035 Hello, Sorry, if this is the wrong place to ask. I am trying to run ATF v2.4 for platform g12a on the Odroid-C4 board. I've built ATF as the following make DISABLE_PEDANTIC=1 DEBUG=1 PLAT=g12a Unfortunately, the only thing I see in the console when BL31 is supposed to run is CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035 Is there any chance to figure out what is wrong? -- With best regards, Matwey V. Kornilov -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 2 months

1
0
0 0

zynqmp: How to inform the bl33 about RAM reservation?

by Jan Kiszka

Hi all, 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? Jan

4 years, 2 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A