Form a Cortex-A team?

[japaric]

We have a Cortex-M team focused on bare metal (no_std) development for
Cortex-M devices and an Embedded Linux team focused on development for embedded
Linux devices (this includes Cortex-A devices, MIPS routers, etc.).

Should we make a Cortex-A team focused on bare metal (no_std) development for
Cortex-A processors? This team would be involved in improving the developer
experience in this area, collecting or writing resources on the topic, and
maintaining and developing widely used crates.

In this space I know of these projects:

• rust-raspi3-tutorial
• The cortex-a crate.
• Redox port to AArch64

Opportunities I see:

• Develop core crates for bare metal Cortex-A development. cortex-a would be
  in this group, and perhaps it makes sense to have some cortex-m-rt like
  crate (see also embedonomicon) to boot a RPi 3 or QEMU? What else could go
  here? It should not be board specific (e.g. not RPi specific).

• Make it possible to build AArch64 kernels / programs on stable. The
  aarch64-unknown-none target would help here but a pre-compiled rust-std
  component would also be needed to avoid depending on Xargo / cargo-xbuild.
  What compilation target does the AArch64 port of Redox use?

• Push for a stable core::arch::arm module (see Stable assembly operations #63) to make the cortex-a
  crate (see its asm module) work on stable w/o depending on GCC.

Who would be interested in forming part of such team?

cc @andre-richter @wizofe and I believe there was another person interested but
I forgot their name :-(

cc @Amanieu? I know you maintain general purpose no_std crates and iirc you
work, or have done work, with Cortex-A processors (though it may have been
no_std programs on top of Linux?)

[wizofe]

Help is here! I am definitely more than happy to work on that 👍 (and thanks for the invite)!

[jamesmunns]

👍 to this, we might also want to CC @SergioBenitez, as he has taught a class on this at Stanford, and might be interested or able to point us to other people in this space.

I had 2-3 people asking me about this at RustConf this past weekend.

[jamesmunns]

We also may want to consider either renaming this to a "microprocessor" team, or consider some other arches like PPC, which are used in a bare metal fashion for things like control systems, satellites, etc as well.

That being said, I have seen the most public interest in cortex-a bare metal so far.

Sorry to steal your line, sir. But I love it when a plan comes together.

A-Team

[andre-richter]

I'm glad to see interest in this topic.

The past couple of months I already put effort into laying the groundwork for making Rust on AArch64 an enjoyable and seamless experience. I'm most happy that register-rs has landed (thanks again to the nice collaboration with the tock team!), which provides a unified interface for both MMIO and CPU registers. It features the same API for both resources. cortex-a already leverages register-rs (btw its not cortex-a specific, feel free to pick it up!).

Also, with aarch64-unknown-none, the first aarch64 bare-metal target has landed upstream.

Finally, rust-raspi3-tutorial is basically the showcase that presents all of these resources coming together, while adhering to the embedonomicon for writing the boot code.

If people think it helps with regards to visibility or promotion, I'm open to move all this stuff to the WG. I put register-rs into @phil-opp 's OSDEV group recently, but we can nicely ask him if he would support moving it to a "more official" place if people deem it useful :)

In the past I also tried to write a cortex-a-rt, but soon abandoned the idea. I found that initialization code for kernels differs just too much between each other. Once you go multi-core, there's usually lots of custom assembly involved already in the earliest stages of booting. Even the target architecture can be a difficult disussion already, as has been shown here.

[raw-bin]

Hi.

A focused group on Cortex-A and Rust would be a very good thing! (Thanks @japaric for the heads up).

I'm with Arm working on open source system software for safety critical domains and wanted to share some thoughts here.

Within the Arm safety critical ecosystem, there is growing interest in enabling Cortex-A Armv8 bare-metal programming with Rust. The primary use-cases are Secure-EL3 resident applications (secure monitors, Trusted bare-metal 'applets', Trusted Firmware) as well as more traditional boot loader class software (non-secure EL1 resident). There's a similar theme for Cortex-M.

See Trusted Firmware for Cortex-A and for Cortex-M for pertinent examples of the kind of software that could be fortified by Rust.

Agree with @andre-richter about kernel init code being different between kernels - often needlessly so IMO. I'm on the lookout for ways to prevent needless duplication. Towards that aim: I'm porting Redox OS to Armv8, specifically the 64-bit AArch64 execution state. See here for a slightly dated overview. I hope to make the Redox AArch64 specific code a comprehensive and re-purposable example of typical Armv8 EL1 -> EL0 initialisation and run-time code written in Rust to the extent permissible. I think that would be an interesting alignment/discussion point for a Cortex-A Rust focused group.

(Some background info about the port which may be of interest: At work I'm exploring overlaps between microkernel designs and upcoming Arm architectural extensions. I'd like Rust to be the foundation for this exploration. Rather than do a microkernel from scratch I decided to port Redox instead. I'm initially targeting a virtual Armv8 platform (qemu-system-aarch64) for the core kernel bring-up. I've made a fair bit of progress and at present I see stirrings from user-space which is exciting! @wizofe is an RSoC assignee who's shadowing me and is tasked with bringing up my core port on the Hikey960 board. He's also super-keen to help! Oh and since @andre-richter mentioned aarch64-unknown-none: I have a WIP support for the aarch64-unknown-redox triplet to rustc+llvm and binutils+GCC).

I had no idea about register-rs! I wrote my own Armv8 system control register access routines for Redox. I will look to see if I can revector to this crate eventually.

At some point I'd like to 'port' @phil-opp's excellent x86_64 Rust kernel blog to AArch64 - something that the Redox core work should help with. That would be another tiny step to prevent redundant re-implementation of common OS design idioms.

Anyway, I think I should be able to help provide Cortex-A architecture insights and channels to the mothership as and when needed! Please advise on next steps. Cheers.

[japaric]

It's great to see there's lots of interest.

To create a new team you'll need to make PR adding the ilst of team members to the README. This PR will also be a proposal for the /all team to vote on so it must also include a rough plan of what you want to accomplish in the short and medium term, for example: getting AArch64 no_std programs to build on stable (see built-in targets and rust-std components); creating or moving existing core crates (e.g. cortex-a listed above) or resources like tutorials into the organization; etc.

You can use proposal #199 as an example / reference.

[raw-bin]

Hi.
Thanks for the info and the pointer to the reference PR. I'll follow up on this.

[andre-richter]

Closed by #207