On Tue, 14 Apr 2020 at 00:57, Victor Erminpour <victor.erminpour@xxxxxxxxxx> wrote: > > > > On 4/10/20 11:39 PM, Ard Biesheuvel wrote: > > On Sat, 11 Apr 2020 at 00:12, Victor Erminpour > > <victor.erminpour@xxxxxxxxxx> wrote: > >> > >> > >> > >> On 4/10/20 1:09 AM, Ard Biesheuvel wrote: > >>> On Thu, 9 Apr 2020 at 23:44, Victor Erminpour > >>> <victor.erminpour@xxxxxxxxxx> wrote: > >>>> > >>>> Enable the __efistub_global define to place variables in the > >>>> .data section for both CONFIG_ARM and CONFIG_ARM64. > >>>> > >>>> This places the EFIstub sys_table variable and other EFIstub > >>>> static variables in the .data section for both CONFIG_ARM and > >>>> CONFIG_ARM64. > >>>> > >>> > >>> What does that achieve? > >> > >> Hi Ard, > >> > >> Without placing these global variables in .data, I get the > >> following errors when booting an ARM64 EFI system: > >> > >> EFI stub: ERROR: Exit boot services failed. > >> EFI stub: ERROR: Failed to update FDT and exit boot services > >> > > > > Which boot loader are you using? Does this involve shim? > > > > grub2-efi-aa64-2.02-0.80.0.4.el7.aarch64 > shim-aa64-15-1.0.4.el7.aarch64 > Does your system give access to the UEFI shell? If so, could you please try booting the [uncompressed] Image file from the command prompt? Which hardware are you booting? > > Also, does it help if you add 'efi=no_disable_early_pci_dma'? > > > > Tried this boot time option, but to no effect. > > > > >> > >> I know that the ARM64 linker script is supposed to put the > >> .init.bss into the .init.data section, but I don't think this > >> is happening for all systems. > >> > >> Having it explicitly enabled for CONFIG_ARM64 worked for me. > >> > > > > OK, thanks for the report. However, we will be removing > > __efistub_global entirely during the next cycle, so this is not the > > right fix. > > Thanks Ard, this sounds promising! > Quite the opposite, unfortunately. It means the feature you are using to fix your boot issue is going away. This really looks like a bootloader issue to me, so let's narrow this down first. If there is a real kernel issue here that needs __efistub_global to be fixed, we obviously won't be removing it.
