dualcore: Basic dual core support.

[richardeoin]

Only the Cortex-M7 core is currently supported upstream

[richardeoin]

bors try

[bors]

try

Merge conflict

[richardeoin]

Ready for review

Note that the parts in CI have been trimmed to only those explicitly listed as supported in the README

[jordens]

Looks good to me. I didn't check it w.r.t. the ref manual though.

With "upstream" support existing only for the M7, do you mean the PAC?
What's the plan with the M4? Do you ultimately want to support that one from within this crate as well?
Do we want to tie into microamp?
I'm happy to have details/bugs sorted out later.

bors r+

[jordens]

Ah. You wanted more reviews I guess. Feel free to have bors merge it when @hargoniX approves.

bors cancel

[jordens]

bors r-
bors d+

[bors]

✌️ richardeoin can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

[bors]

Canceled

[richardeoin]

More eyes is better if possible.

Yes, "upstream" refers to the PAC. M4 support starts there, because it's derived from a different SVD. Eventually it'd be great to try it with microamp - I haven't done that yet though.

[richardeoin]

^^ found in my own review

[richardeoin]

Okay, merging this now. There's no support for the Cortex-M4 core yet, although some feature gates exist for it already. This needs more consideration in the PAC first.

[noppej]

@richardeoin , @jordens ... any more thoughts/plans on supporting the second core on the dual-core devices? If there is a specific body of work to be done or problem to be solved, I'd be willing to help.

[richardeoin]

Hi @noppej ! Other than exporting the correct feature flag from the PAC, in principle there's nothing preventing the HAL from being used on the CM4 core already. The downside of that approach is that you end up with two separate crates (one for each core) and there's nothing to prevent data races between them. The other approach is using something like the microamp crate, which I've not investigated at all.

So here are some areas that would help:

• Exporting that feature flag. Have a look at Minimal requirements for targeting the Cortex-M4 core #62, which does this but is very behind the current master branch. Using the cm4 feature flag doesn't actually matter, except from matching some of the interrupt names with the RM.
• Adding documentation and examples to help new users get started with the CM4 core. That would cover setting the memory regions in memory.x, and whatever needs to be done to the BOOT_CM4 / BOOT_CM4_ADDx bits to make it work.
• Research using microamp, which already supports homogeneous cores. Likely this would result in a separate example crate, which we could link to in the README.

[noppej]

Hi @richardeoin. Thanks for your quick response. A couple of thoughts ...

• Minimal requirements for targeting the Cortex-M4 core #62 is probably a good start, and if we can somehow create two bins in the same crate, with a build.rs script to manage the memory.x file, then it might be sufficient for someone (like me) to build a working app, where the developer manually manages the data races - not really in the spirit of what rust stands for, but it might be enough to build some tests, examples, documentation, etc. That said, it feels like we might be re-inventing the wheel that was started by the microamp team.
• I've spent the last few days looking into microamp and also into rtic. From what I can tell, someone on the rtic made a solid effort at leveraging microamp to provide a framework for safely managing the inter-core apps. There are at least two challenges I can see with this ...
  -- As far as I can tell there hasn't been much activity on the microamp repository these past few months. Not sure what that means.
  -- I also discovered that the rtic team has recently decided to remove all the multi-core work - look at #27

In summary, I think it is probably worth a conversation with someone on the rtic and microamp teams, and shake out where the various parts of a safe multi-core implementation should land. Thoughts?

[richardeoin]

Agreed that it'd be better not to re-invent multi-core build infrastructure here, especially as many of the parts supported by this crate are only single-core. We have a few rtic examples already and it works very well, so more of that would be great.

I'd try asking in the #rust-embedded room, it's usually a good place to ask about rtic especially.

It's probably worth continuing this discussion in a new Issue/PR also, this one is a bit old.

[noppej]

Thanks @richardeoin ... I appreciate the guidance. I will start the conversation in #rust-embedded room, and open a new Issue here as appropriate.