Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

2017-04-05 Thread Long, Qin
Yes, it's feasible.
I still prefer to use "Library/Include" path setting for this, since only 
CryptoPkg/Library/*
will refer to these internal header files.
It may be cleaner to keep the current directory in root of CryptoPkg. 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, April 06, 2017 2:09 PM
> To: Long, Qin; Ye, Ting
> Cc: edk2-devel@lists.01.org
> Subject: RE: [Patch] CryptoPkg: Move openssl and CRT headers to private
> include section
> 
> Qin:
>   How about creating new Private directory in CryptoPkg, then move those
> internal header files into it?
> 
> Thanks
> Liming
> >-Original Message-
> >From: Long, Qin
> >Sent: Thursday, April 06, 2017 1:56 PM
> >To: Gao, Liming ; Ye, Ting 
> >Cc: edk2-devel@lists.01.org; Long, Qin 
> >Subject: [Patch] CryptoPkg: Move openssl and CRT headers to private
> >include section
> >
> >Moving the header files for openssl and CRT wrappers to the private
> >include section, since these files should be referenced by CryptoPkg
> >internally. This update was supported by new [Includes.Common.Private]
> >setting in Package DEC file.
> >The external consumer modules should only use the interfaces defined in
> >BaseCryptLib.h to access crypto functions. This change will be helpful
> >to immediately detect any illegal direct reference to internal openssl
> >headers.
> >The Perl script "process_files.pl" was also updated to reflect the new
> >private include path.
> >
> >Cc: Gao Liming 
> >Cc: Ting Ye 
> >Contributed-under: TianoCore Contribution Agreement 1.0
> >Signed-off-by: Qin Long 
> >Signed-off-by: Long Qin 
> >---
> > CryptoPkg/CryptoPkg.dec   | 3 +++
> > CryptoPkg/{ => Library}/Include/CrtLibSupport.h   | 0
> > CryptoPkg/{ => Library}/Include/assert.h  | 0
> > CryptoPkg/{ => Library}/Include/ctype.h   | 0
> > CryptoPkg/{ => Library}/Include/errno.h   | 0
> > CryptoPkg/{ => Library}/Include/internal/dso_conf.h   | 0
> > CryptoPkg/{ => Library}/Include/limits.h  | 0
> > CryptoPkg/{ => Library}/Include/memory.h  | 0
> > CryptoPkg/{ => Library}/Include/openssl/opensslconf.h | 0
> > CryptoPkg/{ => Library}/Include/stdarg.h  | 0
> > CryptoPkg/{ => Library}/Include/stddef.h  | 0
> > CryptoPkg/{ => Library}/Include/stdio.h   | 0
> > CryptoPkg/{ => Library}/Include/stdlib.h  | 0
> > CryptoPkg/{ => Library}/Include/string.h  | 0
> > CryptoPkg/{ => Library}/Include/strings.h | 0
> > CryptoPkg/{ => Library}/Include/sys/time.h| 0
> > CryptoPkg/{ => Library}/Include/sys/types.h   | 0
> > CryptoPkg/{ => Library}/Include/syslog.h  | 0
> > CryptoPkg/{ => Library}/Include/time.h| 0
> > CryptoPkg/{ => Library}/Include/unistd.h  | 0
> > CryptoPkg/Library/OpensslLib/process_files.pl | 2 +-
> > 21 files changed, 4 insertions(+), 1 deletion(-)  rename CryptoPkg/{
> >=> Library}/Include/CrtLibSupport.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/assert.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/ctype.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/errno.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/internal/dso_conf.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/limits.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/memory.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/openssl/opensslconf.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stdarg.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stddef.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stdio.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/stdlib.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/string.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/strings.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/sys/time.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/sys/types.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/syslog.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/time.h (100%)  rename CryptoPkg/{ =>
> >Library}/Include/unistd.h (100%)
> >
> >diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec index
> >fdccbf06f7..b2fae6142a 100644
> >--- a/CryptoPkg/CryptoPkg.dec
> >+++ b/CryptoPkg/CryptoPkg.dec
> >@@ -24,6 +24,9 @@
> >
> > [Includes]
> >   Include
> >+
> >+[Includes.Common.Private]
> >+  Library/Include
> >   Library/OpensslLib/openssl/include
> >   Library/OpensslLib/openssl/crypto/include
> >
> >diff --git a/CryptoPkg/Include/CrtLibSupport.h
> >b/CryptoPkg/Library/Include/CrtLibSupport.h
> >similarity index 100%
> >rename from CryptoPkg/Include/CrtLibSupport.h rename to
> >CryptoPkg/Library/Include/CrtLibSupport.h
> >diff --git a/CryptoPkg/Include/assert.h
> >b/CryptoPkg/Library/Include/assert.h
> >similarity index 100%
> >rename from CryptoPkg/Include/assert.h
> >rename to CryptoPkg/Library/Include/assert.h
> >diff --git a/CryptoPkg/Include/ct

Re: [edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

2017-04-05 Thread Gao, Liming
Qin:
  How about creating new Private directory in CryptoPkg, then move those 
internal header files into it? 

Thanks
Liming
>-Original Message-
>From: Long, Qin
>Sent: Thursday, April 06, 2017 1:56 PM
>To: Gao, Liming ; Ye, Ting 
>Cc: edk2-devel@lists.01.org; Long, Qin 
>Subject: [Patch] CryptoPkg: Move openssl and CRT headers to private include
>section
>
>Moving the header files for openssl and CRT wrappers to the private
>include section, since these files should be referenced by CryptoPkg
>internally. This update was supported by new [Includes.Common.Private]
>setting in Package DEC file.
>The external consumer modules should only use the interfaces defined
>in BaseCryptLib.h to access crypto functions. This change will be
>helpful to immediately detect any illegal direct reference to internal
>openssl headers.
>The Perl script "process_files.pl" was also updated to reflect the new
>private include path.
>
>Cc: Gao Liming 
>Cc: Ting Ye 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Qin Long 
>Signed-off-by: Long Qin 
>---
> CryptoPkg/CryptoPkg.dec   | 3 +++
> CryptoPkg/{ => Library}/Include/CrtLibSupport.h   | 0
> CryptoPkg/{ => Library}/Include/assert.h  | 0
> CryptoPkg/{ => Library}/Include/ctype.h   | 0
> CryptoPkg/{ => Library}/Include/errno.h   | 0
> CryptoPkg/{ => Library}/Include/internal/dso_conf.h   | 0
> CryptoPkg/{ => Library}/Include/limits.h  | 0
> CryptoPkg/{ => Library}/Include/memory.h  | 0
> CryptoPkg/{ => Library}/Include/openssl/opensslconf.h | 0
> CryptoPkg/{ => Library}/Include/stdarg.h  | 0
> CryptoPkg/{ => Library}/Include/stddef.h  | 0
> CryptoPkg/{ => Library}/Include/stdio.h   | 0
> CryptoPkg/{ => Library}/Include/stdlib.h  | 0
> CryptoPkg/{ => Library}/Include/string.h  | 0
> CryptoPkg/{ => Library}/Include/strings.h | 0
> CryptoPkg/{ => Library}/Include/sys/time.h| 0
> CryptoPkg/{ => Library}/Include/sys/types.h   | 0
> CryptoPkg/{ => Library}/Include/syslog.h  | 0
> CryptoPkg/{ => Library}/Include/time.h| 0
> CryptoPkg/{ => Library}/Include/unistd.h  | 0
> CryptoPkg/Library/OpensslLib/process_files.pl | 2 +-
> 21 files changed, 4 insertions(+), 1 deletion(-)
> rename CryptoPkg/{ => Library}/Include/CrtLibSupport.h (100%)
> rename CryptoPkg/{ => Library}/Include/assert.h (100%)
> rename CryptoPkg/{ => Library}/Include/ctype.h (100%)
> rename CryptoPkg/{ => Library}/Include/errno.h (100%)
> rename CryptoPkg/{ => Library}/Include/internal/dso_conf.h (100%)
> rename CryptoPkg/{ => Library}/Include/limits.h (100%)
> rename CryptoPkg/{ => Library}/Include/memory.h (100%)
> rename CryptoPkg/{ => Library}/Include/openssl/opensslconf.h (100%)
> rename CryptoPkg/{ => Library}/Include/stdarg.h (100%)
> rename CryptoPkg/{ => Library}/Include/stddef.h (100%)
> rename CryptoPkg/{ => Library}/Include/stdio.h (100%)
> rename CryptoPkg/{ => Library}/Include/stdlib.h (100%)
> rename CryptoPkg/{ => Library}/Include/string.h (100%)
> rename CryptoPkg/{ => Library}/Include/strings.h (100%)
> rename CryptoPkg/{ => Library}/Include/sys/time.h (100%)
> rename CryptoPkg/{ => Library}/Include/sys/types.h (100%)
> rename CryptoPkg/{ => Library}/Include/syslog.h (100%)
> rename CryptoPkg/{ => Library}/Include/time.h (100%)
> rename CryptoPkg/{ => Library}/Include/unistd.h (100%)
>
>diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec
>index fdccbf06f7..b2fae6142a 100644
>--- a/CryptoPkg/CryptoPkg.dec
>+++ b/CryptoPkg/CryptoPkg.dec
>@@ -24,6 +24,9 @@
>
> [Includes]
>   Include
>+
>+[Includes.Common.Private]
>+  Library/Include
>   Library/OpensslLib/openssl/include
>   Library/OpensslLib/openssl/crypto/include
>
>diff --git a/CryptoPkg/Include/CrtLibSupport.h
>b/CryptoPkg/Library/Include/CrtLibSupport.h
>similarity index 100%
>rename from CryptoPkg/Include/CrtLibSupport.h
>rename to CryptoPkg/Library/Include/CrtLibSupport.h
>diff --git a/CryptoPkg/Include/assert.h b/CryptoPkg/Library/Include/assert.h
>similarity index 100%
>rename from CryptoPkg/Include/assert.h
>rename to CryptoPkg/Library/Include/assert.h
>diff --git a/CryptoPkg/Include/ctype.h b/CryptoPkg/Library/Include/ctype.h
>similarity index 100%
>rename from CryptoPkg/Include/ctype.h
>rename to CryptoPkg/Library/Include/ctype.h
>diff --git a/CryptoPkg/Include/errno.h b/CryptoPkg/Library/Include/errno.h
>similarity index 100%
>rename from CryptoPkg/Include/errno.h
>rename to CryptoPkg/Library/Include/errno.h
>diff --git a/CryptoPkg/Include/internal/dso_conf.h
>b/CryptoPkg/Library/Include/internal/dso_conf.h
>similarity index 100%
>rename from CryptoPkg/Include/internal/dso_conf.h
>rename to CryptoPkg/Library/Include/internal/dso_conf.h
>diff --git a/CryptoPkg/Include/limits.h b/CryptoPkg/Library/Include/limits.h
>similarity index 100%
>rename from CryptoPkg/Include/limit

[edk2] [Patch] CryptoPkg: Move openssl and CRT headers to private include section

2017-04-05 Thread Long Qin
Moving the header files for openssl and CRT wrappers to the private
include section, since these files should be referenced by CryptoPkg
internally. This update was supported by new [Includes.Common.Private]
setting in Package DEC file.
The external consumer modules should only use the interfaces defined
in BaseCryptLib.h to access crypto functions. This change will be
helpful to immediately detect any illegal direct reference to internal
openssl headers.
The Perl script "process_files.pl" was also updated to reflect the new
private include path.

Cc: Gao Liming 
Cc: Ting Ye 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
Signed-off-by: Long Qin 
---
 CryptoPkg/CryptoPkg.dec   | 3 +++
 CryptoPkg/{ => Library}/Include/CrtLibSupport.h   | 0
 CryptoPkg/{ => Library}/Include/assert.h  | 0
 CryptoPkg/{ => Library}/Include/ctype.h   | 0
 CryptoPkg/{ => Library}/Include/errno.h   | 0
 CryptoPkg/{ => Library}/Include/internal/dso_conf.h   | 0
 CryptoPkg/{ => Library}/Include/limits.h  | 0
 CryptoPkg/{ => Library}/Include/memory.h  | 0
 CryptoPkg/{ => Library}/Include/openssl/opensslconf.h | 0
 CryptoPkg/{ => Library}/Include/stdarg.h  | 0
 CryptoPkg/{ => Library}/Include/stddef.h  | 0
 CryptoPkg/{ => Library}/Include/stdio.h   | 0
 CryptoPkg/{ => Library}/Include/stdlib.h  | 0
 CryptoPkg/{ => Library}/Include/string.h  | 0
 CryptoPkg/{ => Library}/Include/strings.h | 0
 CryptoPkg/{ => Library}/Include/sys/time.h| 0
 CryptoPkg/{ => Library}/Include/sys/types.h   | 0
 CryptoPkg/{ => Library}/Include/syslog.h  | 0
 CryptoPkg/{ => Library}/Include/time.h| 0
 CryptoPkg/{ => Library}/Include/unistd.h  | 0
 CryptoPkg/Library/OpensslLib/process_files.pl | 2 +-
 21 files changed, 4 insertions(+), 1 deletion(-)
 rename CryptoPkg/{ => Library}/Include/CrtLibSupport.h (100%)
 rename CryptoPkg/{ => Library}/Include/assert.h (100%)
 rename CryptoPkg/{ => Library}/Include/ctype.h (100%)
 rename CryptoPkg/{ => Library}/Include/errno.h (100%)
 rename CryptoPkg/{ => Library}/Include/internal/dso_conf.h (100%)
 rename CryptoPkg/{ => Library}/Include/limits.h (100%)
 rename CryptoPkg/{ => Library}/Include/memory.h (100%)
 rename CryptoPkg/{ => Library}/Include/openssl/opensslconf.h (100%)
 rename CryptoPkg/{ => Library}/Include/stdarg.h (100%)
 rename CryptoPkg/{ => Library}/Include/stddef.h (100%)
 rename CryptoPkg/{ => Library}/Include/stdio.h (100%)
 rename CryptoPkg/{ => Library}/Include/stdlib.h (100%)
 rename CryptoPkg/{ => Library}/Include/string.h (100%)
 rename CryptoPkg/{ => Library}/Include/strings.h (100%)
 rename CryptoPkg/{ => Library}/Include/sys/time.h (100%)
 rename CryptoPkg/{ => Library}/Include/sys/types.h (100%)
 rename CryptoPkg/{ => Library}/Include/syslog.h (100%)
 rename CryptoPkg/{ => Library}/Include/time.h (100%)
 rename CryptoPkg/{ => Library}/Include/unistd.h (100%)

diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec
index fdccbf06f7..b2fae6142a 100644
--- a/CryptoPkg/CryptoPkg.dec
+++ b/CryptoPkg/CryptoPkg.dec
@@ -24,6 +24,9 @@
 
 [Includes]
   Include
+
+[Includes.Common.Private]
+  Library/Include
   Library/OpensslLib/openssl/include
   Library/OpensslLib/openssl/crypto/include
 
diff --git a/CryptoPkg/Include/CrtLibSupport.h 
b/CryptoPkg/Library/Include/CrtLibSupport.h
similarity index 100%
rename from CryptoPkg/Include/CrtLibSupport.h
rename to CryptoPkg/Library/Include/CrtLibSupport.h
diff --git a/CryptoPkg/Include/assert.h b/CryptoPkg/Library/Include/assert.h
similarity index 100%
rename from CryptoPkg/Include/assert.h
rename to CryptoPkg/Library/Include/assert.h
diff --git a/CryptoPkg/Include/ctype.h b/CryptoPkg/Library/Include/ctype.h
similarity index 100%
rename from CryptoPkg/Include/ctype.h
rename to CryptoPkg/Library/Include/ctype.h
diff --git a/CryptoPkg/Include/errno.h b/CryptoPkg/Library/Include/errno.h
similarity index 100%
rename from CryptoPkg/Include/errno.h
rename to CryptoPkg/Library/Include/errno.h
diff --git a/CryptoPkg/Include/internal/dso_conf.h 
b/CryptoPkg/Library/Include/internal/dso_conf.h
similarity index 100%
rename from CryptoPkg/Include/internal/dso_conf.h
rename to CryptoPkg/Library/Include/internal/dso_conf.h
diff --git a/CryptoPkg/Include/limits.h b/CryptoPkg/Library/Include/limits.h
similarity index 100%
rename from CryptoPkg/Include/limits.h
rename to CryptoPkg/Library/Include/limits.h
diff --git a/CryptoPkg/Include/memory.h b/CryptoPkg/Library/Include/memory.h
similarity index 100%
rename from CryptoPkg/Include/memory.h
rename to CryptoPkg/Library/Include/memory.h
diff --git a/CryptoPkg/Include/openssl/opensslconf.h 
b/CryptoPkg/Library/Include/openssl/opensslconf.h
similarity index 100%
rename from CryptoPkg/Include/openssl/opensslconf.h
rename to CryptoPkg/Library/Include/openssl/opensslco

[edk2] [PATCH] UefiCpuPkg/CpuFeatures: Change CPU features name to follow IA32 SDM

2017-04-05 Thread Jeff Fan
Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
---
 UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index 4765bc3..4aa3529 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -45,8 +45,8 @@
 #define CPU_FEATURE_C1E 16
 #define CPU_FEATURE_C1_AUTO_DEMOTION17
 #define CPU_FEATURE_C3_AUTO_DEMOTION18
-#define CPU_FEATURE_C1_AUTO_UNDEMOTION  19
-#define CPU_FEATURE_C3_AUTO_UNDEMOTION  20
+#define CPU_FEATURE_C1_UNDEMOTION   19
+#define CPU_FEATURE_C3_UNDEMOTION   20
 #define CPU_FEATURE_C_STATE 21
 #define CPU_FEATURE_TM  22
 #define CPU_FEATURE_TM2 23
-- 
2.9.3.windows.2

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


Re: [edk2] [DxeNetLib] Why do we restrict each field to have the same leading zero format?

2017-04-05 Thread Wu, Jiaxin
Hi Gary,

The issue has been gone since the version of 
9f5ca5efbd0bb00c9d3577b95e6322e85cb0b118. Please check that.

Thanks,
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Guoheyi
> Sent: Wednesday, April 5, 2017 6:56 PM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Wu, Jiaxin ; Fu,
> Siyuan ; Zeng, Star 
> Subject: [edk2] [DxeNetLib] Why do we restrict each field to have the same
> leading zero format?
> 
> Hi folks,
> 
> We are using NetLibAsciiStrToIp6 function in DxeNetLib.c of MdeModulePkg
> to convert string to IPv6 address. We found this function will return invalid
> parameter with below input:
> 2001:3456:789a::f012:2:2003:2005
> 
> We trace the code and believe it is handled by the branch in line 2955:
> 
>   if ((Cnt != 0) && (Cnt < 4) && LeadZero) {
> return EFI_INVALID_PARAMETER;
>   }
> 
> I think the reason is that we have field 3 of "" which has leading zero 
> and
> causes LeadZero flag to be true, and it requires all the following fields to 
> have
> the same leading zero format, while field 5 of "2" is not.
> 
> I checked RFC 4291 and only found below text; I didn't find any restriction
> that requires each field to have the same leading zero format.
> 
>1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
>   four hexadecimal digits of the eight 16-bit pieces of the address.
>   Examples:
> 
>  ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
> 
>  2001:DB8:0:0:8:800:200C:417A
> 
>   Note that it is not necessary to write the leading zeros in an
>   individual field, but there must be at least one numeral in every
>   field (except for the case described in 2.).
> 
> Could you help to confirm whether it is a bug or there is some special reason
> for this?
> 
> Thanks and regards,
> 
> Gary (Heyi Guo)
> ___
> 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 v4 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Laszlo Ersek
Apologies, I noticed something else:

On 04/05/17 14:55, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan 
> 
> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
> a basic version of VMWare's SVGA display device. Drivers for this
> device exist for some guest OSes which do not support Qemu's other
> display adapters, so supporting it in OVMF is useful in conjunction
> with those OSes.
> 
> This change adds support for the SVGA device's framebuffer to
> QemuVideoDxe's graphics output protocol implementation, based on
> VMWare's documentation. The most basic initialisation, framebuffer
> layout query, and mode setting operations are implemented.
> 
> The device relies on port-based 32-bit I/O, unfortunately on misaligned
> addresses. This limits the driver's support to the x86 family of
> platforms.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Phil Dennis-Jordan 
> ---
> 
> Notes:
> v2:
> - Unaligned I/O helper functions moved to separate commit [Laszlo]
> - Multi-line function call whitespace fixes.
> 
> v3:
> - Dropped the "2" from "SVGA2" where appropriate. [Jordan, Laszlo]
> - Renamed various struct fields and functions with consistent prefixes 
> [Laszlo]
> - #include orders fixed [Laszlo]
> - Renamedi/moved lots of local variables to comply with convention. 
> [Laszlo]
> - Added error checking to PCI BAR queries. [Laszlo]
> - Moved some function definitions around for better grouping. [Laszlo]
> - Fixed ClearScreen() to use the correct VRAM BAR. [Laszlo]
> - Changed modelist initialisation to fetch all mode data on startup, so 
> mode
>   queries can return everything including channel masks without hitting 
> the
>   device. Mask calculations hopefully make more sense now. [Laszlo]
> - Whitespace fixes. [Laszlo]
> - Fixed a memory leak in BAR query.
> 
> v4:
> - Simplified mode info pixel mask calculation & PCI BAR OOB check. 
> [Laszlo]
> - Replaced struct assignment with CopyMem. [Laszlo]
> - Whitespace & comment typo fixes. [Laszlo]
> 
>  OvmfPkg/QemuVideoDxe/Qemu.h   |  29 
>  OvmfPkg/QemuVideoDxe/Driver.c | 128 +++-
>  OvmfPkg/QemuVideoDxe/Gop.c|  61 +++-
>  OvmfPkg/QemuVideoDxe/Initialize.c | 161 
>  4 files changed, 372 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
> index 2ce37defc5b8..7fbb25b3efd3 100644
> --- a/OvmfPkg/QemuVideoDxe/Qemu.h
> +++ b/OvmfPkg/QemuVideoDxe/Qemu.h
> @@ -92,6 +92,7 @@ typedef enum {
>QEMU_VIDEO_CIRRUS_5446,
>QEMU_VIDEO_BOCHS,
>QEMU_VIDEO_BOCHS_MMIO,
> +  QEMU_VIDEO_VMWARE_SVGA,
>  } QEMU_VIDEO_VARIANT;
>  
>  typedef struct {
> @@ -115,10 +116,13 @@ typedef struct {
>//
>UINTN MaxMode;
>QEMU_VIDEO_MODE_DATA  *ModeData;
> +  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *VmwareSvgaModeInfo;

This array is dynamically allocated in QemuVideoVmwareSvgaModeSetup(),
which is called from QemuVideoControllerDriverStart(). That's OK.

However, it is not freed (except on the error path in
QemuVideoVmwareSvgaModeSetup(), under the Rollback label). It should be
freed in two additional places:

- in QemuVideoControllerDriverStart(), under the FreeModeData label
(which is also part of an (outer) error path),

- in QemuVideoControllerDriverStop(), near

  FreePool (Private->ModeData);

Of course, these additional FreePool() calls should be conditional, as
FreePool() doesn't handle NULL automatically.

I should have noticed this earlier (in v3); sorry about that.

Thanks,
Laszlo

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


Re: [edk2] [PATCH 5/6] MdePkg: Convert files to CRLF line ending

2017-04-05 Thread Gao, Liming
Reviewed-by: Liming Gao 

>-Original Message-
>From: Wu, Hao A
>Sent: Thursday, April 06, 2017 10:25 AM
>To: edk2-devel@lists.01.org
>Cc: Wu, Hao A ; Kinney, Michael D
>; Gao, Liming 
>Subject: [PATCH 5/6] MdePkg: Convert files to CRLF line ending
>
>Cc: Michael Kinney 
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Hao Wu 
>---
> MdePkg/Include/IndustryStandard/Tls1.h | 186 ++--
> MdePkg/Include/Protocol/Tls.h  | 921 ++--
> MdePkg/Include/Protocol/TlsConfig.h| 265 +++---
> MdePkg/Library/BaseLib/SafeString.c|  39 +-
> 4 files changed, 707 insertions(+), 704 deletions(-)
>
>diff --git a/MdePkg/Include/IndustryStandard/Tls1.h
>b/MdePkg/Include/IndustryStandard/Tls1.h
>index 019ff617de..9009291ee3 100644
>--- a/MdePkg/Include/IndustryStandard/Tls1.h
>+++ b/MdePkg/Include/IndustryStandard/Tls1.h
>@@ -1,93 +1,93 @@
>-/** @file
>-  Transport Layer Security  -- TLS 1.0/1.1/1.2 Standard definitions, from RFC
>2246/4346/5246
>-
>-  This file contains common TLS 1.0/1.1/1.2 definitions from RFC
>2246/4346/5246
>-
>-  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
>-  This program and the accompanying materials
>-  are licensed and made available under the terms and conditions of the BSD
>License
>-  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 __TLS_1_H__
>-#define __TLS_1_H__
>-
>-#pragma pack(1)
>-
>-///
>-/// TLS Cipher Suite, refers to A.5 of rfc-2246, rfc-4346 and rfc-5246.
>-///
>-#define TLS_RSA_WITH_NULL_MD5{0x00, 0x01}
>-#define TLS_RSA_WITH_NULL_SHA{0x00, 0x02}
>-#define TLS_RSA_WITH_RC4_128_MD5 {0x00, 0x04}
>-#define TLS_RSA_WITH_RC4_128_SHA {0x00, 0x05}
>-#define TLS_RSA_WITH_IDEA_CBC_SHA{0x00, 0x07}
>-#define TLS_RSA_WITH_DES_CBC_SHA {0x00, 0x09}
>-#define TLS_RSA_WITH_3DES_EDE_CBC_SHA{0x00, 0x0A}
>-#define TLS_DH_DSS_WITH_DES_CBC_SHA  {0x00, 0x0C}
>-#define TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA {0x00, 0x0D}
>-#define TLS_DH_RSA_WITH_DES_CBC_SHA  {0x00, 0x0F}
>-#define TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA {0x00, 0x10}
>-#define TLS_DHE_DSS_WITH_DES_CBC_SHA {0x00, 0x12}
>-#define TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA{0x00, 0x13}
>-#define TLS_DHE_RSA_WITH_DES_CBC_SHA {0x00, 0x15}
>-#define TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA{0x00, 0x16}
>-#define TLS_RSA_WITH_AES_128_CBC_SHA {0x00, 0x2F}
>-#define TLS_DH_DSS_WITH_AES_128_CBC_SHA  {0x00, 0x30}
>-#define TLS_DH_RSA_WITH_AES_128_CBC_SHA  {0x00, 0x31}
>-#define TLS_DHE_DSS_WITH_AES_128_CBC_SHA {0x00, 0x32}
>-#define TLS_DHE_RSA_WITH_AES_128_CBC_SHA {0x00, 0x33}
>-#define TLS_RSA_WITH_AES_256_CBC_SHA {0x00, 0x35}
>-#define TLS_DH_DSS_WITH_AES_256_CBC_SHA  {0x00, 0x36}
>-#define TLS_DH_RSA_WITH_AES_256_CBC_SHA  {0x00, 0x37}
>-#define TLS_DHE_DSS_WITH_AES_256_CBC_SHA {0x00, 0x38}
>-#define TLS_DHE_RSA_WITH_AES_256_CBC_SHA {0x00, 0x39}
>-#define TLS_RSA_WITH_NULL_SHA256 {0x00, 0x3B}
>-#define TLS_RSA_WITH_AES_128_CBC_SHA256  {0x00, 0x3C}
>-#define TLS_RSA_WITH_AES_256_CBC_SHA256  {0x00, 0x3D}
>-#define TLS_DH_DSS_WITH_AES_128_CBC_SHA256   {0x00, 0x3E}
>-#define TLS_DH_RSA_WITH_AES_128_CBC_SHA256   {0x00, 0x3F}
>-#define TLS_DHE_DSS_WITH_AES_128_CBC_SHA256  {0x00, 0x40}
>-#define TLS_DHE_RSA_WITH_AES_128_CBC_SHA256  {0x00, 0x67}
>-#define TLS_DH_DSS_WITH_AES_256_CBC_SHA256   {0x00, 0x68}
>-#define TLS_DH_RSA_WITH_AES_256_CBC_SHA256   {0x00, 0x69}
>-#define TLS_DHE_DSS_WITH_AES_256_CBC_SHA256  {0x00, 0x6A}
>-#define TLS_DHE_RSA_WITH_AES_256_CBC_SHA256  {0x00, 0x6B}
>-
>-///
>-/// TLS Version, refers to A.1 of rfc-2246, rfc-4346 and rfc-5246.
>-///
>-#define TLS10_PROTOCOL_VERSION_MAJOR  0x03
>-#define TLS10_PROTOCOL_VERSION_MINOR  0x01
>-#define TLS11_PROTOCOL_VERSION_MAJOR  0x03
>-#define TLS11_PROTOCOL_VERSION_MINOR  0x02
>-#define TLS12_PROTOCOL_VERSION_MAJOR  0x03
>-#define TLS12_PROTOCOL_VERSION_MINOR  0x03
>-
>-///
>-/// TLS Content Type, refers to A.1 of rfc-2246, rfc-4346 and rfc-5246.
>-///
>-typedef enum {
>-  TlsContentTypeChangeCipherSpec = 20,
>-  TlsContentTypeAlert= 21,
>-  TlsContentTypeHandshake= 22,
>-  TlsContentTypeApplicationData  = 23,
>-} TLS_CONTENT_TYPE;
>-
>-///
>-/// TLS Record Header, refers to A.1 of rfc-2246, rfc-4346 and rfc-5246.
>-///
>-typedef struct {
>-  UINT8   ContentType;
>-  EFI_TLS_VERSION Version;
>-  UINT16  Length;
>-} TLS_RECORD_HEADER;
>-
>-#pragma pack()
>-
>-#endif

Re: [edk2] [edk2-FdfSpecification Patch] IMAGE_TYPE_ID is required in [FmpPayload] section

2017-04-05 Thread Zhu, Yonghong
Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong

-Original Message-
From: Kinney, Michael D 
Sent: Thursday, April 6, 2017 11:38 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-FdfSpecification Patch] IMAGE_TYPE_ID is required in 
[FmpPayload] section

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

Update the EBNF for [FmpPayload] in Section 3.8 so IMAGE_TYPE_ID is required 
and must always be assigned to a valid registry format GUID value.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md 
b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
index 8368ac3..1c38f59 100644
--- a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
+++ b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
@@ -41,7 +41,7 @@ Capsule files.
   
   
::= [ "IMAGE_HEADER_INIT_VERSION"   ]
-  [ "IMAGE_TYPE_ID"   ]
+   "IMAGE_TYPE_ID"   
   [ "IMAGE_INDEX"   ]
   [ "HARDWARE_INSTANCE"   ]   
::=  "FILE"  "DATA"   
--
2.6.3.windows.1

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


[edk2] [edk2-FdfSpecification Patch] IMAGE_TYPE_ID is required in [FmpPayload] section

2017-04-05 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=426

Update the EBNF for [FmpPayload] in Section 3.8
so IMAGE_TYPE_ID is required and must always be assigned
to a valid registry format GUID value.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md 
b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
index 8368ac3..1c38f59 100644
--- a/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
+++ b/3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md
@@ -41,7 +41,7 @@ Capsule files.
   
   
::= [ "IMAGE_HEADER_INIT_VERSION"   ]
-  [ "IMAGE_TYPE_ID"   ]
+   "IMAGE_TYPE_ID"   
   [ "IMAGE_INDEX"   ]
   [ "HARDWARE_INSTANCE"   ]
  ::=  "FILE"  "DATA"   
-- 
2.6.3.windows.1

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


[edk2] [edk2-FdfSpecification Patch] IMAGE_TYPE_ID is required in [FmpPayload] section

2017-04-05 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=426

Update the EBNF for [FmpPayload] in Section 3.8
so IMAGE_TYPE_ID is required and must always be assigned
to a valid registry format GUID value.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

GitHub branch for review:

  
https://github.com/mdkinney/edk2-FdfSpecification/tree/Bugzilla_426_IMAGE_TYPE_ID_Required


GitHub branch compare against latest DRAFT for review:
  
  
https://github.com/tianocore-docs/edk2-FdfSpecification/compare/master...mdkinney:Bugzilla_426_IMAGE_TYPE_ID_Required?w=1

Michael Kinney (1):
  IMAGE_TYPE_ID is required in [FmpPayload] section

 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.6.3.windows.1

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


Re: [edk2] [PATCH 2/6] IntelFsp2Pkg: Convert files to CRLF line ending

2017-04-05 Thread Yao, Jiewen
Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, April 6, 2017 10:25 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen 
> Subject: [PATCH 2/6] IntelFsp2Pkg: Convert files to CRLF line ending
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  IntelFsp2Pkg/Readme.md | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/IntelFsp2Pkg/Readme.md b/IntelFsp2Pkg/Readme.md
> index 6e38e8ca61..719ce099e4 100644
> --- a/IntelFsp2Pkg/Readme.md
> +++ b/IntelFsp2Pkg/Readme.md
> @@ -1,7 +1,7 @@
> -# IntelFsp2Pkg
> -
> -This package provides the component to create an FSP binary.
> -
> -Source Repository:
> https://github.com/tianocore/edk2/tree/master/IntelFsp2Pkg
> -
> -A whitepaper to describe the IntelFsp2Pkg:
> https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_t
> he_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP
> 2.0%29.pdf
> \ No newline at end of file
> +# IntelFsp2Pkg
> +
> +This package provides the component to create an FSP binary.
> +
> +Source Repository:
> https://github.com/tianocore/edk2/tree/master/IntelFsp2Pkg
> +
> +A whitepaper to describe the IntelFsp2Pkg:
> https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_t
> he_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP
> 2.0%29.pdf
> --
> 2.12.0.windows.1

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


Re: [edk2] [PATCH 4/6] SignedCapsulePkg: Convert files to CRLF line ending

2017-04-05 Thread Yao, Jiewen
Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, April 6, 2017 10:25 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen 
> Subject: [PATCH 4/6] SignedCapsulePkg: Convert files to CRLF line ending
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  SignedCapsulePkg/Readme.md | 22 ++--
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/SignedCapsulePkg/Readme.md b/SignedCapsulePkg/Readme.md
> index 67c78edfb4..03358e93ee 100644
> --- a/SignedCapsulePkg/Readme.md
> +++ b/SignedCapsulePkg/Readme.md
> @@ -1,11 +1,11 @@
> -# SignedCapsulePkg
> -
> -This package provides a signed capsule solution in EDKII to support a secure
> capsule update and recovery solution.
> -
> -Source Repository:
> https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg
> -
> -A whitepaper to describe the capsule design:
> https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Be
> yond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf
> -
> -Wiki pages to provides more detail on how to enable:
> https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware
> -Update-and-Firmware-Recovery
> -
> -
> +# SignedCapsulePkg
> +
> +This package provides a signed capsule solution in EDKII to support a secure
> capsule update and recovery solution.
> +
> +Source Repository:
> https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg
> +
> +A whitepaper to describe the capsule design:
> https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Be
> yond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf
> +
> +Wiki pages to provides more detail on how to enable:
> https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware
> -Update-and-Firmware-Recovery
> +
> +
> --
> 2.12.0.windows.1

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


Re: [edk2] [PATCH 3/6] IntelFsp2WrapperPkg: Convert files to CRLF line ending

2017-04-05 Thread Yao, Jiewen
Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, April 6, 2017 10:25 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen 
> Subject: [PATCH 3/6] IntelFsp2WrapperPkg: Convert files to CRLF line ending
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  IntelFsp2WrapperPkg/Readme.md | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/IntelFsp2WrapperPkg/Readme.md
> b/IntelFsp2WrapperPkg/Readme.md
> index 0b0f81b033..dfcb4c1a2e 100644
> --- a/IntelFsp2WrapperPkg/Readme.md
> +++ b/IntelFsp2WrapperPkg/Readme.md
> @@ -1,7 +1,7 @@
> -# IntelFsp2WrapperPkg
> -
> -This package provides the component to use an FSP binary.
> -
> -Source Repository:
> https://github.com/tianocore/edk2/tree/master/IntelFsp2WrapperPkg
> -
> -A whitepaper to describe the IntelFsp2WrapperPkg:
> https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Using_the
> _Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0
> %29.pdf
> \ No newline at end of file
> +# IntelFsp2WrapperPkg
> +
> +This package provides the component to use an FSP binary.
> +
> +Source Repository:
> https://github.com/tianocore/edk2/tree/master/IntelFsp2WrapperPkg
> +
> +A whitepaper to describe the IntelFsp2WrapperPkg:
> https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Using_the
> _Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0
> %29.pdf
> --
> 2.12.0.windows.1

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


[edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Add SATA initialization.

2017-04-05 Thread lushifex
Add additional SATA initialization code.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 .../BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScInit.c  |  3 +
 .../BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScSata.c  | 91 +-
 2 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScInit.c 
b/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScInit.c
index 9620dac..3fb37ea 100644
--- a/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScInit.c
+++ b/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScInit.c
@@ -660,6 +660,9 @@ ScOnEndOfDxe (
   gBS->CloseEvent (Event);
 
   BxtSeries = GetBxtSeries ();
+  if (BxtSeries == BxtP) {
+ConfigureSataDxe (mScPolicy);
+  }
   AcpiBaseAddr   = (UINT16) PcdGet16 (PcdScAcpiIoPortBaseAddress);
   PmcBase= PMC_BASE_ADDRESS;
   FuncDisableReg = MmioRead32 (PmcBase + R_PMC_FUNC_DIS);
diff --git a/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScSata.c 
b/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScSata.c
index 63c2b88..c6d83e9 100644
--- a/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScSata.c
+++ b/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScSata.c
@@ -1,7 +1,7 @@
 /** @file
   Perform related functions for SC Sata in DXE phase.
 
-  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -15,4 +15,93 @@
 
 #include 
 
+/**
+  Perform the remaining configuration on SC SATA to perform device detection
+  at end of Dxe, then set the SATA SPD and PxE corresponding, and set the 
Register Lock
+
+  @param[in] ScPolicy   The SC Policy instance
+
+  @retvalEFI_SUCCESSThe function completed successfully
+
+**/
+EFI_STATUS
+ConfigureSataDxe (
+  IN SC_POLICY_HOB *ScPolicy
+  )
+{
+  EFI_STATUS Status;
+  SC_SATA_CONFIG *SataConfig;
+  UINTN  PciSataRegBase;
+  UINT16 SataPortsEnabled;
+  UINT32 DwordReg;
+  UINTN  Index;
+
+  DEBUG ((DEBUG_INFO, "ConfigureSataDxe() Start\n"));
+  Status = GetConfigBlock ((VOID *) ScPolicy, &gSataConfigGuid, (VOID *) 
&SataConfig);
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // SATA PCS: Enable the port in any of below condition:
+  // i.)   Hot plug is enabled
+  // ii.)  A device is attached
+  // iii.) Test mode is enabled
+  // iv.)  Configured as eSATA port
+  //
+  PciSataRegBase = MmPciBase (
+ DEFAULT_PCI_BUS_NUMBER_SC,
+ PCI_DEVICE_NUMBER_SATA,
+ PCI_FUNCTION_NUMBER_SATA
+ );
+  SataPortsEnabled = 0;
+  DwordReg = MmioRead32 (PciSataRegBase + 0x94);
+  DEBUG ((DEBUG_INFO, "PCS = 0x%x\n", DwordReg));
+  for (Index = 0; Index < SC_MAX_SATA_PORTS; Index++) {
+if ((SataConfig->PortSettings[Index].HotPlug == TRUE) ||
+(DwordReg & (BIT16 << Index)) ||
+(SataConfig->TestMode == TRUE) ||
+(SataConfig->PortSettings[Index].External == TRUE)) {
+  SataPortsEnabled |= (SataConfig->PortSettings[Index].Enable << Index);
+}
+  }
+  DEBUG ((DEBUG_INFO, "SataPortsEnabled = 0x%x\n", SataPortsEnabled));
+
+  //
+  // MAP - Port Mapping Register
+  // PCI Offset:   90h - 93h
+  // Value [23:16] Port Disabled
+  //   [7:0]   Port Clock Disabled
+  //
+  MmioOr32 (PciSataRegBase + R_SATA_MAP, (UINT32) ((~SataPortsEnabled << 
N_SATA_MAP_SPD) & B_SATA_MAP_SPD));
+  DEBUG ((DEBUG_INFO, "MAP = 0x%x\n", MmioRead32 (PciSataRegBase + 
R_SATA_MAP)));
+  S3BootScriptSaveMemWrite (
+S3BootScriptWidthUint32,
+(UINTN) (PciSataRegBase + R_SATA_MAP),
+1,
+(VOID *) (UINTN) (PciSataRegBase + R_SATA_MAP)
+);
+
+  MmioOr16 (PciSataRegBase + 0x94, SataPortsEnabled);
+  S3BootScriptSaveMemWrite (
+S3BootScriptWidthUint16,
+(UINTN) (PciSataRegBase + 0x94),
+1,
+(VOID *) (UINTN) (PciSataRegBase + 0x94)
+);
+
+  //
+  // Step 14
+  // Program SATA PCI offset 9Ch [31] to 1b
+  //
+  MmioOr32 ((UINTN) (PciSataRegBase + R_SATA_SATAGC), BIT31);
+  S3BootScriptSaveMemWrite (
+S3BootScriptWidthUint32,
+(UINTN) (PciSataRegBase + R_SATA_SATAGC),
+1,
+(VOID *) (UINTN) (PciSataRegBase + R_SATA_SATAGC)
+);
+  DEBUG ((DEBUG_INFO, "SATAGC = 0x%x\n", MmioRead32 (PciSataRegBase + 
R_SATA_SATAGC)));
+  DEBUG ((DEBUG_INFO, "ConfigureSataDxe() End\n"));
+
+  return EFI_SUCCESS;
+}
 
-- 
2.7.0.windows.1


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


[edk2] [PATCH 5/6] MdePkg: Convert files to CRLF line ending

2017-04-05 Thread Hao Wu
Cc: Michael Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdePkg/Include/IndustryStandard/Tls1.h | 186 ++--
 MdePkg/Include/Protocol/Tls.h  | 921 ++--
 MdePkg/Include/Protocol/TlsConfig.h| 265 +++---
 MdePkg/Library/BaseLib/SafeString.c|  39 +-
 4 files changed, 707 insertions(+), 704 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Tls1.h 
b/MdePkg/Include/IndustryStandard/Tls1.h
index 019ff617de..9009291ee3 100644
--- a/MdePkg/Include/IndustryStandard/Tls1.h
+++ b/MdePkg/Include/IndustryStandard/Tls1.h
@@ -1,93 +1,93 @@
-/** @file
-  Transport Layer Security  -- TLS 1.0/1.1/1.2 Standard definitions, from RFC 
2246/4346/5246
-
-  This file contains common TLS 1.0/1.1/1.2 definitions from RFC 
2246/4346/5246 
-
-  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  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 __TLS_1_H__
-#define __TLS_1_H__
-
-#pragma pack(1)
-
-///
-/// TLS Cipher Suite, refers to A.5 of rfc-2246, rfc-4346 and rfc-5246.
-///
-#define TLS_RSA_WITH_NULL_MD5{0x00, 0x01}
-#define TLS_RSA_WITH_NULL_SHA{0x00, 0x02}
-#define TLS_RSA_WITH_RC4_128_MD5 {0x00, 0x04}
-#define TLS_RSA_WITH_RC4_128_SHA {0x00, 0x05}
-#define TLS_RSA_WITH_IDEA_CBC_SHA{0x00, 0x07}
-#define TLS_RSA_WITH_DES_CBC_SHA {0x00, 0x09}
-#define TLS_RSA_WITH_3DES_EDE_CBC_SHA{0x00, 0x0A}
-#define TLS_DH_DSS_WITH_DES_CBC_SHA  {0x00, 0x0C}
-#define TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA {0x00, 0x0D}
-#define TLS_DH_RSA_WITH_DES_CBC_SHA  {0x00, 0x0F}
-#define TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA {0x00, 0x10}
-#define TLS_DHE_DSS_WITH_DES_CBC_SHA {0x00, 0x12}
-#define TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA{0x00, 0x13}
-#define TLS_DHE_RSA_WITH_DES_CBC_SHA {0x00, 0x15}
-#define TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA{0x00, 0x16}
-#define TLS_RSA_WITH_AES_128_CBC_SHA {0x00, 0x2F}
-#define TLS_DH_DSS_WITH_AES_128_CBC_SHA  {0x00, 0x30}
-#define TLS_DH_RSA_WITH_AES_128_CBC_SHA  {0x00, 0x31}
-#define TLS_DHE_DSS_WITH_AES_128_CBC_SHA {0x00, 0x32}
-#define TLS_DHE_RSA_WITH_AES_128_CBC_SHA {0x00, 0x33}
-#define TLS_RSA_WITH_AES_256_CBC_SHA {0x00, 0x35}
-#define TLS_DH_DSS_WITH_AES_256_CBC_SHA  {0x00, 0x36}
-#define TLS_DH_RSA_WITH_AES_256_CBC_SHA  {0x00, 0x37}
-#define TLS_DHE_DSS_WITH_AES_256_CBC_SHA {0x00, 0x38}
-#define TLS_DHE_RSA_WITH_AES_256_CBC_SHA {0x00, 0x39}
-#define TLS_RSA_WITH_NULL_SHA256 {0x00, 0x3B}
-#define TLS_RSA_WITH_AES_128_CBC_SHA256  {0x00, 0x3C}
-#define TLS_RSA_WITH_AES_256_CBC_SHA256  {0x00, 0x3D}
-#define TLS_DH_DSS_WITH_AES_128_CBC_SHA256   {0x00, 0x3E}
-#define TLS_DH_RSA_WITH_AES_128_CBC_SHA256   {0x00, 0x3F}
-#define TLS_DHE_DSS_WITH_AES_128_CBC_SHA256  {0x00, 0x40}
-#define TLS_DHE_RSA_WITH_AES_128_CBC_SHA256  {0x00, 0x67}
-#define TLS_DH_DSS_WITH_AES_256_CBC_SHA256   {0x00, 0x68}
-#define TLS_DH_RSA_WITH_AES_256_CBC_SHA256   {0x00, 0x69}
-#define TLS_DHE_DSS_WITH_AES_256_CBC_SHA256  {0x00, 0x6A}
-#define TLS_DHE_RSA_WITH_AES_256_CBC_SHA256  {0x00, 0x6B}
-
-///
-/// TLS Version, refers to A.1 of rfc-2246, rfc-4346 and rfc-5246.
-///
-#define TLS10_PROTOCOL_VERSION_MAJOR  0x03
-#define TLS10_PROTOCOL_VERSION_MINOR  0x01
-#define TLS11_PROTOCOL_VERSION_MAJOR  0x03
-#define TLS11_PROTOCOL_VERSION_MINOR  0x02
-#define TLS12_PROTOCOL_VERSION_MAJOR  0x03
-#define TLS12_PROTOCOL_VERSION_MINOR  0x03
-
-///
-/// TLS Content Type, refers to A.1 of rfc-2246, rfc-4346 and rfc-5246.
-///
-typedef enum {
-  TlsContentTypeChangeCipherSpec = 20,
-  TlsContentTypeAlert= 21,
-  TlsContentTypeHandshake= 22,
-  TlsContentTypeApplicationData  = 23,
-} TLS_CONTENT_TYPE;
-
-///
-/// TLS Record Header, refers to A.1 of rfc-2246, rfc-4346 and rfc-5246.
-///
-typedef struct {   
-  UINT8   ContentType;
-  EFI_TLS_VERSION Version;
-  UINT16  Length;
-} TLS_RECORD_HEADER;
-
-#pragma pack()
-
-#endif
-
+/** @file
+  Transport Layer Security  -- TLS 1.0/1.1/1.2 Standard definitions, from RFC 
2246/4346/5246
+
+  This file contains common TLS 1.0/1.1/1.2 definitions from RFC 2246/4346/5246
+
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the term

[edk2] [PATCH 4/6] SignedCapsulePkg: Convert files to CRLF line ending

2017-04-05 Thread Hao Wu
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 SignedCapsulePkg/Readme.md | 22 ++--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/SignedCapsulePkg/Readme.md b/SignedCapsulePkg/Readme.md
index 67c78edfb4..03358e93ee 100644
--- a/SignedCapsulePkg/Readme.md
+++ b/SignedCapsulePkg/Readme.md
@@ -1,11 +1,11 @@
-# SignedCapsulePkg
-
-This package provides a signed capsule solution in EDKII to support a secure 
capsule update and recovery solution.
-
-Source Repository: 
https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg 
-
-A whitepaper to describe the capsule design: 
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf
-
-Wiki pages to provides more detail on how to enable: 
https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery
-
-
+# SignedCapsulePkg
+
+This package provides a signed capsule solution in EDKII to support a secure 
capsule update and recovery solution.
+
+Source Repository: 
https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg
+
+A whitepaper to describe the capsule design: 
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf
+
+Wiki pages to provides more detail on how to enable: 
https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery
+
+
-- 
2.12.0.windows.1

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


[edk2] [PATCH 0/6] Convert files to CRLF line ending

2017-04-05 Thread Hao Wu
This series converts the following file formats to CRLF line ending:
.c
.h
.inf
.uni
.vfr
.pl


Hao Wu (6):
  CryptoPkg: Convert files to CRLF line ending
  IntelFsp2Pkg: Convert files to CRLF line ending
  IntelFsp2WrapperPkg: Convert files to CRLF line ending
  SignedCapsulePkg: Convert files to CRLF line ending
  MdePkg: Convert files to CRLF line ending
  NetworkPkg: Convert files to CRLF line ending

 CryptoPkg/Include/Library/TlsLib.h  | 1575 -
 CryptoPkg/Library/OpensslLib/process_files.pl   |  447 +--
 CryptoPkg/Library/TlsLib/InternalTlsLib.h   |   85 +-
 CryptoPkg/Library/TlsLib/TlsConfig.c| 2119 ++--
 CryptoPkg/Library/TlsLib/TlsInit.c  |  537 +--
 CryptoPkg/Library/TlsLib/TlsLib.inf |  113 +-
 CryptoPkg/Library/TlsLib/TlsLib.uni |   38 +-
 CryptoPkg/Library/TlsLib/TlsProcess.c   |  925 +++---
 IntelFsp2Pkg/Readme.md  |   14 +-
 IntelFsp2WrapperPkg/Readme.md   |   14 +-
 MdePkg/Include/IndustryStandard/Tls1.h  |  186 +-
 MdePkg/Include/Protocol/Tls.h   |  921 +++---
 MdePkg/Include/Protocol/TlsConfig.h |  265 +-
 MdePkg/Library/BaseLib/SafeString.c |   39 +-
 NetworkPkg/HttpDxe/HttpsSupport.c   | 3439 
++--
 NetworkPkg/HttpDxe/HttpsSupport.h   |  521 +--
 NetworkPkg/Include/Guid/TlsAuthConfigHii.h  |   51 +-
 NetworkPkg/Include/Guid/TlsAuthentication.h |   59 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c  |  270 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf|  147 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.uni|   42 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxeExtra.uni   |   38 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxeStrings.uni |   78 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 3377 
+--
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h |  564 ++--
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigNvData.h   |   99 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigVfr.vfr|  305 +-
 NetworkPkg/TlsDxe/TlsConfigProtocol.c   |  305 +-
 NetworkPkg/TlsDxe/TlsDriver.c   |  993 +++---
 NetworkPkg/TlsDxe/TlsDriver.h   |  475 +--
 NetworkPkg/TlsDxe/TlsDxe.inf|  131 +-
 NetworkPkg/TlsDxe/TlsDxe.uni|   50 +-
 NetworkPkg/TlsDxe/TlsDxeExtra.uni   |   37 +-
 NetworkPkg/TlsDxe/TlsImpl.c |  653 ++--
 NetworkPkg/TlsDxe/TlsImpl.h |  631 ++--
 NetworkPkg/TlsDxe/TlsProtocol.c | 1265 +++
 SignedCapsulePkg/Readme.md  |   22 +-
 37 files changed, 10428 insertions(+), 10402 deletions(-)

-- 
2.12.0.windows.1

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


[edk2] [PATCH 3/6] IntelFsp2WrapperPkg: Convert files to CRLF line ending

2017-04-05 Thread Hao Wu
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 IntelFsp2WrapperPkg/Readme.md | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/IntelFsp2WrapperPkg/Readme.md b/IntelFsp2WrapperPkg/Readme.md
index 0b0f81b033..dfcb4c1a2e 100644
--- a/IntelFsp2WrapperPkg/Readme.md
+++ b/IntelFsp2WrapperPkg/Readme.md
@@ -1,7 +1,7 @@
-# IntelFsp2WrapperPkg
-
-This package provides the component to use an FSP binary.
-
-Source Repository: 
https://github.com/tianocore/edk2/tree/master/IntelFsp2WrapperPkg
-
-A whitepaper to describe the IntelFsp2WrapperPkg: 
https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf
\ No newline at end of file
+# IntelFsp2WrapperPkg
+
+This package provides the component to use an FSP binary.
+
+Source Repository: 
https://github.com/tianocore/edk2/tree/master/IntelFsp2WrapperPkg
+
+A whitepaper to describe the IntelFsp2WrapperPkg: 
https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf
-- 
2.12.0.windows.1

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


[edk2] [PATCH 2/6] IntelFsp2Pkg: Convert files to CRLF line ending

2017-04-05 Thread Hao Wu
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 IntelFsp2Pkg/Readme.md | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/IntelFsp2Pkg/Readme.md b/IntelFsp2Pkg/Readme.md
index 6e38e8ca61..719ce099e4 100644
--- a/IntelFsp2Pkg/Readme.md
+++ b/IntelFsp2Pkg/Readme.md
@@ -1,7 +1,7 @@
-# IntelFsp2Pkg
-
-This package provides the component to create an FSP binary.
-
-Source Repository: https://github.com/tianocore/edk2/tree/master/IntelFsp2Pkg
-
-A whitepaper to describe the IntelFsp2Pkg: 
https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf
\ No newline at end of file
+# IntelFsp2Pkg
+
+This package provides the component to create an FSP binary.
+
+Source Repository: https://github.com/tianocore/edk2/tree/master/IntelFsp2Pkg
+
+A whitepaper to describe the IntelFsp2Pkg: 
https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf
-- 
2.12.0.windows.1

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


Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3 3/3] Fix set variable issue

2017-04-05 Thread Wei, David
Reviewed-by: zwei4 

Thanks,
David  Wei 


-Original Message-
From: Guo, Mang 
Sent: Wednesday, April 05, 2017 2:58 PM
To: edk2-devel@lists.01.org
Cc: Wei, David ; Lu, ShifeiX A 
Subject: [Patch][edk2-platforms/devel-MinnowBoard3 3/3] Fix set variable issue

Change variable attribute to fix variable couldn't be set issue.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Guo Mang 
---
 .../BroxtonPlatformPkg/Common/PlatformSettings/PlatformDxe/Platform.c   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformDxe/Platform.c 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformDxe/Platform.c
index 187eb21..de503a3 100644
--- a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformDxe/Platform.c
+++ b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformDxe/Platform.c
@@ -596,7 +596,7 @@ InitSeC (
   Status = gRT->SetVariable (
   L"Setup",
   &gEfiSetupVariableGuid,
-  EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_NON_VOLATILE,
+  EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS,
   sizeof (SYSTEM_CONFIGURATION),
   &mSystemConfiguration
   );
-- 
2.10.1.windows.1

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


Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3 1/3] Fix get variable issue

2017-04-05 Thread Wei, David
Reviewed-by: zwei4 


Thanks,
David  Wei 

-Original Message-
From: Guo, Mang 
Sent: Wednesday, April 05, 2017 2:57 PM
To: edk2-devel@lists.01.org
Cc: Wei, David ; Lu, ShifeiX A 
Subject: [Patch][edk2-platforms/devel-MinnowBoard3 1/3] Fix get variable issue

Fix "AcpiGlobalVariable" couldn't be get issue. S3 memory info was saved in 
this variable.

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../PlatformPreMemPei/PlatformInitPreMem.c| 15 ---
 .../CseVariableStorageSelectorLib.c   |  9 -
 .../SmmCseVariableStorageSelectorLib.inf  |  4 +++-
 .../PeiCseVariableStorageSelectorLib.c|  8 +++-
 .../PeiCseVariableStorageSelectorLib.inf  |  4 +++-
 5 files changed, 29 insertions(+), 11 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPreMemPei/PlatformInitPreMem.c
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPreMemPei/PlatformInitPreMem.c
index a002bef..854d737 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPreMemPei/PlatformInitPreMem.c
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPreMemPei/PlatformInitPreMem.c
@@ -907,6 +907,7 @@ PlatformInitPreMemEntryPoint (
   #endif
   PEI_BOARD_PRE_MEM_INIT_PPI   *BoardPreMemInitPpi;
   UINTNInstance;
+  UINT64   AcpiVariableSetCompatibility;
 
   Status = (*PeiServices)->RegisterForShadow (FileHandle);
 
@@ -1070,25 +1071,25 @@ PlatformInitPreMemEntryPoint (
   ASSERT_EFI_ERROR (Status);
   return Status;
 }
-
-VariableSize = sizeof (SystemConfiguration);
+ 
+VariableSize = sizeof (AcpiVariableSetCompatibility);
 Status = VariableServices->GetVariable (
  VariableServices,
- PLATFORM_SETUP_VARIABLE_NAME,
- &gEfiSetupVariableGuid,
+ ACPI_GLOBAL_VARIABLE,
+ &gEfiAcpiVariableCompatiblityGuid,
  NULL,
  &VariableSize,
- &SystemConfiguration
+ &AcpiVariableSetCompatibility
  );
 
 AcpiVarHobSize = sizeof (UINT64);
 BuildGuidDataHob (
   &gEfiAcpiVariableCompatiblityGuid,
-  &SystemConfiguration.AcpiVariableSetCompatibility,
+  &AcpiVariableSetCompatibility,
   sizeof (AcpiVarHobSize)
   );
 
-DEBUG ((DEBUG_INFO, "AcpiVariableAddr : 0x%08x\n", 
SystemConfiguration.AcpiVariableSetCompatibility));
+DEBUG ((DEBUG_INFO, "AcpiVariableAddr : 0x%08x\n", 
AcpiVariableSetCompatibility)); 
 
 PERF_START_EX (NULL, "RstVctr", "IBBL", 1, 0x1000);
 Tick = CarMap->IbblPerfRecord0;
diff --git 
a/Silicon/BroxtonSoC/BroxtonSiPkg/Library/Private/DxeSmmCseVariableStorageSelectorLib/CseVariableStorageSelectorLib.c
 
b/Silicon/BroxtonSoC/BroxtonSiPkg/Library/Private/DxeSmmCseVariableStorageSelectorLib/CseVariableStorageSelectorLib.c
index 09e6d68..1087196 100644
--- 
a/Silicon/BroxtonSoC/BroxtonSiPkg/Library/Private/DxeSmmCseVariableStorageSelectorLib/CseVariableStorageSelectorLib.c
+++ 
b/Silicon/BroxtonSoC/BroxtonSiPkg/Library/Private/DxeSmmCseVariableStorageSelectorLib/CseVariableStorageSelectorLib.c
@@ -1,7 +1,7 @@
 /** @file
   DXE SMM CSE Variable Storage Selector Library.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -75,6 +75,13 @@ GetCseVariableStoreFileType (

CseVariableFileTypePreMemoryFile :

CseVariableFileTypePrimaryIndexFile
);
+  } else if ((StrCmp (VariableName, L"AcpiGlobalVariable") == 0) &&
+CompareGuid (VendorGuid, &gEfiAcpiVariableCompatiblityGuid)) {
+DEBUG ((EFI_D_INFO, "CseVariableStorageSelectorLib - Variable is 
AcpiGlobalVariable\n"));
+return (CseVariableFileInfo[CseVariableFileTypePreMemoryFile]->FileEnabled 
?
+   
CseVariableFileTypePreMemoryFile :
+   
CseVariableFileTypePrimaryIndexFile
+   );
   } else {
 //
 // All other variables are stored in individual CSE files
diff --git 
a/Silicon/BroxtonSoC/BroxtonSiPkg/Library/Private/DxeSmmCseVariableStorageSelectorLib/SmmCseVariableStorageSelectorLib.inf
 
b/

Re: [edk2] [Patch] BaseTools: Update tools_def.template to add -fno-builtin in GCC tool chain

2017-04-05 Thread Laszlo Ersek
On 04/06/17 02:45, Liming Gao wrote:
> Now, -fno-builtin option is added for the specific GCC tool chain.
> It is a generic option. It can be moved to common GCC option to keep
> the consistent compiler option.
> 
> Cc: Ard Biesheuvel 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Signed-off-by: Laszlo Ersek 

Please don't add "Signed-off-by" tags for other people. That tag should
only come from people with actual authorship on the patch.

Instead, in this case,

Suggested-by: Laszlo Ersek 

would be appropriate (and welcome too :) ).

I'll check this patch in more detail later.

Thanks,
Laszlo

> ---
>  BaseTools/Conf/tools_def.template | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 2c5cd58089..14ecfedab1 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4335,13 +4335,13 @@ DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
> --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_N
>  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
>  NOOPT_*_*_OBJCOPY_ADDDEBUGFLAG = 
> --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>  
> -DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h 
> -fno-common
> +DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-builtin 
> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h 
> -fno-common
>  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
> -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
> -mno-stack-arg-probe
>  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
> -Wno-address -mno-stack-arg-probe
>  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> -minline-int-divide-min-latency
> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb 
> -mfloat-abi=soft
> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
>  DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access
> -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
> -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables 
> -fno-pic
> +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
> -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic
>  DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
>  DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
>  DEFINE GCC_DLINK2_FLAGS_COMMON = 
> -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
> @@ -4368,7 +4368,7 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
> elf64-ia64-little   -B ia64
>  DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm 
> --rename-section .data=.hii
>  DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
> aarch64 --rename-section .data=.hii
>  
> -DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
> -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include 
> AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> +DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-builtin 
> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections 
> -fdata-sections -include AutoGen.h -fno-common 
> -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>  DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
> -march=i586 -malign-double -fno-stack-protector -D EFI32 
> -fno-asynchronous-unwind-tables
>  DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
> -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" 
> -maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie 
> -fno-asynchronous-unwind-tables
>  DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
> common-page-size=0x20
> @@ -4471,8 +4471,8 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS= 
> DEF(GCC48_AARCH64_DLINK2_FLAGS)
>  DEFINE GCC49_ARM_ASLDLINK_FLAGS  = DEF(GCC48_ARM_ASLDLINK_FLAGS)
>  DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>  
> -DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-builtin
> -DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -fno-builtin
> +DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
> +DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
>  DEFINE GCC5_IA3

Re: [edk2] [patch] UefiCpuPkg: Fix typos in UefiCpuPkg.dec

2017-04-05 Thread Fan, Jeff
Reviewed-by: Jeff Fan 

Thanks!

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan Bi
Sent: Thursday, April 06, 2017 8:53 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff
Subject: [edk2] [patch] UefiCpuPkg: Fix typos in UefiCpuPkg.dec

Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 UefiCpuPkg/UefiCpuPkg.dec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index 
e87f103..6f30ad0 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -30,11 +30,11 @@
   UefiCpuLib|Include/Library/UefiCpuLib.h
 
   ##  @libraryclass  Defines some routines that are used to 
register/manage/program
   ## CPU features.
   ##
-  UefiCpuLib|Include/Library/RegisterCpuFeaturesLib.h
+  RegisterCpuFeaturesLib|Include/Library/RegisterCpuFeaturesLib.h
 
 [LibraryClasses.IA32, LibraryClasses.X64]
   ##  @libraryclass  Provides functions to manage MTRR settings on IA32 and 
X64 CPUs.
   ##
   MtrrLib|Include/Library/MtrrLib.h
--
1.9.5.msysgit.1

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


[edk2] [patch] UefiCpuPkg: Fix typos in UefiCpuPkg.dec

2017-04-05 Thread Dandan Bi
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 UefiCpuPkg/UefiCpuPkg.dec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index e87f103..6f30ad0 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -30,11 +30,11 @@
   UefiCpuLib|Include/Library/UefiCpuLib.h
 
   ##  @libraryclass  Defines some routines that are used to 
register/manage/program
   ## CPU features.
   ##
-  UefiCpuLib|Include/Library/RegisterCpuFeaturesLib.h
+  RegisterCpuFeaturesLib|Include/Library/RegisterCpuFeaturesLib.h
 
 [LibraryClasses.IA32, LibraryClasses.X64]
   ##  @libraryclass  Provides functions to manage MTRR settings on IA32 and 
X64 CPUs.
   ##
   MtrrLib|Include/Library/MtrrLib.h
-- 
1.9.5.msysgit.1

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


Re: [edk2] [Patch] BaseTools: update error message for SKUID_IDENTIFIER format

2017-04-05 Thread Gao, Liming
Reviewed-by: Liming Gao 

> -Original Message-
> From: Zhu, Yonghong
> Sent: Saturday, April 1, 2017 1:59 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [Patch] BaseTools: update error message for SKUID_IDENTIFIER format
> 
> Per DSC spec, the SkuUiName use '|' as separator, so this patch update
> the error message to use '|' but not space as separator.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/Common/Misc.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Common/Misc.py 
> b/BaseTools/Source/Python/Common/Misc.py
> index 1a5968a..390ef36 100644
> --- a/BaseTools/Source/Python/Common/Misc.py
> +++ b/BaseTools/Source/Python/Common/Misc.py
> @@ -2004,21 +2004,21 @@ class SkuClass():
>  try:
>  self.SkuIdNumberSet = [SkuIds[k].strip() + 'U' for k in 
> self.SkuIdSet]
>  except Exception:
>  EdkLogger.error("build", PARAMETER_INVALID,
>  ExtraData = "SKU-ID [%s] is not supported by the 
> platform. [Valid SKU-ID: %s]"
> -  % (k, " ".join(SkuIds.keys(
> +  % (k, " | ".join(SkuIds.keys(
>  if len(self.SkuIdSet) == 2 and 'DEFAULT' in self.SkuIdSet and 
> SkuIdentifier != 'ALL':
>  self.SkuIdSet.remove('DEFAULT')
>  self.SkuIdNumberSet.remove('0U')
>  for each in self.SkuIdSet:
>  if each in SkuIds:
>  self.AvailableSkuIds[each] = SkuIds[each]
>  else:
>  EdkLogger.error("build", PARAMETER_INVALID,
>  ExtraData="SKU-ID [%s] is not supported by the 
> platform. [Valid SKU-ID: %s]"
> -  % (each, " ".join(SkuIds.keys(
> +  % (each, " | ".join(SkuIds.keys(
> 
>  def __SkuUsageType(self):
> 
>  if len(self.SkuIdSet) == 1:
>  if self.SkuIdSet[0] == 'DEFAULT':
> --
> 2.6.1.windows.1

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


Re: [edk2] [PATCH v5] MdePkg: BaseIoLibIntrinsic (IoLib class) library

2017-04-05 Thread Gao, Liming
Leo:
  Seemly, this patch doesn't include new INF file. Could you create it again?

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leo 
> Duran
> Sent: Wednesday, April 5, 2017 9:20 PM
> To: edk2-de...@ml01.01.org
> Cc: Kinney, Michael D ; Brijesh Singh 
> ; Leo Duran ; Gao,
> Liming 
> Subject: [edk2] [PATCH v5] MdePkg: BaseIoLibIntrinsic (IoLib class) library
> 
> This patch adds an SEV-specific .INF and corresponding assembly
> files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
> when the SEV feature is enabled under a hypervisor environment.
> 
> The new .INF only supports the IA32 and X64 architectures.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Leo Duran 
> ---
>  .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293 
> +
>  .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282 
>  MdePkg/MdePkg.dsc  |   2 +
>  3 files changed, 577 insertions(+)
>  create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
>  create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm 
> b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> new file mode 100644
> index 000..9adb972
> --- /dev/null
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> @@ -0,0 +1,293 @@
> +;--
> +;
> +; Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
> +; Copyright (c) 2017, AMD Incorporated. 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.
> +;
> +;--
> +
> +SECTION .text
> +
> +;--
> +; Check whether we need to unroll the String I/O under SEV guest
> +;
> +; Return // eax   (1 - unroll, 0 - no unroll)
> +;--
> +global ASM_PFX(SevNoRepIo)
> +ASM_PFX(SevNoRepIo):
> +
> +  ; CPUID clobbers ebx, ecx and edx
> +  push  ebx
> +  push  ecx
> +  push  edx
> +
> +  ; Check if we are running under hypervisor
> +  ; CPUID(1).ECX Bit 31
> +  mov   eax, 1
> +  cpuid
> +  btecx, 31
> +  jnc   @UseRepIo
> +
> +  ; Check if we have Memory encryption CPUID leaf
> +  mov   eax, 0x8000
> +  cpuid
> +  cmp   eax, 0x801f
> +  jl@UseRepIo
> +
> +  ; Check for memory encryption feature:
> +  ;  CPUID  Fn8000_001F[EAX] - Bit 1
> +  ;
> +  mov   eax,  0x801f
> +  cpuid
> +  bteax, 1
> +  jnc   @UseRepIo
> +
> +  ; Check if memory encryption is enabled
> +  ;  MSR_0xC0010131 - Bit 0 (SEV enabled)
> +  ;  MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
> +  mov   ecx, 0xc0010131
> +  rdmsr
> +
> +  ; Check for (SevEsEnabled == 0 && SevEnabled == 1)
> +  and   eax, 3
> +  cmp   eax, 1
> +  je@SevNoRepIo_Done
> +
> +@UseRepIo:
> +  xor   eax, eax
> +
> +@SevNoRepIo_Done:
> +  pop   edx
> +  pop   ecx
> +  pop   ebx
> +  ret
> +
> +;--
> +;  VOID
> +;  EFIAPI
> +;  IoReadFifo8 (
> +;IN  UINTN Port,
> +;IN  UINTN Size,
> +;OUT VOID  *Buffer
> +;);
> +;--
> +global ASM_PFX(IoReadFifo8)
> +ASM_PFX(IoReadFifo8):
> +pushedi
> +mov dx, [esp + 8]
> +mov ecx, [esp + 12]
> +mov edi, [esp + 16]
> +
> +callSevNoRepIo; Check if we need to unroll the rep
> +testeax, eax
> +jnz @IoReadFifo8_NoRep
> +
> +cld
> +rep insb
> +jmp @IoReadFifo8_Done
> +
> +@IoReadFifo8_NoRep:
> +jecxz   @IoReadFifo8_Done
> +
> +@IoReadFifo8_Loop:
> +in  al, dx
> +mov byte [edi], al
> +inc edi
> +loop@IoReadFifo8_Loop
> +
> +@IoReadFifo8_Done:
> +pop edi
> +ret
> +
> +;--
> +;  VOID
> +;  EFIAPI
> +;  IoReadFifo16 (
> +;IN  UINTN Port,
> +;IN  UINTN Size,
> +;OUT VOID  *Buffer
> +;);
> +;--

Re: [edk2] [Patch] MdeModulePkg: Remove unsupported PcdExpression usage in module INF

2017-04-05 Thread Zeng, Star
Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: Gao, Liming 
Sent: Friday, March 31, 2017 1:04 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star 
Subject: [Patch] MdeModulePkg: Remove unsupported PcdExpression usage in module 
INF

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

PcdExpression used in INF to control PCD and Source is unsupported feature.
Current sample usage in module INF brings confuse.

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Application/HelloWorld/HelloWorld.inf   |  6 +++---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  | 12 ++--
 .../Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf|  4 ++--
 MdeModulePkg/Universal/PCD/Pei/Pcd.inf   |  4 ++--
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Application/HelloWorld/HelloWorld.inf 
b/MdeModulePkg/Application/HelloWorld/HelloWorld.inf
index 2240e17..1cfed2d 100644
--- a/MdeModulePkg/Application/HelloWorld/HelloWorld.inf
+++ b/MdeModulePkg/Application/HelloWorld/HelloWorld.inf
@@ -6,7 +6,7 @@
 #
 #  It demos how to use EDKII PCD mechanism to make code more flexible.
 #
-#  Copyright (c) 2008 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2008 - 2017, Intel Corporation. All rights 
+reserved.
 #
 #  This program and the accompanying materials  #  are licensed and made 
available under the terms and conditions of the BSD License @@ -55,8 +55,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintEnable   ## CONSUMES
 
 [Pcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintString || 
gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintEnable## SOMETIMES_CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintTimes  || 
gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintEnable## SOMETIMES_CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintString   ## 
SOMETIMES_CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldPrintTimes## 
SOMETIMES_CONSUMES
 
 [UserExtensions.TianoCore."ExtraFiles"]
   HelloWorldExtra.uni
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index d62bd9b..c54afe4 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -5,7 +5,7 @@
 #  PPI to discover and dispatch the DXE Foundation and components that are  #  
needed to run the DXE Foundation.
 #
-#  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2017, Intel Corporation. All rights 
+reserved.
 #  Copyright (c) 2017, AMD Incorporated. All rights reserved.  #  #  This 
program and the accompanying materials @@ -39,12 +39,12 @@
   DxeLoad.c
 
 [Sources.Ia32]
-  X64/VirtualMemory.h  
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
-  X64/VirtualMemory.c  
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
+  X64/VirtualMemory.h
+  X64/VirtualMemory.c
   Ia32/DxeLoadFunc.c
-  
Ia32/IdtVectorAsm.nasmgEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
-  
Ia32/IdtVectorAsm.asmgEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
-  Ia32/IdtVectorAsm.S  
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
+  Ia32/IdtVectorAsm.nasm
+  Ia32/IdtVectorAsm.asm
+  Ia32/IdtVectorAsm.S
 
 [Sources.X64]
   X64/VirtualMemory.h
diff --git a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf 
b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
index 7a7a3e3..9ab04ce 100644
--- a/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -4,7 +4,7 @@
 #  It installs the Capsule Architectural Protocol defined in PI1.0a to signify 
 #  the capsule runtime services are ready.
 #
-#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2017, Intel Corporation. All rights 
+reserved.
 #  This program and the accompanying materials  #  are licensed and made 
available under the terms and conditions of the BSD License  #  which 
accompanies this distribution.  The full text of the license may be found at @@ 
-81,7 +81,7 @@
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule   ## 
SOMETIMES_CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule || 
gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleReset ## 
SOMETIMES_CONSUMES # Populate Image requires reset support.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule  ## 
SOMETIMES_CONSUMES # Populate Image requires reset support.
 
 [Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdCapsulePeiLongModeStackSize   ## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Universal/PCD/Pei/Pcd.inf 
b/MdeModulePkg/Universal/PCD/Pei/Pcd.inf
index 0645f91..1d9c924 100644
--- a/MdeModulePkg/Universal/PCD/Pei/Pcd.inf
+++ b/MdeModulePkg/Univers

[edk2] [Patch] BaseTools: Update tools_def.template to add -fno-builtin in GCC tool chain

2017-04-05 Thread Liming Gao
Now, -fno-builtin option is added for the specific GCC tool chain.
It is a generic option. It can be moved to common GCC option to keep
the consistent compiler option.

Cc: Ard Biesheuvel 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Signed-off-by: Laszlo Ersek 
---
 BaseTools/Conf/tools_def.template | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2c5cd58089..14ecfedab1 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4335,13 +4335,13 @@ DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_N
 RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
 NOOPT_*_*_OBJCOPY_ADDDEBUGFLAG = 
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
 
-DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-common
+DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-builtin 
-fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h 
-fno-common
 DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double 
-freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe
 DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
-Wno-address -mno-stack-arg-probe
 DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
-minline-int-divide-min-latency
-DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb 
-mfloat-abi=soft
+DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
-fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
 DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access
-DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables 
-fno-pic
+DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic
 DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
 DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON = 
-Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
@@ -4368,7 +4368,7 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O 
elf64-ia64-little   -B ia64
 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm   
  --rename-section .data=.hii
 DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B 
aarch64 --rename-section .data=.hii
 
-DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include 
AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
+DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-builtin 
-fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections 
-fdata-sections -include AutoGen.h -fno-common 
-DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-march=i586 -malign-double -fno-stack-protector -D EFI32 
-fno-asynchronous-unwind-tables
 DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" 
-maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie 
-fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
common-page-size=0x20
@@ -4471,8 +4471,8 @@ DEFINE GCC49_AARCH64_DLINK2_FLAGS= 
DEF(GCC48_AARCH64_DLINK2_FLAGS)
 DEFINE GCC49_ARM_ASLDLINK_FLAGS  = DEF(GCC48_ARM_ASLDLINK_FLAGS)
 DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
 
-DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-builtin
-DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -fno-builtin
+DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
+DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
 DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
 DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
 DEFINE GCC5_IA32_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS)
@@ -5512,7 +5512,7 @@ DEFINE CLANG38_X64_PREFIX   = ENV(CLANG38_BIN)
 DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
 DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
 
-DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body 
-fno-stack-pro

[edk2] [edk2-FdfSpecification Patch] FILE RAW Multiple binaries and FmpPayload extensions

2017-04-05 Thread Michael Kinney
* Changed the FDF_SPECIFICATION value from 0x0001001A to
  0x0001001B or 1.27
* Extended the FV and Capsule, FILE RAW statement formats to
  support multiple binary files.
* Changed section 3.8 [FmpPayload] to add definitions for
  MONOTONIC_COUNT and CERTIFICATE_GUID, plus some notes about
  how these are used.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_fdf_design_discussion/README.md|  8 
 3_edk_ii_fdf_file_format/34_[defines]_section.md | 17 +
 3_edk_ii_fdf_file_format/36_[fv]_sections.md | 16 ++--
 3_edk_ii_fdf_file_format/37_[capsule]_sections.md|  5 +++--
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 10 ++
 README.md|  5 -
 6 files changed, 44 insertions(+), 17 deletions(-)

diff --git a/2_fdf_design_discussion/README.md 
b/2_fdf_design_discussion/README.md
index 37e37c7..3202f56 100644
--- a/2_fdf_design_discussion/README.md
+++ b/2_fdf_design_discussion/README.md
@@ -50,10 +50,10 @@ The EDK II Build generates UEFI and PI specification 
compliant binary images.
 The tools provided in the EDK and the EdkCompatibilityPkg module support
 earlier versions of the specifications.
 
-This revision of the specification adds support for multiple EDK II Packages
-directories outside of the WORKSPACE. FDF files that use this feature must
-use the new `FDF_SPECIFICATION = 0x00010019` in the `[Defines]` section. Older
-FDF files do not need to update the `FDF_SPECIFICATION` value.
+This revision of the specification adds support for multiple binary files in
+an FV FILE RAW statement. FDF files that use this feature must use the new
+`FDF_SPECIFICATION = 0x0001001B` in the `[Defines]` section. Older FDF files
+do not need to update the `FDF_SPECIFICATION` value.
 
 The EDK II build system has been updated to allow the setting of multiple paths
 that will be searched when attempting to resolve the location of EDK II
diff --git a/3_edk_ii_fdf_file_format/34_[defines]_section.md 
b/3_edk_ii_fdf_file_format/34_[defines]_section.md
index 789f114..eec7698 100644
--- a/3_edk_ii_fdf_file_format/34_[defines]_section.md
+++ b/3_edk_ii_fdf_file_format/34_[defines]_section.md
@@ -40,14 +40,15 @@ This section describes the defines section content in the 
FDF files. This file
 can be created by a developer and is an input to the EDK II build tool parsing
 utilities. Elements may appear in any order within this section.
 
-The code for this version of the FDF specification is "0x0001001A" and new
-versions of this specification must increment the minor (001A) portion of the
-specification code for backward compatible changes, and increment the major
-number for non-backward compatible specification changes.
-
-This revision of the specification adds FMP Capsule support. Any FDF file that
-uses this feature must use the 0x0001001A FDF_SPECIFICATION value. Older FDF
-files that do not use this feature do not need to update the value.
+The code for this version of the FDF specification is "0x0001001B". New
+versions of this specification must increment the minor (001B) portion of the
+specification code for backward-compatible changes, and increment the major
+specification number for non-backward-compatible changes.
+
+This revision of the specification adds support for multiple binaries in an
+FV or Capsule RAW FILE statement. Any FDF file that uses this feature must use
+the value `0x0001001B` in the `FDF_SPECIFICATION` statement. Older FDF files
+that do not use this feature do not need to update the value.
 
 Conditional statements may be used anywhere within this section.
 
diff --git a/3_edk_ii_fdf_file_format/36_[fv]_sections.md 
b/3_edk_ii_fdf_file_format/36_[fv]_sections.md
index b80f6be..f2d34cf 100644
--- a/3_edk_ii_fdf_file_format/36_[fv]_sections.md
+++ b/3_edk_ii_fdf_file_format/36_[fv]_sections.md
@@ -157,11 +157,13 @@ Conditional statements may be used anywhere within this 
section.
 {} {}   "}" []
   ::= [] [] 
 "{" []
-{} {}  "}" []
+ {} {+} { }
+"}" 
+  ::=  []  
   ::= ["FIXED" ] ["CHECKSUM" ]
 []
   ::= "Align"   
-  ::= {} {} {}
+  ::=  {} {} {} 
::=  "FV"   
::=  "FD"   
   ::= {} {"common"}
@@ -415,4 +417,14 @@ INF $(SAMPLE)/Universal/Network/Tcp4/Dxe/Tcp4.inf
 INF $(SAMPLE)/Universal/Network/Dhcp4/Dxe/Dhcp4.inf
 INF $(SAMPLE)/Universal/Network/Mtftp4/Dxe/Mtftp4.inf
 INF $(SAMPLE)/Universal/Network/SnpNt32/Dxe/SnpNt32.inf
+
+FILE RAW = 197DB236-F856-4924-90F8-CDF12FB975F3 {
+  $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/$PLATFORM_ARCH)/File.bin
+}
+
+FILE RAW = 197DB236-F856-4924-90F8-CDF12FB975F3 {
+  Align=16 $(PLATFORM_PACKAGE)/Binaries/File1.pdb

[edk2] [edk2-FdfSpecification Patch] FILE RAW Multiple binaries and FmpPayload extensions

2017-04-05 Thread Michael Kinney
* Changed the FDF_SPECIFICATION value from 0x0001001A to
  0x0001001B or 1.27
* Extended the FV and Capsule, FILE RAW statement formats to
  support multiple binary files.
* Changed section 3.8 [FmpPayload] to add definitions for
  MONOTONIC_COUNT and CERTIFICATE_GUID, plus some notes about
  how these are used.

The document changes in this patch are in Gitbook format and are equivalent to
the changes in the EDK II FDF File Spec v1.27 DRAFT for Review that was posted
as a PDF with change bars on the tianocore site in September 2016.

  
https://github.com/tianocore-docs/Docs/raw/master/Specifications/FDF_Spec_1_27_Review_Draft.pdf

These same document changes are also availabe in the following GIT branch:
  
  https://github.com/mdkinney/edk2-FdfSpecification/tree/FileRawMultipleBinary

The content difference between the latest DRAFT and this change can be 
viewed at the following link.  The ?w=1 performs a word diff and ignores
white space changes.
  
  
https://github.com/tianocore-docs/edk2-FdfSpecification/compare/master...mdkinney:FileRawMultipleBinary?w=1
  
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  FILE RAW Multiple binaries and FmpPayload extensions

 2_fdf_design_discussion/README.md|  8 
 3_edk_ii_fdf_file_format/34_[defines]_section.md | 17 +
 3_edk_ii_fdf_file_format/36_[fv]_sections.md | 16 ++--
 3_edk_ii_fdf_file_format/37_[capsule]_sections.md|  5 +++--
 3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md | 10 ++
 README.md|  5 -
 6 files changed, 44 insertions(+), 17 deletions(-)

-- 
2.6.3.windows.1

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


Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 22:28, Jeremy Linton  wrote:
> Hi,
>
>
> On 04/05/2017 03:34 PM, Ard Biesheuvel wrote:
>>
>> On 5 April 2017 at 21:12, Jeremy Linton  wrote:
>>>
>>> Hi,
>>>
>>> On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:


 The new accelerated ARM and AARCH64 implementations take advantage of
 features that are only available when the MMU and Dcache are on. So
 restrict the use of this library to the DXE phase or later.
>>>
>>>
>>>
>>> I don't think this is sufficient because DC ZVA doesn't work against
>>> device
>>> memory/etc. That means that users have to somehow know the page/etc
>>> attributes of memory regions before they call SetMemXX() on them.
>>>
>>
>> Yes. I literally found this out myself yesterday. Note that this
>> applies equally to unaligned accesses.
>>
>>
>>> I think this is a problem because nowhere in the UEFI specs do I see such
>>> restrictions on those memory operations.
>>>
>>
>> Using device attributes for memory is something we should ban for
>> AArch64 in the spec.
>>
>>> For a specific problematic example, the LcdGraphicsOutputBlt.c uses it
>>> for
>>> BltVideoFill() and the target of that is likely not regular cached video
>>> memory.
>>>
>>
>> Those drivers should be using EFI_MEMORY_WC not EFI_MEMORY_UC for the
>> VRAM mapping. Note that EFI_MEMORY_UC is nGnRnE which is unnecessarily
>> restrictive.
>>
>> I agree there is a general issue here which we should address by
>> tightening the spec. I don't see a lot of value in avoiding DC ZVA and
>> unaligned accesses altogether, I'd rather fix the code instead.
>
>
>
> While I agree with the general sentiment, I find the result brittle. If it
> were used as a DEBUG build way to locate sub-optmimal code I would be more
> on board. But shipping it like this, puts it into situations where the user
> inadvertently changes something (say making the background black and
> therefore triggering the DC) or some obscure option ROM (we will get there
> right??!!) triggers it in a place where it can't be debugged.
>
> Particularly since we are talking boot, where the few percent perf
> improvement on this operation is likely completely undetectable. The one
> place where I can think it might even be measurable is in routines to clear
> system memory, and those routines could be a special case anyway.
>

I guess this depends on the use case. For server, it may not matter,
but the case is different for mobile, and the Broadcom engineers that
did some benchmarks on this code were very pleased with the result
(and the speedup was significant, although I don't know which routines
are the hotspots)

As for option ROMs: those will link to their own BaseMemoryLib
implementation (assuming that they are EDK2 based) so the only way
they would have access to these routines is via the CopyMem() and
SetMem() boot services. Note that that does not dismiss the concern at
all, it is just a clarification.

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


Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

2017-04-05 Thread Jeremy Linton

Hi,

On 04/05/2017 03:34 PM, Ard Biesheuvel wrote:

On 5 April 2017 at 21:12, Jeremy Linton  wrote:

Hi,

On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:


The new accelerated ARM and AARCH64 implementations take advantage of
features that are only available when the MMU and Dcache are on. So
restrict the use of this library to the DXE phase or later.



I don't think this is sufficient because DC ZVA doesn't work against device
memory/etc. That means that users have to somehow know the page/etc
attributes of memory regions before they call SetMemXX() on them.



Yes. I literally found this out myself yesterday. Note that this
applies equally to unaligned accesses.



I think this is a problem because nowhere in the UEFI specs do I see such
restrictions on those memory operations.



Using device attributes for memory is something we should ban for
AArch64 in the spec.


For a specific problematic example, the LcdGraphicsOutputBlt.c uses it for
BltVideoFill() and the target of that is likely not regular cached video
memory.



Those drivers should be using EFI_MEMORY_WC not EFI_MEMORY_UC for the
VRAM mapping. Note that EFI_MEMORY_UC is nGnRnE which is unnecessarily
restrictive.

I agree there is a general issue here which we should address by
tightening the spec. I don't see a lot of value in avoiding DC ZVA and
unaligned accesses altogether, I'd rather fix the code instead.



While I agree with the general sentiment, I find the result brittle. If 
it were used as a DEBUG build way to locate sub-optmimal code I would be 
more on board. But shipping it like this, puts it into situations where 
the user inadvertently changes something (say making the background 
black and therefore triggering the DC) or some obscure option ROM (we 
will get there right??!!) triggers it in a place where it can't be 
debugged.


Particularly since we are talking boot, where the few percent perf 
improvement on this operation is likely completely undetectable. The one 
place where I can think it might even be measurable is in routines to 
clear system memory, and those routines could be a special case anyway.



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


[edk2] [PATCH 1/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

2017-04-05 Thread Ard Biesheuvel
Replace the uncached memory mapping of the framebuffer with a write-
combining one. This improves performance, and avoids issues with
unaligned accesses and DC ZVA instructions performed by the accelerated
memcpy/memset routines.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c | 
2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index a57846715ed7..d6d47545c824 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -143,7 +143,7 @@ LcdPlatformGetVram (
   ASSERT_EFI_ERROR(Status);
 
   // Mark the VRAM as un-cacheable. The VRAM is inside the DRAM, which is 
cacheable.
-  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_UC);
+  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_WC);
   ASSERT_EFI_ERROR(Status);
   if (EFI_ERROR(Status)) {
 gBS->FreePool (VramBaseAddress);
-- 
2.7.4

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


[edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

2017-04-05 Thread Ard Biesheuvel
Replace the uncached memory mapping of the framebuffer with a write-
combining one. This improves performance, and avoids issues with
unaligned accesses and DC ZVA instructions performed by the accelerated
memcpy/memset routines.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index 2000c9bdf436..d18d6b3e1665 100644
--- 
a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -192,7 +192,7 @@ LcdPlatformGetVram (
 ASSERT_EFI_ERROR(Status);
 
 // Mark the VRAM as un-cachable. The VRAM is inside the DRAM, which is 
cachable.
-Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_UC);
+Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
EFI_MEMORY_WC);
 ASSERT_EFI_ERROR(Status);
 if (EFI_ERROR(Status)) {
   gBS->FreePool(VramBaseAddress);
-- 
2.7.4

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


Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 21:12, Jeremy Linton  wrote:
> Hi,
>
> On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:
>>
>> The new accelerated ARM and AARCH64 implementations take advantage of
>> features that are only available when the MMU and Dcache are on. So
>> restrict the use of this library to the DXE phase or later.
>
>
> I don't think this is sufficient because DC ZVA doesn't work against device
> memory/etc. That means that users have to somehow know the page/etc
> attributes of memory regions before they call SetMemXX() on them.
>

Yes. I literally found this out myself yesterday. Note that this
applies equally to unaligned accesses.


> I think this is a problem because nowhere in the UEFI specs do I see such
> restrictions on those memory operations.
>

Using device attributes for memory is something we should ban for
AArch64 in the spec.

> For a specific problematic example, the LcdGraphicsOutputBlt.c uses it for
> BltVideoFill() and the target of that is likely not regular cached video
> memory.
>

Those drivers should be using EFI_MEMORY_WC not EFI_MEMORY_UC for the
VRAM mapping. Note that EFI_MEMORY_UC is nGnRnE which is unnecessarily
restrictive.

I agree there is a general issue here which we should address by
tightening the spec. I don't see a lot of value in avoiding DC ZVA and
unaligned accesses altogether, I'd rather fix the code instead.

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


Re: [edk2] [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases

2017-04-05 Thread Jeremy Linton

Hi,

On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:

The new accelerated ARM and AARCH64 implementations take advantage of
features that are only available when the MMU and Dcache are on. So
restrict the use of this library to the DXE phase or later.


I don't think this is sufficient because DC ZVA doesn't work against 
device memory/etc. That means that users have to somehow know the 
page/etc attributes of memory regions before they call SetMemXX() on them.


I think this is a problem because nowhere in the UEFI specs do I see 
such restrictions on those memory operations.


For a specific problematic example, the LcdGraphicsOutputBlt.c uses it 
for BltVideoFill() and the target of that is likely not regular cached 
video memory.






Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf 
b/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
index 64d11b09ef06..5ddc0cbc2d77 100644
--- a/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
+++ b/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
@@ -116,6 +116,15 @@ [Sources.X64]
   X64/CopyMem.S
   X64/IsZeroBuffer.nasm

+[Defines.ARM, Defines.AARCH64]
+  #
+  # The ARM implementations of this library may perform unaligned accesses, and
+  # may use DC ZVA instructions that are only allowed when the MMU and D-cache
+  # are on. Since SEC, PEI_CORE and PEIM modules may execute with the MMU off,
+  # omit them from the supported module types list for this library.
+  #
+  LIBRARY_CLASS = BaseMemoryLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER 
UEFI_DRIVER UEFI_APPLICATION
+
 [Sources.ARM]
   Arm/ScanMem.S   |GCC
   Arm/SetMem.S|GCC



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


Re: [edk2] [PATCH v4 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Jordan Justen
On 2017-04-05 06:58:33, Laszlo Ersek wrote:
> 
> This is #2.
> 
> Which one do you want to keep? I think we should drop #1, and keep #2.
> 
> Do you wish to submit v5, or are you okay if I remove #1 for you at
> commit time?
> 
> With this tweak,
> 
> Reviewed-by: Laszlo Ersek 
> 
> Before committing, I would like to give Jordan a chance to comment as
> well. I think Friday this week should be a good day to commit the series.

After convincing myself that, yes, the unaligned i/o was *actually*
required. :) / :(

Series Reviewed-by: Jordan Justen 

The one comment I had, is given how verbose the 3 inline assembly
source files are in patch 2, maybe nasm code would actually be cleaner
looking. But, considering we'd need both an IA32 and X64 version, it
isn't much better.

> Impressive work!

Agreed. Thanks for your contribution Phil!

-Jordan

> 
> > +  ModeInfo->PixelsPerScanLine = BytesPerLine / (BitsPerPixel / 8);
> > +
> > +  ModeData++;
> > +  ModeInfo++;
> > +}
> > +VideoMode++;
> > +  }
> > +  Private->MaxMode = ModeData - Private->ModeData;
> > +  return EFI_SUCCESS;
> > +
> > +Rollback:
> > +  FreePool (Private->VmwareSvgaModeInfo);
> > +  Private->VmwareSvgaModeInfo = NULL;
> > +
> > +ModeInfoAllocError:
> > +  FreePool (Private->ModeData);
> > +  Private->ModeData = NULL;
> > +
> > +ModeDataAllocError:
> > +  return Status;
> > +}
> > 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

2017-04-05 Thread Tim Lewis
There are "load options" that are passed to drivers (as a part of the 
EFI_LOADED_IMAGE_PROTOCOL), but there is no guarantee as to their format 
(binary data or ASCII string or UCS-2 string). It is possible for "load" to be 
modified to create this data and populate it between the calls to LoadImage() 
and StartImage() as the shell does, but that isn't spec.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
jim.dai...@dell.com
Sent: Wednesday, April 05, 2017 8:21 AM
To: jaben.car...@intel.com; ruiyu...@intel.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

Thanks, Jaben. That makes sense.

Now I see the real issue is with the "app" I ran across.  It is a driver, and 
it was trying to access command line args.  The driver crashed when it tried to 
access the command line, but it had been loaded in memory via the "load" 
command.

So, it seems "load" has no mechanism to pass command line arguments to a 
driver, and as a result, it apparently doesn't load the shell parameters 
protocol on the driver's handle, which caused the crash.

Regards,
Jim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, April 5, 2017 10:08 AM
To: Dailey, Jim ; Ni, Ruiyu 
Cc: edk2-devel@lists.01.org
Subject: RE: UEFI Shell Lib Constructor and Shell Parameters Protocol

Jim,

That protocol must be installed on your applications own image handle for it to 
be valid.  Locating the protocol on some other image would result with finding 
the other image's command line parameters and the like...

-Jaben


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> jim.dai...@dell.com
> Sent: Wednesday, April 05, 2017 7:07 AM
> To: Carsey, Jaben ; Ni, Ruiyu 
> 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters 
> Protocol
> Importance: High
> 
> 
> A question or two for all shell experts:
> 
> In the UEFI Shell Lib constructor code, if the Shell protocol cannot 
> be opened, then an attempt is made to locate it before "giving up".
> 
> However, if the Shell parameters protocol cannot be opened, no attempt 
> is made to locate it---the code simply leaves the parameters protocol 
> pointer set to NULL. Can anyone explain why this is?
> 
> I came across an app that crashes because of this behavior, but if I 
> add code to try and locate the parameters protocol, then the app works 
> as designed WRT accessing command line parameters.  Is there some 
> lurking issue if an attempt to locate the parameters protocol is made 
> and is successful?
> 
> Thanks,
> Jim
> 
> ---
> Here is the relevant code:
> 
> EFI_STATUS
> ShellLibConstructorWorker (
>   IN EFI_HANDLEImageHandle,
>   IN EFI_SYSTEM_TABLE  *SystemTable
>   )
> {
>   EFI_STATUS  Status;
> 
>   //
>   // UEFI 2.0 shell interfaces (used preferentially)
>   //
>   Status = gBS->OpenProtocol(
> ImageHandle,
> &gEfiShellProtocolGuid,
> (VOID **)&gEfiShellProtocol,
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> //
> // Search for the shell protocol
> //
> Status = gBS->LocateProtocol(
>   &gEfiShellProtocolGuid,
>   NULL,
>   (VOID **)&gEfiShellProtocol
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellProtocol = NULL;
> }
>   }
>   Status = gBS->OpenProtocol(
> ImageHandle,
> &gEfiShellParametersProtocolGuid,
> (VOID **)&gEfiShellParametersProtocol,
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> #if 1 // _Dell_ : Search for the parameters protocol too!
> //
> // Search for the shell parameters protocol
> //
> Status = gBS->LocateProtocol(
>   &gEfiShellParametersProtocolGuid,
>   NULL,
>   (VOID **)&gEfiShellParametersProtocol
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellParametersProtocol = NULL;
> }
> #else
> gEfiShellParametersProtocol = NULL; #endif
>   }
> ...
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

2017-04-05 Thread Carsey, Jaben
Glad to help.  

I do not think that UEFI drivers really have the concept of command line 
parameters... they use other methods for configuration...

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jim.dai...@dell.com
> Sent: Wednesday, April 05, 2017 8:21 AM
> To: Carsey, Jaben ; Ni, Ruiyu 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol
> Importance: High
> 
> Thanks, Jaben. That makes sense.
> 
> Now I see the real issue is with the "app" I ran across.  It is a driver,
> and it was trying to access command line args.  The driver crashed when
> it tried to access the command line, but it had been loaded in memory via
> the "load" command.
> 
> So, it seems "load" has no mechanism to pass command line arguments to a
> driver, and as a result, it apparently doesn't load the shell parameters
> protocol on the driver's handle, which caused the crash.
> 
> Regards,
> Jim
> 
> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Wednesday, April 5, 2017 10:08 AM
> To: Dailey, Jim ; Ni, Ruiyu 
> Cc: edk2-devel@lists.01.org
> Subject: RE: UEFI Shell Lib Constructor and Shell Parameters Protocol
> 
> Jim,
> 
> That protocol must be installed on your applications own image handle for it
> to be valid.  Locating the protocol on some other image would result with
> finding the other image's command line parameters and the like...
> 
> -Jaben
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > jim.dai...@dell.com
> > Sent: Wednesday, April 05, 2017 7:07 AM
> > To: Carsey, Jaben ; Ni, Ruiyu
> 
> > Cc: edk2-devel@lists.01.org
> > Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol
> > Importance: High
> >
> >
> > A question or two for all shell experts:
> >
> > In the UEFI Shell Lib constructor code, if the Shell protocol cannot
> > be opened, then an attempt is made to locate it before "giving up".
> >
> > However, if the Shell parameters protocol cannot be opened, no attempt
> > is made to locate it---the code simply leaves the parameters protocol
> > pointer set to NULL. Can anyone explain why this is?
> >
> > I came across an app that crashes because of this behavior, but if I
> > add code to try and locate the parameters protocol, then the app works
> > as designed WRT accessing command line parameters.  Is there some
> > lurking issue if an attempt to locate the parameters protocol is made
> > and is successful?
> >
> > Thanks,
> > Jim
> >
> > ---
> > Here is the relevant code:
> >
> > EFI_STATUS
> > ShellLibConstructorWorker (
> >   IN EFI_HANDLEImageHandle,
> >   IN EFI_SYSTEM_TABLE  *SystemTable
> >   )
> > {
> >   EFI_STATUS  Status;
> >
> >   //
> >   // UEFI 2.0 shell interfaces (used preferentially)
> >   //
> >   Status = gBS->OpenProtocol(
> > ImageHandle,
> > &gEfiShellProtocolGuid,
> > (VOID **)&gEfiShellProtocol,
> > ImageHandle,
> > NULL,
> > EFI_OPEN_PROTOCOL_GET_PROTOCOL
> >);
> >   if (EFI_ERROR(Status)) {
> > //
> > // Search for the shell protocol
> > //
> > Status = gBS->LocateProtocol(
> >   &gEfiShellProtocolGuid,
> >   NULL,
> >   (VOID **)&gEfiShellProtocol
> >  );
> > if (EFI_ERROR(Status)) {
> >   gEfiShellProtocol = NULL;
> > }
> >   }
> >   Status = gBS->OpenProtocol(
> > ImageHandle,
> > &gEfiShellParametersProtocolGuid,
> > (VOID **)&gEfiShellParametersProtocol,
> > ImageHandle,
> > NULL,
> > EFI_OPEN_PROTOCOL_GET_PROTOCOL
> >);
> >   if (EFI_ERROR(Status)) {
> > #if 1 // _Dell_ : Search for the parameters protocol too!
> > //
> > // Search for the shell parameters protocol
> > //
> > Status = gBS->LocateProtocol(
> >   &gEfiShellParametersProtocolGuid,
> >   NULL,
> >   (VOID **)&gEfiShellParametersProtocol
> >  );
> > if (EFI_ERROR(Status)) {
> >   gEfiShellParametersProtocol = NULL;
> > }
> > #else
> > gEfiShellParametersProtocol = NULL;
> > #endif
> >   }
> > ...
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg: move PlatformHasAcpiGuid from EmbeddedPkg

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 16:38, Leif Lindholm  wrote:
> On Wed, Apr 05, 2017 at 11:01:05AM +0100, Ard Biesheuvel wrote:
>> On 5 April 2017 at 10:49, Laszlo Ersek  wrote:
>> > On 04/05/17 11:38, Ard Biesheuvel wrote:
>> >> Given the agreement on the edk2-devel regarding the fact that the
>> >> notion whether or not a 'platform has ACPI' is a universal one, move
>> >> the PlatformHasAcpi GUID to MdeModulePkg.
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.0
>> >> Signed-off-by: Ard Biesheuvel 
>> >> Reviewed-by: "Zeng, Star" 
>> >> ---
>> >>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf   | 1 +
>> >>  ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 1 +
>> >>  EmbeddedPkg/EmbeddedPkg.dec| 3 ---
>> >>  EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf  | 1 +
>> >>  {EmbeddedPkg => MdeModulePkg}/Include/Guid/PlatformHasAcpi.h   | 0
>> >>  MdeModulePkg/MdeModulePkg.dec  | 3 +++
>> >>  6 files changed, 6 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf 
>> >> b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> >> index 08025f0c3722..5351e741aa41 100644
>> >> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> >> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> >> @@ -27,6 +27,7 @@ [Sources]
>> >>  [Packages]
>> >>ArmVirtPkg/ArmVirtPkg.dec
>> >>EmbeddedPkg/EmbeddedPkg.dec
>> >> +  MdeModulePkg/MdeModulePkg.dec
>> >>MdePkg/MdePkg.dec
>> >>OvmfPkg/OvmfPkg.dec
>> >>
>> >> diff --git 
>> >> a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf 
>> >> b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> >> index 2833075f65c9..26965c50c12b 100644
>> >> --- a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> >> +++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> >> @@ -26,6 +26,7 @@ [Sources]
>> >>
>> >>  [Packages]
>> >>EmbeddedPkg/EmbeddedPkg.dec
>> >> +  MdeModulePkg/MdeModulePkg.dec
>> >>MdePkg/MdePkg.dec
>> >>
>> >>  [LibraryClasses]
>> >> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
>> >> index 0bed2736c8c3..a7e127085236 100644
>> >> --- a/EmbeddedPkg/EmbeddedPkg.dec
>> >> +++ b/EmbeddedPkg/EmbeddedPkg.dec
>> >> @@ -57,9 +57,6 @@ [Guids.common]
>> >>gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 
>> >> 0x85, 0xAD, 0x3F, 0x71, 0x6D } }
>> >>gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 
>> >> 0xc8, 0x4e, 0xfb, 0x3e, 0x57 } }
>> >>
>> >> -  ## Include/Guid/PlatformHasAcpi.h
>> >> -  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 
>> >> 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
>> >> -
>> >>## Include/Guid/PlatformHasDeviceTree.h
>> >>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 
>> >> 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>> >>
>> >> diff --git 
>> >> a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf 
>> >> b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>> >> index 6268293ca97b..be298ba67c40 100644
>> >> --- a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>> >> +++ b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>> >> @@ -34,6 +34,7 @@ [Sources]
>> >>
>> >>  [Packages]
>> >>EmbeddedPkg/EmbeddedPkg.dec
>> >
>> > I think you can remove "EmbeddedPkg/EmbeddedPkg.dec" here.
>> >
>>
>> Ah yes. It didn't occur to me to remove the 'home' package here, but I
>> suppose this library doesn't depend on anything it provides.
>>
>> > (
>> >
>> > I checked all the other INF files being modified as well; it seems that
>> > "EmbeddedPkg/EmbeddedPkg.dec" remains necessary in all other places.
>> >
>> > I also grepped all INF files for the GUID -- DtPlatformDxe.inf is
>> > another user, but it needs no modification.
>> >
>> > )
>> >
>> > With that update (if it indeed works),
>> >
>> > Reviewed-by: Laszlo Ersek 
>
> Seconded.
> (Reviewed-by: Leif Lindholm )
>

Thanks. Pushed as a391e5925dc3 (with the suggestion incorporated)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg: move PlatformHasAcpiGuid from EmbeddedPkg

2017-04-05 Thread Leif Lindholm
On Wed, Apr 05, 2017 at 11:01:05AM +0100, Ard Biesheuvel wrote:
> On 5 April 2017 at 10:49, Laszlo Ersek  wrote:
> > On 04/05/17 11:38, Ard Biesheuvel wrote:
> >> Given the agreement on the edk2-devel regarding the fact that the
> >> notion whether or not a 'platform has ACPI' is a universal one, move
> >> the PlatformHasAcpi GUID to MdeModulePkg.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel 
> >> Reviewed-by: "Zeng, Star" 
> >> ---
> >>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf   | 1 +
> >>  ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 1 +
> >>  EmbeddedPkg/EmbeddedPkg.dec| 3 ---
> >>  EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf  | 1 +
> >>  {EmbeddedPkg => MdeModulePkg}/Include/Guid/PlatformHasAcpi.h   | 0
> >>  MdeModulePkg/MdeModulePkg.dec  | 3 +++
> >>  6 files changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf 
> >> b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> >> index 08025f0c3722..5351e741aa41 100644
> >> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> >> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> >> @@ -27,6 +27,7 @@ [Sources]
> >>  [Packages]
> >>ArmVirtPkg/ArmVirtPkg.dec
> >>EmbeddedPkg/EmbeddedPkg.dec
> >> +  MdeModulePkg/MdeModulePkg.dec
> >>MdePkg/MdePkg.dec
> >>OvmfPkg/OvmfPkg.dec
> >>
> >> diff --git 
> >> a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf 
> >> b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> >> index 2833075f65c9..26965c50c12b 100644
> >> --- a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> >> +++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> >> @@ -26,6 +26,7 @@ [Sources]
> >>
> >>  [Packages]
> >>EmbeddedPkg/EmbeddedPkg.dec
> >> +  MdeModulePkg/MdeModulePkg.dec
> >>MdePkg/MdePkg.dec
> >>
> >>  [LibraryClasses]
> >> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
> >> index 0bed2736c8c3..a7e127085236 100644
> >> --- a/EmbeddedPkg/EmbeddedPkg.dec
> >> +++ b/EmbeddedPkg/EmbeddedPkg.dec
> >> @@ -57,9 +57,6 @@ [Guids.common]
> >>gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 
> >> 0xAD, 0x3F, 0x71, 0x6D } }
> >>gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 
> >> 0xc8, 0x4e, 0xfb, 0x3e, 0x57 } }
> >>
> >> -  ## Include/Guid/PlatformHasAcpi.h
> >> -  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
> >> 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
> >> -
> >>## Include/Guid/PlatformHasDeviceTree.h
> >>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
> >> 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
> >>
> >> diff --git a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf 
> >> b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> >> index 6268293ca97b..be298ba67c40 100644
> >> --- a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> >> +++ b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> >> @@ -34,6 +34,7 @@ [Sources]
> >>
> >>  [Packages]
> >>EmbeddedPkg/EmbeddedPkg.dec
> >
> > I think you can remove "EmbeddedPkg/EmbeddedPkg.dec" here.
> >
> 
> Ah yes. It didn't occur to me to remove the 'home' package here, but I
> suppose this library doesn't depend on anything it provides.
> 
> > (
> >
> > I checked all the other INF files being modified as well; it seems that
> > "EmbeddedPkg/EmbeddedPkg.dec" remains necessary in all other places.
> >
> > I also grepped all INF files for the GUID -- DtPlatformDxe.inf is
> > another user, but it needs no modification.
> >
> > )
> >
> > With that update (if it indeed works),
> >
> > Reviewed-by: Laszlo Ersek 

Seconded.
(Reviewed-by: Leif Lindholm )

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


Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

2017-04-05 Thread Jim.Dailey
Thanks, Jaben. That makes sense.

Now I see the real issue is with the "app" I ran across.  It is a driver,
and it was trying to access command line args.  The driver crashed when
it tried to access the command line, but it had been loaded in memory via
the "load" command.

So, it seems "load" has no mechanism to pass command line arguments to a
driver, and as a result, it apparently doesn't load the shell parameters
protocol on the driver's handle, which caused the crash.

Regards,
Jim

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Wednesday, April 5, 2017 10:08 AM
To: Dailey, Jim ; Ni, Ruiyu 
Cc: edk2-devel@lists.01.org
Subject: RE: UEFI Shell Lib Constructor and Shell Parameters Protocol

Jim,

That protocol must be installed on your applications own image handle for it to 
be valid.  Locating the protocol on some other image would result with finding 
the other image's command line parameters and the like...

-Jaben


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jim.dai...@dell.com
> Sent: Wednesday, April 05, 2017 7:07 AM
> To: Carsey, Jaben ; Ni, Ruiyu 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol
> Importance: High
> 
> 
> A question or two for all shell experts:
> 
> In the UEFI Shell Lib constructor code, if the Shell protocol cannot
> be opened, then an attempt is made to locate it before "giving up".
> 
> However, if the Shell parameters protocol cannot be opened, no attempt
> is made to locate it---the code simply leaves the parameters protocol
> pointer set to NULL. Can anyone explain why this is?
> 
> I came across an app that crashes because of this behavior, but if I
> add code to try and locate the parameters protocol, then the app works
> as designed WRT accessing command line parameters.  Is there some
> lurking issue if an attempt to locate the parameters protocol is made
> and is successful?
> 
> Thanks,
> Jim
> 
> ---
> Here is the relevant code:
> 
> EFI_STATUS
> ShellLibConstructorWorker (
>   IN EFI_HANDLEImageHandle,
>   IN EFI_SYSTEM_TABLE  *SystemTable
>   )
> {
>   EFI_STATUS  Status;
> 
>   //
>   // UEFI 2.0 shell interfaces (used preferentially)
>   //
>   Status = gBS->OpenProtocol(
> ImageHandle,
> &gEfiShellProtocolGuid,
> (VOID **)&gEfiShellProtocol,
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> //
> // Search for the shell protocol
> //
> Status = gBS->LocateProtocol(
>   &gEfiShellProtocolGuid,
>   NULL,
>   (VOID **)&gEfiShellProtocol
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellProtocol = NULL;
> }
>   }
>   Status = gBS->OpenProtocol(
> ImageHandle,
> &gEfiShellParametersProtocolGuid,
> (VOID **)&gEfiShellParametersProtocol,
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> #if 1 // _Dell_ : Search for the parameters protocol too!
> //
> // Search for the shell parameters protocol
> //
> Status = gBS->LocateProtocol(
>   &gEfiShellParametersProtocolGuid,
>   NULL,
>   (VOID **)&gEfiShellParametersProtocol
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellParametersProtocol = NULL;
> }
> #else
> gEfiShellParametersProtocol = NULL;
> #endif
>   }
> ...
> ___
> 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 v4 0/4] Juno cleanup -- OpenPlatformPkg edition

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 15:11, Ard Biesheuvel  wrote:
> On 5 April 2017 at 15:10, Ryan Harkin  wrote:
>> On 5 April 2017 at 15:00, Ard Biesheuvel  wrote:
>>> Counterpart to the EDK2 series switching Juno to the generic 
>>> non-discoverable
>>> device driver and generic PCI host bridge driver.
>>>
>>> v4: fixed a number of non-functional issues -- include ordering, incorrect
>>> BASE_NAME, commit log clarifications
>>> add RBs and TBs
>>
>> I don't see my TBs in there, is gmail messing me about or are they not there?
>>
>
> That appears to be caused by poor git send-email skills on my part,
> unfortunately. I added the locally, though, so I will include them
> when merging.
>

OK all pushed now (including you Tested-by's)

Thanks!

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


Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

2017-04-05 Thread Carsey, Jaben
Jim,

That protocol must be installed on your applications own image handle for it to 
be valid.  Locating the protocol on some other image would result with finding 
the other image's command line parameters and the like...

-Jaben


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jim.dai...@dell.com
> Sent: Wednesday, April 05, 2017 7:07 AM
> To: Carsey, Jaben ; Ni, Ruiyu 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol
> Importance: High
> 
> 
> A question or two for all shell experts:
> 
> In the UEFI Shell Lib constructor code, if the Shell protocol cannot
> be opened, then an attempt is made to locate it before "giving up".
> 
> However, if the Shell parameters protocol cannot be opened, no attempt
> is made to locate it---the code simply leaves the parameters protocol
> pointer set to NULL. Can anyone explain why this is?
> 
> I came across an app that crashes because of this behavior, but if I
> add code to try and locate the parameters protocol, then the app works
> as designed WRT accessing command line parameters.  Is there some
> lurking issue if an attempt to locate the parameters protocol is made
> and is successful?
> 
> Thanks,
> Jim
> 
> ---
> Here is the relevant code:
> 
> EFI_STATUS
> ShellLibConstructorWorker (
>   IN EFI_HANDLEImageHandle,
>   IN EFI_SYSTEM_TABLE  *SystemTable
>   )
> {
>   EFI_STATUS  Status;
> 
>   //
>   // UEFI 2.0 shell interfaces (used preferentially)
>   //
>   Status = gBS->OpenProtocol(
> ImageHandle,
> &gEfiShellProtocolGuid,
> (VOID **)&gEfiShellProtocol,
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> //
> // Search for the shell protocol
> //
> Status = gBS->LocateProtocol(
>   &gEfiShellProtocolGuid,
>   NULL,
>   (VOID **)&gEfiShellProtocol
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellProtocol = NULL;
> }
>   }
>   Status = gBS->OpenProtocol(
> ImageHandle,
> &gEfiShellParametersProtocolGuid,
> (VOID **)&gEfiShellParametersProtocol,
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
>);
>   if (EFI_ERROR(Status)) {
> #if 1 // _Dell_ : Search for the parameters protocol too!
> //
> // Search for the shell parameters protocol
> //
> Status = gBS->LocateProtocol(
>   &gEfiShellParametersProtocolGuid,
>   NULL,
>   (VOID **)&gEfiShellParametersProtocol
>  );
> if (EFI_ERROR(Status)) {
>   gEfiShellParametersProtocol = NULL;
> }
> #else
> gEfiShellParametersProtocol = NULL;
> #endif
>   }
> ...
> ___
> 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 v4 2/4] Platforms/Juno: add PciHostBridgeLib implementation

2017-04-05 Thread Leif Lindholm
On Wed, Apr 05, 2017 at 03:00:53PM +0100, Ard Biesheuvel wrote:
> In order to be able to switch to the generic PCI host bridge driver,
> implement the glue library that exposes the PCIe parameters to the
> common driver. Since the Juno performs some initialization of the
> PCIe control registers as well, copy that code from the old EDK2
> driver into the library's constructor.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c   | 
> 199 
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf |  
> 77 
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c| 
> 182 ++
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h| 
> 107 +++
>  4 files changed, 565 insertions(+)
> 
> diff --git 
> a/Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c 
> b/Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c
> new file mode 100644
> index ..f5cb2544652b
> --- /dev/null
> +++ b/Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c
> @@ -0,0 +1,199 @@
> +/** @file
> +  PCI Host Bridge Library instance for ARM Juno
> +
> +  Copyright (c) 2017, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "ArmPlatform.h"
> +
> +#pragma pack(1)
> +typedef struct {
> +  ACPI_HID_DEVICE_PATH AcpiDevicePath;
> +  EFI_DEVICE_PATH_PROTOCOL EndDevicePath;
> +} EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
> +#pragma pack ()
> +
> +STATIC EFI_PCI_ROOT_BRIDGE_DEVICE_PATH mEfiPciRootBridgeDevicePath = {
> +  {
> +{
> +  ACPI_DEVICE_PATH,
> +  ACPI_DP,
> +  {
> +(UINT8) (sizeof(ACPI_HID_DEVICE_PATH)),
> +(UINT8) ((sizeof(ACPI_HID_DEVICE_PATH)) >> 8)
> +  }
> +},
> +EISA_PNP_ID(0x0A03), // PCI
> +0
> +  }, {
> +END_DEVICE_PATH_TYPE,
> +END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +{
> +  END_DEVICE_PATH_LENGTH,
> +  0
> +}
> +  }
> +};
> +
> +STATIC PCI_ROOT_BRIDGE mRootBridge = {
> +  0,  // Segment
> +  0,  // Supports
> +  0,  // Attributes
> +  TRUE,   // DmaAbove4G
> +  FALSE,  // NoExtendedConfigSpace
> +  FALSE,  // ResourceAssigned
> +  EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |  // AllocationAttributes
> +  EFI_PCI_HOST_BRIDGE_MEM64_DECODE,
> +  {
> +// Bus
> +FixedPcdGet32 (PcdPciBusMin),
> +FixedPcdGet32 (PcdPciBusMax)
> +  }, {
> +// Io
> +FixedPcdGet64 (PcdPciIoBase),
> +FixedPcdGet64 (PcdPciIoBase) + FixedPcdGet64 (PcdPciIoSize) - 1
> +  }, {
> +// Mem
> +FixedPcdGet32 (PcdPciMmio32Base),
> +FixedPcdGet32 (PcdPciMmio32Base) + FixedPcdGet32 (PcdPciMmio32Size) - 1
> +  }, {
> +// MemAbove4G
> +FixedPcdGet64 (PcdPciMmio64Base),
> +FixedPcdGet64 (PcdPciMmio64Base) + FixedPcdGet64 (PcdPciMmio64Size) - 1
> +  }, {
> +// PMem
> +MAX_UINT64,
> +0
> +  }, {
> +// PMemAbove4G
> +MAX_UINT64,
> +0
> +  },
> +  (EFI_DEVICE_PATH_PROTOCOL *)&mEfiPciRootBridgeDevicePath
> +};
> +
> +/**
> +  Return all the root bridge instances in an array.
> +
> +  @param Count  Return the count of root bridge instances.
> +
> +  @return All the root bridge instances in an array.
> +  The array should be passed into PciHostBridgeFreeRootBridges()
> +  when it's not used.
> +**/
> +PCI_ROOT_BRIDGE *
> +EFIAPI
> +PciHostBridgeGetRootBridges (
> +  UINTN *Count
> +  )
> +{
> +  UINT32  JunoRevision;
> +
> +  //
> +  // Juno R0 has no working PCIe
> +  //
> +  GetJunoRevision (JunoRevision);
> +  if (JunoRevision < JUNO_REVISION_R1) {
> +*Count = 0;
> +return NULL;
> +  }
> +
> +  *Count = 1;
> +
> +  return &mRootBridge;
> +}
> +
> +/**
> +  Free the root bridge instances array returned from 
> PciHostBridgeGetRootBridges().
> +
> +  @param Bridges The root bridge instances array.
> +  @param Count   The count of the array.
> +**/
> +VOID
> +EFIAPI
> +PciHostBridgeFreeRootBridges (
> +  PCI_ROOT_BRIDGE *Bridges,
> +  UINTN   Count
> +  )
> +{
> +}
>

Re: [edk2] [PATCH v4 resend v4 5/6] ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver

2017-04-05 Thread Leif Lindholm
On Wed, Apr 05, 2017 at 02:58:06PM +0100, Ard Biesheuvel wrote:
> We are switching the Juno platform to the generic host bridge driver,
> which involves implementing PciHostBridgeLib for this platform, and
> plugging it into MdeModulePkg's PciHostBridgeDxe.inf.
> 
> Since the platform descriptions no longer live in upstream EDK2, the
> PciHostBridgeLib implementation (which reuses some of the code removed
> here) will live there as well. But this PciHostBridgeDxe driver is no
> longer used, so remove it.

Splendid, thanks!

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> Tested-by: Ryan Harkin 

Reviewed-by: Leif Lindholm 

> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c   
> | 199 --
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h   
> | 324 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf  
> |  76 --
>  
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>  | 642 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c   
> | 748 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
> | 170 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h 
> | 111 ---
>  7 files changed, 2270 deletions(-)
> 
> diff --git 
> a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
> deleted file mode 100644
> index e1a6b749e4e6..
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
> +++ /dev/null
> @@ -1,199 +0,0 @@
> -/** @file
> -*  Pci Host Bridge support for the Xpress-RICH3 PCIe Root Complex
> -*
> -*  Copyright (c) 2011-2015, ARM Ltd. All rights reserved.
> -*
> -*  This program and the accompanying materials
> -*  are licensed and made available under the terms and conditions of the BSD 
> License
> -*  which accompanies this distribution.  The full text of the license may be 
> found at
> -*  http://opensource.org/licenses/bsd-license.php
> -*
> -*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -*
> -**/
> -
> -#include "PciHostBridge.h"
> -
> -#include 
> -
> -/**
> - * PCI Root Bridge Description
> - */
> -typedef struct {
> -  UINT32  AcpiUid;
> -  UINT64  MemAllocAttributes;
> -} PCI_ROOT_BRIDGE_DESC;
> -
> -PCI_ROOT_BRIDGE_DESC PciRbDescriptions = {
> -0,  // AcpiUid
> -PCI_MEMORY_ALLOCATION_ATTRIBUTES// MemAllocAttributes
> -};
> -
> -/**
> - * Template for PCI Host Bridge Instance
> - **/
> -STATIC CONST PCI_HOST_BRIDGE_INSTANCE
> -gPciHostBridgeInstanceTemplate = {
> -  PCI_HOST_BRIDGE_SIGNATURE,  //Signature
> -  NULL,   // Handle
> -  NULL,   // ImageHandle
> -  NULL,   // RootBridge
> -  TRUE,   // CanRestarted
> -  NULL,   // CpuIo
> -  NULL,   // Metronome
> -  {   // ResAlloc
> -PciHbRaNotifyPhase,   //   ResAlloc.NotifyPhase
> -PciHbRaGetNextRootBridge, //   ResAlloc.GetNextRootBridge
> -PciHbRaGetAllocAttributes,//   ResAlloc.GetAllocAttributes
> -PciHbRaStartBusEnumeration,   //   ResAlloc.StartBusEnumeration
> -PciHbRaSetBusNumbers, //   ResAlloc.SetBusNumbers
> -PciHbRaSubmitResources,   //   ResAlloc.SubmitResources
> -PciHbRaGetProposedResources,  //   ResAlloc.GetProposedResources
> -PciHbRaPreprocessController   //   ResAlloc.PreprocessController
> -  }
> -};
> -PCI_HOST_BRIDGE_INSTANCE* gpPciHostBridgeInstance;
> -
> -EFI_STATUS
> -HostBridgeConstructor (
> -  IN OUT PCI_HOST_BRIDGE_INSTANCE** Instance,
> -  IN  EFI_HANDLEImageHandle
> -  )
> -{
> -  EFI_STATUS  Status;
> -  PCI_HOST_BRIDGE_INSTANCE*   HostBridge;
> -
> -  PCI_TRACE ("HostBridgeConstructor()");
> -
> -  if (Instance == NULL) {
> -return EFI_INVALID_PARAMETER;
> -  }
> -
> -  HostBridge = AllocateCopyPool (sizeof (PCI_HOST_BRIDGE_INSTANCE), 
> &gPciHostBridgeInstanceTemplate);
> -  if (HostBridge == NULL) {
> -PCI_TRACE ("HostBridgeConstructor(): FAIL to allocate resources");
> -return EFI_OUT_OF_RESOURCES;
> -  }
> -
> -  // It will also create a device handle for the PCI Host Bridge (as 
> HostBridge->Handle == NULL)
> -  Status = gBS->InstallMultipleProtocolInterfaces (
> -&HostBridge->Handle,
> -&gEfiPciHostBridgeResourceAllocationProtocolGuid, 
> &HostBridge->ResAlloc,
> -NULL
> -);
> -  if (EFI_ERROR (Status)) {
> -PCI_TRACE ("Hos

Re: [edk2] [PATCH v3 1/6] ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency

2017-04-05 Thread Leif Lindholm
On Wed, Apr 05, 2017 at 02:11:44PM +0100, Ard Biesheuvel wrote:
> On 5 April 2017 at 14:09, Leif Lindholm  wrote:
> > On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
> >> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
> >> cloning the ShutdownUefiBootServices() routine into a local source
> >> file; this is the only BdsLib feature 'runaxf' depends on.
> >
> > I was going to go through these individually and give a R-b for the
> > whole series at the end if I didn't come across anything, but I'd just
> > like to add for this one:
> >
> > This is abslutely the right thing to do - BdsLib only had this
> > functionality due to the LinuxLoader, and it could be deleted now (but
> > I guess we're planning to get rid of the whole thing?).
> >
> 
> I'd like to avoid doing any 'improvements' to BdsLib while it's on its
> way you -- once AndroidFastBootApp is the last remaining user, we can
> fold whatever it uses into it instead.

Agreed - thanks!

/
Leif

> > Reviewed-by: Leif Lindholm 
> >
> 
> Thanks
> 
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf |  1 -
> >>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  | 58 
> >> +++-
> >>  2 files changed, 57 insertions(+), 2 deletions(-)
> >>
> >> diff --git 
> >> a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
> >> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
> >> index 9a34f12a..7d15f6934608 100644
> >> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
> >> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
> >> @@ -43,7 +43,6 @@ [Packages]
> >>  [LibraryClasses]
> >>ArmLib
> >>BaseLib
> >> -  BdsLib
> >>DebugLib
> >>HiiLib
> >>ShellLib
> >> diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c 
> >> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> >> index 2abfb6cc1053..9f4fc780307d 100644
> >> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> >> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> >> @@ -21,7 +21,6 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> -#include 
> >>  #include 
> >>  #include 
> >>
> >> @@ -35,6 +34,63 @@
> >>  typedef VOID (*ELF_ENTRYPOINT)(UINTN arg0, UINTN arg1,
> >> UINTN arg2, UINTN arg3);
> >>
> >> +STATIC
> >> +EFI_STATUS
> >> +ShutdownUefiBootServices (
> >> +  VOID
> >> +  )
> >> +{
> >> +  EFI_STATUS  Status;
> >> +  UINTN   MemoryMapSize;
> >> +  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
> >> +  UINTN   MapKey;
> >> +  UINTN   DescriptorSize;
> >> +  UINT32  DescriptorVersion;
> >> +  UINTN   Pages;
> >> +
> >> +  MemoryMap = NULL;
> >> +  MemoryMapSize = 0;
> >> +  Pages = 0;
> >> +
> >> +  do {
> >> +Status = gBS->GetMemoryMap (
> >> +&MemoryMapSize,
> >> +MemoryMap,
> >> +&MapKey,
> >> +&DescriptorSize,
> >> +&DescriptorVersion
> >> +);
> >> +if (Status == EFI_BUFFER_TOO_SMALL) {
> >> +
> >> +  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
> >> +  MemoryMap = AllocatePages (Pages);
> >> +
> >> +  //
> >> +  // Get System MemoryMap
> >> +  //
> >> +  Status = gBS->GetMemoryMap (
> >> +  &MemoryMapSize,
> >> +  MemoryMap,
> >> +  &MapKey,
> >> +  &DescriptorSize,
> >> +  &DescriptorVersion
> >> +  );
> >> +}
> >> +
> >> +// Don't do anything between the GetMemoryMap() and ExitBootServices()
> >> +if (!EFI_ERROR(Status)) {
> >> +  Status = gBS->ExitBootServices (gImageHandle, MapKey);
> >> +  if (EFI_ERROR(Status)) {
> >> +FreePages (MemoryMap, Pages);
> >> +MemoryMap = NULL;
> >> +MemoryMapSize = 0;
> >> +  }
> >> +}
> >> +  } while (EFI_ERROR(Status));
> >> +
> >> +  return Status;
> >> +}
> >> +
> >>
> >>  STATIC
> >>  EFI_STATUS
> >> --
> >> 2.9.3
> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v4 0/4] Juno cleanup -- OpenPlatformPkg edition

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 15:10, Ryan Harkin  wrote:
> On 5 April 2017 at 15:00, Ard Biesheuvel  wrote:
>> Counterpart to the EDK2 series switching Juno to the generic non-discoverable
>> device driver and generic PCI host bridge driver.
>>
>> v4: fixed a number of non-functional issues -- include ordering, incorrect
>> BASE_NAME, commit log clarifications
>> add RBs and TBs
>
> I don't see my TBs in there, is gmail messing me about or are they not there?
>

That appears to be caused by poor git send-email skills on my part,
unfortunately. I added the locally, though, so I will include them
when merging.

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


Re: [edk2] [PATCH v4 0/4] Juno cleanup -- OpenPlatformPkg edition

2017-04-05 Thread Ryan Harkin
On 5 April 2017 at 15:00, Ard Biesheuvel  wrote:
> Counterpart to the EDK2 series switching Juno to the generic non-discoverable
> device driver and generic PCI host bridge driver.
>
> v4: fixed a number of non-functional issues -- include ordering, incorrect
> BASE_NAME, commit log clarifications
> add RBs and TBs

I don't see my TBs in there, is gmail messing me about or are they not there?

>
> Ard Biesheuvel (4):
>   Platforms/Juno: add non-discoverable device driver and library
>   Platforms/Juno: add PciHostBridgeLib implementation
>   Platforms/Juno: switch to generic PCI host bridge driver
>   Platforms/Juno: remove BdsLib dependency
>
>  Platforms/ARM/Juno/ArmJuno.dsc   |  
> 24 ++-
>  Platforms/ARM/Juno/ArmJuno.fdf   |  
> 11 +-
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c   | 
> 199 
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf |  
> 77 
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c| 
> 182 ++
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h| 
> 107 +++
>  6 files changed, 585 insertions(+), 15 deletions(-)
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h
>
> --
> 2.9.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

2017-04-05 Thread Jim.Dailey

A question or two for all shell experts:

In the UEFI Shell Lib constructor code, if the Shell protocol cannot
be opened, then an attempt is made to locate it before "giving up".

However, if the Shell parameters protocol cannot be opened, no attempt
is made to locate it---the code simply leaves the parameters protocol
pointer set to NULL. Can anyone explain why this is?

I came across an app that crashes because of this behavior, but if I
add code to try and locate the parameters protocol, then the app works
as designed WRT accessing command line parameters.  Is there some
lurking issue if an attempt to locate the parameters protocol is made
and is successful?

Thanks,
Jim

---
Here is the relevant code:

EFI_STATUS
ShellLibConstructorWorker (
  IN EFI_HANDLEImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS  Status;

  //
  // UEFI 2.0 shell interfaces (used preferentially)
  //
  Status = gBS->OpenProtocol(
ImageHandle,
&gEfiShellProtocolGuid,
(VOID **)&gEfiShellProtocol,
ImageHandle,
NULL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL
   );
  if (EFI_ERROR(Status)) {
//
// Search for the shell protocol
//
Status = gBS->LocateProtocol(
  &gEfiShellProtocolGuid,
  NULL,
  (VOID **)&gEfiShellProtocol
 );
if (EFI_ERROR(Status)) {
  gEfiShellProtocol = NULL;
}
  }
  Status = gBS->OpenProtocol(
ImageHandle,
&gEfiShellParametersProtocolGuid,
(VOID **)&gEfiShellParametersProtocol,
ImageHandle,
NULL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL
   );
  if (EFI_ERROR(Status)) {
#if 1 // _Dell_ : Search for the parameters protocol too!
//
// Search for the shell parameters protocol
//
Status = gBS->LocateProtocol(
  &gEfiShellParametersProtocolGuid,
  NULL,
  (VOID **)&gEfiShellParametersProtocol
 );
if (EFI_ERROR(Status)) {
  gEfiShellParametersProtocol = NULL;
}
#else
gEfiShellParametersProtocol = NULL;
#endif
  }
...
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v4 2/4] Platforms/Juno: add PciHostBridgeLib implementation

2017-04-05 Thread Ard Biesheuvel
In order to be able to switch to the generic PCI host bridge driver,
implement the glue library that exposes the PCIe parameters to the
common driver. Since the Juno performs some initialization of the
PCIe control registers as well, copy that code from the old EDK2
driver into the library's constructor.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c   | 199 

 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf |  77 

 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c| 182 
++
 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h| 107 
+++
 4 files changed, 565 insertions(+)

diff --git 
a/Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c 
b/Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c
new file mode 100644
index ..f5cb2544652b
--- /dev/null
+++ b/Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c
@@ -0,0 +1,199 @@
+/** @file
+  PCI Host Bridge Library instance for ARM Juno
+
+  Copyright (c) 2017, Linaro Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "ArmPlatform.h"
+
+#pragma pack(1)
+typedef struct {
+  ACPI_HID_DEVICE_PATH AcpiDevicePath;
+  EFI_DEVICE_PATH_PROTOCOL EndDevicePath;
+} EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
+#pragma pack ()
+
+STATIC EFI_PCI_ROOT_BRIDGE_DEVICE_PATH mEfiPciRootBridgeDevicePath = {
+  {
+{
+  ACPI_DEVICE_PATH,
+  ACPI_DP,
+  {
+(UINT8) (sizeof(ACPI_HID_DEVICE_PATH)),
+(UINT8) ((sizeof(ACPI_HID_DEVICE_PATH)) >> 8)
+  }
+},
+EISA_PNP_ID(0x0A03), // PCI
+0
+  }, {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{
+  END_DEVICE_PATH_LENGTH,
+  0
+}
+  }
+};
+
+STATIC PCI_ROOT_BRIDGE mRootBridge = {
+  0,  // Segment
+  0,  // Supports
+  0,  // Attributes
+  TRUE,   // DmaAbove4G
+  FALSE,  // NoExtendedConfigSpace
+  FALSE,  // ResourceAssigned
+  EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |  // AllocationAttributes
+  EFI_PCI_HOST_BRIDGE_MEM64_DECODE,
+  {
+// Bus
+FixedPcdGet32 (PcdPciBusMin),
+FixedPcdGet32 (PcdPciBusMax)
+  }, {
+// Io
+FixedPcdGet64 (PcdPciIoBase),
+FixedPcdGet64 (PcdPciIoBase) + FixedPcdGet64 (PcdPciIoSize) - 1
+  }, {
+// Mem
+FixedPcdGet32 (PcdPciMmio32Base),
+FixedPcdGet32 (PcdPciMmio32Base) + FixedPcdGet32 (PcdPciMmio32Size) - 1
+  }, {
+// MemAbove4G
+FixedPcdGet64 (PcdPciMmio64Base),
+FixedPcdGet64 (PcdPciMmio64Base) + FixedPcdGet64 (PcdPciMmio64Size) - 1
+  }, {
+// PMem
+MAX_UINT64,
+0
+  }, {
+// PMemAbove4G
+MAX_UINT64,
+0
+  },
+  (EFI_DEVICE_PATH_PROTOCOL *)&mEfiPciRootBridgeDevicePath
+};
+
+/**
+  Return all the root bridge instances in an array.
+
+  @param Count  Return the count of root bridge instances.
+
+  @return All the root bridge instances in an array.
+  The array should be passed into PciHostBridgeFreeRootBridges()
+  when it's not used.
+**/
+PCI_ROOT_BRIDGE *
+EFIAPI
+PciHostBridgeGetRootBridges (
+  UINTN *Count
+  )
+{
+  UINT32  JunoRevision;
+
+  //
+  // Juno R0 has no working PCIe
+  //
+  GetJunoRevision (JunoRevision);
+  if (JunoRevision < JUNO_REVISION_R1) {
+*Count = 0;
+return NULL;
+  }
+
+  *Count = 1;
+
+  return &mRootBridge;
+}
+
+/**
+  Free the root bridge instances array returned from 
PciHostBridgeGetRootBridges().
+
+  @param Bridges The root bridge instances array.
+  @param Count   The count of the array.
+**/
+VOID
+EFIAPI
+PciHostBridgeFreeRootBridges (
+  PCI_ROOT_BRIDGE *Bridges,
+  UINTN   Count
+  )
+{
+}
+
+
+STATIC CONST CHAR16 mPciHostBridgeLibAcpiAddressSpaceTypeStr[][4] = {
+  L"Mem", L"I/O", L"Bus"
+};
+
+/**
+  Inform the platform that the resource conflict happens.
+
+  @param HostBridgeHandle Handle of the Host Bridge.
+  @param ConfigurationPointer to PCI I/O and PCI memory resource
+  descriptors. The Configuration contains the resources
+  for all the root bridges.

[edk2] [PATCH v4 1/4] Platforms/Juno: add non-discoverable device driver and library

2017-04-05 Thread Ard Biesheuvel
In preparation of moving ArmJunoDxe's support of the OHCI and EHCI
controllers to the generic non-discoverable device infrastructure,
add the prerequisite driver and library class resolution to the
Juno platform description.

Note that the FD image size needs to be increased slightly to
accommodate the added code.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 Platforms/ARM/Juno/ArmJuno.dsc | 2 ++
 Platforms/ARM/Juno/ArmJuno.fdf | 7 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index 1f56643ae996..4d5d207f0c3a 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -65,6 +65,7 @@
 
 [LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, 
LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+  
NonDiscoverableDeviceRegistrationLib|MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/NonDiscoverableDeviceRegistrationLib.inf
 
 [BuildOptions]
   *_*_*_PLATFORM_FLAGS = -I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmJunoPkg/Include
@@ -307,6 +308,7 @@
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
+  
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
   #
   # Juno platform driver
diff --git a/Platforms/ARM/Juno/ArmJuno.fdf b/Platforms/ARM/Juno/ArmJuno.fdf
index beee7afd11fb..a16c897f4656 100644
--- a/Platforms/ARM/Juno/ArmJuno.fdf
+++ b/Platforms/ARM/Juno/ArmJuno.fdf
@@ -26,12 +26,12 @@
 
 [FD.BL33_AP_UEFI]
 BaseAddress   = 0xE000|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
address of the Firmware in NOR Flash.
-Size  = 0x000F|gArmTokenSpaceGuid.PcdFdSize # The size in 
bytes of the FLASH Device
+Size  = 0x000F8000|gArmTokenSpaceGuid.PcdFdSize # The size in 
bytes of the FLASH Device
 ErasePolarity = 1
 
 # This one is tricky, it must be: BlockSize * NumBlocks = Size
 BlockSize = 0x1000
-NumBlocks = 0xF0
+NumBlocks = 0xF8
 
 

 #
@@ -49,7 +49,7 @@ NumBlocks = 0xF0
 #
 

 
-0x|0x000F
+0x|0x000F8000
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
@@ -155,6 +155,7 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
   INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
   INF MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
+  INF 
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
   #
   # PCI Support
-- 
2.9.3

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


[edk2] [PATCH v4 0/4] Juno cleanup -- OpenPlatformPkg edition

2017-04-05 Thread Ard Biesheuvel
Counterpart to the EDK2 series switching Juno to the generic non-discoverable
device driver and generic PCI host bridge driver.

v4: fixed a number of non-functional issues -- include ordering, incorrect
BASE_NAME, commit log clarifications
add RBs and TBs

Ard Biesheuvel (4):
  Platforms/Juno: add non-discoverable device driver and library
  Platforms/Juno: add PciHostBridgeLib implementation
  Platforms/Juno: switch to generic PCI host bridge driver
  Platforms/Juno: remove BdsLib dependency

 Platforms/ARM/Juno/ArmJuno.dsc   |  24 
++-
 Platforms/ARM/Juno/ArmJuno.fdf   |  11 
+-
 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c   | 199 

 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf |  77 

 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c| 182 
++
 Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h| 107 
+++
 6 files changed, 585 insertions(+), 15 deletions(-)
 create mode 100644 
Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c
 create mode 100644 
Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf
 create mode 100644 
Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c
 create mode 100644 
Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h

-- 
2.9.3

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


[edk2] [PATCH v4 4/4] Platforms/Juno: remove BdsLib dependency

2017-04-05 Thread Ard Biesheuvel
ArmJunoDxe no longer depends on BdsLib so we no longer have to specify
a library class resolution for it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 Platforms/ARM/Juno/ArmJuno.dsc | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index a9524be86dbc..6adb33c76087 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -318,10 +318,7 @@
   #
   # Juno platform driver
   #
-  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf {
-
-  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
-  }
+  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
 
   #
   # SMBIOS/DMI
-- 
2.9.3

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


[edk2] [PATCH v4 3/4] Platforms/Juno: switch to generic PCI host bridge driver

2017-04-05 Thread Ard Biesheuvel
Now that we have the prerequisites in place, switch to the generic PCI
host bridge driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 Platforms/ARM/Juno/ArmJuno.dsc | 17 +++--
 Platforms/ARM/Juno/ArmJuno.fdf |  4 ++--
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index 4d5d207f0c3a..a9524be86dbc 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -66,6 +66,10 @@
 [LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, 
LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   
NonDiscoverableDeviceRegistrationLib|MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/NonDiscoverableDeviceRegistrationLib.inf
+  
PciHostBridgeLib|OpenPlatformPkg/Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf
+  PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
+  PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf
+  PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
 
 [BuildOptions]
   *_*_*_PLATFORM_FLAGS = -I$(WORKSPACE)/ArmPlatformPkg/ArmVExpressPkg/Include 
-I$(WORKSPACE)/ArmPlatformPkg/ArmJunoPkg/Include
@@ -143,13 +147,17 @@
   # PLDA PCI Root Complex
   #
   gArmTokenSpaceGuid.PcdPciBusMax|255
-  gArmTokenSpaceGuid.PcdPciIoBase|0x5f80
+  gArmTokenSpaceGuid.PcdPciIoBase|0x0
   gArmTokenSpaceGuid.PcdPciIoSize|0x0080
   gArmTokenSpaceGuid.PcdPciMmio32Base|0x5000
   gArmTokenSpaceGuid.PcdPciMmio32Size|0x0800
   gArmTokenSpaceGuid.PcdPciMmio64Base|0x40
   gArmTokenSpaceGuid.PcdPciMmio64Size|0x1
 
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x4000
+  gArmTokenSpaceGuid.PcdPciIoTranslation|0x5f80
+  gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24
+
   # List of Device Paths that support BootMonFs
   
gArmPlatformTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)"
 
@@ -270,16 +278,13 @@
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 
   # Required by PCI
-  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
+  ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
 
   #
   # PCI Support
   #
   MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
-  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf {
-
-  DmaLib|EmbeddedPkg/Library/NullDmaLib/NullDmaLib.inf
-  }
+  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
 
   #
   # SATA Controller
diff --git a/Platforms/ARM/Juno/ArmJuno.fdf b/Platforms/ARM/Juno/ArmJuno.fdf
index a16c897f4656..53a3bd2420ce 100644
--- a/Platforms/ARM/Juno/ArmJuno.fdf
+++ b/Platforms/ARM/Juno/ArmJuno.fdf
@@ -140,7 +140,7 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 
   # Required by PCI
-  INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
+  INF ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
 
   # FV FileSystem
   INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
@@ -161,7 +161,7 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
   # PCI Support
   #
   INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
-  INF ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
+  INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
 
   #
   # SATA Controller
-- 
2.9.3

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


[edk2] [PATCH v4 resend v4 6/6] ArmPlatformPkg/ArmJunoDxe: simplify ACPI table installation

2017-04-05 Thread Ard Biesheuvel
Having a three way conditional with callbacks would make sense if the
callbacks weren't (a) identical and (b) didn't return TRUE all the
time. So get rid of the kludge.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Tested-by: Ryan Harkin 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 37 
+---
 1 file changed, 1 insertion(+), 36 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
index f7e33961b4e7..da93eb582909 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
@@ -400,34 +400,6 @@ OnEndOfDxe (
   }
 }
 
-STATIC
-BOOLEAN
-AcpiTableJunoR0Check (
-  IN  EFI_ACPI_DESCRIPTION_HEADER *AcpiHeader
-  )
-{
-  return TRUE;
-}
-
-STATIC
-BOOLEAN
-AcpiTableJunoR1Check (
-  IN  EFI_ACPI_DESCRIPTION_HEADER *AcpiHeader
-  )
-{
-  return TRUE;
-}
-
-STATIC
-BOOLEAN
-AcpiTableJunoR2Check (
-  IN  EFI_ACPI_DESCRIPTION_HEADER *AcpiHeader
-  )
-{
-  return TRUE;
-}
-
-
 EFI_STATUS
 EFIAPI
 ArmJunoEntryPoint (
@@ -517,14 +489,7 @@ ArmJunoEntryPoint (
   //
   // Try to install the ACPI Tables
   //
-  if (JunoRevision == JUNO_REVISION_R0) {
-Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile, 
AcpiTableJunoR0Check);
-  } else if (JunoRevision == JUNO_REVISION_R1) {
-Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile, 
AcpiTableJunoR1Check);
-  } else if (JunoRevision == JUNO_REVISION_R2) {
-Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile, 
AcpiTableJunoR2Check);
-  }
-
+  Status = LocateAndInstallAcpiFromFv (&mJunoAcpiTableFile);
   ASSERT_EFI_ERROR (Status);
 
   //
-- 
2.9.3

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


Re: [edk2] [PATCH v4 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Laszlo Ersek
On 04/05/17 14:55, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan 
> 
> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
> a basic version of VMWare's SVGA display device. Drivers for this
> device exist for some guest OSes which do not support Qemu's other
> display adapters, so supporting it in OVMF is useful in conjunction
> with those OSes.
> 
> This change adds support for the SVGA device's framebuffer to
> QemuVideoDxe's graphics output protocol implementation, based on
> VMWare's documentation. The most basic initialisation, framebuffer
> layout query, and mode setting operations are implemented.
> 
> The device relies on port-based 32-bit I/O, unfortunately on misaligned
> addresses. This limits the driver's support to the x86 family of
> platforms.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Phil Dennis-Jordan 
> ---
> 
> Notes:
> v2:
> - Unaligned I/O helper functions moved to separate commit [Laszlo]
> - Multi-line function call whitespace fixes.
> 
> v3:
> - Dropped the "2" from "SVGA2" where appropriate. [Jordan, Laszlo]
> - Renamed various struct fields and functions with consistent prefixes 
> [Laszlo]
> - #include orders fixed [Laszlo]
> - Renamedi/moved lots of local variables to comply with convention. 
> [Laszlo]
> - Added error checking to PCI BAR queries. [Laszlo]
> - Moved some function definitions around for better grouping. [Laszlo]
> - Fixed ClearScreen() to use the correct VRAM BAR. [Laszlo]
> - Changed modelist initialisation to fetch all mode data on startup, so 
> mode
>   queries can return everything including channel masks without hitting 
> the
>   device. Mask calculations hopefully make more sense now. [Laszlo]
> - Whitespace fixes. [Laszlo]
> - Fixed a memory leak in BAR query.
> 
> v4:
> - Simplified mode info pixel mask calculation & PCI BAR OOB check. 
> [Laszlo]
> - Replaced struct assignment with CopyMem. [Laszlo]
> - Whitespace & comment typo fixes. [Laszlo]

Also, you moved around the "BytesPerLine" assignment.

Then I noticed that you actually moved around the *second* instance of
it, so you continue to have two identical assignments, one of which
should be superfluous:

[snip]

> +EFI_STATUS
> +QemuVideoVmwareSvgaModeSetup (
> +  QEMU_VIDEO_PRIVATE_DATA *Private
> +  )
> +{
> +  EFI_STATUSStatus;
> +  UINT32FbSize;
> +  UINT32MaxWidth, MaxHeight;
> +  UINT32Capabilities;
> +  UINT32BitsPerPixel;
> +  UINT32Index;
> +  QEMU_VIDEO_MODE_DATA  *ModeData;
> +  QEMU_VIDEO_BOCHS_MODES*VideoMode;
> +  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
> +
> +  VmwareSvgaWrite (Private, VmwareSvgaRegEnable, 0);
> +
> +  Private->ModeData =
> +AllocatePool (sizeof (Private->ModeData[0]) * 
> QEMU_VIDEO_BOCHS_MODE_COUNT);
> +  if (Private->ModeData == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto ModeDataAllocError;
> +  }
> +
> +  Private->VmwareSvgaModeInfo =
> +AllocatePool (
> +  sizeof (Private->VmwareSvgaModeInfo[0]) * QEMU_VIDEO_BOCHS_MODE_COUNT
> +  );
> +  if (Private->VmwareSvgaModeInfo == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto ModeInfoAllocError;
> +  }
> +
> +  FbSize =   VmwareSvgaRead (Private, VmwareSvgaRegFbSize);
> +  MaxWidth = VmwareSvgaRead (Private, VmwareSvgaRegMaxWidth);
> +  MaxHeight =VmwareSvgaRead (Private, VmwareSvgaRegMaxHeight);
> +  Capabilities = VmwareSvgaRead (Private, VmwareSvgaRegCapabilities);
> +  if ((Capabilities & VMWARE_SVGA_CAP_8BIT_EMULATION) != 0) {
> +BitsPerPixel = VmwareSvgaRead (
> + Private,
> + VmwareSvgaRegHostBitsPerPixel
> + );
> +VmwareSvgaWrite (
> +  Private,
> +  VmwareSvgaRegBitsPerPixel,
> +  BitsPerPixel
> +  );
> +  } else {
> +BitsPerPixel = VmwareSvgaRead (
> + Private,
> + VmwareSvgaRegBitsPerPixel
> + );
> +  }
> +
> +  if (FbSize == 0   ||
> +  MaxWidth == 0 ||
> +  MaxHeight == 0||
> +  BitsPerPixel == 0 ||
> +  BitsPerPixel % 8 != 0) {
> +Status = EFI_DEVICE_ERROR;
> +goto Rollback;
> +  }
> +
> +  ModeData = Private->ModeData;
> +  ModeInfo = Private->VmwareSvgaModeInfo;
> +  VideoMode = &QemuVideoBochsModes[0];
> +  for (Index = 0; Index < QEMU_VIDEO_BOCHS_MODE_COUNT; Index++) {
> +UINTN RequiredFbSize;
> +
> +RequiredFbSize = (UINTN) VideoMode->Width * VideoMode->Height *
> + (BitsPerPixel / 8);
> +if (RequiredFbSize <= FbSize &&
> +VideoMode->Width <= MaxWidth &&
> +VideoMode->Height <= MaxHeight) {
> +  U

[edk2] [PATCH v4 resend v4 5/6] ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver

2017-04-05 Thread Ard Biesheuvel
We are switching the Juno platform to the generic host bridge driver,
which involves implementing PciHostBridgeLib for this platform, and
plugging it into MdeModulePkg's PciHostBridgeDxe.inf.

Since the platform descriptions no longer live in upstream EDK2, the
PciHostBridgeLib implementation (which reuses some of the code removed
here) will live there as well. But this PciHostBridgeDxe driver is no
longer used, so remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Tested-by: Ryan Harkin 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c 
  | 199 --
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h 
  | 324 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
  |  76 --
 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
 | 642 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c 
  | 748 
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c   
  | 170 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h   
  | 111 ---
 7 files changed, 2270 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
deleted file mode 100644
index e1a6b749e4e6..
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
+++ /dev/null
@@ -1,199 +0,0 @@
-/** @file
-*  Pci Host Bridge support for the Xpress-RICH3 PCIe Root Complex
-*
-*  Copyright (c) 2011-2015, ARM Ltd. All rights reserved.
-*
-*  This program and the accompanying materials
-*  are licensed and made available under the terms and conditions of the BSD 
License
-*  which accompanies this distribution.  The full text of the license may be 
found at
-*  http://opensource.org/licenses/bsd-license.php
-*
-*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-*
-**/
-
-#include "PciHostBridge.h"
-
-#include 
-
-/**
- * PCI Root Bridge Description
- */
-typedef struct {
-  UINT32  AcpiUid;
-  UINT64  MemAllocAttributes;
-} PCI_ROOT_BRIDGE_DESC;
-
-PCI_ROOT_BRIDGE_DESC PciRbDescriptions = {
-0,  // AcpiUid
-PCI_MEMORY_ALLOCATION_ATTRIBUTES// MemAllocAttributes
-};
-
-/**
- * Template for PCI Host Bridge Instance
- **/
-STATIC CONST PCI_HOST_BRIDGE_INSTANCE
-gPciHostBridgeInstanceTemplate = {
-  PCI_HOST_BRIDGE_SIGNATURE,  //Signature
-  NULL,   // Handle
-  NULL,   // ImageHandle
-  NULL,   // RootBridge
-  TRUE,   // CanRestarted
-  NULL,   // CpuIo
-  NULL,   // Metronome
-  {   // ResAlloc
-PciHbRaNotifyPhase,   //   ResAlloc.NotifyPhase
-PciHbRaGetNextRootBridge, //   ResAlloc.GetNextRootBridge
-PciHbRaGetAllocAttributes,//   ResAlloc.GetAllocAttributes
-PciHbRaStartBusEnumeration,   //   ResAlloc.StartBusEnumeration
-PciHbRaSetBusNumbers, //   ResAlloc.SetBusNumbers
-PciHbRaSubmitResources,   //   ResAlloc.SubmitResources
-PciHbRaGetProposedResources,  //   ResAlloc.GetProposedResources
-PciHbRaPreprocessController   //   ResAlloc.PreprocessController
-  }
-};
-PCI_HOST_BRIDGE_INSTANCE* gpPciHostBridgeInstance;
-
-EFI_STATUS
-HostBridgeConstructor (
-  IN OUT PCI_HOST_BRIDGE_INSTANCE** Instance,
-  IN  EFI_HANDLEImageHandle
-  )
-{
-  EFI_STATUS  Status;
-  PCI_HOST_BRIDGE_INSTANCE*   HostBridge;
-
-  PCI_TRACE ("HostBridgeConstructor()");
-
-  if (Instance == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
-
-  HostBridge = AllocateCopyPool (sizeof (PCI_HOST_BRIDGE_INSTANCE), 
&gPciHostBridgeInstanceTemplate);
-  if (HostBridge == NULL) {
-PCI_TRACE ("HostBridgeConstructor(): FAIL to allocate resources");
-return EFI_OUT_OF_RESOURCES;
-  }
-
-  // It will also create a device handle for the PCI Host Bridge (as 
HostBridge->Handle == NULL)
-  Status = gBS->InstallMultipleProtocolInterfaces (
-&HostBridge->Handle,
-&gEfiPciHostBridgeResourceAllocationProtocolGuid, 
&HostBridge->ResAlloc,
-NULL
-);
-  if (EFI_ERROR (Status)) {
-PCI_TRACE ("HostBridgeConstructor(): FAIL to install resource allocator");
-FreePool (HostBridge);
-return EFI_DEVICE_ERROR;
-  } else {
-PCI_TRACE ("HostBridgeConstructor(): SUCCEED to install resource 
allocator");
-  }
-
-  Status = gBS->LocateProtocol (&gEfiCpuIo2ProtocolGuid, NULL, (VOID 
**)(&(HostBridge->CpuIo)));
-  ASSERT_EFI_ERROR (Status);
-
-  Status = gBS->Loc

[edk2] [PATCH v4 resend v4 0/6] Juno cleanup -- EDK2 edition

2017-04-05 Thread Ard Biesheuvel
This series is specific to Juno; it replaces the cargo culted and ancient
PCI 'emulation' code with calls into the new non-discoverable device API,
and removes the Juno specific PCI host bridge driver in favor of the generic
one.

v4: add missing commit log
add TBs and RBs
*no* code changes

Ard Biesheuvel (6):
  ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency
  ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency
  ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device
support
  ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0
  ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver
  ArmPlatformPkg/ArmJunoDxe: simplify ACPI table installation

 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c  
  | 110 ++-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
  |   4 +-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h  
  |   5 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
  | 596 
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h
  | 284 
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c 
  | 299 
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c 
  | 199 --
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h 
  | 324 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
  |  76 --
 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
 | 642 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c 
  | 748 
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c   
  | 170 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h   
  | 111 ---
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
  |   1 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  
  |  58 +-
 15 files changed, 104 insertions(+), 3523 deletions(-)
 delete mode 100644 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
 delete mode 100644 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h

-- 
2.9.3

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


[edk2] [PATCH v4 resend v4 4/6] ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0

2017-04-05 Thread Ard Biesheuvel
The ArmJunoDxe driver code registers a callback for the EndOfDxe event,
at which time it does some manipulation of the PCI peripherals on the
board. Given that R0 has no working PCIe, instead of conditionally
performing these operations, omit the registration of the
callback altogether on that platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Tested-by: Ryan Harkin 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 43 
+---
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
index 14ff189a3078..f7e33961b4e7 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
@@ -379,7 +379,6 @@ OnEndOfDxe (
   EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
   EFI_HANDLEHandle;
   EFI_STATUSStatus;
-  UINT32JunoRevision;
 
   //
   // PCI Root Complex initialization
@@ -395,13 +394,9 @@ OnEndOfDxe (
   Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath, 
FALSE);
   ASSERT_EFI_ERROR (Status);
 
-  GetJunoRevision (JunoRevision);
-
-  if (JunoRevision != JUNO_REVISION_R0) {
-Status = ArmJunoSetNicMacAddress ();
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_ERROR, "ArmJunoDxe: Failed to set Marvell Yukon NIC MAC 
address\n"));
-}
+  Status = ArmJunoSetNicMacAddress ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "ArmJunoDxe: Failed to set Marvell Yukon NIC MAC 
address\n"));
   }
 }
 
@@ -511,22 +506,6 @@ ArmJunoEntryPoint (
 }
   }
 
-  //
-  // Create an event belonging to the "gEfiEndOfDxeEventGroupGuid" group.
-  // The "OnEndOfDxe()" function is declared as the call back function.
-  // It will be called at the end of the DXE phase when an event of the
-  // same group is signalled to inform about the end of the DXE phase.
-  // Install the INSTALL_FDT_PROTOCOL protocol.
-  //
-  Status = gBS->CreateEventEx (
-  EVT_NOTIFY_SIGNAL,
-  TPL_CALLBACK,
-  OnEndOfDxe,
-  NULL,
-  &gEfiEndOfDxeEventGroupGuid,
-  &EndOfDxeEvent
-  );
-
   // Install dynamic Shell command to run baremetal binaries.
   Status = ShellDynCmdRunAxfInstall (ImageHandle);
   if (EFI_ERROR (Status)) {
@@ -555,6 +534,22 @@ ArmJunoEntryPoint (
 // Enable PCI enumeration
 PcdSetBool (PcdPciDisableBusEnumeration, FALSE);
 
+//
+// Create an event belonging to the "gEfiEndOfDxeEventGroupGuid" group.
+// The "OnEndOfDxe()" function is declared as the call back function.
+// It will be called at the end of the DXE phase when an event of the
+// same group is signalled to inform about the end of the DXE phase.
+// Install the INSTALL_FDT_PROTOCOL protocol.
+//
+Status = gBS->CreateEventEx (
+EVT_NOTIFY_SIGNAL,
+TPL_CALLBACK,
+OnEndOfDxe,
+NULL,
+&gEfiEndOfDxeEventGroupGuid,
+&EndOfDxeEvent
+);
+
 // Declare the related ACPI Tables
 EfiCreateProtocolNotifyEvent (
 &gEfiAcpiTableProtocolGuid,
-- 
2.9.3

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


[edk2] [PATCH v4 resend v4 3/6] ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device support

2017-04-05 Thread Ard Biesheuvel
Replace the open coded reimplementation of 'PCI emulation' with a pair
of calls into NonDiscoverableDeviceRegistrationLib to register the OHCI
and EHCI controllers. These will be picked up by the generic driver instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Tested-by: Ryan Harkin 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c |  30 +-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf   |   3 +-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h |   5 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c   | 596 

 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h   | 284 
--
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c| 299 
--
 6 files changed, 27 insertions(+), 1190 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
index f13c49559bb4..14ff189a3078 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -447,10 +448,31 @@ ArmJunoEntryPoint (
   UINT32JunoRevision;
   EFI_EVENT EndOfDxeEvent;
 
-  Status = PciEmulationEntryPoint ();
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
+  //
+  // Register the OHCI and EHCI controllers as non-coherent
+  // non-discoverable devices.
+  //
+  Status = RegisterNonDiscoverableMmioDevice (
+ NonDiscoverableDeviceTypeOhci,
+ NonDiscoverableDeviceDmaTypeNonCoherent,
+ NULL,
+ NULL,
+ 1,
+ FixedPcdGet32 (PcdSynopsysUsbOhciBaseAddress),
+ SIZE_64KB
+ );
+  ASSERT_EFI_ERROR (Status);
+
+  Status = RegisterNonDiscoverableMmioDevice (
+ NonDiscoverableDeviceTypeEhci,
+ NonDiscoverableDeviceDmaTypeNonCoherent,
+ NULL,
+ NULL,
+ 1,
+ FixedPcdGet32 (PcdSynopsysUsbEhciBaseAddress),
+ SIZE_64KB
+ );
+  ASSERT_EFI_ERROR (Status);
 
   //
   // If a hypervisor has been declared then we need to make sure its region is 
protected at runtime
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
index 168070c6add4..6719d0adcc87 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
@@ -21,8 +21,6 @@ [Defines]
 [Sources.common]
   AcpiTables.c
   ArmJunoDxe.c
-  PciEmulation.c
-  PciRootBridgeIo.c
 
 [Packages]
   ArmPkg/ArmPkg.dec
@@ -42,6 +40,7 @@ [LibraryClasses]
   DmaLib
   DxeServicesTableLib
   IoLib
+  NonDiscoverableDeviceRegistrationLib
   PcdLib
   PrintLib
   SerialPortLib
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
index df0277067e34..5d2b68fabd12 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
@@ -42,11 +42,6 @@
 #define R_TST_CTRL_1  0x0158 /* Test Control Register 1 */
 
 
-EFI_STATUS
-PciEmulationEntryPoint (
-  VOID
-  );
-
 /**
  * Callback called when ACPI Protocol is installed
  */
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
deleted file mode 100644
index 2ddebf606e3d..
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
+++ /dev/null
@@ -1,596 +0,0 @@
-/** @file
-
-  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-  Copyright (c) 2013 - 2014, ARM Ltd. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "PciEmulation.h"
-
-#define HOST_CONTROLLER_OPERATION_REG_SIZE  0x44
-
-typedef struct {
-  ACPI_HID_DEVICE_PATH  AcpiDevicePath;
-  PCI_DEVICE_PATH   PciDevicePath;
-  EFI_DEVICE_PATH_PROTOCOL  EndDevicePath;
-} EFI_PCI_IO_DEVICE_PATH;
-
-typedef struct {
-  UINT32  Signature;
-  EFI_PCI_IO_DEVICE_PATH  DevicePath;
-  EFI_PCI_IO_PROTOCOL PciIoProtocol;
-  PCI_TYPE00  *ConfigSpace;
-  PCI_ROOT_BRIDGE RootBridge;
-  UINTN   Segment;
-} EFI_PCI_IO_PRIVATE_DATA;
-
-#define EF

[edk2] [PATCH v4 resend v4 2/6] ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency

2017-04-05 Thread Ard Biesheuvel
The ArmJunoDxe driver does not actually depend on the deprecated BdsLib
so remove the dependency declaration from the INF file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Tested-by: Ryan Harkin 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
index a2617982b259..168070c6add4 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
@@ -38,7 +38,6 @@ [LibraryClasses]
   ArmLib
   ArmShellCmdRunAxfLib
   BaseMemoryLib
-  BdsLib
   DebugLib
   DmaLib
   DxeServicesTableLib
-- 
2.9.3

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


[edk2] [PATCH v4 resend v4 1/6] ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency

2017-04-05 Thread Ard Biesheuvel
Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
cloning the ShutdownUefiBootServices() routine into a local source
file; this is the only BdsLib feature 'runaxf' depends on.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Tested-by: Ryan Harkin 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf |  1 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  | 58 
+++-
 2 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
index 9a34f12a..7d15f6934608 100644
--- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
+++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
@@ -43,7 +43,6 @@ [Packages]
 [LibraryClasses]
   ArmLib
   BaseLib
-  BdsLib
   DebugLib
   HiiLib
   ShellLib
diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
index 2abfb6cc1053..9f4fc780307d 100644
--- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
+++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -35,6 +34,63 @@
 typedef VOID (*ELF_ENTRYPOINT)(UINTN arg0, UINTN arg1,
UINTN arg2, UINTN arg3);
 
+STATIC
+EFI_STATUS
+ShutdownUefiBootServices (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  UINTN   MemoryMapSize;
+  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
+  UINTN   MapKey;
+  UINTN   DescriptorSize;
+  UINT32  DescriptorVersion;
+  UINTN   Pages;
+
+  MemoryMap = NULL;
+  MemoryMapSize = 0;
+  Pages = 0;
+
+  do {
+Status = gBS->GetMemoryMap (
+&MemoryMapSize,
+MemoryMap,
+&MapKey,
+&DescriptorSize,
+&DescriptorVersion
+);
+if (Status == EFI_BUFFER_TOO_SMALL) {
+
+  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
+  MemoryMap = AllocatePages (Pages);
+
+  //
+  // Get System MemoryMap
+  //
+  Status = gBS->GetMemoryMap (
+  &MemoryMapSize,
+  MemoryMap,
+  &MapKey,
+  &DescriptorSize,
+  &DescriptorVersion
+  );
+}
+
+// Don't do anything between the GetMemoryMap() and ExitBootServices()
+if (!EFI_ERROR(Status)) {
+  Status = gBS->ExitBootServices (gImageHandle, MapKey);
+  if (EFI_ERROR(Status)) {
+FreePages (MemoryMap, Pages);
+MemoryMap = NULL;
+MemoryMapSize = 0;
+  }
+}
+  } while (EFI_ERROR(Status));
+
+  return Status;
+}
+
 
 STATIC
 EFI_STATUS
-- 
2.9.3

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


Re: [edk2] [PATCH v4 0/6] Juno cleanup -- EDK2 edition

2017-04-05 Thread Ard Biesheuvel
Please disregard -- I failed to add Ryan's Tested-by


On 5 April 2017 at 14:53, Ard Biesheuvel  wrote:
> This series is specific to Juno; it replaces the cargo culted and ancient
> PCI 'emulation' code with calls into the new non-discoverable device API,
> and removes the Juno specific PCI host bridge driver in favor of the generic
> one.
>
> v4: add missing commit log
> add acks
> *no* code changes
>
> Ard Biesheuvel (6):
>   ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency
>   ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency
>   ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device
> support
>   ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0
>   ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver
>   ArmPlatformPkg/ArmJunoDxe: simplify ACPI table installation
>
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> | 110 ++-
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf  
> |   4 +-
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
> |   5 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c  
> | 596 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h  
> | 284 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c   
> | 299 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c   
> | 199 --
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h   
> | 324 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf  
> |  76 --
>  
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>  | 642 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c   
> | 748 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
> | 170 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h 
> | 111 ---
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf   
> |   1 -
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> |  58 +-
>  15 files changed, 104 insertions(+), 3523 deletions(-)
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h
>
> --
> 2.9.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v4 3/6] ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device support

2017-04-05 Thread Ard Biesheuvel
Replace the open coded reimplementation of 'PCI emulation' with a pair
of calls into NonDiscoverableDeviceRegistrationLib to register the OHCI
and EHCI controllers. These will be picked up by the generic driver instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c |  30 +-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf   |   3 +-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h |   5 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c   | 596 

 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h   | 284 
--
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c| 299 
--
 6 files changed, 27 insertions(+), 1190 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
index f13c49559bb4..14ff189a3078 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -447,10 +448,31 @@ ArmJunoEntryPoint (
   UINT32JunoRevision;
   EFI_EVENT EndOfDxeEvent;
 
-  Status = PciEmulationEntryPoint ();
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
+  //
+  // Register the OHCI and EHCI controllers as non-coherent
+  // non-discoverable devices.
+  //
+  Status = RegisterNonDiscoverableMmioDevice (
+ NonDiscoverableDeviceTypeOhci,
+ NonDiscoverableDeviceDmaTypeNonCoherent,
+ NULL,
+ NULL,
+ 1,
+ FixedPcdGet32 (PcdSynopsysUsbOhciBaseAddress),
+ SIZE_64KB
+ );
+  ASSERT_EFI_ERROR (Status);
+
+  Status = RegisterNonDiscoverableMmioDevice (
+ NonDiscoverableDeviceTypeEhci,
+ NonDiscoverableDeviceDmaTypeNonCoherent,
+ NULL,
+ NULL,
+ 1,
+ FixedPcdGet32 (PcdSynopsysUsbEhciBaseAddress),
+ SIZE_64KB
+ );
+  ASSERT_EFI_ERROR (Status);
 
   //
   // If a hypervisor has been declared then we need to make sure its region is 
protected at runtime
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
index 168070c6add4..6719d0adcc87 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
@@ -21,8 +21,6 @@ [Defines]
 [Sources.common]
   AcpiTables.c
   ArmJunoDxe.c
-  PciEmulation.c
-  PciRootBridgeIo.c
 
 [Packages]
   ArmPkg/ArmPkg.dec
@@ -42,6 +40,7 @@ [LibraryClasses]
   DmaLib
   DxeServicesTableLib
   IoLib
+  NonDiscoverableDeviceRegistrationLib
   PcdLib
   PrintLib
   SerialPortLib
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
index df0277067e34..5d2b68fabd12 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
@@ -42,11 +42,6 @@
 #define R_TST_CTRL_1  0x0158 /* Test Control Register 1 */
 
 
-EFI_STATUS
-PciEmulationEntryPoint (
-  VOID
-  );
-
 /**
  * Callback called when ACPI Protocol is installed
  */
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
deleted file mode 100644
index 2ddebf606e3d..
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
+++ /dev/null
@@ -1,596 +0,0 @@
-/** @file
-
-  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-  Copyright (c) 2013 - 2014, ARM Ltd. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "PciEmulation.h"
-
-#define HOST_CONTROLLER_OPERATION_REG_SIZE  0x44
-
-typedef struct {
-  ACPI_HID_DEVICE_PATH  AcpiDevicePath;
-  PCI_DEVICE_PATH   PciDevicePath;
-  EFI_DEVICE_PATH_PROTOCOL  EndDevicePath;
-} EFI_PCI_IO_DEVICE_PATH;
-
-typedef struct {
-  UINT32  Signature;
-  EFI_PCI_IO_DEVICE_PATH  DevicePath;
-  EFI_PCI_IO_PROTOCOL PciIoProtocol;
-  PCI_TYPE00  *ConfigSpace;
-  PCI_ROOT_BRIDGE RootBridge;
-  UINTN   Segment;
-} EFI_PCI_IO_PRIVATE_DATA;
-
-#define EFI_PCI_IO_PRIVATE_DATA_SI

[edk2] [PATCH v4 4/6] ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0

2017-04-05 Thread Ard Biesheuvel
The ArmJunoDxe driver code registers a callback for the EndOfDxe event,
at which time it does some manipulation of the PCI peripherals on the
board. Given that R0 has no working PCIe, instead of conditionally
performing these operations, omit the registration of the
callback altogether on that platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 43 
+---
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
index 14ff189a3078..f7e33961b4e7 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
@@ -379,7 +379,6 @@ OnEndOfDxe (
   EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
   EFI_HANDLEHandle;
   EFI_STATUSStatus;
-  UINT32JunoRevision;
 
   //
   // PCI Root Complex initialization
@@ -395,13 +394,9 @@ OnEndOfDxe (
   Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath, 
FALSE);
   ASSERT_EFI_ERROR (Status);
 
-  GetJunoRevision (JunoRevision);
-
-  if (JunoRevision != JUNO_REVISION_R0) {
-Status = ArmJunoSetNicMacAddress ();
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_ERROR, "ArmJunoDxe: Failed to set Marvell Yukon NIC MAC 
address\n"));
-}
+  Status = ArmJunoSetNicMacAddress ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "ArmJunoDxe: Failed to set Marvell Yukon NIC MAC 
address\n"));
   }
 }
 
@@ -511,22 +506,6 @@ ArmJunoEntryPoint (
 }
   }
 
-  //
-  // Create an event belonging to the "gEfiEndOfDxeEventGroupGuid" group.
-  // The "OnEndOfDxe()" function is declared as the call back function.
-  // It will be called at the end of the DXE phase when an event of the
-  // same group is signalled to inform about the end of the DXE phase.
-  // Install the INSTALL_FDT_PROTOCOL protocol.
-  //
-  Status = gBS->CreateEventEx (
-  EVT_NOTIFY_SIGNAL,
-  TPL_CALLBACK,
-  OnEndOfDxe,
-  NULL,
-  &gEfiEndOfDxeEventGroupGuid,
-  &EndOfDxeEvent
-  );
-
   // Install dynamic Shell command to run baremetal binaries.
   Status = ShellDynCmdRunAxfInstall (ImageHandle);
   if (EFI_ERROR (Status)) {
@@ -555,6 +534,22 @@ ArmJunoEntryPoint (
 // Enable PCI enumeration
 PcdSetBool (PcdPciDisableBusEnumeration, FALSE);
 
+//
+// Create an event belonging to the "gEfiEndOfDxeEventGroupGuid" group.
+// The "OnEndOfDxe()" function is declared as the call back function.
+// It will be called at the end of the DXE phase when an event of the
+// same group is signalled to inform about the end of the DXE phase.
+// Install the INSTALL_FDT_PROTOCOL protocol.
+//
+Status = gBS->CreateEventEx (
+EVT_NOTIFY_SIGNAL,
+TPL_CALLBACK,
+OnEndOfDxe,
+NULL,
+&gEfiEndOfDxeEventGroupGuid,
+&EndOfDxeEvent
+);
+
 // Declare the related ACPI Tables
 EfiCreateProtocolNotifyEvent (
 &gEfiAcpiTableProtocolGuid,
-- 
2.9.3

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


[edk2] [PATCH v4 0/6] Juno cleanup -- EDK2 edition

2017-04-05 Thread Ard Biesheuvel
This series is specific to Juno; it replaces the cargo culted and ancient
PCI 'emulation' code with calls into the new non-discoverable device API,
and removes the Juno specific PCI host bridge driver in favor of the generic
one.

v4: add missing commit log
add acks
*no* code changes

Ard Biesheuvel (6):
  ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency
  ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency
  ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device
support
  ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0
  ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver
  ArmPlatformPkg/ArmJunoDxe: simplify ACPI table installation

 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c  
  | 110 ++-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
  |   4 +-
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h  
  |   5 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
  | 596 
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h
  | 284 
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c 
  | 299 
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c 
  | 199 --
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h 
  | 324 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
  |  76 --
 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
 | 642 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c 
  | 748 
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c   
  | 170 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h   
  | 111 ---
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
  |   1 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  
  |  58 +-
 15 files changed, 104 insertions(+), 3523 deletions(-)
 delete mode 100644 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
 delete mode 100644 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
 delete mode 100644 
ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h

-- 
2.9.3

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


[edk2] [PATCH v4 1/6] ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency

2017-04-05 Thread Ard Biesheuvel
Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
cloning the ShutdownUefiBootServices() routine into a local source
file; this is the only BdsLib feature 'runaxf' depends on.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf |  1 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  | 58 
+++-
 2 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
index 9a34f12a..7d15f6934608 100644
--- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
+++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
@@ -43,7 +43,6 @@ [Packages]
 [LibraryClasses]
   ArmLib
   BaseLib
-  BdsLib
   DebugLib
   HiiLib
   ShellLib
diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
index 2abfb6cc1053..9f4fc780307d 100644
--- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
+++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -35,6 +34,63 @@
 typedef VOID (*ELF_ENTRYPOINT)(UINTN arg0, UINTN arg1,
UINTN arg2, UINTN arg3);
 
+STATIC
+EFI_STATUS
+ShutdownUefiBootServices (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  UINTN   MemoryMapSize;
+  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
+  UINTN   MapKey;
+  UINTN   DescriptorSize;
+  UINT32  DescriptorVersion;
+  UINTN   Pages;
+
+  MemoryMap = NULL;
+  MemoryMapSize = 0;
+  Pages = 0;
+
+  do {
+Status = gBS->GetMemoryMap (
+&MemoryMapSize,
+MemoryMap,
+&MapKey,
+&DescriptorSize,
+&DescriptorVersion
+);
+if (Status == EFI_BUFFER_TOO_SMALL) {
+
+  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
+  MemoryMap = AllocatePages (Pages);
+
+  //
+  // Get System MemoryMap
+  //
+  Status = gBS->GetMemoryMap (
+  &MemoryMapSize,
+  MemoryMap,
+  &MapKey,
+  &DescriptorSize,
+  &DescriptorVersion
+  );
+}
+
+// Don't do anything between the GetMemoryMap() and ExitBootServices()
+if (!EFI_ERROR(Status)) {
+  Status = gBS->ExitBootServices (gImageHandle, MapKey);
+  if (EFI_ERROR(Status)) {
+FreePages (MemoryMap, Pages);
+MemoryMap = NULL;
+MemoryMapSize = 0;
+  }
+}
+  } while (EFI_ERROR(Status));
+
+  return Status;
+}
+
 
 STATIC
 EFI_STATUS
-- 
2.9.3

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


[edk2] [PATCH v4 2/6] ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency

2017-04-05 Thread Ard Biesheuvel
The ArmJunoDxe driver does not actually depend on the deprecated BdsLib
so remove the dependency declaration from the INF file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
index a2617982b259..168070c6add4 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
@@ -38,7 +38,6 @@ [LibraryClasses]
   ArmLib
   ArmShellCmdRunAxfLib
   BaseMemoryLib
-  BdsLib
   DebugLib
   DmaLib
   DxeServicesTableLib
-- 
2.9.3

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


Re: [edk2] [PATCH v3 3/6] ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device support

2017-04-05 Thread Leif Lindholm
On Tue, Apr 04, 2017 at 01:30:07PM +0100, Ard Biesheuvel wrote:
> Replace the open coded reimplementation of 'PCI emulation' with a pair
> of calls into NonDiscoverableDeviceRegistrationLib to register the OHCI
> and EHCI controllers. These will be picked up by the generic driver instead.
> 

That is a *sweet* diffstat.

Reviewed-by: Leif Lindholm 

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c |  30 +-
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf   |   3 +-
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h |   5 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c   | 596 
> 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h   | 284 
> --
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c| 299 
> --
>  6 files changed, 27 insertions(+), 1190 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index f13c49559bb4..14ff189a3078 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -447,10 +448,31 @@ ArmJunoEntryPoint (
>UINT32JunoRevision;
>EFI_EVENT EndOfDxeEvent;
>  
> -  Status = PciEmulationEntryPoint ();
> -  if (EFI_ERROR (Status)) {
> -return Status;
> -  }
> +  //
> +  // Register the OHCI and EHCI controllers as non-coherent
> +  // non-discoverable devices.
> +  //
> +  Status = RegisterNonDiscoverableMmioDevice (
> + NonDiscoverableDeviceTypeOhci,
> + NonDiscoverableDeviceDmaTypeNonCoherent,
> + NULL,
> + NULL,
> + 1,
> + FixedPcdGet32 (PcdSynopsysUsbOhciBaseAddress),
> + SIZE_64KB
> + );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  Status = RegisterNonDiscoverableMmioDevice (
> + NonDiscoverableDeviceTypeEhci,
> + NonDiscoverableDeviceDmaTypeNonCoherent,
> + NULL,
> + NULL,
> + 1,
> + FixedPcdGet32 (PcdSynopsysUsbEhciBaseAddress),
> + SIZE_64KB
> + );
> +  ASSERT_EFI_ERROR (Status);
>  
>//
>// If a hypervisor has been declared then we need to make sure its region 
> is protected at runtime
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
> index 168070c6add4..6719d0adcc87 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
> @@ -21,8 +21,6 @@ [Defines]
>  [Sources.common]
>AcpiTables.c
>ArmJunoDxe.c
> -  PciEmulation.c
> -  PciRootBridgeIo.c
>  
>  [Packages]
>ArmPkg/ArmPkg.dec
> @@ -42,6 +40,7 @@ [LibraryClasses]
>DmaLib
>DxeServicesTableLib
>IoLib
> +  NonDiscoverableDeviceRegistrationLib
>PcdLib
>PrintLib
>SerialPortLib
> diff --git 
> a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
> index df0277067e34..5d2b68fabd12 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
> @@ -42,11 +42,6 @@
>  #define R_TST_CTRL_1  0x0158 /* Test Control Register 1 
> */
>  
>  
> -EFI_STATUS
> -PciEmulationEntryPoint (
> -  VOID
> -  );
> -
>  /**
>   * Callback called when ACPI Protocol is installed
>   */
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
> deleted file mode 100644
> index 2ddebf606e3d..
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
> +++ /dev/null
> @@ -1,596 +0,0 @@
> -/** @file
> -
> -  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> -  Copyright (c) 2013 - 2014, ARM Ltd. All rights reserved.
> -
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of the BSD 
> License
> -  which accompanies this distribution.  The full text of the license may be 
> found at
> -  http://opensource.org/licenses/bsd-license.php
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -
> -**/
> -
> -#include "PciEmulation.h"
> -
> -#define HOST_CONTROLLER_OPERATION_REG_SIZE  0x44
> -
> -typedef struct {
> -  ACPI_HID_DEVICE_PATH  AcpiDevicePath;
> -  PCI_DEVICE_PATH   PciDevicePath;
> -  EFI_DE

Re: [edk2] [PATCH v3 2/6] ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency

2017-04-05 Thread Leif Lindholm
On Tue, Apr 04, 2017 at 01:30:06PM +0100, Ard Biesheuvel wrote:
> The ArmJunoDxe driver does not actually depend on the deprecated BdsLib
> so remove the dependency declaration from the INF file.
> 

Reviewed-by: Leif Lindholm 

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
> index a2617982b259..168070c6add4 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
> @@ -38,7 +38,6 @@ [LibraryClasses]
>ArmLib
>ArmShellCmdRunAxfLib
>BaseMemoryLib
> -  BdsLib
>DebugLib
>DmaLib
>DxeServicesTableLib
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v5] MdePkg: BaseIoLibIntrinsic (IoLib class) library

2017-04-05 Thread Leo Duran
This patch adds an SEV-specific .INF and corresponding assembly
files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.

The new .INF only supports the IA32 and X64 architectures.

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh 
Signed-off-by: Leo Duran 
---
 .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293 +
 .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282 
 MdePkg/MdePkg.dsc  |   2 +
 3 files changed, 577 insertions(+)
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm 
b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
new file mode 100644
index 000..9adb972
--- /dev/null
+++ b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
@@ -0,0 +1,293 @@
+;--
+;
+; Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
+; Copyright (c) 2017, AMD Incorporated. 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.
+;
+;--
+
+SECTION .text
+
+;--
+; Check whether we need to unroll the String I/O under SEV guest
+;
+; Return // eax   (1 - unroll, 0 - no unroll)
+;--
+global ASM_PFX(SevNoRepIo)
+ASM_PFX(SevNoRepIo):
+
+  ; CPUID clobbers ebx, ecx and edx
+  push  ebx
+  push  ecx
+  push  edx
+
+  ; Check if we are running under hypervisor
+  ; CPUID(1).ECX Bit 31
+  mov   eax, 1
+  cpuid
+  btecx, 31
+  jnc   @UseRepIo
+
+  ; Check if we have Memory encryption CPUID leaf
+  mov   eax, 0x8000
+  cpuid
+  cmp   eax, 0x801f
+  jl@UseRepIo
+
+  ; Check for memory encryption feature:
+  ;  CPUID  Fn8000_001F[EAX] - Bit 1
+  ;
+  mov   eax,  0x801f
+  cpuid
+  bteax, 1
+  jnc   @UseRepIo
+
+  ; Check if memory encryption is enabled
+  ;  MSR_0xC0010131 - Bit 0 (SEV enabled)
+  ;  MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
+  mov   ecx, 0xc0010131
+  rdmsr
+
+  ; Check for (SevEsEnabled == 0 && SevEnabled == 1)
+  and   eax, 3
+  cmp   eax, 1
+  je@SevNoRepIo_Done
+
+@UseRepIo:
+  xor   eax, eax
+
+@SevNoRepIo_Done:
+  pop   edx
+  pop   ecx
+  pop   ebx
+  ret
+
+;--
+;  VOID
+;  EFIAPI
+;  IoReadFifo8 (
+;IN  UINTN Port,
+;IN  UINTN Size,
+;OUT VOID  *Buffer
+;);
+;--
+global ASM_PFX(IoReadFifo8)
+ASM_PFX(IoReadFifo8):
+pushedi
+mov dx, [esp + 8]
+mov ecx, [esp + 12]
+mov edi, [esp + 16]
+
+callSevNoRepIo; Check if we need to unroll the rep
+testeax, eax
+jnz @IoReadFifo8_NoRep
+
+cld
+rep insb
+jmp @IoReadFifo8_Done
+
+@IoReadFifo8_NoRep:
+jecxz   @IoReadFifo8_Done
+
+@IoReadFifo8_Loop:
+in  al, dx
+mov byte [edi], al
+inc edi
+loop@IoReadFifo8_Loop
+
+@IoReadFifo8_Done:
+pop edi
+ret
+
+;--
+;  VOID
+;  EFIAPI
+;  IoReadFifo16 (
+;IN  UINTN Port,
+;IN  UINTN Size,
+;OUT VOID  *Buffer
+;);
+;--
+global ASM_PFX(IoReadFifo16)
+ASM_PFX(IoReadFifo16):
+pushedi
+mov dx, [esp + 8]
+mov ecx, [esp + 12]
+mov edi, [esp + 16]
+
+callSevNoRepIo; Check if we need to unroll the rep
+testeax, eax
+jnz @IoReadFifo16_NoRep
+
+cld
+rep insw
+jmp @IoReadFifo16_Done
+
+@IoReadFifo16_NoRep:
+jecxz   @IoReadFifo16_Done
+
+@IoReadFifo16_Loop:
+in  ax, dx
+mov word [edi], ax
+add edi, 2
+loop@IoReadFifo16_Loop
+
+@IoReadFifo16_Done:
+pop edi
+ret
+
+;--
+;  VOID
+;  E

[edk2] [PATCH v5] MdePkg: BaseIoLibIntrinsic (IoLib class) library

2017-04-05 Thread Leo Duran
This patch adds an SEV-specific .INF and corresponding assembly
files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.

The new .INF only supports the IA32 and X64 architectures.

This patch follows the series "[PATCH v3 00/10] IoLib class library",
which has already being pushed upstream.

Changes since v4:
- Clean up comments in .INF file (removed reference to IPF and EBC)

Leo Duran (1):
  MdePkg: BaseIoLibIntrinsic (IoLib class) library

 .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293 +
 .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282 
 MdePkg/MdePkg.dsc  |   2 +
 3 files changed, 577 insertions(+)
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
 create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm

-- 
2.7.4

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


Re: [edk2] [PATCH v3 5/6] ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 14:18, Leif Lindholm  wrote:
> On Tue, Apr 04, 2017 at 01:30:09PM +0100, Ard Biesheuvel wrote:
>
> Should this not have come kind of commit message?
>

Oops, sorry about that. I'm pretty sure I added one at some point, but
it got lost along the way.

>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c  
>>  | 199 --
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h  
>>  | 324 -
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf 
>>  |  76 --
>>  
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>>  | 642 -
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c  
>>  | 748 
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>>  | 170 -
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h
>>  | 111 ---
>>  7 files changed, 2270 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c 
>> b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
>> deleted file mode 100644
>> index e1a6b749e4e6..
>> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
>> +++ /dev/null
>> @@ -1,199 +0,0 @@
>> -/** @file
>> -*  Pci Host Bridge support for the Xpress-RICH3 PCIe Root Complex
>> -*
>> -*  Copyright (c) 2011-2015, ARM Ltd. All rights reserved.
>> -*
>> -*  This program and the accompanying materials
>> -*  are licensed and made available under the terms and conditions of the 
>> BSD License
>> -*  which accompanies this distribution.  The full text of the license may 
>> be found at
>> -*  http://opensource.org/licenses/bsd-license.php
>> -*
>> -*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> -*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> -*
>> -**/
>> -
>> -#include "PciHostBridge.h"
>> -
>> -#include 
>> -
>> -/**
>> - * PCI Root Bridge Description
>> - */
>> -typedef struct {
>> -  UINT32  AcpiUid;
>> -  UINT64  MemAllocAttributes;
>> -} PCI_ROOT_BRIDGE_DESC;
>> -
>> -PCI_ROOT_BRIDGE_DESC PciRbDescriptions = {
>> -0,  // AcpiUid
>> -PCI_MEMORY_ALLOCATION_ATTRIBUTES// MemAllocAttributes
>> -};
>> -
>> -/**
>> - * Template for PCI Host Bridge Instance
>> - **/
>> -STATIC CONST PCI_HOST_BRIDGE_INSTANCE
>> -gPciHostBridgeInstanceTemplate = {
>> -  PCI_HOST_BRIDGE_SIGNATURE,  //Signature
>> -  NULL,   // Handle
>> -  NULL,   // ImageHandle
>> -  NULL,   // RootBridge
>> -  TRUE,   // CanRestarted
>> -  NULL,   // CpuIo
>> -  NULL,   // Metronome
>> -  {   // ResAlloc
>> -PciHbRaNotifyPhase,   //   ResAlloc.NotifyPhase
>> -PciHbRaGetNextRootBridge, //   ResAlloc.GetNextRootBridge
>> -PciHbRaGetAllocAttributes,//   ResAlloc.GetAllocAttributes
>> -PciHbRaStartBusEnumeration,   //   ResAlloc.StartBusEnumeration
>> -PciHbRaSetBusNumbers, //   ResAlloc.SetBusNumbers
>> -PciHbRaSubmitResources,   //   ResAlloc.SubmitResources
>> -PciHbRaGetProposedResources,  //   ResAlloc.GetProposedResources
>> -PciHbRaPreprocessController   //   ResAlloc.PreprocessController
>> -  }
>> -};
>> -PCI_HOST_BRIDGE_INSTANCE* gpPciHostBridgeInstance;
>> -
>> -EFI_STATUS
>> -HostBridgeConstructor (
>> -  IN OUT PCI_HOST_BRIDGE_INSTANCE** Instance,
>> -  IN  EFI_HANDLEImageHandle
>> -  )
>> -{
>> -  EFI_STATUS  Status;
>> -  PCI_HOST_BRIDGE_INSTANCE*   HostBridge;
>> -
>> -  PCI_TRACE ("HostBridgeConstructor()");
>> -
>> -  if (Instance == NULL) {
>> -return EFI_INVALID_PARAMETER;
>> -  }
>> -
>> -  HostBridge = AllocateCopyPool (sizeof (PCI_HOST_BRIDGE_INSTANCE), 
>> &gPciHostBridgeInstanceTemplate);
>> -  if (HostBridge == NULL) {
>> -PCI_TRACE ("HostBridgeConstructor(): FAIL to allocate resources");
>> -return EFI_OUT_OF_RESOURCES;
>> -  }
>> -
>> -  // It will also create a device handle for the PCI Host Bridge (as 
>> HostBridge->Handle == NULL)
>> -  Status = gBS->InstallMultipleProtocolInterfaces (
>> -&HostBridge->Handle,
>> -&gEfiPciHostBridgeResourceAllocationProtocolGuid, 
>> &HostBridge->ResAlloc,
>> -NULL
>> -);
>> -  if (EFI_ERROR (Status)) {
>> -PCI_TRACE ("HostBridgeConstructor(): FAIL to install resource 
>> allocator");
>> -FreePool (HostBridge);
>> -return EFI_DEVICE_ERROR;
>> -  } else {
>> -PCI_TRACE ("HostBridgeConstructor(): SUCCEED t

Re: [edk2] [PATCH v3 6/6] ArmPlatformPkg/ArmJunoDxe: simplify ACPI table installation

2017-04-05 Thread Leif Lindholm
On Tue, Apr 04, 2017 at 01:30:10PM +0100, Ard Biesheuvel wrote:
> Having a three way conditional with callbacks would make sense if the
> callbacks weren't (a) identical and (b) didn't return TRUE all the
> time. So get rid of the kludge.
> 

Reviewed-by: Leif Lindholm 

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 37 
> +---
>  1 file changed, 1 insertion(+), 36 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index f7e33961b4e7..da93eb582909 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -400,34 +400,6 @@ OnEndOfDxe (
>}
>  }
>  
> -STATIC
> -BOOLEAN
> -AcpiTableJunoR0Check (
> -  IN  EFI_ACPI_DESCRIPTION_HEADER *AcpiHeader
> -  )
> -{
> -  return TRUE;
> -}
> -
> -STATIC
> -BOOLEAN
> -AcpiTableJunoR1Check (
> -  IN  EFI_ACPI_DESCRIPTION_HEADER *AcpiHeader
> -  )
> -{
> -  return TRUE;
> -}
> -
> -STATIC
> -BOOLEAN
> -AcpiTableJunoR2Check (
> -  IN  EFI_ACPI_DESCRIPTION_HEADER *AcpiHeader
> -  )
> -{
> -  return TRUE;
> -}
> -
> -
>  EFI_STATUS
>  EFIAPI
>  ArmJunoEntryPoint (
> @@ -517,14 +489,7 @@ ArmJunoEntryPoint (
>//
>// Try to install the ACPI Tables
>//
> -  if (JunoRevision == JUNO_REVISION_R0) {
> -Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile, 
> AcpiTableJunoR0Check);
> -  } else if (JunoRevision == JUNO_REVISION_R1) {
> -Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile, 
> AcpiTableJunoR1Check);
> -  } else if (JunoRevision == JUNO_REVISION_R2) {
> -Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile, 
> AcpiTableJunoR2Check);
> -  }
> -
> +  Status = LocateAndInstallAcpiFromFv (&mJunoAcpiTableFile);
>ASSERT_EFI_ERROR (Status);
>  
>//
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3 5/6] ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver

2017-04-05 Thread Leif Lindholm
On Tue, Apr 04, 2017 at 01:30:09PM +0100, Ard Biesheuvel wrote:

Should this not have come kind of commit message?

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c   
> | 199 --
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h   
> | 324 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf  
> |  76 --
>  
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>  | 642 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c   
> | 748 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
> | 170 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h 
> | 111 ---
>  7 files changed, 2270 deletions(-)
> 
> diff --git 
> a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
> deleted file mode 100644
> index e1a6b749e4e6..
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
> +++ /dev/null
> @@ -1,199 +0,0 @@
> -/** @file
> -*  Pci Host Bridge support for the Xpress-RICH3 PCIe Root Complex
> -*
> -*  Copyright (c) 2011-2015, ARM Ltd. All rights reserved.
> -*
> -*  This program and the accompanying materials
> -*  are licensed and made available under the terms and conditions of the BSD 
> License
> -*  which accompanies this distribution.  The full text of the license may be 
> found at
> -*  http://opensource.org/licenses/bsd-license.php
> -*
> -*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -*
> -**/
> -
> -#include "PciHostBridge.h"
> -
> -#include 
> -
> -/**
> - * PCI Root Bridge Description
> - */
> -typedef struct {
> -  UINT32  AcpiUid;
> -  UINT64  MemAllocAttributes;
> -} PCI_ROOT_BRIDGE_DESC;
> -
> -PCI_ROOT_BRIDGE_DESC PciRbDescriptions = {
> -0,  // AcpiUid
> -PCI_MEMORY_ALLOCATION_ATTRIBUTES// MemAllocAttributes
> -};
> -
> -/**
> - * Template for PCI Host Bridge Instance
> - **/
> -STATIC CONST PCI_HOST_BRIDGE_INSTANCE
> -gPciHostBridgeInstanceTemplate = {
> -  PCI_HOST_BRIDGE_SIGNATURE,  //Signature
> -  NULL,   // Handle
> -  NULL,   // ImageHandle
> -  NULL,   // RootBridge
> -  TRUE,   // CanRestarted
> -  NULL,   // CpuIo
> -  NULL,   // Metronome
> -  {   // ResAlloc
> -PciHbRaNotifyPhase,   //   ResAlloc.NotifyPhase
> -PciHbRaGetNextRootBridge, //   ResAlloc.GetNextRootBridge
> -PciHbRaGetAllocAttributes,//   ResAlloc.GetAllocAttributes
> -PciHbRaStartBusEnumeration,   //   ResAlloc.StartBusEnumeration
> -PciHbRaSetBusNumbers, //   ResAlloc.SetBusNumbers
> -PciHbRaSubmitResources,   //   ResAlloc.SubmitResources
> -PciHbRaGetProposedResources,  //   ResAlloc.GetProposedResources
> -PciHbRaPreprocessController   //   ResAlloc.PreprocessController
> -  }
> -};
> -PCI_HOST_BRIDGE_INSTANCE* gpPciHostBridgeInstance;
> -
> -EFI_STATUS
> -HostBridgeConstructor (
> -  IN OUT PCI_HOST_BRIDGE_INSTANCE** Instance,
> -  IN  EFI_HANDLEImageHandle
> -  )
> -{
> -  EFI_STATUS  Status;
> -  PCI_HOST_BRIDGE_INSTANCE*   HostBridge;
> -
> -  PCI_TRACE ("HostBridgeConstructor()");
> -
> -  if (Instance == NULL) {
> -return EFI_INVALID_PARAMETER;
> -  }
> -
> -  HostBridge = AllocateCopyPool (sizeof (PCI_HOST_BRIDGE_INSTANCE), 
> &gPciHostBridgeInstanceTemplate);
> -  if (HostBridge == NULL) {
> -PCI_TRACE ("HostBridgeConstructor(): FAIL to allocate resources");
> -return EFI_OUT_OF_RESOURCES;
> -  }
> -
> -  // It will also create a device handle for the PCI Host Bridge (as 
> HostBridge->Handle == NULL)
> -  Status = gBS->InstallMultipleProtocolInterfaces (
> -&HostBridge->Handle,
> -&gEfiPciHostBridgeResourceAllocationProtocolGuid, 
> &HostBridge->ResAlloc,
> -NULL
> -);
> -  if (EFI_ERROR (Status)) {
> -PCI_TRACE ("HostBridgeConstructor(): FAIL to install resource 
> allocator");
> -FreePool (HostBridge);
> -return EFI_DEVICE_ERROR;
> -  } else {
> -PCI_TRACE ("HostBridgeConstructor(): SUCCEED to install resource 
> allocator");
> -  }
> -
> -  Status = gBS->LocateProtocol (&gEfiCpuIo2ProtocolGuid, NULL, (VOID 
> **)(&(HostBridge->CpuIo)));
> -  ASSERT_EFI_ERROR (Status);
> -
> -  Status = gBS->LocateProtocol (&gEfiMetronomeArchProtocolGuid, NULL, (VOID 
> **)(&(HostB

Re: [edk2] [PATCH v3 4/6] ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0

2017-04-05 Thread Leif Lindholm
On Tue, Apr 04, 2017 at 01:30:08PM +0100, Ard Biesheuvel wrote:
> The ArmJunoDxe driver code registers a callback for the EndOfDxe event,
> at which time it does some manipulation of the PCI peripherals on the
> board. Given that R0 has no working PCIe, we can omit the registration
> of the callback altogether.

This is a nice simplification.
However, could the final sentence of the commit message be changed to

"
Given that R0 has no working PCIe, instead of conditionally
performing these operations, omit the registration of the
callback altogether on that platform.
"

With that:
Reviewed-by: Leif Lindholm 

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 43 
> +---
>  1 file changed, 19 insertions(+), 24 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index 14ff189a3078..f7e33961b4e7 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -379,7 +379,6 @@ OnEndOfDxe (
>EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>EFI_HANDLEHandle;
>EFI_STATUSStatus;
> -  UINT32JunoRevision;
>  
>//
>// PCI Root Complex initialization
> @@ -395,13 +394,9 @@ OnEndOfDxe (
>Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath, 
> FALSE);
>ASSERT_EFI_ERROR (Status);
>  
> -  GetJunoRevision (JunoRevision);
> -
> -  if (JunoRevision != JUNO_REVISION_R0) {
> -Status = ArmJunoSetNicMacAddress ();
> -if (EFI_ERROR (Status)) {
> -  DEBUG ((DEBUG_ERROR, "ArmJunoDxe: Failed to set Marvell Yukon NIC MAC 
> address\n"));
> -}
> +  Status = ArmJunoSetNicMacAddress ();
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "ArmJunoDxe: Failed to set Marvell Yukon NIC MAC 
> address\n"));
>}
>  }
>  
> @@ -511,22 +506,6 @@ ArmJunoEntryPoint (
>  }
>}
>  
> -  //
> -  // Create an event belonging to the "gEfiEndOfDxeEventGroupGuid" group.
> -  // The "OnEndOfDxe()" function is declared as the call back function.
> -  // It will be called at the end of the DXE phase when an event of the
> -  // same group is signalled to inform about the end of the DXE phase.
> -  // Install the INSTALL_FDT_PROTOCOL protocol.
> -  //
> -  Status = gBS->CreateEventEx (
> -  EVT_NOTIFY_SIGNAL,
> -  TPL_CALLBACK,
> -  OnEndOfDxe,
> -  NULL,
> -  &gEfiEndOfDxeEventGroupGuid,
> -  &EndOfDxeEvent
> -  );
> -
>// Install dynamic Shell command to run baremetal binaries.
>Status = ShellDynCmdRunAxfInstall (ImageHandle);
>if (EFI_ERROR (Status)) {
> @@ -555,6 +534,22 @@ ArmJunoEntryPoint (
>  // Enable PCI enumeration
>  PcdSetBool (PcdPciDisableBusEnumeration, FALSE);
>  
> +//
> +// Create an event belonging to the "gEfiEndOfDxeEventGroupGuid" group.
> +// The "OnEndOfDxe()" function is declared as the call back function.
> +// It will be called at the end of the DXE phase when an event of the
> +// same group is signalled to inform about the end of the DXE phase.
> +// Install the INSTALL_FDT_PROTOCOL protocol.
> +//
> +Status = gBS->CreateEventEx (
> +EVT_NOTIFY_SIGNAL,
> +TPL_CALLBACK,
> +OnEndOfDxe,
> +NULL,
> +&gEfiEndOfDxeEventGroupGuid,
> +&EndOfDxeEvent
> +);
> +
>  // Declare the related ACPI Tables
>  EfiCreateProtocolNotifyEvent (
>  &gEfiAcpiTableProtocolGuid,
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3 1/6] ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 14:11, Ard Biesheuvel  wrote:
> On 5 April 2017 at 14:09, Leif Lindholm  wrote:
>> On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
>>> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
>>> cloning the ShutdownUefiBootServices() routine into a local source
>>> file; this is the only BdsLib feature 'runaxf' depends on.
>>
>> I was going to go through these individually and give a R-b for the
>> whole series at the end if I didn't come across anything, but I'd just
>> like to add for this one:
>>
>> This is abslutely the right thing to do - BdsLib only had this
>> functionality due to the LinuxLoader, and it could be deleted now (but
>> I guess we're planning to get rid of the whole thing?).
>>
>
> I'd like to avoid doing any 'improvements' to BdsLib while it's on its
> way you

way *out*

> -- once AndroidFastBootApp is the last remaining user, we can
> fold whatever it uses into it instead.
>
>
>> Reviewed-by: Leif Lindholm 
>>
>
> Thanks
>
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf |  1 -
>>>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  | 58 
>>> +++-
>>>  2 files changed, 57 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
>>> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
>>> index 9a34f12a..7d15f6934608 100644
>>> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
>>> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
>>> @@ -43,7 +43,6 @@ [Packages]
>>>  [LibraryClasses]
>>>ArmLib
>>>BaseLib
>>> -  BdsLib
>>>DebugLib
>>>HiiLib
>>>ShellLib
>>> diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c 
>>> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
>>> index 2abfb6cc1053..9f4fc780307d 100644
>>> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
>>> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
>>> @@ -21,7 +21,6 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -#include 
>>>  #include 
>>>  #include 
>>>
>>> @@ -35,6 +34,63 @@
>>>  typedef VOID (*ELF_ENTRYPOINT)(UINTN arg0, UINTN arg1,
>>> UINTN arg2, UINTN arg3);
>>>
>>> +STATIC
>>> +EFI_STATUS
>>> +ShutdownUefiBootServices (
>>> +  VOID
>>> +  )
>>> +{
>>> +  EFI_STATUS  Status;
>>> +  UINTN   MemoryMapSize;
>>> +  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
>>> +  UINTN   MapKey;
>>> +  UINTN   DescriptorSize;
>>> +  UINT32  DescriptorVersion;
>>> +  UINTN   Pages;
>>> +
>>> +  MemoryMap = NULL;
>>> +  MemoryMapSize = 0;
>>> +  Pages = 0;
>>> +
>>> +  do {
>>> +Status = gBS->GetMemoryMap (
>>> +&MemoryMapSize,
>>> +MemoryMap,
>>> +&MapKey,
>>> +&DescriptorSize,
>>> +&DescriptorVersion
>>> +);
>>> +if (Status == EFI_BUFFER_TOO_SMALL) {
>>> +
>>> +  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
>>> +  MemoryMap = AllocatePages (Pages);
>>> +
>>> +  //
>>> +  // Get System MemoryMap
>>> +  //
>>> +  Status = gBS->GetMemoryMap (
>>> +  &MemoryMapSize,
>>> +  MemoryMap,
>>> +  &MapKey,
>>> +  &DescriptorSize,
>>> +  &DescriptorVersion
>>> +  );
>>> +}
>>> +
>>> +// Don't do anything between the GetMemoryMap() and ExitBootServices()
>>> +if (!EFI_ERROR(Status)) {
>>> +  Status = gBS->ExitBootServices (gImageHandle, MapKey);
>>> +  if (EFI_ERROR(Status)) {
>>> +FreePages (MemoryMap, Pages);
>>> +MemoryMap = NULL;
>>> +MemoryMapSize = 0;
>>> +  }
>>> +}
>>> +  } while (EFI_ERROR(Status));
>>> +
>>> +  return Status;
>>> +}
>>> +
>>>
>>>  STATIC
>>>  EFI_STATUS
>>> --
>>> 2.9.3
>>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v4] MdePkg: BaseIoLibIntrinsic (IoLib class) library

2017-04-05 Thread Duran, Leo
Liming,
Yes, agreed... I'll push a v5.
Leo.

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Tuesday, April 04, 2017 8:48 PM
> To: Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Kinney, Michael D ; Singh, Brijesh
> 
> Subject: RE: [edk2] [PATCH v4] MdePkg: BaseIoLibIntrinsic (IoLib class) 
> library
> 
> Leo:
>   I just find one minor issue. Could you help update the comments in new
> module INF file?
> 
> > +#  Instance of I/O Library using compiler intrinsics.
> > +#
> > +#  I/O Library that uses compiler intrinsics to perform IN and OUT
> > +instructions #  for IA-32 and x64.  On IPF, I/O port requests are 
> > translated
> into MMIO requests.
> > +#  MMIO requests are forwarded directly to memory.  For EBC, I/O port
> > +requests #  ASSERT().
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Leo Duran
> > Sent: Tuesday, April 4, 2017 10:11 PM
> > To: edk2-de...@ml01.01.org
> > Cc: Kinney, Michael D ; Brijesh Singh
> > ; Leo Duran ; Gao, Liming
> > 
> > Subject: [edk2] [PATCH v4] MdePkg: BaseIoLibIntrinsic (IoLib class)
> > library
> >
> > This patch adds an SEV-specific .INF and corresponding assembly files,
> > to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV
> > feature is enabled under a hypervisor environment.
> >
> > The new .INF only supports the IA32 and X64 architectures.
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Brijesh Singh 
> > Signed-off-by: Leo Duran 
> > ---
> >  .../BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf   |  61 +
> >  .../Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm | 293
> > +
> .../Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm  | 282
> 
> >  MdePkg/MdePkg.dsc  |   2 +
> >  4 files changed, 638 insertions(+)
> >  create mode 100644
> > MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> >  create mode 100644
> > MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> >  create mode 100644
> > MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm
> >
> > diff --git
> > a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> > b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> > new file mode 100644
> > index 000..4544f23
> > --- /dev/null
> > +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> > @@ -0,0 +1,61 @@
> > +## @file
> > +#  Instance of I/O Library using compiler intrinsics.
> > +#
> > +#  I/O Library that uses compiler intrinsics to perform IN and OUT
> > +instructions #  for IA-32 and x64.  On IPF, I/O port requests are 
> > translated
> into MMIO requests.
> > +#  MMIO requests are forwarded directly to memory.  For EBC, I/O port
> > +requests #  ASSERT().
> > +#
> > +#  Copyright (c) 2007 - 2015, Intel Corporation. All rights
> > +reserved. #  Portions copyright (c) 2008 - 2009, Apple Inc. All
> > +rights reserved. #  Copyright (c) 2017, AMD Incorporated. All
> > +rights reserved. # #  This program and the accompanying materials
> > +#  are licensed and made available under the terms and conditions of
> > +the BSD License #  which accompanies this distribution. The full text
> > +of the license may be found at #  http://opensource.org/licenses/bsd-
> license.php.
> > +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > +BASIS, #  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > +#
> > +##
> > +
> > +[Defines]
> > +  INF_VERSION= 0x00010005
> > +  BASE_NAME  = BaseIoLibIntrinsicSev
> > +  MODULE_UNI_FILE= BaseIoLibIntrinsic.uni
> > +  FILE_GUID  = 93742f95-6e71-4581-b600-8e1da443f95a
> > +  MODULE_TYPE= BASE
> > +  VERSION_STRING = 1.0
> > +  LIBRARY_CLASS  = IoLib
> > +
> > +
> > +#
> > +#  VALID_ARCHITECTURES   = IA32 X64
> > +#
> > +
> > +[Sources]
> > +  IoLibMmioBuffer.c
> > +  BaseIoLibIntrinsicInternal.h
> > +  IoHighLevel.c
> > +
> > +[Sources.IA32]
> > +  IoLibGcc.c| GCC
> > +  IoLibMsc.c| MSFT
> > +  IoLibIcc.c| INTEL
> > +  IoLib.c
> > +  Ia32/IoFifoSev.nasm
> > +
> > +[Sources.X64]
> > +  IoLibGcc.c| GCC
> > +  IoLibMsc.c| MSFT
> > +  IoLibIcc.c| INTEL
> > +  IoLib.c
> > +  X64/IoFifoSev.nasm
> > +
> > +[Packages]
> > +  MdePkg/MdePkg.dec
> > +
> > +[LibraryClasses]
> > +  DebugLib
> > +  BaseLib
> > +
> > diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> > b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> > new file mode 100644
> > index 000..9adb972
> > --- /dev/null
> > +++ b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
> > @@ -0,0 +1,293 @@
> > +;
> > +--
> > +;
> > +; Copyright (c) 20

Re: [edk2] [PATCH v3 1/6] ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 14:09, Leif Lindholm  wrote:
> On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
>> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
>> cloning the ShutdownUefiBootServices() routine into a local source
>> file; this is the only BdsLib feature 'runaxf' depends on.
>
> I was going to go through these individually and give a R-b for the
> whole series at the end if I didn't come across anything, but I'd just
> like to add for this one:
>
> This is abslutely the right thing to do - BdsLib only had this
> functionality due to the LinuxLoader, and it could be deleted now (but
> I guess we're planning to get rid of the whole thing?).
>

I'd like to avoid doing any 'improvements' to BdsLib while it's on its
way you -- once AndroidFastBootApp is the last remaining user, we can
fold whatever it uses into it instead.


> Reviewed-by: Leif Lindholm 
>

Thanks

>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf |  1 -
>>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  | 58 
>> +++-
>>  2 files changed, 57 insertions(+), 2 deletions(-)
>>
>> diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
>> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
>> index 9a34f12a..7d15f6934608 100644
>> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
>> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
>> @@ -43,7 +43,6 @@ [Packages]
>>  [LibraryClasses]
>>ArmLib
>>BaseLib
>> -  BdsLib
>>DebugLib
>>HiiLib
>>ShellLib
>> diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c 
>> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
>> index 2abfb6cc1053..9f4fc780307d 100644
>> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
>> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
>> @@ -21,7 +21,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>
>> @@ -35,6 +34,63 @@
>>  typedef VOID (*ELF_ENTRYPOINT)(UINTN arg0, UINTN arg1,
>> UINTN arg2, UINTN arg3);
>>
>> +STATIC
>> +EFI_STATUS
>> +ShutdownUefiBootServices (
>> +  VOID
>> +  )
>> +{
>> +  EFI_STATUS  Status;
>> +  UINTN   MemoryMapSize;
>> +  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
>> +  UINTN   MapKey;
>> +  UINTN   DescriptorSize;
>> +  UINT32  DescriptorVersion;
>> +  UINTN   Pages;
>> +
>> +  MemoryMap = NULL;
>> +  MemoryMapSize = 0;
>> +  Pages = 0;
>> +
>> +  do {
>> +Status = gBS->GetMemoryMap (
>> +&MemoryMapSize,
>> +MemoryMap,
>> +&MapKey,
>> +&DescriptorSize,
>> +&DescriptorVersion
>> +);
>> +if (Status == EFI_BUFFER_TOO_SMALL) {
>> +
>> +  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
>> +  MemoryMap = AllocatePages (Pages);
>> +
>> +  //
>> +  // Get System MemoryMap
>> +  //
>> +  Status = gBS->GetMemoryMap (
>> +  &MemoryMapSize,
>> +  MemoryMap,
>> +  &MapKey,
>> +  &DescriptorSize,
>> +  &DescriptorVersion
>> +  );
>> +}
>> +
>> +// Don't do anything between the GetMemoryMap() and ExitBootServices()
>> +if (!EFI_ERROR(Status)) {
>> +  Status = gBS->ExitBootServices (gImageHandle, MapKey);
>> +  if (EFI_ERROR(Status)) {
>> +FreePages (MemoryMap, Pages);
>> +MemoryMap = NULL;
>> +MemoryMapSize = 0;
>> +  }
>> +}
>> +  } while (EFI_ERROR(Status));
>> +
>> +  return Status;
>> +}
>> +
>>
>>  STATIC
>>  EFI_STATUS
>> --
>> 2.9.3
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3 1/6] ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency

2017-04-05 Thread Leif Lindholm
On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
> cloning the ShutdownUefiBootServices() routine into a local source
> file; this is the only BdsLib feature 'runaxf' depends on.

I was going to go through these individually and give a R-b for the
whole series at the end if I didn't come across anything, but I'd just
like to add for this one:

This is abslutely the right thing to do - BdsLib only had this
functionality due to the LinuxLoader, and it could be deleted now (but
I guess we're planning to get rid of the whole thing?).

Reviewed-by: Leif Lindholm 

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf |  1 -
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  | 58 
> +++-
>  2 files changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
> index 9a34f12a..7d15f6934608 100644
> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
> @@ -43,7 +43,6 @@ [Packages]
>  [LibraryClasses]
>ArmLib
>BaseLib
> -  BdsLib
>DebugLib
>HiiLib
>ShellLib
> diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c 
> b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> index 2abfb6cc1053..9f4fc780307d 100644
> --- a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> +++ b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -35,6 +34,63 @@
>  typedef VOID (*ELF_ENTRYPOINT)(UINTN arg0, UINTN arg1,
> UINTN arg2, UINTN arg3);
>  
> +STATIC
> +EFI_STATUS
> +ShutdownUefiBootServices (
> +  VOID
> +  )
> +{
> +  EFI_STATUS  Status;
> +  UINTN   MemoryMapSize;
> +  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
> +  UINTN   MapKey;
> +  UINTN   DescriptorSize;
> +  UINT32  DescriptorVersion;
> +  UINTN   Pages;
> +
> +  MemoryMap = NULL;
> +  MemoryMapSize = 0;
> +  Pages = 0;
> +
> +  do {
> +Status = gBS->GetMemoryMap (
> +&MemoryMapSize,
> +MemoryMap,
> +&MapKey,
> +&DescriptorSize,
> +&DescriptorVersion
> +);
> +if (Status == EFI_BUFFER_TOO_SMALL) {
> +
> +  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
> +  MemoryMap = AllocatePages (Pages);
> +
> +  //
> +  // Get System MemoryMap
> +  //
> +  Status = gBS->GetMemoryMap (
> +  &MemoryMapSize,
> +  MemoryMap,
> +  &MapKey,
> +  &DescriptorSize,
> +  &DescriptorVersion
> +  );
> +}
> +
> +// Don't do anything between the GetMemoryMap() and ExitBootServices()
> +if (!EFI_ERROR(Status)) {
> +  Status = gBS->ExitBootServices (gImageHandle, MapKey);
> +  if (EFI_ERROR(Status)) {
> +FreePages (MemoryMap, Pages);
> +MemoryMap = NULL;
> +MemoryMapSize = 0;
> +  }
> +}
> +  } while (EFI_ERROR(Status));
> +
> +  return Status;
> +}
> +
>  
>  STATIC
>  EFI_STATUS
> -- 
> 2.9.3
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Laszlo Ersek
On 04/05/17 14:37, Phil Dennis-Jordan wrote:
>> In fact, above you already have a (BitsPerPixel == 32) check. At the end
>> of that block, you could set PixelMask to MAX_UINT32 explicitly. And,
>> you could add an "else" branch, simply with
>>
>>   PixelMask = (1u << (BitsPerPixel - 1)) - 1;
>>
>> What do you think?
> I'm pretty sure you mean
> 
>   PixelMask = (0x1u << BitsPerPixel) - 1;

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


[edk2] [PATCH v4 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Phil Dennis-Jordan
From: Phil Dennis-Jordan 

In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
a basic version of VMWare's SVGA display device. Drivers for this
device exist for some guest OSes which do not support Qemu's other
display adapters, so supporting it in OVMF is useful in conjunction
with those OSes.

This change adds support for the SVGA device's framebuffer to
QemuVideoDxe's graphics output protocol implementation, based on
VMWare's documentation. The most basic initialisation, framebuffer
layout query, and mode setting operations are implemented.

The device relies on port-based 32-bit I/O, unfortunately on misaligned
addresses. This limits the driver's support to the x86 family of
platforms.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan 
---

Notes:
v2:
- Unaligned I/O helper functions moved to separate commit [Laszlo]
- Multi-line function call whitespace fixes.

v3:
- Dropped the "2" from "SVGA2" where appropriate. [Jordan, Laszlo]
- Renamed various struct fields and functions with consistent prefixes 
[Laszlo]
- #include orders fixed [Laszlo]
- Renamedi/moved lots of local variables to comply with convention. [Laszlo]
- Added error checking to PCI BAR queries. [Laszlo]
- Moved some function definitions around for better grouping. [Laszlo]
- Fixed ClearScreen() to use the correct VRAM BAR. [Laszlo]
- Changed modelist initialisation to fetch all mode data on startup, so mode
  queries can return everything including channel masks without hitting the
  device. Mask calculations hopefully make more sense now. [Laszlo]
- Whitespace fixes. [Laszlo]
- Fixed a memory leak in BAR query.

v4:
- Simplified mode info pixel mask calculation & PCI BAR OOB check. [Laszlo]
- Replaced struct assignment with CopyMem. [Laszlo]
- Whitespace & comment typo fixes. [Laszlo]

 OvmfPkg/QemuVideoDxe/Qemu.h   |  29 
 OvmfPkg/QemuVideoDxe/Driver.c | 128 +++-
 OvmfPkg/QemuVideoDxe/Gop.c|  61 +++-
 OvmfPkg/QemuVideoDxe/Initialize.c | 161 
 4 files changed, 372 insertions(+), 7 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index 2ce37defc5b8..7fbb25b3efd3 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -92,6 +92,7 @@ typedef enum {
   QEMU_VIDEO_CIRRUS_5446,
   QEMU_VIDEO_BOCHS,
   QEMU_VIDEO_BOCHS_MMIO,
+  QEMU_VIDEO_VMWARE_SVGA,
 } QEMU_VIDEO_VARIANT;
 
 typedef struct {
@@ -115,10 +116,13 @@ typedef struct {
   //
   UINTN MaxMode;
   QEMU_VIDEO_MODE_DATA  *ModeData;
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *VmwareSvgaModeInfo;
 
   QEMU_VIDEO_VARIANTVariant;
   FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
   UINTN FrameBufferBltConfigureSize;
+  UINT8 FrameBufferVramBarIndex;
+  UINT16VmwareSvgaBasePort;
 } QEMU_VIDEO_PRIVATE_DATA;
 
 ///
@@ -502,9 +506,34 @@ QemuVideoBochsModeSetup (
   BOOLEAN  IsQxl
   );
 
+EFI_STATUS
+QemuVideoVmwareSvgaModeSetup (
+  QEMU_VIDEO_PRIVATE_DATA *Private
+  );
+
 VOID
 InstallVbeShim (
   IN CONST CHAR16 *CardName,
   IN EFI_PHYSICAL_ADDRESS FrameBufferBase
   );
+
+VOID
+VmwareSvgaWrite (
+  QEMU_VIDEO_PRIVATE_DATA *Private,
+  UINT16  Register,
+  UINT32  Value
+  );
+
+UINT32
+VmwareSvgaRead (
+  QEMU_VIDEO_PRIVATE_DATA *Private,
+  UINT16  Register
+  );
+
+VOID
+InitializeVmwareSvgaGraphicsMode (
+  QEMU_VIDEO_PRIVATE_DATA  *Private,
+  QEMU_VIDEO_BOCHS_MODES   *ModeData
+  );
+
 #endif
diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index fc8025ec46de..2ed1506a1381 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -14,8 +14,10 @@
 
 **/
 
-#include "Qemu.h"
+#include 
 #include 
+#include "Qemu.h"
+#include "UnalignedIoInternal.h"
 
 EFI_DRIVER_BINDING_PROTOCOL gQemuVideoDriverBinding = {
   QemuVideoControllerDriverSupported,
@@ -58,6 +60,11 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
 QEMU_VIDEO_BOCHS_MMIO,
 L"QEMU VirtIO VGA"
 },{
+VMWARE_PCI_VENDOR_ID_VMWARE,
+VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2,
+QEMU_VIDEO_VMWARE_SVGA,
+L"QEMU VMWare SVGA"
+},{
 0 /* end of list */
 }
 };
@@ -242,6 +249,7 @@ QemuVideoControllerDriverStart (
 goto ClosePciIo;
   }
   Private->Variant = Card->Variant;
+  Private->FrameBufferVramBarIndex = PCI_BAR_IDX0;
 
   //
   // IsQxl is based on the detected Card->Variant, which at a later point might
@@ -317,6 +325,58 @@ QemuVideoControllerDriverStart (
   }
 
   //
+  // Check if accessing Vmware SVGA interface works
+  //
+  if (Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
+ 

[edk2] [PATCH v4 2/3] OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O.

2017-04-05 Thread Phil Dennis-Jordan
From: Phil Dennis-Jordan 

The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. (The register value port has an offset of 1 and requires
32 bit wide read/write access.)

The EFI_PCI_IO_PROTOCOL's Io.Read/Io.Write functions do not support
such unaligned I/O.

Before a driver for this device can be added to QemuVideoDxe, helper
functions for unaligned I/O are therefore required. This adds the
functions UnalignedIoWrite32 and UnalignedIoRead32, based on IoLib's
IoWrite32 and IoRead32, for the Ia32 and X64 architectures. Port I/O
requires inline assembly, so implementations are provided for the GCC,
ICC, and Microsoft compiler families. Such I/O is not possible on other
architectures, a dummy (ASSERT()ing) implementation is therefore
provided to satisfy the linker.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Laszlo Ersek 
---

Notes:
v2:
- Separate commit for the unaligned I/O helper functions. [Laszlo]
- Dummy implementations return values despite ASSERT(). [Laszlo]
- Build failure in ArmVirtPkg fixed. [Laszlo]
- More consistent API docs and function ordering.

v3:
- Fixed typos in commit message [Laszlo]
- Added Suggested-by: tag [Laszlo]
- Rewrapped comment lines to 79 chars [Laszlo]
- Corrected whitespace in function calls [Laszlo]
- EFIAPI dropped. [Laszlo]
- Fixed return value in dummy UnsignedIoWrite32 [Laszlo]
- Dropped "N" imm8 constraint in GCC inline asm [Laszlo]

v4: (no changes)

 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  6 ++
 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h| 59 +++
 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c | 70 +
 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c | 80 
 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c | 78 +++
 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c | 66 
 6 files changed, 359 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf 
b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
index affb6ffd88e0..346a5aed94fa 100644
--- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
+++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
@@ -41,6 +41,12 @@ [Sources.common]
 
 [Sources.Ia32, Sources.X64]
   VbeShim.c
+  UnalignedIoGcc.c| GCC
+  UnalignedIoMsc.c| MSFT
+  UnalignedIoIcc.c| INTEL
+
+[Sources.IPF, Sources.EBC, Sources.ARM, Sources.AARCH64]
+  UnalignedIoUnsupported.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h 
b/OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
new file mode 100644
index ..234de6c21bd1
--- /dev/null
+++ b/OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
@@ -0,0 +1,59 @@
+/** @file
+  Unaligned port I/O, with implementations for various x86 compilers and a
+  dummy for platforms which do not support unaligned port I/O.
+
+  Copyright (c) 2017, Phil Dennis-Jordan.
+  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 _UNALIGNED_IO_INTERNAL_H_
+#define _UNALIGNED_IO_INTERNAL_H_
+
+/**
+  Performs a 32-bit write to the specified, possibly unaligned I/O-type 
address.
+
+  Writes the 32-bit I/O port specified by Port with the value specified by 
Value
+  and returns Value. This function must guarantee that all I/O read and write
+  operations are serialized.
+
+  If 32-bit unaligned I/O port operations are not supported, then ASSERT().
+
+  @param[in]  Port   I/O port address
+  @param[in]  Value  32-bit word to write
+
+  @return The value written to the I/O port.
+
+**/
+UINT32
+UnalignedIoWrite32 (
+  IN  UINTN Port,
+  IN  UINT32Value
+  );
+
+/**
+  Reads a 32-bit word from the specified, possibly unaligned I/O-type address.
+
+  Reads the 32-bit I/O port specified by Port. The 32-bit read value is
+  returned. This function must guarantee that all I/O read and write operations
+  are serialized.
+
+  If 32-bit unaligned I/O port operations are not supported, then ASSERT().
+
+  @param[in]  Port  The I/O port to read.
+
+  @return The value read.
+
+**/
+UINT32
+UnalignedIoRead32 (
+  IN  UINTN Port
+  );
+
+#endif
diff --git a/OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c 
b/OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c
new file mode 100644
index ..105d55d3b903
--- /dev/null
+++ b/OvmfPkg/QemuVideoDxe/UnalignedIoGcc.

[edk2] [PATCH v4 1/3] OvmfPkg: VMWare SVGA display device register definitions

2017-04-05 Thread Phil Dennis-Jordan
From: Phil Dennis-Jordan 

This adds a header file defining symbolic constants for the VMWare SVGA
virtual display device in preparation for supporting it in
QemuVideoDxe.

It is mostly an extract of the file lib/vmware/svga_reg.h from commit
329dd537456f93a806841ec8a8213aed11395def of VMWare's vmware-svga
repository at git://git.code.sf.net/p/vmware-svga/git (See also
http://vmware-svga.sourceforge.net/ )

Only the bare essentials necessary for initialisation, modesetting and
framebuffer access have been kept from the original file; macro names
have been prefixed with VMWARE_SVGA_ instead of SVGA2_, and the enum
definition has been adapted to comply with EDK2 naming conventions.

The original file was released by VMWare under the MIT license, this
has been retained.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Laszlo Ersek 
---

Notes:
v2:
- New, custom header file instead of importing VMWare's verbatim. [Laszlo]

v3:
- Prefixed macros with VMWARE_SVGA_ instead of SVGA2_ [Jordan, Laszlo]
- Adjusted enum definition to comply with EDK2 convention [Jordan, Laszlo]
- Tweaks to definitions of numeric constants [Laszlo]
- Renamed the file to fit with convention [Jordan, Laszlo]
- Dropped the "2" from SVGA2 wherever appropriate.

v4: (no changes)

 OvmfPkg/Include/IndustryStandard/VmwareSvga.h | 104 
 1 file changed, 104 insertions(+)

diff --git a/OvmfPkg/Include/IndustryStandard/VmwareSvga.h 
b/OvmfPkg/Include/IndustryStandard/VmwareSvga.h
new file mode 100644
index ..693d44bab6c3
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/VmwareSvga.h
@@ -0,0 +1,104 @@
+/** @file
+
+  Macro and enum definitions of a subset of port numbers, register identifiers
+  and values required for driving the VMWare SVGA virtual display adapter,
+  also implemented by Qemu.
+
+  This file's contents was extracted from file lib/vmware/svga_reg.h in commit
+  329dd537456f93a806841ec8a8213aed11395def of VMWare's vmware-svga repository:
+  git://git.code.sf.net/p/vmware-svga/git
+
+
+  Copyright 1998-2009 VMware, Inc.  All rights reserved.
+  Portions Copyright 2017 Phil Dennis-Jordan 
+
+  Permission is hereby granted, free of charge, to any person
+  obtaining a copy of this software and associated documentation
+  files (the "Software"), to deal in the Software without
+  restriction, including without limitation the rights to use, copy,
+  modify, merge, publish, distribute, sublicense, and/or sell copies
+  of the Software, and to permit persons to whom the Software is
+  furnished to do so, subject to the following conditions:
+
+  The above copyright notice and this permission notice shall be
+  included in all copies or substantial portions of the Software.
+
+  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+  ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+  SOFTWARE.
+
+**/
+
+#ifndef _VMWARE_SVGA_H_
+#define _VMWARE_SVGA_H_
+
+#include 
+
+//
+// IDs for recognising the device
+//
+#define VMWARE_PCI_VENDOR_ID_VMWARE0x15AD
+#define VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2  0x0405
+
+//
+// I/O port BAR offsets for register selection and read/write.
+//
+// The register index is written to the 32-bit index port, followed by a 32-bit
+// read or write on the value port to read or set that register's contents.
+//
+#define VMWARE_SVGA_INDEX_PORT 0x0
+#define VMWARE_SVGA_VALUE_PORT 0x1
+
+//
+// Some of the device's register indices for basic framebuffer functionality.
+//
+typedef enum {
+  VmwareSvgaRegId = 0,
+  VmwareSvgaRegEnable = 1,
+  VmwareSvgaRegWidth = 2,
+  VmwareSvgaRegHeight = 3,
+  VmwareSvgaRegMaxWidth = 4,
+  VmwareSvgaRegMaxHeight = 5,
+
+  VmwareSvgaRegBitsPerPixel = 7,
+
+  VmwareSvgaRegRedMask = 9,
+  VmwareSvgaRegGreenMask = 10,
+  VmwareSvgaRegBlueMask = 11,
+  VmwareSvgaRegBytesPerLine = 12,
+
+  VmwareSvgaRegFbOffset = 14,
+
+  VmwareSvgaRegFbSize = 16,
+  VmwareSvgaRegCapabilities = 17,
+
+  VmwareSvgaRegHostBitsPerPixel = 28,
+} VMWARE_SVGA_REGISTER;
+
+//
+// Values used with VmwareSvgaRegId for sanity-checking the device and getting
+// its version.
+//
+#define VMWARE_SVGA_MAGIC  0x90U
+#define VMWARE_SVGA_MAKE_ID(ver)   (VMWARE_SVGA_MAGIC << 8 | (ver))
+
+#define VMWARE_SVGA_VERSION_2  2
+#define VMWARE_SVGA_ID_2   VMWARE_SVGA_MAKE_ID (VMWARE_SVGA_VERSION_2)
+
+#define VMWARE_SVGA_VERSION_1  1
+#define VMWARE_SVGA_ID_1   VMWARE_SVGA_MAKE_ID (VMWARE_SVGA_VERSION_1)
+
+#define VMWARE_SVGA_VERSION_0  

[edk2] [PATCH v4 0/3] OvmfPkg/QemuVideoDxe: Add VMWare SVGA framebuffer support

2017-04-05 Thread Phil Dennis-Jordan
This extends the QemuVideoDxe driver to support the VMWare SVGA display
device implemented by Qemu. Drivers for this device exist for guest OSes
which do not support Qemu's other display adapters, so supporting it in
OVMF is useful in conjunction with those OSes.

I've tried to follow the existing pattern for device-specific code in
OVMF's QemuVideoDxe driver as much as possible, with a minimum of
additional code.

For the functionality this driver uses, 2 I/O ports are used with
32-bit wide reads and writes. Unfortunately, one of them is not 32-bit
aligned. This is fine as far as x86/x86-64 is concerned, but neither
EDK2's IoLib nor other platforms support such an access pattern.
This issue was already encountered/discussed on the edk2-devel list 4
years ago: http://edk2-devel.narkive.com/bwH3r0us/unaligned-i-o
I've therefore added UnalignedIoWrite/Read32() helper functions for 
Ia32/X64, which I've based on IoLib's aligned ones.

Because querying mode properties on the device is only possible by
actually entering the mode, all display modes are queried on startup
and saved for when they are queried.

Feature branch: https://github.com/pmj/edk2/tree/ovmf_vmware_svga_v4

v2:
- Unaligned I/O helpers are now in a separate commit. [Laszlo]
- New header file with only essential device constants [Laszlo]
- ArmVirtPkg build failures fixed [Laszlo]
- Code formatting improvements in main driver code.

v3:
- Hardware describing header definitions now prefixed [Jordan, Laszlo]
- "2" dropped from "SVGA2" wherever it made sense. [Jordan, Laszlo]
- Various formatting tweaks to the unaligned IO helpers [Laszlo]
- Mode properties are now queried and stored up front. [Laszlo]
- Lots of formatting fixes in the driver code. [Laszlo]
- PCI BAR confusion resolved. [Laszlo]
- Found & fixed a memory leak.

v4: (only patch 3/3 changed)
- Struct assignment fix, pixel mask simplified, comment & whitespace
  fixes. [Laszlo]

Phil Dennis-Jordan (3):
  OvmfPkg: VMWare SVGA display device register definitions
  OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O.
  OvmfPkg/QemuVideoDxe: VMWare SVGA device support

 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |   6 +
 OvmfPkg/Include/IndustryStandard/VmwareSvga.h | 104 +
 OvmfPkg/QemuVideoDxe/Qemu.h   |  29 
 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h|  59 +++
 OvmfPkg/QemuVideoDxe/Driver.c | 128 +++-
 OvmfPkg/QemuVideoDxe/Gop.c|  61 +++-
 OvmfPkg/QemuVideoDxe/Initialize.c | 161 
 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c |  70 +
 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c |  80 ++
 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c |  78 ++
 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c |  66 
 11 files changed, 835 insertions(+), 7 deletions(-)
 create mode 100644 OvmfPkg/Include/IndustryStandard/VmwareSvga.h
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c

-- 
2.3.2 (Apple Git-55)

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


Re: [edk2] [PATCH v3 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Phil Dennis-Jordan
On Wed, Apr 5, 2017 at 11:41 PM, Laszlo Ersek  wrote:
> On 04/05/17 11:58, Phil Dennis-Jordan wrote:
>> From: Phil Dennis-Jordan 
>>
>> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
>> a basic version of VMWare's SVGA display device. Drivers for this
>> device exist for some guest OSes which do not support Qemu's other
>> display adapters, so supporting it in OVMF is useful in conjunction
>> with those OSes.
>>
>> This change adds support for the SVGA device's framebuffer to
>> QemuVideoDxe's graphics output protocol implementation, based on
>> VMWare's documentation. The most basic initialisation, framebuffer
>> layout query, and mode setting operations are implemented.
>>
>> The device relies on port-based 32-bit I/O, unfortunately on misaligned
>> addresses. This limits the driver's support to the x86 family of
>> platforms.
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Phil Dennis-Jordan 
>> ---
>>
>> Notes:
>> v2:
>> - Unaligned I/O helper functions moved to separate commit [Laszlo]
>> - Multi-line function call whitespace fixes.
>>
>> v3:
>> - Dropped the "2" from "SVGA2" where appropriate. [Jordan, Laszlo]
>> - Renamed various struct fields and functions with consistent prefixes 
>> [Laszlo]
>> - #include orders fixed [Laszlo]
>> - Renamedi/moved lots of local variables to comply with convention. 
>> [Laszlo]
>> - Added error checking to PCI BAR queries. [Laszlo]
>> - Moved some function definitions around for better grouping. [Laszlo]
>> - Fixed ClearScreen() to use the correct VRAM BAR. [Laszlo]
>> - Changed modelist initialisation to fetch all mode data on startup, so 
>> mode
>>   queries can return everything including channel masks without hitting 
>> the
>>   device. Mask calculations hopefully make more sense now. [Laszlo]
>> - Whitespace fixes. [Laszlo]
>> - Fixed a memory leak in BAR query.
>>
>>  OvmfPkg/QemuVideoDxe/Qemu.h   |  29 
>>  OvmfPkg/QemuVideoDxe/Driver.c | 127 ++-
>>  OvmfPkg/QemuVideoDxe/Gop.c|  61 +++-
>>  OvmfPkg/QemuVideoDxe/Initialize.c | 161 
>>  4 files changed, 371 insertions(+), 7 deletions(-)
>>
>> diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
>> index 2ce37defc5b8..7fbb25b3efd3 100644
>> --- a/OvmfPkg/QemuVideoDxe/Qemu.h
>> +++ b/OvmfPkg/QemuVideoDxe/Qemu.h
>> @@ -92,6 +92,7 @@ typedef enum {
>>QEMU_VIDEO_CIRRUS_5446,
>>QEMU_VIDEO_BOCHS,
>>QEMU_VIDEO_BOCHS_MMIO,
>> +  QEMU_VIDEO_VMWARE_SVGA,
>>  } QEMU_VIDEO_VARIANT;
>>
>>  typedef struct {
>> @@ -115,10 +116,13 @@ typedef struct {
>>//
>>UINTN MaxMode;
>>QEMU_VIDEO_MODE_DATA  *ModeData;
>> +  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *VmwareSvgaModeInfo;
>>
>>QEMU_VIDEO_VARIANTVariant;
>>FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
>>UINTN FrameBufferBltConfigureSize;
>> +  UINT8 FrameBufferVramBarIndex;
>> +  UINT16VmwareSvgaBasePort;
>>  } QEMU_VIDEO_PRIVATE_DATA;
>>
>>  ///
>> @@ -502,9 +506,34 @@ QemuVideoBochsModeSetup (
>>BOOLEAN  IsQxl
>>);
>>
>> +EFI_STATUS
>> +QemuVideoVmwareSvgaModeSetup (
>> +  QEMU_VIDEO_PRIVATE_DATA *Private
>> +  );
>> +
>>  VOID
>>  InstallVbeShim (
>>IN CONST CHAR16 *CardName,
>>IN EFI_PHYSICAL_ADDRESS FrameBufferBase
>>);
>> +
>> +VOID
>> +VmwareSvgaWrite (
>> +  QEMU_VIDEO_PRIVATE_DATA *Private,
>> +  UINT16  Register,
>> +  UINT32  Value
>> +  );
>> +
>> +UINT32
>> +VmwareSvgaRead (
>> +  QEMU_VIDEO_PRIVATE_DATA *Private,
>> +  UINT16  Register
>> +  );
>> +
>> +VOID
>> +InitializeVmwareSvgaGraphicsMode (
>> +  QEMU_VIDEO_PRIVATE_DATA  *Private,
>> +  QEMU_VIDEO_BOCHS_MODES   *ModeData
>> +  );
>> +
>>  #endif
>> diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
>> index fc8025ec46de..79c430e920d7 100644
>> --- a/OvmfPkg/QemuVideoDxe/Driver.c
>> +++ b/OvmfPkg/QemuVideoDxe/Driver.c
>> @@ -14,8 +14,10 @@
>>
>>  **/
>>
>> -#include "Qemu.h"
>> +#include 
>>  #include 
>> +#include "Qemu.h"
>> +#include "UnalignedIoInternal.h"
>>
>>  EFI_DRIVER_BINDING_PROTOCOL gQemuVideoDriverBinding = {
>>QemuVideoControllerDriverSupported,
>> @@ -58,6 +60,11 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
>>  QEMU_VIDEO_BOCHS_MMIO,
>>  L"QEMU VirtIO VGA"
>>  },{
>> +VMWARE_PCI_VENDOR_ID_VMWARE,
>> +VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2,
>> +QEMU_VIDEO_VMWARE_SVGA,
>> +L"QEMU VMWare SVGA"
>> +},{
>>  0 /* end of list */
>>  }
>>  };
>> @@ -242,6 +249,7 @@ QemuVideoControllerDriverStart (
>>  goto ClosePciIo;
>>}
>>Private->Variant = Card->Variant;
>> +  P

Re: [edk2] [PATCH v3 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Laszlo Ersek
On 04/05/17 11:58, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan 
> 
> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
> a basic version of VMWare's SVGA display device. Drivers for this
> device exist for some guest OSes which do not support Qemu's other
> display adapters, so supporting it in OVMF is useful in conjunction
> with those OSes.
> 
> This change adds support for the SVGA device's framebuffer to
> QemuVideoDxe's graphics output protocol implementation, based on
> VMWare's documentation. The most basic initialisation, framebuffer
> layout query, and mode setting operations are implemented.
> 
> The device relies on port-based 32-bit I/O, unfortunately on misaligned
> addresses. This limits the driver's support to the x86 family of
> platforms.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Phil Dennis-Jordan 
> ---
> 
> Notes:
> v2:
> - Unaligned I/O helper functions moved to separate commit [Laszlo]
> - Multi-line function call whitespace fixes.
> 
> v3:
> - Dropped the "2" from "SVGA2" where appropriate. [Jordan, Laszlo]
> - Renamed various struct fields and functions with consistent prefixes 
> [Laszlo]
> - #include orders fixed [Laszlo]
> - Renamedi/moved lots of local variables to comply with convention. 
> [Laszlo]
> - Added error checking to PCI BAR queries. [Laszlo]
> - Moved some function definitions around for better grouping. [Laszlo]
> - Fixed ClearScreen() to use the correct VRAM BAR. [Laszlo]
> - Changed modelist initialisation to fetch all mode data on startup, so 
> mode
>   queries can return everything including channel masks without hitting 
> the
>   device. Mask calculations hopefully make more sense now. [Laszlo]
> - Whitespace fixes. [Laszlo]
> - Fixed a memory leak in BAR query.
> 
>  OvmfPkg/QemuVideoDxe/Qemu.h   |  29 
>  OvmfPkg/QemuVideoDxe/Driver.c | 127 ++-
>  OvmfPkg/QemuVideoDxe/Gop.c|  61 +++-
>  OvmfPkg/QemuVideoDxe/Initialize.c | 161 
>  4 files changed, 371 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
> index 2ce37defc5b8..7fbb25b3efd3 100644
> --- a/OvmfPkg/QemuVideoDxe/Qemu.h
> +++ b/OvmfPkg/QemuVideoDxe/Qemu.h
> @@ -92,6 +92,7 @@ typedef enum {
>QEMU_VIDEO_CIRRUS_5446,
>QEMU_VIDEO_BOCHS,
>QEMU_VIDEO_BOCHS_MMIO,
> +  QEMU_VIDEO_VMWARE_SVGA,
>  } QEMU_VIDEO_VARIANT;
>  
>  typedef struct {
> @@ -115,10 +116,13 @@ typedef struct {
>//
>UINTN MaxMode;
>QEMU_VIDEO_MODE_DATA  *ModeData;
> +  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *VmwareSvgaModeInfo;
>  
>QEMU_VIDEO_VARIANTVariant;
>FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
>UINTN FrameBufferBltConfigureSize;
> +  UINT8 FrameBufferVramBarIndex;
> +  UINT16VmwareSvgaBasePort;
>  } QEMU_VIDEO_PRIVATE_DATA;
>  
>  ///
> @@ -502,9 +506,34 @@ QemuVideoBochsModeSetup (
>BOOLEAN  IsQxl
>);
>  
> +EFI_STATUS
> +QemuVideoVmwareSvgaModeSetup (
> +  QEMU_VIDEO_PRIVATE_DATA *Private
> +  );
> +
>  VOID
>  InstallVbeShim (
>IN CONST CHAR16 *CardName,
>IN EFI_PHYSICAL_ADDRESS FrameBufferBase
>);
> +
> +VOID
> +VmwareSvgaWrite (
> +  QEMU_VIDEO_PRIVATE_DATA *Private,
> +  UINT16  Register,
> +  UINT32  Value
> +  );
> +
> +UINT32
> +VmwareSvgaRead (
> +  QEMU_VIDEO_PRIVATE_DATA *Private,
> +  UINT16  Register
> +  );
> +
> +VOID
> +InitializeVmwareSvgaGraphicsMode (
> +  QEMU_VIDEO_PRIVATE_DATA  *Private,
> +  QEMU_VIDEO_BOCHS_MODES   *ModeData
> +  );
> +
>  #endif
> diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
> index fc8025ec46de..79c430e920d7 100644
> --- a/OvmfPkg/QemuVideoDxe/Driver.c
> +++ b/OvmfPkg/QemuVideoDxe/Driver.c
> @@ -14,8 +14,10 @@
>  
>  **/
>  
> -#include "Qemu.h"
> +#include 
>  #include 
> +#include "Qemu.h"
> +#include "UnalignedIoInternal.h"
>  
>  EFI_DRIVER_BINDING_PROTOCOL gQemuVideoDriverBinding = {
>QemuVideoControllerDriverSupported,
> @@ -58,6 +60,11 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
>  QEMU_VIDEO_BOCHS_MMIO,
>  L"QEMU VirtIO VGA"
>  },{
> +VMWARE_PCI_VENDOR_ID_VMWARE,
> +VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2,
> +QEMU_VIDEO_VMWARE_SVGA,
> +L"QEMU VMWare SVGA"
> +},{
>  0 /* end of list */
>  }
>  };
> @@ -242,6 +249,7 @@ QemuVideoControllerDriverStart (
>  goto ClosePciIo;
>}
>Private->Variant = Card->Variant;
> +  Private->FrameBufferVramBarIndex = PCI_BAR_IDX0;
>  
>//
>// IsQxl is based on the detected Card->Variant, which at a later point 
> might
> @@ -317,6 +325,59 @@ QemuVid

[edk2] [DxeNetLib] Why do we restrict each field to have the same leading zero format?

2017-04-05 Thread Guoheyi
Hi folks,

We are using NetLibAsciiStrToIp6 function in DxeNetLib.c of MdeModulePkg to 
convert string to IPv6 address. We found this function will return invalid 
parameter with below input:
2001:3456:789a::f012:2:2003:2005

We trace the code and believe it is handled by the branch in line 2955:

  if ((Cnt != 0) && (Cnt < 4) && LeadZero) {
return EFI_INVALID_PARAMETER;
  }

I think the reason is that we have field 3 of "" which has leading zero and 
causes LeadZero flag to be true, and it requires all the following fields to 
have the same leading zero format, while field 5 of "2" is not.

I checked RFC 4291 and only found below text; I didn't find any restriction 
that requires each field to have the same leading zero format.

   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
  four hexadecimal digits of the eight 16-bit pieces of the address.
  Examples:

 ABCD:EF01:2345:6789:ABCD:EF01:2345:6789

 2001:DB8:0:0:8:800:200C:417A

  Note that it is not necessary to write the leading zeros in an
  individual field, but there must be at least one numeral in every
  field (except for the case described in 2.).

Could you help to confirm whether it is a bug or there is some special reason 
for this?

Thanks and regards,

Gary (Heyi Guo)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3 2/3] OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O.

2017-04-05 Thread Laszlo Ersek
On 04/05/17 11:57, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan 
> 
> The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
> an I/O-type BAR which is laid out such that some register offsets are
> not aligned to the read/write width with which they are expected to be
> accessed. (The register value port has an offset of 1 and requires
> 32 bit wide read/write access.)
> 
> The EFI_PCI_IO_PROTOCOL's Io.Read/Io.Write functions do not support
> such unaligned I/O.
> 
> Before a driver for this device can be added to QemuVideoDxe, helper
> functions for unaligned I/O are therefore required. This adds the
> functions UnalignedIoWrite32 and UnalignedIoRead32, based on IoLib's
> IoWrite32 and IoRead32, for the Ia32 and X64 architectures. Port I/O
> requires inline assembly, so implementations are provided for the GCC,
> ICC, and Microsoft compiler families. Such I/O is not possible on other
> architectures, a dummy (ASSERT()ing) implementation is therefore
> provided to satisfy the linker.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Suggested-by: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Phil Dennis-Jordan 
> Reviewed-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> - Separate commit for the unaligned I/O helper functions. [Laszlo]
> - Dummy implementations return values despite ASSERT(). [Laszlo]
> - Build failure in ArmVirtPkg fixed. [Laszlo]
> - More consistent API docs and function ordering.
> 
> v3:
> - Fixed typos in commit message [Laszlo]
> - Added Suggested-by: tag [Laszlo]
> - Rewrapped comment lines to 79 chars [Laszlo]
> - Corrected whitespace in function calls [Laszlo]
> - EFIAPI dropped. [Laszlo]
> - Fixed return value in dummy UnsignedIoWrite32 [Laszlo]
> - Dropped "N" imm8 constraint in GCC inline asm [Laszlo]
> 
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  6 ++
>  OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h| 59 +++
>  OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c | 70 +
>  OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c | 80 
>  OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c | 78 +++
>  OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c | 66 
>  6 files changed, 359 insertions(+)

Looks good, thank you for the update.
Laszlo

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


Re: [edk2] [PATCH v3 1/3] OvmfPkg: VMWare SVGA display device register definitions

2017-04-05 Thread Laszlo Ersek
On 04/05/17 11:57, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan 
> 
> This adds a header file defining symbolic constants for the VMWare SVGA
> virtual display device in preparation for supporting it in
> QemuVideoDxe.
> 
> It is mostly an extract of the file lib/vmware/svga_reg.h from commit
> 329dd537456f93a806841ec8a8213aed11395def of VMWare's vmware-svga
> repository at git://git.code.sf.net/p/vmware-svga/git (See also
> http://vmware-svga.sourceforge.net/ )
> 
> Only the bare essentials necessary for initialisation, modesetting and
> framebuffer access have been kept from the original file; macro names
> have been prefixed with VMWARE_SVGA_ instead of SVGA2_, and the enum
> definition has been adapted to comply with EDK2 naming conventions.
> 
> The original file was released by VMWare under the MIT license, this
> has been retained.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Phil Dennis-Jordan 
> Reviewed-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> - New, custom header file instead of importing VMWare's verbatim. [Laszlo]
> 
> v3:
> - Prefixed macros with VMWARE_SVGA_ instead of SVGA2_ [Jordan, Laszlo]
> - Adjusted enum definition to comply with EDK2 convention [Jordan, Laszlo]
> - Tweaks to definitions of numeric constants [Laszlo]
> - Renamed the file to fit with convention [Jordan, Laszlo]
> - Dropped the "2" from SVGA2 wherever appropriate.
> 
>  OvmfPkg/Include/IndustryStandard/VmwareSvga.h | 104 
>  1 file changed, 104 insertions(+)
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/VmwareSvga.h 
> b/OvmfPkg/Include/IndustryStandard/VmwareSvga.h
> new file mode 100644
> index ..693d44bab6c3
> --- /dev/null
> +++ b/OvmfPkg/Include/IndustryStandard/VmwareSvga.h
> @@ -0,0 +1,104 @@
> +/** @file
> +
> +  Macro and enum definitions of a subset of port numbers, register 
> identifiers
> +  and values required for driving the VMWare SVGA virtual display adapter,
> +  also implemented by Qemu.
> +
> +  This file's contents was extracted from file lib/vmware/svga_reg.h in 
> commit
> +  329dd537456f93a806841ec8a8213aed11395def of VMWare's vmware-svga 
> repository:
> +  git://git.code.sf.net/p/vmware-svga/git
> +
> +
> +  Copyright 1998-2009 VMware, Inc.  All rights reserved.
> +  Portions Copyright 2017 Phil Dennis-Jordan 
> +
> +  Permission is hereby granted, free of charge, to any person
> +  obtaining a copy of this software and associated documentation
> +  files (the "Software"), to deal in the Software without
> +  restriction, including without limitation the rights to use, copy,
> +  modify, merge, publish, distribute, sublicense, and/or sell copies
> +  of the Software, and to permit persons to whom the Software is
> +  furnished to do so, subject to the following conditions:
> +
> +  The above copyright notice and this permission notice shall be
> +  included in all copies or substantial portions of the Software.
> +
> +  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> +  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> +  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> +  ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> +  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> +  SOFTWARE.
> +
> +**/
> +
> +#ifndef _VMWARE_SVGA_H_
> +#define _VMWARE_SVGA_H_
> +
> +#include 
> +
> +//
> +// IDs for recognising the device
> +//
> +#define VMWARE_PCI_VENDOR_ID_VMWARE0x15AD
> +#define VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2  0x0405
> +
> +//
> +// I/O port BAR offsets for register selection and read/write.
> +//
> +// The register index is written to the 32-bit index port, followed by a 
> 32-bit
> +// read or write on the value port to read or set that register's contents.
> +//
> +#define VMWARE_SVGA_INDEX_PORT 0x0
> +#define VMWARE_SVGA_VALUE_PORT 0x1
> +
> +//
> +// Some of the device's register indices for basic framebuffer functionality.
> +//
> +typedef enum {
> +  VmwareSvgaRegId = 0,
> +  VmwareSvgaRegEnable = 1,
> +  VmwareSvgaRegWidth = 2,
> +  VmwareSvgaRegHeight = 3,
> +  VmwareSvgaRegMaxWidth = 4,
> +  VmwareSvgaRegMaxHeight = 5,
> +
> +  VmwareSvgaRegBitsPerPixel = 7,
> +
> +  VmwareSvgaRegRedMask = 9,
> +  VmwareSvgaRegGreenMask = 10,
> +  VmwareSvgaRegBlueMask = 11,
> +  VmwareSvgaRegBytesPerLine = 12,
> +
> +  VmwareSvgaRegFbOffset = 14,
> +
> +  VmwareSvgaRegFbSize = 16,
> +  VmwareSvgaRegCapabilities = 17,
> +
> +  VmwareSvgaRegHostBitsPerPixel = 28,
> +} VMWARE_SVGA_REGISTER;
> +
> +//
> +// Values used with VmwareSvgaRegId for sanity-checking the device and 
> getting
> +// its version.
> +//
> +#define VMWARE_SVGA_MAGIC  0x90U
> +#define VMWARE_SVGA_MAKE_ID(ver)   (VM

Re: [edk2] [PATCH] MdeModulePkg: move PlatformHasAcpiGuid from EmbeddedPkg

2017-04-05 Thread Ard Biesheuvel
On 5 April 2017 at 10:49, Laszlo Ersek  wrote:
> On 04/05/17 11:38, Ard Biesheuvel wrote:
>> Given the agreement on the edk2-devel regarding the fact that the
>> notion whether or not a 'platform has ACPI' is a universal one, move
>> the PlatformHasAcpi GUID to MdeModulePkg.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> Reviewed-by: "Zeng, Star" 
>> ---
>>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf   | 1 +
>>  ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 1 +
>>  EmbeddedPkg/EmbeddedPkg.dec| 3 ---
>>  EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf  | 1 +
>>  {EmbeddedPkg => MdeModulePkg}/Include/Guid/PlatformHasAcpi.h   | 0
>>  MdeModulePkg/MdeModulePkg.dec  | 3 +++
>>  6 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf 
>> b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> index 08025f0c3722..5351e741aa41 100644
>> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> @@ -27,6 +27,7 @@ [Sources]
>>  [Packages]
>>ArmVirtPkg/ArmVirtPkg.dec
>>EmbeddedPkg/EmbeddedPkg.dec
>> +  MdeModulePkg/MdeModulePkg.dec
>>MdePkg/MdePkg.dec
>>OvmfPkg/OvmfPkg.dec
>>
>> diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf 
>> b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> index 2833075f65c9..26965c50c12b 100644
>> --- a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> +++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> @@ -26,6 +26,7 @@ [Sources]
>>
>>  [Packages]
>>EmbeddedPkg/EmbeddedPkg.dec
>> +  MdeModulePkg/MdeModulePkg.dec
>>MdePkg/MdePkg.dec
>>
>>  [LibraryClasses]
>> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
>> index 0bed2736c8c3..a7e127085236 100644
>> --- a/EmbeddedPkg/EmbeddedPkg.dec
>> +++ b/EmbeddedPkg/EmbeddedPkg.dec
>> @@ -57,9 +57,6 @@ [Guids.common]
>>gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 
>> 0xAD, 0x3F, 0x71, 0x6D } }
>>gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 
>> 0xc8, 0x4e, 0xfb, 0x3e, 0x57 } }
>>
>> -  ## Include/Guid/PlatformHasAcpi.h
>> -  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
>> 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
>> -
>>## Include/Guid/PlatformHasDeviceTree.h
>>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
>> 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>>
>> diff --git a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf 
>> b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>> index 6268293ca97b..be298ba67c40 100644
>> --- a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>> +++ b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>> @@ -34,6 +34,7 @@ [Sources]
>>
>>  [Packages]
>>EmbeddedPkg/EmbeddedPkg.dec
>
> I think you can remove "EmbeddedPkg/EmbeddedPkg.dec" here.
>

Ah yes. It didn't occur to me to remove the 'home' package here, but I
suppose this library doesn't depend on anything it provides.

> (
>
> I checked all the other INF files being modified as well; it seems that
> "EmbeddedPkg/EmbeddedPkg.dec" remains necessary in all other places.
>
> I also grepped all INF files for the GUID -- DtPlatformDxe.inf is
> another user, but it needs no modification.
>
> )
>
> With that update (if it indeed works),
>
> Reviewed-by: Laszlo Ersek 
>

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


[edk2] [PATCH v3 1/3] OvmfPkg: VMWare SVGA display device register definitions

2017-04-05 Thread Phil Dennis-Jordan
From: Phil Dennis-Jordan 

This adds a header file defining symbolic constants for the VMWare SVGA
virtual display device in preparation for supporting it in
QemuVideoDxe.

It is mostly an extract of the file lib/vmware/svga_reg.h from commit
329dd537456f93a806841ec8a8213aed11395def of VMWare's vmware-svga
repository at git://git.code.sf.net/p/vmware-svga/git (See also
http://vmware-svga.sourceforge.net/ )

Only the bare essentials necessary for initialisation, modesetting and
framebuffer access have been kept from the original file; macro names
have been prefixed with VMWARE_SVGA_ instead of SVGA2_, and the enum
definition has been adapted to comply with EDK2 naming conventions.

The original file was released by VMWare under the MIT license, this
has been retained.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Laszlo Ersek 
---

Notes:
v2:
- New, custom header file instead of importing VMWare's verbatim. [Laszlo]

v3:
- Prefixed macros with VMWARE_SVGA_ instead of SVGA2_ [Jordan, Laszlo]
- Adjusted enum definition to comply with EDK2 convention [Jordan, Laszlo]
- Tweaks to definitions of numeric constants [Laszlo]
- Renamed the file to fit with convention [Jordan, Laszlo]
- Dropped the "2" from SVGA2 wherever appropriate.

 OvmfPkg/Include/IndustryStandard/VmwareSvga.h | 104 
 1 file changed, 104 insertions(+)

diff --git a/OvmfPkg/Include/IndustryStandard/VmwareSvga.h 
b/OvmfPkg/Include/IndustryStandard/VmwareSvga.h
new file mode 100644
index ..693d44bab6c3
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/VmwareSvga.h
@@ -0,0 +1,104 @@
+/** @file
+
+  Macro and enum definitions of a subset of port numbers, register identifiers
+  and values required for driving the VMWare SVGA virtual display adapter,
+  also implemented by Qemu.
+
+  This file's contents was extracted from file lib/vmware/svga_reg.h in commit
+  329dd537456f93a806841ec8a8213aed11395def of VMWare's vmware-svga repository:
+  git://git.code.sf.net/p/vmware-svga/git
+
+
+  Copyright 1998-2009 VMware, Inc.  All rights reserved.
+  Portions Copyright 2017 Phil Dennis-Jordan 
+
+  Permission is hereby granted, free of charge, to any person
+  obtaining a copy of this software and associated documentation
+  files (the "Software"), to deal in the Software without
+  restriction, including without limitation the rights to use, copy,
+  modify, merge, publish, distribute, sublicense, and/or sell copies
+  of the Software, and to permit persons to whom the Software is
+  furnished to do so, subject to the following conditions:
+
+  The above copyright notice and this permission notice shall be
+  included in all copies or substantial portions of the Software.
+
+  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+  ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+  SOFTWARE.
+
+**/
+
+#ifndef _VMWARE_SVGA_H_
+#define _VMWARE_SVGA_H_
+
+#include 
+
+//
+// IDs for recognising the device
+//
+#define VMWARE_PCI_VENDOR_ID_VMWARE0x15AD
+#define VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2  0x0405
+
+//
+// I/O port BAR offsets for register selection and read/write.
+//
+// The register index is written to the 32-bit index port, followed by a 32-bit
+// read or write on the value port to read or set that register's contents.
+//
+#define VMWARE_SVGA_INDEX_PORT 0x0
+#define VMWARE_SVGA_VALUE_PORT 0x1
+
+//
+// Some of the device's register indices for basic framebuffer functionality.
+//
+typedef enum {
+  VmwareSvgaRegId = 0,
+  VmwareSvgaRegEnable = 1,
+  VmwareSvgaRegWidth = 2,
+  VmwareSvgaRegHeight = 3,
+  VmwareSvgaRegMaxWidth = 4,
+  VmwareSvgaRegMaxHeight = 5,
+
+  VmwareSvgaRegBitsPerPixel = 7,
+
+  VmwareSvgaRegRedMask = 9,
+  VmwareSvgaRegGreenMask = 10,
+  VmwareSvgaRegBlueMask = 11,
+  VmwareSvgaRegBytesPerLine = 12,
+
+  VmwareSvgaRegFbOffset = 14,
+
+  VmwareSvgaRegFbSize = 16,
+  VmwareSvgaRegCapabilities = 17,
+
+  VmwareSvgaRegHostBitsPerPixel = 28,
+} VMWARE_SVGA_REGISTER;
+
+//
+// Values used with VmwareSvgaRegId for sanity-checking the device and getting
+// its version.
+//
+#define VMWARE_SVGA_MAGIC  0x90U
+#define VMWARE_SVGA_MAKE_ID(ver)   (VMWARE_SVGA_MAGIC << 8 | (ver))
+
+#define VMWARE_SVGA_VERSION_2  2
+#define VMWARE_SVGA_ID_2   VMWARE_SVGA_MAKE_ID (VMWARE_SVGA_VERSION_2)
+
+#define VMWARE_SVGA_VERSION_1  1
+#define VMWARE_SVGA_ID_1   VMWARE_SVGA_MAKE_ID (VMWARE_SVGA_VERSION_1)
+
+#define VMWARE_SVGA_VERSION_0  0
+#define VMWARE_SVGA

[edk2] [PATCH v3 3/3] OvmfPkg/QemuVideoDxe: VMWare SVGA device support

2017-04-05 Thread Phil Dennis-Jordan
From: Phil Dennis-Jordan 

In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
a basic version of VMWare's SVGA display device. Drivers for this
device exist for some guest OSes which do not support Qemu's other
display adapters, so supporting it in OVMF is useful in conjunction
with those OSes.

This change adds support for the SVGA device's framebuffer to
QemuVideoDxe's graphics output protocol implementation, based on
VMWare's documentation. The most basic initialisation, framebuffer
layout query, and mode setting operations are implemented.

The device relies on port-based 32-bit I/O, unfortunately on misaligned
addresses. This limits the driver's support to the x86 family of
platforms.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan 
---

Notes:
v2:
- Unaligned I/O helper functions moved to separate commit [Laszlo]
- Multi-line function call whitespace fixes.

v3:
- Dropped the "2" from "SVGA2" where appropriate. [Jordan, Laszlo]
- Renamed various struct fields and functions with consistent prefixes 
[Laszlo]
- #include orders fixed [Laszlo]
- Renamedi/moved lots of local variables to comply with convention. [Laszlo]
- Added error checking to PCI BAR queries. [Laszlo]
- Moved some function definitions around for better grouping. [Laszlo]
- Fixed ClearScreen() to use the correct VRAM BAR. [Laszlo]
- Changed modelist initialisation to fetch all mode data on startup, so mode
  queries can return everything including channel masks without hitting the
  device. Mask calculations hopefully make more sense now. [Laszlo]
- Whitespace fixes. [Laszlo]
- Fixed a memory leak in BAR query.

 OvmfPkg/QemuVideoDxe/Qemu.h   |  29 
 OvmfPkg/QemuVideoDxe/Driver.c | 127 ++-
 OvmfPkg/QemuVideoDxe/Gop.c|  61 +++-
 OvmfPkg/QemuVideoDxe/Initialize.c | 161 
 4 files changed, 371 insertions(+), 7 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index 2ce37defc5b8..7fbb25b3efd3 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -92,6 +92,7 @@ typedef enum {
   QEMU_VIDEO_CIRRUS_5446,
   QEMU_VIDEO_BOCHS,
   QEMU_VIDEO_BOCHS_MMIO,
+  QEMU_VIDEO_VMWARE_SVGA,
 } QEMU_VIDEO_VARIANT;
 
 typedef struct {
@@ -115,10 +116,13 @@ typedef struct {
   //
   UINTN MaxMode;
   QEMU_VIDEO_MODE_DATA  *ModeData;
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *VmwareSvgaModeInfo;
 
   QEMU_VIDEO_VARIANTVariant;
   FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
   UINTN FrameBufferBltConfigureSize;
+  UINT8 FrameBufferVramBarIndex;
+  UINT16VmwareSvgaBasePort;
 } QEMU_VIDEO_PRIVATE_DATA;
 
 ///
@@ -502,9 +506,34 @@ QemuVideoBochsModeSetup (
   BOOLEAN  IsQxl
   );
 
+EFI_STATUS
+QemuVideoVmwareSvgaModeSetup (
+  QEMU_VIDEO_PRIVATE_DATA *Private
+  );
+
 VOID
 InstallVbeShim (
   IN CONST CHAR16 *CardName,
   IN EFI_PHYSICAL_ADDRESS FrameBufferBase
   );
+
+VOID
+VmwareSvgaWrite (
+  QEMU_VIDEO_PRIVATE_DATA *Private,
+  UINT16  Register,
+  UINT32  Value
+  );
+
+UINT32
+VmwareSvgaRead (
+  QEMU_VIDEO_PRIVATE_DATA *Private,
+  UINT16  Register
+  );
+
+VOID
+InitializeVmwareSvgaGraphicsMode (
+  QEMU_VIDEO_PRIVATE_DATA  *Private,
+  QEMU_VIDEO_BOCHS_MODES   *ModeData
+  );
+
 #endif
diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index fc8025ec46de..79c430e920d7 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -14,8 +14,10 @@
 
 **/
 
-#include "Qemu.h"
+#include 
 #include 
+#include "Qemu.h"
+#include "UnalignedIoInternal.h"
 
 EFI_DRIVER_BINDING_PROTOCOL gQemuVideoDriverBinding = {
   QemuVideoControllerDriverSupported,
@@ -58,6 +60,11 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
 QEMU_VIDEO_BOCHS_MMIO,
 L"QEMU VirtIO VGA"
 },{
+VMWARE_PCI_VENDOR_ID_VMWARE,
+VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2,
+QEMU_VIDEO_VMWARE_SVGA,
+L"QEMU VMWare SVGA"
+},{
 0 /* end of list */
 }
 };
@@ -242,6 +249,7 @@ QemuVideoControllerDriverStart (
 goto ClosePciIo;
   }
   Private->Variant = Card->Variant;
+  Private->FrameBufferVramBarIndex = PCI_BAR_IDX0;
 
   //
   // IsQxl is based on the detected Card->Variant, which at a later point might
@@ -317,6 +325,59 @@ QemuVideoControllerDriverStart (
   }
 
   //
+  // Check if accessing Vmware SVGA interface works
+  //
+  if (Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
+EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *IoDesc;
+UINT32TargetId;
+UINT32SvgaIdRead;
+
+IoDesc = NULL;
+Status = Private->PciIo->

[edk2] [PATCH v3 2/3] OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O.

2017-04-05 Thread Phil Dennis-Jordan
From: Phil Dennis-Jordan 

The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. (The register value port has an offset of 1 and requires
32 bit wide read/write access.)

The EFI_PCI_IO_PROTOCOL's Io.Read/Io.Write functions do not support
such unaligned I/O.

Before a driver for this device can be added to QemuVideoDxe, helper
functions for unaligned I/O are therefore required. This adds the
functions UnalignedIoWrite32 and UnalignedIoRead32, based on IoLib's
IoWrite32 and IoRead32, for the Ia32 and X64 architectures. Port I/O
requires inline assembly, so implementations are provided for the GCC,
ICC, and Microsoft compiler families. Such I/O is not possible on other
architectures, a dummy (ASSERT()ing) implementation is therefore
provided to satisfy the linker.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Laszlo Ersek 
---

Notes:
v2:
- Separate commit for the unaligned I/O helper functions. [Laszlo]
- Dummy implementations return values despite ASSERT(). [Laszlo]
- Build failure in ArmVirtPkg fixed. [Laszlo]
- More consistent API docs and function ordering.

v3:
- Fixed typos in commit message [Laszlo]
- Added Suggested-by: tag [Laszlo]
- Rewrapped comment lines to 79 chars [Laszlo]
- Corrected whitespace in function calls [Laszlo]
- EFIAPI dropped. [Laszlo]
- Fixed return value in dummy UnsignedIoWrite32 [Laszlo]
- Dropped "N" imm8 constraint in GCC inline asm [Laszlo]

 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  6 ++
 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h| 59 +++
 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c | 70 +
 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c | 80 
 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c | 78 +++
 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c | 66 
 6 files changed, 359 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf 
b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
index affb6ffd88e0..346a5aed94fa 100644
--- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
+++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
@@ -41,6 +41,12 @@ [Sources.common]
 
 [Sources.Ia32, Sources.X64]
   VbeShim.c
+  UnalignedIoGcc.c| GCC
+  UnalignedIoMsc.c| MSFT
+  UnalignedIoIcc.c| INTEL
+
+[Sources.IPF, Sources.EBC, Sources.ARM, Sources.AARCH64]
+  UnalignedIoUnsupported.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h 
b/OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
new file mode 100644
index ..234de6c21bd1
--- /dev/null
+++ b/OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
@@ -0,0 +1,59 @@
+/** @file
+  Unaligned port I/O, with implementations for various x86 compilers and a
+  dummy for platforms which do not support unaligned port I/O.
+
+  Copyright (c) 2017, Phil Dennis-Jordan.
+  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 _UNALIGNED_IO_INTERNAL_H_
+#define _UNALIGNED_IO_INTERNAL_H_
+
+/**
+  Performs a 32-bit write to the specified, possibly unaligned I/O-type 
address.
+
+  Writes the 32-bit I/O port specified by Port with the value specified by 
Value
+  and returns Value. This function must guarantee that all I/O read and write
+  operations are serialized.
+
+  If 32-bit unaligned I/O port operations are not supported, then ASSERT().
+
+  @param[in]  Port   I/O port address
+  @param[in]  Value  32-bit word to write
+
+  @return The value written to the I/O port.
+
+**/
+UINT32
+UnalignedIoWrite32 (
+  IN  UINTN Port,
+  IN  UINT32Value
+  );
+
+/**
+  Reads a 32-bit word from the specified, possibly unaligned I/O-type address.
+
+  Reads the 32-bit I/O port specified by Port. The 32-bit read value is
+  returned. This function must guarantee that all I/O read and write operations
+  are serialized.
+
+  If 32-bit unaligned I/O port operations are not supported, then ASSERT().
+
+  @param[in]  Port  The I/O port to read.
+
+  @return The value read.
+
+**/
+UINT32
+UnalignedIoRead32 (
+  IN  UINTN Port
+  );
+
+#endif
diff --git a/OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c 
b/OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c
new file mode 100644
index ..105d55d3b903
--- /dev/null
+++ b/OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c
@@ -0,0 +1,70 @@
+/** @f

[edk2] [PATCH v3 0/3] OvmfPkg/QemuVideoDxe: Add VMWare SVGA framebuffer support

2017-04-05 Thread Phil Dennis-Jordan
This extends the QemuVideoDxe driver to support the VMWare SVGA display
device implemented by Qemu. Drivers for this device exist for guest OSes
which do not support Qemu's other display adapters, so supporting it in
OVMF is useful in conjunction with those OSes.

I've tried to follow the existing pattern for device-specific code in
OVMF's QemuVideoDxe driver as much as possible, with a minimum of
additional code.

For the functionality this driver uses, 2 I/O ports are used with
32-bit wide reads and writes. Unfortunately, one of them is not 32-bit
aligned. This is fine as far as x86/x86-64 is concerned, but neither
EDK2's IoLib nor other platforms support such an access pattern.
This issue was already encountered/discussed on the edk2-devel list 4
years ago: http://edk2-devel.narkive.com/bwH3r0us/unaligned-i-o
I've therefore added UnalignedIoWrite/Read32() helper functions for 
Ia32/X64, which I've based on IoLib's aligned ones.

Because querying mode properties on the device is only possible by
actually entering the mode, all display modes are queried on startup
and saved for when they are queried.

Feature branch: https://github.com/pmj/edk2/tree/ovmf_vmware_svga2_v3

v2:
- Unaligned I/O helpers are now in a separate commit. [Laszlo]
- New header file with only essential device constants [Laszlo]
- ArmVirtPkg build failures fixed [Laszlo]
- Code formatting improvements in main driver code.

v3:
- Hardware describing header definitions now prefixed [Jordan, Laszlo]
- "2" dropped from "SVGA2" wherever it made sense. [Jordan, Laszlo]
- Various formatting tweaks to the unaligned IO helpers [Laszlo]
- Mode properties are now queried and stored up front. [Laszlo]
- Lots of formatting fixes in the driver code. [Laszlo]
- PCI BAR confusion resolved. [Laszlo]
- Found & fixed a memory leak.

Phil Dennis-Jordan (3):
  OvmfPkg: VMWare SVGA display device register definitions
  OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O.
  OvmfPkg/QemuVideoDxe: VMWare SVGA device support

 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |   6 +
 OvmfPkg/Include/IndustryStandard/VmwareSvga.h | 104 +
 OvmfPkg/QemuVideoDxe/Qemu.h   |  29 
 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h|  59 +++
 OvmfPkg/QemuVideoDxe/Driver.c | 127 ++-
 OvmfPkg/QemuVideoDxe/Gop.c|  61 +++-
 OvmfPkg/QemuVideoDxe/Initialize.c | 161 
 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c |  70 +
 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c |  80 ++
 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c |  78 ++
 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c |  66 
 11 files changed, 834 insertions(+), 7 deletions(-)
 create mode 100644 OvmfPkg/Include/IndustryStandard/VmwareSvga.h
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c

-- 
2.3.2 (Apple Git-55)

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


Re: [edk2] Using Intel UDk debugger

2017-04-05 Thread Arka Sharma
When I try to set break point after launching the application and
CpuBreakpoint() is hit and symbols are seen in lmv command, the
breakpoints are set using F9. I can list them with bl. But if I
attempt to set a breakpoint with F9 before CpuBreakpoint is called
WinDbg pops up a dialog box throwing the following error message

"Symbol information for the current line could not be located in the
currently loaded symbols.Do you want the debugger to load and search
the remaining symbols? Yes performs the search immediately. No returns
to the UI while search proceeds. Canel exits the operation.". If I
select 'yes' then it shows breakpoint not set. In this case there is
no symbols loaded for my application which I confirmed using lmv.

The CpuBreakpoint() approach is ok for debugging the application. But
I am also debugging the driver whose io routines are called by my
application. The driver is loaded from Pci expansion ROM. I can
manually load it from shell as well, but that will need code changes
and rebuilding of the driver. That is why I am trying to figure out
alternative approach.

Regards,
Arka

On Sun, Apr 2, 2017 at 7:26 AM, Ni, Ruiyu  wrote:
> Arka,
> Can you try to set unresolved breakpoint through Graphics UI?
> Open the App.c file in WinDbg and put the caret in the line you want
> to set breakpoint. Press F9 to set it. than use bl to confirm.
>
> Regards,
> Ray
>
>>-Original Message-
>>From: Arka Sharma [mailto:arka.sw1...@gmail.com]
>>Sent: Saturday, April 1, 2017 4:57 PM
>>To: Ni, Ruiyu 
>>Cc: Fan, Jeff ; edk2-devel@lists.01.org
>>Subject: Re: [edk2] Using Intel UDk debugger
>>
>>Thanks Jeff and Ray. As of now I am using CpuBreakPoint() in the entry
>>point of my application. Once I start the application __debugbreak()
>>is getting called and I am able to set additional breakpoints. Also I
>>confirmed the symbols are loaded using lmv. When I am trying to use
>>unresolved breakpoint I was using "bu `!>name>:" syntax, when I was not using CpuBreakPoint(). I
>>am using the same source in WinDbg as the image and symbol. After
>>executing bu command in WinDbg I can find the breakpoint using bl
>>command.
>>
>>On Sat, Apr 1, 2017 at 10:38 AM, Ni, Ruiyu  wrote:
>>> Arka,
>>> Can you make sure that the source code is not modified after the image 
>>> symbol
>>> is generated by compiler?
>>> And can you send me a screenshot of WinDbg when you are using the unresolved
>>> breakpoint feature? I need to see which command is auto-pasted to WinDbg 
>>> from
>>> UDK Debugger.
>>>
>>> Thanks/Ray
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 Arka Sharma
 Sent: Friday, March 31, 2017 5:18 PM
 To: Fan, Jeff 
 Cc: edk2-devel@lists.01.org
 Subject: Re: [edk2] Using Intel UDk debugger

  Thanks Jeff. Using CpuBreakPoint() has temporarily solved the purpose. But
 I need the symbols to be loaded properly. Please let me know if I missed
 something in building the application. As mentioned earlier I have disabled
 optimization and used --keepexceptiontable in GenFw. Is there something
 else I need to do.

 Regards,
 Arka

 On Fri, Mar 31, 2017 at 12:58 PM, Fan, Jeff  wrote:
 > It seems that symbols are not load correctly.
 >
 > Could you add CpuBreakpoint () in your application code to trigger SW
 breakpoint by code instead of setting unresolved breakpoint by Windbg?
 And to check if it could break at CpuBreakpoint() and symbols if could be
 loaded correctly.
 >
 > Jeff
 > -Original Message-
 > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 > Arka Sharma
 > Sent: Friday, March 31, 2017 2:53 PM
 > To: Fan, Jeff
 > Cc: edk2-devel@lists.01.org
 > Subject: Re: [edk2] Using Intel UDk debugger
 >
 > I have built my application with /Od and /Oy-, and GENFW_FLAGS as --
 keepexceptiontable. After loading DebugAgentDxe I have set an unresolved
 breakpoint in main routine of my application, but when I start my 
 application
 in the target no breakpoint is hit. But when the application crashes the
 symbols are properly loaded in WinDbg and the asm code for the crash is
 displayed.
 >
 > Regards,
 > Arka
 >
 > On Fri, Mar 31, 2017 at 9:03 AM, Fan, Jeff  wrote:
 >> Yes.
 >>
 >> If you want to enable flow control, you could set
 gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl|TR
 UE in SourceLevelDebugPkg.dsc when you build DebugAgentDxe.efi.
 >>
 >> It could improve the serial port communication quality.
 >>
 >> Thanks!
 >> Jeff
 >>
 >> -Original Message-
 >> From: Arka Sharma [mailto:arka.sw1...@gmail.com]
 >> Sent: Friday, March 31, 2017 11:23 AM
 >> To: Fan, Jeff
 >> Cc: edk2-devel@lists.01.org
 >> Subject: Re: [edk2] Using Intel UDk debugger
 >>
 >> Thanks 

Re: [edk2] [PATCH] MdeModulePkg: move PlatformHasAcpiGuid from EmbeddedPkg

2017-04-05 Thread Laszlo Ersek
On 04/05/17 11:38, Ard Biesheuvel wrote:
> Given the agreement on the edk2-devel regarding the fact that the
> notion whether or not a 'platform has ACPI' is a universal one, move
> the PlatformHasAcpi GUID to MdeModulePkg.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> Reviewed-by: "Zeng, Star" 
> ---
>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf   | 1 +
>  ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 1 +
>  EmbeddedPkg/EmbeddedPkg.dec| 3 ---
>  EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf  | 1 +
>  {EmbeddedPkg => MdeModulePkg}/Include/Guid/PlatformHasAcpi.h   | 0
>  MdeModulePkg/MdeModulePkg.dec  | 3 +++
>  6 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf 
> b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> index 08025f0c3722..5351e741aa41 100644
> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> @@ -27,6 +27,7 @@ [Sources]
>  [Packages]
>ArmVirtPkg/ArmVirtPkg.dec
>EmbeddedPkg/EmbeddedPkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
>MdePkg/MdePkg.dec
>OvmfPkg/OvmfPkg.dec
>  
> diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf 
> b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> index 2833075f65c9..26965c50c12b 100644
> --- a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> +++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> @@ -26,6 +26,7 @@ [Sources]
>  
>  [Packages]
>EmbeddedPkg/EmbeddedPkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
>MdePkg/MdePkg.dec
>  
>  [LibraryClasses]
> diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
> index 0bed2736c8c3..a7e127085236 100644
> --- a/EmbeddedPkg/EmbeddedPkg.dec
> +++ b/EmbeddedPkg/EmbeddedPkg.dec
> @@ -57,9 +57,6 @@ [Guids.common]
>gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 
> 0xAD, 0x3F, 0x71, 0x6D } }
>gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 0xc8, 
> 0x4e, 0xfb, 0x3e, 0x57 } }
>  
> -  ## Include/Guid/PlatformHasAcpi.h
> -  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
> 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
> -
>## Include/Guid/PlatformHasDeviceTree.h
>gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
> 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>  
> diff --git a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf 
> b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> index 6268293ca97b..be298ba67c40 100644
> --- a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> +++ b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> @@ -34,6 +34,7 @@ [Sources]
>  
>  [Packages]
>EmbeddedPkg/EmbeddedPkg.dec

I think you can remove "EmbeddedPkg/EmbeddedPkg.dec" here.

(

I checked all the other INF files being modified as well; it seems that
"EmbeddedPkg/EmbeddedPkg.dec" remains necessary in all other places.

I also grepped all INF files for the GUID -- DtPlatformDxe.inf is
another user, but it needs no modification.

)

With that update (if it indeed works),

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> +  MdeModulePkg/MdeModulePkg.dec
>MdePkg/MdePkg.dec
>  
>  [Depex]
> diff --git a/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h 
> b/MdeModulePkg/Include/Guid/PlatformHasAcpi.h
> similarity index 100%
> rename from EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
> rename to MdeModulePkg/Include/Guid/PlatformHasAcpi.h
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 4f69c24c4d1d..ca09cbc10923 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -385,6 +385,9 @@ [Guids]
>gEdkiiNonDiscoverableUhciDeviceGuid = { 0xA8CDA0A2, 0x4F37, 0x4A1B, {0x8E, 
> 0x10, 0x8E, 0xF3, 0xCC, 0x3B, 0xF3, 0xA8 } }
>gEdkiiNonDiscoverableXhciDeviceGuid = { 0xB1BE0BC5, 0x6C28, 0x442D, {0xAA, 
> 0x37, 0x15, 0x1B, 0x42, 0x57, 0xBD, 0x78 } }
>  
> +  ## Include/Guid/PlatformHasAcpi.h
> +  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
> 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
> +
>  [Ppis]
>## Include/Ppi/AtaController.h
>gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 
> 0x7a, 0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
> 

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


Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window shrinking

2017-04-05 Thread Fu, Siyuan
Hi, Andrey

When the client received such a segment that moves the right edge of send 
window back to the left said, the client actually have no idea about whether 
the server is "shrinking the window" or just "reducing window size". Actually, 
if the server reduced the advertised windows size too much, which takes back 
his previous permission of sending a number of bytes, from the client side, the 
server is indeed shrink the receive window. This is discouraged by RFC793, 
while it says the client must prepare for the peer to do such kind of thing.

Back to the original code, move the SndNxt to the "Right" will let client to 
retransmit some bytes of data (from Right to SndNxt), but I don't see a 
condition that it will cause deadlock. While if we adopt this patch, the SndNxt 
is unchanged when we got a positive usable window, and in the meanwhile, if 
server did shrink the window and dropped the data from Right to SndNxt, this 
piece of data won't be retransmit by the client anymore, this is actually a 
deadlock.

So please provide more details if you did observe a deadlock, maybe an example 
would help to understand the problem.

Thanks,
Siyuan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
ate...@kraftway.ru
Sent: 2017年3月28日 15:20
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Fix unconditional window 
shrinking

Moving Right window edge to the left on sender side without additional checks 
leads to the situation when sender assumes the receiver shrunk its rcv buffer, 
when, in fact, it only reduced window size. This is a TCP deadlock situation. 
Receiver ACKs proper segment, while sender discards it for future ACK. Add 
check for negative usable window to prevent erroneous window shrinking.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrey Tepin 
---
 NetworkPkg/TcpDxe/TcpInput.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/TcpDxe/TcpInput.c b/NetworkPkg/TcpDxe/TcpInput.c index 
04c8a82..11b3eb8 100644
--- a/NetworkPkg/TcpDxe/TcpInput.c
+++ b/NetworkPkg/TcpDxe/TcpInput.c
@@ -738,6 +738,7 @@ TcpInput (
   TCP_SEQNO   Right;
   TCP_SEQNO   Urg;
   UINT16  Checksum;
+  INT32   UsableWnd;
 
   ASSERT ((Version == IP_VERSION_4) || (Version == IP_VERSION_6));
 
@@ -1307,7 +1308,10 @@ TcpInput (
 
   if (TCP_SEQ_LT (Right, Tcb->SndNxt)) {
 
-Tcb->SndNxt = Right;
+UsableWnd = Tcb->SndUna + Tcb->SndWnd - Tcb->SndNxt;
+if (UsableWnd < 0) {
+  Tcb->SndNxt = Right;
+}
 
 if (Right == Tcb->SndUna) {
 
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] MdeModulePkg: move PlatformHasAcpiGuid from EmbeddedPkg

2017-04-05 Thread Ard Biesheuvel
Given the agreement on the edk2-devel regarding the fact that the
notion whether or not a 'platform has ACPI' is a universal one, move
the PlatformHasAcpi GUID to MdeModulePkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: "Zeng, Star" 
---
 ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf   | 1 +
 ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 1 +
 EmbeddedPkg/EmbeddedPkg.dec| 3 ---
 EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf  | 1 +
 {EmbeddedPkg => MdeModulePkg}/Include/Guid/PlatformHasAcpi.h   | 0
 MdeModulePkg/MdeModulePkg.dec  | 3 +++
 6 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf 
b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
index 08025f0c3722..5351e741aa41 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
@@ -27,6 +27,7 @@ [Sources]
 [Packages]
   ArmVirtPkg/ArmVirtPkg.dec
   EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   OvmfPkg/OvmfPkg.dec
 
diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf 
b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
index 2833075f65c9..26965c50c12b 100644
--- a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
+++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
@@ -26,6 +26,7 @@ [Sources]
 
 [Packages]
   EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
 
 [LibraryClasses]
diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 0bed2736c8c3..a7e127085236 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -57,9 +57,6 @@ [Guids.common]
   gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 
0xAD, 0x3F, 0x71, 0x6D } }
   gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 0xc8, 
0x4e, 0xfb, 0x3e, 0x57 } }
 
-  ## Include/Guid/PlatformHasAcpi.h
-  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
-
   ## Include/Guid/PlatformHasDeviceTree.h
   gEdkiiPlatformHasDeviceTreeGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 
0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
 
diff --git a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf 
b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
index 6268293ca97b..be298ba67c40 100644
--- a/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
+++ b/EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
@@ -34,6 +34,7 @@ [Sources]
 
 [Packages]
   EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
 
 [Depex]
diff --git a/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h 
b/MdeModulePkg/Include/Guid/PlatformHasAcpi.h
similarity index 100%
rename from EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
rename to MdeModulePkg/Include/Guid/PlatformHasAcpi.h
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 4f69c24c4d1d..ca09cbc10923 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -385,6 +385,9 @@ [Guids]
   gEdkiiNonDiscoverableUhciDeviceGuid = { 0xA8CDA0A2, 0x4F37, 0x4A1B, {0x8E, 
0x10, 0x8E, 0xF3, 0xCC, 0x3B, 0xF3, 0xA8 } }
   gEdkiiNonDiscoverableXhciDeviceGuid = { 0xB1BE0BC5, 0x6C28, 0x442D, {0xAA, 
0x37, 0x15, 0x1B, 0x42, 0x57, 0xBD, 0x78 } }
 
+  ## Include/Guid/PlatformHasAcpi.h
+  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
+
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
-- 
2.9.3

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


  1   2   >