-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Boards: STM32H750B-DK: Introduce App in Ext Flash variant #97037
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
Boards: STM32H750B-DK: Introduce App in Ext Flash variant #97037
Conversation
erwango
left a comment
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.
@JarmouniA I was wondering if snippets could be used instead of adding a target each time we need to introduce an ext_mem app. Did you look at this possibility ?
Just thinking out loud, maybe the combination with sysbuild doesn't work great.
Not sure what we would put in them, maybe an ext Flash-specific snippet, but then the internal Flash is not necessarily the same, its sector size... |
95ac7ff to
573417e
Compare
|
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
00106a2 to
b26dafd
Compare
boards/st/stm32h750b_dk/stm32h750b_dk_stm32h750xx_ext_flash_app.dts
Outdated
Show resolved
Hide resolved
|
@erwango You should probably take the PR assignment, as it is only touching STM32 area (except for the minor tests' changes to add the board variant to |
519cd25 to
693af83
Compare
|
@etienne-lms Could you take a look, thanks! |
693af83 to
00aedda
Compare
Introduce a board variant for storing an app in external QSPI NOR Flash and chainloading it with MCUboot (placed in internal Flash) to be executed in place (uses MCUboot's swap-using-offset mode, set via Sysbuild). The new variant requires on MCUboot app side: a board/SoC DT overlay to set the internal Flash & Flash controller as the chosen 'zephyr,flash' & 'zephyr,flash-controller', and CONFIG_STM32_MEMMAP=y (this was upstreamed to MCUboot.) Change external Flash memory attribute "zephyr,memory-attr" to DT_MEM_ARM_MPU_FLASH, since ATTR_MPU_IO (corresponds to "DEVICE_NON_SHAREABLE & P_RW_U_NA") is actually for memory-mapped devices (with registers...) and was causing access issues with apps like LVGL that would freeze the target. Also, change the size of the external flash "zephyr,memory-region" node, since we only need to define accesss rights to the memory space actually used by the external flash chips, not the total addresssable QSPI memory. The 2nd QSPI NOR contoller node was removed, since it does not reflect the actual hardware layout, that has only one controller and the 2 NOR flash chips are connected to it in parallel with a shift register. Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
Add stm32h750b_dk/stm32h750xx/ext_flash_app target to CI platforms Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
Add stm32h750b_dk/stm32h750xx/ext_flash_app target to CI platforms. Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
Add stm32h750b_dk/stm32h750xx/ext_flash_app target to CI platforms of the Hawkbit sample. Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
00aedda to
ba20a2e
Compare
maass-hamburg
left a comment
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 things should be 😌
|



Introduce a board variant for storing an app in external QSPI NOR Flash and chainloading it with MCUboot (which is placed in internal Flash) to be executed in place (XiP).
The ext Flash memory partition also allows for using the Swap-using-offset & swap-using-move MCUboot image upgrade algorithms, eventhough it's not optimal as it has same-sized slots.
The new variant requires a board DT overlay on the MCUboot side (mcu-tools/mcuboot#2479) to set the internal Flash & Flash controller as the chosen 'zephyr,flash' & 'zephyr,flash-controller'. This way, no overlay will be needed at the Zephyr user app level.
Board doc preview https://builds.zephyrproject.io/zephyr/pr/97037/docs/boards/st/stm32h750b_dk/doc/index.html