MCUBOOT on nRF54L15: Can not FPROTECT region that big

[Fridtjof]

I'm working on a project for the nRF54L15. Until now I have not been using mcuboot, but since I added SB_CONFIG_BOOTLOADER_MCUBOOT=y to my sysbuild.conf, I get an error when building MCUBOOT:

error: static assertion failed: "Can not FPROTECT region that big"
   87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG)
      |                                    ^~~~~~~~~~~~~~

I found some old posts which recommended looking at partition manager and creating a pm_static, but partition manager was just deprecated so I want to use the device tree. How do I get rid of this build error?

[Fridtjof]

For whatever reason, the nRF54L-devices cannot FPROTECT more than 62kB. However, the standard size for the bootloader partition is 64kB. There are some .dtsi files in ncs which set the correct partition size, however, I don't know to make the build system include those.

I solved the issue by adding an overlay file to my project with the correct partitioning schema. In boards/nrf54l15dk_nrf54l15_partitions.overlay:

/delete-node/ &{/soc/rram-controller@5004b000/rram@0/partitions};

&cpuapp_rram {
	reg = <0x0 0x165000>;
	partitions{
		compatible = "fixed-partitions";
		#address-cells = <0x1>;
		#size-cells = <0x1>;
		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x0 DT_SIZE_K(62)>;
		};
		slot0_partition: partition@10000 {
			label = "image-0";
			reg = <0x10000 0xa0000>;
		};
		slot1_partition: partition@b0000 {
			label = "image-1";
			reg = <0xb0000 0xa0000>;
		};
		storage_partition: partition@150000 {
			label = "storage";
			reg = <0x150000 0x15000>;
		};
	};
    // cpuflpr occupies 0x165000 - 0x17d000
};

Then including this file in cpuapp's and mcuboot's overlay files. In boards/nrf54l15dk_nrf54l15_cpuapp.overlay:

#include "nrf54l15dk_nrf54l15_partitions.overlay"

In sysbuild/mcuboot/boards/nrf54l15dk_nrf54l15_cpuapp.overlay:

#include "../../../boards/nrf54l15dk_nrf54l15_partitions.overlay"

When adding a sysbuild folder (which we must in order to add a device tree overlay to mcuboot), zephyr stops including the default mcuboot prj.conf. So I copied it and added it as sysbuild/mcuboot/prj.conf:

####################################################################
# Copied from $ZEPHYR_BASE/bootloader/mcuboot/boot/zephyr/prj.conf #
####################################################################

CONFIG_PM=n

CONFIG_MAIN_STACK_SIZE=10240

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_IMAGE=n

CONFIG_BOOT_UPGRADE_ONLY=n
CONFIG_BOOT_BOOTSTRAP=n

### mbedTLS has its own heap
# CONFIG_HEAP_MEM_POOL_SIZE is not set

CONFIG_FLASH=y

### Various Zephyr boards enable features that we don't want.
# CONFIG_BT is not set
# CONFIG_I2C is not set

CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y
### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=0
### Use info log level by default
CONFIG_MCUBOOT_LOG_LEVEL_INF=y
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y
### Use picolibc to reduce flash usage
CONFIG_PICOLIBC=y
### Disable malloc arena because we don't need it
CONFIG_COMMON_LIBC_MALLOC_ARENA_SIZE=0

# NCS boot banner
CONFIG_NCS_APPLICATION_BOOT_BANNER_STRING="MCUboot"

Please tell me if this is a bad way to go.

[Fridtjof]

Actually this does not work. MCUBOOT does not seem to even boot

[Fridtjof]

I changed from using sysbuild/mcuboot/boards/nrf54l15dk_nrf54l15_cpuapp.overlay to sysbuild/mcuboot.overlay and deleted the sysbuild/mcuboot folder. This made the build system use mcuboot's default prj.conf, so the copied config file wasn't needed anymore.

But it still does not boot.

[Fridtjof]

I recreated the problem using the blinky sample. I also solved it. To recreate:

1. make a copy of blinky
2. in prj.conf, set CONFIG_MCUBOOT=y
3. create sysbuild.conf:
   

   SB_CONFIG_PARTITION_MANAGER=n
   SB_CONFIG_BOOTLOADER_MCUBOOT=y

Build with west build -b nrf54l15dk/nrf54l15/cpuapp --sysbuild and observe that the mcuboot build fails with the original error. Now, we fix this build error:

1. add boards/partitions.dtsi
   

   &boot_partition {
     reg = <0x0 DT_SIZE_K(62)>;
   };

2. add sysbuild/ folder and sysbuild/mcuboot.overlay
   

   #include "../boards/partition.dtsi"

Now The build will complete, but McuBoot will fail, and you can see the log over UART:

*** Booting MCUboot v2.3.0-dev-fce4dac2e629 ***
*** Using nRF Connect SDK v3.3.0-ba167d9f3db4 ***
*** Using Zephyr OS v4.3.99-fd9204a02d52 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=bad, swap_type=0x1, copy_done=0x2, image_ok=0x2
I: Boot source: none
I: Image index: 0, Swap type: none
E: Image in the primary slot is not valid!
E: Unable to find bootable image

The problem is that just by adding mcuboot.overlay, we have stopped the build system from including an important file, bootloader/mcuboot/boot/zephyr/app.overlay, which contains:

/ {
	chosen {
		zephyr,code-partition = &boot_partition;
	};
};

If you inspect our build/mcuboot/zephyr/zephyr.dts, you can see that zephyr,code-partition is set to &slot0_partition. If you add the above overlay code to sysbuild/mcuboot.overlay, the firmware successfully boots! Happy days!

Now my question is: Why? Is this a bug of some sort?

Edit: it seems like this solved the problem on blinky, but in my own larger project I'm still getting boot issues :(

[Vidar Berg]

Hello,

FPROTECT is limited by the available RRAM protection regions on this chip as mentioned here: https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/device_guides/nrf54l/dfu_config.html#nvm-protections so to be able to keep FPROTECT enabled in the bootloader, you will need to reduce the size of the bootloader, which you already did through your DT overlay. Given this limitation I agree that it does not make sense to have 64k allocated the bootloader slot by default.

Regarding the boot issue, perhaps you are missing the provisioning step: https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/device_guides/nrf54l/dfu_config.html#nvm-protections.

The public key is automatically provisioned to the KMU if you use the 

west flash --erase

 command. Button to invoke this command from the VS code extension:

Best regards,

Vidar