diff options
| -rw-r--r-- | arch/riscv64/kernel/core_bringup.S | 4 | ||||
| -rw-r--r-- | arch/riscv64/kernel/smp.c | 6 | ||||
| -rw-r--r-- | docs/visionfive2.md | 10 |
3 files changed, 16 insertions, 4 deletions
diff --git a/arch/riscv64/kernel/core_bringup.S b/arch/riscv64/kernel/core_bringup.S index 8a5a6f5..db68dce 100644 --- a/arch/riscv64/kernel/core_bringup.S +++ b/arch/riscv64/kernel/core_bringup.S @@ -1,3 +1,4 @@ +#include "../kernel/csr.h" #include "asm.h" /* pic forces core_bringup to be placed in .got that we can access both from @@ -11,6 +12,9 @@ riscv_bringup: csrw satp, a1 sfence.vma + /* set scratch to zero in case we crash */ + csrw CSR_SSCRATCH, x0 + /* fetch the stack allocated to us at our hart index in smp_init_stacks */ lui t0, %hi(smp_init_stacks) addi t0, t0, %lo(smp_init_stacks) diff --git a/arch/riscv64/kernel/smp.c b/arch/riscv64/kernel/smp.c index 5e30fee..f061694 100644 --- a/arch/riscv64/kernel/smp.c +++ b/arch/riscv64/kernel/smp.c @@ -99,8 +99,7 @@ void smp_bringup(struct vmem *b, void *fdt) BASE_PAGE_SIZE; /* fixup physical address of bringup */ - pm_t bringup = (pm_t)riscv_bringup; - bringup = bringup - VM_KERNEL + get_load_addr(); + pm_t bringup = (pm_t)riscv_bringup - VM_KERNEL + get_load_addr(); r = sbi_hart_start(hartid, bringup, satp); @@ -149,6 +148,9 @@ __noreturn void core_bringup(long hartid) tcb_assign(t); use_tcb(t); + /* now that we're in our own virtual address space, set stack etc. */ + set_thread(t); + info("core %ld releasing BKL\n", (long)cpuid); run_init(t, NULL, NULL); unreachable(); diff --git a/docs/visionfive2.md b/docs/visionfive2.md index 24677f8..1e21896 100644 --- a/docs/visionfive2.md +++ b/docs/visionfive2.md @@ -7,8 +7,7 @@ kernel, but it turns out that their fork is at the time of writing borked and I wasn't able to get anything to boot with it. As such, we'll use their prebuilt bootloader and boot in a more generic way. I've used the binaries downloadable from https://github.com/starfive-tech/VisionFive2/releases/tag/VF2_v3.0.4, -although they are a bit old by now and should probably try to update at some -point. +although newer versions seem to work as well. The following is how to boot with an SD card. The board seems to support serial and ethernet booting, but I haven't looked into how they work. @@ -46,12 +45,19 @@ sync With the SD card ready to go, reset the device and manually run these commands: +0. `fdt set /cpus/cpu@0 status "disabled"` 1. `fdt move ${fdtaddr} ${fdt_addr_r}` 2. `load mmc 1:3 0x47000000 kmi.bin` 3. `load mmc 1:3 0x48000000 initrd` 4. `fdt chosen 0x48000000 0x48001200` 5. `go 0x47000000 ${fdt_addr_r}` +Disabling `cpu@0` is necessary because it's a control core, and as such doesn't +actually participate in booting, but for whatever reason the device tree that +U-Boot comes with doesn't mark it as such in any way, shape of form. From what I +can tell, Linux and *BSD seem to use their own FDTs with that core disabled. +Might be a good idea. + These commands are pretty hard coded and might not work in the future. At least currently `${fdt_addr_r}` is `0x46000000`, so you can probably see where the other addresses come from. Also, the `/chosen` node has to reflect the size of |