Hi Murat,

You are right the naming convention is faulty.

However the image is deliberately linked to the address space of SRAM. On Musca A1 only the low-level startup part of the bootloader is executed from QSPI. But it copies itself to SRAM as well. Then bootloader copies TF-M to SRAM and executes them from there. This is the reason why is it linked to that address space.

Could you explain how to try to execute TF-M in your use case?

Tamas

Hi Tamas,

Thank you for the reply.

Ok, it makes sense.

In our case, we are trying to port/integrate our Kernel (ZAYA Kernel) and we dont use bootloader at the moment. So, we locate all code in the QSPI flash.

• 0x10200000 : TFM (Secure)
• 0x220000 : ZAYA Kernel (Non-Secure)
• 0x230000 : ZAYA User Application (Non-Secure, ZAYA user applications are separate executables than the Kernel)

Also, we dont use TF-m makefiles to build the project. Instead, we created a Keil uVision project including scatter file. All addresses are absolute addresses(QSPI) and we can program the Musca Board using QSPI Flash Programming Algorithm using Keil uVision.

Probably you are running the image from the SRAM because of Musca board QSPI HW issue (only first 256K is directly accessible).

In this case, TF-m implementation can be left as is and we can modify the region_defs.h for our needs internally.

Or a compiler switch could be added like "run from QSPI or SRAM"?

Murat

Hi Murat,

exactly we decided to execute code from SRAM due to this 256KB limitation. If one wants to combine Secure code with a slightly bigger NS application then you can easily run out of QSPI space. Considering the allocated space for bootloader as well.

There were other parties as well who are interested in to execute TF-M without MCUBoot from SRAM or QSPI. The DIPDAP firmware of Musca A can load the image (drag-and-drop programming ) to both location, but there are separated firmware binaries. I do not know whether Keil can load code to code SRAM.

But we need to consider the extra complexity adding a new compiler switch:

• usually we add a compiler switch if it is applicable on all supported platform
• we are careful adding new switch to not blow up the test matrix for CI

Tamas

Thank you Tamas,

I agree a compiler switch for SRAM/QSPI selection should not affect the whole TF-m implementation. (Just scope of the compiler switch could trusted-firmware-m\platform\ext\target\musca_a while the only musca_a has this limitation but musca_a maintenance getting complex)

Also, Bootloader option was optional before while it is not now so we need more than one change at the moment, therefore we can handle our needs internally using patches.

Let us leave the TF-m implementation as is. In the near future, we will be aligning the with TF-m (Bootloader, SRAM Code Execution etc.)

If you agree, we are happy to close this ticket.

Thanks.
Murat Cakmak

Hi Murat,

Ok, if you can handle it internally then close the ticket.

Tamas

Hi, If I understand correctly only the region addresses need to be different for this use case, in which case it should be possible to update the cmake target and partition definition to achieve this purely within platform folder.

@zaya-mc, Would you like to enable this config to support the use case you are targeting?

Thanks,
Abhishek