From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 E0654823EE for ; Thu, 22 Dec 2016 20:59:58 -0800 (PST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP; 22 Dec 2016 20:59:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,391,1477983600"; d="scan'208";a="46311159" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga006.fm.intel.com with ESMTP; 22 Dec 2016 20:59:58 -0800 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 22 Dec 2016 20:59:58 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 22 Dec 2016 20:59:57 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.204]) with mapi id 14.03.0248.002; Fri, 23 Dec 2016 12:59:55 +0800 From: "Gao, Liming" To: Andrew Fish CC: edk2-devel Thread-Topic: [edk2] FDF Spec question? Thread-Index: AQHSWyD6ajcIFFV2/UCS/4347so5i6EScM3Q//+yS4CAAQjIoP//f9cAgAJL0xA= Date: Fri, 23 Dec 2016 04:59:54 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C389E@shsmsx102.ccr.corp.intel.com> References: <4B9E734E-C111-4CDB-AA8E-B3FA8B06D22B@apple.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C1D52@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C2FEB@shsmsx102.ccr.corp.intel.com> <23AF9C44-DF46-452F-B981-D86783FE676C@apple.com> In-Reply-To: <23AF9C44-DF46-452F-B981-D86783FE676C@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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: Fri, 23 Dec 2016 04:59:58 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew: I am not clear your usage. Could you use source section and compressed se= ction for the data before and after compression? Here, section means PI EF= I section format file. Take Lzma compression as the example, source data i= s the section stream. It may be combined of more than one sections, such as= two FV sections. OVMF FVMAIN_COMPACT is just a case. Compressed section is= the guided section. It is GUIDED section header + compressed data. Here, t= here is only one GUIDED section header.=20 For the below case, BaseTools will add RAW section header for the input = newform.bin, then call the matched GUIDed tool to process this raw section = to get the processed data, last append GUIDed section header before the pro= cessed data as the output GUIDed section.=20 SECTION GUIDED 4C2B8C75-C6F6-11E6-B483-B8E8562CBAFA PROCESSING_REQUIRED = =3D TRUE { SECTION RAW =3D $(WORKSPACE)/MyPackage/MyNewType/Binary/newform.bin } Thanks Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Andrew Fish > Sent: Thursday, December 22, 2016 9:38 AM > To: Gao, Liming > Cc: edk2-devel > Subject: Re: [edk2] FDF Spec question? >=20 >=20 > > 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. Yo= u > expect to directly add it into GUIDED section without specify section hea= der > again. Right? > > >=20 > Liming, >=20 > Yes. >=20 > 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 do= n'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 start= s > 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). >=20 > 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 s= ection > is an artifact of the FDF syntax. >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 > > 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 sou= rce > tree. The section extraction code actually dynamically creates the sectio= n > header(s) for the stream and this means the section header in the FV is n= ot > 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 t= he > 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 t= he > extra 4 byte section header so it is unused space. > >> > >> SECTION GUIDED 4C2B8C75-C6F6-11E6-B483-B8E8562CBAFA > PROCESSING_REQUIRED =3D TRUE { > >> SECTION RAW =3D > $(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 =3D > $(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 >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel