From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: poky@lists.yoctoproject.org
Subject: Re: [poky] [PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass
Date: Wed, 11 Mar 2026 14:10:22 +0200 [thread overview]
Message-ID: <abFbrkd8o7iYxUkF@nuoska> (raw)
In-Reply-To: <f3f3d82f4f70370b4904d65467748210e5cd1c84.camel@linuxfoundation.org>
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
next prev parent reply other threads:[~2026-03-11 12:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 11:36 [PATCH] genericarm64.conf: fix qemu testing with testimage.bbclass Mikko Rapeli
2026-03-11 11:53 ` [poky] " Richard Purdie
2026-03-11 12:10 ` Mikko Rapeli [this message]
2026-03-11 12:13 ` Richard Purdie
2026-03-11 12:18 ` Mikko Rapeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abFbrkd8o7iYxUkF@nuoska \
--to=mikko.rapeli@linaro.org \
--cc=poky@lists.yoctoproject.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox