Hi, Maybe, you need to add the "-bios none" option. I booted the image with the following options on Fedora 33. ~~~ $ qemu-system-riscv64 -bios none -nographic -machine virt -smp 1 -m 1G \ -kernel Fedora-Minimal-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf \ -device virtio-blk-device,drive=hd0 \ -drive file=Fedora-Minimal-Rawhide-20200108.n.0-sda.raw,format=raw,id=hd0 \ -device virtio-net-device,netdev=usernet \ -netdev user,id=usernet,hostfwd=tcp::10000-:22 ~~~ Takayuki Nagata 2021年7月6日(火) 10:16 Andrej Podzimek via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx>: > > Hi Fedora developers! > > I'm trying to start a Fedora riscv64 VM on an ArchLinux x86_64 host based on this wiki page: https://fedoraproject.org/wiki/Architectures/RISC-V/Installing I have a reasonably recent qemu and virt-manager: > > ``` > qemu 6.0.0-3 > qemu-arch-extra 6.0.0-3 > libvirt 1:7.3.0-1 > virt-manager 3.2.0-1 > ``` > > All virt-builder steps work perfectly fine and produce an image. > > However, I cannot start an instance. I tried the image prepared with virt-builder, the manually downloaded image, the nightly image, direct kernel loading (configured in libvirt / virt-manager), but none of that worked. > > For the nightly instances in particular, the wiki says one should extract "firmware" from /opensbi/... in the image. However, there is _no_ such directory in the image (and also no file called .elf). This information may be outdated. > > When using the downloaded .elf file (as described in the "Download using virt-builder" section), I get this from qemu: > > ``` > qemu-system-riscv64: Some ROM regions are overlapping > These ROM regions might have been loaded by direct user request or by default. > They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. > Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. > > The following two regions overlap (in the memory address space): > /usr/bin/../share/qemu/opensbi-riscv64-generic-fw_dynamic.bin (addresses 0x0000000080000000 - 0x0000000080012558) > VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf ELF program header segment 0 (addresses 0x0000000080000000 - 0x000000008000d0e0) > ``` > > The qemu command line was: > > ``` > qemu-system-riscv64 \ > -nographic \ > -machine virt \ > -smp 8 \ > -m 32G \ > -kernel VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf \ > -object rng-random,filename=/dev/urandom,id=rng0 \ > -device virtio-rng-device,rng=rng0 \ > -device virtio-blk-device,drive=hd0\ > -drive file=VirtualMachineMedia/Fedora-Developer-Rawhide-20210421.n.0-sda.raw,format=raw,id=hd0 \ > -device virtio-net-device,netdev=usernet \ > -netdev user,id=usernet,hostfwd=tcp::10000-:22 > ``` > > Idea No. 1: Drop the "-kernel ..." argument. In that case I get an OpenSBI splash that looks like this: https://pastebin.com/5QKJqkRg Sadly, the VM is frozen and nothing else happens. There is no network communication either. > > It looks like this^^^ configuration might start something, but fails to load a kernel properly (or the like). The nightly image appears to contain multiple bootloaders, but the wiki doesn't say how to run them. > > Idea No. 2: Delete /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin to see if the conflict goes away. (For the record, the file is owned by qemu-arch-extra.) Well, qemu then says 'qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-generic-fw_dynamic.bin"'. > > Idea No. 3: Extract the kernel (vmlinuz-5.10.6-200.0.riscv64.fc33.riscv64) and initramdisk (initramfs-5.10.6-200.0.riscv64.fc33.riscv64.img) from the nightly image and load them "directly" (using virt-manager) like this: https://pastebin.com/36RVR75r > > This^^^ failed the same way as all virt-manager experiments (with nightly / manually downloaded / built with virt-builder) images: A black console with a blinking cursor and nothing happens. No activity on the virtual bridge either. > > Interestingly, each time qemu starts and freezes, host CPU utilization is about 200% (i.e., 2 cores worth of load, not 1 core, not 8 cores etc.). (The host machine is a Ryzen 3950X with 32 CPUs altogether and 128 GB RAM.) > > What am I doing wrong (apart from not using Fedora as a host)? > Why am I getting a weird conflict with a system built-in OpenSBI? Could the built-in firmware be incompatible with the Fedora image? > Are there any up-to-date instructions on how to get the recent nightly images (without the /opensbi directory) working? > How can I debug why qemu / OpenSBI freezes? Does OpenSBI need a bit of configuration to boot the image? > > I'll retry this on a Fedora VM if need be, but would also like to understand what the issue is on Arch. Also, I wanted to double-check that the riscv64 port actually works on current systems... > > Just about any hint would help a lot. :-) > > Cheers! > Andrej > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
