From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 42533803AC for ; Wed, 15 Mar 2017 08:38:07 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A3B7DC04BD56; Wed, 15 Mar 2017 15:38:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A3B7DC04BD56 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A3B7DC04BD56 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-55.phx2.redhat.com [10.3.117.55]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2FFc5BV016894; Wed, 15 Mar 2017 11:38:06 -0400 To: Andrew Fish References: <426920F0-4266-4BB2-BF19-40715A0F1C01@apple.com> Cc: Michael Zimmermann , Feng Tian , "edk2-devel@lists.01.org" , Star Zeng , Liming Gao From: Laszlo Ersek Message-ID: <385c68bb-4a3f-e586-f62b-9dd9f9c6490b@redhat.com> Date: Wed, 15 Mar 2017 16:38:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <426920F0-4266-4BB2-BF19-40715A0F1C01@apple.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 15 Mar 2017 15:38:07 +0000 (UTC) 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 15:38:07 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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. Thanks Laszlo