All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Tom Rini <trini@konsulko.com>
Cc: openembedded-core@lists.openembedded.org,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64
Date: Wed, 4 Jun 2025 13:09:54 +0300	[thread overview]
Message-ID: <aEAbciwMY_LS2AMU@nuoska> (raw)
In-Reply-To: <20250528141808.GU100073@bill-the-cat>

Hi,

On Wed, May 28, 2025 at 08:18:08AM -0600, Tom Rini wrote:
> On Wed, May 28, 2025 at 09:40:59AM +0300, Mikko Rapeli wrote:
> > On Tue, May 27, 2025 at 06:51:33PM -0600, Tom Rini wrote:
> > > On Mon, May 26, 2025 at 11:35:44AM +0300, Mikko Rapeli wrote:
> > > 
> > > > Booting u-boot on qemu with kvm is currently hanging on aarch64
> > > > build host. Root cause is in u-boot and CONFIG_BLOBLIST can be
> > > > disabled as a workaround.
> > > > 
> > > > To reproduce, build on kvm enabled host where "kvm-ok"
> > > > succeeds. For example genericarm64 machine and core-image-base
> > > > should then boot with:
> > > > 
> > > > $ runqemu slirp nographic novga snapshot kvm
> > > > 
> > > > On qemuarm64, default kvm setup will boot directly to kernel
> > > > and is not affected by this. If build enables u-boot as bios
> > > > then the same issue happens.
> > > > 
> > > > Without this config workaround, the boot hangs without
> > > > any messages in qemu output but ctrl-a-c to qemu console
> > > > can shutdown the emulated machine.
> > > > 
> > > > This seems to have regressed after u-boot 2025.04 update.
> > > > KVM boot can be detected from speed, for example genericarm64
> > > > boots in 550 ms with KVM and without in over 5 seconds.
> > > > 
> > > > Fixes: [YOCTO #15872]
> > > > 
> > > > Upstream u-boot discussion:
> > > > https://lists.denx.de/pipermail/u-boot/2025-May/590101.html
> > > > 
> > > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > 
> > > I think it's a tad early to disable this. On the U-Boot side, it's being
> > > looked in to. In fact, you're saying v2025.04 is working (current
> > > release) and v2025.07-rcX is failing. At this point in the U-Boot cycle
> > > I think we'll figure out the problem and fix it. If we can't figure out
> > > how to keep all the use cases working for v2025.07 then disabling
> > > BLOBLIST here in OE can be thought on, I would expect. Thanks.
> > 
> > 2025.04 is affected by this. My wording for this is not accurate enough, sorry.
> 
> Do you have a known good version where it does work? I assume it's
> v2025.01 that does work, and an OE-specific revert of commit
> 53d5a221632e ("emulation: Use bloblist to hold tables") with appropriate
> status tags about it being discussed upstream would make the most sense.

As you suspected and Ilias bisected this to:

53d5a221632eeef7483d250fdde09bde6cb54df9 is the first bad commit
commit 53d5a221632eeef7483d250fdde09bde6cb54df9
Author: Simon Glass <sjg@chromium.org>
Date:   Fri Jan 10 17:00:17 2025 -0700
    
    emulation: Use bloblist to hold tables
    
    QEMU can have its own internal ACPI and SMBIOS tables. At present U-Boot
    copies out the SMBIOS tables but points directly to the ACPI ones.

    The ACPI tables are not aligned on a 4KB boundary, which means that UPL
    cannot use them directly, since it uses a reserved-memory node for the
    tables and that it assumed (by EDK2) to be 4KB-aligned.

    On x86, QEMU provides the tables in a mapped memory region and U-Boot
    makes use of these directly, thus making it difficult to use any common
    code.
    
    Adjust the logic to fit within the existing table-generation code. Use a
    bloblist always and ensure that the ACPI tables is placed in an aligned
    region. Set a size of 8K for QEMU. This does not actually put all the
    tables in one place, for QEMU, since it currently adds a pointer to the
    tables in QFW.
    
    On ARM, enable bloblist so that SMBIOS tables can be added to the
    bloblist.

    Signed-off-by: Simon Glass <sjg@chromium.org>

So tags v2025.01-rc4 and earlier are fine and v2025.04-rc1 and newer
are affected.

Reverting this is a bit hard due to other changes so for oe-core it's
easier to disable CONFIG_BLOBLIST where possible, on qemuarm64 and
genericarm64 (uses same qemu defconfig) yocto target machines for
example, which for testing purposes can be used with qemu and KVM.

Cheers,

-Mikko


  reply	other threads:[~2025-06-04 10:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-26  8:35 [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64 Mikko Rapeli
2025-05-26  8:35 ` [PATCH v4 2/4] qemuarm64.conf: allow overriding QB_OPT_APPEND Mikko Rapeli
2025-05-28  0:52   ` Tom Rini
2025-05-28  8:02     ` Mikko Rapeli
2025-05-28 14:15       ` Tom Rini
2025-05-26  8:35 ` [PATCH v4 3/4] oeqa decorator/data.py: add skipIfNotBuildArch decorator Mikko Rapeli
2025-05-26  8:35 ` [PATCH v4 4/4] oeqa selftest uboot.py: add qemu KVM test case Mikko Rapeli
2025-05-28  0:51 ` [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64 Tom Rini
2025-05-28  6:40   ` Mikko Rapeli
2025-05-28 14:18     ` Tom Rini
2025-06-04 10:09       ` Mikko Rapeli [this message]
2025-06-04 13:08         ` Ilias Apalodimas

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=aEAbciwMY_LS2AMU@nuoska \
    --to=mikko.rapeli@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=trini@konsulko.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.