I've created a proof of concept for allowing out-of-tree platforms here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7301 It was simpler than I had thought :) Øyvind From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: Thursday, November 26, 2020 07:57 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Rasmussen, Torsten <Torsten.Rasmussen@nordicsemi.nomailto:Torsten.Rasmussen@nordicsemi.no> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/fileshttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Ftrusted-firmware-m%2Fpull%2F18%2Ffiles&data=04%7C01%7Coyvind.ronningstad%40nordicsemi.no%7C0386d9599eb047b2626f08d891d888db%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637419706486504405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Poy3%2F7Wfi4hVUE%2BVdQ%2FxOJI%2BY3ggIYZx10sSPAUncMo%3D&reserved=0 We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something.

Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs.

But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations.

What are your thoughts? BR, Øyvind Rønningstad