On one of my computers: 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 Thanks ------- Original Message ------- On Monday, July 11th, 2022 at 1:13 AM, Ivan Velickovic wrote:

What platform are you trying to build for sel4test? What command did you use to build sel4test? QEMU version 6.0.0 works successfully for me.

...

On 11/07/2022, at 3:43 PM, Ahmed Charles me@ahmedcharles.com wrote:

I'm having similar issues getting seL4test to work on riscv32/64 on QEMU 6.0.0 and 7.0.0. I tried debugging with a connected gdb, but I'm new at this and setting breakpoints in user mode seems to fail, so I'm not sure what happens once the root task starts, other than it eventually runs an infinite loop (0: j 0b, specifically).

Any ideas? Thanks. _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

I've done both of those, neither worked because the memory wasn't accessible when setting the breakpoint and it doesn't let you single step over an sret. ------- Original Message ------- On Monday, July 11th, 2022 at 9:39 AM, Sid Agrawal wrote:

Re. Breakpoint in user mode. This might be a silly thing but it did trip me up so worth pointing out. While running gdb, ensure that you are loading the symbols for the user task and not the kernel.

Window1: ./simulate --extra-qemu-args="-S -s"

Window2: ${CROSS_COMPILER_PREFIX}gdb projects/sel4test/apps/sel4test-driver/sel4test-driver (inside gdb) target remote :1234 (inside gdb) b <some func in your root task>

src: https://docs.sel4.systems/projects/sel4-tutorials/debugging-guide

-Sid

On Mon., Jul. 11, 2022, 1:28 a.m. Ahmed Charles, me@ahmedcharles.com

wrote:

...

On one of my computers:

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

Thanks

------- Original Message ------- On Monday, July 11th, 2022 at 1:13 AM, Ivan Velickovic < i.velickovic@unsw.edu.au> wrote:

...

What platform are you trying to build for sel4test? What command did you use to build sel4test? QEMU version 6.0.0 works successfully for me.

...

On 11/07/2022, at 3:43 PM, Ahmed Charles me@ahmedcharles.com wrote:

I'm having similar issues getting seL4test to work on riscv32/64 on QEMU 6.0.0 and 7.0.0. I tried debugging with a connected gdb, but I'm new at this and setting breakpoints in user mode seems to fail, so I'm not sure what happens once the root task starts, other than it eventually runs an infinite loop (0: j 0b, specifically).

Any ideas? Thanks. _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

_______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

------- Original Message ------- On Monday, July 11th, 2022 at 4:55 PM, Axel Heider 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.