summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRonald G. Minnich <rminnich@gmail.com>2018-09-15 05:21:45 -0700
committerRonald G. Minnich <rminnich@gmail.com>2018-09-15 12:52:32 +0000
commitb159d5ba8f4731a08028fed92bdb12e2357c73e7 (patch)
tree0f44af2619498f4ec872af5432c06b3c6435a0d0
parentc75f2d811933051c991d71f39aa94b43063ec479 (diff)
downloadcoreboot-b159d5ba8f4731a08028fed92bdb12e2357c73e7.tar.xz
riscv: add documentation for stages and payloads
Change-Id: Iff522e309e9cf9a31c1c79c24047d83d7fd0b00a Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28619 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
-rw-r--r--Documentation/arch/riscv/index.md47
1 files changed, 47 insertions, 0 deletions
diff --git a/Documentation/arch/riscv/index.md b/Documentation/arch/riscv/index.md
new file mode 100644
index 0000000000..c2ecaef958
--- /dev/null
+++ b/Documentation/arch/riscv/index.md
@@ -0,0 +1,47 @@
+# RISCV architecture documentation
+
+This section contains documentation about coreboot on RISCV architecture.
+
+## Mode usage
+All stages run in M mode.
+
+Payloads have a choice of managing M mode activity: they can control
+everything or nothing.
+
+Payloads run from the romstage (i.e. rampayloads) are started in M mode.
+The payload must, for example, prepare and install its own SBI.
+
+Payloads run from the ramstage are started in S mode, and trap delegation
+will have been done. These payloads rely on the SBI and can not replace it.
+
+## Stage handoff protocol
+On entry to a stage or payload,
+* all harts are running.
+* A0 is the hart ID
+* A1 is the pointer to the Flattened Device Tree (FDT).
+
+## Additional payload handoff requirements
+The location of cbmem should be placed in a node in the FDT.
+
+## Trap delegation
+Traps are delegated in the ramstage.
+
+## SMP within a stage
+At the beginning of each stage, all harts save 0 are spinning in a loop on a semaphore.
+At the end of the stage harts 1..max are released by changing the
+semaphore.
+
+A possible way to do this is to have a pointer to a struct containing variables, e.g.
+
+```c
+struct blocker {
+ void (*fn)(); // never returns
+}
+```
+
+The hart blocks until fn is non-null, and then calls it.
+If fn returns we will panic if possible, but behavior
+is largely undefined.
+
+Only hart 0 runs through most of the code in each stage.
+