[RFC] Initial Cortex-A team

[andre-richter]

This is a proposal for creating a Cortex-A team.

This is based on and will close issue #182. Please refrain from approving until I removed the [DRAFT] from the title and every proposed member has his points on the agenda.

@raw-bin, @wizofe and me will be the initial members.

The following work is planned for this team:

Maintain a set of ecosystem crates under the embedded WG

• Write a tool that generates accessors for the ARM System Register XML.
• Move cortex-a to the WG and keep extending/completing it.
  • If feasible, feed the XML accessors into the crate.
  • Add ready-to-use idioms for bare-metal use cases.
    • MMU idioms
    • GIC idioms
    • ...?
• Move register-rs to the WG. CC @phil-opp for sign-off.
• Discuss if something the likes of cortex-m-rt is feasible for cortex-a.

Provide resources for learning

• Move rust-raspi3-tutorial to the WG

Make it possible to build AArch64 kernels / programs on stable.

• Add a rust-std component for aarch64-unknown-none
• Differentiate into further aarch64 targets, e.g. a non-fp version of aarch64-unknown-none, and add them as well.

Stabilization

• 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.

---

@raw-bin and @wizofe, kindly let me know your agenda points and I will edit them into this comment.
I understand your Redox work will most probably be a part of it, but I want to leave it to you guys to describe it.

Once we are set, I will remove the [DRAFT] and open this for members to approve.

@jamesmunns I tend to agree to your thought about having a microprocessor group. However, I think that cortex-a alone is such a complex architecture, it can easily keep the initial three of us busy for years to come.
I would argue that we would need separate teams for PPC, RISC-V and the likes.

[parched]

@andre-richter Something I think would be useful here, is generating rust readers/writers of the system registers from the System Register XML. I've been meaning to do it for a while but haven't had the time.

(Bikeshed) Perhaps "Arm A profile team" may be a better name as I assume you're not just targeting the Cortex brand of CPUs.

[andre-richter]

Good point! Such a tool would be very useful to generate the register definitions that I currently maintain manually for the cortex-a crate.

I will add this point when I update the synopsis.

Regarding the name: your argument applies for the M and R profile as well, but here teams are called cortex- currently. I think we should sync here first. @japaric?

[raw-bin]

Hi @andre-richter, thanks for setting up this proposal!

My terminology may not be very precise, but here are some free form thoughts. I would appreciate guidance in massaging these into requirements for the WG, if deemed appropriate.

So what I think we need is a way to have Rust 'accessor' APIs for architecturally specified Cortex-A v{7,8} (and others if needed) registers that support access at all exception levels thereby supporting writing bare-metal code for any exception level (secure monitors at EL3, hypervisors at EL2 etc). The suggestion made by @parched is perfect for automating the generation of such accessors.

On top of that, I think we need a collection of common Cortex-A bare-metal programming idioms which are common-place in misc bare-metal programs. I mean simple things like identifying the underlying processor type, or the number of processors at the same affinity level. On to incrementally more complex things like 'set me up an N-level page table set to map X bytes from this VA to this PA'.

I think there is a fair set of these idioms that can be expressed in a library that lies one level up from the bare accessor lib. Such an aggregation can help localise brittle code and promote re-use for misc projects.

While I agree that a lot of operating system boot strap code, for example, tends to be very implementation specific, I would argue that having such a collection of idioms should promote a more standardised construction of such software.

From that point on, having bare-metal programs that become consumers of the above would be needed. I would pony up Redox's AArch64 port as one of them where I can envision a lot of stuff from bootstrap, processor bring-up/tear-down via PSCI (another item that could be folded into back-end of the idioms I speak of for things like 'bring up this processor out of reset', or 'get me the set of services supported by secure FW on this system'), page table setup and management etc.

Thoughts ? Thanks.

[raw-bin]

Oh an @parched, apologies for the ambiguous thumbs up. That was for the XML descriptions idea.

[andre-richter]

Thanks Robin. From a simple project plan perspective, I would envision your input to translate to something like this: 1. Write the XML tool 2. Feed outputs into the cortex-a crate for the reg access part. 3. The idioms, in my opinion, should go into the crate as well. Code for common MMU operations like you described. Maybe GIC code as well or at least in another crate. 3. Keep publishing and providing projects that use these libs. Redox, raspi3 tutorials, etc. Cheers, Andre Robin Randhawa <[email protected]> schrieb am Di. 11. Sep. 2018 um 12:28:

…

Oh an @parched <https://github.com/parched>, apologies for the ambiguous thumbs up. That was for the XML descriptions idea. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#207 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD8E1d6jWnCVZnkQ5ULBsvJM2_M8AyVqks5uZ5AzgaJpZM4WgbK2> .

[raw-bin]

Thanks @andre-richter. Yes, that sounds right. Agree with the keeping the idioms in the crate. And yes, GIC related idioms are a good fit too.

How should we proceed from this point on ? I assume there is some process to follow to kind of formalise things ?

[andre-richter]

@raw-bin I updated the initial comment with the proposed content.

I propose to proceed the following way:

1. Get a final ping from @wizofe if he wants something on the agenda, or is happy to work on any of the proposed items and good to go as we are.
2. @parched, do you want to apply as a member of the team, or is occasional review work as you currently do fine for you?
3. Once feedback received for 1+2, I will open for the WG members to vote.
4. If we are accepted, we can officially create the team, and I would start moving the mentioned crates, and instantiate issues for all the items in the first comments to track the same.

[raw-bin]

Sounds good.

I'll ping @wizofe. I understand he's super pre-occupied with his day job for a couple of months but agree that it would be good to know if he has any agenda items.

I am happy to help break things down or detail items. Please let me know as and when you need that.

[posborne]

Good stuff. I've worked with Cortex-A processors a fair amount the past several years doing Linux/Android bringup (U-Boot, OP-TEE, etc.) and will contribute what knowledge I have when relevant.

The proposed team and initial set of projects/goals seem like a good place to focus starting out and it is exciting to hear about the interest in Rust on the Cortex-A metal.

[raw-bin]

Couldn't get a response from @wizofe. Probably best to move along. If there's an update from him we can consider rolling it in as appropriate.

[parched]

@andre-richter

@parched, do you want to apply as a member of the team, or is occasional review work as you currently do fine for you?

I'm potentially interested but I don't think I'll have time for any code contributions for now as I have some other Rust projects I'm working on. I'm happy to participate in reviews and discussions though :).

[andre-richter]

@parched Review duty is fine. Since I understand you also work for ARM, this will be a very helpful to us.

Couldn't get a response from @wizofe. Probably best to move along. If there's an update from him we can consider rolling it in as appropriate.

I removed the draft state, we are open for approvement. CC @rust-embedded/all

[wizofe]

Very exciting news @andre-richter, @raw-bin @posborne and @parched. I apologise for my delay, but indeed as Robin said, the next two months are looking quite difficult for me there's currently a Shenzhen production crisis!

From my side I am very keen on helping with creating and documenting projects that use those libs, both in Redox (which I need to extend what I've done until now) and the Raspberry Pi (that's my working every day platform and where our product and OS is based on!). On that note, I am very happy to maintain and extend Andre's great raspi3-rust-tutorial, if he wants that.

1. Write the XML tool 2. Feed outputs into the cortex-a crate for the reg access part. 3. The idioms, in my opinion, should go into the crate as well. Code for common MMU operations like you described. Maybe GIC code as well or at least in another crate. 3. Keep publishing and providing projects that use these libs. Redox, raspi3 tutorials, etc. Cheers, Andre

This 'XML tool' sounds also something I could do and it's on my skill level; I would be happy to get some more guidance on this and how to approach it.

Looking forward!

Rgrds,

Ioannis

[raw-bin]

I didn't know @parched works for Arm! That makes two of us! :) I'll reach out to him! Between us we should be able to provide any guidance/support from the mothership as needed.

[andre-richter]

We're a bit stalled here. Kindly ask you to make use of your voting rights or propose changes to the RFC.

@rust-embedded/all

[therealprof]

LGTM

[jamesmunns]

LGTM

[phil-opp]

@andre-richter

• Move register-rs to the WG. CC @phil-opp for sign-off.

Fine with me! Let me know if you need me to do anything.

[andre-richter]

We are at 8 approvals. The current WG size is 22. Four more would be needed for majority.

[sekineh]

👍lgtm

[hannobraun]

We have a majority now.

bors r+

This RFC clearly shows that we need #206, or something like it.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[japaric]

@rust-embedded/cortex-a now exists 🎉.

@phil-opp

Fine with me! Let me know if you need me to do anything.

The procedure for moving a crate into the org can be found here.

[andre-richter]

Let me check if I can move it out of there. I'll add a PR for the proposed crates once I'll have some free cycles :)

[phil-opp]

The procedure for moving a crate into the org can be found here.

I filed #227.