------- Original Message -------
On Monday, July 11th, 2022 at 4:55 PM, Axel Heider
Charles,
My first name is Ahmed, though this is a common occurrence. :)
QEMU emulator version 7.0.0 (Debian 1:7.0+dfsg-2~bpo11+2) Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
$ ../init-build.sh -DPLATFORM=spike -DRISCV64=TRUE -DRELEASE=FALSE -DSIMULATION=TRUE $ ninja $ ./simulate -m 1G # becomes: qemu-system-riscv64 -machine spike -cpu rv64 -nographic -serial mon:stdio -m size=1G -bios none -kernel images/sel4test-driver-image-riscv-spike
So - just to check, you don't see any output at all form the system booting, right? So Open-SBI and no seL4 messages?
I see everything up to (qemu 7): Jumping to kernel-image entry point... On qemu 5, I see: Jumping to kernel-image entry point... Init local IRQ no PLIC present, skip hart specific initialisation Bootstrapping kernel Initializing PLIC... no PLIC present, skip platform specific initialisation available phys memory regions: 1 [80200000..17ff00000] reserved virt address space regions: 3 [ffffffc084000000..ffffffc08401f000] [ffffffc08401f000..ffffffc08401f3a1] [ffffffc084020000..ffffffc084417000] This means that opensbi runs. The default opensbi that I've seen for qemu 7 is 1.0. I have a local version of xv6 (riscv64) which boots fine with a custom m-mode implementation (it doesn't use opensbi or bbl). It works while passing -bios none.
You have to use "-bios <img>" now instead of "-kernel <img>" when starting
QEMU. There was a change that "-kernel <img>" now starts the "kernel" in
S-Mode and an SBI will be taken from QEMU's internal (it comes with a dedicated ELF), while "-bios <img>" starts in M-Mode. Since we have an SBI
in the sel4 system image, this will crash if started in S-Mode due to missing access permission.
Both behave the same way, I've tried. Note, if you pass -kernel <img> while -bios isn't specified, which means the default is used, then you get an error: "Some ROM regions are overlapping" which is obvious as to what is happening.
Using "-bios none" will just skip S-Mode, but that means the PMP is left unconfigured and S-Mode does not have access to any memory. New QEMU (6.0+?) emulate a PMP, older ones did now to this was not an issue.
The qemu docs: https://qemu.readthedocs.io/en/latest/system/target-riscv.html do not say that -bios starts the core in S-Mode, though it isn't explicit either way. I've written a kernel based on xv6 which I run as -bios none -kernel <img> which successfully starts in qemu with the new pmp protections. Given that I've examined every assembly instruction required to go from M-Mode start on qemu to S-Mode, I would hope that if that was the only issue going on here, I'd have noticed when I debugged it using gdb. I suspect something else is going on, though unfortunately, I don't know what.
We have to QEMU simulate update the scrips to handle this, but the docker container still has the old QEMU, so this is not an issue there.
I'll look into trying the docker container. Thanks.