From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=tGL3xTmh; spf=pass (domain: apple.com, ip: 17.151.62.68, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) by groups.io with SMTP; Wed, 02 Oct 2019 21:20:08 -0700 Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x934HRlK027663; Wed, 2 Oct 2019 21:20:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=E32t9I2z+o35JGsP2195StzaVUd7sLJLBWBGfarhHn4=; b=tGL3xTmhUNATspP70ACRgsGWg5FCcH212hWYHcM7cgSmVEO8rlO5QIqKjcBtQU5IV5fK 9Qc+x+54urLeuYLejXCFopokC99+My1J+lBSNKQdQLxWD6h0hej4H/+lZehXQ5hnQKxp Y3LYvby7f8h2IuVoiCtRu37vAjvSrOAxNNERWmYk+rigs1iUDvRhhL0FHVjERSjchk13 c1uSCya2sFv9DgNOl4iLo8EfoPwxf8Dn4Ev4ga+NpNHd8z02Xd0J5ha2W0747v1W8cno 7CjWR+iTRRWrdNe5M4IE5hYSrTrBN2e3/xlo5I/8UuAnArqoiN6Lty1XR2Y12bJNuDvr SA== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2vaqrksxja-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 02 Oct 2019 21:20:05 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PYS00KPE6PGPJ20@ma1-mtap-s03.corp.apple.com>; Wed, 02 Oct 2019 21:20:04 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PYS00E006I8TB00@nwk-mmpp-sz10.apple.com>; Wed, 02 Oct 2019 21:20:04 -0700 (PDT) X-Va-CD: 0 X-Va-ID: 57553914-cadc-4fb2-9350-49b5a953a1dc X-V-A: X-V-T-CD: f0178fbe912c7da515175cdd596b2d6a X-V-E-CD: 827989215b6a388a3e5129ebc951bfa1 X-V-R-CD: 7d7a7e1c784afbe47feabc59a82f53b1 X-V-CD: 0 X-V-ID: bdd33392-09de-47d0-9b18-623112b5ddd4 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-03_02:,, signatures=0 Received: from [17.235.92.83] (unknown [17.235.92.83]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PYS006B16PDDY80@nwk-mmpp-sz10.apple.com>; Wed, 02 Oct 2019 21:20:03 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <56807650-1B30-4A3F-BF9D-6A98F945DA95@apple.com> MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [edk2-platforms][PATCH V1 0/3] Add FW Boot Media Device Indicator Date: Wed, 02 Oct 2019 23:20:01 -0500 In-reply-to: Cc: "Chaganty, Rangasai V" , "Dong, Eric" , "Gao, Liming" , "Ni, Ray" To: devel@edk2.groups.io, michael.a.kubacki@intel.com References: <20191001011547.14588-1-michael.a.kubacki@intel.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-03_02:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_326CDDEA-390E-4F80-A6AE-FB1E08069255" --Apple-Mail=_326CDDEA-390E-4F80-A6AE-FB1E08069255 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Since I was around back in the Intel Tiano days and I've worked on all the = PI specs I can share the history.=20 The reset vector is a hardware thing. It is usually at the top or bottom o= f the address space. For x86 it is at the TOP of the ROM and that is why th= e FV has a VoluteTop file GUID that places the file at the end of the FV, t= hus the end of that file is the reset vector. If the reset vector is low th= en the FV header starts with a 16 byte ZeroVector that can contain the rese= t jump instruction. The other architecture that is out there is a mask ROM,= and the mask ROM is the reset vector, and that code hands off to the 2nd l= evel, and sometimes that can be in DRAM or ROM.=20 The PI FVs (Firmware Volumes) are abstracted by Firmware Volume Blocks (FV= B) the FVB instances abstract the storage media for the firmware. Thus from= a PI spec point of view there is not need to define the storage type of th= e "ROM". That is just an implementation detail, that needs to be managed by= the implementation.=20 If you think about in UEFI disk are abstracted by the Block IO protocol. W= e can boot an OS from any Block device, and the firmware does not need to k= now what kind of disk it is. The purpose of the Block IO protocol is to abs= tract all possible implementations o block devices. For the "Boot ROM", FVB= is the same kind of abstraction. So you can implement PI with out knowing = the media type. Managing the media type was is a platform abstraction, thus= there is no need for a boot media abstraction in the MdePkg.=20 That being said the PI architecture is abstract to a fault. It was designe= d to abstract all possible future platforms. If there are a family of platf= orms that share common properties it makes sense to build a platform abstra= ction package that a set of platforms can share. This is the intent of the = PI architecture and the EDKII source base.=20 The MdePkg implements the UEFI and PI specs, and other industry standards,= with some common libs thrown in. So the MdePkg is not the place to put som= e implementation hint about the Media Device. You could use a GUIDed HOB fo= r that if needed? Thanks, Andrew Fish > On Oct 2, 2019, at 8:02 PM, Kubacki, Michael A wrote: >=20 > In platforms built for boot media other than SPI flash there has been a = compelling > need for silicon and platform code to be aware of the firmware boot medi= a but > apart from the UEFI variable driver (which is a special case being addre= ssed > here - https://github.com/makubacki/edk2/tree/storage_agnostic_uefi_vari= ables ), > this has not been the case for edk2 repository packages. In some cases, = code in SEC > has made assumptions about the reset vector or FIT pointer that do not n= ecessarily > translate to storage media that does not support MMIO. These cases have = been > handled more gracefully than checking the firmware boot media technology= . This is > just an observation, not necessarily a case for it to stay in IntelSilic= onPkg (which > does make it accessible to Intel silicon and platform code). >=20 > I suppose the firmware boot media properties could be treated in a simil= ar manner > to Boot Mode as defined in the Platform Initialization spec. If this was= done, it may > make more sense to abstract the technology impact onto firmware, for exa= mple, > whether it supports MMIO or not (NOR vs NAND flash) instead of what is d= efined > here with specific technologies such as eMMC and UFS. Otherwise, the spe= cification > describing this would be subject to constant expansion over time keeping= pace with > new technologies and cross-generation code (not silicon or platform spec= ific drivers) > may base conditionals on something like eMMC when its algorithm really a= pplies to > all NAND media (which, again, has been the proven observation thus far o= utside > silicon and platform code). >=20 > With that said, I see the firmware boot technology details being more pe= rtinent to > silicon and platform code so that's why this change is made now. It can = immediately > address existing needs for these details in silicon and platform code. = Some form of > the firmware boot media details in a more generic package could be usefu= l but it > will likely not align closely with the scope of information needed at th= is level and is > an undertaking, that in my opinion, is separate but compatible with the = work done here. >=20 >> -----Original Message----- >> From: Chaganty, Rangasai V > >> Sent: Wednesday, October 2, 2019 4:03 PM >> To: Kubacki, Michael A >; >> devel@edk2.groups.io >> Cc: Dong, Eric >; Gao,= Liming >; >> Ni, Ray > >> Subject: RE: [edk2-platforms][PATCH V1 0/3] Add FW Boot Media Device >> Indicator >>=20 >> I am not sure if there is a silicon scope around the FirmwareBootMediaL= ib. >> Have we considered adding this interface to MdePkg, instead? >>=20 >> -----Original Message----- >> From: Kubacki, Michael A >> Sent: Monday, September 30, 2019 6:16 PM >> To: devel@edk2.groups.io >> Cc: Chaganty, Rangasai V ; Dong, Eric >> ; Gao, Liming ; Ni, Ray >> >> Subject: [edk2-platforms][PATCH V1 0/3] Add FW Boot Media Device >> Indicator >>=20 >> This patch series introduces a mechanism for determining the firmware b= oot >> media device. This allows the firmware boot media to be discovered thro= ugh >> a standardized API. >>=20 >> Traditionally, most systems have only supported firmware storage on SPI >> flash. Presently, several other storage technologies are being used to = store >> boot system firmware such as eMMC, UFS, and NVMe. >>=20 >> The API for all board, platform, and silicon code to consume the firmwa= re >> boot media device is provided by the FirmwareBootMediaLib in >> IntelSiliconPkg. >>=20 >> A driver (FirmwareBootMediaInfoPei) is added to BoardModulePkg to serve >> as a consistent location for reporting the firmware boot device informa= tion. >> In order to abstract the potentially hardware-specific details to deter= mine >> the boot media (for platforms that support multiple firmware boot media >> devices), the driver retrieves the boot media information using a new l= ibrary >> class introduced called FirmwareBootMediaInfoLib. A default instance of= this >> library class is provided in BoardModulePkg that always returns SPI fla= sh. This >> is intended to serve as a default implementation of the library for the= most >> common scenario and to easily allow a board package to substitute the l= ogic >> required to determine the boot media in more complex scenarios. >> Ultimately, FirmwareBootMediaInfoPei produces a HOB containing the >> firmware boot media device information so it can be used in the HOB >> consumer phase. >>=20 >> Cc: Sai Chaganty >> Cc: Eric Dong >> Cc: Liming Gao >> Cc: Ray Ni >> Signed-off-by: Michael Kubacki >>=20 >> Michael Kubacki (3): >> IntelSiliconPkg/FirmwareBootMediaLib: Add library >> BoardModulePkg/FirmwareBootMediaInfoLib: Add library >> BoardModulePkg/FirmwareBootMediaInfoPei: Add module >>=20 >> Platform/Intel/BoardModulePkg/BoardModulePkg.dec >> | 3 + >> Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec = | 4 >> +- >> Platform/Intel/BoardModulePkg/BoardModulePkg.dsc >> | 5 + >> Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc = | 4 >> +- >>=20 >> Platform/Intel/BoardModulePkg/FirmwareBootMediaInfo/FirmwareBootMe >> diaInfoPei.inf | 46 +++++++++ >>=20 >> Platform/Intel/BoardModulePkg/Library/PeiFirmwareBootMediaInfoLib/Pei >> FirmwareBootMediaInfoLib.inf | 35 +++++++ >>=20 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm >> wareBootMediaLib.inf | 43 ++++++++ >>=20 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmware= B >> ootMediaLib.inf | 38 +++++++ >>=20 >> Platform/Intel/BoardModulePkg/Include/Library/FirmwareBootMediaInfoLi >> b.h | 26 +++++ >> Silicon/Intel/IntelSiliconPkg/Include/Library/FirmwareBootMediaLib.h >> | 106 +++++++++++++++++++ >>=20 >> Platform/Intel/BoardModulePkg/FirmwareBootMediaInfo/FirmwareBootMe >> diaInfoPei.c | 76 ++++++++++++++ >>=20 >> Platform/Intel/BoardModulePkg/Library/PeiFirmwareBootMediaInfoLib/Pei >> FirmwareBootMediaInfoLib.c | 24 +++++ >>=20 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm >> wareBootMediaLib.c | 107 +++++++++++++++++++ >>=20 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/FirmwareBoo >> tMediaLib.c | 109 ++++++++++++++++++++ >>=20 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmware= B >> ootMediaLib.c | 82 +++++++++++++++ >> 15 files changed, 706 insertions(+), 2 deletions(-) create mode 100644 >> Platform/Intel/BoardModulePkg/FirmwareBootMediaInfo/FirmwareBootMe >> diaInfoPei.inf >> create mode 100644 >> Platform/Intel/BoardModulePkg/Library/PeiFirmwareBootMediaInfoLib/Pei >> FirmwareBootMediaInfoLib.inf >> create mode 100644 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm >> wareBootMediaLib.inf >> create mode 100644 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmware= B >> ootMediaLib.inf >> create mode 100644 >> Platform/Intel/BoardModulePkg/Include/Library/FirmwareBootMediaInfoLi >> b.h >> create mode 100644 >> Silicon/Intel/IntelSiliconPkg/Include/Library/FirmwareBootMediaLib.h >> create mode 100644 >> Platform/Intel/BoardModulePkg/FirmwareBootMediaInfo/FirmwareBootMe >> diaInfoPei.c >> create mode 100644 >> Platform/Intel/BoardModulePkg/Library/PeiFirmwareBootMediaInfoLib/Pei >> FirmwareBootMediaInfoLib.c >> create mode 100644 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm >> wareBootMediaLib.c >> create mode 100644 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/FirmwareBoo >> tMediaLib.c >> create mode 100644 >> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmware= B >> ootMediaLib.c >>=20 >> -- >> 2.16.2.windows.1 >>=20 >=20 >=20 >=20 --Apple-Mail=_326CDDEA-390E-4F80-A6AE-FB1E08069255 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Since I was around bac= k in the Intel Tiano days and I've worked on all the PI specs I can share t= he history. 

The r= eset vector is a hardware thing. It is usually at the top or bottom of the = address space. For x86 it is at the TOP of the ROM and that is why the FV h= as a VoluteTop file GUID that places the file at the end of the FV, thus th= e end of that file is the reset vector. If the reset vector is low then the= FV header starts with a 16 byte ZeroVector that can contain the reset jump= instruction. The other architecture that is out there is a mask ROM, and t= he mask ROM is the reset vector, and that code hands off to the 2nd level, = and sometimes that can be in DRAM or ROM. 

The PI FVs (Firmware Volumes) are abstracted= by Firmware Volume Blocks (FVB) the FVB instances abstract the storage med= ia for the firmware. Thus from a PI spec point of view there is not need to= define the storage type of the "ROM". That is just an implementation detai= l, that needs to be managed by the implementation. 

If you think about in UEFI disk are= abstracted by the Block IO protocol. We can boot an OS from any Block devi= ce, and the firmware does not need to know what kind of disk it is. The pur= pose of the Block IO protocol is to abstract all possible implementations o= block devices. For the "Boot ROM", FVB is the same kind of abstraction. So= you can implement PI with out knowing the media type. Managing the media t= ype was is a platform abstraction, thus there is no need for a boot media a= bstraction in the MdePkg. 

<= div class=3D"">That being said the PI architecture is abstract to a fault. = It was designed to abstract all possible future platforms. If there are a f= amily of platforms that share common properties it makes sense to build a p= latform abstraction package that a set of platforms can share. This is the = intent of the PI architecture and the EDKII source base. 

The MdePkg implements the UEF= I and PI specs, and other industry standards, with some common libs thrown = in. So the MdePkg is not the place to put some implementation hint about th= e Media Device. You could use a GUIDed HOB for that if needed?

Thanks,
=
Andrew Fish

On Oct 2, 2019= , at 8:02 PM, Kubacki, Michael A <michael.a.kubacki@intel.com> wrote:

In platforms built = for boot media other than SPI flash there has been a compelling
need for silicon and platform code= to be aware of the firmware boot media but
apart from the UEFI variable driver (which is a specia= l case being addressed
= here - https://github.com/makubacki/edk= 2/tree/storage_agnostic_uefi_variables),
this has not been the case for edk2 repository= packages. In some cases, code in SEC
has made assumptions about the reset vector or FIT pointer t= hat do not necessarily
= translate to storage media that does not support MMIO. These cases have bee= n
handled more graceful= ly than checking the firmware boot media technology. This is
just an observation, not necessarily = a case for it to stay in IntelSiliconPkg (which
does make it accessible to Intel silicon and platf= orm code).

I suppose the firmware boot media properties cou= ld be treated in a similar manner
to Boot Mode as defined in the Platform Initialization spec. = If this was done, it may
make more sense to abstract the technology impact onto firmware, for exam= ple,
whether it support= s MMIO or not (NOR vs NAND flash) instead of what is defined
here with specific technologies such = as eMMC and UFS. Otherwise, the specification
describing this would be subject to constant expansi= on over time keeping pace with
new technologies and cross-generation code (not silicon or platform= specific drivers)
may= base conditionals on something like eMMC when its algorithm really applies= to
all NAND media (whi= ch, again, has been the proven observation thus far outside
silicon and platform code).
= With that said, I see the firmware boot technology details being mor= e pertinent to
silicon = and platform code so that's why this change is made now. It can immediately=
address existing needs= for these details in silicon and platform code.  Some form of<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">the firmware boot media detail= s in a more generic package could be useful but it
will likely not align closely with the scope of= information needed at this level and is
an undertaking, that in my opinion, is separate but compa= tible with the work done here.

-----Original M= essage-----
From: Chaganty, Rangasai V <rangasai.v.chaganty@intel.com= >
Sent: Wednesday, October 2, 2019 4:03 PM
T= o: Kubacki, Michael A <michael.a.kubacki@intel.com>;
devel@edk2.groups.io
= Cc: Dong, Eric <eric.d= ong@intel.com>; Gao, Liming <liming.gao@intel.com>;
Ni, Ray <ray.ni@intel.com>
Subject: RE: [edk2-platforms][PATCH V1 0/3] Add FW Boot Media Device=
Indicator

I am not sure if ther= e is a silicon scope around the FirmwareBootMediaLib.
Have we= considered adding this interface to MdePkg, instead?

-----Original Message-----
From: Kubacki, Michael ASent: Monday, September 30, 2019 6:16 PM
To: devel@edk2.groups.ioCc: Chaganty, Rangasai V <rangasai.v.chaganty@intel.com>; Dong, Eric=
<eric.d= ong@intel.com>; Gao, Liming <liming.gao@intel.com>; Ni, Ray
<ray.ni@intel.com>
Subject: [edk2-platforms][PATCH V1 0/3] Add FW Boot Media Device
Indicator

This patch series introdu= ces a mechanism for determining the firmware boot
media devic= e. This allows the firmware boot media to be discovered through
a standardized API.

Traditionally, most sys= tems have only supported firmware storage on SPI
flash. Prese= ntly, several other storage technologies are being used to store
boot system firmware such as eMMC, UFS, and NVMe.

The API for all board, platform, and silicon code to consume the= firmware
boot media device is provided by the FirmwareBootMe= diaLib in
IntelSiliconPkg.

A dri= ver (FirmwareBootMediaInfoPei) is added to BoardModulePkg to serve
as a consistent location for reporting the firmware boot device info= rmation.
In order to abstract the potentially hardware-specif= ic details to determine
the boot media (for platforms that su= pport multiple firmware boot media
devices), the driver retri= eves the boot media information using a new library
class int= roduced called FirmwareBootMediaInfoLib. A default instance of this
library class is provided in BoardModulePkg that always returns SPI = flash. This
is intended to serve as a default implementation = of the library for the most
common scenario and to easily all= ow a board package to substitute the logic
required to determ= ine the boot media in more complex scenarios.
Ultimately, Fir= mwareBootMediaInfoPei produces a HOB containing the
firmware = boot media device information so it can be used in the HOB
co= nsumer phase.

Cc: Sai Chaganty <rangasai.v.chaganty@intel.= com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao= <liming.gao@intel.co= m>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael Ku= backi <michael= .a.kubacki@intel.com>

Michael Kubacki (= 3):
 IntelSiliconPkg/FirmwareBootMediaLib: Add library BoardModulePkg/FirmwareBootMediaInfoLib: Add library
 BoardModulePkg/FirmwareBootMediaInfoPei: Add module

Platform/Intel/BoardModulePkg/BoardModulePkg.dec
|   3 +
Silicon/Intel/IntelSiliconPkg/In= telSiliconPkg.dec          &nb= sp;            =             &nb= sp;            =  |   4
+-
Platform/Intel/BoardMo= dulePkg/BoardModulePkg.dsc
|   5 +
Si= licon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc     &nb= sp;            =             &nb= sp;            =       |   4
+-

Platform/Intel/BoardModulePkg/FirmwareBootMediaInfo/= FirmwareBootMe
diaInfoPei.inf      &= nbsp;           | &n= bsp;46 +++++++++

Platform/Intel/BoardModulePkg= /Library/PeiFirmwareBootMediaInfoLib/Pei
FirmwareBootMediaInf= oLib.inf |  35 +++++++

Silicon/Intel/Inte= lSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
wareBoot= MediaLib.inf        |  43 ++++++++<= br class=3D"">
Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSm= mBootMediaLib/PeiFirmwareB
ootMediaLib.inf    =        |  38 +++++++
=
Platform/Intel/BoardModulePkg/Include/Library/FirmwareBootMe= diaInfoLi
b.h         = ;            &n= bsp;    |  26 +++++
Silicon/Intel/In= telSiliconPkg/Include/Library/FirmwareBootMediaLib.h
| 106 ++= +++++++++++++++++

Platform/Intel/BoardModulePk= g/FirmwareBootMediaInfo/FirmwareBootMe
diaInfoPei.c  &nb= sp;            =      |  76 ++++++++++++++

Platform/Intel/BoardModulePkg/Library/PeiFirmwareBootMediaInfoLib= /Pei
FirmwareBootMediaInfoLib.c   |  24 +++++<= br class=3D"">
Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSm= mBootMediaLib/DxeSmmFirm
wareBootMediaLib.c    = ;      | 107 +++++++++++++++++++

Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLi= b/FirmwareBoo
tMediaLib.c       = ;         | 109 ++++++++++++++= ++++++

Silicon/Intel/IntelSiliconPkg/Library/P= eiDxeSmmBootMediaLib/PeiFirmwareB
ootMediaLib.c   &= nbsp;         |  82 +++++= ++++++++++
15 files changed, 706 insertions(+), 2 deletions(-= )  create mode 100644
Platform/Intel/BoardModulePkg/Firm= wareBootMediaInfo/FirmwareBootMe
diaInfoPei.inf
create mode 100644
Platform/Intel/BoardModulePkg/Library/Pei= FirmwareBootMediaInfoLib/Pei
FirmwareBootMediaInfoLib.inf
create mode 100644
Silicon/Intel/IntelSiliconPkg/L= ibrary/PeiDxeSmmBootMediaLib/DxeSmmFirm
wareBootMediaLib.inf<= br class=3D"">create mode 100644
Silicon/Intel/IntelSiliconPk= g/Library/PeiDxeSmmBootMediaLib/PeiFirmwareB
ootMediaLib.inf<= br class=3D"">create mode 100644
Platform/Intel/BoardModulePk= g/Include/Library/FirmwareBootMediaInfoLi
b.h
c= reate mode 100644
Silicon/Intel/IntelSiliconPkg/Include/Libra= ry/FirmwareBootMediaLib.h
create mode 100644
Pl= atform/Intel/BoardModulePkg/FirmwareBootMediaInfo/FirmwareBootMe
diaInfoPei.c
create mode 100644
Platform= /Intel/BoardModulePkg/Library/PeiFirmwareBootMediaInfoLib/Pei
FirmwareBootMediaInfoLib.c
create mode 100644
= Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
wareBootMediaLib.c
create mode 100644
Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/FirmwareBootMediaLib.c
create mode 100644
Sili= con/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwareB
ootMediaLib.c

--
2.16.2.= windows.1



=

--Apple-Mail=_326CDDEA-390E-4F80-A6AE-FB1E08069255--