mcuboot supports the stm32 external flash in XiP mode by FRASTM · Pull Request #2154 · mcu-tools/mcuboot

FRASTM · 2024-12-18T13:56:26Z

New version of the old PR #1891

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 · 2024-12-18T14:00:53Z

requires the zephyrproject-rtos/zephyr#81651 which introduces the nucleo_h7s3l8 target
The application running in the external flash is a samples/hello_world available in the branch https://github.com/FRASTM/zephyr/tree/xip_h7s3

JarmouniA · 2025-01-17T21:22:10Z

@FRASTM Any plans to move forward with this PR? some CI issues to be fixed (Primarily caused by missing "Signed-off-by: Francois RAMU francois.ramu@st.com" in some commits)

nordicjm

same for all .dts files, otherwise you can't build a zephyr application for them

FRASTM · 2025-01-23T11:56:45Z

correct sign-off
removing chosen zephyr,flash = &flash0; from the overlay as it is in the board DTS for zephyr

nordicjm · 2025-01-23T12:13:53Z

+		status = "okay";
+
+		partitions {
+			compatible = "fixed-partitions";


this should be in the upstream zephyr board so it's visible to everything

The xspi1 node is not enabled in the zephyr boards/st/stm32h7s78_dk/
then moving the overlay from mcuboot to zephyr board DTS will create a dependency with another next PR in zephyr (a PR to add the xspi1 node)

JarmouniA · 2025-03-17T10:59:59Z

@FRASTM Any plans to mark this PR as ready?
@erwango

Jowllel · 2025-03-29T16:45:00Z

These fixes seem a bit unclear to me. What do I need to change about the stm32h573i_dk board files, so I can use MCUBoot with XIP. My Issue is described in: zephyrproject-rtos/zephyr#87531

FRASTM · 2025-04-02T12:32:28Z

rebased on the main branch c8470fb

tested on the nucleo_h7s3l8 where the external flash is MX25UW25645GXDI00
Requires the &xspi2 node definition

*** Booting MCUboot v2.1.0-rc1-187-g2d4946ed7e39 ***
*** Using Zephyr OS build v4.0.0-rc3-6-g88c5329c33e5 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x0
I: Image version: v0.0.0
I: Jumping to the first image slot
*** Booting Zephyr OS build v4.0.0-rc3-6-g88c5329c33e5 ***
Hello World! from external flash  nucleo_h7s3l8

FRASTM · 2025-04-04T13:45:32Z

These fixes seem a bit unclear to me. What do I need to change about the stm32h573i_dk board files, so I can use MCUBoot with XIP. My Issue is described in: zephyrproject-rtos/zephyr#87531

@Jowllel, I will go with the stm32h573 disco kit in the coming days to execute from external flash

JarmouniA · 2025-04-24T09:43:05Z

+#define FLASH_DEVICE_ID SPI_FLASH_0_ID
+#if DT_NODE_HAS_STATUS(DT_INST(0, st_stm32_xspi_nor), okay)
+#define FLASH_DEVICE_NODE DT_INST(0, st_stm32_xspi_nor)
+#define FLASH_DEVICE_BASE DT_REG_ADDR(DT_INST(0, st_stm32_xspi_nor))


Shouldn't this be changed following #88646?

Yes, the FLASH_DEVICE_BASE is now given by the parent of the "st,stm32-xspi-nor" node. However
#define FLASH_DEVICE_BASE DT_REG_ADDR_BY_IDX(DT_INST(0, st_stm32_xspi),1)
does not help linking at the expected address 0x90000000 (stm32h573i_dk)

only
-DCONFIG_FLASH_BASE_ADDRESS=0x90000000
can link at the correct address of the external flash memory

@nordicjm Following zephyrproject-rtos/zephyr#88646, we're reusing similar bindings as you or NXP do for external memories (memory mapping address of the memory provided in a second reg cell of the memoy parent node ). I would expect we could align on a common code on mcuboot for this case, but apparently -DCONFIG_FLASH_BASE_ADDRESS=0x90000000 is still required which seems odd to me
Did we missed something ?

I am checking when the CONFIG_FLASH_BASE_ADDRESS is given by the Kconfig.defconfig for any stm32 soc as follows:

DT_CHOSEN_Z_FLASH := zephyr,flash DT_COMPAT_XSPI := st,stm32-xspi DT_CHOSEN_FLASH_NODE := $(dt_chosen_path,$(DT_CHOSEN_Z_FLASH)) DT_CHOSEN_FLASH_PARENT := $(dt_node_parent,$(DT_CHOSEN_FLASH_NODE)) DT_FLASH_PARENT_IS_XSPI := $(dt_node_has_compat,$(DT_CHOSEN_FLASH_PARENT),$(DT_COMPAT_XSPI)) config FLASH_BASE_ADDRESS default $(dt_node_reg_addr_hex,$(DT_CHOSEN_FLASH_PARENT),1) \ if $(DT_FLASH_PARENT_IS_XSPI) default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_FLASH))

The CONFIG_FLASH_BASE_ADDRESS is correctly defined = 0x90000000 which is the second reg of the xspi node:

xspi1: spi@47001400 { compatible = "st,stm32-xspi"; reg = <0x47001400 0x400>, <0x90000000 DT_SIZE_M(256)>;

Then build option -DCONFIG_FLASH_BASE_ADDRESS=0x90000000 is not required anymore and the application is correclty linked for external address of the NOR octo-flash

Kconfig above looks correct for specifying the base address

This PR will get the soc/st/stm32/Kconfig.defconfig inherited from the zephyr code which sets the CONFIG_FLASH_BASE_ADDRESS

FRASTM · 2025-04-29T08:42:42Z

without board overlay files :

zephyr,code-partition = &boot_partition; is in the app.overlay
zephyr,flash = &flash0; is already set in the board DTS

Requires the zephyrproject-rtos/zephyr#88579 where the CONFIG_FLASH_BASE_ADDRESS is defined by the soc/st/stm32/Kconfig.defconfig

nordicjm · 2025-04-29T09:38:44Z

 #if DT_NODE_HAS_STATUS(DT_INST(0, st_stm32_xspi_nor), okay)
 #define FLASH_DEVICE_NODE DT_INST(0, st_stm32_xspi_nor)
-#define FLASH_DEVICE_BASE DT_REG_ADDR(DT_INST(0, st_stm32_xspi_nor))
+#define FLASH_DEVICE_BASE DT_REG_ADDR_BY_IDX(DT_INST(0, st_stm32_xspi),1) 


fix in original commit

do you mean squashing 0adf7c0 and 22d64bc ?

FRASTM · 2025-05-07T15:22:55Z

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)

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

closed by error

Refer to #2323

FRASTM mentioned this pull request Dec 18, 2024

mcuboot supports the stm32 external octo-flash in XiP #1891

Closed

de-nordic added area: zephyr Affects the Zephyr port STM Changes related to STM platforms labels Dec 18, 2024

nvlsianpu approved these changes Dec 24, 2024

View reviewed changes

de-nordic requested review from de-nordic and nordicjm December 25, 2024 16:47

nordicjm reviewed Jan 20, 2025

View reviewed changes

Comment thread boot/zephyr/boards/b_u585i_iot02a.overlay Outdated

This was referenced Jan 20, 2025

boards: STM32h750B-DK: add memory partitions for MCUboot zephyrproject-rtos/zephyr#84256

Merged

Cannot boot LVGL apps from external QSPI Flash with MCUBoot zephyrproject-rtos/zephyr#84395

Closed

FRASTM force-pushed the XIP_mcuboot branch from 2d4946e to 9d40738 Compare January 23, 2025 11:56

FRASTM force-pushed the XIP_mcuboot branch from 9d40738 to 071f8cc Compare January 23, 2025 12:12

nordicjm reviewed Jan 23, 2025

View reviewed changes

FRASTM force-pushed the XIP_mcuboot branch 2 times, most recently from d81f77a to 500f4bd Compare January 23, 2025 15:17

JarmouniA mentioned this pull request Feb 9, 2025

Test zephyrproject-rtos/zephyr#85456

Closed

JarmouniA mentioned this pull request Mar 24, 2025

stm32h573i_dk can't boot from external flash with mcuboot zephyrproject-rtos/zephyr#87531

Closed

FRASTM force-pushed the XIP_mcuboot branch from 500f4bd to cb21d20 Compare April 2, 2025 12:23

FRASTM force-pushed the XIP_mcuboot branch from cb21d20 to 6d34ca2 Compare April 2, 2025 12:34

FRASTM mentioned this pull request Apr 2, 2025

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

Merged

FRASTM force-pushed the XIP_mcuboot branch 3 times, most recently from 540654e to 374659f Compare April 11, 2025 13:36

FRASTM mentioned this pull request Apr 14, 2025

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

Merged

FRASTM force-pushed the XIP_mcuboot branch 2 times, most recently from c821bee to 8d36285 Compare April 14, 2025 12:46

FRASTM marked this pull request as ready for review April 14, 2025 13:55

JarmouniA suggested changes Apr 24, 2025

View reviewed changes

FRASTM force-pushed the XIP_mcuboot branch from 8d36285 to 22d64bc Compare April 29, 2025 08:36

nordicjm reviewed Apr 29, 2025

View reviewed changes

FRASTM force-pushed the XIP_mcuboot branch from 22d64bc to 2f73ee8 Compare May 7, 2025 15:20

FRASTM closed this May 26, 2025

FRASTM force-pushed the XIP_mcuboot branch from 2f73ee8 to f74b77c Compare May 26, 2025 13:59

FRASTM mentioned this pull request May 26, 2025

Xip mcuboot #2323

Merged

JarmouniA mentioned this pull request Aug 12, 2025

boot: zephyr: boards: nrf54h20dk cpuapp add chosen code part #2425

Merged

Conversation

FRASTM commented Dec 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FRASTM commented Dec 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

nordicjm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JarmouniA commented Mar 17, 2025

Uh oh!

Jowllel commented Mar 29, 2025

Uh oh!

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

Uh oh!

Uh oh!

FRASTM commented Apr 4, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FRASTM Apr 24, 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!

FRASTM Apr 28, 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!

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

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

FRASTM commented Dec 18, 2024 •

edited

Loading

FRASTM commented Dec 18, 2024 •

edited

Loading

JarmouniA commented Jan 17, 2025 •

edited

Loading

FRASTM commented Jan 23, 2025 •

edited

Loading

FRASTM commented Apr 2, 2025 •

edited

Loading

FRASTM Apr 24, 2025 •

edited

Loading

FRASTM Apr 28, 2025 •

edited

Loading

FRASTM commented Apr 29, 2025 •

edited

Loading

FRASTM commented May 7, 2025 •

edited

Loading

FRASTM commented May 26, 2025 •

edited

Loading