From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CB2492265A326 for ; Wed, 11 Apr 2018 09:20:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2190F722C7; Wed, 11 Apr 2018 16:20:48 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-97.rdu2.redhat.com [10.10.120.97]) by smtp.corp.redhat.com (Postfix) with ESMTP id B845C215CDAF; Wed, 11 Apr 2018 16:20:46 +0000 (UTC) To: Supreeth Venkatesh , Steve Capper , "edk2-devel@lists.01.org" Cc: Ard Biesheuvel , Leif Lindholm , Nariman Poushin References: From: Laszlo Ersek Message-ID: <63ca473d-b032-3e46-b3c1-62734cf7ea6f@redhat.com> Date: Wed, 11 Apr 2018 18:20:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 11 Apr 2018 16:20:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 11 Apr 2018 16:20:48 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: Boot failure for ArmVExpress-FVP-AArch64, CpuArch protocol does not appear to be registered X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 16:20:49 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/11/18 17:34, Supreeth Venkatesh wrote: > Laszlo/Steve, > > I ran into the same problem on ArmVExpress-FVP-AArch64 while running > management mode. > I have fixed this problem in this patch by reordering driver load > order here: > https://lists.01.org/pipermail/edk2-devel/2018-April/023550.html > > Not sure whether Leif/Ard/Laszlo agree with this. Unfortunately, that's not a fix, just an unreliable work-around. The dispatch order between DXE modules is unspecified beyond the order imposed by their dependency expressions (hence "depex"). I don't claim that it's always feasible to fix the problem with custom NULL protocols, but whenever it is, I suggest that we do. The protocol dependency mechanism is clean and extensible, unlike "BEFORE" depex opcodes, or the "naked" listing order in FDF files. Admittedly, sometimes there's no way around specifying a precise (partial) load order for several modules. For that, the APRIORI DXE file should be used, if possible. And, the APRIORI DXE file should be kept as small as possible (listing as few modules as possible). I think we should implement the following changes. (1) "ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" produces two custom protocols already, gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid. These are installed on the following call path: InterruptDxeInitialize() [ArmPkg/Drivers/ArmGic/ArmGicDxe.c] GicV2DxeInitialize() | GicV3DxeInitialize() [ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c] InstallAndRegisterInterruptService() [ArmPkg/Drivers/ArmGic/ArmGicCommonDxe.c] The GUIDs come from "EmbeddedPkg/Include/Protocol/HardwareInterrupt.h" and "EmbeddedPkg/Include/Protocol/HardwareInterrupt2.h", respectively. Annotate "ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" that it produces gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid, and that it consumes (with a protocol notify) gEfiCpuArchProtocolGuid. (2) Replace "AFTER gArmGicDxeFileGuid" in "ArmPkg/Drivers/CpuDxe/CpuDxe.inf" with "gHardwareInterruptProtocolGuid OR gHardwareInterrupt2ProtocolGuid". (3) Replace "BEFORE gVariableRuntimeDxeFileGuid" in "ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf" with "gEfiCpuArchProtocolGuid". (4) In all platforms that use NorFlashDxe without formatting a variable store template at build time, make the variable driver depend on NorFlashDxe's runtime formatting, with the trick I described earlier. In fact, I haven't booted ArmVirtQemu in a while, and now I'm finding it is afflicted by the same assertion failure as the one reported by Steve. This is somewhat strange because I don't see any Arm*Pkg changes since my commit 34711bf19833 ("ArmVirtPkg/PlatformBootManagerLib: return to "-kernel before boot devices"", 2018-03-16). I definitely tested that commit successfully, so I wonder what may have triggered / exposed the issue recently. Possibly BaseTools changes? That wouldn't be surprising; again, the dispatch order is unspecified beyond depexes. Either way, I guess I better get to work on this. Thanks, Laszlo