-
Notifications
You must be signed in to change notification settings - Fork 197
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
[RFC] supporting other architectures #203
Comments
I'm interested in having RTFM for RISC-V, however I need to understand possible RISC-V-related limitations and how to deal with them (if possible).
P.S. I'm not quite familiar with RTFM, so I need to study it first in detail. |
I need to view @korken89's presentation on RTFM before I could meaningfully contribute a port, but I am very interested and supportive of this proposal. This would also be a good opportunity to flesh out what features are feasible to support on archs more constrained than |
@Disasm I have a prototype implementation that targets the HiFive1 board here. The prototype implements the core API plus the
Even if you have zero IRQs, you can use the (machine) software (MSI) / timer (MTI) interrupt to implement (software) tasks.
But you can individually mask interrupts (MSIE, MTIE, etc.); it's possible to implement some form of prioritization (and critical sections) using interrupt masking.
(I have one of those K210 chips; too bad my "development" board has no on-board debugger (and I have no JTAG probe around) so I can't actually do any actual development on it ...)
We could state that some privileged parts are required to use RTFM on RISCV. If the softcore has zero support for interrupts / preemption then we can't run RTFM on it. |
@japaric Thanks for making the prototype!
I use BusBlaster based on FTDI chip, but I think that any JTAG adapter for FPGA would work.
They are standard, but due to their device-dependent addressing I have no idea how to pass them to the RTFM implementation. Of cause, we could tie |
As part of the prototype I wrote a With this approach any crate can use the There are other ways to pass device specific information to the RTFM runtime though. The Cortex-M port uses a |
I think this is a great idea! |
This proposal has been well received so I'm going to FCP it with disposition to merge it. We can start right away with the refactor and take our time to roll out the org. (One extra thing I'd like to do is create an rfcs repo and archive all these RFCs as proper markdown files). |
OK for me |
🎉 This RFC has been formally approved. The refactor part is in PR #205. |
205: rtfm-syntax refactor + heterogeneous multi-core support r=japaric a=japaric this PR implements RFCs #178, #198, #199, #200, #201, #203 (only the refactor part), #204, #207, #211 and #212. most cfail tests have been removed because the test suite of `rtfm-syntax` already tests what was being tested here. The `rtfm-syntax` crate also has tests for the analysis pass which we didn't have here -- that test suite contains a regression test for #183. the remaining cfail tests have been upgraded into UI test so we can more thoroughly check / test the error message presented to the end user. the cpass tests have been converted into plain examples EDIT: I forgot, there are some examples of the multi-core API for the LPC541xx in [this repository](https://github.com/japaric/lpcxpresso54114) people that would like to try out this API but have no hardware can try out the x86_64 [Linux port] which also has multi-core support. [Linux port]: https://github.com/japaric/linux-rtfm closes #178 #198 #199 #200 #201 #203 #204 #207 #211 #212 closes #163 cc #209 (documents how to deal with errors) Co-authored-by: Jorge Aparicio <jorge@japaric.io>
205: rtfm-syntax refactor + heterogeneous multi-core support r=japaric a=japaric this PR implements RFCs #178, #198, #199, #200, #201, #203 (only the refactor part), #204, #207, #211 and #212. most cfail tests have been removed because the test suite of `rtfm-syntax` already tests what was being tested here. The `rtfm-syntax` crate also has tests for the analysis pass which we didn't have here -- that test suite contains a regression test for #183. the remaining cfail tests have been upgraded into UI test so we can more thoroughly check / test the error message presented to the end user. the cpass tests have been converted into plain examples EDIT: I forgot, there are some examples of the multi-core API for the LPC541xx in [this repository](https://github.com/japaric/lpcxpresso54114) people that would like to try out this API but have no hardware can try out the x86_64 [Linux port] which also has multi-core support. [Linux port]: https://github.com/japaric/linux-rtfm closes #178 #198 #199 #200 #201 #203 #204 #207 #211 #212 closes #163 cc #209 (documents how to deal with errors) Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Done in PR #205 |
203: Update to Syn 1.0 r=korken89 a=dtolnay Release notes: https://github.com/dtolnay/syn/releases/tag/1.0.0 Co-authored-by: David Tolnay <dtolnay@gmail.com>
Current state
cortex-m-rtfm
is the main port of the RTFM framework. There are two outdatedports of RTFM for MSP430 and RISCV and two experimental Cortex-R and Linux
ports. None of these ports shares code with one another so they have diverged or
stalled since their inception.
The
cortex-m-rtfm
port is under @japaric's GitHub account and currently has 3people maintaining it.
Proposal
This RFC proposes refactoring out the RTFM syntax (meta-language) and analysis
pass that currently live in
cortex-m-rtfm
into a crate that can be used toeasily implement ports for different architectures.
Rationale
We want to make RTFM available on as many architectures as possible with minimal
maintenance effort and with as similar APIs / syntax as possible.
Detailed design
This RFC proposes the following crate hierarchy:
rtfm-core
This crate will only contain the
Mutex
trait and theExclusive
newtype andit's meant to be used to implement generic library code.
rtfm-syntax
This crate will contain the parser of the
#[app]
and the analysis pass (e.g.priority ceiling analysis) of the RTFM specification.
The main function in this crate is the
parse
function which parse the input ofthe
#[app]
attribute.To accommodate the different capabilities of the many RTFM ports this function
takes a
Settings
struct that indicates which extensions the port implements.$ARCH-rtfm
These are the actual ports. These crates will use the
rtfm-syntax
crate toimplement the
#[app]
attribute and they'll re-export thertfm-core
API.All ports must implement the following API:
lock
API#[task]
s andspawn
APIAnd they may implement any of these extensions:
#[exception]
API#[interrupt]
APIschedule
APImulti-core support
GitHub org
All these crates will be owned by the
rtfm-rs
GitHub organization andmaintained by the members of the organization. The idea is to grow the
membership of the organization to include people with expertise on
architectures other than ARM Cortex-M.
I have already done the refactor and have tested the portability of the
rtfm-syntax
crate by implementing a Linux port (base features +schedule
+ multi-core support) and the single-core and multi-core variants ofcortex-m-rtfm
(see PR #205).cc'ing people that may be interested in other ports:
@Disasm (rust-embedded/riscv)
@cr1901 @pftbest (rust-embedded/msp430)
The text was updated successfully, but these errors were encountered: