Add initial RISC-V support + HiFive board #1317

bradjc · 2019-06-03T19:17:37Z

Pull Request Overview

Support for RISC-V has been progressing on the side for a while, and I've been realizing that trying to make a pull request that includes three different boards and support for a new architecture is not only going to be very difficult to review, but also very difficult to create. So instead, this is an attempt to start the process with some initial code that supports the HiFive1 rev A board.

This code is very similar to the riscv branch that has been around for a while. Some things (like better OpenOCD support) have improved in the meantime, and it includes some learnings from using a different chip (we cannot assume RISC-V cores have a PLIC, for example), but otherwise it doesn't include any new functionality from what was on that branch from a while ago. It also does not include any of the new context switching code. With this PR established or merged it will be a lot easier to see what "hidden" changes we had to make to get context switching to work.

Since the HiFive1a does not support User mode I removed all of the code related to supporting applications in main.rs.

One nice thing about this PR is that only one file actually changed, most of this patch is just adding code. The changed file is the kernel linker script which requires a few additions.

Testing Strategy

This pull request was tested by running the kernel on a HiFive1 board and verifying that it still prints the debug!() message in main.rs.

TODO or Help Wanted

A big question is how to integrate the improvements from others related to the HiFive1/E310 code. My preference would be to merge this PR and then use it as base for other improvements, but if other code is ready to go it might make sense to extend this PR or create a series of active PRs.

Documentation Updated

Updated the relevant files in /docs, or no updates are required.

I updated several READMEs, but I'm still not sure that I didn't miss anything.

Formatting

Ran make formatall.

This commit is the first towards adding RISC-V support to Tock. It includes enough code that a RISC-V core will boot and can handle interrupts. It also includes basic support for the HiFive1 (a) board, and some SiFive peripherals. The HiFive1(a) board does not support User mode, so there is no support for userland (yet). This simply allows kernel code to boot and run. The SiFive peripherals are organized into their own folder because they are shared among multiple SiFive cores.

ppannuto

This is super exciting!

In general, I think I agree with the path forward of merging this as a "base" RiscV support and then adding more manageable PRs along the way

arch/rv32i/src/lib.rs

ppannuto · 2019-06-03T20:38:13Z

arch/rv32i/src/support.rs

+pub unsafe fn atomic<F, R>(f: F) -> R
+where
+    F: FnOnce() -> R,
+{


You can make the body of this unimplemented!(), which the compiler is aware of and can then warn folks if this gets used

Well it is called, but just doesn't really protect against anything.

boards/hifive1/Makefile

ppannuto · 2019-06-03T20:43:43Z

boards/kernel_layout.ld

+         * shouldn't have any effect.
+         */
+        KEEP(*(.riscv.start));
+        KEEP(*(.riscv.trap));


This looks good -- perhaps we should consider renaming the vectors and irqs sections to arm.*

Not something that needs fixing in this PR though -- wish GH had a 'this is really a comment not something that needs addressing' option :/

Agree with Pat, but more generally does it make sense to separate ARM kernel_layout and RISC-V kernel_layout?

ppannuto · 2019-06-03T20:46:27Z

boards/kernel_layout.ld

        *(.app_memory)
    } > ram
+
+    /* Discard RISC-V relevant .eh_frame, we are not doing unwind on panic


I'm guessing this proved necessary due to size? This isn't something you necessarily want to do as it was will make a debugger less useful; unwind info isn't just used for runtime panics

I have no idea where that came from, probably rust-riscv I started from.

chips/e310x/src/chip.rs

- use tock-rt0 functions - remove old commented out code - add more to readme.md

bradjc · 2019-06-04T14:48:55Z

Updated after Pat's comments.

phil-levis

I left a few comments. The only one that's substantive is the question about inline assembly.

phil-levis · 2019-06-07T17:03:54Z

arch/rv32i/src/lib.rs

+// frame pointer (needed for closures to work in start_rust) and the global
+// pointer. Then it calls _start_rust.
+#[cfg(any(target_arch = "riscv32", target_arch = "riscv64"))]
+global_asm!(


A while ago we talked about migrating away from inline assembly and instead just relying on assembly, linked as C functions. IIRC this was because of the optimization tricks the compiler does such that the generated assembly may (unless you get all of the annotations right) not be what you wrote.

Ok, yes, this will be fixed in the next PR. It's fixed in the riscv2 branch.

phil-levis · 2019-06-07T17:10:58Z

boards/hifive1/layout.ld

@@ -0,0 +1,10 @@
+MEMORY


Can you reference where these values come from? I'm trying to understand why prog is 507M.

phil-levis · 2019-06-07T17:13:34Z

boards/kernel_layout.ld

+         * shouldn't have any effect.
+         */
+        KEEP(*(.riscv.start));
+        KEEP(*(.riscv.trap));


Agree with Pat, but more generally does it make sense to separate ARM kernel_layout and RISC-V kernel_layout?

phil-levis · 2019-06-07T17:16:43Z

boards/kernel_layout.ld

        . = ALIGN(4);
        _srelocate = .;
+
+        /* The Global Pointer is used by the RISC-V architecture to provide


Data past 4kB has to do something else (that's less efficient)? It seems like there are certain kernel structures we'll want to make sure are in this 4kB region, then.

phil-levis · 2019-06-07T17:18:11Z

chips/sifive/src/uart.rs

+    }
+}
+
+impl hil::uart::Transmit<'a> for Uart<'a> {


Any thoughts on the new UART HIL?

You know this was just a pretty mechanical translation from the old to the new, so I didn't really interact with the new HIL API. I did like it is more explicit that receive has not been implemented.

bradjc · 2019-06-11T18:21:09Z

If there are any other comments I'm happy to address them, but the consensus was to merge riscv code aggressively so here we go!

ppannuto reviewed Jun 3, 2019

View reviewed changes

hifive1 updates

a60951e

- use tock-rt0 functions - remove old commented out code - add more to readme.md

bradjc mentioned this pull request Jun 4, 2019

Tracking: Support RISC-V #1135

Closed

20 tasks

phil-levis previously approved these changes Jun 7, 2019

View reviewed changes

hifive1: add comment to layout.ld

6eb36fd

bradjc dismissed phil-levis’s stale review via 6eb36fd June 11, 2019 15:18

bradjc merged commit 6942503 into master Jun 11, 2019

bors bot deleted the hifive1 branch June 11, 2019 18:20

Uh oh!

Add initial RISC-V support + HiFive board #1317

Add initial RISC-V support + HiFive board #1317

Uh oh!

Conversation

bradjc commented Jun 3, 2019

Pull Request Overview

Testing Strategy

TODO or Help Wanted

Documentation Updated

Formatting

Uh oh!

ppannuto left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bradjc commented Jun 4, 2019

Uh oh!

phil-levis left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bradjc commented Jun 11, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants