qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: How I can get/dump full dtb file?
Date: Tue, 27 Sep 2022 10:26:53 +0100

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

> 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.

(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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]