Hi Andy,
Please find my reply in the previous mail.
Regards,
JK
From: Andy Chen <andychen(a)pufsecurity.com>
Sent: Wednesday, July 24, 2024 8:11 PM
To: Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Jothikumar Mani <Jothikumar.Mani(a)arm.com>; tf-a(a)lists.trustedfirmware.org
Cc: Diya Soubra <Diya.Soubra(a)arm.com>; Victoria Lee <victorialee(a)pufsecurity.com>; Andrew <andrewirvin(a)pufsecurity.com>
Subject: 回覆: Integrate TF-A and PSA Crypto API with PUFcc
Hi Manish,
Thanks for your information.
We need to integrate our hardware Crypto IP (PUFcc). And it seems that FVP cannot add custom IP, so we are planning to purchase an FPGA with the A53 - AXU9EGB<https://www.xilinx.com/products/boards-and-kits/1-1ervp7b.html> for our needs. And we need to make sure it is compatible with TF-A lts-v2.10.5.
Thanks.
Hi Jothikumar,
We would try to integrate with PSA Crypto API, and we need a test bench for v1.2.1.
Please feel free to let me know if you have any suggestions.
[JK] : may I know what the intent is to requesting the crypto v1.2.1 spec compliance suites?, if you are looking for the PSA Certified APIs compliance for your product then the currently available testsuite is more than sufficient. Also, the mbedTLS version mentioned also only supports psa-crypto spec v1.1.0. I am trying to under the end goal of the psa certified api compliance suite usage with your product. Answer to this question will help me to give better suggestion.
For TF-A, we plan to integrate with:
TF-A lts-v2.10.5
PSA Crypto API - v1.1.0 >>> v1.2.1
PSA Certified APIs Architecture Test Suite - v1.6
Thank you very much.
Have a Nice Day,
Andy
________________________________
寄件者: Manish Badarkhe <Manish.Badarkhe(a)arm.com<mailto:Manish.Badarkhe@arm.com>>
寄件日期: 2024年7月24日 下午 06:12
收件者: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>; Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>>; Jothikumar Mani <Jothikumar.Mani(a)arm.com<mailto:Jothikumar.Mani@arm.com>>
副本: Diya Soubra <Diya.Soubra(a)arm.com<mailto:Diya.Soubra@arm.com>>; Victoria Lee <victorialee(a)pufsecurity.com<mailto:victorialee@pufsecurity.com>>; Andrew <andrewirvin(a)pufsecurity.com<mailto:andrewirvin@pufsecurity.com>>
主旨: Re: Integrate TF-A and PSA Crypto API with PUFcc
Hi Andy
Please see my replies inline. Adding Jothikumar Mani for PSA Certified APIs Architecture Test Suite.
Thanks,
Manish Badarkhe
________________________________
From: Andy Chen via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>
Sent: 23 July 2024 09:55
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: Diya Soubra <Diya.Soubra(a)arm.com<mailto:Diya.Soubra@arm.com>>; Victoria Lee <victorialee(a)pufsecurity.com<mailto:victorialee@pufsecurity.com>>; Andrew <andrewirvin(a)pufsecurity.com<mailto:andrewirvin@pufsecurity.com>>
Subject: [TF-A] Integrate TF-A and PSA Crypto API with PUFcc
Hi TF-A teams,
This is Andy from PUFsecurity, and we have a project with ARM.
We try to integrate the PSA Crypto API with PUFcc (Our Crypto Engine) on TF-A.
However, there are multiple versions included, and we need your assistance for specification clarification.
Please ensure the versions match your recommendations.
For TF-A, we plan to integrate with:
TF-A lts-v2.10.5
PSA Crypto API - v1.1.0
PSA Certified APIs Architecture Test Suite - v1.6
[MB]: This looks fine. As TF-A lts-v2.10.5 using mbedTLS v3.6.0 which is compliance with PSA Crypto API - v1.1.0 but mbedTLS team can provide more detailed answer on this and also on test suite PSA Certified APIs Architecture Test Suite - v1.6.
TF-A
It would be beneficial to use the same hardware (FPGA) and tools as the ARM development team.
If we can confirm which models are used for TF-A , scripts or details with the ARM hardware That would be grateful.
[MB]: We are using FVP AEM model i.e. FVP_Base_RevC-2xAEMvA (Model version: 11.26, Build: 11). Test Run with PSA Crypto
you can find here: https://ci.trustedfirmware.org/job/tf-a-builder/4029201/ (today's daily run)
PSA Crypto API -
The test bench is using the PSA Crypto API v1.1.0, and it is published in 2022.
And Now is v1.2.1 in March 2024. I not sure it is a good choose or not.
[cid:image001.png@01DADE0E.1BA75330]
[MB]: It looks like arch-test is not upgraded to use v1.2.1 PSA Crypto API. Added Jothikumar Mani, he may have idea about this.
Test Bench -
For the "PSA Certified APIs Architecture Test Suite - v1.6," we would like to identify which test codes (test_c001 to test_c067) are relevant for TF-A.
[MB]: Again, TF-A is not using this test suite, so we don't have any insights unless we review all these tests. TF-A mainly uses the following PSA_* APIs for signature verification, hash calculation, and hash comparison.
psa_crypto_init
mbedtls_md_psa_alg_from_type
psa_set_key_algorithm
psa_set_key_type
psa_set_key_usage_flags
psa_import_key
psa_destroy_key
psa_verify_message
psa_hash_compute
psa_hash_compare
Thank you very much!!!
Have a Nice Day,
Andy
[cid:image002.png@01DADE0E.1BA75330]
熵碼科技股份有限公司
Tel: 886-3-5601010 #2119
Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>
Website: https://www.pufsecurity.com/
-------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------
-------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------
-------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------
This event has been updated
Changed: time
TF-A Tech Forum
Every 2 weeks from 9am to 10am on Thursday from Thursday Mar 7 to Wednesday
Jul 24
Mountain Standard Time - Phoenix
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been updated
TF-A Tech Forum
Every 2 weeks from 8am to 9am on Thursday
Mountain Standard Time - Phoenix
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi TF-A teams,
This is Andy from PUFsecurity, and we have a project with ARM.
We try to integrate the PSA Crypto API with PUFcc (Our Crypto Engine) on TF-A.
However, there are multiple versions included, and we need your assistance for specification clarification.
Please ensure the versions match your recommendations.
For TF-A, we plan to integrate with:
TF-A lts-v2.10.5
PSA Crypto API - v1.1.0
PSA Certified APIs Architecture Test Suite - v1.6
TF-A
It would be beneficial to use the same hardware (FPGA) and tools as the ARM development team.
If we can confirm which models are used for TF-A , scripts or details with the ARM hardware That would be grateful.
PSA Crypto API -
The test bench is using the PSA Crypto API v1.1.0, and it is published in 2022.
And Now is v1.2.1 in March 2024. I not sure it is a good choose or not.
[cid:0e747007-8c2a-49a7-9447-8d5e7f9a3e9c]
Test Bench -
For the "PSA Certified APIs Architecture Test Suite - v1.6," we would like to identify which test codes (test_c001 to test_c067) are relevant for TF-A.
Thank you very much!!!
Have a Nice Day,
Andy
[cid:74269c28-12d4-48a9-b215-3d3eaf95f2c3]
熵碼科技股份有限公司
Tel: 886-3-5601010 #2119
Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>
Website: https://www.pufsecurity.com/
-------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------
-------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------
Hi, On Jul 25th in the TF-A Tech Forum: Unification of Chain of Trust
Descriptors - presented by Xialin Liu Currently, the Chain of Trust is
implemented using C data structures built into the firmware or through
device tree nodes. Maintaining both formats can lead to maintenance
challenges. Therefore, we are standardizing the provision of Chain of Trust
descriptors exclusively via the device tree and providing a tool to convert
device tree descriptors into C source files. This approach simplifies the
process, ensuring consistency and reducing the potential for errors
associated with managing multiple formats. Regards, Olivier.
TF-A Tech Forum
Thursday Jul 25, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
Greetings everyone,
I came across the following paragraph while reading the 'Firmware Partition Filesystem' chapter from EBBR v2.2.0
and I would like to clarify my understanding:
Where possible, firmware images and data should be stored in a filesystem. Firmware can be stored either in a
dedicated firmware partition, or in certain circumstances in the UEFI System Partition (ESP). Using a filesystem
makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware
for multiple platforms.
Dedicated firmware partitions should be formatted with a FAT filesystem as defined in UEFI § 13.3 File System
Format. Dedicated firmware partitions should use the same /FIRMWARE directory hierarchy. OS tools shall ignore
dedicated firmware partitions, and shall not attempt to use a dedicated firmware partition as an ESP
Questions:
1. Does the above paragraph mean that, if the device allows, all firmware binaries (TF-A, U-Boot, and some others)
must be stored in a dedicated firmware partition formatted with a FAT filesystem and GUID Partition Table (GPT)
disk layout?
2. If so, would this also mean that, where possible, the BootROM or a (first stage) bootloader running before TF-A
should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Regards,
Ghennadi
Hi,
On AMD-Xilinx ZynqMP platform for ERRATA_NOT_APPLIES case; the log appearing on the console is as below:
"VERBOSE: BL31: cortex_a53: CPU workaround for erratum 819472was not applied".
We checked ZynqMP code and found that the ZynqMP cpu revision was higher than the cpu revision intended in the erratum and hence it was not applicable and not applied.
The message seems inappropriate to us as from log message it is not clear why it wasn't applied.
Our suggestion is that in the log message instead of "not applied" it should be mentioned as "not applicable" as indicated below to reflect the reason properly.
"VERBOSE: BL31: cortex_a53: CPU workaround for erratum 819472 was not applicable".
Regards,
Maheedhar.
Hey all,
i tried to setup a fip.bin and add 3 images (bl31, bl32 and bl33).
./fiptool --verbose create --soc-fw bl31.bin --nt-fw bl33.bin --tos-fw bl32.bin fip.bin
When i check the generated fip.bin with fiptool info it shows me all my three images in the fip.bin
EL3 Runtime Firmware BL31: offset=0xB0, size=0x13644, cmdline="--soc-fw"
Secure Payload BL32 (Trusted OS): offset=0x136F4, size=0x18D864, cmdline="--tos-fw"
Non-Trusted Firmware BL33: offset=0x1A0F58, size=0x9692E, cmdline="--nt-fw"
But during bootup the BL2 finds only the image id =3 and image id=5 which is BL32 and BL33. Why he is not finding the bl32?
Thanks for youre short help.
Regards
Torsten
Hi, This Thursday Jul 11th Kathleen Capella from Arm's TF-A team will
present: **Using the SMC Fuzzing Module in TF-A** This presentation will
show how you might get started with fuzz testing using the SMC fuzzing
module in TF-A. I will demonstrate the basic fuzzer features, how to add
SMC calls/test cases and how to make use of the module's integration with
tf-a-tests and the TF-A CI. Regards, Olivier.
TF-A Tech Forum
Thursday Jul 11, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
Hi, On Thursday Jul 18th 2024 Rohit Mathew from Arm's Infra solutions team
will present: ** NUMA-Aware PER-CPU Framework: Enhancing Latency and
Storage Efficiency** With the increasing prevalence of multi-chip
platforms, it is crucial for software written for Trusted Firmware-A to be
NUMA-aware. The PER-CPU framework addresses this need by distributing the
allocation of per-CPU objects across different NUMA nodes. This approach
reduces NUMA latency and balances the allocation load, leading to improved
performance and efficiency. Regards, Olivier.
NUMA-Aware PER-CPU Framework: Enhancing Latency and Storage Efficiency
Thursday Jul 18, 2024 ⋅ 5pm – 5:50pm
Central European Time - Paris
Location
zoom, see dial-in information below
https://www.google.com/maps/search/zoom,+see+dial-in+information+below?hl=en
NUMA-Aware PER-CPU Framework: Enhancing Latency and Storage EfficiencyWith
the increasing prevalence of multi-chip platforms, it is crucial for
software written for Trusted Firmware-A to be NUMA-aware. The PER-CPU
framework addresses this need by distributing the allocation of per-CPU
objects across different NUMA nodes. This approach reduces NUMA latency and
balances the allocation load, leading to improved performance and
efficiency.Dial In Information:Trusted Firmware is inviting you to a
scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/j/9159704974?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09Meeting
ID: 915 970 4974Passcode: Mj6NdM---One tap mobile+13462487799,,9159704974#
US (Houston)+16694449171,,9159704974# US---Dial by your location• +1 346
248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)•
+1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 646
931 3860 US• +1 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305
224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 360 209
5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646
558 8656 US (New York)• 833 548 0276 US Toll-free• 833 548 0282 US
Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928
4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US
Toll-freeMeeting ID: 915 970 4974Find your local number:
https://linaro-org.zoom.us/u/aZXJZYXK
Hi All,
I am trying to compile the latest ATF on Raspberry Pi 5 but it fails.
This is the same for all the other Arm64 architecture I have.
Earlier versions of ATF were able to compile on-board with native gcc.
Well with CROSS_COMPILE it works fine on x86_64 machine.
alarm@raspberrypi:~/Downloads/trusted-firmware-a$ make PLAT=rpi5 DEBUG=1
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The configured AArch64 C compiler could
not be identified and may not be supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The default AArch64 C compiler is:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The following tools are supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang`
make_helpers/toolchain.mk:344: - LLVM Clang (`clang`)
make_helpers/toolchain.mk:344: - GNU GCC (`gcc`)
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The build system will treat this C
compiler as GNU GCC (`gcc`).
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The configured AArch64 C preprocessor
could not be identified and may not be supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The default AArch64 C preprocessor is:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The following tools are supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang`
make_helpers/toolchain.mk:344: - LLVM Clang (`clang`)
make_helpers/toolchain.mk:344: - GNU GCC (`gcc`)
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The build system will treat this C
preprocessor as GNU GCC (`gcc`).
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The configured AArch64 assembler could
not be identified and may not be supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The default AArch64 assembler is:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The following tools are supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang`
make_helpers/toolchain.mk:344: - LLVM Clang (`clang`)
make_helpers/toolchain.mk:344: - GNU GCC (`gcc`)
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The build system will treat this
assembler as GNU GCC (`gcc`).
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The configured AArch64 linker could not
be identified and may not be supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The default AArch64 linker is:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The following tools are supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armclang`
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armlink`
make_helpers/toolchain.mk:344: - LLVM Clang (`clang`)
make_helpers/toolchain.mk:344: - LLVM LLD (`lld`)
make_helpers/toolchain.mk:344: - GNU GCC (`gcc`)
make_helpers/toolchain.mk:344: - GNU LD (`ld.bfd`)
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The build system will treat this linker
as GNU GCC (`gcc`).
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The configured AArch64 object copier
could not be identified and may not be supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-objcopy
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The default AArch64 object copier is:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-objcopy
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The following tools are supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `fromelf`
make_helpers/toolchain.mk:344: - LLVM `llvm-objcopy`
make_helpers/toolchain.mk:344: - GNU `objcopy`
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The build system will treat this object
copier as GNU `objcopy`.
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The configured AArch64 object dumper
could not be identified and may not be supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-objdump
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The default AArch64 object dumper is:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-objdump
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The following tools are supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `fromelf`
make_helpers/toolchain.mk:344: - LLVM `llvm-objdump`
make_helpers/toolchain.mk:344: - GNU `objdump`
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The build system will treat this object
dumper as GNU `objdump`.
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The configured AArch64 archiver could
not be identified and may not be supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc-ar
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The default AArch64 archiver is:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: aarch64-none-elf-gcc-ar
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The following tools are supported:
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: - Arm® Compiler for Embedded `armar`
make_helpers/toolchain.mk:344: - LLVM `llvm-ar`
make_helpers/toolchain.mk:344: - GNU `ar`
make_helpers/toolchain.mk:344:
make_helpers/toolchain.mk:344: The build system will treat this
archiver as GNU `ar`.
make_helpers/toolchain.mk:344:
/bin/sh: 1: aarch64-none-elf-gcc: not found
/bin/sh: 1: aarch64-none-elf-gcc: not found
CC bl31/bl31_context_mgmt.c
make: aarch64-none-elf-gcc: No such file or directory
make: *** [Makefile:1514:
/home/alarm/Downloads/trusted-firmware-a/build/rpi5/debug/bl31/bl31_context_mgmt.o]
Error 127
alarm@raspberrypi:~/Downloads/trusted-firmware-a$
alarm@raspberrypi:~/Downloads/trusted-firmware-a$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-12
--program-prefix=aarch64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu
--host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)
Thanks
-Anand
Hi Feifan Qian,
Trapping GPF to EL3 is permitted by the architecture, however I don't believe TF-A provides such option.
In general for TF-A's reference software stacks, a GPF is trapped first at EL2 (hence SCR_EL3.GPF=0).
E.g.
In a system implementing RME, the RMM (@ R-EL2) traps a GPF occurring in an R-EL1/0 Realm (or R-EL2 itself).
Similarly, in the secure world, the SPM (@ S-EL2) traps a GPF occurring in a S-EL1/0 secure partition (or S-EL2 itself).
Regards,
Olivier.
________________________________
From: 钱非凡 <qianfeifan(a)iie.ac.cn>
Sent: 01 July 2024 08:52
To: tf-a-owner(a)lists.trustedfirmware.org <tf-a-owner(a)lists.trustedfirmware.org>
Subject: Questions about the Fault Handling of GPFs
Dear experts,
I have been learning the Fault Handling of the Granule Protection
Fault in Arm CCA. Upon studying the Arm Document, I discovered that the
GPF bit in the SCR_EL3 register controls whether the fault handling of
GPFs occurs in EL3 or not. In addition, I noted that
`include/arch/aarch64/arch.h` defines a macro `#define SCR_GPF_BIT
(UL(1) << 48)`, yet I could not find any reference to this macro in the
source code.
I want to know that whether ATF has implemented the fault handling
of GPFs or if this is a feature to be expected in the future. If its
not, how can I implement this. Any guidance or advice you could provide
would be greatly appreciated.
Sincerely,
Feifan Qian
This event has been canceled with a note:
"Hi, Cancelling as no topic planned. Regards, Olivier. "
TF-A Tech Forum
Thursday Jun 27, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been canceled with a note:
"Hi, Cancelling this instance as no topic proposed. Thanks, Olivier. "
TF-A Tech Forum
Thursday Jun 13, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been canceled with a note:
"Hi, Cancelling for this week as no topic proposed. Thanks, Olivier. "
TF-A Tech Forum
Thursday May 30, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi All,
We are pleased to announce the formal release of Trusted Firmware-A version 2.10 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM and TF-A OpenCI Scripts/Jobs 2.10 releases involving the tagging of multiple repositories.
These went live on 22nd November 2023.
Please find references to tags and change logs at the end of this email.
Many thanks to the community for the active engagement in delivering this release!
Notable Features of the Version 2.10 Release are as follows:
TF-A/EL3 Root World
* New Features:
* Firmware handoff library support
* Improvements to BL31 runtime exception handling
* Context management refactoring for RME/4 worlds
* Gelas, Nevis & Travis CPUs support
* V8.9 features enabled (FEAT_ HAFT, RPRFM, LRCPC3, MTE_PERM)
TF-A Boot BL1/BL2
* New Features
* Trusted Boot support for ECDSA (Elliptic Curve Digital Signature Algorithm)
* Migrated to PSA crypto API’s
* Improved the GUID Partition Table (GPT) parser.
* Various security Improvements and threat Model updates for ARM CCA
* Signer id extraction Implementation
Hafnium/SEL2 SPM
* New Features:
* FF-A v1.2: FFA_YIELD with time-out; EL3 SPMDs LSPs communication; memory sharing updates.
* Memory region relative base address field support in SP manifests.
* Interrupt re-configuration hypervisor calls.
* Memory management: S2 PT NS/S IPA split
* SMCCCv1.2+ compliance fixes.
* Feature parity test improvements, EL3 SPMC and Hafnium (S-EL2 SPMC)
TF-RMM/REL2
* New Feature/Support
* Fenimore v1.0 EAC5 aligned implementation.
* TFTF Enhancements for RME testing
* Initial CBMC support
* NS SME support in RMM
* BTI support for RMM
Errata
* Errata implemented (1xCortex-X2/ Matterhorn-ELP, 1xCortex-A710/Matterhorn, 1xNeoverse N2/Perseus, 2xNeoverse V2/Demeter, Makalu ELP/Cortex X3, Klein/Cortex-A510)
* Fix some minor defects with version in a few errata that applies for some follow up revisions of the CPUs. (Neoverse V1, Cortex-X2, Cortex-A710)
TF-A Tests
* Core
* Added errata management firmware interface tests.
* Added firmware handoff tests.
* Introduced RAS KFH support test.
* SPM/FF-A
* Support SMCCCv1.2 extended GP registers set.
* Test SMCCC compliance at the non-secure physical instance.
* Test secure eSPI interrupt handling.
* Test FF-A v1.2 FFA_PARTITION_INFO_GET_REGS interface.
* RMM
* Added FPU/SVE/SME tests
* Added multiple REC single CPU tests.
* Added PAuth support in Realms tests.
* Added PMU tests.
Platform Support
* New platforms added:
* Aspeed AST2700, NXP IMX93, Intel Agilex5, Nuvoton NPCM845x, QTI MDM9607, MSM8909, MSM8939, ST STM32MP2
Release tags across repositories:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.10https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.4.0
Change logs:
https://trustedfirmware-a.readthedocs.io/en/v2.10/change-log.html#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver…https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0
Regards,
Olivier.
Hi ,
We are trying to build the TF-A code using clang compiler .
Instructions are followed as per the conf page https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-…
1. export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf-
2. make CC=<path-to-armclang>/bin/armclang PLAT=<platform> all
in our side , make CC=/tools/installs/arm/safety/armcc/6.6.2/bin/armclang PLAT=zynqmp distclean
3.
with steps 1) and 2) , we observe the value of AS and AR getting set as below:
AS = /tools/installs/arm/safety/armcc/6.6.2/bin/armclang -c -x assembler-with-cpp -target aarch64-arm-none-eabi -march=armv8-a
AR = <path-to-aarch64-gcc>/bin/aarch64-linux-gnu-ar
4.
However in /tools/installs/arm/safety/armcc/6.6.2/bin , clang tool specific AS points to armasm and AR points to armar utility.
5.
From above output in point 4 , we can see that AS and AR does not refer to clang toolchain utilities armasm and armar.
From point 3) , AS still points to armclang utility only instead of armasm , while AR still points to aarch64-linux-gnu-ar instead of armar .
6.
Can we be guided if the above outputs are correct to use wrt TF-A code build using clang compiler ?
And whether any modifications can be done to point AS and AR to clang toolchain specific utilities as mentioned in step 4.
Regards
Amit
Hi,
We do not have active maintainer for Marvell platform.
As per docs/about/maintainers.rst the current maintainer is "Konstantin Porotchkin <kostap(a)marvell.com>".
Is anybody willing to take ownership of the platform, preferably people who have contributed to this platform in past.
Thanks
Manish
Clock and power management in ATF, preemption issue.
I have seen that multiple Vendors are using arm scmi protocol to do clock management in bl31[0][1].
The problem with such implementations is any long running SCMI operations (like PLL locking for example)
will hold the core in EL3 for extended period of time, adding to latency of NS EL1 interrupt handling
as ATF is not preemptible.
This problem can be solved by making ATF preemptible, similar to how OP-TEE does it by
by implementing a remote procedural call after it receives a interrupt.
[2]How Linux does SMC call with YIELD flag enabled.
[3]How OP-TEE handles the timer interrupt
[4]How Linux receives an interrupt which came in EL3->SEL1
As quoted in exception Handling document in ATF docs[5]
"Receive exceptions, but handle part of the exception in EL3, and delegate processing of
the error to dedicated software stack running at lower secure ELs (as above); additionally,
the Normal world may also be required to participate in the handling,
or be notified of such events (for example, as an event).
In this scheme, exception handling potentially and maximally spans all
ELs in both Secure and Normal worlds."
From this we can understand that we can delegate the exception to EL1 if we are already in EL3.
(way to preempt)
We are aware that ARM v8.4-A onwards arch are having a SEL2 level with which we can run a vendor specific firmware
parallel to TEE at SEL1 in a secure partition. But how we do handle clock and power management
for version which doesn't support SEL2?
We don't want to put it in TEE as it will constraint our devices to that
specific TEE.
I am starting to work on a proposal to make ATF preemptible similar to how OP-TEE is doing it.
a)Will the similar approach from OP-TEE if implemented and working be
accepted by ATF upstream?
The SMC call with YIELD option will only be preemtible so will not
affect the normal flow.
b)As quoted in Trusted Firmware-A Document[6] Page 94,
"Yielding calls are reserved exclusively for Trusted OS providers"
"Yielding 0- 1 Reserved for existing Armv7-A calls
Yielding 2-63 Trusted OS Standard Calls"
Can this range be consumed within ATF/bl31 firmware or is it necessary to forward all yielding calls to Trusted OS?
[0]https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/st/…
[1]https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840
[2]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_ab…
[3]https://github.com/OP-TEE/optee_os/blob/fc57019cb35c8c1bad66fc6d814ace5de…
[4]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_ab…
[5]https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/com…
[6]https://trustedfirmware-a.readthedocs.io/_/downloads/en/latest/pdf/
Regards,
Kamlesh
Hi ,
There is a contradiction present in TF-A documentation whether secure interrupts can be handled in EL3 for arm gic v2 case .
1.
Referring https://trustedfirmware-a.readthedocs.io/en/latest/design/interrupt-framewo…
It says secure interrupts can't be handled in EL3 .
Refer statement : "In Arm GICv2, all secure interrupts are assumed to be handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they cannot be handled in EL3."
2.
Referring https://trustedfirmware-a.readthedocs.io/en/latest/components/platform-inte…
It says secure interrupts can be handled in EL3 , When GICV2_G0_FOR_EL3 is 1 .
Refer below statements :
For interrupt type INTR_TYPE_EL3:
When GICV2_G0_FOR_EL3 is 0, it returns false, indicating no support for EL3 interrupts.
When GICV2_G0_FOR_EL3 is 1, it returns true, indicating support for EL3 interrupts.
can this be clarified ?
Regards
Amit
This event has been canceled with a note:
"Hi, Cancelling as no topic proposed this week. Thanks & Regards, Olivier. "
TF-A Tech Forum
Thursday May 16, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding