No device tree source for the QEMU Risc-V virt board?

[Atish Patra]

On Wed, Dec 23, 2020 at 12:22 PM Michael Opdenacker
<michael.opdenacker at bootlin.com> wrote:
>
> Greetings,
>
> I struggled to get Linux to boot from U-Boot on the QEMU Risc-V virt
> board. I know that I can boot Linux directly, and this is well
> documented, but booting U-Boot first and then Linux was much harder and
> not really documented (at least according to what I found).
>
> I believe that booting Linux from U-Boot is better in terms of
> demonstrating a more realistic Risc-V system, that's why I wanted to do
> this.
>
> One of the issues that I got was that U-Boot didn't want to boot the
> kernel binary without a DTB. However, I didn't find any corresponding DT
> sources in the Linux sources. To get a working DTB, I had to boot Linux
> directly, and then get the "/sys/firmware/fdt" file contents! Would you
> have any other way to suggest to make me prouder?
>

Copy pasting my explanation from sw-dev to avoid redundant replies,

You shouldn't have to do that. The DTB is copied a few times during the boot.
In RISC-V, every boot loader stage passes the memory address of DTB in a1.
Thus, Qemu loader will pass the DTB address in a1 to OpenSBI and
OpenSBI passes that to U-Boot via a1.
Before that, OpenSBI may copy the DTB depending on the firmware type
(fw_jump or fw_dynamic).
U-Boot relocates the DT the $fdtcontroladdr. You can verify the
correct fdt by doing the following at U-Boot prompt.

<AT U-Boot prompt>
#fdt addr $fdtcontroladdr
#fdt print

Depending on how you have configured U-Boot, it may again need to be
copied to fdt_addr_r if that's the address
you are using while using booti/bootm command so that Linux kernel
gets the correct DTB address in a1.

> For people interested in doing the same thing, here are my raw notes...
>
> Thanks in advance for your insights about the QEMU virt board DTB. I'm
> probably missing something.
>
> Cheers,
>
> Michael.
>
> ---
>
> QEMU Risc-V instructions
> For booting Linux from U-Boot in QEMU's virt machine
>
>
> Linux (5.10.0)
> export ARCH=riscv
> make defconfig
> make -j8 Image
>
> Create a disk image with 2 partitions, to mimic a real-life case:
> - A fat32 one (for the kernel and DTB)
> - An ext2 or ext4 one (for the root fs)
>
> To boot this kernel from QEMU, I need to compile opensbi for Linux
> cd opensbi
> make PLATFORM=generic FW_PAYLOAD_PATH=../linux/arch/arm/boot/Image
>
> Boot ing Linux directly:
> qemu-system-riscv64 -M virt -m 2G -nographic -kernel
> opensbi/build/platform/generic/firmware/fw_payload.elf -device
> virtio-blk-device,drive=hd0 -drive file=disk.img,format=raw,id=hd0
> -append "console=ttyS0 rw root=/dev/vda2 earlycon=sbi"
>
> From the booted system, copy /sys/firmware/fdt to the first partition of
> the virtio drive, naming the file "dtb". Why don't we get one from the
> Linux kernel sources?
>
> Now, we can prepare U-Boot for booting Linux. Without a dtb, U-Boot
> refused to start the Linux kernel.
>
> U-Boot (c15f44acf9d473f4682bfdc63b8aebd313492b15, 2021.04-rc4)
>
> cd u-boot
> make qemu-riscv64_smode_defconfig
>
> Modify the configuration to support loading an environment from a FAT
> partition on a virtio disk. That's closer to real life:
> CONFIG_ENV_IS_IN_FAT=y
> CONFIG_ENV_FAT_INTERFACE="virtio"
> CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> make -j 8
>
> Now, let's compile opensbi again:
> cd opensbi
> make clean
> make PLATFORM=generic FW_PAYLOAD_PATH=../u-boot/u-boot.bin
>
> We can now boot U-Boot:
> qemu-system-riscv64 -M virt -m 2G -nographic -bios
> opensbi/build/platform/generic/firmware/fw_payload.elf -device
> virtio-blk-device,drive=hd0 -drive file=disk.img,format=raw,id=hd0
>
> The first time, interrupt the U-Boot countdown and set environment
> variables:
> setenv bootcmd 'fatload virtio 0:1 80200000 Image; fatload virtio 0:1
> 0x82000000 dtb; booti 0x80200000 - 0x82000000'
> setenv bootargs 'root=/dev/vda2 rootwait console=ttyS0
> earlycon=sbiroot=/dev/vda2 rootwait console=ttyS0 earlycon=sbi'
> saveenv
>
> You can now restart QEMU and Linux boots!
>
> --
> Michael Opdenacker, CEO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish