- TF-M - lists.trustedfirmware.org

by Tomasz Jastrzębski

Hi Ahmad, Thank you for the confirmation. To be honest, I did not expect good news. Kind regards, Tomasz From: Ahmad EL JOUAID <ahmad.eljouaid(a)st.com> Sent: Wednesday, February 7, 2024 3:04 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl> Cc: tf-m-request(a)lists.trustedfirmware.org; Stephane LE ROY <stephane.leroy(a)st.com> Subject: RE: STM target - HAL version upgrade? Hi Tomasz, In our objectives, we have included the update of the STM HAL version. However, an exact date for its implementation has not been determined yet. Nevertheless, I anticipate that the timeline for its execution will not be significantly prolonged. Kind regards, Ahmad STM ST Restricted From: Tomasz Jastrzębski < <mailto:tdjastrzebski@wp.pl> tdjastrzebski(a)wp.pl> Sent: Tuesday, February 6, 2024 2:49 PM To: <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org Cc: Ahmad EL JOUAID < <mailto:ahmad.eljouaid@st.com> ahmad.eljouaid(a)st.com>; Stephane LE ROY < <mailto:stephane.leroy@st.com> stephane.leroy(a)st.com> Subject: STM target - HAL version upgrade? Hi All, Are there currently any plans to update STM HAL version? HAL is a common component shared by all the STM boards. The currently used, relatively old version 1.0.0 does not support ST MCUs like STM32U5A9 and STM32U5G9 - the first one released a year ago. I need to decide where I should go ahead and do the update myself and since then probably maintain private TF-M version or maybe I should just wait because update is just on the way. Needless to say, an HAL update will probably take me way more effort than if it were done by someone who already knows the ropes. Kind regards, Tomasz Jastrzębski

1 year, 11 months

1
0
0 0

STM target - HAL version upgrade?

by Tomasz Jastrzębski

Hi All, Are there currently any plans to update STM HAL version? HAL is a common component shared by all the STM boards. The currently used, relatively old version 1.0.0 does not support ST MCUs like STM32U5A9 and STM32U5G9 - the first one released a year ago. I need to decide where I should go ahead and do the update myself and since then probably maintain private TF-M version or maybe I should just wait because update is just on the way. Needless to say, an HAL update will probably take me way more effort than if it were done by someone who already knows the ropes. Kind regards, Tomasz Jastrzębski

1 year, 11 months

2
1
0 0

STM32U585 target - how to remove TF-M and bootloader?

by Tomasz Jastrzębski

Hi All, I think I am ready to try TF-M on B-U585I-IOT02A board. However, before doing so I want to make sure I know how to remove it when tests are done. Please advise. Tomasz

1 year, 11 months

2
1
0 0

Can primary and secondary images size change in opposite directions? (2)

by Tomasz Jastrzębski

Hi Anton, I think now I finally understand what I what to achieve with TF-M and it may not be achievable. I was hoping for the TF-M to be able to be able to manage both SPE and NSPE partition containing my LocalLoader using two slots of variable size placed in non-continuous memory. The PRIMARY LocalLoader slot has fixed start while the SECONDARY LocalLoader slot has fixed end, but byte order in secondary blocks can be reversed so bootloader always knows where to start - that is, at the end of flash memory where the header starts going backwards. My MainApp remains managed by LocalLoader using Secure FW services, not by TF-M/MCUboot directly. I am afraid that the above scenario is currently not achievable with TF-M because: - LocalLoader secondary slot must have a fixed start location - The memory area that Primary/Secondary slots occupy has to be continuous - Secondary slot reverse byte order is not supported - although probably fairly easy to implement. Is my understanding correct? Kind regards, Tomasz From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, January 30, 2024 5:32 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Can primary and secondary images size change in opposite directions? Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? I cut the image from the original mail to stay within the size limit (80K). Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski

1 year, 11 months

2
2
0 0

Re: Can primary and secondary images size change in opposite directions?

by Tomasz Jastrzębski

Hi Anton I think what I really was uncertain about was whether sizes and locations of my LocalLoader "slots" have to be hardcoded somewhere so they cannot change, but it looks like it is not the case. As you pointed out, my LocalLoader app can just use TF-M crypto service to decrypt MainApp firmware update and then decompress it on its own. Ofc, out-of-the-box TF-M decryption-decompression (same time) service would be helpful, but there are no standard ones I am aware of and by no means lack of it is any show stopper. Kind regards, Tomasz Btw, I apologize for multiple posts, I thought those exceeding 80k would be just discarded. From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, January 30, 2024 5:23 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Can primary and secondary images size change in opposite directions? Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/17jrIfz0vE6OGJDWvXRn6TqNSh3mAX7e-/view?usp=s haring

1 year, 11 months

1
0
0 0

Re: Can primary and secondary images size change in opposite directions?

by Anton Komlev

Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? I cut the image from the original mail to stay within the size limit (80K). Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/17jrIfz0vE6OGJDWvXRn6TqNSh3mAX7e-/view?usp=… [cid:image002.png@01DA5399.4D502290]

1 year, 11 months

1
0
0 0

Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )

by Tomasz Jastrzębski

Hello All, I read the entire TF-M documentation, but I still do not quite understand how to get started with ST B-U585I-IOT02A, although my ultimate target is STM32U5A9/U5G9 MCU (4 MB of flash, 2.5/3.0 MB SRAM). 1. Based on Getting Started <https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht ml> section I managed to compile TF-M solution, but I do not know how to properly flash the board using e.g. pyOCD or OpenOCD. How do I flash bl2.bin, tfm_(n)s.bin and tfm_(n)s_signed.bin? The only method I found was described here <https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht ml#run-an521-regression-sample> and it relied on Arm Development Studio, a product which after 30-day evaluation must be purchased. 2. How do I update my NS application once the device is initially provisioned? I think this, although excellent TF-M documentation, is probably aimed at those who already are familiar with TF-M and could be supplemented with some "TF-M for dummies" section, better explaining basic concepts and the purpose all the TF-M services. Anyway, my goal is to implement as simple as it gets, yet secure firmware update. Firmware has to be signed and encrypted, ideally compressed as well. Firmware must be easily upgradable by non-technical users so USB stick with firmware file on it is the method of choice. What I envision is this process: 1. user inserts USB stick 2. device enters firmware update mode - probably performed by a separate, small and updatable "USB Loader" app, optionally using basic 1bit graphics, progress bar etc. - low flash & SRAM footprint. 3. "USB Loader" loads, verifies and decrypts new firmware using TF-M APIs and compresses it (if it was not compressed) when storing it in the internal SRAM. Compression may be required since internal SRAM on STM32U5A9/U5G9 (2.3/3.0 MB) is smaller than the flash size (4 MB). 4. Once the entire new firmware is loaded into internal SRAM, "USB Loader" decompresses it block-by-block and flashes flash, I suppose, again using TF-M APIs. Does the above process make sense? It is possible to implement it with TF-M? One potential challenge I can see is that, practically speaking, my "USB Loader" must use Microsoft FileX, USBX and, in consequence, ThreadX because probably only this way I can get USB-C and exFAT partitions support in a reasonable amount of time. TF-M docs do not list Microsoft ThreadX as a supported RTOS. Kind regards, Tomasz Jastrzębski

1 year, 11 months

3
7
0 0

STM32 target provisioning difficulties

by tomasz jastrzebski.net

After successful compilation I tried to provision B-U585I-IOT02A board following the steps described here: STM32U5 provisioning<https://trustedfirmware-m.readthedocs.io/en/latest/platform/stm/common/stm3…>. Process did not succeed due to the errors described below. What am I missing? postbuild.sh results in: Thomas@AMDMINIATX MINGW64 /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts (main) $ ./postbuild.sh ./postbuild.sh: line 22: /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts/preprocess.sh: No such file or directory preprocess bl2 file ./postbuild.sh: line 36: preprocess: command not found C:\Python312\python.exe: can't open file 'C:\\Temp\\tf-m\\trusted-firmware-m\\platform\\ext\\target\\stm\\common\\scripts\\scripts\\stm_tool.py': [Errno 2] No such file or directory postbuild.sh failed There are 3 versions of preprocess.sh script, it is compiler specific. TFM_UPDATE.sh has some syntax errors which reveal themselves under GitBash Thomas@AMDMINIATX MINGW64 /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts (main) $ ./TFM_UPDATE.sh TFM UPDATE started ./TFM_UPDATE.sh: line 52: [: ==: unary operator expected ./TFM_UPDATE.sh: line 56: [: ==: unary operator expected ./TFM_UPDATE.sh: line 59: [: ==: unary operator expected These are easy to fix. Eg. if [ $encrypted == "0x1" ]; then -> if [ "$encrypted" == "0x1" ]; then It looks postbuild.sh and TFM_UPDATE.sh take two additional parameters which are not documented. regression.sh takes one undocumented parameter.

1 year, 12 months

5
5
0 0

Can primary and secondary images have clearly different sizes?

by tomasz jastrzebski.net

Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size, hence the latest version may be clearly larger than the previous one. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. LL1 size may be clearly different than LL2, Local Loader update may result in the Main App update, but that is OK. Does TF-M support the described scenario? Flexibility is the key. Can primary and secondary Local Loader (LL) images have clearly different sizes? Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=… [cid:image001.png@01DA4F08.95319C00]<https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=…>

1 year, 12 months

2
3
0 0

Pre-encryption image compression (re-posting as a new topic)

by Tomasz Jastrzębski

Hello All, Does the current TF-M version support image compression before image is encrypted? Needless to say, compression after the image has been encrypted would not yield reasonable compression ratio. I am showing that *.bin files, even built with MinSizeRel option, zip-compress with minimum 50% compression ratio so probably this would make sense. Tested with STM32U5 target and GCC. "PSA Certified Firmware Update API <https://arm-software.github.io/psa-api/fwu/1.0/overview/architecture.html#m anifest> " document in sections 3.1 and 3.2 provides for image compression. Kind regards, Tomasz Jastrzębski

2 years

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M