Cannot run an up-to-date Linux kernel in Spike or Qemu

[riscv-software-src]

Cannot run an up-to-date Linux kernel in Spike or Qemu

[seldridge]

FWIW, I'm seeing the same problem after updating. Compiling with the --with-payload=[full path to vmlinux] produces a hang. Running this through spike with logging, I'm seeing it get stuck in the memcpy function called by load_kernel_elf. I'll do some more digging...

However, I'm somewhat curious as to the motivation for the BBL_PAYLOAD modifications. Does this mean that a bbl binary is tied to a specific kernel?

[seldridge]

I was a little premature with this. I think that memcpy just takes a long time if you're running spike with logging. It obviously gets past this because the logo gets printed. Still digging...

[handong32]

I'm hitting the same issue, on spike it is repeatedly outputting this after printing the logo and motto:

core 0: exception trap_instruction_access_fault, epc 0x0000000000000000

[zhemao]

Hi guys. We are currently working on moving our software over to the new privilege 1.9 ISA. As a result, the versions of some things might be out of sync with each other.

If you want to use the stable 1.7 ISA, make sure you use the correct versions. You should use the master branch of riscv-tools (not master branch of riscv-pk) and build the version of bbl and spike provided as submodules. In addition, you should use master branch or linux-4.1.y-riscv branch of riscv-linux. These versions will allow you to use the old command line spike +disk=root.bin bbl vmlinux.

If you want to use the new 1.9 ISA, you will need to check out the priv-1.9 branch of riscv-tools and build spike and bbl from that branch. In addition, you will need to use priv-1.9 or linux-4.1.y-riscv-priv-1.9 branch of riscv-linux. As you've already discovered, this version does not include HTIF support in bbl or vmlinux. As a result, you will need to configure bbl with the --with-payload option. Another consequence of removing HTIF is that the kernel will not have block device support so "+disk" will not work. For now, you can get around this by booting from an initramfs ramdisk instead of from a disk image.

We are sorry for the inconvenience this has caused and the lack of communication from our end. We hope to have the privilege 1.9 ISA finalized and the software in a stable state soon.

[seldridge]

All good. I've gotten myself into trouble here because I've assumed that rocket-chip master was somewhat stable, but that's been aggressively tracking the 1.9 WIP updates as of late.

Just to clarify, the --with-payload is for specifying the kernel, i.e., vmlinux?

Also, you wouldn't happen to have an example for booting from an initramfs lying around? I'm out of my element here, but it seems like I'd need to configure the kernel to use an initramfs, package up the existing root filesystem image as an initramfs, and give this to the kernel at configure time so that it will automatically pull it in?

[seldridge]

I was able to get through what I think is a correct initramfs setup within the kernel just using menuconfig to enable initramfs and point it at a directory containing the root filesystem with a /init defined.

Using --with-payload to point at this built vmlinux, I'm still seeing the behavior that @handong32 identified above, i.e., that core 0 exception trap/access fault on epc 0x0 repeating indefinitely.

Anyway, ignoring the result, does the methodology here seem correct?

[seldridge]

*** I was on the wrong version of riscv-linux. I'm booting with spike and kernel panicking (progress!). This appears to be a problem with my /init. Yes, --with-payload does need to point at vmlinux.

Thanks for the help @zhemao -- your initial suggestion was enough to get me going here.