- TF-A - lists.trustedfirmware.org

by Manish Pandey2

Hi Tien Hock, Did you explored EL3_PAYLOAD_BASE build option. This option enables booting an EL3 payload, if it suits you then u-boot as EL3 payload. thanks Manish ________________________________ 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: 27 April 2021 20:16 To: Loh, Tien Hock <tien.hock.loh(a)intel.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; See, Chin Liang <chin.liang.see(a)intel.com>; Chee, Tien Fong <tien.fong.chee(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com> Subject: Re: [TF-A] Run BL33 (u-boot) in EL3 Le mar. 27 avr. 2021 à 11:04, Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> a écrit : Achin, Yes that’s what I have suspected in the first place, but no harm asking :) Tien Fong, As per discussed, we could probably expose the a compile time option in BL31 that expose a command that read/write to the secure domain. That case, u-boot shell will be able to access secure domain and not need to run in EL3. Would you allow an OS to access underlying hypervisor ? In essence this is what you are asking: there are architectural services such as kicking off a new cpu that are supposed to be routed to the right service handler (PSCI) or secure firmware updates with anti-bricking support.... Could you be more specific on what you want to do and why ? That may help us advise on achieving your goals while still being architecturally correct. Thanks From: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>> Sent: Tuesday, April 27, 2021 5:01 PM To: Achin Gupta <Achin.Gupta(a)arm.com<mailto:Achin.Gupta@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; Loh, Tien Hock <tien.hock.loh(a)intel.com<mailto:tien.hock.loh@intel.com>> Cc: See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>> Subject: RE: Run BL33 (u-boot) in EL3 Hi Achin, Thanks for the feedback. This is use case when user doing development, testing and bring up the board, they can use this option to run their script on U-Boot shell to access these secure region. Once they have finished the development, and testing, then user can switch U-Boot into EL2. This flexibility would definitely giving some degree of convenience for development and testing. Thanks. From: Achin Gupta <Achin.Gupta(a)arm.com<mailto:Achin.Gupta@arm.com>> Sent: Tuesday, 27 April, 2021 4:38 PM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; Loh, Tien Hock <tien.hock.loh(a)intel.com<mailto:tien.hock.loh@intel.com>> Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>>; See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>> Subject: Re: Run BL33 (u-boot) in EL3 Hi Tien Hock, The maintainers will have more thoughts on this but my $0.02 fwiw. I cannot see why the Trusted Firmware project should carry any option that enables use of EL3 by users who do not care about security. EL3 is not meant to run u-boot with a shell that can be used to fiddle with secure memory. This flies against the basic security principles that the project is built upon. cheers, Achin ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 27 April 2021 09:02 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>>; See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>> Subject: [TF-A] Run BL33 (u-boot) in EL3 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 -- 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, 8 months

2
1
0 0

Re: [TF-A] Run BL33 (u-boot) in EL3

by Achin Gupta

Hi Tien Hock, The maintainers will have more thoughts on this but my $0.02 fwiw. I cannot see why the Trusted Firmware project should carry any option that enables use of EL3 by users who do not care about security. EL3 is not meant to run u-boot with a shell that can be used to fiddle with secure memory. This flies against the basic security principles that the project is built upon. cheers, Achin ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 27 April 2021 09:02 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com>; See, Chin Liang <chin.liang.see(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com> Subject: [TF-A] Run BL33 (u-boot) in EL3 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

3 years, 8 months

3
2
0 0

Question on how enable TF-A SPM on iMX8M

by Jun Nie

Hi, I am trying to enable SPM on iMX8MP platform, which is cortex-A53. The BL2 is already enabled and the dts file is needed. But I am not sure how to write below dts information when I referencing fvp_spmc_manifest.dts. Could you help to give some suggestion or where should I find the anwsers? 1. Is fvp_spmc_manifest.dts enough to enable SPM? I see there are dts files, such as fvp_fw_config.dts. What's necessary dts nodes to enable SPM? 2. Does vcpu_count means CPU number? 3. I see load_address of attribute is optee-os load address. But I do not know how should I decide the load addresses of hypervisors. Is this address decided by virtual machine, or it is decided in runtime? I cannot find the 0x7100000 in trusted-services project. 4. I am confused on "Secure Partitions are bundled as independent package files" in below link. Does this bundle package means fip image, or into another file by jason file? Could you help point to the files and image generation command? https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/compo… Regards, Jun

3 years, 8 months

5
20
0 0

Run BL33 (u-boot) in EL3

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

3 years, 8 months

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ä

3 years, 8 months

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…

3 years, 8 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

3 years, 8 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

3 years, 8 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

3 years, 8 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

3 years, 8 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A