------- Original Message ------- On Monday, July 11th, 2022 at 4:55 PM, Axel Heider <axelhei...@gmx.de> wrote:
> 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. _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
