Regression to execute on QSPI memory ??

[joelguittet]

Hello,

I'm currently working on getting the STM32F746G-DISCO board booting on QSPI in zephyr environment. Just done a fresh update (west update) everything broken...
This is due to commit f1efd48, but not sure which part exactly...

With this commit the image in the QSPI primary slot is detected invalid:

[00:00:00.479,000] <err> mcuboot: Image in the primary slot is not valid!
[00:00:00.486,000] <err> mcuboot: Unable to find bootable image

Just checkout the commit before, no more the error.
@taltenbach @nordicjm

Joel

[taltenbach]

Hi Joël, just looking at the commit I don't see any obvious relation between the changes and the failure you're seeing, so this will need further investigation. I will try tomorrow to reproduce your issue with a similar board.

Is the failure seen immediately after flashing using west flash or only after an update made via MCUboot?

[joelguittet]

Hello Thomas,
Thanks for the quick answer !
Initial programming with west flash.
I haven't take the time to debug this, just took recent commit one by one to understand when it was introduced.
If you have something to test I m happy also to do it on my board.
Joel

[de-nordic]

Build MCUboot with CONFIG_MCUBOOT_LOG_LEVEL_DBG=y and see if there is more diagnostic visible in logs.

[taltenbach]

@joelguittet Unfortunately I was unable to reproduce the issue on my STM32H747I-DISCO board. I put both the primary and secondary slots in the QSPI flash memory and I tried swap-move and swap-scratch configurations. As @de-nordic said, I think it could be useful to have more logs when you have some time. Also, could you share the configuration you're using (flash partitions and Kconfig values)?

[joelguittet]

Thanks for testing @taltenbach , will do.
I was working on support to boot on qspi on my stm32f746g-disco, so maybe my configuration, almost working before this commit, was not good and need to be reworked. You mentioned your board booting on qspi, is it a public example I can reuse ?

[taltenbach]

Sorry for the delay @joelguittet! I simply used the Zephyr's example application that I slightly customized to use MCUboot and execute the app from QSPI flash memory on my STM32H747I-DISCO board. I pushed a branch based on Zephyr v4.2.0-rc2 here: https://github.com/taltenbach/example-application/tree/test/stm32h747-mcuboot-xip

Note that:

• If you used the Zephyr main branch (or v4.2.0-rc1) at the time your issue was created, MCUboot wasn't jumping to the right address in QSPI flash memory because of stm32 xspi bindings fixes dtc warnings zephyrproject-rtos/zephyr#88646. A change was needed in MCUboot, which was merged recently (see Xip mcuboot #2323). Zephyr v4.2.0-rc2 contains the necessary change.
• The support for the QSPI flash memory on the STM32H747I-DISCO is currently broken in Zephyr. I created a PR to fix the issue (drivers: flash: stm32_qspi: Fix flash configuration in dual flash mode zephyrproject-rtos/zephyr#92737). The issue only impacts dual-flash mode, your STM32F746G-DISCO is not impacted.
• I fixed two minor bugs in the Zephyr's STM32 QSPI flash driver (see drivers: flash: stm32_qspi: Fix flash not reset when in QPI mode zephyrproject-rtos/zephyr#92743 and drivers: flash: flash_stm32_qspi: Make CS high time configurable zephyrproject-rtos/zephyr#92742). I doubt this would fix your issue but it could be good to retrieve those changes anyway.

[joelguittet]

Thanks @taltenbach . I have a couple of fix too I need to push creating pull requests. I was doubting of the good way to do it for the moment.
Will check all of this.