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
Hi Tomasz,
I believe these questions are all platform specific for the STM32 target, I suggest again to directly get in touch with the ST maintainer: maintainers.rst « contributing « docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUshttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contributing/maintainers.rst
For example, flashing a binary on a platform is platform dependent, there are instructions on each in each platform docs, for example:
readme.rst « stm32u5xx « common « stm « platform « docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUshttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/platform/stm/common/stm32u5xx/readme.rst
Usage of PyOCD/OpenOCD is also platform dependent, so it would be a question for the maintainers to answer if it is possible to use, and in that case, the exact syntax of the command to use. The same for the usage of the firmware update on the platform to update binaries.
Thanks, Antonio
________________________________ From: Tomasz Jastrzębski via TF-M tf-m@lists.trustedfirmware.org Sent: Sunday, January 14, 2024 20:49 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
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 Startedhttps://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.html 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 herehttps://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.html#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
Hi Antonio,
Thank you for your answer. The intention of my question was not how to use pyOCD or OpenOCD , I use them on daily basis, I used their names just as an example.
However, what is important is which binaries need to be loaded, at what base address and which order. Probably this not platform specific.
I think that TF-M, by default relies on UART communication for NS firmware updates so again, the question is what commands and protocol has to be used. E.g Ymodem?
Anyway, postbuild.sh, regression.sh and TFM_UPDATE.sh scripts shed some light.
The second part of my email is even more important and, at least mainly, it is not platform specific. Does the process I described make sense? Is it how TF-M is intended to be used? Or, maybe, my USB-C boot loader should be implemented the same way and instead of the default UART support? But then image size will likely exceed limits since code will contain ThreadX. I do not know what would be the correct approach in this case.
Thanks,
Tomasz
From: Antonio De Angelis Antonio.DeAngelis@arm.com Sent: Monday, January 15, 2024 10:23 AM To: tf-m@lists.trustedfirmware.org; Tomasz Jastrzębski tdjastrzebski@wp.pl Subject: Re: [TF-M] Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
Hi Tomasz,
I believe these questions are all platform specific for the STM32 target, I suggest again to directly get in touch with the ST maintainer:
maintainers.rst https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr ibuting/maintainers.rst < contributing < docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUs
For example, flashing a binary on a platform is platform dependent, there are instructions on each in each platform docs, for example:
readme.rst https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/platf orm/stm/common/stm32u5xx/readme.rst < stm32u5xx < common < stm < platform < docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUs
Usage of PyOCD/OpenOCD is also platform dependent, so it would be a question for the maintainers to answer if it is possible to use, and in that case, the exact syntax of the command to use. The same for the usage of the firmware update on the platform to update binaries.
Thanks, Antonio
_____
From: Tomasz Jastrzębski via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Sent: Sunday, January 14, 2024 20:49 To: tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Subject: [TF-M] Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
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
Hi Tomasz,
Thank you for your valid questions. TF-M implements a set of PSA serviceshttps://arm-software.github.io/psa-api/ and offers a framework of Secure Processing Environment (SPE)https://trustedfirmware-m.readthedocs.io/en/latest/introduction/index.html for custom service extensions, ported on multiple HW platformshttps://trustedfirmware-m.readthedocs.io/en/latest/platform/index.html. A non-secure side (NSPE) like bare-metal application or RTOS integration is out of TF-M scope and shall be implemented as a part of end-product development. Examples of such implementations you can find in tf-m-extrashttps://git.trustedfirmware.org/TF-M/tf-m-extras.git/ repository.
A specific platform like STM in your case can offer different mechanism and tools for image upload so better refer to a platform documentation or ask questions to a platform maintainer as Antonio suggested.
Best regards and hope that helps, Anton
From: Tomasz Jastrzębski via TF-M tf-m@lists.trustedfirmware.org Sent: Monday, January 15, 2024 12:34 PM To: Antonio De Angelis Antonio.DeAngelis@arm.com; tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
Hi Antonio,
Thank you for your answer. The intention of my question was not how to use pyOCD or OpenOCD , I use them on daily basis, I used their names just as an example. However, what is important is which binaries need to be loaded, at what base address and which order. Probably this not platform specific. I think that TF-M, by default relies on UART communication for NS firmware updates so again, the question is what commands and protocol has to be used. E.g Ymodem? Anyway, postbuild.sh, regression.sh and TFM_UPDATE.sh scripts shed some light.
The second part of my email is even more important and, at least mainly, it is not platform specific. Does the process I described make sense? Is it how TF-M is intended to be used? Or, maybe, my USB-C boot loader should be implemented the same way and instead of the default UART support? But then image size will likely exceed limits since code will contain ThreadX. I do not know what would be the correct approach in this case.
Thanks, Tomasz
From: Antonio De Angelis <Antonio.DeAngelis@arm.commailto:Antonio.DeAngelis@arm.com> Sent: Monday, January 15, 2024 10:23 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Tomasz Jastrzębski <tdjastrzebski@wp.plmailto:tdjastrzebski@wp.pl> Subject: Re: [TF-M] Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
Hi Tomasz,
I believe these questions are all platform specific for the STM32 target, I suggest again to directly get in touch with the ST maintainer: maintainers.rst < contributing < docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUshttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contributing/maintainers.rst
For example, flashing a binary on a platform is platform dependent, there are instructions on each in each platform docs, for example: readme.rst < stm32u5xx < common < stm < platform < docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUshttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/platform/stm/common/stm32u5xx/readme.rst
Usage of PyOCD/OpenOCD is also platform dependent, so it would be a question for the maintainers to answer if it is possible to use, and in that case, the exact syntax of the command to use. The same for the usage of the firmware update on the platform to update binaries.
Thanks, Antonio
________________________________ From: Tomasz Jastrzębski via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Sunday, January 14, 2024 20:49 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
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 Startedhttps://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.html 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 herehttps://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.html#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
Hi Anton,
ST does offer at least four different mechanisms for image upload that I am aware of.
However, the first two of them are suitable only for OEMs. Another two (TFM and SBSFU) are at least partially based on TF-M (1.3?), probably are no longer actively developed and support Ymodem only. My summary of available options is posted here https://community.st.com/t5/stm32-mcus-security/secure-firmware-re-install- by-the-end-user-on-stm32u5-how-to/m-p/625456/highlight/true#M6262 .
That and desperation is exactly what brought me to this forum.
Thank you,
Tomasz
From: Anton Komlev Anton.Komlev@arm.com Sent: Monday, January 15, 2024 4:41 PM To: Tomasz Jastrzębski tdjastrzebski@wp.pl; Antonio De Angelis Antonio.DeAngelis@arm.com; tf-m@lists.trustedfirmware.org Subject: RE: [TF-M] Re: Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
Hi Tomasz,
Thank you for your valid questions. TF-M implements a set of PSA services https://arm-software.github.io/psa-api/ and offers a framework of Secure Processing Environment (SPE) https://trustedfirmware-m.readthedocs.io/en/latest/introduction/index.html for custom service extensions, ported on multiple HW platforms https://trustedfirmware-m.readthedocs.io/en/latest/platform/index.html .
A non-secure side (NSPE) like bare-metal application or RTOS integration is out of TF-M scope and shall be implemented as a part of end-product development. Examples of such implementations you can find in tf-m-extras https://git.trustedfirmware.org/TF-M/tf-m-extras.git/ repository.
A specific platform like STM in your case can offer different mechanism and tools for image upload so better refer to a platform documentation or ask questions to a platform maintainer as Antonio suggested.
Best regards and hope that helps,
Anton
From: Tomasz Jastrzębski via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Sent: Monday, January 15, 2024 12:34 PM To: Antonio De Angelis <Antonio.DeAngelis@arm.com mailto:Antonio.DeAngelis@arm.com >; tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
Hi Antonio,
Thank you for your answer. The intention of my question was not how to use pyOCD or OpenOCD , I use them on daily basis, I used their names just as an example.
However, what is important is which binaries need to be loaded, at what base address and which order. Probably this not platform specific.
I think that TF-M, by default relies on UART communication for NS firmware updates so again, the question is what commands and protocol has to be used. E.g Ymodem?
Anyway, postbuild.sh, regression.sh and TFM_UPDATE.sh scripts shed some light.
The second part of my email is even more important and, at least mainly, it is not platform specific. Does the process I described make sense? Is it how TF-M is intended to be used? Or, maybe, my USB-C boot loader should be implemented the same way and instead of the default UART support? But then image size will likely exceed limits since code will contain ThreadX. I do not know what would be the correct approach in this case.
Thanks,
Tomasz
From: Antonio De Angelis <Antonio.DeAngelis@arm.com mailto:Antonio.DeAngelis@arm.com > Sent: Monday, January 15, 2024 10:23 AM To: tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org ; Tomasz Jastrzębski <tdjastrzebski@wp.pl mailto:tdjastrzebski@wp.pl > Subject: Re: [TF-M] Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
Hi Tomasz,
I believe these questions are all platform specific for the STM32 target, I suggest again to directly get in touch with the ST maintainer:
maintainers.rst https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr ibuting/maintainers.rst < contributing < docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUs
For example, flashing a binary on a platform is platform dependent, there are instructions on each in each platform docs, for example:
readme.rst https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/platf orm/stm/common/stm32u5xx/readme.rst < stm32u5xx < common < stm < platform < docs - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUs
Usage of PyOCD/OpenOCD is also platform dependent, so it would be a question for the maintainers to answer if it is possible to use, and in that case, the exact syntax of the command to use. The same for the usage of the firmware update on the platform to update binaries.
Thanks, Antonio
_____
From: Tomasz Jastrzębski via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Sent: Sunday, January 14, 2024 20:49 To: tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Subject: [TF-M] Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )
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
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
Hi Tomasz,
Sorry for the delay in response. Although PCA FWU specification allows image compression, TF-M does not implement that feature because the method and place of image compression/decompression is flexible and is up to the target system design and implementation.
Best regards, Anton
From: Tomasz Jastrzębski via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, January 19, 2024 10:29 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Pre-encryption image compression
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 APIhttps://arm-software.github.io/psa-api/fwu/1.0/overview/architecture.html#manifest" document in sections 3.1 and 3.2 provides for image compression.
Kind regards,
Tomasz Jastrzębski
Hi Anton
Thank you for you for your response. It is helpful. I slowly start to see the big picture.
Kind regards,
Tomasz
From: Anton Komlev Anton.Komlev@arm.com Sent: Tuesday, January 30, 2024 4:14 PM To: Tomasz Jastrzębski tdjastrzebski@wp.pl; tf-m@lists.trustedfirmware.org Subject: RE: [TF-M] Pre-encryption image compression
Hi Tomasz,
Sorry for the delay in response.
Although PCA FWU specification allows image compression, TF-M does not implement that feature because the method and place of image compression/decompression is flexible and is up to the target system design and implementation.
Best regards,
Anton
From: Tomasz Jastrzębski via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Sent: Friday, January 19, 2024 10:29 AM To: tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Pre-encryption image compression
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
tf-m@lists.trustedfirmware.org
-
Anton Komlev -
Antonio De Angelis -
Tomasz Jastrzębski