[PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64

[PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64

[Mikko Rapeli]

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>
---
 meta/recipes-bsp/u-boot/files/disable-CONFIG_BLOBLIST.cfg | 1 +
 meta/recipes-bsp/u-boot/u-boot-common.inc                 | 4 ++++
 2 files changed, 5 insertions(+)
 create mode 100644 meta/recipes-bsp/u-boot/files/disable-CONFIG_BLOBLIST.cfg

v4: no changes, posted together with selftest for feature

v3: added u-boot discussion link to commit message
    https://lists.openembedded.org/g/openembedded-core/message/217105

v2: applying to genericarm64 and qemuarm64 machines only
    https://lists.openembedded.org/g/openembedded-core/message/217054

v1: https://lists.openembedded.org/g/openembedded-core/message/217030

diff --git a/meta/recipes-bsp/u-boot/files/disable-CONFIG_BLOBLIST.cfg b/meta/recipes-bsp/u-boot/files/disable-CONFIG_BLOBLIST.cfg
new file mode 100644
index 0000000000..d01d3d12d8
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/files/disable-CONFIG_BLOBLIST.cfg
@@ -0,0 +1 @@
+# CONFIG_BLOBLIST is not set
diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc b/meta/recipes-bsp/u-boot/u-boot-common.inc
index fd1eab5cdd..a77c49cb8b 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -16,6 +16,10 @@ SRCREV = "34820924edbc4ec7803eb89d9852f4b870fa760a"
 
 SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master;tag=v${PV}"
 
+# workaround for aarch64 kvm qemu boot regression
+SRC_URI:append:qemuarm64 = " file://disable-CONFIG_BLOBLIST.cfg"
+SRC_URI:append:genericarm64 = " file://disable-CONFIG_BLOBLIST.cfg"
+
 S = "${WORKDIR}/git"
 B = "${WORKDIR}/build"
 
-- 
2.43.0

[PATCH v4 2/4] qemuarm64.conf: allow overriding QB_OPT_APPEND

[Mikko Rapeli]

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@"
-- 
2.43.0

Re: [PATCH v4 2/4] qemuarm64.conf: allow overriding QB_OPT_APPEND

[Tom Rini]

On Mon, May 26, 2025 at 11:35:45AM +0300, Mikko Rapeli 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(-)

This too feel like something that should be brought up on the U-Boot
side.

-- 
Tom

Re: [PATCH v4 2/4] qemuarm64.conf: allow overriding QB_OPT_APPEND

[Mikko Rapeli]

Hi,

On Tue, May 27, 2025 at 06:52:47PM -0600, Tom Rini wrote:
> On Mon, May 26, 2025 at 11:35:45AM +0300, Mikko Rapeli 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(-)
> 
> This too feel like something that should be brought up on the U-Boot
> side.

We saw these issues in 2023 on qemu but thought they were specific to our
Trusted Substrate config with tf-a, OP-TEE and u-boot. Some public info is
in: https://linaro.atlassian.net/browse/LEDGE-435

I know USB support is really tricky with timings etc so I don't expect
it to work well with bootloaders. Hence did not dig deeper.

Now that I saw this reset loop with KVM I will note the details down
with reproduction steps and send to u-boot list.

But I think overriding QB_OPT_APPEND is handy, wether it has USB setup
or something else. Other layers in yocto ecosystem use qemuarm64 as basis
machine with testing and may want to change this.

Cheers,

-Mikko

Re: [PATCH v4 2/4] qemuarm64.conf: allow overriding QB_OPT_APPEND

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

On Wed, May 28, 2025 at 11:02:44AM +0300, Mikko Rapeli wrote:
> Hi,
> 
> On Tue, May 27, 2025 at 06:52:47PM -0600, Tom Rini wrote:
> > On Mon, May 26, 2025 at 11:35:45AM +0300, Mikko Rapeli 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(-)
> > 
> > This too feel like something that should be brought up on the U-Boot
> > side.
> 
> We saw these issues in 2023 on qemu but thought they were specific to our
> Trusted Substrate config with tf-a, OP-TEE and u-boot. Some public info is
> in: https://linaro.atlassian.net/browse/LEDGE-435
> 
> I know USB support is really tricky with timings etc so I don't expect
> it to work well with bootloaders. Hence did not dig deeper.
> 
> Now that I saw this reset loop with KVM I will note the details down
> with reproduction steps and send to u-boot list.
> 
> But I think overriding QB_OPT_APPEND is handy, wether it has USB setup
> or something else. Other layers in yocto ecosystem use qemuarm64 as basis
> machine with testing and may want to change this.

I would say there are two parts to this. On the U-Boot side, USB is
expected to work and we have active custodians dealing with it. Please
work with Ilias and others to get a reproduceable set of steps with
vanilla QEMU and report them to the U-Boot list with appropriate CC. On
the OE side, it's all complicated enough that I would defer to Richard.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[PATCH v4 3/4] oeqa decorator/data.py: add skipIfNotBuildArch decorator

[Mikko Rapeli]

To limit tests to specific build host architectures.
For example KVM testing will only work if target and
build architectures are the same.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/lib/oeqa/core/decorator/data.py | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/meta/lib/oeqa/core/decorator/data.py b/meta/lib/oeqa/core/decorator/data.py
index 5444b2cb75..0daf46334f 100644
--- a/meta/lib/oeqa/core/decorator/data.py
+++ b/meta/lib/oeqa/core/decorator/data.py
@@ -228,3 +228,15 @@ class skipIfNotArch(OETestDecorator):
         arch = self.case.td['HOST_ARCH']
         if arch not in self.archs:
              self.case.skipTest('Test skipped on %s' % arch)
+
+@registerDecorator
+class skipIfNotBuildArch(OETestDecorator):
+    """
+    Skip test if BUILD_ARCH is not present in the tuple specified.
+    """
+
+    attrs = ('archs',)
+    def setUpDecorator(self):
+        arch = self.case.td['BUILD_ARCH']
+        if arch not in self.archs:
+             self.case.skipTest('Test skipped on %s' % arch)
-- 
2.43.0

[PATCH v4 4/4] oeqa selftest uboot.py: add qemu KVM test case

[Mikko Rapeli]

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>
---
 meta/lib/oeqa/selftest/cases/uboot.py | 61 ++++++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 2 deletions(-)

v4: use skipIfNotBuildArch, variable for image name except config where
    bitbake syntax causes python parsing errors when replacing variables,
    check that target host arch and build arch are the same for KVM to work,
    fixed QB_DRIVE_TYPE syntax to include /dev/ path,
    tested on aarch64 build machine and genericarm64 and qemuarm64 target machines

v1: https://lists.openembedded.org/g/openembedded-core/message/217107

diff --git a/meta/lib/oeqa/selftest/cases/uboot.py b/meta/lib/oeqa/selftest/cases/uboot.py
index 96da4efb06..cd9c74f52f 100644
--- a/meta/lib/oeqa/selftest/cases/uboot.py
+++ b/meta/lib/oeqa/selftest/cases/uboot.py
@@ -6,8 +6,8 @@
 #
 
 from oeqa.selftest.case import OESelftestTestCase
-from oeqa.utils.commands import bitbake, runqemu
-from oeqa.core.decorator.data import skipIfNotArch
+from oeqa.utils.commands import bitbake, runqemu, get_bb_var, get_bb_vars, runCmd
+from oeqa.core.decorator.data import skipIfNotArch, skipIfNotBuildArch
 from oeqa.core.decorator import OETestTag
 
 uboot_boot_patterns = {
@@ -41,3 +41,60 @@ QEMU_USE_KVM = "False"
             status, output = qemu.run_serial(cmd)
             self.assertEqual(status, 1, msg=output)
             self.assertTrue("U-Boot" in output, msg=output)
+
+    @skipIfNotArch(['aarch64'])
+    @skipIfNotBuildArch(['aarch64'])
+    @OETestTag("runqemu")
+    def test_boot_uboot_kvm_to_full_target(self):
+        """
+        Tests building u-boot and booting it with QEMU and KVM.
+        Requires working KVM on build host. See "kvm-ok" output.
+        """
+
+        runCmd("kvm-ok")
+
+        image = "core-image-minimal"
+        vars = get_bb_vars(['HOST_ARCH', 'BUILD_ARCH'], image)
+        host_arch = vars['HOST_ARCH']
+        build_arch = vars['BUILD_ARCH']
+
+        self.assertEqual(host_arch, build_arch, 'HOST_ARCH %s and BUILD_ARCH %s must match for KVM' % (host_arch, build_arch))
+
+        self.write_config("""
+QEMU_USE_KVM = "1"
+
+# Using u-boot in EFI mode, need ESP partition for grub/systemd-boot/kernel etc
+IMAGE_FSTYPES:pn-core-image-minimal:append = " wic"
+
+# easiest to follow genericarm64 setup with wks file, initrd and EFI loader
+INITRAMFS_IMAGE = "core-image-initramfs-boot"
+EFI_PROVIDER = "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
+WKS_FILE = "genericarm64.wks.in"
+
+# use wic image with ESP for u-boot, not ext4
+QB_DEFAULT_FSTYPE = "wic"
+
+PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
+QB_DEFAULT_BIOS = "u-boot.bin"
+
+# let u-boot or EFI loader load kernel from ESP
+QB_DEFAULT_KERNEL = "none"
+
+# virt pci, not scsi because support not in u-boot to find ESP
+QB_DRIVE_TYPE = "/dev/vd"
+# qemu usb causes u-boot reset atm
+QB_OPT_APPEND = ""
+""")
+        bitbake("virtual/bootloader %s" % image)
+
+        runqemu_params = get_bb_var('TEST_RUNQEMUPARAMS', image) or ""
+        with runqemu(image, ssh=False, runqemuparams='nographic kvm %s' % runqemu_params) as qemu:
+
+            # boot to target and login worked, should have been fast with kvm
+            cmd = "dmesg"
+            status, output = qemu.run_serial(cmd)
+            self.assertEqual(status, 1, msg=output)
+            # Machine is qemu
+            self.assertTrue("Machine model: linux,dummy-virt" in output, msg=output)
+            # with KVM enabled
+            self.assertTrue("KVM: hypervisor services detected" in output, msg=output)
-- 
2.43.0

Re: [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64

[Mikko Rapeli]

Hi,

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.

We have a workaround for qemuarm64 and generiarm64 for testing use cases
with disabling BLOBLIST so we might as well use it since there does
not seem to be any downsides to it in testing.

Cheers,

-Mikko

Re: [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

On Wed, May 28, 2025 at 09:40:59AM +0300, Mikko Rapeli wrote:
> Hi,
> 
> 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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64

[Mikko Rapeli]

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

Re: [PATCH v4 1/4] u-boot: disable CONFIG_BLOBLIST on genericarm64 and qemuarm64

[Ilias Apalodimas]

Hi all,

On Wed, 4 Jun 2025 at 13:09, Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
>
> 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.

So I had a closer look. It is affected by previous patches added for
BLOBLIST. The reason this one triggers it is because it
unconditionally enables BLOBLIST for qemu arm64.

I'll need a few more days on it, but I will have a proper fix

Cheers
/Ilias
>
> Cheers,
>
> -Mikko