nrf54l15: Applicability of mcuboot DIRECT_XIP mode

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Ramakrishnan — Fri, 06 Mar 2026 02:10:15 GMT

Okay, Thanks Vidar. Appreciate you diligently responding to all the questions. It helped me to understand how things are today... Will do some experimentation and get back if I have any more questions.

You can close the ticket if you would like to. I'm good for now.

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Vidar Berg — Thu, 05 Mar 2026 06:38:34 GMT

I made an edit to my earlier comment where I said it was not possible to use TF-M with direct-xip. Initially I forgot that the secure and non-secure memory split does not necessarily have to be static since it is controlled by the TF-M image, but I still doubt that it will work out of the box.

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Ramakrishnan — Wed, 04 Mar 2026 13:42:39 GMT

Ok, great. Thx

So, if I'm okay with tf-m + application getting upgraded through OTA and keep only mcuboot as non-upgradeable, then direct-xip is equally possible like swap-move ? or there is something else that prevents from using direct-xip?

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Vidar Berg — Wed, 04 Mar 2026 13:26:02 GMT

zephyr.elf is the application only. The signed binary includes both images. Yes, this applies to swap move too.

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Ramakrishnan — Wed, 04 Mar 2026 07:47:49 GMT

Ok. Thanks for that clarification.

Just so that I understand this clearly, are you saying that we can't upgrade the non-secure application alone without touching the tf-m that's already flashed . Because, the zephyr.signed.bin that gets generated when i build with cpuapp/ns includes the tf-m image as well ? When I disassemble zephyr.elf I don't see a lot of tf-m code, may be it gets pulled in only when zephyr.signed.bin is created ?

Regardless, if tf-m needs to be part of the image that will be used for OTA, it would apply for swap-move also , isn't it ?

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Vidar Berg — Wed, 04 Mar 2026 06:20:28 GMT

The TF-M image is merged with the application image and uploaded together, so it will not work with direct-xip, unfortunately.

EDIT: Technically it may work to combine tf-m with the direct-xip mode, but I do not see any tests or samples that covers this configuration. A potential issue may be if the TF-M image will be able to correctly configure the secure and non-secure memory regions also when executing from the secondary slot.

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Ramakrishnan — Wed, 04 Mar 2026 01:48:37 GMT

Thanks Vidar for the prompt response. I went through the sample, will give it a try. For resilience, the swap-move seem to handle it well. For now, we will try out both options for feasibility and then take a call.

A follow up question, We plan to keep mcuboot and tf-m as secure and non-upgradeable with 2 banks for application which will be non-secure and upgradeable. I presume we will be able to do this ( DIRECT_XIP ) even when running the application non-secure ?

RE: nrf54l15: Applicability of mcuboot DIRECT_XIP mode

Vidar Berg — Tue, 03 Mar 2026 09:46:43 GMT

Hello,

Yes, direct-xip is supported and is demonstrated by this sample here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/zephyr/smp_svr_mini_boot/README.html. The main reason for considering direct-xip is generally to reduce the FW activation time, not to make it more resilient against unexpected resets. The swap algorithm is designed to be resilient against that. It may still be a good idea to check the battery level before allowing DFU to be initiated.

Best regards,

Vidar