boards: st: stm32h573i_dk: Add board variant for app in external flash

[tpambor]

Commit 5d0306c of #88579 moved the slot0_partition, slot1_partition, scratch_partition from the internal flash to the external OSPI NOR flash. At the same time, the nor partition on the external NOR flash was deleted. This breaks all applications that rely on the slot0_partition, slot1_partition, scratch_partition to be on internal flash as well as all applications that use the nor partition on external flash with the stm32h573i_dk board.

To avoid breaking existing projects and maintain compatibility with previous versions of Zephyr, this PR restores the default flash layout and introduces a new board variant for applications stored in external flash. This approach allows users to opt-in to the new flash layout without affecting existing projects.

A similar ext_flash_app variant is proposed for the STM32H750B-DK in #97037.

Fixes #97423.

[erwango]

@tpambor Thanks for this, but don't you miss to add an overlay in mcuboot repo to provide the right zephyr,flash and zephyr,flash-controller ? (Dependency that I'd like to get rid of but mandatory today for current version of #97037)

[tpambor]

@tpambor Thanks for this, but don't you miss to add an overlay in mcuboot repo to provide the right zephyr,flash and zephyr,flash-controller ? (Dependency that I'd like to get rid of but mandatory today for current version of #97037)

You are right, I missed that, currently it places mcuboot in external flash, so a overlay is necessary for mcuboot.

	/* node '/chosen' defined in zephyr/dts/common/skeleton.dtsi:13 */
	chosen {
...
		zephyr,flash = &ext_flash;                 /* in zephyr/boards/st/stm32h573i_dk/stm32h573i_dk_stm32h573xx_ext_flash_app.dts:15 */
		zephyr,flash-controller = &ext_flash_ctrl; /* in zephyr/boards/st/stm32h573i_dk/stm32h573i_dk_stm32h573xx_ext_flash_app.dts:16 */
		zephyr,code-partition = &boot_partition;   /* in bootloader/mcuboot/boot/zephyr/app.overlay:3 */
	};

[etienne-lms]

The overall looks good to me and is more consistent regarding the board initial layout.

For commit "boards: st: stm32h573i_dk: Add board variant for app in external flash":
Would it be worth to add an entry in the board doc to mention the new variant?

For commit "mgmt: hawkbit: Replace overlay with new board variant":
Could you prefix the commit message header line with samples: ?

[github-actions]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[nordicjm]

I'm OK with boards using different defaults for the mode, sure some other features might not be compatible with a specific configuration but that's just how those features are, direct-xip is a valid supported MCUboot mode and fine for any board to use (by default or otherwise)

[JarmouniA]

Can you please rework the 2 commits concerning the board, put everything concerning the base variant (with the common dtsi) in a 1st commit which builds and runs correctly with & without MCUboot. Then, introduce the ext_flash_app variant in a 2nd commit.

[tpambor]

Can you please rework the 2 commits concerning the board, put everything concerning the base variant (with the common dtsi) in a 1st commit which builds and runs correctly with & without MCUboot. Then, introduce the ext_flash_app variant in a 2nd commit.

The motivation for having the two commits like this was that current main is external flash only, so splitting it into first commit internal flash, second commit external flash, would require reverting some changes and re-introduce at the same time the old layout from 4.2 which used internal flash and then in second commit re-apply the changes from master to have external flash.

[JarmouniA]

so splitting it into first commit internal flash, second commit external flash, would require reverting some changes and re-introduce at the same time the old layout from 4.2 which used internal flash and then in second commit re-apply the changes from master to have external flash.

I don't see an issue with that. You can also just put everything (board-related) is one commit (and detail all the changes & the reasoning behind them in the commit message).

FYI, a commit is required to build & run correctly without the following one(s). See the 7th point https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-requirements

[JarmouniA]

Single App mode does not support image upgrade.

[maass-hamburg]

Suggested change

	erase-block-size = <DT_SIZE_K(64)>;
	erase-block-size = <DT_SIZE_K(4)>;

should be the smallest supported

[maass-hamburg]

See #97037 (comment)

It should probably also fix the swap modes, meaning we can get rid of the default. But I have to verify this tomorrow on my dev board

[JarmouniA]

@tpambor I switched H750B-DK to swap-using-offset after fixing the erase-block-size (which fixed all swap modes), up to you if you want to do the same here.

[maass-hamburg]

Just do it like in the other PR, but add both variants to the hawkbit sample test.

[tpambor]

Yes, now it boots here also in swap mode. I kept both variants for the hawkbit sample.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud