> On Mar 15, 2017, at 7:29 PM, Gao, Liming <liming....@intel.com> wrote: > > Michael: > I agree this is an issue in PeiCore and DxeCore, because PI spec has no > limitation to nest FV number. Could you help submit one tracker in bugzillar? > We will fix it. >
Liming, Thanks for double checking the spec, I did not have time to do that today. Thanks, Andrew Fish > Thanks > Liming >> -----Original Message----- >> From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] >> Sent: Thursday, March 16, 2017 12:08 AM >> To: Andrew Fish <af...@apple.com> >> Cc: Laszlo Ersek <ler...@redhat.com>; Tian, Feng <feng.t...@intel.com>; Gao, >> Liming <liming....@intel.com>; >> edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Zeng, Star >> <star.z...@intel.com> >> Subject: Re: [edk2] how to load drivers from additional FV's? >> >> Andrew, using a fallback with 1 as the fourth argument didn't seem to work. >> >>> So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd >>> FV in the 1st FV_IMAGE Section. >> I've actually tried that before and it didn't seem to work. BUt after >> what you've said I tried using a uncompressed, nested FV like >> this(inside [FV.FvMain]): >> >> FILE FV_IMAGE = B67596E9-EA27-40E4-885C-5AE83D414BD4 { >> SECTION FV_IMAGE = FVMAINPLATFORM >> } >> >> And that actually worked! So is this a workaround or a clean solution? >> >> Thanks a lot >> Michael >> >> >> On Wed, Mar 15, 2017 at 4:54 PM, Andrew Fish <af...@apple.com> wrote: >>> >>> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek <ler...@redhat.com> wrote: >>> >>> On 03/15/17 16:13, Andrew Fish wrote: >>> >>> >>> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek <ler...@redhat.com> wrote: >>> >>> On 03/15/17 13:23, Michael Zimmermann wrote: >>> >>> I'm trying to add another FV section FVMAIN_COMPACT so I can keep >>> Platform specific drivers in a separate, included fdf. >>> >>> I did this: >>> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 { >>> SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF >>> PROCESSING_REQUIRED = TRUE { >>> SECTION FV_IMAGE = FVMAIN >>> SECTION FV_IMAGE = FVMAINPLATFORM >>> } >>> } >>> >>> The image builds file and using uefitool I can verify that the new FV >>> is inside the compressed section. >>> But none of the drivers gets discovered/loaded and I get 'Protocol not >>> present!!' errors. >>> >>> >>> The FVs need to be exposed to the DXE core via FV HOBs. See >>> - 9.8.5 "Firmware Volume HOBs" in Volume 2 of the Platform Init 1.5 >>> spec, >>> - and more importantly, 5.7 "Firmware Volume HOB" in Volume 3 of the >>> same. >>> >>> You can use the BuildFvHob() function for this. >>> >>> If the firmware volume contains PEIMs (... as well), then it has to be >>> exposed to the PEI core too, I think. I think the >>> PeiServicesInstallFvInfoPpi() function can be used for that. (See 3.3 >>> "PEI" in Volume 3 of the PI spec.) >>> >>> ... I used the PeiFvInitialization() function in >>> OvmfPkg/PlatformPei/Fv.c as a "cheat sheet" for the above. >>> >>> >>> Laszlo, >>> >>> I think this case is an FV that is compressed and nested in another FV that >>> is discovered. I think the issues is multiple FV Sections in an FV file are >>> not currently supported. >>> >>> >>> In OVMF we do the same: >>> >>> FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 { >>> SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = >>> TRUE { >>> # >>> # These firmware volumes will have files placed in them uncompressed, >>> # and then both firmware volumes will be compressed in a single >>> # compression operation in order to achieve better overall compression. >>> # >>> SECTION FV_IMAGE = PEIFV >>> SECTION FV_IMAGE = DXEFV >>> } >>> } >>> >>> "OvmfPkg/Sec/SecMain.c" decompresses the compressed FFS file into memory -- >>> which is special to OVMF, i.e. the fact that there is writeable memory in >>> SEC --, then jumps to the PEI entry point. PlatformPei then exposes DXEFV to >>> the PEI core (for loading the DXE core AIUI) and to the DXE core as well >>> (for loading DXE modules). >>> >>> The multiple FV sections in the FFS file are not discovered automatically. >>> First, the OVMF build process saves the final (= decompressed) in-memory >>> locations of the nested FVs into PCDs. Second, in DecompressMemFvs(), the >>> SEC module decompresses the outer, compressed, FFS file, then locates the >>> embedded FVs manually with FindFfsSectionInstance(), then moves the >>> decompressed FVs individually to their pre-recorded locations. >>> >>> In Michael's case, I think the same should be possible -- since FVMAIN is >>> running for him, the outer, compressed file must already be decompressed (in >>> full) to some temporary buffer in memory. If he can find, manually, the >>> second section (with the embedded FVMAINPLATFORM firmware volume in it) in >>> that area, then he can also expose it to the DXE core, I believe. >>> >>> >>> Laszlo, >>> >>> The DXE Core will dispatch FVs with Depex "automagically" but only one >>> FV_IMAGE Section per FV_IMAGE file. >>> >>> So one workaround would be to add a 2nd FV_IMAGE file that contains the 2nd >>> FV in the 1st FV_IMAGE Section. >>> >>> Also I'm not sure if the outer FV is compressed, but compressing compressed >>> data usually does not end well as the algorithms leverage entropy. It is >>> better to just compress the outer FV and have everything else uncompressed >>> and let it all get compressed together. This also helps as there will be >>> common dictionary entries so compressing as much data as possible in one >>> shot usually works better. So for example if the outer FV is compressed it >>> may have a dictionary entry that represents CopyMem, and it can represent >>> that pattern with a small number of bits. Doing compression multiple times >>> causes duplication as each compressed image has one copy of CopyMem (massive >>> over simplification). Also if you compress a nested FV then the CopyMem >>> pattern does not exist in the compressed data, and since the compressed data >>> is more random it is hard to find patterns to compress, so it hurts the >>> compression of the outer FV. >>> >>> Thanks, >>> >>> Andrew Fish >>> >>> Thanks >>> Laszlo >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >>> > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
