Re: [edk2-devel] [Patch] BaseTools: Sometime write file not immediate to disk

2019-04-10 Thread Zhu, Yonghong
Reviewed-by: Yonghong Zhu 

Best Regards,
Zhu Yonghong

-Original Message-
From: Gao, Liming 
Sent: Thursday, April 11, 2019 12:57 PM
To: devel@edk2.groups.io
Cc: Feng, YunhuaX ; Feng, Bob C ; 
Zhu, Yonghong 
Subject: [Patch] BaseTools: Sometime write file not immediate to disk

From: Yunhua Feng 

BZ: https://bugzilla.tianocore.org/process_bug.cgi

On Windows OS, sometime the generated file is not immediate saved to disk.
When run nmake, prompt AutoGen.h not found, and stop build.
Below blog shows Write-Replace to fix it. This patch uses this way to write 
temp file, then rename the temp file to the real file.
https://blog.gocept.com/2013/07/15/reliable-file-updates-with-python/

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Common/Misc.py | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 5db9405ddc..3b3ab2d6df 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -22,6 +22,7 @@ from random import sample  from struct import pack  import 
uuid  import subprocess
+import tempfile
 from collections import OrderedDict
 
 import Common.LongFilePathOs as os
@@ -476,15 +477,23 @@ def SaveFileOnChange(File, Content, IsBinaryFile=True):
 if not os.access(DirName, os.W_OK):
 EdkLogger.error(None, PERMISSION_FAILURE, "Do not have write 
permission on directory %s" % DirName)
 
+OpenMode = "w"
 if IsBinaryFile:
+OpenMode = "wb"
+
+if GlobalData.gIsWindows and not os.path.exists(File):
+# write temp file, then rename the temp file to the real file
+# to make sure the file be immediate saved to disk
+with tempfile.NamedTemporaryFile(OpenMode, dir=os.path.dirname(File), 
delete=False) as tf:
+tf.write(Content)
+tempname = tf.name
 try:
-with open(File, "wb") as Fd:
-Fd.write(Content)
-except IOError as X:
+os.rename(tempname, File)
+except:
 EdkLogger.error(None, FILE_CREATE_FAILURE, ExtraData='IOError %s' 
% X)
 else:
 try:
-with open(File, 'w') as Fd:
+with open(File, OpenMode) as Fd:
 Fd.write(Content)
 except IOError as X:
 EdkLogger.error(None, FILE_CREATE_FAILURE, ExtraData='IOError %s' 
% X)
--
2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38850): https://edk2.groups.io/g/devel/message/38850
Mute This Topic: https://groups.io/mt/31027692/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] MdePkg/BaseLib: Remove LongJump.c and SetJump.c

2019-04-10 Thread Liming Gao
Reviewed-by: Liming Gao 

>-Original Message-
>From: Zhang, Shenglei
>Sent: Tuesday, April 09, 2019 11:22 AM
>To: devel@edk2.groups.io
>Cc: Kinney, Michael D ; Gao, Liming
>
>Subject: [PATCH] MdePkg/BaseLib: Remove LongJump.c and SetJump.c
>
>MdePkg BaseLib still uses the inline X86 assembly code
>in C code files.For now, inline SetJump/LongJump() can be removed.
>https://bugzilla.tianocore.org/show_bug.cgi?id=1163
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Shenglei Zhang 
>---
> MdePkg/Library/BaseLib/BaseLib.inf |   8 +-
> MdePkg/Library/BaseLib/Ia32/LongJump.c |  76 ---
> MdePkg/Library/BaseLib/Ia32/SetJump.c  | 101 -
> 3 files changed, 2 insertions(+), 183 deletions(-)
> delete mode 100644 MdePkg/Library/BaseLib/Ia32/LongJump.c
> delete mode 100644 MdePkg/Library/BaseLib/Ia32/SetJump.c
>
>diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
>b/MdePkg/Library/BaseLib/BaseLib.inf
>index 16829deeb4..344cb58249 100644
>--- a/MdePkg/Library/BaseLib/BaseLib.inf
>+++ b/MdePkg/Library/BaseLib/BaseLib.inf
>@@ -96,7 +96,6 @@
>   Ia32/WriteCr0.c | MSFT
>   Ia32/WriteMsr64.c | MSFT
>   Ia32/SwapBytes64.c | MSFT
>-  Ia32/SetJump.c | MSFT
>   Ia32/RRotU64.c | MSFT
>   Ia32/RShiftU64.c | MSFT
>   Ia32/ReadPmc.c | MSFT
>@@ -140,7 +139,6 @@
>   Ia32/MultU64x32.c | MSFT
>   Ia32/LShiftU64.c | MSFT
>   Ia32/LRotU64.c | MSFT
>-  Ia32/LongJump.c | MSFT
>   Ia32/Invd.c | MSFT
>   Ia32/FxRestore.c | MSFT
>   Ia32/FxSave.c | MSFT
>@@ -190,7 +188,6 @@
>   Ia32/WriteCr0.nasm| INTEL
>   Ia32/WriteMsr64.nasm| INTEL
>   Ia32/SwapBytes64.nasm| INTEL
>-  Ia32/SetJump.nasm| INTEL
>   Ia32/RRotU64.nasm| INTEL
>   Ia32/RShiftU64.nasm| INTEL
>   Ia32/ReadPmc.nasm| INTEL
>@@ -234,7 +231,6 @@
>   Ia32/MultU64x32.nasm| INTEL
>   Ia32/LShiftU64.nasm| INTEL
>   Ia32/LRotU64.nasm| INTEL
>-  Ia32/LongJump.nasm| INTEL
>   Ia32/Invd.nasm| INTEL
>   Ia32/FxRestore.nasm| INTEL
>   Ia32/FxSave.nasm| INTEL
>@@ -268,8 +264,8 @@
>   Ia32/Monitor.nasm| GCC
>   Ia32/CpuIdEx.nasm| GCC
>   Ia32/CpuId.nasm| GCC
>-  Ia32/LongJump.nasm| GCC
>-  Ia32/SetJump.nasm| GCC
>+  Ia32/LongJump.nasm
>+  Ia32/SetJump.nasm
>   Ia32/SwapBytes64.nasm| GCC
>   Ia32/DivU64x64Remainder.nasm| GCC
>   Ia32/DivU64x32Remainder.nasm| GCC
>diff --git a/MdePkg/Library/BaseLib/Ia32/LongJump.c
>b/MdePkg/Library/BaseLib/Ia32/LongJump.c
>deleted file mode 100644
>index 2c1feb8373..00
>--- a/MdePkg/Library/BaseLib/Ia32/LongJump.c
>+++ /dev/null
>@@ -1,76 +0,0 @@
>-/** @file
>-  Implementation of _LongJump() on IA-32.
>-
>-  Copyright (c) 2006 - 2019, 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.
>-
>-**/
>-
>-
>-#include "BaseLibInternals.h"
>-
>-
>-/**
>-  Restores the CPU context that was saved with SetJump().
>-
>-  Restores the CPU context from the buffer specified by JumpBuffer.
>-  This function never returns to the caller.
>-  Instead is resumes execution based on the state of JumpBuffer.
>-
>-  @param  JumpBufferA pointer to CPU context buffer.
>-  @param  Value The value to return when the SetJump() context is
>restored.
>-
>-**/
>-__declspec (naked)
>-VOID
>-EFIAPI
>-InternalLongJump (
>-  IN  BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer,
>-  IN  UINTN Value
>-  )
>-{
>-  _asm {
>-mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
>-testeax, eax
>-jz  CetDone
>-_emit  0x0F
>-_emit  0x20
>-_emit  0xE0; mov eax, cr4
>-bt  eax, 23; check if CET is enabled
>-jnc CetDone
>-
>-mov edx, [esp + 4] ; edx = JumpBuffer
>-mov edx, [edx + 24]; edx = target SSP
>-_emit  0xF3
>-_emit  0x0F
>-_emit  0x1E
>-_emit  0xC8; READSSP EAX
>-sub edx, eax   ; edx = delta
>-mov eax, edx   ; eax = delta
>-
>-shr eax, 2 ; eax = delta/sizeof(UINT32)
>-_emit  0xF3
>-_emit  0x0F
>-_emit  0xAE
>-_emit  0xE8; INCSSP EAX
>-
>-CetDone:
>-
>-pop eax ; skip return address
>-pop edx ; edx <- JumpBuffer
>-pop eax ; eax <- Value
>-mov ebx, [edx]
>-mov esi, [edx + 4]
>-mov edi, [edx + 8]
>-mov ebp, [edx + 12]
>-mov esp, [edx + 16]
>-jmp dword ptr [edx + 20]
>-  }
>-}
>-
>diff --git 

[edk2-devel] [Patch] BaseTools: Sometime write file not immediate to disk

2019-04-10 Thread Liming Gao
From: Yunhua Feng 

BZ: https://bugzilla.tianocore.org/process_bug.cgi

On Windows OS, sometime the generated file is not immediate saved to disk.
When run nmake, prompt AutoGen.h not found, and stop build.
Below blog shows Write-Replace to fix it. This patch uses this way to write
temp file, then rename the temp file to the real file.
https://blog.gocept.com/2013/07/15/reliable-file-updates-with-python/

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Common/Misc.py | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 5db9405ddc..3b3ab2d6df 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -22,6 +22,7 @@ from random import sample
 from struct import pack
 import uuid
 import subprocess
+import tempfile
 from collections import OrderedDict
 
 import Common.LongFilePathOs as os
@@ -476,15 +477,23 @@ def SaveFileOnChange(File, Content, IsBinaryFile=True):
 if not os.access(DirName, os.W_OK):
 EdkLogger.error(None, PERMISSION_FAILURE, "Do not have write 
permission on directory %s" % DirName)
 
+OpenMode = "w"
 if IsBinaryFile:
+OpenMode = "wb"
+
+if GlobalData.gIsWindows and not os.path.exists(File):
+# write temp file, then rename the temp file to the real file
+# to make sure the file be immediate saved to disk
+with tempfile.NamedTemporaryFile(OpenMode, dir=os.path.dirname(File), 
delete=False) as tf:
+tf.write(Content)
+tempname = tf.name
 try:
-with open(File, "wb") as Fd:
-Fd.write(Content)
-except IOError as X:
+os.rename(tempname, File)
+except:
 EdkLogger.error(None, FILE_CREATE_FAILURE, ExtraData='IOError %s' 
% X)
 else:
 try:
-with open(File, 'w') as Fd:
+with open(File, OpenMode) as Fd:
 Fd.write(Content)
 except IOError as X:
 EdkLogger.error(None, FILE_CREATE_FAILURE, ExtraData='IOError %s' 
% X)
-- 
2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38848): https://edk2.groups.io/g/devel/message/38848
Mute This Topic: https://groups.io/mt/31027692/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Building EDK2 code on arm64 (aarch64) - BaseTools fails

2019-04-10 Thread Rebecca Cran via Groups.Io

On 2019-04-10 20:07, Rebecca Cran via Groups.Io wrote:
Thanks. I'm working on fixing it now: it looks like it needs new 
compiler flags in BaseTools/Source/C/Makefiles/header.makefile, as 
well as recognizing arm64 as a platform name in addition to aarch64



It didn't need any compiler flag changes after all: it only needed the 
change to recognize 'arm64' as a platform name, in addition to avoiding 
falling through to the 'arm' case which was causing it to still pull in 
the ARM instead of AARCH64 headers.



--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38847): https://edk2.groups.io/g/devel/message/38847
Mute This Topic: https://groups.io/mt/31015935/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2][PATCH V2] BaseTools:Enable the /MP option of MSVC compiler

2019-04-10 Thread BobCF
I also added the incremental build performance data in BZ 
https://bugzilla.tianocore.org/show_bug.cgi?id=1672

-Bob

-Original Message-
From: Fan, ZhijuX 
Sent: Wednesday, April 10, 2019 4:51 PM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C 
Subject: [edk2][PATCH V2] BaseTools:Enable the /MP option of MSVC compiler

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1672
The /MP option of MSVC compiler can reduce the total time to compile the source 
files on the command line.

This patch is going to enable this MSVC option in BaseTools.

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Conf/tools_def.template  | 126 ++---
 BaseTools/Source/Python/AutoGen/GenMake.py |  81 +--
 2 files changed, 137 insertions(+), 70 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index abda2164a6..bffb6d63eb 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -674,9 +674,9 @@ NOOPT_VS2008_IA32_DLINK_FLAGS = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF
 *_VS2008_X64_ASLPP_PATH= DEF(VS2008_BINX64)\cl.exe
 *_VS2008_X64_ASLDLINK_PATH = DEF(VS2008_BINX64)\link.exe
 
-  DEBUG_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm
-RELEASE_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
+  DEBUG_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /MP
+RELEASE_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /MP
+NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /Od /MP
 
   DEBUG_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -876,9 +876,9 @@ NOOPT_VS2008xASL_X64_DLINK_FLAGS= /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:RE
 *_VS2008x86_IA32_ASM_PATH = DEF(VS2008x86_BIN)\ml.exe
 
   *_VS2008x86_IA32_MAKE_FLAGS  = /nologo
-  DEBUG_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
-RELEASE_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2008x86_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
+  DEBUG_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /MP
+RELEASE_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /MP
+NOOPT_VS2008x86_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Od /MP
 
   DEBUG_VS2008x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2008x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -908,9 +908,9 @@ NOOPT_VS2008x86_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF
 *_VS2008x86_X64_DLINK_PATH= DEF(VS2008x86_BINX64)\link.exe
 *_VS2008x86_X64_ASLDLINK_PATH = DEF(VS2008x86_BINX64)\link.exe
 
-  DEBUG_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm
-RELEASE_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2008x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
+  DEBUG_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /MP
+RELEASE_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /MP
+NOOPT_VS2008x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /Od /MP
 
   DEBUG_VS2008x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2008x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -1109,9 +1109,9 @@ NOOPT_VS2008x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 *_VS2010_IA32_ASLDLINK_PATH   = DEF(VS2010_BIN)\link.exe
 
   *_VS2010_IA32_MAKE_FLAGS= /nologo
-  DEBUG_VS2010_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
-RELEASE_VS2010_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2010_IA32_CC_FLAGS

[edk2-devel] [PATCH] BaseTools: support arm64 as a platform name in addition to aarch64

2019-04-10 Thread Rebecca Cran via Groups.Io
Some systems such as FreeBSD identify the platform as 'arm64'
and not 'aarch64' as Linux does.

Signed-off-by: Rebecca Cran 
---
 BaseTools/Source/C/GNUmakefile   | 5 +++--
 BaseTools/Source/C/Makefiles/header.makefile | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/C/GNUmakefile b/BaseTools/Source/C/GNUmakefile
index 1d048c4cc6..37bcce519c 100644
--- a/BaseTools/Source/C/GNUmakefile
+++ b/BaseTools/Source/C/GNUmakefile
@@ -21,8 +21,9 @@ ifndef HOST_ARCH
   endif
   ifneq (,$(findstring aarch64,$(uname_m)))
 HOST_ARCH=AARCH64
-  endif
-  ifneq (,$(findstring arm,$(uname_m)))
+  else ifneq (,$(findstring arm64,$(uname_m)))
+HOST_ARCH=AARCH64
+  else ifneq (,$(findstring arm,$(uname_m)))
 HOST_ARCH=ARM
   endif
   ifndef HOST_ARCH
diff --git a/BaseTools/Source/C/Makefiles/header.makefile 
b/BaseTools/Source/C/Makefiles/header.makefile
index 90fb3453ad..d76b8283dd 100644
--- a/BaseTools/Source/C/Makefiles/header.makefile
+++ b/BaseTools/Source/C/Makefiles/header.makefile
@@ -23,8 +23,9 @@ ifndef HOST_ARCH
   endif
   ifneq (,$(findstring aarch64,$(uname_m)))
 HOST_ARCH=AARCH64
-  endif
-  ifneq (,$(findstring arm,$(uname_m)))
+  else ifneq (,$(findstring arm64,$(uname_m)))
+HOST_ARCH=AARCH64
+  else ifneq (,$(findstring arm,$(uname_m)))
 HOST_ARCH=ARM
   endif
   ifndef HOST_ARCH
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38845): https://edk2.groups.io/g/devel/message/38845
Mute This Topic: https://groups.io/mt/31026994/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Building EDK2 code on arm64 (aarch64) - BaseTools fails

2019-04-10 Thread Rebecca Cran via Groups.Io

On 2019-04-10 18:09, Liming Gao wrote:

Yes. No test on FreeBSD. If possible, can you contribute the patch to fix this 
issue on FreeBSD?




Thanks. I'm working on fixing it now: it looks like it needs new 
compiler flags in BaseTools/Source/C/Makefiles/header.makefile, as well 
as recognizing arm64 as a platform name in addition to aarch64.



--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38844): https://edk2.groups.io/g/devel/message/38844
Mute This Topic: https://groups.io/mt/31015935/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] BaseTools: Hash false success with back to back builds

2019-04-10 Thread BobCF
The patch looks good for me.

Reviewed-by: Bob Feng 

-Bob

-Original Message-
From: Rodriguez, Christian 
Sent: Wednesday, April 10, 2019 11:27 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming ; 
Zhu, Yonghong 
Subject: [PATCH] BaseTools: Hash false success with back to back builds

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

Add error handling to the --hash feature so that hash files are invalidated 
when a build error occurs.

Signed-off-by: Christian Rodriguez 
Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
---
 BaseTools/Source/Python/Common/GlobalData.py |  4 
 BaseTools/Source/Python/build/build.py   | 45 
+
 2 files changed, 49 insertions(+)

diff --git a/BaseTools/Source/Python/Common/GlobalData.py 
b/BaseTools/Source/Python/Common/GlobalData.py
index 1853f1d2f6..79f23c892d 100644
--- a/BaseTools/Source/Python/Common/GlobalData.py
+++ b/BaseTools/Source/Python/Common/GlobalData.py
@@ -108,3 +108,7 @@ gPackageHash = {}
 gModuleHash = {}
 gEnableGenfdsMultiThread = False
 gSikpAutoGenCache = set()
+
+# Dictionary for tracking Module build status as success or failure # 
+False -> Fail : True -> Success gModuleBuildTracking = dict()
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index af8bba47b1..71478b7268 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -620,6 +620,8 @@ class BuildTask:
 BuildTask._ErrorFlag.set()
 BuildTask._ErrorMessage = "%s broken\n%s [%s]" % \
   (threading.currentThread().getName(), 
Command, WorkingDir)
+if self.BuildItem.BuildObject in GlobalData.gModuleBuildTracking and 
not BuildTask._ErrorFlag.isSet():
+GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] 
+ = True
 # indicate there's a thread is available for another build task
 BuildTask._RunningQueueLock.acquire()
 BuildTask._RunningQueue.pop(self.BuildItem)
@@ -1138,6 +1140,37 @@ class Build():
 if Process.returncode != 0 :
 EdkLogger.error("Postbuild", POSTBUILD_ERROR, 'Postbuild 
process is not success!')
 EdkLogger.info("\n- Postbuild Done -\n")
+
+## Error handling for hash feature
+#
+# On BuildTask error, iterate through the Module Build tracking
+# dictionary to determine wheather a module failed to build. Invalidate
+# the hash associated with that module by removing it from storage.
+#
+#
+def invalidateHash(self):
+# GlobalData.gModuleBuildTracking contains only modules that cannot be 
skipped by hash
+for moduleAutoGenObj in GlobalData.gModuleBuildTracking.keys():
+# False == FAIL : True == Success
+# Skip invalidating for Successful module builds
+if GlobalData.gModuleBuildTracking[moduleAutoGenObj] == True:
+continue
+
+# The module failed to build or failed to start building, 
+ from this point on
+
+# Remove .hash from build
+if GlobalData.gUseHashCache:
+ModuleHashFile = path.join(moduleAutoGenObj.BuildDir, 
moduleAutoGenObj.Name + ".hash")
+if os.path.exists(ModuleHashFile):
+os.remove(ModuleHashFile)
+
+# Remove .hash file from cache
+if GlobalData.gBinCacheSource:
+FileDir = path.join(GlobalData.gBinCacheSource, 
moduleAutoGenObj.Arch, moduleAutoGenObj.SourceDir, 
moduleAutoGenObj.MetaFile.BaseName)
+HashFile = path.join(FileDir, moduleAutoGenObj.Name + '.hash')
+if os.path.exists(HashFile):
+os.remove(HashFile)
+
 ## Build a module or platform
 #
 # Create autogen code and makefile for a module or platform, and the 
launch @@ -1795,6 +1828,9 @@ class Build():
 if self.Target == "genmake":
 return True
 self.BuildModules.append(Ma)
+# Initialize all modules in tracking to False 
(FAIL)
+if Ma not in GlobalData.gModuleBuildTracking:
+GlobalData.gModuleBuildTracking[Ma] = 
+ False
 self.AutoGenTime += int(round((time.time() - 
AutoGenStart)))
 MakeStart = time.time()
 for Ma in self.BuildModules:
@@ -1805,6 +1841,7 @@ class Build():
 # we need a full version of makefile for platform
 ExitFlag.set()
 BuildTask.WaitForComplete()
+self.invalidateHash()
 Pa.CreateMakeFile(False)
 EdkLogger.error("build", BUILD_ERROR, "Failed to 
build module", ExtraData=GlobalData.gBuildingModule)
   

Re: [edk2-devel] [Patch] BaseTools/PatchCheck: Generate error if Contributed under found

2019-04-10 Thread Liming Gao
Mike:
  Could you also update wiki 
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format to 
remove Contributed-under: TianoCore Contribution Agreement 1.1?

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Michael D Kinney
>Sent: Friday, April 05, 2019 6:43 AM
>To: devel@edk2.groups.io
>Cc: Justen, Jordan L ; Feng, Bob C
>; Gao, Liming ; Zhu,
>Yonghong 
>Subject: [edk2-devel] [Patch] BaseTools/PatchCheck: Generate error if
>Contributed under found
>
>https://bugzilla.tianocore.org/show_bug.cgi?id=1655
>
>With the change to BSD+Patent License, the TianoCore Contributor's
>Agreement has been removed and as a result, a Contributed under
>tag is no longer appropriate in patches.  Remove the check for
>the TianoCore Contributor's Agreement and instead, generate an
>error if a patch contains a Contributed under tag in the commit
>message.
>
>Cc: Jordan Justen 
>Cc: Bob Feng 
>Cc: Liming Gao 
>Cc: Yonghong Zhu 
>Signed-off-by: Michael D Kinney 
>---
> BaseTools/Scripts/PatchCheck.py | 12 
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
>diff --git a/BaseTools/Scripts/PatchCheck.py
>b/BaseTools/Scripts/PatchCheck.py
>index 0b580f3b31..19a7159358 100755
>--- a/BaseTools/Scripts/PatchCheck.py
>+++ b/BaseTools/Scripts/PatchCheck.py
>@@ -1,7 +1,7 @@
> ## @file
> #  Check a patch for various format issues
> #
>-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
>+#  Copyright (c) 2015 - 2019, 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
>@@ -75,13 +75,9 @@ class CommitMessageCheck:
> count += 1
>
> def check_contributed_under(self):
>-cu_msg='Contributed-under: TianoCore Contribution Agreement 1.1'
>-if self.msg.find(cu_msg) < 0:
>-# Allow 1.0 for now while EDK II community transitions to 1.1
>-cu_msg='Contributed-under: TianoCore Contribution Agreement 1.0'
>-if self.msg.find(cu_msg) < 0:
>-self.error('Missing Contributed-under! (Note: this must be ' +
>-   'added by the code contributor!)')
>+if self.msg.find('Contributed-under') >= 0:
>+self.error('Contributed-under! (Note: this must be ' +
>+   'removed by the code contributor!)')
>
> @staticmethod
> def make_signature_re(sig, re_input=False):
>--
>2.21.0.windows.1
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38842): https://edk2.groups.io/g/devel/message/38842
Mute This Topic: https://groups.io/mt/30911614/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 0/8] Duplicate 8259/8254 components in OvmfPkg

2019-04-10 Thread Wu, Hao A
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, April 11, 2019 12:26 AM
> To: Wu, Hao A; devel@edk2.groups.io
> Cc: Justen, Jordan L; Ard Biesheuvel; David Woodhouse; Ni, Ray
> Subject: Re: [PATCH v2 0/8] Duplicate 8259/8254 components in OvmfPkg
> 
> On 04/10/19 03:06, Hao Wu wrote:
> > This series is also available at:
> > https://github.com/hwu25/edk2/tree/ovmf_8259_8254_v2
> >
> >
> > V2 changes:
> >
> > Due to the file license change, rebase the whole series onto the tip of
> > the master branch. The 'Contributed-under' tag is removed from the log
> > messages as well.
> >
> > The V2 series keeps all the 'Reviewed-by' tags from Laszlo from the
> > previous version of the series.
> 
> I skimmed this version briefly, with an eye towards my v1 requests. The
> v2 series looks fine to me, ready for pushing.

Thanks Laszlo,

Series has been pushed at:
ddb8cedce7..6d70ade90c

Best Regards,
Hao Wu

> 
> Thanks!
> Laszlo
> 
> >
> >
> > V1 history:
> >
> > As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
> >
> > 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> > Legacy8259 protocol (IntelFrameworkPkg)
> > 8254TimerDxe driver (PcAtChipsetPkg)
> >
> > will be removed in the near future. Meanwhile, OVMF will still require
> > those components (due to CSM support & HPET emulation stability
> concern).
> >
> > Thus, the series will copy the below 8259/8254 components:
> >
> > A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> > B. Two 8259 related PCDs (PcAtChipsetPkg)
> > C. Legacy8259 protocol (IntelFrameworkPkg)
> > D. 8254TimerDxe driver (PcAtChipsetPkg)
> >
> > in the OvmfPkg to address the above-mentioned issue.
> >
> >
> > Tests done for the proposed series:
> >
> > A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
> > B. Boot to Shell with commands:
> >   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon
> file:boot.log -global isa-debugcon.iobase=0x402
> >   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd
> -debugcon file:boot.log -global isa-debugcon.iobase=0x402
> > C. 'stall X' command under Shell to verify the timer is working properly.
> >
> >
> > (Please note that there will be a subsequent patch to remove the
> 8259/8254
> > components after platforms dropping the dependencies on them.)
> >
> > Cc: Jordan Justen 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> > Cc: David Woodhouse 
> > Cc: Ray Ni 
> >
> >
> > Hao Wu (8):
> >   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
> >   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
> >   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
> >   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
> >   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
> >   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
> >   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
> >   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg
> >
> >  OvmfPkg/OvmfPkg.dec|  29 +-
> >  OvmfPkg/OvmfPkgIa32.dsc|   6 +-
> >  OvmfPkg/OvmfPkgIa32X64.dsc |   6 +-
> >  OvmfPkg/OvmfPkgX64.dsc |   6 +-
> >  OvmfPkg/OvmfPkgIa32.fdf|   4 +-
> >  OvmfPkg/OvmfPkgIa32X64.fdf |   4 +-
> >  OvmfPkg/OvmfPkgX64.fdf |   4 +-
> >  OvmfPkg/8254TimerDxe/8254Timer.inf |  42 ++
> >  OvmfPkg/8259InterruptControllerDxe/8259.inf|  45 ++
> >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf|   5 +-
> >  OvmfPkg/8254TimerDxe/Timer.h   | 185 ++
> >  OvmfPkg/8259InterruptControllerDxe/8259.h  | 218 +++
> >  OvmfPkg/Include/Protocol/Legacy8259.h  | 291 +
> >  OvmfPkg/8254TimerDxe/Timer.c   | 401 +
> >  OvmfPkg/8259InterruptControllerDxe/8259.c  | 622
> 
> >  OvmfPkg/8254TimerDxe/Timer.uni |  16 +
> >  OvmfPkg/8254TimerDxe/TimerExtra.uni|  14 +
> >  OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni  |  16 +
> >  OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  14 +
> >  19 files changed, 1909 insertions(+), 19 deletions(-)
> >  create mode 100644 OvmfPkg/8254TimerDxe/8254Timer.inf
> >  create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.inf
> >  create mode 100644 OvmfPkg/8254TimerDxe/Timer.h
> >  create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.h
> >  create mode 100644 OvmfPkg/Include/Protocol/Legacy8259.h
> >  create mode 100644 OvmfPkg/8254TimerDxe/Timer.c
> >  create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.c
> >  create mode 100644 OvmfPkg/8254TimerDxe/Timer.uni
> >  create mode 100644 OvmfPkg/8254TimerDxe/TimerExtra.uni
> >  create mode 100644 

Re: [edk2-devel] [PATCH] IntelFrameworkModulePkg: Fix comments and improve E820 debug output

2019-04-10 Thread Liming Gao
Push on commit ddb8cedce7e07b87c0ac6b84cd750a6d3dac47c8

>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Liming Gao
>Sent: Monday, April 08, 2019 9:16 PM
>To: Philippe Mathieu-Daudé ; rebe...@bluestop.org
>Cc: devel@edk2.groups.io
>Subject: Re: [edk2-devel] [PATCH] IntelFrameworkModulePkg: Fix comments
>and improve E820 debug output
>
>Reviewed-by: Liming Gao 
>
>> -Original Message-
>> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
>> Sent: Friday, April 5, 2019 5:05 PM
>> To: rebe...@bluestop.org; Gao, Liming 
>> Cc: devel@edk2.groups.io
>> Subject: Re: [edk2-devel] [PATCH] IntelFrameworkModulePkg: Fix
>comments and improve E820 debug output
>>
>> On 4/4/19 7:56 PM, Rebecca Cran via Groups.Io wrote:
>> > Fix a few typos in LegacyBiosBuildE820, and improve the debug output of
>> > the E820 table to pad with zeros instead of spaces, remove extra hyphens
>> > and display the memory type in decimal.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.1
>> > Signed-off-by: Rebecca Cran 
>>
>> Reviewed-by: Philippe Mathieu-Daude 
>>
>> > ---
>> >  .../Csm/LegacyBiosDxe/LegacyBootSupport.c  | 10 +-
>> >  1 file changed, 5 insertions(+), 5 deletions(-)
>> >
>> > diff --git
>a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>> > index a7b8e6a9a0..8c415cdfc6 100644
>> > ---
>a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>> > +++
>b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>> > @@ -1711,9 +1711,9 @@ LegacyBiosBuildE820 (
>> >
>> >do {
>> >  //
>> > -// Use size returned back plus 1 descriptor for the AllocatePool.
>> > +// Use size returned for the AllocatePool.
>> >  // We don't just multiply by 2 since the "for" loop below terminates 
>> > on
>> > -// EfiMemoryMapEnd which is dependent upon EfiMemoryMapSize.
>Otherwize
>> > +// EfiMemoryMapEnd which is dependent upon EfiMemoryMapSize.
>Otherwise
>> >  // we process bogus entries and create bogus E820 entries.
>> >  //
>> >  EfiMemoryMap = (EFI_MEMORY_DESCRIPTOR *) AllocatePool
>(EfiMemoryMapSize);
>> > @@ -1801,7 +1801,7 @@ LegacyBiosBuildE820 (
>> >  MemoryBlockLength = (UINT64) (LShiftU64 (EfiEntry->NumberOfPages,
>12));
>> >  if ((EfiEntry->PhysicalStart + MemoryBlockLength) < 0x10) {
>> >//
>> > -  // Skip the memory block is under 1MB
>> > +  // Skip the memory block if under 1MB
>> >//
>> >  } else {
>> >if (EfiEntry->PhysicalStart < 0x10) {
>> > @@ -1926,7 +1926,7 @@ LegacyBiosBuildE820 (
>> >*Size = (UINTN) (Index * sizeof (EFI_E820_ENTRY64));
>> >
>> >//
>> > -  // Determine OS usable memory above 1Mb
>> > +  // Determine OS usable memory above 1MB
>> >//
>> >Private->IntThunk->EfiToLegacy16BootTable.OsMemoryAbove1Mb =
>0x;
>> >for (TempIndex = Above1MIndex; TempIndex < Index; TempIndex++) {
>> > @@ -1948,7 +1948,7 @@ LegacyBiosBuildE820 (
>> >// Print DEBUG information
>> >//
>> >for (TempIndex = 0; TempIndex < Index; TempIndex++) {
>> > -DEBUG((EFI_D_INFO, "E820[%2d]: 0x%16lx  0x%16lx, Type = 0x%x
>\n",
>> > +DEBUG((EFI_D_INFO, "E820[%2d]: 0x%016lx - 0x%016lx, Type = %d\n",
>> >TempIndex,
>> >E820Table[TempIndex].BaseAddr,
>> >(E820Table[TempIndex].BaseAddr + E820Table[TempIndex].Length),
>> >
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38840): https://edk2.groups.io/g/devel/message/38840
Mute This Topic: https://groups.io/mt/30899017/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Building EDK2 code on arm64 (aarch64) - BaseTools fails

2019-04-10 Thread Liming Gao
Yes. No test on FreeBSD. If possible, can you contribute the patch to fix this 
issue on FreeBSD? 

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Laszlo Ersek
>Sent: Thursday, April 11, 2019 1:31 AM
>To: devel@edk2.groups.io; rebe...@bluestop.org
>Subject: Re: [edk2-devel] Building EDK2 code on arm64 (aarch64) - BaseTools
>fails
>
>On 04/10/19 06:57, Rebecca Cran via Groups.Io wrote:
>> Is there any expectation that EDK2 will build on non-x86 systems?
>
>Yes. It should certainly build on aarch64 (Linux at least).
>
>>
>> I tried building BaseTools (from git master,
>> ae2fb9ead47b5abaf2a4e815b5f57c8f4838b221) using GCC 8.2 on a SoftIron
>> OverDrive 1000 (running FreeBSD) but there are lots of errors, such as:
>
>The issue here must be "FreeBSD". That's not supported as a build host
>OS, to my knowledge.
>
>I assume the build platform check in the BaseTools makefiles / scripts
>fail due to FreeBSD.
>
>edk2 platforms are otherwise regularly built on aarch64 Linux.
>
>Thanks
>Laszlo
>
>>
>>
>> gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I
>> ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/Arm/
>> -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
>> -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict
>> -Wno-unused-result -nostdlib -g -O2  BasePeCoff.c -o BasePeCoff.o
>> BasePeCoff.c: In function 'PeCoffLoaderGetPeHeader':
>> BasePeCoff.c:120:49: error: cast from pointer to integer of different
>> size [-Werror=pointer-to-int-cast]
>>    *PeHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)
>> ((UINTN)ImageContext->Handle + ImageContext->PeCoffHeaderOffset);
>>  ^
>> BasePeCoff.c:120:12: error: cast to pointer from integer of different
>> size [-Werror=int-to-pointer-cast]
>>    *PeHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)
>> ((UINTN)ImageContext->Handle + ImageContext->PeCoffHeaderOffset);
>>     ^
>> BasePeCoff.c: In function 'PeCoffLoaderImageAddress':
>> BasePeCoff.c:551:10: error: cast to pointer from integer of different
>> size [-Werror=int-to-pointer-cast]
>>    return (UINT8 *) ((UINTN) ImageContext->ImageAddress + Address);
>>   ^
>>
>>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38839): https://edk2.groups.io/g/devel/message/38839
Mute This Topic: https://groups.io/mt/31015935/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms/devel-MinPlatform] [patch 0/3] Update to use shell source directly

2019-04-10 Thread Sinha, Ankit
Reviewed-by: Ankit Sinha 

-Original Message-
From: Bi, Dandan 
Sent: Tuesday, April 9, 2019 10:33 PM
To: devel@edk2.groups.io
Cc: Kubacki, Michael A ; Sinha, Ankit 
; Desimone, Nathaniel L 
; Chiu, Chasel ; Lu, 
Shifei A ; Zhou, Bowen ; Oram, 
Isaac W 
Subject: [edk2-platforms/devel-MinPlatform] [patch 0/3] Update to use shell 
source directly

The series will update ClevoOpenBoardPkg KabylakeOpenBoardPkg and 
PurleyOpenBoardPkg to use ShellPkg directly.

Test done for the series:
Build pass for ClevoOpenBoardPkg KabylakeOpenBoardPkg and PurleyOpenBoardPkg.
Boot to shell with KBLRvp3.

Cc: Michael Kubacki 
Cc: Ankit Sinha 
Cc: Nate DeSimone 
Cc: Chasel Chiu 
Cc: Shifei A Lu 
Cc: Xiaohu Zhou 
Cc: Isaac W Oram 

Dandan Bi (3):
  ClevoOpenBoardPkg/N1xxWU: Use shell source directly
  KabylakeOpenBoardPkg/KBLRvp3: Use shell source directly
  PurleyOpenBoardPkg/BoardMtOlympus: Use shell source directly

 .../ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.dsc | 22 ++-  
.../ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf |  2 +-
 .../KabylakeRvp3/OpenBoardPkg.dsc | 22 ++-
 .../KabylakeRvp3/OpenBoardPkg.fdf |  2 +-
 .../BoardMtOlympus/PlatformPkg.dsc| 22 ++-
 .../BoardMtOlympus/PlatformPkg.fdf|  2 +-
 6 files changed, 66 insertions(+), 6 deletions(-)

--
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38838): https://edk2.groups.io/g/devel/message/38838
Mute This Topic: https://groups.io/mt/31016077/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms/devel-MinPlatform] [patch 0/3] Update to use shell source directly

2019-04-10 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

-Original Message-
From: Bi, Dandan 
Sent: Tuesday, April 9, 2019 10:33 PM
To: devel@edk2.groups.io
Cc: Kubacki, Michael A ; Sinha, Ankit 
; Desimone, Nathaniel L 
; Chiu, Chasel ; Lu, 
Shifei A ; Zhou, Bowen ; Oram, 
Isaac W 
Subject: [edk2-platforms/devel-MinPlatform] [patch 0/3] Update to use shell 
source directly

The series will update ClevoOpenBoardPkg KabylakeOpenBoardPkg and 
PurleyOpenBoardPkg to use ShellPkg directly.

Test done for the series:
Build pass for ClevoOpenBoardPkg KabylakeOpenBoardPkg and PurleyOpenBoardPkg.
Boot to shell with KBLRvp3.

Cc: Michael Kubacki 
Cc: Ankit Sinha 
Cc: Nate DeSimone 
Cc: Chasel Chiu 
Cc: Shifei A Lu 
Cc: Xiaohu Zhou 
Cc: Isaac W Oram 

Dandan Bi (3):
  ClevoOpenBoardPkg/N1xxWU: Use shell source directly
  KabylakeOpenBoardPkg/KBLRvp3: Use shell source directly
  PurleyOpenBoardPkg/BoardMtOlympus: Use shell source directly

 .../ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.dsc | 22 ++-  
.../ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf |  2 +-
 .../KabylakeRvp3/OpenBoardPkg.dsc | 22 ++-
 .../KabylakeRvp3/OpenBoardPkg.fdf |  2 +-
 .../BoardMtOlympus/PlatformPkg.dsc| 22 ++-
 .../BoardMtOlympus/PlatformPkg.fdf|  2 +-
 6 files changed, 66 insertions(+), 6 deletions(-)

--
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38837): https://edk2.groups.io/g/devel/message/38837
Mute This Topic: https://groups.io/mt/31016077/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH 1/5] OvmfPkg/build.sh: Require QEMU 1.6 or newer and always enable flash

2019-04-10 Thread Jordan Justen
On 2019-04-10 07:16:34, Laszlo Ersek wrote:
> Hi Jordan,
> 
> I've asked Phil (CC'd) to review this series in my stead. I'll be happy
> to provide an ACK when Phil gives his R-b (if I should forget, please
> ping me separately).
> 
> In the future, please include a cover letter; a cumulative diffstat
> usually helps with the review. (I've had to check all patches to see
> that only build.sh is being modified.)

I did create a cover letter, but then I deleted it. I thought I was
making too much out of it...

>From what I gather, you don't find this script useful, and therefore I
sometimes wonder if I'm the only one that uses it. :)

-Jordan

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38836): https://edk2.groups.io/g/devel/message/38836
Mute This Topic: https://groups.io/mt/31017199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH 3/5] OvmfPkg/build.sh: Move automatic TARGET_TOOLS detection later

2019-04-10 Thread Jordan Justen
On 2019-04-10 08:37:22, Philippe Mathieu-Daudé wrote:
> Hi Jordan,
> 
> On 4/10/19 11:34 AM, Jordan Justen wrote:
> > If we are building for a non-native ARM, then we may need to select a
> > cross-compiler based on the -a paramter.
> 
> I am sorry but I am non-native English and I have hard time to
> understand your comment.
> 
> OVMF targets x86 hardware, which is obviously not ARM.

>From OvmfPkg/README:

"The Open Virtual Machine Firmware (OVMF) project aims to support
firmware for Virtual Machines using the edk2 code base."

This doesn't appear to indicate any particular architecture or VMM.
Nevertheless, ArmVirtPkg was created, so in effect, you are correct.

> And I'm not aware of another target architecture. Are you talking
> about the host where you build?

I mean the target. The patch looks for something like "-a AARCH64" on
the command line. If found, we try to build ArmVirtPkg/ArmVirtQemu.dsc
instead of OVMF.

It's a bit of a hack in that it will try to build the dsc from another
package. But, OvmfPkg/build.sh is a little more generic than one might
expect. For example, when I want to build MdeModulePkg, I usually just
run:

OvmfPkg/build.sh -p MdeModulePkg/MdeModulePkg.dsc

I find it convenient that the script sets up the build environment
automatically, and after the script is done, no changes persist in my
shell's environment.

> I am trying your series on a Aarch64 host but I fail at passing the
> correct cross gcc. I set GCC5_IA32_PREFIX, GCC5_X64_PREFIX and GCC5_BIN
> env vars, but the build script still run '"gcc"' instead of my cross one.
> 
> A more generic comment regarding your series: how do you use this script?

Yeah, you are right. The comments could be better. I'll try to improve
them.

Basically, these changes let me build ArmVirtPkg/ArmVirtQemu.dsc on
x86_64 Linux by simply added "-a AARCH64" or "-a ARM" parameteres to
this script. It also helped setup the qemu command line. Here are the
4 commands I used on x86_64 Linux to build and run ArmVirtPkg:

$ OvmfPkg/build.sh -a AARCH64

$ OvmfPkg/build.sh -a AARCH64 qemu -m 1024 -cpu cortex-a57 -M virt -net none

$ OvmfPkg/build.sh -a ARM

$ OvmfPkg/build.sh -a ARM qemu -m 1024 -cpu cortex-a15 -M virt -net none

I think the script might be usable on an ARM based build systems as
well, but it might require further tweaks. Ideally, if the build
system was AARCH64 based, then:

* OvmfPkg/build.sh: (with no params) would cause AARCH64 ArmVirtPkg to
  be built using a native compiler.

* OvmfPkg/build.sh -a ARM: would cause ARM ArmVirtPkg to be built
  using a cross compiler.

* OvmfPkg/build.sh -a X64: would cause X64 OVMF to be built using a
  cross compiler.

-Jordan

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38835): https://edk2.groups.io/g/devel/message/38835
Mute This Topic: https://groups.io/mt/31017201/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 0/6] Fix PEI Core issue during TemporaryRamMigration

2019-04-10 Thread Jordan Justen
On 2019-04-10 09:41:43, Ard Biesheuvel wrote:
> On Wed, 10 Apr 2019 at 01:41, Jordan Justen  wrote:
> >
> > https://github.com/jljusten/edk2.git temp-ram-support-v2
> >
> > https://github.com/jljusten/edk2/commits/temp-ram-support-v2
> >
> > v2:
> >  * Add AARCH64 and ARM assembly
> 
> Hi Jordan,
> 
> I'm not sure I'm following the reasoning behind this.

Did you see the explanation in patch 1 commit message? Could you reply
there with questions, or maybe I should try to expand on that?

> Does this fix an issue we currently have on ARM systems?

Yes, but I don't know of a case where it has been observed on
AARCH64/ARM. Nevertheless, as far as I can tell, a similar issue could
happen because the current implementation relies on non-spec'd
behavior of code gen within a C function. (Not the C calling
convention, but what code does with inside the function between
calls.)

> And how did you build and/or test OVMF for ARM?

I built ArmVirtPkg for AARCH64 and ARM on x86_64 Linux with a
cross-compiler, and ran it with qemu.

-Jordan

> 
> >  * Drop IA32 and X64 .S source files
> >  * Adjust PEI_CORE_TEMPORARY_RAM_TRANSITION pointer in the assembly
> >code based on the stack pointer change before & after
> >TemporaryRamSupport->TemporaryRamMigration
> >  * Drop extra cleanup patches for OvmfPkg & EmulatorPkg. These were
> >just complicating the series.
> >
> > This series fixes an issue that, while rare, is possible based on the
> > way the TemporaryRamSupport PPI is defined along with how it is used
> > by the PEI Core.
> >
> > Liu Yu reported a boot issue with EmulatorPkg, which I believe was
> > caused by this issue.
> >
> > The details of the issue are described in the commit message of the
> > "MdeModulePkg/Core/Pei: Add interface for assembly based
> > TemporaryRamSupport" patch.
> >
> > Testing:
> >
> > I tested building and booting in several scenarios:
> >
> > * OVMF IA32 & X64 on Linux
> > * ArmVirtPkg AARCH64 & ARM on x86_64 Linux
> > * EmulatorPkg IA32 & X64 on Linux
> >
> > Untested:
> >
> > * My system does not reproduce the issue that Liu Yu reported with
> >   EmulatorPkg, so I can't say that I have verified that issue.
> > * Building on windows
> > * AARCH64/ARM TemporaryRamMigration.asm sources

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38834): https://edk2.groups.io/g/devel/message/38834
Mute This Topic: https://groups.io/mt/31016921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 0/6] Fix PEI Core issue during TemporaryRamMigration

2019-04-10 Thread Ard Biesheuvel
On Wed, 10 Apr 2019 at 11:28, Laszlo Ersek  wrote:
>
> On 04/10/19 18:41, Ard Biesheuvel wrote:
> > On Wed, 10 Apr 2019 at 01:41, Jordan Justen  
> > wrote:
> >>
> >> https://github.com/jljusten/edk2.git temp-ram-support-v2
> >>
> >> https://github.com/jljusten/edk2/commits/temp-ram-support-v2
> >>
> >> v2:
> >>  * Add AARCH64 and ARM assembly
> >
> > Hi Jordan,
> >
> > I'm not sure I'm following the reasoning behind this. Does this fix an
> > issue we currently have on ARM systems?
>
> IIUC, the PEI Core can only be updated to use the "safe path" (= the
> assembly path) on IA32/X64 if that path (= the assembly path) *exists*
> regardless of architecture.
>
> This is anyway my understanding of the last commit message in the series.
>
> I can't evaluate whether the problem statement, in the first commit
> message in the series, would ever turn into an actual issue on
> ARM/AARCH64, dependent on toolchain. On IA32/X64, we've seen examples
> (although none of those have bit me personally), and AIUI the issue
> could theoretically apply to all arches (again, dependent on toolchain).
>
> (Apologies if I've only increased the confusion with this -- but at
> least it could help me improve my own understanding.)
>
> > And how did you build and/or test OVMF for ARM?
>
> Hmmm, I'm unsure where this question / implication comes from. AIUI, the
> new ARM/AARCH64 assembly is automatically put to use if you run the PEI
> Core -- as part of a firmware platform that uses temp RAM migration --
> on ARM/AARCH64.
>

OK, seems like I'm the one creating confusion here. These are
MdeModulePkg patches not OvmfPkg patches, and I noticed some other
patches by Jordan adding ARM/AARCH64 build support to OVMF.

I will put the assembly patches on my to-review list, but it may take
me a couple of days to get to them.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38832): https://edk2.groups.io/g/devel/message/38832
Mute This Topic: https://groups.io/mt/31016921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 0/6] Fix PEI Core issue during TemporaryRamMigration

2019-04-10 Thread Laszlo Ersek
On 04/10/19 18:41, Ard Biesheuvel wrote:
> On Wed, 10 Apr 2019 at 01:41, Jordan Justen  wrote:
>>
>> https://github.com/jljusten/edk2.git temp-ram-support-v2
>>
>> https://github.com/jljusten/edk2/commits/temp-ram-support-v2
>>
>> v2:
>>  * Add AARCH64 and ARM assembly
> 
> Hi Jordan,
> 
> I'm not sure I'm following the reasoning behind this. Does this fix an
> issue we currently have on ARM systems?

IIUC, the PEI Core can only be updated to use the "safe path" (= the
assembly path) on IA32/X64 if that path (= the assembly path) *exists*
regardless of architecture.

This is anyway my understanding of the last commit message in the series.

I can't evaluate whether the problem statement, in the first commit
message in the series, would ever turn into an actual issue on
ARM/AARCH64, dependent on toolchain. On IA32/X64, we've seen examples
(although none of those have bit me personally), and AIUI the issue
could theoretically apply to all arches (again, dependent on toolchain).

(Apologies if I've only increased the confusion with this -- but at
least it could help me improve my own understanding.)

> And how did you build and/or test OVMF for ARM?

Hmmm, I'm unsure where this question / implication comes from. AIUI, the
new ARM/AARCH64 assembly is automatically put to use if you run the PEI
Core -- as part of a firmware platform that uses temp RAM migration --
on ARM/AARCH64.

Thanks,
Laszlo

> 
> 
>>  * Drop IA32 and X64 .S source files
>>  * Adjust PEI_CORE_TEMPORARY_RAM_TRANSITION pointer in the assembly
>>code based on the stack pointer change before & after
>>TemporaryRamSupport->TemporaryRamMigration
>>  * Drop extra cleanup patches for OvmfPkg & EmulatorPkg. These were
>>just complicating the series.
>>
>> This series fixes an issue that, while rare, is possible based on the
>> way the TemporaryRamSupport PPI is defined along with how it is used
>> by the PEI Core.
>>
>> Liu Yu reported a boot issue with EmulatorPkg, which I believe was
>> caused by this issue.
>>
>> The details of the issue are described in the commit message of the
>> "MdeModulePkg/Core/Pei: Add interface for assembly based
>> TemporaryRamSupport" patch.
>>
>> Testing:
>>
>> I tested building and booting in several scenarios:
>>
>> * OVMF IA32 & X64 on Linux
>> * ArmVirtPkg AARCH64 & ARM on x86_64 Linux
>> * EmulatorPkg IA32 & X64 on Linux
>>
>> Untested:
>>
>> * My system does not reproduce the issue that Liu Yu reported with
>>   EmulatorPkg, so I can't say that I have verified that issue.
>> * Building on windows
>> * AARCH64/ARM TemporaryRamMigration.asm sources
>>
>> Cc: Liu Yu 
>> Cc: Ray Ni 
>> Cc: Andrew Fish 
>> Cc: Laszlo Ersek 
>> Cc: Leif Lindholm 
>> Cc: Michael D Kinney 
>>
>> Jordan Justen (6):
>>   MdeModulePkg/Core/Pei: Add interface for assembly based
>> TemporaryRamSupport
>>   MdeModulePkg/Core/Pei: Add AARCH64 assembly for TemporaryRamMigration
>>   MdeModulePkg/Core/Pei: Add ARM assembly for TemporaryRamMigration
>>   MdeModulePkg/Core/Pei: Add IA32 assembly for TemporaryRamMigration
>>   MdeModulePkg/Core/Pei: Add X64 assembly for TemporaryRamMigration
>>   MdeModulePkg/Core/Pei: Use code path for assembly based
>> TemporaryRamSupport
>>
>>  .../AArch64/TemporaryRamMigration.S   | 63 +++
>>  .../AArch64/TemporaryRamMigration.asm | 63 +++
>>  .../Dispatcher/Arm/TemporaryRamMigration.S| 68 
>>  .../Dispatcher/Arm/TemporaryRamMigration.asm  | 68 
>>  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 +-
>>  .../Ia32/TemporaryRamMigration.nasm   | 77 +++
>>  .../Dispatcher/X64/TemporaryRamMigration.nasm | 74 ++
>>  MdeModulePkg/Core/Pei/PeiMain.h   | 52 +
>>  MdeModulePkg/Core/Pei/PeiMain.inf | 15 
>>  9 files changed, 518 insertions(+), 21 deletions(-)
>>  create mode 100644 
>> MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S
>>  create mode 100644 
>> MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm
>>  create mode 100644 
>> MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S
>>  create mode 100644 
>> MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm
>>  create mode 100644 
>> MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm
>>  create mode 100644 
>> MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm
>>
>> --
>> 2.20.1
>>
>>
>> 
>>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38831): https://edk2.groups.io/g/devel/message/38831
Mute This Topic: https://groups.io/mt/31016921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH edk2-platforms] Platform/DeveloperBox: actually enable secure boot checking

2019-04-10 Thread Ard Biesheuvel
The current secure boot enabled DeveloperBox build contains all the
pieces to maintain the authenticated variable store, but doesn't
actually bother to check the signature on anything it boots. Fix that.

Signed-off-by: Ard Biesheuvel 
---
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 39077ab5ee79..4ddb0d427f13 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -245,7 +245,12 @@
   }
   MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
-  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
+  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
+
+!if $(SECURE_BOOT_ENABLE) == TRUE
+  
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
+!endif
+  }
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38830): https://edk2.groups.io/g/devel/message/38830
Mute This Topic: https://groups.io/mt/31021919/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Building EDK2 code on arm64 (aarch64) - BaseTools fails

2019-04-10 Thread Laszlo Ersek
On 04/10/19 06:57, Rebecca Cran via Groups.Io wrote:
> Is there any expectation that EDK2 will build on non-x86 systems?

Yes. It should certainly build on aarch64 (Linux at least).

> 
> I tried building BaseTools (from git master,
> ae2fb9ead47b5abaf2a4e815b5f57c8f4838b221) using GCC 8.2 on a SoftIron
> OverDrive 1000 (running FreeBSD) but there are lots of errors, such as:

The issue here must be "FreeBSD". That's not supported as a build host
OS, to my knowledge.

I assume the build platform check in the BaseTools makefiles / scripts
fail due to FreeBSD.

edk2 platforms are otherwise regularly built on aarch64 Linux.

Thanks
Laszlo

> 
> 
> gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I
> ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/Arm/ 
> -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
> -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict
> -Wno-unused-result -nostdlib -g -O2  BasePeCoff.c -o BasePeCoff.o
> BasePeCoff.c: In function 'PeCoffLoaderGetPeHeader':
> BasePeCoff.c:120:49: error: cast from pointer to integer of different
> size [-Werror=pointer-to-int-cast]
>    *PeHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)
> ((UINTN)ImageContext->Handle + ImageContext->PeCoffHeaderOffset);
>  ^
> BasePeCoff.c:120:12: error: cast to pointer from integer of different
> size [-Werror=int-to-pointer-cast]
>    *PeHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)
> ((UINTN)ImageContext->Handle + ImageContext->PeCoffHeaderOffset);
>     ^
> BasePeCoff.c: In function 'PeCoffLoaderImageAddress':
> BasePeCoff.c:551:10: error: cast to pointer from integer of different
> size [-Werror=int-to-pointer-cast]
>    return (UINT8 *) ((UINTN) ImageContext->ImageAddress + Address);
>   ^
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38829): https://edk2.groups.io/g/devel/message/38829
Mute This Topic: https://groups.io/mt/31015935/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 0/6] Fix PEI Core issue during TemporaryRamMigration

2019-04-10 Thread Laszlo Ersek
On 04/10/19 10:39, Jordan Justen wrote:
> https://github.com/jljusten/edk2.git temp-ram-support-v2
> 
> https://github.com/jljusten/edk2/commits/temp-ram-support-v2
> 
> v2:
>  * Add AARCH64 and ARM assembly
>  * Drop IA32 and X64 .S source files
>  * Adjust PEI_CORE_TEMPORARY_RAM_TRANSITION pointer in the assembly
>code based on the stack pointer change before & after
>TemporaryRamSupport->TemporaryRamMigration
>  * Drop extra cleanup patches for OvmfPkg & EmulatorPkg. These were
>just complicating the series.
> 
> This series fixes an issue that, while rare, is possible based on the
> way the TemporaryRamSupport PPI is defined along with how it is used
> by the PEI Core.
> 
> Liu Yu reported a boot issue with EmulatorPkg, which I believe was
> caused by this issue.
> 
> The details of the issue are described in the commit message of the
> "MdeModulePkg/Core/Pei: Add interface for assembly based
> TemporaryRamSupport" patch.
> 
> Testing:
> 
> I tested building and booting in several scenarios:
> 
> * OVMF IA32 & X64 on Linux

Performed my usual Linux checks on these, as described in
.

For building, I used the GCC48 toolchain.

> * ArmVirtPkg AARCH64 & ARM on x86_64 Linux

Performed a normal boot test, on AARCH64 KVM.

For building, I used the GCC5 toolchain (using an oldie 6.1.1
cross-compiler from x86_64).

For the series,

Regression-tested-by: Laszlo Ersek 


If a nontrivial update is needed for the series, I don't mind retesting,
but only as the last action before pushing. Testing is time consuming
and now I'm asking myself if I should have waited for some feedback to
arrive first. :)

Thanks
Laszlo

> * EmulatorPkg IA32 & X64 on Linux
> 
> Untested:
> 
> * My system does not reproduce the issue that Liu Yu reported with
>   EmulatorPkg, so I can't say that I have verified that issue.
> * Building on windows
> * AARCH64/ARM TemporaryRamMigration.asm sources
> 
> Cc: Liu Yu 
> Cc: Ray Ni 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> 
> Jordan Justen (6):
>   MdeModulePkg/Core/Pei: Add interface for assembly based
> TemporaryRamSupport
>   MdeModulePkg/Core/Pei: Add AARCH64 assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Add ARM assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Add IA32 assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Add X64 assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Use code path for assembly based
> TemporaryRamSupport
> 
>  .../AArch64/TemporaryRamMigration.S   | 63 +++
>  .../AArch64/TemporaryRamMigration.asm | 63 +++
>  .../Dispatcher/Arm/TemporaryRamMigration.S| 68 
>  .../Dispatcher/Arm/TemporaryRamMigration.asm  | 68 
>  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 +-
>  .../Ia32/TemporaryRamMigration.nasm   | 77 +++
>  .../Dispatcher/X64/TemporaryRamMigration.nasm | 74 ++
>  MdeModulePkg/Core/Pei/PeiMain.h   | 52 +
>  MdeModulePkg/Core/Pei/PeiMain.inf | 15 
>  9 files changed, 518 insertions(+), 21 deletions(-)
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38828): https://edk2.groups.io/g/devel/message/38828
Mute This Topic: https://groups.io/mt/31016921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms/devel-MinPlatform] [patch 0/3] Update to use shell source directly

2019-04-10 Thread Kubacki, Michael A
Reviewed-by: Michael Kubacki 

> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, April 9, 2019 10:33 PM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Sinha, Ankit
> ; Desimone, Nathaniel L
> ; Chiu, Chasel ;
> Lu, Shifei A ; Zhou, Bowen
> ; Oram, Isaac W 
> Subject: [edk2-platforms/devel-MinPlatform] [patch 0/3] Update to use shell
> source directly
> 
> The series will update ClevoOpenBoardPkg KabylakeOpenBoardPkg and
> PurleyOpenBoardPkg to use ShellPkg directly.
> 
> Test done for the series:
> Build pass for ClevoOpenBoardPkg KabylakeOpenBoardPkg and
> PurleyOpenBoardPkg.
> Boot to shell with KBLRvp3.
> 
> Cc: Michael Kubacki 
> Cc: Ankit Sinha 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Cc: Shifei A Lu 
> Cc: Xiaohu Zhou 
> Cc: Isaac W Oram 
> 
> Dandan Bi (3):
>   ClevoOpenBoardPkg/N1xxWU: Use shell source directly
>   KabylakeOpenBoardPkg/KBLRvp3: Use shell source directly
>   PurleyOpenBoardPkg/BoardMtOlympus: Use shell source directly
> 
>  .../ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.dsc | 22
> ++-  .../ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf
> |  2 +-
>  .../KabylakeRvp3/OpenBoardPkg.dsc | 22 ++-
>  .../KabylakeRvp3/OpenBoardPkg.fdf |  2 +-
>  .../BoardMtOlympus/PlatformPkg.dsc| 22 ++-
>  .../BoardMtOlympus/PlatformPkg.fdf|  2 +-
>  6 files changed, 66 insertions(+), 6 deletions(-)
> 
> --
> 2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38827): https://edk2.groups.io/g/devel/message/38827
Mute This Topic: https://groups.io/mt/31016077/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 0/6] Fix PEI Core issue during TemporaryRamMigration

2019-04-10 Thread Ard Biesheuvel
On Wed, 10 Apr 2019 at 01:41, Jordan Justen  wrote:
>
> https://github.com/jljusten/edk2.git temp-ram-support-v2
>
> https://github.com/jljusten/edk2/commits/temp-ram-support-v2
>
> v2:
>  * Add AARCH64 and ARM assembly

Hi Jordan,

I'm not sure I'm following the reasoning behind this. Does this fix an
issue we currently have on ARM systems? And how did you build and/or
test OVMF for ARM?


>  * Drop IA32 and X64 .S source files
>  * Adjust PEI_CORE_TEMPORARY_RAM_TRANSITION pointer in the assembly
>code based on the stack pointer change before & after
>TemporaryRamSupport->TemporaryRamMigration
>  * Drop extra cleanup patches for OvmfPkg & EmulatorPkg. These were
>just complicating the series.
>
> This series fixes an issue that, while rare, is possible based on the
> way the TemporaryRamSupport PPI is defined along with how it is used
> by the PEI Core.
>
> Liu Yu reported a boot issue with EmulatorPkg, which I believe was
> caused by this issue.
>
> The details of the issue are described in the commit message of the
> "MdeModulePkg/Core/Pei: Add interface for assembly based
> TemporaryRamSupport" patch.
>
> Testing:
>
> I tested building and booting in several scenarios:
>
> * OVMF IA32 & X64 on Linux
> * ArmVirtPkg AARCH64 & ARM on x86_64 Linux
> * EmulatorPkg IA32 & X64 on Linux
>
> Untested:
>
> * My system does not reproduce the issue that Liu Yu reported with
>   EmulatorPkg, so I can't say that I have verified that issue.
> * Building on windows
> * AARCH64/ARM TemporaryRamMigration.asm sources
>
> Cc: Liu Yu 
> Cc: Ray Ni 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
>
> Jordan Justen (6):
>   MdeModulePkg/Core/Pei: Add interface for assembly based
> TemporaryRamSupport
>   MdeModulePkg/Core/Pei: Add AARCH64 assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Add ARM assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Add IA32 assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Add X64 assembly for TemporaryRamMigration
>   MdeModulePkg/Core/Pei: Use code path for assembly based
> TemporaryRamSupport
>
>  .../AArch64/TemporaryRamMigration.S   | 63 +++
>  .../AArch64/TemporaryRamMigration.asm | 63 +++
>  .../Dispatcher/Arm/TemporaryRamMigration.S| 68 
>  .../Dispatcher/Arm/TemporaryRamMigration.asm  | 68 
>  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 +-
>  .../Ia32/TemporaryRamMigration.nasm   | 77 +++
>  .../Dispatcher/X64/TemporaryRamMigration.nasm | 74 ++
>  MdeModulePkg/Core/Pei/PeiMain.h   | 52 +
>  MdeModulePkg/Core/Pei/PeiMain.inf | 15 
>  9 files changed, 518 insertions(+), 21 deletions(-)
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm
>  create mode 100644 
> MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm
>
> --
> 2.20.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38826): https://edk2.groups.io/g/devel/message/38826
Mute This Topic: https://groups.io/mt/31016921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 0/8] Duplicate 8259/8254 components in OvmfPkg

2019-04-10 Thread Laszlo Ersek
On 04/10/19 03:06, Hao Wu wrote:
> This series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_8259_8254_v2
> 
> 
> V2 changes:
> 
> Due to the file license change, rebase the whole series onto the tip of
> the master branch. The 'Contributed-under' tag is removed from the log
> messages as well.
> 
> The V2 series keeps all the 'Reviewed-by' tags from Laszlo from the
> previous version of the series.

I skimmed this version briefly, with an eye towards my v1 requests. The
v2 series looks fine to me, ready for pushing.

Thanks!
Laszlo

> 
> 
> V1 history:
> 
> As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
> 
> 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> Legacy8259 protocol (IntelFrameworkPkg)
> 8254TimerDxe driver (PcAtChipsetPkg)
> 
> will be removed in the near future. Meanwhile, OVMF will still require
> those components (due to CSM support & HPET emulation stability concern).
> 
> Thus, the series will copy the below 8259/8254 components:
> 
> A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> B. Two 8259 related PCDs (PcAtChipsetPkg)
> C. Legacy8259 protocol (IntelFrameworkPkg)
> D. 8254TimerDxe driver (PcAtChipsetPkg)
> 
> in the OvmfPkg to address the above-mentioned issue.
> 
> 
> Tests done for the proposed series:
> 
> A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
> B. Boot to Shell with commands:
>   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
> -global isa-debugcon.iobase=0x402
>   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
> file:boot.log -global isa-debugcon.iobase=0x402
> C. 'stall X' command under Shell to verify the timer is working properly.
> 
> 
> (Please note that there will be a subsequent patch to remove the 8259/8254
> components after platforms dropping the dependencies on them.)
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> 
> 
> Hao Wu (8):
>   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
>   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
>   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
>   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
>   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
>   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
>   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
>   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg
> 
>  OvmfPkg/OvmfPkg.dec|  29 +-
>  OvmfPkg/OvmfPkgIa32.dsc|   6 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc |   6 +-
>  OvmfPkg/OvmfPkgX64.dsc |   6 +-
>  OvmfPkg/OvmfPkgIa32.fdf|   4 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf |   4 +-
>  OvmfPkg/OvmfPkgX64.fdf |   4 +-
>  OvmfPkg/8254TimerDxe/8254Timer.inf |  42 ++
>  OvmfPkg/8259InterruptControllerDxe/8259.inf|  45 ++
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf|   5 +-
>  OvmfPkg/8254TimerDxe/Timer.h   | 185 ++
>  OvmfPkg/8259InterruptControllerDxe/8259.h  | 218 +++
>  OvmfPkg/Include/Protocol/Legacy8259.h  | 291 +
>  OvmfPkg/8254TimerDxe/Timer.c   | 401 +
>  OvmfPkg/8259InterruptControllerDxe/8259.c  | 622 
> 
>  OvmfPkg/8254TimerDxe/Timer.uni |  16 +
>  OvmfPkg/8254TimerDxe/TimerExtra.uni|  14 +
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni  |  16 +
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  14 +
>  19 files changed, 1909 insertions(+), 19 deletions(-)
>  create mode 100644 OvmfPkg/8254TimerDxe/8254Timer.inf
>  create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.inf
>  create mode 100644 OvmfPkg/8254TimerDxe/Timer.h
>  create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.h
>  create mode 100644 OvmfPkg/Include/Protocol/Legacy8259.h
>  create mode 100644 OvmfPkg/8254TimerDxe/Timer.c
>  create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.c
>  create mode 100644 OvmfPkg/8254TimerDxe/Timer.uni
>  create mode 100644 OvmfPkg/8254TimerDxe/TimerExtra.uni
>  create mode 100644 OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni
>  create mode 100644 OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38824): https://edk2.groups.io/g/devel/message/38824
Mute This Topic: https://groups.io/mt/31014305/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 7/8] OvmfPkg/8254TimerDxe: Update to make it build for OVMF

2019-04-10 Thread Laszlo Ersek
On 04/10/19 03:06, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit will remove the IntelFrameworkPkg DEC file dependency in the
> driver INF file.
> 
> A new GUID has been updated for the INF file.
> 
> Corresponding changes have been made in OVMF DSC files as well in order to
> verify the build.
> 
> Please note that a subsequent commit (final patch of the series) will:
> 
> A) Add OvmfPkg/8254TimerDxe driver in OVMF FDF files;
> B) Remove the consumption of PcAtChipsetPkg/8254TimerDxe driver in OVMF
> DSC/FDF files.
> 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Signed-off-by: Hao Wu 
> Reviewed-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  OvmfPkg/8254TimerDxe/8254Timer.inf | 6 +++---
>  4 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index feb8bc9b92..888909d809 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -668,6 +668,7 @@ [Components]
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 993da3197c..1771c457f4 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -677,6 +677,7 @@ [Components.X64]
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 65aab4f711..dfe5781658 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -675,6 +675,7 @@ [Components]
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/8254TimerDxe/8254Timer.inf 
> b/OvmfPkg/8254TimerDxe/8254Timer.inf
> index 751ed1c02c..8a07c8247e 100644
> --- a/OvmfPkg/8254TimerDxe/8254Timer.inf
> +++ b/OvmfPkg/8254TimerDxe/8254Timer.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  # 8254 timer driver that provides Timer Arch protocol.
>  #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -10,7 +10,7 @@ [Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = Timer
>MODULE_UNI_FILE= Timer.uni
> -  FILE_GUID  = f2765dec-6b41-11d5-8e71-00902707b35e
> +  FILE_GUID  = C190FE35-44AA-41A1-8AEA-4947BC60E09D
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>  
> @@ -18,7 +18,7 @@ [Defines]
>  
>  [Packages]
>MdePkg/MdePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>UefiBootServicesTableLib
> 

Thanks for the commit msg update
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38822): https://edk2.groups.io/g/devel/message/38822
Mute This Topic: https://groups.io/mt/31014312/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 4/8] OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF

2019-04-10 Thread Laszlo Ersek
On 04/10/19 03:06, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> Several updates have been made to the
> OvmfPkg/8259InterruptControllerDxe driver to make it build under OvmfPkg:
> 
> A) Update the driver INF file to consume PCDs defined within OvmfPkg;
> B) Remove the unnecessary dependency on the IntelFrameworkPkg header file
>'FrameworkDxe.h';
> C) Remove the IntelFrameworkPkg & PcAtChipsetPkg DEC files dependency in
>the driver INF file.
> 
> A new GUID has been updated for the INF file.
> 
> Corresponding changes have been made in OVMF DSC files as well in order to
> verify the build.
> 
> Please note that a subsequent commit (final patch of the series) will:
> 
> A) Add OvmfPkg/8259InterruptControllerDxe driver in OVMF FDF files;
> B) Remove the consumption of PcAtChipsetPkg/8259InterruptControllerDxe
>driver in OVMF DSC/FDF files;
> C) Remove the consumption of
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel in OVMF DSC
>files.
> 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Signed-off-by: Hao Wu 
> Reviewed-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc |  2 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
>  OvmfPkg/OvmfPkgX64.dsc  |  2 ++
>  OvmfPkg/8259InterruptControllerDxe/8259.inf | 11 +--
>  OvmfPkg/8259InterruptControllerDxe/8259.h   |  4 +---
>  5 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 2612c6fd89..feb8bc9b92 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -511,6 +511,7 @@ [PcdsFixedAtBuild]
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -663,6 +664,7 @@ [Components]
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 02308c01c5..993da3197c 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -517,6 +517,7 @@ [PcdsFixedAtBuild.X64]
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -672,6 +673,7 @@ [Components.X64]
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 505a46bb0b..65aab4f711 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -516,6 +516,7 @@ [PcdsFixedAtBuild]
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -670,6 +671,7 @@ [Components]
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
> b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> index 530596a36c..7320ff2490 100644
> --- a/OvmfPkg/8259InterruptControllerDxe/8259.inf
> +++ b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  # 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
>  #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -10,7 +10,7 @@ [Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = Legacy8259
>

Re: [edk2-devel] [PATCH v2 3/8] OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file

2019-04-10 Thread Laszlo Ersek
On 04/10/19 03:06, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> According to the DEC file in PcAtChipsetPkg, this commit adds the two
> 8259-driver-related PCDs into the OvmfPkg DEC file.
> 
> Please note that, instead of adding the two PCDs under section:
> [PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]
> 
> as in PcAtChipsetPkg.dec file, they are added in section:
> [PcdsFixedAtBuild]
> 
> in OvmfPkg.dec instead.
> 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Signed-off-by: Hao Wu 
> Reviewed-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkg.dec | 26 
>  1 file changed, 26 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index d59508db56..cc2a4909af 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -122,6 +122,32 @@ [PcdsFixedAtBuild]
>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
>  
> +  ## Pcd8259LegacyModeMask defines the default mask value for platform. This
> +  #  value is determined.
> +  #  1) If platform only support pure UEFI, value should be set to 0x or
> +  # 0xFFFE; Because only clock interrupt is allowed in legacy mode in 
> pure
> +  # UEFI platform.
> +  #  2) If platform install CSM and use thunk module:
> +  # a) If thunk call provided by CSM binary requires some legacy 
> interrupt
> +  #support, the corresponding bit should be opened as 0.
> +  #For example, if keyboard interfaces provided CSM binary use legacy
> +  #keyboard interrupt in 8259 bit 1, then the value should be set to
> +  #0xFFFC.
> +  # b) If all thunk call provied by CSM binary do not require legacy
> +  #interrupt support, value should be set to 0x or 0xFFFE.
> +  #
> +  #  The default value of legacy mode mask could be changed by
> +  #  EFI_LEGACY_8259_PROTOCOL->SetMask(). But it is rarely need change it
> +  #  except some special cases such as when initializing the CSM binary, it
> +  #  should be set to 0x to mask all legacy interrupt. Please restore the
> +  #  original legacy mask value if changing is made for these special case.
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeMask|0x|UINT16|0x3
> +
> +  ## Pcd8259LegacyModeEdgeLevel defines the default edge level for legacy
> +  #  mode's interrrupt controller.
> +  #  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x5
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> 

Thanks for addressing my v1 comments! My R-b stands.

Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38820): https://edk2.groups.io/g/devel/message/38820
Mute This Topic: https://groups.io/mt/31014308/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH 3/5] OvmfPkg/build.sh: Move automatic TARGET_TOOLS detection later

2019-04-10 Thread Philippe Mathieu-Daudé
Hi Jordan,

On 4/10/19 11:34 AM, Jordan Justen wrote:
> If we are building for a non-native ARM, then we may need to select a
> cross-compiler based on the -a paramter.

I am sorry but I am non-native English and I have hard time to
understand your comment.

OVMF targets x86 hardware, which is obviously not ARM. And I'm not aware
of another target architecture.  Are you talking about the host where
you build?

I am trying your series on a Aarch64 host but I fail at passing the
correct cross gcc. I set GCC5_IA32_PREFIX, GCC5_X64_PREFIX and GCC5_BIN
env vars, but the build script still run '"gcc"' instead of my cross one.

A more generic comment regarding your series: how do you use this script?

Thanks,

Phil.

> Signed-off-by: Jordan Justen 
> ---
>  OvmfPkg/build.sh | 99 +---
>  1 file changed, 51 insertions(+), 48 deletions(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index 217abae683..812441b9b1 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -40,58 +40,11 @@ ARCH_X64=no
>  BUILDTARGET=DEBUG
>  BUILD_OPTIONS=
>  PLATFORMFILE=
> +TARGET_TOOLS=
>  THREADNUMBER=1
>  LAST_ARG=
>  RUN_QEMU=no
>  
> -#
> -# Pick a default tool type for a given OS
> -#
> -TARGET_TOOLS=MYTOOLS
> -case `uname` in
> -  CYGWIN*)
> -echo Cygwin not fully supported yet.
> -;;
> -  Darwin*)
> -Major=$(uname -r | cut -f 1 -d '.')
> -# Major is Darwin version, not OS X version.
> -# OS X Yosemite 10.10.2 returns 14.
> -case $Major in
> -  [156789])
> -echo OvmfPkg requires OS X Snow Leopard 10.6 or newer OS
> -exit 1
> -;;
> -  10)
> -TARGET_TOOLS=XCODE32
> -;;
> -  1[12])
> -TARGET_TOOLS=XCLANG
> -;;
> -   *)
> -# Mavericks and future assume XCODE5 (clang + lldb)
> -TARGET_TOOLS=XCODE5
> -;;
> -esac
> -;;
> -  Linux*)
> -gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
> -case $gcc_version in
> -  [1-3].*|4.[0-7].*)
> -echo OvmfPkg requires GCC4.8 or later
> -exit 1
> -;;
> -  4.8.*)
> -TARGET_TOOLS=GCC48
> -;;
> -  4.9.*|6.[0-2].*)
> -TARGET_TOOLS=GCC49
> -;;
> -  *)
> -TARGET_TOOLS=GCC5
> -;;
> -esac
> -esac
> -
>  #
>  # Scan command line to override defaults
>  #
> @@ -166,6 +119,56 @@ else
>BUILD_ROOT_ARCH=X64
>  fi
>  
> +#
> +# Pick a default tool type for a given OS
> +#
> +if [ -z "$TARGET_TOOLS" ]; then
> +  TARGET_TOOLS=MYTOOLS
> +  case `uname` in
> +CYGWIN*)
> +  echo Cygwin not fully supported yet.
> +  ;;
> +Darwin*)
> +  Major=$(uname -r | cut -f 1 -d '.')
> +  # Major is Darwin version, not OS X version.
> +  # OS X Yosemite 10.10.2 returns 14.
> +  case $Major in
> +[156789])
> +  echo OvmfPkg requires OS X Snow Leopard 10.6 or newer OS
> +  exit 1
> +  ;;
> +10)
> +  TARGET_TOOLS=XCODE32
> +  ;;
> +1[12])
> +  TARGET_TOOLS=XCLANG
> +  ;;
> + *)
> +  # Mavericks and future assume XCODE5 (clang + lldb)
> +  TARGET_TOOLS=XCODE5
> +  ;;
> +  esac
> +  ;;
> +Linux*)
> +  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
> +  case $gcc_version in
> +[1-3].*|4.[0-7].*)
> +  echo OvmfPkg requires GCC4.8 or later
> +  exit 1
> +  ;;
> +4.8.*)
> +  TARGET_TOOLS=GCC48
> +  ;;
> +4.9.*|6.[0-2].*)
> +  TARGET_TOOLS=GCC49
> +  ;;
> +*)
> +  TARGET_TOOLS=GCC5
> +  ;;
> +  esac
> +  esac
> +fi
> +
>  case $PROCESSOR in
>IA32)
>  if [ -n "$QEMU_COMMAND" ]; then
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38819): https://edk2.groups.io/g/devel/message/38819
Mute This Topic: https://groups.io/mt/31017201/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH] BaseTools: Hash false success with back to back builds

2019-04-10 Thread Christian Rodriguez
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1692

Add error handling to the --hash feature so that hash files
are invalidated when a build error occurs.

Signed-off-by: Christian Rodriguez 
Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
---
 BaseTools/Source/Python/Common/GlobalData.py |  4 
 BaseTools/Source/Python/build/build.py   | 45 
+
 2 files changed, 49 insertions(+)

diff --git a/BaseTools/Source/Python/Common/GlobalData.py 
b/BaseTools/Source/Python/Common/GlobalData.py
index 1853f1d2f6..79f23c892d 100644
--- a/BaseTools/Source/Python/Common/GlobalData.py
+++ b/BaseTools/Source/Python/Common/GlobalData.py
@@ -108,3 +108,7 @@ gPackageHash = {}
 gModuleHash = {}
 gEnableGenfdsMultiThread = False
 gSikpAutoGenCache = set()
+
+# Dictionary for tracking Module build status as success or failure
+# False -> Fail : True -> Success
+gModuleBuildTracking = dict()
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index af8bba47b1..71478b7268 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -620,6 +620,8 @@ class BuildTask:
 BuildTask._ErrorFlag.set()
 BuildTask._ErrorMessage = "%s broken\n%s [%s]" % \
   (threading.currentThread().getName(), 
Command, WorkingDir)
+if self.BuildItem.BuildObject in GlobalData.gModuleBuildTracking and 
not BuildTask._ErrorFlag.isSet():
+GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] = True
 # indicate there's a thread is available for another build task
 BuildTask._RunningQueueLock.acquire()
 BuildTask._RunningQueue.pop(self.BuildItem)
@@ -1138,6 +1140,37 @@ class Build():
 if Process.returncode != 0 :
 EdkLogger.error("Postbuild", POSTBUILD_ERROR, 'Postbuild 
process is not success!')
 EdkLogger.info("\n- Postbuild Done -\n")
+
+## Error handling for hash feature
+#
+# On BuildTask error, iterate through the Module Build tracking
+# dictionary to determine wheather a module failed to build. Invalidate
+# the hash associated with that module by removing it from storage.
+#
+#
+def invalidateHash(self):
+# GlobalData.gModuleBuildTracking contains only modules that cannot be 
skipped by hash
+for moduleAutoGenObj in GlobalData.gModuleBuildTracking.keys():
+# False == FAIL : True == Success
+# Skip invalidating for Successful module builds
+if GlobalData.gModuleBuildTracking[moduleAutoGenObj] == True:
+continue
+
+# The module failed to build or failed to start building, from 
this point on
+
+# Remove .hash from build
+if GlobalData.gUseHashCache:
+ModuleHashFile = path.join(moduleAutoGenObj.BuildDir, 
moduleAutoGenObj.Name + ".hash")
+if os.path.exists(ModuleHashFile):
+os.remove(ModuleHashFile)
+
+# Remove .hash file from cache
+if GlobalData.gBinCacheSource:
+FileDir = path.join(GlobalData.gBinCacheSource, 
moduleAutoGenObj.Arch, moduleAutoGenObj.SourceDir, 
moduleAutoGenObj.MetaFile.BaseName)
+HashFile = path.join(FileDir, moduleAutoGenObj.Name + '.hash')
+if os.path.exists(HashFile):
+os.remove(HashFile)
+
 ## Build a module or platform
 #
 # Create autogen code and makefile for a module or platform, and the launch
@@ -1795,6 +1828,9 @@ class Build():
 if self.Target == "genmake":
 return True
 self.BuildModules.append(Ma)
+# Initialize all modules in tracking to False 
(FAIL)
+if Ma not in GlobalData.gModuleBuildTracking:
+GlobalData.gModuleBuildTracking[Ma] = False
 self.AutoGenTime += int(round((time.time() - 
AutoGenStart)))
 MakeStart = time.time()
 for Ma in self.BuildModules:
@@ -1805,6 +1841,7 @@ class Build():
 # we need a full version of makefile for platform
 ExitFlag.set()
 BuildTask.WaitForComplete()
+self.invalidateHash()
 Pa.CreateMakeFile(False)
 EdkLogger.error("build", BUILD_ERROR, "Failed to 
build module", ExtraData=GlobalData.gBuildingModule)
 # Start task scheduler
@@ -1814,6 +1851,7 @@ class Build():
 # in case there's an interruption. we need a full version 
of makefile for platform
 Pa.CreateMakeFile(False)
 if BuildTask.HasError():
+

Re: [edk2-devel] Building EDK2 code on arm64 (aarch64) - BaseTools fails

2019-04-10 Thread Rebecca Cran via Groups.Io

On 2019-04-10 08:41, Philippe Mathieu-Daudé wrote:


This doesn't look like an architecture problem. It seems your GCC
version isn't checked correctly by BaseTools. This warning is supposed
to be disabled, see:

StdLib/LibC/Stdio/Stdio.inf:  GCC:*_*_*_CC_FLAGS= -fno-builtin
-Wno-pointer-to-int-cast -Wno-int-to-pointer-cast -Wno-format



Thanks! I shouldn't have posted so late, I didn't look closely enough at 
the error messages before sending my email.



--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38817): https://edk2.groups.io/g/devel/message/38817
Mute This Topic: https://groups.io/mt/31015935/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH 1/5] OvmfPkg/build.sh: Require QEMU 1.6 or newer and always enable flash

2019-04-10 Thread Philippe Mathieu-Daudé
On 4/10/19 11:34 AM, Jordan Justen wrote:
> Signed-off-by: Jordan Justen 
> ---
>  OvmfPkg/build.sh | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index 4fcbdd2bc9..c92e90acfa 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -43,7 +43,6 @@ PLATFORMFILE=
>  THREADNUMBER=1
>  LAST_ARG=
>  RUN_QEMU=no
> -ENABLE_FLASH=no
>  
>  #
>  # Pick a default tool type for a given OS
> @@ -110,7 +109,7 @@ do
>  break
>  ;;
>--enable-flash)
> -ENABLE_FLASH=yes
> +# Ignore old option. We always enable flash.
>  ;;
>*)
>  BUILD_OPTIONS="$BUILD_OPTIONS $arg"
> @@ -210,7 +209,10 @@ if [[ "$RUN_QEMU" == "yes" ]]; then
>   awk '{print $2}')
>case $qemu_version in
>  1.[6-9].*|[2-9].*.*|[1-9][0-9]*.*.*)
> -  ENABLE_FLASH=yes
> +  ;;
> +*)
> +  echo qemu 1.6 or newer is required. detected: $qemu_version
> +  exit 1
>;;
>esac
>  
> @@ -258,15 +260,8 @@ fi
>  
>  
>  if [[ "$RUN_QEMU" == "yes" ]]; then
> -  if [[ ! -d $QEMU_FIRMWARE_DIR ]]; then
> -mkdir $QEMU_FIRMWARE_DIR
> -  fi
> -  ln -sf $FV_DIR/OVMF.fd $QEMU_FIRMWARE_DIR/bios.bin
> -  if [[ "$ENABLE_FLASH" == "yes" ]]; then
> -QEMU_COMMAND="$QEMU_COMMAND -pflash $QEMU_FIRMWARE_DIR/bios.bin"
> -  else
> -QEMU_COMMAND="$QEMU_COMMAND -L $QEMU_FIRMWARE_DIR"
> -  fi
> +  FIRMWARE_IMAGE=$FV_DIR/OVMF.fd
> +  QEMU_COMMAND="$QEMU_COMMAND -pflash $FIRMWARE_IMAGE"
>if [[ "$ADD_QEMU_HDA" == "yes" ]]; then
>  QEMU_COMMAND="$QEMU_COMMAND -hda fat:$BUILD_ROOT_ARCH"
>fi
> 

Reviewed-by: Philippe Mathieu-Daude 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38816): https://edk2.groups.io/g/devel/message/38816
Mute This Topic: https://groups.io/mt/31017199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Building EDK2 code on arm64 (aarch64) - BaseTools fails

2019-04-10 Thread Philippe Mathieu-Daudé
On 4/10/19 6:57 AM, Rebecca Cran via Groups.Io wrote:
> Is there any expectation that EDK2 will build on non-x86 systems?

I have no problem using Ubuntu Bionic on Aarch64 using the default GCC.

$ lsb_release -cd
Description:Ubuntu 18.04.2 LTS
Codename:   bionic

$ uname -ms
Linux aarch64

$ gcc -v
gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)

> I tried building BaseTools (from git master,
> ae2fb9ead47b5abaf2a4e815b5f57c8f4838b221) using GCC 8.2 on a SoftIron
> OverDrive 1000 (running FreeBSD) but there are lots of errors, such as:
> 
> 
> gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I
> ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/Arm/ 
> -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
> -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict
> -Wno-unused-result -nostdlib -g -O2  BasePeCoff.c -o BasePeCoff.o
> BasePeCoff.c: In function 'PeCoffLoaderGetPeHeader':
> BasePeCoff.c:120:49: error: cast from pointer to integer of different
> size [-Werror=pointer-to-int-cast]
>    *PeHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)
> ((UINTN)ImageContext->Handle + ImageContext->PeCoffHeaderOffset);
>  ^
> BasePeCoff.c:120:12: error: cast to pointer from integer of different
> size [-Werror=int-to-pointer-cast]
>    *PeHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)
> ((UINTN)ImageContext->Handle + ImageContext->PeCoffHeaderOffset);
>     ^
> BasePeCoff.c: In function 'PeCoffLoaderImageAddress':
> BasePeCoff.c:551:10: error: cast to pointer from integer of different
> size [-Werror=int-to-pointer-cast]
>    return (UINT8 *) ((UINTN) ImageContext->ImageAddress + Address);
>   ^

This doesn't look like an architecture problem. It seems your GCC
version isn't checked correctly by BaseTools. This warning is supposed
to be disabled, see:

StdLib/LibC/Stdio/Stdio.inf:  GCC:*_*_*_CC_FLAGS= -fno-builtin
-Wno-pointer-to-int-cast -Wno-int-to-pointer-cast -Wno-format

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38815): https://edk2.groups.io/g/devel/message/38815
Mute This Topic: https://groups.io/mt/31015935/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] Where is PLATFORM_SOURCE_DIR var?

2019-04-10 Thread Nikolai SAOUKH
There is PLATFORM_OUTPUT_DIR. And PLATFORM_DIR that points to same place 
as WORKSPACE )-;


In setups where workspace is not in source tree there is no way to get 
sources.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38813): https://edk2.groups.io/g/devel/message/38813
Mute This Topic: https://groups.io/mt/31019360/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH 1/5] OvmfPkg/build.sh: Require QEMU 1.6 or newer and always enable flash

2019-04-10 Thread Laszlo Ersek
Hi Jordan,

I've asked Phil (CC'd) to review this series in my stead. I'll be happy
to provide an ACK when Phil gives his R-b (if I should forget, please
ping me separately).

In the future, please include a cover letter; a cumulative diffstat
usually helps with the review. (I've had to check all patches to see
that only build.sh is being modified.)

Thanks,
Laszlo

On 04/10/19 11:34, Jordan Justen wrote:
> Signed-off-by: Jordan Justen 
> ---
>  OvmfPkg/build.sh | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index 4fcbdd2bc9..c92e90acfa 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -43,7 +43,6 @@ PLATFORMFILE=
>  THREADNUMBER=1
>  LAST_ARG=
>  RUN_QEMU=no
> -ENABLE_FLASH=no
>  
>  #
>  # Pick a default tool type for a given OS
> @@ -110,7 +109,7 @@ do
>  break
>  ;;
>--enable-flash)
> -ENABLE_FLASH=yes
> +# Ignore old option. We always enable flash.
>  ;;
>*)
>  BUILD_OPTIONS="$BUILD_OPTIONS $arg"
> @@ -210,7 +209,10 @@ if [[ "$RUN_QEMU" == "yes" ]]; then
>   awk '{print $2}')
>case $qemu_version in
>  1.[6-9].*|[2-9].*.*|[1-9][0-9]*.*.*)
> -  ENABLE_FLASH=yes
> +  ;;
> +*)
> +  echo qemu 1.6 or newer is required. detected: $qemu_version
> +  exit 1
>;;
>esac
>  
> @@ -258,15 +260,8 @@ fi
>  
>  
>  if [[ "$RUN_QEMU" == "yes" ]]; then
> -  if [[ ! -d $QEMU_FIRMWARE_DIR ]]; then
> -mkdir $QEMU_FIRMWARE_DIR
> -  fi
> -  ln -sf $FV_DIR/OVMF.fd $QEMU_FIRMWARE_DIR/bios.bin
> -  if [[ "$ENABLE_FLASH" == "yes" ]]; then
> -QEMU_COMMAND="$QEMU_COMMAND -pflash $QEMU_FIRMWARE_DIR/bios.bin"
> -  else
> -QEMU_COMMAND="$QEMU_COMMAND -L $QEMU_FIRMWARE_DIR"
> -  fi
> +  FIRMWARE_IMAGE=$FV_DIR/OVMF.fd
> +  QEMU_COMMAND="$QEMU_COMMAND -pflash $FIRMWARE_IMAGE"
>if [[ "$ADD_QEMU_HDA" == "yes" ]]; then
>  QEMU_COMMAND="$QEMU_COMMAND -hda fat:$BUILD_ROOT_ARCH"
>fi
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38812): https://edk2.groups.io/g/devel/message/38812
Mute This Topic: https://groups.io/mt/31017199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms/devel-MinPlatform] [patch 3/3] PurleyOpenBoardPkg/BoardMtOlympus: Use shell source directly

2019-04-10 Thread Zhou, Bowen
Reviewed-by: Xiaohu Zhou 

-Original Message-
From: Bi, Dandan 
Sent: Wednesday, April 10, 2019 1:33 PM
To: devel@edk2.groups.io
Cc: Lu, Shifei A ; Zhou, Bowen ; 
Oram, Isaac W 
Subject: [edk2-platforms/devel-MinPlatform] [patch 3/3] 
PurleyOpenBoardPkg/BoardMtOlympus: Use shell source directly

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

In long term we will remove ShellBinPkg, so now update platform to use ShellPkg 
directly.

Cc: Shifei A Lu 
Cc: Xiaohu Zhou 
Cc: Isaac W Oram 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../BoardMtOlympus/PlatformPkg.dsc| 22 ++-
 .../BoardMtOlympus/PlatformPkg.fdf|  2 +-
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.dsc 
b/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.dsc
index 384e70a832..aa8bde5460 100644
--- a/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.dsc
+++ b/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.dsc
@@ -225,11 +225,31 @@
   AdvancedFeaturePkg/Smbios/SmbiosBasicDxe/SmbiosBasicDxe.inf
 !endif
 
   PurleyOpenBoardPkg/Policy/S3NvramSave/S3NvramSave.inf
 
-  ShellBinPkg/UefiShell/UefiShell.inf
+  #
+  # Shell
+  #
+  ShellPkg/Application/Shell/Shell.inf {
+   
+ gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+   
+ 
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
+ 
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
+ 
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
+ 
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
+ 
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
+ 
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+ 
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
+ 
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
+ 
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
+ 
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+ 
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
+ ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
+ ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  }
 
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
 
   PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
 
diff --git a/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf 
b/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf
index 610aa18d49..0100f88aa3 100644
--- a/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf
+++ b/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf
@@ -297,11 +297,11 @@ INF  $(BOARD_PKG)/Policy/IioUdsDataDxe/IioUdsDataDxe.inf
 INF  $(BOARD_PKG)/Policy/PlatformCpuPolicy/PlatformCpuPolicy.inf
 INF  $(BOARD_PKG)/Pci/PciPlatform/PciPlatform.inf
 
 INF  MinPlatformPkg/PlatformInit/PlatformInitDxe/PlatformInitDxe.inf
 
-INF  ShellBinPkg/UefiShell/UefiShell.inf
+INF  ShellPkg/Application/Shell/Shell.inf
 
 INF  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
 
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
 
--
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38811): https://edk2.groups.io/g/devel/message/38811
Mute This Topic: https://groups.io/mt/31016081/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms/devel-MinPlatform] [patch 2/3] KabylakeOpenBoardPkg/KBLRvp3: Use shell source directly

2019-04-10 Thread Chiu, Chasel


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Dandan Bi
> Sent: Wednesday, April 10, 2019 1:33 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Kubacki, Michael A
> 
> Subject: [edk2-devel] [edk2-platforms/devel-MinPlatform] [patch 2/3]
> KabylakeOpenBoardPkg/KBLRvp3: Use shell source directly
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> 
> In long term we will remove ShellBinPkg, so now update platform to use 
> ShellPkg
> directly.
> 
> Cc: Chasel Chiu 
> Cc: Michael Kubacki 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  .../KabylakeRvp3/OpenBoardPkg.dsc | 22 ++-
>  .../KabylakeRvp3/OpenBoardPkg.fdf |  2 +-
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> index d1fb795f15..8602052666 100644
> --- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> +++
> b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> @@ -261,11 +261,31 @@
>MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
>MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
>MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
> 
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.i
> nf
> 
> -  ShellBinPkg/UefiShell/UefiShell.inf
> +  #
> +  # Shell
> +  #
> +  ShellPkg/Application/Shell/Shell.inf {
> +   
> + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> +   
> +
> NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Comman
> dsLib.inf
> +
> NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1Comman
> dsLib.inf
> +
> NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3Comman
> dsLib.inf
> +
> NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1Comm
> andsLib.inf
> +
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Comma
> ndsLib.inf
> +
> NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comm
> andsLib.inf
> +
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1C
> ommandsLib.inf
> +
> NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2C
> ommandsLib.inf
> +
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommand
> Lib.inf
> +
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLi
> b.inf
> +
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCo
> mmandLib.inf
> +
> ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
> + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  }
> 
>  #
>  # Silicon
>  #
>  !include $(PLATFORM_SI_PACKAGE)/SiPkgDxe.dsc
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
> b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
> index dc2a5d7e12..8e8abab0dc 100644
> --- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
> +++
> b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
> @@ -333,11 +333,11 @@ INF
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
>  INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
>  INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
>  INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
>  INF
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.i
> nf
> 
> -INF  ShellBinPkg/UefiShell/UefiShell.inf
> +INF  ShellPkg/Application/Shell/Shell.inf
> 
>  INF
> $(PLATFORM_PACKAGE)/PlatformInit/PlatformInitDxe/PlatformInitDxe.inf
>  INF  IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> 
>  INF  $(PLATFORM_PACKAGE)/Test/TestPointStubDxe/TestPointStubDxe.inf
> --
> 2.18.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38805): https://edk2.groups.io/g/devel/message/38805
Mute This Topic: https://groups.io/mt/31016080/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 2/5] OvmfPkg/build.sh: Don't automatically -hda qemu parameter

2019-04-10 Thread Jordan Justen
This hasn't worked for me in quite some time. I always add a -cdrom
paramter, which causes build.sh to skip this.

Signed-off-by: Jordan Justen 
---
 OvmfPkg/build.sh | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index c92e90acfa..217abae683 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -262,9 +262,6 @@ fi
 if [[ "$RUN_QEMU" == "yes" ]]; then
   FIRMWARE_IMAGE=$FV_DIR/OVMF.fd
   QEMU_COMMAND="$QEMU_COMMAND -pflash $FIRMWARE_IMAGE"
-  if [[ "$ADD_QEMU_HDA" == "yes" ]]; then
-QEMU_COMMAND="$QEMU_COMMAND -hda fat:$BUILD_ROOT_ARCH"
-  fi
   echo Running: $QEMU_COMMAND "$@"
   $QEMU_COMMAND "$@"
   exit $?
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38798): https://edk2.groups.io/g/devel/message/38798
Mute This Topic: https://groups.io/mt/31017200/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 4/5] OvmfPkg/build.sh: Add AARCH64/ARM build and qemu support

2019-04-10 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 OvmfPkg/build.sh | 72 
 1 file changed, 60 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index 812441b9b1..9d787452b5 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -35,6 +35,8 @@ fi
 # Configure defaults for various options
 #
 
+ARCH_AARCH64=no
+ARCH_ARM=no
 ARCH_IA32=no
 ARCH_X64=no
 BUILDTARGET=DEBUG
@@ -71,12 +73,14 @@ do
   else
 case $LAST_ARG in
   -a)
-if [[ x"$arg" != x"IA32" && x"$arg" != x"X64" ]]; then
-  echo Unsupported processor architecture: $arg
-  echo Only IA32 or X64 is supported
-  exit 1
-fi
-eval ARCH_$arg=yes
+case $arg in
+  AARCH64|ARM|IA32|X64)
+eval ARCH_$arg=yes
+;;
+  *)
+echo Unsupported processor architecture: $arg
+exit 1
+   esac
 ;;
   -b)
 BUILDTARGET=$arg
@@ -99,7 +103,22 @@ do
   shift
 done
 
-if [[ "$ARCH_IA32" == "yes" && "$ARCH_X64" == "yes" ]]; then
+export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
+export GCC5_ARM_PREFIX=arm-linux-gnueabihf-
+
+if [[ "$ARCH_AARCH64" == "yes" ]]; then
+  PROCESSOR=AARCH64
+  Processor=AArch64
+  BUILD_OPTIONS="$BUILD_OPTIONS -a $PROCESSOR"
+  PLATFORM_BUILD_DIR=ArmVirtQemu-$PROCESSOR
+  BUILD_ROOT_ARCH=$PROCESSOR
+elif [[ "$ARCH_ARM" == "yes" ]]; then
+  PROCESSOR=ARM
+  Processor=Arm
+  BUILD_OPTIONS="$BUILD_OPTIONS -a $PROCESSOR"
+  PLATFORM_BUILD_DIR=ArmVirtQemu-$PROCESSOR
+  BUILD_ROOT_ARCH=$PROCESSOR
+elif [[ "$ARCH_IA32" == "yes" && "$ARCH_X64" == "yes" ]]; then
   PROCESSOR=IA32X64
   Processor=Ia32X64
   BUILD_OPTIONS="$BUILD_OPTIONS -a IA32 -a X64"
@@ -170,6 +189,22 @@ if [ -z "$TARGET_TOOLS" ]; then
 fi
 
 case $PROCESSOR in
+  AARCH64)
+if [ -z "$QEMU_COMMAND" ]; then
+  #
+  # The user didn't set the QEMU_COMMAND variable.
+  #
+  QEMU_COMMAND=qemu-system-aarch64
+fi
+;;
+  ARM)
+if [ -z "$QEMU_COMMAND" ]; then
+  #
+  # The user didn't set the QEMU_COMMAND variable.
+  #
+  QEMU_COMMAND=qemu-system-aarch64
+fi
+;;
   IA32)
 if [ -n "$QEMU_COMMAND" ]; then
   #
@@ -203,7 +238,14 @@ case $PROCESSOR in
 esac
 
 if [ -z "$PLATFORMFILE" ]; then
-  PLATFORMFILE=$WORKSPACE/OvmfPkg/OvmfPkg$Processor.dsc
+  case $PROCESSOR in
+AARCH64|ARM)
+  PLATFORMFILE=$WORKSPACE/ArmVirtPkg/ArmVirtQemu.dsc
+  ;;
+*)
+  PLATFORMFILE=$WORKSPACE/OvmfPkg/OvmfPkg$Processor.dsc
+  ;;
+  esac
 fi
 
 if [[ "$RUN_QEMU" == "yes" ]]; then
@@ -263,8 +305,15 @@ fi
 
 
 if [[ "$RUN_QEMU" == "yes" ]]; then
-  FIRMWARE_IMAGE=$FV_DIR/OVMF.fd
-  QEMU_COMMAND="$QEMU_COMMAND -pflash $FIRMWARE_IMAGE"
+  case $PROCESSOR in
+AARCH64|ARM)
+  FIRMWARE_IMAGE="-bios $FV_DIR/QEMU_EFI.fd"
+  ;;
+*)
+  FIRMWARE_IMAGE="-pflash $FV_DIR/OVMF.fd"
+  ;;
+  esac
+  QEMU_COMMAND="$QEMU_COMMAND $FIRMWARE_IMAGE"
   echo Running: $QEMU_COMMAND "$@"
   $QEMU_COMMAND "$@"
   exit $?
@@ -273,7 +322,6 @@ fi
 #
 # Build the edk2 OvmfPkg
 #
-echo Running edk2 build for OvmfPkg$Processor
+echo Running edk2 build for $PROCESSOR $PLATFORMFILE
 build -p $PLATFORMFILE $BUILD_OPTIONS -b $BUILDTARGET -t $TARGET_TOOLS -n 
$THREADNUMBER
 exit $?
-
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38800): https://edk2.groups.io/g/devel/message/38800
Mute This Topic: https://groups.io/mt/31017202/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 1/5] OvmfPkg/build.sh: Require QEMU 1.6 or newer and always enable flash

2019-04-10 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 OvmfPkg/build.sh | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index 4fcbdd2bc9..c92e90acfa 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -43,7 +43,6 @@ PLATFORMFILE=
 THREADNUMBER=1
 LAST_ARG=
 RUN_QEMU=no
-ENABLE_FLASH=no
 
 #
 # Pick a default tool type for a given OS
@@ -110,7 +109,7 @@ do
 break
 ;;
   --enable-flash)
-ENABLE_FLASH=yes
+# Ignore old option. We always enable flash.
 ;;
   *)
 BUILD_OPTIONS="$BUILD_OPTIONS $arg"
@@ -210,7 +209,10 @@ if [[ "$RUN_QEMU" == "yes" ]]; then
  awk '{print $2}')
   case $qemu_version in
 1.[6-9].*|[2-9].*.*|[1-9][0-9]*.*.*)
-  ENABLE_FLASH=yes
+  ;;
+*)
+  echo qemu 1.6 or newer is required. detected: $qemu_version
+  exit 1
   ;;
   esac
 
@@ -258,15 +260,8 @@ fi
 
 
 if [[ "$RUN_QEMU" == "yes" ]]; then
-  if [[ ! -d $QEMU_FIRMWARE_DIR ]]; then
-mkdir $QEMU_FIRMWARE_DIR
-  fi
-  ln -sf $FV_DIR/OVMF.fd $QEMU_FIRMWARE_DIR/bios.bin
-  if [[ "$ENABLE_FLASH" == "yes" ]]; then
-QEMU_COMMAND="$QEMU_COMMAND -pflash $QEMU_FIRMWARE_DIR/bios.bin"
-  else
-QEMU_COMMAND="$QEMU_COMMAND -L $QEMU_FIRMWARE_DIR"
-  fi
+  FIRMWARE_IMAGE=$FV_DIR/OVMF.fd
+  QEMU_COMMAND="$QEMU_COMMAND -pflash $FIRMWARE_IMAGE"
   if [[ "$ADD_QEMU_HDA" == "yes" ]]; then
 QEMU_COMMAND="$QEMU_COMMAND -hda fat:$BUILD_ROOT_ARCH"
   fi
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38797): https://edk2.groups.io/g/devel/message/38797
Mute This Topic: https://groups.io/mt/31017199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 3/5] OvmfPkg/build.sh: Move automatic TARGET_TOOLS detection later

2019-04-10 Thread Jordan Justen
If we are building for a non-native ARM, then we may need to select a
cross-compiler based on the -a paramter.

Signed-off-by: Jordan Justen 
---
 OvmfPkg/build.sh | 99 +---
 1 file changed, 51 insertions(+), 48 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index 217abae683..812441b9b1 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -40,58 +40,11 @@ ARCH_X64=no
 BUILDTARGET=DEBUG
 BUILD_OPTIONS=
 PLATFORMFILE=
+TARGET_TOOLS=
 THREADNUMBER=1
 LAST_ARG=
 RUN_QEMU=no
 
-#
-# Pick a default tool type for a given OS
-#
-TARGET_TOOLS=MYTOOLS
-case `uname` in
-  CYGWIN*)
-echo Cygwin not fully supported yet.
-;;
-  Darwin*)
-Major=$(uname -r | cut -f 1 -d '.')
-# Major is Darwin version, not OS X version.
-# OS X Yosemite 10.10.2 returns 14.
-case $Major in
-  [156789])
-echo OvmfPkg requires OS X Snow Leopard 10.6 or newer OS
-exit 1
-;;
-  10)
-TARGET_TOOLS=XCODE32
-;;
-  1[12])
-TARGET_TOOLS=XCLANG
-;;
-   *)
-# Mavericks and future assume XCODE5 (clang + lldb)
-TARGET_TOOLS=XCODE5
-;;
-esac
-;;
-  Linux*)
-gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
-case $gcc_version in
-  [1-3].*|4.[0-7].*)
-echo OvmfPkg requires GCC4.8 or later
-exit 1
-;;
-  4.8.*)
-TARGET_TOOLS=GCC48
-;;
-  4.9.*|6.[0-2].*)
-TARGET_TOOLS=GCC49
-;;
-  *)
-TARGET_TOOLS=GCC5
-;;
-esac
-esac
-
 #
 # Scan command line to override defaults
 #
@@ -166,6 +119,56 @@ else
   BUILD_ROOT_ARCH=X64
 fi
 
+#
+# Pick a default tool type for a given OS
+#
+if [ -z "$TARGET_TOOLS" ]; then
+  TARGET_TOOLS=MYTOOLS
+  case `uname` in
+CYGWIN*)
+  echo Cygwin not fully supported yet.
+  ;;
+Darwin*)
+  Major=$(uname -r | cut -f 1 -d '.')
+  # Major is Darwin version, not OS X version.
+  # OS X Yosemite 10.10.2 returns 14.
+  case $Major in
+[156789])
+  echo OvmfPkg requires OS X Snow Leopard 10.6 or newer OS
+  exit 1
+  ;;
+10)
+  TARGET_TOOLS=XCODE32
+  ;;
+1[12])
+  TARGET_TOOLS=XCLANG
+  ;;
+ *)
+  # Mavericks and future assume XCODE5 (clang + lldb)
+  TARGET_TOOLS=XCODE5
+  ;;
+  esac
+  ;;
+Linux*)
+  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
+  case $gcc_version in
+[1-3].*|4.[0-7].*)
+  echo OvmfPkg requires GCC4.8 or later
+  exit 1
+  ;;
+4.8.*)
+  TARGET_TOOLS=GCC48
+  ;;
+4.9.*|6.[0-2].*)
+  TARGET_TOOLS=GCC49
+  ;;
+*)
+  TARGET_TOOLS=GCC5
+  ;;
+  esac
+  esac
+fi
+
 case $PROCESSOR in
   IA32)
 if [ -n "$QEMU_COMMAND" ]; then
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38799): https://edk2.groups.io/g/devel/message/38799
Mute This Topic: https://groups.io/mt/31017201/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 5/5] OvmfPkg/build.sh: Add a cross compiler prefix for AARCH64/ARM

2019-04-10 Thread Jordan Justen
Signed-off-by: Jordan Justen 
---
 OvmfPkg/build.sh | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index 9d787452b5..e1a708942b 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -103,9 +103,6 @@ do
   shift
 done
 
-export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
-export GCC5_ARM_PREFIX=arm-linux-gnueabihf-
-
 if [[ "$ARCH_AARCH64" == "yes" ]]; then
   PROCESSOR=AARCH64
   Processor=AArch64
@@ -138,6 +135,23 @@ else
   BUILD_ROOT_ARCH=X64
 fi
 
+GCC_CROSS_PREFIX=
+gcc_machine=$(gcc -dumpmachine 2>&1 | awk -F - '{print $1}')
+case $gcc_machine in
+  x86_64)
+case $BUILD_ROOT_ARCH in
+  AARCH64)
+   GCC_CROSS_PREFIX=aarch64-linux-gnu-
+;;
+  ARM)
+   GCC_CROSS_PREFIX=arm-linux-gnueabihf-
+;;
+esac
+;;
+esac
+
+GCC=${GCC_CROSS_PREFIX}gcc
+
 #
 # Pick a default tool type for a given OS
 #
@@ -169,7 +183,7 @@ if [ -z "$TARGET_TOOLS" ]; then
   esac
   ;;
 Linux*)
-  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
+  gcc_version=$($GCC -v 2>&1 | tail -1 | awk '{print $3}')
   case $gcc_version in
 [1-3].*|4.[0-7].*)
   echo OvmfPkg requires GCC4.8 or later
@@ -188,6 +202,10 @@ if [ -z "$TARGET_TOOLS" ]; then
   esac
 fi
 
+if [ -n "${GCC_CROSS_PREFIX}" ]; then
+  export ${TARGET_TOOLS}_${BUILD_ROOT_ARCH}_PREFIX=${GCC_CROSS_PREFIX}
+fi
+
 case $PROCESSOR in
   AARCH64)
 if [ -z "$QEMU_COMMAND" ]; then
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38801): https://edk2.groups.io/g/devel/message/38801
Mute This Topic: https://groups.io/mt/31017203/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH] EmulatorPkg/build.sh: Fix missing usage of -b BUILDTARGET parameter

2019-04-10 Thread Jordan Justen
Signed-off-by: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
---
 EmulatorPkg/build.sh | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/EmulatorPkg/build.sh b/EmulatorPkg/build.sh
index 89fd26baca..75561c116a 100755
--- a/EmulatorPkg/build.sh
+++ b/EmulatorPkg/build.sh
@@ -1,7 +1,7 @@
 #!/bin/bash
 #
 # Copyright (c) 2008 - 2011, Apple Inc. All rights reserved.
-# Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -188,7 +188,7 @@ do
 done
 
 PLATFORMFILE=$WORKSPACE/EmulatorPkg/EmulatorPkg.dsc
-BUILD_DIR=$BUILD_OUTPUT_DIR/DEBUG_"$TARGET_TOOLS"
+BUILD_DIR="$BUILD_OUTPUT_DIR/${BUILDTARGET}_$TARGET_TOOLS"
 BUILD_ROOT_ARCH=$BUILD_DIR/$PROCESSOR
 
 if  [[ ! -f `which build` || ! -f `which GenFv` ]];
@@ -218,11 +218,11 @@ if [[ "$RUN_EMULATOR" == "yes" ]]; then
   then
   # only older versions of Xcode support -ccc-host-tripe, for newer 
versions
   # it is -target
-cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py 
$BUILD_OUTPUT_DIR/DEBUG_"$TARGET_TOOLS"/$PROCESSOR
+cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py 
"$BUILD_OUTPUT_DIR/${BUILDTARGET}_$TARGET_TOOLS/$PROCESSOR"
 cd $BUILD_ROOT_ARCH; /usr/bin/lldb --source 
$WORKSPACE/EmulatorPkg/Unix/lldbinit Host
 exit $? 
   else
-cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit 
$BUILD_OUTPUT_DIR/DEBUG_"$TARGET_TOOLS"/$PROCESSOR
+cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit 
"$BUILD_OUTPUT_DIR/${BUILDTARGET}_$TARGET_TOOLS/$PROCESSOR"
   fi
   ;;
   esac
@@ -255,7 +255,7 @@ if [[ $HOST_TOOLS == $TARGET_TOOLS ]]; then
 else
   build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR 
-b $BUILDTARGET -t $HOST_TOOLS  -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD -D 
SKIP_MAIN_BUILD -n 3 modules
   build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR 
-b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE $NETWORK_SUPPORT 
$BUILD_NEW_SHELL $BUILD_FAT -n 3
-  cp $BUILD_OUTPUT_DIR/DEBUG_"$HOST_TOOLS"/$PROCESSOR/Host $BUILD_ROOT_ARCH
+  cp "$BUILD_OUTPUT_DIR/${BUILDTARGET}_$HOST_TOOLS/$PROCESSOR/Host" 
$BUILD_ROOT_ARCH
 fi
 exit $?
 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38794): https://edk2.groups.io/g/devel/message/38794
Mute This Topic: https://groups.io/mt/31017060/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2][PATCH V2] BaseTools:Enable the /MP option of MSVC compiler

2019-04-10 Thread Fan, ZhijuX
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1672
The /MP option of MSVC compiler can reduce the total time to compile the
source files on the command line.

This patch is going to enable this MSVC option in BaseTools.

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Conf/tools_def.template  | 126 ++---
 BaseTools/Source/Python/AutoGen/GenMake.py |  81 +--
 2 files changed, 137 insertions(+), 70 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index abda2164a6..bffb6d63eb 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -674,9 +674,9 @@ NOOPT_VS2008_IA32_DLINK_FLAGS = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF
 *_VS2008_X64_ASLPP_PATH= DEF(VS2008_BINX64)\cl.exe
 *_VS2008_X64_ASLDLINK_PATH = DEF(VS2008_BINX64)\link.exe
 
-  DEBUG_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm
-RELEASE_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
+  DEBUG_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /MP
+RELEASE_VS2008_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /MP
+NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /Od /MP
 
   DEBUG_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -876,9 +876,9 @@ NOOPT_VS2008xASL_X64_DLINK_FLAGS= /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:RE
 *_VS2008x86_IA32_ASM_PATH = DEF(VS2008x86_BIN)\ml.exe
 
   *_VS2008x86_IA32_MAKE_FLAGS  = /nologo
-  DEBUG_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
-RELEASE_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2008x86_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
+  DEBUG_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /MP
+RELEASE_VS2008x86_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /MP
+NOOPT_VS2008x86_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Od /MP
 
   DEBUG_VS2008x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2008x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -908,9 +908,9 @@ NOOPT_VS2008x86_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF
 *_VS2008x86_X64_DLINK_PATH= DEF(VS2008x86_BINX64)\link.exe
 *_VS2008x86_X64_ASLDLINK_PATH = DEF(VS2008x86_BINX64)\link.exe
 
-  DEBUG_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm
-RELEASE_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2008x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
+  DEBUG_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /MP
+RELEASE_VS2008x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /MP
+NOOPT_VS2008x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /Od /MP
 
   DEBUG_VS2008x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2008x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -1109,9 +1109,9 @@ NOOPT_VS2008x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 *_VS2010_IA32_ASLDLINK_PATH   = DEF(VS2010_BIN)\link.exe
 
   *_VS2010_IA32_MAKE_FLAGS= /nologo
-  DEBUG_VS2010_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
-RELEASE_VS2010_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2010_IA32_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
+  DEBUG_VS2010_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /MP
+RELEASE_VS2010_IA32_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h 

[edk2-devel] [PATCH v2 5/6] MdeModulePkg/Core/Pei: Add X64 assembly for TemporaryRamMigration

2019-04-10 Thread Jordan Justen
Some compilers may optimize register usage in ways that are
incompatible with the TemporaryRamSupport PPI. Using assembly code to
call the TemporaryRamMigration function prevents this issue.

Signed-off-by: Jordan Justen 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
---
 .../Dispatcher/X64/TemporaryRamMigration.nasm | 74 +++
 MdeModulePkg/Core/Pei/PeiMain.inf |  3 +
 2 files changed, 77 insertions(+)
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm 
b/MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm
new file mode 100644
index 00..5de8acdf34
--- /dev/null
+++ b/MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm
@@ -0,0 +1,74 @@
+;--
+;
+; Copyright (c) 2018, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+#include 
+
+SECTION .text
+
+extern ASM_PFX(PeiTemporaryRamMigrated)
+
+;--
+; VOID
+; EFIAPI
+; PeiTemporaryRamMigration (
+;   IN  PEI_CORE_TEMPORARY_RAM_TRANSITION  *TempRamTransitionData
+;   );
+;
+; @param[in]  RCX   Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+; @return None  This routine does not return
+;--
+global ASM_PFX(PeiTemporaryRamMigration)
+ASM_PFX(PeiTemporaryRamMigration):
+
+;
+; We never return from this call
+;
+add rsp, 8
+
+;
+;   (rax) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+mov rax, rcx
+
+;
+; We store the TempRamTransitionData pointer in rbx. By the X64
+; calling convention we should normally save rbx, but we won't be
+; returning to the caller, so we don't need to save it. By the
+; same rule, the TemporaryRamMigration PPI call should preserve
+; rbx for us.
+;
+mov rbx, rcx
+
+;
+; Setup parameters and call TemporaryRamSupport->TemporaryRamMigration
+;   (rcx) PeiServices
+;   (rdx) TemporaryMemoryBase
+;   (r8)  PermanentMemoryBase
+;   (r9)  CopySize
+;
+mov rcx, [rax + 0x08]
+mov rdx, [rax + 0x10]
+mov r8, [rax + 0x18]
+mov r9, [rax + 0x20]
+
+;
+; (rbx) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION on stack
+;
+; Adjusted based on stack change made during
+; TemporaryRamSupport->TemporaryRamMigration call
+;
+sub rbx, rsp
+call[rax + 0x00]
+add rbx, rsp
+
+;
+; Setup parameters and call PeiTemporaryRamMigrated
+;   (rcx) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+mov rcx, rbx
+callASM_PFX(PeiTemporaryRamMigrated)
diff --git a/MdeModulePkg/Core/Pei/PeiMain.inf 
b/MdeModulePkg/Core/Pei/PeiMain.inf
index 918c4a0df8..fb643a9dd5 100644
--- a/MdeModulePkg/Core/Pei/PeiMain.inf
+++ b/MdeModulePkg/Core/Pei/PeiMain.inf
@@ -59,6 +59,9 @@
 [Sources.Ia32]
   Dispatcher/Ia32/TemporaryRamMigration.nasm
 
+[Sources.X64]
+  Dispatcher/X64/TemporaryRamMigration.nasm
+
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38791): https://edk2.groups.io/g/devel/message/38791
Mute This Topic: https://groups.io/mt/31016933/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v2 2/6] MdeModulePkg/Core/Pei: Add AARCH64 assembly for TemporaryRamMigration

2019-04-10 Thread Jordan Justen
Signed-off-by: Jordan Justen 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 .../AArch64/TemporaryRamMigration.S   | 63 +++
 .../AArch64/TemporaryRamMigration.asm | 63 +++
 MdeModulePkg/Core/Pei/PeiMain.inf |  4 ++
 3 files changed, 130 insertions(+)
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S 
b/MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S
new file mode 100644
index 00..e73932daff
--- /dev/null
+++ b/MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S
@@ -0,0 +1,63 @@
+#--
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#--
+
+.text
+.align 5
+
+GCC_ASM_EXPORT(PeiTemporaryRamMigration)
+
+#--
+# VOID
+# EFIAPI
+# PeiTemporaryRamMigration (
+#   IN  PEI_CORE_TEMPORARY_RAM_TRANSITION  *TempRamTransitionData
+#   );
+#
+# @param[in]  x0Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+#
+# @return None  This routine does not return
+#--
+ASM_PFX(PeiTemporaryRamMigration):
+
+#
+# We store the TempRamTransitionData pointer in x19. By the
+# AArch64 calling convention we should normally save x19, but we
+# won't be returning to the caller, so we don't need to save it.
+# By the same rule, the TemporaryRamMigration PPI call should
+# preserve x19 for us.
+#
+mov x19, x0
+
+#
+# Setup parameters and call TemporaryRamSupport->TemporaryRamMigration
+#   (rcx) PeiServices
+#   (rdx) TemporaryMemoryBase
+#   (r8)  PermanentMemoryBase
+#   (r9)  CopySize
+#
+ldp x0, x1, [x19, 0x08]
+ldp x2, x3, [x19, 0x18]
+
+#
+# (x19) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION on stack
+#
+# Adjusted based on stack change made during
+# TemporaryRamSupport->TemporaryRamMigration call
+#
+ldr x4, [x19]
+mov x5, sp
+sub x19, x19, x5
+blr x4
+mov x5, sp
+add x19, x19, x5
+
+#
+# Setup parameters and call PeiTemporaryRamMigrated
+#   (x0) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+#
+mov x0, x19
+bl  ASM_PFX(PeiTemporaryRamMigrated)
diff --git a/MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm 
b/MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm
new file mode 100644
index 00..fbffd16c52
--- /dev/null
+++ b/MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm
@@ -0,0 +1,63 @@
+;--
+;
+; Copyright (c) 2019, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+  EXPORT PeiTemporaryRamMigration
+  AREA PeiCore_LowLevel, CODE, READONLY
+
+;--
+; VOID
+; EFIAPI
+; PeiTemporaryRamMigration (
+;   IN  PEI_CORE_TEMPORARY_RAM_TRANSITION  *TempRamTransitionData
+;   );
+;
+; @param[in]  x0Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+; @return None  This routine does not return
+;--
+PeiTemporaryRamMigration
+
+;
+; We store the TempRamTransitionData pointer in x19. By the
+; AArch64 calling convention we should normally save x19, but we
+; won't be returning to the caller, so we don't need to save it.
+; By the same rule, the TemporaryRamMigration PPI call should
+; preserve x19 for us.
+;
+mov x19, x0
+
+;
+; Setup parameters and call TemporaryRamSupport->TemporaryRamMigration
+;   (rcx) PeiServices
+;   (rdx) TemporaryMemoryBase
+;   (r8)  PermanentMemoryBase
+;   (r9)  CopySize
+;
+ldp x0, x1, [x19, 0x08]
+ldp x2, x3, [x19, 0x18]
+
+;
+; (x19) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION on stack
+;
+; Adjusted based on stack change made during
+; TemporaryRamSupport->TemporaryRamMigration call
+;
+ldr x4, [x19]
+mov x5, sp
+sub x19, x19, x5
+blr x4
+mov x5, sp
+add x19, x19, x5
+
+;
+; Setup parameters and call PeiTemporaryRamMigrated
+;   (x0) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+mov x0, x19
+bl  ASM_PFX(PeiTemporaryRamMigrated)
+
+  END
diff --git 

[edk2-devel] [PATCH v2 6/6] MdeModulePkg/Core/Pei: Use code path for assembly based TemporaryRamSupport

2019-04-10 Thread Jordan Justen
There is potential problem with PEI Core's usage of the
TemporaryRamSupport PPI. The issue is described in the previous patch:

"MdeModulePkg/Core/Pei: Add interface for assembly based TemporaryRamSupport"

Now that assembly paths are available for all supported architectures,
we can make use of the assembly based PEI Core code path.

Signed-off-by: Jordan Justen 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
---
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 ---
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index ba2fd0cae1..116124d6f8 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -682,6 +682,7 @@ PeiCheckAndSwitchStack (
   EFI_PHYSICAL_ADDRESS  TempBase2;
   UINTN TempSize2;
   UINTN Index;
+  PEI_CORE_TEMPORARY_RAM_TRANSITION TempRamTransitionData;
 
   PeiServices = (CONST EFI_PEI_SERVICES **) >Ps;
 
@@ -816,30 +817,20 @@ PeiCheckAndSwitchStack (
 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private - StackOffset);
   }
 
-  //
-  // Temporary Ram Support PPI is provided by platform, it will copy
-  // temporary memory to permanent memory and do stack switching.
-  // After invoking Temporary Ram Support PPI, the following code's
-  // stack is in permanent memory.
-  //
-  TemporaryRamSupportPpi->TemporaryRamMigration (
-PeiServices,
-TemporaryRamBase,
-(EFI_PHYSICAL_ADDRESS)(UINTN)(TopOfNewStack - 
TemporaryStackSize),
-TemporaryRamSize
-);
-
-  //
-  // Migrate memory pages allocated in pre-memory phase.
-  // It could not be called before calling 
TemporaryRamSupportPpi->TemporaryRamMigration()
-  // as the migrated memory pages may be overridden by 
TemporaryRamSupportPpi->TemporaryRamMigration().
-  //
-  MigrateMemoryPages (Private, TRUE);
+  TempRamTransitionData.TemporaryRamMigration =
+TemporaryRamSupportPpi->TemporaryRamMigration;
+  TempRamTransitionData.PeiServices = PeiServices;
+  TempRamTransitionData.TemporaryMemoryBase = TemporaryRamBase;
+  TempRamTransitionData.PermanentMemoryBase =
+(EFI_PHYSICAL_ADDRESS)(UINTN)(TopOfNewStack - TemporaryStackSize);
+  TempRamTransitionData.CopySize = TemporaryRamSize;
+  TempRamTransitionData.Private = Private;
+  TempRamTransitionData.SecCoreData = SecCoreData;
 
   //
-  // Entry PEI Phase 2
+  // Migrate Temporary RAM and enter PEI Phase 2
   //
-  PeiCore (SecCoreData, NULL, Private);
+  PeiTemporaryRamMigration();
 } else {
   //
   // Migrate memory pages allocated in pre-memory phase.
@@ -952,6 +943,32 @@ PeiCheckAndSwitchStack (
   }
 }
 
+VOID
+EFIAPI
+PeiTemporaryRamMigrated (
+  IN  VOID  *CallbackContext
+  )
+{
+  PEI_CORE_TEMPORARY_RAM_TRANSITION *TempRamTransitionData =
+(PEI_CORE_TEMPORARY_RAM_TRANSITION*)CallbackContext;
+
+  //
+  // Migrate memory pages allocated in pre-memory phase.
+  // It could not be called before calling 
TemporaryRamSupportPpi->TemporaryRamMigration()
+  // as the migrated memory pages may be overridden by 
TemporaryRamSupportPpi->TemporaryRamMigration().
+  //
+  MigrateMemoryPages (TempRamTransitionData->Private, TRUE);
+
+  //
+  // Entry PEI Phase 2
+  //
+  PeiCore (
+TempRamTransitionData->SecCoreData,
+NULL,
+TempRamTransitionData->Private
+);
+}
+
 /**
   Conduct PEIM dispatch.
 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38790): https://edk2.groups.io/g/devel/message/38790
Mute This Topic: https://groups.io/mt/31016932/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v2 3/6] MdeModulePkg/Core/Pei: Add ARM assembly for TemporaryRamMigration

2019-04-10 Thread Jordan Justen
Signed-off-by: Jordan Justen 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 .../Dispatcher/Arm/TemporaryRamMigration.S| 68 +++
 .../Dispatcher/Arm/TemporaryRamMigration.asm  | 68 +++
 MdeModulePkg/Core/Pei/PeiMain.inf |  5 ++
 3 files changed, 141 insertions(+)
 create mode 100644 MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S 
b/MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S
new file mode 100644
index 00..872bbcf27d
--- /dev/null
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S
@@ -0,0 +1,68 @@
+#--
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#--
+
+.text
+.align 5
+
+GCC_ASM_EXPORT(PeiTemporaryRamMigration)
+
+#--
+# VOID
+# EFIAPI
+# PeiTemporaryRamMigration (
+#   IN  PEI_CORE_TEMPORARY_RAM_TRANSITION  *TempRamTransitionData
+#   );
+#
+# @param[in]  r0Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+#
+# @return None  This routine does not return
+#--
+ASM_PFX(PeiTemporaryRamMigration):
+
+#
+# We store the TempRamTransitionData pointer in r6. By the
+# Arm calling convention we should normally save r6, but we
+# won't be returning to the caller, so we don't need to save it.
+# By the same rule, the TemporaryRamMigration PPI call should
+# preserve r6 for us.
+#
+mov r6, r0
+
+#
+# Setup parameters and call TemporaryRamSupport->TemporaryRamMigration
+#   (r0)  PeiServices
+#   (r2,r3)   TemporaryMemoryBase
+#   (stack)   PermanentMemoryBase
+#   (stack)   CopySize
+#
+add r7, r6, #4
+ldmia   r7, {r0-r5}
+stmfd   sp!, {r3, r4, r5}
+mov r3, r2
+mov r2, r1
+
+#
+# (r6) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION on stack
+#
+# Adjusted based on stack change made during
+# TemporaryRamSupport->TemporaryRamMigration call
+#
+ldr r4, [r6]
+mov r5, sp
+sub r6, r6, r5
+mov lr, pc
+bx  r4
+mov r0, sp
+add r6, r6, r0
+add sp, sp, #0xc
+
+#
+# Setup parameters and call PeiTemporaryRamMigrated
+#   (r0) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+#
+mov r0, r6
+bl  ASM_PFX(PeiTemporaryRamMigrated)
diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm 
b/MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm
new file mode 100644
index 00..1cfb0e0dd8
--- /dev/null
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm
@@ -0,0 +1,68 @@
+;--
+;
+; Copyright (c) 2019, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+  EXPORT PeiTemporaryRamMigration
+  AREA PeiCore_LowLevel, CODE, READONLY
+
+;--
+; VOID
+; EFIAPI
+; PeiTemporaryRamMigration (
+;   IN  PEI_CORE_TEMPORARY_RAM_TRANSITION  *TempRamTransitionData
+;   );
+;
+; @param[in]  r0Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+; @return None  This routine does not return
+;--
+PeiTemporaryRamMigration
+
+;
+; We store the TempRamTransitionData pointer in r6. By the
+; Arm calling convention we should normally save r6, but we
+; won't be returning to the caller, so we don't need to save it.
+; By the same rule, the TemporaryRamMigration PPI call should
+; preserve r6 for us.
+;
+mov r6, r0
+
+;
+; Setup parameters and call TemporaryRamSupport->TemporaryRamMigration
+;   (r0)  PeiServices
+;   (r2,r3)   TemporaryMemoryBase
+;   (stack)   PermanentMemoryBase
+;   (stack)   CopySize
+;
+add r7, r6, #4
+ldmia   r7, {r0-r5}
+stmfd   sp!, {r3, r4, r5}
+mov r3, r2
+mov r2, r1
+
+;
+; (r6) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION on stack
+;
+; Adjusted based on stack change made during
+; TemporaryRamSupport->TemporaryRamMigration call
+;
+ldr r4, [r6]
+mov r5, sp
+sub r6, r6, r5
+mov lr, pc
+bx  r4
+mov r0, sp
+add r6, r6, r0
+add sp, sp, #0xc
+
+;
+; Setup parameters and call PeiTemporaryRamMigrated
+;   (r0) 

[edk2-devel] [PATCH v2 4/6] MdeModulePkg/Core/Pei: Add IA32 assembly for TemporaryRamMigration

2019-04-10 Thread Jordan Justen
Signed-off-by: Jordan Justen 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
---
 .../Ia32/TemporaryRamMigration.nasm   | 77 +++
 MdeModulePkg/Core/Pei/PeiMain.inf |  3 +
 2 files changed, 80 insertions(+)
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm 
b/MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm
new file mode 100644
index 00..8014e3cc95
--- /dev/null
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm
@@ -0,0 +1,77 @@
+;--
+;
+; Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+#include 
+
+SECTION .text
+
+extern ASM_PFX(PeiTemporaryRamMigrated)
+
+;--
+; VOID
+; EFIAPI
+; PeiTemporaryRamMigration (
+;   IN  PEI_CORE_TEMPORARY_RAM_TRANSITION  *TempRamTransitionData
+;   );
+;
+; @param[in]  Stack Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+; @return None  This routine does not return
+;--
+global ASM_PFX(PeiTemporaryRamMigration)
+ASM_PFX(PeiTemporaryRamMigration):
+
+;
+; We never return from this call
+;
+add esp, 4
+
+;
+;   (eax) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+mov eax, [esp]
+
+;
+; We store the TempRamTransitionData pointer in ebx. By the IA32
+; calling convention we should normally save ebx, but we won't be
+; returning to the caller, so we don't need to save it. By the
+; same rule, the TemporaryRamMigration PPI call should preserve
+; ebx for us.
+;
+mov ebx, [esp]
+
+;
+; Setup parameters and call TemporaryRamSupport->TemporaryRamMigration
+;   32-bit PeiServices
+;   64-bit TemporaryMemoryBase
+;   64-bit PermanentMemoryBase
+;   32-bit CopySize
+;
+pushDWORD [eax + 0x18] ; CopySize
+pushDWORD [eax + 0x14] ; PermanentMemoryBase Upper 32-bit
+pushDWORD [eax + 0x10] ; PermanentMemoryBase Lower 32-bit
+pushDWORD [eax + 0x0c] ; TemporaryMemoryBase Upper 32-bit
+pushDWORD [eax + 0x08] ; TemporaryMemoryBase Lower 32-bit
+pushDWORD [eax + 0x04] ; PeiServices
+
+;
+; (ebx) Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION on stack
+;
+; Adjusted based on stack change made during
+; TemporaryRamSupport->TemporaryRamMigration call
+;
+sub ebx, esp
+callDWORD [eax + 0x00]
+add ebx, esp
+add esp, 0x18
+
+;
+; Setup parameters and call PeiTemporaryRamMigrated
+;   32-bit Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+;
+pushebx
+callASM_PFX(PeiTemporaryRamMigrated)
diff --git a/MdeModulePkg/Core/Pei/PeiMain.inf 
b/MdeModulePkg/Core/Pei/PeiMain.inf
index 1be898bb91..918c4a0df8 100644
--- a/MdeModulePkg/Core/Pei/PeiMain.inf
+++ b/MdeModulePkg/Core/Pei/PeiMain.inf
@@ -56,6 +56,9 @@
   Dispatcher/Arm/TemporaryRamMigration.asm | MSFT
   Dispatcher/Arm/TemporaryRamMigration.S   | GCC
 
+[Sources.Ia32]
+  Dispatcher/Ia32/TemporaryRamMigration.nasm
+
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38789): https://edk2.groups.io/g/devel/message/38789
Mute This Topic: https://groups.io/mt/31016930/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v2 1/6] MdeModulePkg/Core/Pei: Add interface for assembly based TemporaryRamSupport

2019-04-10 Thread Jordan Justen
There is potential problem with PEI Core's usage of the
TemporaryRamSupport PPI. When the TemporaryRamMigration function is
called, it returns to C based code after changing the stack to the new
permanent memory copy of the stack. But, the C compiler may have
stored pointers to addresses on the old temporary RAM stack. Even
though the stack is copied to a new permanent memory location, it is
not possible to adjust all pointers that the C compiler may have added
within the stack data.

For this reason, it is only safe to return to assembly code after
calling TemporaryRamMigration. The assembly code can make sure the old
temporary RAM stack is not used before calling a new C function. When
the new function is called, it will use the new permanent memory
stack, so it is safe to use C code again.

This patch add the interface that the assembly function will need. The
PEI_CORE_TEMPORARY_RAM_TRANSITION contains all the data that the
assembly code will need to call the
TemporaryRamSupport->TemporaryRamMigration function, and then the
context that PEI will need after this call when the new C based
PeiTemporaryRamMigrated function is called.

After all assembly code based implementations have been added, PEI
Core will be updated to use the new assembly based code path.

Signed-off-by: Jordan Justen 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
---
 MdeModulePkg/Core/Pei/PeiMain.h | 52 +
 1 file changed, 52 insertions(+)

diff --git a/MdeModulePkg/Core/Pei/PeiMain.h b/MdeModulePkg/Core/Pei/PeiMain.h
index 0aed4f4685..6522798059 100644
--- a/MdeModulePkg/Core/Pei/PeiMain.h
+++ b/MdeModulePkg/Core/Pei/PeiMain.h
@@ -1865,4 +1865,56 @@ PeiReinitializeFv (
   IN  PEI_CORE_INSTANCE   *PrivateData
   );
 
+#pragma pack(1)
+typedef struct {
+  /**
+These fields are used by PeiTemporaryRamMigration to call the
+TemporaryRamMigration PPI.
+  **/
+  TEMPORARY_RAM_MIGRATION   TemporaryRamMigration;
+  CONST EFI_PEI_SERVICES**PeiServices;
+  EFI_PHYSICAL_ADDRESS  TemporaryMemoryBase;
+  EFI_PHYSICAL_ADDRESS  PermanentMemoryBase;
+  UINTN CopySize;
+
+  /**
+These fields are used by PeiTemporaryRamMigrated.
+  **/
+  PEI_CORE_INSTANCE *Private;
+  CONST EFI_SEC_PEI_HAND_OFF*SecCoreData;
+} PEI_CORE_TEMPORARY_RAM_TRANSITION;
+#pragma pack()
+
+/**
+  To call the TemporaryRamMigration PPI, we might not be able to rely
+  on C code's handling of the stack. In these cases we use an assembly
+  function to make sure the old stack is not used after the
+  TemporaryRamMigration PPI is used.
+
+  After calling the TemporaryRamMigration PPI, this function calls
+  PeiTemporaryRamMigrated.
+
+  @param TempRamTransitionData
+**/
+VOID
+EFIAPI
+PeiTemporaryRamMigration (
+  IN  PEI_CORE_TEMPORARY_RAM_TRANSITION  *TempRamTransitionData
+  );
+
+/**
+  After PeiTemporaryRamMigration has called the TemporaryRamMigration
+  PPI, it will call this C based function to allow PEI to continue
+  after the migration using the new stack in the migrated RAM.
+
+  @param CallbackContext   Pointer to PEI_CORE_TEMPORARY_RAM_TRANSITION
+   data.
+**/
+VOID
+EFIAPI
+PeiTemporaryRamMigrated (
+  IN  VOID  *CallbackContext
+  );
+
+
 #endif
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38786): https://edk2.groups.io/g/devel/message/38786
Mute This Topic: https://groups.io/mt/31016924/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v2 0/6] Fix PEI Core issue during TemporaryRamMigration

2019-04-10 Thread Jordan Justen
https://github.com/jljusten/edk2.git temp-ram-support-v2

https://github.com/jljusten/edk2/commits/temp-ram-support-v2

v2:
 * Add AARCH64 and ARM assembly
 * Drop IA32 and X64 .S source files
 * Adjust PEI_CORE_TEMPORARY_RAM_TRANSITION pointer in the assembly
   code based on the stack pointer change before & after
   TemporaryRamSupport->TemporaryRamMigration
 * Drop extra cleanup patches for OvmfPkg & EmulatorPkg. These were
   just complicating the series.

This series fixes an issue that, while rare, is possible based on the
way the TemporaryRamSupport PPI is defined along with how it is used
by the PEI Core.

Liu Yu reported a boot issue with EmulatorPkg, which I believe was
caused by this issue.

The details of the issue are described in the commit message of the
"MdeModulePkg/Core/Pei: Add interface for assembly based
TemporaryRamSupport" patch.

Testing:

I tested building and booting in several scenarios:

* OVMF IA32 & X64 on Linux
* ArmVirtPkg AARCH64 & ARM on x86_64 Linux
* EmulatorPkg IA32 & X64 on Linux

Untested:

* My system does not reproduce the issue that Liu Yu reported with
  EmulatorPkg, so I can't say that I have verified that issue.
* Building on windows
* AARCH64/ARM TemporaryRamMigration.asm sources

Cc: Liu Yu 
Cc: Ray Ni 
Cc: Andrew Fish 
Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Michael D Kinney 

Jordan Justen (6):
  MdeModulePkg/Core/Pei: Add interface for assembly based
TemporaryRamSupport
  MdeModulePkg/Core/Pei: Add AARCH64 assembly for TemporaryRamMigration
  MdeModulePkg/Core/Pei: Add ARM assembly for TemporaryRamMigration
  MdeModulePkg/Core/Pei: Add IA32 assembly for TemporaryRamMigration
  MdeModulePkg/Core/Pei: Add X64 assembly for TemporaryRamMigration
  MdeModulePkg/Core/Pei: Use code path for assembly based
TemporaryRamSupport

 .../AArch64/TemporaryRamMigration.S   | 63 +++
 .../AArch64/TemporaryRamMigration.asm | 63 +++
 .../Dispatcher/Arm/TemporaryRamMigration.S| 68 
 .../Dispatcher/Arm/TemporaryRamMigration.asm  | 68 
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 +-
 .../Ia32/TemporaryRamMigration.nasm   | 77 +++
 .../Dispatcher/X64/TemporaryRamMigration.nasm | 74 ++
 MdeModulePkg/Core/Pei/PeiMain.h   | 52 +
 MdeModulePkg/Core/Pei/PeiMain.inf | 15 
 9 files changed, 518 insertions(+), 21 deletions(-)
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.S
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/AArch64/TemporaryRamMigration.asm
 create mode 100644 MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.S
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/Arm/TemporaryRamMigration.asm
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm
 create mode 100644 
MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm

-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38785): https://edk2.groups.io/g/devel/message/38785
Mute This Topic: https://groups.io/mt/31016921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2][PATCH] BaseTools:Coding problems cause can not encode FMP Auth Header

2019-04-10 Thread Fan, ZhijuX
GenerateCapsule: error: can not encode FMP Auth Header
The system cannot find the file specified.

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Capsule/GenerateCapsule.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Capsule/GenerateCapsule.py 
b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
index ab1c811b22..4de3635298 100644
--- a/BaseTools/Source/Python/Capsule/GenerateCapsule.py
+++ b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
@@ -126,7 +126,7 @@ def SignPayloadOpenSsl (Payload, ToolPath, 
SignerPrivateCertFile, OtherPublicCer
 try:
 Process = subprocess.Popen (Command, stdin = subprocess.PIPE, stdout = 
subprocess.PIPE, stderr = subprocess.PIPE, shell = True)
 Result = Process.communicate(input = Payload)
-Signature = Result[0].decode(encoding='utf-8', errors='ignore')
+Signature = Result[0]
 except:
 raise ValueError ('GenerateCapsule: error: can not run openssl.')
 
-- 
2.14.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38784): https://edk2.groups.io/g/devel/message/38784
Mute This Topic: https://groups.io/mt/31016918/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

<>

[edk2-devel] [PATCH 4/5] MdeModulePkg/UefidebugLibConOut: Make it runtime safe

2019-04-10 Thread Gao, Zhichao
From: Aaron Antone 

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

After ExitBootServices, some pointer would be invalid such as
the Protocol pointer and gBS. The function depend on those should
be prevent. So disable the related function while after
ExitBootServices.
Change the gST to a internal one, because there will be a cycle
consume between UefiBootServicesTableLib and DebugLib due to the
library constructors.
Also remove the SMM support for this instance.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 MdePkg/Library/UefiDebugLibConOut/DebugLib.c  | 116 +-
 .../UefiDebugLibConOut/DebugLibConstructor.c  |  72 +++
 .../UefiDebugLibConOut/UefiDebugLibConOut.inf |  12 +-
 3 files changed, 142 insertions(+), 58 deletions(-)
 create mode 100644 MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c

diff --git a/MdePkg/Library/UefiDebugLibConOut/DebugLib.c 
b/MdePkg/Library/UefiDebugLibConOut/DebugLib.c
index c430419c99..cf168d05cf 100644
--- a/MdePkg/Library/UefiDebugLibConOut/DebugLib.c
+++ b/MdePkg/Library/UefiDebugLibConOut/DebugLib.c
@@ -9,7 +9,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -27,6 +26,9 @@
 //
 VA_LIST mVaListNull;
 
+extern BOOLEANmPostEBS;
+extern EFI_SYSTEM_TABLE   *mDebugST;
+
 /**
   Prints a debug message to the debug output device if the specified error 
level is enabled.
 
@@ -85,33 +87,35 @@ DebugPrintMarker (
 {
   CHAR16   Buffer[MAX_DEBUG_MESSAGE_LENGTH];
 
-  //
-  // If Format is NULL, then ASSERT().
-  //
-  ASSERT (Format != NULL);
-
-  //
-  // Check driver debug mask value and global mask
-  //
-  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
-return;
-  }
-
-  //
-  // Convert the DEBUG() message to a Unicode String
-  //
-  if (BaseListMarker == NULL) {
-UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH,  Format, 
VaListMarker);
-  } else {
-UnicodeBSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH,  Format, 
BaseListMarker);
-  }
-
-
-  //
-  // Send the print string to the Console Output device
-  //
-  if ((gST != NULL) && (gST->ConOut != NULL)) {
-gST->ConOut->OutputString (gST->ConOut, Buffer);
+  if (!mPostEBS) {
+//
+// If Format is NULL, then ASSERT().
+//
+ASSERT (Format != NULL);
+
+//
+// Check driver debug mask value and global mask
+//
+if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
+  return;
+}
+
+//
+// Convert the DEBUG() message to a Unicode String
+//
+if (BaseListMarker == NULL) {
+  UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH,  Format, 
VaListMarker);
+} else {
+  UnicodeBSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH,  Format, 
BaseListMarker);
+}
+
+
+//
+// Send the print string to the Console Output device
+//
+if ((mDebugST != NULL) && (mDebugST->ConOut != NULL)) {
+  mDebugST->ConOut->OutputString (mDebugST->ConOut, Buffer);
+}
   }
 }
 
@@ -205,33 +209,35 @@ DebugAssert (
 {
   CHAR16  Buffer[MAX_DEBUG_MESSAGE_LENGTH];
 
-  //
-  // Generate the ASSERT() message in Unicode format
-  //
-  UnicodeSPrintAsciiFormat (
-Buffer,
-sizeof (Buffer),
-"ASSERT [%a] %a(%d): %a\n",
-gEfiCallerBaseName,
-FileName,
-LineNumber,
-Description
-);
-
-  //
-  // Send the print string to the Console Output device
-  //
-  if ((gST != NULL) && (gST->ConOut != NULL)) {
-gST->ConOut->OutputString (gST->ConOut, Buffer);
-  }
-
-  //
-  // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
-  //
-  if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) {
-CpuBreakpoint ();
-  } else if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED) != 0) {
-CpuDeadLoop ();
+  if (!mPostEBS) {
+//
+// Generate the ASSERT() message in Unicode format
+//
+UnicodeSPrintAsciiFormat (
+  Buffer,
+  sizeof (Buffer),
+  "ASSERT [%a] %a(%d): %a\n",
+  gEfiCallerBaseName,
+  FileName,
+  LineNumber,
+  Description
+  );
+
+//
+// Send the print string to the Console Output device
+//
+if ((mDebugST != NULL) && (mDebugST->ConOut != NULL)) {
+  mDebugST->ConOut->OutputString (mDebugST->ConOut, Buffer);
+}
+
+//
+// Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
+//
+if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) {
+  CpuBreakpoint ();
+} else if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED) != 0) {
+  CpuDeadLoop ();
+}
   }
 }
 
diff --git a/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c 
b/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
new file mode 100644
index 00..48a761a71e
--- /dev/null
+++ 

[edk2-devel] [PATCH 0/5] Make some DebugLib instance runtime safe

2019-04-10 Thread Gao, Zhichao
Some pointer will be invalid after ExitBootServices, such as protocol pointer,
gST, gBS and so on. Disable the functions which used that pointer.

Remove SMM support of UefiDebugLibDebugPortProtocol, UefidebugLibConOut
and UefiDebugLibStdErr.
Before removing, should change the SMM instance in the dsc file which use
them as SMM instance. And null version is safe.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 

Aaron Antone (3):
  MdeModulePkg/UefiDebugLibDebugPortProtocol: Make it runtime safe
  MdeModulePkg/UefidebugLibConOut: Make it runtime safe
  MdeModule/UefiDebugLibStdErr: Make it runtime safe

Zhichao Gao (2):
  MdeModulePkg: Change the SMM debug lib instance
  SignedCapsulePkg: Change the SMM debug lib instance

 MdeModulePkg/MdeModulePkg.dsc |   2 +-
 MdePkg/Library/UefiDebugLibConOut/DebugLib.c  | 116 +++---
 .../UefiDebugLibConOut/DebugLibConstructor.c  |  72 +
 .../UefiDebugLibConOut/UefiDebugLibConOut.inf |  12 +-
 .../UefiDebugLibDebugPortProtocol/DebugLib.c  | 146 +-
 .../DebugLibConstructor.c |  72 +
 .../UefiDebugLibDebugPortProtocol.inf |  12 +-
 MdePkg/Library/UefiDebugLibStdErr/DebugLib.c  | 113 +++---
 .../UefiDebugLibStdErr/DebugLibConstructor.c  |  72 +
 .../UefiDebugLibStdErr/UefiDebugLibStdErr.inf |  12 +-
 SignedCapsulePkg/SignedCapsulePkg.dsc |   4 +-
 11 files changed, 443 insertions(+), 190 deletions(-)
 create mode 100644 MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
 create mode 100644 
MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
 create mode 100644 MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38778): https://edk2.groups.io/g/devel/message/38778
Mute This Topic: https://groups.io/mt/31016456/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 5/5] MdeModule/UefiDebugLibStdErr: Make it runtime safe

2019-04-10 Thread Gao, Zhichao
From: Aaron Antone 

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

After ExitBootServices, some pointer would be invalid such as
the Protocol pointer and gBS. The function depend on those should
be prevent. So disable the related function while after
ExitBootServices.
Change the gST to a internal one, because there will be a cycle
consume between UefiBootServicesTableLib and DebugLib due to the
library constructors.
Also remove the SMM support for this instance.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 MdePkg/Library/UefiDebugLibStdErr/DebugLib.c  | 113 +-
 .../UefiDebugLibStdErr/DebugLibConstructor.c  |  72 +++
 .../UefiDebugLibStdErr/UefiDebugLibStdErr.inf |  12 +-
 3 files changed, 140 insertions(+), 57 deletions(-)
 create mode 100644 MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c

diff --git a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c 
b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c
index 29f93cf3e3..40eb697e7e 100644
--- a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c
+++ b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c
@@ -10,7 +10,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -29,6 +28,8 @@
 //
 VA_LIST mVaListNull;
 
+extern BOOLEANmPostEBS;
+extern EFI_SYSTEM_TABLE   *mDebugST;
 
 /**
   Prints a debug message to the debug output device if the specified error 
level is enabled.
@@ -88,32 +89,34 @@ DebugPrintMarker (
 {
   CHAR16   Buffer[MAX_DEBUG_MESSAGE_LENGTH];
 
-  //
-  // If Format is NULL, then ASSERT().
-  //
-  ASSERT (Format != NULL);
-
-  //
-  // Check driver debug mask value and global mask
-  //
-  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
-return;
-  }
-
-  //
-  // Convert the DEBUG() message to a Unicode String
-  //
-  if (BaseListMarker == NULL) {
-UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, 
VaListMarker);
-  } else {
-UnicodeBSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, 
BaseListMarker);
-  }
-
-  //
-  // Send the print string to the Standard Error device
-  //
-  if ((gST != NULL) && (gST->StdErr != NULL)) {
-gST->StdErr->OutputString (gST->StdErr, Buffer);
+  if (!mPostEBS) {
+//
+// If Format is NULL, then ASSERT().
+//
+ASSERT (Format != NULL);
+
+//
+// Check driver debug mask value and global mask
+//
+if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
+  return;
+}
+
+//
+// Convert the DEBUG() message to a Unicode String
+//
+if (BaseListMarker == NULL) {
+  UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, 
VaListMarker);
+} else {
+  UnicodeBSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, 
BaseListMarker);
+}
+
+//
+// Send the print string to the Standard Error device
+//
+if ((mDebugST != NULL) && (mDebugST->StdErr != NULL)) {
+  mDebugST->StdErr->OutputString (mDebugST->StdErr, Buffer);
+}
   }
 }
 
@@ -207,33 +210,35 @@ DebugAssert (
 {
   CHAR16  Buffer[MAX_DEBUG_MESSAGE_LENGTH];
 
-  //
-  // Generate the ASSERT() message in Unicode format
-  //
-  UnicodeSPrintAsciiFormat (
-Buffer,
-sizeof (Buffer),
-"ASSERT [%a] %a(%d): %a\n",
-gEfiCallerBaseName,
-FileName,
-LineNumber,
-Description
-);
-
-  //
-  // Send the print string to the Standard Error device
-  //
-  if ((gST != NULL) && (gST->StdErr != NULL)) {
-gST->StdErr->OutputString (gST->StdErr, Buffer);
-  }
-
-  //
-  // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
-  //
-  if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) {
-CpuBreakpoint ();
-  } else if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED) != 0) {
-CpuDeadLoop ();
+  if (!mPostEBS) {
+//
+// Generate the ASSERT() message in Unicode format
+//
+UnicodeSPrintAsciiFormat (
+  Buffer,
+  sizeof (Buffer),
+  "ASSERT [%a] %a(%d): %a\n",
+  gEfiCallerBaseName,
+  FileName,
+  LineNumber,
+  Description
+  );
+
+//
+// Send the print string to the Standard Error device
+//
+if ((mDebugST != NULL) && (mDebugST->StdErr != NULL)) {
+  mDebugST->StdErr->OutputString (mDebugST->StdErr, Buffer);
+}
+
+//
+// Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
+//
+if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) {
+  CpuBreakpoint ();
+} else if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED) != 0) {
+  CpuDeadLoop ();
+}
   }
 }
 
diff --git a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c 
b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
new file mode 100644
index 00..48a761a71e
--- /dev/null
+++ 

[edk2-devel] [PATCH 2/5] SignedCapsulePkg: Change the SMM debug lib instance

2019-04-10 Thread Gao, Zhichao
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1416

The UefiDebugLibConOut will not support DXE_SMM_DRIVER,
change UefiDebugLibConOut to PeiDxeDebugLibReportStatusCode.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 SignedCapsulePkg/SignedCapsulePkg.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/SignedCapsulePkg/SignedCapsulePkg.dsc 
b/SignedCapsulePkg/SignedCapsulePkg.dsc
index 862756e233..0da445503b 100644
--- a/SignedCapsulePkg/SignedCapsulePkg.dsc
+++ b/SignedCapsulePkg/SignedCapsulePkg.dsc
@@ -1,7 +1,7 @@
 ## @file
 # This package provides EDKII capsule related support.
 #
-# Copyright (c) 2016, Intel Corporation. All rights reserved.
+# Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -150,7 +150,7 @@
 
 [LibraryClasses.common.DXE_SMM_DRIVER]
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
-  DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
+  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38780): https://edk2.groups.io/g/devel/message/38780
Mute This Topic: https://groups.io/mt/31016458/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 1/5] MdeModulePkg: Change the SMM debug lib instance

2019-04-10 Thread Gao, Zhichao
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1416

The UefiDebugLibConOut will not support DXE_SMM_DRIVER,
change UefiDebugLibConOut to PeiDxeDebugLibReportStatusCode.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 MdeModulePkg/MdeModulePkg.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 7ef39af847..0da28e74c2 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -144,7 +144,7 @@
 
 [LibraryClasses.common.DXE_SMM_DRIVER]
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
-  DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
+  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
   MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#38779): https://edk2.groups.io/g/devel/message/38779
Mute This Topic: https://groups.io/mt/31016457/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH 3/5] MdeModulePkg/UefiDebugLibDebugPortProtocol: Make it runtime safe

2019-04-10 Thread Gao, Zhichao
From: Aaron Antone 

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

After ExitBootServices, some pointer would be invalid such as
the Protocol pointer and gBS. The function depend on those should
be prevent. So disable the related function while after
ExitBootServices.
Change the gBS to a internal one, because there will be a cycle
consume between UefiBootServicesTableLib and DebugLib due to the
library constructors.
Also remove the SMM support for this instance.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 .../UefiDebugLibDebugPortProtocol/DebugLib.c  | 146 +-
 .../DebugLibConstructor.c |  72 +
 .../UefiDebugLibDebugPortProtocol.inf |  12 +-
 3 files changed, 158 insertions(+), 72 deletions(-)
 create mode 100644 
MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c

diff --git a/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLib.c 
b/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLib.c
index 24bfb4f37e..cd7e2abbd3 100644
--- a/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLib.c
+++ b/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLib.c
@@ -9,7 +9,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -37,6 +36,9 @@ EFI_DEBUGPORT_PROTOCOL *mDebugPort = NULL;
 //
 VA_LIST mVaListNull;
 
+extern BOOLEANmPostEBS;
+extern EFI_BOOT_SERVICES *mDebugBS;
+
 /**
   Send message to DebugPort Protocol.
 
@@ -56,31 +58,33 @@ UefiDebugLibDebugPortProtocolWrite (
   UINTN  Length;
   EFI_STATUS Status;
 
-  //
-  // If mDebugPort is NULL, initialize first.
-  //
-  if (mDebugPort == NULL) {
-  Status = gBS->LocateProtocol (, NULL, (VOID 
**));
-  if (EFI_ERROR (Status)) {
-  return;
-  }
+  if (!mPostEBS) {
+//
+// If mDebugPort is NULL, initialize first.
+//
+if (mDebugPort == NULL) {
+Status = mDebugBS->LocateProtocol (, NULL, 
(VOID **));
+if (EFI_ERROR (Status)) {
+return;
+}
+
+mDebugPort->Reset (mDebugPort);
+}
 
-  mDebugPort->Reset (mDebugPort);
-  }
+//
+// EFI_DEBUGPORT_PROTOCOL.Write is called until all message is sent.
+//
+while (BufferLength > 0) {
+  Length = BufferLength;
 
-  //
-  // EFI_DEBUGPORT_PROTOCOL.Write is called until all message is sent.
-  //
-  while (BufferLength > 0) {
-Length = BufferLength;
+  Status = mDebugPort->Write (mDebugPort, WRITE_TIMEOUT, , (VOID *) 
Buffer);
+  if (EFI_ERROR (Status) || BufferLength < Length) {
+break;
+  }
 
-Status = mDebugPort->Write (mDebugPort, WRITE_TIMEOUT, , (VOID *) 
Buffer);
-if (EFI_ERROR (Status) || BufferLength < Length) {
-  break;
+  Buffer += Length;
+  BufferLength -= Length;
 }
-
-Buffer += Length;
-BufferLength -= Length;
   }
 }
 
@@ -142,31 +146,33 @@ DebugPrintMarker (
 {
   CHAR8  Buffer[MAX_DEBUG_MESSAGE_LENGTH];
 
-  //
-  // If Format is NULL, then ASSERT().
-  //
-  ASSERT (Format != NULL);
+  if (!mPostEBS) {
+//
+// If Format is NULL, then ASSERT().
+//
+ASSERT (Format != NULL);
+
+//
+// Check driver debug mask value and global mask
+//
+if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
+  return;
+}
 
-  //
-  // Check driver debug mask value and global mask
-  //
-  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
-return;
-  }
+//
+// Convert the DEBUG() message to an ASCII String
+//
+if (BaseListMarker == NULL) {
+  AsciiVSPrint (Buffer, sizeof (Buffer), Format, VaListMarker);
+} else {
+  AsciiBSPrint (Buffer, sizeof (Buffer), Format, BaseListMarker);
+}
 
-  //
-  // Convert the DEBUG() message to an ASCII String
-  //
-  if (BaseListMarker == NULL) {
-AsciiVSPrint (Buffer, sizeof (Buffer), Format, VaListMarker);
-  } else {
-AsciiBSPrint (Buffer, sizeof (Buffer), Format, BaseListMarker);
+//
+// Send the print string to EFI_DEBUGPORT_PROTOCOL.Write.
+//
+UefiDebugLibDebugPortProtocolWrite (Buffer, AsciiStrLen (Buffer));
   }
-
-  //
-  // Send the print string to EFI_DEBUGPORT_PROTOCOL.Write.
-  //
-  UefiDebugLibDebugPortProtocolWrite (Buffer, AsciiStrLen (Buffer));
 }
 
 
@@ -259,31 +265,33 @@ DebugAssert (
 {
   CHAR8  Buffer[MAX_DEBUG_MESSAGE_LENGTH];
 
-  //
-  // Generate the ASSERT() message in ASCII format
-  //
-  AsciiSPrint (
-Buffer,
-sizeof (Buffer),
-"ASSERT [%a] %a(%d): %a\n",
-gEfiCallerBaseName,
-FileName,
-LineNumber,
-Description
-);
-
-  //
-  // Send the print string to EFI_DEBUGPORT_PROTOCOL.Write.
-  //
-  UefiDebugLibDebugPortProtocolWrite (Buffer, AsciiStrLen (Buffer));
-
-  //
-  // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
-  //
-  if ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) {
-