Re: [edk2] Dependency expression inheritance problems

[darylm]

Liming,

I don't remember whether I replied to you.
I submitted Bugzilla report #914 - DEPEX not inherited from binary libraries -
on 30 March 2018.

Thanks,
Daryl

-Original Message-
From: edk2-devel  On Behalf Of Gao, Liming
Sent: Thursday, March 29, 2018 5:36 PM
To: edk2-li...@mc2research.org; edk2-devel@lists.01.org
Subject: Re: [edk2] Dependency expression inheritance problems

Daryl:
  Could you submit one tracker in bugzillar? We will check it in BaseTools.

Thanks
Liming
> -Original Message-
> From: dar...@mc2research.com [mailto:dar...@mc2research.com] On Behalf 
> Of edk2-li...@mc2research.org
> Sent: Friday, March 30, 2018 7:10 AM
> To: Gao, Liming ; edk2-devel@lists.01.org
> Subject: RE: [edk2] Dependency expression inheritance problems
> 
> Liming,
> 
> This is only a problem with binary libraries.  If I do everything from 
> sources, the generated .depex is correct.
> 
> Daryl
> 
> -Original Message-
> From: Gao, Liming 
> Sent: Thursday, March 29, 2018 12:08 AM
> To: edk2-li...@mc2research.org; 'Laszlo Ersek' ; 
> edk2-devel@lists.01.org
> Subject: RE: [edk2] Dependency expression inheritance problems
> 
> Daryl:
>   Do you try the source library INF file? EDK2 build system will 
> inherit the depex section from its library. Seemly, this is an issue 
> when the module is the binary library.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >Of edk2-li...@mc2research.org
> >Sent: Thursday, March 29, 2018 6:48 AM
> >To: 'Laszlo Ersek' ; edk2-devel@lists.01.org
> >Subject: Re: [edk2] Dependency expression inheritance problems
> >
> >Laszlo,
> >
> >I think you are thinking of the old .dxs files.  EDK II supports 
> >them, but their use is discouraged.
> >From the "EDK II Build Specification", v1.27:
> >"For EDK II modules, the build tools will create the complete 
> >dependency expression using the information in the [Depex] section 
> >along with all [Depex] sections from the linked in library instances."
> >
> >and
> >
> >"Once all files are parsed, the build tools will do following work 
> >for each EDK II
> >module:
> > ...
> > *  Inherit library instance dependency ( [Depex] sections) 
> >expressions
> 
> >if a module does not list a separate dependency file."
> >
> >So, use of the [Depex] sections in the .DSC and .INF files is 
> >supposed to be the way to go.
> >
> >The spec. also states that if a .dxs file is specified, inheritance 
> >will not be used and the .dxs file must specify every dependency.  
> >"Use of a separate file for describing the dependencies is discouraged. ...
> >Libraries may also have a dependency, [Depex] , section. These 
> >dependencies must be appended to the module's DEPEX sections unless 
> >the module includes a depex (.dxs) file - even if the module does not 
> >contain a [Depex] section. When a developer chooses to write the .dxs 
> >file, the developer is responsible for specifying all dependencies in 
> >the
> .dxs file."
> >
> >I believe that according to the spec., what I am attempting should 
> >work.  The EDK II build tools should generate a .depex file for the 
> >module that contains the module's depex as well as depex' inherited 
> >from the module's component libraries.
> >
> >But, I could be misinterpreting the spec. or doing something wrong in 
> >the build files (.DSC and .INF).
> >
> >Has anyone actually looked at the .depex that the tools produce and 
> >compared it to what the expected contents are for binary and hybrid 
> >(binary +
> >source) builds?
> >
> >Thanks much,
> >Daryl
> >
> >
> >-Original Message-
> >From: Laszlo Ersek 
> >Sent: Wednesday, March 28, 2018 11:34 AM
> >To: edk2-li...@mc2research.org; edk2-devel@lists.01.org
> >Subject: Re: [edk2] Dependency expression inheritance problems
> >
> >On 03/28/18 20:32, Laszlo Ersek wrote:
> >> On 03/28/18 20:14, edk2-li...@mc2research.org wrote:
> >>> Hopefully someone on the list can help with this problem.
> >>>
> >>>
> >>>
> >>> I have a DXE_DRIVER that links with several libraries.  Some of 
> >>> these libraries are from a binary distribution.  I checked the 
> >>> binary library's .INF file and it has the [LibraryClasses] and 
> >>> [Depex] sections present in the same format as for a source .INF.
> >>> (not
> >>> comments)
> >>
> >> Isn't that wrong (from the binary distribution)? The INF spec makes 
> >> me think think that library instances provided in binary format 
> >> should ship their standalone .depex files as well, and they should 
> >> be referenced in the [Binaries] section of the respective lib 
> >> instance INF
> file.
> >>
> >> https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/2_in
> >> f_ o verview/215_[depex]_section.html#215-depex-section
> >>
> >> "Binary .depex files are listed in [Binaries] sections 

Re: [edk2] Dependency expression inheritance problems

[edk2-lists]

Liming,

I don't remember whether I answered you or not, but I did submit a Bugzilla
report on March 30, 2018.
Bug 914 - DEPEX not inherited from binary libraries

Thank you,
Daryl

-Original Message-
From: edk2-devel  On Behalf Of Gao, Liming
Sent: Thursday, March 29, 2018 5:36 PM
To: edk2-li...@mc2research.org; edk2-devel@lists.01.org
Subject: Re: [edk2] Dependency expression inheritance problems

Daryl:
  Could you submit one tracker in bugzillar? We will check it in BaseTools.

Thanks
Liming
> -Original Message-
> From: dar...@mc2research.com [mailto:dar...@mc2research.com] On Behalf 
> Of edk2-li...@mc2research.org
> Sent: Friday, March 30, 2018 7:10 AM
> To: Gao, Liming ; edk2-devel@lists.01.org
> Subject: RE: [edk2] Dependency expression inheritance problems
> 
> Liming,
> 
> This is only a problem with binary libraries.  If I do everything from 
> sources, the generated .depex is correct.
> 
> Daryl
> 
> -Original Message-
> From: Gao, Liming 
> Sent: Thursday, March 29, 2018 12:08 AM
> To: edk2-li...@mc2research.org; 'Laszlo Ersek' ; 
> edk2-devel@lists.01.org
> Subject: RE: [edk2] Dependency expression inheritance problems
> 
> Daryl:
>   Do you try the source library INF file? EDK2 build system will 
> inherit the depex section from its library. Seemly, this is an issue 
> when the module is the binary library.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >Of edk2-li...@mc2research.org
> >Sent: Thursday, March 29, 2018 6:48 AM
> >To: 'Laszlo Ersek' ; edk2-devel@lists.01.org
> >Subject: Re: [edk2] Dependency expression inheritance problems
> >
> >Laszlo,
> >
> >I think you are thinking of the old .dxs files.  EDK II supports 
> >them, but their use is discouraged.
> >From the "EDK II Build Specification", v1.27:
> >"For EDK II modules, the build tools will create the complete 
> >dependency expression using the information in the [Depex] section 
> >along with all [Depex] sections from the linked in library instances."
> >
> >and
> >
> >"Once all files are parsed, the build tools will do following work 
> >for each EDK II
> >module:
> > ...
> > *  Inherit library instance dependency ( [Depex] sections) 
> >expressions
> 
> >if a module does not list a separate dependency file."
> >
> >So, use of the [Depex] sections in the .DSC and .INF files is 
> >supposed to be the way to go.
> >
> >The spec. also states that if a .dxs file is specified, inheritance 
> >will not be used and the .dxs file must specify every dependency.  
> >"Use of a separate file for describing the dependencies is discouraged. ...
> >Libraries may also have a dependency, [Depex] , section. These 
> >dependencies must be appended to the module's DEPEX sections unless 
> >the module includes a depex (.dxs) file - even if the module does not 
> >contain a [Depex] section. When a developer chooses to write the .dxs 
> >file, the developer is responsible for specifying all dependencies in 
> >the
> .dxs file."
> >
> >I believe that according to the spec., what I am attempting should 
> >work.  The EDK II build tools should generate a .depex file for the 
> >module that contains the module's depex as well as depex' inherited 
> >from the module's component libraries.
> >
> >But, I could be misinterpreting the spec. or doing something wrong in 
> >the build files (.DSC and .INF).
> >
> >Has anyone actually looked at the .depex that the tools produce and 
> >compared it to what the expected contents are for binary and hybrid 
> >(binary +
> >source) builds?
> >
> >Thanks much,
> >Daryl
> >
> >
> >-Original Message-
> >From: Laszlo Ersek 
> >Sent: Wednesday, March 28, 2018 11:34 AM
> >To: edk2-li...@mc2research.org; edk2-devel@lists.01.org
> >Subject: Re: [edk2] Dependency expression inheritance problems
> >
> >On 03/28/18 20:32, Laszlo Ersek wrote:
> >> On 03/28/18 20:14, edk2-li...@mc2research.org wrote:
> >>> Hopefully someone on the list can help with this problem.
> >>>
> >>>
> >>>
> >>> I have a DXE_DRIVER that links with several libraries.  Some of 
> >>> these libraries are from a binary distribution.  I checked the 
> >>> binary library's .INF file and it has the [LibraryClasses] and 
> >>> [Depex] sections present in the same format as for a source .INF.
> >>> (not
> >>> comments)
> >>
> >> Isn't that wrong (from the binary distribution)? The INF spec makes 
> >> me think think that library instances provided in binary format 
> >> should ship their standalone .depex files as well, and they should 
> >> be referenced in the [Binaries] section of the respective lib 
> >> instance INF
> file.
> >>
> >> https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/2_in
> >> f_ o verview/215_[depex]_section.html#215-depex-section
> >>
> >> "Binary .depex files are listed in 

Re: [edk2] [Patch 9/9] SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress API

[Kinney, Michael D]

Ard,

Yes.  I need to do an edk2-platforms patch to
go with this one.

The current API can be implemented on top of
the new API with no use of progress. That is the
simple patch.  Each platform can choose to use
progress for portions of flash update if needed.

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, April 6, 2018 6:55 AM
> To: Kinney, Michael D 
> Cc: edk2-devel@lists.01.org; Yao, Jiewen
> 
> Subject: Re: [edk2] [Patch 9/9]
> SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress
> API
> 
> On 4 April 2018 at 22:25, Michael D Kinney
>  wrote:
> > From: "Kinney, Michael D"
> 
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=801
> >
> > Use PlatformFlashWriteWithProgress() instead of
> PlatformFLashWrite()
> > so the user can be informed of the progress as a
> capsule is used
> > to update a firmware image in a firmware device.
> >
> > Cc: Jiewen Yao 
> > Signed-off-by: Michael D Kinney
> 
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> 
> Doesn't this break existing platforms that do not
> implement this in
> their PlatformFlashAccessLib?
> 
> > ---
> >  .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c |
> 92 --
> >  1 file changed, 68 insertions(+), 24 deletions(-)
> >
> > diff --git
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> > index fd6641eb3e..8d2e0df81c 100644
> > ---
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> > +++
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/Syste
> mFirmwareUpdateDxe.c
> > @@ -8,7 +8,7 @@
> >
> >FmpSetImage() will receive untrusted input and do
> basic validation.
> >
> > -  Copyright (c) 2016, Intel Corporation. All rights
> reserved.
> > +  Copyright (c) 2016 - 2018, Intel Corporation. All
> rights reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms
> and conditions of the BSD License
> >which accompanies this distribution.  The full
> text of the license may be found at
> > @@ -65,11 +65,14 @@ ParseUpdateDataFile (
> >  **/
> >  EFI_STATUS
> >  PerformUpdate (
> > -  IN VOID
> *SystemFirmwareImage,
> > -  IN UINTN
> SystemFirmwareImageSize,
> > -  IN UPDATE_CONFIG_DATA   *ConfigData,
> > -  OUT UINT32
> *LastAttemptVersion,
> > -  OUT UINT32  *LastAttemptStatus
> > +  IN VOID
> *SystemFirmwareImage,
> > +  IN UINTN
> SystemFirmwareImageSize,
> > +  IN UPDATE_CONFIG_DATA
> *ConfigData,
> > +  OUT UINT32
> *LastAttemptVersion,
> > +  OUT UINT32
> *LastAttemptStatus,
> > +  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS
> Progress,
> > +  IN UINTN
> StartPercentage,
> > +  IN UINTN
> EndPercentage
> >)
> >  {
> >EFI_STATUS   Status;
> > @@ -78,12 +81,15 @@ PerformUpdate (
> >DEBUG((DEBUG_INFO, "  BaseAddress - 0x%lx,",
> ConfigData->BaseAddress));
> >DEBUG((DEBUG_INFO, "  ImageOffset - 0x%x,",
> ConfigData->ImageOffset));
> >DEBUG((DEBUG_INFO, "  Legnth - 0x%x\n",
> ConfigData->Length));
> > -  Status = PerformFlashWrite (
> > +  Status = PerformFlashWriteWithProgress (
> >   ConfigData->FirmwareType,
> >   ConfigData->BaseAddress,
> >   ConfigData->AddressType,
> >   (VOID *)((UINTN)SystemFirmwareImage +
> (UINTN)ConfigData->ImageOffset),
> > - ConfigData->Length
> > + ConfigData->Length,
> > + Progress,
> > + StartPercentage,
> > + EndPercentage
> >   );
> >if (!EFI_ERROR(Status)) {
> >  *LastAttemptStatus =
> LAST_ATTEMPT_STATUS_SUCCESS;
> > @@ -111,12 +117,13 @@ PerformUpdate (
> >  **/
> >  EFI_STATUS
> >  UpdateImage (
> > -  IN VOID
> *SystemFirmwareImage,
> > -  IN UINTN
> SystemFirmwareImageSize,
> > -  IN VOID *ConfigImage,
> > -  IN UINTNConfigImageSize,
> > -  OUT UINT32
> *LastAttemptVersion,
> > -  OUT UINT32  *LastAttemptStatus
> > +  IN VOID
> *SystemFirmwareImage,
> > +  IN UINTN
> SystemFirmwareImageSize,
> > +  IN VOID
> *ConfigImage,
> > +  IN UINTN
> ConfigImageSize,
> > +  OUT UINT32
> *LastAttemptVersion,
> > +  OUT UINT32
> *LastAttemptStatus,
> > +  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS
> Progress
> >)
> >  {
> >EFI_STATUSStatus;
> > @@ -124,19 +131,34 @@ UpdateImage (
> >UPDATE_CONFIG_DATA
> *UpdateConfigData;
> >CONFIG_HEADER
> ConfigHeader;
> >UINTN Index;
> > +  UINTN TotalSize;
> > +  UINTN
> BytesWritten;
> > +  UINTN
> StartPercentage;
> > +  UINTN
> EndPercentage;
> >
> >  

Re: [edk2] [RFC v1 00/15] *** Proposal for StandaloneMmPkg ***

[Supreeth Venkatesh]

Jiewen,

My response inline for some of the comments.
I have posted new series of patches. Please review them and provide feedback.

Thanks,
Supreeth

-Original Message-
From: Yao, Jiewen 
Sent: Monday, December 4, 2017 12:36 AM
To: Supreeth Venkatesh ; edk2-devel@lists.01.org
Cc: leif.lindh...@linaro.org
Subject: RE: [edk2] [RFC v1 00/15] *** Proposal for StandaloneMmPkg ***

Thanks you very much.

Thanks for your patient. I have reviewed https://github.com/supven01/edk2.git 
(Branch: AArch64StandaloneMm)

Below is my thougth:
1) I do not have comment for ArmPkg related change. - I expect Arm expert can 
review that.

2) For "BaseTools/AutoGen: Update header file for MM modules."
I agree with you on that. (Reviewed-by: jiewen@intel.com) Would you please 
send separate patch for BaseTools owner to review?
[Supreeth] already Merged.

3) For "MdePkg/Include: Add management mode FV file type and depex."
I agree with you on that. (Reviewed-by: jiewen@intel.com) Would you please 
send separate patch for MdePkg owner to review?
[Supreeth] Posted Patch. Maintainers waiting on StandaloneMmPkg changes to be 
merged.

4) For "MdeModulePkg: Add application to test MM communication protocol."
Can we put UefiInfoApp to StandaloneMmPkg?
The gMmUefiInfoGuid is consumed by StandaloneMmPkg\Core\StandaloneMmCore.c, so 
I believe it more tights to StandaloneMmPkg.
I do not want to bother MdeModulePkg on that.
[Supreeth] Modified. Done.

5) The rest are all StandaloneMmPkg.
5.1) For "StandaloneMmPkg: Add an AArch64 specific entry point library."
This seems not a generic lib.
Can we rename it to be: StandaloneMmCoreEntryPointArm?
If so, we do not need create Arm sub-folder there.
[Supreeth] I created an Arm sub-folder so that it can be extensible to other 
architectures, if some other architecture wants to reuse this ARM Specific 
library and extend it.
Also, In the inf file, Arm specific source files are under [Sources.AARCH64]. 
Let me know if you prefer renaming as opposed to creating a sub folder.

5.2) For "StandaloneMmPkg/HobLib: Add a common HOB Library for management mode."
This seems not a generic way to get the Hob.

Below API seems private one. It is not defined in HobLib. But a contract 
between StandaloneMmPkg\Library\StandaloneMmCoreEntryPoint\Arm\CreateHobList.c 
and StandaloneMmPkg\Library\HobLib\HobLib.c

EFI_HOB_HANDOFF_INFO_TABLE*
HobConstructor (
  IN VOID   *EfiMemoryBegin,
  IN UINTN  EfiMemoryLength,
  IN VOID   *EfiFreeMemoryBottom,
  IN VOID   *EfiFreeMemoryTop
  )

This is typically not encourage. I am not sure if we have better way to resolve 
the issue.
But if there is not, I prefer we move it to be ArmSpecific HobLib, such as 
HobLibArmStandaloneMm.
[Supreeth] For the moment, I don’t have a better way. I have made it Arm 
specific by creating a subfolder "Arm" and sources in inf file under 
[Sources.AARCH64].

5.3) For "StandaloneMmPkg/FvLib: Add a common FV Library for management mode."
Looks good.

5.4) For "StandaloneMmPkg/MemLib: Instance of memory check library."
It seems a compatibility issue, that we rename SmmMemLib to MmMemLib.

Maybe, we can add MmMemLib.h API, and move SmmMemLib content to MmMemLib, then 
let SmmMemLib call MmMemLib.
[Supreeth] MmMemLib differs significantly from SmmMemLib as SmmMemLib has some 
intel specific physical address bits, some memory map references.
So I have moved this as ARM specific library at this point with scope for 
refactoring.

5.5) For "StandaloneMmPkg/MemoryAllocationLib: Add MM memory allocation 
library."
May I know why you change " gSmst->SmmAllocatePool ();" to "MmAllocatePool ();"

An MM driver should not know the detail implementation of MmCore.

Can we just use gMmst->MmAllocatePool() here?
[Supreeth] I modified it to use gMmst->MmX() Apis.

5.6) For "StandaloneMmPkg: MM driver entry point library."
Looks good.

5.7) For "StandaloneMmPkg/CpuMm: Add CPU driver suitable for ARM Platforms."
It seems Arm specific. Can we rename to ArmCpuMm?
[Supreeth]  I created an Arm sub-folder within CpuMm so that it can be 
extensible to other architectures, if some other architecture wants to reuse 
this ARM Specific cpu mm driver and extend it.
Also, in DSC file, this is included under [Components.AARCH64] . Let me know if 
you prefer renaming as opposed to creating a sub folder.

5.8) For "StandaloneMmPkg/Core: Implementation of Standalone MM Core Module."
I have not gone through all detail.
It seems quite similar to my previous one. So it is good.

5.9) For "StandaloneMmPkg: Add handler to handle event received from 
"uefiinfo"."
Looks good.


Thank you
Yao Jiewen

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Friday, December 1, 2017 6:55 AM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org
> Subject: Re: [edk2] [RFC v1 00/15] *** Proposal for 

[edk2] [edk2-platforms PATCH v1 0/3] *** Enable Standalone Management Mode Core Interface on AARCH64 FVP ***

[Supreeth Venkatesh]

***
PI Specification v1.5 "Volume 4: Management Mode Core Interface"
introduces the concept of MM Standalone Mode. This patchset enables
Standalone Management Mode Core Interface on AARCH64 FVP.
***

Supreeth Venkatesh (3):
  Platform/VExpressPkg: Enable MM communication driver.
  VExpressPkg: Add Test application "MmCommTest" to AArch64 FVP.
  VExpressPkg: Reorder driver load order for AARCH64 FVP.

 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 14 +-
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf |  7 ++-
 2 files changed, 19 insertions(+), 2 deletions(-)

-- 
2.16.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 18/18] StandaloneMmPkg: Add handler to handle event received from Normal World.

[Supreeth Venkatesh]

This patch adds a simple handler to handle event received from
"mmcommtest" shell application. It prints the version information from
the copy of the UEFI system table received from normal world.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 StandaloneMmPkg/Core/StandaloneMmCore.c   | 39 +++
 StandaloneMmPkg/Core/StandaloneMmCore.inf |  2 ++
 StandaloneMmPkg/StandaloneMmPkg.dec   |  2 ++
 3 files changed, 43 insertions(+)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
b/StandaloneMmPkg/Core/StandaloneMmCore.c
index 0bb99b9710..4aaecdb2ea 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.c
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
@@ -95,6 +95,15 @@ EFI_MM_SYSTEM_TABLE  gMmCoreMmst = {
 //
 BOOLEAN  mInLegacyBoot = FALSE;
 
+EFI_STATUS
+EFIAPI
+MmCommTestHandler (
+  IN EFI_HANDLE   DispatchHandle,
+  IN CONST VOID   *Context,OPTIONAL
+  IN OUT VOID *CommBuffer, OPTIONAL
+  IN OUT UINTN*CommBufferSize  OPTIONAL
+  );
+
 //
 // Table of MMI Handlers that are registered by the MM Core when it is 
initialized
 //
@@ -106,6 +115,7 @@ MM_CORE_MMI_HANDLERS  mMmCoreMmiHandlers[] = {
   { MmLegacyBootHandler, ,   NULL, FALSE },
   { MmExitBootServiceHandler,, NULL, FALSE },
   { MmReadyToBootHandler,,  NULL, FALSE },
+  { MmCommTestHandler,   ,   NULL, TRUE  },
   { NULL,NULL,   NULL, FALSE },
 };
 
@@ -379,7 +389,36 @@ MmEndOfDxeHandler (
   return Status;
 }
 
+/**
+  This function is the main entry point for communicate-based callback.
+
+  @param  DispatchHandle  The unique handle assigned to this handler by 
MmiHandlerRegister().
+  @param  Context Points to an optional handler context which was 
specified when the handler was registered.
+  @param  CommBuffer  A pointer to a collection of data in memory that will
+  be conveyed from a non-MM environment into an MM 
environment.
+  @param  CommBufferSize  The size of the CommBuffer.
 
+  @return Status Code
+**/
+EFI_STATUS
+EFIAPI
+MmCommTestHandler (
+  IN EFI_HANDLE   DispatchHandle,
+  IN CONST VOID   *Context,OPTIONAL
+  IN OUT VOID *CommBuffer, OPTIONAL
+  IN OUT UINTN*CommBufferSize  OPTIONAL
+  )
+{
+  EFI_SYSTEM_TABLE  SystemTable;
+
+  DEBUG ((DEBUG_INFO, "MmUefiInfoHandler\n"));
+
+  CopyMem (, CommBuffer, sizeof(EFI_SYSTEM_TABLE));
+
+  DEBUG ((DEBUG_INFO, "  UEFI Firmware Version - 0x%x\n", 
SystemTable.FirmwareRevision));
+
+  return EFI_SUCCESS;
+}
 
 /**
   The main entry point to MM Foundation.
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf 
b/StandaloneMmPkg/Core/StandaloneMmCore.inf
index c5eaa14ba3..b35870732c 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -78,3 +78,5 @@
   gEfiEventLegacyBootGuid
   gEfiEventExitBootServicesGuid
   gEfiEventReadyToBootGuid
+  gMmCommTestGuid
+
diff --git a/StandaloneMmPkg/StandaloneMmPkg.dec 
b/StandaloneMmPkg/StandaloneMmPkg.dec
index 36521bb039..d88be3ce5e 100644
--- a/StandaloneMmPkg/StandaloneMmPkg.dec
+++ b/StandaloneMmPkg/StandaloneMmPkg.dec
@@ -39,6 +39,8 @@
   gEfiStandaloneMmNonSecureBufferGuid  = { 0xf00497e3, 0xbfa2, 0x41a1, { 
0x9d, 0x29, 0x54, 0xc2, 0xe9, 0x37, 0x21, 0xc5 }}
   gEfiArmTfCpuDriverEpDescriptorGuid   = { 0x6ecbd5a1, 0xc0f8, 0x4702, { 
0x83, 0x01, 0x4f, 0xc2, 0xc5, 0x47, 0x0a, 0x51 }}
 
+  gMmCommTestGuid  = { 0xa37721e4, 0x8c0b, 0x4bca, { 
0xb5, 0xe8, 0xe9, 0x2, 0xa0, 0x25, 0x51, 0x4e }}
+
 [PcdsFeatureFlag]
   gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|FALSE|BOOLEAN|0x0001
 
-- 
2.16.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 17/18] StandaloneMmPkg: Add application to test MM communication protocol.

[Supreeth Venkatesh]

This patch adds a simple application that uses the MM
communication protocol to pass a copy of the UEFI system table to
the MM environment in the secure world.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 .../Application/MmCommTestApp/MmCommTest.c | 81 ++
 .../Application/MmCommTestApp/MmCommTest.h | 37 ++
 .../Application/MmCommTestApp/MmCommTest.inf   | 57 +++
 3 files changed, 175 insertions(+)
 create mode 100644 StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c
 create mode 100644 StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h
 create mode 100644 StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.inf

diff --git a/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c 
b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c
new file mode 100644
index 00..efbafdde62
--- /dev/null
+++ b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.c
@@ -0,0 +1,81 @@
+/** @file
+  This sample application demos how to communicate
+  with secure partition using MM communication protocol
+
+  Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "MmCommTest.h"
+
+#include 
+
+#include 
+
+EFI_MM_COMMUNICATION_PROTOCOL  *mMmCommunication = NULL;
+
+EFI_STATUS
+MmIplNotifyCommTest (
+  VOID
+  )
+{
+  EFI_MM_COMMUNICATE_TESTMmCommTest;
+  UINTN  Size;
+
+  DEBUG ((DEBUG_INFO, "MmIplNotifyCommTest\n"));
+
+  CopyGuid (, );
+  CopyMem (, gST, sizeof (EFI_SYSTEM_TABLE));
+  MmCommTest.MessageLength = sizeof (EFI_MM_COMMUNICATE_TEST_DATA);
+
+  //
+  // Generate the MM_COMMUNICATE SMC and return the result
+  //
+  Size = sizeof (MmCommTest);
+  return mMmCommunication->Communicate (NULL, , );
+}
+
+/**
+  The user Entry Point for Application. The user code starts with this function
+  as the real entry point for the application.
+
+  @param[in] ImageHandleThe firmware allocated handle for the EFI image.
+  @param[in] SystemTableA pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The entry point is executed successfully.
+  @retval other Some error occurs when executing this entry point.
+
+**/
+EFI_STATUS
+EFIAPI
+MmCommTestEntryPoint (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS Status;
+
+  Status = gBS->LocateProtocol (, NULL, (VOID 
**) );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  return MmIplNotifyCommTest ();
+}
diff --git a/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h 
b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h
new file mode 100644
index 00..8e8305a060
--- /dev/null
+++ b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.h
@@ -0,0 +1,37 @@
+/** @file
+  GUIDs for MM Event.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MM_COMM_TEST_H__
+#define __MM_COMM_TEST_H__
+
+#define MM_COMM_TEST_GUID \
+  { 0xa37721e4, 0x8c0b, 0x4bca, { 0xb5, 0xe8, 0xe9, 0x2, 0xa0, 0x25, 0x51, 
0x4e }}
+
+extern EFI_GUID gMmCommTestGuid;
+
+#pragma pack(1)
+typedef struct {
+  EFI_SYSTEM_TABLE  EfiSystemTable;
+} EFI_MM_COMMUNICATE_TEST_DATA;
+
+typedef struct {
+  EFI_GUID HeaderGuid;
+  UINTNMessageLength;
+  EFI_MM_COMMUNICATE_TEST_DATA Data;
+} EFI_MM_COMMUNICATE_TEST;
+#pragma pack()
+
+#endif
diff --git a/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.inf 
b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.inf
new file mode 100644
index 00..1828cd7e13
--- /dev/null
+++ b/StandaloneMmPkg/Application/MmCommTestApp/MmCommTest.inf
@@ -0,0 +1,57 @@
+## @file
+#  Sample UEFI Application Reference EDKII Module.
+#
+#  This is a sample shell application that will print "UEFI firmware version 
Info!" to 

[edk2] [PATCH v1 11/18] StandaloneMmPkg: MM driver entry point library.

[Supreeth Venkatesh]

This patch implements module entry point library for Standalone
management mode (MM) Drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 .../Include/Library/MmDriverStandaloneEntryPoint.h | 148 +
 .../StandaloneMmDriverEntryPoint.c | 102 ++
 .../StandaloneMmDriverEntryPoint.inf   |  41 ++
 3 files changed, 291 insertions(+)
 create mode 100644 
StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf

diff --git a/StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h 
b/StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h
new file mode 100644
index 00..6fb9224e2e
--- /dev/null
+++ b/StandaloneMmPkg/Include/Library/MmDriverStandaloneEntryPoint.h
@@ -0,0 +1,148 @@
+/** @file
+  Module entry point library for UEFI drivers, DXE Drivers, DXE Runtime 
Drivers,
+  and DXE SMM Drivers.
+
+Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MODULE_ENTRY_POINT_H__
+#define __MODULE_ENTRY_POINT_H__
+
+///
+///Declare the PI Specification Revision that this driver requires to execute 
correctly.
+///
+extern CONST UINT32   _gMmRevision;
+
+/**
+  The entry point of PE/COFF Image for a DXE Driver, DXE Runtime Driver, DXE 
SMM Driver, or UEFI Driver.
+
+  This function is the entry point for a DXE Driver, DXE Runtime Driver, DXE 
SMM Driver,
+  or UEFI Driver.  This function must call ProcessLibraryConstructorList() and
+  ProcessModuleEntryPointList(). If the return status from 
ProcessModuleEntryPointList()
+  is an error status, then ProcessLibraryDestructorList() must be called. The 
return value
+  from ProcessModuleEntryPointList() is returned. If _gDriverUnloadImageCount 
is greater
+  than zero, then an unload handler must be registered for this image and the 
unload handler
+  must invoke ProcessModuleUnloadList().
+  If _gUefiDriverRevision is not zero and SystemTable->Hdr.Revision is less 
than _gUefiDriverRevison,
+  then return EFI_INCOMPATIBLE_VERSION.
+
+
+  @param  ImageHandle  The image handle of the DXE Driver, DXE Runtime Driver, 
DXE SMM Driver, or UEFI Driver.
+  @param  SystemTable  A pointer to the EFI System Table.
+
+  @retval  EFI_SUCCESS   The DXE Driver, DXE Runtime Driver, DXE 
SMM Driver,
+ or UEFI Driver exited normally.
+  @retval  EFI_INCOMPATIBLE_VERSION  _gUefiDriverRevision is greater than 
SystemTable->Hdr.Revision.
+  @retval  Other Return value from 
ProcessModuleEntryPointList().
+
+**/
+EFI_STATUS
+EFIAPI
+_ModuleEntryPoint (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE*MmSystemTable
+  );
+
+
+/**
+  Required by the EBC compiler and identical in functionality to 
_ModuleEntryPoint().
+
+  This function is required to call _ModuleEntryPoint() passing in 
ImageHandle, and SystemTable.
+
+  @param  ImageHandle  The image handle of the DXE Driver, DXE Runtime Driver, 
DXE SMM Driver, or UEFI Driver.
+  @param  SystemTable  A pointer to the EFI System Table.
+
+  @retval  EFI_SUCCESS   The DXE Driver, DXE Runtime Driver, DXE 
SMM Driver,
+ or UEFI Driver exited normally.
+  @retval  EFI_INCOMPATIBLE_VERSION  _gUefiDriverRevision is greater than 
SystemTable->Hdr.Revision.
+  @retval  Other Return value from 
ProcessModuleEntryPointList().
+**/
+EFI_STATUS
+EFIAPI
+EfiMain (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE*MmSystemTable
+  );
+
+
+/**
+  Autogenerated function that calls the library constructors for all of the 
module's
+  dependent libraries.
+
+  This function must be called by _ModuleEntryPoint().
+  This function calls the set of library constructors for the set of library 
instances
+  that a module depends on.  This includes library instances that a module 
depends on
+  directly and library instances that a module depends on indirectly through 
other libraries.
+  This function is autogenerated by build tools and those build tools are 
responsible
+  for collecting the set of library instances, determine which ones have 

[edk2] [PATCH v1 12/18] StandaloneMmPkg/CpuMm: Add CPU driver suitable for ARM Platforms.

[Supreeth Venkatesh]

This patch adds a simple CPU driver that exports the
EFI_MM_CONFIGURATION_PROTOCOL to allow registration of the Standalone
MM Foundation entry point. It preserves the existing notification
mechanism for the configuration protocol.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S  |  33 +++
 StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c| 231 +
 StandaloneMmPkg/Drivers/CpuMm/Arm/Init.c   | 229 
 .../CpuMm/Arm/PiMmStandloneArmTfCpuDriver.h|  89 
 .../CpuMm/Arm/PiMmStandloneArmTfCpuDriver.inf  |  60 ++
 StandaloneMmPkg/Drivers/CpuMm/Arm/StateSave.c  |  51 +
 StandaloneMmPkg/Include/Guid/MpInformation.h   |  41 
 7 files changed, 734 insertions(+)
 create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S
 create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c
 create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/Init.c
 create mode 100644 
StandaloneMmPkg/Drivers/CpuMm/Arm/PiMmStandloneArmTfCpuDriver.h
 create mode 100644 
StandaloneMmPkg/Drivers/CpuMm/Arm/PiMmStandloneArmTfCpuDriver.inf
 create mode 100644 StandaloneMmPkg/Drivers/CpuMm/Arm/StateSave.c
 create mode 100644 StandaloneMmPkg/Include/Guid/MpInformation.h

diff --git a/StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S 
b/StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S
new file mode 100644
index 00..0b6e1c330d
--- /dev/null
+++ b/StandaloneMmPkg/Drivers/CpuMm/Arm/Entry.S
@@ -0,0 +1,33 @@
+//
+//  Copyright (c) 2017, ARM Limited. All rights reserved.
+//
+//  This program and the accompanying materials
+//  are licensed and made available under the terms and conditions of the BSD 
License
+//  which accompanies this distribution.  The full text of the license may be 
found at
+//  http://opensource.org/licenses/bsd-license.php
+//
+//  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+//  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+//
+//
+
+#include 
+#include 
+#include 
+
+.text
+.align 3
+
+GCC_ASM_IMPORT(PiMmStandloneArmTfCpuDriverEntry)
+GCC_ASM_EXPORT(_PiMmStandloneArmTfCpuDriverEntry)
+
+// Stub entry point to ensure that the stacks are completely unwound before
+// signalling completion of event handling
+ASM_PFX(_PiMmStandloneArmTfCpuDriverEntry):
+  blPiMmStandloneArmTfCpuDriverEntry
+  mov   x1, x0
+  mov   x0, #(ARM_SMC_ID_MM_EVENT_COMPLETE_AARCH64 & 0x)
+  movk  x0, #((ARM_SMC_ID_MM_EVENT_COMPLETE_AARCH64 >> 16) & 0x), lsl #16
+  svc   #0
+LoopForever:
+  b LoopForever
diff --git a/StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c 
b/StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c
new file mode 100644
index 00..7b19f53ecb
--- /dev/null
+++ b/StandaloneMmPkg/Drivers/CpuMm/Arm/EventHandle.c
@@ -0,0 +1,231 @@
+/** @file
+
+  Copyright (c) 2016 HP Development Company, L.P.
+  Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include  // for EFI_SYSTEM_CONTEXT
+
+#include 
+#include 
+
+#include 
+
+#include "PiMmStandloneArmTfCpuDriver.h"
+
+EFI_STATUS
+EFIAPI
+MmFoundationEntryRegister(
+  IN CONST EFI_MM_CONFIGURATION_PROTOCOL  *This,
+  IN EFI_MM_ENTRY_POINTMmEntryPoint
+  );
+
+//
+// On ARM platforms every event is expected to have a GUID associated with
+// it. It will be used by the MM Entry point to find the handler for the
+// event. It will either be populated in a EFI_MM_COMMUNICATE_HEADER by the
+// caller of the event (e.g. MM_COMMUNICATE SMC) or by the CPU driver
+// (e.g. during an asynchronous event). In either case, this context is
+// maintained in an array which has an entry for each CPU. The pointer to this
+// array is held in PerCpuGuidedEventContext. Memory is allocated once the
+// number of CPUs in the system are made known through the
+// MP_INFORMATION_HOB_DATA.
+//
+EFI_MM_COMMUNICATE_HEADER **PerCpuGuidedEventContext = NULL;
+
+//
+// When an event is received by the CPU driver, it could correspond to a unique
+// GUID (e.g. interrupt events) or to multiple GUIDs (e.g. MM_COMMUNICATE
+// SMC). A table is used by the CPU driver to find the GUID corresponding to 
the
+// event id in case there is a 1:1 mapping between the two. If an event id has
+// multiple GUIDs associated with it then such an entry will not be found in

[edk2] [PATCH v1 16/18] BaseTools/AutoGen: Update header file for MM modules.

[Supreeth Venkatesh]

This patch corrects the Module Type Header file for Management Mode(MM)
as specified in PI v1.6 Specification. Also, it updates parameter for
auto generated template functions from EFI_SMM_SYSTEM_TABLE2 to
EFI_MM_SYSTEM_TABLE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 BaseTools/Source/Python/AutoGen/GenC.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 4d9ea1b2a8..8601e4ee70 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -270,7 +270,7 @@ EFI_STATUS
 EFIAPI
 ${Function} (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   );
 ${END}
 """)
@@ -283,7 +283,7 @@ EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 
 {
@@ -297,7 +297,7 @@ EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 
 {
@@ -312,7 +312,7 @@ EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 
 {
@@ -680,7 +680,7 @@ EFI_STATUS
 EFIAPI
 ${Function} (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   );${END}
 """),
 }
@@ -760,7 +760,7 @@ VOID
 EFIAPI
 ProcessLibrary${Type}List (
   IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
+  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
   )
 {
 ${BEGIN}  EFI_STATUS  Status;
@@ -784,8 +784,8 @@ gModuleTypeHeaderFile = {
 "UEFI_DRIVER"   :   ["Uefi.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
"Library/UefiDriverEntryPoint.h"],
 "UEFI_APPLICATION"  :   ["Uefi.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
"Library/UefiApplicationEntryPoint.h"],
 "SMM_CORE"  :   ["PiDxe.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
-"MM_STANDALONE" :   ["PiSmm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/SmmDriverStandaloneEntryPoint.h"],
-"MM_CORE_STANDALONE" :  ["PiSmm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/SmmCoreStandaloneEntryPoint.h"],
+"MM_STANDALONE" :   ["PiMm.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/MmDriverStandaloneEntryPoint.h"],
+"MM_CORE_STANDALONE":   ["PiMm.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/MmCoreStandaloneEntryPoint.h"],
 "USER_DEFINED"  :   [gBasicHeaderFile]
 }
 
-- 
2.16.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 14/18] StandaloneMmPkg: Describe the declaration, definition and fdf files.

[Supreeth Venkatesh]

This patch describes the package declarations, definitions and firmware
device files for creating standalone management mode image with
core/foundation and drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 StandaloneMmPkg/StandaloneMmPkg.dec |  47 +
 StandaloneMmPkg/StandaloneMmPkg.dsc | 132 ++
 StandaloneMmPkg/StandaloneMmPkg.fdf | 184 
 3 files changed, 363 insertions(+)
 create mode 100644 StandaloneMmPkg/StandaloneMmPkg.dec
 create mode 100644 StandaloneMmPkg/StandaloneMmPkg.dsc
 create mode 100644 StandaloneMmPkg/StandaloneMmPkg.fdf

diff --git a/StandaloneMmPkg/StandaloneMmPkg.dec 
b/StandaloneMmPkg/StandaloneMmPkg.dec
new file mode 100644
index 00..36521bb039
--- /dev/null
+++ b/StandaloneMmPkg/StandaloneMmPkg.dec
@@ -0,0 +1,47 @@
+## @file
+# This package is a platform package that provide platform module/library
+# required by Standalone MM platform.
+#
+# Copyright (c) 2016-2017, ARM Ltd. All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution. The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+#
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = StandaloneMmPkg
+  PACKAGE_GUID   = 2AE82968-7769-4A85-A5BC-A0954CE54A5C
+  PACKAGE_VERSION= 1.0
+
+[Includes]
+  Include
+
+[LibraryClasses]
+
+[Guids]
+  gStandaloneMmPkgTokenSpaceGuid   = { 0x18fe7632, 0xf5c8, 0x4e63, { 
0x8d, 0xe8, 0x17, 0xa5, 0x5c, 0x59, 0x13, 0xbd }}
+  gMpInformationHobGuid= { 0xba33f15d, 0x4000, 0x45c1, { 
0x8e, 0x88, 0xf9, 0x16, 0x92, 0xd4, 0x57, 0xe3 }}
+  gMmFvDispatchGuid= { 0xb65694cc, 0x09e3, 0x4c3b, { 
0xb5, 0xcd, 0x05, 0xf4, 0x4d, 0x3c, 0xdb, 0xff }}
+
+  ## Include/Guid/MmCoreData.h
+  gMmCoreDataHobGuid   = { 0xa160bf99, 0x2aa4, 0x4d7d, { 
0x99, 0x93, 0x89, 0x9c, 0xb1, 0x2d, 0xf3, 0x76 }}
+
+  ## Include/Guid/MmramMemoryReserve.h
+  gEfiMmPeiMmramMemoryReserveGuid  = { 0x0703f912, 0xbf8d, 0x4e2a, { 
0xbe, 0x07, 0xab, 0x27, 0x25, 0x25, 0xc5, 0x92 }}
+
+  gEfiStandaloneMmNonSecureBufferGuid  = { 0xf00497e3, 0xbfa2, 0x41a1, { 
0x9d, 0x29, 0x54, 0xc2, 0xe9, 0x37, 0x21, 0xc5 }}
+  gEfiArmTfCpuDriverEpDescriptorGuid   = { 0x6ecbd5a1, 0xc0f8, 0x4702, { 
0x83, 0x01, 0x4f, 0xc2, 0xc5, 0x47, 0x0a, 0x51 }}
+
+[PcdsFeatureFlag]
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|FALSE|BOOLEAN|0x0001
+
+[Protocols]
+  gEfiMmConfigurationProtocolGuid  = { 0xc109319, 0xc149, 0x450e,  { 
0xa3, 0xe3, 0xb9, 0xba, 0xdd, 0x9d, 0xc3, 0xa4 }}
+
diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc 
b/StandaloneMmPkg/StandaloneMmPkg.dsc
new file mode 100644
index 00..8cc996f6b0
--- /dev/null
+++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
@@ -0,0 +1,132 @@
+## @file
+# Standalone MM Platform.
+#
+# Copyright (c) 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
+#
+#This program and the accompanying materials
+#are licensed and made available under the terms and conditions of the BSD 
License
+#which accompanies this distribution. The full text of the license may be 
found at
+#http://opensource.org/licenses/bsd-license.php
+#
+#THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = StandaloneMm
+  PLATFORM_GUID  = 9A4BBA60-B4F9-47C7-9258-3BD77CAE9322
+  PLATFORM_VERSION   = 1.0
+  DSC_SPECIFICATION  = 0x00010011
+  OUTPUT_DIRECTORY   = Build/StandaloneMmPkg
+  SUPPORTED_ARCHITECTURES= IA32|X64|AARCH64
+  BUILD_TARGETS  = DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+  FLASH_DEFINITION   = StandaloneMmPkg/StandaloneMmPkg.fdf
+  DEFINE DEBUG_MESSAGE   = TRUE
+
+  # LzmaF86
+  DEFINE COMPRESSION_TOOL_GUID   = D42AE6BD-1352-4bfb-909A-CA72A6EAE889
+
+
+#
+# Library Class section - list of all Library Classes needed by this Platform.
+#

[edk2] [PATCH v1 15/18] ArmPkg: Extra action to update permissions for S-ELO MM Image.

[Supreeth Venkatesh]

The Standalone MM drivers runs in S-EL0 in AArch64 on ARM Standard
Platforms and is deployed during SEC phase. The memory allocated to the
Standalone MM drivers should be marked as RO+X.

During PE/COFF Image section parsing, this patch implements extra action
"UpdatePeCoffPermissions" to request the privileged firmware in EL3 to
update the permissions.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 .../DebugPeCoffExtraActionLib.c| 185 +++--
 .../DebugPeCoffExtraActionLib.inf  |   7 +
 2 files changed, 181 insertions(+), 11 deletions(-)

diff --git 
a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c 
b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
index f298e58cdf..c87aaf05c7 100644
--- a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
+++ b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
@@ -15,14 +15,165 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 **/
 
 #include 
-#include 
 
+#include 
 #include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
+typedef RETURN_STATUS (*REGION_PERMISSION_UPDATE_FUNC) (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  );
+
+STATIC
+RETURN_STATUS
+UpdatePeCoffPermissions (
+  IN  CONST PE_COFF_LOADER_IMAGE_CONTEXT  *ImageContext,
+  IN  REGION_PERMISSION_UPDATE_FUNC   NoExecUpdater,
+  IN  REGION_PERMISSION_UPDATE_FUNC   ReadOnlyUpdater
+  )
+{
+  RETURN_STATUS Status;
+  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION   Hdr;
+  EFI_IMAGE_OPTIONAL_HEADER_UNION   HdrData;
+  UINTN Size;
+  UINTN ReadSize;
+  UINT32SectionHeaderOffset;
+  UINTN NumberOfSections;
+  UINTN Index;
+  EFI_IMAGE_SECTION_HEADER  SectionHeader;
+  PE_COFF_LOADER_IMAGE_CONTEXT  TmpContext;
+  EFI_PHYSICAL_ADDRESS  Base;
+
+  //
+  // We need to copy ImageContext since PeCoffLoaderGetImageInfo ()
+  // will mangle the ImageAddress field
+  //
+  CopyMem (, ImageContext, sizeof (TmpContext));
+
+  if (TmpContext.PeCoffHeaderOffset == 0) {
+Status = PeCoffLoaderGetImageInfo ();
+if (RETURN_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR,
+"%a: PeCoffLoaderGetImageInfo () failed (Status = %r)\n",
+__FUNCTION__, Status));
+  return Status;
+}
+  }
+
+  if (TmpContext.IsTeImage &&
+  TmpContext.ImageAddress == ImageContext->ImageAddress) {
+DEBUG ((DEBUG_INFO, "%a: ignoring XIP TE image at 0x%lx\n", __FUNCTION__,
+  ImageContext->ImageAddress));
+return RETURN_SUCCESS;
+  }
+
+  if (TmpContext.SectionAlignment < EFI_PAGE_SIZE) {
+//
+// The sections need to be at least 4 KB aligned, since that is the
+// granularity at which we can tighten permissions. So just clear the
+// noexec permissions on the entire region.
+//
+if (!TmpContext.IsTeImage) {
+  DEBUG ((DEBUG_WARN,
+"%a: non-TE Image at 0x%lx has SectionAlignment < 4 KB (%lu)\n",
+__FUNCTION__, ImageContext->ImageAddress, 
TmpContext.SectionAlignment));
+}
+Base = ImageContext->ImageAddress & ~(EFI_PAGE_SIZE - 1);
+Size = ImageContext->ImageAddress - Base + ImageContext->ImageSize;
+return NoExecUpdater (Base, ALIGN_VALUE (Size, EFI_PAGE_SIZE));
+  }
+
+  //
+  // Read the PE/COFF Header. For PE32 (32-bit) this will read in too much
+  // data, but that should not hurt anything. Hdr.Pe32->OptionalHeader.Magic
+  // determines if this is a PE32 or PE32+ image. The magic is in the same
+  // location in both images.
+  //
+  Hdr.Union = 
+  Size = sizeof (EFI_IMAGE_OPTIONAL_HEADER_UNION);
+  ReadSize = Size;
+  Status = TmpContext.ImageRead (TmpContext.Handle,
+ TmpContext.PeCoffHeaderOffset, , Hdr.Pe32);
+  if (RETURN_ERROR (Status) || (Size != ReadSize)) {
+DEBUG ((DEBUG_ERROR,
+  "%a: TmpContext.ImageRead () failed (Status = %r)\n",
+  __FUNCTION__, Status));
+return Status;
+  }
+
+  ASSERT (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE);
+
+  SectionHeaderOffset = TmpContext.PeCoffHeaderOffset + sizeof (UINT32) +
+sizeof (EFI_IMAGE_FILE_HEADER);
+  NumberOfSections= (UINTN)(Hdr.Pe32->FileHeader.NumberOfSections);
+
+  switch (Hdr.Pe32->OptionalHeader.Magic) {
+case EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC:
+  SectionHeaderOffset += Hdr.Pe32->FileHeader.SizeOfOptionalHeader;
+  break;
+case EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC:
+  SectionHeaderOffset += Hdr.Pe32Plus->FileHeader.SizeOfOptionalHeader;
+  break;
+default:
+  ASSERT (FALSE);
+  }
+
+  //
+  // 

[edk2] [PATCH v1 07/18] StandaloneMmPkg/FvLib: Add a common FV Library for management mode.

[Supreeth Venkatesh]

This patch implements a firmware volume library that can be used by the
Standalone management mode core module to parse the firmware volume.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 StandaloneMmPkg/Include/Library/FvLib.h | 109 ++
 StandaloneMmPkg/Library/FvLib/FvLib.c   | 366 
 StandaloneMmPkg/Library/FvLib/FvLib.inf |  57 +
 3 files changed, 532 insertions(+)
 create mode 100644 StandaloneMmPkg/Include/Library/FvLib.h
 create mode 100644 StandaloneMmPkg/Library/FvLib/FvLib.c
 create mode 100644 StandaloneMmPkg/Library/FvLib/FvLib.inf

diff --git a/StandaloneMmPkg/Include/Library/FvLib.h 
b/StandaloneMmPkg/Include/Library/FvLib.h
new file mode 100644
index 00..13e1ae2b01
--- /dev/null
+++ b/StandaloneMmPkg/Include/Library/FvLib.h
@@ -0,0 +1,109 @@
+/** @file
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2017, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _FV_LIB_H_
+#define _FV_LIB_H_
+
+#include 
+#include 
+#include 
+
+/**
+  Given the input file pointer, search for the next matching file in the
+  FFS volume as defined by SearchType. The search starts from FileHeader inside
+  the Firmware Volume defined by FwVolHeader.
+
+  @param  SearchType  Filter to find only files of this type.
+  Type EFI_FV_FILETYPE_ALL causes no filtering to be done.
+  @param  FwVolHeader Pointer to the FV header of the volume to search.
+  This parameter must point to a valid FFS volume.
+  @param  FileHeader  Pointer to the current file from which to begin 
searching.
+  This pointer will be updated upon return to reflect the 
file found.
+
+  @retval EFI_NOT_FOUND  No files matching the search criteria were found
+  @retval EFI_SUCCESS
+**/
+EFI_STATUS
+EFIAPI
+FfsFindNextFile (
+  IN EFI_FV_FILETYPE SearchType,
+  IN EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader,
+  IN OUT EFI_FFS_FILE_HEADER **FileHeader
+  );
+
+/**
+  Given the input file pointer, search for the next matching section in the
+  FFS volume.
+
+  @param  SearchTypeFilter to find only sections of this type.
+  @param  FfsFileHeader Pointer to the current file to search.
+  @param  SectionHeader Pointer to the Section matching SectionType in 
FfsFileHeader.
+NULL if section not found
+
+  @retval  EFI_NOT_FOUND  No files matching the search criteria were found
+  @retval  EFI_SUCCESS
+**/
+EFI_STATUS
+FfsFindSection (
+  IN EFI_SECTION_TYPE  SectionType,
+  IN EFI_FFS_FILE_HEADER   *FfsFileHeader,
+  IN OUT EFI_COMMON_SECTION_HEADER **SectionHeader
+  );
+
+/**
+  Locates a section within a series of sections
+  with the specified section type.
+
+  @param[in]   SectionsThe sections to search
+  @param[in]   SizeOfSections  Total size of all sections
+  @param[in]   SectionType The section type to locate
+  @param[out]  FoundSectionThe FFS section if found
+
+  @retval EFI_SUCCESS   The file and section was found
+  @retval EFI_NOT_FOUND The file and section was not found
+  @retval EFI_VOLUME_CORRUPTED  The firmware volume was corrupted
+**/
+EFI_STATUS
+EFIAPI
+FindFfsSectionInSections (
+  IN  VOID *Sections,
+  IN  UINTNSizeOfSections,
+  IN  EFI_SECTION_TYPE SectionType,
+  OUT EFI_COMMON_SECTION_HEADER**FoundSection
+  );
+
+/**
+  Given the input file pointer, search for the next matching section in the
+  FFS volume.
+
+  @param  SearchType  Filter to find only sections of this type.
+  @param  FfsFileHeader   Pointer to the current file to search.
+  @param  SectionData Pointer to the Section matching SectionType in 
FfsFileHeader.
+  NULL if section not found
+  @param  SectionDataSize The size of SectionData
+
+  @retval  EFI_NOT_FOUND  No files matching the search criteria were found
+  @retval  EFI_SUCCESS
+**/
+EFI_STATUS
+EFIAPI
+FfsFindSectionData (
+  IN EFI_SECTION_TYPE  SectionType,
+  IN EFI_FFS_FILE_HEADER   *FfsFileHeader,
+  OUT VOID **SectionData,
+  OUT UINTN*SectionDataSize
+  );
+
+#endif
diff --git a/StandaloneMmPkg/Library/FvLib/FvLib.c 
b/StandaloneMmPkg/Library/FvLib/FvLib.c
new file mode 100644
index 00..cacfc81338
--- /dev/null
+++ 

[edk2] [PATCH v1 09/18] StandaloneMmPkg/MemoryAllocationLib: Add MM memory allocation library.

[Supreeth Venkatesh]

This patch implements management mode memory allocation services.The
implementation borrows the MM Core Memory Allocation services as the
primitive for memory allocation instead of using MM System Table
services.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 StandaloneMmPkg/Include/Guid/MmCoreData.h  | 132 +++
 StandaloneMmPkg/Include/Guid/MmramMemoryReserve.h  |  62 ++
 .../MemoryAllocationLib/MemoryAllocationLib.c  | 907 +
 .../MemoryAllocationLib/MemoryAllocationLib.inf|  49 ++
 .../MemoryAllocationLib/MemoryAllocationServices.h |  38 +
 5 files changed, 1188 insertions(+)
 create mode 100644 StandaloneMmPkg/Include/Guid/MmCoreData.h
 create mode 100644 StandaloneMmPkg/Include/Guid/MmramMemoryReserve.h
 create mode 100644 
StandaloneMmPkg/Library/MemoryAllocationLib/MemoryAllocationLib.c
 create mode 100644 
StandaloneMmPkg/Library/MemoryAllocationLib/MemoryAllocationLib.inf
 create mode 100644 
StandaloneMmPkg/Library/MemoryAllocationLib/MemoryAllocationServices.h

diff --git a/StandaloneMmPkg/Include/Guid/MmCoreData.h 
b/StandaloneMmPkg/Include/Guid/MmCoreData.h
new file mode 100644
index 00..c0ac772014
--- /dev/null
+++ b/StandaloneMmPkg/Include/Guid/MmCoreData.h
@@ -0,0 +1,132 @@
+/** @file
+  MM Core data.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MM_CORE_DATA_H__
+#define __MM_CORE_DATA_H__
+
+#define MM_CORE_DATA_HOB_GUID \
+  { 0xa160bf99, 0x2aa4, 0x4d7d, { 0x99, 0x93, 0x89, 0x9c, 0xb1, 0x2d, 0xf3, 
0x76 }}
+
+extern EFI_GUID gMmCoreDataHobGuid;
+
+typedef struct {
+  //
+  // Address pointer to MM_CORE_PRIVATE_DATA
+  //
+  EFI_PHYSICAL_ADDRESS   Address;
+} MM_CORE_DATA_HOB_DATA;
+
+
+///
+/// Define values for the communications buffer used when 
gEfiEventDxeDispatchGuid is
+/// event signaled.  This event is signaled by the DXE Core each time the DXE 
Core
+/// dispatcher has completed its work.  When this event is signaled, the MM 
Core
+/// if notified, so the MM Core can dispatch MM drivers.  If 
COMM_BUFFER_MM_DISPATCH_ERROR
+/// is returned in the communication buffer, then an error occurred 
dispatching MM
+/// Drivers.  If COMM_BUFFER_MM_DISPATCH_SUCCESS is returned, then the MM Core
+/// dispatched all the drivers it could.  If COMM_BUFFER_MM_DISPATCH_RESTART is
+/// returned, then the MM Core just dispatched the MM Driver that registered
+/// the MM Entry Point enabling the use of MM Mode.  In this case, the MM Core
+/// should be notified again to dispatch more MM Drivers using MM Mode.
+///
+#define COMM_BUFFER_MM_DISPATCH_ERROR0x00
+#define COMM_BUFFER_MM_DISPATCH_SUCCESS  0x01
+#define COMM_BUFFER_MM_DISPATCH_RESTART  0x02
+
+///
+/// Signature for the private structure shared between the MM IPL and the MM 
Core
+///
+#define MM_CORE_PRIVATE_DATA_SIGNATURE  SIGNATURE_32 ('m', 'm', 'i', 'c')
+
+///
+/// Private structure that is used to share information between the MM IPL and
+/// the MM Core.  This structure is allocated from memory of type 
EfiRuntimeServicesData.
+/// Since runtime memory types are converted to available memory when a legacy 
boot
+/// is performed, the MM Core must not access any fields of this structure if 
a legacy
+/// boot is performed.  As a result, the MM IPL must create an event 
notification
+/// for the Legacy Boot event and notify the MM Core that a legacy boot is 
being
+/// performed.  The MM Core can then use this information to filter accesses to
+/// thos structure.
+///
+typedef struct {
+  UINT64  Signature;
+
+  ///
+  /// The number of MMRAM ranges passed from the MM IPL to the MM Core.  The MM
+  /// Core uses these ranges of MMRAM to initialize the MM Core memory manager.
+  ///
+  UINT64  MmramRangeCount;
+
+  ///
+  /// A table of MMRAM ranges passed from the MM IPL to the MM Core.  The MM
+  /// Core uses these ranges of MMRAM to initialize the MM Core memory manager.
+  ///
+  EFI_PHYSICAL_ADDRESSMmramRanges;
+
+  ///
+  /// The MM Foundation Entry Point.  The MM Core fills in this field when the
+  /// MM Core is initialized.  The MM IPL is responsbile for registering this 
entry
+  /// point with the MM Configuration Protocol.  The MM Configuration Protocol 
may
+  /// not be available at the time the MM IPL and MM Core are started, so the 
MM IPL
+  /// sets up a protocol notification on the MM Configuration Protocol and 
registers
+  /// the MM 

[edk2] [PATCH v1 06/18] StandaloneMmPkg: Add an AArch64 specific entry point library.

[Supreeth Venkatesh]

The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms and is initialised during the SEC phase. ARM Trusted firmware
in EL3 is responsible for initialising the architectural context for
S-EL0 and loading the Standalone MM image. The memory allocated to this
image is marked as RO+X. Heap memory is marked as RW+XN.

Certain actions have to be completed prior to executing the generic code
in the Standalone MM Core module. These are:

1. Memory permission attributes for each section of the Standalone MM
   Core module need to be changed prior to accessing any RW data.

2. A Hob list has to be created with information that allows the MM
   environment to initialise and dispatch drivers.

Furthermore, this module is responsible for handing over runtime MM
events to the Standalone MM CPU driver and returning control to ARM
Trusted Firmware upon event completion. Hence it needs to know the CPU
driver entry point.

This patch implements an entry point module that ARM Trusted Firmware
jumps to in S-EL0. It then performs the above actions before calling the
Standalone MM Foundation entry point and handling subsequent MM events.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 .../Library/Arm/StandaloneMmCoreEntryPoint.h   | 232 +
 .../Include/Library/MmCoreStandaloneEntryPoint.h   | 101 
 .../StandaloneMmCoreEntryPoint/Arm/CreateHobList.c | 200 +++
 .../Arm/SetPermissions.c   | 278 +
 .../Arm/StandaloneMmCoreEntryPoint.c   | 264 +++
 .../StandaloneMmCoreEntryPoint.inf |  53 
 StandaloneMmPkg => StandaloneMmPkg~HEAD|   0
 7 files changed, 1128 insertions(+)
 create mode 100644 
StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
 create mode 100644 StandaloneMmPkg/Include/Library/MmCoreStandaloneEntryPoint.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/SetPermissions.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/StandaloneMmCoreEntryPoint.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
 rename StandaloneMmPkg => StandaloneMmPkg~HEAD (100%)

diff --git a/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h 
b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
new file mode 100644
index 00..029c6c476c
--- /dev/null
+++ b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
@@ -0,0 +1,232 @@
+/** @file
+  Entry point to the Standalone MM Foundation when initialised during the SEC
+  phase on ARM platforms
+
+Copyright (c) 2017, ARM Ltd. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MODULE_ENTRY_POINT_H__
+#define __MODULE_ENTRY_POINT_H__
+
+#include 
+#include 
+
+#define CPU_INFO_FLAG_PRIMARY_CPU  0x0001
+
+typedef
+EFI_STATUS
+(*PI_MM_CPU_TP_FW_ENTRYPOINT) (
+  IN UINTN EventId,
+  IN UINTN CpuNumber,
+  IN UINTN NsCommBufferAddr
+  );
+
+typedef struct {
+  UINT8  Type;   /* type of the structure */
+  UINT8  Version;/* version of this structure */
+  UINT16 Size;  /* size of this structure in bytes */
+  UINT32 Attr;  /* attributes: unused bits SBZ */
+} EFI_PARAM_HEADER;
+
+typedef struct {
+  UINT64 Mpidr;
+  UINT32 LinearId;
+  UINT32 Flags;
+} EFI_SECURE_PARTITION_CPU_INFO;
+
+typedef struct {
+  EFI_PARAM_HEADER  Header;
+  UINT64SpMemBase;
+  UINT64SpMemLimit;
+  UINT64SpImageBase;
+  UINT64SpStackBase;
+  UINT64SpHeapBase;
+  UINT64SpNsCommBufBase;
+  UINT64SpSharedBufBase;
+  UINT64SpImageSize;
+  UINT64SpPcpuStackSize;
+  UINT64SpHeapSize;
+  UINT64SpNsCommBufSize;
+  UINT64SpPcpuSharedBufSize;
+  UINT32NumSpMemRegions;
+  UINT32NumCpus;
+  EFI_SECURE_PARTITION_CPU_INFO *CpuInfo;
+} EFI_SECURE_PARTITION_BOOT_INFO;
+
+typedef struct {
+  EFI_PARAM_HEADER   h;
+  UINT64 SpStackBase;
+  UINT64 SpSharedBufBase;
+  UINT32

[edk2] [PATCH v1 04/18] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

[Supreeth Venkatesh]

The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
architectural context including the initial translation tables for the
S-EL1/EL0 translation regime. The MM environment could still request ARM
TF to change the memory attributes of memory regions during
initialization.

This patch adds a simple MMU library suitable for execution in S-EL0 and
requesting operations from higher exception levels.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c | 146 
 1 file changed, 146 insertions(+)
 create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c

diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c 
b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c
new file mode 100644
index 00..56969e31d1
--- /dev/null
+++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c
@@ -0,0 +1,146 @@
+/** @file
+*  File managing the MMU for ARMv8 architecture in S-EL0
+*
+*  Copyright (c) 2017, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+RequestMemoryPermissionChange(
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length,
+  IN  UINTN Permissions
+  )
+{
+  EFI_STATUSStatus;
+  ARM_SVC_ARGS  ChangeMemoryPermissionsSvcArgs = {0};
+
+  ChangeMemoryPermissionsSvcArgs.Arg0 = 
ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
+  ChangeMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
+  ChangeMemoryPermissionsSvcArgs.Arg2 = (Length >= EFI_PAGE_SIZE) ? \
+ Length >> EFI_PAGE_SHIFT : 1;
+  ChangeMemoryPermissionsSvcArgs.Arg3 = Permissions;
+
+  ArmCallSvc();
+
+  Status = ChangeMemoryPermissionsSvcArgs.Arg0;
+
+  switch (Status) {
+  case ARM_SVC_SPM_RET_SUCCESS:
+Status = EFI_SUCCESS;
+break;
+
+  case ARM_SVC_SPM_RET_NOT_SUPPORTED:
+Status = EFI_UNSUPPORTED;
+break;
+
+  case ARM_SVC_SPM_RET_INVALID_PARAMS:
+Status = EFI_INVALID_PARAMETER;
+break;
+
+  case ARM_SVC_SPM_RET_DENIED:
+Status = EFI_ACCESS_DENIED;
+break;
+
+  case ARM_SVC_SPM_RET_NO_MEMORY:
+Status = EFI_BAD_BUFFER_SIZE;
+break;
+
+  default:
+Status = EFI_ACCESS_DENIED;
+ASSERT (0);
+  }
+
+  return Status;
+}
+
+EFI_STATUS
+ArmSetMemoryRegionNoExec (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  )
+{
+  return RequestMemoryPermissionChange(BaseAddress,
+   Length,
+   SET_MEM_ATTR_MAKE_PERM_REQUEST( \
+ SET_MEM_ATTR_DATA_PERM_RO, \
+ SET_MEM_ATTR_CODE_PERM_XN));
+}
+
+EFI_STATUS
+ArmClearMemoryRegionNoExec (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  )
+{
+  return RequestMemoryPermissionChange(BaseAddress,
+   Length,
+   SET_MEM_ATTR_MAKE_PERM_REQUEST( \
+ SET_MEM_ATTR_DATA_PERM_RO, \
+ SET_MEM_ATTR_CODE_PERM_X));
+}
+
+EFI_STATUS
+ArmSetMemoryRegionReadOnly (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  )
+{
+  return RequestMemoryPermissionChange(BaseAddress,
+   Length,
+   SET_MEM_ATTR_MAKE_PERM_REQUEST( \
+ SET_MEM_ATTR_DATA_PERM_RO, \
+ SET_MEM_ATTR_CODE_PERM_XN));
+}
+
+EFI_STATUS
+ArmClearMemoryRegionReadOnly (
+  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN  UINT64Length
+  )
+{
+  return RequestMemoryPermissionChange(BaseAddress,
+   Length,
+   SET_MEM_ATTR_MAKE_PERM_REQUEST( \
+ SET_MEM_ATTR_DATA_PERM_RW, \
+ SET_MEM_ATTR_CODE_PERM_XN));
+}
+
+EFI_STATUS
+EFIAPI
+ArmConfigureMmu (
+  IN  ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable,
+  OUT VOID  **TranslationTableBase OPTIONAL,
+  OUT UINTN 

[edk2] [PATCH v1 03/18] ArmPkg/Include: Add MM interface SVC return codes.

[Supreeth Venkatesh]

This patch adds the Management Mode(MM) SVC return codes as specified in
http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
Also, corrects SVC ID for retrieving SPM version information.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
index 4c7b6c3386..a64b9ec23c 100644
--- a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
+++ b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
@@ -20,7 +20,7 @@
  * delegated events and request the Secure partition manager to perform
  * privileged operations on its behalf.
  */
-#define ARM_SVC_ID_SPM_VERSION_AARCH64 0xC460
+#define ARM_SVC_ID_SPM_VERSION_AARCH32 0x8460
 #define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64   0xC461
 #define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64   0xC464
 #define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64   0xC465
@@ -40,4 +40,11 @@
 c_perm) & SET_MEM_ATTR_CODE_PERM_MASK) << 
SET_MEM_ATTR_CODE_PERM_SHIFT) | \
 (( (d_perm) & SET_MEM_ATTR_DATA_PERM_MASK) << 
SET_MEM_ATTR_DATA_PERM_SHIFT))
 
+/* MM SVC Return error codes */
+#define ARM_SVC_SPM_RET_SUCCESS   0
+#define ARM_SVC_SPM_RET_NOT_SUPPORTED-1
+#define ARM_SVC_SPM_RET_INVALID_PARAMS   -2
+#define ARM_SVC_SPM_RET_DENIED   -3
+#define ARM_SVC_SPM_RET_NO_MEMORY-5
+
 #endif
-- 
2.16.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 05/18] ArmPkg/ArmMmuLib: Add MMU library inf file suitable for use in S-EL0.

[Supreeth Venkatesh]

This patch adds the definitions, sources, packages and library classes
needed to compile and link MMU Library suitable for use in S-EL0.

Currently, this is used only during the Standalone MM Core
initialization and hence defined as MM_CORE_STANDALONE Module.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf | 37 +++
 1 file changed, 37 insertions(+)
 create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf

diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf 
b/ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf
new file mode 100644
index 00..5c802923da
--- /dev/null
+++ b/ArmPkg/Library/ArmMmuLib/ArmMmuSecLib.inf
@@ -0,0 +1,37 @@
+#/** @file
+#
+#  Copyright (c) 2017, ARM Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = ArmMmuSecLib
+  FILE_GUID  = da8f0232-fb14-42f0-922c-63104d2c70bd
+  MODULE_TYPE= MM_CORE_STANDALONE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmMmuSecLib|MM_CORE_STANDALONE
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  CONSTRUCTOR= ArmMmuSecLibConstructor
+
+[Sources.AARCH64]
+  AArch64/ArmMmuSecLib.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  ArmLib
+  CacheMaintenanceLib
+  MemoryAllocationLib
+
+
-- 
2.16.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 02/18] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Supreeth Venkatesh]

PI v1.5 Specification Volume 4 defines Management Mode Core Interface
and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
means of communicating between drivers outside of MM and MMI
handlers inside of MM.

This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
driver for AARCH64 platforms. It uses SMCs allocated from the standard
SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf
to communicate with the standalone MM environment in the secure world.

This patch also adds the MM Communication driver (.inf) file to
define entry point for this driver and other compile
related information the driver needs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 .../Drivers/MmCommunicationDxe/MmCommunication.c   | 339 +
 .../Drivers/MmCommunicationDxe/MmCommunication.inf |  50 +++
 2 files changed, 389 insertions(+)
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf

diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
new file mode 100644
index 00..e801c1c601
--- /dev/null
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
@@ -0,0 +1,339 @@
+/** @file
+
+  Copyright (c) 2016-2017, ARM Limited. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+//
+// Address, Length of the pre-allocated buffer for communication with the 
secure
+// world.
+//
+STATIC ARM_MEMORY_REGION_DESCRIPTOR  mNsCommBuffMemRegion;
+
+// Notification event when virtual address map is set.
+STATIC EFI_EVENT  mSetVirtualAddressMapEvent;
+
+//
+// Handle to install the MM Communication Protocol
+//
+STATIC EFI_HANDLE  mMmCommunicateHandle;
+
+/**
+  Communicates with a registered handler.
+
+  This function provides an interface to send and receive messages to the
+  Standalone MM environment on behalf of UEFI services.  This function is part
+  of the MM Communication Protocol that may be called in physical mode prior to
+  SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap().
+
+  @param[in]  ThisThe EFI_MM_COMMUNICATION_PROTOCOL
+  instance.
+  @param[in, out] CommBuffer  A pointer to the buffer to convey
+  into MMRAM.
+  @param[in, out] CommSizeThe size of the data buffer being
+  passed in. This is optional.
+
+  @retval EFI_SUCCESS The message was successfully posted.
+  @retval EFI_INVALID_PARAMETER   The CommBuffer was NULL.
+  @retval EFI_BAD_BUFFER_SIZE The buffer size is incorrect for the MM
+  implementation. If this error is
+  returned, the MessageLength field in
+  the CommBuffer header or the integer
+  pointed by CommSize are updated to 
reflect
+  the maximum payload size the
+  implementation can accommodate.
+  @retval EFI_ACCESS_DENIED   The CommunicateBuffer parameter
+  or CommSize parameter, if not omitted,
+  are in address range that cannot be
+  accessed by the MM environment
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+MmCommunicationCommunicate (
+  IN CONST EFI_MM_COMMUNICATION_PROTOCOL  *This,
+  IN OUT VOID *CommBuffer,
+  IN OUT UINTN*CommSize OPTIONAL
+  )
+{
+  EFI_MM_COMMUNICATE_HEADER   *CommunicateHeader;
+  ARM_SMC_ARGSCommunicateSmcArgs;
+  EFI_STATUS  Status;
+  UINTN   BufferSize;
+
+  CommunicateHeader = CommBuffer;
+  Status = EFI_ACCESS_DENIED;
+  BufferSize = 0;
+
+  ZeroMem (, sizeof (ARM_SMC_ARGS));
+
+  //
+  // Check parameters
+  //
+  if (CommBuffer == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  // If the length of the CommBuffer is 0 then return the expected length.
+  if (CommSize) {
+if (*CommSize == 0) {
+  *CommSize = mNsCommBuffMemRegion.Length;
+  return EFI_BAD_BUFFER_SIZE;

[edk2] [PATCH v1 01/18] ArmPkg: Add PCDs needed for MM communication driver.

[Supreeth Venkatesh]

This patch defines PCDs to describe the base address and size of
communication buffer between normal world (uefi) and standalone MM
environment in the secure world.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta 
Signed-off-by: Supreeth Venkatesh 
---
 ArmPkg/ArmPkg.dec | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index a55b6268ff..b64942220b 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -223,6 +223,9 @@
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
   gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
 
+  gArmTokenSpaceGuid.PcdMmBufferBase|0|UINT64|0x0045
+  gArmTokenSpaceGuid.PcdMmBufferSize|0|UINT64|0x0046
+
 [PcdsFixedAtBuild.common, PcdsDynamic.common]
   #
   # ARM Architectural Timer
-- 
2.16.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 9/9] SignedCapsulePkg/SystemFirmwareUpdateDxe: Use progress API

[Ard Biesheuvel]

On 4 April 2018 at 22:25, Michael D Kinney  wrote:
> From: "Kinney, Michael D" 
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=801
>
> Use PlatformFlashWriteWithProgress() instead of PlatformFLashWrite()
> so the user can be informed of the progress as a capsule is used
> to update a firmware image in a firmware device.
>
> Cc: Jiewen Yao 
> Signed-off-by: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1

Doesn't this break existing platforms that do not implement this in
their PlatformFlashAccessLib?

> ---
>  .../SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c | 92 
> --
>  1 file changed, 68 insertions(+), 24 deletions(-)
>
> diff --git 
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c 
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
> index fd6641eb3e..8d2e0df81c 100644
> --- 
> a/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
> +++ 
> b/SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.c
> @@ -8,7 +8,7 @@
>
>FmpSetImage() will receive untrusted input and do basic validation.
>
> -  Copyright (c) 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
>which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -65,11 +65,14 @@ ParseUpdateDataFile (
>  **/
>  EFI_STATUS
>  PerformUpdate (
> -  IN VOID *SystemFirmwareImage,
> -  IN UINTNSystemFirmwareImageSize,
> -  IN UPDATE_CONFIG_DATA   *ConfigData,
> -  OUT UINT32  *LastAttemptVersion,
> -  OUT UINT32  *LastAttemptStatus
> +  IN VOID   *SystemFirmwareImage,
> +  IN UINTN  SystemFirmwareImageSize,
> +  IN UPDATE_CONFIG_DATA *ConfigData,
> +  OUT UINT32*LastAttemptVersion,
> +  OUT UINT32*LastAttemptStatus,
> +  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress,
> +  IN UINTN  StartPercentage,
> +  IN UINTN  EndPercentage
>)
>  {
>EFI_STATUS   Status;
> @@ -78,12 +81,15 @@ PerformUpdate (
>DEBUG((DEBUG_INFO, "  BaseAddress - 0x%lx,", ConfigData->BaseAddress));
>DEBUG((DEBUG_INFO, "  ImageOffset - 0x%x,", ConfigData->ImageOffset));
>DEBUG((DEBUG_INFO, "  Legnth - 0x%x\n", ConfigData->Length));
> -  Status = PerformFlashWrite (
> +  Status = PerformFlashWriteWithProgress (
>   ConfigData->FirmwareType,
>   ConfigData->BaseAddress,
>   ConfigData->AddressType,
>   (VOID *)((UINTN)SystemFirmwareImage + 
> (UINTN)ConfigData->ImageOffset),
> - ConfigData->Length
> + ConfigData->Length,
> + Progress,
> + StartPercentage,
> + EndPercentage
>   );
>if (!EFI_ERROR(Status)) {
>  *LastAttemptStatus = LAST_ATTEMPT_STATUS_SUCCESS;
> @@ -111,12 +117,13 @@ PerformUpdate (
>  **/
>  EFI_STATUS
>  UpdateImage (
> -  IN VOID *SystemFirmwareImage,
> -  IN UINTNSystemFirmwareImageSize,
> -  IN VOID *ConfigImage,
> -  IN UINTNConfigImageSize,
> -  OUT UINT32  *LastAttemptVersion,
> -  OUT UINT32  *LastAttemptStatus
> +  IN VOID   *SystemFirmwareImage,
> +  IN UINTN  SystemFirmwareImageSize,
> +  IN VOID   *ConfigImage,
> +  IN UINTN  ConfigImageSize,
> +  OUT UINT32*LastAttemptVersion,
> +  OUT UINT32*LastAttemptStatus,
> +  IN EFI_FIRMWARE_MANAGEMENT_UPDATE_IMAGE_PROGRESS  Progress
>)
>  {
>EFI_STATUSStatus;
> @@ -124,19 +131,34 @@ UpdateImage (
>UPDATE_CONFIG_DATA*UpdateConfigData;
>CONFIG_HEADER ConfigHeader;
>UINTN Index;
> +  UINTN TotalSize;
> +  UINTN BytesWritten;
> +  UINTN StartPercentage;
> +  UINTN EndPercentage;
>
>if (ConfigImage == NULL) {
>  DEBUG((DEBUG_INFO, "PlatformUpdate (NoConfig):"));
>