-
Notifications
You must be signed in to change notification settings - Fork 772
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
base: main
Are you sure you want to change the base?
Xip mcuboot #2323
Conversation
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]>
only boards that have been tested with samples/sysbuild/with_mcuboot/ --sysbuild
|
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) |
There was a problem hiding this comment.
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:
#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) |
There was a problem hiding this comment.
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:
#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 { |
There was a problem hiding this comment.
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
scratch_partition: partition@d0000 { | ||
label = "image-scratch"; | ||
reg = <0x000d00000 DT_SIZE_K(64)>; | ||
}; |
There was a problem hiding this comment.
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
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)