Re: [U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine
On Sat, May 4, 2019 at 8:38 PM Karsten Merker merker@debian.org wrote:
On Sat, May 04, 2019 at 09:24:15AM +0530, Anup Patel wrote:
[U-Boot+OpenSBI crash with more than 2GB RAM in qemu-system-riscv64]
I tried again with image header changes applied to u-boot and Linux kernel but still not able to reproduce the issues.
Either you might have more local changes or debian toolchain is causing issue for u-boot.
Hello,
I hadn't made any local changes besides the ones described in my original email, i.e. the application of the booti patches. To check for a toolchain-related problem I have rebuilt everything with both the gcc8-based and the gcc7-based buildroot toolchains, but the problem remained in all cases, regardless of whether I used the branch with the booti patch or the plain v2019.07-rc1 tag, so the problem is definitely not specific to the Debian toolchain. As a new qemu release has happend just a few days ago, I have now tried to upgrade qemu from the previous release version 3.1.0 to the freshly released version 4.0.0, and indeed with qemu 4.0.0 both the 2GB problem and the hang of init in SMP configurations with OpenSBI+U-Boot are gone. Which qemu version had you been using in your tests?
I am using QEMU 4.0.0-rc2.
Like mentioned in previous email, BBL has limitation that it allows full memory access to S-mode software. This means S-mode software can actually corrupt BBL too. This is not possible in OpenSBI because we use PMP configuration to protect firmware and critical memory regions.
With QEMU 3.x, OpenSBI+U-Boot is failing for you because there were bugs in QEMU PMP checks.
What makes this interesting is that I'm running qemu 3.1.0 with BBL and Linux in a 4-core SMP configuration and with 8GB of RAM since months and never had any problems with it, so OpenSBI+U-Boot seems to do something differently from BBL.
That's because BBL is buggy. It allows complete RAM access to S-mode software so QEMU PMP checks did not matter.
Regards, Anup
On Sat, May 4, 2019 at 7:20 PM Anup Patel anup@brainfault.org wrote:
On Sat, May 4, 2019 at 8:38 PM Karsten Merker merker@debian.org wrote:
On Sat, May 04, 2019 at 09:24:15AM +0530, Anup Patel wrote:
[U-Boot+OpenSBI crash with more than 2GB RAM in qemu-system-riscv64]
I tried again with image header changes applied to u-boot and Linux kernel but still not able to reproduce the issues.
Either you might have more local changes or debian toolchain is causing issue for u-boot.
Hello,
I hadn't made any local changes besides the ones described in my original email, i.e. the application of the booti patches. To check for a toolchain-related problem I have rebuilt everything with both the gcc8-based and the gcc7-based buildroot toolchains, but the problem remained in all cases, regardless of whether I used the branch with the booti patch or the plain v2019.07-rc1 tag, so the problem is definitely not specific to the Debian toolchain. As a new qemu release has happend just a few days ago, I have now tried to upgrade qemu from the previous release version 3.1.0 to the freshly released version 4.0.0, and indeed with qemu 4.0.0 both the 2GB problem and the hang of init in SMP configurations with OpenSBI+U-Boot are gone. Which qemu version had you been using in your tests?
I am using QEMU 4.0.0-rc2.
If you want to use SMP with U-Boot you need to use QEMU 4.0.0 + Kernel 5.1 + U-Boot v2019.07-rc1. At least that's what I recall.
david
Waking this thread up, because I'm seeing similar behavior as Karsten -- i.e. the system hangs when launching init.
Software: QEMU emulator version 4.0.50 (v4.0.0-576-g6d8e75d41c58) Linux kernel v5.2-rc1, defconfig OpenSBI commit 392749f6338a ("docs: Add documentation about dynamic firmware")
Toolchain-wise: Ubuntu/Debian: riscv64-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Launching the VM with: ~/pkg/qemu/bin/qemu-system-riscv64 \ -nographic \ XXXX -machine virt \ -smp 2 \ -m 8G \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-device,rng=rng0 \ -append "console=ttyS0 selinux=0 apparmor=0 loglevel=7 rw root=/dev/vda2" \ -device virtio-blk-device,drive=hd0 \ -drive file=~/rv/play/debian-sid-sda.raw,format=raw,id=hd0 \ -device virtio-net,mac=36:8c:88:13:10:d2,netdev=network0 \ -netdev tap,id=network0,fd=3 3<>/dev/tap5
Where XXXX: -kernel ~/src/rv/opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \ -device loader,file=/home/btopel/build/rv/arch/riscv/boot/Image,addr=0x80200000 \
or -kernel bbl \ # riscv-pk HEAD
* When riscv-pk carries the payload, the kernel boots and succeeds to launch init. * Using OpenSBI commit 392749f6338a ("docs: Add documentation about dynamic firmware"), the kernel boots, but hangs/spins ("info registers" says it's "rdcycle").
Bisecting OpenSBI, it looks like commit 90cb4917b584 ("lib: Implement sfence.vma correctly.") broke something. At least prior that, the VM launches correctly.
I haven't looked further -- any ideas?
Thanks, Björn
On 5/20/19 10:26 AM, Björn Töpel wrote:
Waking this thread up, because I'm seeing similar behavior as Karsten -- i.e. the system hangs when launching init.
Software: QEMU emulator version 4.0.50 (v4.0.0-576-g6d8e75d41c58) Linux kernel v5.2-rc1, defconfig OpenSBI commit 392749f6338a ("docs: Add documentation about dynamic firmware")
Toolchain-wise: Ubuntu/Debian: riscv64-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Launching the VM with: ~/pkg/qemu/bin/qemu-system-riscv64 \ -nographic \ XXXX -machine virt \ -smp 2 \ -m 8G \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-device,rng=rng0 \ -append "console=ttyS0 selinux=0 apparmor=0 loglevel=7 rw root=/dev/vda2" \ -device virtio-blk-device,drive=hd0 \ -drive file=~/rv/play/debian-sid-sda.raw,format=raw,id=hd0 \ -device virtio-net,mac=36:8c:88:13:10:d2,netdev=network0 \ -netdev tap,id=network0,fd=3 3<>/dev/tap5
Where XXXX: -kernel ~/src/rv/opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \ -device loader,file=/home/btopel/build/rv/arch/riscv/boot/Image,addr=0x80200000 \
or -kernel bbl \ # riscv-pk HEAD
- When riscv-pk carries the payload, the kernel boots and succeeds to launch init.
- Using OpenSBI commit 392749f6338a ("docs: Add documentation about dynamic firmware"), the kernel boots, but hangs/spins ("info registers" says it's "rdcycle").
Bisecting OpenSBI, it looks like commit 90cb4917b584 ("lib: Implement sfence.vma correctly.") broke something. At least prior that, the VM launches correctly.
I haven't looked further -- any ideas?
Thanks, Björn
opensbi mailing list opensbi@lists.infradead.org http://lists.infradead.org/mailman/listinfo/opensbi
Try this patch. This should solve this issue.
http://lists.infradead.org/pipermail/opensbi/2019-May/000118.html
On Mon, 20 May 2019 at 22:03, Atish Patra atish.patra@wdc.com wrote:
[...]
Try this patch. This should solve this issue.
http://lists.infradead.org/pipermail/opensbi/2019-May/000118.html
Yup, it does solve it. Thank you!
Björn
participants (4)
-
Anup Patel -
Atish Patra -
Björn Töpel -
David Abdurachmanov