[v5,2/4] qemuarm64.conf: allow overriding QB_OPT_APPEND

It enables qemu USB support which causes a reset
loop currently with u-boot.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/conf/machine/qemuarm64.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Tue, 2025-05-27 at 12:07 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> It enables qemu USB support which causes a reset
> loop currently with u-boot.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/conf/machine/qemuarm64.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
> index d310445a34..f086729641 100644
> --- a/meta/conf/machine/qemuarm64.conf
> +++ b/meta/conf/machine/qemuarm64.conf
> @@ -20,7 +20,7 @@ QB_SMP ?= "-smp 4"
>  QB_CPU_KVM = "-cpu host -machine gic-version=3"
>  # For graphics to work we need to define the VGA device as well as the necessary USB devices
>  QB_GRAPHICS = "-device virtio-gpu-pci"
> -QB_OPT_APPEND = "-device qemu-xhci -device usb-tablet -device usb-kbd"
> +QB_OPT_APPEND ?= "-device qemu-xhci -device usb-tablet -device usb-kbd"
>  # Virtio Networking support
>  QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
>  QB_NETWORK_DEVICE = "-device virtio-net-pci,netdev=net0,mac=@MAC@"

I am very worried about merging patches specifically to disable usb
(here and in the selftest) since that is something we expect to work to
allow the graphics images to work properly.

Is there an upstream discussion about why usb causes the hang and/or
any estimate on when it might get fixed? I'm partly tempted to revert
the uboot version instead of this.

Cheers,

Richard

Hi,

On Tue, May 27, 2025 at 12:53:20PM +0100, Richard Purdie wrote:
> On Tue, 2025-05-27 at 12:07 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> > It enables qemu USB support which causes a reset
> > loop currently with u-boot.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > �meta/conf/machine/qemuarm64.conf | 2 +-
> > �1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
> > index d310445a34..f086729641 100644
> > --- a/meta/conf/machine/qemuarm64.conf
> > +++ b/meta/conf/machine/qemuarm64.conf
> > @@ -20,7 +20,7 @@ QB_SMP ?= "-smp 4"
> > �QB_CPU_KVM = "-cpu host -machine gic-version=3"
> > �# For graphics to work we need to define the VGA device as well as the necessary USB devices
> > �QB_GRAPHICS = "-device virtio-gpu-pci"
> > -QB_OPT_APPEND = "-device qemu-xhci -device usb-tablet -device usb-kbd"
> > +QB_OPT_APPEND ?= "-device qemu-xhci -device usb-tablet -device usb-kbd"
> > �# Virtio Networking support
> > �QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
> > �QB_NETWORK_DEVICE = "-device virtio-net-pci,netdev=net0,mac=@MAC@"
> 
> I am very worried about merging patches specifically to disable usb
> (here and in the selftest) since that is something we expect to work to
> allow the graphics images to work properly.
>
> Is there an upstream discussion about why usb causes the hang and/or
> any estimate on when it might get fixed? I'm partly tempted to revert
> the uboot version instead of this.

Please allow downstream configurations to override this. They may not
care about USB emulation with qemu/runqemu. Several layers try to
build upon qemuarm64 oe-core machine but may need to tweak things
to get to a working test setup.

With Linux kernel AFAIK qemu USB works well, and qemu itself.
u-boot is a different beast but we have developers working
on improving the situation and I've notified them of this
easy to test scenario. u-boot side needs to sync the USB
stack with Linux kernel side changes and this is not a small
task. Sadly no upstream discussion link currently.

Not a perfect answer but better than nothing I hope.

Cheers,

-Mikko

Hi,

On Tue, May 27, 2025 at 12:53:20PM +0100, Richard Purdie wrote:
> On Tue, 2025-05-27 at 12:07 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> > It enables qemu USB support which causes a reset
> > loop currently with u-boot.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > �meta/conf/machine/qemuarm64.conf | 2 +-
> > �1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
> > index d310445a34..f086729641 100644
> > --- a/meta/conf/machine/qemuarm64.conf
> > +++ b/meta/conf/machine/qemuarm64.conf
> > @@ -20,7 +20,7 @@ QB_SMP ?= "-smp 4"
> > �QB_CPU_KVM = "-cpu host -machine gic-version=3"
> > �# For graphics to work we need to define the VGA device as well as the necessary USB devices
> > �QB_GRAPHICS = "-device virtio-gpu-pci"
> > -QB_OPT_APPEND = "-device qemu-xhci -device usb-tablet -device usb-kbd"
> > +QB_OPT_APPEND ?= "-device qemu-xhci -device usb-tablet -device usb-kbd"
> > �# Virtio Networking support
> > �QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
> > �QB_NETWORK_DEVICE = "-device virtio-net-pci,netdev=net0,mac=@MAC@"
> 
> I am very worried about merging patches specifically to disable usb
> (here and in the selftest) since that is something we expect to work to
> allow the graphics images to work properly.
> 
> Is there an upstream discussion about why usb causes the hang and/or
> any estimate on when it might get fixed? I'm partly tempted to revert
> the uboot version instead of this.

I've reported this to upstream u-boot list now
https://lists.denx.de/pipermail/u-boot/2025-June/591233.html

The bisection points at enabling USB support for qemu so
the issue seems to have always been there and possibly
quite fundamental.

Would it be acceptable to disable USB support in
qemuarm64/genericarm64 u-boot as a workaround while
keeping USB in qemu?

I tested this and qemu USB devices were still
detected in by Linux kernel and u-boot just ignored them.

So for u-boot aarch64 KVM support under qemu, both
CONFIG_BLOBLIST and CONFIG_USB currently need to be
disabled. Both issues reported to upstream and hopefully
better fixes get developed. We could apply the workarounds
on qemuarm64 and genericarm64 and improve testing to cover
KVM u-boot with qemu. KVM could improve qemu testing times a
lot on aarch64/qemuarm64/genericarm64.

Cheers,

-Mikko