Re: How I can get/dump full dtb file?

[Victor Martins]

Peter Maydell <peter.maydell@linaro.org> escreveu no dia terça, 27/09/2022 à(s) 10:27:

On Mon, 26 Sept 2022 at 20:39, Victor Martins <vmartins@lisha.ufsc.br> 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