Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 3/3] oeqa selftest uboot.py: add qemu KVM test case
Date: Mon, 26 May 2025 11:45:21 +0300	[thread overview]
Message-ID: <aDQqIZgXepLP3xXD@nuoska> (raw)
In-Reply-To: <18422DAC420B1606.3062@lists.openembedded.org>

Hi,

On Fri, May 23, 2025 at 05:16:58PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> On Fri, May 23, 2025 at 03:15:51PM +0200, Mathieu Dubois-Briand wrote:
> > On Thu May 22, 2025 at 3:41 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
> > > Add a test case to boot target system via u-boot
> > > using qemu with KVM. This was broken recently
> > > and workaround proposed to u-boot. Test case
> > > works with genericarm64 and qemuarm64 target machines
> > > compiled and tested on aarch64 build host with KVM
> > > support.
> > >
> > > Test execution time with full sstate cache is
> > > around 170 seconds. qemu boot itself takes just
> > > a few seconds to full userspace.
> > >
> > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > ---
> > 
> > Hi Mikko,
> > 
> > I saw your other mail saying you will make an update, but as I had
> > already picked these patches, here is the build result: the selftest is
> > failing on armhost:
> > 
> > ---
> > 2025-05-23 08:50:18,542 - oe-selftest - INFO - uboot.UBootTest.test_boot_uboot_kvm_to_full_target (subunit.RemotedTestCase)
> > 2025-05-23 08:50:18,543 - oe-selftest - INFO -  ... ERROR
> > ...
> > QEMU 10.0.0 monitor - type 'help' for more information
> > (qemu)
> > Waiting at most 1000 seconds for login banner (05/23/25 08:33:29)
> > Connection from 127.0.0.1:43786
> > Target didn't reach login banner in 1000 seconds (05/23/25 08:50:12)
> > Last 25 lines of login console (1721):
> > Scanning bootdev 'virtio-blk#36.bootdev':
> > Scanning bootdev 'virtio-net#32.bootdev':
> > BOOTP broadcast 1
> > ...
> > BOOTP broadcast 17
> > 
> > Retry time exceeded; starting again
> > No more bootdevs
> > ---  -----------  ------  --------  ----  ------------------------  ----------------
> > (1 bootflow, 1 valid)
> > =>
> > ...
> > RuntimeError: core-image-minimal - FAILED to start qemu - check the task log and the boot log
> > ---
> > 
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1749
> 
> Thanks, I will take a look. Boot to u-boot seems to ok so KVM is working on
> the aarch64 build machine but something in wic image ESP partition detection is not
> working in the same way as on my aarch64 build machine and qemuarm64 and
> genericarm64 configs.
> 
> I will compare the runqemu and qemu-system-aarch64 arguments to figure out what is
> different.
> 
> One problem I thought I solved was to change from virtio scsi to virtio blk emulation
> but that seems to be effecttive albeit with a warning:
> 
> https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/2468510/raw_inline
> 
> runqemu - WARNING - Unknown QB_DRIVE_TYPE: vd
> runqemu - WARNING - Failed to figure out drive type, consider define or fix QB_DRIVE_TYPE
> runqemu - WARNING - Trying to use virtio block drive
> 
> u-boot defconfig does not have scsi support but virtio blk works for disk with ESP
> partition in fat format.

I reviewed the runqemu and qemu-system-aarch64 arguments but could not see major differences.
One difference is that autobuilder runs with tap and I with slirp networking, but that
should not affect rootfs/ESP partition detection in u-boot. I've sent out v4 now.
If this still fails on autobuilder, then I'd need know what config fragments
are applied. I've configured qemuarm64 and genericarm64 with
". oe-init-build-env" and then added TEST_RUNQEMUPARAMS += "slirp"
and SANITY_TESTED_DISTROS = "" to conf/local.conf. Maybe autobuilder
scripts add something more.

Cheers,

-Mikko


  parent reply	other threads:[~2025-05-26  8:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-22 13:41 [PATCH v3 1/3] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64 Mikko Rapeli
2025-05-22 13:41 ` [PATCH 2/3] qemuarm64.conf: allow overriding QB_OPT_APPEND Mikko Rapeli
2025-05-22 13:41 ` [PATCH 3/3] oeqa selftest uboot.py: add qemu KVM test case Mikko Rapeli
2025-05-23 13:15   ` [OE-core] " Mathieu Dubois-Briand
2025-05-23 14:16     ` Mikko Rapeli
     [not found]     ` <18422DAC420B1606.3062@lists.openembedded.org>
2025-05-26  8:45       ` Mikko Rapeli [this message]
2025-05-27  6:34         ` Mathieu Dubois-Briand
2025-05-27  7:17           ` Mikko Rapeli
2025-05-27  7:43             ` Mathieu Dubois-Briand
2025-05-27  8:54               ` Mikko Rapeli
2025-05-27  9:37                 ` Mathieu Dubois-Briand
2025-05-27  9:55                   ` Mikko Rapeli
2025-05-27  9:36               ` Mathieu Dubois-Briand
2025-05-27  9:52                 ` Mikko Rapeli
     [not found] ` <1841DD2A7A0AA7E1.3062@lists.openembedded.org>
2025-05-23  9:42   ` 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=aDQqIZgXepLP3xXD@nuoska \
    --to=mikko.rapeli@linaro.org \
    --cc=mathieu.dubois-briand@bootlin.com \
    --cc=openembedded-core@lists.openembedded.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