Explore a wishlist for MCU vendors interested in Rust

[i509VCB]

I've discussing with some vendors who are interested in Rust support (no names to protect the innocent). Some of the questions they have are around what they could provide to make this support easier for us or things that the vendors can do themselves.

I propose we have a discussion on a sort of "wishlist" that vendors can reference to make supporting Rust on their parts easier. Some of the topics here include:

• SVDs/register definitions
  • One vendor has asked how should they improve the SVDs to make PACs easier to create (and require a lot less patching).
  • Would be good to encourage vendors to test their SVDs with svd2rust and chiptool.
  • Topics around consistency across families and correctness.
    • Ideally 0 patching needed to match the datasheet
• Ability to flash with probe-rs, or at minimum something open source like openocd or pyocd
• Chip metadata
  • The metapac crates are a great example of the things you can do with some well made machine processable chip metadata (pin muxing, peripherals, clock info).
  • I think it would valuable to propose to vendors to invest in publicly accessible chip metadata and show them the business case for making such metadata available (even its uses outside of Rust).

Other topics relating to vendors interested in Rust and what they could do would also be valuable, even if not listed.

I am going to propose to add this to an upcoming agenda for a WG meeting.

[burrbull]

Saying about SVD the main question is improving SVD specification itself to:

• share xml parts between chips. The simplest way I see is to allow file path syntax in derivedFrom.
• support non-ARM chips.

Patching question I would split on 3 steps like I've done in stm32-rs:

• Fixing bugs and inconsistencies between register names
• Adding missing information (like field enums, etc.). Do not go ST auto-generating way. Give enum variant meaningful name.
• Wide using of arrays and clusters to de-duplicate generated code (require correct sorting of peripherals)

@bugadani I think ESP guys also have what to say.

P.S. Avoid using comments in SVD as very hard to parse. Put license in special licenseText tag.
Check on errors with svdconv before publish.

[bugadani]

let's cc @MabezDev here

[BartMassey]

Provide Rust source crates equivalent to what is being provided in C/C++ SDKs. (Alternatively, just provide Rust crates with FFI C APIs to avoid the duplication.) Failing providing Rust, ensure that clear complete docs exist for everything proprietary so that the community can fill in.

Wrapping C/C++ is doable but no fun; AI-ing C/C++ into Rust is error prone and fraught with social and legal peril right now.

[thejpster]

I'd go further and ask the silicon vendors to just publish the PACs themselves, whether through svd2rust or something else.

And given svd2rust (I think) still has the reference-to-MMIO unsoundness, I might actually prefer something else.

For me, probe-rs support is the most important, because flash algorithms are weird and not well documented.

[BartMassey]

Yeah, as long as we're wish-listing, adequately documenting the flash algorithm and debug interface for the chip rather than relying on obscure C tools and code would be fantastic, notwithstanding if probe-rs support is added. I have had to give up on some RISC-V chips that are otherwise nice after spending substantial time trying to figure this part out and failing.

Maybe a bit out-of-scope, but providing permalinks to latest chip documentation, ideally including to internal references, would be fantastic. Folks widely use chip doc links in their Rustdoc, tutorials and other documentation.

[wt]

This seems like a good thing to discuss.

[inferiorhumanorgans]

I'd go further and ask the silicon vendors to just publish the PACs themselves, whether through svd2rust or something else.

And given svd2rust (I think) still has the reference-to-MMIO unsoundness, I might actually prefer something else.

For me, probe-rs support is the most important, because flash algorithms are weird and not well documented.

I think that relying on vendors to publish a PAC ties Rust support to a specific implementation. Cleaning up the source materials makes actually generating a PAC quite simple and leaves room to iterate.

[jonathanpallant]

I think that relying on vendors to publish a PAC ties Rust support to a specific implementation

That's fair. A good SVD allows both svd2rust and chiptool and potentially also svd2derive-mmio approaches to be done.

[BartMassey]

It doesn't look like RISC-V vendors will be willing to provide SVDs as they view them as an ARM thing? They often provide a Device Tree, which doesn't usually contain enough information to generate a PAC as far as I can tell. Maybe that can be fixed?

[diondokter]

I've been building out a metapac for NXP.

SVDs are great and I'll take them. But they're limited in that they describe the peripherals of just one device. They also don't carry pin data.
So, if a metapac is desired (which IMO it is for any manufacturer that shares IP across device families), we should ask for metadata too. The exact format doesn't really matter, we can write tooling that ingests it, as long as all the info is there.

This is per peripheral:

• IP name/version
• Associated pins and alternate modes
• DMA info

Per device/package:

• List of peripherals with addresses
• Description of memory regions

I'm probably forgetting something, but this is the gist at least. More info is more better.

[felipebalbi]

The exact format doesn't really matter

I'll disagree with this statement. I think the exact format matters as it's the difference between writing one generic tool or per-vendor, or even per-family, tools for the ingestion process.

This is per peripheral:

• IP name/version
• Associated pins and alternate modes
• DMA info

Right, I think what we really need is a per-IP description. We also need manufacturers to have some form of semver tracking for the IPs themselves (at least Synopsys has been pretty good at this for the designware core IPs). It's a long shot, of course, but it's what would make our lives (and, frankly their SDK teams lives) much easier.

Per device/package:

• List of peripherals with addresses
• Description of memory regions

I'd add:

• List of pins and functions
• List of interrupts and routing

[diondokter]

I'll disagree with this statement. I think the exact format matters as it's the difference between writing one generic tool or per-vendor, or even per-family, tools for the ingestion process.

Well, yeah, but there's no way to get them all on the same format.
And also there's only a handful of vendors, so in the end not such a big problem IMO

[inferiorhumanorgans]

This is per peripheral:

* IP name/version

* Associated pins and alternate modes

* DMA info

Also any clock gating info.

[inferiorhumanorgans]

Seems a bit basic but: make sure there's information for all of the cores, if Cortex-M then a viable SVD for each core, etc.

[wt]

How should we ask that the core (like cortex-m33) peripherals are handled. Should those be included in the SVD for the board? If so, should we ask for standard naming?

If not, should we ask that a common SVD for each core type (like cortex-m33) that is somehow referenced by the SVD?

Should we ask for extensions to the SVD spec to make it more composable?

Should we ask for the source code to flash algos?

Should we ask for anything around ISP flashing (vs debug probe flashing)?