CMake: MCUboot: fix image hex address in RAM Load mode

[JarmouniA]

In MCUBoot RAM LOAD mode, the app slot addr is taken as the hex-addr passed to imgtool to create slot0 & 1 images, which is only correct if the grand-parent node's (usually the flash node) absolute address is actually 0, because the addresses of all the flash fixed-partitions in-tree are relative to their grand-parent node's address.

Hence, use the newly added dt_fixed_partition_addr() CMake function to get the absolute address of app slots partitions.

[nordicjm]

My first point would be that you are missing a ranges property for your flash controller, but I have just investigated by building for stm32n6570_dk and I'm a bit confused because that board does not even use RAM load?

[nordicjm]

Saw you need to manually specify it, so it is not default. Anyhow, this fixes it with the ranges property, otherwise you are declaring that the flash partitions start at 0x0 in dts, which is wrong:

diff --git a/boards/st/stm32n6570_dk/stm32n6570_dk_common.dtsi b/boards/st/stm32n6570_dk/stm32n6570_dk_common.dtsi
index 5b91c96d7d4..758b007f0c6 100644
--- a/boards/st/stm32n6570_dk/stm32n6570_dk_common.dtsi
+++ b/boards/st/stm32n6570_dk/stm32n6570_dk_common.dtsi
@@ -380,6 +380,8 @@ zephyr_udc0: &usbotg_hs1 {
 
 	mx66uw1g45g: ospi-nor-flash@0 {
 		compatible = "st,stm32-xspi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
 		reg = <0>;
 		size = <DT_SIZE_M(1024)>; /* 1Gbits */
 		ospi-max-frequency = <DT_FREQ_M(200)>;
@@ -387,11 +389,13 @@ zephyr_udc0: &usbotg_hs1 {
 		data-rate = <XSPI_DTR_TRANSFER>;
 		four-byte-opcodes;
 		status = "okay";
+		ranges = <0x0 0x70000000 0x1000000>;
 
 		partitions {
 			compatible = "fixed-partitions";
 			#address-cells = <1>;
 			#size-cells = <1>;
+			ranges;
 
 			/*
 			 * Following flash partition is dedicated to the use of bootloader

[erwango]

My first point would be that you are missing a ranges property for your flash controller, but I have just investigated by building for stm32n6570_dk and I'm a bit confused because that board does not even use RAM load?

@nordicjm STM32N6 is a specific kind of STM32: there is no internal flash. In default mode, the BootROM (internal and non updatable bootloader) will load the binary (called First Stage Boot Loader) from ext flash (at a specific location) to RAM, which will then execute in XIP=n. FSBL can be a usual zephyr application or MCUBoot which will could then do it's usual job with application that would be also stored on ext flash.

[JarmouniA]

I'm implementing a CMake function in cmake.extensions, to replace dt_reg_addr above, that will give the absolute address of the slot partition, similar to the macro

zephyr/include/zephyr/devicetree/fixed-partitions.h

Line 133 in fb7a74e

#define DT_FIXED_PARTITION_ADDR(node_id) \

[erwango]

Probably a good thing but nack on the board impact part for now

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud