New linker script and multi-core support #31
Conversation
… dependency graph
This reverts commit 3a76c3b.
| @@ -71,6 +71,10 @@ _start: | |||
| // Set frame pointer | |||
| add s0, sp, zero | |||
|
|
|||
| // Set trap handler | |||
| la t0, _start_trap | |||
| csrw mtvec, t0 | |||
There was a problem hiding this comment.
Beware that not all targets support Privileged Architecture CSRs.
I wanted to submit a PR gating the mtvec::write in src/lib.rs. It's not gonna be possible to conditionally compile an '.S'
There was a problem hiding this comment.
I thought about it. Both riscv and riscv-rt depend on running with privileged support, so there is no easy way to support picorv32 and complex cores like FU540. Seems like it's better to have separate picorv32-rt library.
There was a problem hiding this comment.
Yeah, makes sense. I'll just fork off this repo then after this PR lands
| @@ -253,9 +250,6 @@ pub unsafe extern "C" fn start_rust() -> ! { | |||
|
|
|||
| // TODO: Enable FPU when available | |||
|
|
|||
| // Set mtvec to _start_trap | |||
| mtvec::write(&_start_trap as *const _ as usize, mtvec::TrapMode::Direct); | |||
There was a problem hiding this comment.
Removing this single line allowed me to run Rust on https://github.com/cliffordwolf/picorv32.
|
@bradjc Could you review this? |
|
Nice. |
|
@laanwj Do you have any suggestions or we can merge it? |
|
bors try |
tryBuild failed |
I haven't tried the code, but the changes look good to me. I made similar (but more hacky) changes to succesfully test multi-core on K210. Mainly: set the trap handler for all cores, then enable MIE and MSOFT so that the other core can be woken up using an IPI: + // Set trap handler
+ la t0, _start_trap
+ csrw mtvec, t0
+ // Enable software interrupts
+ csrs mstatus, 8
+ csrs mie, 8Then to invoke the trap handler on the other core: writeln!(stdout, "Generate IPI for core 1 !").unwrap();
unsafe {
(*pac::CLINT::ptr()).msip[1].write(|w| w.bits(1));
}It looks like So looks good for merge to me. |
|
@laanwj I thought about handling other cores with a trap handler, but refused to go this way. One of the reasons is that we should decide which core is the main one upon startup. I wanted to avoid this, because I know at least one case where choosing |
|
bors r=laanwj |
31: New linker script and multi-core support r=laanwj a=Disasm * Linker script was reworked. Now it uses region aliases to relocate sections. This approach makes it possible to build firmware for both FLASH+RAM and RAM-only targets. Memory definitions now supposed to be present in their corresponding crates (e.g. RAM definition in PAC crate, FLASH definition in board support crate). * Multi-core support was introduced. Cores are parked with `_mp_hook` function and then awakened in platform-dependent way. * Documentation was updated to reflect new features. * New crate version: 0.6.0 Depends on: rust-embedded/riscv#28 Closes: #26 Co-authored-by: Vadim Kaushan <admin@disasm.info>
Build succeeded |
_mp_hookfunction and then awakened in platform-dependent way.Depends on: rust-embedded/riscv#28
Closes: #26