STM32: Add support for STM32H7 dual core

[erwango]

Enable support of Zephyr on STM32H747I-DISCO board.
This board is dual core and this work enable running zephyr in both cores.

For now, the minimum work is done to enable dual core operation by sharing the resources.
No communication is enabled between cores except use of hardware semaphore for synchronization
and critical resources access.

Depends on zephyrproject-rtos/hal_stm32#15

[erwango]

@arnop2

[zephyrbot]

All checks are passing now.

Review history of this comment for details about previous failed status.
Note that some checks might have not completed yet.

[erwango]

stm32h747i_disco_m4 doesn't enable CONFIG_SERIAL.

How come samples/nfc/nfc_hello (filters on CONFIG_SERIAL) and samples/mpu/mpu_test (filters on CONFIG_SERIAL_SUPPORT_INTERRUPT) are compiled on that target ?

EDIT: While target does not enable CONFIG_SERIAL, is it actually enabled in samples .config file when building (then build fails because no uart device is enabled).

EDIT: Adding following in target .yaml, but notsure it's the right solution:

testing:
  ignore_tags:
    - mpu
    - nfc

[dbkinder]

some recommended doc changes

[dbkinder]

Suggested change

	and high-speed connectivity features. Important board features include:
	and high-speed connectivity features.

[erwango]

Done

[dbkinder]

Suggested change

	It embeds STM32H747XI SoC: a high-performance and DSP with DP-FPU, Arm Cortex-M7 + Cortex-M4 MCU,
	The board includes an STM32H747XI SoC with a high-performance DSP, DP-FPU, Arm Cortex-M7 + Cortex-M4 MCU,

[erwango]

Done

[dbkinder]

Suggested change

	large set of peripherals, SMPS, MIPI-DSI.
	large set of peripherals, SMPS, and MIPI-DSI.

[erwango]

Done

[dbkinder]

Suggested change

	``boards/arm/stm32h747i_disco/stm32h747i_disco_defconfig_m7``
	``boards/arm/stm32h747i_disco/stm32h747i_disco_defconfig_m7`` and

[erwango]

Done

[dbkinder]

Not sure what the right fix is here, but should this be ST-LINK/Virtual

[erwango]

Should be ST-LINK/V3.0. Txs

[dbkinder]

Suggested change

	tree before compilation. it is up to the user to ensure same peripheral is not
	tree before compilation. The user must ensure peripherals are not

[erwango]

Done

[dbkinder]

Suggested change

	assigned to both cores at the same time
	assigned to both cores at the same time.

[erwango]

Done

[dbkinder]

I'd start a new paragraph here by adding a blank line before By default:

[erwango]

Done

[arnopo]

if (IS_ENABLED(CONFIG_STM32H7_BOOT_CM4_CM7)) ?

[erwango]

This was my first try, but then, I need to define stm32h7_m4_boot_stop also when CONFIG_STM32H7_BOOT_CM4_CM7 is not enabled, so I preferred to keep it this way

[arnopo]

ok for me

[arnopo]

As peripherals are shared between cortex contexts i would set configs to n by default for peripheral to ensure that is not used by M4 and M7

[erwango]

Problem is that I need one UART defined on one side to enable serial testing (and things that require serial).

But, I agree with your concern and this is actually why I preferred to put devices activation in this file common to both cores rather than in _m{4.7}_defconfig files.
What I can add is the following to make the intention clearer (won't add nothing in term of "mechanical" check though :

config UART_1
	default y if BOARD_STM32H747I_DISCO_M7
	default n if BOARD_STM32H747I_DISCO_M4

And the same should be done for each other peripheral device.

[arnopo]

ok for me

[arnopo]

ok for me

[arnopo]

ok for me

[dbkinder]

doc changes LGTM, thanks!

[ioannisg]

Weird that Board options select Cortex cores.
could this be done in the SOC level instead?

[erwango]

This was my initial attempt, but at the end, this only introduces and intermediate SOC_STM32H747XX_M7, that selects CPU_CORTEX_M7.
When electing the cortex at this level, I can remove an intermediate step which makes things clearer. Still, we're able to do cortex specific settings in soc/arm/st_stm32/stm32h7/Kconfig.soc

[ioannisg]

same here

[ioannisg]

Looks good, I only notice that CPU core options are selected at the board level.
That's not what we have done in the other multi-core SOCs (but I might be wrong).

I think it would be cleaner, if at the SOC level we have SOC options for the two cores, i.e. xxx_M4 and xxx_M7 and then we have two different BOARDs, anyways, because we need to build two different images.

[erwango]

@ioannisg

I think it would be cleaner, if at the SOC level we have SOC options for the two cores, i.e. xxx_M4 and xxx_M7

As answered above, this would introduce an intermediate symbol with no added value.
And I don't see limitation or risk with the current method

we have two different BOARDs, anyways, because we need to build two different images.

I understand you propose to introduce 2 boards directories.
I don't think this is the good direction: even if we have 2 targets to build, they share a lot of common configuration: boot type, clocks settings, boards support package, pinmux ..
Having 2 targets in the same board directory allow to share some Kconfig file which force configuration coherency.
Also, even if we miss a good tool to handle peripheral assignment, having all information at one place eases manual check that resources are assigned to only one core at the same time.

[ioannisg]

@erwango, got me a bit wrong, here, we shoudln't have 2 BOARD directories, we should have two BOARD .defconfigs (we do actually), as we do for other dual-cores.

So, I am only worried about consistency here. Check the 2 dual-core NXP lpc platforms; they have two SOC symbols defined, for each core, and the two BOARD symbols depend on either SOC Kconfig. I think the ARM Musca_x does the same. We should have one way to do this for any multi-core platform....

[erwango]

@ioannisg

@erwango, got me a bit wrong, here, we shoudln't have 2 BOARD directories, we should have two BOARD .defconfigs (we do actually), as we do for other dual-cores.

Ok. And we have 2 _defconfig, but only one .defconfig. This is the same than lpx as I can check. So we're aligned here.

So, I am only worried about consistency here. Check the 2 dual-core NXP lpc platforms; they have two SOC symbols defined, for each core, and the two BOARD symbols depend on either SOC Kconfig. I think the ARM Musca_x does the same. We should have one way to do this for any multi-core platform.

From what I see, ARM musca defines 2 boards, so does cypress_062_wifi_bt dual core board, let put these aside.
I see your point about consistency. But then, looking at lpc5Xxxx implementations, I don't particularly agree on the way things are done (specially in soc files Kconfig.defconfig.lpcxxxx_mx some kind of peripheral assignment is done, which limits the flexibility at board level and performs driver deactivation at soc level which seems error prone for an end user).
Anyway, I'm keeping your suggestion in mind and I'll see if solves issues when we'll have to add mode resources or mode boards/soc derivates based on this porting.

[galak]

From what I see, ARM musca defines 2 boards, so does cypress_062_wifi_bt dual core board, let put these aside.
I see your point about consistency. But then, looking at lpc5Xxxx implementations, I don't particularly agree on the way things are done (specially in soc files Kconfig.defconfig.lpcxxxx_mx some kind of peripheral assignment is done, which limits the flexibility at board level and performs driver deactivation at soc level which seems error prone for an end user).
Anyway, I'm keeping your suggestion in mind and I'll see if solves issues when we'll have to add mode resources or mode boards/soc derivates based on this porting.

Musca is 2 different actual boards. The cypress_062_wifi_bt should be reworked but we've never gotten around to it.