MCUBoot memory layout for FOTA for cpuapp and cpuflpr

[Jonathan Lange]

Hello,

one of our devices moved from using the nRF52832 to using the nRF54L15.

I created new board files and got the old software to run, after some adjustments.

The application uses MCUBoot and the devices are supposed to be updated over FOTA. If I am not mistaken we have to determine the memory layout for the immutable bootloader, before we can move to production (or even just further testing).
The new chip obviously opens up new possibilities - like using TF-M for more security and the fplr for parrallel processing. Both being part of the memory layout though. So I want to prepare the memory layout in a way that allows me to use them later if needed.

I think TF-M worked by just building with the corresponding board target.
Regarding the flpr, I am very lost.
Is it possible to update the flpr image with MCUBoot as well?
I read that the partition manager is about to be deprecated and would like to use the dts approach.
I started with the sysbuild Nordic Academy exercise for the flpr. (I have nRF54L15DK available for testing). After that I just enabled MCUBoot and it still builds succesfull and could probably update the cpuapp application, but since it was just the defaults MCUBoot settings and MCUBoot just takes the board target from my main application it only includes nrf54l15_cpuapp_ns_partition.dtsi in its final zephyr.dts and does not know about the flpr partition of nrf54l15dk_nrf54l15_cpuflpr.dts. (which also has the be split for the switch move algorithm)
Would I add the flpr image to the cpuapp devicetree as slot2_partition and slot3_partition as described in https://docs.mcuboot.com/readme-zephyr?
And then set the following in sysbuild.conf:

SB_CONFIG_PARTITION_MANAGER=n

SB_CONFIG_BOOTLOADER_MCUBOOT=y

SB_CONFIG_MCUBOOT_MODE_SINGLE_APP=n

SB_CONFIG_MCUBOOT_EXTRA_IMAGES=1

Additional questions:
If enabled via the snippet does the flpr get started from the cpuapp image after it was started by the bootloader or would it be started directly by the bootloader as well?

The flpr cpu does not support TF-M since its an Arm specification, correct? And following this I should not put sensitive information in the flpr image.

Is there a sample for the nRF54L15DK that uses cpuapp, cpuflpr and MCUBoot with the ability to update both?

After the building process is there a file with the generated memory layout MCUBoot uses as reference? (Like the old pm-static.yaml)
flash_layout.h is mentioned in nrf54l15_cpuapp_ns_partition.dtsi, but I can't find it in my build.

Kind regards
Jonathan Lange

[Håkon Alseth]

Hi,

 

A colleague of mine setup an example on this very topic:

https://github.com/vidarbe/ncs_hello_world_with_flpr

 

This is implemented based on our documentation on this matter:

https://docs.nordicsemi.com/bundle/ncs-3.3.0/page/nrf/app_dev/device_guides/nrf54l/nrf54l_signing_with_payload.html

 

Kind regards,

Håkon

[Jonathan Lange]

Thank you for this answer. The guide was suggested to me by the automated AI answer and set me on the right track after submitting. Sadly I was not able to get it to run even with the guide. The build was succesfull but the bootloader rejected the image.

With the example project it almost ran out of the box, but it failed to encode non-Ascii-symbols in def bin_to_header() in bin_to_header.py
After finding this solution on stackoverflow, I added the -X utf8 argument to CMakeLists.txt

add_custom_command(

    OUTPUT  "${FLPR_HDR}"

    COMMAND "${PYTHON_EXECUTABLE}"

                -X           utf8

                "${BIN2HDR}"

                --input      "${FLPR_BIN}"

                --output     "${FLPR_HDR}"

                --array-name flpr_firmware

    DEPENDS "${FLPR_BIN}" "${BIN2HDR}"

    COMMENT "Generating FLPR firmware header from zephyr.bin"

    VERBATIM

)

This was able to perform the encoding succesfull.
I thought I might share this in case someone gets a similar error and in hope that the sample can become an official sample in the future.

Gratefully
Jonathan

[Vidar Berg]

Thank you for suggesting this fix, Jonathan. I have not encountered this error before and not fully sure I understand what it means since I am not able to reproduce it on my system. Anyway for now I have updated the cmake script to include this argument: https://github.com/vidarbe/ncs_hello_world_with_flpr/blob/2c7148ba3acec1aa767422f6eab572378e7efb7b/CMakeLists.txt#L17