Re: [edk2] TFTP failed with large blocksize
Hi, One more addition, on further analysis i can see packet is been received by my underlying hardware (DPAA/PCIe) 6 times (default retry count). Please let me know how can I check at what stage packet is been discarded by uefi framework. Thanks, Meenakshi -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Meenakshi Aggarwal Sent: Thursday, July 13, 2017 11:58 AM To: edk2-devel@lists.01.org Subject: [edk2] TFTP failed with large blocksize [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Hi All, I am working on an ARM based SoC (AARCH64). When I perform tftp form UEFI shell with blocksize 1024 then it succeeds for filesize (~500MB) Tftp -s 1024 iI eth3 192.168.3.161 Image But if I give blocksize greater than 1024 says 9000 then it results in timeout. Tftp -s 9000 -i eth3 192.168.3.161 Image This blocksize of 9000 works fine for small sized files like 34MB. I tried to analyze the tcpdump on tftp server side and it shows server didn't receive ACK for the packet it sent. I checked the function which is sending ACK (Mtftp4RrqInput-> Mtftp4RrqHandleData (send Ack)), control didn't come here for the last(last sent packet for which ACK not received by server) packet. Now I am wondering if Packet is been received by client or not. Also UEFI spec mentioned that if you face packet drop then try calling poll function from your device. I am not able to understand how I can do this? Also how I can change the polling period? Please provide some debug points on same. Thanks, Meenakshi ___ 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 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in XIP code
XIP code may execute with the MMU off, in which case all memory accesses should be strictly aligned to their size. Some versions of GCC violate this restriction even when -mstrict-align is passed, when performing loads and stores that involve SIMD registers. This is clearly a bug in the compiler, but we can easily work around it by avoiding SIMD registers altogether when building code that may execute in such a context. So add -mgeneral-regs-only to the AARCH64 XIP CC flags. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 128da5131d01..cdc9df44d97d 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4342,7 +4342,7 @@ DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-m DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -fno-pic -fno-pie DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie -ffixed-x18 -DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align +DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_DLINK2_FLAGS_COMMON = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections -- 2.9.3 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/2] BaseTools/tools_def AARCH64: mark register x18 as reserved
The AArch64 ABI classifies register x18 as a platform register, which means it should not be used unless the code is guaranteed to run on a platform that doesn't use it in such a capacity. GCC does not honour this requirement by default, and so we need to tell it not to touch it explicitly, by passing the -ffixed-x18 command line option. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=625 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 7d3f54218461..128da5131d01 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4341,7 +4341,7 @@ DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-ad DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -fno-pic -fno-pie DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie -ffixed-x18 DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_DLINK2_FLAGS_COMMON = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds -- 2.9.3 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Edk2] issue in clearing the contents of input queues.
Hello all, I'm currently working on a tool in which I am required to clear the contents of input queues. I tried EFI_SIMPLE_TEXT_INPUT_PROTOCOL Reset(), but not succeeded. Please help me out. Thanks, Atul ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] BaseTools/tools_def AARCH64: mark register x18 as reserved
On Thu, Jul 13, 2017 at 01:48:43PM +0100, Ard Biesheuvel wrote: > The AArch64 ABI classifies register x18 as a platform register, which > means it should not be used unless the code is guaranteed to run on a > platform that doesn't use it in such a capacity. > > GCC does not honour this requirement by default, and so we need to tell > it not to touch it explicitly, by passing the -ffixed-x18 command line > option. > > Link: https://bugzilla.tianocore.org/show_bug.cgi?id=625 > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > BaseTools/Conf/tools_def.template | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index 7d3f54218461..128da5131d01 100755 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -4341,7 +4341,7 @@ DEFINE GCC_X64_CC_FLAGS= > DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-ad > DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) > -minline-int-divide-min-latency > DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections > -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft > -fno-pic -fno-pie > DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access > -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections > -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie > +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections > -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic > -fno-pie -ffixed-x18 > DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align > DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie > DEFINE GCC_DLINK2_FLAGS_COMMON = > -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds > -- > 2.9.3 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in XIP code
On Thu, Jul 13, 2017 at 01:48:44PM +0100, Ard Biesheuvel wrote: > XIP code may execute with the MMU off, in which case all memory accesses > should be strictly aligned to their size. Some versions of GCC violate > this restriction even when -mstrict-align is passed, when performing > loads and stores that involve SIMD registers. This is clearly a bug in > the compiler, but we can easily work around it by avoiding SIMD registers > altogether when building code that may execute in such a context. So add > -mgeneral-regs-only to the AARCH64 XIP CC flags. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > BaseTools/Conf/tools_def.template | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index 128da5131d01..cdc9df44d97d 100755 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -4342,7 +4342,7 @@ DEFINE GCC_IPF_CC_FLAGS= > DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-m > DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections > -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft > -fno-pic -fno-pie > DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access > DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections > -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic > -fno-pie -ffixed-x18 > -DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align > +DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only > DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie > DEFINE GCC_DLINK2_FLAGS_COMMON = > -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds > DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) > --gc-sections > -- > 2.9.3 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Multi board support.
Cleanup libraries for multi boards.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: zwei4
---
.../BensonGlacier/BoardInitDxe/BoardInitDxe.h | 4 +-
.../BensonGlacier/BoardInitPostMem/BoardGpios.c| 72 +--
.../BensonGlacier/BoardInitPostMem/BoardGpios.h| 22 +++---
.../BensonGlacier/BoardInitPostMem/BoardInit.c | 2 +-
.../BensonGlacier/BoardInitPostMem/BoardInit.h | 6 +-
.../BoardInitPostMem/BoardInitMiscs.c | 24 +++
.../BoardInitPostMem/BoardInitMiscs.h | 18 ++---
.../BoardInitPostMem/PlatformInfoHob.c | 4 +-
.../BensonGlacier/BoardInitPreMem/BoardInit.c | 6 +-
.../BensonGlacier/BoardInitPreMem/BoardInit.h | 6 +-
.../BensonGlacier/BoardInitPreMem/BoardInitMiscs.h | 6 +-
.../BensonGlacier/BoardInitPreMem/PlatformId.c | 8 +--
.../BensonGlacier/BoardInitPreMem/PlatformId.h | 18 ++---
.../Board/LeafHill/BoardInitDxe/BoardInitDxe.h | 4 +-
.../Board/LeafHill/BoardInitPostMem/BoardGpios.c | 80 +++---
.../Board/LeafHill/BoardInitPostMem/BoardGpios.h | 32 -
.../Board/LeafHill/BoardInitPostMem/BoardInit.c| 2 +-
.../Board/LeafHill/BoardInitPostMem/BoardInit.h| 6 +-
.../LeafHill/BoardInitPostMem/BoardInitMiscs.c | 22 +++---
.../LeafHill/BoardInitPostMem/BoardInitMiscs.h | 16 ++---
.../LeafHill/BoardInitPostMem/PlatformInfoHob.c| 2 +-
.../Board/LeafHill/BoardInitPreMem/BoardInit.c | 6 +-
.../Board/LeafHill/BoardInitPreMem/BoardInit.h | 6 +-
.../LeafHill/BoardInitPreMem/BoardInitMiscs.h | 4 +-
.../Board/LeafHill/BoardInitPreMem/PlatformId.c| 4 +-
.../Board/LeafHill/BoardInitPreMem/PlatformId.h| 18 ++---
.../Board/MinnowBoard3/BoardInitDxe/BoardInitDxe.h | 4 +-
.../MinnowBoard3/BoardInitPostMem/BoardGpios.c | 70 +--
.../MinnowBoard3/BoardInitPostMem/BoardGpios.h | 22 +++---
.../MinnowBoard3/BoardInitPostMem/BoardInit.c | 2 +-
.../MinnowBoard3/BoardInitPostMem/BoardInit.h | 6 +-
.../MinnowBoard3/BoardInitPostMem/BoardInitMiscs.c | 22 +++---
.../MinnowBoard3/BoardInitPostMem/BoardInitMiscs.h | 18 ++---
.../BoardInitPostMem/PlatformInfoHob.c | 4 +-
.../Board/MinnowBoard3/BoardInitPreMem/BoardInit.c | 8 +--
.../Board/MinnowBoard3/BoardInitPreMem/BoardInit.h | 6 +-
.../MinnowBoard3/BoardInitPreMem/BoardInitMiscs.h | 6 +-
.../MinnowBoard3/BoardInitPreMem/PlatformId.c | 8 +--
.../MinnowBoard3/BoardInitPreMem/PlatformId.h | 20 +++---
39 files changed, 297 insertions(+), 297 deletions(-)
diff --git
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitDxe/BoardInitDxe.h
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitDxe/BoardInitDxe.h
index e8f2aa3f0..e7ba1d255 100644
---
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitDxe/BoardInitDxe.h
+++
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitDxe/BoardInitDxe.h
@@ -14,8 +14,8 @@
**/
-#ifndef __BOARD_INIT_DXE_H__
-#define __BOARD_INIT_DXE_H__
+#ifndef __BENSON_BOARD_INIT_DXE_H__
+#define __BENSON_BOARD_INIT_DXE_H__
#include
#include
diff --git
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.c
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.c
index eef62d9fa..df11c8bbd 100644
---
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.c
+++
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.c
@@ -13,7 +13,7 @@
**/
-#include
+#include "BoardGpios.h"
#include
#include
@@ -30,12 +30,12 @@
**/
EFI_STATUS
-MultiPlatformGpioTableInit (
+BensonMultiPlatformGpioTableInit (
IN CONST EFI_PEI_SERVICES **PeiServices,
IN EFI_PLATFORM_INFO_HOB *PlatformInfoHob
)
{
- DEBUG ((DEBUG_INFO, "MultiPlatformGpioTableInit()...\n"));
+ DEBUG ((DEBUG_INFO, "BensonMultiPlatformGpioTableInit()...\n"));
DEBUG ((DEBUG_INFO, "PlatformInfoHob->BoardId: 0x%02X\n",
PlatformInfoHob->BoardId));
//
@@ -45,16 +45,16 @@ MultiPlatformGpioTableInit (
case BOARD_ID_LFH_CRB:
case BOARD_ID_MINNOW:
case BOARD_ID_BENSON:
- PlatformInfoHob->PlatformGpioSetting_SW = &mBXT_GpioInitData_SW[0];
- PlatformInfoHob->PlatformGpioSetting_W = &mBXT_GpioInitData_W[0];
- PlatformInfoHob->PlatformGpioSetting_NW = &mBXT_GpioInitData_NW[0];
- PlatformInfoHob->PlatformGpioSetting_N = &mBXT_GpioInitData_N[0];
+ PlatformInfoHob->PlatformGpioSetting_SW = &mBenson_GpioInitData_SW[0];
+ PlatformInfoHob->PlatformGpioSetting_W = &mBenson_GpioInitData_W[0];
+ PlatformInfoHob->PlatformGpioSetting_NW = &mBenson_GpioInitData_NW[0];
+ PlatformInfoHob->PlatformGpioSetting_N = &mBenson_GpioInitData_N[0];
break;
default:
- PlatformInfoHob->PlatformGpioSetting_SW = &mBXT_GpioInitData_SW[0];
- PlatformInfoHob->PlatformGpioSetting_W = &mBXT_GpioInitData_W[0];
- Platf
Re: [edk2] [PATCH 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in XIP code
On 13 July 2017 at 17:15, Alexei Fedorov wrote: > Hi, > > I've tried the patch & it turns out that options provided with > > DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only > > aren't picked when building library code with SIMD load/store instructions > still being generated. > > Please see the attached assembly generated file for > edk2\MdePkg\Library\UefiLib\UefiLibPrint.c. > What is wrong with SIMD registers being used in UefiLibPrint? The report was about code that runs with the MMU off, right? ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] How to use a VGA adapter
Hello, I'm using the UDK2015 release and I want to enable the Graphic Output on a PCI VGA adapter (PCI class code: 3, 0, 0). My VGA device doesn't provide any ROM. In my FDF I've included the VgaMiniPortDxe and the VgaClassDxe. I haven't enabled the CSM layer. When my board boots the screen doesn't display anything. The PCI device is enumerated (device found with pci command on the EFI shell). Must I include another EFI driver to activate and/or initialize the VGA adapter or are these 2 drivers sufficient to enable the VGA display? Can I use the VGA without the CSM layer? Note: the display had already worked with a GOP driver on an AMD GPU. Is it possible to enable the GOP layer with the VGA layer? Regards. Cédric ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in XIP code
On 13 July 2017 at 17:56, Alexei Fedorov wrote:
> I'm getting
>
>
> UEFI firmware (version built at 16:34:57 on Jul 13 2017)
> Synchronous Exception at 0xF5451338
> :
>
> EL2:0xF5451338 : LDR q0,[x9,x0]
> EL2:0xF545133C : ADD x1,x1,#1
> EL2:0xF5451340 : CMP x7,x1
> EL2:0xF5451344 : STR q0,[x2,x0]
> EL2:0xF5451348 : ADD x0,x0,#0x10
> EL2:0xF545134C : B.HI {pc}-0x14 ; 0xf5451338
> ...
>
> with X0=0 & X9 = 0x0BFD0008 (Flash memory) in AlignedCopyMem()
> function
>
> (edk2\ArmPlatformPkg\Drivers\NorFlashDxe\NorFlashDxe.c):
>
>
> // r:\edk2\ArmPlatformPkg\Drivers\NorFlashDxe\NorFlashDxe.c:784:
> *Destination64++ = *Source64++;
> .loc 10 784 0
> ldrq0, [x9, x0]// MEM[base: vectp.229_593, index:
> ivtmp.349_1117, offset: 0B], MEM[base: vectp.229_593, index: ivtmp.349_1117,
> offset: 0B]
> addx1, x1, 1// ivtmp_603, ivtmp_603,
> cmpx7, x1// bnd.223, ivtmp_603
> strq0, [x2, x0]// MEM[base: vectp.229_593, index:
> ivtmp.349_1117, offset: 0B], MEM[base: vectp_Buffer.232_598, index:
> ivtmp.349_1117, offset: 0B]
> addx0, x0, 16// ivtmp.349, ivtmp.349,
> bhi.L200//,
>
>
> Despite compiler option -mgeneral-regs-only:
>
> // -mfix-cortex-a53-835769 -mfix-cortex-a53-843419 -mgeneral-regs-only
> // -mlittle-endian -mpc-relative-literal-loads -mstrict-align
> (see attached assembly generated file)
>
That is the same compiler bug at work, I think. So we need to add
-mgeneral-regs-only for this module as well.
Perhaps we should simply set it globally? Leif?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in XIP code
-mgeneral-regs-only is already there:
See the top of generated .S file:
.arch armv8-a
.file""
// GNU GIMPLE (Linaro GCC 7.1-2017.05) version 7.1.1 20170510 (aarch64-elf)
//compiled by GNU C version 4.8.2, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version none
// GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
// options passed: -mlittle-endian -mcmodel=tiny -march=armv8-a -mabi=lp64
// -mstrict-align -mgeneral-regs-only -mlittle-endian -mcmodel=tiny
// -march=armv8-a -mabi=lp64
// -auxbase-strip ArmVeNorFlashDxe.dll.ltrans0.ltrans.o -g -g -O3 -O3 -Os
// -Os -O3 -Wno-lto-type-mismatch -Wno-array-bounds
From: Ard Biesheuvel
Sent: 13 July 2017 18:00:43
To: Alexei Fedorov
Cc: Leif Lindholm; edk2-devel@lists.01.org; liming@intel.com;
yonghong@intel.com; Evan Lloyd
Subject: Re: [PATCH 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in
XIP code
On 13 July 2017 at 17:56, Alexei Fedorov wrote:
> I'm getting
>
>
> UEFI firmware (version built at 16:34:57 on Jul 13 2017)
> Synchronous Exception at 0xF5451338
> :
>
> EL2:0xF5451338 : LDR q0,[x9,x0]
> EL2:0xF545133C : ADD x1,x1,#1
> EL2:0xF5451340 : CMP x7,x1
> EL2:0xF5451344 : STR q0,[x2,x0]
> EL2:0xF5451348 : ADD x0,x0,#0x10
> EL2:0xF545134C : B.HI {pc}-0x14 ; 0xf5451338
> ...
>
> with X0=0 & X9 = 0x0BFD0008 (Flash memory) in AlignedCopyMem()
> function
>
> (edk2\ArmPlatformPkg\Drivers\NorFlashDxe\NorFlashDxe.c):
>
>
> // r:\edk2\ArmPlatformPkg\Drivers\NorFlashDxe\NorFlashDxe.c:784:
> *Destination64++ = *Source64++;
> .loc 10 784 0
> ldrq0, [x9, x0]// MEM[base: vectp.229_593, index:
> ivtmp.349_1117, offset: 0B], MEM[base: vectp.229_593, index: ivtmp.349_1117,
> offset: 0B]
> addx1, x1, 1// ivtmp_603, ivtmp_603,
> cmpx7, x1// bnd.223, ivtmp_603
> strq0, [x2, x0]// MEM[base: vectp.229_593, index:
> ivtmp.349_1117, offset: 0B], MEM[base: vectp_Buffer.232_598, index:
> ivtmp.349_1117, offset: 0B]
> addx0, x0, 16// ivtmp.349, ivtmp.349,
> bhi.L200//,
>
>
> Despite compiler option -mgeneral-regs-only:
>
> // -mfix-cortex-a53-835769 -mfix-cortex-a53-843419 -mgeneral-regs-only
> // -mlittle-endian -mpc-relative-literal-loads -mstrict-align
> (see attached assembly generated file)
>
That is the same compiler bug at work, I think. So we need to add
-mgeneral-regs-only for this module as well.
Perhaps we should simply set it globally? Leif?
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in XIP code
How are you ending up with all of those -O3?
Are they hardwired in the toolchain?
Are you adding that manually?
Can you see if the issue is reproducible with aarch64-linux-gnu, which
will have a configuration matching more closely what we tend to use?
(Not as a solution, just looking for a workaround better than "don't
build with GCC7.)
/
Leif
On Thu, Jul 13, 2017 at 05:06:43PM +, Alexei Fedorov wrote:
> -mgeneral-regs-only is already there:
>
> See the top of generated .S file:
>
>
> .arch armv8-a
> .file""
> // GNU GIMPLE (Linaro GCC 7.1-2017.05) version 7.1.1 20170510 (aarch64-elf)
> //compiled by GNU C version 4.8.2, GMP version 6.1.2, MPFR version 3.1.5,
> MPC version 1.0.3, isl version none
> // GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> // options passed: -mlittle-endian -mcmodel=tiny -march=armv8-a -mabi=lp64
> // -mstrict-align -mgeneral-regs-only -mlittle-endian -mcmodel=tiny
> // -march=armv8-a -mabi=lp64
> // -auxbase-strip ArmVeNorFlashDxe.dll.ltrans0.ltrans.o -g -g -O3 -O3 -Os
> // -Os -O3 -Wno-lto-type-mismatch -Wno-array-bounds
>
>
>
> From: Ard Biesheuvel
> Sent: 13 July 2017 18:00:43
> To: Alexei Fedorov
> Cc: Leif Lindholm; edk2-devel@lists.01.org; liming@intel.com;
> yonghong@intel.com; Evan Lloyd
> Subject: Re: [PATCH 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in
> XIP code
>
> On 13 July 2017 at 17:56, Alexei Fedorov wrote:
> > I'm getting
> >
> >
> > UEFI firmware (version built at 16:34:57 on Jul 13 2017)
> > Synchronous Exception at 0xF5451338
> > :
> >
> > EL2:0xF5451338 : LDR q0,[x9,x0]
> > EL2:0xF545133C : ADD x1,x1,#1
> > EL2:0xF5451340 : CMP x7,x1
> > EL2:0xF5451344 : STR q0,[x2,x0]
> > EL2:0xF5451348 : ADD x0,x0,#0x10
> > EL2:0xF545134C : B.HI {pc}-0x14 ; 0xf5451338
> > ...
> >
> > with X0=0 & X9 = 0x0BFD0008 (Flash memory) in AlignedCopyMem()
> > function
> >
> > (edk2\ArmPlatformPkg\Drivers\NorFlashDxe\NorFlashDxe.c):
> >
> >
> > // r:\edk2\ArmPlatformPkg\Drivers\NorFlashDxe\NorFlashDxe.c:784:
> > *Destination64++ = *Source64++;
> > .loc 10 784 0
> > ldrq0, [x9, x0]// MEM[base: vectp.229_593, index:
> > ivtmp.349_1117, offset: 0B], MEM[base: vectp.229_593, index: ivtmp.349_1117,
> > offset: 0B]
> > addx1, x1, 1// ivtmp_603, ivtmp_603,
> > cmpx7, x1// bnd.223, ivtmp_603
> > strq0, [x2, x0]// MEM[base: vectp.229_593, index:
> > ivtmp.349_1117, offset: 0B], MEM[base: vectp_Buffer.232_598, index:
> > ivtmp.349_1117, offset: 0B]
> > addx0, x0, 16// ivtmp.349, ivtmp.349,
> > bhi.L200//,
> >
> >
> > Despite compiler option -mgeneral-regs-only:
> >
> > // -mfix-cortex-a53-835769 -mfix-cortex-a53-843419 -mgeneral-regs-only
> > // -mlittle-endian -mpc-relative-literal-loads -mstrict-align
> > (see attached assembly generated file)
> >
>
> That is the same compiler bug at work, I think. So we need to add
> -mgeneral-regs-only for this module as well.
>
> Perhaps we should simply set it globally? Leif?
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] How to use a VGA adapter
You need a device specific GOP driver for graphics in UEFI. Thanks … br --- Brian Richardson, Senior Technical Marketing Engineer, Intel Software brian.richard...@intel.com -- @intel_brian (Twitter & WeChat) https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cédric Cano Sent: Thursday, July 13, 2017 12:23 PM To: edk2-devel@lists.01.org Subject: [edk2] How to use a VGA adapter Hello, I'm using the UDK2015 release and I want to enable the Graphic Output on a PCI VGA adapter (PCI class code: 3, 0, 0). My VGA device doesn't provide any ROM. In my FDF I've included the VgaMiniPortDxe and the VgaClassDxe. I haven't enabled the CSM layer. When my board boots the screen doesn't display anything. The PCI device is enumerated (device found with pci command on the EFI shell). Must I include another EFI driver to activate and/or initialize the VGA adapter or are these 2 drivers sufficient to enable the VGA display? Can I use the VGA without the CSM layer? Note: the display had already worked with a GOP driver on an AMD GPU. Is it possible to enable the GOP layer with the VGA layer? Regards. Cédric ___ 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 2/2] BaseTools/tools_def AARCH64: avoid SIMD register in XIP code
On 07/13/17 19:31, Leif Lindholm wrote:
> How are you ending up with all of those -O3?
Sorry for butting in, but personally I consider -O3 "suicidal".
The only -O3's I can currently see in BaseTools are:
> Conf/tools_def.template:DEBUG_CLANG38_IA32_DLINK2_FLAGS =
> DEF(GCC5_IA32_DLINK2_FLAGS) -O3
> Conf/tools_def.template:RELEASE_CLANG38_IA32_DLINK2_FLAGS =
> DEF(GCC5_IA32_DLINK2_FLAGS) -O3
> Conf/tools_def.template:DEBUG_CLANG38_X64_DLINK2_FLAGS =
> DEF(GCC5_X64_DLINK2_FLAGS) -O3
> Conf/tools_def.template:RELEASE_CLANG38_X64_DLINK2_FLAGS =
> DEF(GCC5_X64_DLINK2_FLAGS) -O3
Since I don't use CLANG, I don't mind these, but for gcc, I would.
In the past, Liming once suggested -O3 for the build tools themselves
(via -Ofast) -- meaning full well, of course! --, and I protested:
http://mid.mail-archive.com/ed237dbc-25f0-d0a9-3252-9a503de67ee4@redhat.com
And so we have commit 202726b3ceb3 ("BaseTools Makefile: Enable O2
option for GCC tool chain", 2016-09-29) today.
... I realize my email can appear as FUD, but I think there's a reason
most distros build their packages with -O2. Even upstream Linux uses -O2
generally (the only mention of -O3 I find right now in "Makefile" is
about problems it causes with gcc-4.8).
Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] CorebootPayloadPkg: redirect UEFI Shell to serial
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/11/2017 08:01 PM, Laszlo Ersek wrote: Hi Laszlo, thanks for taking time to reply. > > CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc seems to correctly > include the general SerialDxe driver: > > # # ISA Support # MdeModulePkg/Universal/SerialDxe/SerialDxe.inf > > and on top of that, the terminal and console drivers: > > # # Console Support # > MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf > MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf > MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf > > > MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf > > I imagine SerialDxe is not configured correctly for the platform. > Can you look into the PCDs that SerialDxe consumes (see the INF > file), Logs appear correctly in DXE and BDS, so at least at some point it works. Boot logs for SHELL_TYPE=UEFI_BIN adn SHELL_TYPE=BUILD_UEFI: http://81.95.197.197:/aciqabilaw http://81.95.197.197:/ijopesosuy It would be great to have the same for Shell application. Board schematics is open and available here: http://www.pcengines.ch/schema/apu2c.pdf You can see that serial is exposed through LPC. I tried to modify PcdSerialUseMmio to TRUE, but it doesn't seem to affect anything. Linux say "ttyS0 at I/O 0x3f8", so using IO seems to be fine. > and/or whether > "CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf", > > > which SerialDxe depends on in the CorebootPayloadPkg build, is > appropriate for your hardware? (This lib instance also consumes a > large set of PCDs.) I was able to get some results after removing: DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf from Shell.inf section in DSC. Boot log: http://81.95.197.197:/isenazutac As you can see I'm getting some logs from Shell entry point and it looks like DoShellPrompt start, but it doesn't appear on serial. In DoShellPrompt thing wait on ShellInfoObject.NewEfiShellProtocol->ReadFile so it seems no input from serial is accepted. Any further steps appreciated. I believe I need no stuff related to GOP, maybe it cause some problems ? Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlloB+kACgkQsu5x6Weq nkxUJRAAn8vB7qYm7vvFiAU8n7YM3AkkJyWs0KoQOO/4vDqJU8/O3dgDsnOhMfa8 T4xD0w/DBRdn7l06IrEnGHrYq6qH7zXmY7H3+QU4J55off/LHqNYm1SwJ+8LCDU0 /3+8VKaG3j3SR+nw/+iYAK+jPRFC0CtRIT2eNseqRHyZyvVaBEs/gcmv0znHqAjS rxkXc9VpkRbMq/dpoPpSbLtCf2D0d9G7QeyML4K+Kqhx66dnaKckUz7jS9amWE5b diFH8rI9IzxugO4Yg/SQsGKnGdR2c4oOxiZbV+p8fbe/AyE5qB76V+YpM9bChB/0 5/kaiWrD4S4ucZH9mRb63Km4rFZV3Km2P0EWZvtaGNacIjvLoYH6kXlqDVemdDRQ FxGhswPxDFYkhoXKN2TVUOVihKde37pkU2txDheQ60HdzcRl4uu3kSoX1g3j9gxe +cDOv/K8GePbp6QRhVtOqz6qIsPbpffjucqnJ5fjKkHOqSFcj8d9hKhREoL5SbBW YQXY9at0yLQWsvyOePcn5PFLxOpv6xr26KzLcAd6uKFMnxn64gXKZzrktJlY3VtQ b2R57kADlluTLgpcprs2QSB/v1WSSQ9KLwV8FuoMAO4XyQ1S2mDQLQhbs70zJP+h hcGK98Yqn0ItFinrOWT72sHUz35WUtUF8p9MdOd7eVxvcGLwwl4= =qNsJ -END PGP SIGNATURE- ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] CorebootPayloadPkg: redirect UEFI Shell to serial
On 07/14/17 01:53, Piotr Król wrote: > I was able to get some results after removing: > DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf > from Shell.inf section in DSC. Boot log: > http://81.95.197.197:/isenazutac > > As you can see I'm getting some logs from Shell entry point and it > looks like DoShellPrompt start, but it doesn't appear on serial. In > DoShellPrompt thing wait on > ShellInfoObject.NewEfiShellProtocol->ReadFile so it seems no input > from serial is accepted. > > Any further steps appreciated. I believe I need no stuff related to > GOP, maybe it cause some problems ? There are two paths to the serial port: (1) Via SerialPortLib APIs directly (or a bit more indirectly, via a DebugLib instance that relies on SerialPortLib). This is working for you already. (2) Using EfiSimpleTextOutProtocol. ConSplitterDxe installs a "fake" one of this, and then splits the output to all "actual" ones. This isn't working for you. From the log, the problem seems to me that ConPlatformDxe does not install a NULL EfiConsoleOutDevice protocol instance on the EfiSimpleTextOutProtocol instance that comes from TerminalDxe. Therefore, ConSplitterDxe does not consider the terminal as a device that it should split console output to. So when any application writes to ConSplitterDxe's own "fake" EfiSimpleTextOutProtocol, ConSplitterDxe does not forward the data to TerminalDxe's EfiSimpleTextOutProtocol, and the output is lost. The reason for ConPlatformDxe's behavior could be that your PlatformBootManagerLib instance does not add, in the PlatformBootManagerBeforeConsole() function, a device path to the L"ConOut" global variable that would match the device path of TerminalDxe's EfiSimpleTextOutProtocol instance. For example, see "ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c", function PlatformBootManagerBeforeConsole(): // // Add the hardcoded serial console device path to ConIn, ConOut, ErrOut. // CopyGuid (&mSerialConsole.TermType.Guid, PcdGetPtr (PcdTerminalTypeGuidBuffer)); EfiBootManagerUpdateConsoleVariable (ConIn, (EFI_DEVICE_PATH_PROTOCOL *)&mSerialConsole, NULL); EfiBootManagerUpdateConsoleVariable (ConOut, (EFI_DEVICE_PATH_PROTOCOL *)&mSerialConsole, NULL); EfiBootManagerUpdateConsoleVariable (ErrOut, (EFI_DEVICE_PATH_PROTOCOL *)&mSerialConsole, NULL); See the initialization of "mSerialConsole" near the top of that file. In short, in PlatformBootManagerBeforeConsole(), you need to add the device paths of all the EfiSimpleTextOutProtocol instances to L"ConOut" that you want to use as output consoles. Similarly for input and error. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 1/4] UefiCpuPkg: Add PPIN related MSR for Xeon E5.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong
Cc: Jeff Fan
---
UefiCpuPkg/Include/Register/Msr.h | 1 +
UefiCpuPkg/Include/Register/Msr/XeonE5v2Msr.h | 91 +++
2 files changed, 92 insertions(+)
create mode 100644 UefiCpuPkg/Include/Register/Msr/XeonE5v2Msr.h
diff --git a/UefiCpuPkg/Include/Register/Msr.h
b/UefiCpuPkg/Include/Register/Msr.h
index 0ac8d5b..8dbd6f7 100644
--- a/UefiCpuPkg/Include/Register/Msr.h
+++ b/UefiCpuPkg/Include/Register/Msr.h
@@ -45,5 +45,6 @@
#include
#include
#include
+#include
#endif
diff --git a/UefiCpuPkg/Include/Register/Msr/XeonE5v2Msr.h
b/UefiCpuPkg/Include/Register/Msr/XeonE5v2Msr.h
new file mode 100644
index 000..29ba125
--- /dev/null
+++ b/UefiCpuPkg/Include/Register/Msr/XeonE5v2Msr.h
@@ -0,0 +1,91 @@
+/** @file
+ MSR Definitions for Intel(R) Xeon(R) Processor E5 v2 Family.
+
+ Provides defines for Machine Specific Registers(MSR) indexes. Data structures
+ are provided for MSRs that contain one or more bit fields. If the MSR value
+ returned is a single 32-bit or 64-bit value, then a data structure is not
+ provided for that MSR.
+
+ Copyright (c) 2017, Intel Corporation. All rights reserved.
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+ @par Specification Reference:
+ Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 3,
+ September 2016, Chapter 35 Model-Specific-Registers (MSR), Section 35.8.
+
+**/
+
+#ifndef __XEON_E5_V2_MSR_H__
+#define __XEON_E5_V2_MSR_H__
+
+#include
+
+/**
+ Is Intel(R) Xeon(R) Processor E5 V2 Family?
+
+ @param DisplayFamily Display Family ID
+ @param DisplayModel Display Model ID
+
+ DisplayModel == 0x3E Intel Xeon processors E5 V2
+
+ @retval TRUE Yes, it is.
+ @retval FALSE No, it isn't.
+**/
+#define IS_XEON_E5_V2_PROCESSOR(DisplayFamily, DisplayModel) \
+ (DisplayFamily == 0x06 && \
+ (\
+DisplayModel == 0x3E\
+) \
+ )
+
+#define MSR_XEON_E5_V2_PIN_CTL0x004E
+
+/**
+ MSR information returned for MSR index #MSR_XEON_E7_FEATURE_CONFIG
+**/
+typedef union {
+ ///
+ /// Individual bit fields
+ ///
+ struct {
+///
+/// [Bit 0] LockOut (R/WO) 1 = Locked; 0 = unlocked
+/// Set 1 to prevent further writes to MSR_PPIN_CTL. Writing 1 to
+/// MSR_PPINCTL[bit 0] is permitted only if MSR_PPIN_CTL[bit 1] is
+/// clear, Default is 0.
+/// BIOS should provide an opt-in menu to enable the user to turn on
+/// MSR_PPIN_CTL[bit 1] for privileged inventory initialization agent to
+/// access MSR_PPIN. After reading MSR_PPIN, the privileged
+/// inventory initialization agent should write '1b' to MSR_PPIN_CTL
+/// to disable further access to MSR_PPIN and prevent unauthorized
+/// modification to MSR_PPIN_CTL
+///
+UINT32 LockOut:1;
+/// [Bit 1] Enable_PPIN (R/W) 1 = Enabled; 0 = Disabled
+/// If 1, enables MSR_PPIN to be accessible using RDMSR. Once set,
+/// attempt to write 1 to MSR_PPIN_CTL[bit 0] will cause #GP.
+/// If 0, an attempt to read MSR_PPIN will cause #GP. Default is 0
+///
+UINT32 EnablePpin:1;
+UINT32 Reserved1:30;
+UINT32 Reserved2:32;
+ } Bits;
+ ///
+ /// All bit fields as a 32-bit value
+ ///
+ UINT32 Uint32;
+ ///
+ /// All bit fields as a 64-bit value
+ ///
+ UINT64 Uint64;
+} MSR_XEON_E5_V2_PIN_CTL_REGISTER;
+
+#define MSR_XEON_E5_V2_PLATFORM_INFO 0x00CE
+
+#endif
\ No newline at end of file
--
2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 3/4] UefiCpuPkg: Add feature definition for PPIN.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Cc: Jeff Fan --- UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h | 1 + 1 file changed, 1 insertion(+) diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h index 4aa3529..10286ed 100644 --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h @@ -70,6 +70,7 @@ #define CPU_FEATURE_THREE_STRICK_COUNTER(32+8) #define CPU_FEATURE_APIC_TPR_UPDATE_MESSAGE (32+9) #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS (32+10) +#define CPU_FEATURE_PPIN(32+11) #define CPU_FEATURE_BEFORE_ALL BIT27 #define CPU_FEATURE_AFTER_ALL BIT28 -- 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 2/4] UefiCpuPkg RegisterCpuFeaturesLib: Add error handling.
Disable CPU feature may return error, add error handling
code to handle it instead of assert it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong
Cc: Jeff Fan
---
.../Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index e91a438..7a76730 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -536,7 +536,14 @@ AnalysisProcessorFeatures (
}
} else {
Status = CpuFeatureInOrder->InitializeFunc (ProcessorNumber, CpuInfo,
CpuFeatureInOrder->ConfigData, FALSE);
-ASSERT_EFI_ERROR (Status);
+if (EFI_ERROR (Status)) {
+ if (CpuFeatureInOrder->FeatureName != NULL) {
+DEBUG ((DEBUG_WARN, "Warning :: Failed to enable Feature Name =
%a.\n", CpuFeatureInOrder->FeatureName));
+ } else {
+DEBUG ((DEBUG_WARN, "Warning :: Failed to enable Feature Mask =
"));
+DumpCpuFeatureMask (CpuFeatureInOrder->FeatureMask);
+ }
+}
}
Entry = Entry->ForwardLink;
}
--
2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 0/4] Enable PPIN Cpu feature.
Enable PPIN Cpu feature. Eric Dong (4): UefiCpuPkg: Add PPIN related MSR for Xeon E5. UefiCpuPkg RegisterCpuFeaturesLib: Add error handling. UefiCpuPkg: Add feature definition for PPIN. UefiCpuPkg CpuCommonFeaturesLib: Enable Ppin feature. .../Include/Library/RegisterCpuFeaturesLib.h | 1 + UefiCpuPkg/Include/Register/Msr.h | 1 + UefiCpuPkg/Include/Register/Msr/XeonE5v2Msr.h | 91 ++ .../CpuCommonFeaturesLib/CpuCommonFeatures.h | 55 +++ .../CpuCommonFeaturesLib/CpuCommonFeaturesLib.c| 11 +++ .../CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf | 1 + UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c | 107 + .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 9 +- 8 files changed, 275 insertions(+), 1 deletion(-) create mode 100644 UefiCpuPkg/Include/Register/Msr/XeonE5v2Msr.h create mode 100644 UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c -- 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 4/4] UefiCpuPkg CpuCommonFeaturesLib: Enable Ppin feature.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong
Cc: Jeff Fan
---
.../CpuCommonFeaturesLib/CpuCommonFeatures.h | 55 +++
.../CpuCommonFeaturesLib/CpuCommonFeaturesLib.c| 11 +++
.../CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf | 1 +
UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c | 107 +
4 files changed, 174 insertions(+)
create mode 100644 UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
index 9c6e0b4..c03e5ab 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
@@ -854,4 +854,59 @@ FeatureControlGetConfigData (
IN UINTN NumberOfProcessors
);
+/**
+ Detects if Protected Processor Inventory Number feature supported on current
+ processor.
+
+ @param[in] ProcessorNumber The index of the CPU executing this function.
+ @param[in] CpuInfo A pointer to the
REGISTER_CPU_FEATURE_INFORMATION
+ structure for the CPU executing this function.
+ @param[in] ConfigData A pointer to the configuration buffer returned
+ by CPU_FEATURE_GET_CONFIG_DATA. NULL if
+ CPU_FEATURE_GET_CONFIG_DATA was not provided in
+ RegisterCpuFeature().
+
+ @retval TRUE Enhanced Intel SpeedStep feature is supported.
+ @retval FALSEEnhanced Intel SpeedStep feature is not supported.
+
+ @note This service could be called by BSP/APs.
+**/
+BOOLEAN
+EFIAPI
+PpinSupport (
+ IN UINTN ProcessorNumber,
+ IN REGISTER_CPU_FEATURE_INFORMATION *CpuInfo,
+ IN VOID *ConfigData OPTIONAL
+ );
+
+/**
+ Initializes Protected Processor Inventory Number feature to specific state.
+
+ @param[in] ProcessorNumber The index of the CPU executing this function.
+ @param[in] CpuInfo A pointer to the
REGISTER_CPU_FEATURE_INFORMATION
+ structure for the CPU executing this function.
+ @param[in] ConfigData A pointer to the configuration buffer returned
+ by CPU_FEATURE_GET_CONFIG_DATA. NULL if
+ CPU_FEATURE_GET_CONFIG_DATA was not provided in
+ RegisterCpuFeature().
+ @param[in] StateIf TRUE, then the Protected Processor Inventory
+ Number feature must be enabled.
+ If FALSE, then the Protected Processor
Inventory
+ Number feature must be disabled.
+
+ @retval RETURN_SUCCESS Protected Processor Inventory Number feature is
+ initialized.
+ @retval RETURN_DEVICE_ERROR Device can't change state because it has been
+ locked.
+
+**/
+RETURN_STATUS
+EFIAPI
+PpinInitialize (
+ IN UINTN ProcessorNumber,
+ IN REGISTER_CPU_FEATURE_INFORMATION *CpuInfo,
+ IN VOID *ConfigData, OPTIONAL
+ IN BOOLEAN State
+ );
+
#endif
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
index 2bd32ab..b88b7d1 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
@@ -206,6 +206,17 @@ CpuCommonFeaturesLibConstructor (
);
ASSERT_EFI_ERROR (Status);
}
+ if (IsCpuFeatureSupported (CPU_FEATURE_PPIN)) {
+Status = RegisterCpuFeature (
+ "PPIN",
+ NULL,
+ PpinSupport,
+ PpinInitialize,
+ CPU_FEATURE_PPIN,
+ CPU_FEATURE_END
+ );
+ASSERT_EFI_ERROR (Status);
+ }
return RETURN_SUCCESS;
}
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf
index e68936b..202d560 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf
@@ -47,6 +47,7 @@
MonitorMwait.c
PendingBreak.c
X2Apic.c
+ Ppin.c
[Packages]
MdePkg/MdePkg.dec
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c
new file mode 100644
index 000..5c213e3
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/Ppin.c
@@ -0,0 +1,107 @@
+/** @file
+ Protected Processor Inventory Number(PPIN) feature.
+
+ Copyright (c) 2017, Intel Corporation. All rights reserved.
+ This program and the accompanying materials
+ are licensed and made available under t
