- TF-A - lists.trustedfirmware.org

TF-A Tech Forum Agenda @ Thr 6th May 2021 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). Agenda: * Discussion Session: Static and Dynamic Information Handling in TF-A * Lead by Manish Pandy and Madhukar Pappireddy · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. The requirement is two-fold: 1. Passing static information(config files) 2. Passing dynamic information (Hob list) In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. The two specific item which we would like to discuss are: 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? 2. Standardization on Physical register use to pass base of HoB data structure. References: [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% Thanks Joanna 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 Who • Bill Fletcher- creator • tf-a(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 One 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-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>.

4 years, 9 months

1
0
0 0

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

by François Ozog

Le mar. 27 avr. 2021 à 11:04, Loh, Tien Hock via TF-A < tf-a(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> > *Sent:* Tuesday, April 27, 2021 5:01 PM > *To:* Achin Gupta <Achin.Gupta(a)arm.com>; tf-a(a)lists.trustedfirmware.org; > Loh, Tien Hock <tien.hock.loh(a)intel.com> > *Cc:* See, Chin Liang <chin.liang.see(a)intel.com>; Hea, Kok Kiang < > kok.kiang.hea(a)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> > *Sent:* Tuesday, 27 April, 2021 4:38 PM > *To:* tf-a(a)lists.trustedfirmware.org; Loh, Tien Hock < > tien.hock.loh(a)intel.com> > *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:* 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> 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 > > > -- > 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, 9 months

2
3
0 0

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

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

4 years, 9 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

4 years, 9 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

4 years, 9 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

4 years, 9 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ä

4 years, 9 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…

4 years, 9 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, 9 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, 9 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A