From: "Daniel Schaefer" <daniel.schaefer@hpe.com>
To: Ard Biesheuvel <ard.biesheuvel@arm.com>, <devel@edk2.groups.io>
Cc: "Chang, Abner (HPS SW/FW Technologist)" <abner.chang@hpe.com>,
Atish Patra <atishp@atishpatra.org>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Atish Patra <atish.patra@wdc.com>,
Alexander Graf <agraf@csgraf.de>, Anup Patel <anup.patel@wdc.com>,
"leif@nuviainc.com" <leif@nuviainc.com>,
<jordan.l.justen@intel.com>
Subject: Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from?
Date: Thu, 7 May 2020 15:43:12 +0200 [thread overview]
Message-ID: <eea0e214-9bb3-3a00-ddbf-a2b6bfc2cb89@hpe.com> (raw)
In-Reply-To: <3cb1d47e-983f-dd93-33d2-5a7896791dde@arm.com>
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
next prev parent reply other threads:[~2020-05-07 13:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200224221949.28826-1-atish.patra@wdc.com>
[not found] ` <dcab6806-fa1c-8c7e-b0dc-2d96c017872d@gmx.de>
[not found] ` <CAKv+Gu_-1BrjiKKw6qa9a6vjXHrf=iYa1oaKCRr5HZf0HM+mZA@mail.gmail.com>
[not found] ` <CAOnJCULfew0aZ3FiDQAZZTPjzE5bvdN5of5AP_r6_1W+CQDh=A@mail.gmail.com>
[not found] ` <TU4PR8401MB0429018FEDB13B1057A452E4FFED0@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM>
[not found] ` <CAKv+Gu9vSVMg3L++7xM2LYV7XPoMtY-E1HXZa290srk0CfBqig@mail.gmail.com>
[not found] ` <TU4PR8401MB04290CF16E0037DD90FDAE15FFED0@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM>
[not found] ` <CAKv+Gu9kuiOag+BV5--QbhkEFCD8q8FJFzQ=uYV=oEMfrAo0Zg@mail.gmail.com>
2020-05-07 13:18 ` APRIORI in RISC-V or Where did OVMF APRIORIs come from? Daniel Schaefer
2020-05-07 13:24 ` [edk2-devel] " Ard Biesheuvel
2020-05-07 13:43 ` Daniel Schaefer [this message]
2020-05-07 13:53 ` Ard Biesheuvel
2020-05-07 16:42 ` Andrew Fish
2020-05-07 16:45 ` [EXTERNAL] " Bret Barkelew
2020-05-07 16:54 ` [EXTERNAL] " Andrew Fish
2020-05-07 17:00 ` Michael D Kinney
2020-05-08 11:05 ` [EXTERNAL] " Laszlo Ersek
2020-05-08 9:48 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eea0e214-9bb3-3a00-ddbf-a2b6bfc2cb89@hpe.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox