On Tue, Jun 6, 2023 at 11:33 AM Clément Péron <peron.c...@gmail.com> wrote: > > Hi, > > On Tue, 6 Jun 2023 at 17:32, Clément Péron via lists.yoctoproject.org > <peron.clem=gmail....@lists.yoctoproject.org> wrote: > > > > Hi, > > > > On 03/03/2023 17:28, Jon Mason wrote: > > > /ATA > > > > > > On Wed, Mar 1, 2023 at 10:38 AM Bruce Ashfield <bruce.ashfi...@gmail.com> > > > wrote: > > >> > > >> Patch 1/2 looks fine, but 2/2 reverts the following commit: > > >> > > >> ========================== > > >> commit 41751659d0650c4effdd598f26febba39aeaf082 > > >> Author: Andrei Gherzan <andrei.gher...@huawei.com> > > >> Date: Mon Aug 22 19:55:10 2022 +0200 > > >> > > >> efi.cfg: Drop ACPI dependency > > >> > > >> On X86 this will have no impact as CONFIG_ACPI is enabled by > > >> default. On > > >> the other hand, ARM64 would be affected as they don't have the same > > >> default. The defconfig for arm64 recommends CONFIG_ACPI and this > > >> patch > > >> follows this recommendation in the qemuarm64 bsp configuration to > > >> fix > > >> ACPI-only EFI boots on this arch. > > >> > > >> arm (32bit) would also be unaffected as there is no ACPI support > > >> there > > >> at all. And this unconditional drop (CONFIG_ACPI) will actually fix > > >> a > > >> configuration warning when enabling EFI on a arm (32bit) machine: > > >> > > >> [INFO]: config 'CONFIG_ACPI' was set, but it wasn't assignable, > > >> check (parent) dependencies > > > > > > What's weird is that I'm not seeing this issue at all, and I'm > > > compiling with and without efi enabled. See > > > https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-kernel/linux/linux-yocto_%25.bbappend > > > https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-kernel/linux/files/efi.cfg > > > > > > with edk2 (uefi) > > > https://gitlab.com/jonmason00/meta-arm/-/jobs/3868649253 > > > without edk2 (using u-boot) > > > https://gitlab.com/jonmason00/meta-arm/-/jobs/3868649241 > > > > > > For giggles, I added the same efi.cfg to qemuarmv5 to see if it would > > > cause an issue (as maybe the sstate is hiding the warnings), and I > > > don't see it there either. Is there a better way than this to > > > replicate it? > > > > > > Also, if this one is holding the other back, feel free to drop and > > > I'll mess with it again later. > > > > +Andrei Gherzan to this mail, > Resent with proper email.
We have a couple of options to resolve this. a) since we can't reproduce the audit warning, we could apply the patch and undo the dropping of ACPI in the EFI fragment. If the warning does come back, I could address it, as we'd have a reproducing configuration b) as we did with qemuarm64, we could get BSPs to include CONFIG_ACPI when they use EFI and know they also need ACPI to be enabled. Bruce > > > > > I'm also facing the same issue, with a qemuarm64 board MACHINE_FEATURES > > have the EFI but it refuses to boot and I needed to manually set > > CONFIG_ACPI as it was missing to my kernel config. > > > > @Andrei could you explain which ACPI-only ARM64 EFI boots would break > > with this patch? > > > > Is seems that John did multiple test and didn't reproduce the issue. > > > > Thanks, > > Clement > > > > > > > > > > > > Thanks, > > > Jon > > > > > > > > > > > > > > >> > > >> Signed-off-by: Andrei Gherzan <andrei.gher...@huawei.com> > > >> Signed-off-by: Bruce Ashfield <bruce.ashfi...@gmail.com> > > >> > > >> diff --git a/bsp/qemuarm64/qemuarm64.cfg b/bsp/qemuarm64/qemuarm64.cfg > > >> index ef8d3ed023d..03fdc58cccf 100644 > > >> --- a/bsp/qemuarm64/qemuarm64.cfg > > >> +++ b/bsp/qemuarm64/qemuarm64.cfg > > >> @@ -32,3 +32,10 @@ CONFIG_RTC_DRV_PL031=y > > >> # PCI configs, needed for virtio-rng (and others) > > >> CONFIG_PCI=y > > >> CONFIG_PCI_HOST_GENERIC=y > > >> + > > >> +# arm64 defconfig suggests CONFIG_ACPI as default because it won't > > >> be enabled > > >> +# with CONFIG_EFI - even though ACPI-only ARM64 EFI boots would > > >> break > > >> +# otherwise. We also do the same here as a sane default. > > >> +CONFIG_ARCH_SUPPORTS_ACPI=y > > >> +CONFIG_ACPI=y > > >> + > > >> diff --git a/cfg/efi.cfg b/cfg/efi.cfg > > >> index d3dfd603dc5..d729cbe9fc7 100644 > > >> --- a/cfg/efi.cfg > > >> +++ b/cfg/efi.cfg > > >> @@ -3,7 +3,6 @@ > > >> > > >> # Dependencies > > >> CONFIG_PCI=y > > >> -CONFIG_ACPI=y > > >> > > >> # Enable basic EFI support > > >> CONFIG_EFI=y > > >> > > >> =============== > > >> > > >> So what's the right path ? We could potentially declare the option > > >> non-hardware so the warning doesn't come back. More BSPs may need > > >> to have the option added to them, if we are seeing boot issues. But > > >> constantly adding an option to many BSPs does indicate that it could > > >> be enabled in a more generic place. > > >> > > >> We could also create an edk2 fragment, and just have it include > > >> efi and add this option ? And then BSPs we want to support edk2 > > >> could include that ? That at least gets us some abstraction and > > >> assigns a meaningful name to the feature we are trying to enable. > > >> > > >> Bruce > > >> > > >> > > >> In message: [yocto-kernel-cache][master/yocto-6.1 PATCH 2/2] efi: add > > >> ACPI enablement > > >> on 28/02/2023 Jon Mason wrote: > > >> > > >>> CONFIG_ACPI is needed for qemuarm and qemuarm64 kernels to boot edk2. > > >>> Since this is only needed for edk2, add this to the efi config fragment. > > >>> > > >>> Signed-off-by: Jon Mason <jdma...@kudzu.us> > > >>> --- > > >>> cfg/efi.cfg | 3 +++ > > >>> 1 file changed, 3 insertions(+) > > >>> > > >>> diff --git a/cfg/efi.cfg b/cfg/efi.cfg > > >>> index d729cbe9fc78..482e622bce97 100644 > > >>> --- a/cfg/efi.cfg > > >>> +++ b/cfg/efi.cfg > > >>> @@ -8,3 +8,6 @@ CONFIG_PCI=y > > >>> CONFIG_EFI=y > > >>> CONFIG_EFI_STUB=y > > >>> CONFIG_EFIVAR_FS=y > > >>> + > > >>> +# While you can do EFI with device tree, the vast majority do ACPI > > >>> +CONFIG_ACPI=y > > >>> -- > > >>> 2.30.2 > > >>> > > > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12782): https://lists.yoctoproject.org/g/linux-yocto/message/12782 Mute This Topic: https://lists.yoctoproject.org/mt/97296889/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
