Re: If your networking is failing after updating to the latest git version of QEMU...
On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé wrote: > > On 28/9/22 10:27, Thomas Huth wrote: > > > > ... it might have happened due to the removal of the "slirp" submodule > > from the git repository. For example if you see an error message like this: > > > > Parameter 'type' expects a netdev backend type > > > > this likely means that the "user" mode backend type is not available in > > your binary anymore. To fix it, simply install "libslirp-devel" (or > > libslirp-dev or however it is called) from your OS distribution and > > recompile. > > Thanks for the hint Thomas. I'm afraid many developers will miss your > email. > > Jason, Marc-André, could we improve the buildsys check or display > a more helpful information from the code instead? It looks to me we need to improve the build. Thanks > > Thanks, > > Phil. >
Re: How I can get/dump full dtb file?
On Wed, 28 Sept 2022 at 18:27, Victor Martins wrote: > Peter Maydell escreveu no dia terça, 27/09/2022 > à(s) 16:52: >> >> > 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. > > > But, is not possible, at least, use the dtb to force the map address? > Like Memory start at 0x700 with 32GB or UART it is at 0x10008000? > Because the new SoC in FPGA will be simple (CPU+RAM+Uart+IOs). But > I need a way to control que hardware address lines. No. QEMU never uses any of the DTB to determine what its hardware emulation should be. To change the hardware emulation you need to change the C code of QEMU itself. > And a stupid question: it is possible mount the uart from virt > machine in the host OS? And after can run a application in the > host OS that can communicate to the RISC-V SoC in the QEMU using > the serial port? QEMU emulated UARTs all connect to what QEMU calls a "chardev" interface. There are a wide variety of chardevs, including one to send data to/from a TCP socket, and one to send data/to from UNIX FIFOs. Those two are usually the easiest to use for automated communication to a host OS program. -- PMM
Re: How I can get/dump full dtb file?
Peter Maydell escreveu no dia terça, 27/09/2022 à(s) 16:52: > > 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. > I see :( > > > 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@101: 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. > But, is not possible, at least, use the dtb to force the map address? Like Memory start at 0x700 with 32GB or UART it is at 0x10008000? Because the new SoC in FPGA will be simple (CPU+RAM+Uart+IOs). But I need a way to control que hardware address lines. And a stupid question: it is possible mount the uart from virt machine in the host OS? And after can run a application in the host OS that can communicate to the RISC-V SoC in the QEMU using the serial port? Maybe is ridiculous ask this, but will be great is is possible :) Best Regards > > -- PMM >
Re: If your networking is failing after updating to the latest git version of QEMU...
On 28/9/22 10:27, Thomas Huth wrote: ... it might have happened due to the removal of the "slirp" submodule from the git repository. For example if you see an error message like this: Parameter 'type' expects a netdev backend type this likely means that the "user" mode backend type is not available in your binary anymore. To fix it, simply install "libslirp-devel" (or libslirp-dev or however it is called) from your OS distribution and recompile. Thanks for the hint Thomas. I'm afraid many developers will miss your email. Jason, Marc-André, could we improve the buildsys check or display a more helpful information from the code instead? Thanks, Phil.
If your networking is failing after updating to the latest git version of QEMU...
... it might have happened due to the removal of the "slirp" submodule from the git repository. For example if you see an error message like this: Parameter 'type' expects a netdev backend type this likely means that the "user" mode backend type is not available in your binary anymore. To fix it, simply install "libslirp-devel" (or libslirp-dev or however it is called) from your OS distribution and recompile. See also the commit message here: https://gitlab.com/qemu-project/qemu/-/commit/5890258aeeba303704 Thomas
