Hi Ravi,
You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c:
/* Populate entry point information for BL33 */
SET_PARAM_HEAD(&bl33_image_ep_info,
PARAM_EP,
VERSION_1,
0);
/*
* Tell BL31 where the non-trusted software image
* is located and the entry state information
*/
bl33_image_ep_info.pc = plat_get_ns_image_entrypoint();
bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry();
SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE);
Regards.
Alexei
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 21 October 2020 10:57
To: Manish Pandey2 <Manish.Pandey2(a)arm.com>
Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: Re: [TF-A] BL31 as bootloader
Hi Manish,
The test image should not have any dependency on device tree (dtb?)
for console init.
I used the NXP provided imx8qm-mek-ca53.dtb file which should match
the MEK board.
I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below)
as well but no luck.
I don't believe PC is getting set to the 0x80020000 entry point.
The test image has validated with u-boot using these tftpboot settings:
setenv ipaddr x.x.x.x
setenv serverip x.x.x.x
tftpboot 0xf0000000 App.bin
bootm 0xf0000000
I don't see any console output on the screen running it with bl31.bin as below.
Is there any debug I can add somewhere to help troubleshoot?
Can you please provide me instructions on where to patch this missing code :
"SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);"
I can try it to see if any change in behavior.
Thanks in advance.
Regards
Ravi
On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com> wrote:
>
> Hi Ravi,
>
> Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value.
> Also, does your "test image" depends on device tree for console initialization?
>
> One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization
> SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);
>
> thanks
> Manish
>
> ________________________________
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org>
> Sent: 21 October 2020 00:10
> To: Ravi Kohli <rkohli2000(a)gmail.com>
> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
> Subject: Re: [TF-A] BL31 as bootloader
>
> Hi Alexei,
>
> I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit.
>
> make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31
>
> I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK:
>
> flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb
> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin
>
> Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53).
> I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000.
>
> NOTICE: Memreg 3 0x38000000 -- 0x3bffffff
> NOTICE: Memreg 4 0x60000000 -- 0x6fffffff
> NOTICE: Memreg 5 0x70000000 -- 0x7fffffff
> NOTICE: Memreg 6 0x80000000 -- 0xffffffff
> NOTICE: Memreg 7 0x400000000 -- 0x43fffffff
> NOTICE: Memreg 8 0x880000000 -- 0x97fffffff
> NOTICE: Non-secure Partitioning Succeeded
> NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty
> NOTICE: BL31: Built : 17:33:32, Oct 20 2020
> INFO: bl31_platform_setup is called
> INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3
> INFO: BL31: Initializing runtime services
> INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
> INFO: BL31: Preparing for EL3 exit to normal world
> INFO: Entry point address = 0x80020000
> INFO: SPSR = 0x3c9
> INFO: BL31: DEBUG: image_type is: normal
>
>
> Can anyone please suggest what could be the issue here that I don't see the test image console output ?
> Note, the same test image works fine using u-boot.
>
> Regards
> Ravi
>
>
> On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi Alexei,
>
> Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet.
> I will try it out and confirm. And, thanks for this suggestion.
>
> Regards
> Ravi
>
> On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com> wrote:
>
> Hi Ravi,
>
> Have you tried to use RESET_TO_BL31 build option for your platform?
>
> Regards.
> Alexei
> ________________________________
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org>
> Sent: 07 October 2020 17:01
> To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
> Subject: [TF-A] BL31 as bootloader
>
> Hi,
> I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated.
>
> I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot.
> I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can
> specify this container image with both bl31.bin and a separate custom app at a give flash address.
> This is without any security requirements or dependencies.
>
> Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch
> a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point
> 0x80020000 address ?
>
> Thanks in advance.
> Ravi
>
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
>
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Ravi,
Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value.
Also, does your "test image" depends on device tree for console initialization?
One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization
SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);
thanks
Manish
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 21 October 2020 00:10
To: Ravi Kohli <rkohli2000(a)gmail.com>
Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: Re: [TF-A] BL31 as bootloader
Hi Alexei,
I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit.
make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31
I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK:
flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb
./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin
Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53).
I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000.
NOTICE: Memreg 3 0x38000000 -- 0x3bffffff
NOTICE: Memreg 4 0x60000000 -- 0x6fffffff
NOTICE: Memreg 5 0x70000000 -- 0x7fffffff
NOTICE: Memreg 6 0x80000000 -- 0xffffffff
NOTICE: Memreg 7 0x400000000 -- 0x43fffffff
NOTICE: Memreg 8 0x880000000 -- 0x97fffffff
NOTICE: Non-secure Partitioning Succeeded
NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty
NOTICE: BL31: Built : 17:33:32, Oct 20 2020
INFO: bl31_platform_setup is called
INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x80020000
INFO: SPSR = 0x3c9
INFO: BL31: DEBUG: image_type is: normal
Can anyone please suggest what could be the issue here that I don't see the test image console output ?
Note, the same test image works fine using u-boot.
Regards
Ravi
On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote:
Hi Alexei,
Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet.
I will try it out and confirm. And, thanks for this suggestion.
Regards
Ravi
On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote:
Hi Ravi,
Have you tried to use RESET_TO_BL31 build option for your platform?
Regards.
Alexei
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>
Sent: 07 October 2020 17:01
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>>
Subject: [TF-A] BL31 as bootloader
Hi,
I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated.
I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot.
I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can
specify this container image with both bl31.bin and a separate custom app at a give flash address.
This is without any security requirements or dependencies.
Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch
a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point
0x80020000 address ?
Thanks in advance.
Ravi
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Alexei,
I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit.
make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31
I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK:
flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb
./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin
Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53).
I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000.
NOTICE: Memreg 3 0x38000000 -- 0x3bffffff
NOTICE: Memreg 4 0x60000000 -- 0x6fffffff
NOTICE: Memreg 5 0x70000000 -- 0x7fffffff
NOTICE: Memreg 6 0x80000000 -- 0xffffffff
NOTICE: Memreg 7 0x400000000 -- 0x43fffffff
NOTICE: Memreg 8 0x880000000 -- 0x97fffffff
NOTICE: Non-secure Partitioning Succeeded
NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty
NOTICE: BL31: Built : 17:33:32, Oct 20 2020
INFO: bl31_platform_setup is called
INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x80020000
INFO: SPSR = 0x3c9
INFO: BL31: DEBUG: image_type is: normal
Can anyone please suggest what could be the issue here that I don't see the test image console output ?
Note, the same test image works fine using u-boot.
Regards
Ravi
> On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi Alexei,
>
> Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet.
> I will try it out and confirm. And, thanks for this suggestion.
>
> Regards
> Ravi
>
>> On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote:
>>
>> Hi Ravi,
>>
>> Have you tried to use RESET_TO_BL31 build option for your platform?
>>
>> Regards.
>> Alexei
>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>>
>> Sent: 07 October 2020 17:01
>> 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>>
>> Subject: [TF-A] BL31 as bootloader
>>
>> Hi,
>> I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated.
>>
>> I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot.
>> I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can
>> specify this container image with both bl31.bin and a separate custom app at a give flash address.
>> This is without any security requirements or dependencies.
>>
>> Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch
>> a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point
>> 0x80020000 address ?
>>
>> Thanks in advance.
>> Ravi
>>
>>
>>
>> --
>> 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://lists.trustedfirmware.org/mailman/listinfo/tf-a>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi All,
The next TF-A Tech Forum is scheduled for Thu 22nd October 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
Agenda:
* Encrypted FIP Support
* Presented by Sumit Garg
* Summary
* Overview of FIP encryption.
* Common challenges with firmware encryption implementation and how we addressed those in TF-A.
* FIP encryption implementation details.
* Follow on Measured Boot Support in TF-A discussion from last meeting (if required)
* Optional TF-A Mailing List Topic Discussions
If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled.
Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list.
Thanks
Joanna
Hi Joanna,
Can you please share the presentation of the session on Measured Boot. It
is not currently available on the webpage -
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
Regards,
Ruchika
On Tue, 6 Oct 2020 at 22:58, Joanna Farley via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> The next TF-A Tech Forum is scheduled for Thu 8th October 2020 16:00 –
> 17:00 (BST). A reoccurring meeting invite has been sent out to the
> subscribers of this TF-A mailing list. If you don’t have this please let me
> know.
>
>
>
> Agenda:
>
>
>
> - Measured Boot Support in TF-A
> - Presented by Alexei Fedorov and Javier Almansa Sobrino
> - Update on the support for Measured Boot in TF-A along with an
> overview of test cases for integration with a TPM service
> - Optional TF-A Mailing List Topic Discussions
>
>
>
> If TF-A contributors have anything they wish to present at any future TF-A
> tech forum please contact me to have that scheduled.
>
>
>
> Previous sessions, both recording and presentation material can be found
> on the trustedfirmware.org TF-A Technical meeting webpage:
> https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
>
>
>
> A scheduling tracking page is also available to help track sessions
> suggested and being prepared:
> https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final
> decisions on what will be presented will be shared a few days before the
> next meeting and shared on the TF-A mailing list.
>
>
>
> Thanks
>
>
>
> Joanna
>
>
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
Hi All,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days.
Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community
* Constant-time code
* How to be an effective Mbed TLS reviewer
* Processes - how does work get scheduled?
* Roadmap, Mbed TLS3.0
* PSA Crypto APIs
* How Do I contribute my first review.
Thanks,
Shebu
(TrustedFirmware.org Co-Chair,
Mbed TLS Technology Manager)
* https://lists.trustedfirmware.org/mailman/listinfo/mbed-tlshttps://lists.trustedfirmware.org/mailman/listinfo/psa-crypto
Hi Biju, Andre,
> sctlr_el3 = 0x0000000030c5183a
The MMU is still disabled since we're so early in BL31, so nothing preventing us
from making an actual access to physical address 0x0.
As Andre already noted:
> x30 = 0x0000000000000000
> elr_el3 = 0x0000000000000000
> far_el3 = 0x0000000000000000
It looks like we do have an errant null pointer dereference here.
If I had to guess, the I-side successfully fetches a 32-bit word from physical
address 0x0, but then fails to decode that bit pattern as a valid opcode. This
is reported as "unknown reason", like you're seeing:
<quote Arm ARM DDI 0487E.a pp D13-2963>
This EC code is used for all exceptions that are not covered by any other EC
value. This includes exceptions that are generated in the following situations:
- ...
- Instruction encodings that are unallocated.
- ...
</quote>
Hope that helps,
Ash.
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ash Wilding via TF-A <TF-A(a)lists.trustedfirmware.org>
Date: Sunday, 11 October 2020 at 18:53
<...>
It looks like we do have an errant null pointer dereference here.
<...>
Just to clarify, when I say "null pointer dereference":
- you may be trampling over your stack, causing you to pop 0x0 into LR and
return there;
- you may be trampling over your stack, causing you to pop 0x0 into a GPR that
is then BLR'd to;
- you may be trampling over some other region of memory containing a function
pointer, causing you to load 0x0 into a GPR that is then BLR'd to;
- etc.
Cheers,
Ash.
Hello all,
Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB.
The modules involved on the interaction with the fTPM (for this particular example) are:
* optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world).
* tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case.
In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM.
I would also like to highlight the following points:
A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS.
B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually.
Please, let me know in case you have any more questions.
Best regards,
Javier