Re: [edk2] [PATCH] CryptoPkg/IntrinsicLib: add missing BaseLib declaration

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Wang, Jian J 
Sent: Thursday, December 6, 2018 1:46 PM
To: edk2-devel@lists.01.org
Cc: Long, Qin ; Ye, Ting 
Subject: [PATCH] CryptoPkg/IntrinsicLib: add missing BaseLib declaration

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

BaseLib interfaces are used in this library but not declared in module's inf 
file. This patch fix this situation to keep inf and its code in consistency. No 
functionality or interface change are involved.

Cc: Qin Long 
Cc: Ting Ye 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf 
b/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
index 579da34aff..a91c850013 100644
--- a/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
+++ b/CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
@@ -51,6 +51,7 @@
   MdePkg/MdePkg.dec
 
 [LibraryClasses]
+  BaseLib
   BaseMemoryLib
 
 [BuildOptions]
--
2.19.0.windows.1

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

Re: [edk2] [PATCH] Platform/ARM/SgiPkg: Add support for HDLCD

[Vijayenthiran Subramaniam]

On Thu, Dec 6, 2018 at 5:08 PM Ard Biesheuvel  wrote:
>
> On Thu, 6 Dec 2018 at 13:43, Vijayenthiran Subramaniam
>  wrote:
> >
> > Add HDLCD platform library for SGI platform that implements platform
> > callbacks for the Arm HDLCD driver.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Vijayenthiran Subramaniam 
> > ---
> >  Platform/ARM/SgiPkg/SgiPlatform.dsc   |   6 +
> >  Platform/ARM/SgiPkg/SgiPlatform.fdf   |   6 +
> >  Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf |  37 +++
> >  Platform/ARM/SgiPkg/Include/SgiPlatform.h |   4 +
> >  Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgi.c  | 262 
> > 
> >  Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c  |   8 +-
> >  6 files changed, 322 insertions(+), 1 deletion(-)
> >
> > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
> > b/Platform/ARM/SgiPkg/SgiPlatform.dsc
> > index 0c794c6b299d..7995c7d132d6 100644
> > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc
> > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc
> > @@ -37,6 +37,8 @@ [LibraryClasses.common]
> >ArmPlatformLib|Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
> >BasePathLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >
> > EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
> > +  LcdHwLib|ArmPlatformPkg/Library/HdLcd/HdLcd.inf
> > +  
> > LcdPlatformLib|Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
> >
> > NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/NorFlashLib.inf
> >HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> >TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> > @@ -155,6 +157,9 @@ [PcdsFixedAtBuild.common]
> >gArmPlatformTokenSpaceGuid.PL011UartInteger|4
> >gArmPlatformTokenSpaceGuid.PL011UartFractional|0
> >
> > +  ## PL370 - HDLCD1
> > +  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x7FF6
> > +
> >## PL011 - Serial Debug UART
> >gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase|0x7FF8
> >gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz|7372800
> > @@ -235,6 +240,7 @@ [Components.common]
> >ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> >ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> >ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
> > +  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
> >ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
> >EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
> >EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
> > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.fdf 
> > b/Platform/ARM/SgiPkg/SgiPlatform.fdf
> > index ddf1fda5a16e..80c3412fd4ad 100644
> > --- a/Platform/ARM/SgiPkg/SgiPlatform.fdf
> > +++ b/Platform/ARM/SgiPkg/SgiPlatform.fdf
> > @@ -133,6 +133,9 @@ [FV.FvMain]
> >#
> ># Multiple Console IO support
> >#
> > +  INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
> > +  INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> > +  INF 
> > MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
> >INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> >INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> >
> > @@ -144,6 +147,9 @@ [FV.FvMain]
> >INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
> >INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> >
> > +  # Graphics Output Protocol
> > +  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
> > +
> >INF Platform/ARM/Drivers/BootMonFs/BootMonFs.inf
> >INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> >
> > diff --git a/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf 
> > b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
> > new file mode 100644
> > index ..25efbea5fb83
> > --- /dev/null
> > +++ b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
> > @@ -0,0 +1,37 @@
> > +#
> > +#  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= 0x0001001A
> > +  BASE_NAME  = HdLcdArmSgiLib
> > +  FILE_GUID  = 0C77342C-7895-4DE1-A9C8-1DBBFA71AF34
> > +  MODULE_TYPE= BASE
> > +  VERSION_STRING = 1.0
> > +  LIBRARY_CLASS  = LcdPlatformLib
> > +
> > +[Sources.common]
> > +  HdLcdArmSgi.c
> > +
> > 

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

[Rebecca Cran via edk2-devel]

On Thursday, 6 December 2018 07:13:24 MST Laszlo Ersek wrote:

> They don't contain any code (diff hunks). I hope I can change that in my
> email preferences (I haven't gotten around checking those yet). 

I've updated the Mail settings to inline diffs up to 200 lines, and also 
attach diffs to the emails. It sends git-style diffs - it can also be 
configured to send unified diffs instead.

>   nore...@phabricator.example.com
> 
> That doesn't look right even for this testing; can you please update the
> config? I believe the emails should come from a sender @
> code.bluestop.org. Is that correct?

I've configured it to send from p...@bluestop.org .

I'm sure there are other things that aren't properly configured (for example, 
I've not set it up so you can reply to emails and have those replies be added 
to the review), but hopefully it gives you an idea of what it can do.

-- 
Rebecca


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

[edk2] [PATCH v2 edk2-platforms] Platform/ARM/SgiPkg: Add support for HDLCD

[Vijayenthiran Subramaniam]

Add HDLCD platform library for SGI platform that implements platform
callbacks for the Arm HDLCD driver.

Change-Id: I6cdca16bd69eeadeeb879dd5fe9acc72a12fbf2f
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vijayenthiran Subramaniam 
---
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |   6 +
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   6 +
 Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf |  40 +++
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |   4 +
 Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgi.c  | 257 

 Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c  |   8 +-
 6 files changed, 320 insertions(+), 1 deletion(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
b/Platform/ARM/SgiPkg/SgiPlatform.dsc
index 0c794c6b299d..7995c7d132d6 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc
@@ -37,6 +37,8 @@ [LibraryClasses.common]
   ArmPlatformLib|Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
   BasePathLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
   
EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
+  LcdHwLib|ArmPlatformPkg/Library/HdLcd/HdLcd.inf
+  LcdPlatformLib|Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
   NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/NorFlashLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
@@ -155,6 +157,9 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PL011UartInteger|4
   gArmPlatformTokenSpaceGuid.PL011UartFractional|0
 
+  ## PL370 - HDLCD1
+  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x7FF6
+
   ## PL011 - Serial Debug UART
   gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase|0x7FF8
   gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz|7372800
@@ -235,6 +240,7 @@ [Components.common]
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
   EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
diff --git a/Platform/ARM/SgiPkg/SgiPlatform.fdf 
b/Platform/ARM/SgiPkg/SgiPlatform.fdf
index ddf1fda5a16e..80c3412fd4ad 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.fdf
+++ b/Platform/ARM/SgiPkg/SgiPlatform.fdf
@@ -133,6 +133,9 @@ [FV.FvMain]
   #
   # Multiple Console IO support
   #
+  INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
+  INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
+  INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
   INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
 
@@ -144,6 +147,9 @@ [FV.FvMain]
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
 
+  # Graphics Output Protocol
+  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
+
   INF Platform/ARM/Drivers/BootMonFs/BootMonFs.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
 
diff --git a/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf 
b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
new file mode 100644
index ..751f0d9288eb
--- /dev/null
+++ b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
@@ -0,0 +1,40 @@
+#
+#  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= 0x0001001A
+  BASE_NAME  = HdLcdArmSgiLib
+  FILE_GUID  = 0C77342C-7895-4DE1-A9C8-1DBBFA71AF34
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = LcdPlatformLib
+
+[Sources.common]
+  HdLcdArmSgi.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  MdePkg/MdePkg.dec
+  Platform/ARM/SgiPkg/SgiPlatform.dec
+
+[LibraryClasses]
+  BaseLib
+
+[FixedPcd]
+  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize
+  gArmPlatformTokenSpaceGuid.PcdGopPixelFormat
+
+[depex]
+  gEfiCpuArchProtocolGuid
diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 

Re: [edk2] [PATCH v1 edk2-platforms 1/8] Platform/ARM/SgiPkg: Restructure virtio device registration

[Vijayenthiran Subramaniam]

On Thu, Dec 6, 2018 at 5:18 PM Ard Biesheuvel  wrote:
>
> On Wed, 5 Dec 2018 at 07:10, Vijayenthiran Subramaniam
>  wrote:
> >
> > Hi Ard,
> >
> > The virtio block device and virtio network device are available in software 
> > model only. As of now, it exposes only one instance of each device.
> >
>
> Are the virtio devices described by the device tree obtained from the
> secure firmware?

No. The device tree from secure firmware does not carry any devices
information other than platform/config id.

>
> > On Tue, Dec 4, 2018 at 8:16 PM Ard Biesheuvel  
> > wrote:
> >>
> >> On Tue, 4 Dec 2018 at 10:12, Vijayenthiran Subramaniam
> >>  wrote:
> >> >
> >> > From: Daniil Egranov 
> >> >
> >> > SGI platforms support multiple virtio devices. So the existing code, that
> >> > supports registration of only the virtio disk, is restructured to
> >> > accommodate the registration of additional virtio devices.
> >> >
> >> > In addition to this, PCDs to represent the virtio controller base and
> >> > address space size are introduced.
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > Signed-off-by: Daniil Egranov 
> >> > ---
> >> >  Platform/ARM/SgiPkg/SgiPlatform.dec 
> >> >  |  8 ++-
> >> >  Platform/ARM/SgiPkg/SgiPlatform.dsc 
> >> >  |  7 +-
> >> >  Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf 
> >> >  |  8 ++-
> >> >  Platform/ARM/SgiPkg/Include/Guid/SgiVirtioDevicesFormSet.h  
> >> >  | 21 ++
> >> >  Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c   
> >> >  | 14 +---
> >> >  Platform/ARM/SgiPkg/Drivers/PlatformDxe/{VirtioBlockIo.c => 
> >> > VirtioDevices.c} | 67 
> >> >  6 files changed, 81 insertions(+), 44 deletions(-)
> >> >
> >>
> >> Can these platforms only ever expose a single block device and a
> >> single network device?
> >>
> >> > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec 
> >> > b/Platform/ARM/SgiPkg/SgiPlatform.dec
> >> > index f6e0ba1e927a..ed29a4d5d91f 100644
> >> > --- a/Platform/ARM/SgiPkg/SgiPlatform.dec
> >> > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
> >> > @@ -37,12 +37,16 @@ [Guids.common]
> >> >gSgiClarkHeliosAcpiTablesFileGuid = { 0x2af40815, 0xa84e, 0x4de9, { 
> >> > 0x8c, 0x38, 0x91, 0x40, 0xb3, 0x54, 0x40, 0x73 } }
> >> >
> >> >  [PcdsFeatureFlag.common]
> >> > -  # Set this PCD to TRUE to enable virtio support.
> >> > -  gArmSgiTokenSpaceGuid.PcdVirtioSupported|TRUE|BOOLEAN|0x0001
> >> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported|FALSE|BOOLEAN|0x0001
> >> >
> >> >  [PcdsFixedAtBuild]
> >> >gArmSgiTokenSpaceGuid.PcdDramBlock2Base|0|UINT64|0x0002
> >> >gArmSgiTokenSpaceGuid.PcdDramBlock2Size|0|UINT64|0x0003
> >> >
> >> > +  # Virtio Block device
> >> > +  
> >> > gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress|0x|UINT32|0x0004
> >> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSize|0x|UINT32|0x0005
> >> > +  
> >> > gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt|0x|UINT32|0x0006
> >> > +
> >> >  [Ppis]
> >> >gHwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 
> >> > 0x9b, 0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
> >> > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
> >> > b/Platform/ARM/SgiPkg/SgiPlatform.dsc
> >> > index b3f76d2d9720..ada72be72f8a 100644
> >> > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc
> >> > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc
> >> > @@ -98,7 +98,7 @@ [LibraryClasses.common.UEFI_DRIVER, 
> >> > LibraryClasses.common.UEFI_APPLICATION, Libr
> >> >  
> >> > 
> >> >
> >> >  [PcdsFeatureFlag.common]
> >> > -  gArmSgiTokenSpaceGuid.PcdVirtioSupported|TRUE
> >> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported|TRUE
> >> >
> >> >  [PcdsFixedAtBuild.common]
> >> >gArmTokenSpaceGuid.PcdVFPEnabled|1
> >> > @@ -180,6 +180,11 @@ [PcdsFixedAtBuild.common]
> >> ># Ethernet
> >> >gEmbeddedTokenSpaceGuid.PcdLan91xDxeBaseAddress|0x1800
> >> >
> >> > +  # Virtio Disk
> >> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress|0x1c13
> >> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSize|0x1
> >> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt|202
> >> > +
> >> >  
> >> > 
> >> >  #
> >> >  # Components Section - list of all EDK II Modules needed by this 
> >> > Platform
> >> > diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf 
> >> > b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
> >> > index d903ed8d3375..f920f6ecafb8 100644
> >> > --- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
> >> > +++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
> >> > @@ -20,7 +20,7 @@ [Defines]
> >> >
> >> >  [Sources.common]
> >> >PlatformDxe.c
> >> > -  VirtioBlockIo.c
> >> > +  

[edk2] Add wiki EDK-II-Release-Notes to record new added Wiki and update Notes in the release cycle

[Gao, Liming]

Hi, all
  EDK II Release Notes 
(https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Notes) is 
created to record the release information when the code change is pushed in 
edk2 trunk.

In this release cycle, if you implement new feature and add wiki page for this 
feature, please add this wiki page link into Release Notes. If you make the 
incompatible change, please add the update step into Release Notes.

Thanks
Liming
___
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 '*'

[Carsey, Jaben]

I will submit a new change with those changed back.

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Carsey, Jaben
> Sent: Thursday, December 6, 2018 4:50 PM
> To: Zhu, Yonghong ; edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: Re: [edk2] [Patch v1 1/1] BaseTools: create and use a standard
> shared variable for '*'
> Importance: High
> 
> How about undo those and push the remaining?  Since that's a very small
> change.
> 
> -Jaben
> 
> > -Original Message-
> > From: Zhu, Yonghong
> > Sent: Monday, December 3, 2018 5:53 PM
> > To: Carsey, Jaben ; edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Zhu, Yonghong
> > 
> > Subject: RE: [Patch v1 1/1] BaseTools: create and use a standard
> > shared variable for '*'
> > Importance: High
> >
> > Yes.  I prefer not to change it.
> >
> > Best Regards,
> > Zhu Yonghong
> >
> >
> > -Original Message-
> > From: Carsey, Jaben
> > Sent: Monday, December 03, 2018 11:19 PM
> > To: Zhu, Yonghong ; edk2-devel@lists.01.org
> > Cc: Gao, Liming 
> > Subject: RE: [Patch v1 1/1] BaseTools: create and use a standard
> > shared variable for '*'
> >
> > I was trying to change all use of *, without regard to the usage of it.
> >
> > Do you think that mathematical * should not be changed?
> >
> > -Jaben
> >
> > > -Original Message-
> > > From: Zhu, Yonghong
> > > Sent: Sunday, December 02, 2018 6:31 PM
> > > To: Carsey, Jaben ; edk2-devel@lists.01.org
> > > Cc: Gao, Liming ; Zhu, Yonghong
> > > 
> > > Subject: RE: [Patch v1 1/1] BaseTools: create and use a standard
> > > shared variable for '*'
> > > Importance: High
> > >
> > > Hi Jaben,
> > >
> > > In this patch, it also changed the mathematics multiplicative '*'
> > > (used in
> > > expression) to  TAB_STAR, is it by on purpose?
> > > Eg:
> > > -NonLetterOpLst = ['+', '-', '*', '/', '%', '&', '|', '^', '~', '<<', 
> > > '>>', '!', '=', '>',
> > '<',
> > > '?', ':']
> > > +NonLetterOpLst = ['+', '-', TAB_STAR, '/', '%', '&', '|', '^',
> > > + '~', '<<', '>>', '!', '=',
> > > '>', '<', '?', ':']
> > >
> > > Best Regards,
> > > Zhu Yonghong
> > >
> > > -Original Message-
> > > From: Carsey, Jaben
> > > Sent: Friday, November 16, 2018 11:40 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Zhu, Yonghong ; Gao, Liming
> > > 
> > > Subject: [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 ==

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

[Carsey, Jaben]

How about undo those and push the remaining?  Since that's a very small change.

-Jaben

> -Original Message-
> From: Zhu, Yonghong
> Sent: Monday, December 3, 2018 5:53 PM
> To: Carsey, Jaben ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zhu, Yonghong
> 
> Subject: RE: [Patch v1 1/1] BaseTools: create and use a standard shared
> variable for '*'
> Importance: High
> 
> Yes.  I prefer not to change it.
> 
> Best Regards,
> Zhu Yonghong
> 
> 
> -Original Message-
> From: Carsey, Jaben
> Sent: Monday, December 03, 2018 11:19 PM
> To: Zhu, Yonghong ; edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: RE: [Patch v1 1/1] BaseTools: create and use a standard shared
> variable for '*'
> 
> I was trying to change all use of *, without regard to the usage of it.
> 
> Do you think that mathematical * should not be changed?
> 
> -Jaben
> 
> > -Original Message-
> > From: Zhu, Yonghong
> > Sent: Sunday, December 02, 2018 6:31 PM
> > To: Carsey, Jaben ; edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Zhu, Yonghong
> > 
> > Subject: RE: [Patch v1 1/1] BaseTools: create and use a standard
> > shared variable for '*'
> > Importance: High
> >
> > Hi Jaben,
> >
> > In this patch, it also changed the mathematics multiplicative '*'
> > (used in
> > expression) to  TAB_STAR, is it by on purpose?
> > Eg:
> > -NonLetterOpLst = ['+', '-', '*', '/', '%', '&', '|', '^', '~', '<<', 
> > '>>', '!', '=', '>',
> '<',
> > '?', ':']
> > +NonLetterOpLst = ['+', '-', TAB_STAR, '/', '%', '&', '|', '^',
> > + '~', '<<', '>>', '!', '=',
> > '>', '<', '?', ':']
> >
> > Best Regards,
> > Zhu Yonghong
> >
> > -Original Message-
> > From: Carsey, Jaben
> > Sent: Friday, November 16, 2018 11:40 PM
> > To: edk2-devel@lists.01.org
> > Cc: Zhu, Yonghong ; Gao, Liming
> > 
> > Subject: [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 

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

[Gao, Liming]

Oh, this is a good point of runtime service in OS part. I agree to revert it. 

Reviewed-by: Liming Gao 

Thanks
Liming
>-Original Message-
>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>Sent: Friday, December 07, 2018 5:37 AM
>To: edk2-devel@lists.01.org
>Cc: Ard Biesheuvel ; Leif Lindholm
>; Gao, Liming ; Laszlo Ersek
>; Eric Auger ; Andrew Jones
>; Philippe Mathieu-Daude 
>Subject: [PATCH] Revert "MdePkg/ProcessorBind.h AARCH64: limit
>MAX_ADDRESS to 48 bits"
>
>This reverts commit 82379bf6603274e81604d5a6f6bb14bdde616286.
>
>On AArch64, we can only use 48 address bits while running in UEFI,
>while the GCD and UEFI memory maps may describe up to 52 bits of
>physical address space. For this reason, MAX_ADDRESS was reduced
>to 48 bits, to ensure that the firmware does not inadvertently
>attempt to allocate memory that we cannot access.
>
>However, MAX_ADDRESS is used in runtime drivers as well, and
>runtime drivers may deal with kernel virtual addresses, which have
>bits [63:48] set. In fact, the OS may be running with 64 KB pages
>and pass addresses into the runtime services that use up to 52
>bits of address space, either with the top bits set or cleared,
>even if the physical address space does not extend beyond 48 bits.
>
>In summary, changing MAX_ADDRESS is a mistake, and needs to be
>reverted.
>
>Cc: Leif Lindholm 
>Cc: Liming Gao 
>Cc: Laszlo Ersek 
>Cc: Eric Auger 
>Cc: Andrew Jones 
>Cc: Philippe Mathieu-Daude 
>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 dad75df1c579..968c18f915ae 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 (48 bits for 4 KB page size)
>+/// Maximum legal AARCH64  address
> ///
>-#define MAX_ADDRESS   0xULL
>+#define MAX_ADDRESS   0xULL
>
> ///
> /// Maximum legal AArch64 INTN and UINTN values.
>--
>2.19.2

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

[edk2] December TianoCore Meeting Minutes - EMEA/NAMO

[stephano]

An HTML version is available here:
https://www.tianocore.org/minutes/Community-EMEA-NAMO-12.html

Community Updates
We have talks submitted to both FOSDEM and the OCP Summit:
https://fosdem.org/2019/
https://www.opencompute.org/summit/global-summit

FOSDEM Topics
UEFI Capsule Update
UEFI Overview - TianoCore & U-Boot

OCP Topics
TianoCore Roadmap

At the start of the community meetings, please feel free to introduce 
yourself if you'd like your attendance to be recorded in the minutes. 
This can be done on IRC (OFTC - #edk2) or on the zoom chat feature.


Please send feedback to me regarding the dates / times of these 
meetings. If no comments are heard I will assume that these dates and 
times are good.


January and February's meetings will both be held on *the second week* 
of the month to accommodate holidays.


Opens
We would like to setup demos of the current patch systems specific 
companies are using and record those sessions. Nate can do this for 
Gerrit and the folks at Microsoft can do the same for Github. John from 
MS volunteered to do a walk-through of the patch review system as well 
as CI. Stephano will contact potential demo hosts and setup a time that 
works for them as well as discuss any concerns with recording the session.


There were questions about the release process, specifically the 
differences between the UDK release and Stable Tag releases.


-For details on Stable Tags, please see the following links:
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II#stable-tags
https://github.com/tianocore/tianocore.github.io/wiki/HardFeatureFreeze
https://github.com/tianocore/tianocore.github.io/wiki/SoftFeatureFreeze

-A Stable Tag is more frequent than the UDK release. It is a demand 
based branch rather than a cadence.


If a branch is created by the community, is that branch maintained, 
curated, and allowed to have future versions?

-The community we will discuss how this is addressed.
-For now, much like the UDK, only critical fixes would be maintained.
-Please feel free to send additional questions / comments on a new thread.

Build system changes, optimizations of the build system, possibly moving 
to the make files:

-There are some Bugzilla entries for this concept:
https://bugzilla.tianocore.org/show_bug.cgi?id=1378
https://bugzilla.tianocore.org/show_bug.cgi?id=1302
https://bugzilla.tianocore.org/show_bug.cgi?id=1301
https://bugzilla.tianocore.org/show_bug.cgi?id=1288
https://bugzilla.tianocore.org/show_bug.cgi?id=972
-In the upcoming design meetings (TBD) we can discuss those bugs and 
review possible changes.

-Community members should feel free to comment on those bugs directly.

License Change
Mark Doran has made it clear that we'll be moving to an Apache 2.0 
license. There is an RFC with a detailed proposal here:

https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html

If you are a copyright holder, please look at the RFC, give comments, 
and if there is a legal process for approval on your end, please start 
that process. Let us know if there are any concerns from your legal 
department. There is also a Bugzilla entry for details on code changes:

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

There will be a branch that Mike Kinney will create soon so that folks 
can review the changes to ensure that nothing is incorrect or might 
cause a build break. There is a script making this change, so the manual 
review of all these files will be difficult. Community assistance in 
reviewing those changes is appreciated.


Public Design and Bug Scrub Meetings
Stephano will send out an RFC to find a frequency and dates/times so 
that we can setup public design and bug scrub meetings. These are not 
meetings that everyone needs to join each occurance, however there will 
be required reviewers identified for specific features and bugs. There 
will be two meetings held, much like the Community Meeting format, to 
accommodate different time zones. Current thoughts are that Thursday AM 
(PST) for EMEA and PM (PST Friday AM Asia) would work, but please 
comment when the RFC is sent out if you have questions or comments. 
Making the design and bug scrub meeting agendas clear ahead of time is 
ideal. Stephano will head up that effort. Also, in each meeting we will 
collect the next week's possible topics.


//COMMENT
We need to have a process for the best way to begin a new design idea. 
We do have a "feature request" in Bugzilla. We also need a way to share 
documentation in terms of design. Stephano will send out an RFC 
regarding options for ways of sharing these documents. The design 
meeting can act as a clarification to possible new feature questions.


Patch Review Update
GitHub
Laszlo has been reviewing GitHub with the help of several folks at 
Microsoft. Microsoft currently relies on the Web UI of GitHub to archive 
all the details of their process. Laszlo did find some places where a 
"force commit" (as one example, there are others) would be 

Re: [edk2] edk2 and gnu-efi calling schemes

[Bill Paul]

Of all the gin joints in all the towns in all the world, Peter Wiehe had to 
walk into mine at 14:34 on Thursday 06 December 2018 and say:

> OK, another question:
> 
> when writing an UEFI application, edk2 and gnu-efi have different 64bit
> calling schemes. Does that only apply to calling the
> runtime-library/object file (and inside of the UEFI-application, of
> course)? Or does the call from application to UEFI differ in both
> toolkits, too? (If it is the latter, it would mean that the UEFI
> standard is unprecise!)

Both the EDK and GNU EFI obey the same standards when calling UEFI APIs. Their 
exact implementations may differ depending on the circumstances. For example, 
GNU EFI may use the __attribute__((ms_abi)) tag to tell the compiler what ABI 
to use, or if the compiler doesn't support this it can fall back to using some 
compatibility wrapper macros (see lib/x86_64/efi_stub.S). Either way, you end 
up with the same behavior.

Within a given FOO.EFI application, the application code itself can get away 
with using whatever calling convention it wants, right up until it needs to 
call a UEFI firmware routine. At that point, it has to follow the conventions 
spelled out in the UEFI spec.

-Bill

> Kind regards
> 
> Peter Wiehe
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] edk2 and gnu-efi calling schemes

[Peter Wiehe]

OK, another question:

when writing an UEFI application, edk2 and gnu-efi have different 64bit 
calling schemes. Does that only apply to calling the 
runtime-library/object file (and inside of the UEFI-application, of 
course)? Or does the call from application to UEFI differ in both 
toolkits, too? (If it is the latter, it would mean that the UEFI 
standard is unprecise!)


Kind regards

Peter Wiehe

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

Re: [edk2] [RFC] Remove unused tool chain configuration in BaseTools/Conf/tools_def.template

[Ard Biesheuvel]

On Thu, 6 Dec 2018 at 15:42, Gao, Liming  wrote:
>
> Hi, all
>   tools_def.template includes all tool chains. Some are not used any more. 
> And, there is no verification for them. So, I propose to remove them. They 
> are VS2003, VS2005, VS2008, VS2010, DDK3790, UNIXGCC, GCC44, GCC45, GCC46, 
> GCC47, ELFGCC, CYGGCC, ICC, ICC11, MYTOOLS. If you still use some one of 
> them, please let me know.
>

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

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

[Ard Biesheuvel]

This reverts commit 82379bf6603274e81604d5a6f6bb14bdde616286.

On AArch64, we can only use 48 address bits while running in UEFI,
while the GCD and UEFI memory maps may describe up to 52 bits of
physical address space. For this reason, MAX_ADDRESS was reduced
to 48 bits, to ensure that the firmware does not inadvertently
attempt to allocate memory that we cannot access.

However, MAX_ADDRESS is used in runtime drivers as well, and
runtime drivers may deal with kernel virtual addresses, which have
bits [63:48] set. In fact, the OS may be running with 64 KB pages
and pass addresses into the runtime services that use up to 52
bits of address space, either with the top bits set or cleared,
even if the physical address space does not extend beyond 48 bits.

In summary, changing MAX_ADDRESS is a mistake, and needs to be
reverted.

Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Laszlo Ersek 
Cc: Eric Auger 
Cc: Andrew Jones 
Cc: Philippe Mathieu-Daude 
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 dad75df1c579..968c18f915ae 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 (48 bits for 4 KB page size)
+/// Maximum legal AARCH64  address
 ///
-#define MAX_ADDRESS   0xULL
+#define MAX_ADDRESS   0xULL
 
 ///
 /// Maximum legal AArch64 INTN and UINTN values.
-- 
2.19.2

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

Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP

[Brian J. Johnson]

On 12/5/18 6:07 PM, Felix Polyudov wrote:

Andrew,

I think there are two aspects here:

1) What's the final solution we would like to see?
I think DebugLibMpSafe and a fake PEI Services Table that you are proposing are 
good ideas.
Ideally, it should still be possible to use the real PEI Services table by 
overriding a library class.
Please correct me if I'm wrong, but I believe it is legal to call PEI Service 
from AP if all other CPUs (including BSP) are not-running (halted or sitting in 
a spin-loop).



It's highly platform-dependent.  For instance, on many Intel server 
processors, RAM is not available for most of PEI (the memory init code 
runs in a PEIM.)  The CPUs are configured to use their internal caches 
as small amounts of temporary RAM, but they are not shared.  So the PEI 
environment set up on the BSP is not available to the APs.  No PPIs, 
HOBs, dynamic PCDs, PEI services, etc, etc.  The platform code is 
responsible for transferring anything the APs need, generally via 
chipset registers.  Slow, ugly, and extremely platform-dependent.


A basic self-contained DebugLib without dependencies is certainly handy. 
 But again, its implementation is platform-dependent.  For instance, if 
all APs try to write output to a single UART at the same time, all 
you'll see is a mess.  If a platform has some way for them to 
synchronize, or a separate debug channel per CPU, you could fix that.


FWIW, BaseDebugLibSerialPort has few or no dependencies if your 
SerialPortLib and DebugPrintErrorLevelLib don't.  Nor does 
BaseDebugLibNull.  :)


Brian Johnson


2) Should we do something short-term?
In my opinion yes, because commit c563077a380437c1 breaks perhaps questionable 
but working production code.
Additionally, as I've mentioned the library itself is broken because it uses 
DebugLib, which is likely to use PEI Services.
The patch I've submitted certainly does not provide a complete solution, but it 
provides a workaround for the immediate issue.
So I think it makes sense  to apply the patch.

Thanks
Felix

From: af...@apple.com [mailto:af...@apple.com]
Sent: Friday, November 30, 2018 3:37 PM
To: Felix Polyudov
Cc: Ni, Ruiyu; edk2-devel@lists.01.org; ler...@redhat.com; Dong, Eric
Subject: Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on 
AP

Felix,

I agree the obfuscation may not really be helpful. I've got a couple of 
thoughts.

1) I agree that I don't think the DebugLib is inherently safe on APs. I wonder 
if we could make a library class that was DebugLibMpSafe and have the same API 
as DebugLib. That way the library class matches how the module was coded.
2) If we want to enforce the rules we should add code to the PEI or DXE Core to 
CpuBreakpoint() etc. if an AP calls a core service.

Adding detection code is possible, but it is not trivial. For example if you 
have remembered the BSP and if the WhoAmI returns something different you need 
to check to see if some one changed the BSP.

I guess for PEI the other option could be to have a fake PEI Services Table 
that stubs out all the functions with CpuBreakpoint() or some such?

Thanks,

Andrew Fish



On Nov 30, 2018, at 6:33 AM, Felix Polyudov 
mailto:fel...@ami.com>> wrote:

Ray,

I agree with the premise that calling PEI services from AP should generally be 
avoided.
However, the PEI services can be used on AP under certain special circumstances.
A couple of examples:
1. For debugging purposes. The MpInitLib contains 12 DEBUG calls and 19 ASSERT 
calls. Depending on the DebugLib instance used in the project, these calls may 
lead to PEI services invocation.
2. MpInitLib provides ability to call AP in a serialized manner (only one AP is 
running, other APs and BSP are waiting), when it is safe to call PEI services.

Additionally, I think even if PEI services should not be used on AP, there is 
still a reason to keep PEI services table pointer initialized.
On one hand, given the complexity of modern firmware projects comprised of 
modules coming from multiple vendors, making sure PEI services are not used on 
AP can be a challenge.
For example, in my case the call was coming from the chipset reference code.
On the other hand, with the current implementation, when somebody does try to 
use PEI services on AP the behavior is unpredictable.
Depending on the content of the uninitialized PEI service table pointer, the 
system may either crash with one of the handful of different exceptions,
or it may start executing code from a random location. It's very difficult to 
debug such issues. One can spend weeks chasing a problem like this.


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ruiyu
Sent: Thursday, November 29, 2018 10:43 PM
To: Felix Polyudov; edk2-devel@lists.01.org
Cc: ler...@redhat.com; Dong, Eric
Subject: Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on 
AP

Felix,
I disagree:) 

Re: [edk2] [PATCH edk2-platforms 2/2] Platform/ARM/Sgi: Use NT_FW_CONFIG instead of HW_CONFIG

[Thomas Abraham]

On Thu, Dec 6, 2018 at 10:25 PM Ard Biesheuvel
 wrote:
>
> On Thu, 6 Dec 2018 at 16:50, Thomas Abraham  wrote:
> >
> > Hi Ard, Leif,
> >
> > On Tue, Dec 4, 2018 at 5:31 PM Chandni Cherukuri
> >  wrote:
> > >
> > > The hardware configuration in HW_CONFIG dts is not being
> > > passed onto the operating system but used and terminated
> > > at edk2 boot stage (BL33). So, as per the recommendations
> > > of the trusted-firmware design, the hardware description
> > > specified in NT_FW_CONFIG dts should be used instead of
> > > HW_CONFIG dts.
> >
> > The corresponding change in upstream trusted firmware has been merged.
> > So can you please have a look at this patch and let us know if any
> > changes are needed. Until this patch gets merged, the upstream master
> > branch of trusted firmware and edk2-platforms support for SGI
> > platforms is out of sync with each other. We will take care next time
> > to avoid causing dependencies like these between these two repos.
> >
>
> For the series
>
> Reviewed-by: Ard Biesheuvel 
>
> Pushed as 07c6bc27730d..327ff4ae71ae

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

Re: [edk2] [PATCH v1 edk2-platforms 1/8] Platform/ARM/SgiPkg: Restructure virtio device registration

[Ard Biesheuvel]

On Wed, 5 Dec 2018 at 07:10, Vijayenthiran Subramaniam
 wrote:
>
> Hi Ard,
>
> The virtio block device and virtio network device are available in software 
> model only. As of now, it exposes only one instance of each device.
>

Are the virtio devices described by the device tree obtained from the
secure firmware?

> On Tue, Dec 4, 2018 at 8:16 PM Ard Biesheuvel  
> wrote:
>>
>> On Tue, 4 Dec 2018 at 10:12, Vijayenthiran Subramaniam
>>  wrote:
>> >
>> > From: Daniil Egranov 
>> >
>> > SGI platforms support multiple virtio devices. So the existing code, that
>> > supports registration of only the virtio disk, is restructured to
>> > accommodate the registration of additional virtio devices.
>> >
>> > In addition to this, PCDs to represent the virtio controller base and
>> > address space size are introduced.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.1
>> > Signed-off-by: Daniil Egranov 
>> > ---
>> >  Platform/ARM/SgiPkg/SgiPlatform.dec   
>> >|  8 ++-
>> >  Platform/ARM/SgiPkg/SgiPlatform.dsc   
>> >|  7 +-
>> >  Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf   
>> >|  8 ++-
>> >  Platform/ARM/SgiPkg/Include/Guid/SgiVirtioDevicesFormSet.h
>> >| 21 ++
>> >  Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c 
>> >| 14 +---
>> >  Platform/ARM/SgiPkg/Drivers/PlatformDxe/{VirtioBlockIo.c => 
>> > VirtioDevices.c} | 67 
>> >  6 files changed, 81 insertions(+), 44 deletions(-)
>> >
>>
>> Can these platforms only ever expose a single block device and a
>> single network device?
>>
>> > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec 
>> > b/Platform/ARM/SgiPkg/SgiPlatform.dec
>> > index f6e0ba1e927a..ed29a4d5d91f 100644
>> > --- a/Platform/ARM/SgiPkg/SgiPlatform.dec
>> > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
>> > @@ -37,12 +37,16 @@ [Guids.common]
>> >gSgiClarkHeliosAcpiTablesFileGuid = { 0x2af40815, 0xa84e, 0x4de9, { 
>> > 0x8c, 0x38, 0x91, 0x40, 0xb3, 0x54, 0x40, 0x73 } }
>> >
>> >  [PcdsFeatureFlag.common]
>> > -  # Set this PCD to TRUE to enable virtio support.
>> > -  gArmSgiTokenSpaceGuid.PcdVirtioSupported|TRUE|BOOLEAN|0x0001
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported|FALSE|BOOLEAN|0x0001
>> >
>> >  [PcdsFixedAtBuild]
>> >gArmSgiTokenSpaceGuid.PcdDramBlock2Base|0|UINT64|0x0002
>> >gArmSgiTokenSpaceGuid.PcdDramBlock2Size|0|UINT64|0x0003
>> >
>> > +  # Virtio Block device
>> > +  
>> > gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress|0x|UINT32|0x0004
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSize|0x|UINT32|0x0005
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt|0x|UINT32|0x0006
>> > +
>> >  [Ppis]
>> >gHwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 
>> > 0x9b, 0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
>> > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
>> > b/Platform/ARM/SgiPkg/SgiPlatform.dsc
>> > index b3f76d2d9720..ada72be72f8a 100644
>> > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc
>> > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc
>> > @@ -98,7 +98,7 @@ [LibraryClasses.common.UEFI_DRIVER, 
>> > LibraryClasses.common.UEFI_APPLICATION, Libr
>> >  
>> > 
>> >
>> >  [PcdsFeatureFlag.common]
>> > -  gArmSgiTokenSpaceGuid.PcdVirtioSupported|TRUE
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported|TRUE
>> >
>> >  [PcdsFixedAtBuild.common]
>> >gArmTokenSpaceGuid.PcdVFPEnabled|1
>> > @@ -180,6 +180,11 @@ [PcdsFixedAtBuild.common]
>> ># Ethernet
>> >gEmbeddedTokenSpaceGuid.PcdLan91xDxeBaseAddress|0x1800
>> >
>> > +  # Virtio Disk
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress|0x1c13
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSize|0x1
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkInterrupt|202
>> > +
>> >  
>> > 
>> >  #
>> >  # Components Section - list of all EDK II Modules needed by this Platform
>> > diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf 
>> > b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
>> > index d903ed8d3375..f920f6ecafb8 100644
>> > --- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
>> > +++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
>> > @@ -20,7 +20,7 @@ [Defines]
>> >
>> >  [Sources.common]
>> >PlatformDxe.c
>> > -  VirtioBlockIo.c
>> > +  VirtioDevices.c
>> >
>> >  [Packages]
>> >EmbeddedPkg/EmbeddedPkg.dec
>> > @@ -41,7 +41,11 @@ [Guids]
>> >gSgiClarkHeliosAcpiTablesFileGuid
>> >
>> >  [FeaturePcd]
>> > -  gArmSgiTokenSpaceGuid.PcdVirtioSupported
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported
>> > +
>> > +[FixedPcd]
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkBaseAddress
>> > +  gArmSgiTokenSpaceGuid.PcdVirtioBlkSize
>> >
>> >  [Depex]
>> >

Re: [edk2] [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function

[Ard Biesheuvel]

On Thu, 6 Dec 2018 at 18:02, Jeff Brasen  wrote:
>
>
>
> -Original Message-
> From: Ard Biesheuvel 
> Sent: Thursday, December 6, 2018 9:54 AM
> To: Jeff Brasen 
> Cc: edk2-devel@lists.01.org; Leif Lindholm ; Girish 
> Pathak 
> Subject: Re: [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function
>
> On Thu, 6 Dec 2018 at 01:37, Jeff Brasen  wrote:
> >
> > Leif/Ard,
> >
> >
> >   Any comments on this v2 patch for this?
> >
> >
>
> Hi Jeff,
>
> I'm not sure what level of bikeshedding is justified when it comes to a 
> driver such as this one, which is very recent, and mostly for platform 
> internal use. However, I will note that the current versioning approach 
> permits a *client* of the old SCMI_CLOCK_PROTOCOL to be built that invokes 
> ->Enable(), which is not defined for it. This somewhat defeats the purpose of 
> the versioning, since the whole point is to avoid invoking ->Enable() on 
> older implementations of the protocol.
>
> I'd be fine with just modifying the protocol, but if we decide we need 
> versioning, we should not modify the public interface of the old one.
> How the driver reuses one implementation to back the other is another matter, 
> of course.
> [JMB] I can either just change without versioning (that was my original 
> approach but I also changed the guid which would primarily catch new clients 
> running on old platforms from calling an undefined function), I am fine with 
> either that (with maybe a switch back to original guid if we are not 
> concerned about that issue) or a future update that creates a full v2 version 
> of the protocol in the header.
>

Maybe Leif disagrees, but I am not too concerned about just changing
it. This is not a protocol that 3rd party drivers would invoke, right?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Platform/ARM/SgiPkg: Add support for HDLCD

[Ard Biesheuvel]

On Thu, 6 Dec 2018 at 13:43, Vijayenthiran Subramaniam
 wrote:
>
> Add HDLCD platform library for SGI platform that implements platform
> callbacks for the Arm HDLCD driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vijayenthiran Subramaniam 
> ---
>  Platform/ARM/SgiPkg/SgiPlatform.dsc   |   6 +
>  Platform/ARM/SgiPkg/SgiPlatform.fdf   |   6 +
>  Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf |  37 +++
>  Platform/ARM/SgiPkg/Include/SgiPlatform.h |   4 +
>  Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgi.c  | 262 
> 
>  Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c  |   8 +-
>  6 files changed, 322 insertions(+), 1 deletion(-)
>
> diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
> b/Platform/ARM/SgiPkg/SgiPlatform.dsc
> index 0c794c6b299d..7995c7d132d6 100644
> --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc
> +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc
> @@ -37,6 +37,8 @@ [LibraryClasses.common]
>ArmPlatformLib|Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
>BasePathLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>
> EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
> +  LcdHwLib|ArmPlatformPkg/Library/HdLcd/HdLcd.inf
> +  
> LcdPlatformLib|Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
>NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/NorFlashLib.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> @@ -155,6 +157,9 @@ [PcdsFixedAtBuild.common]
>gArmPlatformTokenSpaceGuid.PL011UartInteger|4
>gArmPlatformTokenSpaceGuid.PL011UartFractional|0
>
> +  ## PL370 - HDLCD1
> +  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x7FF6
> +
>## PL011 - Serial Debug UART
>gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase|0x7FF8
>gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz|7372800
> @@ -235,6 +240,7 @@ [Components.common]
>ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
> +  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
>ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
>EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
> diff --git a/Platform/ARM/SgiPkg/SgiPlatform.fdf 
> b/Platform/ARM/SgiPkg/SgiPlatform.fdf
> index ddf1fda5a16e..80c3412fd4ad 100644
> --- a/Platform/ARM/SgiPkg/SgiPlatform.fdf
> +++ b/Platform/ARM/SgiPkg/SgiPlatform.fdf
> @@ -133,6 +133,9 @@ [FV.FvMain]
>#
># Multiple Console IO support
>#
> +  INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
> +  INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> +  INF 
> MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
>INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>
> @@ -144,6 +147,9 @@ [FV.FvMain]
>INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
>INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>
> +  # Graphics Output Protocol
> +  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
> +
>INF Platform/ARM/Drivers/BootMonFs/BootMonFs.inf
>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>
> diff --git a/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf 
> b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
> new file mode 100644
> index ..25efbea5fb83
> --- /dev/null
> +++ b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
> @@ -0,0 +1,37 @@
> +#
> +#  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= 0x0001001A
> +  BASE_NAME  = HdLcdArmSgiLib
> +  FILE_GUID  = 0C77342C-7895-4DE1-A9C8-1DBBFA71AF34
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = LcdPlatformLib
> +
> +[Sources.common]
> +  HdLcdArmSgi.c
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  ArmPlatformPkg/ArmPlatformPkg.dec
> +  MdePkg/MdePkg.dec
> +  Platform/ARM/SgiPkg/SgiPlatform.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +
> +[FixedPcd]
> +  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase
> +  

Re: [edk2] [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function

[Jeff Brasen]

-Original Message-
From: Ard Biesheuvel  
Sent: Thursday, December 6, 2018 9:54 AM
To: Jeff Brasen 
Cc: edk2-devel@lists.01.org; Leif Lindholm ; Girish 
Pathak 
Subject: Re: [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function

On Thu, 6 Dec 2018 at 01:37, Jeff Brasen  wrote:
>
> Leif/Ard,
>
>
>   Any comments on this v2 patch for this?
>
>

Hi Jeff,

I'm not sure what level of bikeshedding is justified when it comes to a driver 
such as this one, which is very recent, and mostly for platform internal use. 
However, I will note that the current versioning approach permits a *client* of 
the old SCMI_CLOCK_PROTOCOL to be built that invokes ->Enable(), which is not 
defined for it. This somewhat defeats the purpose of the versioning, since the 
whole point is to avoid invoking ->Enable() on older implementations of the 
protocol.

I'd be fine with just modifying the protocol, but if we decide we need 
versioning, we should not modify the public interface of the old one.
How the driver reuses one implementation to back the other is another matter, 
of course.
[JMB] I can either just change without versioning (that was my original 
approach but I also changed the guid which would primarily catch new clients 
running on old platforms from calling an undefined function), I am fine with 
either that (with maybe a switch back to original guid if we are not concerned 
about that issue) or a future update that creates a full v2 version of the 
protocol in the header. 

 

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] ArmPkg/OpteeLib: Add dummy RPC handler

[Ard Biesheuvel]

On Wed, 5 Dec 2018 at 12:58, Sumit Garg  wrote:
>
> Add dummy RPC handler for RPCs that are not implemented as control
> should be returned back to OP-TEE in case any RPC is invoked.
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sumit Garg 

Reviewed-by: Ard Biesheuvel 

Pushed as bc39c5cbea30..088a5334809d

Thanks

> ---
>  ArmPkg/Library/OpteeLib/OpteeSmc.h |  3 ++
>  ArmPkg/Library/OpteeLib/Optee.c| 34 
>  2 files changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/ArmPkg/Library/OpteeLib/OpteeSmc.h 
> b/ArmPkg/Library/OpteeLib/OpteeSmc.h
> index 9cccd81810c9..6209782aaed7 100644
> --- a/ArmPkg/Library/OpteeLib/OpteeSmc.h
> +++ b/ArmPkg/Library/OpteeLib/OpteeSmc.h
> @@ -25,6 +25,9 @@
>
>  #define OPTEE_SMC_SHARED_MEMORY_CACHED  1
>
> +#define OPTEE_SMC_RETURN_UNKNOWN_FUNCTION   0x
> +#define OPTEE_SMC_RETURN_RPC_PREFIX_MASK0x
> +#define OPTEE_SMC_RETURN_RPC_PREFIX 0x
>  #define OPTEE_SMC_RETURN_RPC_FOREIGN_INTERRUPT  0x0004
>
>  #define OPTEE_MESSAGE_COMMAND_OPEN_SESSION  0
> diff --git a/ArmPkg/Library/OpteeLib/Optee.c b/ArmPkg/Library/OpteeLib/Optee.c
> index 55dcc7853b59..ed2a03c593c2 100644
> --- a/ArmPkg/Library/OpteeLib/Optee.c
> +++ b/ArmPkg/Library/OpteeLib/Optee.c
> @@ -123,6 +123,17 @@ OpteeInit (
>return EFI_SUCCESS;
>  }
>
> +STATIC
> +BOOLEAN
> +IsOpteeSmcReturnRpc (
> +  UINT32 Return
> +  )
> +{
> +  return (Return != OPTEE_SMC_RETURN_UNKNOWN_FUNCTION) &&
> + ((Return & OPTEE_SMC_RETURN_RPC_PREFIX_MASK) ==
> +  OPTEE_SMC_RETURN_RPC_PREFIX);
> +}
> +
>  /**
>Does Standard SMC to OP-TEE in secure world.
>
> @@ -147,13 +158,22 @@ OpteeCallWithArg (
>while (TRUE) {
>  ArmCallSmc ();
>
> -if (ArmSmcArgs.Arg0 == OPTEE_SMC_RETURN_RPC_FOREIGN_INTERRUPT) {
> -  //
> -  // A foreign interrupt was raised while secure world was
> -  // executing, since they are handled in UEFI a dummy RPC is
> -  // performed to let UEFI take the interrupt through the normal
> -  // vector.
> -  //
> +if (IsOpteeSmcReturnRpc (ArmSmcArgs.Arg0)) {
> +  switch (ArmSmcArgs.Arg0) {
> +  case OPTEE_SMC_RETURN_RPC_FOREIGN_INTERRUPT:
> +//
> +// A foreign interrupt was raised while secure world was
> +// executing, since they are handled in UEFI a dummy RPC is
> +// performed to let UEFI take the interrupt through the normal
> +// vector.
> +//
> +break;
> +
> +  default:
> + // Do nothing in case RPC is not implemented.
> +break;
> +  }
> +
>ArmSmcArgs.Arg0 = OPTEE_SMC_RETURN_FROM_RPC;
>  } else {
>break;
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 2/2] Platform/ARM/Sgi: Use NT_FW_CONFIG instead of HW_CONFIG

[Ard Biesheuvel]

On Thu, 6 Dec 2018 at 16:50, Thomas Abraham  wrote:
>
> Hi Ard, Leif,
>
> On Tue, Dec 4, 2018 at 5:31 PM Chandni Cherukuri
>  wrote:
> >
> > The hardware configuration in HW_CONFIG dts is not being
> > passed onto the operating system but used and terminated
> > at edk2 boot stage (BL33). So, as per the recommendations
> > of the trusted-firmware design, the hardware description
> > specified in NT_FW_CONFIG dts should be used instead of
> > HW_CONFIG dts.
>
> The corresponding change in upstream trusted firmware has been merged.
> So can you please have a look at this patch and let us know if any
> changes are needed. Until this patch gets merged, the upstream master
> branch of trusted firmware and edk2-platforms support for SGI
> platforms is out of sync with each other. We will take care next time
> to avoid causing dependencies like these between these two repos.
>

For the series

Reviewed-by: Ard Biesheuvel 

Pushed as 07c6bc27730d..327ff4ae71ae
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function

[Ard Biesheuvel]

On Thu, 6 Dec 2018 at 01:37, Jeff Brasen  wrote:
>
> Leif/Ard,
>
>
>   Any comments on this v2 patch for this?
>
>

Hi Jeff,

I'm not sure what level of bikeshedding is justified when it comes to
a driver such as this one, which is very recent, and mostly for
platform internal use. However, I will note that the current
versioning approach permits a *client* of the old SCMI_CLOCK_PROTOCOL
to be built that invokes ->Enable(), which is not defined for it. This
somewhat defeats the purpose of the versioning, since the whole point
is to avoid invoking ->Enable() on older implementations of the
protocol.

I'd be fine with just modifying the protocol, but if we decide we need
versioning, we should not modify the public interface of the old one.
How the driver reuses one implementation to back the other is another
matter, of course.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 2/2] Platform/ARM/Sgi: Use NT_FW_CONFIG instead of HW_CONFIG

[Thomas Abraham]

Hi Ard, Leif,

On Tue, Dec 4, 2018 at 5:31 PM Chandni Cherukuri
 wrote:
>
> The hardware configuration in HW_CONFIG dts is not being
> passed onto the operating system but used and terminated
> at edk2 boot stage (BL33). So, as per the recommendations
> of the trusted-firmware design, the hardware description
> specified in NT_FW_CONFIG dts should be used instead of
> HW_CONFIG dts.

The corresponding change in upstream trusted firmware has been merged.
So can you please have a look at this patch and let us know if any
changes are needed. Until this patch gets merged, the upstream master
branch of trusted firmware and edk2-platforms support for SGI
platforms is out of sync with each other. We will take care next time
to avoid causing dependencies like these between these two repos.

Thanks,
Thomas.

>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chandni Cherukuri 
> ---
>  Platform/ARM/SgiPkg/SgiPlatform.dec   |  2 +-
>  Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf   |  2 +-
>  Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPei.inf |  4 +--
>  Platform/ARM/SgiPkg/Include/Ppi/SgiPlatformId.h   |  6 ++---
>  Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.c | 10 +++
>  Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c  | 28 
> ++--
>  Platform/ARM/SgiPkg/Library/PlatformLib/AArch64/Helper.S  |  6 ++---
>  7 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec 
> b/Platform/ARM/SgiPkg/SgiPlatform.dec
> index f6e0ba1..9166052 100644
> --- a/Platform/ARM/SgiPkg/SgiPlatform.dec
> +++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
> @@ -45,4 +45,4 @@
>gArmSgiTokenSpaceGuid.PcdDramBlock2Size|0|UINT64|0x0003
>
>  [Ppis]
> -  gHwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 0x9b, 
> 0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
> +  gNtFwConfigDtInfoPpiGuid = { 0x6f606eb3, 0x9123, 0x4e15, { 0xa8, 0x9b, 
> 0x0f, 0xac, 0x66, 0xef, 0xd0, 0x17 } }
> diff --git a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf 
> b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
> index 93377fa..260be58 100644
> --- a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
> +++ b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
> @@ -71,4 +71,4 @@
>
>  [Ppis]
>gArmMpCoreInfoPpiGuid
> -  gHwConfigDtInfoPpiGuid
> +  gNtFwConfigDtInfoPpiGuid
> diff --git a/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPei.inf 
> b/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPei.inf
> index a7c718b..a9173cc 100644
> --- a/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPei.inf
> +++ b/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPei.inf
> @@ -34,7 +34,7 @@
>gArmSgiPlatformIdDescriptorGuid
>
>  [Ppis]
> -  gHwConfigDtInfoPpiGuid
> +  gNtFwConfigDtInfoPpiGuid
>
>  [Depex]
> -  gHwConfigDtInfoPpiGuid
> +  gNtFwConfigDtInfoPpiGuid
> diff --git a/Platform/ARM/SgiPkg/Include/Ppi/SgiPlatformId.h 
> b/Platform/ARM/SgiPkg/Include/Ppi/SgiPlatformId.h
> index 934eef2..b830326 100644
> --- a/Platform/ARM/SgiPkg/Include/Ppi/SgiPlatformId.h
> +++ b/Platform/ARM/SgiPkg/Include/Ppi/SgiPlatformId.h
> @@ -15,9 +15,9 @@
>  #ifndef  SGI_PLATFORMID_PPI_
>  #define  SGI_PLATFORMID_PPI_
>
> -// HwConfig DT structure
> +// NT_FW_CONFIG DT structure
>  typedef struct {
> -  UINT64  HwConfigDtAddr;
> -} SGI_HW_CONFIG_INFO_PPI;
> +  UINT64  NtFwConfigDtAddr;
> +} SGI_NT_FW_CONFIG_INFO_PPI;
>
>  #endif
> diff --git a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.c 
> b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.c
> index 13bb423..d264292 100644
> --- a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.c
> +++ b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.c
> @@ -17,8 +17,8 @@
>  #include 
>  #include 
>
> -UINT64 HwConfigDtBlob;
> -STATIC SGI_HW_CONFIG_INFO_PPI mHwConfigDtInfoPpi;
> +UINT64 NtFwConfigDtBlob;
> +STATIC SGI_NT_FW_CONFIG_INFO_PPI mNtFwConfigDtInfoPpi;
>
>  STATIC ARM_CORE_INFO mCoreInfoTable[] = {
>{
> @@ -40,7 +40,7 @@ ArmPlatformInitialize (
>IN  UINTN MpId
>)
>  {
> -  mHwConfigDtInfoPpi.HwConfigDtAddr = HwConfigDtBlob;
> +  mNtFwConfigDtInfoPpi.NtFwConfigDtAddr = NtFwConfigDtBlob;
>return RETURN_SUCCESS;
>  }
>
> @@ -67,8 +67,8 @@ EFI_PEI_PPI_DESCRIPTOR gPlatformPpiTable[] = {
>},
>{
>  EFI_PEI_PPI_DESCRIPTOR_PPI,
> -,
> -
> +,
> +
>}
>  };
>
> diff --git a/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c 
> b/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c
> index 065b23d..d133921 100644
> --- a/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c
> +++ b/Platform/ARM/SgiPkg/Library/SgiPlatformPei/SgiPlatformPeim.c
> @@ -24,9 +24,9 @@
>
>This function returns the System ID of the platform
>
> -  This 

Re: [edk2] [RFC] Remove unused tool chain configuration in BaseTools/Conf/tools_def.template

[Laszlo Ersek]

On 12/06/18 15:42, Gao, Liming wrote:
> Hi, all tools_def.template includes all tool chains. Some are not
> used any more. And, there is no verification for them. So, I propose
> to remove them. They are VS2003, VS2005, VS2008, VS2010, DDK3790,
> UNIXGCC, GCC44, GCC45, GCC46, GCC47, ELFGCC, CYGGCC, ICC, ICC11,
> MYTOOLS. If you still use some one of them, please let me know.

I don't know how to reach out to Linux distros (hopefully their
representatives are already subscribed to this list), but we should
really pose this question to them.

Regarding GCC44, that's the compiler in RHEL6, and RHEL6 is not EOL. On
the other hand, I don't see any reason why anyone would prefer RHEL6 to
RHEL7+ (or recent Fedora) for doing upstream edk2 development. (RHEL6
itself does not ship any edk2 firmware platform.)

So, from a Fedora & RHEL perspective, I'm OK with dropping GCC44..GCC47
inclusive (please do keep GCC48). And, outside of the GCC toolchain
family, I'm neutral.

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

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

[Rebecca Cran via edk2-devel]

On December 6, 2018 at 7:13:24 AM, Laszlo Ersek 
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote:

> I've just noticed that I got the following emails:
>  
> [Differential] [Request] [+ ] D1: Update URL of OVMF page
> [Differential] [Updated] D1: Update URL of OVMF page
>  
> They don't contain any code (diff hunks). I hope I can change that in my
> email preferences (I haven't gotten around checking those yet). However,
> one bit that I doubt I'll be able to update myself, is the sender for
> these emails:
>  
> nore...@phabricator.example.com  

Yeah, sorry - I’ll fix the configuration this evening to send diffs and allow 
replies to emails (and update the domain name).






Rebecca

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

Re: [edk2] Build fail using latest UDK2018

[Gao, Liming]

edksetup.bat Rebuild  is to compile BaseTools C tools. It doesn’t build any 
thing.
Thanks
Liming

From: Prem Kumar [mailto:perry.p...@gmail.com]
Sent: Thursday, December 6, 2018 10:57 PM
To: Gao, Liming 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Build fail using latest UDK2018

Hi Liming,
 You no need to do Rebuild. Just normal build is sufficient to recreate this 
build error.

--
Thanks,
Prem.

On Thu, Dec 6, 2018 at 8:23 PM Gao, Liming 
mailto:liming@intel.com>> wrote:
Seemly, this is an incremental build issue.

I try below command. But, I don’t reproduce it.

edksetup.bat Rebuild
build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86
build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86 run
build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86

Thanks
Liming
From: Prem Kumar [mailto:perry.p...@gmail.com]
Sent: Thursday, December 6, 2018 10:42 PM
To: Gao, Liming mailto:liming@intel.com>>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Build fail using latest UDK2018

Recreating this issue is simple..

  1.  Fresh build either NT32Pkg for x64 bit
  2.  Launch NT32 simulator
  3.  Close Nt32 simulator
  4.  And try build again for x64 bit
  5.  It will throw this build error.
I've even tried to delete folder PeiMain from Build folder.. then it gives 
error for another. But it build success when I delete entire build folder.

Configuration used:

  1.  Visual Studio 2016
  2.  Nt32Pkg
  3.  UDK2018

On Thu, Dec 6, 2018 at 5:29 AM Gao, Liming 
mailto:liming@intel.com>> wrote:
How reproduce this issue? Could you list your step?

>-Original Message-
>From: edk2-devel 
>[mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of
>Prem Kumar
>Sent: Thursday, December 06, 2018 2:37 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] Build fail using latest UDK2018
>
>Hi All,
> When I try to build UDK2018 package I'm facing below build error.
>
>*Note:*
>  When I delete the build folder the same build error is not happening.
>  The same build error is not happening when build is happening for first
>time.
>
>Any pointers is appreciated.
>
>
>build.py...
> : error C0DE: Unknown fatal error when processing
>[c:\myworkspace\MdeModulePkg\Core\Pei\PeiMain.inf]
>
>(Please send email to edk2-devel@lists.01.org 
>for help, attaching following
>call stack trace!)
>
>(Python 2.7.14 on win32) Traceback (most recent call last):
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2494,
>in Main
>MyBuild.Launch()
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2227,
>in Launch
>self._MultiThreadBuildPlatform()
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2100,
>in _MultiThreadBuildPlatform
>self.CreateAsBuiltInf()
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2239,
>in CreateAsBuiltInf
>Module.CreateAsBuiltInf()
>  File "C:\myworkspace\BaseTools\Source\Python\AutoGen\AutoGen.py",
>line
>3617, in CreateAsBuiltInf
>shutil.copy2(UNIFile, self.OutputDir)
>  File "C:\Python27\lib\shutil.py", line 144, in copy2
>copyfile(src, dst)
>  File "C:\Python27\lib\shutil.py", line 97, in copyfile
>with open(dst, 'wb') as fdst:
>IOError: [Errno 13] Permission denied:
>'c:\\myworkspaceBuild\\NT32X64\\DEBUG_VS2015x86\\X64\\MdeModulePk
>g\\Core\\Pei\\PeiMain\\OUTPUT\\PeiCore.uni'
>___
>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] Build fail using latest UDK2018

[Prem Kumar]

Hi Liming,
 You no need to do Rebuild. Just normal build is sufficient to recreate
this build error.

--
Thanks,
Prem.

On Thu, Dec 6, 2018 at 8:23 PM Gao, Liming  wrote:

> Seemly, this is an incremental build issue.
>
>
>
> I try below command. But, I don’t reproduce it.
>
>
>
> edksetup.bat Rebuild
>
> build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86
>
> build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86 run
>
> build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86
>
>
>
> Thanks
>
> Liming
>
> *From:* Prem Kumar [mailto:perry.p...@gmail.com]
> *Sent:* Thursday, December 6, 2018 10:42 PM
> *To:* Gao, Liming 
> *Cc:* edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Build fail using latest UDK2018
>
>
>
> Recreating this issue is simple..
>
>1. Fresh build either NT32Pkg for x64 bit
>2. Launch NT32 simulator
>3. Close Nt32 simulator
>4. And try build again for x64 bit
>5. It will throw this build error.
>
> I've even tried to delete folder PeiMain from Build folder.. then it gives
> error for another. But it build success when I delete entire build folder.
>
>
>
> Configuration used:
>
>1. Visual Studio 2016
>2. Nt32Pkg
>3. UDK2018
>
>
>
> On Thu, Dec 6, 2018 at 5:29 AM Gao, Liming  wrote:
>
> How reproduce this issue? Could you list your step?
>
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Prem Kumar
> >Sent: Thursday, December 06, 2018 2:37 AM
> >To: edk2-devel@lists.01.org
> >Subject: [edk2] Build fail using latest UDK2018
> >
> >Hi All,
> > When I try to build UDK2018 package I'm facing below build error.
> >
> >*Note:*
> >  When I delete the build folder the same build error is not happening.
> >  The same build error is not happening when build is happening for first
> >time.
> >
> >Any pointers is appreciated.
> >
> >
> >build.py...
> > : error C0DE: Unknown fatal error when processing
> >[c:\myworkspace\MdeModulePkg\Core\Pei\PeiMain.inf]
> >
> >(Please send email to edk2-devel@lists.01.org for help, attaching
> following
> >call stack trace!)
> >
> >(Python 2.7.14 on win32) Traceback (most recent call last):
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2494,
> >in Main
> >MyBuild.Launch()
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2227,
> >in Launch
> >self._MultiThreadBuildPlatform()
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2100,
> >in _MultiThreadBuildPlatform
> >self.CreateAsBuiltInf()
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2239,
> >in CreateAsBuiltInf
> >Module.CreateAsBuiltInf()
> >  File "C:\myworkspace\BaseTools\Source\Python\AutoGen\AutoGen.py",
> >line
> >3617, in CreateAsBuiltInf
> >shutil.copy2(UNIFile, self.OutputDir)
> >  File "C:\Python27\lib\shutil.py", line 144, in copy2
> >copyfile(src, dst)
> >  File "C:\Python27\lib\shutil.py", line 97, in copyfile
> >with open(dst, 'wb') as fdst:
> >IOError: [Errno 13] Permission denied:
> >'c:\\myworkspaceBuild\\NT32X64\\DEBUG_VS2015x86\\X64\\MdeModulePk
> >g\\Core\\Pei\\PeiMain\\OUTPUT\\PeiCore.uni'
> >___
> >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] Build fail using latest UDK2018

[Gao, Liming]

Seemly, this is an incremental build issue.

I try below command. But, I don’t reproduce it.

edksetup.bat Rebuild
build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86
build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86 run
build -p Nt32Pkg\Nt32Pkg.dsc -a X64 -t VS2015x86

Thanks
Liming
From: Prem Kumar [mailto:perry.p...@gmail.com]
Sent: Thursday, December 6, 2018 10:42 PM
To: Gao, Liming 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Build fail using latest UDK2018

Recreating this issue is simple..

  1.  Fresh build either NT32Pkg for x64 bit
  2.  Launch NT32 simulator
  3.  Close Nt32 simulator
  4.  And try build again for x64 bit
  5.  It will throw this build error.
I've even tried to delete folder PeiMain from Build folder.. then it gives 
error for another. But it build success when I delete entire build folder.

Configuration used:

  1.  Visual Studio 2016
  2.  Nt32Pkg
  3.  UDK2018

On Thu, Dec 6, 2018 at 5:29 AM Gao, Liming 
mailto:liming@intel.com>> wrote:
How reproduce this issue? Could you list your step?

>-Original Message-
>From: edk2-devel 
>[mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of
>Prem Kumar
>Sent: Thursday, December 06, 2018 2:37 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] Build fail using latest UDK2018
>
>Hi All,
> When I try to build UDK2018 package I'm facing below build error.
>
>*Note:*
>  When I delete the build folder the same build error is not happening.
>  The same build error is not happening when build is happening for first
>time.
>
>Any pointers is appreciated.
>
>
>build.py...
> : error C0DE: Unknown fatal error when processing
>[c:\myworkspace\MdeModulePkg\Core\Pei\PeiMain.inf]
>
>(Please send email to edk2-devel@lists.01.org 
>for help, attaching following
>call stack trace!)
>
>(Python 2.7.14 on win32) Traceback (most recent call last):
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2494,
>in Main
>MyBuild.Launch()
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2227,
>in Launch
>self._MultiThreadBuildPlatform()
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2100,
>in _MultiThreadBuildPlatform
>self.CreateAsBuiltInf()
>  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2239,
>in CreateAsBuiltInf
>Module.CreateAsBuiltInf()
>  File "C:\myworkspace\BaseTools\Source\Python\AutoGen\AutoGen.py",
>line
>3617, in CreateAsBuiltInf
>shutil.copy2(UNIFile, self.OutputDir)
>  File "C:\Python27\lib\shutil.py", line 144, in copy2
>copyfile(src, dst)
>  File "C:\Python27\lib\shutil.py", line 97, in copyfile
>with open(dst, 'wb') as fdst:
>IOError: [Errno 13] Permission denied:
>'c:\\myworkspaceBuild\\NT32X64\\DEBUG_VS2015x86\\X64\\MdeModulePk
>g\\Core\\Pei\\PeiMain\\OUTPUT\\PeiCore.uni'
>___
>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] [RFC] Remove unused tool chain configuration in BaseTools/Conf/tools_def.template

[Gao, Liming]

Hi, all
  tools_def.template includes all tool chains. Some are not used any more. And, 
there is no verification for them. So, I propose to remove them. They are 
VS2003, VS2005, VS2008, VS2010, DDK3790, UNIXGCC, GCC44, GCC45, GCC46, GCC47, 
ELFGCC, CYGGCC, ICC, ICC11, MYTOOLS. If you still use some one of them, please 
let me know.

Thanks
Liming

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

Re: [edk2] Build fail using latest UDK2018

[Prem Kumar]

Recreating this issue is simple..

   1. Fresh build either NT32Pkg for x64 bit
   2. Launch NT32 simulator
   3. Close Nt32 simulator
   4. And try build again for x64 bit
   5. It will throw this build error.

I've even tried to delete folder PeiMain from Build folder.. then it gives
error for another. But it build success when I delete entire build folder.

Configuration used:

   1. Visual Studio 2016
   2. Nt32Pkg
   3. UDK2018


On Thu, Dec 6, 2018 at 5:29 AM Gao, Liming  wrote:

> How reproduce this issue? Could you list your step?
>
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Prem Kumar
> >Sent: Thursday, December 06, 2018 2:37 AM
> >To: edk2-devel@lists.01.org
> >Subject: [edk2] Build fail using latest UDK2018
> >
> >Hi All,
> > When I try to build UDK2018 package I'm facing below build error.
> >
> >*Note:*
> >  When I delete the build folder the same build error is not happening.
> >  The same build error is not happening when build is happening for first
> >time.
> >
> >Any pointers is appreciated.
> >
> >
> >build.py...
> > : error C0DE: Unknown fatal error when processing
> >[c:\myworkspace\MdeModulePkg\Core\Pei\PeiMain.inf]
> >
> >(Please send email to edk2-devel@lists.01.org for help, attaching
> following
> >call stack trace!)
> >
> >(Python 2.7.14 on win32) Traceback (most recent call last):
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2494,
> >in Main
> >MyBuild.Launch()
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2227,
> >in Launch
> >self._MultiThreadBuildPlatform()
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2100,
> >in _MultiThreadBuildPlatform
> >self.CreateAsBuiltInf()
> >  File "C:\myworkspace\BaseTools\Source\Python\build\build.py", line 2239,
> >in CreateAsBuiltInf
> >Module.CreateAsBuiltInf()
> >  File "C:\myworkspace\BaseTools\Source\Python\AutoGen\AutoGen.py",
> >line
> >3617, in CreateAsBuiltInf
> >shutil.copy2(UNIFile, self.OutputDir)
> >  File "C:\Python27\lib\shutil.py", line 144, in copy2
> >copyfile(src, dst)
> >  File "C:\Python27\lib\shutil.py", line 97, in copyfile
> >with open(dst, 'wb') as fdst:
> >IOError: [Errno 13] Permission denied:
> >'c:\\myworkspaceBuild\\NT32X64\\DEBUG_VS2015x86\\X64\\MdeModulePk
> >g\\Core\\Pei\\PeiMain\\OUTPUT\\PeiCore.uni'
> >___
> >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

[Laszlo Ersek]

On 12/05/18 18:26, Rebecca Cran wrote:
> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> 
>> (1) Pls. explain to me how I can create an edk2 clone at
>> . :)
> 
> You don't. In a production system it may be possible to clone from either 
> GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
> when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
> work (since I've not configured it).
>  
>> (2) Please create a throw-away account for yourself.
> 
> Done (though not throw-away).
>  
>> (3) Submit a pullreq against (1), with a topic branch that has two
>> commits, and simple text file modifications.
> 
> https://code.bluestop.org/D1
> Since Phabricator doesn't care about topic branches (just patches), I created 
> a diff to README.
> 

(Sorry about the many emails I'm sending. :/ )

I've just noticed that I got the following emails:

  [Differential] [Request] [+  ] D1: Update URL of OVMF page
  [Differential] [Updated] D1: Update URL of OVMF page

They don't contain any code (diff hunks). I hope I can change that in my
email preferences (I haven't gotten around checking those yet). However,
one bit that I doubt I'll be able to update myself, is the sender for
these emails:

  nore...@phabricator.example.com

That doesn't look right even for this testing; can you please update the
config? I believe the emails should come from a sender @
code.bluestop.org. Is that correct?

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

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

[Laszlo Ersek]

On 12/06/18 15:05, Laszlo Ersek wrote:
> On 12/05/18 18:26, Rebecca Cran wrote:
>> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
>>
>>> (1) Pls. explain to me how I can create an edk2 clone at
>>> . :)
>>
>> You don't. In a production system it may be possible to clone from either 
>> GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
>> when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
>> work (since I've not configured it).
> 
> Well, I don't specifically desire creating an edk2 clone on
>  *using the WebUI*. However, in order to share my
> work (i.e. to submit a pull request that refers to a topic branch of
> mine), I need to have a publicly available / fetchable git repository.
> (This is no different from mailing list based pull requests BTW.)
> 
> So, let me reformulate: can I *have* (by any means) a personal edk2
> clone on , and can I push my topic branches there?
> (Obviously it's not specifically about me nor specifically about
> , but about any contributor with a topic branch to
> submit, and about any site that would possibly run the central edk2
> Phabricator instance.)
> 
> Right now I'm confused whether Phabricator (in general) offers
> repository storage for contributors, or if that would have to come from
> another service. (That wouldn't be too convenient.)
> 
> Anyway, the goal of a personal edk2 repo (clone) for me on
>  would be that I should be able to receive pull
> requests against it.
> 
> Am I misunderstanding something?
> 
>>  
>>> (2) Please create a throw-away account for yourself.
>>
>> Done (though not throw-away).
> 
> I suggested "throw-away" because one of the later steps involves
> deleting it.
> 
>>  
>>> (3) Submit a pullreq against (1), with a topic branch that has two
>>> commits, and simple text file modifications.
>>
>> https://code.bluestop.org/D1
>> Since Phabricator doesn't care about topic branches (just patches),
> 
> Please wait a second, I don't understand. What do you mean by "doesn't
> care about topic branches, just patches"?
> 
> Compare three scenarios:
> 
> (a) Someone implements a new feature in 10 patches, and sends each patch
> individually to the mailing list, without a common cover letter, and
> without numbering in the subject lines. That's what I'd call "doesn't
> care about branches just patches", and it's unusable for development.
> 
> (b) Someone sends a normal patch series, they just don't state what
> upstream commit the series applies to. I can sort-of see this as "no
> topic branch, just patches". Is this what you mean? Does Phabricator
> maintain the series of patches as such (without a base commit), i.e. the
> set of patches in the series, and their relative order?
> 
> (c) An actual pull request that refers to a specific commit hash (which
> may or may not, although it almost always is, identified by a branch
> head or tag).

Sigh, I failed to finish (c). I meant to ask, assuming I upload my work
(a topic branch) via git-push to the phabricator instance that hosts my
personal clone -- when I submit the pull request, does the pull req
preserve the specific commit hash (and hence the full git history
leading up to it), or does the request decay to (b), similarly to the
"normal" mailing list posting?

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

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

[Laszlo Ersek]

On 12/05/18 18:26, Rebecca Cran wrote:
> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> 
>> (1) Pls. explain to me how I can create an edk2 clone at
>> . :)
> 
> You don't. In a production system it may be possible to clone from either 
> GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
> when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
> work (since I've not configured it).

Well, I don't specifically desire creating an edk2 clone on
 *using the WebUI*. However, in order to share my
work (i.e. to submit a pull request that refers to a topic branch of
mine), I need to have a publicly available / fetchable git repository.
(This is no different from mailing list based pull requests BTW.)

So, let me reformulate: can I *have* (by any means) a personal edk2
clone on , and can I push my topic branches there?
(Obviously it's not specifically about me nor specifically about
, but about any contributor with a topic branch to
submit, and about any site that would possibly run the central edk2
Phabricator instance.)

Right now I'm confused whether Phabricator (in general) offers
repository storage for contributors, or if that would have to come from
another service. (That wouldn't be too convenient.)

Anyway, the goal of a personal edk2 repo (clone) for me on
 would be that I should be able to receive pull
requests against it.

Am I misunderstanding something?

>  
>> (2) Please create a throw-away account for yourself.
> 
> Done (though not throw-away).

I suggested "throw-away" because one of the later steps involves
deleting it.

>  
>> (3) Submit a pullreq against (1), with a topic branch that has two
>> commits, and simple text file modifications.
> 
> https://code.bluestop.org/D1
> Since Phabricator doesn't care about topic branches (just patches),

Please wait a second, I don't understand. What do you mean by "doesn't
care about topic branches, just patches"?

Compare three scenarios:

(a) Someone implements a new feature in 10 patches, and sends each patch
individually to the mailing list, without a common cover letter, and
without numbering in the subject lines. That's what I'd call "doesn't
care about branches just patches", and it's unusable for development.

(b) Someone sends a normal patch series, they just don't state what
upstream commit the series applies to. I can sort-of see this as "no
topic branch, just patches". Is this what you mean? Does Phabricator
maintain the series of patches as such (without a base commit), i.e. the
set of patches in the series, and their relative order?

(c) An actual pull request that refers to a specific commit hash (which
may or may not, although it almost always is, identified by a branch
head or tag).

Thanks,
Laszlo

> I created a diff to README.
> 

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

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

[Laszlo Ersek]

On 12/05/18 18:31, Rebecca Cran wrote:
> On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> 
>> Can you assist with the following please?
> 
> Also, a couple of notes:
> 
> Go to https://code.bluestop.org/settings/user/lersek/  to configure 
> preferences 
> related to emails (http/plain), diffs etc.
> 
> Install the arcanist package on your system or follow the instructions at 
> https://secure.phabricator.com/book/phabricator/article/arcanist/#installing-arcanist
>  to get a copy (the 'arc' command). It's the command-line interface to 
> Phabricator.

That's optional, right? It's OK if it improves interaction with
Phabricator, but hopefully it shouldn't be a hard requirement.

(It seems that arcanist is not packaged for Fedora -- I don't see builds
in Koji past Fedora 25:


and the Review Request RHBZ at
 is still "ASSIGNED".)

> 
> https://code.bluestop.org/differential/ is your main code reviews page.
> https://code.bluestop.org/diffusion/ is a repo browser.
> https://code.bluestop.org/maniphest/ (if we were to use it) is for tasks and 
> bugs.
> 

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

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

[Laszlo Ersek]

On 12/05/18 20:09, Jeremiah Cox wrote:
> Hi Laszlo,
> Regarding "comprehensive backup/archival functionality that is core to the 
> service itself", are you speaking more to GitHub's internal metadata 
> verbosity (e.g. not losing PR details when branches and repos are deleted), 
> GitHub's backup strategy to prevent data loss, or the ability to export all 
> of this data from GitHub?

The last one.

Unless the service sends sufficiently comprehensive emails, so that a
human reader -- note: not writer -- can later get a full understanding
of the events related to the project, the service should provide some
other (core) functionality to keep an external archive up-to-date at all
times. The goal of both alternatives is the same -- at any point, if the
service suddenly becomes unusable, the project should be at liberty to
take its past with itself elsewhere. At that point, extracting data may
no longer be possible, which is why the archive should continuously be
refreshed, on-line.

> I believe your PR experiments are exploring the first point about metadata 
> verbosity.

Not exactly / not only. I care about multiple topics. One is the
usability of the WebUI itself (e.g. what artifacts one can attach review
comments to). Another is the longevity of artifacts as they are
presented on the WebUI (and to local git command lines). Yet another is
how independent a project can remain / how easily it can take its past
with itself elsewhere. Others have mentioned offline reviewing of
project events (recent or not so recent).

> We've done some experimentation of our own and have found the verbosity 
> acceptable for us.
> 
> GitHub's internal backup strategy is published:
> https://help.github.com/articles/github-security/#file-system-and-backups 
> 
> Regarding export, I discovered GitHub has a preview REST API dedicated to 
> backup & archival.  GitHub will package up all of our metadata into a big 
> tarball:
> https://developer.github.com/v3/migrations/orgs/ 
> At a glance it appears to be simple to use and comprehensive.

If this archive is complete (that is, if we download it on Monday, fail
to download it on Tuesday, manage to download it again on Wednesday, and
the Wed download contains all the Tues events as well), then I agree it
is comprehensive enough, because outages in the consumer component will
not cause permanent data loss -- eventually the next successful download
will fill the gap.

I'm unsure about the scope of this feature however. The page you linked
starts with:

The organization migrations API lets you move a repository from
GitHub to GitHub Enterprise.

That's not really what I have in mind; instead, if the above
(comprehensive) download is offered indeed, we should download it daily.
That would sort-of cover alternative #2.

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

Re: [edk2] [PATCH] MdeModulePkg/PciBus: Shadow option ROM after BARs are programmed

[Wu, Hao A]

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 05, 2018 5:25 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH] MdeModulePkg/PciBus: Shadow option ROM after BARs
> are programmed
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1376
> 
> Today's implementation reuses the 32bit MMIO resource requested by
> all PCI devices MMIO BARs when shadowing the option ROM.
> Take a simple example, a system has only one PCI device. It requires
> 8MB 32bit MMIO and contains a 4MB option ROM. Today's implementation
> only requests 8MB (max of 4M and 8M) 32bit MMIO from
> PciHostBridgeResourceAllocation protocol. Let's assume the MMIO range
> [3GB, 3GB+8MB) is allocated. The 3GB base address is firstly
> programmed to the option ROM BAR for option ROM shadow. Then the
> option ROM decoding is turned off and 3GB base address is programmed
> to the 32bit MMIO BAR.
> 
> It doesn't cause issues when the device doesn't request too much
> MMIO.
> But when the device contains a 64bit MMIO BAR which requests 4GB MMIO
> and a 4MB option ROM. Let's assume [3GB, 3GB+8MB) 32bit MMIO range is

"[3GB, 3GB+4MB)" here?

> allocated for the option ROM. When the option ROM is being shadowed,
> 64bit MMIO BAR is programmed to value 0, which means [0, 4GB) MMIO is
> given to the 64bit BAR.
> The range overlaps with the option ROM range which may cause the
> device malfunction (e.g.: option ROM cannot be read out) when the
> device has two separate decoders: one for MMIO BAR, the other for
> option ROM.
> 
> The patch requests dedicated MEM32 resource for Option ROMs and
> moves the Option ROM shadow logic after all MMIO BARs are programmed.
> The MMIO BAR setting to 0 when shadowing Option ROM is also skipped
> because the MMIO BAR already contains the correct value.

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Hao A Wu 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h|  3 +-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c| 71 
> --
>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c| 13 
>  .../Bus/Pci/PciBusDxe/PciResourceSupport.c | 37 ++-
>  4 files changed, 62 insertions(+), 62 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> index f9eebdd5a8..6938802857 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> @@ -1,7 +1,7 @@
>  /** @file
>Header files and data structures needed by PCI Bus module.
> 
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be
> found at
> @@ -67,6 +67,7 @@ typedef enum {
>PciBarTypePMem32,
>PciBarTypeMem64,
>PciBarTypePMem64,
> +  PciBarTypeOpRom,
>PciBarTypeIo,
>PciBarTypeMem,
>PciBarTypeMaxType
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> index b81f81a136..7255bcfbbc 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> @@ -24,6 +24,7 @@ CHAR16 *mBarTypeStr[] = {
>L"PMem32",
>L" Mem64",
>L"PMem64",
> +  L" OpRom",
>L"Io",
>L"   Mem",
>L"Unknow"
> @@ -425,15 +426,9 @@ PciHostBridgeResourceAllocator (
>PCI_RESOURCE_NODE  PMem32Pool;
>PCI_RESOURCE_NODE  Mem64Pool;
>PCI_RESOURCE_NODE  PMem64Pool;
> -  BOOLEANReAllocate;
>EFI_DEVICE_HANDLE_EXTENDED_DATA_PAYLOADHandleExtendedData;
>EFI_RESOURCE_ALLOC_FAILURE_ERROR_DATA_PAYLOAD
> AllocFailExtendedData;
> 
> -  //
> -  // Reallocate flag
> -  //
> -  ReAllocate = FALSE;
> -
>//
>// It may try several times if the resource allocation fails
>//
> @@ -514,6 +509,17 @@ PciHostBridgeResourceAllocator (
> PciResUsageTypical
> );
> 
> +  //
> +  // Get the max ROM size that the root bridge can process
> +  // Insert to resource map so that there will be dedicate MEM32 resource
> range for Option ROM.
> +  // All devices' Option ROM share the same MEM32 resource.
> +  //
> +  MaxOptionRomSize = GetMaxOptionRomSize (RootBridgeDev);
> +  RootBridgeDev->PciBar[0].BarType   = PciBarTypeOpRom;
> +  RootBridgeDev->PciBar[0].Length= MaxOptionRomSize;
> +  RootBridgeDev->PciBar[0].Alignment = MaxOptionRomSize - 1;
> +  GetResourceFromDevice (RootBridgeDev, IoBridge, Mem32Bridge,
> PMem32Bridge, Mem64Bridge, PMem64Bridge);
> +
>//
>// Create 

[edk2] [PATCH] Platform/ARM/SgiPkg: Add support for HDLCD

[Vijayenthiran Subramaniam]

Add HDLCD platform library for SGI platform that implements platform
callbacks for the Arm HDLCD driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vijayenthiran Subramaniam 
---
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |   6 +
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   6 +
 Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf |  37 +++
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |   4 +
 Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgi.c  | 262 

 Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c  |   8 +-
 6 files changed, 322 insertions(+), 1 deletion(-)

diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc 
b/Platform/ARM/SgiPkg/SgiPlatform.dsc
index 0c794c6b299d..7995c7d132d6 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc
@@ -37,6 +37,8 @@ [LibraryClasses.common]
   ArmPlatformLib|Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
   BasePathLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
   
EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
+  LcdHwLib|ArmPlatformPkg/Library/HdLcd/HdLcd.inf
+  LcdPlatformLib|Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
   NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/NorFlashLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
@@ -155,6 +157,9 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PL011UartInteger|4
   gArmPlatformTokenSpaceGuid.PL011UartFractional|0
 
+  ## PL370 - HDLCD1
+  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x7FF6
+
   ## PL011 - Serial Debug UART
   gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase|0x7FF8
   gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz|7372800
@@ -235,6 +240,7 @@ [Components.common]
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
   EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
diff --git a/Platform/ARM/SgiPkg/SgiPlatform.fdf 
b/Platform/ARM/SgiPkg/SgiPlatform.fdf
index ddf1fda5a16e..80c3412fd4ad 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.fdf
+++ b/Platform/ARM/SgiPkg/SgiPlatform.fdf
@@ -133,6 +133,9 @@ [FV.FvMain]
   #
   # Multiple Console IO support
   #
+  INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
+  INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
+  INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
   INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
 
@@ -144,6 +147,9 @@ [FV.FvMain]
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
 
+  # Graphics Output Protocol
+  INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
+
   INF Platform/ARM/Drivers/BootMonFs/BootMonFs.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
 
diff --git a/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf 
b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
new file mode 100644
index ..25efbea5fb83
--- /dev/null
+++ b/Platform/ARM/SgiPkg/Library/HdLcdArmSgiLib/HdLcdArmSgiLib.inf
@@ -0,0 +1,37 @@
+#
+#  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= 0x0001001A
+  BASE_NAME  = HdLcdArmSgiLib
+  FILE_GUID  = 0C77342C-7895-4DE1-A9C8-1DBBFA71AF34
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = LcdPlatformLib
+
+[Sources.common]
+  HdLcdArmSgi.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  MdePkg/MdePkg.dec
+  Platform/ARM/SgiPkg/SgiPlatform.dec
+
+[LibraryClasses]
+  BaseLib
+
+[FixedPcd]
+  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize
+  gArmPlatformTokenSpaceGuid.PcdGopPixelFormat
diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
index 550189565752..b9a662ae41a1 100644
--- 

Re: [edk2] [PATCH] Maintainers.txt: Remove DuetPkg

[Wu, Hao A]

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> -Original Message-
> From: Zhang, Shenglei
> Sent: Thursday, December 06, 2018 11:12 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu; Wu, Hao A; Andrew Fish; Laszlo Ersek; Leif Lindholm; Kinney,
> Michael D
> Subject: [PATCH] Maintainers.txt: Remove DuetPkg
> 
> Since DuetPkg is due to be removed, Maintainers.txt
> should also be updated.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1322
> 
> Cc: Ruiyu Ni 
> Cc: Hao Wu 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> ---
>  Maintainers.txt | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3f6e4e091b..001d8ba010 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -105,11 +105,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
>  M: Qin Long 
>  M: Ting Ye 
> 
> -DuetPkg
> -W: https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
> -M: Ruiyu Ni 
> -M: Hao Wu 
> -
>  DynamicTablesPkg
>  W:
> https://github.com/tianocore/tianocore.github.io/wiki/DynamicTablesPkg
>  M: Evan Lloyd 
> --
> 2.18.0.windows.1

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

[edk2] [PATCH edk2-platforms 0/2] Silicon/Styx: merge and simplify ACPI platform driver

[Ard Biesheuvel]

After fixing the iasl issue yesterday, I got a bit carried away and ended
up rewriting most of the ACPI table generation logic for Styx. So this
applies on top of the patches I sent out yesterday.

Patch #1 merges the DXE driver and the library, that are split in two for
no good reason.

Patch #2 simplifies the MADT generation code.

Ard Biesheuvel (2):
  Silicon/AMD/Styx: merge ACPI table drivers
  Silicon/Styx/AcpiPlatformDxe: simplify MADT generation logic

 .../AMD/OverdriveBoard/OverdriveBoard.dsc |   1 -
 Platform/LeMaker/CelloBoard/CelloBoard.dsc|   1 -
 .../Overdrive1000Board/Overdrive1000Board.dsc |   1 -
 .../AMD/OverdriveBoard/OverdriveBoard.fdf |   1 +
 Platform/LeMaker/CelloBoard/CelloBoard.fdf|   1 +
 .../Overdrive1000Board/Overdrive1000Board.fdf |   1 +
 Silicon/AMD/Styx/AcpiTables/AcpiTables.inf|  85 -
 .../AcpiPlatformDxe/AcpiPlatformDxe.inf   |  34 +-
 .../AcpiPlatformDxe/AcpiPlatform.h}   |  11 +-
 Silicon/AMD/Styx/AcpiTables/Madt.c| 318 --
 .../Drivers/AcpiPlatformDxe/AcpiPlatform.c| 155 +
 .../AcpiPlatformDxe/Csrt.aslc}|  13 +-
 .../AcpiPlatformDxe/Dbg2.aslc}|  12 +-
 .../AcpiPlatformDxe/Fadt.aslc}|  11 +-
 .../AcpiPlatformDxe/Gtdt.aslc}|  20 +-
 .../AcpiPlatformDxe/Iort.aslc}|  19 +-
 .../Styx/Drivers/AcpiPlatformDxe/Madt.aslc| 117 +++
 .../AcpiPlatformDxe/Mcfg.aslc}|  13 +-
 .../AcpiPlatformDxe/Pptt.aslc}|  10 +-
 .../AcpiPlatformDxe/Spcr.aslc}|  12 +-
 20 files changed, 264 insertions(+), 572 deletions(-)
 delete mode 100644 Silicon/AMD/Styx/AcpiTables/AcpiTables.inf
 rename Silicon/AMD/Styx/{Common/AmdStyxAcpiLib.h => 
Drivers/AcpiPlatformDxe/AcpiPlatform.h} (81%)
 delete mode 100644 Silicon/AMD/Styx/AcpiTables/Madt.c
 rename Silicon/AMD/Styx/{AcpiTables/Csrt.c => 
Drivers/AcpiPlatformDxe/Csrt.aslc} (93%)
 rename Silicon/AMD/Styx/{AcpiTables/Dbg2.c => 
Drivers/AcpiPlatformDxe/Dbg2.aslc} (95%)
 rename Silicon/AMD/Styx/{AcpiTables/Fadt.c => 
Drivers/AcpiPlatformDxe/Fadt.aslc} (96%)
 rename Silicon/AMD/Styx/{AcpiTables/Gtdt.c => 
Drivers/AcpiPlatformDxe/Gtdt.aslc} (92%)
 rename Silicon/AMD/Styx/{AcpiTables/Iort.c => 
Drivers/AcpiPlatformDxe/Iort.aslc} (95%)
 create mode 100644 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Madt.aslc
 rename Silicon/AMD/Styx/{AcpiTables/Mcfg.c => 
Drivers/AcpiPlatformDxe/Mcfg.aslc} (86%)
 rename Silicon/AMD/Styx/{AcpiTables/Pptt.c => 
Drivers/AcpiPlatformDxe/Pptt.aslc} (97%)
 rename Silicon/AMD/Styx/{AcpiTables/Spcr.c => 
Drivers/AcpiPlatformDxe/Spcr.aslc} (90%)

-- 
2.19.2

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

[edk2] [PATCH edk2-platforms 1/2] Silicon/AMD/Styx: merge ACPI table drivers

[Ard Biesheuvel]

ACPI table support on Seattle is split into two parts for no good
reason: AcpiPlatformDxe and AmdStyxAcpiLib. Let's merge them
together, and clean up the code that iterates over the tables and
installs them.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
  |   1 -
 Platform/LeMaker/CelloBoard/CelloBoard.dsc 
  |   1 -
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
  |   1 -
 Platform/AMD/OverdriveBoard/OverdriveBoard.fdf 
  |   1 +
 Platform/LeMaker/CelloBoard/CelloBoard.fdf 
  |   1 +
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.fdf
  |   1 +
 Silicon/AMD/Styx/AcpiTables/AcpiTables.inf 
  |  85 --
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf   
  |  31 +-
 Silicon/AMD/Styx/{Common/AmdStyxAcpiLib.h => 
Drivers/AcpiPlatformDxe/AcpiPlatform.h} |   9 --
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.c
  | 117 +---
 Silicon/AMD/Styx/{AcpiTables => Drivers/AcpiPlatformDxe}/Madt.c
  |   3 +-
 Silicon/AMD/Styx/{AcpiTables/Csrt.c => Drivers/AcpiPlatformDxe/Csrt.aslc}  
  |  13 +--
 Silicon/AMD/Styx/{AcpiTables/Dbg2.c => Drivers/AcpiPlatformDxe/Dbg2.aslc}  
  |  12 +-
 Silicon/AMD/Styx/{AcpiTables/Fadt.c => Drivers/AcpiPlatformDxe/Fadt.aslc}  
  |  11 +-
 Silicon/AMD/Styx/{AcpiTables/Gtdt.c => Drivers/AcpiPlatformDxe/Gtdt.aslc}  
  |  20 +---
 Silicon/AMD/Styx/{AcpiTables/Iort.c => Drivers/AcpiPlatformDxe/Iort.aslc}  
  |  19 +---
 Silicon/AMD/Styx/{AcpiTables/Mcfg.c => Drivers/AcpiPlatformDxe/Mcfg.aslc}  
  |  13 +--
 Silicon/AMD/Styx/{AcpiTables/Pptt.c => Drivers/AcpiPlatformDxe/Pptt.aslc}  
  |  10 +-
 Silicon/AMD/Styx/{AcpiTables/Spcr.c => Drivers/AcpiPlatformDxe/Spcr.aslc}  
  |  12 +-
 19 files changed, 108 insertions(+), 253 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 2843e51f93f7..87731357e2eb 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -121,7 +121,6 @@ DEFINE DO_CAPSULE   = FALSE
   # Styx specific libraries
   #
   
AmdSataInit|Silicon/AMD/Styx/AmdModulePkg/Library/AmdSataInitLib/AmdSataInitLib.inf
-  AmdStyxAcpiLib|Silicon/AMD/Styx/AcpiTables/AcpiTables.inf
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
   
RealTimeClockLib|Silicon/AMD/Styx/Library/RealTimeClockLib/RealTimeClockLib.inf
 
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 057bf0eb67de..29e740695366 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -118,7 +118,6 @@ DEFINE DO_FLASHER   = FALSE
   # Styx specific libraries
   #
   
AmdSataInit|Silicon/AMD/Styx/AmdModulePkg/Library/AmdSataInitLib/AmdSataInitLib.inf
-  AmdStyxAcpiLib|Silicon/AMD/Styx/AcpiTables/AcpiTables.inf
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
   
RealTimeClockLib|Silicon/AMD/Styx/Library/RealTimeClockLib/RealTimeClockLib.inf
 
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 985ba2253a90..f342cf82d251 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -117,7 +117,6 @@ DEFINE DO_FLASHER   = FALSE
   # Styx specific libraries
   #
   
AmdSataInit|Silicon/AMD/Styx/AmdModulePkg/Library/AmdSataInitLib/AmdSataInitLib.inf
-  AmdStyxAcpiLib|Silicon/AMD/Styx/AcpiTables/AcpiTables.inf
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
   
RealTimeClockLib|Silicon/AMD/Styx/Library/RealTimeClockLib/RealTimeClockLib.inf
 
diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
index 96df83e0da5a..c7e27e20ad4a 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
@@ -454,6 +454,7 @@ CAPSULE_HEADER_INIT_VERSION = 0x1
 PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 UI   STRING="$(MODULE_NAME)" Optional
 RAW  ASLOptional|.aml
+RAW  ACPI   Optional|.acpi
   }
 
 [Rule.Common.DXE_RUNTIME_DRIVER]
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.fdf 
b/Platform/LeMaker/CelloBoard/CelloBoard.fdf
index fc977f14b5a1..6362257deb8c 100644
--- 

[edk2] [PATCH edk2-platforms 2/2] Silicon/Styx/AcpiPlatformDxe: simplify MADT generation logic

[Ard Biesheuvel]

The MADT generation code is rather unpolished and overcomplicated,
and rewrites most of the table with information that is known
statically at build time, with the exception of which CPUs are
actually online.

So remove all the runtime generation code, and replace it with a
simple loop that sets the 'enabled' flag on each CPU that is
reported as present by the secure firmware.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf |   5 +-
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.h  |   2 +-
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.c  |  64 +++-
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Madt.c  | 319 

 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Madt.aslc   | 117 +++
 5 files changed, 172 insertions(+), 335 deletions(-)

diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 95745db00ff3..2a42d76d4883 100644
--- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -34,7 +34,7 @@
   Fadt.aslc
   Gtdt.aslc
   Iort.aslc
-  Madt.c
+  Madt.aslc
   Mcfg.aslc
   Pptt.aslc
   Spcr.aslc
@@ -49,6 +49,7 @@
   Silicon/AMD/Styx/AmdStyx.dec
 
 [LibraryClasses]
+  ArmLib
   BaseLib
   BaseMemoryLib
   DebugLib
@@ -92,4 +93,4 @@
   gEfiAcpiTableProtocolGuid ## ALWAYS_CONSUMED
 
 [Depex]
-  gEfiAcpiTableProtocolGuid
+  gEfiAcpiTableProtocolGuid AND gAmdMpCoreInfoProtocolGuid
diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.h 
b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.h
index b1864131795a..883dc9df36f9 100644
--- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.h
+++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.h
@@ -18,7 +18,7 @@
 
 #include 
 
-EFI_ACPI_DESCRIPTION_HEADER *MadtHeader (void);
+#define MAX_CORES8
 
 #define EFI_ACPI_AMD_OEM_ID_ARRAY{'A','M','D','I','N','C'}
 #define EFI_ACPI_AMD_OEM_TABLE_ID
SIGNATURE_64('S','E','A','T','T','L','E',' ')
diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.c 
b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.c
index ff1326982329..f1223ada2444 100644
--- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.c
+++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/AcpiPlatform.c
@@ -19,8 +19,12 @@
MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
 **/
 
+#include 
+
 #include 
+#include 
 
+#include 
 #include 
 #include 
 #include 
@@ -37,6 +41,7 @@
 #include "AcpiPlatform.h"
 
 STATIC EFI_ACPI_TABLE_PROTOCOL   *mAcpiTableProtocol;
+STATIC AMD_MP_CORE_INFO_PROTOCOL *mAmdMpCoreInfoProtocol;
 
 #if DO_XGBE
 
@@ -89,20 +94,49 @@ PatchAmlPackage (
 
 #endif
 
+STATIC
+VOID
+EnableAvailableCores (
+  EFI_ACPI_5_1_GIC_STRUCTURE*GicC
+  )
+{
+  ARM_CORE_INFO *ArmCoreInfoTable;
+  UINTN CoreCount;
+  UINTN Index;
+
+  CoreCount = 0;
+  ArmCoreInfoTable = mAmdMpCoreInfoProtocol->GetArmCoreInfoTable ();
+  ASSERT (ArmCoreInfoTable != NULL);
+
+  while (CoreCount--) {
+for (Index = 0; Index < MAX_CORES; Index++) {
+  if (GicC[Index].MPIDR == GET_MPID (ArmCoreInfoTable->ClusterId,
+ ArmCoreInfoTable->CoreId)) {
+GicC[Index].Flags |= EFI_ACPI_5_1_GIC_ENABLED;
+break;
+  }
+}
+ArmCoreInfoTable++;
+  }
+}
+
 STATIC
 VOID
 InstallSystemDescriptionTables (
   VOID
   )
 {
-  EFI_ACPI_DESCRIPTION_HEADER   *Table;
-  EFI_STATUSStatus;
-  UINT32CpuId;
-  UINTN Index;
-  UINTN TableSize;
-  UINTN TableHandle;
-  EFI_ACPI_5_1_GENERIC_TIMER_DESCRIPTION_TABLE  *Gtdt;
-  EFI_ACPI_6_0_IO_REMAPPING_TABLE   *Iort;
+  EFI_ACPI_DESCRIPTION_HEADER *Table;
+  EFI_STATUS  Status;
+  UINT32  CpuId;
+  UINTN   Index;
+  UINTN   TableSize;
+  UINTN   TableHandle;
+  EFI_ACPI_5_1_GENERIC_TIMER_DESCRIPTION_TABLE*Gtdt;
+  EFI_ACPI_6_0_IO_REMAPPING_TABLE *Iort;
+  EFI_ACPI_5_1_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER *Madt;
+  EFI_ACPI_5_1_GIC_STRUCTURE  *GicC;
+
 #if DO_XGBE
   UINT8 MacPackage[sizeof(mDefaultMacPackageA)];
 #endif
@@ -163,6 +197,13 @@ InstallSystemDescriptionTables (
   Gtdt->PlatformTimerOffset = 0;
 }
   

Re: [edk2] [Patch] BaseTools: Correct CCFLAG for PcdValueInit

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, November 28, 2018 5:01 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [Patch] BaseTools: Correct CCFLAG for PcdValueInit
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1361
> This patch is going to correct the CCFlag
> for building PcdValueInit
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: BobCF 
> Cc: Liming Gao 
> ---
>  .../Source/Python/Workspace/DscBuildData.py   | 24 +--
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index 11aa63fb26..c04f970c7d 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -2184,20 +2184,20 @@ class DscBuildData(PlatformBuildClassObject):
>  return False
>  return True
> 
>  def ParseCCFlags(self, ccflag):
>  ccflags = set()
> -flag = ""
> -for ch in ccflag:
> -if ch in (r"/", "-"):
> -if flag.strip():
> -ccflags.add(flag.strip())
> -flag = ch
> -else:
> -flag += ch
> -if flag.strip():
> -ccflags.add(flag.strip())
> +ccflaglist = ccflag.split(" ")
> +i = 0
> +while i < len(ccflaglist):
> +item = ccflaglist[i].strip()
> +if item in (r"/D", r"/U","-D","-U"):
> +ccflags.add(" ".join((ccflaglist[i],ccflaglist[i+1])))
> +i = i+1
> +elif item.startswith((r"/D", r"/U","-D","-U")):
> +ccflags.add(item)
> +i +=1
>  return ccflags
>  def GenerateByteArrayValue (self, StructuredPcds):
>  #
>  # Generate/Compile/Run C application to determine if there are any 
> flexible array members
>  #
> @@ -2318,11 +2318,11 @@ class DscBuildData(PlatformBuildClassObject):
>  if Target == "*" or Target == self._Target:
>  if Tag == "*" or Tag == self._Toolchain:
>  if 'COMMON' not in BuildOptions:
>  BuildOptions['COMMON'] = set()
>  if Arch == "*":
> -
> BuildOptions['COMMON'].add(self.BuildOptions[Options])
> +BuildOptions['COMMON']|= 
> self.ParseCCFlags(self.BuildOptions[Options])
>  if Arch in self.SupArchList:
>  if Arch not in BuildOptions:
>  BuildOptions[Arch] = set()
>  BuildOptions[Arch] |= 
> self.ParseCCFlags(self.BuildOptions[Options])
> 
> @@ -2332,11 +2332,11 @@ class DscBuildData(PlatformBuildClassObject):
>  BuildOptions['COMMON'] |= (ArchBuildOptions.values()[0])
>  elif len(ArchBuildOptions.keys()) > 1:
>  CommonBuildOptions = reduce(lambda x,y: x, 
> ArchBuildOptions.values())
>  BuildOptions['COMMON'] |= CommonBuildOptions
>  ValueList = list(BuildOptions['COMMON'])
> -CC_FLAGS += " ".join([item for item in ValueList if 
> item.startswith(('-D', '/D', '-U', '/U'))])
> +CC_FLAGS += " ".join(ValueList)
>  MakeApp += CC_FLAGS
> 
>  if sys.platform == "win32":
>  MakeApp = MakeApp + PcdMakefileEnd
>  MakeApp = MakeApp + AppTarget % ("""\tcopy $(APPLICATION) 
> $(APPFILE) /y """)
> --
> 2.19.1.windows.1

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

Re: [edk2] [PATCH] Maintainers.txt: Remove DuetPkg

[Laszlo Ersek]

On 12/06/18 04:11, Shenglei Zhang wrote:
> Since DuetPkg is due to be removed, Maintainers.txt
> should also be updated.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1322
> 
> Cc: Ruiyu Ni 
> Cc: Hao Wu 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> ---
>  Maintainers.txt | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3f6e4e091b..001d8ba010 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -105,11 +105,6 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
>  M: Qin Long 
>  M: Ting Ye 
>  
> -DuetPkg
> -W: https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
> -M: Ruiyu Ni 
> -M: Hao Wu 
> -
>  DynamicTablesPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/DynamicTablesPkg
>  M: Evan Lloyd 
> 

Please push this right after removing DuetPkg itself.

Reviewed-by: Laszlo Ersek 

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