From: "Daniel Schaefer" <daniel.schaefer@hpe.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
<jordan.l.justen@intel.com>
Subject: APRIORI in RISC-V or Where did OVMF APRIORIs come from?
Date: Thu, 7 May 2020 15:18:48 +0200 [thread overview]
Message-ID: <4de513ea-26fb-c830-2348-c0f57946fd3d@hpe.com> (raw)
In-Reply-To: <CAKv+Gu9kuiOag+BV5--QbhkEFCD8q8FJFzQ=uYV=oEMfrAo0Zg@mail.gmail.com>
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.
If we compare our APRIORIs with OVMF (OvmfPkg/OvmfPkgX64.fdf) we can see
that
it contains the same DXEs from MdeModulePkg in APRIORI, as well as the OVMF
version of FvbServicesRuntimeDxe:
APRIORI PEI {
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
}
APRIORI DXE {
INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
!if $(SMM_REQUIRE) == FALSE
INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
!endif
}
I conclude, that we cannot give an explanation for why we added them.
I'm not
sure whether to remove as many as possible now or to keep a similar list as
OvmfPkg. If we keep them, people can just add DXEs like they do in OVMF and
they will behave the same. If we remove them, we might expose some
dependency
issues in existing DXEs. That would be an advantage, so I would vote for
this
option.
By the way, currently our most recent code is here:
https://github.com/changab/edk2-platforms/tree/riscv-smode-lib/Platform/SiFive/U5SeriesPkg
https://github.com/changab/edk2-platforms/tree/riscv-smode-lib/Silicon/RISC-V/ProcessorPkg
https://github.com/changab/edk2-platforms/tree/riscv-smode-lib/Platform/RISC-V/PlatformPkg
Thanks,
Daniel
next parent reply other threads:[~2020-05-07 13:19 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 ` Daniel Schaefer [this message]
2020-05-07 13:24 ` [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from? Ard Biesheuvel
2020-05-07 13:43 ` Daniel Schaefer
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=4de513ea-26fb-c830-2348-c0f57946fd3d@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