Peter Maydell <[email protected]> escreveu no dia terça, 27/09/2022 à(s) 10:27:
> On Mon, 26 Sept 2022 at 20:39, Victor Martins <[email protected]> > wrote: > > And after I try use the dtb file and remove the virt board like this: > > > > $ qemu-system-riscv64 \ > > -nographic \ > > -dtb ./riscv64-virt.dtb \ > > -kernel linux-5.19.1/arch/riscv/boot/Image \ > > -append "root=/dev/vda ro console=ttyS0" \ > > -drive file=busybox,format=raw,id=hd0 \ > > -device virtio-blk-device,drive=hd0 \ > > -netdev user,id=eth0 \ > > -device virtio-net-device,netdev=eth0 > > This command doesn't specify a machine type. That means you > get whatever the default machine type for riscv64 is, which > happens to be "spike". A kernel built for the "virt" board > won't run on "spike", especially if it's passed a DTB for > the "virt" board. > > What are you trying to achieve by removing the "-machine virt" > option? In general: > (1) you should always specify a machine type (even if there > is a default, it's clearer to say what you want rather than > relying on the default) > (2) the guest kernel you pass should be built with support > for that machine type > (3) for machine types that automatically generate a DTB > file, you should just let QEMU autogenerate and pass the > DTB file; don't use the "-dtb" option on these machines > Thanks Peter, you gave me a great first lesson. I suppose the "dumpdtb" export all about the machine type and when I use the -dtb the QEMU follow that instructions. Basically my original plan was use this way to design my machine (using DTC dts => dtb). All this because I wish to develop my RISC-V SoC in one FPGA. > > > But don't work as before and I get this error: > > > > $ qemu-system-riscv64: -device virtio-blk-device, > > > > drive=hd0: No `virtio-bus´ bus found for device `virtio-blk-device´ > > This is because "spike" doesn't support virtio. > > > I feel that the dump operation dont extract the full Device > > Tree. My idea is to try to use only the dtb/dts. Is that possible? > > -dumpdtb is giving you the complete device tree, but you seem > to be confused about what QEMU does with the -dtb option. > All QEMU does with the dtb file you provide is give it to > the kernel you boot. > *The dtb file does not cause QEMU in any way to change what kind of > hardware it is emulating*. > I know this now. Thanks. Any way if I do this (-machine and -dtb flags): $ qemu-system-riscv64 \ -nographic \ -machine virt \ -kernel linux-5.19.1/arch/riscv/boot/Image \ -dtb ./riscv64-virt.dtb \ -append "root=/dev/vda ro console=ttyS0" \ -drive file=busybox,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev user,id=eth0 \ -device virtio-net-device,netdev=eth0 I receive this error: qemu-system-riscv64: qemu_fdt_add_subnode: Failed to create subnode /fw-cfg@1010000: FDT_ERR_EXISTS Im using exactly the dump dtb file. I know I´m not adding any new information, but because this I expect will work in the same way as before :/ Any way, I have no problem use the -machine virt. My problem is know how I can map my RISC-V SoC in the FPGA (like have control of the modules map address) to can develop my applications in the future using the QEMU as I use the FPGA board. Best Regards > (dumpdtb is intended largely for debugging, so you can see > what the dtb passed to the guest kernel is; there are also > some rare use cases where you might want to edit it and then > pass it back to QEMU. 99% of users don't need it at all.) > > thanks > -- PMM >
