this normally happens when there is some component that is requiring heap memory (heap is disabled in TF-M's plaform linker files, as we shouldn't have any function that requires it, apart for some debug functionalities (i.e. used only when the build type is Debug)).

This could be an issue with the toolchain (in the sense that some lib component is requiring heap and TF-M does not expect that) or that some functions in Musca-S1 platform are linked which require heap. I believe last year some fixes went to clean up some of the print() inclusions (i.e. the CryptoCell printing functions were being linked against the libc printf, rather than the printf implemented within TF-M). I suggest to check that your branch has those fixes as well. I am not entirely sure how TF-M gets integrated into Zephyr, they might have forked before those went it?

From: Arun D via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, October 23, 2023 12:37
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Building TF-M for ARM reference SoC/boards MPS2/MPS3 and Musca S1

Hi Xinyu,

The error reported by the cross compiler in "_sbrk" is "sbrk.c:21: undefined reference to `end'", seems to happen in the standalone clone of TF-M Git clone as well as the one under Zephyr "v3.4.0" (which is TF-M hash '79a6115d3', your commit dated 'Mon Apr 10 14:43:47 2023').

However the one under Zephyr's TF-M (same hash of "79a6115d3") builds ok when compiled via Zephyr's "west" build system.

Also, if I grep for the "79a6115d3" hash in standalone TF-M Git clone, I do not find it.

I am not sure how to reconcile these different observations. I would appreciate any thought.

Regards,
-Arun.
--
TF-M mailing list -- tf-m@lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org