[PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass

[PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass

[Mikko Rapeli]

genericarm64 machine has supported qemu for a long time but
the default build config failed with testimage.bbclass to boot
and run oeqa runtime tests.

TESTIMAGEDEPENDS needs qemu utilities so that they are correctly
installed to image sysroot. For qemu machines these are set in
testimage.bbclass but remain unset for non-qemu machines like
genericarm64.

TEST_RUNQEMUPARAMS needs snapshot since default genericarm64 image
is a compressed wic.zst, nographic to run qemu without connected
display which is better on headless build machines, and slirp which
also works on much broader set of build machines than the default
tap networking.

With these set, default genericarm64 core-image-sato boots correctly
with testimage.bbclass and all oeqa runtime tests pass on an x86_64
build machine:

$ bitbake core-image-sato && bitbake -c testimage core-image-sato
...
SUMMARY:
core-image-sato () - Ran 75 tests in 229.248s
core-image-sato - OK - All required tests passed (successes=24,
skipped=51, failures=0, errors=0)
NOTE: Tasks Summary: Attempted 1558 tasks of which 1556 didn't need to
be rerun and all succeeded.

To boot qemu manually:

$ runqemu slirp nographic snapshot core-image-sato

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta-yocto-bsp/conf/machine/genericarm64.conf | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta-yocto-bsp/conf/machine/genericarm64.conf b/meta-yocto-bsp/conf/machine/genericarm64.conf
index 2b1ce4bdd02b..e3bc0064e96b 100644
--- a/meta-yocto-bsp/conf/machine/genericarm64.conf
+++ b/meta-yocto-bsp/conf/machine/genericarm64.conf
@@ -73,5 +73,9 @@ QB_TCPSERIAL_OPT ?= "-device virtio-serial-pci -chardev socket,id=virtcon,port=@
 # Virtio networking
 QB_TAP_OPT ?= "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
 
+# default to slirp and no graphic to work on headless build machines using testimage.bbclass
+TEST_RUNQEMUPARAMS ?= "slirp nographic snapshot"
+# basic qemu testimage.bbclass support
+TESTIMAGEDEPENDS:append = " qemu-native:do_populate_sysroot qemu-helper-native:do_populate_sysroot qemu-helper-native:do_addto_recipe_sysroot"
 # If we're running testimage then we're in a qemu, so ensure u-boot is build
 TESTIMAGEDEPENDS:append = " u-boot:do_deploy"
-- 
2.34.1

Re: [poky] [PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass

[Richard Purdie]

On Wed, 2026-03-11 at 13:36 +0200, Mikko Rapeli via lists.yoctoproject.org wrote:
> genericarm64 machine has supported qemu for a long time but
> the default build config failed with testimage.bbclass to boot
> and run oeqa runtime tests.

The key question is whether genericarm64 is meant for real hardware or
qemu.

When you run testimage against an image, the assumption has been it
would be a real hardware setup, not a qemu one. If you wanted qemu,
you'd have used qemuarm64.

These changes are basically turning genericarm64 into qemuarm64 :/.

> TESTIMAGEDEPENDS needs qemu utilities so that they are correctly
> installed to image sysroot. For qemu machines these are set in
> testimage.bbclass but remain unset for non-qemu machines like
> genericarm64.

This is going to be annoying if you're trying to test real hardware
with testimage. I can see the arguments both ways. This is one of the
differences between the two machines though and I'm not sure it makes
sense to make them match.

> TEST_RUNQEMUPARAMS needs snapshot since default genericarm64 image
> is a compressed wic.zst, nographic to run qemu without connected
> display which is better on headless build machines, and slirp which
> also works on much broader set of build machines than the default
> tap networking.

You shouldn't need to use nographic with the changes I'm proposing to
how runqemu is working, even on a headless system.

slirp, is a preference thing and I'd like to stay consistent between
the qemu setups. It is not the default.

snapshot is probably the one setting I think we should have as default
for the reason you mention.


Cheers,

Richard

Re: [poky] [PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass

[Mikko Rapeli]

Hi,

On Wed, Mar 11, 2026 at 11:53:25AM +0000, Richard Purdie wrote:
> On Wed, 2026-03-11 at 13:36 +0200, Mikko Rapeli via lists.yoctoproject.org wrote:
> > genericarm64 machine has supported qemu for a long time but
> > the default build config failed with testimage.bbclass to boot
> > and run oeqa runtime tests.
> 
> The key question is whether genericarm64 is meant for real hardware or
> qemu.

Both, this has always been the case.

> When you run testimage against an image, the assumption has been it
> would be a real hardware setup, not a qemu one. If you wanted qemu,
> you'd have used qemuarm64.

Not true, real target images can be booted with qemu if there is enough
BSP side support for qemu HW and if config options for qemu etc are
correct.

> These changes are basically turning genericarm64 into qemuarm64 :/.

This has always been the case.

> > TESTIMAGEDEPENDS needs qemu utilities so that they are correctly
> > installed to image sysroot. For qemu machines these are set in
> > testimage.bbclass but remain unset for non-qemu machines like
> > genericarm64.
> 
> This is going to be annoying if you're trying to test real hardware
> with testimage. I can see the arguments both ways. This is one of the
> differences between the two machines though and I'm not sure it makes
> sense to make them match.

On genericarm64 which I help maintain, I will instruct real HW testing
to use testexport.bbclass. Real target HW is rarely next to the build
machines so using the exported test framework to run the tests is
preferred. In our test automation builds we do this and I can make the
testexport.bbclass default on all generiarm64 builds.

> > TEST_RUNQEMUPARAMS needs snapshot since default genericarm64 image
> > is a compressed wic.zst, nographic to run qemu without connected
> > display which is better on headless build machines, and slirp which
> > also works on much broader set of build machines than the default
> > tap networking.
> 
> You shouldn't need to use nographic with the changes I'm proposing to
> how runqemu is working, even on a headless system.

nographic works out the box now and all tests pass. Same with
runqemu, nographic boot works well on headless console machines
already now.

> slirp, is a preference thing and I'd like to stay consistent between
> the qemu setups. It is not the default.

It is the default on all builds and configuration I use and on meta-arm
so I would rather set this by default for genericarm64. Since yocto
upstream does not test genericarm64 I think this should be the default.

Cheers,

-Mikko

Re: [poky] [PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass

[Richard Purdie]

On Wed, 2026-03-11 at 14:10 +0200, Mikko Rapeli wrote:
> > slirp, is a preference thing and I'd like to stay consistent
> > between
> > the qemu setups. It is not the default.
> 
> It is the default on all builds and configuration I use and on meta-
> arm so I would rather set this by default for genericarm64. Since
> yocto upstream does not test genericarm64 I think this should be the
> default.

I don't, sorry.

I've made my views on slirp and various other aspects of this clear
multiple times. I'm wading into this again.

Cheers,

Richard

Re: [poky] [PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass

[Mikko Rapeli]

Hi,

On Wed, Mar 11, 2026 at 12:13:44PM +0000, Richard Purdie wrote:
> On Wed, 2026-03-11 at 14:10 +0200, Mikko Rapeli wrote:
> > > slirp, is a preference thing and I'd like to stay consistent
> > > between
> > > the qemu setups. It is not the default.
> > 
> > It is the default on all builds and configuration I use and on meta-
> > arm so I would rather set this by default for genericarm64. Since
> > yocto upstream does not test genericarm64 I think this should be the
> > default.
> 
> I don't, sorry.
> 
> I've made my views on slirp and various other aspects of this clear
> multiple times. I'm wading into this again.

Understood. Are there some current issues with slirp in oeqa
selftests like runqemu, runtime_test, sdk or uki?

These are testing that slirp networking continues to work and AFAIK
there have not been issues with the tests lately on any qemu machines
tested on oe-core autobuilders.

Sad but I will drop this in v2.

Cheers,

-Mikko