Re: [edk2] Transition to GitHub is complete

[Ryan Harkin]

On 3 February 2016 at 08:51, Ard Biesheuvel  wrote:
> On 3 February 2016 at 00:40, Jordan Justen  wrote:
>> On 2016-02-02 09:47:23, Jordan Justen wrote:
>>> As mentioned previously, we will attempt to transition to GitHub
>>> starting this morning (around 10AM PST, UTC-8). One of the first steps
>>> will be to disable SourceForge SVN write access.
>>>
>>> You can follow the progress here:
>>>
>>> https://github.com/tianocore/tianocore.github.io/wiki/Transition-to-GitHub
>>>
>>
>> Ok, all the major transition tasks have been completed now.
>>
>> Laszlo took the honor of pushing the first commit directly to the
>> GitHub repo, so it appears that the package maintainers should have
>> push access now. (Thanks Laszlo!)
>>
>> And, for months, quite a few people at Intel have been working behind
>> the scenes to get everything ready for the transition. Thanks!
>>
>> Now, good luck to us on a (hopefully smooth) transition to using git
>> directly for day-to-day development work!
>>
>> Merry EDK II Git Day!
>>
>
> Great news! Thanks to everyone involved.
>

Fabulous news :-)  Thanks a lot for the hard work!
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2 0/3] Fix several issues related to TX buffer recycle

[Laszlo Ersek]

On 02/03/16 04:46, Fu Siyuan wrote:
> 1. MdeModulePkg-Update-the-default-size-of-MNP-TX-buffer.
> 2. Update DBsize in SNP GetStatus command
> 3. Correct one return status code in SNP Transmit function.
> 
> Fu Siyuan (3):
>   MdeModulePkg: Update the default size of MNP TX buffer pool.
>   MdeModulePkg: Update DBsize in SNP GetStatus command.
>   MdeModulePkg: Correct one return status code in SNP Transmit function.
> 
>  MdeModulePkg/Universal/Network/MnpDxe/MnpImpl.h| 2 +-
>  MdeModulePkg/Universal/Network/SnpDxe/Get_status.c | 2 +-
>  MdeModulePkg/Universal/Network/SnpDxe/Transmit.c   | 3 ++-
>  3 files changed, 4 insertions(+), 3 deletions(-)
> 

With the comment in the context of patch #2 cleaned up, as suggested by
Sriram (this can occur right before you commit):

Series
Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v3 1/6] ArmPlatformPkg: Add FileExplorerLib.inf to the dsc file

[Ryan Harkin]

On 3 February 2016 at 05:01, Dandan Bi  wrote:
> V3: Add FileExplorerLib when SECURE_BOOT_ENABLE == TRUE, so
> when to use FileExplorerLib is clear.
>
> Because SecureBootConfigDxe use FileExplorerLib now, but
> FileExplorerLib is not in the dsc file of the package
> that use SecureBootConfigDxe. Now add it to pass build.
>
>
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Ryan.Harkin 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
> index af46331..ee6fa8e 100644
> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
> @@ -1,8 +1,8 @@
>  #
>  #  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
> -#  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2015-2016, 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
>  #  http://opensource.org/licenses/bsd-license.php
> @@ -48,10 +48,14 @@ [LibraryClasses.common]
>
># Virtio Support
>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>
> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +!endif
> +
>  [LibraryClasses.common.SEC]
>ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf
>
> ArmPlatformSecLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/ArmVExpressSecLib.inf
>
> ArmPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLibSec.inf
>
> --
> 1.9.5.msysgit.1
>

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

Re: [edk2] [PATCH v3 2/6] ArmVirPkg: Add FileExplorerLib.inf to the dsc file

[Laszlo Ersek]

On 02/03/16 06:01, Dandan Bi wrote:
> V3: Add FileExplorerLib when SECURE_BOOT_ENABLE == TRUE, so 
> when to use FileExplorerLib is clear.
> 
> Because SecureBootConfigDxe use FileExplorerLib now, but
> FileExplorerLib is not in the dsc file of the package
> that use SecureBootConfigDxe. Now add it to pass build.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index e6440ec..0a21bf1 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -1,9 +1,9 @@
>  #
>  #  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
>  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
> -#  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2015-2016, 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
>  #  http://opensource.org/licenses/bsd-license.php
> @@ -60,10 +60,13 @@ [LibraryClasses.common]
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>
> GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
>
> PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +!endif
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>  
>  [LibraryClasses.AARCH64.SEC]
> 

Nice.

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

Re: [edk2] [PATCH v3 3/6] OvmfPkg: Add FileExplorerLib.inf to the dsc file

[Laszlo Ersek]

On 02/03/16 06:01, Dandan Bi wrote:
> V3: Add FileExplorerLib when SECURE_BOOT_ENABLE == TRUE, so 
> when to use FileExplorerLib is clear.
> 
> Because SecureBootConfigDxe use FileExplorerLib now, but
> FileExplorerLib is not in the dsc file of the package
> that use SecureBootConfigDxe. Now add it to pass build.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 5 -
>  OvmfPkg/OvmfPkgIa32X64.dsc | 5 -
>  OvmfPkg/OvmfPkgX64.dsc | 5 -
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index a6d8d63..d74427c 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -1,9 +1,9 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2016, 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
>  #  http://opensource.org/licenses/bsd-license.php
> @@ -280,10 +280,13 @@ [LibraryClasses.common.DXE_DRIVER]
>  !endif
>  !ifdef $(SOURCE_DEBUG_ENABLE)
>DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
>  !endif
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +!endif
>  
>  [LibraryClasses.common.UEFI_APPLICATION]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 299c862..e3928ce 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -1,9 +1,9 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2016, 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
>  #  http://opensource.org/licenses/bsd-license.php
> @@ -285,10 +285,13 @@ [LibraryClasses.common.DXE_DRIVER]
>  !endif
>  !ifdef $(SOURCE_DEBUG_ENABLE)
>DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
>  !endif
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +!endif
>  
>  [LibraryClasses.common.UEFI_APPLICATION]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index fa37b1e..5a7c22b 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -1,9 +1,9 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2016, 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
>  #  http://opensource.org/licenses/bsd-license.php
> @@ -285,10 +285,13 @@ [LibraryClasses.common.DXE_DRIVER]
>  !endif
>  !ifdef $(SOURCE_DEBUG_ENABLE)
>DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
>  !endif
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +!endif
>  
>  [LibraryClasses.common.UEFI_APPLICATION]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> 

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

Re: [edk2] Transition to GitHub is complete

[Ard Biesheuvel]

On 3 February 2016 at 00:40, Jordan Justen  wrote:
> On 2016-02-02 09:47:23, Jordan Justen wrote:
>> As mentioned previously, we will attempt to transition to GitHub
>> starting this morning (around 10AM PST, UTC-8). One of the first steps
>> will be to disable SourceForge SVN write access.
>>
>> You can follow the progress here:
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/Transition-to-GitHub
>>
>
> Ok, all the major transition tasks have been completed now.
>
> Laszlo took the honor of pushing the first commit directly to the
> GitHub repo, so it appears that the package maintainers should have
> push access now. (Thanks Laszlo!)
>
> And, for months, quite a few people at Intel have been working behind
> the scenes to get everything ready for the transition. Thanks!
>
> Now, good luck to us on a (hopefully smooth) transition to using git
> directly for day-to-day development work!
>
> Merry EDK II Git Day!
>

Great news! Thanks to everyone involved.

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

Re: [edk2] SATA 3.0 AHCI host controller codebase

[Leif Lindholm]

Hi Shaveta,

On Tue, Feb 02, 2016 at 07:05:03AM +, Shaveta Leekha wrote:
> Is there some SATA 3.0 AHCI driver implementation in UEFI / EDK code?
> The one I need to write for our platform is not PCI based.
> 
> I have seen few implementations in EDK2:
> DuetPkg/SataControllerDxe/SataController.c
> OvmfPkg/SataControllerDxe/SataController.c
> But in all of them SATA connectivity is via PCI Express switch.
> 
> Kindly point me to some non-PCI based "SATA 3.0 AHCI driver code"
> for UEFI, if there is any such code.

I have seen several such platforms implementing a "dummy" PCI Express
driver, simply translating PCI accesses to memory mapped ones, and
still making use of the MdeModulePkg/Bus/Ata/ libraries.

You can see examples of PCI emulation in
Omap35xxPkg/PciEmulation/PciEmulation.c
and
ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c

As a side note, we really should have a common mmio-PCI emulation
library in core EDK2.

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

Re: [edk2] MdePkg/SmmMemLib: Insufficient abstraction for CPU physical address size

[Cohen, Eugene]

Mike,

Thanks - I agree that HOBs are part of the PI specification although it's clear 
in the specs that the intent is passing data from PEI to DXE (case in point: 
the string 'HOB' appears in the DXE volume 200 times and in the SMM volume zero 
times other than the revision history table).  It's even more strange to see a 
library called DxeHobLib be used in the build description files for SMM phase 
components.  I don't have a problem with the use of HOBs in SMM it was just a 
surprise that it's required for SMM to work when using this library.  It sounds 
like some PI SMM spec verbiage about HOBs being exposed to SMM is required.

For the CPU physical address bits base library abstraction it would be great if 
I could work with someone on the Intel side on the abstraction since I don't 
have a good setup to verify it.  Would this be a good item for me to tee up on 
the issue tracker?

Thanks,

Eugene

> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, February 03, 2016 11:54 AM
> To: Cohen, Eugene ; edk2-devel@lists.01.org; Fan,
> Jeff ; Kinney, Michael D
> 
> Subject: RE: MdePkg/SmmMemLib: Insufficient abstraction for CPU
> physical address size
> 
> Eugene,
> 
> HOBs and SMM are both part of the PI Specifications.  From an
> implementation perspective, HOBs used in entry points of SMM core
> and SMM drivers can provide important platform/CPU state
> information.  So I think use of HOBs from SMM modules is allowed.
> 
> You do bring up some good points, and I do agree that it is possible to
> define library abstractions that can be used to increase compatibility of
> EDK II modules.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of Cohen, Eugene
> > Sent: Wednesday, February 3, 2016 8:23 AM
> > To: edk2-devel@lists.01.org; Kinney, Michael D
> ; Fan, Jeff
> > 
> > Subject: [edk2] MdePkg/SmmMemLib: Insufficient abstraction for
> CPU physical address
> > size
> >
> > In SmmMemLib there's a routine to determine the maximum
> physical address supported by a
> > processor:
> >
> >
> >   //
> >   // Get physical address bits supported.
> >   //
> >   Hob = GetFirstHob (EFI_HOB_TYPE_CPU);
> >   if (Hob != NULL) {
> > PhysicalAddressBits = ((EFI_HOB_CPU *) Hob)-
> >SizeOfMemorySpace;
> >   } else {
> > AsmCpuid (0x8000, , NULL, NULL, NULL);
> > if (RegEax >= 0x8008) {
> >   AsmCpuid (0x8008, , NULL, NULL, NULL);
> >   PhysicalAddressBits = (UINT8) RegEax;
> > } else {
> >   PhysicalAddressBits = 36;
> > }
> > >   }
> >
> >
> >
> > This is problematic in a couple ways:
> >
> >
> >
> > 1. AsmCpuid is not portable across architectures (understandably we
> would have said
> > that SMM is an IA thing originally)
> >
> > 2. The PI spec for SMM does not specify the use of HOBs (in fact I
> was very surprised
> > to even see HOBs in SMM, and even more confounded by platforms
> using the "DxeHobLib" in
> > the SMM core and drivers!)
> >
> >
> >
> > I think this would be a good job for a base library interface to handle -
> (e.g. UINTN
> > GetCpuPhysicalAddressBits().  You could then have a version that
> uses HOBs (MdePkg),
> > another IA specific one (UefiCpuPackage) that uses CPU ID, and one
> that works for ARM
> > (ArmPkg)  that reads ID registers.
> >
> >
> >
> > Does that sound reasonable?
> >
> >
> >
> > [Presumably this is just the beginning - we see AsmCpuId show up in
> a lot of modules
> > that need to be architecture-agnostic like BootScript (1G page
> support), CapsulePei (1G
> > page support), and AcpiS3SaveDxe (1G pages and physical address
> size).]
> >
> >
> >
> > Eugene
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] MdeModulePkg: Update DxeCore dispatcher to ignore PEI and SMM depex for FV.

[Liming Gao]

If FV image without DXE depex, it will be dispatched by DxeCore.
If FV image with SMM depex, it is the invalid image. ASSERT will be trig.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c | 31 ---
 1 file changed, 4 insertions(+), 27 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
index 0776cd6..69c3b11 100644
--- a/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
@@ -26,7 +26,7 @@
   Depex - Dependency Expresion.
   SOR   - Schedule On Request - Don't schedule if this bit is set.
 
-Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, 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
@@ -1249,29 +1249,6 @@ CoreFwVolEventProtocolNotify (
 }
 
 //
-// Check if this EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE file has 
PEI depex section.
-//
-DepexBuffer  = NULL;
-SizeOfBuffer = 0;
-Status = Fv->ReadSection (
-   Fv,
-   ,
-   EFI_SECTION_PEI_DEPEX,
-   0,
-   ,
-   ,
-   
-   );
-if (!EFI_ERROR (Status)) {
-  //
-  // If PEI depex section is found, this FV image will be ignored 
in DXE phase.
-  // Now, DxeCore doesn't support FV image with more one type 
DEPEX section.
-  //
-  FreePool (DepexBuffer);
-  continue;
-}
-
-//
 // Check if this EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE file has 
SMM depex section.
 //
 DepexBuffer  = NULL;
@@ -1287,11 +1264,11 @@ CoreFwVolEventProtocolNotify (
);
 if (!EFI_ERROR (Status)) {
   //
-  // If SMM depex section is found, this FV image will be ignored 
in DXE phase.
-  // Now, DxeCore doesn't support FV image with more one type 
DEPEX section.
+  // If SMM depex section is found, this FV image is invalid to be 
supported.
+  // ASSERT FALSE to report this FV image.  
   //
   FreePool (DepexBuffer);
-  continue;
+  ASSERT (FALSE);
 }
 
 //
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH] Reformatting xsd document with VS2013

[Jordan Justen]

On 2016-02-03 15:20:22, Hauch, Larry wrote:
> Hi Jordan,
> Git config global entry:
> commit.template=C:/Users/lhauch/msgtemplate.txt was not picked up by
> git send-email.
> 

You might try /c/Users ...

Another note, you should prefix the subject (1st line of commit
message) with BaseTools.

https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

For example:

BaseTools: Reformatting xsd document with VS2013

> Here is the content of that file:
> BaseTools-Conf: Re-formatting xsd file using VS2013
> 
> No functional changes - this just changes the XML format in the XSD file.
> 
> Cc: Zhu Yonghong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Larry Hauch 
> Reviewed-by: Reviewer Name 
> 

Is this Reviewed-by in your template? You shouldn't include that when
sending out the patch. When someone replies, they'll include the full
Reviewed-by which you can then copy into the commit message when
amending it.

-Jordan

> ANYHOW, here's the required content:
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Larry Hauch 
> Reviewed-by: Reviewer Name 
> 
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Wednesday, February 03, 2016 3:12 PM
> > To: Hauch, Larry; edk2-devel@lists.01.org
> > Subject: Re: [edk2] [PATCH] Reformatting xsd document with VS2013
> > 
> > Missing Contributed-under/Signed-off-by. (See
> > BaseTools/Contributions.txt)
> > 
> > On 2016-02-03 14:49:09, Larry Hauch wrote:
> > > ---
> > >  BaseTools/Conf/XMLSchema/DistributionPackage.xsd | 5735
> > --
> > >  1 file changed, 3080 insertions(+), 2655 deletions(-)
> > >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] EDK II subversion branches archived

[Jordan Justen]

I moved all the 'svn/*' branches to a separate repo:

https://github.com/tianocore/edk2-archive

In the main EDK II git repo, these branches have been removed.

To 'clean up' these branches from your local repo use the '--prune'
parameter when fetching from the github upstream repo:

$ git fetch origin --prune

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

Re: [edk2] Transition to GitHub is complete

[El-Haj-Mahmoud, Samer]

Excellent and thanks to everyone who made this happen!

>From the wiki, it looks like all tasks were completed except these two:

Post transition follow on tasks:

#  Automated mirroring of git repo to git mirrors
#  Automated mirroring of git repo (master, UDK branches) back to deprecated 
svn repo

When do we expect the automated mirroring of git to legacy SF SVN repo to get 
started?



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Tuesday, February 2, 2016 5:41 PM
To: edk2-devel@lists.01.org
Cc: Jarlstrom, Laurie ; Laszlo Ersek 

Subject: [edk2] Transition to GitHub is complete

On 2016-02-02 09:47:23, Jordan Justen wrote:
> As mentioned previously, we will attempt to transition to GitHub 
> starting this morning (around 10AM PST, UTC-8). One of the first steps 
> will be to disable SourceForge SVN write access.
> 
> You can follow the progress here:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Transition-to-Gi
> tHub
> 

Ok, all the major transition tasks have been completed now.

Laszlo took the honor of pushing the first commit directly to the GitHub repo, 
so it appears that the package maintainers should have push access now. (Thanks 
Laszlo!)

And, for months, quite a few people at Intel have been working behind the 
scenes to get everything ready for the transition. Thanks!

Now, good luck to us on a (hopefully smooth) transition to using git directly 
for day-to-day development work!

Merry EDK II Git Day!

-Jordan

> Or, on IRC (#edk2 on http://www.oftc.net/)
> 
> On 2016-01-29 16:16:59, Jarlstrom, Laurie wrote:
> > To: EDK II Community
> > 
> > The transition to GitHub will start February 2nd at around 10AM PST 
> > (UTC-8). We estimate it to be completed by February 4th at 5PM PST.
> > During this time a number of changes will be happening including the 
> > disabling of write access to the EDK II repository on SourceForge.
> > The time that write access is disabled will be reduced as much as 
> > possible. A notification will be sent out prior to disabling write 
> > access on SourceForge as well as a mail when write access is enabled 
> > on GitHub.
> > 
> > For status on the transition to GitHub see the Wiki page below.
> > https://github.com/tianocore/tianocore.github.io/wiki/Transition-to-
> > GitHub
> > 
> > Please post any comments or questions related to this transition to 
> > the edk2-devel mailing list or reply to the email message.
> > 
> > Thanks, Tianocore.org Administration 
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/2] MdeModulePkg: Add RamDiskDxe driver implementation

[Hao Wu]

The RamDiskDxe driver will:
1. Produce the EFI RAM Disk Protocol
2. Install RAM disk device path and block I/O related protocols on the
   RAM disk device handle.
3. Install RAM disk configuration form to HII database

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Include/Guid/RamDiskHii.h |  25 +
 MdeModulePkg/MdeModulePkg.dec  |   3 +
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 .../Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 258 +++
 .../Universal/Disk/RamDiskDxe/RamDiskDriver.c  | 169 +
 .../Universal/Disk/RamDiskDxe/RamDiskDxe.inf   |  78 ++
 .../Universal/Disk/RamDiskDxe/RamDiskDxe.uni   |  20 +
 .../Disk/RamDiskDxe/RamDiskFileExplorer.c  | 253 +++
 .../Universal/Disk/RamDiskDxe/RamDiskHii.vfr   |  93 +++
 .../Disk/RamDiskDxe/RamDiskHiiStrings.uni  |  42 ++
 .../Universal/Disk/RamDiskDxe/RamDiskImpl.c| 801 +
 .../Universal/Disk/RamDiskDxe/RamDiskImpl.h| 499 +
 .../Universal/Disk/RamDiskDxe/RamDiskNVData.h  |  43 ++
 .../Universal/Disk/RamDiskDxe/RamDiskProtocol.c| 348 +
 14 files changed, 2633 insertions(+)
 create mode 100644 MdeModulePkg/Include/Guid/RamDiskHii.h
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.uni
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskFileExplorer.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskNVData.h
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c

diff --git a/MdeModulePkg/Include/Guid/RamDiskHii.h 
b/MdeModulePkg/Include/Guid/RamDiskHii.h
new file mode 100644
index 000..0457ee2
--- /dev/null
+++ b/MdeModulePkg/Include/Guid/RamDiskHii.h
@@ -0,0 +1,25 @@
+/** @file
+  GUIDs used as HII FormSet and HII Package list GUID in RamDiskDxe driver.
+
+  Copyright (c) 2016, 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
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __RAM_DISK_HII_GUID_H__
+#define __RAM_DISK_HII_GUID_H__
+
+#define RAM_DISK_FORM_SET_GUID \
+  { \
+0x2a46715f, 0x3581, 0x4a55, {0x8e, 0x73, 0x2b, 0x76, 0x9a, 0xaa, 0x30, 
0xc5} \
+  }
+
+extern EFI_GUID gRamDiskFormSetGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 5c5a9ee..fa40ee3 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -342,6 +342,9 @@
 
   gEfiIfrFrontPageGuid= { 0xe58809f8, 0xfbc1, 0x48e2, { 0x88, 0x3a, 
0xa3, 0x0f, 0xdc, 0x4b, 0x44, 0x1e } }
 
+  ## Include/Guid/RamDiskHii.h
+  gRamDiskFormSetGuid= { 0x2a46715f, 0x3581, 0x4a55, { 0x8e, 0x73, 
0x2b, 0x76, 0x9a, 0xaa, 0x30, 0xc5 }}
+
 
 [Ppis]
   ## Include/Ppi/AtaController.h
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index ad2b913..0b54030 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -322,6 +322,7 @@
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Universal/Disk/CdExpressPei/CdExpressPei.inf
+  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
   MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   
MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/GenericMemoryTestDxe.inf
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
new file mode 100644
index 000..1687da3
--- /dev/null
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
@@ -0,0 +1,258 @@
+/** @file
+  Produce EFI_BLOCK_IO_PROTOCOL on a RAM disk device.
+
+  Copyright (c) 2016, 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
+  

[edk2] [PATCH 0/2] RAM disk driver implementation

[Hao Wu]

This patch series:
1. Add EFI RAM Disk Protocol definitions in MdePkg
(The patch does not modify comments in MdePkg.dec to reflect the current
version of UEFI spec, this change will be added before code check in)

2. Add RamDiskDxe driver implementation in MdeModulePkg

The patch series is also available at the following URL:
https://github.com/hwu25/edk2/tree/ramdisk

Hao Wu (2):
  MdePkg: Add EFI RAM Disk Protocol definitions
  MdeModulePkg: Add RamDiskDxe driver implementation

 MdeModulePkg/Include/Guid/RamDiskHii.h |  25 +
 MdeModulePkg/MdeModulePkg.dec  |   3 +
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 .../Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 258 +++
 .../Universal/Disk/RamDiskDxe/RamDiskDriver.c  | 169 +
 .../Universal/Disk/RamDiskDxe/RamDiskDxe.inf   |  78 ++
 .../Universal/Disk/RamDiskDxe/RamDiskDxe.uni   |  20 +
 .../Disk/RamDiskDxe/RamDiskFileExplorer.c  | 253 +++
 .../Universal/Disk/RamDiskDxe/RamDiskHii.vfr   |  93 +++
 .../Disk/RamDiskDxe/RamDiskHiiStrings.uni  |  42 ++
 .../Universal/Disk/RamDiskDxe/RamDiskImpl.c| 801 +
 .../Universal/Disk/RamDiskDxe/RamDiskImpl.h| 499 +
 .../Universal/Disk/RamDiskDxe/RamDiskNVData.h  |  43 ++
 .../Universal/Disk/RamDiskDxe/RamDiskProtocol.c| 348 +
 MdePkg/Include/Protocol/RamDisk.h  | 106 +++
 MdePkg/MdePkg.dec  |   3 +
 16 files changed, 2742 insertions(+)
 create mode 100644 MdeModulePkg/Include/Guid/RamDiskHii.h
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.uni
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskFileExplorer.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskNVData.h
 create mode 100644 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
 create mode 100644 MdePkg/Include/Protocol/RamDisk.h

-- 
1.9.5.msysgit.0

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

Re: [edk2] [Patch V4 4/4] MdeModulePkg: Add generic PciHostBridgeDxe driver.

[Ni, Ruiyu]

Laszlo, Marcel,
Thanks for the explanation. I need to think for a while and will get back to 
you in second half of February after the Chinese New Year vocation.


Regards,
Ray


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, February 2, 2016 7:08 PM
To: mar...@redhat.com
Cc: Ni, Ruiyu ; Justen, Jordan L 
; edk2-de...@ml01.01.org; Tian, Feng 
; Fan, Jeff 
Subject: Re: [edk2] [Patch V4 4/4] MdeModulePkg: Add generic PciHostBridgeDxe 
driver.

On 02/01/16 16:07, Marcel Apfelbaum wrote:
> On 01/26/2016 07:17 AM, Ni, Ruiyu wrote:
>> Laszlo,
>> I now understand your problem.
>> Can you tell me why OVMF needs multiple root bridges support?
>> My understanding to OVMF is it's a firmware which can be used in a
>> guest VM
>> environment to boot OS.
>> Multiple root bridges requirement currently mainly comes from high-end
>> servers.
>> Do you mean that the VM guest needs to be like a high-end server?
>> This may help me to think about the possible solution to your problem.
> 
> Hi Ray,
> 
> Laszlo's explanation is very good, this is not exactly about high-end VMs,
> we need the extra root bridges to match assigned devices to their
> corresponding NUMA node.
> 
> Regarding the OVMF issue, the main problem is that the extra root
> bridges are created dynamically
> for the VMs (command line parameter) and their resources are computed on
> the fly.
> 
> Not directly related to the above, the optimal way to allocate resources
> for PCI root bridges
> sharing the same PCI domain is to sort devices MEM/IO ranges from the
> biggest to smallest
> and use this order during allocation.
> 
> After the resources allocation is finished we can build the CRS for each
> PCI root bridge
> and pass it back to firmware/OS.
> 
> While for "real" machines we can hard-code the root bridge resources in
> some ROM and have it
> extracted early in the boot process, for the VM world this would not be
> possible. Also
> any effort to divide the resources range before the resource allocation
> would be odd and far from optimal.
> 
> Regarding a possible solution, I first need to understand why the
> resource allocation is done
> per PCI root bridge and not per PCI domain. The CRS allows a PCI root
> bridge to have several MEM/IO ranges
> so there is really no need to impose a per PCI root bridge logic.
> 
> I am new to the edk2 project so I might get things wrong, but I think we
> need a way to specify if
> the PCI root bridges will supply their resources or if an external
> allocator will do the job.
> Laszlo proposed solution looks like a way to implement such a policy, I
> am personally OK with it.
> 
> I really think the generic PciHostBridgeDxe driver is the right way to
> go also for OVMF, we just need
> a way to deal with this issue.

For the sake of discussion, I pushed my WIP patches to:

https://github.com/lersek/edk2/commits/pci_host_wip

It is a faithful conversion of OvmfPkg/PciHostBridgeDxe/, to
MdeModulePkg's PciHostBridgeDxe, plus an OVMF-specific PciHostBridgeLib
instance.

The problem is of course patch

  MdeModulePkg: PciHostBridgeDxe: allow PciHostBridgeLib to prime the
  GCD map

which we've been discussing in this thread.

Thanks
Laszlo


>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, January 26, 2016 11:10 AM
>> To: Ni, Ruiyu 
>> Cc: edk2-de...@ml01.01.org; Tian, Feng ; Fan,
>> Jeff ; Justen, Jordan L
>> ; Marcel Apfelbaum 
>> Subject: Re: [edk2] [Patch V4 4/4] MdeModulePkg: Add generic
>> PciHostBridgeDxe driver.
>>
>> On 01/26/16 03:42, Ni, Ruiyu wrote:
>>> Laszlo,
>>> Thanks for the detailed explanation and I agrees with your idea that
>>> a generic
>>> driver should consider the case that part of the IO/MMIO resource may be
>>> already added by platform, no matter by PEI or by DXE.
>>>
>>> So I think we may not need the flag you proposed here. To achieve the
>>> maximum
>>> flexibility, we can use gDS.GetMemorySpaceMap/GetIoSpaceMap to
>>> retrieve all
>>> the current MMIO/IO space map and only add those ranges that are not
>>> added.
>>>
>>> And to be more robust, we can check that the range specified to the
>>> root bridge
>>> should not be allocated by anyone (CAN be added by someone).
>>>
>>> What's your opinion?
>>
>> Very good, but painful questions. :)
>>
>> Until now, OVMF has relied upon PlatformPei producing the HOBs in
>> question (where the base of the 32-bit PCI MMIO window varies in the
>> HOB, based on guest RAM size), *and* OVMF's PCI host bridge driver has
>> never even tried to match the root bridges' 32-bit MMIO apertures to
>> anything at all. All of those apertures are set as [2GB, 4GB).
>>
>> The idea being, the gDS->AllocateMemorySpace() calls can be satisfied
>> from whatever room is left from the range that 

[edk2] [PATCH 1/2] MdePkg: Add EFI RAM Disk Protocol definitions

[Hao Wu]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdePkg/Include/Protocol/RamDisk.h | 106 ++
 MdePkg/MdePkg.dec |   3 ++
 2 files changed, 109 insertions(+)
 create mode 100644 MdePkg/Include/Protocol/RamDisk.h

diff --git a/MdePkg/Include/Protocol/RamDisk.h 
b/MdePkg/Include/Protocol/RamDisk.h
new file mode 100644
index 000..5df8213
--- /dev/null
+++ b/MdePkg/Include/Protocol/RamDisk.h
@@ -0,0 +1,106 @@
+/** @file
+  This file defines the EFI RAM Disk Protocol.
+
+  Copyright (c) 2016, 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
+  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.
+
+  @par Revision Reference:
+  This Protocol is introduced in UEFI Specification 2.6
+
+**/
+
+#ifndef __RAM_DISK_PROTOCOL_H__
+#define __RAM_DISK_PROTOCOL_H__
+
+//
+// EFI RAM Disk Protocol GUID value
+//
+#define EFI_RAM_DISK_PROTOCOL_GUID \
+  { 0xab38a0df, 0x6873, 0x44a9, { 0x87, 0xe6, 0xd4, 0xeb, 0x56, 0x14, 0x84, 
0x49 }};
+
+//
+// Forward reference for pure ANSI compatability
+//
+typedef struct _EFI_RAM_DISK_PROTOCOL  EFI_RAM_DISK_PROTOCOL;
+
+/**
+  Register a RAM disk with specified address, size and type.
+
+  @param[in]  RamDiskBaseThe base address of registered RAM disk.
+  @param[in]  RamDiskSizeThe size of registered RAM disk.
+  @param[in]  RamDiskTypeThe type of registered RAM disk. The GUID can be
+ any of the values defined in section 9.3.6.9, or a
+ vendor defined GUID.
+  @param[in]  ParentDevicePath
+ Pointer to the parent device path. If there is no
+ parent device path then ParentDevicePath is NULL.
+  @param[out] DevicePath On return, points to a pointer to the device path
+ of the RAM disk device.
+ If ParentDevicePath is not NULL, the returned
+ DevicePath is created by appending a RAM disk node
+ to the parent device path. If ParentDevicePath is
+ NULL, the returned DevicePath is a RAM disk device
+ path without appending. This function is
+ responsible for allocating the buffer DevicePath
+ with the boot service AllocatePool().
+
+  @retval EFI_SUCCESS The RAM disk is registered successfully.
+  @retval EFI_INVALID_PARAMETER   DevicePath or RamDiskType is NULL.
+  RamDiskSize is 0.
+  @retval EFI_ALREADY_STARTED A Device Path Protocol instance to be created
+  is already present in the handle database.
+  @retval EFI_OUT_OF_RESOURCESThe RAM disk register operation fails due to
+  resource limitation.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_RAM_DISK_REGISTER_RAMDISK) (
+  IN UINT64   RamDiskBase,
+  IN UINT64   RamDiskSize,
+  IN EFI_GUID *RamDiskType,
+  IN EFI_DEVICE_PATH  *ParentDevicePath OPTIONAL,
+  OUT EFI_DEVICE_PATH_PROTOCOL**DevicePath
+  );
+
+/**
+  Unregister a RAM disk specified by DevicePath.
+
+  @param[in] DevicePath  A pointer to the device path that describes a RAM
+ Disk device.
+
+  @retval EFI_SUCCESS The RAM disk is unregistered successfully.
+  @retval EFI_INVALID_PARAMETER   DevicePath is NULL.
+  @retval EFI_UNSUPPORTED The device specified by DevicePath is not a
+  valid ramdisk device path and not supported
+  by the driver.
+  @retval EFI_NOT_FOUND   The RAM disk pointed by DevicePath doesn't
+  exist.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_RAM_DISK_UNREGISTER_RAMDISK) (
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath
+  );
+
+///
+/// RAM Disk Protocol structure.
+///
+struct _EFI_RAM_DISK_PROTOCOL {
+  EFI_RAM_DISK_REGISTER_RAMDISKRegister;
+  EFI_RAM_DISK_UNREGISTER_RAMDISK  Unregister;
+};
+
+///
+/// RAM Disk Protocol GUID variable.
+///
+extern EFI_GUID gEfiRamDiskProtocolGuid;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 7ab0cbb..ebd5806 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -1587,6 +1587,9 @@
   ## Include/Protocol/Rest.h
   gEfiRestProtocolGuid =  { 0x0db48a36, 0x4e54, 0xea9c, {0x9b, 
0x09, 0x1e, 0xa5, 0xbe, 0x3a, 0x66, 0x0b 

[edk2] [PATCH] ArmPkg: Add isb when setting SCR.

[evan . lloyd]

From: Evan Lloyd 

Some updates to SCR can cause a problem which manifests as an undefined opcode 
exception.
This may be when a speculative secure instruction fetch happens after the NS 
bit is set.
An isb is required to make the register change take effect fully.

Contributed-under: Tianocore Contribution Agreement 1.0
Signed-off-by: Evan Lloyd  arm.com>
Reviewed-by: Sami Mujawar  arm.com>
Reviewed-by: Ard Biesheuvel  linaro.org>
(See http://article.gmane.org/gmane.comp.bios.edk2.devel/1675
never appeared to get merged)

Code at: 
https://github.com/EvanLloyd/tianocore/commit/903827785a576fd346475c69c42e5d0aa0c6676c

diff --git a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S 
b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
index 28db98b..50faef4 100644
--- a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
+++ b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
@@ -184,6 +184,7 @@ ASM_PFX(ArmWriteCptr):
 
 ASM_PFX(ArmWriteScr):
   msr scr_el3, x0// Secure configuration register EL3
+  isb
   ret
 
 ASM_PFX(ArmWriteMVBar):
diff --git a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S 
b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S
index 59f9918..085f08b 100644
--- a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S
+++ b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S
@@ -147,6 +147,7 @@ ASM_PFX(ArmReadScr):
 
 ASM_PFX(ArmWriteScr):
   mcr p15, 0, r0, c1, c1, 0
+  isb
   bx  lr
 
 ASM_PFX(ArmReadHVBar):
diff --git a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm 
b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm
index bdd862a..228d7c8 100644
--- a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm
+++ b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm
@@ -121,6 +121,7 @@
 
  RVCT_ASM_EXPORT ArmWriteScr
   mcr p15, 0, r0, c1, c1, 0
+  isb
   bx  lr
 
  RVCT_ASM_EXPORT ArmReadHVBar
-- 
2.7.0

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

[edk2] MdePkg/SmmMemLib: Insufficient abstraction for CPU physical address size

[Cohen, Eugene]

In SmmMemLib there's a routine to determine the maximum physical address 
supported by a processor:


  //
  // Get physical address bits supported.
  //
  Hob = GetFirstHob (EFI_HOB_TYPE_CPU);
  if (Hob != NULL) {
PhysicalAddressBits = ((EFI_HOB_CPU *) Hob)->SizeOfMemorySpace;
  } else {
AsmCpuid (0x8000, , NULL, NULL, NULL);
if (RegEax >= 0x8008) {
  AsmCpuid (0x8008, , NULL, NULL, NULL);
  PhysicalAddressBits = (UINT8) RegEax;
} else {
  PhysicalAddressBits = 36;
}

  }



This is problematic in a couple ways:



1. AsmCpuid is not portable across architectures (understandably we would have 
said that SMM is an IA thing originally)

2. The PI spec for SMM does not specify the use of HOBs (in fact I was very 
surprised to even see HOBs in SMM, and even more confounded by platforms using 
the "DxeHobLib" in the SMM core and drivers!)



I think this would be a good job for a base library interface to handle - (e.g. 
UINTN GetCpuPhysicalAddressBits().  You could then have a version that uses 
HOBs (MdePkg), another IA specific one (UefiCpuPackage) that uses CPU ID, and 
one that works for ARM (ArmPkg)  that reads ID registers.



Does that sound reasonable?



[Presumably this is just the beginning - we see AsmCpuId show up in a lot of 
modules that need to be architecture-agnostic like BootScript (1G page 
support), CapsulePei (1G page support), and AcpiS3SaveDxe (1G pages and 
physical address size).]



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

[edk2] [PATCH v2 0/6] ArmPlatformPkg: remove unused code

[Ryan Harkin]

This is an update to my original series titled:

[PATCH 0/2] ArmPlatformPkg: Remove FVP and Juno

ARM Ltd Platform support is migrating to use OpenPlatformPkg [1].

Currently, TC2, Juno and FVP exist both in EDK2's ArmPlatformPkg and in
OpenPlatformPkg.  And they are starting to diverge, with
OpenPlatformPkg being the most up-to-date with current developments.
To prevent this divergence, remove the .dsc and .fdf files from
ArmPlatformPkg and leave OpenPlatformPkg as the master.

32-bit models are no longer tested or supported, so this series also
removes the .dsc/fdf files for them.

And the Sec library has no clients either, so that can also be removed
as it hasn't been tested for a long time.

We can't remove ArmJuno.dec yet because ACPI still uses it to set the
include path to ArmPlatform.h.

[PATCH 1/6] ArmPlatformPkg: remove ArmVExpress-CTA15-A7.dsc/fdf
[PATCH 2/6] ArmPlatformPkg: remove ArmVExpress-FVP-AArch64.dsc/fdf
[PATCH 3/6] ArmPlatformPkg: remove ArmJuno.dsc/fdf
[PATCH 4/6] ArmPlatformPkg: remove ArmVExpress-RTSM-A15_MPCore.dsc/fdf
[PATCH 5/6] ArmPlatformPkg: remove unused Sec library
[PATCH 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF

[1] https://git.linaro.org/uefi/OpenPlatformPkg.git
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 1/6] ArmPlatformPkg: remove ArmVExpress-CTA15-A7.dsc/fdf

[Ryan Harkin]

ARM Ltd Platform support is migrating to use OpenPlatformPkg [1].

Currently, Juno exists both in EDK2's ArmPlatformPkg and in
OpenPlatformPkg [2].  And they are starting to diverge, with
OpenPlatformPkg being the most up-to-date with current developments.
To prevent this divergence, remove the .dsc and .fdf files from
ArmPlatformPkg and leave OpenPlatformPkg as the master.

We can't remove ArmJuno.dec yet because ACPI still uses it to set the
include path to ArmPlatform.h.

[1] https://git.linaro.org/uefi/OpenPlatformPkg.git
[2] 
https://git.linaro.org/uefi/OpenPlatformPkg.git/tree/master:/Platforms/ARM/Juno

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin 
---
 .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 285 --
 .../ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf| 323 -
 2 files changed, 608 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
deleted file mode 100644
index a711f56..000
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ /dev/null
@@ -1,285 +0,0 @@
-#
-#  Copyright (c) 2012-2015, ARM Limited. All rights reserved.
-#  Copyright (c) 2015, Intel Corporation. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#
-
-
-#
-# Defines Section - statements that will be processed to create a Makefile.
-#
-
-[Defines]
-  PLATFORM_NAME  = ArmVExpressPkg-CTA15-A7
-  PLATFORM_GUID  = 0b511920-978d-4b34-acc0-3d9f8e6f9d81
-  PLATFORM_VERSION   = 0.1
-  DSC_SPECIFICATION  = 0x00010005
-  OUTPUT_DIRECTORY   = Build/ArmVExpress-CTA15-A7
-  SUPPORTED_ARCHITECTURES= ARM
-  BUILD_TARGETS  = DEBUG|RELEASE
-  SKUID_IDENTIFIER   = DEFAULT
-  FLASH_DEFINITION   = 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf
-
-  DEFINE EDK2_SKIP_PEICORE = 1
-  DEFINE ARM_BIGLITTLE_TC2 = 1 # We build for the TC2 hardware by default
-
-!include ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
-
-[LibraryClasses.common]
-  ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
-  
ArmPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA15-A7/ArmVExpressLib.inf
-
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-
-  
#DebugAgentTimerLib|ArmPlatformPkg/ArmVExpressPkg/Library/DebugAgentTimerLib/DebugAgentTimerLib.inf
-
-  # ARM General Interrupt Driver in Secure and Non-secure
-  ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
-
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
-
-  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
-  ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
-
-[BuildOptions]
-!ifdef ARM_BIGLITTLE_TC2
-  *_*_ARM_ARCHCC_FLAGS  = -DARM_BIGLITTLE_TC2=1
-  *_*_ARM_PP_FLAGS  = -DARM_BIGLITTLE_TC2=1
-!endif
-
-  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/CTA15-A7
-
-  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/CTA15-A7
-
-  XCODE:*_*_ARM_PLATFORM_FLAGS = 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/CTA15-A7
-
-
-#
-# Pcd Section - list of all EDK II PCD Entries defined by this Platform
-#
-
-
-[PcdsFeatureFlag.common]
-  gArmPlatformTokenSpaceGuid.PcdSystemMemoryInitializeInSec|TRUE
-  gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores|TRUE
-
-  ## If TRUE, Graphics Output Protocol will be installed on virtual handle 
created by ConsplitterDxe.
-  #  It could be set FALSE to save size.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
-
-[PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Versatile Express"
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"ArmVExpress-CTA15-A7"
-

[edk2] [PATCH v2 4/6] ArmPlatformPkg: remove ArmVExpress-RTSM-A15_MPCore.dsc/fdf

[Ryan Harkin]

This platform is untested and no longer supported, so remove it from the
tree.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin 
---
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 297 -
 .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 365 -
 2 files changed, 662 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
deleted file mode 100644
index 91852a4..000
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
+++ /dev/null
@@ -1,297 +0,0 @@
-#
-#  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
-#  Copyright (c) 2015, Intel Corporation. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#
-
-
-#
-# Defines Section - statements that will be processed to create a Makefile.
-#
-
-[Defines]
-  PLATFORM_NAME  = ArmVExpressPkg-RTSM-A15_MPCore
-  PLATFORM_GUID  = 3a91a0f8-3af4-409d-a71d-a199dc134357
-  PLATFORM_VERSION   = 0.1
-  DSC_SPECIFICATION  = 0x00010005
-  OUTPUT_DIRECTORY   = Build/ArmVExpress-RTSM-A15_MPCore
-  SUPPORTED_ARCHITECTURES= ARM
-  BUILD_TARGETS  = DEBUG|RELEASE
-  SKUID_IDENTIFIER   = DEFAULT
-  FLASH_DEFINITION   = 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf
-
-!include ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
-
-[LibraryClasses.common]
-  ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
-  ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
-  
ArmPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
-
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-
-  
#DebugAgentTimerLib|ArmPlatformPkg/ArmVExpressPkg/Library/DebugAgentTimerLib/DebugAgentTimerLib.inf
-
-  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
-
-  # Virtio Support
-  VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
-  
VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
-
-[LibraryClasses.common.SEC]
-  ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
-  
ArmPlatformSecLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/ArmVExpressSecLib.inf
-  
ArmPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLibSec.inf
-
-[LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, 
LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
-  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-
-[BuildOptions]
-  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM
-
-  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM
-
-  XCODE:*_*_ARM_PLATFORM_FLAGS = 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM
-
-
-#
-# Pcd Section - list of all EDK II PCD Entries defined by this Platform
-#
-
-
-[PcdsFeatureFlag.common]
-!ifdef EDK2_SKIP_PEICORE
-  gArmPlatformTokenSpaceGuid.PcdSystemMemoryInitializeInSec|TRUE
-  gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores|TRUE
-!endif
-
-  ## If TRUE, Graphics Output Protocol will be installed on virtual handle 
created by ConsplitterDxe.
-  #  It could be set FALSE to save size.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
-
-[PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Versatile Express"
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"ArmVExpress-RTSM"
-
-  gArmPlatformTokenSpaceGuid.PcdCoreCount|2
-
-  #
-  # NV Storage PCDs. Use base of 0x0C00 for NOR1
-  #
-!if $(EDK2_ARMVE_SUPPORT_QEMU) == 1
-  # 

[edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF / ArmPlatformLib template"

[Ryan Harkin]

This reverts commit 12fcdcb83d8e91cb730db9252189269467b9ed73

The files added by the commit have never been used.  In the intervening
years since they've been added, ~30 patches have been submitted to
update them.

Remove them as part of a general cleanup of ArmPlatformPkg.

Signed-off-by: Ryan Harkin 
---
 ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382 --
 ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 263 
 ArmPlatformPkg/ArmPlatformPkg.dsc  | 445 -
 ArmPlatformPkg/ArmPlatformPkg.fdf  | 320 ---
 .../ArmPlatformLibNull/ArmPlatformLibNull.c| 162 
 .../ArmPlatformLibNull/ArmPlatformLibNull.inf  |  51 ---
 .../ArmPlatformLibNull/ArmPlatformLibNullMem.c |  34 --
 .../ArmPlatformLibNull/ArmPlatformLibNullSec.inf   |  47 ---
 8 files changed, 1704 deletions(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc 
b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
deleted file mode 100644
index 45d7427..000
--- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
+++ /dev/null
@@ -1,382 +0,0 @@
-#
-#  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#
-
-#
-# Defines Section - statements that will be processed to create a Makefile.
-#
-
-[Defines]
-  PLATFORM_NAME  = ArmPlatform
-  PLATFORM_GUID  = 4fe82b83-9315-4ff3-8cc0-ab77ca93cb7f
-  PLATFORM_VERSION   = 0.1
-  DSC_SPECIFICATION  = 0x00010005
-  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
-  SUPPORTED_ARCHITECTURES= ARM|AARCH64
-  BUILD_TARGETS  = DEBUG|RELEASE
-  SKUID_IDENTIFIER   = DEFAULT
-  FLASH_DEFINITION   = ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf
-
-[LibraryClasses.common]
-  
ArmPlatformLib|ArmPlatformPkg/Library/ArmPlatformLibNull/ArmPlatformLibNull.inf
-
-!if $(TARGET) == RELEASE
-  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-  
UncachedMemoryAllocationLib|ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
-!else
-  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
-  
UncachedMemoryAllocationLib|ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
-#  
UncachedMemoryAllocationLib|ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
-!endif
-  
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
-
-  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
-  
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
-  
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
-  PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
-  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
-  
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
-  CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
-
-  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
-  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
-  
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
-  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
-  
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
-  
DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
-  
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
-  
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
-  HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
-  
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
-
-  UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
-
-  #
-  # Assume everything is fixed at build
-  #
-  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
-
-  # 1/123 faster than Stm or Vstm version
-  #BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
-  BaseMemoryLib|ArmPkg/Library/BaseMemoryLibStm/BaseMemoryLibStm.inf
-
-  # ARM Architectural Libraries
-  

[edk2] [PATCH v2 3/6] ArmPlatformPkg: remove ArmJuno.dsc/fdf

[Ryan Harkin]

ARM Ltd Platform support is migrating to use OpenPlatformPkg [1].

Currently, Juno exists both in EDK2's ArmPlatformPkg and in
OpenPlatformPkg [2].  And they are starting to diverge, with
OpenPlatformPkg being the most up-to-date with current developments.
To prevent this divergence, remove the .dsc and .fdf files from
ArmPlatformPkg and leave OpenPlatformPkg as the master.

We can't remove ArmJuno.dec yet because ACPI still uses it to set the
include path to ArmPlatform.h.

[1] https://git.linaro.org/uefi/OpenPlatformPkg.git
[2] 
https://git.linaro.org/uefi/OpenPlatformPkg.git/tree/master:/Platforms/ARM/Juno

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin 
---
 ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 291 ---
 ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 365 --
 2 files changed, 656 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc 
b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
deleted file mode 100644
index 638be2e..000
--- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
+++ /dev/null
@@ -1,291 +0,0 @@
-#
-#  Copyright (c) 2013-2015, ARM Limited. All rights reserved.
-#  Copyright (c) 2015, Intel Corporation. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-
-
-#
-# Defines Section - statements that will be processed to create a Makefile.
-#
-
-[Defines]
-  PLATFORM_NAME  = ArmJuno
-  PLATFORM_GUID  = ca0722fd-7d3d-45ea-948c-d62b2199807d
-  PLATFORM_VERSION   = 0.1
-  DSC_SPECIFICATION  = 0x00010005
-  OUTPUT_DIRECTORY   = Build/ArmJuno
-  SUPPORTED_ARCHITECTURES= AARCH64|ARM
-  BUILD_TARGETS  = DEBUG|RELEASE
-  SKUID_IDENTIFIER   = DEFAULT
-  FLASH_DEFINITION   = ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf
-
-# On RTSM, most peripherals are VExpress Motherboard peripherals
-!include ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
-
-[LibraryClasses.common]
-  ArmPlatformLib|ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
-  ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
-
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf
-  
EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
-
-  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
-
-  # USB Requirements
-  UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
-
-[LibraryClasses.ARM]
-  ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
-
-[LibraryClasses.AARCH64]
-  ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
-
-[LibraryClasses.common.SEC]
-  PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
-  
ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
-  
LzmaDecompressLib|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
-  
MemoryAllocationLib|EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf
-  HobLib|EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
-  
PrePiHobListPointerLib|ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
-  PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
-  PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf
-
-[LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
-  MemoryInitPeiLib|ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
-
-[LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, 
LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
-  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-
-[BuildOptions]
-  *_*_*_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmJunoPkg/Include
-
-
-#
-# Pcd Section - list of all EDK II PCD Entries defined by this Platform
-#
-
-
-[PcdsFeatureFlag.common]
-  gArmPlatformTokenSpaceGuid.PcdSystemMemoryInitializeInSec|TRUE
-
-  ## If TRUE, Graphics Output Protocol will be installed on virtual handle 
created by ConsplitterDxe.
-  #  It could be set FALSE to save size.
-  

Re: [edk2] [Patch] MdeModulePkg: Update DxeCore dispatcher to ignore PEI and SMM depex for FV.

[Andrew Fish]

Reviewed-by: Andrew Fish 

> On Feb 3, 2016, at 6:01 AM, Liming Gao  wrote:
> 
> If FV image without DXE depex, it will be dispatched by DxeCore.
> If FV image with SMM depex, it is the invalid image. ASSERT will be trig.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
> MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c | 31 ---
> 1 file changed, 4 insertions(+), 27 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c 
> b/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
> index 0776cd6..69c3b11 100644
> --- a/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
> +++ b/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
> @@ -26,7 +26,7 @@
>   Depex - Dependency Expresion.
>   SOR   - Schedule On Request - Don't schedule if this bit is set.
> 
> -Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2016, 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
> @@ -1249,29 +1249,6 @@ CoreFwVolEventProtocolNotify (
> }
> 
> //
> -// Check if this EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE file has 
> PEI depex section.
> -//
> -DepexBuffer  = NULL;
> -SizeOfBuffer = 0;
> -Status = Fv->ReadSection (
> -   Fv,
> -   ,
> -   EFI_SECTION_PEI_DEPEX,
> -   0,
> -   ,
> -   ,
> -   
> -   );
> -if (!EFI_ERROR (Status)) {
> -  //
> -  // If PEI depex section is found, this FV image will be 
> ignored in DXE phase.
> -  // Now, DxeCore doesn't support FV image with more one type 
> DEPEX section.
> -  //
> -  FreePool (DepexBuffer);
> -  continue;
> -}
> -
> -//
> // Check if this EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE file has 
> SMM depex section.
> //
> DepexBuffer  = NULL;
> @@ -1287,11 +1264,11 @@ CoreFwVolEventProtocolNotify (
>);
> if (!EFI_ERROR (Status)) {
>   //
> -  // If SMM depex section is found, this FV image will be 
> ignored in DXE phase.
> -  // Now, DxeCore doesn't support FV image with more one type 
> DEPEX section.
> +  // If SMM depex section is found, this FV image is invalid to 
> be supported.
> +  // ASSERT FALSE to report this FV image.  
>   //
>   FreePool (DepexBuffer);
> -  continue;
> +  ASSERT (FALSE);
> }
> 
> //
> -- 
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF / ArmPlatformLib template"

[Carsey, Jaben]

> -Original Message-
> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> Sent: Wednesday, February 03, 2016 9:25 AM
> To: Carsey, Jaben 
> Cc: edk2-de...@ml01.01.org; linaro-u...@lists.linaro.org; Leif Lindholm
> ; Justen, Jordan L ; Ard
> Biesheuvel 
> Subject: Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM
> Platform DSC / FDF / ArmPlatformLib template"
> Importance: High
> 
> On 3 February 2016 at 17:20, Carsey, Jaben 
> wrote:
> > Change looks good.
> >
> > Question - Is there a way to optimize the patch/email for this type of 
> > change
> so that we do not see the "diff" for a file that is deleted?  It seems 
> redundant
> to show a whole file of "-" lines...
> >
> 
> That's a good question.  I remember Ard discussing this previously.
> I'll see if I can find the discussion...

Thanks!  That would be good.  

The worst example is the patch with a delete and then some code change 
(probably should be a series).

-Jaben

> 
> 
> > -Jaben
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Ryan Harkin
> >> Sent: Wednesday, February 03, 2016 9:10 AM
> >> To: edk2-de...@ml01.01.org; linaro-u...@lists.linaro.org; Leif Lindholm
> >> 
> >> Cc: Ryan Harkin ; Ard Biesheuvel
> >> 
> >> Subject: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM
> >> Platform DSC / FDF / ArmPlatformLib template"
> >> Importance: High
> >>
> >> This reverts commit 12fcdcb83d8e91cb730db9252189269467b9ed73
> >>
> >> The files added by the commit have never been used.  In the intervening
> >> years since they've been added, ~30 patches have been submitted to
> >> update them.
> >>
> >> Remove them as part of a general cleanup of ArmPlatformPkg.
> >>
> >> Signed-off-by: Ryan Harkin 
> >> ---
> >>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382 
> >> --
> >>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 263 
> >>  ArmPlatformPkg/ArmPlatformPkg.dsc  | 445 
> >> -
> >>  ArmPlatformPkg/ArmPlatformPkg.fdf  | 320 ---
> >>  .../ArmPlatformLibNull/ArmPlatformLibNull.c| 162 
> >>  .../ArmPlatformLibNull/ArmPlatformLibNull.inf  |  51 ---
> >>  .../ArmPlatformLibNull/ArmPlatformLibNullMem.c |  34 --
> >>  .../ArmPlatformLibNull/ArmPlatformLibNullSec.inf   |  47 ---
> >>  8 files changed, 1704 deletions(-)
> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF / ArmPlatformLib template"

[Leif Lindholm]

On Wed, Feb 03, 2016 at 05:29:58PM +, Carsey, Jaben wrote:
> > -Original Message-
> > From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> > Sent: Wednesday, February 03, 2016 9:25 AM
> > To: Carsey, Jaben 
> > Cc: edk2-de...@ml01.01.org; linaro-u...@lists.linaro.org; Leif Lindholm
> > ; Justen, Jordan L ; 
> > Ard
> > Biesheuvel 
> > Subject: Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM
> > Platform DSC / FDF / ArmPlatformLib template"
> > Importance: High
> > 
> > On 3 February 2016 at 17:20, Carsey, Jaben 
> > wrote:
> > > Change looks good.
> > >
> > > Question - Is there a way to optimize the patch/email for this type of 
> > > change
> > so that we do not see the "diff" for a file that is deleted?  It seems 
> > redundant
> > to show a whole file of "-" lines...
> > >
> > 
> > That's a good question.  I remember Ard discussing this previously.
> > I'll see if I can find the discussion...
> 
> Thanks!  That would be good.  
> 
> The worst example is the patch with a delete and then some code change 
> (probably should be a series).

You can tell this from the start of the diff for each file:

> --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
> +++ /dev/null ,

And also from the diffstat (if all '-' signs next to a file, nothing
was added, if anything was added, you'll see '+' also).

> > >>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382 
> > >> --
> > >>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 263 
> > >>  ArmPlatformPkg/ArmPlatformPkg.dsc  | 445 
> > >> -
> > >>  ArmPlatformPkg/ArmPlatformPkg.fdf  | 320 ---
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNull.c| 162 
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNull.inf  |  51 ---
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNullMem.c |  34 --
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNullSec.inf   |  47 ---

And, yes, it should :)

/
Leif

> > >> -Original Message-
> > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > >> Ryan Harkin
> > >> Sent: Wednesday, February 03, 2016 9:10 AM
> > >> To: edk2-de...@ml01.01.org; linaro-u...@lists.linaro.org; Leif Lindholm
> > >> 
> > >> Cc: Ryan Harkin ; Ard Biesheuvel
> > >> 
> > >> Subject: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM
> > >> Platform DSC / FDF / ArmPlatformLib template"
> > >> Importance: High
> > >>
> > >> This reverts commit 12fcdcb83d8e91cb730db9252189269467b9ed73
> > >>
> > >> The files added by the commit have never been used.  In the intervening
> > >> years since they've been added, ~30 patches have been submitted to
> > >> update them.
> > >>
> > >> Remove them as part of a general cleanup of ArmPlatformPkg.
> > >>
> > >> Signed-off-by: Ryan Harkin 
> > >> ---
> > >>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382 
> > >> --
> > >>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 263 
> > >>  ArmPlatformPkg/ArmPlatformPkg.dsc  | 445 
> > >> -
> > >>  ArmPlatformPkg/ArmPlatformPkg.fdf  | 320 ---
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNull.c| 162 
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNull.inf  |  51 ---
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNullMem.c |  34 --
> > >>  .../ArmPlatformLibNull/ArmPlatformLibNullSec.inf   |  47 ---
> > >>  8 files changed, 1704 deletions(-)
> > >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/6] ArmPlatformPkg: remove unused code

[Leif Lindholm]

Hi Ryan,

On Wed, Feb 03, 2016 at 05:09:28PM +, Ryan Harkin wrote:
> This is an update to my original series titled:
> 
> [PATCH 0/2] ArmPlatformPkg: Remove FVP and Juno
> 
> ARM Ltd Platform support is migrating to use OpenPlatformPkg [1].
> 
> Currently, TC2, Juno and FVP exist both in EDK2's ArmPlatformPkg and in
> OpenPlatformPkg.  And they are starting to diverge, with
> OpenPlatformPkg being the most up-to-date with current developments.
> To prevent this divergence, remove the .dsc and .fdf files from
> ArmPlatformPkg and leave OpenPlatformPkg as the master.
> 
> 32-bit models are no longer tested or supported, so this series also
> removes the .dsc/fdf files for them.
> 
> And the Sec library has no clients either, so that can also be removed
> as it hasn't been tested for a long time.
> 
> We can't remove ArmJuno.dec yet because ACPI still uses it to set the
> include path to ArmPlatform.h.
> 
> [PATCH 1/6] ArmPlatformPkg: remove ArmVExpress-CTA15-A7.dsc/fdf
> [PATCH 2/6] ArmPlatformPkg: remove ArmVExpress-FVP-AArch64.dsc/fdf
> [PATCH 3/6] ArmPlatformPkg: remove ArmJuno.dsc/fdf
> [PATCH 4/6] ArmPlatformPkg: remove ArmVExpress-RTSM-A15_MPCore.dsc/fdf
> [PATCH 5/6] ArmPlatformPkg: remove unused Sec library
> [PATCH 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF
> 
> [1] https://git.linaro.org/uefi/OpenPlatformPkg.git

I am entirely happy with 1-5.
I know Ard objected to (what is now) 2. This is something to be
discussed.

6/6 ... I think we can leave ArmPlatformLinBull in for now.
It is meant to be a template for use by new platform ports.
Ard: what's your take on dropping the generic .dsc files?

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

Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF / ArmPlatformLib template"

[Carsey, Jaben]

Change looks good.

Question - Is there a way to optimize the patch/email for this type of change 
so that we do not see the "diff" for a file that is deleted?  It seems 
redundant to show a whole file of "-" lines...

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ryan Harkin
> Sent: Wednesday, February 03, 2016 9:10 AM
> To: edk2-de...@ml01.01.org; linaro-u...@lists.linaro.org; Leif Lindholm
> 
> Cc: Ryan Harkin ; Ard Biesheuvel
> 
> Subject: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM
> Platform DSC / FDF / ArmPlatformLib template"
> Importance: High
> 
> This reverts commit 12fcdcb83d8e91cb730db9252189269467b9ed73
> 
> The files added by the commit have never been used.  In the intervening
> years since they've been added, ~30 patches have been submitted to
> update them.
> 
> Remove them as part of a general cleanup of ArmPlatformPkg.
> 
> Signed-off-by: Ryan Harkin 
> ---
>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382 --
>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 263 
>  ArmPlatformPkg/ArmPlatformPkg.dsc  | 445 
> -
>  ArmPlatformPkg/ArmPlatformPkg.fdf  | 320 ---
>  .../ArmPlatformLibNull/ArmPlatformLibNull.c| 162 
>  .../ArmPlatformLibNull/ArmPlatformLibNull.inf  |  51 ---
>  .../ArmPlatformLibNull/ArmPlatformLibNullMem.c |  34 --
>  .../ArmPlatformLibNull/ArmPlatformLibNullSec.inf   |  47 ---
>  8 files changed, 1704 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
> b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
> deleted file mode 100644
> index 45d7427..000
> --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
> +++ /dev/null
> @@ -1,382 +0,0 @@
> -#
> -#  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
> -#
> -#  This program and the accompanying materials
> -#  are licensed and made available under the terms and conditions of the BSD
> License
> -#  which accompanies this distribution.  The full text of the license may be
> found at
> -#  http://opensource.org/licenses/bsd-license.php
> -#
> -#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -#
> -#
> -
> 
> 
> -#
> -# Defines Section - statements that will be processed to create a Makefile.
> -#
> -
> 
> 
> -[Defines]
> -  PLATFORM_NAME  = ArmPlatform
> -  PLATFORM_GUID  = 4fe82b83-9315-4ff3-8cc0-ab77ca93cb7f
> -  PLATFORM_VERSION   = 0.1
> -  DSC_SPECIFICATION  = 0x00010005
> -  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
> -  SUPPORTED_ARCHITECTURES= ARM|AARCH64
> -  BUILD_TARGETS  = DEBUG|RELEASE
> -  SKUID_IDENTIFIER   = DEFAULT
> -  FLASH_DEFINITION   = ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf
> -
> -[LibraryClasses.common]
> -
> ArmPlatformLib|ArmPlatformPkg/Library/ArmPlatformLibNull/ArmPlatformLi
> bNull.inf
> -
> -!if $(TARGET) == RELEASE
> -  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> -
> UncachedMemoryAllocationLib|ArmPkg/Library/UncachedMemoryAllocation
> Lib/UncachedMemoryAllocationLib.inf
> -!else
> -
> DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.i
> nf
> -
> UncachedMemoryAllocationLib|ArmPkg/Library/UncachedMemoryAllocation
> Lib/UncachedMemoryAllocationLib.inf
> -#
> UncachedMemoryAllocationLib|ArmPkg/Library/DebugUncachedMemoryAll
> ocationLib/DebugUncachedMemoryAllocationLib.inf
> -!endif
> -
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/Base
> DebugPrintErrorLevelLib.inf
> -
> -  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
> -
> SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroniz
> ationLib.inf
> -
> PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformance
> LibNull.inf
> -  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> -
> PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePe
> CoffGetEntryPointLib.inf
> -  PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
> -  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> -
> UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDeco
> mpressLib.inf
> -  CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
> -
> -  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
> -  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> -
> UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/
> UefiRuntimeServicesTableLib.inf
> -  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
> -
> 

Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF / ArmPlatformLib template"

[Ryan Harkin]

On 3 February 2016 at 17:20, Carsey, Jaben  wrote:
> Change looks good.
>
> Question - Is there a way to optimize the patch/email for this type of change 
> so that we do not see the "diff" for a file that is deleted?  It seems 
> redundant to show a whole file of "-" lines...
>

That's a good question.  I remember Ard discussing this previously.
I'll see if I can find the discussion...


> -Jaben
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ryan Harkin
>> Sent: Wednesday, February 03, 2016 9:10 AM
>> To: edk2-de...@ml01.01.org; linaro-u...@lists.linaro.org; Leif Lindholm
>> 
>> Cc: Ryan Harkin ; Ard Biesheuvel
>> 
>> Subject: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM
>> Platform DSC / FDF / ArmPlatformLib template"
>> Importance: High
>>
>> This reverts commit 12fcdcb83d8e91cb730db9252189269467b9ed73
>>
>> The files added by the commit have never been used.  In the intervening
>> years since they've been added, ~30 patches have been submitted to
>> update them.
>>
>> Remove them as part of a general cleanup of ArmPlatformPkg.
>>
>> Signed-off-by: Ryan Harkin 
>> ---
>>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382 --
>>  ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 263 
>>  ArmPlatformPkg/ArmPlatformPkg.dsc  | 445 
>> -
>>  ArmPlatformPkg/ArmPlatformPkg.fdf  | 320 ---
>>  .../ArmPlatformLibNull/ArmPlatformLibNull.c| 162 
>>  .../ArmPlatformLibNull/ArmPlatformLibNull.inf  |  51 ---
>>  .../ArmPlatformLibNull/ArmPlatformLibNullMem.c |  34 --
>>  .../ArmPlatformLibNull/ArmPlatformLibNullSec.inf   |  47 ---
>>  8 files changed, 1704 deletions(-)
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg: Update DxeCore dispatcher to ignore PEI and SMM depex for FV.

[Kinney, Michael D]

Liming,

Thanks for doing this quick update!

Reviewed-by: Michael Kinney 

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
> Gao
> Sent: Wednesday, February 3, 2016 6:01 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] MdeModulePkg: Update DxeCore dispatcher to ignore PEI 
> and SMM
> depex for FV.
> 
> If FV image without DXE depex, it will be dispatched by DxeCore.
> If FV image with SMM depex, it is the invalid image. ASSERT will be trig.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c | 31 
> ---
>  1 file changed, 4 insertions(+), 27 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
> b/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
> index 0776cd6..69c3b11 100644
> --- a/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
> +++ b/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
> @@ -26,7 +26,7 @@
>Depex - Dependency Expresion.
>SOR   - Schedule On Request - Don't schedule if this bit is set.
> 
> -Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2016, 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
> @@ -1249,29 +1249,6 @@ CoreFwVolEventProtocolNotify (
>  }
> 
>  //
> -// Check if this EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE file has 
> PEI depex
> section.
> -//
> -DepexBuffer  = NULL;
> -SizeOfBuffer = 0;
> -Status = Fv->ReadSection (
> -   Fv,
> -   ,
> -   EFI_SECTION_PEI_DEPEX,
> -   0,
> -   ,
> -   ,
> -   
> -   );
> -if (!EFI_ERROR (Status)) {
> -  //
> -  // If PEI depex section is found, this FV image will be 
> ignored in DXE
> phase.
> -  // Now, DxeCore doesn't support FV image with more one type 
> DEPEX
> section.
> -  //
> -  FreePool (DepexBuffer);
> -  continue;
> -}
> -
> -//
>  // Check if this EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE file has 
> SMM depex
> section.
>  //
>  DepexBuffer  = NULL;
> @@ -1287,11 +1264,11 @@ CoreFwVolEventProtocolNotify (
> );
>  if (!EFI_ERROR (Status)) {
>//
> -  // If SMM depex section is found, this FV image will be 
> ignored in DXE
> phase.
> -  // Now, DxeCore doesn't support FV image with more one type 
> DEPEX
> section.
> +  // If SMM depex section is found, this FV image is invalid to 
> be
> supported.
> +  // ASSERT FALSE to report this FV image.
>//
>FreePool (DepexBuffer);
> -  continue;
> +  ASSERT (FALSE);
>  }
> 
>  //
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg: Add isb when setting SCR.

[Leif Lindholm]

Thanks Evan,

Pushed (with a few fixups) via the version in your repository.
Apologies for dropping the ball on this one.

On Wed, Feb 03, 2016 at 05:59:06PM +, evan.ll...@arm.com wrote:
> From: Evan Lloyd 
> 
> Some updates to SCR can cause a problem which manifests as an undefined 
> opcode exception.
> This may be when a speculative secure instruction fetch happens after the NS 
> bit is set.
> An isb is required to make the register change take effect fully.
> 
> Contributed-under: Tianocore Contribution Agreement 1.0
> Signed-off-by: Evan Lloyd  arm.com>
> Reviewed-by: Sami Mujawar  arm.com>
> Reviewed-by: Ard Biesheuvel  linaro.org>

Proper email addresses please.

> (See http://article.gmane.org/gmane.comp.bios.edk2.devel/1675
> never appeared to get merged)
>
> Code at: 
> https://github.com/EvanLloyd/tianocore/commit/903827785a576fd346475c69c42e5d0aa0c6676c

Free text goes after the --- line produced by git format-patch, but
missing from this email.

/
Leif

> diff --git a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S 
> b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
> index 28db98b..50faef4 100644
> --- a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
> +++ b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
> @@ -184,6 +184,7 @@ ASM_PFX(ArmWriteCptr):
>  
>  ASM_PFX(ArmWriteScr):
>msr scr_el3, x0// Secure configuration register EL3
> +  isb
>ret
>  
>  ASM_PFX(ArmWriteMVBar):
> diff --git a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S 
> b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S
> index 59f9918..085f08b 100644
> --- a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S
> +++ b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.S
> @@ -147,6 +147,7 @@ ASM_PFX(ArmReadScr):
>  
>  ASM_PFX(ArmWriteScr):
>mcr p15, 0, r0, c1, c1, 0
> +  isb
>bx  lr
>  
>  ASM_PFX(ArmReadHVBar):
> diff --git a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm 
> b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm
> index bdd862a..228d7c8 100644
> --- a/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm
> +++ b/ArmPkg/Library/ArmLib/Common/Arm/ArmLibSupport.asm
> @@ -121,6 +121,7 @@
>  
>   RVCT_ASM_EXPORT ArmWriteScr
>mcr p15, 0, r0, c1, c1, 0
> +  isb
>bx  lr
>  
>   RVCT_ASM_EXPORT ArmReadHVBar
> -- 
> 2.7.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] MdePkg/SmmMemLib: Insufficient abstraction for CPU physical address size

[Kinney, Michael D]

Eugene,

HOBs and SMM are both part of the PI Specifications.  From an implementation 
perspective, HOBs used in entry points of SMM core and SMM drivers can provide 
important platform/CPU state information.  So I think use of HOBs from SMM 
modules is allowed.

You do bring up some good points, and I do agree that it is possible to define 
library abstractions that can be used to increase compatibility of EDK II 
modules.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
> Eugene
> Sent: Wednesday, February 3, 2016 8:23 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D ; 
> Fan, Jeff
> 
> Subject: [edk2] MdePkg/SmmMemLib: Insufficient abstraction for CPU physical 
> address
> size
> 
> In SmmMemLib there's a routine to determine the maximum physical address 
> supported by a
> processor:
> 
> 
>   //
>   // Get physical address bits supported.
>   //
>   Hob = GetFirstHob (EFI_HOB_TYPE_CPU);
>   if (Hob != NULL) {
> PhysicalAddressBits = ((EFI_HOB_CPU *) Hob)->SizeOfMemorySpace;
>   } else {
> AsmCpuid (0x8000, , NULL, NULL, NULL);
> if (RegEax >= 0x8008) {
>   AsmCpuid (0x8008, , NULL, NULL, NULL);
>   PhysicalAddressBits = (UINT8) RegEax;
> } else {
>   PhysicalAddressBits = 36;
> }
> >   }
> 
> 
> 
> This is problematic in a couple ways:
> 
> 
> 
> 1. AsmCpuid is not portable across architectures (understandably we would 
> have said
> that SMM is an IA thing originally)
> 
> 2. The PI spec for SMM does not specify the use of HOBs (in fact I was very 
> surprised
> to even see HOBs in SMM, and even more confounded by platforms using the 
> "DxeHobLib" in
> the SMM core and drivers!)
> 
> 
> 
> I think this would be a good job for a base library interface to handle - 
> (e.g. UINTN
> GetCpuPhysicalAddressBits().  You could then have a version that uses HOBs 
> (MdePkg),
> another IA specific one (UefiCpuPackage) that uses CPU ID, and one that works 
> for ARM
> (ArmPkg)  that reads ID registers.
> 
> 
> 
> Does that sound reasonable?
> 
> 
> 
> [Presumably this is just the beginning - we see AsmCpuId show up in a lot of 
> modules
> that need to be architecture-agnostic like BootScript (1G page support), 
> CapsulePei (1G
> page support), and AcpiS3SaveDxe (1G pages and physical address size).]
> 
> 
> 
> Eugene
> ___
> 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] How do you get current timestamp in ms or ns ?

[Shubha Ramani]

Is there an EDK2 API which returns the current timetamp or current number of 
ticks thathave elapsed in nanoseconds or milliseconds ?
I have tried GetTime() and it returns the time in seconds. I need higher 
resolution thanseconds. 
I also tried GetPerformanceCounter() but I get 0 for some reason.
Thanks !
Shubha Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel