Hi Jamie,

Could help to provide the details so that we can see what the problem is? Looks like you mentioned two problems here, one for the un-aligned memory accessing and another is the FLASH read/write.

For the memory alignment, to ensure the isolation setting all sections should be 32-bytes aligned; and the stack-alignment is 8 bytes. Other contents are set as default, the toolchain should have handled them correctly.

Please provide the details, thank you!

/Ken

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: Monday, March 29, 2021 10:19 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Issues with alignment and buffer locations

Hi,

There seems to be a large oversight in the TF-M codeline relating to buffer alignment and locations of buffers, in terms of buffer alignment, some ARM-based silicon has restrictions on buffer alignment, generally 4-byte boundaries, this means that if a non-4 byte boundary address, buffer or data size is provided, the operation cannot be completed. Another issue is that some ARM-based silicon has restrictions on where data can be located, e.g. in RAM only for writing and not from other address spaces.

I am currently trying to get TF-M working on a Nordic nRF53-based designed and have encountered these issues many times, and can see no way to set an alignment, data size or address space limitation in the whole code line which I find to be quite displeasing given that both the silicon and software are ARM-based, I would expect the software you give for silicon based on your reference designs to actually work with it out of the box rather than need lots of work to have these limitations supported. On Nordic silicon, data can only be written and read from RAM e.g. you cannot write to flash from a flash offset, and writes must be 4-byte aligned and 4-byte sized (the QSPI  functionality is being used here).

So I am emailing here to ask: what is the suggestion for dealing with this? Why does the baseline project not (from what I can see) have any sort of support for this?

Thanks,
Jamie

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.