From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 938D280329 for ; Wed, 15 Mar 2017 09:07:45 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id f54so11983567uaa.1 for ; Wed, 15 Mar 2017 09:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KLDwKBQObGsG8FCBSwkaRRiGSp5SGrn4VKe8vNg6iTw=; b=cduEKnJvYhmzRNqGKTWYJ9/nPr83ZiHaGfcU4dGaqxj9OOeffCA5EUHas/P83HF9SA awGcG/LS1exrtH9Kd2jaFO3OtK6TOjmBRUy1MGd6/khqhxfOQ5BzsmfQq0axke/Z0CBf jz6eFu1095ZVg+uWaTLZloHzsFYp1jEMTRgQbwrtH3ux4bshFESSnqsu4+4oqZdd3gQc tiiEg0FI0lYAZF88I9yneRgXMCbigaIUq8XQCuF3/1mWOl5Rw2khT6FLArBn8p+pIiKB Nr0hkKASBDLV4Ximoa9XTbelR9uq0w5qAC6KhmoDrPPGRgBpDE8tM49qyxlpaFPYfL6f P1ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KLDwKBQObGsG8FCBSwkaRRiGSp5SGrn4VKe8vNg6iTw=; b=RR75oyTruQpRAfW4NpxbMcZSQH70nC7XIxoGOVoqkEovTw8lge8WJiesP84CDEs5Zf +B2yM7Q5os2ICbD36SkUI8on/hOBoKeiI67Ta6a3bU4zN39rZgDABVvtsuTzyk1sVklq Af27O0m6KAWyI2YUvyw9pzCT3I+XeZ75kGhcXMww9h7vtbWeusGaxfg6jhgXm9tVqAl0 9+I/BBn0gy9hBWxXXfdHPVdBPfx1VzEEKAzhcXcDYRngk3mBLML8qU33jr0VloQL9NKU 3uJ6DDTx1MV1DDkHdbs7YPjJY5RREOOr2CpYix6cXLer/FTgtPNaM1LYxOPlwc24Yac8 j7Sw== X-Gm-Message-State: AFeK/H2jTlPnb06G919ckjt22K6bydwtqPXgfB98fMXFc31Z/pYb31HmAueS0QTMWLPlfBaSvxqNyBsIJyeLdA== X-Received: by 10.159.32.78 with SMTP id 72mr1387434uam.59.1489594064590; Wed, 15 Mar 2017 09:07:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.151.68 with HTTP; Wed, 15 Mar 2017 09:07:44 -0700 (PDT) In-Reply-To: <75A865F3-53E6-4C54-91A0-46A32E3CAB84@apple.com> References: <426920F0-4266-4BB2-BF19-40715A0F1C01@apple.com> <385c68bb-4a3f-e586-f62b-9dd9f9c6490b@redhat.com> <75A865F3-53E6-4C54-91A0-46A32E3CAB84@apple.com> From: Michael Zimmermann Date: Wed, 15 Mar 2017 17:07:44 +0100 Message-ID: To: Andrew Fish Cc: Laszlo Ersek , Feng Tian , Liming Gao , "edk2-devel@lists.01.org" , Star Zeng Subject: Re: how to load drivers from additional FV's? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:07:45 -0000 Content-Type: text/plain; charset=UTF-8 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 wrote: > > On Mar 15, 2017, at 8:38 AM, Laszlo Ersek wrote: > > On 03/15/17 16:13, Andrew Fish wrote: > > > On Mar 15, 2017, at 8:07 AM, Laszlo Ersek 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 > >