Hi everyone,
From what I see manifest lists (e.g. tools/tfm_manifest_list.yaml) describe partitions, but "name" field there (which is a description of the partition) uses "Service" word, for example:
"name": "Protected Storage Service",
Shouldn't this be "name": "Protected Storage Partition" ?
Why do TFM uses Service when describing the Partition?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi,
TF-M coding standard<https://tf-m-user-guide.trustedfirmware.org/contributing/coding_guide.html> mandates up to 80 characters per line. This looks a bit too restrictive nowadays with no punch cards or text terminals.
I propose to increase this limit to 120 or 140 characters. Personally like 128.
Are there any thoughts or objections against it?
Thanks,
Anton
Hi all,
Please be noted that the TF-M example Secure Partition has been moved from the tf-m-tools repo to the tf-m-extras<https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/examples/example_…> repo.
It has also been aligned with the latest TF-M. The documentations are improved as well.
It could be a good reference for Secure Partition developer starters.
Best Regards,
Kevin
Hello,
The project documentation will never be ideal and we are continuing improving it.
Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase.
Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful.
Thank you in advance,
Anton
[Thread res-used, title renamed]
Hi all,
This is now happening - fully support non-CMake use of the manifest tool.
Here is the patch:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15756
With this patch, the manifest tool takes build configurations from a config header file instead of replying on the build system.
Please check the details in the patch.
Any comments are welcome.
Best Regards,
Kevin
-----Original Message-----
From: Andrej Butok <andrey.butok(a)nxp.com>
Sent: Thursday, May 12, 2022 2:49 PM
To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: RE: Any usage of environment variables in manifest lists
> If there are strong requirements on supporting the non-cmake usecase
Yes, it is 😉
-----Original Message-----
From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, May 12, 2022 5:46 AM
To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Re: Any usage of environment variables in manifest lists
Well, I think I figured out a way to decouple them.
If there are strong requirements on supporting the non-cmake usecase, I can try to work it out.
Best Regards,
Kevin
-----Original Message-----
From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, May 12, 2022 10:09 AM
To: Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Re: Any usage of environment variables in manifest lists
Yes.
The manifest tool is now fully replying on CMake (it has been, since I introduced the conditional parsing of manifests around half a year ago).
It needs to be aware of the build configurations.
Best Regards,
Kevin
-----Original Message-----
From: Raef Coles <Raef.Coles(a)arm.com>
Sent: Wednesday, May 11, 2022 7:15 PM
To: tf-m(a)lists.trustedfirmware.org; Kevin Peng <Kevin.Peng(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: Re: Any usage of environment variables in manifest lists
Hey Kevin
Does this mean that cmake will be required to generate the headers/etc from the manifests?
I believe in the past we deliberately supported the non-cmake usecase, as some people were building TF-M in alternate ways.
Raef
________________________________________
From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 11 May 2022 09:24
To: tf-m(a)lists.trustedfirmware.org
Cc: nd
Subject: [TF-M] Any usage of environment variables in manifest lists
Hi,
Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists?
I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>.
In the patch the support of environment variables in manifest lists is removed<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>.
Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> surrounded with "@") with their values.
While configure_file does not recognize environment variables.
If you do have environment variables in manifest list, there is an alternative:
Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs.
Best Regards,
Kevin
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
Hi,
What was the intended usage of psa_reset_key_attribute(*attributes) which requires a PSA call from non-secure side to reset the client attributes? I am curious because the attributes to be reset comes from the non-secure memory, not directly associated with ITS/PS.
The current IPC setup performs a PSA call to tfm_crypto_rest_key_attributes()(https://git.trustedfirmware.org/TF-M/trust…
This function creates a copy of client key attribute in a secure key attribute structure. The secure key attribute is reset (set to 0) and then copied back to the client key attribute before returning to non-secure code. At first glance, this seems like a roundabout way to zeorise client side attributes.
Regards,
Archanaa
Hi All,
FYI.
Open CI will be down from 2022 07-22 18:00 UTC to 2022-07-22 22:00 UTC for Jenkins upgrade.
Please let us know if there is any problem.
Thanks
Xinyu
-----Original Message-----
From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org>
Sent: Thursday, July 21, 2022 10:14 PM
To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org
Subject: [Tf-openci-triage] [Maintenance] - ci.staging.trustedfirmware.org down time 2022-07-22
Hello All,
The server will be offline to start a maintenance window on 2022-07-22 at
20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-22 18:00 UTC to stop accepting new jobs and allow executing tasks to complete.
This downtime is required to add a plugin to Jenkins to support new functionality required for a service being developed. The version of Jenkins and the plugins currently being run will not be changing.
Emails will be sent prior to and following the upgrade to provide status reports.
Start: 2022 07-22 18:00 UTC
End: 2022-07-22 22:00 UTC
Regards,
--
Kelley Spoon <kelley.spoon(a)linaro.org>
--
Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org