[edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from?
Ard Biesheuvel
ard.biesheuvel at arm.com
Thu May 7 13:53:04 UTC 2020
(+ 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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#58793): https://edk2.groups.io/g/devel/message/58793
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]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list