date:20181127

Re: [edk2] [PATCH v2 0/2] Remove DuetPkg and unused tools

2018-11-27 Thread Wu, Hao A

> -Original Message-
> From: Zhang, Shenglei
> Sent: Tuesday, November 27, 2018 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu; Wu, Hao A; Zhu, Yonghong; Gao, Liming
> Subject: [PATCH v2 0/2] Remove DuetPkg and unused tools
> 
> DuetPkg depends on Legacy BIOS to provide a UEFI environment.
> It was invented in the era when UEFI environment is hard to find.
> Since now UEFI is very popular in PC area, we could stop the
> official support of this package and remove it from the master.
> And moreover, the tools only used by DuetPkg can also be removed.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1322
> 
> The changes are placed in
> https://github.com/shenglei10/edk2/tree/duet
> 
> v2:Remove these tools in Makefile and GNUmakefile.

Hi,

For DuetPkg patch (2/2), I am wondering we can move the Makefile changes in the
BaseTools to either A) or B) below:

A) To the 1/2 patch
B) To a separate patch


Best Regards,
Hao Wu

> 
> Cc: Ruiyu Ni 
> Cc: Hao Wu 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> Shenglei Zhang (2):
>   BaseTools: Remove tools only used by DuetPkg
>   DuetPkg: Remove DuetPkg
> 
>  BaseTools/Source/BinaryFiles.txt  |4 -
>  BaseTools/Source/C/BootSectImage/GNUmakefile  |   21 -
>  BaseTools/Source/C/BootSectImage/Makefile |   22 -
>  .../Source/C/BootSectImage/bootsectimage.c|  955 --
>  BaseTools/Source/C/BootSectImage/fat.h|  152 -
>  BaseTools/Source/C/BootSectImage/mbr.h|   58 -
>  BaseTools/Source/C/EfiLdrImage/EfiLdrImage.c  |  319 --
>  BaseTools/Source/C/EfiLdrImage/GNUmakefile|   21 -
>  BaseTools/Source/C/EfiLdrImage/Makefile   |   22 -
>  BaseTools/Source/C/GNUmakefile|5 -
>  BaseTools/Source/C/GenBootSector/FatFormat.h  |  152 -
>  .../Source/C/GenBootSector/GenBootSector.c|  823 -
>  .../Source/C/GenBootSector/GetDrvNumOffset.c  |   73 -
>  BaseTools/Source/C/GenBootSector/Makefile |   22 -
>  BaseTools/Source/C/GenPage/GNUmakefile|   21 -
>  BaseTools/Source/C/GenPage/GenPage.c  |  441 ---
>  BaseTools/Source/C/GenPage/Makefile   |   22 -
>  BaseTools/Source/C/GenPage/VirtualMemory.h|  122 -
>  .../Source/C/GnuGenBootSector/FatFormat.h |  152 -
>  .../Source/C/GnuGenBootSector/GNUmakefile |   21 -
>  .../C/GnuGenBootSector/GnuGenBootSector.c |  455 ---
>  BaseTools/Source/C/Makefile   |4 -
>  BaseTools/toolsetup.bat   |4 -
>  DuetPkg/AcpiResetDxe/Reset.c  |  212 --
>  DuetPkg/AcpiResetDxe/Reset.inf|   47 -
>  DuetPkg/BiosVideoThunkDxe/BiosVideo.c | 2822 -
>  DuetPkg/BiosVideoThunkDxe/BiosVideo.h |  504 ---
>  DuetPkg/BiosVideoThunkDxe/BiosVideo.inf   |   50 -
>  DuetPkg/BiosVideoThunkDxe/ComponentName.c |  166 -
>  DuetPkg/BiosVideoThunkDxe/LegacyBiosThunk.c   |  220 --
>  .../BiosVideoThunkDxe/VesaBiosExtensions.h|  457 ---
>  DuetPkg/BootSector/BootSector.inf |   79 -
>  DuetPkg/BootSector/FILE.LST   |   39 -
>  DuetPkg/BootSector/GNUmakefile|  140 -
>  DuetPkg/BootSector/Gpt.S  |  297 --
>  DuetPkg/BootSector/Gpt.asm|  294 --
>  DuetPkg/BootSector/Makefile   |  173 -
>  DuetPkg/BootSector/Mbr.S  |  262 --
>  DuetPkg/BootSector/Mbr.asm|  261 --
>  DuetPkg/BootSector/bin/Gpt.com|  Bin 512 -> 0 bytes
>  DuetPkg/BootSector/bin/Mbr.com|  Bin 512 -> 0 bytes
>  DuetPkg/BootSector/bin/Readme.txt |8 -
>  DuetPkg/BootSector/bin/St16_64.com|  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bin/St32_64.com|  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bin/Start.com  |  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bin/Start16.com|  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bin/Start32.com|  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bin/Start64.com|  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bin/bootsect.com   |  Bin 512 -> 0 bytes
>  DuetPkg/BootSector/bin/bs16.com   |  Bin 512 -> 0 bytes
>  DuetPkg/BootSector/bin/bs32.com   |  Bin 512 -> 0 bytes
>  DuetPkg/BootSector/bin/efi32.com  |  Bin 139264 -> 0 bytes
>  DuetPkg/BootSector/bin/efi32.com2 |  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bin/efi64.com  |  Bin 139264 -> 0 bytes
>  DuetPkg/BootSector/bin/efi64.com2 |  Bin 4096 -> 0 bytes
>  DuetPkg/BootSector/bootsect.S |  303 --
>  DuetPkg/BootSector/bootsect.asm   |  301 --
>  DuetPkg/BootSector/bs16.S |  291 --
>  DuetPkg/BootSector/bs16.asm   |  288 --
>  DuetPkg/BootSector/bs32.S |  312 --
>  DuetPkg/BootSector/bs32.asm   |  310 --
>  DuetPkg/BootSector/efi32.S| 1176 ---
>

Re: [edk2] [Patch v1 1/1] BaseTools: create and use a standard shared variable for '*'

2018-11-27 Thread Feng, Bob C

Reviewed-by : Bob Feng 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jaben 
Carsey
Sent: Friday, November 16, 2018 11:40 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: [edk2] [Patch v1 1/1] BaseTools: create and use a standard shared 
variable for '*'

add a variable for the string '*' and then use it instead of lots of '*'

Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 54 
++--
 BaseTools/Source/Python/AutoGen/BuildEngine.py | 10 ++--
 BaseTools/Source/Python/BPDG/GenVpd.py | 14 ++---
 BaseTools/Source/Python/Common/DataType.py |  1 +
 BaseTools/Source/Python/Common/Expression.py   |  4 +-
 BaseTools/Source/Python/Common/Misc.py |  2 +-
 BaseTools/Source/Python/Common/ToolDefClassObject.py   | 23 +
 BaseTools/Source/Python/Common/VpdInfoFile.py  |  8 +--
 BaseTools/Source/Python/GenFds/FdfParser.py|  5 +-
 BaseTools/Source/Python/GenFds/GenFds.py   |  2 +-
 BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py |  8 +--
 BaseTools/Source/Python/GenFds/Section.py  |  2 +-
 BaseTools/Source/Python/Workspace/DscBuildData.py  |  6 +--
 13 files changed, 70 insertions(+), 69 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index f3560bfc787d..25417c447061 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -1438,7 +1438,7 @@ class PlatformAutoGen(AutoGen):
 PcdValue = Sku.DefaultValue
 if PcdValue == "":
 PcdValue  = Pcd.DefaultValue
-if Sku.VpdOffset != '*':
+if Sku.VpdOffset != TAB_STAR:
 if PcdValue.startswith("{"):
 Alignment = 8
 elif PcdValue.startswith("L"):
@@ -1462,7 +1462,7 @@ class PlatformAutoGen(AutoGen):
 VpdFile.Add(Pcd, SkuName, Sku.VpdOffset)
 SkuValueMap[PcdValue].append(Sku)
 # if the offset of a VPD is *, then it need to be 
fixed up by third party tool.
-if not NeedProcessVpdMapFile and Sku.VpdOffset == "*":
+if not NeedProcessVpdMapFile and Sku.VpdOffset == 
TAB_STAR:
 NeedProcessVpdMapFile = True
 if self.Platform.VpdToolGuid is None or 
self.Platform.VpdToolGuid == '':
 EdkLogger.error("Build", FILE_NOT_FOUND, \ @@ 
-1522,7 +1522,7 @@ class PlatformAutoGen(AutoGen):
 PcdValue = Sku.DefaultValue
 if PcdValue == "":
 PcdValue  = DscPcdEntry.DefaultValue
-if Sku.VpdOffset != '*':
+if Sku.VpdOffset != TAB_STAR:
 if PcdValue.startswith("{"):
 Alignment = 8
 elif PcdValue.startswith("L"):
@@ -1545,7 +1545,7 @@ class PlatformAutoGen(AutoGen):
 SkuValueMap[PcdValue] = []
 VpdFile.Add(DscPcdEntry, SkuName, 
Sku.VpdOffset)
 SkuValueMap[PcdValue].append(Sku)
-if not NeedProcessVpdMapFile and Sku.VpdOffset 
== "*":
+if not NeedProcessVpdMapFile and Sku.VpdOffset 
== TAB_STAR:
 NeedProcessVpdMapFile = True
 if DscPcdEntry.DatumType == TAB_VOID and 
PcdValue.startswith("L"):
 UnicodePcdArray.add(DscPcdEntry) @@ -1573,7 
+1573,7 @@ class PlatformAutoGen(AutoGen):
 if os.path.exists(VpdMapFilePath):
 VpdFile.Read(VpdMapFilePath)
 
-# Fixup "*" offset
+# Fixup TAB_STAR offset
 for pcd in VpdSkuMap:
 vpdinfo = VpdFile.GetVpdInfo(pcd)
 if vpdinfo is None:
@@ -2210,15 +2210,15 @@ class PlatformAutoGen(AutoGen):
 def CalculatePriorityValue(self, Key):
 Target, ToolChain, Arch, CommandType, Attr = Key.split('_')
 PriorityValue = 0x1
-if Target == "*":
+if Target == TAB_STAR:
 PriorityValue &= 0x0
-if ToolChain == "*":
+if ToolChain == TAB_STAR:
 PriorityValue &= 0x10111
-if Arch == "*":
+if Arch == TAB_STAR:
 PriorityValue &= 0x11011
-

Re: [edk2] [Patch v1 1/1] BaseTools: cleanup LongFilePathSupport usage

2018-11-27 Thread Feng, Bob C

Reviewed-by : Bob Feng 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jaben 
Carsey
Sent: Friday, November 16, 2018 11:38 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: [edk2] [Patch v1 1/1] BaseTools: cleanup LongFilePathSupport usage

1) remove an identical function and import it from Common.LongFilePathSupport
2) remove an import that is not needed/used.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey 
---
 BaseTools/Source/Python/AutoGen/UniClassObject.py | 14 +-
 BaseTools/Source/Python/build/build.py|  1 -
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py 
b/BaseTools/Source/Python/AutoGen/UniClassObject.py
index 384f31b165de..764d95ec660b 100644
--- a/BaseTools/Source/Python/AutoGen/UniClassObject.py
+++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py
@@ -24,7 +24,7 @@ from io import BytesIO  from Common.BuildToolError import *  
from Common.StringUtils import GetLineNo  from Common.Misc import PathClass 
-from Common.LongFilePathSupport import LongFilePath
+from Common.LongFilePathSupport import LongFilePath, UniToStr
 from Common.GlobalData import *
 ##
 # Static definitions
@@ -46,18 +46,6 @@ BACK_SLASH_PLACEHOLDER = u'\u0006'
 
 gIncludePattern = re.compile("^#include +[\"<]+([^\"< >]+)[>\"]+$", 
re.MULTILINE | re.UNICODE)
 
-## Convert a python unicode string to a normal string -# -# Convert a python 
unicode string to a normal string -# UniToStr(u'I am a string') is 'I am a 
string'
-#
-# @param Uni:  The python unicode string -#
-# @retval: The formatted normal string
-#
-def UniToStr(Uni):
-return repr(Uni)[2:-1]
-
 ## Convert a unicode string to a Hex list  #  # Convert a unicode string to a 
Hex list diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index d74082fc2666..5eeb626cfbbb 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -36,7 +36,6 @@ from subprocess import *  from Common import Misc as Utils
 
 from Common.LongFilePathSupport import OpenLongFilePath as open -from 
Common.LongFilePathSupport import LongFilePath  from 
Common.TargetTxtClassObject import *  from Common.ToolDefClassObject import *  
from Common.DataType import *
--
2.16.2.windows.1

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

[edk2] [Patch] Maintainers.txt: Add the rule to hand over the package maintain role

2018-11-27 Thread Liming Gao

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
---
 Maintainers.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 91a4657adc..d75bbe278d 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -6,7 +6,9 @@ EDK II.
 
 In general, you should not privately email the maintainer. You should
 email the edk2-devel list, and Cc the package maintainers and
-reviewers.
+reviewers. If the package maintainer wants to hand over his role to 
+other people, the package maintainer should send the patch to update 
+Maintainers.txt with new maintainer.
 
 Descriptions of section entries:
 
-- 
2.13.0.windows.1

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

Re: [edk2] [Patch v1 1/1] BaseTools: Move Identification file to Eot

2018-11-27 Thread Feng, Bob C

Reviewed-by : Bob Feng 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jaben 
Carsey
Sent: Friday, November 16, 2018 11:42 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: [edk2] [Patch v1 1/1] BaseTools: Move Identification file to Eot

Move the Identification file.
This file is only ever imported into the Eot tool.

Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey 
---
 BaseTools/Source/Python/{Common => Eot}/Identification.py | 0
 BaseTools/Source/Python/Eot/InfParserLite.py  | 3 ++-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Identification.py 
b/BaseTools/Source/Python/Eot/Identification.py
similarity index 100%
rename from BaseTools/Source/Python/Common/Identification.py
rename to BaseTools/Source/Python/Eot/Identification.py
diff --git a/BaseTools/Source/Python/Eot/InfParserLite.py 
b/BaseTools/Source/Python/Eot/InfParserLite.py
index c910c129a719..0cfe0398f05f 100644
--- a/BaseTools/Source/Python/Eot/InfParserLite.py
+++ b/BaseTools/Source/Python/Eot/InfParserLite.py
@@ -16,11 +16,12 @@
 #
 from __future__ import print_function
 from __future__ import absolute_import
+
 import Common.LongFilePathOs as os
 import Common.EdkLogger as EdkLogger
 from Common.DataType import *
 from CommonDataClass.DataClass import * -from Common.Identification import *
+from Eot.Identification import Identification
 from Common.StringUtils import *
 from Eot.Parser import *
 from Eot import Database
--
2.16.2.windows.1

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

Re: [edk2] [PATCH v3 1/2] MdeModulePkg/SdMmcPciHcDxe: Declare V4 64 bit address capability

2018-11-27 Thread Wu, Hao A

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Tuesday, November 20, 2018 4:59 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH v3 1/2] MdeModulePkg/SdMmcPciHcDxe: Declare V4
> 64 bit address capability
> 
> Add capability declaration for V4.x 64 bit system address support.
> This would be used for host controllers working in version 4. Enable
> 64 bit DMA support in PCI layer if V3 or V4 64 bit support is
> enabled in host capability register.
> 
> The usage of this new field does not need a guard for version check as
> spec for previous SDMMC versions defines this field as reserved with
> default value of 0.

Hello,

Sorry for the delayed response.

I have filed a Tianocore Feature Requests Bugzilla tracker for the 64-bit
SDMA/ADMA support for Sd/MMC host controller driver:

https://bugzilla.tianocore.org/show_bug.cgi?id=1359

Could you help to include this Bugzilla tracker message in your 2 proposed
patches?

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c |  4 ++--
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   |  3 ++-
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   | 10 +-
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index bf9869d..1c18ea4 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -617,7 +617,6 @@ SdMmcPciHcDriverBindingStart (
>  }
>}
> 
> -  Support64BitDma = TRUE;

Please keep the above line, otherwise GCC compiler (I am testing with GCC4.9)
seems not happy with it.

>for (Slot = FirstBar; Slot < (FirstBar + SlotNum); Slot++) {
>  Private->Slot[Slot].Enable = TRUE;
> 
> @@ -638,7 +637,8 @@ SdMmcPciHcDriverBindingStart (
>  }
>  DumpCapabilityReg (Slot, >Capability[Slot]);
> 
> -Support64BitDma &= Private->Capability[Slot].SysBus64;
> +Support64BitDma = (Private->Capability[Slot].SysBus64V3 |
> +   Private->Capability[Slot].SysBus64V4);

For the above statement, how about:

Support64BitDma &= (Private->Capability[Slot].SysBus64V3 |
Private->Capability[Slot].SysBus64V4);

The Visual Studio 2015 complier build fails for your current proposed change.


Best Regards,
Hao Wu

> 
>  Status = SdMmcHcGetMaxCurrent (PciIo, Slot, 
> >MaxCurrent[Slot]);
>  if (EFI_ERROR (Status)) {
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index bedc968..e506875 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -45,7 +45,8 @@ DumpCapabilityReg (
>DEBUG ((DEBUG_INFO, "   Voltage 3.3   %a\n", Capability->Voltage33 ?
> "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, "   Voltage 3.0   %a\n", Capability->Voltage30 ?
> "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, "   Voltage 1.8   %a\n", Capability->Voltage18 ?
> "TRUE" : "FALSE"));
> -  DEBUG ((DEBUG_INFO, "   64-bit Sys Bus%a\n", Capability->SysBus64 ?
> "TRUE" : "FALSE"));
> +  DEBUG ((DEBUG_INFO, "   V4 64-bit Sys Bus %a\n", Capability-
> >SysBus64V4 ? "TRUE" : "FALSE"));
> +  DEBUG ((DEBUG_INFO, "   V3 64-bit Sys Bus %a\n", Capability-
> >SysBus64V3 ? "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, "   Async Interrupt   %a\n", Capability->AsyncInt ?
> "TRUE" : "FALSE"));
>DEBUG ((DEBUG_INFO, "   SlotType  "));
>if (Capability->SlotType == 0x00) {
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> index 7e3f588..cc138fc 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h
> @@ -114,24 +114,24 @@ typedef struct {
>UINT32   Voltage33:1;   // bit 24
>UINT32   Voltage30:1;   // bit 25
>UINT32   Voltage18:1;   // bit 26
> -  UINT32   Reserved3:1;   // bit 27
> -  UINT32   SysBus64:1;// bit 28
> +  UINT32   SysBus64V4:1;  // bit 27
> +  UINT32   SysBus64V3:1;  // bit 28
>UINT32   AsyncInt:1;// bit 29
>UINT32   SlotType:2;// bit 30:31
>UINT32   Sdr50:1;   // bit 32
>UINT32   Sdr104:1;  // bit 33
>UINT32   Ddr50:1;   // bit 34
> -  UINT32   Reserved4:1;   // bit 35
> +  UINT32   Reserved3:1;   // bit 35
>UINT32   DriverTypeA:1; // bit 36
>UINT32   DriverTypeC:1; // bit 37
>UINT32   DriverTypeD:1; // bit 38
>UINT32   DriverType4:1; // bit 39
>UINT32   TimerCount:4;  // bit 40:43
> -  UINT32   Reserved5:1;   // bit 44
> +  UINT32   Reserved4:1;   // bit 44
>UINT32

Re: [edk2] [PATCH v3 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit SDMA and ADMA2 support.

2018-11-27 Thread Wu, Hao A

Hello,

Sorry for the delayed response.

Apart from inserting the Bugzilla tracker information, several more general 
level
comments:

1. Cannot access the files (content) on SD & eMMC devices

After applying (rebasing onto the latest codes) your patches, I found that
though the SD & eMMC devices can be detected, yet the content cannot be
accessed.

There are 1 SD card and 1 embedded eMMC device within the system. Under Shell,
I can see 2 file systems on SD & eMMC devices being detected, but when I try to
access the files on those file systems by using the 'ls' command, it fails,
saying "ls: File Not Found - 'FS0:\'". I can confirm that files can be listed
successfully without applying this patch.

I also tried the 'dblk' command for display the data via BlockIO protocols
created on those devices. I found that for SD, the command works fine. But for
eMMC, the command fails with message "dblk: Read file error - 'BlockIo'".

For the hardware I own, the controllers are all version 3.0. I tested on both
IA32 and X64 arch image. The results were the same as described above.

Unfortunately, I do not have access to boards with SD controller with version
newer than 3.0. So I am not able to perform those tests on my side for Version
4.0 or greater SD controllers.

Do you have any hardware with SD controller of version 3.0? Is it working on
your side?

Please let me know if additional information is needed.


2. On SdMmcHcGetControllerVersion()

I found that there is a 'ControllerVersion' version in the data structure
SD_MMC_HC_PRIVATE_DATA. But currently, this field seems never used.

I think we can get the controller version information only once and use this
field to store it. Hence, this new function can be eliminated and also can
avoid calling it multiple times.


3. Setting the SD_MMC_HC_64_ADDR_EN bit in SdMmcHcV4Init64BitSupport()

The setting of the SD_MMC_HC_64_ADDR_EN bit is decided by the 'SysBus64V4'
field in the CAP register. For me, additional dependency on the 64-bit DMA
support in the PCI layer is needed as well.

In function SdMmcPciHcDriverBindingStart():

  //
  // Enable 64-bit DMA support in the PCI layer if this controller
  // supports it.
  //
  if (Support64BitDma) {
Status = PciIo->Attributes (
  PciIo,
  EfiPciIoAttributeOperationEnable,
  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
  NULL
  );
if (EFI_ERROR (Status)) {
  DEBUG ((DEBUG_WARN, "SdMmcPciHcDriverBindingStart: failed to enable 
64-bit DMA (%r)\n", Status));
}
  }

If the above PCI attribute setting fails, the PCI layer will not support the
64-bit DMA.

Hence, I am thinking to introduce a new BOOLEAN field in the
"SD_MMC_HC_PRIVATE_DATA" data structure (maybe putting the 'Support64BitDma'
into the data structure). If the above PCI operation succeeds, the BOOLEAN
field will be set to TRUE, otherwise, FALSE.

And the setting of the SD_MMC_HC_64_ADDR_EN bit should depend on the BOOLEAN
field as well.


4. Please help to rebase the patch upon the latest master branch.

Some changes within the SdMmcPciHcDxe have been pushed recently. Could you help
to rebase this patch upon the latest changes. Thanks in advance.


Also, some inline comments below.


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Tuesday, November 20, 2018 4:59 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH v3 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4
> 64bit SDMA and ADMA2 support.
> 
> If V4 64 bit address mode is enabled in compatibility register,
> program controller to enable V4 host mode.
> Use appropriate ADMA2 descriptors supporting 64 bit addresses.
> Use appropriate registers for SDMA mode operation.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   4 +-
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 273
> +
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |  28 ++-
>  3 files changed, 260 insertions(+), 45 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index c683600..22795df 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,6 +2,7 @@
> 
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
> 
> +Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
>  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
> @@ -144,7 +145,8 @@ typedef struct {
>BOOLEAN Started;
>UINT64  Timeout;
> 
>

Re: [edk2] [PATCH] Maintainers.txt: Update FmpDevicePkg maintainer

2018-11-27 Thread Gao, Liming

Ack-by: Liming Gao 

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 28, 2018 9:13 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Gao, Liming ; 
> Kinney, Michael D 
> Subject: [PATCH] Maintainers.txt: Update FmpDevicePkg maintainer
> 
> As Star has some other focus, remove Star and add Liming as
> the FmpDevicePkg maintainer.
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 9a36f0232b35..91a4657adcd1 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -133,7 +133,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git
> 
>  FmpDevicePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> -M: Star Zeng 
> +M: Liming Gao 
>  M: Michael D Kinney 
> 
>  IntelFrameworkModulePkg
> --
> 2.7.0.windows.1

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

[edk2] [PATCH] SecurityPkg: Remove dead code and inf redundant definitions.

2018-11-27 Thread Chen A Chen

Fix BZ1065, https://bugzilla.tianocore.org/show_bug.cgi?id=1065

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
Cc: Zhang Chao B 
---
 SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf  |   1 -
 SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c   |  52 
 SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h   |  23 --
 SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h|  11 -
 .../Tcg/Opal/OpalPassword/OpalHiiCallbacks.c   |  87 --
 SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeMode.c   | 321 -
 SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeMode.h   | 128 
 .../Tcg/Opal/OpalPassword/OpalPasswordDxe.inf  |   2 -
 .../Tcg/Opal/OpalPassword/OpalPasswordPei.inf  |   1 -
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf   |   1 -
 SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf|   1 -
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf|   1 -
 SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDxe.inf  |   1 -
 .../SecureBootConfigDxe/SecureBootConfigDxe.inf|   2 -
 14 files changed, 632 deletions(-)

diff --git a/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf 
b/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
index 6f9a77b868..a17fa4046d 100644
--- a/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
+++ b/SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
@@ -43,7 +43,6 @@
   UefiDriverEntryPoint
   UefiBootServicesTableLib
   UefiRuntimeServicesTableLib
-  ReportStatusCodeLib
   DebugLib
   UefiLib
   MemoryAllocationLib
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
index d51865380f..0c4edd5346 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.c
@@ -969,58 +969,6 @@ AhciReset (
 
 }
 
-/**
-  Send Buffer cmd to specific device.
-
-  @param[in]  AhciContext The pointer to the AHCI_CONTEXT.
-  @param[in]  PortThe port number of attached ATA device.
-  @param[in]  PortMultiplier  The port number of port multiplier of 
attached ATA device.
-  @param[in, out]  Buffer The Data Buffer to store IDENTIFY PACKET 
Data.
-
-  @retval EFI_DEVICE_ERRORThe cmd abort with error occurs.
-  @retval EFI_TIMEOUT The operation is time out.
-  @retval EFI_UNSUPPORTED The device is not ready for executing.
-  @retval EFI_SUCCESS The cmd executes successfully.
-
-**/
-EFI_STATUS
-EFIAPI
-AhciIdentify (
-  IN AHCI_CONTEXT *AhciContext,
-  IN UINT8Port,
-  IN UINT8PortMultiplier,
-  IN OUT ATA_IDENTIFY_DATA*Buffer
-  )
-{
-  EFI_STATUS   Status;
-  EFI_ATA_COMMAND_BLOCKAtaCommandBlock;
-
-  if (AhciContext == NULL || Buffer == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
-
-  ZeroMem (, sizeof (EFI_ATA_COMMAND_BLOCK));
-
-  AtaCommandBlock.AtaCommand = ATA_CMD_IDENTIFY_DRIVE;
-  AtaCommandBlock.AtaSectorCount = 1;
-
-  Status = AhciPioTransfer (
- AhciContext,
- Port,
- PortMultiplier,
- NULL,
- 0,
- TRUE,
- ,
- NULL,
- Buffer,
- sizeof (ATA_IDENTIFY_DATA),
- ATA_TIMEOUT
- );
-
-  return Status;
-}
-
 /**
   Allocate transfer-related data struct which is used at AHCI mode.
 
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
index 037f81ac24..2076b0411b 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h
@@ -293,29 +293,6 @@ typedef struct {
   UINT32AhciBar;
 } AHCI_CONTEXT;
 
-/**
-  Send Buffer cmd to specific device.
-
-  @param  AhciContext The pointer to the AHCI_CONTEXT.
-  @param  PortThe number of port.
-  @param  PortMultiplier  The timeout Value of stop.
-  @param  Buffer  The Data Buffer to store IDENTIFY PACKET Data.
-
-  @retval EFI_DEVICE_ERRORThe cmd abort with error occurs.
-  @retval EFI_TIMEOUT The operation is time out.
-  @retval EFI_UNSUPPORTED The device is not ready for executing.
-  @retval EFI_SUCCESS The cmd executes successfully.
-
-**/
-EFI_STATUS
-EFIAPI
-AhciIdentify (
-  IN AHCI_CONTEXT *AhciContext,
-  IN UINT8Port,
-  IN UINT8PortMultiplier,
-  IN OUT ATA_IDENTIFY_DATA*Buffer
-  );
-
 /**
   Allocate transfer-related data struct which is used at AHCI mode.
 
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h
index a4bb19ad60..8b368fe995 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h
@@ -285,17 +285,6 @@ OpalHiiAddPackages(
   VOID
   );
 
-/**
-  Check whether enable feature or not.
-
-  @retval  Return the disk number.
-
-**/
-UINT8

Re: [edk2] [edk2-announce] Research Request

2018-11-27 Thread Stephano Cetola

That would be great, thank you!

https://lists.01.org/pipermail/edk2-devel/2018-November/032462.html

Cheers,
Stephano
On Tue, Nov 27, 2018 at 9:54 PM Desimone, Nathaniel L
 wrote:
>
> Hi Stephano,
>
> If no one has claimed it yet I can take Gerrit.
>
> Thanks,
> Nate
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> stephano
> Sent: Wednesday, November 14, 2018 10:34 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [edk2-announce] Research Request
>
> We are currently researching several different options to help make 
> contributing to TianoCore easier for the community. A big part of this effort 
> will be enabling pull requests and allowing for a more customizable code 
> review process.
>
> I am looking for members of the community willing to answer a few questions 
> about these solutions to allow us to evaluate our options quickly. The 
> options are:
>
> System/Tool Investigator
> Phabricator Rebecca Cran (thank you again :) )
> Github  ???
> Gerrit  ???
> Gitlab  ???
>
> I have a list of questions that I can send out to each investigator.
> Assuming you are familiar with the software/system, these questions should be 
> answerable with a couple hours of research, writing, and screenshots / 
> examples.
>
> Thanks in advance for your help!
>
> -Stephano
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

2018-11-27 Thread Desimone, Nathaniel L

Hi Stephano,

If no one has claimed it yet I can take Gerrit.

Thanks,
Nate

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of stephano
Sent: Wednesday, November 14, 2018 10:34 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-announce] Research Request

We are currently researching several different options to help make 
contributing to TianoCore easier for the community. A big part of this effort 
will be enabling pull requests and allowing for a more customizable code review 
process.

I am looking for members of the community willing to answer a few questions 
about these solutions to allow us to evaluate our options quickly. The options 
are:

System/Tool Investigator
Phabricator Rebecca Cran (thank you again :) )
Github  ???
Gerrit  ???
Gitlab  ???

I have a list of questions that I can send out to each investigator. 
Assuming you are familiar with the software/system, these questions should be 
answerable with a couple hours of research, writing, and screenshots / examples.

Thanks in advance for your help!

-Stephano

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

Re: [edk2] [PATCH v5 0/5] ArmPkg related changes for StandaloneMM package

2018-11-27 Thread Sughosh Ganu

On Tue Nov 27, 2018 at 01:08:33PM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 11:44, Sughosh Ganu  wrote:
> >
> >
> > Changes since v4:
> > Based on comments from Ard
> >  - Removed now superfluous call to FreePages from MmCommunication.c
> >  - Removed Chipset/AArch64.h header file from ArmMmuStandaloneMmLib.c
> >
> > Changes since v3:
> > Based on review comments from Ard, moved the MMU attribute changing
> > functions for StandaloneMM image into a new library class.
> >
> > Moved the addition of memory space used as a MM_COMMUNICATE buffer to
> > memory type 'EfiGcdMemoryTypeReserved' and removed the call to
> > AllocatgePages.
> >
> > Changes since v2:
> > Based on review comments from Ard, moved the memory attribute updation
> > changes out of DebugPeCoffExtraActionLib into an extra action library
> > added in StandaloneMM package. The patch for setting the memory
> > attributes, now under StandaloneMmPkg directory, will be submitted
> > separately from this series.
> >
> > Changes since v1: Handled review comments from Leif
> >
> >
> > Achin Gupta (4):
> >   ArmPkg: Add PCDs needed for MM communication driver.
> >   ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
> >   ArmPkg/Include: Add MM interface SVC return codes.
> >   ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
> >
> > Sughosh Ganu (1):
> >   ArmPkg/Include: Fix the SPM version SVC ID
> >
> 
> Reviewed-by: Ard Biesheuvel 
> 
> Pushed as 13d5d0a56e48..eed947be0b05
> 
> Thanks! I'm very happy we will finally have the pieces in place to
> implement UEFI secure boot on ARM in a sane way.


Thanks a lot for the review and for applying the patches Ard!

-sughosh

> 
> >  ArmPkg/ArmPkg.dec  
> > 
> >  |   4 +
> >  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf  
> > 
> >  |  56 +++
> >  
> > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> >  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf |  23 +-
> >  ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h  
> > 
> >  |  28 ++
> >  ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
> > 
> >  |   9 +-
> >  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h}   
> > 
> >  |  38 +-
> >  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > 
> >  | 372 
> >  ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c  
> > 
> >  | 184 ++
> >  8 files changed, 669 insertions(+), 45 deletions(-)
> >  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> >  copy 
> > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> >  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf (56%)
> >  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
> >  copy ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h} (55%)
> >  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> >  create mode 100644 
> > ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> >
> > --
> > 2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] [edk2-test][PATCH v2] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool

2018-11-27 Thread Supreeth Venkatesh

Same general comments apply (given in first one in the series).

On Tue, 2018-11-27 at 23:20 +0530, Lokesh B V wrote:
> Some windows editors uses "\r\n" for line feed. While processing uefi
> testcase
> info file, the GenBin tool logic to skip line feed doesn't consider
> the presence
> of carraige return(\r) in line feed. So this results in incorrect 
Please fix the commit message with "carriage return" (same comment as 
given by Philippe)
> format error.
> 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V 
> 
> Signed-off-by: Lokesh B V 
> ---
>  uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c b/uefi-
> sct/SctPkg/Tools/Source/GenBin/GenBin.c
> index 61bb35b..4eaefcc 100644
> --- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> +++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> @@ -2,6 +2,7 @@
>  
>Copyright 2006 - 2010 Unified EFI, Inc.
>Copyright (c) 2010 Intel Corporation. All rights reserved.
> +  Copyright (c) 2018 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
> @@ -176,6 +177,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
>  if ((String[Index1] != ' ' ) &&
>  (String[Index1] != '\t') &&
> +(String[Index1] != '\r') &&
>  (String[Index1] != '\n')) {
>break;
>  }
This Trim function is ridden with bugs. Use the linux kernel
implementation to avoid bugs. Lets fix this properly. something like
below.

char *
Trim (
  char*s
  )
{
  size_t size;
  char *end;

  size = strlen(s);

  if (!size)
return s;

  end = s + size - 1;
  while (end >= s && isspace(*end))
end--;

  *(end + 1) = '\0';

  while (*s && isspace(*s))
s++;

  return s;
}

> @@ -193,6 +195,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
>  if ((String[Length - 1 - Index1] != ' ' ) &&
>  (String[Length - 1 - Index1] != '\t') &&
> +(String[Length - 1 - Index1] != '\r') &&
>  (String[Length - 1 - Index1] != '\n')) {
>break;
>  }

Finally, Getline function should be altered as below to properly skip
empty lines and comment lines like below (or similar).

  for ( ; ; ) {
//
// Get a string from the profile
//
Result = fgets (String, MAX_LINE_LENGTH, Profile);
if (Result == NULL) {
  return -1;
}

//
// Remove the beginning and ending space characters
//
String = Trim (Result);

//
// Skip the empty line and comment line
//
if ((String[0] == '\0') ||
(String[0] == '#' )) {
  continue;
}

(*LineNo)++;
  }

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

Re: [edk2] [PATCH 1/2] [edk2-test][PATCH v3] SctPkg/build: Add support for GenBin tool build

2018-11-27 Thread Supreeth Venkatesh

General Comments:
1. This patch set should have this in  subject line
 "[edk2][edk2-test][PATCH v3 n/m]"
2. Cover letter to specify what changes from v1 to v2 to v3 to help
make maintainers job easier.

More comments inline.

On Tue, 2018-11-27 at 23:20 +0530, Lokesh B V wrote:
> As the GenBin tool is necessary for SCT build, it is appropriate to
> support it's build in the SCT build procedure.
> 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V 
> ---
>  .gitignore   |  1 +
Why did this file change?
If to ignore *.d and *.o files, that should be a separate change in
itself.

>  uefi-sct/SctPkg/build.sh | 33 -
>  2 files changed, 21 insertions(+), 13 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 821ed66..3b8d818 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,2 +1,3 @@
>  Build/
>  tags/
> +*.[od]
> diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
> index 73581c9..92e52c6 100755
> --- a/uefi-sct/SctPkg/build.sh
> +++ b/uefi-sct/SctPkg/build.sh
> @@ -1,7 +1,7 @@
>  #!/bin/bash
>  #
>  #  Copyright 2006 - 2015 Unified EFI, Inc.
> -#  Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2011 - 2018, 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
> @@ -228,21 +228,28 @@ else
>echo using prebuilt tools
>  fi
>  
> -# Copy GenBin file to Base tools directory
Since the advent of edk2-test repository, we won't be using any
binaries. So its better to GenBin everytime.

> +if  [[ ! -e $EDK_TOOLS_PATH/Source/C/bin/GenBin ]]
> +then
> +  # build the GenBin if it doesn't yet exist
> +  echo Building GenBin
> +  make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin
> +  status=$?
> +  if test $status -ne 0
> +  then
> +  echo Error while building GenBin
> +exit -1
> +  fi
> +else
> +  echo using prebuilt GenBin
> +fi
> +
> +# Copy GenBin file to Base tools bin directory
>  DEST_DIR=`GetEdkToolsPathBinDirectory`
>  # Ensure the directory exist
>  mkdir -p $DEST_DIR
> -case `uname -m` in 
> - x86_64)
> - cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin
> - ;;
> - x86_32)
> - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> - ;;
> - *)
> - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> - ;;
> -esac
> +cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin
> +# Clean the intermediate binary file
> +rm -f $EDK_TOOLS_PATH/Source/C/bin/GenBin
Better to add this at the beginning to get rid of any stale binaries in
the build.

>  
>  #
>  # Build the SCT package

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

Re: [edk2] [PATCH] Maintainers.txt: Update MdeModulePkg maintainers

2018-11-27 Thread Wang, Jian J

Acked-by: Jian J Wang 

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 28, 2018 9:19 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A 
> Subject: [PATCH] Maintainers.txt: Update MdeModulePkg maintainers
> 
> As Star has some other focus, change Star from maintainer
> to reviewer, Jian will be the first maintainer, and add
> Hao as the second maintainer.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  Maintainers.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 91a4657adcd1..371268822427 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -170,13 +170,14 @@ M: Rangasai V Chaganty
> 
> 
>  MdeModulePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Star Zeng 
>  M: Jian J Wang 
> +M: Hao Wu 
>  M: NetworkPkg maintainers
>(Universal/Network and related libraries, header files)
>  R: Ruiyu Ni 
>(especially for Bus, Universal/Console, Universal/Disk,
> Universal/BdsDxe and related libraries, header files)
> +R: Star Zeng 
> 
>  MdePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH] Maintainers.txt: Update MdeModulePkg maintainers

2018-11-27 Thread Wu, Hao A

Thanks Star,

Acked-by: Hao Wu 

Best Regards,
Hao Wu

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Star Zeng
> Sent: Wednesday, November 28, 2018 9:19 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Zeng, Star
> Subject: [edk2] [PATCH] Maintainers.txt: Update MdeModulePkg
> maintainers
> 
> As Star has some other focus, change Star from maintainer
> to reviewer, Jian will be the first maintainer, and add
> Hao as the second maintainer.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  Maintainers.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 91a4657adcd1..371268822427 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -170,13 +170,14 @@ M: Rangasai V Chaganty
> 
> 
>  MdeModulePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Star Zeng 
>  M: Jian J Wang 
> +M: Hao Wu 
>  M: NetworkPkg maintainers
>(Universal/Network and related libraries, header files)
>  R: Ruiyu Ni 
>(especially for Bus, Universal/Console, Universal/Disk,
> Universal/BdsDxe and related libraries, header files)
> +R: Star Zeng 
> 
>  MdePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
> --
> 2.7.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] Maintainers.txt: Update MdeModulePkg maintainers

2018-11-27 Thread Star Zeng

As Star has some other focus, change Star from maintainer
to reviewer, Jian will be the first maintainer, and add
Hao as the second maintainer.

Cc: Jian J Wang 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 Maintainers.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 91a4657adcd1..371268822427 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -170,13 +170,14 @@ M: Rangasai V Chaganty 
 
 MdeModulePkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
-M: Star Zeng 
 M: Jian J Wang 
+M: Hao Wu 
 M: NetworkPkg maintainers
   (Universal/Network and related libraries, header files)
 R: Ruiyu Ni 
   (especially for Bus, Universal/Console, Universal/Disk,
Universal/BdsDxe and related libraries, header files)
+R: Star Zeng 
 
 MdePkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
-- 
2.7.0.windows.1

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

Re: [edk2] FmpDeviceLib

2018-11-27 Thread Kinney, Michael D

Tom,

Thanks for noticing this issue.  I need a little 
time to evaluate this use case and see what changes
are required to make this work for a UEFI driver
that manages many controllers.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Tomas Pilar (tpilar)
> Sent: Tuesday, November 27, 2018 7:29 AM
> To: Gao, Liming ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] FmpDeviceLib
> 
> Okay, so I just noticed that FmpDxe is full of module
> globals including the image descriptor, so it
> necessarily requires that the driver that includes it as
> a library can only ever control one controller.
> 
> Cheers,
> Tom
> 
> On 27/11/2018 15:23, Tomas Pilar (tpilar) wrote:
> >
> > On 27/11/2018 14:33, Gao, Liming wrote:
> >> Tom:
> >>   FmpDeviceLib can use UEFI driver model/driver
> binding protocol so it can install FMP on its device
> handle during the BDS/Device connection phase. It can
> implement RegisterFmpInstaller() to install FMP protocol
> in its device handle. In this way, FmpDeviceLib is like
> UEFI driver with UEFI driver binding protocol.
> >>
> >> Thanks
> >> Liming
> > Hi Liming,
> >
> > Sure, so now I can install FMP onto my
> ControllerHandle. Say that someone gets the FMP and
> calls GetImageSize. The FmpDxeLib does some checks and
> then it calls FmpDeviceLibGetImageSize() with no context
> parameter. This method is supposed to be implemented by
> me, the driver writer, but how is the code in this
> method meant to know which Controller are we getting the
> image size from?
> >
> > So maybe I can define some module globals, declare
> them in a cross include file, include that in my driver
> and and have the driver populate the module globals
> during probe. This immediately limits the usefulness by
> requiring that each driver only ever drives one
> controller.
> >
> > And then you consider how to do a SetImage without
> being even given the Handle of the Controller. Do you
> stuff the controller handle into a module global
> parameter that gets populated during the BDS phase?
> >
> > I guess you could enumerate all FMP instances, see
> which one of them advertises your ImageTypeId and get
> the handle that the FMP is installed on that way. But
> that seems rather insane and would cause issues if you
> have two of the same device in the platform, unless you
> check the HardwareInstance as well? This seems insane.
> >
> > Cheers,
> > Tom
> >
> >>> -Original Message-
> >>> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Tomas Pilar (tpilar)
> >>> Sent: Tuesday, November 27, 2018 9:26 PM
> >>> To: edk2-devel@lists.01.org
> >>> Subject: [edk2] FmpDeviceLib
> >>>
> >>> Hi all,
> >>>
> >>> I am looking at using FmpDxeLib so I need to
> implement the FmpDeviceLib. However, it seems like the
> library functions do not take any
> >>> private struct as a parameter, so I am struggling to
> figure out how to read information off the hardware.
> FmpDxe does not even pass its
> >>> created protocol instance when calling the library
> functions, leading me to believe that the only way to do
> this is to assign a pointer to
> >>> private struct during library construction, but that
> means that a driver that uses the code can only ever
> service a single controller.
> >>>
> >>> Can you offer any insights?
> >>>
> >>> Cheers,
> >>> Tom
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] Maintainers.txt: Update FmpDevicePkg maintainer

2018-11-27 Thread Star Zeng

As Star has some other focus, remove Star and add Liming as
the FmpDevicePkg maintainer.

Cc: Liming Gao 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 Maintainers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 9a36f0232b35..91a4657adcd1 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -133,7 +133,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git
 
 FmpDevicePkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
-M: Star Zeng 
+M: Liming Gao 
 M: Michael D Kinney 
 
 IntelFrameworkModulePkg
-- 
2.7.0.windows.1

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

Re: [edk2] [Patch] Edk2: Update FmpDevicePkg Maintainers

2018-11-27 Thread Zeng, Star

Philippe,

Good suggestion. :)
Let me send the patch.


Thanks,
Star
-Original Message-
From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com] 
Sent: Tuesday, November 27, 2018 11:17 PM
To: Gao, Liming ; edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: Re: [edk2] [Patch] Edk2: Update FmpDevicePkg Maintainers

Hi,

On 27/11/18 15:59, Liming Gao wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Star Zeng 

The usual workflow to hand over is the previous maintainer send the patch, and 
you Ack-by it.
Exceptions are acceptable but require an explanation in the commit message.

Regards,

Phil.

> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt index 
> 9a36f0232b..91a4657adc 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -133,7 +133,7 @@ T: git - 
> https://github.com/tianocore/edk2-FatPkg.git
>  
>  FmpDevicePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> -M: Star Zeng 
> +M: Liming Gao 
>  M: Michael D Kinney 
>  
>  IntelFrameworkModulePkg
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] Edk2: Update BaseTools Maintainers

2018-11-27 Thread BobCF

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: BobCF 
Cc: Yonghong Zhu 
Cc: Liming Gao 
---
 Maintainers.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 9a36f0232b..babed93284 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -77,12 +77,13 @@ M: Laszlo Ersek 
 M: Ard Biesheuvel 
 R: Julien Grall 
 
 BaseTools
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
-M: Yonghong Zhu 
+M: Bob Feng 
 M: Liming Gao 
+R: Yonghong Zhu 
 
 BeagleBoardPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/BeagleBoardPkg
 M: Leif Lindholm 
 M: Ard Biesheuvel 
-- 
2.19.1.windows.1

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

Re: [edk2] [edk2-announce] Research Request

2018-11-27 Thread Rebecca Cran via edk2-devel

On Tuesday, 27 November 2018 14:16:18 MST Jeremiah Cox via edk2-devel wrote:

> Do we have data on what it takes to deploy and operate Phabricator with
> Harbormaster or Jenkins?  The up front development/deployment
> activity/costs and then also the ongoing patching/servicing/maintenance
> costs?  Is Intel planning to provide this?

I haven't integrated Harbormaster or Jenkins, but for just Phabricator the 
patching/servicing has ben really simple for the year+ I've been running it. 
I'd not consider it 'production' since I'm the only person using it and I'm 
running from Git master, not a stable branch - but maintenance has been as 
simple as the following (which could of course be put in a script to reduce 
the number of steps!):

# Stop the Phabricator daemon
./bin/phd stop
# Update Phabricator
git pull
# Update libphputil
cd ../libphputil && git pull
# Upgrade arcanist (commandline interface)
cd ../arcanist && git pull
# Upgrade database schema
./bin/storage upgrade
# Start Phabricator daemon
./bin/phd start
# Reload web server
service nginx restart
service php-fpm restart

The "storage upgrade" command goes through the database looking for any 
inconsistencies - missing keys, wrong data types etc., and offers to fix them.

-- 
Rebecca

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

Re: [edk2] [edk2-announce] Research Request

2018-11-27 Thread Brian J. Johnson


On 11/27/18 6:53 AM, Laszlo Ersek wrote:

On 11/26/18 22:43, Jeremiah Cox via edk2-devel wrote:

Feedback on GitHub as follows…



1. No Lock-In - What automated data export is available?
We want to be able to leave and take all our data with us. "Data" here
includes: review comments, pull requests / patches (including metadata),
old (rejected) pull requests and metadata, issue tracker entries and
comments (if issue tracker included). This archiving should be
automated, not something we do by hand.

Untested, but might these all be easily satisfied by subscribing a mailing list 
to GitHub notifications?
https://help.github.com/articles/about-notifications/#watching-notifications  
https://help.github.com/articles/about-email-notifications/  

No, they are insufficient.

Following the last link above ("about-email-notifications"), one finds
several other links; and one of those is:

https://help.github.com/articles/about-notifications/

This article says,

 GitHub sends participating notifications when you're directly
 involved in activities or conversations within a repository or a
 team you're a member of. You'll receive a notification when:

 [...]

 - You open, comment on, or close an issue or pull request.

 [...]

This is demonstrably false. I'm a member of the TianoCore organization,
I have commented on, and closed (rejected):

   https://github.com/tianocore/edk2/pull/133

and I *never*  received an email notification about my *own*  comment /
action. I only received the initial email, about the pull request being
opened (attached for reference).


Try going to the "Settings" item under the menu in the top-right corner, 
and clicking on the "Notifications" tab on the left.  Under "Email 
notification preferences" there should be a checkbox for "Include your 
own updates".  That may do what you need.


--
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

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

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 21:25, Laszlo Ersek  wrote:
>
> On 11/27/18 18:52, Ard Biesheuvel wrote:
> > On Tue, 27 Nov 2018 at 18:26, Laszlo Ersek  wrote:
> >>
> >> On 11/27/18 15:54, Ard Biesheuvel wrote:
> >>> Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
> >>> entire virtual address space is mapped with EFI_MEMORY_UC attributes,
> >>> regardless of whether any devices actually reside there.
> >>>
> >>> Now that we are relaxing the address space limit to more than 40 bits,
> >>> mapping all that address space actually takes up more space in page
> >>> tables than we have so far made available as temporary RAM. So let's
> >>> get rid of the mapping rather than increasing the available RAM, given
> >>> that the mapping is not particularly useful anyway.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Ard Biesheuvel 
> >>> ---
> >>>  ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 17 
> >>> +
> >>>  1 file changed, 5 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c 
> >>> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> >>> index 815ca145b644..70863abb2e7b 100644
> >>> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> >>> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> >>> @@ -73,21 +73,14 @@ ArmVirtGetMemoryMap (
> >>>VirtualMemoryTable[1].Length   = 
> >>> VirtualMemoryTable[0].PhysicalBase;
> >>>VirtualMemoryTable[1].Attributes   = 
> >>> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >>>
> >>> -  // Peripheral space after DRAM
> >>> -  VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length + 
> >>> VirtualMemoryTable[1].Length;
> >>> -  VirtualMemoryTable[2].VirtualBase  = 
> >>> VirtualMemoryTable[2].PhysicalBase;
> >>> -  VirtualMemoryTable[2].Length   = TopOfAddressSpace -
> >>> -   
> >>> VirtualMemoryTable[2].PhysicalBase;
> >>> -  VirtualMemoryTable[2].Attributes   = 
> >>> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >>> -
> >>>// Remap the FD region as normal executable memory
> >>> -  VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> >>> -  VirtualMemoryTable[3].VirtualBase  = 
> >>> VirtualMemoryTable[3].PhysicalBase;
> >>> -  VirtualMemoryTable[3].Length   = FixedPcdGet32 (PcdFdSize);
> >>> -  VirtualMemoryTable[3].Attributes   = 
> >>> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> >>> +  VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> >>> +  VirtualMemoryTable[2].VirtualBase  = 
> >>> VirtualMemoryTable[2].PhysicalBase;
> >>> +  VirtualMemoryTable[2].Length   = FixedPcdGet32 (PcdFdSize);
> >>> +  VirtualMemoryTable[2].Attributes   = 
> >>> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> >>>
> >>>// End of Table
> >>> -  ZeroMem ([4], sizeof 
> >>> (ARM_MEMORY_REGION_DESCRIPTOR));
> >>> +  ZeroMem ([3], sizeof 
> >>> (ARM_MEMORY_REGION_DESCRIPTOR));
> >>>
> >>>*VirtualMemoryMap = VirtualMemoryTable;
> >>>  }
> >>>
> >>
> >> (1) This supplants your other series "[PATCH v2 00/13] ArmPkg, ArmVirtPkg: 
> >> lift 40-bit IPA space limit" minimally due to a contextual conflict; is 
> >> that right?
> >>
> >
> > Not quite. It complements it, in the sense that is should fix the
> > issue reported by Eric when mapping the entire address 48-bit address
> > space.
>
> Oh, you meant this one *on top* of that? In particular, on top of:
>
> [edk2] [PATCH v2 11/13] ArmVirtPkg/QemuVirtMemInfoLib: ignore
> PcdPrePiCpuMemorySize
>
> That wasn't clear to me, sorry.
>

No, the other way around actually :-)

Apologies, I managed to confuse myself a bit as well, so I understand
this may be slightly difficult to follow.

> If this one comes on top of the v2 13-part series, do you ultimately
> need v2 11/13 as a separate patch -- in that form anyway? It seems that
> you could squash this patch into v2 11/13, and eliminate the dependency
> on PcdPrePiCpuMemorySize *by* killing the entry that maps the Peripheral
> space after DRAM.
>

Indeed. So after applying these two patches, I will need to respin
that series once more, and now that I think of it, it might make sense
to simplify those changes signficantly, given that only the Xen code
needs to access the CPU's capability registers in the platform MMU
setup code.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

2018-11-27 Thread Jeremiah Cox via edk2-devel

That is a good data point, thank you Ryszard.  

Do we have data on what it takes to deploy and operate Phabricator with 
Harbormaster or Jenkins?  The up front development/deployment activity/costs 
and then also the ongoing patching/servicing/maintenance costs?  Is Intel 
planning to provide this?

For Project Mu we are leveraging GitHub and Azure Dev Ops for gates & CI builds 
(free for OSS).  We had this basically working in a day and is operating for 
free with all patching/maintenance provided by GitHub & Azure Dev Ops.

-Original Message-
From: Knop, Ryszard  
Sent: Tuesday, November 27, 2018 1:34 AM
To: Jeremiah Cox ; stephano 
; edk2-devel@lists.01.org
Subject: RE: [edk2] [edk2-announce] Research Request

To add on Phabricator not supporting Travis CI - since Travis works exclusively 
with GitHub and has zero interest in supporting anything else, there are other 
options, eg Harbormaster ("native" CI module in Phabricator) or Jenkins (as far 
as I'm aware, many teams at Intel already know Jenkins one way or another). For 
a public example, KDE hosts all their sources on a self-hosted Phabricator 
instance and does CI with Jenkins - see 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuild.kde.org%2Fdata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543sdata=4coAaUQSgmoxLC3SDsW1M0X0bu61hhWQJlP%2B1xyP%2FW0%3Dreserved=0
 and 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricator.kde.org%2Fdata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543sdata=MJaEesRphYxAtZCSJ%2Fyz3ZwcT%2FmMBRGAYHL0GxD5KWw%3Dreserved=0
 - so that's not a problem :)

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeremiah 
Cox via edk2-devel
Sent: Monday, November 26, 2018 22:43
To: stephano 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request

Feedback on GitHub as follows…


> 1. No Lock-In - What automated data export is available?
> We want to be able to leave and take all our data with us. "Data" here
> includes: review comments, pull requests / patches (including 
> metadata), old (rejected) pull requests and metadata, issue tracker 
> entries and comments (if issue tracker included). This archiving 
> should be automated, not something we do by hand.

Untested, but might these all be easily satisfied by subscribing a mailing list 
to GitHub notifications?  
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-notifications%2F%23watching-notificationsdata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543sdata=g3nvEWQuUZzFBEeEpSq63lZLRoPwp06el3kiNmFjfQA%3Dreserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-email-notifications%2Fdata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284825543sdata=4k56B1IeZyK2f3d%2BX9D2q3FFpk0kHt4Jey1NlwYunzs%3Dreserved=0
 

Alternatively, the GitHub REST API appear to offer full export capability of 
all information & metadata:
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fgit%2Fcommits%2F%23get-a-commitdata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552sdata=JsmAP23PWWpvjgfH9XO3qR0OtW8unBujs3MCG7ABCfg%3Dreserved=0
 
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fpulls%2F%23list-pull-requestsdata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552sdata=5TgHzyJNYI2YxRASb4z5QCtui100Ftz25tVxQObytrs%3Dreserved=0
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fpulls%2Fcomments%2F%23list-comments-on-a-pull-requestdata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552sdata=iDB1PW%2B9G1Ywjj%2FFeLYtKmcBI3szuz9%2FX5rBtL0ZNxk%3Dreserved=0
   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Fissues%2Fevents%2F%23list-events-for-a-repositorydata=02%7C01%7Cjerecox%40microsoft.com%7C2dc3cdfe68db4498136b08d6544b6cd6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636789080284835552sdata=1lqC1ZUraFJqs8AJm0Ffd2pJGdK0lA2RA0ADteB2msQ%3Dreserved=0

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range

2018-11-27 Thread Laszlo Ersek

On 11/27/18 18:52, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 18:26, Laszlo Ersek  wrote:
>>
>> On 11/27/18 15:54, Ard Biesheuvel wrote:
>>> Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
>>> entire virtual address space is mapped with EFI_MEMORY_UC attributes,
>>> regardless of whether any devices actually reside there.
>>>
>>> Now that we are relaxing the address space limit to more than 40 bits,
>>> mapping all that address space actually takes up more space in page
>>> tables than we have so far made available as temporary RAM. So let's
>>> get rid of the mapping rather than increasing the available RAM, given
>>> that the mapping is not particularly useful anyway.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 17 
>>> +
>>>  1 file changed, 5 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c 
>>> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
>>> index 815ca145b644..70863abb2e7b 100644
>>> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
>>> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
>>> @@ -73,21 +73,14 @@ ArmVirtGetMemoryMap (
>>>VirtualMemoryTable[1].Length   = VirtualMemoryTable[0].PhysicalBase;
>>>VirtualMemoryTable[1].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>>>
>>> -  // Peripheral space after DRAM
>>> -  VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length + 
>>> VirtualMemoryTable[1].Length;
>>> -  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
>>> -  VirtualMemoryTable[2].Length   = TopOfAddressSpace -
>>> -   VirtualMemoryTable[2].PhysicalBase;
>>> -  VirtualMemoryTable[2].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>>> -
>>>// Remap the FD region as normal executable memory
>>> -  VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
>>> -  VirtualMemoryTable[3].VirtualBase  = VirtualMemoryTable[3].PhysicalBase;
>>> -  VirtualMemoryTable[3].Length   = FixedPcdGet32 (PcdFdSize);
>>> -  VirtualMemoryTable[3].Attributes   = 
>>> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>>> +  VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
>>> +  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
>>> +  VirtualMemoryTable[2].Length   = FixedPcdGet32 (PcdFdSize);
>>> +  VirtualMemoryTable[2].Attributes   = 
>>> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>>>
>>>// End of Table
>>> -  ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
>>> +  ZeroMem ([3], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
>>>
>>>*VirtualMemoryMap = VirtualMemoryTable;
>>>  }
>>>
>>
>> (1) This supplants your other series "[PATCH v2 00/13] ArmPkg, ArmVirtPkg: 
>> lift 40-bit IPA space limit" minimally due to a contextual conflict; is that 
>> right?
>>
> 
> Not quite. It complements it, in the sense that is should fix the
> issue reported by Eric when mapping the entire address 48-bit address
> space.

Oh, you meant this one *on top* of that? In particular, on top of:

[edk2] [PATCH v2 11/13] ArmVirtPkg/QemuVirtMemInfoLib: ignore
PcdPrePiCpuMemorySize

That wasn't clear to me, sorry.

If this one comes on top of the v2 13-part series, do you ultimately
need v2 11/13 as a separate patch -- in that form anyway? It seems that
you could squash this patch into v2 11/13, and eliminate the dependency
on PcdPrePiCpuMemorySize *by* killing the entry that maps the Peripheral
space after DRAM.

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

Re: [edk2] [PATCH v3 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit SDMA and ADMA2 support.

2018-11-27 Thread Ashish Singhal

Hello,

Any feedback on this patch yet?

Thanks
Ashish

-Original Message-
From: Ashish Singhal  
Sent: Monday, November 19, 2018 1:59 PM
To: edk2-devel@lists.01.org
Cc: Ashish Singhal 
Subject: [PATCH v3 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit SDMA and ADMA2 
support.

If V4 64 bit address mode is enabled in compatibility register, program 
controller to enable V4 host mode.
Use appropriate ADMA2 descriptors supporting 64 bit addresses.
Use appropriate registers for SDMA mode operation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal 
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   4 +-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 273 +
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |  28 ++-
 3 files changed, 260 insertions(+), 45 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
index c683600..22795df 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
@@ -2,6 +2,7 @@
 
   Provides some data structure definitions used by the SD/MMC host controller 
driver.
 
+Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
 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 @@ -144,7 +145,8 @@ typedef struct {
   BOOLEAN Started;
   UINT64  Timeout;
 
-  SD_MMC_HC_ADMA_DESC_LINE*AdmaDesc;
+  SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
+  SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
   EFI_PHYSICAL_ADDRESSAdmaDescPhy;
   VOID*AdmaMap;
   UINT32  AdmaPages;
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
index e506875..9fef3fb 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
@@ -4,6 +4,7 @@
 
   It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
 
+  Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
   Copyright (c) 2015 - 2017, 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 @@ -418,6 +419,36 @@ SdMmcHcWaitMmioSet (  }
 
 /**
+  Get the controller version information from the specified slot.
+
+  @param[in]  PciIo   The PCI IO protocol instance.
+  @param[in]  SlotThe slot number of the SD card to send the 
command to.
+  @param[out] Version The buffer to store the version information.
+
+  @retval EFI_SUCCESS The operation executes successfully.
+  @retval Others  The operation fails.
+
+**/
+EFI_STATUS
+SdMmcHcGetControllerVersion (
+  IN EFI_PCI_IO_PROTOCOL  *PciIo,
+  IN UINT8Slot,
+ OUT UINT16   *Version
+  )
+{
+  EFI_STATUSStatus;
+
+  Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_CTRL_VER, TRUE, sizeof 
+ (UINT16), Version);  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  *Version &= 0xFF;
+
+  return EFI_SUCCESS;
+}
+
+/**
   Software reset the specified SD/MMC host controller and enable all 
interrupts.
 
   @param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA instance.
@@ -776,18 +807,18 @@ SdMmcHcClockSupply (
 
   DEBUG ((DEBUG_INFO, "BaseClkFreq %dMHz Divisor %d ClockFreq %dKhz\n", 
BaseClkFreq, Divisor, ClockFreq));
 
-  Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_CTRL_VER, TRUE, sizeof 
(ControllerVer), );
+  Status = SdMmcHcGetControllerVersion (PciIo, Slot, );
   if (EFI_ERROR (Status)) {
 return Status;
   }
   //
   // Set SDCLK Frequency Select and Internal Clock Enable fields in Clock 
Control register.
   //
-  if (((ControllerVer & 0xFF) >= SD_MMC_HC_CTRL_VER_300) &&
-  ((ControllerVer & 0xFF) <= SD_MMC_HC_CTRL_VER_420)) {
+  if ((ControllerVer >= SD_MMC_HC_CTRL_VER_300) &&
+  (ControllerVer <= SD_MMC_HC_CTRL_VER_420)) {
 ASSERT (Divisor <= 0x3FF);
 ClockCtrl = ((Divisor & 0xFF) << 8) | ((Divisor & 0x300) >> 2);
-  } else if (((ControllerVer & 0xFF) == 0) || ((ControllerVer & 0xFF) == 1)) {
+  } else if ((ControllerVer == 0) || (ControllerVer == 1)) {
 //
 // Only the most significant bit can be used as divisor.
 //
@@ -935,6 +966,54 @@ SdMmcHcSetBusWidth (  }
 
 /**
+  Configure V4 64 bit system address support at initialization.
+
+  @param[in] PciIo  The PCI IO protocol instance.
+  @param[in] Slot   The slot number of the SD card to send the command 
to.
+  @param[in] Capability The capability of the slot.
+
+  @retval EFI_SUCCESS   The clock is supplied successfully.
+
+**/

Re: [edk2] [Patch v1 1/1] BaseTools: cleanup LongFilePathSupport usage

2018-11-27 Thread Carsey, Jaben

Poke.  Any comments on this one?

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jaben Carsey
> Sent: Friday, November 16, 2018 7:38 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [Patch v1 1/1] BaseTools: cleanup LongFilePathSupport usage
> 
> 1) remove an identical function and import it from
> Common.LongFilePathSupport
> 2) remove an import that is not needed/used.
> 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jaben Carsey 
> ---
>  BaseTools/Source/Python/AutoGen/UniClassObject.py | 14 +-
>  BaseTools/Source/Python/build/build.py|  1 -
>  2 files changed, 1 insertion(+), 14 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py
> b/BaseTools/Source/Python/AutoGen/UniClassObject.py
> index 384f31b165de..764d95ec660b 100644
> --- a/BaseTools/Source/Python/AutoGen/UniClassObject.py
> +++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py
> @@ -24,7 +24,7 @@ from io import BytesIO
>  from Common.BuildToolError import *
>  from Common.StringUtils import GetLineNo
>  from Common.Misc import PathClass
> -from Common.LongFilePathSupport import LongFilePath
> +from Common.LongFilePathSupport import LongFilePath, UniToStr
>  from Common.GlobalData import *
>  ##
>  # Static definitions
> @@ -46,18 +46,6 @@ BACK_SLASH_PLACEHOLDER = u'\u0006'
> 
>  gIncludePattern = re.compile("^#include +[\"<]+([^\"< >]+)[>\"]+$",
> re.MULTILINE | re.UNICODE)
> 
> -## Convert a python unicode string to a normal string
> -#
> -# Convert a python unicode string to a normal string
> -# UniToStr(u'I am a string') is 'I am a string'
> -#
> -# @param Uni:  The python unicode string
> -#
> -# @retval: The formatted normal string
> -#
> -def UniToStr(Uni):
> -return repr(Uni)[2:-1]
> -
>  ## Convert a unicode string to a Hex list
>  #
>  # Convert a unicode string to a Hex list
> diff --git a/BaseTools/Source/Python/build/build.py
> b/BaseTools/Source/Python/build/build.py
> index d74082fc2666..5eeb626cfbbb 100644
> --- a/BaseTools/Source/Python/build/build.py
> +++ b/BaseTools/Source/Python/build/build.py
> @@ -36,7 +36,6 @@ from subprocess import *
>  from Common import Misc as Utils
> 
>  from Common.LongFilePathSupport import OpenLongFilePath as open
> -from Common.LongFilePathSupport import LongFilePath
>  from Common.TargetTxtClassObject import *
>  from Common.ToolDefClassObject import *
>  from Common.DataType import *
> --
> 2.16.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/2] [edk2-test][PATCH v2] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool

2018-11-27 Thread Lokesh B V

Some windows editors uses "\r\n" for line feed. While processing uefi testcase
info file, the GenBin tool logic to skip line feed doesn't consider the presence
of carraige return(\r) in line feed. So this results in incorrect format error.

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Lokesh B V 

Signed-off-by: Lokesh B V 
---
 uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index 61bb35b..4eaefcc 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -2,6 +2,7 @@
 
   Copyright 2006 - 2010 Unified EFI, Inc.
   Copyright (c) 2010 Intel Corporation. All rights reserved.
+  Copyright (c) 2018 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
@@ -176,6 +177,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Index1] != ' ' ) &&
 (String[Index1] != '\t') &&
+(String[Index1] != '\r') &&
 (String[Index1] != '\n')) {
   break;
 }
@@ -193,6 +195,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Length - 1 - Index1] != ' ' ) &&
 (String[Length - 1 - Index1] != '\t') &&
+(String[Length - 1 - Index1] != '\r') &&
 (String[Length - 1 - Index1] != '\n')) {
   break;
 }
-- 
2.7.4

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

Re: [edk2] [Patch v1 1/1] BaseTools: Move Identification file to Eot

2018-11-27 Thread Carsey, Jaben

Poke.  Any comments on this one?

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jaben Carsey
> Sent: Friday, November 16, 2018 7:42 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [Patch v1 1/1] BaseTools: Move Identification file to Eot
> Importance: High
> 
> Move the Identification file.
> This file is only ever imported into the Eot tool.
> 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jaben Carsey 
> ---
>  BaseTools/Source/Python/{Common => Eot}/Identification.py | 0
>  BaseTools/Source/Python/Eot/InfParserLite.py  | 3 ++-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/Python/Common/Identification.py
> b/BaseTools/Source/Python/Eot/Identification.py
> similarity index 100%
> rename from BaseTools/Source/Python/Common/Identification.py
> rename to BaseTools/Source/Python/Eot/Identification.py
> diff --git a/BaseTools/Source/Python/Eot/InfParserLite.py
> b/BaseTools/Source/Python/Eot/InfParserLite.py
> index c910c129a719..0cfe0398f05f 100644
> --- a/BaseTools/Source/Python/Eot/InfParserLite.py
> +++ b/BaseTools/Source/Python/Eot/InfParserLite.py
> @@ -16,11 +16,12 @@
>  #
>  from __future__ import print_function
>  from __future__ import absolute_import
> +
>  import Common.LongFilePathOs as os
>  import Common.EdkLogger as EdkLogger
>  from Common.DataType import *
>  from CommonDataClass.DataClass import *
> -from Common.Identification import *
> +from Eot.Identification import Identification
>  from Common.StringUtils import *
>  from Eot.Parser import *
>  from Eot import Database
> --
> 2.16.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v1 1/1] BaseTools: create and use a standard shared variable for '*'

2018-11-27 Thread Carsey, Jaben

Poke.  Any comments on this one?

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jaben Carsey
> Sent: Friday, November 16, 2018 7:40 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [Patch v1 1/1] BaseTools: create and use a standard shared
> variable for '*'
> Importance: High
> 
> add a variable for the string '*' and then use it instead of lots of '*'
> 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jaben Carsey 
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py | 54 ++---
> ---
>  BaseTools/Source/Python/AutoGen/BuildEngine.py | 10 ++--
>  BaseTools/Source/Python/BPDG/GenVpd.py | 14 ++---
>  BaseTools/Source/Python/Common/DataType.py |  1 +
>  BaseTools/Source/Python/Common/Expression.py   |  4 +-
>  BaseTools/Source/Python/Common/Misc.py |  2 +-
>  BaseTools/Source/Python/Common/ToolDefClassObject.py   | 23 +
>  BaseTools/Source/Python/Common/VpdInfoFile.py  |  8 +--
>  BaseTools/Source/Python/GenFds/FdfParser.py|  5 +-
>  BaseTools/Source/Python/GenFds/GenFds.py   |  2 +-
>  BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py |  8 +--
>  BaseTools/Source/Python/GenFds/Section.py  |  2 +-
>  BaseTools/Source/Python/Workspace/DscBuildData.py  |  6 +--
>  13 files changed, 70 insertions(+), 69 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index f3560bfc787d..25417c447061 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -1438,7 +1438,7 @@ class PlatformAutoGen(AutoGen):
>  PcdValue = Sku.DefaultValue
>  if PcdValue == "":
>  PcdValue  = Pcd.DefaultValue
> -if Sku.VpdOffset != '*':
> +if Sku.VpdOffset != TAB_STAR:
>  if PcdValue.startswith("{"):
>  Alignment = 8
>  elif PcdValue.startswith("L"):
> @@ -1462,7 +1462,7 @@ class PlatformAutoGen(AutoGen):
>  VpdFile.Add(Pcd, SkuName, Sku.VpdOffset)
>  SkuValueMap[PcdValue].append(Sku)
>  # if the offset of a VPD is *, then it need to be 
> fixed up by third
> party tool.
> -if not NeedProcessVpdMapFile and Sku.VpdOffset == 
> "*":
> +if not NeedProcessVpdMapFile and Sku.VpdOffset ==
> TAB_STAR:
>  NeedProcessVpdMapFile = True
>  if self.Platform.VpdToolGuid is None or
> self.Platform.VpdToolGuid == '':
>  EdkLogger.error("Build", FILE_NOT_FOUND, \
> @@ -1522,7 +1522,7 @@ class PlatformAutoGen(AutoGen):
>  PcdValue = Sku.DefaultValue
>  if PcdValue == "":
>  PcdValue  = DscPcdEntry.DefaultValue
> -if Sku.VpdOffset != '*':
> +if Sku.VpdOffset != TAB_STAR:
>  if PcdValue.startswith("{"):
>  Alignment = 8
>  elif PcdValue.startswith("L"):
> @@ -1545,7 +1545,7 @@ class PlatformAutoGen(AutoGen):
>  SkuValueMap[PcdValue] = []
>  VpdFile.Add(DscPcdEntry, SkuName, 
> Sku.VpdOffset)
>  SkuValueMap[PcdValue].append(Sku)
> -if not NeedProcessVpdMapFile and 
> Sku.VpdOffset == "*":
> +if not NeedProcessVpdMapFile and 
> Sku.VpdOffset ==
> TAB_STAR:
>  NeedProcessVpdMapFile = True
>  if DscPcdEntry.DatumType == TAB_VOID and
> PcdValue.startswith("L"):
>  UnicodePcdArray.add(DscPcdEntry)
> @@ -1573,7 +1573,7 @@ class PlatformAutoGen(AutoGen):
>  if os.path.exists(VpdMapFilePath):
>  VpdFile.Read(VpdMapFilePath)
> 
> -# Fixup "*" offset
> +# Fixup TAB_STAR offset
>  for pcd in VpdSkuMap:
>  vpdinfo = VpdFile.GetVpdInfo(pcd)
>  if vpdinfo is None:
> @@ -2210,15 +2210,15 @@ class PlatformAutoGen(AutoGen):
>  def CalculatePriorityValue(self, Key):
>  Target, ToolChain, Arch, CommandType, Attr = Key.split('_')
>  PriorityValue = 0x1
> -if Target == "*":
> +if Target == TAB_STAR:
>

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 18:26, Laszlo Ersek  wrote:
>
> On 11/27/18 15:54, Ard Biesheuvel wrote:
> > Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
> > entire virtual address space is mapped with EFI_MEMORY_UC attributes,
> > regardless of whether any devices actually reside there.
> >
> > Now that we are relaxing the address space limit to more than 40 bits,
> > mapping all that address space actually takes up more space in page
> > tables than we have so far made available as temporary RAM. So let's
> > get rid of the mapping rather than increasing the available RAM, given
> > that the mapping is not particularly useful anyway.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 17 
> > +
> >  1 file changed, 5 insertions(+), 12 deletions(-)
> >
> > diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c 
> > b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> > index 815ca145b644..70863abb2e7b 100644
> > --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> > +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> > @@ -73,21 +73,14 @@ ArmVirtGetMemoryMap (
> >VirtualMemoryTable[1].Length   = VirtualMemoryTable[0].PhysicalBase;
> >VirtualMemoryTable[1].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >
> > -  // Peripheral space after DRAM
> > -  VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length + 
> > VirtualMemoryTable[1].Length;
> > -  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
> > -  VirtualMemoryTable[2].Length   = TopOfAddressSpace -
> > -   VirtualMemoryTable[2].PhysicalBase;
> > -  VirtualMemoryTable[2].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > -
> >// Remap the FD region as normal executable memory
> > -  VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> > -  VirtualMemoryTable[3].VirtualBase  = VirtualMemoryTable[3].PhysicalBase;
> > -  VirtualMemoryTable[3].Length   = FixedPcdGet32 (PcdFdSize);
> > -  VirtualMemoryTable[3].Attributes   = 
> > ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> > +  VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> > +  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
> > +  VirtualMemoryTable[2].Length   = FixedPcdGet32 (PcdFdSize);
> > +  VirtualMemoryTable[2].Attributes   = 
> > ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> >
> >// End of Table
> > -  ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
> > +  ZeroMem ([3], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
> >
> >*VirtualMemoryMap = VirtualMemoryTable;
> >  }
> >
>
> (1) This supplants your other series "[PATCH v2 00/13] ArmPkg, ArmVirtPkg: 
> lift 40-bit IPA space limit" minimally due to a contextual conflict; is that 
> right?
>

Not quite. It complements it, in the sense that is should fix the
issue reported by Eric when mapping the entire address 48-bit address
space.

> (2) Regarding the patch itself. Currently we have:
>
> - VirtualMemoryTable[0]: "System DRAM"
> - VirtualMemoryTable[1]: "Peripheral space before DRAM"
> - VirtualMemoryTable[2]: "Peripheral space after DRAM"
> - VirtualMemoryTable[3]: "Remap the FD region as normal executable
>   memory"
>
> Let's see what is affected, from the physical map in QEMU's "hw/arm/virt.c", 
> if we evict VirtualMemoryTable[2]:
>
> /* Additional 64 MB redist region (can contain up to 512 redistributors) 
> */
> [VIRT_GIC_REDIST2] ={ 0x40ULL, 0x400 },
> [VIRT_PCIE_ECAM_HIGH] = { 0x401000ULL, 0x1000 },
> /* Second PCIe window, 512GB wide at the 512GB boundary */
> [VIRT_PCIE_MMIO_HIGH] =   { 0x80ULL, 0x80ULL },
>
> I have no idea about VIRT_GIC_REDIST2, but, given that in ArmVirtQemu we do 
> uniprocessor only, it doesn't seem worrisome.
>

The GICv3 architecture permits redistributors (one for each CPU) to be
non-contiguous in physical memory. Some multi-socket systems make use
of this.

In ArmVirtQemu (or actually, in EDK2 in general) we assume that the
boot CPU's redistributor is in the primary redistributor region, so
this region can indeed be disregarded.

> VIRT_PCIE_ECAM_HIGH should be handled by patch #1. (VIRT_PCIE_ECAM_HIGH 
> *replaces* [VIRT_PCIE_ECAM] = { 0x3f00, 0x0100 }, if memory serves.)
>
> VIRT_PCIE_MMIO_HIGH is *in addition* to [VIRT_PCIE_MMIO] = { 0x1000, 
> 0x2eff }, but we need not do anything about that specifically, because we 
> advertize it to PciHostBridgeDxe via our FdtPciHostBridgeLib instance, and 
> PciHostBridgeDxe handles the GCD aspects for the range automatically.
>
> So, together with patch #1, I think this is safe. If we catch a data abort 
> anyway, we'll have to clean up the GCD handling in other drivers.
>
> Reviewed-by:

[edk2] [PATCH 1/2] [edk2-test][PATCH v3] SctPkg/build: Add support for GenBin tool build

2018-11-27 Thread Lokesh B V

As the GenBin tool is necessary for SCT build, it is appropriate to
support it's build in the SCT build procedure.

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Lokesh B V 
---
 .gitignore   |  1 +
 uefi-sct/SctPkg/build.sh | 33 -
 2 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 821ed66..3b8d818 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Build/
 tags/
+*.[od]
diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
index 73581c9..92e52c6 100755
--- a/uefi-sct/SctPkg/build.sh
+++ b/uefi-sct/SctPkg/build.sh
@@ -1,7 +1,7 @@
 #!/bin/bash
 #
 #  Copyright 2006 - 2015 Unified EFI, Inc.
-#  Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved.
+#  Copyright (c) 2011 - 2018, 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
@@ -228,21 +228,28 @@ else
   echo using prebuilt tools
 fi
 
-# Copy GenBin file to Base tools directory
+if  [[ ! -e $EDK_TOOLS_PATH/Source/C/bin/GenBin ]]
+then
+  # build the GenBin if it doesn't yet exist
+  echo Building GenBin
+  make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin
+  status=$?
+  if test $status -ne 0
+  then
+  echo Error while building GenBin
+exit -1
+  fi
+else
+  echo using prebuilt GenBin
+fi
+
+# Copy GenBin file to Base tools bin directory
 DEST_DIR=`GetEdkToolsPathBinDirectory`
 # Ensure the directory exist
 mkdir -p $DEST_DIR
-case `uname -m` in 
-   x86_64)
-   cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin
-   ;;
-   x86_32)
-   cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
-   ;;
-   *)
-   cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
-   ;;
-esac
+cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin
+# Clean the intermediate binary file
+rm -f $EDK_TOOLS_PATH/Source/C/bin/GenBin
 
 #
 # Build the SCT package
-- 
2.7.4

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

Re: [edk2] [PATCH v2 1/2] ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 18:40, Laszlo Ersek  wrote:
>
> On 11/27/18 15:54, Ard Biesheuvel wrote:
> > Up until now, we have been getting away with not declaring the ECAM
> > and translated I/O spaces at all in the GCD memory map, simply because
> > we map the entire address space with device attributes in the early PEI
> > code, and so these regions will be mapped wherever they end up.
> >
> > Now that we are about to make changes to how ArmVirtQemu reasons
> > about the size of the address space, it would be better to get rid
> > of this mapping of the entire address space, since it can get
> > arbitrarily large without real benefit.
> >
> > So start by mapping the ECAM and translated I/O spaces explicitly,
> > instead of relying on the early PEI mapping.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf |  1 +
> >  ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c   | 46 
> > +++-
> >  2 files changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf 
> > b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> > index 0995f4b7a156..4011336a353b 100644
> > --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> > +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> > @@ -42,6 +42,7 @@ [Packages]
> >  [LibraryClasses]
> >DebugLib
> >DevicePathLib
> > +  DxeServicesTableLib
> >MemoryAllocationLib
> >PciPcdProducerLib
> >
> > diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c 
> > b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> > index 5b9c887db35d..ba177353122e 100644
> > --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> > +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> > @@ -17,6 +17,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -82,6 +83,33 @@ typedef struct {
> >  #define DTB_PCI_HOST_RANGE_IO   BIT24
> >  #define DTB_PCI_HOST_RANGE_TYPEMASK (BIT31 | BIT30 | BIT29 | BIT25 | 
> > BIT24)
> >
> > +STATIC
> > +EFI_STATUS
> > +MapGcdMmioSpace (
> > +  INUINT64Base,
> > +  INUINT64Size
> > +  )
> > +{
> > +  EFI_STATUSStatus;
> > +
> > +  Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, Base, Size,
> > +  EFI_MEMORY_UC);
> > +  if (EFI_ERROR (Status)) {
> > +DEBUG ((DEBUG_WARN,
> > +  "%a: failed to add GCD memory space for region [0x%Lx+0x%Lx)\n",
> > +  __FUNCTION__, Base, Size));
> > +return Status;
> > +  }
> > +
> > +  Status = gDS->SetMemorySpaceAttributes (Base, Size, EFI_MEMORY_UC);
> > +  if (EFI_ERROR (Status)) {
> > +DEBUG ((DEBUG_WARN,
> > +  "%a: failed to set memory space attributes for region 
> > [0x%Lx+0x%Lx)\n",
> > +  __FUNCTION__, Base, Size));
> > +  }
> > +  return Status;
> > +}
>
> (1) Given that these failures will quite directly trigger assertions
> (which print messages even in such builds that filter out everything
> except DEBUG_ERROR), I wonder if we should use DEBUG_ERROR here.
>
> Anyway, just an idea, up to you.
>

Yeah that makes sense

> > +
> >  STATIC
> >  EFI_STATUS
> >  ProcessPciHost (
> > @@ -266,7 +294,23 @@ ProcessPciHost (
> >  "Io[0x%Lx+0x%Lx)@0x%Lx Mem32[0x%Lx+0x%Lx)@0x0 
> > Mem64[0x%Lx+0x%Lx)@0x0\n",
> >  __FUNCTION__, ConfigBase, ConfigSize, *BusMin, *BusMax, *IoBase, 
> > *IoSize,
> >  IoTranslation, *Mmio32Base, *Mmio32Size, *Mmio64Base, *Mmio64Size));
> > -  return EFI_SUCCESS;
> > +
> > +  // Map the ECAM space in the GCD memory map
> > +  Status = MapGcdMmioSpace (ConfigBase, ConfigSize);
> > +  ASSERT_EFI_ERROR (Status);
> > +  if (EFI_ERROR (Status)) {
> > +return Status;
> > +  }
> > +
> > +  //
> > +  // Map the MMIO window that provides I/O access - the PCI host bridge 
> > code
> > +  // is not aware of this translation and so it will only map the I/O view
> > +  // in the GCD I/O map.
> > +  //
> > +  Status = MapGcdMmioSpace (IoTranslation, *IoSize);
>
> (2) I think using IoTranslation as base address is incorrect here. I
> reviewed the explanation in "ArmPkg/ArmPkg.dec", and also the rest of
> the code in this function (which matches the DEC's specification). Thus,
> I think you need, for the CPU view, (*IoBase + IoTranslation), as first
> argument.
>
> (I do agree that the DEBUG message right at the end of the function
> could be misleading; it prints
>
>   Io[0x%Lx+0x%Lx)@0x%Lx
>
> from
>
>   *IoBase, *IoSize, IoTranslation
> )
>

Indeed. Well spotted.

> > +  ASSERT_EFI_ERROR (Status);
> > +
> > +  return Status;
> >  }
> >
> >  STATIC PCI_ROOT_BRIDGE mRootBridge;
> >
>
> With (2) fixed:
>
> Reviewed-by: Laszlo Ersek 
>

Thanks.
___
edk2-devel mailing list

Re: [edk2] [PATCH v2 1/2] ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map

2018-11-27 Thread Laszlo Ersek

On 11/27/18 15:54, Ard Biesheuvel wrote:
> Up until now, we have been getting away with not declaring the ECAM
> and translated I/O spaces at all in the GCD memory map, simply because
> we map the entire address space with device attributes in the early PEI
> code, and so these regions will be mapped wherever they end up.
> 
> Now that we are about to make changes to how ArmVirtQemu reasons
> about the size of the address space, it would be better to get rid
> of this mapping of the entire address space, since it can get
> arbitrarily large without real benefit.
> 
> So start by mapping the ECAM and translated I/O spaces explicitly,
> instead of relying on the early PEI mapping.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf |  1 +
>  ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c   | 46 
> +++-
>  2 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf 
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> index 0995f4b7a156..4011336a353b 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> @@ -42,6 +42,7 @@ [Packages]
>  [LibraryClasses]
>DebugLib
>DevicePathLib
> +  DxeServicesTableLib
>MemoryAllocationLib
>PciPcdProducerLib
>  
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c 
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> index 5b9c887db35d..ba177353122e 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -82,6 +83,33 @@ typedef struct {
>  #define DTB_PCI_HOST_RANGE_IO   BIT24
>  #define DTB_PCI_HOST_RANGE_TYPEMASK (BIT31 | BIT30 | BIT29 | BIT25 | 
> BIT24)
>  
> +STATIC
> +EFI_STATUS
> +MapGcdMmioSpace (
> +  INUINT64Base,
> +  INUINT64Size
> +  )
> +{
> +  EFI_STATUSStatus;
> +
> +  Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, Base, Size,
> +  EFI_MEMORY_UC);
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_WARN,
> +  "%a: failed to add GCD memory space for region [0x%Lx+0x%Lx)\n",
> +  __FUNCTION__, Base, Size));
> +return Status;
> +  }
> +
> +  Status = gDS->SetMemorySpaceAttributes (Base, Size, EFI_MEMORY_UC);
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_WARN,
> +  "%a: failed to set memory space attributes for region [0x%Lx+0x%Lx)\n",
> +  __FUNCTION__, Base, Size));
> +  }
> +  return Status;
> +}

(1) Given that these failures will quite directly trigger assertions
(which print messages even in such builds that filter out everything
except DEBUG_ERROR), I wonder if we should use DEBUG_ERROR here.

Anyway, just an idea, up to you.

> +
>  STATIC
>  EFI_STATUS
>  ProcessPciHost (
> @@ -266,7 +294,23 @@ ProcessPciHost (
>  "Io[0x%Lx+0x%Lx)@0x%Lx Mem32[0x%Lx+0x%Lx)@0x0 Mem64[0x%Lx+0x%Lx)@0x0\n",
>  __FUNCTION__, ConfigBase, ConfigSize, *BusMin, *BusMax, *IoBase, *IoSize,
>  IoTranslation, *Mmio32Base, *Mmio32Size, *Mmio64Base, *Mmio64Size));
> -  return EFI_SUCCESS;
> +
> +  // Map the ECAM space in the GCD memory map
> +  Status = MapGcdMmioSpace (ConfigBase, ConfigSize);
> +  ASSERT_EFI_ERROR (Status);
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  //
> +  // Map the MMIO window that provides I/O access - the PCI host bridge code
> +  // is not aware of this translation and so it will only map the I/O view
> +  // in the GCD I/O map.
> +  //
> +  Status = MapGcdMmioSpace (IoTranslation, *IoSize);

(2) I think using IoTranslation as base address is incorrect here. I
reviewed the explanation in "ArmPkg/ArmPkg.dec", and also the rest of
the code in this function (which matches the DEC's specification). Thus,
I think you need, for the CPU view, (*IoBase + IoTranslation), as first
argument.

(I do agree that the DEBUG message right at the end of the function
could be misleading; it prints

  Io[0x%Lx+0x%Lx)@0x%Lx

from

  *IoBase, *IoSize, IoTranslation
)

> +  ASSERT_EFI_ERROR (Status);
> +
> +  return Status;
>  }
>  
>  STATIC PCI_ROOT_BRIDGE mRootBridge;
> 

With (2) fixed:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range

2018-11-27 Thread Laszlo Ersek

On 11/27/18 15:54, Ard Biesheuvel wrote:
> Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
> entire virtual address space is mapped with EFI_MEMORY_UC attributes,
> regardless of whether any devices actually reside there.
> 
> Now that we are relaxing the address space limit to more than 40 bits,
> mapping all that address space actually takes up more space in page
> tables than we have so far made available as temporary RAM. So let's
> get rid of the mapping rather than increasing the available RAM, given
> that the mapping is not particularly useful anyway.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 17 
> +
>  1 file changed, 5 insertions(+), 12 deletions(-)
> 
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c 
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> index 815ca145b644..70863abb2e7b 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> @@ -73,21 +73,14 @@ ArmVirtGetMemoryMap (
>VirtualMemoryTable[1].Length   = VirtualMemoryTable[0].PhysicalBase;
>VirtualMemoryTable[1].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>  
> -  // Peripheral space after DRAM
> -  VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length + 
> VirtualMemoryTable[1].Length;
> -  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
> -  VirtualMemoryTable[2].Length   = TopOfAddressSpace -
> -   VirtualMemoryTable[2].PhysicalBase;
> -  VirtualMemoryTable[2].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> -
>// Remap the FD region as normal executable memory
> -  VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> -  VirtualMemoryTable[3].VirtualBase  = VirtualMemoryTable[3].PhysicalBase;
> -  VirtualMemoryTable[3].Length   = FixedPcdGet32 (PcdFdSize);
> -  VirtualMemoryTable[3].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> +  VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> +  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
> +  VirtualMemoryTable[2].Length   = FixedPcdGet32 (PcdFdSize);
> +  VirtualMemoryTable[2].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>  
>// End of Table
> -  ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
> +  ZeroMem ([3], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
>  
>*VirtualMemoryMap = VirtualMemoryTable;
>  }
> 

(1) This supplants your other series "[PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 
40-bit IPA space limit" minimally due to a contextual conflict; is that right?

(2) Regarding the patch itself. Currently we have:

- VirtualMemoryTable[0]: "System DRAM"
- VirtualMemoryTable[1]: "Peripheral space before DRAM"
- VirtualMemoryTable[2]: "Peripheral space after DRAM"
- VirtualMemoryTable[3]: "Remap the FD region as normal executable
  memory"

Let's see what is affected, from the physical map in QEMU's "hw/arm/virt.c", if 
we evict VirtualMemoryTable[2]:

/* Additional 64 MB redist region (can contain up to 512 redistributors) */
[VIRT_GIC_REDIST2] ={ 0x40ULL, 0x400 },
[VIRT_PCIE_ECAM_HIGH] = { 0x401000ULL, 0x1000 },
/* Second PCIe window, 512GB wide at the 512GB boundary */
[VIRT_PCIE_MMIO_HIGH] =   { 0x80ULL, 0x80ULL },

I have no idea about VIRT_GIC_REDIST2, but, given that in ArmVirtQemu we do 
uniprocessor only, it doesn't seem worrisome.

VIRT_PCIE_ECAM_HIGH should be handled by patch #1. (VIRT_PCIE_ECAM_HIGH 
*replaces* [VIRT_PCIE_ECAM] = { 0x3f00, 0x0100 }, if memory serves.)

VIRT_PCIE_MMIO_HIGH is *in addition* to [VIRT_PCIE_MMIO] = { 0x1000, 
0x2eff }, but we need not do anything about that specifically, because we 
advertize it to PciHostBridgeDxe via our FdtPciHostBridgeLib instance, and 
PciHostBridgeDxe handles the GCD aspects for the range automatically.

So, together with patch #1, I think this is safe. If we catch a data abort 
anyway, we'll have to clean up the GCD handling in other drivers.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool

2018-11-27 Thread Lokesh Belathur Veerappa

Hi Supreeth,

The GenBin tool was not being rebuilt due to the existence of previously built 
intermediate binary. To resolve this, intermediate binary has to be cleaned 
after the build.
I will upload the new patch with the this change.

Thanks,
Lokesh

-Original Message-
From: Supreeth Venkatesh 
Sent: Tuesday, November 27, 2018 8:07 PM
To: Lokesh Belathur Veerappa 
Cc: eric@intel.com; edk2-devel@lists.01.org
Subject: RE: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending 
detection by GenBin tool

Lokesh,

I had applied the GenBin tool rebuild patch before this.
I will check again on my side but please recheck on your side.

Thanks,
Supreeth


-Original Message-
From: Lokesh Belathur Veerappa 
Sent: Tuesday, November 27, 2018 2:04 AM
To: Supreeth Venkatesh ; edk2-devel@lists.01.org; 
eric@intel.com
Subject: RE: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending 
detection by GenBin tool

Hi Supreeth,

The  'GenBin' tool has to be rebuilt with this change. The GenBin tool build 
support is added in the patch "[edk2-test][PATCH] SctPkg/build: Add support for 
GenBin tool build".
I will upload a single patch which includes both the changes. Please verify and 
merge it.

Thanks,
Lokesh

-Original Message-
From: Supreeth Venkatesh 
Sent: Tuesday, November 27, 2018 1:56 AM
To: Lokesh Belathur Veerappa ; edk2-devel@lists.01.org; 
eric@intel.com
Cc: Lokesh Belathur Veerappa 
Subject: RE: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending 
detection by GenBin tool

With the latest edk2, I am getting this compilation error (even when this patch 
is applied).
I will be looking at it tomorrow. Please check this out if you get a chance.

GenBin  
/data/users/supreeth/supven01/work/sct_workspace/edk2/SctPkg/TestCase/UEFI/EFI/Protocol/Decompress/BlackBoxTest/Dependency/UncompressedFile2/UncompressedFile2.ini
 
/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/Decompress_UncompressedFile2.ucmp
Error: Invalid format (Line 30)
Error: Cannot generate the binary file
GNUmakefile:232: recipe for target 
'/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/Decompress_UncompressedFile2.ucmp'
 failed
make: *** 
[/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/Decompress_UncompressedFile2.ucmp]
 Error 255


build.py...
 : error 7000: Failed to execute command
make tbuild 
[/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/SctPkg/TestCase/UEFI/EFI/Protocol/Decompress/BlackBoxTest/Dependency/UncompressedFile2/UncompressedFile2]

Thanks,
Supreeth

-Original Message-
From: Lokesh B V 
Sent: Tuesday, November 20, 2018 12:50 AM
To: edk2-devel@lists.01.org; Supreeth Venkatesh ; 
eric@intel.com
Cc: Lokesh Belathur Veerappa 
Subject: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending detection 
by GenBin tool

Some windows editors uses "\r\n" for line feed. While processing uefi testcase 
info file, the GenBin tool logic to skip line feed doesn't consider the 
presence of carraige return(\r) in line feed. So this results in incorrect 
format error.

Signed-off-by: Lokesh B V 
---
 uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index 61bb35b..ce271a1 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -176,6 +176,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Index1] != ' ' ) &&
 (String[Index1] != '\t') &&
+(String[Index1] != '\r') &&
 (String[Index1] != '\n')) {
   break;
 }
@@ -193,6 +194,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Length - 1 - Index1] != ' ' ) &&
 (String[Length - 1 - Index1] != '\t') &&
+(String[Length - 1 - Index1] != '\r') &&
 (String[Length - 1 - Index1] != '\n')) {
   break;
 }
--
2.7.4

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] FmpDeviceLib

2018-11-27 Thread Tomas Pilar (tpilar)

Okay, so I just noticed that FmpDxe is full of module globals including the 
image descriptor, so it necessarily requires that the driver that includes it 
as a library can only ever control one controller.

Cheers,
Tom

On 27/11/2018 15:23, Tomas Pilar (tpilar) wrote:
>
> On 27/11/2018 14:33, Gao, Liming wrote:
>> Tom:
>>   FmpDeviceLib can use UEFI driver model/driver binding protocol so it can 
>> install FMP on its device handle during the BDS/Device connection phase. It 
>> can implement RegisterFmpInstaller() to install FMP protocol in its device 
>> handle. In this way, FmpDeviceLib is like UEFI driver with UEFI driver 
>> binding protocol. 
>>
>> Thanks
>> Liming
> Hi Liming,
>
> Sure, so now I can install FMP onto my ControllerHandle. Say that someone 
> gets the FMP and calls GetImageSize. The FmpDxeLib does some checks and then 
> it calls FmpDeviceLibGetImageSize() with no context parameter. This method is 
> supposed to be implemented by me, the driver writer, but how is the code in 
> this method meant to know which Controller are we getting the image size from?
>
> So maybe I can define some module globals, declare them in a cross include 
> file, include that in my driver and and have the driver populate the module 
> globals during probe. This immediately limits the usefulness by requiring 
> that each driver only ever drives one controller.
>
> And then you consider how to do a SetImage without being even given the 
> Handle of the Controller. Do you stuff the controller handle into a module 
> global parameter that gets populated during the BDS phase?
>
> I guess you could enumerate all FMP instances, see which one of them 
> advertises your ImageTypeId and get the handle that the FMP is installed on 
> that way. But that seems rather insane and would cause issues if you have two 
> of the same device in the platform, unless you check the HardwareInstance as 
> well? This seems insane.
>
> Cheers,
> Tom
>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Tomas Pilar (tpilar)
>>> Sent: Tuesday, November 27, 2018 9:26 PM
>>> To: edk2-devel@lists.01.org
>>> Subject: [edk2] FmpDeviceLib
>>>
>>> Hi all,
>>>
>>> I am looking at using FmpDxeLib so I need to implement the FmpDeviceLib. 
>>> However, it seems like the library functions do not take any
>>> private struct as a parameter, so I am struggling to figure out how to read 
>>> information off the hardware. FmpDxe does not even pass its
>>> created protocol instance when calling the library functions, leading me to 
>>> believe that the only way to do this is to assign a pointer to
>>> private struct during library construction, but that means that a driver 
>>> that uses the code can only ever service a single controller.
>>>
>>> Can you offer any insights?
>>>
>>> Cheers,
>>> Tom
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v2 1/2] ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map

2018-11-27 Thread Philippe Mathieu-Daudé

On 27/11/18 15:54, Ard Biesheuvel wrote:
> Up until now, we have been getting away with not declaring the ECAM
> and translated I/O spaces at all in the GCD memory map, simply because
> we map the entire address space with device attributes in the early PEI
> code, and so these regions will be mapped wherever they end up.
> 
> Now that we are about to make changes to how ArmVirtQemu reasons
> about the size of the address space, it would be better to get rid
> of this mapping of the entire address space, since it can get
> arbitrarily large without real benefit.
> 
> So start by mapping the ECAM and translated I/O spaces explicitly,
> instead of relying on the early PEI mapping.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf |  1 +
>  ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c   | 46 
> +++-
>  2 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf 
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> index 0995f4b7a156..4011336a353b 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> @@ -42,6 +42,7 @@ [Packages]
>  [LibraryClasses]
>DebugLib
>DevicePathLib
> +  DxeServicesTableLib
>MemoryAllocationLib
>PciPcdProducerLib
>  
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c 
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> index 5b9c887db35d..ba177353122e 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -82,6 +83,33 @@ typedef struct {
>  #define DTB_PCI_HOST_RANGE_IO   BIT24
>  #define DTB_PCI_HOST_RANGE_TYPEMASK (BIT31 | BIT30 | BIT29 | BIT25 | 
> BIT24)
>  
> +STATIC
> +EFI_STATUS
> +MapGcdMmioSpace (
> +  INUINT64Base,
> +  INUINT64Size
> +  )
> +{
> +  EFI_STATUSStatus;
> +
> +  Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, Base, Size,
> +  EFI_MEMORY_UC);
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_WARN,
> +  "%a: failed to add GCD memory space for region [0x%Lx+0x%Lx)\n",
> +  __FUNCTION__, Base, Size));
> +return Status;
> +  }
> +
> +  Status = gDS->SetMemorySpaceAttributes (Base, Size, EFI_MEMORY_UC);
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_WARN,
> +  "%a: failed to set memory space attributes for region [0x%Lx+0x%Lx)\n",
> +  __FUNCTION__, Base, Size));
> +  }
> +  return Status;
> +}
> +
>  STATIC
>  EFI_STATUS
>  ProcessPciHost (
> @@ -266,7 +294,23 @@ ProcessPciHost (
>  "Io[0x%Lx+0x%Lx)@0x%Lx Mem32[0x%Lx+0x%Lx)@0x0 Mem64[0x%Lx+0x%Lx)@0x0\n",
>  __FUNCTION__, ConfigBase, ConfigSize, *BusMin, *BusMax, *IoBase, *IoSize,
>  IoTranslation, *Mmio32Base, *Mmio32Size, *Mmio64Base, *Mmio64Size));
> -  return EFI_SUCCESS;
> +
> +  // Map the ECAM space in the GCD memory map
> +  Status = MapGcdMmioSpace (ConfigBase, ConfigSize);
> +  ASSERT_EFI_ERROR (Status);
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  //
> +  // Map the MMIO window that provides I/O access - the PCI host bridge code
> +  // is not aware of this translation and so it will only map the I/O view
> +  // in the GCD I/O map.
> +  //
> +  Status = MapGcdMmioSpace (IoTranslation, *IoSize);
> +  ASSERT_EFI_ERROR (Status);
> +
> +  return Status;
>  }
>  
>  STATIC PCI_ROOT_BRIDGE mRootBridge;
> 

LGTM:
Reviewed-by: Philippe Mathieu-Daudé 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] FmpDeviceLib

2018-11-27 Thread Tomas Pilar (tpilar)

On 27/11/2018 14:33, Gao, Liming wrote:
> Tom:
>   FmpDeviceLib can use UEFI driver model/driver binding protocol so it can 
> install FMP on its device handle during the BDS/Device connection phase. It 
> can implement RegisterFmpInstaller() to install FMP protocol in its device 
> handle. In this way, FmpDeviceLib is like UEFI driver with UEFI driver 
> binding protocol. 
>
> Thanks
> Liming
Hi Liming,

Sure, so now I can install FMP onto my ControllerHandle. Say that someone gets 
the FMP and calls GetImageSize. The FmpDxeLib does some checks and then it 
calls FmpDeviceLibGetImageSize() with no context parameter. This method is 
supposed to be implemented by me, the driver writer, but how is the code in 
this method meant to know which Controller are we getting the image size from?

So maybe I can define some module globals, declare them in a cross include 
file, include that in my driver and and have the driver populate the module 
globals during probe. This immediately limits the usefulness by requiring that 
each driver only ever drives one controller.

And then you consider how to do a SetImage without being even given the Handle 
of the Controller. Do you stuff the controller handle into a module global 
parameter that gets populated during the BDS phase?

I guess you could enumerate all FMP instances, see which one of them advertises 
your ImageTypeId and get the handle that the FMP is installed on that way. But 
that seems rather insane and would cause issues if you have two of the same 
device in the platform, unless you check the HardwareInstance as well? This 
seems insane.

Cheers,
Tom

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas 
>> Pilar (tpilar)
>> Sent: Tuesday, November 27, 2018 9:26 PM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] FmpDeviceLib
>>
>> Hi all,
>>
>> I am looking at using FmpDxeLib so I need to implement the FmpDeviceLib. 
>> However, it seems like the library functions do not take any
>> private struct as a parameter, so I am struggling to figure out how to read 
>> information off the hardware. FmpDxe does not even pass its
>> created protocol instance when calling the library functions, leading me to 
>> believe that the only way to do this is to assign a pointer to
>> private struct during library construction, but that means that a driver 
>> that uses the code can only ever service a single controller.
>>
>> Can you offer any insights?
>>
>> Cheers,
>> Tom
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [Patch] Edk2: Update FmpDevicePkg Maintainers

2018-11-27 Thread Philippe Mathieu-Daudé

Hi,

On 27/11/18 15:59, Liming Gao wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Star Zeng 

The usual workflow to hand over is the previous maintainer send the
patch, and you Ack-by it.
Exceptions are acceptable but require an explanation in the commit message.

Regards,

Phil.

> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 9a36f0232b..91a4657adc 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -133,7 +133,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git
>  
>  FmpDevicePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> -M: Star Zeng 
> +M: Liming Gao 
>  M: Michael D Kinney 
>  
>  IntelFrameworkModulePkg
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Display Architecture and Bring Up in UEFI

2018-11-27 Thread prabin ca

Thanks Ruiyu, for confirming.

> On 27-Nov-2018, at 7:15 AM, Ni, Ruiyu  wrote:
> 
>> On 11/23/2018 5:19 PM, Laszlo Ersek wrote:
>>> On 11/23/18 07:27, prabin ca wrote:
>>> Hi Team,
>>> 
>>> I’m new to UEFI and display interface in UEFI. I would like to have deep 
>>> dive into how display is working in UEFI (display architecture) and how 
>>> display is have been bring up (porting of display panel in a any platform 
>>> in general ).
>>> 
>>> Please help me with sample codes and necessary documents. I would like to 
>>> get knowledge about display bring up and display architecture in UEFI
>> The driver writers' guide and the UEFI spec have relevant chapters on
>> this. I think it's best to start reading the former, at "23 Graphics
>> Driver Design Guidelines"; that part will give you the pointers to the
>> rest as well.
>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>> For a (hopefully educational) example, I refer you to
>> OvmfPkg/VirtioGpuDxe. In the series that first added this driver to
>> edk2, I managed to construct the driver in stages such that each stage
>> would build and even function, at the level expected from that stage. In
>> particular, commit a2a4fa66701d ("OvmfPkg/VirtioGpuDxe: introduce with
>> Component Name 2 and Driver Binding", 2016-09-01) could prove helpful,
>> as it adds the skeleton of the driver, mostly without VirtIo GPU specifics.
>> In addition, you might want to look into the generic
>>   MdeModulePkg/Universal/Console/GraphicsOutputDxe
>> driver. A platform may be able to incorporate that driver without any
>> changes, and control it by first producing the two HOBs in the PEI phase
>> that the driver consumes:
>>   MdePkg/Include/Guid/GraphicsInfoHob.h
>> (... Interestingly, due to the fact that this header file is under
>> MdePkg and not MdeModulePkg, I've just learned, from the related commit
>> messages, that the PEI phase has standardized graphics support,
>> described in the PI spec. From the following two commit messages:
>> - 697c6cf32693 ("MdePkg: Add PI 1.4 Graphics HOB and PPI header files",
>> 2015-04-28)
>> - 2af538fbf667 ("MdeModulePkg: Add GraphicsOutputDxe driver.", 2016-10-12)
>> it appears that enabling graphics support in the PEI phase could be a
>> *requirement* for using GraphicsOutputDxe in the DXE phase. That might
>> or might not match your use case, so perhaps it will prevent you from
>> using GraphicsOutputDxe. I'm not sure.)
> 
> Yes. GraphicsOutputDxe layers on the HOB produced in PEI phase to provide GOP 
> protocol.
> 
> 
>> Thanks
>> Laszlo
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 
> -- 
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] Edk2: Update FmpDevicePkg Maintainers

2018-11-27 Thread Liming Gao

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
Cc: Star Zeng 
---
 Maintainers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 9a36f0232b..91a4657adc 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -133,7 +133,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git
 
 FmpDevicePkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
-M: Star Zeng 
+M: Liming Gao 
 M: Michael D Kinney 
 
 IntelFrameworkModulePkg
-- 
2.13.0.windows.1

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

[edk2] [PATCH v2 0/2] ArmVirtPkg: remove high peripheral space mapping

2018-11-27 Thread Ard Biesheuvel

Stop mapping the entire address space in the early PEI code. This
wastes temporary RAM on page tables, and encourages sloppy coding
when it comes to populating the GCD memory map.

Cc: Laszlo Ersek 
Cc: Eric Auger 
Cc: Andrew Jones 
Cc: Philippe Mathieu-Daude 

Ard Biesheuvel (2):
  ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory
map
  ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range

 .../FdtPciHostBridgeLib.inf   |  1 +
 .../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c | 46 ++-
 .../QemuVirtMemInfoLib/QemuVirtMemInfoLib.c   | 17 ++-
 3 files changed, 51 insertions(+), 13 deletions(-)

-- 
2.19.1

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

[edk2] [PATCH v2 1/2] ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map

2018-11-27 Thread Ard Biesheuvel

Up until now, we have been getting away with not declaring the ECAM
and translated I/O spaces at all in the GCD memory map, simply because
we map the entire address space with device attributes in the early PEI
code, and so these regions will be mapped wherever they end up.

Now that we are about to make changes to how ArmVirtQemu reasons
about the size of the address space, it would be better to get rid
of this mapping of the entire address space, since it can get
arbitrarily large without real benefit.

So start by mapping the ECAM and translated I/O spaces explicitly,
instead of relying on the early PEI mapping.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf |  1 +
 ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c   | 46 
+++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf 
b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
index 0995f4b7a156..4011336a353b 100644
--- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
+++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
@@ -42,6 +42,7 @@ [Packages]
 [LibraryClasses]
   DebugLib
   DevicePathLib
+  DxeServicesTableLib
   MemoryAllocationLib
   PciPcdProducerLib
 
diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c 
b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
index 5b9c887db35d..ba177353122e 100644
--- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
+++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -82,6 +83,33 @@ typedef struct {
 #define DTB_PCI_HOST_RANGE_IO   BIT24
 #define DTB_PCI_HOST_RANGE_TYPEMASK (BIT31 | BIT30 | BIT29 | BIT25 | BIT24)
 
+STATIC
+EFI_STATUS
+MapGcdMmioSpace (
+  INUINT64Base,
+  INUINT64Size
+  )
+{
+  EFI_STATUSStatus;
+
+  Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, Base, Size,
+  EFI_MEMORY_UC);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN,
+  "%a: failed to add GCD memory space for region [0x%Lx+0x%Lx)\n",
+  __FUNCTION__, Base, Size));
+return Status;
+  }
+
+  Status = gDS->SetMemorySpaceAttributes (Base, Size, EFI_MEMORY_UC);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN,
+  "%a: failed to set memory space attributes for region [0x%Lx+0x%Lx)\n",
+  __FUNCTION__, Base, Size));
+  }
+  return Status;
+}
+
 STATIC
 EFI_STATUS
 ProcessPciHost (
@@ -266,7 +294,23 @@ ProcessPciHost (
 "Io[0x%Lx+0x%Lx)@0x%Lx Mem32[0x%Lx+0x%Lx)@0x0 Mem64[0x%Lx+0x%Lx)@0x0\n",
 __FUNCTION__, ConfigBase, ConfigSize, *BusMin, *BusMax, *IoBase, *IoSize,
 IoTranslation, *Mmio32Base, *Mmio32Size, *Mmio64Base, *Mmio64Size));
-  return EFI_SUCCESS;
+
+  // Map the ECAM space in the GCD memory map
+  Status = MapGcdMmioSpace (ConfigBase, ConfigSize);
+  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  //
+  // Map the MMIO window that provides I/O access - the PCI host bridge code
+  // is not aware of this translation and so it will only map the I/O view
+  // in the GCD I/O map.
+  //
+  Status = MapGcdMmioSpace (IoTranslation, *IoSize);
+  ASSERT_EFI_ERROR (Status);
+
+  return Status;
 }
 
 STATIC PCI_ROOT_BRIDGE mRootBridge;
-- 
2.19.1

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

[edk2] [PATCH v2 2/2] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range

2018-11-27 Thread Ard Biesheuvel

Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
entire virtual address space is mapped with EFI_MEMORY_UC attributes,
regardless of whether any devices actually reside there.

Now that we are relaxing the address space limit to more than 40 bits,
mapping all that address space actually takes up more space in page
tables than we have so far made available as temporary RAM. So let's
get rid of the mapping rather than increasing the available RAM, given
that the mapping is not particularly useful anyway.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 17 
+
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c 
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
index 815ca145b644..70863abb2e7b 100644
--- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
@@ -73,21 +73,14 @@ ArmVirtGetMemoryMap (
   VirtualMemoryTable[1].Length   = VirtualMemoryTable[0].PhysicalBase;
   VirtualMemoryTable[1].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
 
-  // Peripheral space after DRAM
-  VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length + 
VirtualMemoryTable[1].Length;
-  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
-  VirtualMemoryTable[2].Length   = TopOfAddressSpace -
-   VirtualMemoryTable[2].PhysicalBase;
-  VirtualMemoryTable[2].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-
   // Remap the FD region as normal executable memory
-  VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
-  VirtualMemoryTable[3].VirtualBase  = VirtualMemoryTable[3].PhysicalBase;
-  VirtualMemoryTable[3].Length   = FixedPcdGet32 (PcdFdSize);
-  VirtualMemoryTable[3].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+  VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
+  VirtualMemoryTable[2].VirtualBase  = VirtualMemoryTable[2].PhysicalBase;
+  VirtualMemoryTable[2].Length   = FixedPcdGet32 (PcdFdSize);
+  VirtualMemoryTable[2].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
 
   // End of Table
-  ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
+  ZeroMem ([3], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
 
   *VirtualMemoryMap = VirtualMemoryTable;
 }
-- 
2.19.1

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

Re: [edk2] [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits

2018-11-27 Thread Laszlo Ersek

On 11/27/18 13:27, Ard Biesheuvel wrote:
> AArch64 support the use of more than 48 bits for physical and/or
> virtual addressing, but only if the page size is set to 64 KB,
> which is not supported by UEFI/EDK2. So redefine MAX_ADDRESS to
> cover only 48 address bits.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdePkg/Include/AArch64/ProcessorBind.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/AArch64/ProcessorBind.h 
> b/MdePkg/Include/AArch64/ProcessorBind.h
> index 968c18f915ae..dad75df1c579 100644
> --- a/MdePkg/Include/AArch64/ProcessorBind.h
> +++ b/MdePkg/Include/AArch64/ProcessorBind.h
> @@ -138,9 +138,9 @@ typedef INT64   INTN;
>  #define MAX_2_BITS  0xC000ULL
>  
>  ///
> -/// Maximum legal AARCH64  address
> +/// Maximum legal AARCH64  address (48 bits for 4 KB page size)
>  ///
> -#define MAX_ADDRESS   0xULL
> +#define MAX_ADDRESS   0xULL
>  
>  ///
>  /// Maximum legal AArch64 INTN and UINTN values.
> 

H. I'm worried about this change. I think it could open a can of
worms. I have no clue what *all* the things are that we use MAX_ADDRESS
for. Does it give the maximum value of the canonical address *format*?
Or is it the maximum address that the processor could ever access?

Let's look at the X64 situation... For X64, MAX_ADDRESS is
0x____ULL (MdePkg/Include/X64/ProcessorBind.h). However,
on X64, even considering the recently introduced 5-level paging
, the "useful"
number of address bits is up to just 57 -- it used to be 48, with
4-level paging. That is: not 64. Yet we have MAX_UINT64 for MAX_ADDRESS!

Which in turn means that, with X64 5-level paging in mind, the issue
affects X64 as well -- there could be RAM in the system that the 64-bit
DXE phase couldn't access (because edk2 doesn't support 5-level paging,
AIUI), but the OS could.

That officially turns the question into a multi-architectural one: how
should the UEFI memmap describe the highest RAM range, such that it be
exposed to the OS, but not exposed to the firmware itself? (Because, the
firmware doesn't support the necessary paging mode, or processor mode.)

Liming, can you share what Intel plans, in edk2, for supporting 5-level
paging?

And, on such physical X64 systems today that support 57-bit paging, how
does the UEFI memmap describe the [2^48 .. 2^57) RAM?

And how does the firmware allocate and use memory from that area?

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

Re: [edk2] [PATCH v2 01/13] ArmPkg/ArmLib: add support for reading the max physical address space size

2018-11-27 Thread Auger Eric

Hi,

On 11/26/18 11:37 PM, Ard Biesheuvel wrote:
> Add a helper function that returns the maximum physical address space
> size as supported by the current CPU.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Include/Library/ArmLib.h   | 17 +
>  ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 16 
>  ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S |  8 
>  3 files changed, 41 insertions(+)
> 
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index ffda50e9d767..b22879fe6e94 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -29,6 +29,17 @@
>  #define EFI_MEMORY_CACHETYPE_MASK   (EFI_MEMORY_UC | EFI_MEMORY_WC | \
>   EFI_MEMORY_WT | EFI_MEMORY_WB | \
>   EFI_MEMORY_UCE)
> +//
> +// ARM_MMU_IDMAP_RANGE defines the maximum size of the identity mapping
> +// that covers the entire address space when running in UEFI. This is
> +// limited to what can architecturally be mapped using a 4 KB granule,
> +// even if the hardware is capable of mapping more using larger pages.
> +//
> +#ifdef MDE_CPU_ARM
> +#define ARM_MMU_IDMAP_RANGE (1ULL << 32)
> +#else
> +#define ARM_MMU_IDMAP_RANGE (1ULL << 48)
> +#endif
>  
>  /**
>   * The UEFI firmware must not use the 
> ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_* attributes.
> @@ -733,4 +744,10 @@ ArmWriteCntvOff (
>UINT64   Val
>);
>  
> +UINTN
> +EFIAPI
> +ArmGetPhysicalAddressBits (
> +  VOID
> +  );
> +
>  #endif // __ARM_LIB__
> diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S 
> b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S
> index 1ef2f61f5979..7332601241aa 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S
> +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S
> @@ -196,4 +196,20 @@ ASM_FUNC(ArmWriteSctlr)
>  3:msr   sctlr_el3, x0
>  4:ret
>  
> +ASM_FUNC(ArmGetPhysicalAddressBits)
> +  mrs   x0, id_aa64mmfr0_el1
> +  adr   x1, .LPARanges
> +  and   x0, x0, #7
> +  ldrb  w0, [x1, x0]
> +  ret
> +
> +//
> +// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
> +// physical address space support on this CPU:
> +// 0 == 32 bits, 1 == 36 bits, etc etc
> +// 6 and 7 are reserved
> +//
> +.LPARanges:
> +  .byte 32, 36, 40, 42, 44, 48, 52, -1
> +
>  ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S 
> b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S
> index f2a517671f0a..f2f3c9a25991 100644
> --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S
> +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S
> @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr)
>isb
>bx  lr
>  
> +ASM_FUNC (ArmGetPhysicalAddressBits)
> +  mrc p15, 0, r0, c0, c1, 4   // MMFR0
> +  and r0, r0, #0xf// VMSA [3:0]
> +  cmp r0, #5  // >5 implies LPAE support
nit: >= 5 in the comment

Thanks

Eric
> +  movlt   r0, #32 // 32 bits if no LPAE
> +  movge   r0, #40 // 40 bits if LPAE
> +  bx  lr
> +
>  ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool

2018-11-27 Thread Supreeth Venkatesh

Lokesh,

I had applied the GenBin tool rebuild patch before this.
I will check again on my side but please recheck on your side.

Thanks,
Supreeth


-Original Message-
From: Lokesh Belathur Veerappa 
Sent: Tuesday, November 27, 2018 2:04 AM
To: Supreeth Venkatesh ; edk2-devel@lists.01.org; 
eric@intel.com
Subject: RE: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending 
detection by GenBin tool

Hi Supreeth,

The  'GenBin' tool has to be rebuilt with this change. The GenBin tool build 
support is added in the patch "[edk2-test][PATCH] SctPkg/build: Add support for 
GenBin tool build".
I will upload a single patch which includes both the changes. Please verify and 
merge it.

Thanks,
Lokesh

-Original Message-
From: Supreeth Venkatesh 
Sent: Tuesday, November 27, 2018 1:56 AM
To: Lokesh Belathur Veerappa ; edk2-devel@lists.01.org; 
eric@intel.com
Cc: Lokesh Belathur Veerappa 
Subject: RE: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending 
detection by GenBin tool

With the latest edk2, I am getting this compilation error (even when this patch 
is applied).
I will be looking at it tomorrow. Please check this out if you get a chance.

GenBin  
/data/users/supreeth/supven01/work/sct_workspace/edk2/SctPkg/TestCase/UEFI/EFI/Protocol/Decompress/BlackBoxTest/Dependency/UncompressedFile2/UncompressedFile2.ini
 
/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/Decompress_UncompressedFile2.ucmp
Error: Invalid format (Line 30)
Error: Cannot generate the binary file
GNUmakefile:232: recipe for target 
'/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/Decompress_UncompressedFile2.ucmp'
 failed
make: *** 
[/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/Decompress_UncompressedFile2.ucmp]
 Error 255


build.py...
 : error 7000: Failed to execute command
make tbuild 
[/data/users/supreeth/supven01/work/sct_workspace/edk2/Build/UefiSct/DEBUG_GCC49/AARCH64/SctPkg/TestCase/UEFI/EFI/Protocol/Decompress/BlackBoxTest/Dependency/UncompressedFile2/UncompressedFile2]

Thanks,
Supreeth

-Original Message-
From: Lokesh B V 
Sent: Tuesday, November 20, 2018 12:50 AM
To: edk2-devel@lists.01.org; Supreeth Venkatesh ; 
eric@intel.com
Cc: Lokesh Belathur Veerappa 
Subject: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending detection 
by GenBin tool

Some windows editors uses "\r\n" for line feed. While processing uefi testcase 
info file, the GenBin tool logic to skip line feed doesn't consider the 
presence of carraige return(\r) in line feed. So this results in incorrect 
format error.

Signed-off-by: Lokesh B V 
---
 uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index 61bb35b..ce271a1 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -176,6 +176,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Index1] != ' ' ) &&
 (String[Index1] != '\t') &&
+(String[Index1] != '\r') &&
 (String[Index1] != '\n')) {
   break;
 }
@@ -193,6 +194,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Length - 1 - Index1] != ' ' ) &&
 (String[Length - 1 - Index1] != '\t') &&
+(String[Length - 1 - Index1] != '\r') &&
 (String[Length - 1 - Index1] != '\n')) {
   break;
 }
--
2.7.4

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit

2018-11-27 Thread Laszlo Ersek

On 11/27/18 13:13, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 13:11, Laszlo Ersek  wrote:
>>
>> On 11/26/18 23:37, Ard Biesheuvel wrote:
>>> The ArmVirtQemu targets currently limit the size of the IPA space to
>>> 40 bits because that is all what KVM supports. However, this is about
>>> to change, and so we need to update the code if we want to ensure that
>>> our UEFI firmware builds can keep running on systems that set values
>>> other than 40 (which could be > 40 or < 40)
>>>
>>> So refactor the way we deal with this limit, both for bare metal and for
>>> virtual targets, so that
>>> a) the range of the GCD memory map is based directly on the CPU's PA range
>>> b) the range of the 1:1 mapping in the page tables is based on the CPU's PA
>>>range (unless it exceeds what the architecture permits for 4k pages)
>>> c) PcdPrePiCpuMemorySize is no longer needed, and can be removed.
>>>
>>> Patch #1 introduces ARM_MMU_IDMAP_RANGE and ArmGetPhysicalAddressBits ()
>>> in ArmLib.
>>
>> OK, so the crucial piece of info I missed under v1 was that given the
>> fixed 4KB page size under UEFI, we might not be able to identity map all
>> the memory that the CPU would otherwise be capable of addressing
>> (assuming the OS set up a larger page size).
>>
>> However... that seems to leave us with a conundrum. (I'm 100% sure it is
>> nothing new to you, but it is new to me.)
>>
>> If we size the GCD memory space map exactly to what we can identity map
>> under UEFI, then the UEFI memmap will not advertize the rest of the RAM
>> to the OS, and the memory will be unusable.
>>
>> On the other hand, if we size the GCD to the exact RAM size (part of
>> which could be out of reach for the CPU *under UEFI*, using 4KB pages),
>> then the OS will be happy. But, what happens when gBS->AllocatePages()
>> is served from such a high (>48bits) address range, and then the client
>> module tries to access the (not mapped) chunk?
>>
> 
> That is an excellent question, given that IA32 and ARM are in exactly
> the same boat with [L]PAE.

And that's an excellent observation too; I should have noticed the
parallel with at least IA32 myself!

I remember the article where Brian explains why vendors ship IA32-only
firmware on 64-bit capable Intel processors. Hm... It's here:

https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems

Obviously Linux people were never happy with that, so they worked around
it, and the kernel switches to 64-bit mode itself, AFAIK... But what
about the RAM that the 32-bit DXE phase (and firmware runtime) can't
see, but the OS can? Maybe Linux can provide some pointers here (as you
say).

[...]

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

Re: [edk2] FmpDeviceLib

2018-11-27 Thread Gao, Liming

Tom:
  FmpDeviceLib can use UEFI driver model/driver binding protocol so it can 
install FMP on its device handle during the BDS/Device connection phase. It can 
implement RegisterFmpInstaller() to install FMP protocol in its device handle. 
In this way, FmpDeviceLib is like UEFI driver with UEFI driver binding 
protocol. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas 
> Pilar (tpilar)
> Sent: Tuesday, November 27, 2018 9:26 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] FmpDeviceLib
> 
> Hi all,
> 
> I am looking at using FmpDxeLib so I need to implement the FmpDeviceLib. 
> However, it seems like the library functions do not take any
> private struct as a parameter, so I am struggling to figure out how to read 
> information off the hardware. FmpDxe does not even pass its
> created protocol instance when calling the library functions, leading me to 
> believe that the only way to do this is to assign a pointer to
> private struct during library construction, but that means that a driver that 
> uses the code can only ever service a single controller.
> 
> Can you offer any insights?
> 
> Cheers,
> Tom
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits

2018-11-27 Thread Leif Lindholm

On Tue, Nov 27, 2018 at 01:27:48PM +0100, Ard Biesheuvel wrote:
> AArch64 support the use of more than 48 bits for physical and/or

supports

> virtual addressing, but only if the page size is set to 64 KB,
> which is not supported by UEFI/EDK2. So redefine MAX_ADDRESS to

s/EDK2//

With those tweaks:
Reviewed-by: Leif Lindholm 

> cover only 48 address bits.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdePkg/Include/AArch64/ProcessorBind.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/AArch64/ProcessorBind.h 
> b/MdePkg/Include/AArch64/ProcessorBind.h
> index 968c18f915ae..dad75df1c579 100644
> --- a/MdePkg/Include/AArch64/ProcessorBind.h
> +++ b/MdePkg/Include/AArch64/ProcessorBind.h
> @@ -138,9 +138,9 @@ typedef INT64   INTN;
>  #define MAX_2_BITS  0xC000ULL
>  
>  ///
> -/// Maximum legal AARCH64  address
> +/// Maximum legal AARCH64  address (48 bits for 4 KB page size)
>  ///
> -#define MAX_ADDRESS   0xULL
> +#define MAX_ADDRESS   0xULL
>  
>  ///
>  /// Maximum legal AArch64 INTN and UINTN values.
> -- 
> 2.19.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg: fix StandaloneMmMmuLib subdirectory case

2018-11-27 Thread Leif Lindholm

On Tue, Nov 27, 2018 at 01:27:16PM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 13:26, Leif Lindholm  wrote:
> >
> > While this isn't the only Aarch64 directory in the tree, let's
> > keep from adding more of them.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm 
> 
> Acked-by: Ard Biesheuvel 

Thanks - pushed as 18a700945f.

> > ---
> >  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf | 
> > 2 +-
> >  .../StandaloneMmMmuLib/{Aarch64 => AArch64}/ArmMmuStandaloneMmLib.c | 0
> >  2 files changed, 1 insertion(+), 1 deletion(-)
> >  rename ArmPkg/Library/StandaloneMmMmuLib/{Aarch64 => 
> > AArch64}/ArmMmuStandaloneMmLib.c (100%)
> >
> > diff --git a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf 
> > b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> > index d589b23603..7219b59e6f 100644
> > --- a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> > +++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> > @@ -22,7 +22,7 @@ [Defines]
> >PI_SPECIFICATION_VERSION   = 0x00010032
> >
> >  [Sources.AARCH64]
> > -  Aarch64/ArmMmuStandaloneMmLib.c
> > +  AArch64/ArmMmuStandaloneMmLib.c
> >
> >  [Packages]
> >ArmPkg/ArmPkg.dec
> > diff --git 
> > a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c 
> > b/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
> > similarity index 100%
> > rename from 
> > ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > rename to ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
> > --
> > 2.11.0
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] FmpDeviceLib

2018-11-27 Thread Tomas Pilar (tpilar)

Hi all,

I am looking at using FmpDxeLib so I need to implement the FmpDeviceLib. 
However, it seems like the library functions do not take any private struct as 
a parameter, so I am struggling to figure out how to read information off the 
hardware. FmpDxe does not even pass its created protocol instance when calling 
the library functions, leading me to believe that the only way to do this is to 
assign a pointer to private struct during library construction, but that means 
that a driver that uses the code can only ever service a single controller.

Can you offer any insights?

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

Re: [edk2] [edk2-announce] Research Request

2018-11-27 Thread Laszlo Ersek

On 11/26/18 22:43, Jeremiah Cox via edk2-devel wrote:
> Feedback on GitHub as follows…
> 
> 
>> 1. No Lock-In - What automated data export is available?
>> We want to be able to leave and take all our data with us. "Data" here 
>> includes: review comments, pull requests / patches (including metadata), 
>> old (rejected) pull requests and metadata, issue tracker entries and 
>> comments (if issue tracker included). This archiving should be 
>> automated, not something we do by hand.
> 
> Untested, but might these all be easily satisfied by subscribing a mailing 
> list to GitHub notifications?  
> https://help.github.com/articles/about-notifications/#watching-notifications 
> https://help.github.com/articles/about-email-notifications/ 

No, they are insufficient.

Following the last link above ("about-email-notifications"), one finds
several other links; and one of those is:

https://help.github.com/articles/about-notifications/

This article says,

GitHub sends participating notifications when you're directly
involved in activities or conversations within a repository or a
team you're a member of. You'll receive a notification when:

[...]

- You open, comment on, or close an issue or pull request.

[...]

This is demonstrably false. I'm a member of the TianoCore organization,
I have commented on, and closed (rejected):

  https://github.com/tianocore/edk2/pull/133

and I *never* received an email notification about my *own* comment /
action. I only received the initial email, about the pull request being
opened (attached for reference).

* Another pull request, demonstrating the same issue (original email
also attached):

  https://github.com/tianocore/edk2/pull/127

* And here's the same problem, just in a different situation: someone
made a comment on a commit, using the github WebUI:

https://github.com/tianocore/edk2/commit/253d81c71f67e1ab218450b87370abd3bf01d571#commitcomment-27830037

I responded there. I received an email -- attached -- only about that
other person's initial comment, and never received an email about my own.

So, no. I'm already subscribed to github notofications, and their
coverage is insufficient.

> 
> Alternatively, the GitHub REST API appear to offer full export capability of 
> all information & metadata:
>https://developer.github.com/v3/git/commits/#get-a-commit 
>https://developer.github.com/v3/pulls/#list-pull-requests
>
> https://developer.github.com/v3/pulls/comments/#list-comments-on-a-pull-request
>https://developer.github.com/v3/issues/events/#list-events-for-a-repository
>https://developer.github.com/v3/issues/comments/#list-comments-on-an-issue 
>https://developer.github.com/v3/activity/events/#list-repository-events 
>
> https://developer.github.com/v3/reactions/#list-reactions-for-a-pull-request-review-comment
>  
>* the above allows you to export all of the thumbs up/down, smileys, 
> hearts ... that users have given to pull request & issue comments  :)

This is again insufficient. We shouldn't have to cobble together our own
archival soluion from low-level APIs.

GitHub has extremely good availability. I doubt that any hack we could
come up with (and that we'd have to run ourselves, elsewhere), could
muster the same service level. This means that sooner or later our
mirroring hack would go down, while GitHub would stay up, and then we'd
start losing updates to our "mirror".

The offline & full coverage audit trail has to be generated by a core
part of the service.

[...]

>> 3. Flexible Workflow - Can we use email patches / email review as well 
>> as pull requests / web UI review?**
>>   3a. Can we can attach review comments to specific code *and* commit 
>> message locations?
>>   3b. Are the comments faithfully translated to notification emails 
>> (including the locations in code the comment is addressing)?
>>   3c. Are old topic branches (rejected or updated pull requests) 
>> available even after being rejected? (i.e. are they ever deleted?)
>>   3d. Is plain text supported in code review comments?
>> **To be clear, it is acceptable if the system handles only pull requests 
>> and a web UI. We do require, however, a *read-only* email notification 
>> system that thoroughly documents our process.
> 
> We propose that all review & issue tracking are through GitHub web, REST, or 
> Graph APIs.  Email becomes read-only for notification and archival only.
> 3A:  Yes.
> 3B:  From our testing this appears to be yes.
> 3C:  GitHub can be configured to keep rejected and updated pull requests.  
> 3D:  Both plain text and markdown work

This sounds good, but can you please clarify 3C?

In particular, what does an "updated pull request" mean?

Here's the specific workflow I care about.

* Alice implements a new feature for edk2 and opens a pull request. The
pull request refers to her branch that is called "alices-grand-feature",
with the branch HEAD at commit FOO.

* Brenda reviews the commits on that branch,

Re: [edk2] [PATCH] ArmPkg/ArmPkg.dsc: move ArmMmuStandaloneMmLib.inf to AARCH64 section

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 13:27, Leif Lindholm  wrote:
>
> On Tue, Nov 27, 2018 at 01:17:27PM +0100, Ard Biesheuvel wrote:
> > ArmMmuStandaloneMmLib.inf cannot be built for ARM so move it to the
> > [Components.AARCH64] section in ArmPkg.dsc.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
>
> Reviewed-by: Leif Lindholm 
>

Pushed as eed947be0b05..5ee1bcae597b

> > ---
> >  ArmPkg/ArmPkg.dsc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> > index acf679651ddf..495f13d2bbec 100644
> > --- a/ArmPkg/ArmPkg.dsc
> > +++ b/ArmPkg/ArmPkg.dsc
> > @@ -117,7 +117,6 @@ [Components.common]
> >ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
> >ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
> >ArmPkg/Library/ArmExceptionLib/ArmRelocateExceptionLib.inf
> > -  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> >
> >ArmPkg/Drivers/CpuDxe/CpuDxe.inf
> >ArmPkg/Drivers/CpuPei/CpuPei.inf
> > @@ -153,3 +152,4 @@ [Components.common]
> >
> >  [Components.AARCH64]
> >ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
> > +  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> > --
> > 2.19.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits

2018-11-27 Thread Ard Biesheuvel

AArch64 support the use of more than 48 bits for physical and/or
virtual addressing, but only if the page size is set to 64 KB,
which is not supported by UEFI/EDK2. So redefine MAX_ADDRESS to
cover only 48 address bits.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdePkg/Include/AArch64/ProcessorBind.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/AArch64/ProcessorBind.h 
b/MdePkg/Include/AArch64/ProcessorBind.h
index 968c18f915ae..dad75df1c579 100644
--- a/MdePkg/Include/AArch64/ProcessorBind.h
+++ b/MdePkg/Include/AArch64/ProcessorBind.h
@@ -138,9 +138,9 @@ typedef INT64   INTN;
 #define MAX_2_BITS  0xC000ULL
 
 ///
-/// Maximum legal AARCH64  address
+/// Maximum legal AARCH64  address (48 bits for 4 KB page size)
 ///
-#define MAX_ADDRESS   0xULL
+#define MAX_ADDRESS   0xULL
 
 ///
 /// Maximum legal AArch64 INTN and UINTN values.
-- 
2.19.1

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

Re: [edk2] [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 13:11, Laszlo Ersek  wrote:
>
> On 11/26/18 23:37, Ard Biesheuvel wrote:
> > The ArmVirtQemu targets currently limit the size of the IPA space to
> > 40 bits because that is all what KVM supports. However, this is about
> > to change, and so we need to update the code if we want to ensure that
> > our UEFI firmware builds can keep running on systems that set values
> > other than 40 (which could be > 40 or < 40)
> >
> > So refactor the way we deal with this limit, both for bare metal and for
> > virtual targets, so that
> > a) the range of the GCD memory map is based directly on the CPU's PA range
> > b) the range of the 1:1 mapping in the page tables is based on the CPU's PA
> >range (unless it exceeds what the architecture permits for 4k pages)
> > c) PcdPrePiCpuMemorySize is no longer needed, and can be removed.
> >
> > Patch #1 introduces ARM_MMU_IDMAP_RANGE and ArmGetPhysicalAddressBits ()
> > in ArmLib.
>
> OK, so the crucial piece of info I missed under v1 was that given the
> fixed 4KB page size under UEFI, we might not be able to identity map all
> the memory that the CPU would otherwise be capable of addressing
> (assuming the OS set up a larger page size).
>
> However... that seems to leave us with a conundrum. (I'm 100% sure it is
> nothing new to you, but it is new to me.)
>
> If we size the GCD memory space map exactly to what we can identity map
> under UEFI, then the UEFI memmap will not advertize the rest of the RAM
> to the OS, and the memory will be unusable.
>
> On the other hand, if we size the GCD to the exact RAM size (part of
> which could be out of reach for the CPU *under UEFI*, using 4KB pages),
> then the OS will be happy. But, what happens when gBS->AllocatePages()
> is served from such a high (>48bits) address range, and then the client
> module tries to access the (not mapped) chunk?
>

That is an excellent question, given that IA32 and ARM are in exactly
the same boat with [L]PAE.

> Hm... Actually, once this becomes a practical problem, I think we can
> take care of it, in a platform PEIM. Namely, just pre-allocate the
> entire inaccessible / unmappable range (beyond 48-bits) as Boot Services
> Data type memory. That will keep the rest of the firmware out (no
> well-behaving module will read or write memory that it didn't allocate),
> and the OS will be happy to release and reuse that memory.
>
> Does this make sense?
>

I will look into how IA32 and ARM deal with this at the moment. Well spotted!

> I'd like to be sure that I understand this right, before starting my v2
> review.
>
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/ArmPkg.dsc: move ArmMmuStandaloneMmLib.inf to AARCH64 section

2018-11-27 Thread Leif Lindholm

On Tue, Nov 27, 2018 at 01:17:27PM +0100, Ard Biesheuvel wrote:
> ArmMmuStandaloneMmLib.inf cannot be built for ARM so move it to the
> [Components.AARCH64] section in ArmPkg.dsc.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  ArmPkg/ArmPkg.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> index acf679651ddf..495f13d2bbec 100644
> --- a/ArmPkg/ArmPkg.dsc
> +++ b/ArmPkg/ArmPkg.dsc
> @@ -117,7 +117,6 @@ [Components.common]
>ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
>ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
>ArmPkg/Library/ArmExceptionLib/ArmRelocateExceptionLib.inf
> -  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
>  
>ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>ArmPkg/Drivers/CpuPei/CpuPei.inf
> @@ -153,3 +152,4 @@ [Components.common]
>  
>  [Components.AARCH64]
>ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
> +  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> -- 
> 2.19.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg, ArmVirtPkg: discover NOR flash banks from DTB

2018-11-27 Thread Ard Biesheuvel

On Mon, 26 Nov 2018 at 18:02, Ard Biesheuvel  wrote:
>
> On Mon, 26 Nov 2018 at 18:00, Ard Biesheuvel  
> wrote:
> >
> > On Wed, 21 Nov 2018 at 12:58, Ard Biesheuvel  
> > wrote:
> > >
> > > This series fixes an issue reported by Hongbo and Philippe, where
> > > ArmVirtQemuKernel will crash on an attempt to access flash bank #0,
> > > which is secure-only when running QEMU with support for EL3.
> > >
> > > So let's switch to discovering the NOR flash banks from the device tree
> > > instead. This requires some preparatory changes in the NOR flash driver
> > > to avoid having to invent GUIDs on the fly.
> > >
> > > Changes since v1:
> > > - split ArmPlatformPkg for clarity
> > > - move DT node status check into FdtClientDxe where it belongs
> > > - use correct UINT32* type for DT property values, and be pedantic about
> > >   their potential misalignment when casting to UINT64*
> > > - add patch to remove the 'Guid' member from NOR_FLASH_DESCRIPTION
> > > - add some acks
> > >
> > > Ard Biesheuvel (5):
> > >   ArmPlatformPkg/NorFlashDxe: prepare for devicepath format change
> > >   ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash
> > > banks
> > >   ArmVirtPkg/FdtClientDxe: take DT node 'status' properties into account
> > >   ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
> > >   ArmPlatformPkg/NorFlashPlatformLib: remove unused Guid member from
> > > struct
> > >
> > >  .../Drivers/NorFlashDxe/NorFlashDxe.c | 15 ++--
> > >  .../Drivers/NorFlashDxe/NorFlashDxe.h |  3 +
> > >  .../Include/Library/NorFlashPlatformLib.h |  1 -
> > >  ArmVirtPkg/FdtClientDxe/FdtClientDxe.c| 38 +++--
> > >  .../Library/NorFlashQemuLib/NorFlashQemuLib.c | 78 ++-
> > >  .../NorFlashQemuLib/NorFlashQemuLib.inf   | 12 +++
> > >  6 files changed, 114 insertions(+), 33 deletions(-)
> > >
> >
> > Pushed as 1ec194b21c0e..72e514c90730
> >
> > Thanks all
>
> Forgot to add: minus the 5th patch, which I will push once the
> dependent changes in edk2-platforms have been pushed.

#5 now pushed as 13d5d0a56e486be39f95c5e0883e64698ed02714
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v5 0/5] ArmPkg related changes for StandaloneMM package

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 11:44, Sughosh Ganu  wrote:
>
>
> Changes since v4:
> Based on comments from Ard
>  - Removed now superfluous call to FreePages from MmCommunication.c
>  - Removed Chipset/AArch64.h header file from ArmMmuStandaloneMmLib.c
>
> Changes since v3:
> Based on review comments from Ard, moved the MMU attribute changing
> functions for StandaloneMM image into a new library class.
>
> Moved the addition of memory space used as a MM_COMMUNICATE buffer to
> memory type 'EfiGcdMemoryTypeReserved' and removed the call to
> AllocatgePages.
>
> Changes since v2:
> Based on review comments from Ard, moved the memory attribute updation
> changes out of DebugPeCoffExtraActionLib into an extra action library
> added in StandaloneMM package. The patch for setting the memory
> attributes, now under StandaloneMmPkg directory, will be submitted
> separately from this series.
>
> Changes since v1: Handled review comments from Leif
>
>
> Achin Gupta (4):
>   ArmPkg: Add PCDs needed for MM communication driver.
>   ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
>   ArmPkg/Include: Add MM interface SVC return codes.
>   ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
>
> Sughosh Ganu (1):
>   ArmPkg/Include: Fix the SPM version SVC ID
>

Reviewed-by: Ard Biesheuvel 

Pushed as 13d5d0a56e48..eed947be0b05

Thanks! I'm very happy we will finally have the pieces in place to
implement UEFI secure boot on ARM in a sane way.


>  ArmPkg/ArmPkg.dec
>|  
>  4 +
>  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
>|  
> 56 +++
>  
> ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
>  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf |  23 +-
>  ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
>|  
> 28 ++
>  ArmPkg/Include/IndustryStandard/ArmMmSvc.h   
>|  
>  9 +-
>  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h} 
>|  
> 38 +-
>  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c  
>| 
> 372 
>  ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
>| 
> 184 ++
>  8 files changed, 669 insertions(+), 45 deletions(-)
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
>  copy 
> ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
>  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf (56%)
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
>  copy ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h} (55%)
>  create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
>  create mode 100644 
> ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
>
> --
> 2.7.4
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit

2018-11-27 Thread Laszlo Ersek

On 11/26/18 23:37, Ard Biesheuvel wrote:
> The ArmVirtQemu targets currently limit the size of the IPA space to
> 40 bits because that is all what KVM supports. However, this is about
> to change, and so we need to update the code if we want to ensure that
> our UEFI firmware builds can keep running on systems that set values
> other than 40 (which could be > 40 or < 40)
> 
> So refactor the way we deal with this limit, both for bare metal and for
> virtual targets, so that
> a) the range of the GCD memory map is based directly on the CPU's PA range
> b) the range of the 1:1 mapping in the page tables is based on the CPU's PA
>range (unless it exceeds what the architecture permits for 4k pages)
> c) PcdPrePiCpuMemorySize is no longer needed, and can be removed.
> 
> Patch #1 introduces ARM_MMU_IDMAP_RANGE and ArmGetPhysicalAddressBits ()
> in ArmLib.

OK, so the crucial piece of info I missed under v1 was that given the
fixed 4KB page size under UEFI, we might not be able to identity map all
the memory that the CPU would otherwise be capable of addressing
(assuming the OS set up a larger page size).

However... that seems to leave us with a conundrum. (I'm 100% sure it is
nothing new to you, but it is new to me.)

If we size the GCD memory space map exactly to what we can identity map
under UEFI, then the UEFI memmap will not advertize the rest of the RAM
to the OS, and the memory will be unusable.

On the other hand, if we size the GCD to the exact RAM size (part of
which could be out of reach for the CPU *under UEFI*, using 4KB pages),
then the OS will be happy. But, what happens when gBS->AllocatePages()
is served from such a high (>48bits) address range, and then the client
module tries to access the (not mapped) chunk?

Hm... Actually, once this becomes a practical problem, I think we can
take care of it, in a platform PEIM. Namely, just pre-allocate the
entire inaccessible / unmappable range (beyond 48-bits) as Boot Services
Data type memory. That will keep the rest of the firmware out (no
well-behaving module will read or write memory that it didn't allocate),
and the OS will be happy to release and reuse that memory.

Does this make sense?

I'd like to be sure that I understand this right, before starting my v2
review.

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

[edk2] [PATCH] ArmPkg: fix StandaloneMmMmuLib subdirectory case

2018-11-27 Thread Leif Lindholm

While this isn't the only Aarch64 directory in the tree, let's
keep from adding more of them.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---
 ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf | 2 +-
 .../StandaloneMmMmuLib/{Aarch64 => AArch64}/ArmMmuStandaloneMmLib.c | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename ArmPkg/Library/StandaloneMmMmuLib/{Aarch64 => 
AArch64}/ArmMmuStandaloneMmLib.c (100%)

diff --git a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf 
b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
index d589b23603..7219b59e6f 100644
--- a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
+++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
@@ -22,7 +22,7 @@ [Defines]
   PI_SPECIFICATION_VERSION   = 0x00010032
 
 [Sources.AARCH64]
-  Aarch64/ArmMmuStandaloneMmLib.c
+  AArch64/ArmMmuStandaloneMmLib.c
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c 
b/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
similarity index 100%
rename from ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
rename to ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
-- 
2.11.0

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

Re: [edk2] [PATCH v2 01/13] ArmPkg/ArmLib: add support for reading the max physical address space size

2018-11-27 Thread Ard Biesheuvel

On Mon, 26 Nov 2018 at 23:38, Ard Biesheuvel  wrote:
>
> Add a helper function that returns the maximum physical address space
> size as supported by the current CPU.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Include/Library/ArmLib.h   | 17 +
>  ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 16 
>  ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S |  8 
>  3 files changed, 41 insertions(+)
>
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index ffda50e9d767..b22879fe6e94 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -29,6 +29,17 @@
>  #define EFI_MEMORY_CACHETYPE_MASK   (EFI_MEMORY_UC | EFI_MEMORY_WC | \
>   EFI_MEMORY_WT | EFI_MEMORY_WB | \
>   EFI_MEMORY_UCE)
> +//
> +// ARM_MMU_IDMAP_RANGE defines the maximum size of the identity mapping
> +// that covers the entire address space when running in UEFI. This is
> +// limited to what can architecturally be mapped using a 4 KB granule,
> +// even if the hardware is capable of mapping more using larger pages.
> +//
> +#ifdef MDE_CPU_ARM
> +#define ARM_MMU_IDMAP_RANGE (1ULL << 32)
> +#else
> +#define ARM_MMU_IDMAP_RANGE (1ULL << 48)
> +#endif
>

I just learned that this is essentially the same as MAX_ADDRESS (after
we fix AArch64's definition of it) so this can be dropped.

>  /**
>   * The UEFI firmware must not use the 
> ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_* attributes.
> @@ -733,4 +744,10 @@ ArmWriteCntvOff (
>UINT64   Val
>);
>
> +UINTN
> +EFIAPI
> +ArmGetPhysicalAddressBits (
> +  VOID
> +  );
> +
>  #endif // __ARM_LIB__
> diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S 
> b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S
> index 1ef2f61f5979..7332601241aa 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S
> +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S
> @@ -196,4 +196,20 @@ ASM_FUNC(ArmWriteSctlr)
>  3:msr   sctlr_el3, x0
>  4:ret
>
> +ASM_FUNC(ArmGetPhysicalAddressBits)
> +  mrs   x0, id_aa64mmfr0_el1
> +  adr   x1, .LPARanges
> +  and   x0, x0, #7
> +  ldrb  w0, [x1, x0]
> +  ret
> +
> +//
> +// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
> +// physical address space support on this CPU:
> +// 0 == 32 bits, 1 == 36 bits, etc etc
> +// 6 and 7 are reserved
> +//
> +.LPARanges:
> +  .byte 32, 36, 40, 42, 44, 48, 52, -1
> +
>  ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S 
> b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S
> index f2a517671f0a..f2f3c9a25991 100644
> --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S
> +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S
> @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr)
>isb
>bx  lr
>
> +ASM_FUNC (ArmGetPhysicalAddressBits)
> +  mrc p15, 0, r0, c0, c1, 4   // MMFR0
> +  and r0, r0, #0xf// VMSA [3:0]
> +  cmp r0, #5  // >5 implies LPAE support
> +  movlt   r0, #32 // 32 bits if no LPAE
> +  movge   r0, #40 // 40 bits if LPAE
> +  bx  lr
> +
>  ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> --
> 2.19.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg: fix StandaloneMmMmuLib subdirectory case

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 13:26, Leif Lindholm  wrote:
>
> While this isn't the only Aarch64 directory in the tree, let's
> keep from adding more of them.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 

Acked-by: Ard Biesheuvel 

> ---
>  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf | 2 
> +-
>  .../StandaloneMmMmuLib/{Aarch64 => AArch64}/ArmMmuStandaloneMmLib.c | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename ArmPkg/Library/StandaloneMmMmuLib/{Aarch64 => 
> AArch64}/ArmMmuStandaloneMmLib.c (100%)
>
> diff --git a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf 
> b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> index d589b23603..7219b59e6f 100644
> --- a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> +++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> @@ -22,7 +22,7 @@ [Defines]
>PI_SPECIFICATION_VERSION   = 0x00010032
>
>  [Sources.AARCH64]
> -  Aarch64/ArmMmuStandaloneMmLib.c
> +  AArch64/ArmMmuStandaloneMmLib.c
>
>  [Packages]
>ArmPkg/ArmPkg.dec
> diff --git 
> a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c 
> b/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
> similarity index 100%
> rename from ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> rename to ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
> --
> 2.11.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmPkg/ArmPkg.dsc: move ArmMmuStandaloneMmLib.inf to AARCH64 section

2018-11-27 Thread Ard Biesheuvel

ArmMmuStandaloneMmLib.inf cannot be built for ARM so move it to the
[Components.AARCH64] section in ArmPkg.dsc.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index acf679651ddf..495f13d2bbec 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -117,7 +117,6 @@ [Components.common]
   ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
   ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
   ArmPkg/Library/ArmExceptionLib/ArmRelocateExceptionLib.inf
-  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
 
   ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   ArmPkg/Drivers/CpuPei/CpuPei.inf
@@ -153,3 +152,4 @@ [Components.common]
 
 [Components.AARCH64]
   ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
+  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
-- 
2.19.1

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

Re: [edk2] Edk2 2019 Q1 stable tag planning is added into EDK-II-Release-Planning wiki

2018-11-27 Thread Laszlo Ersek

On 11/12/18 11:57, Laszlo Ersek wrote:
> On 11/09/18 15:25, Gao, Liming wrote:
>> Hi, all
>>   Next edk2 stable tag planning has been added into EDK-II-Release-Planning 
>> wiki 
>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.
>>  Please review the proposed schedule. The proposed features are not 
>> finalized. If you know any feature will be ready, please propose to add it 
>> into the feature scope.
>> edk2-stable201903 tag planning
>> Proposed Schedule
>> Date
>>
>> Description
>>
>> 2018-11-15
>>
>> Beginning of development
>>
>> 2019-02-22
>>
>> Soft Feature 
>> Freeze
>>
>> 2019-03-01
>>
>> Hard Feature 
>> Freeze
>>
>> 2019-03-08
>>
>> Release
>>
>> Proposed Features
>>
>>   *   Python 3 migration
>>   *   Add MSFT toolchain support to 
>> BaseStackCheckLib
>>   *   BaseTool Suggestions for improving building 
>> performance
>>   *   Delete IPv4 only TCP/iSCSI/PXE drivers in 
>> MdeModulePkg
>>   *   Remove EdkShellPkg from 
>> edk2/master
>>   *   Remove EdkShellBinPkg from 
>> edk2/master
>>   *   BaseTools: Support Array and C code style initialization in Structure 
>> PCD
>>   *   TBD Bugzilla List
> 
> (I'm answering just to acknowledge that I've read this email; I intend
> to follow up soon.)

Sorry about the delay. I can now confirm that the schedule is OK with us.

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

Re: [edk2] [RFC PATCH v2 04/11] ArmPlatformPkg/NorFlashDxe: allow reusability as a MM driver

2018-11-27 Thread Leif Lindholm

On Tue, Nov 27, 2018 at 04:56:19PM +0530, Jagadeesh Ujja wrote:
> Adapt the NorFlashDxe driver to be used as a MM_STANDALONE driver to
> allow access to NOR flash for code executing in MM_STANDALONE mode.
> This allows storing of EFI variables on NOR flash which is accessible
> only via the MM STANDALONE mode software.
> 
> Change-Id: Ic55ea0bc4098aefd6edfea03e6dd5ccf5f2e

Please don't litter commit messages with company-internal tracking
data.

> Signed-off-by: Jagadeesh Ujja 
> Signed-off-by: Thomas Abraham 
> Signed-off-by: Vishwanatha HG 

There can be only one Signed-off-by for a patch. That sign-off is you
testifying that this code is submissible under the licenses stated.

If you are contributing a patch where you are not the Author, that
will be reflected by the From: header added by git.

> ---
>  .../Drivers/NorFlashDxe/NorFlashBlockIoDxe.c  |   2 +-
>  .../Drivers/NorFlashDxe/NorFlashDxe.c | 211 ++
>  .../Drivers/NorFlashDxe/NorFlashDxe.h |   5 +-
>  .../Drivers/NorFlashDxe/NorFlashDxe.inf   |   3 +
>  .../Drivers/NorFlashDxe/NorFlashFvbDxe.c  |  96 
>  .../NorFlashDxe/NorFlashStandaloneMm.inf  |  76 +++
>  6 files changed, 304 insertions(+), 89 deletions(-)
>  create mode 100644 
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf

Please rework this set and resubmit based on the above comments, and
also ensuring to follow the guidelines in
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

Regards,

Leif

> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c 
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
> index 279b77c75e..4c002c7d65 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
> @@ -1,6 +1,6 @@
>  /** @file  NorFlashBlockIoDxe.c
>  
> -  Copyright (c) 2011-2013, ARM Ltd. All rights reserved.
> +  Copyright (c) 2011-2018, 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
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c 
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> index 46e815beb3..706906a974 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> @@ -1,6 +1,6 @@
>  /** @file  NorFlashDxe.c
>  
> -  Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
> +  Copyright (c) 2011 - 2018, 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
> @@ -134,29 +134,102 @@ NorFlashCreateInstance (
>  
>if (SupportFvb) {
>  NorFlashFvbInitialize (Instance);
> +if (!InMm ()) {
> +Status = gBS->InstallMultipleProtocolInterfaces (
> +>Handle,
> +, >DevicePath,
> +,  
> >BlockIoProtocol,
> +, 
> >FvbProtocol,
> +NULL
> +);
> +if (EFI_ERROR(Status)) {
> +  FreePool (Instance);
> +  return Status;
> +}
> +} else {
> +  //Install DevicePath Protocol
> +  Status = gMmst->MmInstallProtocolInterface (
> +>Handle,
> +,
> +EFI_NATIVE_INTERFACE,
> +>DevicePath
> +);
> +  if (EFI_ERROR(Status)) {
> +FreePool (Instance);
> +return Status;
> +  }
> +  //Install BlockIo Protocol
> +  Status = gMmst->MmInstallProtocolInterface (
> +>Handle,
> +,
> +EFI_NATIVE_INTERFACE,
> +>BlockIoProtocol
> +);
> +  if (EFI_ERROR(Status)) {
> +FreePool (Instance);
> +return Status;
> +  }
>  
> -Status = gBS->InstallMultipleProtocolInterfaces (
> -  >Handle,
> -  , >DevicePath,
> -  ,  >BlockIoProtocol,
> -  , 
> >FvbProtocol,
> -  NULL
> -  );
> -if (EFI_ERROR(Status)) {
> -  FreePool (Instance);
> -  return Status;
> +  //Install FirmwareVolumeBlock Protocol
> +  Status = gMmst->MmInstallProtocolInterface (
> +>Handle,
> +,
> +EFI_NATIVE_INTERFACE,
> +>FvbProtocol
> +);
> +  if (EFI_ERROR(Status)) {
> +FreePool (Instance);
> +return Status;
> +  }
>  }
>} else {
> -Status = gBS->InstallMultipleProtocolInterfaces (
> ->Handle,
> -, >DevicePath,
>

[edk2] [RFC PATCH v2 11/11] CryptoPkg/BaseCryptLib: Hack to get time in MM Standalone mode

2018-11-27 Thread Jagadeesh Ujja

This is hack to get the time when executing in MM Standalone mode. It is
not clear how to implement a function that gets the current time. So
using this as a hack for now.

Change-Id: I5b86a31c3023f31f04985e82a1089cf4d022f060
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 .../Library/BaseCryptLib/BaseCryptLib.inf |  5 
 .../Library/BaseCryptLib/RuntimeCryptLib.inf  |  5 
 .../BaseCryptLib/SysCall/TimerWrapper.c   | 27 ++-
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf 
b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
index c8aafefbab..df4aca6c20 100644
--- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -76,6 +76,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   CryptoPkg/CryptoPkg.dec
+  StandaloneMmPkg/StandaloneMmPkg.dec
 
 [LibraryClasses]
   BaseLib
@@ -86,6 +87,10 @@
   OpensslLib
   IntrinsicLib
   PrintLib
+  PcdLib
+
+[FeaturePcd]
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
 
 #
 # Remove these [BuildOptions] after this library is cleaned up
diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf 
b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
index 32628c8835..651a6736ba 100644
--- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
@@ -80,6 +80,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   CryptoPkg/CryptoPkg.dec
+  StandaloneMmPkg/StandaloneMmPkg.dec
 
 [LibraryClasses]
   BaseLib
@@ -91,6 +92,10 @@
   OpensslLib
   IntrinsicLib
   PrintLib
+  PcdLib
+
+[FeaturePcd]
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
 
 #
 # Remove these [BuildOptions] after this library is cleaned up
diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c 
b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
index 5f9b0c20d7..d01b5c5fc1 100644
--- a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
+++ b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
@@ -3,6 +3,7 @@
   for OpenSSL-based Cryptographic Library (used in DXE & RUNTIME).
 
 Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 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
@@ -77,12 +78,26 @@ time_t time (time_t *timer)
   time_t  CalTime;
   UINTN   Year;
 
-  //
-  // Get the current time and date information
-  //
-  Status = gRT->GetTime (, NULL);
-  if (EFI_ERROR (Status) || (Time.Year < 1970)) {
-return 0;
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
+//
+// Get the current time and date information
+//
+Status = gRT->GetTime (, NULL);
+if (EFI_ERROR (Status) || (Time.Year < 1970)) {
+  return 0;
+}
+  } else {
+//
+//[ToDo] Find out a way to get the current time for code executing as 
MM_STANDALONE
+//
+Time.Year = 2007;
+Time.Month = 11;
+Time.Day = 29;
+Time.Hour = 17;
+Time.Minute = 43;
+Time.Second = 30;
+
+Year  = (UINTN) (Time.Year % 100);
   }
 
   //
-- 
2.19.1

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

[edk2] [RFC PATCH v2 10/11] CryptoPkg/BaseCryptLib: allow MM_STANDALONE drivers to use this library

2018-11-27 Thread Jagadeesh Ujja

“BaseCryptLib” library can be used by MM_STANDALONE drivers as well.
So add MM_STANDALONE as the module type this library supports

Change-Id: I3f3dfd18b0bb62f5317199858c4b9507682895bd
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf 
b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
index f29445ce34..c8aafefbab 100644
--- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -7,6 +7,7 @@
 #  buffer overflow or integer overflow.
 #
 #  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 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
@@ -24,7 +25,7 @@
   FILE_GUID  = be3bb803-91b6-4da0-bd91-a8b21c18ca5d
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = BaseCryptLib|DXE_DRIVER DXE_CORE 
UEFI_APPLICATION UEFI_DRIVER
+  LIBRARY_CLASS  = BaseCryptLib|DXE_DRIVER DXE_CORE 
UEFI_APPLICATION UEFI_DRIVER MM_STANDALONE
 
 #
 # The following information is for reference only and not required by the 
build tools.
-- 
2.19.1

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

[edk2] [RFC PATCH v2 09/11] MdeModulePkg/VarCheckLib: allow MM_STANDALONE drivers to use this library

2018-11-27 Thread Jagadeesh Ujja

“VarCheckLib” library can be used by MM_STANDALONE drivers as well.
So add MM_STANDALONE as the module type this library supports

Change-Id: I09cc068a3a8a4d320789b2074d12978730a1ab50
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf 
b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
index 099f83dd6a..c8cf81063e 100644
--- a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+++ b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
@@ -2,6 +2,7 @@
 #  Provides variable check services and database management.
 #
 #  Copyright (c) 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2018, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions
@@ -21,12 +22,12 @@
   FILE_GUID  = 63E12D08-0C5D-47F8-95E4-09F89D7506C5
   MODULE_TYPE= DXE_RUNTIME_DRIVER
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = VarCheckLib|DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER
+  LIBRARY_CLASS  = VarCheckLib|DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER MM_STANDALONE
 
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES   = IA32 X64
+#  VALID_ARCHITECTURES   = IA32 X64 AARCH64
 #
 
 [Sources]
-- 
2.19.1

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

[edk2] [RFC PATCH v2 08/11] SecurityPkg/AuthVariableLib: allow MM_STANDALONE drivers to use this library

2018-11-27 Thread Jagadeesh Ujja

“AuthVariableLib” library can be used by MM_STANDALONE drivers as well.
So add MM_STANDALONE as the module type this library supports

Change-Id: I86e7f7162e4a7a9ef11a5c0ba7196f22c184aad0
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
Reviewed-by: Chao Zhang 
---
 SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf 
b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
index 572ba4e120..4294d3b1b0 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+++ b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
@@ -2,6 +2,7 @@
 #  Provides authenticated variable services.
 #
 #  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2018, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions
@@ -21,12 +22,12 @@
   FILE_GUID  = B23CF5FB-6FCC-4422-B145-D855DBC05457
   MODULE_TYPE= DXE_RUNTIME_DRIVER
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = AuthVariableLib|DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER
+  LIBRARY_CLASS  = AuthVariableLib|DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER MM_STANDALONE
 
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES   = IA32 X64
+#  VALID_ARCHITECTURES   = IA32 X64 AARCH64
 #
 
 [Sources]
-- 
2.19.1

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

[edk2] [RFC PATCH v2 07/11] MdeModulePkg/Variable/RuntimeDxe: adapt as a MM Standalone driver

2018-11-27 Thread Jagadeesh Ujja

Adapt the variable runtime dxe driver to be used as a MM_STANDALONE
driver to provide variable storage service in MM Standalone mode.

Change-Id: Ia1c60d15a24a47d235a6d2a88164b84f39fcf81b
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 .../Universal/Variable/RuntimeDxe/Variable.c  |  37 ++--
 .../Variable/RuntimeDxe/VariableSmm.c | 201 ++
 .../RuntimeDxe/VariableStandaloneMm.inf   | 132 
 3 files changed, 312 insertions(+), 58 deletions(-)
 create mode 100644 
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 8e8db71bd2..226464c964 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -18,6 +18,7 @@
 
 Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
+Copyright (c) 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
@@ -3247,19 +3248,21 @@ VariableServiceSetVariable (
 }
   }
 
-  //
-  // Special Handling for MOR Lock variable.
-  //
-  Status = SetVariableCheckHandlerMor (VariableName, VendorGuid, Attributes, 
PayloadSize, (VOID *) ((UINTN) Data + DataSize - PayloadSize));
-  if (Status == EFI_ALREADY_STARTED) {
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
 //
-// EFI_ALREADY_STARTED means the SetVariable() action is handled inside of 
SetVariableCheckHandlerMor().
-// Variable driver can just return SUCCESS.
+// Special Handling for MOR Lock variable.
 //
-return EFI_SUCCESS;
-  }
-  if (EFI_ERROR (Status)) {
-return Status;
+Status = SetVariableCheckHandlerMor (VariableName, VendorGuid, Attributes, 
PayloadSize, (VOID *) ((UINTN) Data + DataSize - PayloadSize));
+if (Status == EFI_ALREADY_STARTED) {
+  //
+  // EFI_ALREADY_STARTED means the SetVariable() action is handled inside 
of SetVariableCheckHandlerMor().
+  // Variable driver can just return SUCCESS.
+  //
+  return EFI_SUCCESS;
+}
+if (EFI_ERROR (Status)) {
+  return Status;
+}
   }
 
   Status = VarCheckLibSetVariableCheck (VariableName, VendorGuid, Attributes, 
PayloadSize, (VOID *) ((UINTN) Data + DataSize - PayloadSize), mRequestSource);
@@ -4068,12 +4071,14 @@ VariableWriteServiceInitialize (
 }
   }
 
-  ReleaseLockOnlyAtBootTime 
(>VariableGlobal.VariableServicesLock);
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
+ReleaseLockOnlyAtBootTime 
(>VariableGlobal.VariableServicesLock);
 
-  //
-  // Initialize MOR Lock variable.
-  //
-  MorLockInit ();
+//
+// Initialize MOR Lock variable.
+//
+MorLockInit ();
+  }
 
   return Status;
 }
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
index 6dc19c24db..cbbb446669 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
@@ -15,6 +15,7 @@
   SmmVariableGetStatistics() should also do validation based on its own 
knowledge.
 
 Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 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
@@ -34,6 +35,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include "Variable.h"
 
@@ -218,11 +221,19 @@ GetFtwProtocol (
   //
   // Locate Smm Fault Tolerent Write protocol
   //
-  Status = gSmst->SmmLocateProtocol (
-,
-NULL,
-FtwProtocol
-);
+  if (PcdGetBool (PcdStandaloneMmEnable)) {
+Status = gMmst->MmLocateProtocol (
+  ,
+  NULL,
+  FtwProtocol
+  );
+  } else {
+Status = gSmst->SmmLocateProtocol (
+  ,
+  NULL,
+  FtwProtocol
+  );
+  }
   return Status;
 }
 
@@ -248,11 +259,19 @@ GetFvbByHandle (
   //
   // To get the SMM FVB protocol interface on the handle
   //
-  return gSmst->SmmHandleProtocol (
-  FvBlockHandle,
-  ,
-  (VOID **) FvBlock
-  );
+  if (PcdGetBool (PcdStandaloneMmEnable)) {
+return gMmst->MmHandleProtocol (
+FvBlockHandle,
+,
+(VOID

[edk2] [RFC PATCH v2 06/11] MdeModulePkg/Variable/RuntimeDxe: adapt for usability with MM Standalone

2018-11-27 Thread Jagadeesh Ujja

Adapt the VariableSmmRuntimeDxe driver to communicate with a VariableSmm
driver that is implemented as a MM Standalone driver.

Change-Id: I328be6df99eaf1a815d6352fe86f0679792b3468
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 .../RuntimeDxe/VariableRuntimeDxe.inf |  2 ++
 .../RuntimeDxe/VariableSmmRuntimeDxe.c| 31 ---
 .../RuntimeDxe/VariableSmmRuntimeDxe.inf  |  4 +++
 3 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
index 868981ccaf..f414b461d8 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
@@ -51,6 +51,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  StandaloneMmPkg/StandaloneMmPkg.dec
 
 [LibraryClasses]
   MemoryAllocationLib
@@ -135,6 +136,7 @@
 [FeaturePcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics  ## CONSUMES # 
statistic the information of variable.
   gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangDeprecate ## CONSUMES # 
Auto update PlatformLang/Lang
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
 
 [Depex]
   TRUE
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
index 85d655dc19..da4af5f30e 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
@@ -14,6 +14,8 @@
   InitCommunicateBuffer() is really function to check the variable data size.
 
 Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 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
@@ -179,7 +181,11 @@ SendCommunicateBuffer (
   SMM_VARIABLE_COMMUNICATE_HEADER   *SmmVariableFunctionHeader;
 
   CommSize = DataSize + SMM_COMMUNICATE_HEADER_SIZE + 
SMM_VARIABLE_COMMUNICATE_HEADER_SIZE;
-  Status = mSmmCommunication->Communicate (mSmmCommunication, 
mVariableBufferPhysical, );
+  if (PcdGetBool (PcdStandaloneMmEnable)) {
+Status = mSmmCommunication->Communicate (mSmmCommunication, 
mVariableBuffer, );
+  } else {
+Status = mSmmCommunication->Communicate (mSmmCommunication, 
mVariableBufferPhysical, );
+  }
   ASSERT_EFI_ERROR (Status);
 
   SmmCommunicateHeader  = (EFI_SMM_COMMUNICATE_HEADER *) mVariableBuffer;
@@ -991,9 +997,11 @@ SmmVariableReady (
 {
   EFI_STATUSStatus;
 
-  Status = gBS->LocateProtocol (, NULL, (VOID 
**));
-  if (EFI_ERROR (Status)) {
-return;
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
+Status = gBS->LocateProtocol (, NULL, (VOID 
**));
+if (EFI_ERROR (Status)) {
+  return;
+}
   }
 
   Status = gBS->LocateProtocol (, NULL, (VOID 
**) );
@@ -1069,13 +1077,14 @@ SmmVariableWriteReady (
 {
   EFI_STATUSStatus;
   VOID  *ProtocolOps;
-
-  //
-  // Check whether the protocol is installed or not.
-  //
-  Status = gBS->LocateProtocol (, NULL, (VOID **) 
);
-  if (EFI_ERROR (Status)) {
-return;
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
+//
+// Check whether the protocol is installed or not.
+//
+Status = gBS->LocateProtocol (, NULL, (VOID **) 
);
+if (EFI_ERROR (Status)) {
+  return;
+}
   }
 
   //
diff --git 
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
index bd73f7ac29..b409fa2f58 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
@@ -48,6 +48,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  StandaloneMmPkg/StandaloneMmPkg.dec
 
 [LibraryClasses]
   MemoryAllocationLib
@@ -87,6 +88,9 @@
   ## SOMETIMES_CONSUMES   ## Variable:L"dbt"
   gEfiImageSecurityDatabaseGuid
 
+[FeaturePcd]
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
+
 [Depex]
   gEfiSmmCommunicationProtocolGuid
 
-- 
2.19.1

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

[edk2] [RFC PATCH v2 05/11] MdeModulePkg/FaultTolerantWriteDxe: allow reusability as a MM driver

2018-11-27 Thread Jagadeesh Ujja

Adapt the FaultTolerantWriteDxe driver to be used as a MM_STANDALONE
driver to provide UEFI fault tolerant write protocol functionality
for variable reclaim operation on EFI variables stored on a NOR flash
that is only accessible to code executing in MM Standalone mode.

Change-Id: Ife29e7d6e7f5d17829abb3ce4ddf0eb94f8e7b28
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 .../FaultTolerantWriteDxe.inf |   2 +
 .../FaultTolerantWriteSmm.c   | 203 +-
 .../FaultTolerantWriteStandaloneMm.inf| 102 +
 .../UpdateWorkingBlock.c  |  27 +--
 4 files changed, 273 insertions(+), 61 deletions(-)
 create mode 100644 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf

diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
index dcde58d632..db45be0a98 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
@@ -41,6 +41,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  StandaloneMmPkg/StandaloneMmPkg.dec
 
 [LibraryClasses]
   UefiBootServicesTableLib
@@ -69,6 +70,7 @@
 
 [FeaturePcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFullFtwServiceEnable## CONSUMES
+  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase## 
SOMETIMES_CONSUMES
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
index fabd713c74..ace39fd4d2 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
@@ -44,6 +44,7 @@
   This driver need to make sure the CommBuffer is not in the SMRAM range.
 
 Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 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
@@ -55,13 +56,16 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 **/
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "FaultTolerantWrite.h"
 #include "FaultTolerantWriteSmmCommon.h"
 #include 
+#include 
 
 EFI_EVENT mFvbRegistration = NULL;
 EFI_FTW_DEVICE*mFtwDevice  = NULL;
@@ -92,11 +96,19 @@ FtwGetFvbByHandle (
   //
   // To get the SMM FVB protocol interface on the handle
   //
-  return gSmst->SmmHandleProtocol (
-  FvBlockHandle,
-  ,
-  (VOID **) FvBlock
-  );
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
+return gSmst->SmmHandleProtocol (
+FvBlockHandle,
+,
+(VOID **) FvBlock
+);
+  } else {
+return gMmst->MmHandleProtocol (
+FvBlockHandle,
+,
+(VOID **) FvBlock
+);
+  }
 }
 
 /**
@@ -119,11 +131,19 @@ FtwGetSarProtocol (
   //
   // Locate Smm Swap Address Range protocol
   //
-  Status = gSmst->SmmLocateProtocol (
-,
-NULL,
-SarProtocol
-);
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
+Status = gSmst->SmmLocateProtocol (
+  ,
+  NULL,
+  SarProtocol
+  );
+  } else {
+Status = gMmst->MmLocateProtocol (
+  ,
+  NULL,
+  SarProtocol
+  );
+  }
   return Status;
 }
 
@@ -158,13 +178,23 @@ GetFvbCountAndBuffer (
   BufferSize = 0;
   *NumberHandles = 0;
   *Buffer= NULL;
-  Status = gSmst->SmmLocateHandle (
-ByProtocol,
-,
-NULL,
-,
-*Buffer
-);
+  if (!PcdGetBool (PcdStandaloneMmEnable)) {
+Status = gSmst->SmmLocateHandle (
+  ByProtocol,
+  ,
+  NULL,
+  ,
+  *Buffer
+  );
+  } else {
+Status = gMmst->MmLocateHandle (
+  ByProtocol,
+  ,
+  NULL,
+  ,
+  *Buffer
+  );
+  }
   if (EFI_ERROR(Status) && Status != EFI_BUFFER_TOO_SMALL) {
 return EFI_NOT_FOUND;
   }
@@ -173,15 +203,23 @@ GetFvbCountAndBuffer (

[edk2] [RFC PATCH v2 04/11] ArmPlatformPkg/NorFlashDxe: allow reusability as a MM driver

2018-11-27 Thread Jagadeesh Ujja

Adapt the NorFlashDxe driver to be used as a MM_STANDALONE driver to
allow access to NOR flash for code executing in MM_STANDALONE mode.
This allows storing of EFI variables on NOR flash which is accessible
only via the MM STANDALONE mode software.

Change-Id: Ic55ea0bc4098aefd6edfea03e6dd5ccf5f2e
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
Signed-off-by: Vishwanatha HG 
---
 .../Drivers/NorFlashDxe/NorFlashBlockIoDxe.c  |   2 +-
 .../Drivers/NorFlashDxe/NorFlashDxe.c | 211 ++
 .../Drivers/NorFlashDxe/NorFlashDxe.h |   5 +-
 .../Drivers/NorFlashDxe/NorFlashDxe.inf   |   3 +
 .../Drivers/NorFlashDxe/NorFlashFvbDxe.c  |  96 
 .../NorFlashDxe/NorFlashStandaloneMm.inf  |  76 +++
 6 files changed, 304 insertions(+), 89 deletions(-)
 create mode 100644 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf

diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
index 279b77c75e..4c002c7d65 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
@@ -1,6 +1,6 @@
 /** @file  NorFlashBlockIoDxe.c
 
-  Copyright (c) 2011-2013, ARM Ltd. All rights reserved.
+  Copyright (c) 2011-2018, 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
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
index 46e815beb3..706906a974 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
@@ -1,6 +1,6 @@
 /** @file  NorFlashDxe.c
 
-  Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
+  Copyright (c) 2011 - 2018, 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
@@ -134,29 +134,102 @@ NorFlashCreateInstance (
 
   if (SupportFvb) {
 NorFlashFvbInitialize (Instance);
+if (!InMm ()) {
+Status = gBS->InstallMultipleProtocolInterfaces (
+>Handle,
+, >DevicePath,
+,  >BlockIoProtocol,
+, 
>FvbProtocol,
+NULL
+);
+if (EFI_ERROR(Status)) {
+  FreePool (Instance);
+  return Status;
+}
+} else {
+  //Install DevicePath Protocol
+  Status = gMmst->MmInstallProtocolInterface (
+>Handle,
+,
+EFI_NATIVE_INTERFACE,
+>DevicePath
+);
+  if (EFI_ERROR(Status)) {
+FreePool (Instance);
+return Status;
+  }
+  //Install BlockIo Protocol
+  Status = gMmst->MmInstallProtocolInterface (
+>Handle,
+,
+EFI_NATIVE_INTERFACE,
+>BlockIoProtocol
+);
+  if (EFI_ERROR(Status)) {
+FreePool (Instance);
+return Status;
+  }
 
-Status = gBS->InstallMultipleProtocolInterfaces (
-  >Handle,
-  , >DevicePath,
-  ,  >BlockIoProtocol,
-  , >FvbProtocol,
-  NULL
-  );
-if (EFI_ERROR(Status)) {
-  FreePool (Instance);
-  return Status;
+  //Install FirmwareVolumeBlock Protocol
+  Status = gMmst->MmInstallProtocolInterface (
+>Handle,
+,
+EFI_NATIVE_INTERFACE,
+>FvbProtocol
+);
+  if (EFI_ERROR(Status)) {
+FreePool (Instance);
+return Status;
+  }
 }
   } else {
-Status = gBS->InstallMultipleProtocolInterfaces (
->Handle,
-, >DevicePath,
-,  >BlockIoProtocol,
-, >DiskIoProtocol,
-NULL
-);
-if (EFI_ERROR(Status)) {
-  FreePool (Instance);
-  return Status;
+if (!InMm ()) {
+  Status = gBS->InstallMultipleProtocolInterfaces (
+  >Handle,
+  , >DevicePath,
+  ,  >BlockIoProtocol,
+  , >DiskIoProtocol,
+  NULL
+  );
+  if (EFI_ERROR(Status)) {
+FreePool (Instance);
+return Status;
+  }
+} else {
+  //Install DevicePath Protocol
+  Status = gMmst->MmInstallProtocolInterface (
+>Handle,
+,
+EFI_NATIVE_INTERFACE,
+>DevicePath
+);
+  if

[edk2] [RFC PATCH v2 03/11] MdeModulePkg/Library: Add StandaloneMmRuntimeDxe library

2018-11-27 Thread Jagadeesh Ujja

To resuse some the libraries in both MM and non-MM mode, a mechanism to
determine the execution mode is required, i.e, in MM or non-MM. Add a
new library for use by non-MM code to determine the current execution
mode.

Change-Id: If0ec88f4691b2b059c770faefed59b2dc29312da
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 .../Include/Library/StandaloneMmRuntimeDxe.h  | 39 +
 .../StandaloneMmRuntimeDxe.c  | 36 
 .../StandaloneMmRuntimeDxe.inf| 43 +++
 3 files changed, 118 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
 create mode 100644 
MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.c
 create mode 100644 
MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf

diff --git a/MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h 
b/MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
new file mode 100644
index 00..e4a61f6a7b
--- /dev/null
+++ b/MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
@@ -0,0 +1,39 @@
+/** @file
+  Provides a service to retrieve a pointer to the Standalone MM Services Table.
+  Only available to Standalone MM module types.
+
+Copyright (c) 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.
+
+**/
+
+#ifndef __STANDALONEMM_RUNTIME_DXE_LIB_H__
+#define __STANDALONEMM_RUNTIME_DXE_LIB_H__
+
+#include 
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Standalone Management Mode(SMM).
+
+  This function returns TRUE if the driver is executing in SMM and FALSE if the
+  driver is not executing in SMM.
+
+  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
+  @retval  FALSE The driver is not executing in Standalone Management Mode 
(SMM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  );
+
+#endif
diff --git 
a/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.c 
b/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.c
new file mode 100644
index 00..61ef59a19a
--- /dev/null
+++ b/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.c
@@ -0,0 +1,36 @@
+/** @file
+  StandaloneMmRuntimeDxe Library.
+
+  Copyright (c) 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 
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Standalone Management Mode(SMM).
+
+  This function returns TRUE if the driver is executing in SMM and FALSE if the
+  driver is not executing in SMM.
+
+  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
+  @retval  FALSE The driver is not executing in Standalone Management Mode 
(SMM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  )
+{
+  return FALSE;
+}
diff --git 
a/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf 
b/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf
new file mode 100644
index 00..5948fd2708
--- /dev/null
+++ b/MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf
@@ -0,0 +1,43 @@
+## @file
+#  Provides StandaloneMmRuntimeDxe.
+#
+#  Copyright (c) 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.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = StandaloneMmRuntimeDxe
+  FILE_GUID  = 8099cfbf-9564-4c9b-9052-e66b1da88930
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = StandaloneMmRuntimeDxe |DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER MM_STANDALONE
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#

[edk2] [RFC PATCH v2 02/11] StandaloneMmPkg: Pull in additonal libraries from staging branch

2018-11-27 Thread Jagadeesh Ujja

Three additional library packages are being pulled into StandaloneMmPkg
from the staging area in order to support the secure variable service.
The three packages being pulled in are
  - StandaloneMmHobLib
  - StandaloneMmMemoryAllocationLib
  - StandaloneMmServicesTableLib

Change-Id: I4d76eccd93e1e750b526f67ed470b17aab29ad63
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 .../Library/StandaloneMmServicesTableLib.h|  47 +
 .../StandaloneMmCoreHobLib.inf|   2 +-
 .../AArch64/StandaloneMmCoreHobLibInternal.c  |  64 ++
 .../StandaloneMmHobLib/StandaloneMmHobLib.c   | 655 ++
 .../StandaloneMmHobLib/StandaloneMmHobLib.inf |  48 +
 .../StandaloneMmMemoryAllocationLib.c | 824 ++
 .../StandaloneMmMemoryAllocationLib.inf   |  45 +
 .../StandaloneMmServicesTableLib.c|  64 ++
 .../StandaloneMmServicesTableLib.inf  |  36 +
 9 files changed, 1784 insertions(+), 1 deletion(-)
 create mode 100644 
StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf

diff --git a/StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h 
b/StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
new file mode 100644
index 00..e7a670d363
--- /dev/null
+++ b/StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
@@ -0,0 +1,47 @@
+/** @file
+  Provides a service to retrieve a pointer to the Standalone MM Services Table.
+  Only available to Standalone MM module types.
+
+Copyright (c) 2009 - 2018, 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.
+
+**/
+
+#ifndef __MM_SERVICES_TABLE_LIB_H__
+#define __MM_SERVICES_TABLE_LIB_H__
+
+#include 
+#include 
+
+///
+/// Cache pointer to the Standalone MM Services Table
+
+extern EFI_MM_SYSTEM_TABLE *gMmst;
+
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Standalone Management Mode(SMM).
+
+  This function returns TRUE if the driver is executing in SMM and FALSE if the
+  driver is not executing in SMM.
+
+  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
+  @retval  FALSE The driver is not executing in Standalone Management Mode 
(SMM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  );
+
+#endif
diff --git 
a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf 
b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
index db19d3c926..ac036e31cf 100644
--- a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
+++ b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
@@ -24,7 +24,7 @@
   MODULE_TYPE= MM_CORE_STANDALONE
   VERSION_STRING = 1.0
   PI_SPECIFICATION_VERSION   = 0x00010032
-  LIBRARY_CLASS  = HobLib|MM_CORE_STANDALONE MM_STANDALONE
+  LIBRARY_CLASS  = HobLib|MM_CORE_STANDALONE
 
 #
 #  VALID_ARCHITECTURES   = AARCH64
diff --git 
a/StandaloneMmPkg/Library/StandaloneMmHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
 
b/StandaloneMmPkg/Library/StandaloneMmHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
new file mode 100644
index 00..ac5a1c039f
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/StandaloneMmHobLib/AArch64/StandaloneMmCoreHobLibInternal.c
@@ -0,0 +1,64 @@
+/** @file
+  HOB Library implementation for Standalone MM Core.
+
+Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 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

[edk2] [RFC PATCH v2 01/11] MdeModulePkg/Variable: replace all uses of AsmLfence with MemoryFence

2018-11-27 Thread Jagadeesh Ujja

Replace all uses of AsmLfence with call to MemoryFence to allow
variable service code to be platform independent.

Change-Id: I578719ab038318bd240ec5471d42552c8b7c75db
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Thomas Abraham 
---
 .../Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c   | 4 ++--
 MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c | 2 +-
 MdePkg/Library/BaseLib/X86MemoryFence.c   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
index 27fcab19b6..fabd713c74 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
@@ -419,11 +419,11 @@ SmmFaultTolerantWriteHandler (
  );
   if (!EFI_ERROR (Status)) {
 //
-// The AsmLfence() call here is to ensure the previous range/content
+// The MemoryFence () call here is to ensure the previous range/content
 // checks for the CommBuffer have been completed before calling into
 // FtwWrite().
 //
-AsmLfence ();
+MemoryFence ();
 Status = FtwWrite(
>FtwInstance,
SmmFtwWriteHeader->Lba,
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
index 4b0d7e3e95..7c4b01924e 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
@@ -26,5 +26,5 @@ MemoryLoadFence (
   VOID
   )
 {
-  AsmLfence ();
+  MemoryFence ();
 }
diff --git a/MdePkg/Library/BaseLib/X86MemoryFence.c 
b/MdePkg/Library/BaseLib/X86MemoryFence.c
index 77e1c5a4dd..3a7928df9b 100644
--- a/MdePkg/Library/BaseLib/X86MemoryFence.c
+++ b/MdePkg/Library/BaseLib/X86MemoryFence.c
@@ -28,5 +28,5 @@ MemoryFence (
   VOID
   )
 {
-  return;
+  AsmLfence ();
 }
-- 
2.19.1

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

[edk2] [RFC PATCH v2 00/11] Extend secure variable service to be usable from Standalone MM

2018-11-27 Thread Jagadeesh Ujja

Changes since v1:
- Addressed all the comments from Liming Gao
  - Removed the use of #ifdef/#else/#endif and used a Pcd instead to
select between MM and non-MM paths.
  - Removed all dependencies on edk2-platforms.
  - Dropped the use of mMmst and used gSmst instead.
  - Added a dummy implementation UefiRuntimeServiceTableLib for
MM_STANDALONE usage
- Replaced all uses of AsmLfence with MemoryFence from variable
  service code.
- Add a new StandaloneMmRuntimeDxe library to for use by non-MM code.

This RFC patch series extends the existing secure variable service support
for use with Standalone MM. This is applicable to paltforms that use
Standalone Management Mode to protect access to non-volatile memory (NOR
flash in case of these patches) used to store the secure EFI variables.

The first patch pulls in additional libraries from the staging branch of
StandaloneMmPkg into the edk2's StandaloneMmPkg. The existing secure
variable service implementation supports only the traditional MM mode
and so the rest of the patches extends the existing secure variable
service support to be useable with Standalone MM mode as well.

This patch series is being posted as an RFC to get feedback on the
approach taken in these patches.

Jagadeesh Ujja (11):
  MdeModulePkg/Variable: replace all uses of AsmLfence with MemoryFence
  StandaloneMmPkg: Pull in additonal libraries from staging branch
  MdeModulePkg/Library: Add StandaloneMmRuntimeDxe library
  ArmPlatformPkg/NorFlashDxe: allow reusability as a MM driver
  MdeModulePkg/FaultTolerantWriteDxe: allow reusability as a MM driver
  MdeModulePkg/Variable/RuntimeDxe: adapt for usability with MM
Standalone
  MdeModulePkg/Variable/RuntimeDxe: adapt as a MM Standalone driver
  SecurityPkg/AuthVariableLib: allow MM_STANDALONE drivers to use this
library
  MdeModulePkg/VarCheckLib: allow MM_STANDALONE drivers to use this
library
  CryptoPkg/BaseCryptLib: allow MM_STANDALONE drivers to use this
library
  CryptoPkg/BaseCryptLib: Hack to get time in MM Standalone mode

 .../Drivers/NorFlashDxe/NorFlashDxe.inf   |   3 +
 .../NorFlashDxe/NorFlashStandaloneMm.inf  |  76 ++
 .../Library/BaseCryptLib/BaseCryptLib.inf |   8 +-
 .../Library/BaseCryptLib/RuntimeCryptLib.inf  |   5 +
 .../StandaloneMmRuntimeDxe.inf|  43 +
 .../Library/VarCheckLib/VarCheckLib.inf   |   5 +-
 .../FaultTolerantWriteDxe.inf |   2 +
 .../FaultTolerantWriteStandaloneMm.inf| 102 +++
 .../RuntimeDxe/VariableRuntimeDxe.inf |   2 +
 .../RuntimeDxe/VariableSmmRuntimeDxe.inf  |   4 +
 .../RuntimeDxe/VariableStandaloneMm.inf   | 132 +++
 .../AuthVariableLib/AuthVariableLib.inf   |   5 +-
 .../StandaloneMmCoreHobLib.inf|   2 +-
 .../StandaloneMmHobLib/StandaloneMmHobLib.inf |  48 +
 .../StandaloneMmMemoryAllocationLib.inf   |  45 +
 .../StandaloneMmServicesTableLib.inf  |  36 +
 .../Drivers/NorFlashDxe/NorFlashDxe.h |   5 +-
 .../Include/Library/StandaloneMmRuntimeDxe.h  |  39 +
 .../Library/StandaloneMmServicesTableLib.h|  47 +
 .../Drivers/NorFlashDxe/NorFlashBlockIoDxe.c  |   2 +-
 .../Drivers/NorFlashDxe/NorFlashDxe.c | 211 -
 .../Drivers/NorFlashDxe/NorFlashFvbDxe.c  |  96 +-
 .../BaseCryptLib/SysCall/TimerWrapper.c   |  27 +-
 .../StandaloneMmRuntimeDxe.c  |  36 +
 .../FaultTolerantWriteSmm.c   | 207 +++--
 .../UpdateWorkingBlock.c  |  27 +-
 .../Variable/RuntimeDxe/LoadFenceSmm.c|   2 +-
 .../Universal/Variable/RuntimeDxe/Variable.c  |  37 +-
 .../Variable/RuntimeDxe/VariableSmm.c | 201 -
 .../RuntimeDxe/VariableSmmRuntimeDxe.c|  31 +-
 MdePkg/Library/BaseLib/X86MemoryFence.c   |   2 +-
 .../AArch64/StandaloneMmCoreHobLibInternal.c  |  64 ++
 .../StandaloneMmHobLib/StandaloneMmHobLib.c   | 655 ++
 .../StandaloneMmMemoryAllocationLib.c | 824 ++
 .../StandaloneMmServicesTableLib.c|  64 ++
 35 files changed, 2860 insertions(+), 235 deletions(-)
 create mode 100644 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
 create mode 100644 
MdeModulePkg/Library/StandaloneMmRuntimeDxe/StandaloneMmRuntimeDxe.inf
 create mode 100644 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
 create mode 100644 
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
 create mode 100644 MdeModulePkg/Include/Library/StandaloneMmRuntimeDxe.h
 create mode 100644 
StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h
 create mode 100644

Re: [edk2] [PATCH 0/4] OvmfPkg, ArmVirtPkg: add ACPI Test Support

2018-11-27 Thread Laszlo Ersek

On 11/26/18 18:21, Ard Biesheuvel wrote:
> On Sun, 25 Nov 2018 at 11:02, Laszlo Ersek  wrote:
>>
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: acpi_test_support
>>
>> The feature is described in the first patch. Build OvmfPkg and
>> ArmVirtPkg platforms with "--pcd PcdAcpiTestSupport=TRUE" to enable it.
>>
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Drew Jones 
>> Cc: Igor Mammedov 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>> Cc: Philippe Mathieu-Daudé 
>>
>> Thanks,
>> Laszlo
>>
>> Laszlo Ersek (4):
>>   OvmfPkg: introduce ACPI Test Support data structure and GUID
>>   OvmfPkg/AcpiPlatformDxe: list missing lib classes for
>> QemuFwCfgAcpiPlatformDxe
>>   OvmfPkg/AcpiPlatformDxe: add [Un]RegisterAcpiTestSupport() skeletons
>>   OvmfPkg/AcpiPlatformDxe: fill in ACPI_TEST_SUPPORT at first
>> Ready-To-Boot
>>
> 
> I'm not crazy about scraping memory, but since this is a test feature,
> and since the hypervisor can be trusted to only scrape regions
> populated with non-secure DRAM, I can live with it.
> 
> Regarding the GUID: i thought about perhaps using the XOR of two known
> GUIDs, but bitwise negation involving a all-ones GUID amounts to the
> same thing in the end, so whatever :-)
> 
> Reviewed-by: Ard Biesheuvel 

Thanks :)

> 
>>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h   |  10 ++
>>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf  |   8 ++
>>  OvmfPkg/AcpiPlatformDxe/AcpiTestSupport.c| 119 
>> 
>>  OvmfPkg/AcpiPlatformDxe/EntryPoint.c |  24 +++-
>>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf |  10 ++
>>  OvmfPkg/Include/Guid/AcpiTestSupport.h   |  67 +++
>>  OvmfPkg/OvmfPkg.dec  |   6 +
>>  7 files changed, 239 insertions(+), 5 deletions(-)
>>  create mode 100644 OvmfPkg/AcpiPlatformDxe/AcpiTestSupport.c
>>  create mode 100644 OvmfPkg/Include/Guid/AcpiTestSupport.h
>>
>> --
>> 2.19.1.3.g30247aa5d201
>>

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

Re: [edk2] [PATCH 1/4] OvmfPkg: introduce ACPI Test Support data structure and GUID

2018-11-27 Thread Laszlo Ersek

On 11/26/18 22:43, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
> 
> On 25/11/18 11:01, Laszlo Ersek wrote:
>> QEMU's test suite includes a set of cases called "BIOS tables test". Among
>> other things, it locates the RSD PTR ACPI table in guest RAM, and then
>> (chasing pointers to other ACPI tables) performs various sanity checks on
>> the QEMU-generated and firmware-installed tables.
>>
>> Currently this set of test cases doesn't work with UEFI guests, because
>> the ACPI spec's definition for locating the RSD PTR in UEFI guests is a
>> lot harder to implement from the hypervisor side -- just with raw guest
>> memory access -- than it is when scraping the memory of BIOS guests.
>>
>> Introduce a signature GUID, and a small, MB-aligned structure, identified
>> by the GUID. The hypervisor should loop over all MB-aligned pages in guest
>> RAM until one matches the signature GUID at offset 0, at which point the
>> hypervisor can fetch the RSDP address field(s) from the structure.
>>
>> QEMU's test logic currently spins on a pre-determined guest address, until
>> that address assumes a magic value. The method described in this patch is
>> conceptually the same ("busy loop until match is found"), except there is
>> no hard-coded address. This plays a lot more nicely with UEFI guest
>> firmware (we'll be able to use the normal page allocation UEFI service).
>> Given the size of EFI_GUID (16 bytes -- 128 bits), mismatches should be
>> astronomically unlikely. In addition, given the typical guest RAM size for
>> such tests (128 MB), there are 128 locations to check in one iteration of
>> the "outer" loop, which shouldn't introduce an intolerable delay after the
>> guest stores the RSDP address(es), and then the GUID.
> 
> I applied/build your series,

OK.

> but keep failing trying to test it with QEMU :/

Hm.

> I modified a bit tests/bios-tables-test.c to use the OVMF.fd build for
> the Q35 machine tests,

OK. The primary goal of this series is to enable QEMU developers to
extend bios-tables-test.c to "qemu-system-aarch64/virt"; but, indeed, I
intend the firmware feature to be platform-independent.

Instead, it's the QEMU test case that is supposed to know, intimately,
the subject physical memory map (that is: the set of locations in
guest-phys mem address space that are 1MB aligned and are actually
DRAM-backed). So where exactly to probe is up to QEMU / qtest.

> but still pass the "OnRootBridgesConnected: root
> bridges have been connected, installing ACPI tables".

Sorry, I don't understand this. What do you mean by "still pass"?

AcpiPlatformDxe will print the message you quote when OVMF's platform
boot manager library, in OvmfPkg/Library/PlatformBootManagerLib, signals
it. That's part of the BDS (Boot Device Selection) phase. Similarly,
ArmVirtQemu signals AcpiPlatformDxe from
"ArmVirtPkg/Library/PlatformBootManagerLib".

However, the event we're hooking in this patch set is different, and it
occurs later. It's called "Ready To Boot", and it is emitted / signaled
by the UEFI boot manager when it is about to launch a boot option. See
EFI_EVENT_GROUP_READY_TO_BOOT under EFI_BOOT_SERVICES.CreateEventEx() in
the UEFI spec.

Given that upstream OVMF and ArmVirt builds include / re-create a UEFI
boot option for the built-in UEFI shell, there's always something that
can be booted, even without disks / NICs. Thus, if you launch a
diskless/NIC-less guest with such fw images, the event will be signaled
(and the structure will be populated) no later than the built-in UEFI
shell is launched. The qtest case should simply wait for that.

> Do you have a QEMU companion patch for this series?

I totally don't; I'm not going to write it. :) This patch set is to
support the work of QEMU developers. And, clearly, I'm not going to push
it until someone says, "yes, I've got a working QEMU series that
interfaces with this".

I'm fairly certain this series works as intended, because I tested it as
follows: I booted a guest, waited for the firmware log to confirm that
the callback was called (the log also indicated the correctly aligned
address of the structure, and the RSDP1.0 / RSDP2.0 fields written to
the structure), and then I used the "xp" QEMU monitor commands (via HMP)
to print the guest RAM in the area, and to verify the GUID & the RSDP
fields.

Another possibility (for debugging the qtest work) is to dump the entire
guest RAM with the "dump-guest-memory" monitor command (in ELF format),
and to search the dump for the byte array in question (I think at least
"mcview" and "vbindiff" can search binary files for byte sequences).
Given the XOR trickery, you should have exactly one match, at a
MB-aligned address, assuming you waited long enough before dumping. (The
executable image of the DXE driver will not match.)

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

[edk2] [PATCH v5 5/5] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

2018-11-27 Thread Sughosh Ganu

From: Achin Gupta 

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 will still request ARM
TF to change the memory attributes of memory regions during
initialization.

The Standalone MM image is a FV that encapsulates the MM foundation
and drivers. These are PE-COFF images with data and text segments.
To initialise the MM environment, Arm Trusted Firmware has to create
translation tables with sane default attributes for the memory
occupied by the FV. This library sends SVCs to ARM Trusted Firmware
to request memory permissions change for data and text segments.

This patch adds a simple MMU library suitable for execution in S-EL0 and
requesting memory permissions change operations from Arm Trusted Firmware.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu 
---
 ArmPkg/ArmPkg.dec  
 |   1 +
 
ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
 => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf |  23 +--
 ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h}   
 |  38 
+---
 ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c  
 | 184 

 4 files changed, 202 insertions(+), 44 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 0db7aa9d301c..d99eb6769ff1 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -42,6 +42,7 @@ [LibraryClasses.common]
   ArmMtlLib|ArmPlatformPkg/Include/Library/ArmMtlLib.h
   ArmSvcLib|Include/Library/ArmSvcLib.h
   OpteeLib|Include/Library/OpteeLib.h
+  StandaloneMmMmuLib|Include/Library/StandaloneMmMmuLib.h
 
 [Guids.common]
   gArmTokenSpaceGuid   = { 0xBB11ECFE, 0x820F, 0x4968, { 0xBB, 0xA6, 0xF7, 
0x6A, 0xFE, 0x30, 0x25, 0x96 } }
diff --git 
a/ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
 b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
similarity index 56%
copy from 
ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
copy to ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
index bd6ac8039844..d589b236033c 100644
--- 
a/ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
+++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
@@ -1,7 +1,6 @@
 #/** @file
-#  Implement ArmGenericTimerCounterLib for Xen using the virtual timer
 #
-#  Copyright (c) 2014 - 2018, Linaro Ltd. All rights reserved.
+#  Copyright (c) 2017 - 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
@@ -15,19 +14,23 @@
 
 [Defines]
   INF_VERSION= 0x0001001A
-  BASE_NAME  = XenArmGenericTimerVirtCounterLib
-  FILE_GUID  = e3913319-96ac-4ac0-808b-8edb8776a51c
-  MODULE_TYPE= BASE
+  BASE_NAME  = ArmMmuStandaloneMmCoreLib
+  FILE_GUID  = da8f0232-fb14-42f0-922c-63104d2c70bd
+  MODULE_TYPE= MM_CORE_STANDALONE
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = ArmGenericTimerCounterLib
+  LIBRARY_CLASS  = StandaloneMmMmuLib
+  PI_SPECIFICATION_VERSION   = 0x00010032
 
-[Sources]
-  XenArmGenericTimerVirtCounterLib.c
+[Sources.AARCH64]
+  Aarch64/ArmMmuStandaloneMmLib.c
 
 [Packages]
-  MdePkg/MdePkg.dec
   ArmPkg/ArmPkg.dec
+  MdePkg/MdePkg.dec
 
 [LibraryClasses]
   ArmLib
-  BaseLib
+  CacheMaintenanceLib
+  MemoryAllocationLib
+
+
diff --git a/ArmPkg/Include/Library/ArmMmuLib.h 
b/ArmPkg/Include/Library/StandaloneMmMmuLib.h
similarity index 55%
copy from ArmPkg/Include/Library/ArmMmuLib.h
copy to ArmPkg/Include/Library/StandaloneMmMmuLib.h
index fb7fd006417c..1f7653d00430 100644
--- a/ArmPkg/Include/Library/ArmMmuLib.h
+++ b/ArmPkg/Include/Library/StandaloneMmMmuLib.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2015 - 2016, Linaro Ltd. All rights reserved.
+  Copyright (c) 2018, 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
@@ -12,61 +12,31 @@
 
 **/
 
-#ifndef __ARM_MMU_LIB__
-#define __ARM_MMU_LIB__
-
-#include 
-
-#include 
-
-EFI_STATUS
-EFIAPI
-ArmConfigureMmu (
-  IN  ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable,
-  OUT VOID  **TranslationTableBase

[edk2] [PATCH v5 4/5] ArmPkg/Include: Add MM interface SVC return codes.

2018-11-27 Thread Sughosh Ganu

From: Achin Gupta 

This patch adds the Management Mode(MM) - Secure Partition
Manager(SPM) SVC return codes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu 
---
 ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
index 81b4654fa5dd..a64b9ec23c4b 100644
--- a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
+++ b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
@@ -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.7.4

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

[edk2] [PATCH v5 3/5] ArmPkg/Include: Fix the SPM version SVC ID

2018-11-27 Thread Sughosh Ganu

The MM_VERSION SMC call uses SMC32 calling convention. Fix the macro
to reflect the correct value.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu 
---
 ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
index 4c7b6c338627..81b4654fa5dd 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
-- 
2.7.4

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

[edk2] [PATCH v5 2/5] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

2018-11-27 Thread Sughosh Ganu

From: Achin Gupta 

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: Sughosh Ganu 
---
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf |  56 +++
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h |  28 ++
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c   | 372 

 3 files changed, 456 insertions(+)

diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf 
b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
new file mode 100644
index ..88beafa39c05
--- /dev/null
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
@@ -0,0 +1,56 @@
+#/** @file
+#
+#  DXE MM Communicate driver
+#
+#  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.
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = ArmMmCommunication
+  FILE_GUID  = 09EE81D3-F15E-43F4-85B4-CB9873DA5D6B
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= MmCommunicationInitialize
+
+#
+# The following is for reference only and not required by
+# build tools
+#
+# VALID_ARCHITECTURES= AARCH64
+#
+
+[Sources.AARCH64]
+  MmCommunication.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  ArmLib
+  ArmSmcLib
+  BaseMemoryLib
+  DebugLib
+  DxeServicesTableLib
+  HobLib
+  UefiDriverEntryPoint
+
+[Protocols]
+  gEfiMmCommunicationProtocolGuid  ## PRODUCES
+
+[Pcd.common]
+  gArmTokenSpaceGuid.PcdMmBufferBase
+  gArmTokenSpaceGuid.PcdMmBufferSize
+
+[Depex]
+  gEfiCpuArchProtocolGuid
diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h 
b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
new file mode 100644
index ..0bf1c8d4ca0e
--- /dev/null
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
@@ -0,0 +1,28 @@
+/** @file
+
+  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.
+
+**/
+
+#if !defined _MM_COMMUNICATE_H_
+#define _MM_COMMUNICATE_H_
+
+#define MM_MAJOR_VER_MASK0xEFFF
+#define MM_MINOR_VER_MASK0x
+#define MM_MAJOR_VER_SHIFT   16
+
+#define MM_MAJOR_VER(x) (((x) & MM_MAJOR_VER_MASK) >> MM_MAJOR_VER_SHIFT)
+#define MM_MINOR_VER(x) ((x) & MM_MINOR_VER_MASK)
+
+#define MM_CALLER_MAJOR_VER  0x1UL
+#define MM_CALLER_MINOR_VER  0x0
+
+#endif /* _MM_COMMUNICATE_H_ */
diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
new file mode 100644
index ..feb9fa9f4ead
--- /dev/null
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
@@ -0,0 +1,372 @@
+/** @file
+
+  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 
+#include 
+
+#include 
+
+#include 
+
+#include "MmCommunicate.h"
+
+//
+// Address, Length of the pre-allocated buffer for communication with the 
secure
+// world.
+//
+STATIC

[edk2] [PATCH v5 1/5] ArmPkg: Add PCDs needed for MM communication driver.

2018-11-27 Thread Sughosh Ganu

From: Achin Gupta 

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: Sughosh Ganu 
---
 ArmPkg/ArmPkg.dec | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 84e57a0bf01c..0db7aa9d301c 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -240,6 +240,9 @@ [PcdsFixedAtBuild.common, PcdsDynamic.common, 
PcdsPatchableInModule.common]
   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.7.4

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

[edk2] [PATCH v5 0/5] ArmPkg related changes for StandaloneMM package

2018-11-27 Thread Sughosh Ganu



Changes since v4:
Based on comments from Ard
 - Removed now superfluous call to FreePages from MmCommunication.c
 - Removed Chipset/AArch64.h header file from ArmMmuStandaloneMmLib.c

Changes since v3:
Based on review comments from Ard, moved the MMU attribute changing
functions for StandaloneMM image into a new library class.

Moved the addition of memory space used as a MM_COMMUNICATE buffer to
memory type 'EfiGcdMemoryTypeReserved' and removed the call to
AllocatgePages.

Changes since v2:
Based on review comments from Ard, moved the memory attribute updation
changes out of DebugPeCoffExtraActionLib into an extra action library
added in StandaloneMM package. The patch for setting the memory
attributes, now under StandaloneMmPkg directory, will be submitted
separately from this series.

Changes since v1: Handled review comments from Leif


Achin Gupta (4):
  ArmPkg: Add PCDs needed for MM communication driver.
  ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
  ArmPkg/Include: Add MM interface SVC return codes.
  ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

Sughosh Ganu (1):
  ArmPkg/Include: Fix the SPM version SVC ID

 ArmPkg/ArmPkg.dec  
 |   4 +
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf  
 |  56 
+++
 
ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
 => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf |  23 +-
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h  
 |  28 
++
 ArmPkg/Include/IndustryStandard/ArmMmSvc.h 
 |   9 
+-
 ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h}   
 |  38 
+-
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
 | 372 

 ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c  
 | 184 
++
 8 files changed, 669 insertions(+), 45 deletions(-)
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
 copy 
ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
 => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf (56%)
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunicate.h
 copy ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h} (55%)
 create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
 create mode 100644 
ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c

-- 
2.7.4


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

[edk2] [edk2-test][PATCH v3] SctPkg/build: Add support for GenBin tool build

2018-11-27 Thread Lokesh B V

As the GenBin tool is necessary for SCT build, it is appropriate to
support it's build in the SCT build procedure.

SctPkg/Tools: Fix incorrect line ending detection by GenBin tool

Some windows editors uses "\r\n" for line feed. While processing uefi testcase
info file, the GenBin tool logic to skip line feed doesn't consider the presence
of carriage return(\r) in line feed. So this results in incorrect format error.

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Lokesh B V 
---
 .gitignore   |  1 +
 uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c |  3 +++
 uefi-sct/SctPkg/build.sh | 31 
 3 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 821ed66..3b8d818 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Build/
 tags/
+*.[od]
diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index 61bb35b..4eaefcc 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -2,6 +2,7 @@
 
   Copyright 2006 - 2010 Unified EFI, Inc.
   Copyright (c) 2010 Intel Corporation. All rights reserved.
+  Copyright (c) 2018 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
@@ -176,6 +177,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Index1] != ' ' ) &&
 (String[Index1] != '\t') &&
+(String[Index1] != '\r') &&
 (String[Index1] != '\n')) {
   break;
 }
@@ -193,6 +195,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Length - 1 - Index1] != ' ' ) &&
 (String[Length - 1 - Index1] != '\t') &&
+(String[Length - 1 - Index1] != '\r') &&
 (String[Length - 1 - Index1] != '\n')) {
   break;
 }
diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
index 73581c9..6198532 100755
--- a/uefi-sct/SctPkg/build.sh
+++ b/uefi-sct/SctPkg/build.sh
@@ -1,7 +1,7 @@
 #!/bin/bash
 #
 #  Copyright 2006 - 2015 Unified EFI, Inc.
-#  Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved.
+#  Copyright (c) 2011 - 2018, 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
@@ -228,21 +228,26 @@ else
   echo using prebuilt tools
 fi
 
-# Copy GenBin file to Base tools directory
+if  [[ ! -e $EDK_TOOLS_PATH/Source/C/bin/GenBin ]]
+then
+  # build the GenBin if it doesn't yet exist
+  echo Building GenBin
+  make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin
+  status=$?
+  if test $status -ne 0
+  then
+  echo Error while building GenBin
+exit -1
+  fi
+else
+  echo using prebuilt GenBin
+fi
+
+# Copy GenBin file to Base tools bin directory
 DEST_DIR=`GetEdkToolsPathBinDirectory`
 # Ensure the directory exist
 mkdir -p $DEST_DIR
-case `uname -m` in 
-   x86_64)
-   cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin
-   ;;
-   x86_32)
-   cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
-   ;;
-   *)
-   cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
-   ;;
-esac
+cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin
 
 #
 # Build the SCT package
-- 
2.7.4

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

Re: [edk2] [PATCH] [edk2-test][PATCH v2] SctPkg/build: Add support for GenBin tool build

2018-11-27 Thread Lokesh Belathur Veerappa

Hi Philippe,

-Original Message-
From: Philippe Mathieu-Daudé 
Sent: Tuesday, November 27, 2018 3:20 PM
To: Lokesh Belathur Veerappa ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] [edk2-test][PATCH v2] SctPkg/build: Add support for 
GenBin tool build

Hi,

On 27/11/18 9:35, Lokesh B V wrote:
> As the GenBin tool is necessary for SCT build, it is appropriate to
> support it's build in the SCT build procedure.
>
> SctPkg/Tools: Fix incorrect line ending detection by GenBin tool
>
> Some windows editors uses "\r\n" for line feed. While processing uefi
> testcase info file, the GenBin tool logic to skip line feed doesn't
> consider the presence of carraige return(\r) in line feed. So this results in 
> incorrect format error.

Minor typo: "carriage"

Thanks, will update the patch.

>
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V 
> ---
>  .gitignore   |  1 +
>  uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c |  3 +++
>  uefi-sct/SctPkg/build.sh | 31 
> 
>  3 files changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 821ed66..3b8d818 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,2 +1,3 @@
>  Build/
>  tags/
> +*.[od]
> diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> index 61bb35b..4eaefcc 100644
> --- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> +++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> @@ -2,6 +2,7 @@
>
>Copyright 2006 - 2010 Unified EFI, Inc.
>Copyright (c) 2010 Intel Corporation. All rights reserved.
> +  Copyright (c) 2018 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 @@ -176,6 +177,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
>  if ((String[Index1] != ' ' ) &&
>  (String[Index1] != '\t') &&
> +(String[Index1] != '\r') &&
>  (String[Index1] != '\n')) {
>break;
>  }
> @@ -193,6 +195,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
>  if ((String[Length - 1 - Index1] != ' ' ) &&
>  (String[Length - 1 - Index1] != '\t') &&
> +(String[Length - 1 - Index1] != '\r') &&
>  (String[Length - 1 - Index1] != '\n')) {
>break;
>  }
> diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh index
> 73581c9..6198532 100755
> --- a/uefi-sct/SctPkg/build.sh
> +++ b/uefi-sct/SctPkg/build.sh
> @@ -1,7 +1,7 @@
>  #!/bin/bash
>  #
>  #  Copyright 2006 - 2015 Unified EFI, Inc. -#  Copyright (c) 2011
> - 2015, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2011 - 2018, 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 @@
> -228,21 +228,26 @@ else
>echo using prebuilt tools
>  fi
>
> -# Copy GenBin file to Base tools directory
> +if  [[ ! -e $EDK_TOOLS_PATH/Source/C/bin/GenBin ]] then
> +  # build the GenBin if it doesn't yet exist
> +  echo Building GenBin
> +  make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin
> +  status=$?
> +  if test $status -ne 0
> +  then
> +  echo Error while building GenBin
> +exit -1
> +  fi
> +else
> +  echo using prebuilt GenBin
> +fi
> +
> +# Copy GenBin file to Base tools bin directory
>  DEST_DIR=`GetEdkToolsPathBinDirectory`
>  # Ensure the directory exist
>  mkdir -p $DEST_DIR
> -case `uname -m` in
> -x86_64)
> -cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin
> -;;
> -x86_32)
> -cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> -;;
> -*)
> -cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> -;;
> -esac
> +cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin
>
>  #
>  # Build the SCT package
>
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 5/5] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 11:04, Sughosh Ganu  wrote:
>
> On Tue Nov 27, 2018 at 11:00:51AM +0100, Ard Biesheuvel wrote:
> > On Tue, 27 Nov 2018 at 10:58, Sughosh Ganu  wrote:
> > >
> > > On Tue Nov 27, 2018 at 10:28:50AM +0100, Ard Biesheuvel wrote:
> > > > On Tue, 27 Nov 2018 at 09:50, Sughosh Ganu  wrote:
> > > > >
> > > > > On Tue Nov 27, 2018 at 09:38:24AM +0100, Ard Biesheuvel wrote:
> > > > > > On Tue, 27 Nov 2018 at 09:36, Sughosh Ganu  
> > > > > > wrote:
> > > > > > >
> > > > > > > hi Ard,
> > > > > > >
> > > > > > > On Tue Nov 27, 2018 at 09:14:52AM +0100, Ard Biesheuvel wrote:
> > > > > > > > On Tue, 27 Nov 2018 at 07:20, Sughosh Ganu 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > From: Achin Gupta 
> > > > > > > > >
> > > > > > > > > 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 will still 
> > > > > > > > > request ARM
> > > > > > > > > TF to change the memory attributes of memory regions during
> > > > > > > > > initialization.
> > > > > > > > >
> > > > > > > > > The Standalone MM image is a FV that encapsulates the MM 
> > > > > > > > > foundation
> > > > > > > > > and drivers. These are PE-COFF images with data and text 
> > > > > > > > > segments.
> > > > > > > > > To initialise the MM environment, Arm Trusted Firmware has to 
> > > > > > > > > create
> > > > > > > > > translation tables with sane default attributes for the memory
> > > > > > > > > occupied by the FV. This library sends SVCs to ARM Trusted 
> > > > > > > > > Firmware
> > > > > > > > > to request memory permissions change for data and text 
> > > > > > > > > segments.
> > > > > > > > >
> > > > > > > > > This patch adds a simple MMU library suitable for execution 
> > > > > > > > > in S-EL0 and
> > > > > > > > > requesting memory permissions change operations from Arm 
> > > > > > > > > Trusted Firmware.
> > > > > > > > >
> > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > > > > ---
> > > > > > > > >  ArmPkg/ArmPkg.dec
> > > > > > > > >   
> > > > > > > > >  |   1 +
> > > > > > > > >  
> > > > > > > > > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> > > > > > > > >  => 
> > > > > > > > > ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf | 
> > > > > > > > >  23 +--
> > > > > > > > >  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h} 
> > > > > > > > >   
> > > > > > > > >  |  38 +---
> > > > > > > > >  
> > > > > > > > > ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > > >   
> > > > > > > > >  | 185 
> > > > > > > > >  4 files changed, 203 insertions(+), 44 deletions(-)
> > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > > > +#endif /* __STANDALONEMM_MMU_LIB__ */
> > > > > > > > > diff --git 
> > > > > > > > > a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > > >  
> > > > > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > > > new file mode 100644
> > > > > > > > > index ..d7d87b7d5d69
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ 
> > > > > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > > > @@ -0,0 +1,185 @@
> > > > > > > > > +/** @file
> > > > > > > > > +*  File managing the MMU for ARMv8 architecture in S-EL0
> > > > > > > > > +*
> > > > > > > > > +*  Copyright (c) 2017 - 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 
> > > > > > > >
> > > > > > > > Why do you need this

Re: [edk2] [PATCH v4 5/5] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

2018-11-27 Thread Sughosh Ganu

On Tue Nov 27, 2018 at 11:00:51AM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 10:58, Sughosh Ganu  wrote:
> >
> > On Tue Nov 27, 2018 at 10:28:50AM +0100, Ard Biesheuvel wrote:
> > > On Tue, 27 Nov 2018 at 09:50, Sughosh Ganu  wrote:
> > > >
> > > > On Tue Nov 27, 2018 at 09:38:24AM +0100, Ard Biesheuvel wrote:
> > > > > On Tue, 27 Nov 2018 at 09:36, Sughosh Ganu  
> > > > > wrote:
> > > > > >
> > > > > > hi Ard,
> > > > > >
> > > > > > On Tue Nov 27, 2018 at 09:14:52AM +0100, Ard Biesheuvel wrote:
> > > > > > > On Tue, 27 Nov 2018 at 07:20, Sughosh Ganu  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > From: Achin Gupta 
> > > > > > > >
> > > > > > > > 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 will still 
> > > > > > > > request ARM
> > > > > > > > TF to change the memory attributes of memory regions during
> > > > > > > > initialization.
> > > > > > > >
> > > > > > > > The Standalone MM image is a FV that encapsulates the MM 
> > > > > > > > foundation
> > > > > > > > and drivers. These are PE-COFF images with data and text 
> > > > > > > > segments.
> > > > > > > > To initialise the MM environment, Arm Trusted Firmware has to 
> > > > > > > > create
> > > > > > > > translation tables with sane default attributes for the memory
> > > > > > > > occupied by the FV. This library sends SVCs to ARM Trusted 
> > > > > > > > Firmware
> > > > > > > > to request memory permissions change for data and text segments.
> > > > > > > >
> > > > > > > > This patch adds a simple MMU library suitable for execution in 
> > > > > > > > S-EL0 and
> > > > > > > > requesting memory permissions change operations from Arm 
> > > > > > > > Trusted Firmware.
> > > > > > > >
> > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > > > ---
> > > > > > > >  ArmPkg/ArmPkg.dec  
> > > > > > > > 
> > > > > > > >  |   1 +
> > > > > > > >  
> > > > > > > > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> > > > > > > >  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf 
> > > > > > > > |  23 +--
> > > > > > > >  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h}   
> > > > > > > > 
> > > > > > > >  |  38 +---
> > > > > > > >  
> > > > > > > > ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > > 
> > > > > > > >| 185 
> > > > > > > >  4 files changed, 203 insertions(+), 44 deletions(-)
> > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > > > +#endif /* __STANDALONEMM_MMU_LIB__ */
> > > > > > > > diff --git 
> > > > > > > > a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > >  
> > > > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > > new file mode 100644
> > > > > > > > index ..d7d87b7d5d69
> > > > > > > > --- /dev/null
> > > > > > > > +++ 
> > > > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > > @@ -0,0 +1,185 @@
> > > > > > > > +/** @file
> > > > > > > > +*  File managing the MMU for ARMv8 architecture in S-EL0
> > > > > > > > +*
> > > > > > > > +*  Copyright (c) 2017 - 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 
> > > > > > >
> > > > > > > Why do you need this include? If you can drop it, can you also 
> > > > > > > make
> > > > > > > the library generic (i.e., supporting ARM as well as AArch64) ?
> > > > > > >
> > > > > > > (apologies for not spotting this before)
> > > > > >
> > > > > > I can remove the header file if it is superfluous. But regarding 
> > > > > > your

Re: [edk2] [PATCH v4 5/5] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

2018-11-27 Thread Sughosh Ganu

On Tue Nov 27, 2018 at 10:28:50AM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 09:50, Sughosh Ganu  wrote:
> >
> > On Tue Nov 27, 2018 at 09:38:24AM +0100, Ard Biesheuvel wrote:
> > > On Tue, 27 Nov 2018 at 09:36, Sughosh Ganu  wrote:
> > > >
> > > > hi Ard,
> > > >
> > > > On Tue Nov 27, 2018 at 09:14:52AM +0100, Ard Biesheuvel wrote:
> > > > > On Tue, 27 Nov 2018 at 07:20, Sughosh Ganu  
> > > > > wrote:
> > > > > >
> > > > > > From: Achin Gupta 
> > > > > >
> > > > > > 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 will still request 
> > > > > > ARM
> > > > > > TF to change the memory attributes of memory regions during
> > > > > > initialization.
> > > > > >
> > > > > > The Standalone MM image is a FV that encapsulates the MM foundation
> > > > > > and drivers. These are PE-COFF images with data and text segments.
> > > > > > To initialise the MM environment, Arm Trusted Firmware has to create
> > > > > > translation tables with sane default attributes for the memory
> > > > > > occupied by the FV. This library sends SVCs to ARM Trusted Firmware
> > > > > > to request memory permissions change for data and text segments.
> > > > > >
> > > > > > This patch adds a simple MMU library suitable for execution in 
> > > > > > S-EL0 and
> > > > > > requesting memory permissions change operations from Arm Trusted 
> > > > > > Firmware.
> > > > > >
> > > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > ---
> > > > > >  ArmPkg/ArmPkg.dec  
> > > > > > 
> > > > > >  |   1 +
> > > > > >  
> > > > > > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> > > > > >  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf |  
> > > > > > 23 +--
> > > > > >  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h}   
> > > > > > 
> > > > > >  |  38 +---
> > > > > >  ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c  
> > > > > > 
> > > > > >  | 185 
> > > > > >  4 files changed, 203 insertions(+), 44 deletions(-)
> > > >
> > > >
> > > > 
> > > >
> > > > > > +#endif /* __STANDALONEMM_MMU_LIB__ */
> > > > > > diff --git 
> > > > > > a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c 
> > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > new file mode 100644
> > > > > > index ..d7d87b7d5d69
> > > > > > --- /dev/null
> > > > > > +++ 
> > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > @@ -0,0 +1,185 @@
> > > > > > +/** @file
> > > > > > +*  File managing the MMU for ARMv8 architecture in S-EL0
> > > > > > +*
> > > > > > +*  Copyright (c) 2017 - 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 
> > > > >
> > > > > Why do you need this include? If you can drop it, can you also make
> > > > > the library generic (i.e., supporting ARM as well as AArch64) ?
> > > > >
> > > > > (apologies for not spotting this before)
> > > >
> > > > I can remove the header file if it is superfluous. But regarding your
> > > > comment on making this code generic for Arm as well, i guess we
> > > > can work on refactoring the code when/if we actually require to
> > > > support this on Arm. I am not sure if we are going to have a use-case
> > > > for StandaloneMM on Arm. Currently, we are only supporting it on
> > > > Aarch64 based platforms. Is that fine. Please let me know. Thanks.
> > > >
> > >
> > > I'd strongly prefer this code to be generic if you are not using any
> > > AArch64 specific facilities.
> > >
> > > AFAICT, we'd simply need to move the file out of the AArch64 directory
> > > and rename [Sources.AARCH64] to [Sources] in the .inf file if the
> > >

Re: [edk2] [PATCH v4 5/5] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 10:58, Sughosh Ganu  wrote:
>
> On Tue Nov 27, 2018 at 10:28:50AM +0100, Ard Biesheuvel wrote:
> > On Tue, 27 Nov 2018 at 09:50, Sughosh Ganu  wrote:
> > >
> > > On Tue Nov 27, 2018 at 09:38:24AM +0100, Ard Biesheuvel wrote:
> > > > On Tue, 27 Nov 2018 at 09:36, Sughosh Ganu  wrote:
> > > > >
> > > > > hi Ard,
> > > > >
> > > > > On Tue Nov 27, 2018 at 09:14:52AM +0100, Ard Biesheuvel wrote:
> > > > > > On Tue, 27 Nov 2018 at 07:20, Sughosh Ganu  
> > > > > > wrote:
> > > > > > >
> > > > > > > From: Achin Gupta 
> > > > > > >
> > > > > > > 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 will still 
> > > > > > > request ARM
> > > > > > > TF to change the memory attributes of memory regions during
> > > > > > > initialization.
> > > > > > >
> > > > > > > The Standalone MM image is a FV that encapsulates the MM 
> > > > > > > foundation
> > > > > > > and drivers. These are PE-COFF images with data and text segments.
> > > > > > > To initialise the MM environment, Arm Trusted Firmware has to 
> > > > > > > create
> > > > > > > translation tables with sane default attributes for the memory
> > > > > > > occupied by the FV. This library sends SVCs to ARM Trusted 
> > > > > > > Firmware
> > > > > > > to request memory permissions change for data and text segments.
> > > > > > >
> > > > > > > This patch adds a simple MMU library suitable for execution in 
> > > > > > > S-EL0 and
> > > > > > > requesting memory permissions change operations from Arm Trusted 
> > > > > > > Firmware.
> > > > > > >
> > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > > ---
> > > > > > >  ArmPkg/ArmPkg.dec
> > > > > > >   
> > > > > > >  |   1 +
> > > > > > >  
> > > > > > > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> > > > > > >  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf | 
> > > > > > >  23 +--
> > > > > > >  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h} 
> > > > > > >   
> > > > > > >  |  38 +---
> > > > > > >  
> > > > > > > ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c 
> > > > > > >   
> > > > > > > | 185 
> > > > > > >  4 files changed, 203 insertions(+), 44 deletions(-)
> > > > >
> > > > >
> > > > > 
> > > > >
> > > > > > > +#endif /* __STANDALONEMM_MMU_LIB__ */
> > > > > > > diff --git 
> > > > > > > a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > >  
> > > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > new file mode 100644
> > > > > > > index ..d7d87b7d5d69
> > > > > > > --- /dev/null
> > > > > > > +++ 
> > > > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > > > @@ -0,0 +1,185 @@
> > > > > > > +/** @file
> > > > > > > +*  File managing the MMU for ARMv8 architecture in S-EL0
> > > > > > > +*
> > > > > > > +*  Copyright (c) 2017 - 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 
> > > > > >
> > > > > > Why do you need this include? If you can drop it, can you also make
> > > > > > the library generic (i.e., supporting ARM as well as AArch64) ?
> > > > > >
> > > > > > (apologies for not spotting this before)
> > > > >
> > > > > I can remove the header file if it is superfluous. But regarding your
> > > > > comment on making this code generic for Arm as well, i guess we
> > > > > can work on refactoring the code when/if we actually require to
> > > > > support this on Arm. I am not sure if we are going to have a use-case
> > > > > for StandaloneMM on Arm. Currently, we are only supporting it on
> > > > > Aarch64

Re: [edk2] [PATCH] [edk2-test][PATCH v2] SctPkg/build: Add support for GenBin tool build

2018-11-27 Thread Philippe Mathieu-Daudé

Hi,

On 27/11/18 9:35, Lokesh B V wrote:
> As the GenBin tool is necessary for SCT build, it is appropriate to
> support it's build in the SCT build procedure.
> 
> SctPkg/Tools: Fix incorrect line ending detection by GenBin tool
> 
> Some windows editors uses "\r\n" for line feed. While processing uefi testcase
> info file, the GenBin tool logic to skip line feed doesn't consider the 
> presence
> of carraige return(\r) in line feed. So this results in incorrect format 
> error.

Minor typo: "carriage"

> 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V 
> ---
>  .gitignore   |  1 +
>  uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c |  3 +++
>  uefi-sct/SctPkg/build.sh | 31 
> 
>  3 files changed, 22 insertions(+), 13 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 821ed66..3b8d818 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,2 +1,3 @@
>  Build/
>  tags/
> +*.[od]
> diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
> b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> index 61bb35b..4eaefcc 100644
> --- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> +++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> @@ -2,6 +2,7 @@
>  
>Copyright 2006 - 2010 Unified EFI, Inc.
>Copyright (c) 2010 Intel Corporation. All rights reserved.
> +  Copyright (c) 2018 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
> @@ -176,6 +177,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
>  if ((String[Index1] != ' ' ) &&
>  (String[Index1] != '\t') &&
> +(String[Index1] != '\r') &&
>  (String[Index1] != '\n')) {
>break;
>  }
> @@ -193,6 +195,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
>  if ((String[Length - 1 - Index1] != ' ' ) &&
>  (String[Length - 1 - Index1] != '\t') &&
> +(String[Length - 1 - Index1] != '\r') &&
>  (String[Length - 1 - Index1] != '\n')) {
>break;
>  }
> diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
> index 73581c9..6198532 100755
> --- a/uefi-sct/SctPkg/build.sh
> +++ b/uefi-sct/SctPkg/build.sh
> @@ -1,7 +1,7 @@
>  #!/bin/bash
>  #
>  #  Copyright 2006 - 2015 Unified EFI, Inc.
> -#  Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2011 - 2018, 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
> @@ -228,21 +228,26 @@ else
>echo using prebuilt tools
>  fi
>  
> -# Copy GenBin file to Base tools directory
> +if  [[ ! -e $EDK_TOOLS_PATH/Source/C/bin/GenBin ]]
> +then
> +  # build the GenBin if it doesn't yet exist
> +  echo Building GenBin
> +  make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin
> +  status=$?
> +  if test $status -ne 0
> +  then
> +  echo Error while building GenBin
> +exit -1
> +  fi
> +else
> +  echo using prebuilt GenBin
> +fi
> +
> +# Copy GenBin file to Base tools bin directory
>  DEST_DIR=`GetEdkToolsPathBinDirectory`
>  # Ensure the directory exist
>  mkdir -p $DEST_DIR
> -case `uname -m` in 
> - x86_64)
> - cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin
> - ;;
> - x86_32)
> - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> - ;;
> - *)
> - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> - ;;
> -esac
> +cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin
>  
>  #
>  # Build the SCT package
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-platforms] [PATCH v2 1/2] Readme.md: Update instructions to fetch source

2018-11-27 Thread Nariman Poushin

Openssl is fetched as a git submodule, so make sure git clone --recursive
is specified in the instructions to fetch a full source tree.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nariman Poushin 
---

Resending v2, which addresses the lack of a Contribution Agreement tag.

Changes since v1:

- Added Contribution Agreement tag

 Readme.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Readme.md b/Readme.md
index 6ad5953..bb53c6f 100644
--- a/Readme.md
+++ b/Readme.md
@@ -78,7 +78,7 @@ target-specific binutils. These are included with any 
prepackaged GCC toolchain
1. [edk2-non-osi](https://github.com/tianocore/edk2-non-osi) (if building
   platforms that need it)
```
-   $ git clone https://github.com/tianocore/edk2.git
+   $ git clone https://github.com/tianocore/edk2.git --recursive
...
$ git clone https://github.com/tianocore/edk2-platforms.git
...
-- 
2.7.4


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

Re: [edk2] [edk2-announce] Research Request

2018-11-27 Thread Knop, Ryszard

To add on Phabricator not supporting Travis CI - since Travis works exclusively 
with GitHub and has zero interest in supporting anything else, there are other 
options, eg Harbormaster ("native" CI module in Phabricator) or Jenkins (as far 
as I'm aware, many teams at Intel already know Jenkins one way or another). For 
a public example, KDE hosts all their sources on a self-hosted Phabricator 
instance and does CI with Jenkins - see https://build.kde.org/ and 
https://phabricator.kde.org/ - so that's not a problem :)

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeremiah 
Cox via edk2-devel
Sent: Monday, November 26, 2018 22:43
To: stephano 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce] Research Request

Feedback on GitHub as follows…


> 1. No Lock-In - What automated data export is available?
> We want to be able to leave and take all our data with us. "Data" here
> includes: review comments, pull requests / patches (including 
> metadata), old (rejected) pull requests and metadata, issue tracker 
> entries and comments (if issue tracker included). This archiving 
> should be automated, not something we do by hand.

Untested, but might these all be easily satisfied by subscribing a mailing list 
to GitHub notifications?  
https://help.github.com/articles/about-notifications/#watching-notifications
https://help.github.com/articles/about-email-notifications/ 

Alternatively, the GitHub REST API appear to offer full export capability of 
all information & metadata:
   https://developer.github.com/v3/git/commits/#get-a-commit 
   https://developer.github.com/v3/pulls/#list-pull-requests
   
https://developer.github.com/v3/pulls/comments/#list-comments-on-a-pull-request
   https://developer.github.com/v3/issues/events/#list-events-for-a-repository
   https://developer.github.com/v3/issues/comments/#list-comments-on-an-issue 
   https://developer.github.com/v3/activity/events/#list-repository-events 
   
https://developer.github.com/v3/reactions/#list-reactions-for-a-pull-request-review-comment
 
   * the above allows you to export all of the thumbs up/down, smileys, hearts 
... that users have given to pull request & issue comments  :)



> 2. Easy Administration - Are there any scripts or custom code required 
> after initial setup? We would like to do as little customizing as possible.

Our interpretation of this bullet is to maximize developer productivity & 
minimize deployment & operations costs.  
GitHub provides a ready-to-use, end-to-end solution. There are no servers for 
end-customers to patch & maintain.
GitHub is free for use by open source projects, and Microsoft is committed to 
continuing this tradition:
https://www.microsoft.com/en-us/Investor/events/FY-2018/Microsoft-and-GitHub-Conference-Call
GitHub’s enormous user base has motivated numerous developers to generate 
GitHub Apps that further enhance the GitHub experience.  



> 3. Flexible Workflow - Can we use email patches / email review as well 
> as pull requests / web UI review?**
>   3a. Can we can attach review comments to specific code *and* commit 
> message locations?
>   3b. Are the comments faithfully translated to notification emails 
> (including the locations in code the comment is addressing)?
>   3c. Are old topic branches (rejected or updated pull requests) 
> available even after being rejected? (i.e. are they ever deleted?)
>   3d. Is plain text supported in code review comments?
> **To be clear, it is acceptable if the system handles only pull requests 
> and a web UI. We do require, however, a *read-only* email notification 
> system that thoroughly documents our process.

We propose that all review & issue tracking are through GitHub web, REST, or 
Graph APIs.  Email becomes read-only for notification and archival only.
3A:  Yes.
3B:  From our testing this appears to be yes.
3C:  GitHub can be configured to keep rejected and updated pull requests.  
3D:  Both plain text and markdown work



Some additional questions we feel are important:


*  Does the workflow facilitate automated validation & PR-Gates?  
GitHub: Yes
Phabricator:  https://secure.phabricator.com/T9456 : “Writing lots of 
integrations for third-party software is broadly something the upstream is not 
well equipped for.”
Travis-CI further declined support for Phabricator: 
https://github.com/travis-ci/travis-ci/issues/2143#issuecomment-124150608 “we 
have no immediate plans to add this feature”


*  Does workflow allow easy contribution process?  
GitHub:  Yes, well-known and well-documented


* Does it have comprehensive documentation?
GitHub:  Yes


*  Does it have a comprehensive programmatic API that enables extensibility, 
with numerous online examples?
GitHub:  Yes 


*  Does workflow facilitate different server-enforced policies for different 
branches?
GitHub:  Yes 



Sincerely,
Jeremiah Cox


-Original Message-
From: stephano  
Sent: Tuesday, November 20, 2018

Re: [edk2] [PATCH v2 2/2] Edk2Platforms: Replace MdeModulePkg PXE/iSCSI/TCP with NetworkPkg drivers.

2018-11-27 Thread Thomas Abraham

Hi Siyuan,

On Tue, Nov 27, 2018 at 2:22 PM Fu, Siyuan  wrote:
>
> Hi, Thomas
>
> > -Original Message-
> > From: Thomas Abraham [mailto:thomas.abra...@arm.com]
> > Sent: Friday, November 9, 2018 9:56 PM
> > To: Leif Lindholm 
> > Cc: Fu, Siyuan ; Kinney, Michael D
> > ; edk2-devel@lists.01.org
> > Subject: Re: [edk2] [PATCH v2 2/2] Edk2Platforms: Replace MdeModulePkg
> > PXE/iSCSI/TCP with NetworkPkg drivers.
> >
> > On Wed, Nov 7, 2018 at 1:55 PM Leif Lindholm  
> > wrote:
> > >
> > > Hi Fu Siyan,
> > >
> > > On Wed, Nov 07, 2018 at 08:12:55AM +, Fu, Siyuan wrote:
> > > > Hi, Leif and Ard
> > > >
> > > > I just realized that you may not be CCed in this email. I resent these
> > patches a few minutes ago, my Git Bash send-email reports it added you to CC
> > receiver, but the Outlook received email still doesn't have your name in CC
> > list.
> > > >
> > > > Do you have any comments for this v2 patch of the edk2platforms?
> > > >
> > > >
> > > > BestRegards
> > > > Fu Siyuan
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Fu
> > > > > Siyuan
> > > > > Sent: Monday, November 5, 2018 9:33 AM
> > > > > To: edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D 
> > > > > Subject: [edk2] [PATCH v2 2/2] Edk2Platforms: Replace MdeModulePkg
> > > > > PXE/iSCSI/TCP with NetworkPkg drivers.
> > > > >
> > > > > V2:
> > > > > Additional fixups required for NetworkPkg migration
> > >
> > > Revision history like this belongs in the cover letter.
> > >
> > > > > The PXE/iSCSI/TCP drivers in MdeModulePkg are going to be deprecated.
> > All
> > > > > platform DSC/FDF files should be updated to use the dual-stack drivers
> > in
> > > > > NetworkPkg.
> > > > >
> > > > > The NetworkPkg driver have all the functionality compared with
> > > > > MdeModulePkg
> > > > > one, with more bug fixes and new feature added. While its image size
> > will
> > > > > be a little bigger because it contains both IPv4 and IPv6 stack 
> > > > > support,
> > > > > so it may cause build error in a platform if the flash space is very
> > tight.
> > > > > Basically, this patch won't cause any other problem if build could 
> > > > > pass.
> > > > >
> > > > > I haven't built all the updated platform because the repo ReadMe 
> > > > > doesn't
> > > > > provide a method to build them on Windows Environment, so I would very
> > > > > appreciate if anybody can help to test the build or tell me how to 
> > > > > build
> > > > > it on Windows.
> > >
> > > And comments like the paragraph above belong in the cover letter or
> > > below the ---
> > > If you are OK with me deleting these bits before committing:
> > > Reviewed-by: Leif Lindholm 
> > >
> > > /
> > > Leif
> > >
> > > > >
> > > > > Cc: Ard Biesheuvel 
> > > > > Cc: Leif Lindholm 
> > > > > Cc: Michael D Kinney 
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Fu Siyuan 
> > > > > Signed-off-by: Leif Lindholm 
> > > > > ---
> > > > >  Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  |  6 
> > > > > +++---
> > > > >  Platform/AMD/OverdriveBoard/OverdriveBoard.fdf  |  6 
> > > > > +++---
> > > > >  Platform/ARM/SgiPkg/SgiPlatform.fdf |  6 
> > > > > +++---
> > > > >  Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc   |  1 +
> > > > >  Platform/ARM/VExpressPkg/ArmVExpress-networking.fdf.inc |  6 
> > > > > +++---
> > > > >  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc| 13
> > +++-
> > > > > -
> > > > >  Platform/Comcast/RDKQemu/RDKQemu.dsc| 10 
> > > > > +++---
> > --
> > > > > --
> > > > >  Platform/Hisilicon/D03/D03.dsc  |  4 ++--
> > > > >  Platform/Hisilicon/D03/D03.fdf  |  4 ++--
> > > > >  Platform/Hisilicon/D05/D05.dsc  | 11 
> > > > > +++---
> > --
> > > > > ---
> > > > >  Platform/Hisilicon/D05/D05.fdf  |  9 
> > > > > +++---
> > --
> > > > > -
> > > > >  Platform/Hisilicon/D06/D06.dsc  | 11 
> > > > > +++---
> > --
> > > > > ---
> > > > >  Platform/Hisilicon/D06/D06.fdf  |  9 
> > > > > +++---
> > --
> > > > > -
> > > > >  Platform/Hisilicon/HiKey/HiKey.dsc  |  4 ++--
> > > > >  Platform/Hisilicon/HiKey/HiKey.fdf  |  4 ++--
> > > > >  Platform/Hisilicon/HiKey960/HiKey960.dsc|  4 ++--
> > > > >  Platform/Hisilicon/HiKey960/HiKey960.fdf|  4 ++--
> > > > >  Platform/LeMaker/CelloBoard/CelloBoard.dsc  | 11
> > > > > ---
> > > > >  Platform/LeMaker/CelloBoard/CelloBoard.fdf  |  6 
> > > > > +++---
> > > > >  Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc |  6 
> > > > > +++---
> > > > >  Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.fdf |

Re: [edk2] [PATCH v4 5/5] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

2018-11-27 Thread Ard Biesheuvel

On Tue, 27 Nov 2018 at 09:50, Sughosh Ganu  wrote:
>
> On Tue Nov 27, 2018 at 09:38:24AM +0100, Ard Biesheuvel wrote:
> > On Tue, 27 Nov 2018 at 09:36, Sughosh Ganu  wrote:
> > >
> > > hi Ard,
> > >
> > > On Tue Nov 27, 2018 at 09:14:52AM +0100, Ard Biesheuvel wrote:
> > > > On Tue, 27 Nov 2018 at 07:20, Sughosh Ganu  wrote:
> > > > >
> > > > > From: Achin Gupta 
> > > > >
> > > > > 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 will still request 
> > > > > ARM
> > > > > TF to change the memory attributes of memory regions during
> > > > > initialization.
> > > > >
> > > > > The Standalone MM image is a FV that encapsulates the MM foundation
> > > > > and drivers. These are PE-COFF images with data and text segments.
> > > > > To initialise the MM environment, Arm Trusted Firmware has to create
> > > > > translation tables with sane default attributes for the memory
> > > > > occupied by the FV. This library sends SVCs to ARM Trusted Firmware
> > > > > to request memory permissions change for data and text segments.
> > > > >
> > > > > This patch adds a simple MMU library suitable for execution in S-EL0 
> > > > > and
> > > > > requesting memory permissions change operations from Arm Trusted 
> > > > > Firmware.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Sughosh Ganu 
> > > > > ---
> > > > >  ArmPkg/ArmPkg.dec
> > > > >   
> > > > >  |   1 +
> > > > >  
> > > > > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> > > > >  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf |  23 
> > > > > +--
> > > > >  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h} 
> > > > >   
> > > > >  |  38 +---
> > > > >  ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > >   
> > > > >  | 185 
> > > > >  4 files changed, 203 insertions(+), 44 deletions(-)
> > >
> > >
> > > 
> > >
> > > > > +#endif /* __STANDALONEMM_MMU_LIB__ */
> > > > > diff --git 
> > > > > a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c 
> > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > new file mode 100644
> > > > > index ..d7d87b7d5d69
> > > > > --- /dev/null
> > > > > +++ 
> > > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > > @@ -0,0 +1,185 @@
> > > > > +/** @file
> > > > > +*  File managing the MMU for ARMv8 architecture in S-EL0
> > > > > +*
> > > > > +*  Copyright (c) 2017 - 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 
> > > >
> > > > Why do you need this include? If you can drop it, can you also make
> > > > the library generic (i.e., supporting ARM as well as AArch64) ?
> > > >
> > > > (apologies for not spotting this before)
> > >
> > > I can remove the header file if it is superfluous. But regarding your
> > > comment on making this code generic for Arm as well, i guess we
> > > can work on refactoring the code when/if we actually require to
> > > support this on Arm. I am not sure if we are going to have a use-case
> > > for StandaloneMM on Arm. Currently, we are only supporting it on
> > > Aarch64 based platforms. Is that fine. Please let me know. Thanks.
> > >
> >
> > I'd strongly prefer this code to be generic if you are not using any
> > AArch64 specific facilities.
> >
> > AFAICT, we'd simply need to move the file out of the AArch64 directory
> > and rename [Sources.AARCH64] to [Sources] in the .inf file if the
> > header dependency is indeed superfluous.
>
> There are a couple of places where we use something like
> ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64. Apart from this, it is
> generic.
>

And how do these deviate from their AArch32 counterparts?

I agree that ARM support is not essential right now, or perhaps

Re: [edk2] [PATCH v4 5/5] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.

2018-11-27 Thread Sughosh Ganu

On Tue Nov 27, 2018 at 09:38:24AM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 09:36, Sughosh Ganu  wrote:
> >
> > hi Ard,
> >
> > On Tue Nov 27, 2018 at 09:14:52AM +0100, Ard Biesheuvel wrote:
> > > On Tue, 27 Nov 2018 at 07:20, Sughosh Ganu  wrote:
> > > >
> > > > From: Achin Gupta 
> > > >
> > > > 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 will still request ARM
> > > > TF to change the memory attributes of memory regions during
> > > > initialization.
> > > >
> > > > The Standalone MM image is a FV that encapsulates the MM foundation
> > > > and drivers. These are PE-COFF images with data and text segments.
> > > > To initialise the MM environment, Arm Trusted Firmware has to create
> > > > translation tables with sane default attributes for the memory
> > > > occupied by the FV. This library sends SVCs to ARM Trusted Firmware
> > > > to request memory permissions change for data and text segments.
> > > >
> > > > This patch adds a simple MMU library suitable for execution in S-EL0 and
> > > > requesting memory permissions change operations from Arm Trusted 
> > > > Firmware.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Sughosh Ganu 
> > > > ---
> > > >  ArmPkg/ArmPkg.dec  
> > > > 
> > > >  |   1 +
> > > >  
> > > > ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> > > >  => ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf |  23 
> > > > +--
> > > >  ArmPkg/Include/Library/{ArmMmuLib.h => StandaloneMmMmuLib.h}   
> > > > 
> > > >  |  38 +---
> > > >  ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c  
> > > > 
> > > >  | 185 
> > > >  4 files changed, 203 insertions(+), 44 deletions(-)
> >
> >
> > 
> >
> > > > +#endif /* __STANDALONEMM_MMU_LIB__ */
> > > > diff --git 
> > > > a/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c 
> > > > b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > new file mode 100644
> > > > index ..d7d87b7d5d69
> > > > --- /dev/null
> > > > +++ b/ArmPkg/Library/StandaloneMmMmuLib/Aarch64/ArmMmuStandaloneMmLib.c
> > > > @@ -0,0 +1,185 @@
> > > > +/** @file
> > > > +*  File managing the MMU for ARMv8 architecture in S-EL0
> > > > +*
> > > > +*  Copyright (c) 2017 - 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 
> > >
> > > Why do you need this include? If you can drop it, can you also make
> > > the library generic (i.e., supporting ARM as well as AArch64) ?
> > >
> > > (apologies for not spotting this before)
> >
> > I can remove the header file if it is superfluous. But regarding your
> > comment on making this code generic for Arm as well, i guess we
> > can work on refactoring the code when/if we actually require to
> > support this on Arm. I am not sure if we are going to have a use-case
> > for StandaloneMM on Arm. Currently, we are only supporting it on
> > Aarch64 based platforms. Is that fine. Please let me know. Thanks.
> >
> 
> I'd strongly prefer this code to be generic if you are not using any
> AArch64 specific facilities.
> 
> AFAICT, we'd simply need to move the file out of the AArch64 directory
> and rename [Sources.AARCH64] to [Sources] in the .inf file if the
> header dependency is indeed superfluous.

There are a couple of places where we use something like
ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64. Apart from this, it is
generic.

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

1 2 >

1 - 100 of 109 matches

Mail list logo