[edk2] [Patch 1/2] BaseTools: add /Gw to CC_FLAGS for VS2013 and higher tool chain tags
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 GaoContributed-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
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 GaoContributed-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
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 KinneyCc: 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 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
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
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, JiewenCc: 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
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
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
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
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.
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.
Add more CPU ID which can support SmmFeatureControl, according to IA32 SDM. Cc: Jeff FanCc: 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.
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
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
warter -> water Maunual -> Manual TCP and UDP --> TCP4 and TCP6 TCP or UDP --> TCP4 or TCP6 Cc: Ye TingCc: 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
warter -> water Maunual -> Manual Cc: Ye TingCc: 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
warter -> water Maunual -> Manual TCP and UDP --> TCP4 and TCP6 TCP or UDP --> TCP4 or TCP6 Cc: Ye TingCc: 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