IsaacWoods/poplar

Boot on RISC-V

IsaacWoods opened this issue · 2 comments

IsaacWoods commented

Proof-of-concept

  • Work out how to build OpenSBI
  • Write proof-of-concept booting example
  • Basic serial port driver
  • Test calling into OpenSBI

Infrastructure

  • Build kernel from xtask
  • Run RISC-V QEMU from xtask

Seed

  • Move + rename efiloader to seed_uefi in subdirectory (top-level?)
  • Set up infrastructure for seed_riscv linked to start just after firmware (like the current example)
  • Parse FDT
  • Logging with tracing
  • Physical memory manager
  • Find and load kernel ELF
  • Paging
  • Jump into kernel!
  • Create direct map of physical memory
  • Kernel fault handler
  • Rewrite boot info to use heapless and implement with shared seed library
  • Migrate seed_uefi and kernel_x86_64 to use new seed::boot_info
  • Construct boot info and pass it to the kernel
  • Allocate and map kernel heap within Seed and then initialize it within the kernel
IsaacWoods commented

Easy initial kernel & early task loading

So in the future we will probably want to do the Virtio and GPT support, but for now we could cheat and use QEMU's loader device to just stick a FAT or other image in memory and parse it straight.

Example (force-raw just prevents it from trying to parse and load an image file e.g. an ELF):

-device loader,file=<file>,addr=<addr>,force-raw=on
  • Generate FAT32 from sample files (eventually kernel + tasks)
  • Add it to QEMU using loader device
  • See how the loader appears in the device tree (hopefully it actually does?)
  • Hand off to "driver" that parses the FAT and provides contents of file (hopefully we can avoid actually loading it out?)
  • Load kernel ELF + create set of page tables
IsaacWoods commented

Entry into kernel

Saw an interesting suggestion that you can avoid having to identity-map anything on RISC-V when switching to paging bc you can just trust that it's going to trap - you can then set stvec to a magic "trap handler" in the kernel and go from there.

Would like to have a closer read of the spec to see if this is valid though - feels super icky not to be doing a sfence.vma on this?
Edit: turns out you can do the sfence.vma fairly convincingly like this:

# Feels like every implementation will trap somewhere along these instructions right?
csrw satp, {}
sfence.vma
unimp