[edk2] [Patch 1/2] BaseTools: add /Gw to CC_FLAGS for VS2013 and higher tool chain tags

2017-06-13 Thread Yonghong Zhu
The /Gw flag does a better job at size optimization than use of the
GLOBAL_REMOVE_IF_UNREFERENCED macro that is currently used for VS20xx
tool chains to remove unreferenced global variables.
This patch add /Gw to CC_FLAGS for VS2013 and higher tool chain tags.

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 04a1bcb..aa7ff2f 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3167,13 +3167,13 @@ NOOPT_VS2012x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 *_VS2013_IA32_ASLCC_PATH  = DEF(VS2013_BIN)\cl.exe
 *_VS2013_IA32_ASLPP_PATH  = DEF(VS2013_BIN)\cl.exe
 *_VS2013_IA32_ASLDLINK_PATH   = DEF(VS2013_BIN)\link.exe
 
   *_VS2013_IA32_MAKE_FLAGS= /nologo
-  DEBUG_VS2013_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
-RELEASE_VS2013_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2013_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
+  DEBUG_VS2013_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Gw
+RELEASE_VS2013_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gw
+NOOPT_VS2013_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od /Gw
 
   DEBUG_VS2013_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2013_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd
 NOOPT_VS2013_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 
@@ -3199,13 +3199,13 @@ NOOPT_VS2013_IA32_DLINK_FLAGS = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2013_X64_DLINK_PATH= DEF(VS2013_BINX64)\link.exe
 *_VS2013_X64_ASLCC_PATH= DEF(VS2013_BINX64)\cl.exe
 *_VS2013_X64_ASLPP_PATH= DEF(VS2013_BINX64)\cl.exe
 *_VS2013_X64_ASLDLINK_PATH = DEF(VS2013_BINX64)\link.exe
 
-  DEBUG_VS2013_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm
-RELEASE_VS2013_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2013_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
+  DEBUG_VS2013_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Gw
+RELEASE_VS2013_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Gw
+NOOPT_VS2013_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od /Gw
 
   DEBUG_VS2013_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2013_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
 NOOPT_VS2013_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 
@@ -3230,11 +3230,11 @@ NOOPT_VS2013_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2013_EBC_SLINK_PATH  = DEF(VS2013_BIN)\link.exe
 *_VS2013_EBC_DLINK_PATH  = DEF(VS2013_BIN)\link.exe
 
 *_VS2013_EBC_MAKE_FLAGS  = /nologo
 *_VS2013_EBC_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
-*_VS2013_EBC_CC_FLAGS= /nologo /c /WX /W3 /FIAutoGen.h 
/D$(MODULE_ENTRY_POINT)=$(ARCH_ENTRY_POINT)
+*_VS2013_EBC_CC_FLAGS= /nologo /c /WX /W3 /FIAutoGen.h 
/D$(MODULE_ENTRY_POINT)=$(ARCH_ENTRY_POINT) /Gw
 *_VS2013_EBC_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
 *_VS2013_EBC_SLINK_FLAGS = /lib /NOLOGO /MACHINE:EBC
 *_VS2013_EBC_DLINK_FLAGS = "C:\Program Files\Intel\EBC\Lib\EbcLib.lib" 
/NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF /ENTRY:$(IMAGE_ENTRY_POINT) 
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 /DRIVER
 
 
@@ -3285,13 +3285,13 @@ NOOPT_VS2013_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2013xASL_IA32_ASLCC_PATH= DEF(VS2013_BIN)\cl.exe
 *_VS2013xASL_IA32_ASLPP_PATH= DEF(VS2013_BIN)\cl.exe
 *_VS2013xASL_IA32_ASLDLINK_PATH = DEF(VS2013_BIN)\link.exe
 
   *_VS2013xASL_IA32_MAKE_FLAGS  = /nologo
-  DEBUG_VS2013xASL_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
-RELEASE_VS2013xASL_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- 

[edk2] [Patch 2/2] MdePkg: update Base.h in MdePkg to check the _MSC_VER

2017-06-13 Thread Yonghong Zhu
update Base.h in MdePkg to check the _MSC_VER and define
GLOBAL_REMOVE_IF_UNREFERENCED to nothing for VS2013 and higher tool
chain tags.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 MdePkg/Include/Base.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 5b311f6..21a603a 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -89,11 +89,11 @@ VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);
 //
 // The Microsoft* C compiler can removed references to unreferenced data items
 //  if the /OPT:REF linker option is used. We defined a macro as this is a
 //  a non standard extension
 //
-#if defined(_MSC_EXTENSIONS) && !defined (MDE_CPU_EBC)
+#if defined(_MSC_EXTENSIONS) && _MSC_VER < 1800 && !defined (MDE_CPU_EBC)
   ///
   /// Remove global variable from the linked image if there are no references 
to
   /// it after all compiler and linker optimizations have been performed.
   ///
   ///
-- 
2.6.1.windows.1

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


[edk2] [Patch 0/2] Add /Gw to CC_FLAGS for VS 2013 and higher tool chains

2017-06-13 Thread Yonghong Zhu
The /Gw flag does a better job at size optimization than use of the
GLOBAL_REMOVE_IF_UNREFERENCED macro that is currently used for VS20xx
tool chains to remove unreferenced global variables.

The recommendation is to add /Gw to CC_FLAGS for VS2013 and higher
tool chain tags and update Base.h in MdePkg to check the _MSC_VER
and define GLOBAL_REMOVE_IF_UNREFERENCED to nothing for VS2013 and
higher tool chain tags.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=583
Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 


Yonghong Zhu (2):
  BaseTools: add /Gw to CC_FLAGS for VS2013 and higher tool chain tags
  MdePkg: update Base.h in MdePkg to check the _MSC_VER

 BaseTools/Conf/tools_def.template | 110 +++---
 MdePkg/Include/Base.h |   2 +-
 2 files changed, 56 insertions(+), 56 deletions(-)

-- 
2.6.1.windows.1

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


Re: [edk2] [PATCH v2] EmbeddedPkg/MmcDxe: Add alignment for ECSD data

2017-06-13 Thread Jun Nie
2017-06-13 17:18 GMT+08:00 Leif Lindholm :
> On Tue, Jun 13, 2017 at 10:14:34AM +0800, Jun Nie wrote:
>> 2017-06-12 23:53 GMT+08:00 Leif Lindholm :
>> > On Mon, Jun 12, 2017 at 09:59:28AM +0800, Jun Nie wrote:
>> >> Add alignment for ECSD data for DMA access. Otherwise
>> >> the data is corrupted on Sanechips platform.
>> >
>> > I never did see a reply to my proposed solution, and the below is not
>> > it. Can you explain why you prefer this one?
>>
>> Sorry, just see your email because that thread is not highlighted for
>> new email in gmail for unknown reason.
>> I have concern that "UINT64 VENDOR_SPECIFIC_FIELD[8]" cannot secure
>> the ECSD alignment because it is not the first member.
>
> It being the first member or not has no relevance.
> By my count, it starts at offset 64, with all preceding entries being
> UINT8.

  Maybe you are right. I had have concern that if preceding member of ECSDData,
CSDData, is not 8 bytes aligned in the tail, UINT8 RESERVED_1[] may start from
non 8 bytes aligned address.

>
>> Changing the first member to "UINT64 RESERVED_1[2]" shall secure the
>> alignment.
>
> Relying on a reserved field for setting alignment constraints risks
> having to find an alternative method at some point in the future, so I
> agree this is not a preferred solution.
>
>> But I preferred Pad method. It is more readable if all ECSD member
>> are UINT8 type.
>
> I confess am not familiar enough with eMMC to make a clean call here,
> but if real alignment constrains exist, using UINT8 is actively
> misleading, not to mention incorrect. If there is no real alignment
> constraint, this is not the code that needs fixing.

512 bytes ECSD data may be read either by CPU or DMA via dedicated
 eMMC command. DMA may require alignment for the structure and
DMA on different SoC may require different alignment. Hikey DMA is
OK with 4 bytes alignment, while ZTE SoC require 8 bytes alignment.
And pad must not be added in the 512 bytes structure body by compiler.
So all members in ECSD are defined as UINT8 is safe.

>
>> It is also more clear to add alignment info in
>> CARD_INFO, just before ECSD member.
>
> Why is it more clear to apply alignment constraints at point of use
> instead of point of definition?

Adding alignment attribute in definition is best way for the constraint, but I
 do not know how to make all compilers happy, just like my version 1 patch.
It is more or less obscure to change VENDOR_SPECIFIC_FIELD or RESERVED_1
to type UINT64.

I confess that adding a pad before ECSD usage is compromised method. It
serve as a reminder for developers too, and allow all members of ECSD are
defined with UINT8.

Another method is to define ECSDData as a pointer and allocate buffer for it.
Which method do you prefer?

>
> Is there any chance you can share the EFI_MMC_HOST_PROTOCOL
> implementation that triggers this error?

DWMMC controller on ZTE/Sanchip SoC will read corrupted data with current
DwMmc driver in edk2 96boards git repo. I just add several small patches to
enable it on new SoC. I will send all these changes in near future. Or
what detail
information do you need? I can share it here.

Jun

>
> /
> Leif
>
>> I do not get point of Andrew, maybe he share the same concern.
>>
>> Jun
>>
>> >
>> >> Contributed-under: TianoCore Contribution Agreement 1.0
>> >> Signed-off-by: Jun Nie 
>> >> ---
>> >>  EmbeddedPkg/Universal/MmcDxe/Mmc.h | 1 +
>> >>  1 file changed, 1 insertion(+)
>> >>
>> >> diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.h 
>> >> b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
>> >> index 8a7d5a3..6e3ab17 100644
>> >> --- a/EmbeddedPkg/Universal/MmcDxe/Mmc.h
>> >> +++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
>> >> @@ -319,6 +319,7 @@ typedef struct  {
>> >>OCR   OCRData;
>> >>CID   CIDData;
>> >>CSD   CSDData;
>> >> +  UINT64Pad;  // For 8 bytes alignment 
>> >> of ECSDData
>> >>ECSD  ECSDData; // MMC V4 extended card 
>> >> specific
>> >>  } CARD_INFO;
>> >>
>> >> --
>> >> 1.9.1
>> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch V2] UefiCpuPkg/MpInitLib: Fix X64 XCODE5/NASM compatibility issues

2017-06-13 Thread Kinney, Michael D
hpa,

Use of esi is on purpose.  esi is the base address of a structure and 
it is consistently used as a 32-bit value in all 3 execution modes in
this file.

I agree we can remove the qword specifier as a cleaner style.

Also, as we consolidate on NASM sources, we can see if ASM_PFX() can be
dropped completely.  That would be another good clean up.

I also agree that the mov and call can be reduced to a single call 
instruction.  Another good cleanup.

There are many more NASM source files that need to be updated to be 
compatible with XCODE5 tool chain.  We are continuing to work on those
updates.

Thanks,

Mike


-Original Message-
From: H. Peter Anvin [mailto:h...@zytor.com] 
Sent: Tuesday, June 6, 2017 12:42 PM
To: Fan, Jeff ; Kinney, Michael D 
; edk2-devel@lists.01.org 
Cc: Andrew Fish 
Subject: Re: [edk2] [Patch V2] UefiCpuPkg/MpInitLib: Fix X64 XCODE5/NASM 
compatibility issues

On 05/22/17 19:08, Fan, Jeff wrote:
>  
> diff --git a/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm 
> b/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm
> index fa54d01..0b14a53 100644
> --- a/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm
> +++ b/UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm
> @@ -1,5 +1,5 @@
>  
> ;--
>  ; -; Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> +; Copyright (c) 2015 - 2017, Intel Corporation. All rights 
> +reserved.
>  ; This program and the accompanying materials  ; are licensed and made 
> available under the terms and conditions of the BSD License  ; which 
> accompanies this distribution.  The full text of the license may be found at 
> @@ -201,7 +201,7 @@ CProcedureInvoke:
>  push   rbp
>  movrbp, rsp
>  
> -movrax, ASM_PFX(InitializeFloatingPointUnits)
> +movrax, qword [esi + InitializeFloatingPointUnitsAddress]
>  subrsp, 20h
>  call   rax   ; Call assembly function to initialize FPU 
> per UEFI spec
>  addrsp, 20h

FYI, the qword specifier is unnecessary since you are already specifying
rax.

However, why not simply drop the use of rax entirely and do:

call [esi + InitializeFloatingPointUnitsAddress]

(Also: is this *really* supposed to be esi and not rsi?  The former
means a 32-bit address.)

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


Re: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

2017-06-13 Thread Kinney, Michael D
Hi Leif,

I pulled the latest versions of the repos and I was able to complete
a build with no errors and without using symbolic links.

The change I made is to set WORKSPACE to the directory immediately
above the repos and set PACKAGES_PATH to directories that contain the
packages required for the platform to build.

This is the same technique used to build QuarkPlatformPkg that uses
content from both the edk2 and the edk2-non-osi repos.  See the
Readme.md in the QuarkPlatformPkg with instructions for setting up
the build env for Linux and Windows for an example.

https://github.com/tianocore/edk2/tree/master/QuarkPlatformPkg

I wrote a small shell script that I put in the directory above the
repos to setup the build environment for the JunoPkg platform.

export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-

export WORKSPACE=$PWD

export PACKAGES_PATH=\
$WORKSPACE/edk2:\
$WORKSPACE/edk2-platforms/Platform/ARM:\
$WORKSPACE/edk2-non-osi

cd edk2
make -C BaseTools
. edksetup.sh BaseTools

build -a AARCH64 -t GCC5 -p JunoPkg/ArmJuno.dsc

=== end of build log ===
Generate Region at Offset 0x0
   Region Size = 0xF8000
   Region Name = FV

Generating FVMAIN_COMPACT FV

Generating FVMAIN FV





Generate Region at Offset 0x0
   Region Size = 0xF8000
   Region Name = FV

GUID cross reference file can be found at 
/home/mdkinney/GitHub/tianocore/Build/ArmJuno/DEBUG_GCC5/FV/Guid.xref

FV Space Information
FVMAIN_COMPACT [94%Full] 1015808 total, 956200 used, 59608 free
FVMAIN [99%Full] 8237696 total, 8237688 used, 8 free

- Done -
Build end time: 18:49:57, Jun.13 2017
Build total time: 00:04:22



If you want to support building any of the platforms, then
PACKAGES_PATH can be set as follows:

export PACKAGES_PATH=\
$WORKSPACE/edk2:\
$WORKSPACE/edk2-platforms/Silicon/Hisilicon:\
$WORKSPACE/edk2-platforms/Silicon/AMD:\
$WORKSPACE/edk2-platforms/Platform/Hisilicon:\
$WORKSPACE/edk2-platforms/Platform/Marvell:\
$WORKSPACE/edk2-platforms/Platform/ARM:\
$WORKSPACE/edk2-non-osi/Silicon/Intel:\
$WORKSPACE/edk2-non-osi/Silicon/AMD/Styx:

Best regards,

Mike

-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Wednesday, June 7, 2017 7:58 AM
To: Yao, Jiewen 
Cc: edk2-devel@lists.01.org; Ryan Harkin ; Ard 
Biesheuvel ; Chenhui Sun ; 
Andrew Fish ; Alan Ott ; Richardson, 
Brian ; Duran, Leo ; 
haojian.zhu...@linaro.org; Linaro UEFI ; Kinney, 
Michael D ; Heyi Guo 
Subject: Re: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

Hi all,

OK, so I have now updated both edk2-non-osi and edk2-platforms
(devel-OpenPlatformPkg branches) with package renaming, and updating
.dsc/.fdf files to . 

It appears the problems I'm facing are mainly caused by the GenFds
stage not seeing a view consistent with the actual compilation stage.

To demonstrate, I build the Juno platform:
$ . edksetup.sh
$ make -C BaseTools
$ PACKAGES_PATH=/work/git/edk2-platforms/Platform/ARM \
   GCC5_AARCH64_PREFIX=aarch64-linux-gnu- build -n 9 -a AARCH64 \
   -t GCC5 -p JunoPkg/ArmJuno.dsc -b RELEASE

This build fails with:
---
Fd File Name:BL33_AP_UEFI

Generate Region at Offset 0x0
   Region Size = 0xF8000
  Region Name = FV

Generating FVMAIN_COMPACT FV

Generating FVMAIN FV


GenFds.py...
 : error F003: Output file for RAW section could not be found for
 JunoPkg/AcpiTables/AcpiTables.inf



build.py...
 : error 7000: Failed to execute command
   GenFds -f /work/git/edk2-platforms/Platform/ARM/JunoPkg/ArmJuno.fdf
   --conf=/work/git/edk2/Conf -o
   /work/git/edk2/Build/ArmJuno/RELEASE_GCC5 -t GCC5 -b RELEASE -p
   /work/git/edk2-platforms/Platform/ARM/JunoPkg/ArmJuno.dsc -a
   AARCH64 -D "EFI_SOURCE=/work/git/edk2/EdkCompatibilityPkg" -D
   "EDK_SOURCE=/work/git/edk2/EdkCompatibilityPkg" -D
   "TOOL_CHAIN_TAG=GCC5" -D "TOOLCHAIN=GCC5" -D "TARGET=RELEASE" -D
   "FAMILY=GCC" -D "WORKSPACE=/work/git/edk2" -D
   "EDK_TOOLS_PATH=/work/git/edk2/BaseTools" -D "ARCH=AARCH64" -D
   "ECP_SOURCE=/work/git/edk2/EdkCompatibilityPkg" [/work/git/edk2]

- Failed -
---
, but if I add the symlink
ln -s edk2-platforms/Platform/ARM/JunoPkg/ Build/ArmJuno/RELEASE_GCC5/AARCH64/
it completes successfully on the next pass.

Same when building VExpressPkg/ArmVExpress-FVP-AArch64.dsc
ln -s edk2-platforms/Platform/ARM/VExpressPkg \
 Build/ArmVExpress-FVP-AArch64/RELEASE_GCC5/AARCH64/
resolves the build error.


Similarly, when I build the Overdrive/Overdrive.dsc, using:
$ 

[edk2] [edk2-CCodingStandardsSpecification] Create release/2.20 branch

2017-06-13 Thread Michael Kinney
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 book.json | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/book.json b/book.json
index 30ea7e0..39f6413 100644
--- a/book.json
+++ b/book.json
@@ -1,8 +1,7 @@
 {
   "variables" : {
-"draft"   : "yes",
 "title"   : "EDK II C Coding Standards Specification",
-"version" : "Revision 2.2"
+"version" : "Revision 2.20"
   },
 
   "plugins": ["puml"],
-- 
2.6.3.windows.1

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


[edk2] [PATCH] MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol

2017-06-13 Thread Amit Kumar
Modified source code to update Interface as per spec.
1) In case of Protocol is un-supported, interface should be returned NULL.
2) In case of any error, interface should not be modified.
3) In case of Test Protocol, interface is optional.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Amit Kumar 
---
 MdeModulePkg/Core/Dxe/Hand/Handle.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.c 
b/MdeModulePkg/Core/Dxe/Hand/Handle.c
index 1c25521..0afa86b 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Handle.c
+++ b/MdeModulePkg/Core/Dxe/Hand/Handle.c
@@ -1004,13 +1004,8 @@ CoreOpenProtocol (
   //
   // Check for invalid Interface
   //
-  if (Attributes != EFI_OPEN_PROTOCOL_TEST_PROTOCOL) {
-if (Interface == NULL) {
-  return EFI_INVALID_PARAMETER;
-} else {
-  *Interface = NULL;
-}
-  }
+  if ((Attributes != EFI_OPEN_PROTOCOL_TEST_PROTOCOL) && (Interface == NULL))
+return EFI_INVALID_PARAMETER;
 
   //
   // Check for invalid UserHandle
@@ -1073,15 +1068,11 @@ CoreOpenProtocol (
   Prot = CoreGetProtocolInterface (UserHandle, Protocol);
   if (Prot == NULL) {
 Status = EFI_UNSUPPORTED;
+// Return NULL Interface if Unsupported Protocal
+*Interface = NULL;
 goto Done;
   }
 
-  //
-  // This is the protocol interface entry for this protocol
-  //
-  if (Attributes != EFI_OPEN_PROTOCOL_TEST_PROTOCOL) {
-*Interface = Prot->Interface;
-  }
   Status = EFI_SUCCESS;
 
   ByDriver= FALSE;
@@ -1175,6 +1166,15 @@ CoreOpenProtocol (
   }
 
 Done:
+
+  //
+  // This is the protocol interface entry for this protocol.
+  // In case of any Error, Interface should not be updated as per spec.
+  //
+  if ((Attributes != EFI_OPEN_PROTOCOL_TEST_PROTOCOL)
+  && (Status == EFI_SUCCESS)) {
+*Interface = Prot->Interface;
+  }
   //
   // Done. Release the database lock are return
   //
-- 
1.9.1

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


Re: [edk2] HTTP Boot failed to download NBP file if it is .iso type

2017-06-13 Thread Santhapur Naveen
Hi Siyuan,

Thank you for your reply.
And regarding the OS installation, we are able to download SUSE iso (>3 GB) 
from the HTTP server. But the install didn't happen.
May I ask you what could be possible reason? Is there anything else I've had 
missed, please let me know.

Regards,
Naveen

-Original Message-
From: Fu, Siyuan [mailto:siyuan...@intel.com] 
Sent: Tuesday, June 13, 2017 8:17 AM
To: Santhapur Naveen; Karunakar P; edk2-devel@lists.01.org
Subject: RE: HTTP Boot failed to download NBP file if it is .iso type

Hi, Karunakar and Naveen

Status 0023 is EFI_HTTP_ERROR, which means the HTTP server replied an HTTP 
error. The HTTP error code is placed in 
HttpIo->RspToken.Message->Data.Response->StatusCode, and will be displayed in 
HttpBootPrintErrorMessage() function.

If a downloaded NBP is a RAM disk image, the BDS will try to find a boot file 
inside it according UEFI 2.7 section 3.5.1 "Boot via the Simple File Protocol".

Best Regards,
Siyuan


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Santhapur Naveen
Sent: Saturday, June 10, 2017 1:49 AM
To: Karunakar P; edk2-devel@lists.01.org
Subject: Re: [edk2] HTTP Boot failed to download NBP file if it is .iso type

Even if we are able to download an ISO file successfully, how will 
EFI_RAM_DISK_PROTOCOL comes to know what is the efi that needs to be used?

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Karunakar P
Sent: Friday, June 09, 2017 9:04 PM
To: edk2-devel@lists.01.org
Subject: [edk2] HTTP Boot failed to download NBP file if it is .iso type

Hi All,

We have facing an issue with HTTP boot.

[Issue]
HTTP Boot failed to download NBP file if it is an .iso type

[Reproduction Steps]

1.  Configure HTTP Server in Ubuntu environment.

2.  Place any iso image as NBP file.

3.  Perform UEFI HTTPv4 boot.

[Result]
DHCP process was success, But Failed to download NBP file.

[Observations]

1.  As per UEFI spec "23.7.1 Boot from URL" (UEFI 2.6, page 1222).

Here is what the section says about binary image returned by HTTP server:

"...the binary image [..] is a UEFI-formatted executable[...], or it could be 
mounted as a RAM disk which contains a UEFI-compliant file system (see Section 
12.3)."

We're interested in exploring second scenario, when downloaded image is a 
UEFI-compliant file system.

Section "23.7.3.1 Device Path" on page 1226 provides examples of image URL: 
http://192.168.1.100/boot.iso

The specification also says that "the HTTP Boot driver will register RAM disk 
with the downloaded NBP, by appending a RamDisk device node to the device path 
above, like...".



HttpBootDxe is doing this.But NBP file itself failing to download in the case 
of iso image.



2.  HTTP boot fails in the following function



HttpBootGetBootFile() ->



EFI_STATUS

HttpBootGetBootFile (

  IN HTTP_BOOT_PRIVATE_DATA   *Private,

  IN BOOLEAN  HeaderOnly,

  IN OUT UINTN*BufferSize,

 OUT UINT8*Buffer,

 OUT HTTP_BOOT_IMAGE_TYPE *ImageType

  )

{

.

.

.

 Status = HttpIoRecvResponse (

 >HttpIo,

 TRUE,

 ResponseData

 );

// Here the Status value is Success and ResponseData->Status = 0023



  if (EFI_ERROR (Status) || EFI_ERROR (ResponseData->Status)) {

if (EFI_ERROR (ResponseData->Status)) {

  StatusCode = HttpIo->RspToken.Message->Data.Response->StatusCode;

  HttpBootPrintErrorMessage (StatusCode);

  Status = ResponseData->Status;

// Here Status = 0023



}

goto ERROR_5;// goto ERROR_5

  }

.

.

.

}



Note:
We have HTTP server configured in Ubuntu Environment.

Could you please look into it.


Thanks,
karunakar


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
This e-mail is intended for the use of the addressee only and may contain 
privileged, confidential, or proprietary information that is exempt from 
disclosure under law. If you have received this message in error, please inform 
us promptly by reply e-mail, then delete the e-mail and destroy any printed 
copy. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2] EmbeddedPkg/MmcDxe: Add alignment for ECSD data

2017-06-13 Thread Leif Lindholm
On Tue, Jun 13, 2017 at 10:14:34AM +0800, Jun Nie wrote:
> 2017-06-12 23:53 GMT+08:00 Leif Lindholm :
> > On Mon, Jun 12, 2017 at 09:59:28AM +0800, Jun Nie wrote:
> >> Add alignment for ECSD data for DMA access. Otherwise
> >> the data is corrupted on Sanechips platform.
> >
> > I never did see a reply to my proposed solution, and the below is not
> > it. Can you explain why you prefer this one?
> 
> Sorry, just see your email because that thread is not highlighted for
> new email in gmail for unknown reason.
> I have concern that "UINT64 VENDOR_SPECIFIC_FIELD[8]" cannot secure
> the ECSD alignment because it is not the first member.

It being the first member or not has no relevance.
By my count, it starts at offset 64, with all preceding entries being
UINT8.

> Changing the first member to "UINT64 RESERVED_1[2]" shall secure the
> alignment.

Relying on a reserved field for setting alignment constraints risks
having to find an alternative method at some point in the future, so I
agree this is not a preferred solution.

> But I preferred Pad method. It is more readable if all ECSD member
> are UINT8 type.

I confess am not familiar enough with eMMC to make a clean call here,
but if real alignment constrains exist, using UINT8 is actively
misleading, not to mention incorrect. If there is no real alignment
constraint, this is not the code that needs fixing.

> It is also more clear to add alignment info in
> CARD_INFO, just before ECSD member.

Why is it more clear to apply alignment constraints at point of use
instead of point of definition?

Is there any chance you can share the EFI_MMC_HOST_PROTOCOL
implementation that triggers this error?

/
Leif

> I do not get point of Andrew, maybe he share the same concern.
> 
> Jun
> 
> >
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Jun Nie 
> >> ---
> >>  EmbeddedPkg/Universal/MmcDxe/Mmc.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.h 
> >> b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> >> index 8a7d5a3..6e3ab17 100644
> >> --- a/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> >> +++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> >> @@ -319,6 +319,7 @@ typedef struct  {
> >>OCR   OCRData;
> >>CID   CIDData;
> >>CSD   CSDData;
> >> +  UINT64Pad;  // For 8 bytes alignment of 
> >> ECSDData
> >>ECSD  ECSDData; // MMC V4 extended card 
> >> specific
> >>  } CARD_INFO;
> >>
> >> --
> >> 1.9.1
> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH V2] UefiCpuPkg/SmmCpuFeatureLib: Add more CPU ID for SmmFeatureControl.

2017-06-13 Thread Fan, Jeff
Reviewed-by: Jeff Fan 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen 
Yao
Sent: Tuesday, June 13, 2017 2:44 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D; Fan, Jeff
Subject: [edk2] [PATCH V2] UefiCpuPkg/SmmCpuFeatureLib: Add more CPU ID for 
SmmFeatureControl.

Add more CPU ID which can support SmmFeatureControl, according to IA32 SDM.

Cc: Jeff Fan 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 079baa4..2d2bc6d 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -296,7 +296,9 @@ SmmCpuFeaturesInitializeProcessor (
   // Intel(R) Core(TM) Processor Family MSRs.
   //
   if (FamilyId == 0x06) {
-if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46) {
+if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46 ||
+ModelId == 0x3D || ModelId == 0x47 || ModelId == 0x4E || ModelId == 
0x4F ||
+ModelId == 0x3F || ModelId == 0x56 || ModelId == 0x57 || 
+ ModelId == 0x5C) {
   //
   // Check to see if the CPU supports the SMM Code Access Check feature
   // Do not access this MSR unless the CPU supports the 
SmmRegFeatureControl
--
2.7.4.windows.1

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


[edk2] [PATCH V2] UefiCpuPkg/SmmCpuFeatureLib: Add more CPU ID for SmmFeatureControl.

2017-06-13 Thread Jiewen Yao
Add more CPU ID which can support SmmFeatureControl,
according to IA32 SDM.

Cc: Jeff Fan 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 079baa4..2d2bc6d 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -296,7 +296,9 @@ SmmCpuFeaturesInitializeProcessor (
   // Intel(R) Core(TM) Processor Family MSRs.
   //
   if (FamilyId == 0x06) {
-if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46) {
+if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46 ||
+ModelId == 0x3D || ModelId == 0x47 || ModelId == 0x4E || ModelId == 
0x4F ||
+ModelId == 0x3F || ModelId == 0x56 || ModelId == 0x57 || ModelId == 
0x5C) {
   //
   // Check to see if the CPU supports the SMM Code Access Check feature
   // Do not access this MSR unless the CPU supports the 
SmmRegFeatureControl
-- 
2.7.4.windows.1

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


Re: [edk2] [PATCH] UefiCpuPkg/SmmCpuFeatureLib: Add more CPU ID for SmmFeatureControl.

2017-06-13 Thread Yao, Jiewen
Sure, I will send V2 patch soon.

> -Original Message-
> From: Fan, Jeff
> Sent: Tuesday, June 13, 2017 1:32 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: RE: [PATCH] UefiCpuPkg/SmmCpuFeatureLib: Add more CPU ID for
> SmmFeatureControl.
> 
> Jiewen,
> 
> Besides you added ModelId, we still have the following ModelId support SMM
> Code Access Check feature in IA32 SDM.
> 
> Processor:  ModelId
> Goldmont  0x5C
> HaswellE0x3F
> XeonD   0x4F, 0x56
> XeonPhi0x57
> 
> Could you also add them into your patch?
> 
> Thank!
> Jeff
> 
> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, June 12, 2017 10:14 AM
> To: edk2-devel@lists.01.org
> Cc: Fan, Jeff; Kinney, Michael D
> Subject: [PATCH] UefiCpuPkg/SmmCpuFeatureLib: Add more CPU ID for
> SmmFeatureControl.
> 
> Add more CPU ID which can support SmmFeatureControl, according to IA32 SDM.
> 
> Cc: Jeff Fan 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> index 079baa4..b0c442e 100644
> --- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> @@ -296,7 +296,8 @@ SmmCpuFeaturesInitializeProcessor (
>// Intel(R) Core(TM) Processor Family MSRs.
>//
>if (FamilyId == 0x06) {
> -if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46) {
> +if (ModelId == 0x3C || ModelId == 0x45 || ModelId == 0x46 ||
> +ModelId == 0x3D || ModelId == 0x47 || ModelId == 0x4E ||
> + ModelId == 0x4F) {
>//
>// Check to see if the CPU supports the SMM Code Access Check feature
>// Do not access this MSR unless the CPU supports the
> SmmRegFeatureControl
> --
> 2.7.4.windows.1

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


Re: [edk2] [Patch 0/2] Typo fix and comments correction

2017-06-13 Thread Fu, Siyuan
Reviewed-by: Fu Siyuan 

-Original Message-
From: Wu, Jiaxin 
Sent: Tuesday, June 13, 2017 2:03 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin
Subject: [Patch 0/2] Typo fix and comments correction

warter -> water
Maunual -> Manual
TCP and UDP --> TCP4 and TCP6
TCP or UDP --> TCP4 or TCP6

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 

Jiaxin Wu (2):
  MdeModulePkg/Network: Typo fix
  NetworkPkg: Typo fix and comments correction

 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c |  4 ++--
 MdeModulePkg/Universal/Network/Tcp4Dxe/Socket.h|  6 +++---
 NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c  |  6 +++---
 NetworkPkg/TcpDxe/Socket.h | 10 +-
 4 files changed, 13 insertions(+), 13 deletions(-)

-- 
1.9.5.msysgit.1

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


[edk2] [Patch 0/2] Typo fix and comments correction

2017-06-13 Thread Jiaxin Wu
warter -> water
Maunual -> Manual
TCP and UDP --> TCP4 and TCP6
TCP or UDP --> TCP4 or TCP6

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 

Jiaxin Wu (2):
  MdeModulePkg/Network: Typo fix
  NetworkPkg: Typo fix and comments correction

 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c |  4 ++--
 MdeModulePkg/Universal/Network/Tcp4Dxe/Socket.h|  6 +++---
 NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c  |  6 +++---
 NetworkPkg/TcpDxe/Socket.h | 10 +-
 4 files changed, 13 insertions(+), 13 deletions(-)

-- 
1.9.5.msysgit.1

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


[edk2] [Patch 1/2] MdeModulePkg/Network: Typo fix

2017-06-13 Thread Jiaxin Wu
warter -> water
Maunual -> Manual

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 4 ++--
 MdeModulePkg/Universal/Network/Tcp4Dxe/Socket.h| 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index f4dfbb6..3e38085 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -1226,11 +1226,11 @@ Ip4Config2SetPolicy (
   @retval EFI_SUCCESS   The specified configuration data for the EFI 
IPv6
 network stack was set.
 
 **/
 EFI_STATUS
-Ip4Config2SetMaunualAddress (
+Ip4Config2SetManualAddress (
   IN IP4_CONFIG2_INSTANCE *Instance,
   IN UINTNDataSize,
   IN VOID *Data
   )
 {
@@ -1926,11 +1926,11 @@ Ip4Config2InitInstance (
   DataItem->DataSize = sizeof (Instance->Policy);
   Instance->Policy   = Ip4Config2PolicyStatic;
   SET_DATA_ATTRIB (DataItem->Attribute, DATA_ATTRIB_SIZE_FIXED);
 
   DataItem   = >DataItem[Ip4Config2DataTypeManualAddress];
-  DataItem->SetData  = Ip4Config2SetMaunualAddress;
+  DataItem->SetData  = Ip4Config2SetManualAddress;
   DataItem->Status   = EFI_NOT_FOUND;
 
   DataItem   = >DataItem[Ip4Config2DataTypeGateway];
   DataItem->SetData  = Ip4Config2SetGateway;
   DataItem->Status   = EFI_NOT_FOUND;
diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/Socket.h 
b/MdeModulePkg/Universal/Network/Tcp4Dxe/Socket.h
index 8c25c63..9c2e6d0 100644
--- a/MdeModulePkg/Universal/Network/Tcp4Dxe/Socket.h
+++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/Socket.h
@@ -371,11 +371,11 @@ typedef enum {
 ///
 ///  The buffer structure of rcvd data and send data used by socket.
 ///
 typedef struct _SOCK_BUFFER {
   UINT32HighWater;  ///< The buffersize upper limit of sock_buffer
-  UINT32LowWater;   ///< The low warter mark of sock_buffer
+  UINT32LowWater;   ///< The low water mark of sock_buffer
   NET_BUF_QUEUE *DataQueue; ///< The queue to buffer data
 } SOCK_BUFFER;
 
 /**
   The handler of protocol for request from socket.
@@ -591,12 +591,12 @@ typedef struct _SOCK_INIT_DATA {
   SOCK_TYPE   Type;
   UINT8   State;
 
   SOCKET  *Parent;///< The parent of this socket
   UINT32  BackLog;///< The connection limit for listening socket
-  UINT32  SndBufferSize;  ///< The high warter mark of send buffer
-  UINT32  RcvBufferSize;  ///< The high warter mark of receive buffer
+  UINT32  SndBufferSize;  ///< The high water mark of send buffer
+  UINT32  RcvBufferSize;  ///< The high water mark of receive buffer
   VOID*Protocol;  ///< The pointer to protocol function template
   ///< wanted to install on socket
 
   //
   // Callbacks after socket is created and before socket is to be destroyed.
-- 
1.9.5.msysgit.1

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


[edk2] [Patch 2/2] NetworkPkg: Typo fix and comments correction

2017-06-13 Thread Jiaxin Wu
warter -> water
Maunual -> Manual
TCP and UDP --> TCP4 and TCP6
TCP or UDP --> TCP4 or TCP6

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c |  6 +++---
 NetworkPkg/TcpDxe/Socket.h| 10 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c 
b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
index 7575b79..7c7acc7 100644
--- a/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
+++ b/NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c
@@ -754,11 +754,11 @@ Ip6ConfigSetDadXmits (
 }
 
 /**
   The callback function for Ip6SetAddr. The prototype is defined
   as IP6_DAD_CALLBACK. It is called after Duplicate Address Detection is 
performed
-  for the manual address set by Ip6ConfigSetMaunualAddress.
+  for the manual address set by Ip6ConfigSetManualAddress.
 
   @param[in] IsDadPassed   If TRUE, Duplicate Address Detection passed.
   @param[in] TargetAddress The tentative IPv6 address to be checked.
   @param[in] Context   Pointer to the IP6 configuration instance data.
 
@@ -894,11 +894,11 @@ Ip6ManualAddrDadCallback (
   @retval EFI_SUCCESS   The specified configuration data for the EFI 
IPv6
 network stack was set.
 
 **/
 EFI_STATUS
-Ip6ConfigSetMaunualAddress (
+Ip6ConfigSetManualAddress (
   IN IP6_CONFIG_INSTANCE  *Instance,
   IN UINTNDataSize,
   IN VOID *Data
   )
 {
@@ -2216,11 +2216,11 @@ Ip6ConfigInitInstance (
   DataItem->DataSize = sizeof (Instance->DadXmits);
   Instance->DadXmits.DupAddrDetectTransmits = IP6_CONFIG_DEFAULT_DAD_XMITS;
   SET_DATA_ATTRIB (DataItem->Attribute, DATA_ATTRIB_SIZE_FIXED);
 
   DataItem   = >DataItem[Ip6ConfigDataTypeManualAddress];
-  DataItem->SetData  = Ip6ConfigSetMaunualAddress;
+  DataItem->SetData  = Ip6ConfigSetManualAddress;
   DataItem->Status   = EFI_NOT_FOUND;
 
   DataItem   = >DataItem[Ip6ConfigDataTypeGateway];
   DataItem->SetData  = Ip6ConfigSetGateway;
   DataItem->Status   = EFI_NOT_FOUND;
diff --git a/NetworkPkg/TcpDxe/Socket.h b/NetworkPkg/TcpDxe/Socket.h
index 371e9ab..f7f4a7a 100644
--- a/NetworkPkg/TcpDxe/Socket.h
+++ b/NetworkPkg/TcpDxe/Socket.h
@@ -359,11 +359,11 @@ typedef enum {
 ///
 ///  The buffer structure of rcvd data and send data used by socket.
 ///
 typedef struct _SOCK_BUFFER {
   UINT32HighWater;  ///< The buffersize upper limit of sock_buffer
-  UINT32LowWater;   ///< The low warter mark of sock_buffer
+  UINT32LowWater;   ///< The low water mark of sock_buffer
   NET_BUF_QUEUE *DataQueue; ///< The queue to buffer data
 } SOCK_BUFFER;
 
 /**
   The handler of protocol for request from socket.
@@ -423,12 +423,12 @@ typedef struct _SOCK_INIT_DATA {
   SOCK_TYPE  Type;
   UINT8  State;
 
   SOCKET *Parent;///< The parent of this socket
   UINT32 BackLog;///< The connection limit for 
listening socket
-  UINT32 SndBufferSize;  ///< The high warter mark of send 
buffer
-  UINT32 RcvBufferSize;  ///< The high warter mark of receive 
buffer
+  UINT32 SndBufferSize;  ///< The high water mark of send 
buffer
+  UINT32 RcvBufferSize;  ///< The high water mark of receive 
buffer
   UINT8  IpVersion;
   VOID   *Protocol;  ///< The pointer to protocol function 
template
  ///< wanted to install on socket
 
   //
@@ -448,11 +448,11 @@ typedef struct _SOCK_INIT_DATA {
 
   EFI_HANDLE DriverBinding;   ///< The driver binding handle
 } SOCK_INIT_DATA;
 
 ///
-///  The union type of TCP and UDP protocol.
+///  The union type of TCP4 and TCP6 protocol.
 ///
 typedef union _NET_PROTOCOL {
   EFI_TCP4_PROTOCOL  Tcp4Protocol;///< Tcp4 protocol
   EFI_TCP6_PROTOCOL  Tcp6Protocol;///< Tcp6 protocol
 } NET_PROTOCOL;
@@ -500,11 +500,11 @@ struct _TCP_SOCKET {
   // Interface for low level protocol
   //
   SOCK_PROTO_HANDLERProtoHandler; ///< The request handler of 
protocol
   UINT8 ProtoReserved[PROTO_RESERVED_LEN];  ///< Data 
fields reserved for protocol
   UINT8 IpVersion;
-  NET_PROTOCOL  NetProtocol;///< TCP or 
UDP protocol socket used
+  NET_PROTOCOL  NetProtocol;///< TCP4 or 
TCP6 protocol socket used
   //
   // Callbacks after socket is created and before socket is to be destroyed.
   //
   SOCK_CREATE_CALLBACK  CreateCallback;   ///< Callback after created
   SOCK_DESTROY_CALLBACK DestroyCallback;  ///< Callback before destroied
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org