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.web11.5704.1588857862390073712 for ; Thu, 07 May 2020 06:24:22 -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 EB6FED6E; Thu, 7 May 2020 06:24:21 -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 BBDE53F68F; Thu, 7 May 2020 06:24:19 -0700 (PDT) Subject: Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from? To: devel@edk2.groups.io, daniel.schaefer@hpe.com, Ard Biesheuvel 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 References: <20200224221949.28826-1-atish.patra@wdc.com> <4de513ea-26fb-c830-2348-c0f57946fd3d@hpe.com> From: "Ard Biesheuvel" Message-ID: <3cb1d47e-983f-dd93-33d2-5a7896791dde@arm.com> Date: Thu, 7 May 2020 15:24:17 +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: <4de513ea-26fb-c830-2348-c0f57946fd3d@hpe.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/7/20 3:18 PM, Daniel Schaefer via groups.io wrote: > Hi Ard and others, >=20 > TLDR; We have APRIORI definitions from other places in EDK2 but there's= =20 > no explanation as to why they are there. >=20 > 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 ;) >=20 > On 2/25/20 10:07 AM, Ard Biesheuvel wrote: > > What I did notice is the use of APRIORI PEI and APRIORI DXE sections > > in your platform descriptions. I recommend you try to avoid that, as > > it is a maintenance burden going forward: instead, please use dummy > > protocols and NULL library class resolutions if you need to make > > generic components depend on platform specific protocols. Also, plea= se > > document this - the APRIORI section does not explain *why* you have = to > > circumvent the ordinary dependency tree based module dispatch. >=20 > I'm taking a look at this right now. > You're absolutely right - we should reduce or document APRIORIs. >=20 > However, Abner told me that he had only copied most of the FDF from oth= er > places in EDK2.This is what we currently have: >=20 > APRIORI PEI { > =C2=A0 INF=20 > MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRoute= rPei.inf=20 >=20 > =C2=A0 INF=20 > MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf > =C2=A0 INF=C2=A0 MdeModulePkg/Universal/PCD/Pei/Pcd.inf > } > APRIORI DXE { > =C2=A0 INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf > =C2=A0 INF=C2=A0 MdeModulePkg/Universal/PCD/Dxe/Pcd.inf > =C2=A0 INF=20 > Platform/SiFive/U5SeriesPkg/Universal/Dxe/RamFvbServicesRuntimeDxe/FvbS= ervicesRuntimeDxe.inf=20 >=20 > } >=20 > I can remove all of APRIORI PEI and it boots properly. Of the DXEs I ca= n=20 > only > remove FvbServicesRuntimeDxe, otherwise some DXEs are dispatched in the= =20 > 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 case?