Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from?

["Ard Biesheuvel" <ard.biesheuvel@arm.com>]

(+ 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 
>>> 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:
>>>  > 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, 
>>> please
>>>  > document this - the APRIORI section does not explain *why* you 
>>> have to
>>>  > 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 
>>> other
>>> places in EDK2.This is what we currently have:
>>>
>>> APRIORI PEI {
>>>    INF 
>>> MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf 
>>>
>>>    INF 
>>> MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
>>>    INF  MdeModulePkg/Universal/PCD/Pei/Pcd.inf
>>> }
>>> APRIORI DXE {
>>>    INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>>>    INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>>>    INF 
>>> Platform/SiFive/U5SeriesPkg/Universal/Dxe/RamFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
>>>
>>> }
>>>
>>> I can remove all of APRIORI PEI and it boots properly. Of the DXEs I 
>>> can only
>>> remove FvbServicesRuntimeDxe, otherwise some DXEs are dispatched in 
>>> the wrong
>>> order and boot fails.
>>
>> This means some modules have an undeclared dependency on one of the 
>> remaining modules. Can you elaborate on how the boot fails in this case?
>>
> The error is
>    ASSERT [FvbServicesRuntimeDxe] 
> /edk2/MdePkg/Library/DxePcdLib/DxePcdLib.c(72): !EFI_ERROR (Status)
> In this line, DxePcdLib tries to consume gPcdProtocolGuid. Therefor if I 
> add
> the following to FvbServicesRuntimeDxe.inf:
> 
> [Depex]
>    gEfiPcdProtocolGuid
> [Protocols]
>    gPcdProtocolGuid                              ## SOMETIMES_CONSUMES
>    gEfiPcdProtocolGuid                           ## CONSUMES
>    gGetPcdInfoProtocolGuid                       ## SOMETIMES_CONSUMES
>    gEfiGetPcdInfoProtocolGuid                    ## SOMETIMES_CONSUMES
> 
> I can boot without error.
> Looking at MdePkg/Library/DxePcdLib/DxePcdLib.inf I see that the library 
> has
> exactly the same Depex and Protocols specified. Do DXEs have re-specify 
> them?
> If yes, of what use is it to declare them for the library? Documentation 
> only?
> 

No this is unexpected. If the PcdLib dependency of 
FvbServicesRuntimeDxe.inf resolves to 
MdePkg/Library/DxePcdLib/DxePcdLib.inf, it should inherit the depex and 
the protocol dependencies.

> Should I/we try to remove the APRIORI entries from OVMF in a similar way?
> 

Let's get to the bottom of this first. Laszlo may remember why exactly 
those entries are there in the first place, and I suspect it is a 
different issue.