From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 0CF898233C for ; Wed, 21 Dec 2016 17:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1482370687; 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=5RdVZxSJbKot9JZycKjXKg4lzPLEzYB06rEhCgLq9YI=; b=gMJp/kMmhZRvpIlxYAHu6HM0iEBLQJXVkOCdX/YLTXs064P362CKYuCzY5vBJFDE b7xIw968T4ZuDohMoGVyqZNQATqITLnsf1ONfhzU1eP+uTNTseXDveTFqF1qyO0y ey+vem3cI4VtVBPLRZblFe3XIk3pHs07AzUa0AvL97JxuHE98dp5Du+nVO1UYFvu LfUguOybP9qIISSmLvXtjSZLr/YCV4Vq1JhBPjoOfOgWFhZ4Y6ngyK1/gTNf5mKa mHwxjH9WFCwpNMEGLGcWRIdtfaOrXYgWdsHZZFoSoOVIU3dSKYp5lf8F1cGSayPR MGsALpBv1x5pH1CuXBTYWw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id E8.08.05661.F7E2B585; Wed, 21 Dec 2016 17:38:07 -0800 (PST) X-AuditID: 11973e13-bf50e9a00000161d-30-585b2e7f9223 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay2.apple.com (Apple SCV relay) with SMTP id AE.ED.09148.F7E2B585; Wed, 21 Dec 2016 17:38:07 -0800 (PST) MIME-version: 1.0 Received: from [17.153.27.116] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OIK00IFHCJISY30@nwk-mmpp-sz11.apple.com>; Wed, 21 Dec 2016 17:38:07 -0800 (PST) Sender: afish@apple.com From: Andrew Fish In-reply-to: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C2FEB@shsmsx102.ccr.corp.intel.com> Date: Wed, 21 Dec 2016 17:38:06 -0800 Cc: edk2-devel Message-id: <23AF9C44-DF46-452F-B981-D86783FE676C@apple.com> References: <4B9E734E-C111-4CDB-AA8E-B3FA8B06D22B@apple.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C1D52@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C2FEB@shsmsx102.ccr.corp.intel.com> To: "Gao, Liming" X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FDorFuvFx1hMH+prsWeQ0eZLVbc28Du wOSxeM9LJo/u2f9YApiiuGxSUnMyy1KL9O0SuDKWNC9lLXgpV/Hs4y32BsZtkl2MnBwSAiYS 927dYe1i5OIQEtjLKNG1ZicTTOLt6n5GiMQhRonry2aAJXgFBCV+TL7H0sXIwcEsIC9x8Lws SJhZQEvi+6NWFoj6d4wSH8++ZgZJCAuIS7w7swnKVpNYvKmfDcRmE1CWWDH/AzuIzSkQJnF9 8UcWEJtFQFXi/aXtbBBDNSS+rt7ODrHXRqLx1mZmiAXNTBIdzffBGkSAih7e+80McpCEgKzE 7F9eIDUSAlvYJKZ/38w8gVF4FpK7ZyHcPQvJ3QsYmVcxCuUmZuboZuaZ6iUWFOSk6iXn525i BIX2dDvhHYynV1kdYhTgYFTi4XWYEhUhxJpYVlyZe4hRmoNFSZy3VCY6QkggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOj1d/P9U0h5/uPha+edkOn+f7dLM5rm2rX7LY52n7wT+HuqB0Sbfvm b2g9tnLJAfmj7jOcHjMLqT7YN7/94lPlT1s3Tjo66T73iiTz/L/2evfe35rbqjuRm3X5qkL2 S9EhR8I3/XNb590nIyLkkzPR6+LCpRWh04q/88fc7vsyS4nt9lemGNOiCiWW4oxEQy3mouJE AF3Er5VOAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42IRbCierVuvFx1hcPeXpMWeQ0eZLVbc28Du wOSxeM9LJo/u2f9YApiiuGxSUnMyy1KL9O0SuDKWNC9lLXgpV/Hs4y32BsZtkl2MnBwSAiYS b1f3M0LYYhIX7q1n62Lk4hASOMQocX3ZDCaQBK+AoMSPyfdYuhg5OJgF5CUOnpcFCTMLaEl8 f9TKAlH/jlHi49nXzCAJYQFxiXdnNkHZahKLN/WzgdhsAsoSK+Z/YAexOQXCJK4v/sgCYrMI qEq8v7SdDWKohsTX1dvZIfbaSDTe2swMsaCZSaKj+T5YgwhQ0cN7v5lBDpIQkJWY/ctrAqPg LCSnzkI4dRaSUxcwMq9iFChKzUmsNNJLLCjISdVLzs/dxAgO0ULnHYzHllkdYhTgYFTi4Z0x LSpCiDWxrLgyFxgWHMxKIrxtOtERQrwpiZVVqUX58UWlOanFhxiTge6fyCwlmpwPjJ+8knhD ExMDE2NjM2NjcxNz0oSVxHnN+SIihATSE0tSs1NTC1KLYLYwcXBKNTBWn3q82yAzO8z+8nfG txNzZ+nyFt9MlVxz79HURXoOzx6xquga+8puDOo9I5Isx2H/I61oWdKGk933TAXeC7O17M/a lWl90Dxjlk9Pv5vEWRmpZZ8ZWs2CKn7uzmrs+l9Q9PBb9oszP95M+iH31f/b+eQNq7ZonMpZ mFH6etPs6jyRfz7yYg5KLMUZiYZazEXFiQAhBxgqlQIAAA== Subject: Re: FDF Spec question? 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: Thu, 22 Dec 2016 01:38:08 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Dec 21, 2016, at 5:18 PM, Gao, Liming wrote: > > Andrew: > You mean newform.bin has section header. It is just a leaf section. You expect to directly add it into GUIDED section without specify section header again. Right? > Liming, Yes. The issue is Leaf section header in the FDF is part of the thing that is getting compressed by the build tool. So if you skip that compression step you don't really have the section header, as all you really have is the compressed data. When you decompress the data (process the encapsulation section) it starts with the section header (it could be added pragmatically or just part of the original data). So if you skip the compression phase it seems you want to just point directly to the encapsulated data (the result). Basically my current syntax is pre-pending an unused leaf section header at the beginning of the compressed data. The decompressor has to index sizeof(EFI_COMMON_SECTION_HEADER) into the Source buffer to find the header of the compressed data to process. The size of the compressed data is already represented in the encapsulation section, so this extra leaf section is an artifact of the FDF syntax. Thanks, Andrew Fish > Thanks > Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish > Sent: Thursday, December 22, 2016 1:29 AM > To: Gao, Liming > Cc: edk2-devel > Subject: Re: [edk2] FDF Spec question? > > >> On Dec 21, 2016, at 6:27 AM, Gao, Liming wrote: >> >> Andrew: >> Encapsulation section data is the section stream, not raw format. Then, Leaf section can be extracted from encapsulation section. >> > > Liming, > > I happen to have the section stream in binary form checked into the source tree. The section extraction code actually dynamically creates the section header(s) for the stream and this means the section header in the FV is not really used (the section extraction code actually just skips over it). > > Technically speaking only the post processed GUID'ed section needs to produce the leaf. My case is kind of like I compressed the data without the section header. The section header is redundant data from the section extraction codes point of view as the binary format already has that info. > > Thanks, > > Andrew Fish > >> Thanks >> Liming >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish >> Sent: Wednesday, December 21, 2016 8:27 AM >> To: edk2-devel >> Subject: [edk2] FDF Spec question? >> >> Is it possible in the FDF syntax to make the payload of a EFI_SECTION_GUID_DEFINED (Encapsulating section) a raw binary file? >> >> I can make the contents of the GUID'ed encapsulation section a section. But when I'm processing the GUID'ed section I just end up skipping over the extra 4 byte section header so it is unused space. >> >> SECTION GUIDED 4C2B8C75-C6F6-11E6-B483-B8E8562CBAFA PROCESSING_REQUIRED = TRUE { >> SECTION RAW = $(WORKSPACE)/MyPackage/MyNewType/Binary/newform.bin >> } >> >> There is a syntax to make a leaf section a binary file. >> >> SECTION SUBTYPE_GUID AFC13561-9A65-4754-9C93-E133B3B8767C = $(WORKSPACE)/MyPackage/MyNewType/Binary/newform.bin >> >> >> Thanks, >> >> Andrew Fish >> _______________________________________________ >> 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 > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel