[edk2] [PATCH V2] UefiCpuPkg/CpuCommonFeaturesLib: Aesni.c uses BIT0 and BIT1 reversedly
V2: Correct description "disable(0)/enable(1)" to "disable(1)/enable(0)". BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1621 According to Intel SDM as below, the BIT0 should be treated as lock bit, and BIT1 should be treated as disable(1)/enable(0) bit. "11b: AES instructions are not available until next RESET. Otherwise, AES instructions are available. If the configuration is not 01b, AES instructions can be mis-configured if a privileged agent unintentionally writes 11b" Cc: Laszlo Ersek Cc: Eric Dong Cc: Ruiyu Ni Cc: Chandana Kumar Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng --- UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c index 56b1b551d977..3f7c933e51f4 100644 --- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c +++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c @@ -1,7 +1,7 @@ /** @file AESNI feature. - Copyright (c) 2017, Intel Corporation. All rights reserved. + Copyright (c) 2017 - 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 @@ -123,7 +123,7 @@ AesniInitialize ( MSR_SANDY_BRIDGE_FEATURE_CONFIG, MSR_SANDY_BRIDGE_FEATURE_CONFIG_REGISTER, Bits.AESConfiguration, -BIT1 | ((State) ? 0 : BIT0) +BIT0 | ((State) ? 0 : BIT1) ); } } -- 2.21.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
> On Mar 13, 2019, at 1:16 PM, Brian J. Johnson wrote: > > On 3/12/19 12:28 PM, Andrew Fish via edk2-devel wrote: >>> On Mar 12, 2019, at 10:05 AM, Laszlo Ersek wrote: >>> >>> Hello Heyi, >>> >>> On 03/12/19 07:56, Heyi Guo wrote: Hi Laszlo, I'm thinking about a proposal as below: 1. Reuse the framework of MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf 2. The boot time behavior of this module is not changed 3. Switch to status code protocol for runtime debug 4. Use an overridden SerialPortLib instance for StatusCodeHandlerRuntimeDxe; the instance must support runtime access. Then we can have below benefits: 1. the boot time firmware log, and the OS log, went to one port; and there is no dependence for runtime drivers to output serial message at boot time. 2. By implementing different instances of SerialPortLib for StatusCodeHandlerRuntimeDxe, we can have enough flexibility to direct runtime serial message to platform specific serial port. >>> >>> This looks a bit over-engineered to me. Ultimately our goal is: >>> - for DEBUGs to reach "a" serial port at runtime -- namely one that >>> differs from the "normal" serial port. >>> >>> Given that you'd have to implement a "special" SerialPortLib instance >>> just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps: >>> >>> (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e., >>> stick universally with BaseDebugLibSerialPort, for DebugLib, >>> >>> (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both >>> (a) runtime behavior and (b) handling of a special serial port? >>> >>> In other words, push down the "runtime?" distinction from DebugLib (see >>> commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance >>> would be used only with DXE_RUNTIME_DRIVERs. >>> >>> The lib instance would prepare everything in advance for accessing the >>> "special" serial port at runtime (which could require allocating runtime >>> memory in advance). Once ExitBootServices() is called, a callback should >>> switch over the behavior of the lib instance, without allocating further >>> memory. (The switched-over behavior would not have to be functional >>> until the virtual address map is set.) >>> >> Laszlo, >> Runtime does not quite work like that. As soon as the Set Virtual Address >> map fires it is only legal to call things EFI RT from the virtual mapping. >> The last stage of the Set Virtual Address Map call is to reapply the fixups >> in the Runtime Drivers for the virtual address space. That means any >> absolute address reference in the code now points to the virtual address. >> Also the Set Virtual Address event told the Runtime Driver to convert all >> its pointers to point to the new virtual address space. >> The blackout and the fact you need to hide the hardware from the OS make >> doing things at EFI Runtime Time hard. >> I agree with you that since our logging is really just a serial stream we >> don't require Report Status Code. Report Status Code exists so that the old >> PC POST Cards could still be supported, see: >> https://en.wikipedia.org/wiki/Power-on_self-test#Error_reporting. There is >> also a Report Status Code layer that allows redirecting the stream to >> multiple agents, so for example you could send data to port 80 (POST Card) >> and write out the same values in the serial stream. I find lookup up Report >> Status Code codes very tedious and not really helpful for debugging vs. >> DEBUG prints. >> Thanks, >> Andrew Fish > > Andrew, wasn't Report Status Code also intended to reduce code size? > PeiDxeDebugLibReportStatusCode packages up DEBUG() arguments into a structure > and passes it to the status code handler. It avoids having to link a > PrintLib and SerialPortLib instance into essentially every module. At least > that was the intent... IIRC at some point a few years ago folks realized that > VA_LIST wasn't portable across compilers, so now > PeiDxeDebugLibReportStatusCode converts VA_LIST into BASE_LIST, which > requires parsing the format string much like PrintLib does. No idea if that > actually results in a space savings over BaseDebugLibSerialPort, especially > for really simple SerialPortLib instances. > Brian, Good point about size. We are just talking about runtime drivers, and they are likely all compressed so it would be interesting to know the impact. > +1 for the difficulty of decoding Report Status Code codes... there has to be > a better way to do that than manually parsing through PiStatusCode.h and > friends. > I seem to remember there was some code that shortened it to a post code so the common codes ended up being a byte. But it seems like post processing tools would be useful. Thanks, Andrew Fish > Brian Johnson > >>> I've always seen status code reporting cumbersome in comparison to plain >>> DEBUG
[edk2] [PATCH] UefiCpuPkg/CpuCommonFeaturesLib: Aesni.c uses BIT0 and BIT1 reversedly
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1621 According to Intel SDM as below, the BIT0 should be treated as lock bit, and BIT1 should be treated as disable(0)/enable(1) bit. "11b: AES instructions are not available until next RESET. Otherwise, AES instructions are available. If the configuration is not 01b, AES instructions can be mis-configured if a privileged agent unintentionally writes 11b" Cc: Laszlo Ersek Cc: Eric Dong Cc: Ruiyu Ni Cc: Chandana Kumar Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng --- UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c index 56b1b551d977..3f7c933e51f4 100644 --- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c +++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Aesni.c @@ -1,7 +1,7 @@ /** @file AESNI feature. - Copyright (c) 2017, Intel Corporation. All rights reserved. + Copyright (c) 2017 - 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 @@ -123,7 +123,7 @@ AesniInitialize ( MSR_SANDY_BRIDGE_FEATURE_CONFIG, MSR_SANDY_BRIDGE_FEATURE_CONFIG_REGISTER, Bits.AESConfiguration, -BIT1 | ((State) ? 0 : BIT0) +BIT0 | ((State) ? 0 : BIT1) ); } } -- 2.21.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] BaseTool/Build: Add --disable-include-path-check.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1620
This option is added to disable the include path check
for outside of package.
The original purpose of thie check is to make sure EDK II
modules must not reference header files outside of the packages
they depend on or within the module's directory tree.
However, we do see the usage to build EDKII as executable running
in the operating system which requires include path to outside.
For example, EmulatorPkg. The current solution (soft link) is
weird hack - EmulatorPkg\Unix\Host\X11IncludeHack.
With this solution, this can be supported easily.
The patch is validated with and without --disable-include-path-check.
If user does not use --disable-include-path-check, the build will fail
with outside path in the include path.
If user uses --disable-include-path-check, the build will pass
with outside path in the include path.
Cc: Bob Feng
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 15 ---
BaseTools/Source/Python/build/build.py | 2 ++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index e7dbf66e2f..568d535754 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3037,13 +3037,14 @@ class ModuleAutoGen(AutoGen):
# EDK II modules must not reference header files outside of the
packages they depend on or
# within the module's directory tree. Report error if violation.
#
-for Path in IncPathList:
-if (Path not in self.IncludePathList) and (CommonPath([Path,
self.MetaFile.Dir]) != self.MetaFile.Dir):
-ErrMsg = "The include directory for the EDK II module in
this line is invalid %s specified in %s FLAGS '%s'" % (Path, Tool, FlagOption)
-EdkLogger.error("build",
-PARAMETER_INVALID,
-ExtraData=ErrMsg,
-File=str(self.MetaFile))
+if GlobalData.gDisableIncludePathCheck == False:
+for Path in IncPathList:
+if (Path not in self.IncludePathList) and
(CommonPath([Path, self.MetaFile.Dir]) != self.MetaFile.Dir):
+ErrMsg = "The include directory for the EDK II module
in this line is invalid %s specified in %s FLAGS '%s'" % (Path, Tool,
FlagOption)
+EdkLogger.error("build",
+PARAMETER_INVALID,
+ExtraData=ErrMsg,
+File=str(self.MetaFile))
RetVal += IncPathList
return RetVal
diff --git a/BaseTools/Source/Python/build/build.py
b/BaseTools/Source/Python/build/build.py
index 99e79d4dca..de641fb452 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -719,6 +719,7 @@ class Build():
GlobalData.gBinCacheDest = BuildOptions.BinCacheDest
GlobalData.gBinCacheSource = BuildOptions.BinCacheSource
GlobalData.gEnableGenfdsMultiThread = BuildOptions.GenfdsMultiThread
+GlobalData.gDisableIncludePathCheck =
BuildOptions.DisableIncludePathCheck
if GlobalData.gBinCacheDest and not GlobalData.gUseHashCache:
EdkLogger.error("build", OPTION_NOT_SUPPORTED,
ExtraData="--binary-destination must be used together with --hash.")
@@ -2268,6 +2269,7 @@ def MyOptionParser():
Parser.add_option("--binary-destination", action="store", type="string",
dest="BinCacheDest", help="Generate a cache of binary files in the specified
directory.")
Parser.add_option("--binary-source", action="store", type="string",
dest="BinCacheSource", help="Consume a cache of binary files from the specified
directory.")
Parser.add_option("--genfds-multi-thread", action="store_true",
dest="GenfdsMultiThread", default=False, help="Enable GenFds multi thread to
generate ffs file.")
+Parser.add_option("--disable-include-path-check", action="store_true",
dest="DisableIncludePathCheck", default=False, help="Disable the include path
check for outside of package.")
(Opt, Args) = Parser.parse_args()
return (Opt, Args)
--
2.19.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
On 3/12/19 12:28 PM, Andrew Fish via edk2-devel wrote: On Mar 12, 2019, at 10:05 AM, Laszlo Ersek wrote: Hello Heyi, On 03/12/19 07:56, Heyi Guo wrote: Hi Laszlo, I'm thinking about a proposal as below: 1. Reuse the framework of MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf 2. The boot time behavior of this module is not changed 3. Switch to status code protocol for runtime debug 4. Use an overridden SerialPortLib instance for StatusCodeHandlerRuntimeDxe; the instance must support runtime access. Then we can have below benefits: 1. the boot time firmware log, and the OS log, went to one port; and there is no dependence for runtime drivers to output serial message at boot time. 2. By implementing different instances of SerialPortLib for StatusCodeHandlerRuntimeDxe, we can have enough flexibility to direct runtime serial message to platform specific serial port. This looks a bit over-engineered to me. Ultimately our goal is: - for DEBUGs to reach "a" serial port at runtime -- namely one that differs from the "normal" serial port. Given that you'd have to implement a "special" SerialPortLib instance just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps: (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e., stick universally with BaseDebugLibSerialPort, for DebugLib, (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both (a) runtime behavior and (b) handling of a special serial port? In other words, push down the "runtime?" distinction from DebugLib (see commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance would be used only with DXE_RUNTIME_DRIVERs. The lib instance would prepare everything in advance for accessing the "special" serial port at runtime (which could require allocating runtime memory in advance). Once ExitBootServices() is called, a callback should switch over the behavior of the lib instance, without allocating further memory. (The switched-over behavior would not have to be functional until the virtual address map is set.) Laszlo, Runtime does not quite work like that. As soon as the Set Virtual Address map fires it is only legal to call things EFI RT from the virtual mapping. The last stage of the Set Virtual Address Map call is to reapply the fixups in the Runtime Drivers for the virtual address space. That means any absolute address reference in the code now points to the virtual address. Also the Set Virtual Address event told the Runtime Driver to convert all its pointers to point to the new virtual address space. The blackout and the fact you need to hide the hardware from the OS make doing things at EFI Runtime Time hard. I agree with you that since our logging is really just a serial stream we don't require Report Status Code. Report Status Code exists so that the old PC POST Cards could still be supported, see: https://en.wikipedia.org/wiki/Power-on_self-test#Error_reporting. There is also a Report Status Code layer that allows redirecting the stream to multiple agents, so for example you could send data to port 80 (POST Card) and write out the same values in the serial stream. I find lookup up Report Status Code codes very tedious and not really helpful for debugging vs. DEBUG prints. Thanks, Andrew Fish Andrew, wasn't Report Status Code also intended to reduce code size? PeiDxeDebugLibReportStatusCode packages up DEBUG() arguments into a structure and passes it to the status code handler. It avoids having to link a PrintLib and SerialPortLib instance into essentially every module. At least that was the intent... IIRC at some point a few years ago folks realized that VA_LIST wasn't portable across compilers, so now PeiDxeDebugLibReportStatusCode converts VA_LIST into BASE_LIST, which requires parsing the format string much like PrintLib does. No idea if that actually results in a space savings over BaseDebugLibSerialPort, especially for really simple SerialPortLib instances. +1 for the difficulty of decoding Report Status Code codes... there has to be a better way to do that than manually parsing through PiStatusCode.h and friends. Brian Johnson I've always seen status code reporting cumbersome in comparison to plain DEBUG messages. My understanding is that status code reporting targets devices that are even dumber than serial ports. But, we do target a second serial port. So if we can keep the switchover internal to the SerialPortLib class, at least for runtime DXE drivers, then I think we should do that. Thanks, Laszlo On 2019/3/1 23:27, Laszlo Ersek wrote: +Peter, for the last few paragraphs On 02/28/19 13:10, Ard Biesheuvel wrote: On Thu, 28 Feb 2019 at 09:06, Heyi Guo wrote: Serial port output is useful when debugging UEFI runtime services in OS runtime. The patches are trying to provide a handy method to enable runtime serial port debug for ArmVirtQemu. Cc: Jian J Wang Cc: Hao Wu Cc: Laszlo Ersek Cc: Ard Biesheuvel
[edk2] PATCH] Change EDK II to BSD+Patent License
Hello, BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1373 This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html I have posted the patch series for review on the following branch using edk2-stable201903 as the base for the patch series. https://github.com/mdkinney/edk2/tree/Bug_1373_BsdPatentLicense The commits in patch series can be viewed here: https://github.com/mdkinney/edk2/commits/Bug_1373_BsdPatentLicense The patch series has one patch per package along with a few patches to update the license information in the root of the edk2 repository as described in the RFC V2. Due to the size of the patch series, I prefer to not send the patch emails. Instead, please perform code reviews using content from the branch. All EDK II package maintainers and package reviewers should provide review feedback for their packages. The critical part of the review is: 1) Any changes that cause build breaks or logic changes. These code changes are intended to only modify license contents in comment blocks. 2) Any file that has been changed to BSD+Patent, but should remain with the current license. 3) Any file that that has not changed to BSD+Patent, but should be changed to BSD+Patent. Feedback and Reviewed-by emails should identify the patch the feedback applies using the patch summary listed below. The goal is to complete all reviews to support the commit of these patches on April 9, 2019. 84141eacac edk2: Remove Contributions.txt and update Readme.md 93b121ee79 StdLibPrivateInternalFiles: Replace BSD License with BSD+Patent License 91a1d41ccb StdLib: Replace BSD License with BSD+Patent License a71c378242 AppPkg: Replace BSD License with BSD+Patent License 4eb2592e65 Vlv2TbltDevicePkg: Replace BSD License with BSD+Patent License 7b719f9c0a Vlv2DeviceRefCodePkg: Replace BSD License with BSD+Patent License 1472567223 UefiCpuPkg: Replace BSD License with BSD+Patent License 3001241ef7 StandaloneMmPkg: Replace BSD License with BSD+Patent License e5dddf6e52 SourceLevelDebugPkg: Replace BSD License with BSD+Patent License e83800c47a SignedCapsulePkg: Replace BSD License with BSD+Patent License 3a58ac55fd ShellPkg: Replace BSD License with BSD+Patent License b16c29f4d9 ShellBinPkg: Replace BSD License with BSD+Patent License bf4838b342 SecurityPkg: Replace BSD License with BSD+Patent License 2da66fa9f1 QuarkSocPkg: Replace BSD License with BSD+Patent License f52f862821 QuarkPlatformPkg: Replace BSD License with BSD+Patent License 571f6e2af1 PcAtChipsetPkg: Replace BSD License with BSD+Patent License 837a3425bf OvmfPkg: Replace BSD License with BSD+Patent License d548789dff OptionRomPkg: Replace BSD License with BSD+Patent License 88cbe4e446 Omap35xxPkg: Replace BSD License with BSD+Patent License 452a4e54da Nt32Pkg: Replace BSD License with BSD+Patent License 41704de255 NetworkPkg: Replace BSD License with BSD+Patent License 07716613d3 MdePkg: Replace BSD License with BSD+Patent License bfd7b0e6aa MdeModulePkg: Replace BSD License with BSD+Patent License 9d991b5dff IntelSiliconPkg: Replace BSD License with BSD+Patent License 6c2833f076 IntelFspWrapperPkg: Replace BSD License with BSD+Patent License c679ff1058 IntelFspPkg: Replace BSD License with BSD+Patent License 8623e16830 IntelFsp2WrapperPkg: Replace BSD License with BSD+Patent License 40e4b295f8 IntelFsp2Pkg: Replace BSD License with BSD+Patent License 36ea637247 IntelFrameworkPkg: Replace BSD License with BSD+Patent License 0c6f14fb2f IntelFrameworkModulePkg: Replace BSD License with BSD+Patent License 79ea5a27b9 FmpDevicePkg: Replace BSD License with BSD+Patent License a8e09bbdac FatPkg: Replace BSD License with BSD+Patent License 81322a8327 EmulatorPkg: Replace BSD License with BSD+Patent License 88e68e0fbc EmbeddedPkg: Replace BSD License with BSD+Patent License c3176994e5 EdkCompatibilityPkg: Replace BSD License with BSD+Patent License 06bca42822 DynamicTablesPkg: Replace BSD License with BSD+Patent License 5bdb990eb2 CryptoPkg: Replace BSD License with BSD+Patent License 40472d5724 CorebootPayloadPkg: Replace BSD License with BSD+Patent License a87f66c6a6 CorebootModulePkg: Replace BSD License with BSD+Patent License 18a480540a BeagleBoardPkg: Replace BSD License with BSD+Patent License 908d82c3fd ArmVirtPkg: Replace BSD License with BSD+Patent License 4eb0a6b673 ArmPlatformPkg: Replace BSD License with BSD+Patent License a376999cfd ArmPkg: Replace BSD License with BSD+Patent License 20b76852bb BaseTools: Replace BSD License with BSD+Patent License 15cfa51d6f edk2: Replace BSD License with BSD+Patent License 75c4e96f35 edk2: Change License.txt from 2-Clause BSD to BSD+Patent 1daf0f13e1 edk2: Add License-History.txt
Re: [edk2] F29 Build Issue.
Andrew, This looks like a newer warning added in GCC 8 -Wall? BaseTools/Source/C/GenVtf/GenVtf.h:46:#define FIT_SIGNATURE "_FIT_ " So it looks like the intent is to copy the 8 chars in the string, but not the NULL. That is the intent of -Werror=stringop-truncation. I think this code needs to replace strncpy with memcpy. Please file a bugzilla: https://bugzilla.tianocore.org Thanks, Andrew Fish > On Mar 13, 2019, at 6:27 AM, Andrew J. Hutton > wrote: > > Unsure if this is a missing build dependency (since there doesn't appear to > be a check for this) am I missing a make dep or configure step somewhere? > > This is stock F29, following the website instructions; the make -C > BaseTools/Source/C results in the following errror: > > make[1]: Entering directory > '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' > cc -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror > -Wno-deprecated-declarations -nostdlib -c -g -I .. -I ../Include/Common -I > ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I > ../Include/X64/ GenVtf.c -o GenVtf.o > GenVtf.c: In function ‘CreateFitTableAndInitialize’: > GenVtf.c:1473:3: error: ‘strncpy’ output truncated before terminating nul > copying 8 bytes from a string of the same length [-Werror=stringop-truncation] >strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8); // > "_FIT_ " >^~~ > cc1: all warnings being treated as errors > make[1]: *** [../Makefiles/footer.makefile:27: GenVtf.o] Error 1 > make[1]: Leaving directory > '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' > make: *** [GNUmakefile:73: GenVtf] Error 2 > make: Leaving directory '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C' > > ___ > 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] F29 Build Issue.
Hi, GenVtf is removed from EDK2, since it's IPF specific and no longer used. Commit 64ab2c82e8f61e881eb16849e1b188361b00c4a7 deleted it from the upstream tree, so if you don't need IPF support, you can just remove this tool. Richard On Wed, 2019-03-13 at 09:27 -0400, Andrew J. Hutton wrote: > Unsure if this is a missing build dependency (since there doesn't > appear > to be a check for this) am I missing a make dep or configure step > somewhere? > > This is stock F29, following the website instructions; the make -C > BaseTools/Source/C results in the following errror: > > make[1]: Entering directory > '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' > cc -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror > -Wno-deprecated-declarations -nostdlib -c -g -I .. -I > ../Include/Common > -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I > . > -I ../Include/X64/ GenVtf.c -o GenVtf.o > GenVtf.c: In function ‘CreateFitTableAndInitialize’: > GenVtf.c:1473:3: error: ‘strncpy’ output truncated before > terminating > nul copying 8 bytes from a string of the same length > [-Werror=stringop-truncation] > strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8); > // > "_FIT_ " > ^~~ > cc1: all warnings being treated as errors > make[1]: *** [../Makefiles/footer.makefile:27: GenVtf.o] Error 1 > make[1]: Leaving directory > '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' > make: *** [GNUmakefile:73: GenVtf] Error 2 > make: Leaving directory > '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C' > > ___ > 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] F29 Build Issue.
Unsure if this is a missing build dependency (since there doesn't appear to be a check for this) am I missing a make dep or configure step somewhere? This is stock F29, following the website instructions; the make -C BaseTools/Source/C results in the following errror: make[1]: Entering directory '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' cc -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -nostdlib -c -g -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/ GenVtf.c -o GenVtf.o GenVtf.c: In function ‘CreateFitTableAndInitialize’: GenVtf.c:1473:3: error: ‘strncpy’ output truncated before terminating nul copying 8 bytes from a string of the same length [-Werror=stringop-truncation] strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8); // "_FIT_ " ^~~ cc1: all warnings being treated as errors make[1]: *** [../Makefiles/footer.makefile:27: GenVtf.o] Error 1 make[1]: Leaving directory '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' make: *** [GNUmakefile:73: GenVtf] Error 2 make: Leaving directory '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C' ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 0/2] Platforms/ARM/SgiPkg: apply product names for sgiclarka and sgiclarkh platforms
hi Ard/Leif
Please let me know if you have any comments on this patch
thanks
Jagadeesh
On Tue, Mar 5, 2019 at 12:20 PM Jagadeesh Ujja wrote:
>
> This patchset updates the product names for SGI-Clark.Ares and
> SGI-Clark.Helios platforms.
> The first patch replaces all uses of sgiclarka with rdn1edge.
> The second patch replaces all use of sgiclarkh with rde1edge.
>
> Jagadeesh Ujja (2):
> Platforms/ARM/SgiPkg: Rename SgiClarkAres to RdN1Edge
> Platforms/ARM/SgiPkg: Rename SgiClarkHelios to RdE1Edge
>
> Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Dsdt.asl
>| 66 ++--
> Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Madt.aslc
>| 0
> Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHeliosAcpiTables.inf =>
> RdE1EdgeAcpiTables.inf} | 6 +-
> Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Dsdt.asl
>| 16 ++---
> Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Madt.aslc
>| 16 ++---
> Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAresAcpiTables.inf =>
> RdN1EdgeAcpiTables.inf} | 6 +-
> Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
>| 12 ++--
> Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
>| 4 +-
> Platform/ARM/SgiPkg/Include/SgiPlatform.h
>| 8 +--
> Platform/ARM/SgiPkg/SgiPlatform.dec
>| 4 +-
> Platform/ARM/SgiPkg/SgiPlatform.dsc
>| 4 +-
> Platform/ARM/SgiPkg/SgiPlatform.fdf
>| 4 +-
> 12 files changed, 73 insertions(+), 73 deletions(-)
> rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Dsdt.asl
> (68%)
> rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHelios => RdE1Edge}/Madt.aslc
> (100%)
> rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkHeliosAcpiTables.inf =>
> RdE1EdgeAcpiTables.inf} (91%)
> rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Dsdt.asl
> (85%)
> rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAres => RdN1Edge}/Madt.aslc
> (93%)
> rename Platform/ARM/SgiPkg/AcpiTables/{SgiClarkAresAcpiTables.inf =>
> RdN1EdgeAcpiTables.inf} (92%)
>
> --
> 2.7.4
>
>
> ___
> 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] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer.
Hi Laszlo, This change is not incompatible with CSM feature. It just make the max address not directly than without CSM solution. We just add comments to claim solution can be enhanced when CSM is retired. Thanks, Eric > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, March 8, 2019 1:40 AM > To: Dong, Eric ; Zeng, Star ; > edk2-devel@lists.01.org > Cc: Ni, Ray ; David Woodhouse > Subject: Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for > Wake up Buffer. > > On 03/07/19 03:53, Dong, Eric wrote: > > Hi Star, > > > > This logic seems much complicated than mine. Also after CSM retired from > EDKII, we will change this code back to only require allocate buffer below 1M. > I will add such notes in the code comments. So I prefer to use my change. > > I apologize for my inability to follow the recent developments in this thread. > However, what I recall is that we may not retire the CSM from > edk2 entirely. Instead, if someone volunteers to maintain the CSM under > OvmfPkg for example, then we'll keep it there. > > Personally I'm not interested in the CSM, but it would be nice if we didn't > implement logic in UefiCpuPkg that would be, by design, incompatible with > an optional feature that we might carry forward in OvmfPkg. > > Thanks > Laszlo > > > Thanks, > > Eric > > > >> -Original Message- > >> From: Zeng, Star > >> Sent: Tuesday, March 5, 2019 3:33 PM > >> To: Dong, Eric ; edk2-devel@lists.01.org > >> Cc: Ni, Ray ; Laszlo Ersek (ler...@redhat.com) > >> ; Zeng, Star > >> Subject: RE: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate > >> buffer for Wake up Buffer. > >> > >> Just an idea to avoid hard code value 0x88000. > >> > >> Before EndOfDxe: Allocate buffer in AllocateResetVector(), and free > >> buffer in FreeResetVector(). > >> At EndOfDxe (it is after LegacyBiosDxe driver entry point) callback: > >> Allocate buffer and record it to CpuMpData->WakeupBuffer, and always > >> occupy the buffer, that means no free. > >> After EndOfDxe: Use CpuMpData->WakeupBuffer. > >> > >> > >> Thanks, > >> Star > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > >> Of Eric Dong > >> Sent: Tuesday, March 5, 2019 10:07 AM > >> To: edk2-devel@lists.01.org > >> Subject: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer > >> for Wake up Buffer. > >> > >> https://bugzilla.tianocore.org/show_bug.cgi?id=1538 > >> > >> Current CpuDxe driver "borrows" Wakeup Buffer (through Allocate & > >> free to get the buffer pointer, backup the buffer data before using > >> it and restore it after using). Now this logic met a problem > >> described in the above BZ because the test tool and the CpuDxe both > >> use the same memory at the same time. > >> > >> In order to fix the above issue, CpuDxe changed to allocate the > >> buffer below 1M instead of borrow it. After investigation, we found > >> below > >> 0x88000 is the possible space which can be used. For now, range > >> 0x6 ~ 0x88000 used for Legacy OPROMs by LegacyBios driver. And it > >> tries to allocate these range page(4K size) by page. It just reports > >> warning message if specific page been used by others already. > >> > >> Also CpuDxe driver will produce CPU arch protocol and LegacyBios > >> driver has dependency for this protocol. So CpuDxe driver will start > >> before LegacyBios driver and CpuDxe driver can allocate that space > successful. > >> > >> With this change, CpuDxe driver will use 0x87000 ~ 0x88000 as wakeup > buffer. > >> > >> Cc: Ray Ni > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Eric Dong > >> --- > >> UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 30 +++- > --- > >> --- > >> 1 file changed, 19 insertions(+), 11 deletions(-) > >> > >> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > >> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > >> index b2307cbb61..5bc9a47efb 100644 > >> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > >> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > >> @@ -76,7 +76,7 @@ SaveCpuMpData ( > >> } > >> > >> /** > >> - Get available system memory below 1MB by specified size. > >> + Get available system memory below 0x88000 by specified size. > >> > >>@param[in] WakeupBufferSize Wakeup buffer size required > >> > >> @@ -91,7 +91,19 @@ GetWakeupBuffer ( > >>EFI_STATUS Status; > >>EFI_PHYSICAL_ADDRESSStartAddress; > >> > >> - StartAddress = BASE_1MB; > >> + // > >> + // Current "Borrow" space mechanism caused potential race > >> + condition if both // AP and the original owner use the share space. > >> + // > >> + // LegacyBios driver tries to allocate 4K pages between 0x6 ~ > >> + 0x88000 // space. It will just report an waring message if the > >> + page has been allocate // by other drivers. > >> + // LagacyBios driver depends on CPU Arch protocol, so it will > >> + start after //
