stm32: mcuboot: add support for mcuboot tests and samples #93862

djiatsaf-st · 2025-07-30T07:31:13Z

This PR adds support for testing MCUboot tests and samples. However, not all series are supported yet due to some limitations and hardware incapacity.

Related tests and samples :

zephyr/samples/sysbuild/with_mcuboot
zephyr/tests/boot/test_mcuboot
zephyr/tests/boot/with_mcumgr

add boot and slots partitions for flash memory in dedicated mcu boards Signed-off-by: Fabrice DJIATSA <[email protected]>

Add STM32 supported boards for the test. Signed-off-by: Fabrice DJIATSA <[email protected]>

Since the addition of a new storage partition definition in the nucleo_f746zg dts, this node must be deleted before performing this test. Signed-off-by: Fabrice DJIATSA <[email protected]>

sonarqubecloud · 2025-08-11T08:26:41Z

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

JarmouniA · 2025-08-18T13:45:09Z

boards/st/nucleo_g474re/nucleo_g474re.dts

 		boot_partition: partition@0 {
 			label = "mcuboot";
-			reg = <0x00000000 DT_SIZE_K(34)>;
+			reg = <0x00000000 DT_SIZE_K(64)>;


48KB is the minimum MCUboot partition size, Flash sectors are atmost 4KB on this SoC, so why give more to MCUboot?
Same for other Flash-constrainted SoCs with sub-32KB sector size.

I just based it on how the nucleo_wba55cg was added, and also compared the sizes of the flash sectors/pages in the refman and adapted with the rest so that it worked on the tests.
If you have some references on the rules to follow, that would be welcome.

https://docs.mcuboot.com/design.html#image-slots

nordicjm

see comments, there is a bunch of different things in this PR so not sure what the idea is...

nordicjm · 2025-09-01T09:21:22Z

boards/st/nucleo_c071rb/nucleo_c071rb.dts

+		/* Set 4KB of storage at the end of 128KB flash */
+		storage_partition: partition@1f000 {
+			label = "storage";
+			reg = <0x0001f000 DT_SIZE_K(4)>;
+		};


don't know what the sector size is but for nvs this would need to be at least 3 sectors to be usable

Indeed sectors (named "pages" in th SoC refman) are 2kB large.

nordicjm · 2025-09-01T09:21:47Z

boards/st/nucleo_f103rb/nucleo_f103rb.dts

+		slot0_partition: partition@10000 {
+			label = "image-0";
+			reg = <0x00010000 DT_SIZE_K(32)>;
+		};
+
+		slot1_partition: partition@18000 {
+			label = "image-1";
+			reg = <0x00018000 DT_SIZE_K(30)>;
+		};


sizes are different?

Aren't the sizes required to be different? There is no scratch partition, so this is using one of the move algorithms.

nordicjm · 2025-09-01T09:22:25Z

boards/st/nucleo_f746zg/nucleo_f746zg.dts

+		slot0_partition: partition@40000 {
+			label = "image-0";
+			reg = <0x00040000 DT_SIZE_K(448)>;
+		};
+
+		slot1_partition: partition@b0000 {
+			label = "image-1";
+			reg = <0x000b0000 DT_SIZE_K(320)>;
+		};


sizes are very different? If using different sizes then the extra sector should be in slot 1 and swap using offset should be used rather than swap using move

Thank you for your feedback.
Before addressing the comments, if you could please provide some references on algorithm-based partition distribution or other useful resources, they would be very helpful.

Seen F746xx SoCs flash sectors distribution (rm0385 rev9/table 3/page 79), I think the sole supported layout requires: slot0 is 2x256kB, slot1 is 1x256kB, storage is 3x32kB (placed at flash start) and boot occupies a signle 128kB sector.

nordicjm · 2025-09-01T09:23:04Z

tests/drivers/flash/stm32/boards/nucleo_f746zg.overlay

 */

+/delete-node/ &storage_partition;
 &flash0 {


newline line 8

str4t0m

It's good to get better test coverage, but I don't think it is reasonable to increase the bootloader partition so much. You may want add additional configuration overlays to trim it down and look at smaller nordic nrf51/nrf52 socs to see what is possible.

d3zd3z

Since the dts files in the zephyr tree are where most people will start when trying to support something new, I think it is important that we get this right. For the stm32 this means:

scratch should only be used on the devices that need it. These generally have very large sectors, and there ends up being three partitions for code, slot0, slot1, and scratch all being 128k.
For other devices, we should always be configured for swap-offset, and the partition tables should have a slot1 image that is 1 sector larger than slot0.

d3zd3z · 2025-10-09T18:32:30Z

boards/st/nucleo_f091rc/nucleo_f091rc.dts

+		slot1_partition: partition@27800 {
+			label = "image-1";
+			reg = <0x00027800 DT_SIZE_K(94)>;
+		};


Does this actually work? At least as I remember it, without a scratch partition, there are specific requirements for the sizes, and specifically one slot must be exactly one sector larger than the other (we'd have to look up which is which.)

d3zd3z · 2025-10-09T18:33:04Z

boards/st/nucleo_f103rb/nucleo_f103rb.dts

+		slot0_partition: partition@10000 {
+			label = "image-0";
+			reg = <0x00010000 DT_SIZE_K(32)>;
+		};
+
+		slot1_partition: partition@18000 {
+			label = "image-1";
+			reg = <0x00018000 DT_SIZE_K(30)>;
+		};


Aren't the sizes required to be different? There is no scratch partition, so this is using one of the move algorithms.

etienne-lms · 2025-10-10T06:10:58Z

tests/drivers/flash/stm32/boards/nucleo_f746zg.overlay

 * SPDX-License-Identifier: Apache-2.0
 */

+/delete-node/ &storage_partition;


Since the board already provides a storage area, it's seems not needed to override it.

etienne-lms · 2025-10-10T06:32:29Z

boards/st/nucleo_f746zg/nucleo_f746zg.dts

+		slot0_partition: partition@40000 {
+			label = "image-0";
+			reg = <0x00040000 DT_SIZE_K(448)>;
+		};
+
+		slot1_partition: partition@b0000 {
+			label = "image-1";
+			reg = <0x000b0000 DT_SIZE_K(320)>;
+		};


Seen F746xx SoCs flash sectors distribution (rm0385 rev9/table 3/page 79), I think the sole supported layout requires: slot0 is 2x256kB, slot1 is 1x256kB, storage is 3x32kB (placed at flash start) and boot occupies a signle 128kB sector.

etienne-lms · 2025-10-10T06:35:04Z

boards/st/nucleo_c071rb/nucleo_c071rb.dts

+
+		slot1_partition: partition@17800 {
+			label = "image-1";
+			reg = <0x00017800 DT_SIZE_K(30)>;


Could you update the flash: tag in board specific YAML files to reflect the Zephyr application max flash size for each of these modified layouts?

Could you update the flash: tag in board specific YAML files to reflect the Zephyr application max flash size for each of these modified layouts?

No, it's not a good idea, unless the target is meant to be used exclusively with MCUboot.

Instead, there should be a board mcuboot variant, with - sysbuild=true in its YAML file and MIN(slot0,slot1) as flash size.

etienne-lms · 2025-10-10T06:35:44Z

boards/st/nucleo_c071rb/nucleo_c071rb.dts

+		/* Set 4KB of storage at the end of 128KB flash */
+		storage_partition: partition@1f000 {
+			label = "storage";
+			reg = <0x0001f000 DT_SIZE_K(4)>;
+		};


Indeed sectors (named "pages" in th SoC refman) are 2kB large.

djiatsaf-st marked this pull request as draft July 30, 2025 07:31

zephyrbot added area: Samples Samples area: Sysbuild area: Bootloader platform: STM32 ST Micro STM32 area: MCUBoot labels Jul 30, 2025

zephyrbot requested review from FRASTM, GeorgeCGV, HoZHel, asm5878, benothmn-st, d3zd3z, de-nordic, erwango, etienne-lms, gautierg-st, kartben, marwaiehm-st, mathieuchopstm, nashif and nordicjm July 30, 2025 07:32

zephyrbot assigned d3zd3z Jul 30, 2025

djiatsaf-st force-pushed the support_mcuboot_tests branch 2 times, most recently from 959b37f to 9b3a129 Compare August 1, 2025 08:08

djiatsaf-st added 5 commits August 11, 2025 10:22

boards: st: add support for mcuboot test

c65a97c

add boot and slots partitions for flash memory in dedicated mcu boards Signed-off-by: Fabrice DJIATSA <[email protected]>

samples: sysbuild: with_mcuboot: update sample file

81c085b

Add STM32 supported boards for the test. Signed-off-by: Fabrice DJIATSA <[email protected]>

tests: boot: with_mcumgr: update testcase file

062a2eb

Add STM32 supported boards for the test. Signed-off-by: Fabrice DJIATSA <[email protected]>

tests: boot: test_mcuboot: update testcase file

8c240fa

Add STM32 supported boards for the test. Signed-off-by: Fabrice DJIATSA <[email protected]>

tests: drivers: flash: stm32: handle conflict for storage partition

920d124

Since the addition of a new storage partition definition in the nucleo_f746zg dts, this node must be deleted before performing this test. Signed-off-by: Fabrice DJIATSA <[email protected]>

djiatsaf-st force-pushed the support_mcuboot_tests branch from 9b3a129 to 920d124 Compare August 11, 2025 08:24

djiatsaf-st marked this pull request as ready for review August 14, 2025 15:45

zephyrbot added the area: Flash label Aug 14, 2025

de-nordic approved these changes Aug 18, 2025

View reviewed changes

JarmouniA requested changes Aug 18, 2025

View reviewed changes

nordicjm reviewed Sep 1, 2025

View reviewed changes

str4t0m reviewed Sep 9, 2025

View reviewed changes

d3zd3z requested changes Oct 9, 2025

View reviewed changes

etienne-lms reviewed Oct 10, 2025

View reviewed changes

stm32: mcuboot: add support for mcuboot tests and samples #93862

Are you sure you want to change the base?

stm32: mcuboot: add support for mcuboot tests and samples #93862

Uh oh!

Conversation

djiatsaf-st commented Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sonarqubecloud bot commented Aug 11, 2025

Quality Gate passed

Uh oh!

JarmouniA Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nordicjm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

str4t0m left a comment

Choose a reason for hiding this comment

Uh oh!

d3zd3z left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JarmouniA Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

djiatsaf-st commented Jul 30, 2025 •

edited

Loading

JarmouniA Aug 18, 2025 •

edited

Loading

JarmouniA Oct 10, 2025 •

edited

Loading