nrf54l15: Applicability of mcuboot DIRECT_XIP mode

[Ramakrishnan]

We have a board designed with nrf54l15 and we plan to use the RRAM to store the image.  That is, no external flash to store images.

For this design, is it possible to use DIRECT_XIP mode for mcuboot ?  The default/recommended method seems to be SWAP and MOVE.  But there are concerns around reliability due to additional flash operations ( like device running out of power during move , although mcuboot seems to handle it well ) . 

Just want to first understand if DIRECT_XIP is feasible in the first place ? 

Does the provided development environment support generating images for slot 0 and slot 1 with different load addresses ?

[Vidar Berg]

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

[Ramakrishnan]

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 ?

[Vidar Berg]

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.

[Ramakrishnan]

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 ?

[Vidar Berg]

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