Meeting 2025-04-08

[adamgreig]

This is the agenda for the next meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• Nominated issues
• IRC/Matrix logs

[jonathanpallant]

Should we push armv8r-none-eabihf to Tier 2?

The armv8r-none-eabihf target supports Armv8-R Architecture processors, like the Cortex-R52. QEMU 9 can emulate the MPS3-AN536 machine, which is an FPGA board containing two Cortex-R52 processors. You can also buy SoCs from both Renesas and NXP that use Cortex-R52 cores. The https://github.com/rust-embedded/cortex-ar project currently has to use nightly to test the Armv8-R support, and it would be great to have the support in Tier 2 so we could use stable Rust.

https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-2-target-policy says:

A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

It is of value to people who want to play with Armv8-R architecture in QEMU, or program one of a number of upcoming SoCs that use that architecture.

A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details.

I propose that the EDWG Arm Team would be the maintainers, although https://doc.rust-lang.org/nightly/rustc/platform-support/armv8r-none-eabihf.html says it is currently Chris Copeland. If Arm wants to contribute here, they can join the team.

The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

I find it hard to imagine something that a Rust project contributor might break in armv8r-none-eabihf but that doesn't also break armv7r-none-eabihf (which is Tier 2). So the additional burden seems low.

The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target.

https://doc.rust-lang.org/nightly/rustc/platform-support/armv8r-none-eabihf.html exists already.

The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

Unclear where this is documented, but it doesn't seem to be a problem given that only two processors (Cortex-R52 and Cortex-R52+) implement the architecture currently.

If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.

It's an updated revision of the Architecture, and that warrants a new target (see the M-Profile targets).

Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.

It does not, AFAIK.

The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team.

It does not, AFAIK.

If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C".

It does.

The target must build reliably in CI

It does in Ferrocene.

The approving teams may additionally require that a subset of tests pass in CI,

They do in Ferrocene.

Building the target in CI must not take substantially longer than the current slowest target in CI

It should be the same as armv7r-none-eabihf, and being no_std, it doesn't take long.

Tier 2 targets should, if at all possible, support cross-compiling.

It's a cross-compiled target.

must not impose any onerous license requirements on any members of the Rust project

Pretty sure it is no different to armv7r-none-eabihf in this regard.

Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target.

Pretty sure it is no different to armv7r-none-eabihf in this regard.

The target maintainers should regularly run the testsuite for the target

TIL!

[BartMassey]

Seems like a no-brainer to me. Absolutely should do. Thanks to the ARM team for being willing to maintain it, to the small extent that maintenance should be needed.

[jonathanpallant]

I talked to the existing maintainer, Chris, and he'd like to remain listed as an individual but also expressed interest in joining the team. I've invited him along to this meeting, but it's short notice.

[jonathanpallant]

New Arm Team member: #831

[jamesmunns]

@jonathanpallant and I (totally separately!) are making appearances this week, and are looking for "where has embedded rust been shipped?"

I have a running list here: https://bsky.app/profile/did:plc:rqm4qgf6jdmb35mxatuzi6cq/post/3lmajebv2n22u, if anyone is aware of other good public cases, happy to have them!

I plan to make a blog post afterwards to save others the trouble from hunting for presentations, press items, etc.

[jamesmunns]

Update: posted as https://onevariable.com/blog/embedded-rust-production/