Hi,
Back in March, I wrote the dual-core design document at
https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/
It was discussed on the mailing list in a thread that starts at
https://lists.trustedfirmware.org/pipermail/tf-m/2019-March/000088.html
Since then, TF-M has defined a process for design reviews, and it would be
nice to get this design document into the docs/design directory, particularly
as the implementation of the design is already in the codebase.
Given that there has already been discussion on the mailing list, I've gone
ahead and created a review in Gerrit:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2384
I also added all the people who contributed to that thread as reviewers.
Please feel free to add yourself as a reviewer.
Also, comments on whether this is the right process to follow for design
documentation in this transitional state would be useful.
Thanks,
Chris
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi Alan,
Andrej is right about PSA certification, for that you don't need to pass the regression test suite.
However for submitting a change to the upstream master branch on https://www.trustedfirmware.org/ it is a requirement to pass those tests.
The peripherals defined in the tfm_peripherals_def.h files are the peripherals that are mentioned in the 'mmio_regions' node in the partition manifest yaml files. It is a requirement that a macro is defined with this name that is substituted to a pointer type value. For more details see platform\readme.rst, chapter 'platformext/target/tfm_peripherals_def.h'.
The type 'tfm_spm_partition_platform_data_t' is defined by the platform implementation, so TF-M core has no knowledge about the content of an object of type 'tfm_spm_partition_platform_data_t', and doesn't use it. The pointer is only considered by it as a token, that is passed to the platform HAL functions.
This means that if the platform needs to do nothing related to the peripherals in the HAL functions either because
- no isolation is needed to be configured for that peripheral
- the peripheral doesn't exist, and the functionality is emulated (1)
it is OK to define the value of the macro to be NULL (Just as it is done in platform/ext/target/musca_a/tfm_peripherals_def.h).
The TFM_PERIPHERAL_FPGA_IO is used by the core test, to access button state and to blink leds. For the Musca-A platform these functionalities are emulated in the file platform/ext/target/musca_a/plat_test.c
TFM_PERIPHERAL_TIMER0 is used by the IRQ tests. The upstreamed platforms all support some kind of timer, so there is a real implementation for all the platforms. (platform/ext/target/musca_a/plat_test.c)
If it is not possible to create working implementations for the interfaces in platform/include/tfm_plat_test.h, then it is possible to disable the peripheral access and irq tests, by adding the following lines to the platform cmake file:
set(TFM_ENABLE_PERIPH_ACCESS_TEST Off)
set(TFM_ENABLE_IRQ_TEST Off)
Please note, that even in this case TFM_PERIPHERAL_FPGA_IO and TFM_PERIPHERAL_TIMER0 are still need to be defined (NULL is ok), and the plat_test interface functions also need to have at least an empty implementation.
Regards,
Mate
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 24 October 2019 08:39
To: DeMars, Alan <ademars(a)ti.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] IPC Regressions reference platform specific resources
Hi Alan
> I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests.
Regression tests are only to check if your TFM port is correct (not for certification).
You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required.
Best regards,
Andrej Butok
NXP Semiconductors
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: Wednesday, October 23, 2019 5:20 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] IPC Regressions reference platform specific resources
I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO).
I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict?
Alan
--
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
Hi,
The process of contributing to TF-M patch is updated now: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1007/
We can get an updated version after reviewing.
Regards,
Summer
On 10/23/19, 7:55 PM, "Shebu Varghese Kuriakose via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote:
Hi Alan,
'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task.
Looks like contributing.rst can do with a few updates/corrections.
Regards,
Shebu
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: Monday, October 21, 2019 7:37 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] contributing to the TF-M project
I am trying to follow the instructions provided here:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi…
But I'm stumbling on the very first step:
- Create an issue in http://issues.trustedfirmware.org
to keep others informed about your ongoing work.
When I log into the sight, I have not been able to find how to create an issue.
I see links for "Create Task" and "Create Project" but nothing for "Create Issue".
What am I doing wrong?
Alan
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Alan
> I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests.
Regression tests are only to check if your TFM port is correct (not for certification).
You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required.
Best regards,
Andrej Butok
NXP Semiconductors
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: Wednesday, October 23, 2019 5:20 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] IPC Regressions reference platform specific resources
I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO).
I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict?
Alan
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO).
I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict?
Alan
Hi Alan,
'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task.
Looks like contributing.rst can do with a few updates/corrections.
Regards,
Shebu
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: Monday, October 21, 2019 7:37 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] contributing to the TF-M project
I am trying to follow the instructions provided here:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi…
But I'm stumbling on the very first step:
- Create an issue in http://issues.trustedfirmware.org
to keep others informed about your ongoing work.
When I log into the sight, I have not been able to find how to create an issue.
I see links for "Create Task" and "Create Project" but nothing for "Create Issue".
What am I doing wrong?
Alan
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Alan,
Thanks for reporting this issue. Yes, the "Create Task" in https://developer.trustedfirmware.org/maniphest is the place you can use. Just create a task, add the tag "Trusted Firmware M" and others you can set as you want or keep them as default. And please add this task link under your commit as comments, please add the test env and result as well if you have.
This part needs to be updated, and we will push a patch to fix it ASAP.
Regards,
Summer
On 10/22/19, 2:37 AM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote:
I am trying to follow the instructions provided here:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi…
But I'm stumbling on the very first step:
- Create an issue in http://issues.trustedfirmware.org
to keep others informed about your ongoing work.
When I log into the sight, I have not been able to find how to create an issue.
I see links for "Create Task" and "Create Project" but nothing for "Create Issue".
What am I doing wrong?
Alan
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
I am trying to follow the instructions provided here:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi…
But I'm stumbling on the very first step:
- Create an issue in http://issues.trustedfirmware.org
to keep others informed about your ongoing work.
When I log into the sight, I have not been able to find how to create an issue.
I see links for "Create Task" and "Create Project" but nothing for "Create Issue".
What am I doing wrong?
Alan
Hi,
We need to keep an eye on some factors which the current prototype ignores. Some that come to my mind:
1. which component shall be the owner of sw dependency info? (Documentation, cmake, something else?).
2. how does the solution scale? (i.e. be able to handle platform specific dependencies).
3. how we handle build configuration specific dependencies? (i.e. if I don't build a service then some dependency is not needed).
4. As Minos mentioned some environment verification is already done by CMake. Is it worth to extract all dependency info (tooling + SW) into a dedicated place?
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M
Sent: 21 October 2019 16:47
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format
Hi,
Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) .
So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture.
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 21 October 2019 15:25
To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format
This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead.
- k
> On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI).
>
> The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system.
>
> If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following
>
>
> * Use a reStructuredText grid table to define dependencies
> * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script
>
> I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal.
>
> This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst).
>
> Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa.
>
> Thanks,
> Dev
> 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
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
