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

[Daniel Schaefer]

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?

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

Thanks,
Daniel


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#58792): https://edk2.groups.io/g/devel/message/58792
Mute This Topic: https://groups.io/mt/74049933/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-