✨ add smp dual-core support

[stnolting]

Add SMP dual-core option.

• add rtl infrastructure (two CPU instances + caches + bus arbiter)
• adjust crt0 boot code
• add HAL boot functions for secondary core
• add dual-core example program
• add dual-core test to CI
• add dual-core openOCD configuration
• test dual-core debugging
• update documentation
• update bootloader (image)

🧪 Note that the dual-core configuration is still experimental.

[NikLeberg]

I left some small remarks. The biggest issue I see is with the L1 data caches. I think we should disable them automatically (and emit a warning) even if the user enabled them.

[NikLeberg]

If my understanding of this is correct, then we aren't really limited by having only a single reservation set. The hardware doesn't care. We just have to write correct software for it. The only thing that I think might happen is, if both cores try to atomically change anything via lr/sc, they may end up in livelock as they reset the reservation for each other.
But if we design the spinlock with exponential (or random) backoff (on lock failure) then I think we can have more than one spinlock, can't we?

[stnolting]

I also racked my brains about that... 😅
I've tried to use two individual spinlock variables based on the same LR/SC primitives and ended up in a livelock.

But if we design the spinlock with exponential (or random) backoff (on lock failure)

How would you do that? 🤔

[stnolting]

@NikLeberg Thank you so much for your feedback!

The current design works - at least for a simple dual-core demo program. However, some things are not really efficient and quite hard to handle for a user. But I think this is fine for a first version.

Later, we should perhaps add a special module to avoid the problems (mentioned above). The RP2040 provides a cool block that is used for inter-cpu communication. It provides some nice features:

• hardware spinlocks
• FIFOs for passing messages from one CPU to another

Source: RP2040 data sheet

The rp2040 provides interrupts for the communication FIFOs. I think that is not necessary as we have the software interrupts (and we are running out of interrupt channels anyway).