Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4452118ybb; Tue, 14 Apr 2020 07:36:20 -0700 (PDT) X-Google-Smtp-Source: APiQypJuh3C73rDJwUT6emhhiQWyeIsw5U7+k7i04UzhslbVP75GXmjD+WBA5mFNpmxOYWXVIFrR X-Received: by 2002:aa7:db41:: with SMTP id n1mr20355464edt.260.1586874979933; Tue, 14 Apr 2020 07:36:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586874979; cv=none; d=google.com; s=arc-20160816; b=dK30YWE+s0OorsXpwsZsp7d9RT8oEa6nEz+XtruF/1UemzUWQ6gU3UWmIIU8HIcNNp yO8YFCraFS4CYpnnx0sE4FZdeidGc/+yscq7s3d4g0Tqh3KIYJvaXmh0SMR4PvvnHFfY y2kRluheY4bZ/Cz0X3kR+5qJFZx/a/3ClTjCJYMEajU6PyiOuBnXe+JU7I1JZxZVhbF2 AQILHuCyTZyBlaNxvoaZvPrDM0yEz6q6FvCNRAeAz4HPbgNUBsrP5mk4OkXZZgylSyry RgfWJsEWFuKAyEcsY8AjcRKxfK/OECW77ygRKdkSpznzw+rj4p3zzQ84rx4G9wg5xRGl w3og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=8fu2EomF01hOlRt2drZ0LQQl7yyoInoWnDvbfw4tvQM=; b=EFtwxI/+aszdCR9WrWwYbpqkGYLlRecqZUZtlbfs+i67maUshVPHjNEtcrRlMLk2/p czgVOp1FAUz+ZtH3WVlXH77fn7UekeD28ISNexzI5SnSzxpxg8iUy14OZdw7MBKRIk8O kNbT2HvgPHWQkS+32fK3HaLSkms/hunhbLEochPlJpxpKvCpcVi40g/Y6hWEOO6pl5zJ j0AhIVra5WncwwPib199VYcBIusB6OCB+1JL2YTMv/pdloi/fjHQgb1oTPtpV5GZyv8Q VROtlrgtbjG3dR1V9CSmJco+IeY1lCWXTpjF6LKA0w7K7ezUOYE/xM5C/r3vHDkApu8H rFJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NClJpw+C; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id co20si4209877edb.134.2020.04.14.07.35.55; Tue, 14 Apr 2020 07:36:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NClJpw+C; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406101AbgDNGqP (ORCPT + 99 others); Tue, 14 Apr 2020 02:46:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:38220 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728133AbgDNGqO (ORCPT ); Tue, 14 Apr 2020 02:46:14 -0400 Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 16BBA20735; Tue, 14 Apr 2020 06:46:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586846773; bh=8fu2EomF01hOlRt2drZ0LQQl7yyoInoWnDvbfw4tvQM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NClJpw+CgSR3IQKEpEheu2mjiO2H2WzZbKqPe57LT6UIk8K7FBxcPlwarnEfKzVDn 8gAWXDJho7TGDI5LaaaF7F6gMQeB7bHjRAx5ujPe2tY8yy/sdR1FqKnfzf92NNlXpm zSDJ+ib5oZ9aFB04jqO6l+nUUrpvQ5NYX3SRRdWE= Received: by mail-io1-f44.google.com with SMTP id s18so8736620ioe.10; Mon, 13 Apr 2020 23:46:13 -0700 (PDT) X-Gm-Message-State: AGi0Puas06QcmQbZCKh4ttdAxSAlo/hcFESxvgP8gfNibv8j4WVyT3o/ SfNxprF+7NbiZ7EmM1sJv0j1h7dWscWmm8y+i4I= X-Received: by 2002:a05:6602:1550:: with SMTP id h16mr20064740iow.171.1586846772506; Mon, 13 Apr 2020 23:46:12 -0700 (PDT) MIME-Version: 1.0 References: <1586468669-21456-1-git-send-email-victor.erminpour@oracle.com> <95f421ad-6ba7-b968-d605-c464bc1df4e2@oracle.com> In-Reply-To: <95f421ad-6ba7-b968-d605-c464bc1df4e2@oracle.com> From: Ard Biesheuvel Date: Tue, 14 Apr 2020 08:46:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] efi/libstub/arm64: Enable __efistub_global define in .data section To: Victor Erminpour Cc: Arvind Sankar , linux-efi , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 14 Apr 2020 at 00:57, Victor Erminpour wrote: > > > > On 4/10/20 11:39 PM, Ard Biesheuvel wrote: > > On Sat, 11 Apr 2020 at 00:12, Victor Erminpour > > wrote: > >> > >> > >> > >> On 4/10/20 1:09 AM, Ard Biesheuvel wrote: > >>> On Thu, 9 Apr 2020 at 23:44, Victor Erminpour > >>> 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.