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

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

[Michael Opdenacker]

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?

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: 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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Michael Opdenacker]

Hi Atish,

On 12/23/20 11:59 PM, Atish Patra wrote:
> 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


Good to know, many thanks. I didn't expect this. Indeed, I can dump the
DT from U-Boot using the above command.

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


Yes, I confirm that I manage to boot the kernel using $ftdcontroladdr.

I'll share the whole process again during my upcoming FOSDEM presentation.

Many thanks again. You helped a lot!

Cheers,

Michael.

-- 
Michael Opdenacker, CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv