Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cortex-a crate? #1

Open
andre-richter opened this issue Jan 6, 2019 · 9 comments
Open

cortex-a crate? #1

andre-richter opened this issue Jan 6, 2019 · 9 comments

Comments

@andre-richter
Copy link

Hi,

just saw this repo popping up in my recent activity screen when logging in to Github.
Did you check out https://github.com/rust-embedded/cortex-a yet? From your Readme, it sounds like this could be interesting to you?

@stlankes
Copy link
Contributor

stlankes commented Jul 4, 2019

Excuse me, I oversaw this comment. We were a little bit overloaded and do in the meantime other staff. Now, we restart our activities. But your project seems be the better choice. We will look into it. Currently, I think that we switch to your project.

@andre-richter
Copy link
Author

Good to hear :) Our current contributor staff is always notoriously short on time, so feel free to reach out/contribute or even join us in the embedded Working Group.

In the cortex-a group, we also have people from ARM that indicated interest in adding more functionality to the crate in the future.

In the past I was wondering if aarch64 would have been a better crate name given the current content.
But since you registered that one, we could probably revisit that brainstorming sometime in the future. At least currently, cortex-a is only sporting mostly aarch64 specific registers, but plans for the future are to add reference idioms and data structures for the actual processor features, like paging, interrupt management, maybe GIC (RPi 4).

So we could eventually carve out common aarch64 support (common in the sense that it would also work for aarch64-based cortex-m processors) into an aarch64 crate, put only the idioms I just mentioned into the cortex-a crate, and import/reexport from aarch64 what is additionally needed.

But I am getting side-tracked here with bikeshedding for the future...
In summary, always happy if we can make Rust's aarch64 users work together through the WG.

Best,
Andre

@stlankes
Copy link
Contributor

stlankes commented Jul 4, 2019

Sounds great! Yes, the embedded working group seems to be the right place to develop such a crate. At the beginning, I was looking in the WG repository. But I oversaw or misunderstood the cortex-a crate and start a new one.

@stlankes
Copy link
Contributor

stlankes commented Aug 13, 2020

@andre-richter Ah, I forgot this issue. We reactivate our ARM activities and start writing paging support. Should we also integrate this in the crate cortex-a?

@andre-richter
Copy link
Author

Hi Stefan,

here is the current situation and some thoughts I have on all this:
I am effectively idle as a cortex-a maintainer by now. My rare spare-time will be dedicated fully to the RPi OS tutorials. Apart from adding a processor register here or there to cortex-a, there won't be much activity from me in the future. Also, I am/was the only active maintainer ever since.

If you guys are starting to ramp up on this now, and if you are open to it, please give it a thought to join the embedded WG and take over this project. Then the decisions are mostly all yours.

If you want to go down that road, let me re-iterate that I became increasingly dissatisfied with the name cortex-a. The crate in its current state only covers abstractions of the AArch64 part of the ARMv8 architecture. There is no real tie to specific a processor instance.

If you'll take over the lead, we could move all the cortex-a stuff into the aarch64 crate that you already maintain on crates.io.
We would only need to move the corresponding GitHub repo into the embedded-wg namespace.
To the cortex-a repo, we can add a big disclaimer that the stuff has moved.

Regarding features like paging or IRQ handling: I've spent some thoughts on it in the past, but no real conclusions. I think for such a crate, it will be important to find the right cut between abstractions and implementation.
Adding support for Page and Table descriptors makes sense.
Maybe an interface (trait) for manipulating page table entries using the provided data types can be useful.

But most of the implementation should be left to the user I think. There's just so many ways to realize a paging implementation.

Let me know what you think.
Thanks,
Andre

@stlankes
Copy link
Contributor

Hello Andre,

sounds for me like a good idea. I am not sure, how many time we have to maintain the crate. But we need something in this direction. I am not able to promise to much. But we will do our best.

Cheers

Stefan

@CraftSpider
Copy link
Contributor

I was just looking at this crate as part of playing around with the idea of adding support for ARMv8 to the Rust OS-dev toolchain. I would be interested in seeing this crate join the Rust embedded (Or Rust OS) group, and possibly merging with cortex-a, as I feel it would get love in either place.

For now, I will probably look at opening some pull requests to add functionality to this crate.

@stlankes
Copy link
Contributor

Yes, you are right. I will talk to a colleague to accelerate the process.

@jounathaen
Copy link
Member

Just to add my 5 cent to this discussion: I see this crate fulfilling a very similar role to the x86_64 crate. I think some kind of convergence between the crates would be very desirable. So I think it would be best to make it part of the rust-osdev group. However, the x86_64 crate is way more mature than this one, and I don't see our group putting in sufficient development effort to get to a similar state, at least not in the near to mid-future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants