soc: stm32: incorrect FLASH_BASE_ADDRESS for apps linked in ext Q/OSPI Flash

[JarmouniA]

Describe the bug

On STM32 boards, CONFIG_FLASH_BASE_ADDRESS defaults to $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_FLASH)), this used to be fine for zephyr,flash taking both internal and external Flash nodes.

But following the changes in e35ac8f and 14c1b4a to how external Q/OSPI Flash nodes are declared in DT for boards with STM32 SoCs, CONFIG_FLASH_BASE_ADDRESS now gets 0 when the app is placed in external Q/OSPI Flash (instead of 0x90000000 in the case of STM32H7 for ex.) because the actual external Flash memory address in no longer put in the Flash device node

zephyr/boards/st/stm32h750b_dk/stm32h750b_dk.dts

Line 192 in 0b1cff2

reg = <0>;

, and it is instead only available at the controller level

zephyr/dts/arm/st/h7/stm32h7.dtsi

Line 1077 in 0b1cff2

reg = <0x52005000 0x1000>, <0x90000000 DT_SIZE_M(256)>;

This causes apps, built to be chainloaded with MCUboot from external Q/OSPI Flash, to be linked at the wrong address (0).

Regression

• This is a regression.

Steps to reproduce

1. checkout https://github.com/JarmouniA/zephyr_dev/tree/h750b_dk_ext_flash_app
2. west update

west build -p always -b stm32h750b_dk samples/sysbuild/with_mcuboot --sysbuild

4. go to build/with_mcuboot/zephyr/include/generated/zephyr/autoconf.h and observe that CONFIG_FLASH_BASE_ADDRESS is equal to 0x0
5. west flash
   observe that the download address for zephyr.signed.hex is 0x0

Relevant log output

*** Booting MCUboot v2.1.0-rc1-389-g4eba8087fa60 ***
*** Using Zephyr OS build v4.2.0-rc3-11-g0b1cff200fc4 ***
E: Unable to find bootable image

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

• Ubuntu
• Zephyr SDK 0.17
• Zephyr 4.2.0-rc3

Additional Context

A fix is available in #93089.

[erwango]

@danieldegrasse FYI