Hi Reed,
Thanks for the input.
We name the dual-core/multi-core feature control option flag as `TFM_MULTI_CORE_TOPOLOGY` for a general model.
But as Chris said, it would require additional work to design and support more complicated scenarios. Thus for the current particular patches for dual-core platform, I'd like to specify the topic a little as "dualcpu".
Best regards,
Hu Ziji
-----Original Message-----
From: Reed Hinkel <Reed.Hinkel(a)arm.com>
Sent: Sunday, November 10, 2019 5:45 AM
To: Christopher Brand <chris.brand(a)cypress.com>; Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology China) <David.Hu(a)arm.com>
Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"
Makes sense!
All the best!
Reed
On 11/8/19, 11:05 AM, "Christopher Brand" <chris.brand(a)cypress.com> wrote:
I think that's actually an argument in favour of "dualcpu" for what we have now, because I suspect there would be significant work needed to support an additional core.
Chris
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reed
> Hinkel via TF-M
> Sent: Friday, November 8, 2019 6:53 AM
> To: Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology
> China) <David.Hu(a)arm.com>
> Cc: tf-m(a)lists.trustedfirmware.org
> Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to
> "dualcpu"
>
> Just food for thought, but in the future some devices may have more than
> two cores, but still with one core dedicated to RoT functions.
>
> -Reed
>
> On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-
> bounces(a)lists.trustedfirmware.org on behalf of tf-
> m(a)lists.trustedfirmware.org> wrote:
>
> OK. We use "dual", so it's better ;)
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David
> Hu (Arm Technology China) via TF-M
> Sent: Friday, November 8, 2019 9:16 AM
> To: tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"
>
> Hi all,
>
> As you know, the current topic for dual-core patches is “twincpu”.
> In my very own opinion, keyword “twin” implies that the two cores are the
> same in the system. However, the two cores can be in different archs or
> even heterogeneous in a dual-core system.
>
> Thus I’d like to propose to change the topic name to “dualcpu” to
>
> * Cover larger scope of dual-core topology/system.
> * Align with the description in dual PE-based isolation section in TBSA-M
> spec
>
> Could you please let me know if you have any concern about that change?
> Any feedback or suggestion is welcome. 😊
> Thank you.
>
> Best regards,
> Hu Ziji
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t
> rustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-
> m&data=02%7C01%7Candrey.butok%40nxp.com%7C9dc8588da6e2436e
> 754508d76423ef30%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 7087977806556698&sdata=it6Hfh2Vk9A5FUFudmNn206LYO9Wb8lOattG
> %2FWsm2%2Bo%3D&reserved=0
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
I think the PSA FF current definition of the "irqs" "source" attribute is needlessly opaque, confusing, and limiting.
Why can't there simply be two attributes "irq_number" and "irq_name".
"irq_number" corresponds to the CMSIS XYZ_IRQn convention in terms of its interpretation. It can be either a literal number or a manifest constant.
"irq_name" is the symbolic name of the ISR as it appears in the user's vector table.
That way there is no confusion regarding how they will be used.
Alan
Hi Reed;
Is there a minimum spec in terms of MCU such as M0 or M0+ or anything else for the RoT functionality MCU?
Jay Fallah | Chief Technology Officer | NXM
888-416-6555 | mobile 647-927-9990 | ca.linkedin.com/in/jayfallah
CONFIDENTIALITY NOTICE: This email message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> On Nov 8, 2019, at 9:53 AM, Reed Hinkel via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions.
>
> -Reed
>
> On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote:
>
> OK. We use "dual", so it's better ;)
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M
> Sent: Friday, November 8, 2019 9:16 AM
> To: tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"
>
> Hi all,
>
> As you know, the current topic for dual-core patches is “twincpu”.
> In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system.
>
> Thus I’d like to propose to change the topic name to “dualcpu” to
>
> * Cover larger scope of dual-core topology/system.
> * Align with the description in dual PE-based isolation section in TBSA-M spec
>
> Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊
> Thank you.
>
> Best regards,
> Hu Ziji
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions.
-Reed
On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote:
OK. We use "dual", so it's better ;)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M
Sent: Friday, November 8, 2019 9:16 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"
Hi all,
As you know, the current topic for dual-core patches is “twincpu”.
In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system.
Thus I’d like to propose to change the topic name to “dualcpu” to
* Cover larger scope of dual-core topology/system.
* Align with the description in dual PE-based isolation section in TBSA-M spec
Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊
Thank you.
Best regards,
Hu Ziji
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
OK. We use "dual", so it's better ;)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M
Sent: Friday, November 8, 2019 9:16 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"
Hi all,
As you know, the current topic for dual-core patches is “twincpu”.
In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system.
Thus I’d like to propose to change the topic name to “dualcpu” to
* Cover larger scope of dual-core topology/system.
* Align with the description in dual PE-based isolation section in TBSA-M spec
Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊
Thank you.
Best regards,
Hu Ziji
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
Hi all,
As you know, the current topic for dual-core patches is “twincpu”.
In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system.
Thus I’d like to propose to change the topic name to “dualcpu” to
* Cover larger scope of dual-core topology/system.
* Align with the description in dual PE-based isolation section in TBSA-M spec
Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊
Thank you.
Best regards,
Hu Ziji
Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted.
---
With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line:
python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir>
And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line:
cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../
The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage.
Alan
-----Original Message-----
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M
Sent: Monday, November 4, 2019 4:36 PM
To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org
Subject: [EXTERNAL] Re: [TF-M] out of tree build
Abishek,
Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory.
A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files.
I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible.
Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise.
Alan
-----Original Message-----
From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com]
Sent: Monday, November 4, 2019 3:08 PM
To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org
Subject: [EXTERNAL] RE: out of tree build
Hi Alan,
Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review?
Thanks,
Abhishek
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: 01 November 2019 16:29
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] out of tree build
Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them.
Alan
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line:
python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir>
And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line:
cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../
The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage.
Alan
-----Original Message-----
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M
Sent: Monday, November 4, 2019 4:36 PM
To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org
Subject: [EXTERNAL] Re: [TF-M] out of tree build
Abishek,
Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory.
A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files.
I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible.
Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise.
Alan
-----Original Message-----
From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com]
Sent: Monday, November 4, 2019 3:08 PM
To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org
Subject: [EXTERNAL] RE: out of tree build
Hi Alan,
Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review?
Thanks,
Abhishek
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: 01 November 2019 16:29
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] out of tree build
Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them.
Alan
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi all,
The ITS and SST partitions in TF-M share a common implementation for the backend FS and flash layers, but currently this code is duplicated between the two partitions, increasing overall code size. To fix this, it was previously proposed to keep the common code in only the ITS partition, with SST making service requests to ITS to complete FS and flash operations.
The patches to implement this are now available for review here:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2425https://review.trustedfirmware.org/c/trusted-firmware-m/+/2426
The first patch refactors the FS and flash code in ITS to support multiple contexts, with multiple flash devices. The second refactors SST to make requests to ITS instead of calling the FS code directly, and modifies ITS to handle requests that originate from SST with SST's FS context and flash device. This is a fairly significant change to the architecture of the two services, so feedback would be particularly appreciated.
Kind regards,
Jamie
Hi Alan,
Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review?
Thanks,
Abhishek
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: 01 November 2019 16:29
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] out of tree build
Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them.
Alan
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m