Re: [PATCH 6/8] docs/system/riscv: sifive_u: Document '-dtb' usage

[Alistair Francis]

On Mon, Mar 29, 2021 at 1:27 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Update the 'sifive_u' machine documentation to mention the '-dtb'
> option that can be used to pass a custom DTB to QEMU.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

> ---
>
>  docs/system/riscv/sifive_u.rst | 47 +++++++++++++++++++++++++++++-----
>  1 file changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/docs/system/riscv/sifive_u.rst b/docs/system/riscv/sifive_u.rst
> index dcdfbda931..32d0a1b85d 100644
> --- a/docs/system/riscv/sifive_u.rst
> +++ b/docs/system/riscv/sifive_u.rst
> @@ -36,12 +36,21 @@ Hardware configuration information
>  ----------------------------------
>
>  The ``sifive_u`` machine automatically generates a device tree blob ("dtb")
> -which it passes to the guest. This provides information about the addresses,
> -interrupt lines and other configuration of the various devices in the system.
> -Guest software should discover the devices that are present in the generated
> -DTB instead of using a DTB for the real hardware, as some of the devices are
> -not modeled by QEMU and trying to access these devices may cause unexpected
> -behavior.
> +which it passes to the guest, if there is no ``-dtb`` option. This provides
> +information about the addresses, interrupt lines and other configuration of
> +the various devices in the system. Guest software should discover the devices
> +that are present in the generated DTB instead of using a DTB for the real
> +hardware, as some of the devices are not modeled by QEMU and trying to access
> +these devices may cause unexpected behavior.
> +
> +If users want to provide their own DTB, they can use the ``-dtb`` option.
> +These DTBs should have the following requirements:
> +
> +* The /cpus node should contain at least one subnode for E51 and the number
> +  of subnodes should match QEMU's ``-smp`` option
> +* The /memory reg size should match QEMU’s selected ram_size via ``-m``
> +* Should contain a node for the CLINT device with a compatible string
> +  "riscv,clint0" if using with OpenSBI BIOS images
>
>  Boot options
>  ------------
> @@ -122,6 +131,32 @@ To boot the newly built Linux kernel in QEMU with the 
> ``sifive_u`` machine:
>        -initrd /path/to/rootfs.ext4 \
>        -append "root=/dev/ram"
>
> +Alternatively, we can use a custom DTB to boot the machine by inserting a 
> CLINT
> +node in fu540-c000.dtsi in the Linux kernel,
> +
> +.. code-block:: none
> +
> +    clint: clint@2000000 {
> +        compatible = "riscv,clint0";
> +        interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
> +                               &cpu1_intc 3 &cpu1_intc 7
> +                               &cpu2_intc 3 &cpu2_intc 7
> +                               &cpu3_intc 3 &cpu3_intc 7
> +                               &cpu4_intc 3 &cpu4_intc 7>;
> +        reg = <0x00 0x2000000 0x00 0x10000>;
> +    };
> +
> +with the following command line options:
> +
> +.. code-block:: bash
> +
> +  $ qemu-system-riscv64 -M sifive_u -smp 5 -m 8G \
> +      -display none -serial stdio \
> +      -kernel arch/riscv/boot/Image \
> +      -dtb arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb \
> +      -initrd /path/to/rootfs.ext4 \
> +      -append "root=/dev/ram"
> +
>  To build a Linux mainline kernel that can be booted by the ``sifive_u`` 
> machine
>  in 32-bit mode, use the rv32_defconfig configuration. A patch is required to
>  fix the 32-bit boot issue for Linux kernel v5.10.
> --
> 2.25.1
>
>