Bret, How does that test work? Does it make a custom FDF file?
Thanks, Andrew Fish > On May 7, 2020, at 9:45 AM, Bret Barkelew via groups.io > <bret.barkelew=microsoft....@groups.io> wrote: > > I know I’ve also seen tests that randomize the driver dispatch order to try > to catch these “implementation-specific” edge cases. Perhaps we could > instrument something similar with a weekly OVMF CI test? > > - Bret > > From: Andrew Fish via groups.io <mailto:afish=apple....@groups.io> > Sent: Thursday, May 7, 2020 9:43 AM > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Ard Biesheuvel > <mailto:ard.biesheu...@arm.com> > Cc: Daniel Schaefer <mailto:daniel.schae...@hpe.com>; Chang, Abner (HPS SW/FW > Technologist) <mailto:abner.ch...@hpe.com>; Atish Patra > <mailto:ati...@atishpatra.org>; Heinrich Schuchardt > <mailto:xypron.g...@gmx.de>; Atish Patra <mailto:atish.pa...@wdc.com>; > Alexander Graf <mailto:ag...@csgraf.de>; Anup Patel > <mailto:anup.pa...@wdc.com>; l...@nuviainc.com <mailto:l...@nuviainc.com>; > Jordan Justen <mailto:jordan.l.jus...@intel.com>; Laszlo Ersek > <mailto:ler...@redhat.com> > Subject: [EXTERNAL] Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF > APRIORIs come from? > > > > > On May 7, 2020, at 6:53 AM, Ard Biesheuvel <ard.biesheu...@arm.com > <mailto:ard.biesheu...@arm.com>> wrote: > > (+ 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 > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.io%2F&data=02%7C01%7Cbret.barkelew%40microsoft.com%7C55cf729cb7f2493df70508d7f2a5b761%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637244665879150410&sdata=3m1H%2BjDxdT258g641hJMpIXoSR3C7EmkGo3fpkZhVgw%3D&reserved=0> > 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. > > > Could be the dreaded my INF is wrong but it compiles issue. What happens is > dependencies in the INF are missing but get resolved by the library instances > or even worse libraries pulled in by the libraries. So it looks to me like it > is a missing Depex in the driver. Not all instances of the library, that are > valid for the module, imply the dependency. > > /Volumes/Case/edk2(master)>git grep PcdLib -- *.inf | grep LIBRARY_CLASS > MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf:21: LIBRARY_CLASS > = PcdLib > MdePkg/Library/DxePcdLib/DxePcdLib.inf:35: LIBRARY_CLASS = > PcdLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE > UEFI_APPLICATION UEFI_DRIVER > MdePkg/Library/PeiPcdLib/PeiPcdLib.inf:32: LIBRARY_CLASS = > PcdLib|PEIM PEI_CORE SEC > > > The easiest way to debug these kind of problems is to generate a report file > by passing `-y REPORTFILE` to build. For my projects I usually always build a > report file and dump it into the Build results directory. This will show what > libraries got linked in, and what the actual dependency expression resolved > to. > > > > 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. > > > It is good to get the history. In general the APRIORI files are used to force > a dispatch order for debugging, like getting status codes or serial output > quicker. > > From an architectural point of view the dispatch order is only defined as "if > your Depex is TRUE you can be dispatched". So they APRORI file lets you > define the undefined behavior. The implementation happens to walk the FV in > order and will dispatch and drivers with a Depex of TRUE and keep iterating > until all the Depex'es are TRUE or all the drivers dispatch. In the "good old > days" we would sort the PEIMs in dispatch order so that everything would > dispatch on the 1st pass to reduce the number of slow FLASH reads required to > boot. > > Thanks, > > Andrew Fish > > > > > > <3C121AAE0A3549E984277926BF20E545.png> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58799): https://edk2.groups.io/g/devel/message/58799 Mute This Topic: https://groups.io/mt/74054955/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
