From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web10.6484.1588859590887144669 for ; Thu, 07 May 2020 06:53:11 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 649E3D6E; Thu, 7 May 2020 06:53:09 -0700 (PDT) Received: from [192.168.1.81] (unknown [10.37.8.179]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 38DE83F68F; Thu, 7 May 2020 06:53:07 -0700 (PDT) Subject: Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from? To: Daniel Schaefer , devel@edk2.groups.io Cc: "Chang, Abner (HPS SW/FW Technologist)" , Atish Patra , Heinrich Schuchardt , Atish Patra , Alexander Graf , Anup Patel , "leif@nuviainc.com" , jordan.l.justen@intel.com, Laszlo Ersek References: <20200224221949.28826-1-atish.patra@wdc.com> <4de513ea-26fb-c830-2348-c0f57946fd3d@hpe.com> <3cb1d47e-983f-dd93-33d2-5a7896791dde@arm.com> From: "Ard Biesheuvel" Message-ID: Date: Thu, 7 May 2020 15:53:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable (+ Laszlo) On 5/7/20 3:43 PM, Daniel Schaefer wrote: > On 5/7/20 3:24 PM, Ard Biesheuvel wrote: >> On 5/7/20 3:18 PM, Daniel Schaefer via groups.io wrote: >>> Hi Ard and others, >>> >>> TLDR; We have APRIORI definitions from other places in EDK2 but=20 >>> there's no explanation as to why they are there. >>> >>> I'm taking this to the EDK2 list, since it doesn't concern U-Boot. >>> I kept some other people related to UEFI, maybe you're interested ;) >>> >>> On 2/25/20 10:07 AM, Ard Biesheuvel wrote: >>> =C2=A0> What I did notice is the use of APRIORI PEI and APRIORI DXE s= ections >>> =C2=A0> in your platform descriptions. I recommend you try to avoid t= hat, as >>> =C2=A0> it is a maintenance burden going forward: instead, please use= dummy >>> =C2=A0> protocols and NULL library class resolutions if you need to m= ake >>> =C2=A0> generic components depend on platform specific protocols. Als= o,=20 >>> please >>> =C2=A0> document this - the APRIORI section does not explain *why* yo= u=20 >>> have to >>> =C2=A0> circumvent the ordinary dependency tree based module dispatch= . >>> >>> I'm taking a look at this right now. >>> You're absolutely right - we should reduce or document APRIORIs. >>> >>> However, Abner told me that he had only copied most of the FDF from=20 >>> other >>> places in EDK2.This is what we currently have: >>> >>> APRIORI PEI { >>> =C2=A0=C2=A0 INF=20 >>> MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRou= terPei.inf=20 >>> >>> =C2=A0=C2=A0 INF=20 >>> MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf >>> =C2=A0=C2=A0 INF=C2=A0 MdeModulePkg/Universal/PCD/Pei/Pcd.inf >>> } >>> APRIORI DXE { >>> =C2=A0=C2=A0 INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.i= nf >>> =C2=A0=C2=A0 INF=C2=A0 MdeModulePkg/Universal/PCD/Dxe/Pcd.inf >>> =C2=A0=C2=A0 INF=20 >>> Platform/SiFive/U5SeriesPkg/Universal/Dxe/RamFvbServicesRuntimeDxe/Fv= bServicesRuntimeDxe.inf=20 >>> >>> } >>> >>> I can remove all of APRIORI PEI and it boots properly. Of the DXEs I=20 >>> can only >>> remove FvbServicesRuntimeDxe, otherwise some DXEs are dispatched in=20 >>> the wrong >>> order and boot fails. >> >> This means some modules have an undeclared dependency on one of the=20 >> remaining modules. Can you elaborate on how the boot fails in this cas= e? >> > The error is > =C2=A0 ASSERT [FvbServicesRuntimeDxe]=20 > /edk2/MdePkg/Library/DxePcdLib/DxePcdLib.c(72): !EFI_ERROR (Status) > In this line, DxePcdLib tries to consume gPcdProtocolGuid. Therefor if = I=20 > add > the following to FvbServicesRuntimeDxe.inf: >=20 > [Depex] > =C2=A0 gEfiPcdProtocolGuid > [Protocols] > =C2=A0 gPcdProtocolGuid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ## SOMETIMES_CONSUMES > =C2=A0 gEfiPcdProtocolGuid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ## CONSUMES > =C2=A0 gGetPcdInfoProtocolGuid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ## SOMETIMES_CONSUMES > =C2=A0 gEfiGetPcdInfoProtocolGuid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ## SOMETIMES_CONSUMES >=20 > I can boot without error. > Looking at MdePkg/Library/DxePcdLib/DxePcdLib.inf I see that the librar= y=20 > has > exactly the same Depex and Protocols specified. Do DXEs have re-specify= =20 > them? > If yes, of what use is it to declare them for the library? Documentatio= n=20 > only? >=20 No this is unexpected. If the PcdLib dependency of=20 FvbServicesRuntimeDxe.inf resolves to=20 MdePkg/Library/DxePcdLib/DxePcdLib.inf, it should inherit the depex and=20 the protocol dependencies. > Should I/we try to remove the APRIORI entries from OVMF in a similar wa= y? >=20 Let's get to the bottom of this first. Laszlo may remember why exactly=20 those entries are there in the first place, and I suspect it is a=20 different issue.