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

[Daniel Schaefer]

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


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

View/Reply Online (#58790): https://edk2.groups.io/g/devel/message/58790
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]
-=-=-=-=-=-=-=-=-=-=-=-