On Tue, 27 Sept 2022 at 16:34, Victor Martins <[email protected]> wrote: > Peter Maydell <[email protected]> escreveu no dia terça, 27/09/2022 > à(s) 10:27: >> >> What are you trying to achieve by removing the "-machine virt" >> option?
> 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. Yep, that won't work. If you want a new SoC/machine model in QEMU you need to write a lot of C code, I'm afraid. There is no magic quick route. > 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 :/ This is strictly speaking a bug in the virt board. What's happening is that the virt board code is trying to add an entry to the dtb, but it's already present (because it got added the first time around, when you used the dumpdtb option). But it's not a very important bug, because you're doing something weird anyway. > 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. You need to write a new QEMU machine model to do this (i.e. ignore the 'virt' board entirely). This is quite a lot of work (depending on how complicated your SoC is and whether it's using devices that QEMU already has a model of or if you need also to write models of all the devices) and requires some knowledge of QEMU internals. -- PMM
