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 AB953803B1 for ; Thu, 16 Mar 2017 04:20:52 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F1014DD60; Thu, 16 Mar 2017 11:20:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1F1014DD60 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1F1014DD60 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-73.phx2.redhat.com [10.3.116.73]) by smtp.corp.redhat.com (Postfix) with ESMTP id 879C660F83; Thu, 16 Mar 2017 11:20:51 +0000 (UTC) To: Andrew Fish References: <426920F0-4266-4BB2-BF19-40715A0F1C01@apple.com> <385c68bb-4a3f-e586-f62b-9dd9f9c6490b@redhat.com> <75A865F3-53E6-4C54-91A0-46A32E3CAB84@apple.com> Cc: Feng Tian , Michael Zimmermann , Liming Gao , "edk2-devel@lists.01.org" , Star Zeng From: Laszlo Ersek Message-ID: Date: Thu, 16 Mar 2017 12:20:49 +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: <75A865F3-53E6-4C54-91A0-46A32E3CAB84@apple.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 16 Mar 2017 11:20:53 +0000 (UTC) Subject: Re: how to load drivers from additional FV's? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:20:52 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/15/17 16:54, 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. I apologize if my previous emails were confusing; I didn't mean to imply nested compression. OVMF doesn't do that. > It is better to just compress the outer FV and have everything > else uncompressed and let it all get compressed together. Yes, that's what OVMF does. Did you perhaps misread the comment above that I quoted from the FDF? "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." (Emphasis mine.) Thanks! Laszlo > 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 >