Re: how to load drivers from additional FV's?

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

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 <afish@apple.com> wrote:
>
> On Mar 15, 2017, at 8:38 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 03/15/17 16:13, Andrew Fish wrote:
>
>
> On Mar 15, 2017, at 8:07 AM, Laszlo Ersek <lersek@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
>
>