From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 9977E82406 for ; Thu, 22 Dec 2016 21:17:27 -0800 (PST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP; 22 Dec 2016 21:17:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,391,1477983600"; d="scan'208";a="42681301" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 22 Dec 2016 21:17:27 -0800 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 22 Dec 2016 21:17:27 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 22 Dec 2016 21:17:26 -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 13:17:24 +0800 From: "Gao, Liming" To: "afish@apple.com" CC: edk2-devel Thread-Topic: [edk2] FDF Spec question? Thread-Index: AQHSWyD6ajcIFFV2/UCS/4347so5i6EScM3Q//+yS4CAAQjIoP//f9cAgAJL0xD//4DjgAAQ8jtA Date: Fri, 23 Dec 2016 05:17:23 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C38DC@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> <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C389E@shsmsx102.ccr.corp.intel.com> In-Reply-To: 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 05:17:27 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew: edk2 build output lists all generated binary files. Could you use the bin= ary file without section header?=20 Thanks Liming > -----Original Message----- > From: afish@apple.com [mailto:afish@apple.com] > Sent: Friday, December 23, 2016 1:07 PM > To: Gao, Liming > Cc: edk2-devel > Subject: Re: [edk2] FDF Spec question? >=20 >=20 > > On Dec 22, 2016, at 8:59 PM, Gao, Liming wrote: > > > > Andrew: > > I am not clear your usage. Could you use source section and compressed > section for the data before and after compression? Here, section means P= I > EFI section format file. Take Lzma compression as the example, source da= ta > is 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 d= ata. > Here, there is only one GUIDED section header. > > >=20 > Liming, >=20 > I forgot to mention that the build tool for 4C2B8C75-C6F6-11E6-B483- > B8E8562CBAFA just copies newform.bin to newform.bin without any > processing. The is the only way you can use a "pre-processed" binary with > the existing tools. This is why the syntax under the encapsulated section= is > not needed in this special case. >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 > > For the below case, BaseTools will add RAW section header for the inp= ut > newform.bin, then call the matched GUIDed tool to process this raw sectio= n > to get the processed data, last append GUIDed section header before the > processed data as the output GUIDed section. > > 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? > >> > >> > >>> 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. Y= ou > >> 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 compress= ed > 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 head= er > 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 lea= f > 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. Th= en, > >> 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 sec= tion > >> header(s) for the stream and this means the section header in the FV i= s > 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 withou= t > the > >> section header. The section header is redundant data from the section > >> extraction codes point of view as the binary format already has that i= nfo. > >>> > >>> 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 secti= on. > >> But when I'm processing the GUID'ed section I just end up skipping ove= r > the > >> 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 > >> > >> _______________________________________________ > >> edk2-devel mailing list > >> edk2-devel@lists.01.org > >> https://lists.01.org/mailman/listinfo/edk2-devel