[Buildroot] [PATCH 1/3] boot/edk2: bump to version edk2-stable202305

Julien Olivain ju.o at free.fr
Fri Jul 21 20:07:23 UTC 2023


Hi Romain,

On 19/07/2023 23:46, Romain Naour wrote:
> Hello Julien, Vincent, All,
> 
> Le 18/07/2023 à 23:57, Romain Naour a écrit :
>> Hello Julien, Vincent, All,
>> 
>> Le 01/06/2023 à 15:25, Vincent Stehlé a écrit :
>>> On Tue, May 30, 2023 at 10:07:26PM +0200, Julien Olivain wrote:
>>>> For change log since version edk2-stable202208, see:
>>>> - https://github.com/tianocore/edk2/releases/tag/edk2-stable202211
>>>> - https://github.com/tianocore/edk2/releases/tag/edk2-stable202302
>>>> - https://github.com/tianocore/edk2/releases/tag/edk2-stable202305
>>>> 
>>>> The main motivation of this bump is the RISC-V QEMU Virt support
>>>> introduced in edk2-stable202302 (not yet supported in Buildroot).
>>>> 
>>>> Cc: Dick Olsson <hi at senzilla.io>
>>>> Cc: Vincent Stehlé <vincent.stehle at arm.com>
>>>> Signed-off-by: Julien Olivain <ju.o at free.fr>
>>>> ---
>>>> Patch series tested on branch master at commit c765ac9 with 
>>>> commands:
>>>> 
>>>>     utils/docker-run make check-package
>>>>     ...
>>>>     0 warnings generated
>>>> 
>>>>     support/testing/run-tests \
>>>>         -d dl -o output_folder \
>>>>         tests.boot.test_edk2
>>>>     ...
>>>>     OK
>>>> 
>>>>     make qemu_aarch64_sbsa_defconfig
>>>>     make
>>>>     ...
>>>>     output/images/start-qemu.sh
>>>>     ...
>>>>     buildroot login:
>>> 
>>> Hi Julien,
>>> 
>>> Thanks for those patches!
>>> 
>>> I did test the following on my side without issue:
>>> 
>>>   qemu_aarch64_sbsa_defconfig
>>>   tests.boot.test_edk2.TestEdk2
>>>   tests.boot.test_grub.TestGrubAArch64EFI
>>>   tests.boot.test_grub.TestGrubX8664EFI
>>>   tests.boot.test_grub.TestGrubi386EFI
>>>   tests.fs.test_iso9660.TestIso9660Grub2EFI
>>>   tests.fs.test_iso9660.TestIso9660Grub2Hybrid
>> 
>> Thanks for testing but some test in gitlab-ci doesn't boot since this 
>> patch has
>> been applied:
>> 
>> https://gitlab.com/buildroot.org/buildroot/-/jobs/4664845865
>> https://gitlab.com/buildroot.org/buildroot/-/jobs/4664845861
>> https://gitlab.com/buildroot.org/buildroot/-/jobs/4664845777
>> https://gitlab.com/buildroot.org/buildroot/-/jobs/4664845773
>> 
>> "SystemError: System does not boot"
>> 
>> I reproduced locally with "tests.boot.test_grub.TestGrubX8664EFI" then 
>> I
>> reverted this commit to boot correctly.
>> 
>> There is no useful log, the image just hang.
>> 
>> Can you have a look?
> 
> The issue come from the qemu version (5.2.x) used by our gitlab-ci 
> docker image.
> 
> If we use the "experimental QEMU command line option" (See [1]), the 
> system boot:
> 
>   -fw_cfg name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes
> 
> If edk2 detect the issue in PlatformCpuCountBugCheck(), it print an 
> error
> message (we didn't see it in our log) and *hang* if the qemu issue is 
> present.
> 
> We have to add this workaround to each runtime test using edk2 package.

I confirm the workaround works for me, when adding "-fw_cfg
name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes"
in qemu opts.

We could indeed use it as is for now.

> Thoughts?

Having those quirks here and there in tests will make future updates
of the docker image even more difficult. Ideally, we need some way to
track them for later cleanups. For smooth(er) updates, it would be
also good to have the test not failing before and after the update. By
"not failing", I also mean it could also be skipped.

This could be done by exposing the emulator version, and reporting some
test message (for ex, in support/testing/infra/emulator.py).

We could have somewhere in the test in question, or in a base class:
(untested pseudo pythoncode)

     def qemu_has_cpuhp_bug(self):
         v = self.emulator.get_version()
         return v[0] < 7 or (v[0] = 7 and v < (7, 2, 1))

     if self.qemu_has_cpuhp_bug():
         self.show_msg("Warning: applying QEmu CPUHP workaround")
         emulator_args += "-fw_cfg ..."
     elif self.running_in_br_docker_image():
         self.show_msg("Info: test workaround code no longer needed")


In some other corner cases, we could just skip the test:

     if qemu_has_cpuhp_bug():
         msg = "Unsupported emulator version"
         self.show_msg("Skipping test: " + msg)
         self.skipTest(msg)

I think it would be good to keep the test suite working with the qemu
version in the docker image AND the host-qemu in Buildroot (which the
one used in _defconfigs, and is supposed to be near the latest
released version).

What do you think?


> 
> [1]
> https://github.com/tianocore/edk2/commit/bf5678b5802685e07583e3c7ec56d883cbdd5da3
> 
> Best regards,
> Romain
> 
> 
>> 
>> Best regards,
>> Romain
>> 
>> 
>>> 
>>> Feel free to add (or not):
>>> 
>>>   Tested-by: Vincent Stehlé <vincent.stehle at arm.com>
>> 
>> 
>> 
>>> 
>>> Best regards,
>>> Vincent.
>>> 
>>>> ---
>>>>  boot/edk2/edk2.hash | 2 +-
>>>>  boot/edk2/edk2.mk   | 2 +-
>>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/boot/edk2/edk2.hash b/boot/edk2/edk2.hash
>>>> index 94ee22ddc4..34d4b10e29 100644
>>>> --- a/boot/edk2/edk2.hash
>>>> +++ b/boot/edk2/edk2.hash
>>>> @@ -1,3 +1,3 @@
>>>>  # Locally calculated
>>>> -sha256  
>>>> c10520f269557d566e35fe8104141aa2865f9085ad2b3a30aae8a7e78a3ca5aa  
>>>> edk2-edk2-stable202208-br1.tar.gz
>>>> +sha256  
>>>> ca55351913e6258ebd8c08106f369ac71073d9cfaa80427fc5f131b06d808940  
>>>> edk2-edk2-stable202305-br1.tar.gz
>>>>  sha256  
>>>> 50ce20c9cfdb0e19ee34fe0a51fc0afe961f743697b068359ab2f862b494df80  
>>>> License.txt
>>>> diff --git a/boot/edk2/edk2.mk b/boot/edk2/edk2.mk
>>>> index fb6b9a3280..399bd346ef 100644
>>>> --- a/boot/edk2/edk2.mk
>>>> +++ b/boot/edk2/edk2.mk
>>>> @@ -4,7 +4,7 @@
>>>>  #
>>>>  
>>>> ################################################################################
>>>> 
>>>> -EDK2_VERSION = edk2-stable202208
>>>> +EDK2_VERSION = edk2-stable202305
>>>>  EDK2_SITE = https://github.com/tianocore/edk2
>>>>  EDK2_SITE_METHOD = git
>>>>  EDK2_LICENSE = BSD-2-Clause-Patent
>>>> --
>>>> 2.40.1
>>>> 
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at buildroot.org
>>> https://lists.buildroot.org/mailman/listinfo/buildroot
>> 

Best regards,

Julien.



More information about the buildroot mailing list