diff mbox series

genericarm64: add qemuboot configuration

Message ID 20240322165009.3704771-1-ross.burton@arm.com (mailing list archive)
State New
Headers show
Series genericarm64: add qemuboot configuration | expand

Commit Message

Ross Burton March 22, 2024, 4:50 p.m. UTC
From: Ross Burton <ross.burton@arm.com>

A basic SystemReady IR system can be provided by qemu-system-aarch64
and u-boot, so tell u-boot to build the qemu_arm64 machine and configure
qemuboot to start that u-boot and search the virtio-attached wic image
for the EFI boot partition.

Currently this machine support emulated (Cortex-A76) and virtualised (KVM)
execution, and virtio storage/network/console.  Display support will be
added shortly.

Note that this machine still doesn't build U-Boot by default, as a u-boot
binary for qemu in deploy would potentially confuse users who want to
boot on real hardware and think this u-boot is needed.  If you wish to
use genericarm64 with runqemu, you'll need to manually bitbake u-boot.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta-yocto-bsp/conf/machine/genericarm64.conf | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)

Comments

Jose Quaresma March 22, 2024, 5:02 p.m. UTC | #1
Hi Ross,

Ross Burton <ross.burton@arm.com> escreveu (sexta, 22/03/2024 à(s) 16:50):

> From: Ross Burton <ross.burton@arm.com>
>
> A basic SystemReady IR system can be provided by qemu-system-aarch64
> and u-boot, so tell u-boot to build the qemu_arm64 machine and configure
> qemuboot to start that u-boot and search the virtio-attached wic image
> for the EFI boot partition.
>
> Currently this machine support emulated (Cortex-A76) and virtualised (KVM)
> execution, and virtio storage/network/console.  Display support will be
> added shortly.
>
> Note that this machine still doesn't build U-Boot by default, as a u-boot
> binary for qemu in deploy would potentially confuse users who want to
> boot on real hardware and think this u-boot is needed.  If you wish to
> use genericarm64 with runqemu, you'll need to manually bitbake u-boot.
>

Why not have a new genericarm64-qemu.conf machine which includes this
machine
and adds all the required qemu bits.
In my opinion, this would be more friendly and clear.

Jose


>
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  meta-yocto-bsp/conf/machine/genericarm64.conf | 27 +++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/meta-yocto-bsp/conf/machine/genericarm64.conf
> b/meta-yocto-bsp/conf/machine/genericarm64.conf
> index 7c4c76ffe0c..4afd6c3a870 100644
> --- a/meta-yocto-bsp/conf/machine/genericarm64.conf
> +++ b/meta-yocto-bsp/conf/machine/genericarm64.conf
> @@ -29,3 +29,30 @@ EFI_PROVIDER ?=
> "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boo
>
>  # Try to bring up one physical serial console, or a virtualized serial
> console
>  SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
> +
> +# Allow u-boot to be built for use with qemu-system-aarch64.
> +# This u-boot is _not_ suitable for use with real hardware, and the
> expectation
> +# of this machine is that real hardware comes with the firmware
> pre-loaded.
> +UBOOT_MACHINE = "qemu_arm64_defconfig"
> +
> +# runqemu configuration to run a genericarm64 image inside a
> qemu-system-aarch64. You will need
> +# to build u-boot explicitly.
> +IMAGE_CLASSES += "qemuboot"
> +QB_SYSTEM_NAME = "qemu-system-aarch64"
> +# Boot the virtual machine with either an emulated Cortex-A76, or the
> host if using KVM
> +QB_MACHINE = "-machine virt"
> +QB_CPU = "-cpu cortex-a76"
> +QB_CPU_KVM = "-cpu host -machine gic-version=3"
> +QB_SMP = "-smp 4"
> +# Boot into U-Boot and let that scan the disk for the next step, don't
> pass any kernel or filesystem hints
> +QB_DEFAULT_BIOS = "u-boot.bin"
> +QB_DEFAULT_KERNEL = "none"
> +QB_DEFAULT_FSTYPE = "wic"
> +QB_FSINFO = "wic:no-kernel-in-fs"
> +# Mount the wic rootfs as a virtio block device
> +QB_ROOTFS_OPT = "-drive id=root,file=@ROOTFS@,if=none,format=raw -device
> virtio-blk-pci,drive=root"
> +# Virtio serial consoles
> +QB_SERIAL_OPT = "-device virtio-serial-pci -chardev null,id=virtcon
> -device virtconsole,chardev=virtcon"
> +QB_TCPSERIAL_OPT = "-device virtio-serial-pci -chardev
> socket,id=virtcon,port=@PORT@,host=127.0.0.1,nodelay=on -device
> virtconsole,chardev=virtcon"
> +# Virtio networking
> +QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
> --
> 2.34.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#13312):
> https://lists.yoctoproject.org/g/poky/message/13312
> Mute This Topic: https://lists.yoctoproject.org/mt/105089249/5052612
> Group Owner: poky+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/poky/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
Ross Burton March 22, 2024, 5:09 p.m. UTC | #2
On 22 Mar 2024, at 17:02, Jose Quaresma <quaresma.jose@gmail.com> wrote:
> Why not have a new genericarm64-qemu.conf machine which includes this machine
> and adds all the required qemu bits.
> In my opinion, this would be more friendly and clear.

Because two machines are more annoying, there’s no need.  This is what we had for generic-arm64 and qemu-generic-arm64 in meta-arm, but that was mainly because that also built TF-A/OP-TEE/EDK2, all of which is pointless in a real hardware environment. 

Arguably we could just always build u-boot for qemu and hope nobody gets confused with there being a u-boot binary in the deploy directory, but that feels like it’s asking for trouble.

Ross
Jose Quaresma March 26, 2024, 10:59 a.m. UTC | #3
Ross Burton <Ross.Burton@arm.com> escreveu (sexta, 22/03/2024 à(s) 17:09):

> On 22 Mar 2024, at 17:02, Jose Quaresma <quaresma.jose@gmail.com> wrote:
> > Why not have a new genericarm64-qemu.conf machine which includes this
> machine
> > and adds all the required qemu bits.
> > In my opinion, this would be more friendly and clear.
>
> Because two machines are more annoying, there’s no need.  This is what we
> had for generic-arm64 and qemu-generic-arm64 in meta-arm, but that was
> mainly because that also built TF-A/OP-TEE/EDK2, all of which is pointless
> in a real hardware environment.
>
> Arguably we could just always build u-boot for qemu and hope nobody gets
> confused with there being a u-boot binary in the deploy directory, but that
> feels like it’s asking for trouble.
>
> Ross


I agree that always building u-boot can cause some confusion so it's better
to keep the real machine the primary target.

Jose
diff mbox series

Patch

diff --git a/meta-yocto-bsp/conf/machine/genericarm64.conf b/meta-yocto-bsp/conf/machine/genericarm64.conf
index 7c4c76ffe0c..4afd6c3a870 100644
--- a/meta-yocto-bsp/conf/machine/genericarm64.conf
+++ b/meta-yocto-bsp/conf/machine/genericarm64.conf
@@ -29,3 +29,30 @@  EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boo
 
 # Try to bring up one physical serial console, or a virtualized serial console
 SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
+
+# Allow u-boot to be built for use with qemu-system-aarch64.
+# This u-boot is _not_ suitable for use with real hardware, and the expectation
+# of this machine is that real hardware comes with the firmware pre-loaded.
+UBOOT_MACHINE = "qemu_arm64_defconfig"
+
+# runqemu configuration to run a genericarm64 image inside a qemu-system-aarch64. You will need
+# to build u-boot explicitly.
+IMAGE_CLASSES += "qemuboot"
+QB_SYSTEM_NAME = "qemu-system-aarch64"
+# Boot the virtual machine with either an emulated Cortex-A76, or the host if using KVM
+QB_MACHINE = "-machine virt"
+QB_CPU = "-cpu cortex-a76"
+QB_CPU_KVM = "-cpu host -machine gic-version=3"
+QB_SMP = "-smp 4"
+# Boot into U-Boot and let that scan the disk for the next step, don't pass any kernel or filesystem hints
+QB_DEFAULT_BIOS = "u-boot.bin"
+QB_DEFAULT_KERNEL = "none"
+QB_DEFAULT_FSTYPE = "wic"
+QB_FSINFO = "wic:no-kernel-in-fs"
+# Mount the wic rootfs as a virtio block device
+QB_ROOTFS_OPT = "-drive id=root,file=@ROOTFS@,if=none,format=raw -device virtio-blk-pci,drive=root"
+# Virtio serial consoles
+QB_SERIAL_OPT = "-device virtio-serial-pci -chardev null,id=virtcon -device virtconsole,chardev=virtcon"
+QB_TCPSERIAL_OPT = "-device virtio-serial-pci -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1,nodelay=on -device virtconsole,chardev=virtcon"
+# Virtio networking
+QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"