Re: FDF Spec question?

["Gao, Liming" <liming.gao@intel.com>]

Andrew:
  edk2 build output lists all generated binary files. Could you use the binary file without section header? 

Thanks
Liming
> -----Original Message-----
> From: afish@apple.com [mailto:afish@apple.com]
> Sent: Friday, December 23, 2016 1:07 PM
> To: Gao, Liming <liming.gao@intel.com>
> Cc: edk2-devel <edk2-devel@lists.01.org>
> Subject: Re: [edk2] FDF Spec question?
> 
> 
> > On Dec 22, 2016, at 8:59 PM, Gao, Liming <liming.gao@intel.com> 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 PI
> EFI section format file. Take Lzma compression as the example,  source data
> 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 data.
> Here, there is only one GUIDED section header.
> >
> 
> Liming,
> 
> 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.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> >  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
> processed data as the output GUIDed section.
> >  SECTION GUIDED 4C2B8C75-C6F6-11E6-B483-B8E8562CBAFA
> PROCESSING_REQUIRED = TRUE {
> >    SECTION RAW =
> $(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 <liming.gao@intel.com>
> >> Cc: edk2-devel <edk2-devel@lists.01.org>
> >> Subject: Re: [edk2] FDF Spec question?
> >>
> >>
> >>> On Dec 21, 2016, at 5:18 PM, Gao, Liming <liming.gao@intel.com> 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 <liming.gao@intel.com>
> >>> Cc: edk2-devel <edk2-devel@lists.01.org>
> >>> Subject: Re: [edk2] FDF Spec question?
> >>>
> >>>
> >>>> On Dec 21, 2016, at 6:27 AM, Gao, Liming <liming.gao@intel.com>
> 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 <edk2-devel@lists.01.org>
> >>>> 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
> >>
> >> _______________________________________________
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel