Xip mcuboot #2323

FRASTM · 2025-05-26T14:04:01Z

New version of the #2154

Adding the stm32h7s3l8 nucleo board

Following zephyrproject-rtos/zephyr#76305

Build the application with sysbuild for the nucleo_h7S3L8 :

west build -p auto -b nucleo_h7s3l8 samples/boards/st/hello_world_xip --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y
then, download mcuboot at address 0x8000000 and download the signed hello_world_xip application at 0x70000000 (where i can read the magic nb)

FRASTM · 2025-05-26T14:04:07Z

only boards that have been tested with samples/sysbuild/with_mcuboot/ --sysbuild

stm32h573_dk (st,stm32-xspi driver) --> stm32h5 run application in external flash memory XIP zephyrproject-rtos/zephyr#88579
stm32h7rs (st,stm32-xspi driver) --> stm32h7rs run application in external flash memory XIP zephyrproject-rtos/zephyr#88052
b_u585i_iot02a (st,stm32-ospi compatible) --> stm32 ospi bindings fixes dtc warnings zephyrproject-rtos/zephyr#89707
stm32h750b_dk (st,stm32-qspi compatible)

boot/zephyr/flash_map_extended.c

nordicjm · 2025-05-29T11:37:57Z

boot/zephyr/boards/b_u585i_iot02a.overlay

+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		slot0_partition: partition@0 {


as I said in the other PR, adding this here is pointless, this should go in your base board file in zephyr otherwise you will have completely different partitions for mcuboot vs every application, and the applications will not boot because of that

I understand, that the slot 0 & 1 partitions are kept in the flash0
However, when building the samples/sysbuild/with_mcuboot/ --sysbuild, is there any b_u585i_iot02a.overlay, to declare the zephyr,code-partition to be placed in the external flash, not in the flash0 ?
The slot0_partition is usually in the flash0, but for that samples, we want to place the slot0 in the external flash. The code must then be compiled, linked and downloaded in the external flash.
I see that ./build/with_mcuboot/zephyr/zephyr.signed.bin is linked at address 0 instead of 0x70000000
But this could be another problem : CONFIG_FLASH_BASE_ADDRESS 0x0

no, a board variant should be used for that (either in tree or out of tree with board extensions)

boot/zephyr/boards/b_u585i_iot02a.overlay

erwango · 2025-06-27T06:55:00Z

Please rebase, following merge of #2348 .

FRASTM · 2025-06-30T11:58:14Z

rebase on 07222c1

boot/zephyr/flash_map_extended.c

FRASTM · 2025-07-01T07:31:46Z

next step : (end of july) : going to add a variant for the stm32U5 series

erwango · 2025-07-01T07:39:24Z

next step : (end of july) : going to add a variant for the stm32U5 series

I think we should get at least the flash_extended.c update merged right now since it is broken for QSPI/OSPI atm due to the bindings change.

FRASTM · 2025-07-01T08:06:49Z

next step : (end of july) : going to add a variant for the stm32U5 series

I think we should get at least the flash_extended.c update merged right now since it is broken for QSPI/OSPI atm due to the bindings change.

OK, so :

use this PR for flash_map extended.c
where #define FLASH_DEVICE_BASE DT_REG_ADDR_BY_IDX(DT_INST_PARENT(0), 1)
set another PR for the stm32U5 series (st_stm32_ospi_nor compatible) defining a variant

NB Still CI failure due to strange error on signature

erwango · 2025-07-01T08:22:44Z

@de-nordic Any idea why the ./ci/check-signed-off-by.sh is complaining about ?
Supposedly guilty commit is signed ....

With CONFIG_STM32_MEMMAP flag get NOR flash 32 bytes header Read the NOR flash to get header of the image. The FLASH_DEVICE is now given by the parent of the "st,stm32-xspi-nor" node, which is the "st,stm32-xspi" compatible same for qspi/ospi instances of stm32 devices. Signed-off-by: Francois Ramu <[email protected]>

de-nordic · 2025-07-01T16:59:02Z

@de-nordic Any idea why the ./ci/check-signed-off-by.sh is complaining about ? Supposedly guilty commit is signed ....

The author has not signed-off, sha differs because I have rebased the branch after pulling (for no reason...)

script checks if signoff list contains author and it does not.
Some different git config has been used for that commit.

Define the stm32h7s7 board configuration to set the STM32 XIP mode that will enable the MemoryMapped mode. Gives larger sector size for the external NOR flash See Kconfig of the stm32 soc. Choose the mcu_boot partition where to build ../bootloader/mcuboot/boot/zephyr Signed-off-by: Francois Ramu <[email protected]>

Define the stm32h573 board configuration to set the STM32 XIP mode that will enable the MemoryMapped mode. Gives larger sector size for the external NOR flash See Kconfig of the stm32 soc. Choose the mcu_boot partition where to build ../bootloader/mcuboot/boot/zephyr The zephyr, chosen zephyr,flash = &flash0; is in the board dts. The zephyr,code-partition = &boot_partition; is given by the app.overlay Signed-off-by: Francois Ramu <[email protected]>

FRASTM · 2025-07-02T08:21:01Z

reformating signoff

titouanc

For what it's worth, successfully tested on my STM32H7Z78-DK (with latest Zephyr main at b3ccee473ed64ac9ba7260beafb4fd175eee13ab)

erwango · 2025-07-07T09:26:20Z

@de-nordic This PR (at the minimum the flash-extended part) is required to keep compatibility with Zephyr v4.2 following zephyrproject-rtos/zephyr#88404 for OSPI and QSPI.
What is the procedure in this case?
Is it the usual merge in current MCUBoot with a follow up Zephyr fork sync ?

nordicjm · 2025-07-07T09:45:57Z

If this is a bug fix then sure but if not then it's not something that should be added to 4.2

erwango · 2025-07-07T10:15:21Z

zephyrproject-rtos/zephyr#88404

zephyrproject-rtos/zephyr#88404 has been integrated in v4.2 to align ST bindings with dtc recommendations (and other vendors)
This involves a different way to access size information, which current PR is addressing. Otherwise MCUBoot can't access size of the flash. This is already fixed fir XSPI, but missing for O/QSPI

FRASTM requested review from de-nordic and nordicjm as code owners May 26, 2025 14:04

FRASTM force-pushed the XIP_mcuboot branch from a5dbd66 to e3b8bd4 Compare May 26, 2025 14:06

erwango suggested changes May 27, 2025

View reviewed changes

boot/zephyr/flash_map_extended.c Outdated Show resolved Hide resolved

nordicjm reviewed May 29, 2025

View reviewed changes

JarmouniA mentioned this pull request Jun 3, 2025

stm32h7rs run application in external flash memory XIP zephyrproject-rtos/zephyr#88052

Merged

erwango mentioned this pull request Jun 20, 2025

zephyr: stm32n6 support #2348

Merged

FRASTM mentioned this pull request Jun 30, 2025

mcuboot supports the stm32 external flash in XiP mode #2154

Closed

FRASTM force-pushed the XIP_mcuboot branch from e3b8bd4 to 4617296 Compare June 30, 2025 11:58

FRASTM mentioned this pull request Jun 30, 2025

stm32h5 run application in external flash memory XIP zephyrproject-rtos/zephyr#88579

Merged

FRASTM force-pushed the XIP_mcuboot branch from 4617296 to 8418a57 Compare June 30, 2025 15:11

erwango suggested changes Jun 30, 2025

View reviewed changes

boot/zephyr/flash_map_extended.c Outdated Show resolved Hide resolved

FRASTM force-pushed the XIP_mcuboot branch 2 times, most recently from 6c735b8 to f4f2815 Compare July 1, 2025 07:36

FRASTM force-pushed the XIP_mcuboot branch 2 times, most recently from 361d00d to 70ae81d Compare July 1, 2025 07:42

FRASTM force-pushed the XIP_mcuboot branch 2 times, most recently from 87fd4d3 to b9de801 Compare July 1, 2025 08:26

FRASTM force-pushed the XIP_mcuboot branch from b9de801 to 1f79f7d Compare July 1, 2025 08:35

erwango approved these changes Jul 1, 2025

View reviewed changes

FRASTM mentioned this pull request Jul 2, 2025

stm32: q/o/x-spi bindings generate dtc warnings zephyrproject-rtos/zephyr#88404

Closed

FRASTM added 2 commits July 2, 2025 10:19

FRASTM force-pushed the XIP_mcuboot branch from 1f79f7d to 319c8e8 Compare July 2, 2025 08:20

FRASTM requested review from nordicjm and titouanc July 7, 2025 07:24

titouanc approved these changes Jul 7, 2025

View reviewed changes

nordicjm approved these changes Jul 7, 2025

View reviewed changes

nordicjm merged commit 4eba808 into mcu-tools:main Jul 7, 2025
58 checks passed

taltenbach mentioned this pull request Jul 9, 2025

Regression to execute on QSPI memory ?? #2374

Closed

Xip mcuboot #2323

Xip mcuboot #2323

Uh oh!

Conversation

FRASTM commented May 26, 2025

Uh oh!

FRASTM commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

nordicjm May 29, 2025

Choose a reason for hiding this comment

Uh oh!

FRASTM Jun 30, 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!

nordicjm Jun 30, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

erwango commented Jun 27, 2025

Uh oh!

FRASTM commented Jun 30, 2025

Uh oh!

Uh oh!

FRASTM commented Jul 1, 2025

Uh oh!

erwango commented Jul 1, 2025

Uh oh!

FRASTM commented Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

erwango commented Jul 1, 2025

Uh oh!

de-nordic commented Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FRASTM commented Jul 2, 2025

Uh oh!

titouanc left a comment

Choose a reason for hiding this comment

Uh oh!

erwango commented Jul 7, 2025

Uh oh!

nordicjm commented Jul 7, 2025

Uh oh!

erwango commented Jul 7, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

FRASTM commented May 26, 2025 •

edited

Loading

FRASTM Jun 30, 2025 •

edited

Loading

FRASTM commented Jul 1, 2025 •

edited

Loading

de-nordic commented Jul 1, 2025 •

edited

Loading