Hi all,
Would like to merge the below patch *tomorrow* if there were no objections.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Friday, February 5, 2021 10:37 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M git repo normalization
This patch was generated by git command automatically:
$ git add --renormalize .
It does change any contents of the files, except the line-endings in the repository.
Your existing local working tree should not be affected when you pick up it or later when it's merged.
The only file maintained manually is the .gitattributes
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M
Sent: Friday, February 5, 2021 9:53 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M git repo normalization
Hi all,
Following the git normalization topic of the tech forum yesterday, I checked TF-M.
It has not been enabled the git normalization feature.
I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen.
Please check out or rebase your work upon this patch to see any issues.
Your existing working tree should not be affected regarding the line-endings.
What is the normalization?
To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other.
Reference: https://git-scm.com/docs/gitattributes
Best Regards,
Kevin
Hi,
I have created a couple of patches to change the way to assemble the partitions, and start with the platform data:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8288
The basic idea is we would avoid using pointer to link data between partitions, as mentioned in one of the past tech forum topics: https://www.trustedfirmware.org/docs/TF-M_partition_storage_arrangement.pdf
Please help to review this patch, especially the platform owners, as this change modifies almost all platform sources.
Also, I just use a direct 'find and replace' so some of the copyright years are not updated. Would update them in subsequent small patches.
Thanks.
/Ken
Hi all,
The design document is merged as planned.
Thanks a lot for your review! Any further comment or suggestion is always comment. 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Monday, February 1, 2021 4:01 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Ask for final review on physical attack mitigation design
Hi all,
I’d like to merge the design document of physical attack mitigation in TF-M this week if no further comment.
May I ask you to take another look at the following document patch?
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476
Best regards,
Hu Ziji
This patch was generated by git command automatically:
$ git add --renormalize .
It does change any contents of the files, except the line-endings in the repository.
Your existing local working tree should not be affected when you pick up it or later when it's merged.
The only file maintained manually is the .gitattributes
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Friday, February 5, 2021 9:53 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M git repo normalization
Hi all,
Following the git normalization topic of the tech forum yesterday, I checked TF-M.
It has not been enabled the git normalization feature.
I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen.
Please check out or rebase your work upon this patch to see any issues.
Your existing working tree should not be affected regarding the line-endings.
What is the normalization?
To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other.
Reference: https://git-scm.com/docs/gitattributes
Best Regards,
Kevin
Hi all,
Following the git normalization topic of the tech forum yesterday, I checked TF-M.
It has not been enabled the git normalization feature.
I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen.
Please check out or rebase your work upon this patch to see any issues.
Your existing working tree should not be affected regarding the line-endings.
What is the normalization?
To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other.
Reference: https://git-scm.com/docs/gitattributes
Best Regards,
Kevin
Hi,
Looks like we have an empty agenda for tomorrow's forum. Let's use the time for the free discussion on any TF-M topic. Please raise questions / issues / improvements worth to be discussed within the community.
See you,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 28 January 2021 13:29
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - February 4
Hello,
The next Technical Forum is planned on Thursday, Feb 4 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Thomas,
Sorry about that. I have reproduced the issue on AN521 by copying over the lpcxpresso55s69 storage config. I'll investigate a fix on that platform, but will need you to verify it for me afterwards as I don't have that platform.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 03 February 2021 13:30
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] NXP lpcxpresso55s69 appears broken
Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support:
---
PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good
6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit
commit 6a3946aa017fa4da3953a825991f8ce755114637
Author: Jamie Fox <jamie.fox(a)arm.com><mailto:jamie.fox@arm.com>
Date: Mon Dec 7 21:50:31 2020 +0000
Platform: TF-M ITS and PS HAL
...
---
Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M:
I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251
I tried using the current sources, but it seems that there is some issues causing the board to run into a hard fault when built with GNUARM.
Not sure what commit caused the breakage.
Cheers,
Thomas
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Hi Jamie,
I’ll be happy to test here as well if you add me to the change request.
Best regards,
Kevin
On Wed, 3 Feb 2021 at 16:10, Jamie Fox via TF-M <
tf-m(a)lists.trustedfirmware.org> wrote:
> Hi Thomas,
>
>
>
> Sorry about that. I have reproduced the issue on AN521 by copying over the
> lpcxpresso55s69 storage config. I’ll investigate a fix on that platform,
> but will need you to verify it for me afterwards as I don’t have that
> platform.
>
>
>
> Kind regards,
>
> Jamie
>
>
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Thomas
> Törnblom via TF-M
> *Sent:* 03 February 2021 13:30
> *To:* tf-m(a)lists.trustedfirmware.org
> *Subject:* Re: [TF-M] NXP lpcxpresso55s69 appears broken
>
>
>
> Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support:
> ---
> PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good
> 6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit
> commit 6a3946aa017fa4da3953a825991f8ce755114637
> Author: Jamie Fox <jamie.fox(a)arm.com> <jamie.fox(a)arm.com>
> Date: Mon Dec 7 21:50:31 2020 +0000
>
> Platform: TF-M ITS and PS HAL
> ...
> ---
>
> Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M:
>
> I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see
> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251
>
> I tried using the current sources, but it seems that there is some issues
> causing the board to run into a hard fault when built with GNUARM.
>
> Not sure what commit caused the breakage.
>
> Cheers,
> Thomas
>
> --
>
> *Thomas Törnblom*, *Product Engineer*
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com Website: www.iar.com
> Twitter: www.twitter.com/iarsystems
>
>
>
>
>
> --
>
> *Thomas Törnblom*, *Product Engineer*
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com Website: www.iar.com
> Twitter: www.twitter.com/iarsystems
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support:
---
PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good
6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit
commit 6a3946aa017fa4da3953a825991f8ce755114637
Author: Jamie Fox <jamie.fox(a)arm.com>
Date: Mon Dec 7 21:50:31 2020 +0000
Platform: TF-M ITS and PS HAL
...
---
Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M:
> I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69,
> see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251
>
> I tried using the current sources, but it seems that there is some
> issues causing the board to run into a hard fault when built with GNUARM.
>
> Not sure what commit caused the breakage.
>
> Cheers,
> Thomas
>
> --
>
> *Thomas Törnblom*, /Product Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
> Website: www.iar.com <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
>
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251
I tried using the current sources, but it seems that there is some
issues causing the board to run into a hard fault when built with GNUARM.
Not sure what commit caused the breakage.
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi all,
I'd like to merge the design document of physical attack mitigation in TF-M this week if no further comment.
May I ask you to take another look at the following document patch?
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476
Best regards,
Hu Ziji
Oyvind,
Thanks for putting this together. Looks quite useful, and saves some
monotony debugging.
I put together a similar script but as a Python function for GDB:
https://gist.github.com/microbuilder/1677a27e4566a28b36a79f954f1dede6 ...
having this in C, however, means you don't need to have a Python-enabled
version of GDB.
Best regards,
Kevin
On Fri, 29 Jan 2021 at 11:33, Rønningstad, Øyvind via TF-M <
tf-m(a)lists.trustedfirmware.org> wrote:
> Hi everyone
>
> I wanted to make it easier to debug HardFaults/BusFaults/SecureFaults in
> TFM, since I’ve gotten quite a few of them while adding the nrf platforms.
>
> I have created a proposal in
> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7891 and
> would like to get some comments on the general idea.
>
> The proposal gathers a number of different values, especially the ones
> that are harder to retrieve in a debugger, like the fault status registers
> in SCB.
>
> The values are placed in memory so they can be inspected in a debugger,
> and if built with -DTFM_SPM_LOG_LEVEL=TFM_SPM_LOG_LEVEL_DEBUG they are also
> printed.
>
> Here is an example of the printout:
>
> FATAL ERROR: HardFault
>
> Here is some context for the exception:
>
> EXC_RETURN (LR): 0xFFFFFFBD
>
> Exception came from non-secure FW in thread mode.
>
> MSP(_S): 0x200007F8
>
> PSP(_S): 0x20000F28
>
> Exception frame at: 0x200176D8
>
> R0: 0x0000003E
>
> R1: 0x00000001
>
> R2: 0x00000001
>
> R3: 0xFFFFFFFF
>
> R12: 0x00000000
>
> LR: 0x00050623
>
> PC: 0x00050626
>
> CFSR: 0x00000000
>
> BFAR: Not Valid
>
> MMFAR: Not Valid
>
> HFSR: 0x40000000
>
> SFSR: 0x00000000
>
> SFAR: Not Valid
>
>
>
> BR, Øyvind Rønningstad
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
Hi everyone
I wanted to make it easier to debug HardFaults/BusFaults/SecureFaults in TFM, since I've gotten quite a few of them while adding the nrf platforms.
I have created a proposal in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7891 and would like to get some comments on the general idea.
The proposal gathers a number of different values, especially the ones that are harder to retrieve in a debugger, like the fault status registers in SCB.
The values are placed in memory so they can be inspected in a debugger, and if built with -DTFM_SPM_LOG_LEVEL=TFM_SPM_LOG_LEVEL_DEBUG they are also printed.
Here is an example of the printout:
FATAL ERROR: HardFault
Here is some context for the exception:
EXC_RETURN (LR): 0xFFFFFFBD
Exception came from non-secure FW in thread mode.
MSP(_S): 0x200007F8
PSP(_S): 0x20000F28
Exception frame at: 0x200176D8
R0: 0x0000003E
R1: 0x00000001
R2: 0x00000001
R3: 0xFFFFFFFF
R12: 0x00000000
LR: 0x00050623
PC: 0x00050626
CFSR: 0x00000000
BFAR: Not Valid
MMFAR: Not Valid
HFSR: 0x40000000
SFSR: 0x00000000
SFAR: Not Valid
BR, Øyvind Rønningstad
Hello,
The next Technical Forum is planned on Thursday, Feb 4 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi,
Just a humble suggestion: capability could be added to cmake to generate a build environment manifest. This could be a JSON or simple text file listing the location and version of each dependency (tool or software). The manifest file could simplify tracking down similar issues.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 28 January 2021 08:38
To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Is Musca-A deprecated already?
Thanks Sherry,
Appears the current "cysecuretools" has a dependency on imgtool 1.7.0a1, which is likely where it came from.
I did build for musca_a last week and I may have updated cysecuretools since then as I had issues with flashing the psoc64, and that must have installed 1.7.0a1.
I installed 1.7.1, which caused a dependency error on cysecuretools 3.0.0.
Works now!
Cheers,
Thomas
Den 2021-01-28 kl. 03:50, skrev Sherry Zhang:
Hi Thomas,
The issue is caused by the imgtool package itself. The version 1.7.0a1 is a pre-release version. If you check the line 378 of image.py of the imgtool package of version 1.7.0a1, it does not check the 'None' before accessing the custom_tlvs.items:
[cid:image003.jpg@01D6F552.951E90A0]
In the version of 1.7.1, it has added the 'None' check at line 389 in image.py:
[cid:image004.jpg@01D6F552.951E90A0]
In TF-M build system, the custom_tlvs should be 'None'.
To solve your issue, I suggest you use a release version of the imgtool package, such as 1.7.1, other than a pre-release one.
Please let me know how it goes.
Regards,
Sherry Zhang
From: Thomas Törnblom <thomas.tornblom(a)iar.com><mailto:thomas.tornblom@iar.com>
Sent: Wednesday, January 27, 2021 4:46 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com><mailto:Sherry.Zhang2@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com><mailto:nd@arm.com>
Subject: Re: [TF-M] Is Musca-A deprecated already?
Hi Sherry,
Looks like I have version 1.7.0a1.
PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_iar> imgtool version
1.7.0a1
Cheers,
Thomas
Den 2021-01-27 kl. 09:22, skrev Sherry Zhang:
Hi Thomas,
Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well.
An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/.
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas T�rnblom via TF-M
Sent: Wednesday, January 27, 2021 12:28 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Is Musca-A deprecated already?
I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains.
I get the following errors frmo all of them. Here's a gcc build:
---
[629/629] Generating tfm_s_ns_signed.bin
FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin
cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin"
Traceback (most recent call last):
File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module>
wrap()
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap
img.create(key, public_key_format, enckey, dependencies, boot_record)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create
for tag, value in custom_tlvs.items():
AttributeError: 'NoneType' object has no attribute 'items'
ninja: build stopped: subcommand failed.
---
cmake line:
cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON
I've tested building for several of the other targets, which seems to work, but I don't have any of these here.
Ideas?
Thanks,
Thomas
--
Thomas T�rnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas T�rnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Hi Thomas,
Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well.
An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/.
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: Wednesday, January 27, 2021 12:28 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Is Musca-A deprecated already?
I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains.
I get the following errors frmo all of them. Here's a gcc build:
---
[629/629] Generating tfm_s_ns_signed.bin
FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin
cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin"
Traceback (most recent call last):
File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module>
wrap()
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap
img.create(key, public_key_format, enckey, dependencies, boot_record)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create
for tag, value in custom_tlvs.items():
AttributeError: 'NoneType' object has no attribute 'items'
ninja: build stopped: subcommand failed.
---
cmake line:
cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON
I've tested building for several of the other targets, which seems to work, but I don't have any of these here.
Ideas?
Thanks,
Thomas
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Hi Thomas,
I can also confirm that the build works on a system with the linked environment<https://review.trustedfirmware.org/plugins/gitiles/ci/dockerfiles/+/refs/he…> setup.
I have tested your command, as well as the two methods listed in the documentation and all appear to be working.
Given this opportunity I would like to share that in accordance to the TrustedFirmware.org project maintenance proposal<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, the project should not be removing a platform in without fair notice. In TF-M we try to do so in three steps between releases:
* Adding a deprecation warning patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6516> which will notify the users during compilation and runtime.
* Marking is as soon to be deprecated in documentation.
* Removing the files on or after the marked release.
Back to your problem, I would also confirm that there are no environment variables setting a pre-downloaded repository for TF-M tests.
Please let us know how it goes.
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 27 January 2021 08:46
To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Is Musca-A deprecated already?
Hi Sherry,
Looks like I have version 1.7.0a1.
PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_iar> imgtool version
1.7.0a1
Cheers,
Thomas
Den 2021-01-27 kl. 09:22, skrev Sherry Zhang:
Hi Thomas,
Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well.
An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/.
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: Wednesday, January 27, 2021 12:28 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Is Musca-A deprecated already?
I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains.
I get the following errors frmo all of them. Here's a gcc build:
---
[629/629] Generating tfm_s_ns_signed.bin
FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin
cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin"
Traceback (most recent call last):
File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module>
wrap()
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap
img.create(key, public_key_format, enckey, dependencies, boot_record)
File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create
for tag, value in custom_tlvs.items():
AttributeError: 'NoneType' object has no attribute 'items'
ninja: build stopped: subcommand failed.
---
cmake line:
cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON
I've tested building for several of the other targets, which seems to work, but I don't have any of these here.
Ideas?
Thanks,
Thomas
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
I'm working on some IAR brokenness for the cypress/psoc64 and for
comparison I'm attempting to build for my favorite board, the musca_a,
but it seems builds fails now. I think it was working last week, but
today I'm unable to build with any of the toolchains.
I get the following errors frmo all of them. Here's a gcc build:
---
[629/629] Generating tfm_s_ns_signed.bin
FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin
cmd.exe /C "cd /D
C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot
&& C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe
C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py
-v 1.2.0 --layout
C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o
-k
C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem
--public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto
-d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin
C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin
&& "C:\Program Files\CMake\bin\cmake.exe" -E copy
C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin
C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin"
Traceback (most recent call last):
File
"C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py",
line 126, in <module>
wrap()
File
"C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py",
line 829, in __call__
return self.main(*args, **kwargs)
File
"C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py",
line 782, in main
rv = self.invoke(ctx)
File
"C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py",
line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File
"C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py",
line 610, in invoke
return callback(*args, **kwargs)
File
"C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py",
line 121, in wrap
img.create(key, public_key_format, enckey, dependencies, boot_record)
File
"C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py",
line 378, in create
for tag, value in custom_tlvs.items():
AttributeError: 'NoneType' object has no attribute 'items'
ninja: build stopped: subcommand failed.
---
cmake line:
cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a
"-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON
-DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG
-DTFM_PSA_API=ON
I've tested building for several of the other targets, which seems to
work, but I don't have any of these here.
Ideas?
Thanks,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi all,
Per the off-line discussion with Andrew, I’d like to start a wider discussion on the interrupt APIs, specifically the Secure Partition API changes for interrupt control in chapter 6.3.3.
There are the following APIs:
* uint32_t psa_irq_is_enabled (psa_signal_t irq_signal);
This API returns 0 if the interrupt is disabled and 1 if the interrupt is enabled.
* psa_irq_status_t psa_irq_disable(psa_signal_t irq_signal);
This API returns the status of the interrupt prior to this call with an implementation defined value
Note the return type of the interrupt status is different.
The first one is only to tell whether the interrupt is enabled (1) or not (0) – an equivalent to bool type.
The second one could be any value to indicate an interrupt status. And that value is intended to be passed to psa_irq_restore to write to the interrupt control register directly.
* void psa_irq_restore(psa_signal_t irq_signal, psa_irq_status_t saved_status);
The typical usage:
psa_irq_status irq2_state = psa_irq_disable(IRQ2_SIGNAL) ;
// manipulate data shared with IRQ2 …
psa_irq_restore(IRQ2_SIGNAL, irq2_state);
This is a very efficient design as the 'saved status value' can be the exact value that needs to be written to an interrupt control register to restore the previous state.
But TF-M seems to be unable to take that advantage.
Because the most common interrupt controller is the NVIC provided by the core.
The NVIC takes 1/0 to enable or disable the interrupt and one register for 32 interrupts.
The underlying NVIC operation provided by CMSIS is NVIC_Enable/DisableIRQ.
So the psa_irq_status_t in TF-M would simply 1 or 0 for a specific interrupt signal.
Then the psa_irq_restore could be unnecessary if psa_irq_disable returns uint32_t just like psa_irq_is_enabled:
uint32_t irq_status = psa_irq_disable(IRQ);
... // critical section
if (irq_status)
psa_irq_enable(IRQ);
Any thoughts on the necessity of the psa_irq_restore API?
The draft implementation of the current APIs for easy understanding:
https://review.trustedfirmware.org/q/topic:%22psa_interrupt_api%22+(status:…
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M
Sent: Friday, January 15, 2021 1:25 AM
To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification
Hi all,
The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer.
This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0.
This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification.
The 1.1 Extensions document can be downloaded from:
https://developer.arm.com/documentation/aes0039/latest
Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page:
https://developer.arm.com/architectures/security-architectures/platform-sec…
Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020.
If you have any feedback, please provide it to arm.psa-feedback(a)arm.com<mailto:arm.psa-feedback@arm.com>, or discuss the proposals here in the TF-M mailing list.
Regards,
Andrew
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
As mentioned in Tech Forum, call for feedbacks for doxygen usage:
- Anyone is checking doxygen documents?
- Which API are you checking with doxygen documents? The service APIs, or even some internal static API for SPM?
- When you are reading code, will you check the docs or you just open them in editors and then read it?
The background is we put many efforts on docs, it costs effort to maintain the doxygen format comments for all sources even the concept is covered in the docs folder, we are trying to find a balance to help mitigate the effort spent on internal logics (such as those static APIs inside SPM fewer people would update). For the interfaces API, doxygen would be always there so user can find them easily.
Thanks
/Ken
Hi everyone,
The design proposal of adding secure Flash support in TF-M has been
updated, I would like to ask for a review, any comments and suggestions
will be appreciated.
Link of the design proposal:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8033
Best Regards,
杨雪松 Edward Yang
旺宏微电子(苏州)有限公司
Macronix Microelectronics(Suzhou) Co., Ltd.
地址:中国苏州工业园区苏虹西路55号
No.55,Su Hong Xi Road,Suzhou Industrail Park,Suzhou 215021 P.R.China
TEL: 86-512-62580888 EXT: 3102
FAX: 86-512-62585399 ZIP: 215021
E-mail: edwardyang(a)mxic.com.cn
Http: //www.mxic.com.cn
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hello,
The agenda for the forum:
1. Proposal for changes to the OpenCI job coverage
2. Proposal to reduce Doxygen coverage to the interfaces only
3. Ongoing open issues:
* Musca-A platform deprecation
* Arm Firmware Framework for M 1.1 Extensions Alpha specification
Regards,,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 20 January 2021 14:18
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - January 21
Hi Anton,
I would like to raise a discussion about doxygen usage.
I think it is acceptable to apply doxygen usage in interfaces only if we want to keep alignment with CMSIS code since it applied doxygen result as reference manual; but for other logics, the doxygen is almost not used. Wondered how many users would generate reference manual from doxygen; or they just open an editor then start reading code from sources.
Thanks.
/Ken
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Karl Zhang via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Wednesday, January 20, 2021 7:54 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Technical Forum call - January 21
Hi Anton,
I would like to propose some changes to the openCI job coverage, it may take ~20 mins.
BR
Karl
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Thursday, January 14, 2021 4:19 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Technical Forum call - January 21
Hello,
The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Anton,
I would like to raise a discussion about doxygen usage.
I think it is acceptable to apply doxygen usage in interfaces only if we want to keep alignment with CMSIS code since it applied doxygen result as reference manual; but for other logics, the doxygen is almost not used. Wondered how many users would generate reference manual from doxygen; or they just open an editor then start reading code from sources.
Thanks.
/Ken
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Karl Zhang via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Wednesday, January 20, 2021 7:54 PM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - January 21
Hi Anton,
I would like to propose some changes to the openCI job coverage, it may take ~20 mins.
BR
Karl
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, January 14, 2021 4:19 AM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - January 21
Hello,
The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Anton,
I would like to propose some changes to the openCI job coverage, it may take ~20 mins.
BR
Karl
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, January 14, 2021 4:19 AM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - January 21
Hello,
The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi,
For implementing coming features and optimization, there would be couples of adjustment patches coming, this is the first one (the number looks good):
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8000
The idea is to get these patches to come in first so that we can have more time before the next release to fix spotted issues.
Please help to review the patches and provide different thinking if you have.
Thanks.
/Ken