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 « 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 « 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>
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 Started 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 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