All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Olivain <ju.o@free.fr>
To: Romain Naour <romain.naour@smile.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2 2/3] boot/edk2: bump to version edk2-stable202405
Date: Tue, 29 Oct 2024 21:51:55 +0100	[thread overview]
Message-ID: <7808488cc706e7b21b3b374c78e8548c@free.fr> (raw)
In-Reply-To: <a0addb27-54e4-4e13-b511-302eb40661af@smile.fr>

Hi Romain, Thomas,

On 29/10/2024 10:56, Romain Naour wrote:
> Hello Julien, Thomas,
> 
> Le 28/10/2024 à 22:12, Thomas Petazzoni a écrit :
>> On Mon, 28 Oct 2024 21:27:30 +0100
>> Julien Olivain <ju.o@free.fr> wrote:
>> 
>>> On my side (this series applied on top of branch master at 81e7806),
>>> this patch does not apply. This can be reproduced with:
>>> 
>>>      make qemu_aarch64_sbsa_defconfig
>>>      make edk2-patch
>>> 
>>> Which fails with output:
>>> 
>>>      Applying
>>> 0001-OvmfPkg-QemuVideoDxe-add-feature-PCD-to-remap-frameb.patch using
>>> patch:
>> 
>> I'd say there's a fairly high chance this isn't Romain's fault. I
>> haven't checked but I would guess that this EDK2 code base uses
>> DOS-style new lines (\r\n), and so the patches have those, but they 
>> get
>> stripped when going through the mailing list, making the patch
>> unapplicable.
> 
> Indeed, this is our well known issue with the mailing list
> 
> [The correct patch file]
> $ file 
> boot/edk2/0001-OvmfPkg-QemuVideoDxe-add-feature-PCD-to-remap-frameb.patch
> boot/edk2/0001-OvmfPkg-QemuVideoDxe-add-feature-PCD-to-remap-frameb.patch:
> unified diff output, ASCII text, with CRLF, LF line terminators
> 
> [The corrupted patch file]
> $ file 
> boot/edk2/0001-OvmfPkg-QemuVideoDxe-add-feature-PCD-to-remap-frameb.patch
> boot/edk2/0001-OvmfPkg-QemuVideoDxe-add-feature-PCD-to-remap-frameb.patch:
> unified diff output, ASCII text
> 

I confirm the CR-LR newlines of the original patch got lost on
the mailing list. If I download the patch from:
https://github.com/tianocore/edk2/commit/c1d1910be6e04a8b1a73090cf2881fb698947a6e.patch

It applies and build correctly.

However, while testing this series a bit more, this edk2 bump breaks
several runtime tests. So far, I spotted test_edk2, test_fwts and
test_grub.

Those tests are failing disregarding the qemu version used.

When updating ATF to 2.11 in those tests, they get fixed with a
recent qemu version (I tested 9.1.1), but they are still crashing
in the qemu 5.2.0 in the Buildroot Docker image. This fit to your
commit logs. When crashing, the output is:

     NOTICE:  BL31: v2.11.0(release):v2.11
     NOTICE:  BL31: Built : 17:52:08, Oct 29 2024
     UEFI firmware (version 1.0 built at 17:52:34 on Oct 29 2024)
     Synchronous Exception at 0x000001001F3AE0AC

My guess is that we've reached the limit of this old Qemu version...

I think those tests relying on recent qemu should build their own
host-qemu and the runtime test infra should use it. Other tests
should remain as they are. If I recall correctly, it is not the
first time we get toward this conclusion...

If we decide to do so, this series will need to be expanded a bit
to fix those tests at the same time. I'll continue to testing on
my side to see how we can improve that.

>> 
>>> When we bumping boot/edk2, we usually also bump edk2-non-osi.
>>> See:
>>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/edk2-non-osi/edk2-non-osi.mk?ref_type=heads#L7
>>> 
>>> Even if it is not needed to fix the qemu_aarch64_sbsa_defconfig of
>>> this series, it would be better to keep all those components aligned.
>>> 
>>> Could you check if edk2-non-osi needs to be updated too?
>>> If yes, could you update it?
>>> If no, could you add a mention that it does not need to?
>>> 
>>> Maybe we could add a comment in boot/edk2/edk2.mk, before 
>>> EDK2_VERSION.
>>> Something like:
>>> 
>>> # When updating version, make sure to also update the edk2-platforms
>>> # and edk2-non-osi packages to their respective commit ID nearest to
>>> # the edk2 release.
>> 
>> I'll let Romain address this point before applying then.
> 
> There is no information from edk2 releases about edk2-non-osi and 
> edk2-platforms
> git hashes to use. At least Qemu testsuite files contains the hash used 
> for
> their tests [1]...
> 
> Actually I'm not sure if edk2-non-osi package is really needed since it 
> contains
> mostly prebuilt firmwares.
> 
> meta-arm doesn't use it:
> 
> https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-bsp/uefi/edk2-firmware.inc?h=scarthgap#n18
> 
> Actually this package is only needed for Marvell Armada [2]
> (Silicon/Marvell/Armada7k8k/DeviceTree) that was not updated since 2021 
> in
> edk2-non-osi repository.
> 
> So, no update is required.

Ok, thanks for this confirmation.

> [1]
> https://gitlab.com/qemu-project/qemu/-/commit/24a7cd6a7c21f82f1ce9bd5ecf6fb54eb7bf4602
> [2]
> https://gitlab.com/buildroot.org/buildroot/-/commit/95f72fb61aae6a64ea822b535cf9d2c2e01e6fc9
> 
> Best regards,
> Romain
> 
> 
>> 
>> Thanks!
>> 
>> Thomas

Best regards,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2024-10-29 20:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-27 19:43 [Buildroot] [PATCH v2 1/3] configs/qemu_aarch64_sbsa_defconfig: update ATF to v2.11 Romain Naour via buildroot
2024-10-27 19:43 ` [Buildroot] [PATCH v2 2/3] boot/edk2: bump to version edk2-stable202405 Romain Naour via buildroot
2024-10-28 20:27   ` Julien Olivain
2024-10-28 21:12     ` Thomas Petazzoni via buildroot
2024-10-29  9:56       ` Romain Naour via buildroot
2024-10-29 20:51         ` Julien Olivain [this message]
2024-10-27 19:43 ` [Buildroot] [PATCH v2 3/3] configs/qemu_aarch64_sbsa_defconfig: switch to neoverse-n1 (armv8.2a) Romain Naour via buildroot

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=7808488cc706e7b21b3b374c78e8548c@free.fr \
    --to=ju.o@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=romain.naour@smile.fr \
    --cc=thomas.petazzoni@bootlin.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.