Skip to content

drivers: flash: stm32 xspi flash read with memcopy when executing #93762

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 1 commit into
base: main
Choose a base branch
from

Conversation

FRASTM
Copy link
Contributor

@FRASTM FRASTM commented Jul 28, 2025

When the application is executed in external flash, the read operation cannot be in indirect mode but with memcopy.
When executing in external flash, the CONFIG_STM32_APP_IN_EXT_FLASH is set, the application knows the external flash reading is done with memcopy.

Note that writing or erasing the external flash being executed is not possible during the execution on the external flash.

Fixes #92883

@FRASTM
Copy link
Contributor Author

FRASTM commented Jul 28, 2025

run the samples/sysbuild/with_mcuboot/ on the stm32h573i_dk with --sysbuild and mcuboot shell :

CONFIG_SHELL=y
CONFIG_FLASH_SHELL=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_SHELL=y
CONFIG_IMG_MANAGER=y
CONFIG_STREAM_FLASH=y
CONFIG_MCUBOOT_IMG_MANAGER=y

*** Booting Zephyr OS build v4.2.0-678-g399f8f8b181f ***
Address of sample 0x90000000
Hello sysbuild with mcuboot! stm32h573i_dk
uart:~$ mcuboot
swap type: none
confirmed: 1

primary area (2):
  version: 0.0.0+0
  image size: 76984
  magic: unset
  swap type: none
  copy done: unset
  image ok: unset

secondary area (3):
  version: 0.0.0+0
  image size: 78008
  magic: unset
  swap type: none
  copy done: unset                                                                                                   
  image ok: unset                                                                                                    
[00:00:04.089,000] <inf> mcuboot_util: Image index: 0, Swap type: none                                               
uart:~$ 

(with a second image downloaded on slot1_partition)

@FRASTM
Copy link
Contributor Author

FRASTM commented Jul 28, 2025

same change to apply to the

  • ./drivers/flash/flash_stm32_ospi
  • ./drivers/flash/flash_stm32_qspi

when reading with the CONFIG_STM32_APP_IN_EXT_FLASH set

@@ -1186,29 +1186,32 @@ static int flash_stm32_xspi_read(const struct device *dev, off_t addr,
return 0;
}

#ifdef CONFIG_STM32_MEMMAP
#if defined(CONFIG_STM32_MEMMAP) || defined(CONFIG_STM32_APP_IN_EXT_FLASH)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
#if defined(CONFIG_STM32_MEMMAP) || defined(CONFIG_STM32_APP_IN_EXT_FLASH)
#if defined(CONFIG_STM32_MEMMAP) || (defined(CONFIG_STM32_APP_IN_EXT_FLASH) && defined(CONFIG_XIP))

This is needed in my opinion, since the app image can be stored in ext flash but then be executed in RAM (after being copied there by MCUboot). In that case, we are not sure if the Flash is still MemMapped, because the app can exit Memmap mode and use a storage partition in external Flash for ex. Does this make sense?

set_config_bool(${ZCMAKE_APPLICATION} CONFIG_XIP n)

But maybe CONFIG_XIP is not the appropriate flag to check, since it is not disabled in SINGLE_APP_RAM_LOAD mode for ex.
elseif(SB_CONFIG_MCUBOOT_MODE_SINGLE_APP_RAM_LOAD)

I'm no longer sure of the exact semantics of Zephyr XiP at this point, I think it just means "app is executed where it was last loaded, RAM, Flash, PSRAM...by either flashloader or bootloader" or something close to this.

@nordicjm Any thoughts on this? what am I getting wrong?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

waiting for @nordicjm comment

Copy link
Contributor

Choose a reason for hiding this comment

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

We will perhaps need to check for MCUboot modes instead, to know if Memmap mode is still required after the image has started executing, see #85254 (comment)

It appears that XiP semantics in Zephyr needs real clarification in the docs & Kconfig help text, especially in relationship to the usage of a bootloader that can move the app image around, and Zephyr Code Relocation as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

to be honest I think the comment about single loader is wrong, it is executing from RAM, it should have XIP set to n, XIP means running from flash, the help text is clear on that:

        help
          This option allows the kernel to operate with its text and read-only
          sections residing in ROM (or similar read-only memory). Not all boards
          support this option so it must be used with care; you must also
          supply a linker command file when building your image. Enabling this
          option increases both the code and data footprint of the image.

Copy link
Contributor

Choose a reason for hiding this comment

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

XIP means running from flash, the help text is clear on that

But is the help text still accurate today, compared to when XiP was first introduced?

Copy link
Contributor

Choose a reason for hiding this comment

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

XIP means running from flash, the help text is clear on that

But is the help text still accurate today, compared to when XiP was first introduced?

yes, you are still running from read only media (one could argue that you could erase the flash sector you are running meaning it's not read only but that's not going to go well)

@FRASTM FRASTM force-pushed the issue92883 branch 2 times, most recently from e9722b4 to 7583708 Compare July 30, 2025 07:33
When the application is executed in external flash, the read operation
cannot be in indirect mode but with memcopy.
Note that writing or erasing the external flash being executed
is not possible during the execution.

Signed-off-by: Francois Ramu <[email protected]>
Copy link

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

Successfully merging this pull request may close these issues.

stm32h573i_dk and similar: MCUBoot with external flash not able to update image
5 participants