[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Romain Naour]

Hi Erico, All,

I would like to rename the aarch64_efi_defconfig to
qemu_aarch64_virt_efi_defconfig  in order to do a runtime test in the Buildroot
gitlab-ci.

See the gitlab-ci job for the qemu_aarch64_virt_defconfig:
https://gitlab.com/buildroot.org/buildroot/-/jobs/623442197

Note: There is no ACPI table while booting the kernel built with
qemu_aarch64_virt_defconfig since there is no bootloader.

But we need to build or download the aarch64 UEFI firmware image (QEMU_EFI.fd)
also called Open Virtual Machine Firmware (OVMF).

Building QEMU_EFI.fd would require to package Tianocore's edk2 [1] for the host
and deal with the specific buildsystem (bash + Makefiles).

But since it's only for testing, I'm wondering if we should use a prebuilt
QEMU_EFI.fd instead building it.

I propose to use the one provided by Linaro [2] that is periodically released
(~once a year) and probably well tested.

What do you think?

[1] https://github.com/tianocore/edk2.git
[2]
http://releases.linaro.org/reference-platform/enterprise/firmware/open-source/19.03/

Best regards,
Romain

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Thomas Petazzoni]

On Sat, 11 Jul 2020 01:02:01 +0200
Romain Naour <romain.naour@gmail.com> wrote:

> I would like to rename the aarch64_efi_defconfig to
> qemu_aarch64_virt_efi_defconfig  in order to do a runtime test in the Buildroot
> gitlab-ci.

The thing is that the idea of the aarch64_efi_defconfig is that it is a
generic AArch64 image that should work on all EFI compliant AArch64
systems, not just Qemu.

Renaming it with a "qemu_" prefix kind of losses that implicit
"documentation" that it is a generic AArch64 configuration.

If your goal is to have this defconfig tested under Qemu, then I would
rather suggest that we improve the logic that decides which defconfig
can be tested under Qemu, and not just rely on a qemu_ prefix, but
maybe some kind of explicit list ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Romain Naour]

Hi Thomas,

Le 11/07/2020 ? 12:59, Thomas Petazzoni a ?crit?:
> On Sat, 11 Jul 2020 01:02:01 +0200
> Romain Naour <romain.naour@gmail.com> wrote:
> 
>> I would like to rename the aarch64_efi_defconfig to
>> qemu_aarch64_virt_efi_defconfig  in order to do a runtime test in the Buildroot
>> gitlab-ci.
> 
> The thing is that the idea of the aarch64_efi_defconfig is that it is a
> generic AArch64 image that should work on all EFI compliant AArch64
> systems, not just Qemu.
> 
> Renaming it with a "qemu_" prefix kind of losses that implicit
> "documentation" that it is a generic AArch64 configuration.
> 
> If your goal is to have this defconfig tested under Qemu, then I would
> rather suggest that we improve the logic that decides which defconfig
> can be tested under Qemu, and not just rely on a qemu_ prefix, but
> maybe some kind of explicit list ?

Not really just testing this defconfig under Qemu, but having ACPI tables and
other features enabled by EFI and grub when booting the system under Qemu.

The current qemu_aarch64_virt_defconfig boot with just the kernel, so ACPI
tables are missing and the plig and play support is disabled.

dmesg:
ACPI: Interpreter disabled.
[...]
pnp: PnP ACPI: disabled

For example, ACPI and hotplug support is required to use QEMU Virtual NVDIMM

-device nvdimm,id=nvdimm1,memdev=mem1

Instead of renaming aarch64_efi_defconfig, we can enable UEFI and grub in the
qemu_aarch64_virt_defconfig itself. But it still require the QEMU_EFI.fd
firmware, either built by Buildroot (complex hand written build system) or
fetched from Linaro.

Best regards,
Romain

> 
> Best regards,
> 
> Thomas
> 

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Thomas Petazzoni]

On Sat, 11 Jul 2020 15:08:27 +0200
Romain Naour <romain.naour@gmail.com> wrote:

> Not really just testing this defconfig under Qemu, but having ACPI tables and
> other features enabled by EFI and grub when booting the system under Qemu.
> 
> The current qemu_aarch64_virt_defconfig boot with just the kernel, so ACPI
> tables are missing and the plig and play support is disabled.
> 
> dmesg:
> ACPI: Interpreter disabled.
> [...]
> pnp: PnP ACPI: disabled
> 
> For example, ACPI and hotplug support is required to use QEMU Virtual NVDIMM
> 
> -device nvdimm,id=nvdimm1,memdev=mem1
> 
> Instead of renaming aarch64_efi_defconfig, we can enable UEFI and grub in the
> qemu_aarch64_virt_defconfig itself.

Seems like a good idea.

> But it still require the QEMU_EFI.fd firmware, either built by
> Buildroot (complex hand written build system) or fetched from Linaro.

Of course, it's always better to build things from source, but if it's
really too horrible, we can have a package that fetches pre-compiled
binaries from Linaro.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Romain Naour]

Le 11/07/2020 ? 15:12, Thomas Petazzoni a ?crit?:
> On Sat, 11 Jul 2020 15:08:27 +0200
> Romain Naour <romain.naour@gmail.com> wrote:
> 
>> Not really just testing this defconfig under Qemu, but having ACPI tables and
>> other features enabled by EFI and grub when booting the system under Qemu.
>>
>> The current qemu_aarch64_virt_defconfig boot with just the kernel, so ACPI
>> tables are missing and the plig and play support is disabled.
>>
>> dmesg:
>> ACPI: Interpreter disabled.
>> [...]
>> pnp: PnP ACPI: disabled
>>
>> For example, ACPI and hotplug support is required to use QEMU Virtual NVDIMM
>>
>> -device nvdimm,id=nvdimm1,memdev=mem1
>>
>> Instead of renaming aarch64_efi_defconfig, we can enable UEFI and grub in the
>> qemu_aarch64_virt_defconfig itself.
> 
> Seems like a good idea.

Ok

> 
>> But it still require the QEMU_EFI.fd firmware, either built by
>> Buildroot (complex hand written build system) or fetched from Linaro.
> 
> Of course, it's always better to build things from source, but if it's
> really too horrible, we can have a package that fetches pre-compiled
> binaries from Linaro.

I'm agree, but I would like to avoid to spent too much time on it while it
already available from Linaro.

I suggest to call the package providing the prebuilt QEMU_EFI.fd "ovmf-bin" and
latter add the "ovmf" package to build it from source (like the rust packaging
does with "rust", "rustc" and "rust-bin").

Best regards,
Romain

> 
> Thomas
> 

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Erico Nunes]

Hello all,

On Sat, Jul 11, 2020 at 3:34 PM Romain Naour <romain.naour@gmail.com> wrote:
>
> Le 11/07/2020 ? 15:12, Thomas Petazzoni a ?crit :
> > On Sat, 11 Jul 2020 15:08:27 +0200
> > Romain Naour <romain.naour@gmail.com> wrote:
> >
> >> Not really just testing this defconfig under Qemu, but having ACPI tables and
> >> other features enabled by EFI and grub when booting the system under Qemu.

as you already mentioned, the original intent of aarch64_efi_defconfig
is to be used with standards compliant aarch64 systems running
ACPI/UEFI. It is analogous to the pc_* defconfigs for x86_64.
There is a short documentation on it at
https://git.buildroot.net/buildroot/tree/board/aarch64-efi/readme.txt
where the need for OVMF is mentioned.
That was a manual example though as it requires users to pull OVMF
from the distribution. If there are plans to turn it into an automated
test, then indeed it would be better to have a Buildroot provided one
and this readme can also be updated.

> >>
> >> The current qemu_aarch64_virt_defconfig boot with just the kernel, so ACPI
> >> tables are missing and the plig and play support is disabled.
> >>
> >> dmesg:
> >> ACPI: Interpreter disabled.
> >> [...]
> >> pnp: PnP ACPI: disabled
> >>
> >> For example, ACPI and hotplug support is required to use QEMU Virtual NVDIMM
> >>
> >> -device nvdimm,id=nvdimm1,memdev=mem1
> >>
> >> Instead of renaming aarch64_efi_defconfig, we can enable UEFI and grub in the
> >> qemu_aarch64_virt_defconfig itself.

Probably needs ACPI support in the kernel config as well, and be
booted with acpi=on as device tree is probably the default in upstream
kernels in case both are available.

> >
> > Seems like a good idea.
>
> Ok

Just to double check, wouldn't it be the case to have 2 qemu configs,
one to test the ACPI/UEFI+grub2 profile and another one for the qemu
direct kernel boot?
If qemu_aarch64_virt_defconfig gets converted to that (which is a
little more complex and I believe less used with Buildroot), then only
that would get the automated testing coverage.

>
> >
> >> But it still require the QEMU_EFI.fd firmware, either built by
> >> Buildroot (complex hand written build system) or fetched from Linaro.
> >
> > Of course, it's always better to build things from source, but if it's
> > really too horrible, we can have a package that fetches pre-compiled
> > binaries from Linaro.
>
> I'm agree, but I would like to avoid to spent too much time on it while it
> already available from Linaro.
>
> I suggest to call the package providing the prebuilt QEMU_EFI.fd "ovmf-bin" and
> latter add the "ovmf" package to build it from source (like the rust packaging
> does with "rust", "rustc" and "rust-bin").

Sounds like a good idea to me to have the -bin package, indeed the
edk2 build system is not very friendly.

Erico

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Romain Naour]

Hi Erico, All,

Le 13/07/2020 ? 15:18, Erico Nunes a ?crit?:
> Hello all,
> 
> On Sat, Jul 11, 2020 at 3:34 PM Romain Naour <romain.naour@gmail.com> wrote:
>>
>> Le 11/07/2020 ? 15:12, Thomas Petazzoni a ?crit :
>>> On Sat, 11 Jul 2020 15:08:27 +0200
>>> Romain Naour <romain.naour@gmail.com> wrote:
>>>
>>>> Not really just testing this defconfig under Qemu, but having ACPI tables and
>>>> other features enabled by EFI and grub when booting the system under Qemu.
> 
> as you already mentioned, the original intent of aarch64_efi_defconfig
> is to be used with standards compliant aarch64 systems running
> ACPI/UEFI. It is analogous to the pc_* defconfigs for x86_64.
> There is a short documentation on it at
> https://git.buildroot.net/buildroot/tree/board/aarch64-efi/readme.txt
> where the need for OVMF is mentioned.
> That was a manual example though as it requires users to pull OVMF
> from the distribution. If there are plans to turn it into an automated
> test, then indeed it would be better to have a Buildroot provided one
> and this readme can also be updated.

ok

> 
>>>>
>>>> The current qemu_aarch64_virt_defconfig boot with just the kernel, so ACPI
>>>> tables are missing and the plig and play support is disabled.
>>>>
>>>> dmesg:
>>>> ACPI: Interpreter disabled.
>>>> [...]
>>>> pnp: PnP ACPI: disabled
>>>>
>>>> For example, ACPI and hotplug support is required to use QEMU Virtual NVDIMM
>>>>
>>>> -device nvdimm,id=nvdimm1,memdev=mem1
>>>>
>>>> Instead of renaming aarch64_efi_defconfig, we can enable UEFI and grub in the
>>>> qemu_aarch64_virt_defconfig itself.
> 
> Probably needs ACPI support in the kernel config as well, and be
> booted with acpi=on as device tree is probably the default in upstream
> kernels in case both are available.

Indeed, I enabled ACPI support in the kernel used by
qemu_aarch64_virt_defconfig, see:

http://patchwork.ozlabs.org/project/buildroot/list/?series=189147

> 
>>>
>>> Seems like a good idea.
>>
>> Ok
> 
> Just to double check, wouldn't it be the case to have 2 qemu configs,
> one to test the ACPI/UEFI+grub2 profile and another one for the qemu
> direct kernel boot?
> If qemu_aarch64_virt_defconfig gets converted to that (which is a
> little more complex and I believe less used with Buildroot), then only
> that would get the automated testing coverage.

Yes, I thought about adding a new defconfig qemu_aarch64_virt_efi_defconfig but
I find it too similar compared to qemu_aarch64_virt_defconfig.
Indeed it is a little more complex but not so much (small grub configuration and
genimage).

As a side effect, the bootloader grub2 will be runtime tested in the
Buildroot gitlab-ci while testing this defconfig.

> 
>>
>>>
>>>> But it still require the QEMU_EFI.fd firmware, either built by
>>>> Buildroot (complex hand written build system) or fetched from Linaro.
>>>
>>> Of course, it's always better to build things from source, but if it's
>>> really too horrible, we can have a package that fetches pre-compiled
>>> binaries from Linaro.
>>
>> I'm agree, but I would like to avoid to spent too much time on it while it
>> already available from Linaro.
>>
>> I suggest to call the package providing the prebuilt QEMU_EFI.fd "ovmf-bin" and
>> latter add the "ovmf" package to build it from source (like the rust packaging
>> does with "rust", "rustc" and "rust-bin").
> 
> Sounds like a good idea to me to have the -bin package, indeed the
> edk2 build system is not very friendly.

I received a message on tweeter from Dick Olsson who packaged edk2 and posted on
github. I'll take a look.

https://twitter.com/dickolsson/status/1282402157090799616
https://github.com/dickolsson/buildroot/tree/arm-trusted-firmware/boot/edk2

Best regards,
Romain

> 
> Erico
> 

[Buildroot] Rename aarch64_efi_defconfig to qemu_aarch64_virt_efi_defconfig

[Thomas Petazzoni]

On Mon, 13 Jul 2020 15:18:28 +0200
Erico Nunes <nunes.erico@gmail.com> wrote:

> as you already mentioned, the original intent of aarch64_efi_defconfig
> is to be used with standards compliant aarch64 systems running
> ACPI/UEFI. It is analogous to the pc_* defconfigs for x86_64.
> There is a short documentation on it at
> https://git.buildroot.net/buildroot/tree/board/aarch64-efi/readme.txt
> where the need for OVMF is mentioned.
> That was a manual example though as it requires users to pull OVMF
> from the distribution. If there are plans to turn it into an automated
> test, then indeed it would be better to have a Buildroot provided one
> and this readme can also be updated.

Romain has already submitted a patch series that adds a package for
edk2, in a precompiled form. I don't know if you have been Cc'ed on
that.

> > >> Instead of renaming aarch64_efi_defconfig, we can enable UEFI and grub in the
> > >> qemu_aarch64_virt_defconfig itself.  
> 
> Probably needs ACPI support in the kernel config as well, and be
> booted with acpi=on as device tree is probably the default in upstream
> kernels in case both are available.
> 
> > >
> > > Seems like a good idea.  
> >
> > Ok  
> 
> Just to double check, wouldn't it be the case to have 2 qemu configs,
> one to test the ACPI/UEFI+grub2 profile and another one for the qemu
> direct kernel boot?
> If qemu_aarch64_virt_defconfig gets converted to that (which is a
> little more complex and I believe less used with Buildroot), then only
> that would get the automated testing coverage.

But we already have 2 defconfigs:

 - qemu_aarch64_virt_defconfig, which IMO should stay pretty much as it
   is: directly kernel boot

 - aarch64_efi_defconfig, which should be usable by EFI/ACPI compliant
   platform, and Qemu should be one of them.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com