From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.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 40DA08029A for ; Wed, 15 Mar 2017 19:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489631533; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=D5cY3n6Ra5IyRkzyfTcGlEqWqI7AxxI1G47tH86Vgmg=; b=3LehlTjlOJ6yW4SC4FdLwnYOHjRyEimVQ8IBmc7bGTf9Y5Sn3yi/N2NEQEZnNkFj Pfr4V6u3+Bkl6KqJiPjapqw+a2Aq4ljd6KKsocQOXaIo1Bkalm1Tr+rUNm4bszOC Ppbd3z2xB8qgTugjd6FYr5J0SDWu/dKPbzsCS6d863TKi6Z627rqggNubdbU9gTI wSY2ZB2arkfibJUUpUqo2sm96vBRPy4hmHGaLgON5HxfAaHUsFqRSjdQYZt7l7OA 8kBhH2MnxCNOiosONu17IEcr+EsPZPOh/grDhhTpOPp2QIT81t3b9gSyZAAfusvH s/hL11HJyv8yQTMKl2lnow==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 2C.8C.30614.D29F9C85; Wed, 15 Mar 2017 19:32:13 -0700 (PDT) X-AuditID: 11973e15-27bcd9a000007796-59-58c9f92dc453 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay3.apple.com (Apple SCV relay) with SMTP id 8A.3E.01494.C29F9C85; Wed, 15 Mar 2017 19:32:13 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.47.209] (unknown [17.153.47.209]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OMV00761Z1NQY70@nwk-mmpp-sz09.apple.com>; Wed, 15 Mar 2017 19:32:12 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6F0AC8@shsmsx102.ccr.corp.intel.com> Date: Wed, 15 Mar 2017 19:32:11 -0700 Cc: Michael Zimmermann , "Tian, Feng" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Zeng, Star" Message-id: <09AC7E23-30D0-4329-B83E-B47B4CD95151@apple.com> References: <426920F0-4266-4BB2-BF19-40715A0F1C01@apple.com> <385c68bb-4a3f-e586-f62b-9dd9f9c6490b@redhat.com> <75A865F3-53E6-4C54-91A0-46A32E3CAB84@apple.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D6F0AC8@shsmsx102.ccr.corp.intel.com> To: "Gao, Liming" X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FAYrKv782SEwavVRhbr9nxjt5i0m91i 2bEdLBYr7m1gt5g79Smrxb5eawc2j52z7rJ7LN7zkslj0oXHzB7v911lC2CJ4rJJSc3JLEst 0rdL4MpomzSdteCyScXsVdvZGxiXaHUxcnJICJhITLj9lqmLkYtDSGAvo8TEIz/Yuxg5wBKN T1kg4gcZJZZtWcgI0sArICjxY/I9FpAaZgF5iYPnZUHCzAJaEt8ftbKA2EICE5kkXp0RArGF BcQl3p3ZxAxh20o0H5vBBmKzCShLrJj/AWwVp0CYxMYNsSBhFgFViRuzlrGCrGUWuMoocevi O1aItTYSd86eYYW4ZyOzxN/7c8EGiQhoSDy895sZ4mZZidm/vEBqJAQus0l8WrqaeQKj8Cwk Z89COHsWkrMXMDKvYhTKTczM0c3MM9NLLCjISdVLzs/dxAiKh+l2ojsYz6yyOsQowMGoxMP7 wv9khBBrYllxZe4hRmkOFiVxXpHFJyKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MJ5OufZX YqpB94rQt1/e8Kyaq7rp40Jbrqb0bZFdW479mD9F03XzWj2m1G+8a20Osajv9dl0O7s2Mspr Qv2trzMTDjxZxLTtdWd/ZMB3tXt7zsvkby46pjrlW2X4Uqt992b0b9xSsCfNW83FftfJ2bPy nTqctY69D570Rl6kqYj1a3PfQrc++RIlluKMREMt5qLiRAB+er9gaAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUi2FAcoKv782SEwf1vOhbr9nxjt5i0m91i 2bEdLBYr7m1gt5g79Smrxb5eawc2j52z7rJ7LN7zkslj0oXHzB7v911lC2CJ4rJJSc3JLEst 0rdL4MpomzSdteCyScXsVdvZGxiXaHUxcnBICJhIND5l6WLk4hASOMgosWzLQsYuRk4OXgFB iR+T77GA1DALyEscPC8LEmYW0JL4/qiVBcQWEpjIJPHqjBCILSwgLvHuzCZmCNtWovnYDDYQ m01AWWLF/A/sIGM4BcIkNm6IBQmzCKhK3Ji1jBVkLbPAVUaJWxffsUKstZG4c/YMK8Q9G5kl /t6fCzZIREBD4uG938wQN8tKzP7lNYFRYBaSS2chXDoLyaULGJlXMQoUpeYkVhrrJRYU5KTq JefnbmIEh29h8A7GP8usDjEKcDAq8fBO8D0ZIcSaWFZcmXuIUYKDWUmE9+oroBBvSmJlVWpR fnxRaU5q8SHGKqAHJjJLiSbnA2MrryTe0MTEwMTY2MzY2NzEnCrCSuK8v7SANgukJ5akZqem FqQWwSxn4uCUamAMP3FUYJZN3ru1tZsqT36rVJOL7Hxp4bsoetKljJY4tkO3pP86rbVXNTrR Iaf0gq+bz/WzSbJrn1homv68wEAhFUVP/XgLU6XQ7IAvR95FT308bYLI+lvi6yZ3+fZ1SL5I Fm9Vmit6ybfY6xznW70ihVNBVVoMbEkhYhLT7MxEo3Xi567apsRSnJFoqMVcVJwIANj76/66 AgAA 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 02:32:14 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Mar 15, 2017, at 7:29 PM, Gao, Liming 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:sigmaepsilon92@gmail.com] >> Sent: Thursday, March 16, 2017 12:08 AM >> To: Andrew Fish >> Cc: Laszlo Ersek ; Tian, Feng ; Gao, Liming ; >> edk2-devel@lists.01.org ; Zeng, Star >> 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 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 >>> >>> > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel