STM32H7 dual core devices

[chris-durand]

Add support for STM32 dual-core devices which contain both a Cortex-M7 and a Cortex-M4 core. Contrary to the RP2040 dual-cores these STM32 devices have heterogeneous cores which require individual application programs.

The blink example is working with the Cortex-M7 core blinking two LEDs and the Cortex-M4 application controlling the other.
With the default option byte settings both cores boot simultaneously. On boot the Cortex-M7 core initializes the clocks. The M4 core waits until the initialization is completed and subsequently starts executing its application.

Correct initialization of memories is not implemented yet. In the current state the CM4 core will zero out all SRAMs that are already in use by the other core. The only reason the blink example runs is that all data from the CM7 is kept in DTCM inaccessible to the CM4 core.

The boot process implemented here is much simpler to what ST recommends.
ST does the following arcane procedure:

1. Unassign all D2 domain peripherals from Cortex-M7
2. Activate hardware semaphore 0 event notification on the Cortex-M4
3. Enable deep-sleep on Cortex-M4
4. Send Cortex-M4 core to CSTOP state with WFE instruction
5. The D2 clock domain will enter DSTOP state with the CM4 stopped and no D2 peripherals assigned to the running core
6. Wait for the D2 domain clocks to be disabled on the Cortex-M7
7. Initialize platform on Cortex-M7
8. Lock and unlock hardware semaphore 0 on Cortex-M7 to wake up the M4 core and the D2 clock domain
9. Clear hardware semaphore interrupt flag on Cortex-M4 and continue boot

The downside of ST's tedious method would be that D2 clock domain SRAMs are not powered while the Cortex-M7 startup code is running and thus, can't be initialized by the Cortex-M7 before the other core is booted.

I have decided to simplify the whole procedure by not sending the Cortex-M4 to sleep and to just busy-wait on that core until the system is initialized. This is implemented with the hardware semaphore as well. The Cortex-M4 delays boot until the semaphore is locked. The other core will lock and unlock it after initialization is done and the Cortex-M4 continues to boot.

• Update device files
• Enable H7 dual core devices
• Correctly adapt memory maps in STM32 core module for each core
  • Use one flash bank for each core's application
  • Place Cortex-M4 stack in D2 domain SRAM1
  • Correct initialization of memories (only do it once from one core)
  • Assign memories to cores via lbuild options
  • Shared SRAM for communication between cores
• Fix device files for size "g" devices
• Examples
  • blink
  • more
• make scons debug work for the second core

[salkinium]

Just so this isn't lost: In an IRL discussion we had the idea to build a separate static library that would deal with the communication and place its memory content into D3 SRAM in both linkerscripts. This would allow arbitrary communication mechanisms that are always synchronized.