Skip to content
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

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

FRASTM
Copy link

@FRASTM FRASTM commented Jan 25, 2024

Prepare the boot/zephyr/flash_map_extended.c to support the stm32 MemoryMapped mode where the application is XiP from a external octo/quad flash memory
This is done by setting the CONFIG_STM32_MEMMAP flag which configures the octo/quad flash stm32 driver in MemoryMapped mode.

The MCUBOOT is required to validate the image which is supposed to be in the external flash memory. With

	chosen {
		zephyr,flash = &flash0;
		zephyr,code-partition = &boot_partition;
	};

The mcuboot is built, linked and stored for the stm32 internal flash. The stm32 internal flash must declare the

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

Image slot 0 is located in the external NOR flash to be executed in XiP.

@FRASTM
Copy link
Author

FRASTM commented Jan 25, 2024

Requires the ../zephyr/drivers/flash/flash_stm32_ospi.c to support the XiP as in zephyrproject-rtos/zephyr#61082

$ west build -p always -b b_u585_iot02a -d build_mcuboot ../bootloader/mcuboot/boot/zephyr
$ west flash -d build_mcuboot
--> flash the build_mcuboot/zephyr/zephyr.bin at address 0x8000000

*** Booting Zephyr OS build zephyr-v3.5.0-5257-g667a0df780a5 ***
I: Starting Direct-XIP bootloader
I: Primary   slot: version=0.0.0+0
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the primary slot
I: Bootloader chainload address offset: 0x0
I: Jumping to the image slot
*** Booting Zephyr OS build zephyr-v3.5.0-5257-g667a0df780a5 ***
Hello World from XIP! b_u585i_iot02a

assuming there is a valid image at Primary slot in the external NOR flash. AT least one valid image is required in the external NOR flash.

@FRASTM
Copy link
Author

FRASTM commented Jan 25, 2024

when building the mcu boot there is no slot for image (no image, only a mcuboot) flashing at boot_partition of the flash0
The way to build the mcuboot for stm32 internal flash @ 0x8000000 is with. This is also possible with stm32h750b_dk which has a DUAL quad-spi flash @0x90000000

chosen {
	zephyr,flash = &flash0;
	zephyr,code-partition = &boot_partition;
};

and

$ west build -p always -b stm32h750b_dk -d build_mcuboot ../bootloader/mcuboot/boot/zephyr

`$ west flash -d build_mcuboot`
*** Booting Zephyr OS build zephyr-v3.5.0-5257-g667a0df780a5 ***
I: Starting Direct-XIP bootloader
I: Primary   slot: version=0.0.0+0
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the primary slot
I: Bootloader chainload address offset: 0x0
I: Jumping to the image slot
*** Booting Zephyr OS build zephyr-v3.5.0-5257-g667a0df780a5 ***
Hello World from XIP! stm32h750b_dk

@FRASTM FRASTM force-pushed the XIP_mcuboot branch 2 times, most recently from c135942 to 0689622 Compare February 2, 2024 12:32
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

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

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

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the stale label Nov 28, 2024
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.

1 participant