public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Andrew Fish <afish@apple.com>
To: "Gao, Liming" <liming.gao@intel.com>
Cc: edk2-devel <edk2-devel@lists.01.org>
Subject: Re: FDF Spec question?
Date: Wed, 21 Dec 2016 17:38:06 -0800	[thread overview]
Message-ID: <23AF9C44-DF46-452F-B981-D86783FE676C@apple.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6C2FEB@shsmsx102.ccr.corp.intel.com>


> 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



  reply	other threads:[~2016-12-22  1:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-21  0:26 FDF Spec question? Andrew Fish
2016-12-21 14:27 ` Gao, Liming
2016-12-21 17:29   ` Andrew Fish
2016-12-22  1:18     ` Gao, Liming
2016-12-22  1:38       ` Andrew Fish [this message]
2016-12-23  4:59         ` Gao, Liming
     [not found]           ` <BC80BF3A-FE04-4BC5-BC23-341282A22EA1@apple.com>
2016-12-23  5:17             ` Gao, Liming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23AF9C44-DF46-452F-B981-D86783FE676C@apple.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox