public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Andrew Fish <afish@apple.com>
To: Stefano Cristalli <stefanocristalli@gmail.com>
Cc: edk2-devel@lists.01.org
Subject: Re: Running pieces of PEI from binary UEFI images
Date: Mon, 10 Apr 2017 08:49:55 -0700	[thread overview]
Message-ID: <904DA880-DC03-4FAC-AA01-0A9BACAEA0F8@apple.com> (raw)
In-Reply-To: <CAEemdL_M7uWYpXrKK0-NNobF8Jsu=vmLAjfN7kfRT7rELNdmuw@mail.gmail.com>


> On Apr 10, 2017, at 12:48 AM, Stefano Cristalli <stefanocristalli@gmail.com> wrote:
> 
> Hello everyone,
> 
> I'm interested in experimenting with the PEI phase using EmulatorPkg,
> OVMF and other EDKII parts that could be useful.
> In particular, I'm interested in the possibility of integrating parts
> of an existing pre-built binary UEFI image with such environments. If
> the image was developed based on EDKII, would I expect things to work?
> I'm not looking for complete emulation, I just think it would be
> interesting to be able to single-step code inside PEIMs or even the
> PeiCore from random images, leveraging the already existing EDKII
> infrastructures (rather than switching to other debugging/emulation
> projects).
> 
> I thought that the task might be feasible, since the layout of the
> memory at the beginning of PEI and even the arguments passed to the
> PeiCore are standardized... I should at least be able to begin
> execution.
> 
> What do you think? Am I missing something?
> 
> Additionally, I would ask for technical help, as it's not clear to me
> how exactly I would be able
> to load such modules. I saw that there is
> the possibility of loading binaries inside an EDKII image build (cfr.
> INF_Spec_1_25 section 2.7), but I don't understand how would I do this
> for PEI binaries and if I could expect things to work (as in with only
> the pointer to the image, without any additional information
> specified).
> 


Stefano,

PEI and DXE are designed to support your usage model. The FD (Flash Device) layout is a simple file system (usually read only, but does not have to be) called an FV (Firmware Volume). The FV contains files that are named by EFI_GUID (UUID), and does not support directories. Each file in an FV consists of a set of sections and sections can encapsulate other sections (that is how compression works). Two (PEI and DXE) of the section types are for depex (Dependency Expressions). The PEI depex grammar is simpler than DXE but they both support TRUE, and ANDing together PPI/Protocol GUIDs. When the depex is true  the PEI/DXE Driver is queued for dispatch. So PPI_A AND PPI_B means dispatch this PEIM when both PPI_A and PPI_B are installed in the system. The PEI and DXE Cores both contain dispatchers that make all this happen. This is all described in great detail in the UEFI Platform Initialization (PI) Specification that you can download from here: http://www.uefi.org/specifications

The edk2 uses FDF files to layout the FD and build FVs. Here is an example of a binary DXE driver that will dispatch after gPlatformGOPPolicyGuid is installed. 

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L577

 FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
  SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
  SECTION PE32 = Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.efi
  SECTION UI = "IntelGopDriver"
}

The depex type would be different for PEI  but you get the idea. The FDF spec lives here: https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications

In PEI it is common that the image type may be TE vs. PE/COFF. TE (Tiano Executable) is just a hack to make the PE/COFF header smaller, as in PE/COFF (unlike other image formats) the header is part of the executable image. In general TE makes the most sense when an image is executed from FLASH. You can tell if an image is TE if you hexdump it  you will see a VZ signature, and PE/COFF has a PE/0/0 header and can also start with a DOS header that has an MZ signature.

The PEI Core  will use the FV to find the PE/COFF image, and from the PE/COFF header it can find the offset to the entry point. Thus the PEI Core can call into the PE/COFF image and run it from FLASH, or it can shadow it into memory, relocate the image, and call the entry point. 

Thanks,

Andrew Fish

PS MZ is for Mark Zbikowski one of the developers of MS-DOS. VZ is for Vincent Zimmer as he wrote that part of the Tiano Spec that ended up in the PI Spec. Vincent also made the uninitialized memory value 0xAF as a joke about my initials. 

> I'd really appreciate if someone could give me some explanations to
> clear my ideas about this. Some pointers to documentation would be
> just fine, for it's quite complicated to figure out completely as an
> EDKII beginner. "Dude, it's completely unfeasible" is also fine and
> helpful as a response, if that's the case for some reason.
> 
> Thanks in advance.
> Best regards.
> 
> Stefano Cristalli
> _______________________________________________
> edk2-devel mailing
> list
> edk2-devel@lists.01.org
> https://angler.apple.com:443/proxy?url=ChY71XmEIaglKYTvqPpJ7AsI5LDpggaDTaabgJPkJxd8IubgWIh3iPGbZH%2BpoQgRuP3YvQVwjIVArds4ikYRj%2BSF45Qc%2FowwxUMxCowjAQA%3D&rewritten=true&o=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel



      reply	other threads:[~2017-04-10 15:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10  7:48 Running pieces of PEI from binary UEFI images Stefano Cristalli
2017-04-10 15:49 ` Andrew Fish [this message]

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=904DA880-DC03-4FAC-AA01-0A9BACAEA0F8@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