-
Notifications
You must be signed in to change notification settings - Fork 8.2k
STM32: H7RSx skip clock and xspi config when using XiP #97907
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?
Conversation
|
@erwango and @etienne-lms do you mind having a look at this? |
| { | ||
| int r = 0; | ||
|
|
||
| #if !defined(CONFIG_STM32_APP_IN_EXT_FLASH) |
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.
Completely skipping clock init could lead to misalignment of clock configuration between your bootloader and the application going unnoticed.
I'd suggest to follow what was done here: #88579
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.
Ok, looking into that PR
| { | ||
| int r = 0; | ||
|
|
||
| #if !defined(CONFIG_STM32_APP_IN_EXT_FLASH) |
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.
Ok, looking into that PR
| * turn off and reconfigure.) | ||
| * | ||
| */ | ||
| if (LL_RCC_GetSysClkSource() == LL_RCC_SYS_CLKSOURCE_STATUS_PLL1) { |
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.
Is this a realistic usecase? Chainloading into an app in the small 64k internal flash next to the bootloader (not using XiP)?
Guard with #if !defined(CONFIG_STM32_APP_IN_EXT_FLASH) or remove block?
Disables setting the VOLTAGE_SCALE1 (VOS1) during soc_early_init_hook() when CONFIG_STM32_APP_IN_EXT_FLASH is set. Signed-off-by: Thomas Decker <[email protected]>
Add write-block-size and erase-block-size attributes to xspi nor flash connected to xspi2. This is needed for mcuboot to handle flash access of the ext_flash. The changes in the node structure is taken from the stm32h7s78_dk board. Update zephyr,flash-controller in samples/sysbuild/with_mcuboot/boards /nucleo_h7s3l8.overlay to have CONFIG_STM32_APP_IN_EXT_FLASH set when direct parent of flash is not XSPI but only the parent of the flash- controller. Signed-off-by: Thomas Decker <[email protected]>
Check the used XSPIx peripheral before calling the corresponding function instead of hard-coded calling the LL_PWR_EnableXSPIM2() and LL_SBS_EnableXSPI2SpeedOptim() during flash_stm32_xspi_init(...). Signed-off-by: Thomas Decker <[email protected]>
Enable HSI clock node to fix get_hclk_frequency() returns 0 when called from stm32_clock_control_init(). HSI on is the devices reset default value anyway, but the STM32_HSI_FREQ define is set to 0 when not enabled. Signed-off-by: Thomas Decker <[email protected]>
Add stm32_clock_control_get_status() function needed by flash_stm32_xspi driver for handling XiP. Signed-off-by: Thomas Decker <[email protected]>
Extent set_up_plls() to check if we are running the app in XiP and only reconfigure PLLs and PLL outputs when they are not used in the clock path of Q/O/X-SPI or have other constraints like XSPI AXI clock >= XSPI kernel clock. Signed-off-by: Thomas Decker <[email protected]>
0aaf8a1 to
90bc050
Compare
|
|
I switched to the mcuboot bootloader and digged into sysbuild stuff. I tried to follow #88579 where things are done for the h5, but the h7 family is somehow more complicated (or my understanding of h5 details are wrong). Commit soc: st: stm32: h7rsx: Disable core power and VOS config for XiP (39d3878)The chain-loaded application must not switch to LL_PWR_REGU_VOLTAGE_SCALE1, because the bootloader most likely setup a fast core clock. Commit boards: arm: st: nucleo_h7s3l8: Add *-block-size properties to xspi2 (d0aeb47)
Commit drivers: flash: stm32_xspi: Remove hard-coded XSPI2 dependency (6cbf0b8)
Commit dts: arm: st: h7rs: Enable HSI internal clock (70eb6e5)
Commit drivers: clk: stm32_ll_h7: Add stm32_clock_control_get_status function (025fd7e)
Commit drivers: clock: stm32_ll_h7: Disable clock configuration for XiP (90bc050)Ok, now it gets ugly. I don't like this long list of #ifdefs and #defines, but I didn't find a short way implement this behaviour:
With these changes I am able to run the with_mcuboot example at a SYSCLK of 600MHz and the XSPI at 200MHz from PLL2S. Will hardfault without. The xspi2 node's clock setting must be changed to: |



I am using a customized OpenBLT bootloader which configures the clock system and the XSPI peripheral, then a Zephyr app is executed from external flash. I have not used MCUboot yet, but the problematic should be the same:
Zephyr must not change the clock path used for clocking the XSPI peripheral and must not change XSPI configuration nor set a VOLTAGE_SCALE not allowed for the already high cpu clock.
I have
CONFIG_XIP=yset in my prj.conf,CONFIG_STM32_APP_IN_EXT_FLASHis automatically set because of itsdefault $(DT_FLASH_PARENT_IS_XSPI)value.With the changes in this PR, the combination of bootloader and zephyr runs fine on the nucleo_h7s3l8. But I'm not sure if this is the best way to handle things, so I open this up for discussion...