Skip to content

Xip mcuboot #2323

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Xip mcuboot #2323

wants to merge 5 commits into from

Conversation

FRASTM
Copy link

@FRASTM FRASTM commented May 26, 2025

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 added 2 commits May 19, 2025 09:35
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 the external NOR defined by
the board device tree to be the first qspi/ospi/xspi instance
(not necessarily zephyr, flash-controller)

Signed-off-by: Francois Ramu <[email protected]>
Define the stm32 disco board configuration to set
the STM32 XIP mode that will enable the MemoryMapped mode.
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 FRASTM requested review from nordicjm and de-nordic as code owners May 26, 2025 14:04
@FRASTM
Copy link
Author

FRASTM commented May 26, 2025

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

FRASTM added 3 commits May 26, 2025 16:06
Define the stm32h7s7 and stm32h73 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]>
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]>
FLASH_DEVICE_BASE is now given by the parent of the "st,stm32-xspi-nor"
node, which  is the "st,stm32-xspi" compatible

Signed-off-by: Francois Ramu <[email protected]>
#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_BY_IDX(DT_INST(0, st_stm32_xspi),1)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instance 0 of st_stm32_xspi could be used for other purposes (PSRAM on N6-DK for instance).
We should ensure we get the parent of the st_stm32_xspi_nor node instead.
Something like:

Suggested change
#define FLASH_DEVICE_BASE DT_REG_ADDR_BY_IDX(DT_INST(0, st_stm32_xspi),1)
#define DT_DRV_COMPAT st_stm32_xspi_nor
#define FLASH_DEVICE_BASE DT_REG_ADDR_BY_IDX(DT_INST_PARENT(0), 1)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just ran into this exact issue on my STM32H7S78-DK, see zephyrproject-rtos/zephyr#88052 (comment)

This is because the flash for XiP is on XSPI2, and there is a PSRAM on XSPI1 which is therefore enabled in the device tree. Consequently, the macro being reviewed here is mistakenly using the XSPI1 (PSRAM) address space instead of XSPI2.

I solved the issue with the following change:

Suggested change
#define FLASH_DEVICE_BASE DT_REG_ADDR_BY_IDX(DT_INST(0, st_stm32_xspi),1)
#define FLASH_DEVICE_BASE DT_REG_ADDR_BY_IDX(DT_PARENT(FLASH_DEVICE_NODE),1)

I think we could do the same for ospi/qspi as well

#address-cells = <1>;
#size-cells = <1>;

slot0_partition: partition@0 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +31 to +34
scratch_partition: partition@d0000 {
label = "image-scratch";
reg = <0x000d00000 DT_SIZE_K(64)>;
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and unless you have different sector sizes or variable sector sizes, scratch should not be present

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants