[edk2] [PATCH v1] UefiCpuPkg: Merge StuffRsb.inc files into one in UefiCpuPkg/Include
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1091
Previously, when compiling NASM source files, BaseTools did not support
including files outside of the NASM source file directory. As a result, we
duplicated multiple copies of "StuffRsb.inc" files in UefiCpuPkg. Those
INC files contain the common logic to stuff the Return Stack Buffer and
are identical.
After the fix of BZ 1085:
https://bugzilla.tianocore.org/show_bug.cgi?id=1085
The above support was introduced.
Thus, this commit will merge all the StuffRsb.inc files in UefiCpuPkg into
one file. The merged file will be named 'StuffRsbNasm.inc' and be placed
under folder UefiCpuPkg/Include/.
Cc: Eric Dong
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu
---
UefiCpuPkg/{Library/SmmCpuFeaturesLib/Ia32/StuffRsb.inc =>
Include/StuffRsbNasm.inc} | 3 +-
UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.nasm
| 2 +-
UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiException.nasm
| 2 +-
UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiEntry.nasm
| 2 +-
UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiException.nasm
| 2 +-
UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/StuffRsb.inc
| 55
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
| 2 +-
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm
| 2 +-
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/StuffRsb.inc
| 55
UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm
| 2 +-
UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.nasm
| 2 +-
UefiCpuPkg/PiSmmCpuDxeSmm/X64/StuffRsb.inc
| 55
12 files changed, 10 insertions(+), 174 deletions(-)
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/StuffRsb.inc
b/UefiCpuPkg/Include/StuffRsbNasm.inc
similarity index 94%
rename from UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/StuffRsb.inc
rename to UefiCpuPkg/Include/StuffRsbNasm.inc
index 14267c3fde..276baea906 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/StuffRsb.inc
+++ b/UefiCpuPkg/Include/StuffRsbNasm.inc
@@ -11,7 +11,8 @@
;
; Abstract:
;
-; This file provides macro definitions for stuffing the Return Stack Buffer
(RSB).
+; This file provides macro definitions for stuffing the Return Stack Buffer
(RSB)
+; for NASM files.
;
;--
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.nasm
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.nasm
index 31754734bc..8c1242f978 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.nasm
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.nasm
@@ -18,7 +18,7 @@
;
;---
-%include "StuffRsb.inc"
+%include "StuffRsbNasm.inc"
%define MSR_IA32_MISC_ENABLE 0x1A0
%define MSR_EFER 0xc080
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiException.nasm
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiException.nasm
index bc8dbfe20b..398347c6e8 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiException.nasm
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiException.nasm
@@ -18,7 +18,7 @@
;
;---
-%include "StuffRsb.inc"
+%include "StuffRsbNasm.inc"
global ASM_PFX(gcStmPsd)
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiEntry.nasm
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiEntry.nasm
index c0a0f98f11..4ca05bbd73 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiEntry.nasm
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiEntry.nasm
@@ -18,7 +18,7 @@
;
;---
-%include "StuffRsb.inc"
+%include "StuffRsbNasm.inc"
;
; Variables referrenced by C code
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiException.nasm
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiException.nasm
index 3e5295986b..644d895671 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiException.nasm
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiException.nasm
@@ -18,7 +18,7 @@
;
;---
-%include "StuffRsb.inc"
+%include "StuffRsbNasm.inc"
global ASM_PFX(gcStmPsd)
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/StuffRsb.inc
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/StuffRsb.inc
deleted file mode 100644
index 14267c3fde..00
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/StuffRsb.inc
+++ /dev/null
@@ -1,55 +0,0 @@
-;--
Re: [edk2] Question about hotplugging NIC devices to an empty pci-bridge
You need have a PciHotPlug driver to produce the EFI_PCI_HOT_PLUG_INIT_PROTOCOL One example: https://github.com/tianocore/edk2/tree/master/OvmfPkg/PciHotPlugInitDxe Laszlo added it. He may provide comment on how to use it. Another example: https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform/Platform/Intel/KabylakeOpenBoardPkg/Features/PciHotPlug This is to add Thunderbolt support in Kabylake platform. Thank you Yao Jiewen > -Original Message- > From: Zhoujian (jay) [mailto:jianjay.z...@huawei.com] > Sent: Friday, December 21, 2018 11:04 AM > To: Yao, Jiewen ; edk2-devel@lists.01.org; > ler...@redhat.com > Cc: Huangweidong (C) ; liujunjie (A) > ; wangxin (U) ; > wujing (O) ; dengkai (A) > Subject: RE: Question about hotplugging NIC devices to an empty pci-bridge > > I've tried to set PcdPciBusHotplugDeviceSupport to be true in > MdeModulePkg.dec like below: > gEfiMdeModulePkgTokenSpaceGuid.PcdPciBusHotplugDeviceSupport|TRUE > |BOOLEAN|0x0001003d > But the problem still exists. Is there any steps I missed? Or some infos need > to populate to OVMF by Qemu? > > Could you give me more infos? > > Thanks, > Jay Zhou > > > -Original Message- > > From: Yao, Jiewen [mailto:jiewen@intel.com] > > Sent: Thursday, December 20, 2018 8:09 PM > > To: Zhoujian (jay) ; edk2-devel@lists.01.org > > Cc: Huangweidong (C) ; liujunjie (A) > > ; wangxin (U) > ; wujing (O) > > ; dengkai (A) > > Subject: RE: Question about hotplugging NIC devices to an empty > pci-bridge > > > > Maybe you can use EFI_PCI_HOT_PLUG_INIT_PROTOCOL to reserve some > resource. > > > > See MdePkg\Include\Protocol\PciHotPlugInit.h > > > > Thank you > > Yao Jiewen > > > > > -Original Message- > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of > > > Zhoujian (jay) > > > Sent: Thursday, December 20, 2018 7:34 PM > > > To: edk2-devel@lists.01.org > > > Cc: Huangweidong (C) ; liujunjie (A) > > > ; wangxin (U) > ; > > > wujing (O) ; dengkai (A) > > > > Subject: [edk2] Question about hotplugging NIC devices to an empty > > > pci-bridge > > > > > > Hi all, > > > > > > The issue occurs when I started a virtual machine in UEFI way by > > > libvirt on qemu-kvm platform, the vm is configured with 8 pci-bridges > > > on root bus0. I hotplug a device like virtual nic to an empty > > > pci-bridge which has no device connected. Login the vm, I can see the > > > device by "lspci"", but it didn't show by "ifconfig -a". Dmesg shows like > > below: > > > pci :04:01.0: BAR 0: no space for [mem size 0x0001 64bit pref] > > > pci > > > :04:01.0: BAR 0: failed to assign [mem size 0x0001 64bit pref] > > > pci > > > :04:01.0: BAR 3: no space for [mem size 0x4000 64bit pref] pci > > > :04:01.0: BAR 3: failed to assign [mem size 0x4000 64bit pref] > > > > > > Reboot the vm, everything turns back to normal and I can see the new > > > hotplugged nic by "ifconfig -a". > > > > > > Use the OVMF compiling from latest edk2 source code, the same > problem > > > arises. > > > > > > So, my questions are: > > > 1) the generic PCI bus driver in edk2 does not allocate IO and/or MMIO > > > for a bridge if there is no device behind the bridge that consume that > > > kind of resource? > > > 2) What's the purpose of this strategy? > > > 3) Why don't allocate resource to all bridges like seabios? > > > 4) Is there any switch for me to turn off this constraint so that > > > every pci-bridge including empty ones can be assigned IO and memory > window? > > > Otherwise, each time I hotplug a device to empty pci-bridge, a reboot > > > operation should be implemented to use the device? > > > > > > Any help will be appreciated, Thanks! > > > ___ > > > 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 0/6] Delete TCP, PXE, iSCSI driver in MdeModulePkg
Series Reviewed-by: Jiaxin Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Siyuan Fu > Sent: Thursday, December 20, 2018 9:49 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Wu, Jiaxin ; > Zeng, Star ; Ni, Ruiyu > Subject: [edk2] [PATCH v2 0/6] Delete TCP, PXE, iSCSI driver in > MdeModulePkg > > Delete TCP, PXE, iSCSI driver in MdeModulePkg > > This patch series is to delete the Tcp4Dxe, UefiPxeBcDxe and IScsi4Dxe > drivers in MdeModulePkg. These drivers will not be maintained and can't > co-work with the dual-stack drivers in NetworkPkg. > > In future, people should use below NetworkPkg drivers instead: > NetworkPkg/IScsiDxe/IScsiDxe.inf > NetworkPkg/TcpDxe/TcpDxe.inf > NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf > These drivers are actively maintained with more bug fixes and new feature > support. > > All edk2 platforms DSC/FDF have already been updated to use the > NetworkPkg > drivers in privious patch. > > Bugzilla link: https://bugzilla.tianocore.org/show_bug.cgi?id=1278 > > v2: > Break original patch to separate commits per module. > > Cc: Jian J Wang > Cc: Hao Wu > Cc: Ruiyu Ni > Cc: Star Zeng > Cc: Jiaxin Wu > > Siyuan Fu (6): > MdeModulePkg: Delete Tcp4Dxe in MdeModulePkg. > NetworkPkg: Remove some clarification from TcpDxe.inf > MdeModulePkg: Delete IScsiDxe in MdeModulePkg. > NetworkPkg: Remove some clarification from IScsiDxe.inf > MdeModulePkg: Delete UefiPxeBcDxe in MdeModulePkg. > NetworkPkg: Remove some clarification from UefiPxeBcDxe.inf > > .../Network/IScsiDxe/ComponentName.c | 283 -- > .../Universal/Network/IScsiDxe/IScsiCHAP.c| 430 --- > .../Universal/Network/IScsiDxe/IScsiConfig.c | 1264 --- > .../Universal/Network/IScsiDxe/IScsiDhcp.c| 472 --- > .../Universal/Network/IScsiDxe/IScsiDriver.c | 676 > .../Network/IScsiDxe/IScsiExtScsiPassThru.c | 412 --- > .../Universal/Network/IScsiDxe/IScsiIbft.c| 539 --- > .../Network/IScsiDxe/IScsiInitiatorName.c | 116 - > .../Universal/Network/IScsiDxe/IScsiMisc.c| 948 -- > .../Universal/Network/IScsiDxe/IScsiProto.c | 2799 --- > .../Universal/Network/IScsiDxe/IScsiTcp4Io.c | 487 --- > MdeModulePkg/Universal/Network/IScsiDxe/Md5.c | 350 -- > .../Universal/Network/Tcp4Dxe/ComponentName.c | 433 --- > .../Universal/Network/Tcp4Dxe/SockImpl.c | 1201 --- > .../Universal/Network/Tcp4Dxe/SockInterface.c | 990 -- > .../Network/Tcp4Dxe/Tcp4Dispatcher.c | 717 > .../Universal/Network/Tcp4Dxe/Tcp4Driver.c| 782 - > .../Universal/Network/Tcp4Dxe/Tcp4Input.c | 1497 - > .../Universal/Network/Tcp4Dxe/Tcp4Io.c| 112 - > .../Universal/Network/Tcp4Dxe/Tcp4Main.c | 674 > .../Universal/Network/Tcp4Dxe/Tcp4Misc.c | 940 -- > .../Universal/Network/Tcp4Dxe/Tcp4Option.c| 352 -- > .../Universal/Network/Tcp4Dxe/Tcp4Output.c| 1238 --- > .../Universal/Network/Tcp4Dxe/Tcp4Timer.c | 584 > .../Network/UefiPxeBcDxe/ComponentName.c | 365 -- > .../Network/UefiPxeBcDxe/PxeBcDhcp.c | 1999 --- > .../Network/UefiPxeBcDxe/PxeBcDriver.c| 665 > .../Network/UefiPxeBcDxe/PxeBcImpl.c | 2989 - > .../Network/UefiPxeBcDxe/PxeBcMtftp.c | 454 --- > .../Network/UefiPxeBcDxe/PxeBcSupport.c | 221 -- > MdeModulePkg/MdeModulePkg.dsc |3 - > .../Network/IScsiDxe/ComponentName.h | 165 - > .../Universal/Network/IScsiDxe/IScsi4Dxe.uni | 25 - > .../Network/IScsiDxe/IScsi4DxeExtra.uni | 20 - > .../Universal/Network/IScsiDxe/IScsiCHAP.h| 106 - > .../Universal/Network/IScsiDxe/IScsiCommon.h | 22 - > .../Universal/Network/IScsiDxe/IScsiConfig.h | 166 - > .../Network/IScsiDxe/IScsiConfigDxe.vfr | 219 -- > .../IScsiDxe/IScsiConfigDxeStrings.uni| 62 - > .../Network/IScsiDxe/IScsiConfigNVDataStruc.h | 109 - > .../Universal/Network/IScsiDxe/IScsiDhcp.h| 55 - > .../Universal/Network/IScsiDxe/IScsiDriver.h | 140 - > .../Universal/Network/IScsiDxe/IScsiDxe.inf | 134 - > .../Network/IScsiDxe/IScsiExtScsiPassThru.h | 22 - > .../Universal/Network/IScsiDxe/IScsiIbft.h| 38 - > .../Universal/Network/IScsiDxe/IScsiImpl.h| 168 - > .../Network/IScsiDxe/IScsiInitiatorName.h | 74 - > .../Universal/Network/IScsiDxe/IScsiMisc.h| 317 -- > .../Universal/Network/IScsiDxe/IScsiProto.h | 1005 -- > .../Universal/Network/IScsiDxe/IScsiTcp4Io.h | 142 - > MdeModulePkg/Universal/Network/IScsiDxe/Md5.h | 80 - > .../Universal/Network/Tcp4Dxe/SockImpl.h | 131 - > .../Universal/Network/Tcp4Dxe/Socket.h| 954 -- > .../Universal/Network/Tcp4Dxe/Tcp4Driver.h| 342 -- > .../Universal/Network/Tcp4Dxe/Tcp4Dxe.inf | 94 - > .../Universal/Network/Tcp4Dxe/Tcp4Dxe.uni | 23 - > .../Network/Tcp4Dxe/Tcp4DxeExtra.uni
[edk2] [PATCH v1 5/5] UefiCpuPkg/PiSmmCpuDxeSmm: Update to consume SpeculationBarrier
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417 Since BaseLib API AsmLfence() is a x86 arch specific API and should be avoided using in generic codes, this commit replaces the usage of AsmLfence() with arch-generic API SpeculationBarrier(). Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Liming Gao Cc: Eric Dong Cc: Ruiyu Ni Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu --- UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c index 19979d5418..8c9fa14b5b 100644 --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c @@ -238,10 +238,10 @@ SmmReadSaveState ( return EFI_INVALID_PARAMETER; } // - // The AsmLfence() call here is to ensure the above check for the CpuIndex - // has been completed before the execution of subsequent codes. + // The SpeculationBarrier() call here is to ensure the above check for the + // CpuIndex has been completed before the execution of subsequent codes. // - AsmLfence (); + SpeculationBarrier (); // // Check for special EFI_SMM_SAVE_STATE_REGISTER_PROCESSOR_ID -- 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v1 4/5] MdeModulePkg/Variable: Update to consume SpeculationBarrier
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417
Since BaseLib API AsmLfence() is a x86 arch specific API and should be
avoided using in generic codes, this commit replaces the usage of
AsmLfence() with arch-generic API SpeculationBarrier().
Please note that speculation execution barriers are intended to be
asserted for SMM codes, hence, this commit still preserve an empty
implementation of the speculation execution barrier for the DXE codes.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Liming Gao
Cc: Jian J Wang
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu
---
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
| 2 +-
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
| 2 +-
MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
| 10
MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceDxe.c =>
SpeculationBarrierDxe.c} | 12 ++
MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceSmm.c =>
SpeculationBarrierSmm.c} | 14 +++-
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
| 6 ++---
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
| 24 ++--
7 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
index 868981ccaf..7ef8a97f5d 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
@@ -46,7 +46,7 @@
TcgMorLockDxe.c
VarCheck.c
VariableExLib.c
- LoadFenceDxe.c
+ SpeculationBarrierDxe.c
[Packages]
MdePkg/MdePkg.dec
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
index 2fe72ff8a4..db7d220e06 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
@@ -54,7 +54,7 @@
PrivilegePolymorphic.h
VariableExLib.c
TcgMorLockSmm.c
- LoadFenceSmm.c
+ SpeculationBarrierSmm.c
[Packages]
MdePkg/MdePkg.dec
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
index a324ad2365..7af22a4ad6 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
@@ -85,13 +85,15 @@ SetVariableCheckHandlerMor (
);
/**
- This service is consumed by the variable modules to perform a serializing
- operation on all load-from-memory instructions that were issued prior to the
- call of this function.
+ This service is consumed by the variable modules to place a barrier to stop
+ speculative execution.
+
+ Ensures that no later instruction will execute speculatively, until all prior
+ instructions have completed.
**/
VOID
-MemoryLoadFence (
+VariableSpeculationBarrier (
VOID
);
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
b/MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierDxe.c
similarity index 62%
rename from MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
rename to MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierDxe.c
index 0f64ee093b..bc3f695335 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierDxe.c
@@ -1,5 +1,5 @@
/** @file
- Serialize operation on all load-from-memory instructions (DXE version).
+ Barrier to stop speculative execution (DXE version).
Copyright (c) 2018, Intel Corporation. All rights reserved.
This program and the accompanying materials
@@ -15,13 +15,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
#include "Variable.h"
/**
- This service is consumed by the variable modules to perform a serializing
- operation on all load-from-memory instructions that were issued prior to the
- call of this function.
+ This service is consumed by the variable modules to place a barrier to stop
+ speculative execution.
+
+ Ensures that no later instruction will execute speculatively, until all prior
+ instructions have completed.
**/
VOID
-MemoryLoadFence (
+VariableSpeculationBarrier (
VOID
)
{
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
b/MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierSmm.c
similarity index 61%
rename from MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
rename to MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierSmm.c
index 4b0d7e3e95..dbc20f6c4d 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceSmm.c
+++ b/MdeModulePkg/U
[edk2] [PATCH v1 0/5] Ues arch-generic API SpeculationBarrier() to replace AsmLfence()
X86 specific BaseLib API AsmLfence() was introduced to address the Spectre
Variant 1 (CVE-2017-5753) issue. The purpose of this API is to insert
barriers to stop speculative execution. However, the API is highly
architecture (X86) specific, and thus should be avoided using across
generic code.
To address this issue, this series will add a new BaseLib API called
SpeculationBarrier(). Different architectures will have different
implementations for this API. And the series will replace the usage of
AsmLfence() in generic codes with this newly added SpeculationBarrier().
For the implementations of API SpeculationBarrier() among different
architectures, this series will:
* For IA32 and x64, SpeculationBarrier() will directly call AsmLfence().
* For ARM and EBC architectures, an empty implementation is temporarily
added as a placeholder. We hope experts in those domains can help to
contribute the actual implementation.
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Liming Gao
Cc: Michael D Kinney
Cc: Jiewen Yao
Cc: Laszlo Ersek
Cc: Jian J Wang
Cc: Star Zeng
Cc: Eric Dong
Cc: Ruiyu Ni
Hao Wu (5):
MdePkg/BaseLib: Introduce new SpeculationBarrier API
MdeModulePkg/FaultTolerantWrite: Update to consume SpeculationBarrier
MdeModulePkg/SmmLockBox: Update to consume SpeculationBarrier
MdeModulePkg/Variable: Update to consume SpeculationBarrier
UefiCpuPkg/PiSmmCpuDxeSmm: Update to consume SpeculationBarrier
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
| 2 +-
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
| 2 +-
MdePkg/Library/BaseLib/BaseLib.inf
| 5 +++
MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
| 10 +++---
MdePkg/Include/Library/BaseLib.h
| 15 +
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
| 8 ++---
MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c
| 12
MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceDxe.c =>
SpeculationBarrierDxe.c} | 12 +---
MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceSmm.c =>
SpeculationBarrierSmm.c} | 14 +
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
| 6 ++--
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
| 24 +++
MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c
| 30 ++
MdePkg/Library/BaseLib/Ebc/SpeculationBarrier.c
| 30 ++
MdePkg/Library/BaseLib/X86SpeculationBarrier.c
| 32
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
| 6 ++--
15 files changed, 163 insertions(+), 45 deletions(-)
rename MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceDxe.c =>
SpeculationBarrierDxe.c} (62%)
rename MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceSmm.c =>
SpeculationBarrierSmm.c} (61%)
create mode 100644 MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c
create mode 100644 MdePkg/Library/BaseLib/Ebc/SpeculationBarrier.c
create mode 100644 MdePkg/Library/BaseLib/X86SpeculationBarrier.c
--
2.12.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v1 1/5] MdePkg/BaseLib: Introduce new SpeculationBarrier API
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417
X86 specific BaseLib API AsmLfence() was introduced to address the Spectre
Variant 1 (CVE-2017-5753) issue. The purpose of this API is to insert
barriers to stop speculative execution. However, the API is highly
architecture (X86) specific, and thus should be avoided using across
generic code.
To address this issue, this patch will add a new BaseLib API called
SpeculationBarrier(). Different architectures will have different
implementations for this API.
For IA32 and x64, the implementation of SpeculationBarrier() will
directly call AsmLfence().
For ARM and AARCH64, this patch will add a temporary empty implementation
as a placeholder. We hope experts in ARM can help to contribute the actual
implementation.
For EBC, similar to the ARM and AARCH64 cases, a temporary empty
implementation is added.
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Liming Gao
Cc: Michael D Kinney
Cc: Jiewen Yao
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu
---
MdePkg/Library/BaseLib/BaseLib.inf | 5 +++
MdePkg/Include/Library/BaseLib.h| 15 +
MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c | 30 ++
MdePkg/Library/BaseLib/Ebc/SpeculationBarrier.c | 30 ++
MdePkg/Library/BaseLib/X86SpeculationBarrier.c | 32
5 files changed, 112 insertions(+)
diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
b/MdePkg/Library/BaseLib/BaseLib.inf
index b84e58324c..d195c5417b 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -336,6 +336,7 @@
X86DisablePaging32.c
X86RdRand.c
X86PatchInstruction.c
+ X86SpeculationBarrier.c
[Sources.X64]
X64/Thunk16.nasm
@@ -515,6 +516,7 @@
X86DisablePaging32.c
X86RdRand.c
X86PatchInstruction.c
+ X86SpeculationBarrier.c
X64/GccInline.c | GCC
X64/Thunk16.S | XCODE
X64/SwitchStack.nasm| GCC
@@ -543,12 +545,14 @@
Ebc/CpuBreakpoint.c
Ebc/SetJumpLongJump.c
Ebc/SwitchStack.c
+ Ebc/SpeculationBarrier.c
Unaligned.c
Math64.c
[Sources.ARM]
Arm/InternalSwitchStack.c
Arm/Unaligned.c
+ Arm/SpeculationBarrier.c
Math64.c | RVCT
Math64.c | MSFT
@@ -582,6 +586,7 @@
[Sources.AARCH64]
Arm/InternalSwitchStack.c
Arm/Unaligned.c
+ Arm/SpeculationBarrier.c
Math64.c
AArch64/MemoryFence.S | GCC
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 8cc086983d..1eb842384e 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -5111,6 +5111,21 @@ CpuDeadLoop (
VOID
);
+
+/**
+ Uses as a barrier to stop speculative execution.
+
+ Ensures that no later instruction will execute speculatively, until all prior
+ instructions have completed.
+
+**/
+VOID
+EFIAPI
+SpeculationBarrier (
+ VOID
+ );
+
+
#if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64)
///
/// IA32 and x64 Specific Functions.
diff --git a/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c
b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c
new file mode 100644
index 00..8a6165a102
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c
@@ -0,0 +1,30 @@
+/** @file
+ SpeculationBarrier() function for ARM.
+
+ Copyright (C) 2018, 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.
+
+**/
+
+
+/**
+ Uses as a barrier to stop speculative execution.
+
+ Ensures that no later instruction will execute speculatively, until all prior
+ instructions have completed.
+
+**/
+VOID
+EFIAPI
+SpeculationBarrier (
+ VOID
+ )
+{
+}
diff --git a/MdePkg/Library/BaseLib/Ebc/SpeculationBarrier.c
b/MdePkg/Library/BaseLib/Ebc/SpeculationBarrier.c
new file mode 100644
index 00..8fa4c204f8
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ebc/SpeculationBarrier.c
@@ -0,0 +1,30 @@
+/** @file
+ SpeculationBarrier() function for EBC.
+
+ Copyright (C) 2018, 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.
+
+**/
+
+
+/**
+ Uses as a barrier to stop speculative execution.
+
+ Ensures that no later instruction will execute
[edk2] [PATCH v1 3/5] MdeModulePkg/SmmLockBox: Update to consume SpeculationBarrier
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417 Since BaseLib API AsmLfence() is a x86 arch specific API and should be avoided using in generic codes, this commit replaces the usage of AsmLfence() with arch-generic API SpeculationBarrier(). Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Liming Gao Cc: Jian J Wang Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu --- MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c b/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c index c1c9aa5663..a743129539 100644 --- a/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c +++ b/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c @@ -77,10 +77,10 @@ SmmLockBoxSave ( return ; } // - // The AsmLfence() call here is to ensure the above range check for the - // CommBuffer have been completed before calling into SaveLockBox(). + // The SpeculationBarrier() call here is to ensure the above range check for + // the CommBuffer have been completed before calling into SaveLockBox(). // - AsmLfence (); + SpeculationBarrier (); // // Save data @@ -166,10 +166,10 @@ SmmLockBoxUpdate ( return ; } // - // The AsmLfence() call here is to ensure the above range check for the - // CommBuffer have been completed before calling into UpdateLockBox(). + // The SpeculationBarrier() call here is to ensure the above range check for + // the CommBuffer have been completed before calling into UpdateLockBox(). // - AsmLfence (); + SpeculationBarrier (); // // Update data -- 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v1 2/5] MdeModulePkg/FaultTolerantWrite: Update to consume SpeculationBarrier
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417
Since BaseLib API AsmLfence() is a x86 arch specific API and should be
avoided using in generic codes, this commit replaces the usage of
AsmLfence() with arch-generic API SpeculationBarrier().
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Liming Gao
Cc: Jian J Wang
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu
---
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
index 27fcab19b6..481fea3f1f 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
@@ -419,11 +419,11 @@ SmmFaultTolerantWriteHandler (
);
if (!EFI_ERROR (Status)) {
//
-// The AsmLfence() call here is to ensure the previous range/content
-// checks for the CommBuffer have been completed before calling into
-// FtwWrite().
+// The SpeculationBarrier() call here is to ensure the previous
+// range/content checks for the CommBuffer have been completed before
+// calling into FtwWrite().
//
-AsmLfence ();
+SpeculationBarrier ();
Status = FtwWrite(
&mFtwDevice->FtwInstance,
SmmFtwWriteHeader->Lba,
--
2.12.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about hotplugging NIC devices to an empty pci-bridge
I've tried to set PcdPciBusHotplugDeviceSupport to be true in MdeModulePkg.dec like below: gEfiMdeModulePkgTokenSpaceGuid.PcdPciBusHotplugDeviceSupport|TRUE|BOOLEAN|0x0001003d But the problem still exists. Is there any steps I missed? Or some infos need to populate to OVMF by Qemu? Could you give me more infos? Thanks, Jay Zhou > -Original Message- > From: Yao, Jiewen [mailto:jiewen@intel.com] > Sent: Thursday, December 20, 2018 8:09 PM > To: Zhoujian (jay) ; edk2-devel@lists.01.org > Cc: Huangweidong (C) ; liujunjie (A) > ; wangxin (U) ; wujing (O) > ; dengkai (A) > Subject: RE: Question about hotplugging NIC devices to an empty pci-bridge > > Maybe you can use EFI_PCI_HOT_PLUG_INIT_PROTOCOL to reserve some resource. > > See MdePkg\Include\Protocol\PciHotPlugInit.h > > Thank you > Yao Jiewen > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Zhoujian (jay) > > Sent: Thursday, December 20, 2018 7:34 PM > > To: edk2-devel@lists.01.org > > Cc: Huangweidong (C) ; liujunjie (A) > > ; wangxin (U) ; > > wujing (O) ; dengkai (A) > > Subject: [edk2] Question about hotplugging NIC devices to an empty > > pci-bridge > > > > Hi all, > > > > The issue occurs when I started a virtual machine in UEFI way by > > libvirt on qemu-kvm platform, the vm is configured with 8 pci-bridges > > on root bus0. I hotplug a device like virtual nic to an empty > > pci-bridge which has no device connected. Login the vm, I can see the > > device by "lspci"", but it didn't show by "ifconfig -a". Dmesg shows like > below: > > pci :04:01.0: BAR 0: no space for [mem size 0x0001 64bit pref] > > pci > > :04:01.0: BAR 0: failed to assign [mem size 0x0001 64bit pref] > > pci > > :04:01.0: BAR 3: no space for [mem size 0x4000 64bit pref] pci > > :04:01.0: BAR 3: failed to assign [mem size 0x4000 64bit pref] > > > > Reboot the vm, everything turns back to normal and I can see the new > > hotplugged nic by "ifconfig -a". > > > > Use the OVMF compiling from latest edk2 source code, the same problem > > arises. > > > > So, my questions are: > > 1) the generic PCI bus driver in edk2 does not allocate IO and/or MMIO > > for a bridge if there is no device behind the bridge that consume that > > kind of resource? > > 2) What's the purpose of this strategy? > > 3) Why don't allocate resource to all bridges like seabios? > > 4) Is there any switch for me to turn off this constraint so that > > every pci-bridge including empty ones can be assigned IO and memory window? > > Otherwise, each time I hotplug a device to empty pci-bridge, a reboot > > operation should be implemented to use the device? > > > > Any help will be appreciated, Thanks! > > ___ > > 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 00/13] Extend secure variable service to be usable from Standalone MM
Jagadeesh,
There're many places in this patch series where code similar to following is
added.
It'd better to wrap them into module private functions or even a library, if
necessary.
This can make the code cleaner (no if/else) and easier (central place) to
maintain in
the future.
+ if (!PcdGetBool (PcdStandaloneMmVariableEnabled)) {
+Status = gSmst->SmmLocateProtocol (
+ &gEfiSmmSwapAddressRangeProtocolGuid,
+ NULL,
+ SarProtocol
+ );
+ } else {
+Status = gMmst->MmLocateProtocol (
+ &gEfiSmmSwapAddressRangeProtocolGuid,
+ NULL,
+ SarProtocol
+ );
+ }
Regards,
Jian
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jagadeesh Ujja
> Sent: Friday, December 14, 2018 8:13 PM
> To: edk2-devel@lists.01.org; Gao, Liming ; Zhang, Chao
> B ; leif.lindh...@linaro.org;
> ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH 00/13] Extend secure variable service to be usable from
> Standalone MM
>
> Changes since RFC v4:
> - Addressed all the comments from Liming Gao
> - Added an additional PCD 'PcdStandaloneMmCodeEnabled' to indicate
> presence of StandaloneMM support.
> - MdePkg.dec file updated to include StandaloneMmServiceTableLib and
> StandaloneMmRuntimeDxe library.
> - Platform specific changes will be posted in a seperate patchset.
> - AsmLfence wrapper function is supported for AArch64 platforms.
> - All the patches in this series can be pulled from
> https://github.com/jagadeeshujja/edk2 (branch: topics/aarch64_secure_vars)
>
> Changes since RFC v3:
> - Addressed all the comments from Liming Gao
> - Added a AArch64 implementation of AsmLfence which is a wrapper for
> MemoryFence. The changes in variable service driver in v3 of this
> patchset that used MemoryFence instead of AsmLfence have been removed.
> - Added StandaloneMmServicesTableLib.h and StandaloneMmRuntimeDxe
> library into MdePkg.
> - Renamed PcdStandaloneMmEnable as PcdStandaloneMmVariableEnabled and
> added to in to MdePkg.
> - Now with above changes, edk2 packages don't need to depend on
> StandaloneMmPkg/StandaloneMmPkg.dec
> - Addressed comments from Ting Ye
> - Removed the hacks in the v3 version.
> - Will relook into the “TimerWrapp.c” file and add a appropriate
> implementation of this for MM Standalone mode code.
>
> Changes since RFC v2:
> - Added 'Contributed-under' tag, removed Change-ID tag and
> maintained a single signed-off-by for the all the patches.
>
> Changes since RFC v1:
> - Addressed all the comments from Liming Gao
> - Removed the use of #ifdef/#else/#endif and used a Pcd instead to
> select between MM and non-MM paths.
> - Removed all dependencies on edk2-platforms.
> - Dropped the use of mMmst and used gSmst instead.
> - Added a dummy implementation UefiRuntimeServiceTableLib for
> MM_STANDALONE usage
> - Replaced all uses of AsmLfence with MemoryFence from variable
> service code.
> - Add a new StandaloneMmRuntimeDxe library to for use by non-MM code.
>
> This patch series extends the existing secure variable service support for
> use with Standalone MM. This is applicable to paltforms that use Standalone
> Management Mode to protect access to non-volatile memory (NOR flash in case
> of these patches) used to store the secure EFI variables.
>
> The first patch pulls in additional libraries from the staging branch of
> StandaloneMmPkg into the edk2's StandaloneMmPkg. The existing secure
> variable
> service implementation supports only the traditional MM mode and so the rest
> of the patches extends the existing secure variable service support to be
> useable with Standalone MM mode as well.
>
> Jagadeesh Ujja (13):
> StandaloneMmPkg: Pull in additonal libraries from staging branch
> MdePkg: Add a PCD that indicates presence of Standalone MM mode
> MdeModulePkg: Add a PCD to indicate Standalone MM supports secure
> variable
> MdePkg/Include: add StandaloneMmServicesTableLib header file
> MdePkg/Library/BaseLib/AArch64: Add AsmLfence function
> MdePkg/Library: Add StandaloneMmRuntimeDxe library
> MdeModulePkg/FaultTolerantWriteDxe: allow reusability as a MM driver
> MdeModulePkg/Variable/RuntimeDxe: adapt for usability with MM
> Standalone
> MdeModulePkg/Variable/RuntimeDxe: adapt as a MM Standalone driver
> MdeModulePkg/VarCheckLib: allow MM_STANDALONE drivers to use this
> library
> ArmPlatformPkg/NorFlashDxe: allow reusability as a MM driver
> SecurityPkg/AuthVariableLib: allow MM_STANDALONE drivers to use this
> library
> CryptoPkg/BaseCryptLib: allow MM_STANDALONE drivers to use this
> library
>
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
> | 2 +-
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
>
Re: [edk2] [PATCH] Upgrade OpenSSL to 1.1.0j
Pushed @ a18f784cfdbe17855ec4376e80db927e1a81aaca
To whom it may concern, please remember to update the openssl submodule before
building any modules from CryptoPkg.
Regards,
Jian
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Wednesday, December 19, 2018 11:03 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting
> Subject: [edk2] [PATCH] Upgrade OpenSSL to 1.1.0j
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1393
>
> BZ#1089 (https://bugzilla.tianocore.org/show_bug.cgi?id=1089) requests
> to upgrade the OpenSSL to the latest 1.1.1 release. Since OpenSSL-1.1.1
> has many changes, more porting efforts and feature evaluation are needed.
> This might lead to a situation that it cannot catch the Q1'19 stable tag.
>
> One of the solution is upgrade current version (1.1.0h) to 1.1.0j.
> According to following web page in openssl.org, all security issues
> solved in 1.1.1 have been also back-ported to 1.1.0.j. This can make
> sure that no security vulnerabilities left in edk2 master before 1.1.1.
>
> https://www.openssl.org/news/vulnerabilities-1.1.1.html
>
> Cc: Ting Ye
> Cc: Gang Wei
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang
> ---
> CryptoPkg/CryptoPkg.dsc | 1 +
> .../Library/Include/openssl/opensslconf.h | 20 ---
> CryptoPkg/Library/OpensslLib/OpensslLib.inf | 3 +++
> .../Library/OpensslLib/OpensslLibCrypto.inf | 3 +++
> CryptoPkg/Library/OpensslLib/openssl | 2 +-
> CryptoPkg/Library/OpensslLib/process_files.pl | 0
> 6 files changed, 21 insertions(+), 8 deletions(-)
> mode change 100644 => 100755 CryptoPkg/Library/OpensslLib/process_files.pl
>
> diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
> index a0334d628b..321abe4d4c 100644
> --- a/CryptoPkg/CryptoPkg.dsc
> +++ b/CryptoPkg/CryptoPkg.dsc
> @@ -121,6 +121,7 @@
>CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
>CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>CryptoPkg/Library/TlsLib/TlsLib.inf
> + CryptoPkg/Library/OpensslLib/OpensslLib.inf
>
> [Components.IA32, Components.X64]
>CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> diff --git a/CryptoPkg/Library/Include/openssl/opensslconf.h
> b/CryptoPkg/Library/Include/openssl/opensslconf.h
> index 1917d7ab24..28dd9ab93c 100644
> --- a/CryptoPkg/Library/Include/openssl/opensslconf.h
> +++ b/CryptoPkg/Library/Include/openssl/opensslconf.h
> @@ -2,7 +2,7 @@
> * WARNING: do not edit!
> * Generated from include/openssl/opensslconf.h.in
> *
> - * Copyright 2016 The OpenSSL Project Authors. All Rights Reserved.
> + * Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved.
> *
> * Licensed under the OpenSSL license (the "License"). You may not use
> * this file except in compliance with the License. You can obtain a copy
> @@ -235,12 +235,18 @@ extern "C" {
> * still won't see them if the library has been built to disable deprecated
> * functions.
> */
> -#if defined(OPENSSL_NO_DEPRECATED)
> -# define DECLARE_DEPRECATED(f)
> -#elif __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0)
> -# define DECLARE_DEPRECATED(f)f __attribute__ ((deprecated));
> -#else
> -# define DECLARE_DEPRECATED(f) f;
> +#ifndef DECLARE_DEPRECATED
> +# if defined(OPENSSL_NO_DEPRECATED)
> +# define DECLARE_DEPRECATED(f)
> +# else
> +# define DECLARE_DEPRECATED(f) f;
> +# ifdef __GNUC__
> +# if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0)
> +#undef DECLARE_DEPRECATED
> +#define DECLARE_DEPRECATED(f)f __attribute__ ((deprecated));
> +# endif
> +# endif
> +# endif
> #endif
>
> #ifndef OPENSSL_FILE
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index 0300856cf2..6162d29143 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -175,6 +175,7 @@
>$(OPENSSL_PATH)/crypto/conf/conf_mall.c
>$(OPENSSL_PATH)/crypto/conf/conf_mod.c
>$(OPENSSL_PATH)/crypto/conf/conf_sap.c
> + $(OPENSSL_PATH)/crypto/conf/conf_ssl.c
>$(OPENSSL_PATH)/crypto/cpt_err.c
>$(OPENSSL_PATH)/crypto/cryptlib.c
>$(OPENSSL_PATH)/crypto/cversion.c
> @@ -281,6 +282,7 @@
>$(OPENSSL_PATH)/crypto/evp/pmeth_lib.c
>$(OPENSSL_PATH)/crypto/evp/scrypt.c
>$(OPENSSL_PATH)/crypto/ex_data.c
> + $(OPENSSL_PATH)/crypto/getenv.c
>$(OPENSSL_PATH)/crypto/hmac/hm_ameth.c
>$(OPENSSL_PATH)/crypto/hmac/hm_pmeth.c
>$(OPENSSL_PATH)/crypto/hmac/hmac.c
> @@ -418,6 +420,7 @@
>$(OPENSSL_PATH)/crypto/x509/x509_err.c
>$(OPENSSL_PATH)/crypto/x509/x509_ext.c
>$(OPENSSL_PATH)/crypto/x509/x509_lu.c
> + $(OPENSSL_PATH)/crypto/x509/x509_meth.c
>$(OPENSSL_PATH)/crypto/x509/x509_obj.c
>$(OPENSSL_PATH)/crypto/x509/x509_r2x.c
>$(OPENSSL_PATH)/crypto/x509/x509_req.c
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibC
Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid AP calls PeiService.
Hi,
Thanks all for your comments. It's valuable to me.
Seems like we all agree to remove the PcdSpinLockTimeout in AcquireSpinLock. I
have submit BZ for it:
https://bugzilla.tianocore.org/show_bug.cgi?id=1419
For my patch, I will avoid this code change and set PcdSpinLockTimeout=0 for
my modules. I will send V2 patch soon.
Thanks,
Eric
> -Original Message-
> From: Brian J. Johnson [mailto:brian.john...@hpe.com]
> Sent: Friday, December 21, 2018 12:36 AM
> To: Yao, Jiewen ; Ni, Ruiyu ;
> Dong, Eric ; edk2-devel@lists.01.org
> Cc: Laszlo Ersek
> Subject: Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid
> AP calls PeiService.
>
> Agreed. We've seen issues on real platforms with timed-out spinlocks in DXE
> causing calls to GetPerformanceCounter and DebugAssert. (DXE has the
> same code, with the same issues.)
>
> Note that it's possible to set PcdSpinLockTimeout=0 to work around the issue
> on a particular platform, or in a particular module. But if you have to do
> that
> for every module which uses APs, and hence could contend for a spinlock, it
> kind of defeats the point We're better off removing the timeout code.
>
> Thanks,
> Brian
>
> On 12/19/18 8:08 PM, Yao, Jiewen wrote:
> > Yes, I agree, if we don't have any real case.
> >
> >
> >> -Original Message-
> >> From: Ni, Ruiyu
> >> Sent: Thursday, December 20, 2018 10:07 AM
> >> To: Dong, Eric ; Yao, Jiewen
> >> ; edk2-devel@lists.01.org
> >> Cc: Laszlo Ersek
> >> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
> >> Avoid AP calls PeiService.
> >>
> >> Can you just change the AcquireSpinLock() behavior to remove the
> >> Timeout PCD consumption?
> >>
> >> I haven't seen a real case that the timed acquisition of spin lock is
> >> needed.
> >>
> >>
> >> Thanks/Ray
> >>
> >>> -Original Message-
> >>> From: Dong, Eric
> >>> Sent: Thursday, December 20, 2018 9:23 AM
> >>> To: Yao, Jiewen ; edk2-devel@lists.01.org
> >>> Cc: Ni, Ruiyu ; Laszlo Ersek
> >>> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
> >>> Avoid AP calls PeiService.
> >>>
> >>>
> >>> Agreed, Maybe it's time to add a new API like
> >>> AcquireSpinLockWithoutTimeOut?
> >>>
> >>> Thanks,
> >>> Eric
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, December 20, 2018 9:19 AM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Laszlo Ersek
>
> Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
> Avoid AP calls PeiService.
>
> Hi
> If we think below code is generic, can we have an API for that?
>
> + //
> + // Wait for the AP to release the MSR spin lock.
> + //
> + while (!AcquireSpinLockOrFail (&CpuFlags->ConsoleLogLock)) {
> +CpuPause ();
> + }
>
>
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > Behalf Of Eric Dong
> > Sent: Thursday, December 20, 2018 9:16 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; Laszlo Ersek
> >
> > Subject: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
> > Avoid AP calls PeiService.
> >
> > In AcquireSpinLock function, it calls GetPerformanceCounter which
> > final calls PeiService service. This patch avoid to call
> > AcquireSpinLock function.
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1411
> >
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong
> > ---
> >
> > UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> > |
> > 7
> > ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.
> > c
> > b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.
> > c index 624ddee055..a64326239f 100644
> > ---
> > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.
> > c
> > +++
> >> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.
> > +++ c
> > @@ -832,7 +832,12 @@ ProgramProcessorRegister (
> > RegisterTableEntry = &RegisterTableEntryHead[Index];
> >
> > DEBUG_CODE_BEGIN ();
> > - AcquireSpinLock (&CpuFlags->ConsoleLogLock);
> > + //
> > + // Wait for the AP to release the MSR spin lock.
> > + //
> > + while (!AcquireSpinLockOrFail (&CpuFlags->ConsoleLogLock)) {
> > +CpuPause ();
> > + }
> > ThreadIndex = ApLocation->Package *
> >> CpuStatus->MaxCoreCount *
> > CpuStatus->MaxThreadCount +
> > ApLocation->Core * CpuStatus->MaxThreadCount +
> > ApLocation->Thread;
> > --
> > 2.15.0.
Re: [edk2] [PATCH v2 1/1] UefiCpuPkg/CpuExceptionHandlerLib: Fix spelling issue
Hi Mike,
Reviewed-by: Eric Dong
And pushed it: SHA-1: 7c4207e955b22cab405292b354e22329b5a11caa
Remember to send the patch to edk2 community next time.
Thanks,
Eric
> -Original Message-
> From: Mike Maslenkin [mailto:mike.maslen...@gmail.com]
> Sent: Thursday, December 20, 2018 9:15 PM
> Cc: Mike Maslenkin ; Dong, Eric
> ; Laszlo Ersek
> Subject: [PATCH v2 1/1] UefiCpuPkg/CpuExceptionHandlerLib: Fix spelling
> issue
>
> *Excpetion* should be *Exception*
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Mike Maslenkin
> CC: Eric Dong
> CC: Laszlo Ersek
> ---
> UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h | 2
> +-
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c| 2 +-
> .../Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | 2 +-
> UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c | 2 +-
> .../Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> index 459f06ac8452..83e55ab82836 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> @@ -305,7 +305,7 @@ CommonExceptionHandlerWorker (
>@retval EFI_INVALID_PARAMETER StackSwitchData contains invalid
> content.
> **/
> EFI_STATUS
> -ArchSetupExcpetionStack (
> +ArchSetupExceptionStack (
>IN CPU_EXCEPTION_INIT_DATA*StackSwitchData
>);
>
> diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
> index 2a090782fc22..70ee7dd8bfb3 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
> @@ -285,7 +285,7 @@ InitializeCpuExceptionHandlersEx (
>
> InitData = &EssData;
>}
> - Status = ArchSetupExcpetionStack (InitData);
> + Status = ArchSetupExceptionStack (InitData);
> }
>}
>
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.
> c
> index 4a61b61f0a8c..531258610aa9 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.
> c
> @@ -121,7 +121,7 @@ ArchRestoreExceptionContext (
>
> **/
> EFI_STATUS
> -ArchSetupExcpetionStack (
> +ArchSetupExceptionStack (
>IN CPU_EXCEPTION_INIT_DATA *StackSwitchData
>)
> {
> diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
> index 292e89bed753..d2261720e884 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
> @@ -260,7 +260,7 @@ InitializeCpuExceptionHandlersEx (
> // Initializing stack switch is only necessary for Stack Guard
> functionality.
> //
> if (PcdGetBool (PcdCpuStackGuard) && InitData != NULL) {
> - Status = ArchSetupExcpetionStack (InitData);
> + Status = ArchSetupExceptionStack (InitData);
> }
>}
>
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> index 5dc628149e76..d7e883d19aad 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> @@ -126,7 +126,7 @@ ArchRestoreExceptionContext (
>
> **/
> EFI_STATUS
> -ArchSetupExcpetionStack (
> +ArchSetupExceptionStack (
>IN CPU_EXCEPTION_INIT_DATA *StackSwitchData
>)
> {
> --
> 2.19.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [edk2-announce] January Community Meeting
We will be holding our January Community Meeting on the *2nd* Thursday of January to accommodate holiday schedules. Details for January are posted here: https://github.com/tianocore/tianocore.github.io/wiki/Community-Virtual-Meetings Please contact me or post to the list anything you'd like to see discussed. Cheers, Stephano ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] ArmPkg/ArmLib ARM: set .fpu to let Clang 7 assemble ArmV7Support.S
Clang 7 complains about the vmsr instruction in ArmV7Support.S, which is only available on cores that implement some flavour of VFP. So set the .fpu to NEON like we do in some other places. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Library/ArmLib/Arm/ArmV7Support.S | 1 + 1 file changed, 1 insertion(+) diff --git a/ArmPkg/Library/ArmLib/Arm/ArmV7Support.S b/ArmPkg/Library/ArmLib/Arm/ArmV7Support.S index 281499b46cbc..1808962ee3e2 100644 --- a/ArmPkg/Library/ArmLib/Arm/ArmV7Support.S +++ b/ArmPkg/Library/ArmLib/Arm/ArmV7Support.S @@ -268,6 +268,7 @@ ASM_FUNC(ArmEnableVFP) #ifndef __clang__ mcr p10,#0x7,r0,c8,c0,#0 #else + .fpuneon vmsrfpexc, r0 #endif bx lr -- 2.19.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] GitLab results from my POV [was: Research Request]
On Wednesday, 12 December 2018 06:20:24 MST Laszlo Ersek wrote: > After having looked at GitHub, Phabricator, and GitLab, my personal > preference remains the mailing list. A *distant* second is GitHub. > (GitHub is "almost there", but its emails significantly lack context.) > And Phabricator and GitLab just don't cut it for me; Phabricator doesn't > map to multi-patch series to begin with, and GitLab is too resource > hungry, and it did a terrible job (for me anyway) preserving history. > > Can someone setup Gerrit for a test drive?... Hopefully we'll be able to pick this up again in the new year. -- Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Platform/FVP-AArch64: use different serial ports for DEBUG and console
On Thu, 20 Dec 2018 at 16:30, Ard Biesheuvel wrote:
>
> On Thu, 20 Dec 2018 at 16:20, Leif Lindholm wrote:
> >
> > On Mon, Dec 17, 2018 at 07:53:53PM +0100, Ard Biesheuvel wrote:
> > > The FVP models expose several emulated serial ports, and always start with
> > > Xterm windows connected to at least two of them. So let's switch to the
> > > second one for DEBUG output, leaving the original one for console output
> > > via SerialDxe.
> >
> > Could you clarify whether this means _all_ non-DEBUG output will go to
> > the first UART, or whether there is a switchover point and some early
> > non-DEBUG messages will now appear on the second UART?
> >
>
> Ah yes, good point.
>
> So any explicit calls to SerialPorWrite () from modules other than
> SerialDxe will get directed to the second UART in this case.
>
> There is such a call in PrePi:
>
> CharCount = AsciiSPrint (Buffer,sizeof (Buffer),
> "UEFI firmware (version %s built at %a on %a)\n\r",
> (CHAR16*)PcdGetPtr(PcdFirmwareVersionString), __TIME__, __DATE__);
> SerialPortWrite ((UINT8 *) Buffer, CharCount)
>
> and in one or two other places. Also note that DEBUG() directives in
> SerialDxe itself will be sent to the non-DEBUG uart.
>
> I think it makes sense for the DefaultExceptionHandlerLib to write to
> the console instead of doing a SerialPortWrite () on RELEASE builds,
> so I'll look into that next.
>
>
> > With that:
> > Reviewed-by: Leif Lindholm
> >
Pushed as 88e5de1a2346..861c200cda14, with the following paragraph
added to the commit log:
Note that explicit SerialPortWrite() calls made from other modules will
now also end up on the DEBUG console. Conversely, DEBUG output generated
in the context of SerialDxe will end up on the primary serial console.
This is a fundamental consequence of the way that DEBUG() is built on top
of SerialPortWrite(), which can only be implemented in one way in each
module (but can differ between modules, hence this patch)
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel
> > > ---
> > > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > > b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > > index 7094e57ee13a..7db1c675c3d9 100644
> > > --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > > +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > > @@ -125,7 +125,7 @@
> >
> > .inf diff format would have been slightly nicer here.
> >
> > >gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz|2400
> > >
> > >## PL011 - Serial Terminal
> > > - gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> > > + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c0a
> > >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
> > >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
> > >
> > > @@ -239,7 +239,10 @@
> > >MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> > >
> > > MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
> > >MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> > > - MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> > > + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
> > > +
> > > + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> > > + }
> > >
> > >MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> > >
> > > --
> > > 2.17.1
> > >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 24/41] Platform/NXP: Compilation for LS1046A RDB Board
On Wed, Nov 28, 2018 at 08:31:38PM +0530, Meenakshi Aggarwal wrote: > From: Vabhav > > Adding firmware device,description and declaration files to enable > compilation for NXP LS1046ARDB board. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Vabhav > Signed-off-by: Meenakshi Aggarwal > --- > Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec | 29 Now, I've not kept track, but if this directory was created previously, the .dec should really have been added when files were added to the Include directory. > Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc | 90 > Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.fdf | 198 > +++ > 3 files changed, 317 insertions(+) > create mode 100644 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec > create mode 100644 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc > create mode 100644 Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.fdf > > diff --git a/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec > b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec > new file mode 100644 > index 000..a872ade > --- /dev/null > +++ b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dec > @@ -0,0 +1,29 @@ > +# LS1046aRdbPkg.dec > +# LS1046a board package. > +# > +# Copyright 2017 NXP > +# > +# 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. > +# > + > +[Defines] > + PACKAGE_NAME = LS1046aRdbPkg > + PACKAGE_GUID = c0c8d5e4-f63b-4470-89bc-73c13c13b247 > + > + > +# > +# Include Section - list of Include Paths that are provided by this package. > +# Comments are used for Keywords and Module Types. > +# > +# Supported Module Types: > +# BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER > DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION > +# > + > +[Includes.common] > + Include# Root include for the package > diff --git a/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc > b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc > new file mode 100644 > index 000..7eb08a9 > --- /dev/null > +++ b/Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.dsc > @@ -0,0 +1,90 @@ > +# LS1046aRdbPkg.dsc > +# > +# LS1046ARDB Board package. > +# > +# Copyright 2017 NXP > +# > +# 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. > +# > + > + > +# > +# Defines Section - statements that will be processed to create a Makefile. > +# > + > +[Defines] > + # > + # Defines for default states. These can be changed on the command line. > + # -D FLAG=VALUE > + # > + PLATFORM_NAME = LS1046aRdbPkg > + PLATFORM_GUID = 43920156-3f3b-4199-9b29-c6db1fb792b0 > + OUTPUT_DIRECTORY = Build/LS1046aRdbPkg > + FLASH_DEFINITION = > Platform/NXP/LS1046aRdbPkg/LS1046aRdbPkg.fdf > + > +!include Platform/NXP/NxpQoriqLs.dsc.inc > +!include Silicon/NXP/LS1046A/LS1046A.dsc.inc > + > +[LibraryClasses.common] > + SocLib|Silicon/NXP/Library/SocLib/LS1046aSocLib.inf > + > ArmPlatformLib|Platform/NXP/LS1046aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf > + > ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf > + SerialPortLib|Silicon/NXP/Library/DUartPortLib/DUartPortLib.inf > + IoAccessLib|Silicon/NXP/Library/IoAccessLib/IoAccessLib.inf > + RealTimeClockLib|Silicon/NXP/Library/Pcf2129RtcLib/Pcf2129RtcLib.inf > + IfcLib|Silicon/NXP/Library/IfcLib/IfcLib.inf > + BoardLib|Platform/NXP/LS1046aRdbPkg/Library/BoardLib/BoardLib.inf > + FpgaLib|Silicon/NXP/Library/FpgaLib/FpgaLib.inf > + > +[PcdsFixedAtBuild.common] > + > + # > + # LS1046a board Specific PCDs > + # XX (DRAM - Region 1 2GB) > + # (NOR - IFC Region 1 512MB) > + gArmTokenSpaceGuid.PcdSystemMemoryBase|0x8000 > + gArmTokenSpaceGuid.PcdSystemMemorySize|0x8000 > + gArmPlatformTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0200 > + >
Re: [edk2] [PATCH] ArmPlatformPkg/PL011SerialPortLib: use untyped PCD for register base
On Thu, 20 Dec 2018 at 16:20, Leif Lindholm wrote:
>
> On Mon, Dec 17, 2018 at 07:51:45PM +0100, Ard Biesheuvel wrote:
> > Use an untyped PCD reference for PcdSerialRegisterBase, so that the
> > library gets built without hardcoded values, permitting modules to
> > override the default serial port. This allows SerialDxe to use a
> > different serial port from the one used for DEBUG output (which
> > often gets occluded due to the console driver clearing the screen)
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
>
> Reviewed-by: Leif Lindholm
>
Thanks
Pushed as 6f42f9a54bf0..5a9b3eb8e5fb
> > ---
> > ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c | 14
> > +++---
> > ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 4 +++-
> > 2 files changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > index 212991d63859..d576f79c3e6e 100644
> > --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> > @@ -48,7 +48,7 @@ SerialPortInitialize (
> >StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);
> >
> >return PL011UartInitializePort (
> > - (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > + (UINTN)PcdGet64 (PcdSerialRegisterBase),
> > PL011UartClockGetFreq(),
> > &BaudRate,
> > &ReceiveFifoDepth,
> > @@ -75,7 +75,7 @@ SerialPortWrite (
> >IN UINTN NumberOfBytes
> >)
> > {
> > - return PL011UartWrite ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > Buffer, NumberOfBytes);
> > + return PL011UartWrite ((UINTN)PcdGet64 (PcdSerialRegisterBase), Buffer,
> > NumberOfBytes);
> > }
> >
> > /**
> > @@ -95,7 +95,7 @@ SerialPortRead (
> >IN UINTN NumberOfBytes
> > )
> > {
> > - return PL011UartRead ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > Buffer, NumberOfBytes);
> > + return PL011UartRead ((UINTN)PcdGet64 (PcdSerialRegisterBase), Buffer,
> > NumberOfBytes);
> > }
> >
> > /**
> > @@ -111,7 +111,7 @@ SerialPortPoll (
> >VOID
> >)
> > {
> > - return PL011UartPoll ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase));
> > + return PL011UartPoll ((UINTN)PcdGet64 (PcdSerialRegisterBase));
> > }
> > /**
> >Set new attributes to PL011.
> > @@ -156,7 +156,7 @@ SerialPortSetAttributes (
> >)
> > {
> >return PL011UartInitializePort (
> > - (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> > + (UINTN)PcdGet64 (PcdSerialRegisterBase),
> > PL011UartClockGetFreq(),
> > BaudRate,
> > ReceiveFifoDepth,
> > @@ -198,7 +198,7 @@ SerialPortSetControl (
> >IN UINT32 Control
> >)
> > {
> > - return PL011UartSetControl ((UINTN)FixedPcdGet64
> > (PcdSerialRegisterBase), Control);
> > + return PL011UartSetControl ((UINTN)PcdGet64 (PcdSerialRegisterBase),
> > Control);
> > }
> >
> > /**
> > @@ -239,5 +239,5 @@ SerialPortGetControl (
> >OUT UINT32 *Control
> >)
> > {
> > - return PL011UartGetControl ((UINTN)FixedPcdGet64
> > (PcdSerialRegisterBase), Control);
> > + return PL011UartGetControl ((UINTN)PcdGet64 (PcdSerialRegisterBase),
> > Control);
> > }
> > diff --git
> > a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > index 5ce5b2f5304c..bca7bed875c6 100644
> > --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > @@ -36,8 +36,10 @@
> >MdeModulePkg/MdeModulePkg.dec
> >ArmPlatformPkg/ArmPlatformPkg.dec
> >
> > -[FixedPcd]
> > +[Pcd]
> >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase
> > +
> > +[FixedPcd]
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
> > --
> > 2.17.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms] Platform/Various: drop DefaultExceptionHandlerLibBase reference
Now that DebugAgentSymbolsBaseLib from ArmPkg no longer requires a DefaultExceptionHandlerLib resolution, drop the overrides from the [LibraryClasses.SEC] sections of various platforms. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 1 - Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc| 1 - Platform/LeMaker/CelloBoard/CelloBoard.dsc | 1 - Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc | 1 - Silicon/Hisilicon/Hisilicon.dsc.inc | 2 -- Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 1 - 6 files changed, 7 deletions(-) diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc index 49671eefbdea..93d351de5a27 100644 --- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc +++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc @@ -173,7 +173,6 @@ [LibraryClasses.common.SEC] ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf - DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc index 713c5637b074..e7a77c0ad957 100644 --- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc +++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc @@ -148,7 +148,6 @@ [LibraryClasses.common] [LibraryClasses.common.SEC] DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf - DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf !ifdef $(EDK2_SKIP_PEICORE) PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc b/Platform/LeMaker/CelloBoard/CelloBoard.dsc index a70f91bb02d5..dad9cae97ed4 100644 --- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc +++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc @@ -156,7 +156,6 @@ [LibraryClasses.common.SEC] ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf - DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc index 722c4adb7a72..7e9728d0430e 100644 --- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc +++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc @@ -155,7 +155,6 @@ [LibraryClasses.common.SEC] ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf - DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc b/Silicon/Hisilicon/Hisilicon.dsc.inc index 63d28a57406b..1282a97801b6 100644 --- a/Silicon/Hisilicon/Hisilicon.dsc.inc +++ b/Silicon/Hisilicon/Hisilicon.dsc.inc @@ -127,8 +127,6 @@ [LibraryClasses.common] NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf [LibraryClasses.common.SEC] - DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf - ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc index b3fd1846c0bf..92ff1daf8391 100644 --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc @@ -154,7 +154,6 @@ [LibraryClasses.common] [LibraryClasses.common.SEC] DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf - DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf -- 2.19.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/4] ArmPkg/DebugAgentSymbolsBaseLib: remove exception handling
DebugAgentSymbolsBaseLib is an optional library that is in charge of extracting debug headers from SEC and PEI_CORE images in memory so the filename and the offset in memory can be reported via the UART, allowing a developer to load debugging symbols into his debugger. Interestingly enough, DebugAgentSymbolsBaseLib is also in charge of exception handling before this duty is taken over by either the PEI core, or the CPU DXE driver when running under PrePi. Since exceptions are not actually handled at all on AArch64, and simply routed to the DefaultExceptionHandlerLib (for which a special version has been created to be usable this early), let's get rid of this dubious functionality altogether. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Library/DebugAgentSymbolsBaseLib/AArch64/DebugAgentException.S | 96 --- ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S | 277 ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.asm | 273 --- ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.c| 7 - ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf | 9 - 5 files changed, 662 deletions(-) diff --git a/ArmPkg/Library/DebugAgentSymbolsBaseLib/AArch64/DebugAgentException.S b/ArmPkg/Library/DebugAgentSymbolsBaseLib/AArch64/DebugAgentException.S deleted file mode 100644 index f33a07a19bad.. --- a/ArmPkg/Library/DebugAgentSymbolsBaseLib/AArch64/DebugAgentException.S +++ /dev/null @@ -1,96 +0,0 @@ -#-- -# -# Copyright (c) 2011 - 2013, ARM Ltd. All rights reserved. -# -# This program and the accompanying materials -# are licensed and made available under the terms and conditions of the BSD License -# which accompanies this distribution. The full text of the license may be found at -# http://opensource.org/licenses/bsd-license.php -# -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. -# -#-- - -#include - -GCC_ASM_IMPORT(DefaultExceptionHandler) - -.text -VECTOR_BASE(DebugAgentVectorTable) - -// -// Current EL with SP0 : 0x0 - 0x180 -// -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SP0_SYNC) -ASM_PFX(SynchronousExceptionSP0): - b ASM_PFX(SynchronousExceptionSP0) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SP0_IRQ) -ASM_PFX(IrqSP0): - b ASM_PFX(IrqSP0) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SP0_FIQ) -ASM_PFX(FiqSP0): - b ASM_PFX(FiqSP0) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SP0_SERR) -ASM_PFX(SErrorSP0): - b ASM_PFX(SErrorSP0) - -// -// Current EL with SPx: 0x200 - 0x380 -// -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SPx_SYNC) -ASM_PFX(SynchronousExceptionSPx): - b ASM_PFX(SynchronousExceptionSPx) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SPx_IRQ) -ASM_PFX(IrqSPx): - b ASM_PFX(IrqSPx) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SPx_FIQ) -ASM_PFX(FiqSPx): - b ASM_PFX(FiqSPx) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_CUR_SPx_SERR) -ASM_PFX(SErrorSPx): - b ASM_PFX(SErrorSPx) - -/* Lower EL using AArch64 : 0x400 - 0x580 */ -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A64_SYNC) -ASM_PFX(SynchronousExceptionA64): - b ASM_PFX(SynchronousExceptionA64) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A64_IRQ) -ASM_PFX(IrqA64): - b ASM_PFX(IrqA64) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A64_FIQ) -ASM_PFX(FiqA64): - b ASM_PFX(FiqA64) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A64_SERR) -ASM_PFX(SErrorA64): - b ASM_PFX(SErrorA64) - -// -// Lower EL using AArch32 : 0x600 - 0x780 -// -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A32_SYNC) -ASM_PFX(SynchronousExceptionA32): - b ASM_PFX(SynchronousExceptionA32) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A32_IRQ) -ASM_PFX(IrqA32): - b ASM_PFX(IrqA32) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A32_FIQ) -ASM_PFX(FiqA32): - b ASM_PFX(FiqA32) - -VECTOR_ENTRY(DebugAgentVectorTable, ARM_VECTOR_LOW_A32_SERR) -ASM_PFX(SErrorA32): - b ASM_PFX(SErrorA32) - -VECTOR_END(DebugAgentVectorTable) diff --git a/ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S b/ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S deleted file mode 100644 index 215181460803.. --- a/ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S +++ /dev/null @@ -1,277 +0,0 @@ -#-- -# -# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved. -# Copyright (c) 2011 - 2012, ARM Ltd. All rights reserved. -# -# This program and the accompanying materials -# are licensed and m
[edk2] [PATCH 2/4] ArmPkg/DefaultExceptionHandlerLib: declare the permitted usage context
Declare that this library is only usable in the context of DXE core or a DXE driver. Set the MODULE_TYPE to BASE: this only affects the prototype of the constructor (if present) but doesn't actually restrict the usage context otherwise. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf index f5421b1240a1..7609f82d89a1 100644 --- a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf +++ b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf @@ -17,9 +17,9 @@ INF_VERSION= 0x00010005 BASE_NAME = DefaultExceptionHandlerLib FILE_GUID = EACDB354-DF1A-4AF9-A171-499737ED818F - MODULE_TYPE= UEFI_DRIVER + MODULE_TYPE= BASE VERSION_STRING = 1.0 - LIBRARY_CLASS = DefaultExceptionHandlerLib + LIBRARY_CLASS = DefaultExceptionHandlerLib|DXE_CORE DXE_DRIVER [Sources.common] DefaultExceptionHandlerUefi.c -- 2.19.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 4/4] ArmPkg/DefaultExceptionHandlerLib: use console if available
Print the minimal 'exception occurred' message to the console instead
of straight to the serial port if the console is available. This makes
such messages visible on systems where the console is graphical and
the serial is not connected.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c |
16 +---
ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c |
7 ++-
ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf|
1 +
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git
a/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c
b/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c
index 1024bf48c63d..1aaf3c88f21e 100644
---
a/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c
+++
b/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -159,14 +160,23 @@ DefaultExceptionHandler (
INT32 Offset;
if (mRecursiveException) {
-CharCount = AsciiSPrint (Buffer, sizeof (Buffer),"\nRecursive exception
occurred while dumping the CPU state\n");
-SerialPortWrite ((UINT8 *) Buffer, CharCount);
+STATIC CHAR8 CONST Message[] = "\nRecursive exception occurred while
dumping the CPU state\n";
+
+if (gST->ConOut != NULL) {
+ AsciiPrint (Message);
+} else {
+ SerialPortWrite ((UINT8 *)Message, AsciiStrLen (Message));
+}
CpuDeadLoop ();
}
mRecursiveException = TRUE;
CharCount = AsciiSPrint (Buffer,sizeof (Buffer),"\n\n%a Exception at
0x%016lx\n", gExceptionTypeString[ExceptionType],
SystemContext.SystemContextAArch64->ELR);
- SerialPortWrite ((UINT8 *) Buffer, CharCount);
+ if (gST->ConOut != NULL) {
+AsciiPrint (Buffer);
+ } else {
+SerialPortWrite ((UINT8 *)Buffer, CharCount);
+ }
DEBUG_CODE_BEGIN ();
CHAR8 *Pdb, *PrevPdb;
diff --git
a/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c
b/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c
index 0b9da031b47d..9159b579da6f 100644
--- a/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c
+++ b/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
@@ -194,7 +195,11 @@ DefaultExceptionHandler (
CharCount = AsciiSPrint (Buffer,sizeof (Buffer),"\n%a Exception PC at 0x%08x
CPSR 0x%08x ",
gExceptionTypeString[ExceptionType],
SystemContext.SystemContextArm->PC, SystemContext.SystemContextArm->CPSR);
- SerialPortWrite ((UINT8 *) Buffer, CharCount);
+ if (gST->ConOut != NULL) {
+AsciiPrint (Buffer);
+ } else {
+SerialPortWrite ((UINT8 *)Buffer, CharCount);
+ }
DEBUG_CODE_BEGIN ();
CHAR8 *Pdb;
diff --git
a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
index 7609f82d89a1..6bc48714c9dc 100644
--- a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
+++ b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
@@ -42,6 +42,7 @@
PeCoffGetEntryPointLib
ArmDisassemblerLib
SerialPortLib
+ UefiBootServicesTableLib
[Guids]
gEfiDebugImageInfoTableGuid
--
2.19.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 3/4] ArmPkg/DefaultExceptionHandlerLib: drop BASE variant
Drop the redundant BASE variant, which is no longer used anywhere
now that DebugAgentSymbolsBaseLib no longer incorporates a vector
table and exception handling.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmPkg/ArmPkg.dsc|
1 -
ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerBase.c |
35 ---
ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf |
45
ArmVirtPkg/ArmVirt.dsc.inc |
1 -
4 files changed, 82 deletions(-)
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 5d83c18b143e..d9f9935d70b6 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -141,7 +141,6 @@
ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
ArmPkg/Library/ArmLib/ArmBaseLib.inf
ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
- ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
ArmPkg/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf
ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
diff --git
a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerBase.c
b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerBase.c
deleted file mode 100644
index 4a54298b1189..
--- a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerBase.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/** @file
-
- Copyright (c) 2012, ARM Ltd. All rights reserved.
-
- This program and the accompanying materials
- are licensed and made available under the terms and conditions of the BSD
License
- which accompanies this distribution. The full text of the license may be
found at
- http://opensource.org/licenses/bsd-license.php
-
- THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
- WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include
-
-/**
-
- @param FaultAddress Address to find PE/COFF image for.
- @param ImageBaseReturn load address of found image
- @param PeCoffSizeOfHeaders Return the size of the PE/COFF header for the
image that was found
-
- @retval NULL FaultAddress not in a loaded PE/COFF image.
- @retval Path and file name of PE/COFF image.
-
-**/
-CHAR8 *
-GetImageName (
- IN UINTN FaultAddress,
- OUT UINTN *ImageBase,
- OUT UINTN *PeCoffSizeOfHeaders
- )
-{
- return NULL;
-}
diff --git
a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
deleted file mode 100644
index b53a5e89f507..
---
a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
+++ /dev/null
@@ -1,45 +0,0 @@
-#/** @file
-#
-# Copyright (c) 2012, ARM Ltd. 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.
-#
-#
-#**/
-
-[Defines]
- INF_VERSION= 0x00010005
- BASE_NAME = DefaultExceptionHandlerBaseLib
- FILE_GUID = 3d5261d5-5eb7-4559-98e7-475aa9d0dc42
- MODULE_TYPE= BASE
- VERSION_STRING = 1.0
- LIBRARY_CLASS = DefaultExceptionHandlerLib
-
-[Sources.common]
- DefaultExceptionHandlerBase.c
-
-[Sources.ARM]
- Arm/DefaultExceptionHandler.c
-
-[Sources.AARCH64]
- AArch64/DefaultExceptionHandler.c
-
-[Packages]
- MdePkg/MdePkg.dec
- ArmPkg/ArmPkg.dec
-
-[LibraryClasses]
- BaseLib
- PrintLib
- DebugLib
- PeCoffGetEntryPointLib
- ArmDisassemblerLib
- SerialPortLib
-
-[Guids]
- gEfiDebugImageInfoTableGuid
diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 89c2db074711..c47955be940c 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -174,7 +174,6 @@
BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
-
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
SerialPortLib|ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.inf
HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
--
2.19.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/4] ArmPkg: use console for minimal 'exception occurred' message
When running with a graphical console, no message whatsoever is printed when the systems hits an unexpected exception and hangs, because even the minimal 'exception occurred' message is only sent to the serial port. So let's fix that, by updating DefaultExceptionHandlerLib to take the availability of a console into account. (#4) This requires some preparatory decruftication so that we can safely refer to the system table and console (#1 .. #3). Ard Biesheuvel (4): ArmPkg/DebugAgentSymbolsBaseLib: remove exception handling ArmPkg/DefaultExceptionHandlerLib: declare the permitted usage context ArmPkg/DefaultExceptionHandlerLib: drop BASE variant ArmPkg/DefaultExceptionHandlerLib: use console if available ArmPkg/ArmPkg.dsc | 1 - .../AArch64/DebugAgentException.S | 96 -- .../Arm/DebugAgentException.S | 277 -- .../Arm/DebugAgentException.asm | 273 - .../DebugAgentSymbolsBaseLib.c| 7 - .../DebugAgentSymbolsBaseLib.inf | 9 - .../AArch64/DefaultExceptionHandler.c | 16 +- .../Arm/DefaultExceptionHandler.c | 7 +- .../DefaultExceptionHandlerBase.c | 35 --- .../DefaultExceptionHandlerLib.inf| 5 +- .../DefaultExceptionHandlerLibBase.inf| 45 --- ArmVirtPkg/ArmVirt.dsc.inc| 1 - 12 files changed, 22 insertions(+), 750 deletions(-) delete mode 100644 ArmPkg/Library/DebugAgentSymbolsBaseLib/AArch64/DebugAgentException.S delete mode 100644 ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.S delete mode 100644 ArmPkg/Library/DebugAgentSymbolsBaseLib/Arm/DebugAgentException.asm delete mode 100644 ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerBase.c delete mode 100644 ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf -- 2.19.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid AP calls PeiService.
Agreed. We've seen issues on real platforms with timed-out spinlocks in
DXE causing calls to GetPerformanceCounter and DebugAssert. (DXE has
the same code, with the same issues.)
Note that it's possible to set PcdSpinLockTimeout=0 to work around the
issue on a particular platform, or in a particular module. But if you
have to do that for every module which uses APs, and hence could contend
for a spinlock, it kind of defeats the point We're better off
removing the timeout code.
Thanks,
Brian
On 12/19/18 8:08 PM, Yao, Jiewen wrote:
Yes, I agree, if we don't have any real case.
-Original Message-
From: Ni, Ruiyu
Sent: Thursday, December 20, 2018 10:07 AM
To: Dong, Eric ; Yao, Jiewen
; edk2-devel@lists.01.org
Cc: Laszlo Ersek
Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid
AP calls PeiService.
Can you just change the AcquireSpinLock() behavior to remove the Timeout
PCD consumption?
I haven't seen a real case that the timed acquisition of spin lock is needed.
Thanks/Ray
-Original Message-
From: Dong, Eric
Sent: Thursday, December 20, 2018 9:23 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Laszlo Ersek
Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid
AP calls PeiService.
Agreed, Maybe it's time to add a new API like
AcquireSpinLockWithoutTimeOut?
Thanks,
Eric
-Original Message-
From: Yao, Jiewen
Sent: Thursday, December 20, 2018 9:19 AM
To: Dong, Eric ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Laszlo Ersek
Subject: RE: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib:
Avoid AP calls PeiService.
Hi
If we think below code is generic, can we have an API for that?
+ //
+ // Wait for the AP to release the MSR spin lock.
+ //
+ while (!AcquireSpinLockOrFail (&CpuFlags->ConsoleLogLock)) {
+CpuPause ();
+ }
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
Of Eric Dong
Sent: Thursday, December 20, 2018 9:16 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Laszlo Ersek
Subject: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Avoid
AP calls PeiService.
In AcquireSpinLock function, it calls GetPerformanceCounter which
final calls PeiService service. This patch avoid to call
AcquireSpinLock function.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1411
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c |
7
++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index 624ddee055..a64326239f 100644
---
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.
+++ c
@@ -832,7 +832,12 @@ ProgramProcessorRegister (
RegisterTableEntry = &RegisterTableEntryHead[Index];
DEBUG_CODE_BEGIN ();
- AcquireSpinLock (&CpuFlags->ConsoleLogLock);
+ //
+ // Wait for the AP to release the MSR spin lock.
+ //
+ while (!AcquireSpinLockOrFail (&CpuFlags->ConsoleLogLock)) {
+CpuPause ();
+ }
ThreadIndex = ApLocation->Package *
CpuStatus->MaxCoreCount *
CpuStatus->MaxThreadCount +
ApLocation->Core * CpuStatus->MaxThreadCount +
ApLocation->Thread;
--
2.15.0.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
--
Brian J. Johnson
Enterprise X86 Lab
Hewlett Packard Enterprise
brian.john...@hpe.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Platform/FVP-AArch64: use different serial ports for DEBUG and console
On Thu, 20 Dec 2018 at 16:20, Leif Lindholm wrote:
>
> On Mon, Dec 17, 2018 at 07:53:53PM +0100, Ard Biesheuvel wrote:
> > The FVP models expose several emulated serial ports, and always start with
> > Xterm windows connected to at least two of them. So let's switch to the
> > second one for DEBUG output, leaving the original one for console output
> > via SerialDxe.
>
> Could you clarify whether this means _all_ non-DEBUG output will go to
> the first UART, or whether there is a switchover point and some early
> non-DEBUG messages will now appear on the second UART?
>
Ah yes, good point.
So any explicit calls to SerialPorWrite () from modules other than
SerialDxe will get directed to the second UART in this case.
There is such a call in PrePi:
CharCount = AsciiSPrint (Buffer,sizeof (Buffer),
"UEFI firmware (version %s built at %a on %a)\n\r",
(CHAR16*)PcdGetPtr(PcdFirmwareVersionString), __TIME__, __DATE__);
SerialPortWrite ((UINT8 *) Buffer, CharCount)
and in one or two other places. Also note that DEBUG() directives in
SerialDxe itself will be sent to the non-DEBUG uart.
I think it makes sense for the DefaultExceptionHandlerLib to write to
the console instead of doing a SerialPortWrite () on RELEASE builds,
so I'll look into that next.
> With that:
> Reviewed-by: Leif Lindholm
>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > index 7094e57ee13a..7db1c675c3d9 100644
> > --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> > @@ -125,7 +125,7 @@
>
> .inf diff format would have been slightly nicer here.
>
> >gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz|2400
> >
> >## PL011 - Serial Terminal
> > - gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> > + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c0a
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
> >
> > @@ -239,7 +239,10 @@
> >MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> >MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
> >MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> > - MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> > + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
> > +
> > + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> > + }
> >
> >MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> >
> > --
> > 2.17.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPlatformPkg/PL011SerialPortLib: use untyped PCD for register base
On Mon, Dec 17, 2018 at 07:51:45PM +0100, Ard Biesheuvel wrote:
> Use an untyped PCD reference for PcdSerialRegisterBase, so that the
> library gets built without hardcoded values, permitting modules to
> override the default serial port. This allows SerialDxe to use a
> different serial port from the one used for DEBUG output (which
> often gets occluded due to the console driver clearing the screen)
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c | 14
> +++---
> ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 4 +++-
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> index 212991d63859..d576f79c3e6e 100644
> --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> @@ -48,7 +48,7 @@ SerialPortInitialize (
>StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);
>
>return PL011UartInitializePort (
> - (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> + (UINTN)PcdGet64 (PcdSerialRegisterBase),
> PL011UartClockGetFreq(),
> &BaudRate,
> &ReceiveFifoDepth,
> @@ -75,7 +75,7 @@ SerialPortWrite (
>IN UINTN NumberOfBytes
>)
> {
> - return PL011UartWrite ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Buffer, NumberOfBytes);
> + return PL011UartWrite ((UINTN)PcdGet64 (PcdSerialRegisterBase), Buffer,
> NumberOfBytes);
> }
>
> /**
> @@ -95,7 +95,7 @@ SerialPortRead (
>IN UINTN NumberOfBytes
> )
> {
> - return PL011UartRead ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Buffer, NumberOfBytes);
> + return PL011UartRead ((UINTN)PcdGet64 (PcdSerialRegisterBase), Buffer,
> NumberOfBytes);
> }
>
> /**
> @@ -111,7 +111,7 @@ SerialPortPoll (
>VOID
>)
> {
> - return PL011UartPoll ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase));
> + return PL011UartPoll ((UINTN)PcdGet64 (PcdSerialRegisterBase));
> }
> /**
>Set new attributes to PL011.
> @@ -156,7 +156,7 @@ SerialPortSetAttributes (
>)
> {
>return PL011UartInitializePort (
> - (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> + (UINTN)PcdGet64 (PcdSerialRegisterBase),
> PL011UartClockGetFreq(),
> BaudRate,
> ReceiveFifoDepth,
> @@ -198,7 +198,7 @@ SerialPortSetControl (
>IN UINT32 Control
>)
> {
> - return PL011UartSetControl ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Control);
> + return PL011UartSetControl ((UINTN)PcdGet64 (PcdSerialRegisterBase),
> Control);
> }
>
> /**
> @@ -239,5 +239,5 @@ SerialPortGetControl (
>OUT UINT32 *Control
>)
> {
> - return PL011UartGetControl ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Control);
> + return PL011UartGetControl ((UINTN)PcdGet64 (PcdSerialRegisterBase),
> Control);
> }
> diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> index 5ce5b2f5304c..bca7bed875c6 100644
> --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> @@ -36,8 +36,10 @@
>MdeModulePkg/MdeModulePkg.dec
>ArmPlatformPkg/ArmPlatformPkg.dec
>
> -[FixedPcd]
> +[Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase
> +
> +[FixedPcd]
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
> --
> 2.17.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Need help
Hi Ravi, You can sign up for the edk2-devel mailing list for general discussion: https://lists.01.org/mailman/listinfo/edk2-devel Also, there is a list for bugs if you are interested: https://lists.01.org/mailman/listinfo/edk2-bugs Let me know if you have any questions. Cheers, Stephano Stephano Cetola TianoCore Community Manager On 12/20/2018 5:37 AM, Ravi Kumar Siadri wrote: Hi, I am getting mails from "edk2-devel-requ...@lists.01.org" with " Today's Topics: " kind of information , but i am not getting any mails from with General UEFI discussions and doubts. Can you please help me in this and let me know how can i subscribe to General UEFI discussions mailing list. Thanks, Ravi Kumar ___ 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] Platform/FVP-AArch64: use different serial ports for DEBUG and console
On Mon, Dec 17, 2018 at 07:53:53PM +0100, Ard Biesheuvel wrote:
> The FVP models expose several emulated serial ports, and always start with
> Xterm windows connected to at least two of them. So let's switch to the
> second one for DEBUG output, leaving the original one for console output
> via SerialDxe.
Could you clarify whether this means _all_ non-DEBUG output will go to
the first UART, or whether there is a switchover point and some early
non-DEBUG messages will now appear on the second UART?
With that:
Reviewed-by: Leif Lindholm
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> index 7094e57ee13a..7db1c675c3d9 100644
> --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> @@ -125,7 +125,7 @@
.inf diff format would have been slightly nicer here.
>gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz|2400
>
>## PL011 - Serial Terminal
> - gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c0a
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
>
> @@ -239,7 +239,10 @@
>MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
>MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> - MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
> +
> + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> + }
>
>MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
>
> --
> 2.17.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SP805 driver
On 12/17/2018 8:55 PM, Leif Lindholm wrote:
> Hi Sami, Thomas, (and others on cc)
>
> NXP are upstreaming a set containing an implementation of
> EFI_WATCHDOG_TIMER_ARCH_PROTOCOL using a hardware watchdog as backing.
> This idea comes from the SP805 driver
> ArmPlatformPkg/Drivers/SP805WatchdogDxe, which does the same.
>
> The problem is that this is a horrible idea. The point of the
> EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is that it lets you schedule software events
> when the watchdog timer expires. However, the SP805 driver does not let you
> do this:
>
> EFI_STATUS
> EFIAPI
> SP805RegisterHandler (
> IN CONST EFI_WATCHDOG_TIMER_ARCH_PROTOCOL *This,
> IN EFI_WATCHDOG_TIMER_NOTIFY NotifyFunction
> )
> {
> // ERROR: This function is not supported.
> // The hardware watchdog will reset the board
> return EFI_INVALID_PARAMETER;
> }
>
> From section 12.14 of the PI 1.6 spec:
> "If no handler has been registered, or the registered handler returns, then
> the system will be reset by calling the Runtime Service ResetSystem()."
> Blatantly, any driver that does the above (and initializes hardware that will
> reset the system without software control) will violate this.
>
> Meanwhile, the only two ARM platforms that include this driver are TC2 and
> FVP.
>
> Now, NXP are not at fault for following examples given to them in the
> reference ARM driver section - but can we please keep further people from
> making the same mistake?
> So my question to {Sami|Thomas} is - can we nuke this driver, and if so, can
> you provide the patches to remove it from edk2 and the resulting ones needed
> for edk2-platforms?
>
> I have no issues with reintroducing a fixed SP805 driver in the future that
> does not claim to conform to the above protocol.
>
> Finally - both the D03 and D05 platform .dsc files, as well as the Hisilicon
> ArmPlatformLib, contain references to it. (Ming/Heyi - please provide a
> patch.)
OK.
Thanks.
>
> /
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Drop CSM support in OvmfPkg?
> -Original Message- > From: David Woodhouse [mailto:dw...@infradead.org] > Sent: Thursday, December 20, 2018 9:37 PM > To: Gerd Hoffmann ; Laszlo Ersek > Cc: Ni, Ruiyu ; Justen, Jordan L > ; Ard Biesheuvel ; > Anthony Perard ; Julien Grall > ; edk2-devel@lists.01.org; Kevin O'Connor > > Subject: Re: Drop CSM support in OvmfPkg? > > On Thu, 2018-12-20 at 07:44 +0100, Gerd Hoffmann wrote: > > On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote: > > > (Adding Kevin, Gerd, David) > > > > > > On 12/17/18 03:23, Ni, Ruiyu wrote: > > > > Hi OvmfPkg maintainers and reviewers, > > > > I am working on removing IntelFrameworkModulePkg and > IntelFrameworkPkg. The biggest dependency now I see is the CSM components > that OVMF depends on. > > > > So I'd like to know your opinion about how to handle this. I see two > options here: > > > > > > > > 1. Drop CSM support in OvmfPkg. > > > > 2. Create a OvmfPkg/Csm folder to duplicate all CSM components there. > > > > > > > > What's your opinion about this? > > > > > > (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL > > > and Fedora also don't enable the CSM (mainly because I had found > > > debugging & supporting the CSM *extremely* difficult). For > > > virtualization, we generally recommend "use SeaBIOS directly if you need > > > a traditional BIOS guest". > > > > On a virtual machine it is very simple to switch the firmware (unlike on > > physical machines), which I think is the main reason ovmf+csm never > > really took off. > > Hm, that's true for virtual machines where you own the host system too > and switching BIOS is just a matter of configuration. If you're running > VM hosting at scale, however, and the customers don't get that level of > control, then offering a single BIOS image which does UEFI and CSM in a > "one size fits all" does have some merit. > > > > (3) However, David and Kevin had put a *lot* of work into enabling > > > SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM > > > target is a dedicated / separate "build mode" of SeaBIOS. > > > > IIRC there are still some corner cases which are not working and nobody > > wants put any effort into fixing them. S3 suspend comes to mind. > > Don't think that should be hard to fix if anyone really cares... > > > I'm not even sure it still works. It builds, yes, my jenkins instance > > does that. But there is no testing beyond that, and I doubt that > > someone else does regular ovmf+csm regression testing. So the chances > > that any runtime breakage goes unnoticed are pretty high ... > > > > > (4) I also think an open source CSM implementation should exist, just so > > > people can study it and experiment with it. > > > > It'll not be deleted from git, so it'll be there even when removed from > > master branch. > > > > > In short, I think the community would benefit if someone continued to > > > maintain the CSM infrastructure in edk2, > > Ruiyu (and Jordan), what's actually happening here? You said you were > deprecating IntelFrameworkPkg... in the internal Intel builds, what > replaces the CSM part? We fought to get parts of CSM support published > to TianoCore from the internal tree, and I'm concerned that this is a > regression — we end up with CSM support only being internal again. Or > is it being dropped from the Intel tree entirely? UEFI secure boot enabled firmware is the very recommended pre-OS environment considering nowadays more and more hackers are interested in this area. CSM enabled UEFI environment just cannot provide a trust chain up to OS loader and it will be (or may be) deprecated. I believe this is the major reason that we want to remove CSM support. @Brian, correct me if I am wrong. Regarding to deprecating IntelFrameworkPkg, that's to remove old used interfaces/codes to make developers easier to under EDKII project. > > I am very much against *increasing* the number of features which are > supported in private repositories and not the public one. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable from Standalone MM
Jagadeesh: MdeModulePkg Variable service/Fault tolerant/Nor Flash driver depends on StandaloneMmServicesTableLib library class header file. This header file is added into MdePkg. It has two interfaces. One is global gMmst, another is function InMm(). So, there is no dependency issue here. And, MdePkg adds one StandaloneMmServicesTableLib library INF with empty implementation, this library is just for build. It sets gMmst=NULL, and always return FASLE in InMm(). This library can be used in MdeModulePkg.dsc to make Variable driver pass build. There is also no dependency issue here. Last, Platform DSC file will refer to the real StandaloneMmServicesTableLib library INF from StandaloneMmPkg. Thanks Liming > -Original Message- > From: Jagadeesh Ujja [mailto:jagadeesh.u...@arm.com] > Sent: Tuesday, December 18, 2018 7:19 PM > To: Gao, Liming > Cc: edk2-devel@lists.01.org; Zhang, Chao B > Subject: Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable > from Standalone MM > > Hi Liming, > > On Tue, Dec 18, 2018 at 10:07 AM Gao, Liming wrote: > > > > Jagadeesh: > > StandaloneMmServicesTableLib library class header file is added into > > MdePkg. Its library implementation is in MdePkg and > StandaloneMmPkg. The one in MdePkg produces the dummy implementation, and the > one in StandaloneMmPkg produces the real > implementation. I don't see the reason to separate this library class. > > > > In this patchset series, the Variable service/Fault tolerant/Nor Flash > driver are refactored to be usable as MM_STANDALONE driver. These > drivers uses the following libraries from “StandaloneMmPkg”. > > - > MmServicesTableLib|StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf > - > MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf > > Variable MM_STANDALONE driver is located at > - MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c > - MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > > FaultTolerant MM_STANDALONE is driver located at > - MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c > - > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf > > These drivers look for “gMmst” which is defined in > “MmServicesTableLib”. Ideally, > “StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h” > should have defined “gMmst” as an “extern EFI_MM_SYSTEM_TABLE > *gMmst;”. > In which case, we would have to add > “StandaloneMmPkg/StandaloneMmPkg.dec” in other drivers listed below. > > - MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf > - MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf > > This will make “edk2 packages” to be depended on > "StandaloneMmPkg/StandaloneMmPkg.dec". > > To avoid this, > “StandaloneMmPkg/Include/Library/StandaloneMmServicesTableLib.h” > is moved to “MdePkg/Include/Library/StandaloneMmServicesTableLib.h”. > But, the implementation of “MmServicesTableLib” comes from > “StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf”. > > Thanks > Jagadeesh > > > Thanks > > Liming > > >-Original Message- > > >From: Jagadeesh Ujja [mailto:jagadeesh.u...@arm.com] > > >Sent: Monday, December 17, 2018 7:47 PM > > >To: Gao, Liming > > >Cc: edk2-devel@lists.01.org; Zhang, Chao B ; > > >leif.lindh...@linaro.org; ard.biesheu...@linaro.org > > >Subject: Re: [edk2] [PATCH 00/13] Extend secure variable service to be > > >usable > > >from Standalone MM > > > > > >Hi Liming, > > > > > >On Mon, Dec 17, 2018 at 7:15 AM Gao, Liming wrote: > > >> > > >> One question here. Why separate StandaloneMmServicesTableLib to two > > >library classes? Current MdePkg\Include\Library\SmmServicesTableLib.h is > > >one library class. > > >MdePkg\Library\SmmServicesTableLib\SmmServicesTableLib.inf is its > > >implementation. StandaloneMmServicesTableLib should be same to it. > > >> StandaloneMmServicesTableLib is the library class. > > >MdePkg\Library\StandaloneMmRuntimeDxe is its library instance. > > >> > > >Thanks for your review. > > > > > >The implementation of the "StandaloneMmServicesTableLib" library class > > >is at "StandaloneMmPkg/Library/StandaloneMmServicesTableLib/". As this > > >patchset reuses some of the DXE_DRIVER drivers as MM_STANDALONE > > >drivers, the "StandaloneMmServicesTableLib" library class definition > > >was placed within MdePkg. The reason for splitting the library class > > >definition (in MdePkg) and its implementation (in StandaloneMmPkg) was > > >due to your comment that "edk2 packages" should not have any reference > > >to StandaloneMmPkg.dec. > > > > > >The "StandaloneMmRuntimeDxe" library now just has an implementation of > > >InMm(). And so, this can be kept as a separate library with no > > >dependency on StandaloneMmPkg. So this was the reason to split > > >"StandaloneMmRuntimeDxe" and "Standalon
[edk2] Need help
Hi, I am getting mails from "edk2-devel-requ...@lists.01.org" with " Today's Topics: " kind of information , but i am not getting any mails from with General UEFI discussions and doubts. Can you please help me in this and let me know how can i subscribe to General UEFI discussions mailing list. Thanks, Ravi Kumar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Drop CSM support in OvmfPkg?
On Thu, 2018-12-20 at 07:44 +0100, Gerd Hoffmann wrote: > On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote: > > (Adding Kevin, Gerd, David) > > > > On 12/17/18 03:23, Ni, Ruiyu wrote: > > > Hi OvmfPkg maintainers and reviewers, > > > I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. > > > The biggest dependency now I see is the CSM components that OVMF depends > > > on. > > > So I'd like to know your opinion about how to handle this. I see two > > > options here: > > > > > > 1. Drop CSM support in OvmfPkg. > > > 2. Create a OvmfPkg/Csm folder to duplicate all CSM components there. > > > > > > What's your opinion about this? > > > > (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL > > and Fedora also don't enable the CSM (mainly because I had found > > debugging & supporting the CSM *extremely* difficult). For > > virtualization, we generally recommend "use SeaBIOS directly if you need > > a traditional BIOS guest". > > On a virtual machine it is very simple to switch the firmware (unlike on > physical machines), which I think is the main reason ovmf+csm never > really took off. Hm, that's true for virtual machines where you own the host system too and switching BIOS is just a matter of configuration. If you're running VM hosting at scale, however, and the customers don't get that level of control, then offering a single BIOS image which does UEFI and CSM in a "one size fits all" does have some merit. > > (3) However, David and Kevin had put a *lot* of work into enabling > > SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM > > target is a dedicated / separate "build mode" of SeaBIOS. > > IIRC there are still some corner cases which are not working and nobody > wants put any effort into fixing them. S3 suspend comes to mind. Don't think that should be hard to fix if anyone really cares... > I'm not even sure it still works. It builds, yes, my jenkins instance > does that. But there is no testing beyond that, and I doubt that > someone else does regular ovmf+csm regression testing. So the chances > that any runtime breakage goes unnoticed are pretty high ... > > > (4) I also think an open source CSM implementation should exist, just so > > people can study it and experiment with it. > > It'll not be deleted from git, so it'll be there even when removed from > master branch. > > > In short, I think the community would benefit if someone continued to > > maintain the CSM infrastructure in edk2, Ruiyu (and Jordan), what's actually happening here? You said you were deprecating IntelFrameworkPkg... in the internal Intel builds, what replaces the CSM part? We fought to get parts of CSM support published to TianoCore from the internal tree, and I'm concerned that this is a regression — we end up with CSM support only being internal again. Or is it being dropped from the Intel tree entirely? I am very much against *increasing* the number of features which are supported in private repositories and not the public one. smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about hotplugging NIC devices to an empty pci-bridge
Hi Jiewen, Thank for your quick response, I'll have a try. Regards, Jay Zhou > -Original Message- > From: Yao, Jiewen [mailto:jiewen@intel.com] > Sent: Thursday, December 20, 2018 8:09 PM > To: Zhoujian (jay) ; edk2-devel@lists.01.org > Cc: Huangweidong (C) ; liujunjie (A) > ; wangxin (U) ; wujing (O) > ; dengkai (A) > Subject: RE: Question about hotplugging NIC devices to an empty pci-bridge > > Maybe you can use EFI_PCI_HOT_PLUG_INIT_PROTOCOL to reserve some resource. > > See MdePkg\Include\Protocol\PciHotPlugInit.h > > Thank you > Yao Jiewen > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Zhoujian (jay) > > Sent: Thursday, December 20, 2018 7:34 PM > > To: edk2-devel@lists.01.org > > Cc: Huangweidong (C) ; liujunjie (A) > > ; wangxin (U) ; > > wujing (O) ; dengkai (A) > > Subject: [edk2] Question about hotplugging NIC devices to an empty > > pci-bridge > > > > Hi all, > > > > The issue occurs when I started a virtual machine in UEFI way by > > libvirt on qemu-kvm platform, the vm is configured with 8 pci-bridges > > on root bus0. I hotplug a device like virtual nic to an empty > > pci-bridge which has no device connected. Login the vm, I can see the > > device by "lspci"", but it didn't show by "ifconfig -a". Dmesg shows like > below: > > pci :04:01.0: BAR 0: no space for [mem size 0x0001 64bit pref] > > pci > > :04:01.0: BAR 0: failed to assign [mem size 0x0001 64bit pref] > > pci > > :04:01.0: BAR 3: no space for [mem size 0x4000 64bit pref] pci > > :04:01.0: BAR 3: failed to assign [mem size 0x4000 64bit pref] > > > > Reboot the vm, everything turns back to normal and I can see the new > > hotplugged nic by "ifconfig -a". > > > > Use the OVMF compiling from latest edk2 source code, the same problem > > arises. > > > > So, my questions are: > > 1) the generic PCI bus driver in edk2 does not allocate IO and/or MMIO > > for a bridge if there is no device behind the bridge that consume that > > kind of resource? > > 2) What's the purpose of this strategy? > > 3) Why don't allocate resource to all bridges like seabios? > > 4) Is there any switch for me to turn off this constraint so that > > every pci-bridge including empty ones can be assigned IO and memory window? > > Otherwise, each time I hotplug a device to empty pci-bridge, a reboot > > operation should be implemented to use the device? > > > > Any help will be appreciated, Thanks! > > ___ > > 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] Question about hotplugging NIC devices to an empty pci-bridge
Maybe you can use EFI_PCI_HOT_PLUG_INIT_PROTOCOL to reserve some resource. See MdePkg\Include\Protocol\PciHotPlugInit.h Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Zhoujian (jay) > Sent: Thursday, December 20, 2018 7:34 PM > To: edk2-devel@lists.01.org > Cc: Huangweidong (C) ; liujunjie (A) > ; wangxin (U) ; > wujing (O) ; dengkai (A) > Subject: [edk2] Question about hotplugging NIC devices to an empty > pci-bridge > > Hi all, > > The issue occurs when I started a virtual machine in UEFI way by libvirt on > qemu-kvm platform, the vm is configured with 8 pci-bridges on root bus0. I > hotplug a device like virtual nic to an empty pci-bridge which has no device > connected. Login the vm, I can see the device by "lspci"", but it didn't show > by "ifconfig -a". Dmesg shows like below: > pci :04:01.0: BAR 0: no space for [mem size 0x0001 64bit pref] pci > :04:01.0: BAR 0: failed to assign [mem size 0x0001 64bit pref] pci > :04:01.0: BAR 3: no space for [mem size 0x4000 64bit pref] pci > :04:01.0: BAR 3: failed to assign [mem size 0x4000 64bit pref] > > Reboot the vm, everything turns back to normal and I can see the new > hotplugged nic by "ifconfig -a". > > Use the OVMF compiling from latest edk2 source code, the same problem > arises. > > So, my questions are: > 1) the generic PCI bus driver in edk2 does not allocate IO and/or MMIO for a > bridge if there is no device behind the bridge that consume that kind of > resource? > 2) What's the purpose of this strategy? > 3) Why don't allocate resource to all bridges like seabios? > 4) Is there any switch for me to turn off this constraint so that every > pci-bridge including empty ones can be assigned IO and memory window? > Otherwise, each time I hotplug a device to empty pci-bridge, a reboot > operation should be implemented to use the device? > > Any help will be appreciated, Thanks! > ___ > 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] BaseTools: Reset FdsGlobalVariable
On Thu, 20 Dec 2018 at 12:38, BobCF wrote:
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1418
> This patch is going to fix a regression issue that is introduced
> by commit b3497bad1221704a5dbc5da0b10f42625f1ad2ed.
>
> Before commit b3497b, build launched a external GenFds.py to generate
> Fd, so the global variable in GenFds.py was reset in each execution.
>
> After commit b3497b, each GenFds run in the same python interpeter, so
> we need to explicitly reset global variable in each GenFdsApi call.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng
> Cc: Liming Gao
> Cc: Ard Biesheuvel
Tested-by: Ard Biesheuvel
> ---
> BaseTools/Source/Python/GenFds/GenFds.py | 51
> 1 file changed, 51 insertions(+)
>
> diff --git a/BaseTools/Source/Python/GenFds/GenFds.py
> b/BaseTools/Source/Python/GenFds/GenFds.py
> index 51655cc09c..447aa7f5eb 100644
> --- a/BaseTools/Source/Python/GenFds/GenFds.py
> +++ b/BaseTools/Source/Python/GenFds/GenFds.py
> @@ -39,10 +39,12 @@ from Common.BuildToolError import FatalError,
> GENFDS_ERROR, CODE_ERROR, FORMAT_I
> from Workspace.WorkspaceDatabase import WorkspaceDatabase
>
> from .FdfParser import FdfParser, Warning
> from .GenFdsGlobalVariable import GenFdsGlobalVariable
> from .FfsFileStatement import FileStatement
> +import Common.DataType as DataType
> +from struct import Struct
>
> ## Version and Copyright
> versionNumber = "1.0" + ' ' + gBUILD_VERSION
> __version__ = "%prog Version " + versionNumber
> __copyright__ = "Copyright (c) 2007 - 2018, Intel Corporation All rights
> reserved."
> @@ -60,15 +62,64 @@ def main():
> global Options
> Options = myOptionParser()
> EdkLogger.Initialize()
> return GenFdsApi(OptionsToCommandDict(Options))
>
> +def resetFdsGlobalVariable():
> +GenFdsGlobalVariable.FvDir = ''
> +GenFdsGlobalVariable.OutputDirDict = {}
> +GenFdsGlobalVariable.BinDir = ''
> +# will be FvDir + os.sep + 'Ffs'
> +GenFdsGlobalVariable.FfsDir = ''
> +GenFdsGlobalVariable.FdfParser = None
> +GenFdsGlobalVariable.LibDir = ''
> +GenFdsGlobalVariable.WorkSpace = None
> +GenFdsGlobalVariable.WorkSpaceDir = ''
> +GenFdsGlobalVariable.ConfDir = ''
> +GenFdsGlobalVariable.EdkSourceDir = ''
> +GenFdsGlobalVariable.OutputDirFromDscDict = {}
> +GenFdsGlobalVariable.TargetName = ''
> +GenFdsGlobalVariable.ToolChainTag = ''
> +GenFdsGlobalVariable.RuleDict = {}
> +GenFdsGlobalVariable.ArchList = None
> +GenFdsGlobalVariable.VtfDict = {}
> +GenFdsGlobalVariable.ActivePlatform = None
> +GenFdsGlobalVariable.FvAddressFileName = ''
> +GenFdsGlobalVariable.VerboseMode = False
> +GenFdsGlobalVariable.DebugLevel = -1
> +GenFdsGlobalVariable.SharpCounter = 0
> +GenFdsGlobalVariable.SharpNumberPerLine = 40
> +GenFdsGlobalVariable.FdfFile = ''
> +GenFdsGlobalVariable.FdfFileTimeStamp = 0
> +GenFdsGlobalVariable.FixedLoadAddress = False
> +GenFdsGlobalVariable.PlatformName = ''
> +
> +GenFdsGlobalVariable.BuildRuleFamily = DataType.TAB_COMPILER_MSFT
> +GenFdsGlobalVariable.ToolChainFamily = DataType.TAB_COMPILER_MSFT
> +GenFdsGlobalVariable.__BuildRuleDatabase = None
> +GenFdsGlobalVariable.GuidToolDefinition = {}
> +GenFdsGlobalVariable.FfsCmdDict = {}
> +GenFdsGlobalVariable.SecCmdList = []
> +GenFdsGlobalVariable.CopyList = []
> +GenFdsGlobalVariable.ModuleFile = ''
> +GenFdsGlobalVariable.EnableGenfdsMultiThread = False
> +
> +GenFdsGlobalVariable.LargeFileInFvFlags = []
> +GenFdsGlobalVariable.EFI_FIRMWARE_FILE_SYSTEM3_GUID =
> '5473C07A-3DCB-4dca-BD6F-1E9689E7349A'
> +GenFdsGlobalVariable.LARGE_FILE_SIZE = 0x100
> +
> +GenFdsGlobalVariable.SectionHeader = Struct("3B 1B")
> +
> +# FvName, FdName, CapName in FDF, Image file name
> +GenFdsGlobalVariable.ImageBinDict = {}
> +
> def GenFdsApi(FdsCommandDict, WorkSpaceDataBase=None):
> global Workspace
> Workspace = ""
> ArchList = None
> ReturnCode = 0
> +resetFdsGlobalVariable()
>
> try:
> if FdsCommandDict.get("verbose"):
> EdkLogger.SetLevel(EdkLogger.VERBOSE)
> GenFdsGlobalVariable.VerboseMode = True
> --
> 2.19.1.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 2/4] ArmPlatformPkg/SP805WatchdogDxe: switch to interrupt mode
On Wed, Dec 19, 2018 at 09:40:21PM +0100, Ard Biesheuvel wrote:
> The SP805 watchdog driver doesn't implement the PI watchdog protocol
> fully, but always simply resets the system if the watchdog time runs
> out.
>
> However, the hardware does support the intended usage model, as long
> as the SP805 is wired up correctly. So let's implement interrupt based
> mode involving a handler that is registered by the DXE core and invoked
> when the watchdog runs out. In the interrupt handler, we invoke the
> notify function if one was registered, or call the ResetSystem()
> runtime service otherwise (as per the UEFI spec)
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPlatformPkg/ArmPlatformPkg.dec| 1 +
> ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf | 6 +-
> ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c | 100
> +++-
> 3 files changed, 80 insertions(+), 27 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> b/ArmPlatformPkg/ArmPlatformPkg.dec
> index 5f67e7415469..44c00bd0c133 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> @@ -70,6 +70,7 @@ [PcdsFixedAtBuild.common]
>## SP805 Watchdog
>gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x0|UINT32|0x0023
>
> gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz|32000|UINT32|0x0021
> + gArmPlatformTokenSpaceGuid.PcdSP805WatchdogInterrupt|0|UINT32|0x002E
>
>## PL011 UART
>gArmPlatformTokenSpaceGuid.PL011UartClkInHz|2400|UINT32|0x001F
> diff --git a/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
> b/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
> index c3971fb035d3..0e744deeca8d 100644
> --- a/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
> +++ b/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
> @@ -27,6 +27,7 @@ [Sources.common]
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmPlatformPkg/ArmPlatformPkg.dec
> + EmbeddedPkg/EmbeddedPkg.dec
>MdePkg/MdePkg.dec
>
> [LibraryClasses]
> @@ -35,13 +36,16 @@ [LibraryClasses]
>IoLib
>UefiBootServicesTableLib
>UefiDriverEntryPoint
> + UefiRuntimeServicesTableLib
>
> [Pcd]
>gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase
>gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz
> + gArmPlatformTokenSpaceGuid.PcdSP805WatchdogInterrupt
>
> [Protocols]
> + gHardwareInterruptProtocolGuid ## ALWAYS_CONSUMES
>gEfiWatchdogTimerArchProtocolGuid ## ALWAYS_PRODUCES
>
> [Depex]
> - TRUE
> + gHardwareInterruptProtocolGuid
> diff --git a/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> b/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> index 12c2f0a1fe49..5bbb12af6019 100644
> --- a/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> +++ b/ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
> @@ -21,12 +21,17 @@
> #include
> #include
> #include
> +#include
>
> +#include
> #include
>
> #include "SP805Watchdog.h"
>
> -STATIC EFI_EVENT mEfiExitBootServicesEvent;
> +STATIC EFI_EVENTmEfiExitBootServicesEvent;
> +STATIC EFI_HARDWARE_INTERRUPT_PROTOCOL *mInterrupt;
> +STATIC EFI_WATCHDOG_TIMER_NOTIFYmWatchdogNotify;
> +STATIC UINT32 mTimerPeriod;
>
> /**
>Make sure the SP805 registers are unlocked for writing.
> @@ -65,6 +70,33 @@ SP805Lock (
>}
> }
>
> +STATIC
> +VOID
> +EFIAPI
> +SP805InterruptHandler (
> + IN HARDWARE_INTERRUPT_SOURCE Source,
> + IN EFI_SYSTEM_CONTEXT SystemContext
> + )
> +{
> + SP805Unlock ();
> + MmioWrite32 (SP805_WDOG_INT_CLR_REG, 0); // write of any value clears the
> irq
> + SP805Lock ();
> +
> + mInterrupt->EndOfInterrupt (mInterrupt, Source);
> +
> + //
> + // The notify function should be called with the elapsed number of ticks
> + // since the watchdog was armed, which should exceed the timer period.
> + // We don't actually know the elapsed number of ticks, so let's return
> + // the timer period plus 1.
> + //
> + if (mWatchdogNotify != NULL) {
> +mWatchdogNotify (mTimerPeriod + 1);
> + }
> +
> + gRT->ResetSystem (EfiResetCold, EFI_TIMEOUT, 0, NULL);
> +}
> +
> /**
>Stop the SP805 watchdog timer from counting down by disabling interrupts.
> **/
> @@ -149,9 +181,16 @@ SP805RegisterHandler (
>IN EFI_WATCHDOG_TIMER_NOTIFYNotifyFunction
>)
> {
> - // ERROR: This function is not supported.
> - // The hardware watchdog will reset the board
> - return EFI_INVALID_PARAMETER;
> + if (mWatchdogNotify == NULL && NotifyFunction == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
> + if (mWatchdogNotify != NULL && NotifyFunction != NULL) {
> +return EFI_ALREADY_STARTED;
> + }
> +
> + mWatchdogNotify = NotifyFunction;
> + return
Re: [edk2] [PATCH v2 0/4] ArmPkg, ArmPlatformPkg: watchdog driver cleanup
On Wed, 19 Dec 2018 at 21:40, Ard Biesheuvel wrote: > > This series cleans up the code of the two watchdog drivers we have for > ARM systems, and brings them in compliance with the PI spec, which > specifies that the default action of the watchdog can be overridden > by registering a handler. > > Note that the TC2 code in edk2-platforms will have to be brought up to > date. The SP805 on the FVP model seems terminally broken (it is 'wired' > to the 24 MHz APB clock instead of the 32 kHz WDOG clock, so I'll switch > that one over to use the SBSA watchdog instead) > > Changes since v1: > - always fall back to calling gRT_>ResetSystem() if the registered handler > returns > - WARN() if running the SP805 driver with interrupt handling disabled > - add some R-bs > > Cc: Leif Lindholm > Cc: Sami Mujawar > Cc: Thomas Panakamattam Abraham > Cc: Meenakshi Aggarwal > Cc: Udit Kumar > Cc: Matteo Carlini > Cc: Nariman Poushin > > Ard Biesheuvel (4): > ArmPlatformPkg/SP805WatchdogDxe: cosmetic cleanup > ArmPlatformPkg/SP805WatchdogDxe: switch to interrupt mode > ArmPkg/GenericWatchdogDxe: clean up the code > ArmPkg/GenericWatchdogDxe: implement RegisterHandler() method > Pushed as 87b920fe22be..ba808d11f6a3 Thanks all ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Question about hotplugging NIC devices to an empty pci-bridge
Hi all, The issue occurs when I started a virtual machine in UEFI way by libvirt on qemu-kvm platform, the vm is configured with 8 pci-bridges on root bus0. I hotplug a device like virtual nic to an empty pci-bridge which has no device connected. Login the vm, I can see the device by "lspci"", but it didn't show by "ifconfig -a". Dmesg shows like below: pci :04:01.0: BAR 0: no space for [mem size 0x0001 64bit pref] pci :04:01.0: BAR 0: failed to assign [mem size 0x0001 64bit pref] pci :04:01.0: BAR 3: no space for [mem size 0x4000 64bit pref] pci :04:01.0: BAR 3: failed to assign [mem size 0x4000 64bit pref] Reboot the vm, everything turns back to normal and I can see the new hotplugged nic by "ifconfig -a". Use the OVMF compiling from latest edk2 source code, the same problem arises. So, my questions are: 1) the generic PCI bus driver in edk2 does not allocate IO and/or MMIO for a bridge if there is no device behind the bridge that consume that kind of resource? 2) What's the purpose of this strategy? 3) Why don't allocate resource to all bridges like seabios? 4) Is there any switch for me to turn off this constraint so that every pci-bridge including empty ones can be assigned IO and memory window? Otherwise, each time I hotplug a device to empty pci-bridge, a reboot operation should be implemented to use the device? Any help will be appreciated, Thanks! ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] BaseTools: Reset FdsGlobalVariable
https://bugzilla.tianocore.org/show_bug.cgi?id=1418
This patch is going to fix a regression issue that is introduced
by commit b3497bad1221704a5dbc5da0b10f42625f1ad2ed.
Before commit b3497b, build launched a external GenFds.py to generate
Fd, so the global variable in GenFds.py was reset in each execution.
After commit b3497b, each GenFds run in the same python interpeter, so
we need to explicitly reset global variable in each GenFdsApi call.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng
Cc: Liming Gao
Cc: Ard Biesheuvel
---
BaseTools/Source/Python/GenFds/GenFds.py | 51
1 file changed, 51 insertions(+)
diff --git a/BaseTools/Source/Python/GenFds/GenFds.py
b/BaseTools/Source/Python/GenFds/GenFds.py
index 51655cc09c..447aa7f5eb 100644
--- a/BaseTools/Source/Python/GenFds/GenFds.py
+++ b/BaseTools/Source/Python/GenFds/GenFds.py
@@ -39,10 +39,12 @@ from Common.BuildToolError import FatalError, GENFDS_ERROR,
CODE_ERROR, FORMAT_I
from Workspace.WorkspaceDatabase import WorkspaceDatabase
from .FdfParser import FdfParser, Warning
from .GenFdsGlobalVariable import GenFdsGlobalVariable
from .FfsFileStatement import FileStatement
+import Common.DataType as DataType
+from struct import Struct
## Version and Copyright
versionNumber = "1.0" + ' ' + gBUILD_VERSION
__version__ = "%prog Version " + versionNumber
__copyright__ = "Copyright (c) 2007 - 2018, Intel Corporation All rights
reserved."
@@ -60,15 +62,64 @@ def main():
global Options
Options = myOptionParser()
EdkLogger.Initialize()
return GenFdsApi(OptionsToCommandDict(Options))
+def resetFdsGlobalVariable():
+GenFdsGlobalVariable.FvDir = ''
+GenFdsGlobalVariable.OutputDirDict = {}
+GenFdsGlobalVariable.BinDir = ''
+# will be FvDir + os.sep + 'Ffs'
+GenFdsGlobalVariable.FfsDir = ''
+GenFdsGlobalVariable.FdfParser = None
+GenFdsGlobalVariable.LibDir = ''
+GenFdsGlobalVariable.WorkSpace = None
+GenFdsGlobalVariable.WorkSpaceDir = ''
+GenFdsGlobalVariable.ConfDir = ''
+GenFdsGlobalVariable.EdkSourceDir = ''
+GenFdsGlobalVariable.OutputDirFromDscDict = {}
+GenFdsGlobalVariable.TargetName = ''
+GenFdsGlobalVariable.ToolChainTag = ''
+GenFdsGlobalVariable.RuleDict = {}
+GenFdsGlobalVariable.ArchList = None
+GenFdsGlobalVariable.VtfDict = {}
+GenFdsGlobalVariable.ActivePlatform = None
+GenFdsGlobalVariable.FvAddressFileName = ''
+GenFdsGlobalVariable.VerboseMode = False
+GenFdsGlobalVariable.DebugLevel = -1
+GenFdsGlobalVariable.SharpCounter = 0
+GenFdsGlobalVariable.SharpNumberPerLine = 40
+GenFdsGlobalVariable.FdfFile = ''
+GenFdsGlobalVariable.FdfFileTimeStamp = 0
+GenFdsGlobalVariable.FixedLoadAddress = False
+GenFdsGlobalVariable.PlatformName = ''
+
+GenFdsGlobalVariable.BuildRuleFamily = DataType.TAB_COMPILER_MSFT
+GenFdsGlobalVariable.ToolChainFamily = DataType.TAB_COMPILER_MSFT
+GenFdsGlobalVariable.__BuildRuleDatabase = None
+GenFdsGlobalVariable.GuidToolDefinition = {}
+GenFdsGlobalVariable.FfsCmdDict = {}
+GenFdsGlobalVariable.SecCmdList = []
+GenFdsGlobalVariable.CopyList = []
+GenFdsGlobalVariable.ModuleFile = ''
+GenFdsGlobalVariable.EnableGenfdsMultiThread = False
+
+GenFdsGlobalVariable.LargeFileInFvFlags = []
+GenFdsGlobalVariable.EFI_FIRMWARE_FILE_SYSTEM3_GUID =
'5473C07A-3DCB-4dca-BD6F-1E9689E7349A'
+GenFdsGlobalVariable.LARGE_FILE_SIZE = 0x100
+
+GenFdsGlobalVariable.SectionHeader = Struct("3B 1B")
+
+# FvName, FdName, CapName in FDF, Image file name
+GenFdsGlobalVariable.ImageBinDict = {}
+
def GenFdsApi(FdsCommandDict, WorkSpaceDataBase=None):
global Workspace
Workspace = ""
ArchList = None
ReturnCode = 0
+resetFdsGlobalVariable()
try:
if FdsCommandDict.get("verbose"):
EdkLogger.SetLevel(EdkLogger.VERBOSE)
GenFdsGlobalVariable.VerboseMode = True
--
2.19.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/Arm/ProcessorBind.h: fix copy/paste error
On Thu, 20 Dec 2018 at 12:21, Leif Lindholm wrote: > > On Thu, Dec 20, 2018 at 12:12:01PM +0100, Ard Biesheuvel wrote: > > Instead of #defining MAX_ALLOC_ADDRESS to MAX_ADDRESS as intended, > > it is #defined to itself, causing all ARM builds to break. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > Reviewed-by: Leif Lindholm > Pushed as 4a1500db2b42..87b920fe22be (with Leif's ack) > > --- > > > > Apologies for the breakage. Please ack asap. > > > > MdePkg/Include/Arm/ProcessorBind.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/MdePkg/Include/Arm/ProcessorBind.h > > b/MdePkg/Include/Arm/ProcessorBind.h > > index 16a61fc7a325..0b7b486125f9 100644 > > --- a/MdePkg/Include/Arm/ProcessorBind.h > > +++ b/MdePkg/Include/Arm/ProcessorBind.h > > @@ -151,7 +151,7 @@ typedef INT32 INTN; > > /// > > /// Maximum usable address at boot time > > /// > > -#define MAX_ALLOC_ADDRESS MAX_ALLOC_ADDRESS > > +#define MAX_ALLOC_ADDRESS MAX_ADDRESS > > > > /// > > /// Maximum legal ARM INTN and UINTN values. > > -- > > 2.19.2 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/Arm/ProcessorBind.h: fix copy/paste error
On Thu, Dec 20, 2018 at 12:12:01PM +0100, Ard Biesheuvel wrote: > Instead of #defining MAX_ALLOC_ADDRESS to MAX_ADDRESS as intended, > it is #defined to itself, causing all ARM builds to break. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > > Apologies for the breakage. Please ack asap. > > MdePkg/Include/Arm/ProcessorBind.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MdePkg/Include/Arm/ProcessorBind.h > b/MdePkg/Include/Arm/ProcessorBind.h > index 16a61fc7a325..0b7b486125f9 100644 > --- a/MdePkg/Include/Arm/ProcessorBind.h > +++ b/MdePkg/Include/Arm/ProcessorBind.h > @@ -151,7 +151,7 @@ typedef INT32 INTN; > /// > /// Maximum usable address at boot time > /// > -#define MAX_ALLOC_ADDRESS MAX_ALLOC_ADDRESS > +#define MAX_ALLOC_ADDRESS MAX_ADDRESS > > /// > /// Maximum legal ARM INTN and UINTN values. > -- > 2.19.2 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdePkg/Arm/ProcessorBind.h: fix copy/paste error
Instead of #defining MAX_ALLOC_ADDRESS to MAX_ADDRESS as intended, it is #defined to itself, causing all ARM builds to break. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Apologies for the breakage. Please ack asap. MdePkg/Include/Arm/ProcessorBind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MdePkg/Include/Arm/ProcessorBind.h b/MdePkg/Include/Arm/ProcessorBind.h index 16a61fc7a325..0b7b486125f9 100644 --- a/MdePkg/Include/Arm/ProcessorBind.h +++ b/MdePkg/Include/Arm/ProcessorBind.h @@ -151,7 +151,7 @@ typedef INT32 INTN; /// /// Maximum usable address at boot time /// -#define MAX_ALLOC_ADDRESS MAX_ALLOC_ADDRESS +#define MAX_ALLOC_ADDRESS MAX_ADDRESS /// /// Maximum legal ARM INTN and UINTN values. -- 2.19.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Platform/FVP-AArch64: switch to the SBSA watchdog
On Thu, 20 Dec 2018 at 11:03, Thomas Abraham wrote: > > On Wed, Dec 19, 2018 at 10:04 PM Leif Lindholm > wrote: > > > > On Tue, Dec 18, 2018 at 05:46:21PM +0100, Ard Biesheuvel wrote: > > > On the FVP Foundation model, the SP805 watchdog appears to be 'wired' > > > incorrectly, resulting in a watchdog counter that decrements at the > > > APB clock rate of 24 MHz instead of the usual 32 kHz. Since the > > > timer start value is only 32-bits wide, this makes the watchdog > > > unusable in UEFI, since the default timeout set by the DXE core is > > > 5 minutes, which is not representable in 32-bit at this clock rate. > > > > > > So switch to the SBSA watchdog instead, which is wired up to the > > > generic timer, and ticks at the correct rate. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Ard Biesheuvel > > > > From my point of view: > > Reviewed-by: Leif Lindholm > > > > But I'd like a nod from Sami or Thomas (added to cc) as well. > > I have not been able test this patch yet but the changes looks fine. > > - Thomas. > Thanks all Pushed as dc6b5ef8a6c2..88e5de1a2346 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2] BaseTools/tools_def ARM: use softfloat target for CLANG3x
The 'arm-linux-gnueabihf' target triplet we use for CLANG35 and CLANG38 specifies a hardfloat target, and so the binaries that are emitted are annotated as using VFP registers for passing floating point arguments, even though no VFP is used anywhere in the code. This works fine as long as we don't try to link against code that uses software floating point, but combining object files with different floating point calling conventions is not permitted. So switch to the softfloat arm-linux-gnueabi triplet instead. This affects both the name Clang uses when invoking the linker, and the arguments it passes to it, and we are mostly interested in the latter (since any version of GNU ld.bfd will do the right thing as long as it targets EABI ARM) For native builds, this change has no effect, since the unprefixed system linker will take priority, and so Clang will pass the right arguments to whichever linker happens to be the system linker. For cross builds, the fact that Clang composes the name of the linker by prefixing '-ld' with the target triplet implies that users will have to switch to a version of binutils that targets arm-linux-gnueabi rather than arm-linux-gnueabihf. Note that the GCCx toolchain targets can use either when building for ARM so this does not create a need to install two versions of the ARM cross toolchain. Also, note that all ARM toolchains in the GCC family are already documented as requiring a toolchain that targets arm-linux-gnueabi and not arm-linux-gnueabihf. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- v2: improve commit log BaseTools/Conf/tools_def.template | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 902680c24c85..f7eb87af14c2 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -5231,7 +5231,7 @@ RELEASE_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20 *_CLANG35_*_DLINK_PATH = ENV(CLANG35_BIN)clang *_CLANG35_*_ASLDLINK_PATH= ENV(CLANG35_BIN)clang -DEFINE CLANG35_ARM_TARGET= -target arm-linux-gnueabihf +DEFINE CLANG35_ARM_TARGET= -target arm-linux-gnueabi DEFINE CLANG35_AARCH64_TARGET= -target aarch64-linux-gnu DEFINE CLANG35_WARNING_OVERRIDES = -Wno-parentheses-equality -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare -Wno-empty-body -Wno-unknown-warning-option @@ -5384,7 +5384,7 @@ NOOPT_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS) -O0 ## # CLANG38 ARM definitions ## -DEFINE CLANG38_ARM_TARGET= -target arm-linux-gnueabihf +DEFINE CLANG38_ARM_TARGET= -target arm-linux-gnueabi DEFINE CLANG38_ARM_CC_FLAGS = DEF(GCC_ARM_CC_FLAGS) DEF(CLANG38_ARM_TARGET) DEF(CLANG38_WARNING_OVERRIDES) -mno-movt DEFINE CLANG38_ARM_DLINK_FLAGS = DEF(CLANG38_ARM_TARGET) DEF(GCC_ARM_DLINK_FLAGS) -- 2.19.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 1/1] Silicon/SynQuacer: add OP-TEE based RNG driver
On Tue, 18 Dec 2018 at 13:46, Ard Biesheuvel wrote: > > On Tue, 18 Dec 2018 at 13:17, Sumit Garg wrote: > > > > Hi Ard, > > > > On Wed, 12 Dec 2018 at 11:05, Sumit Garg wrote: > > > > > > On Tue, 11 Dec 2018 at 21:37, Ard Biesheuvel > > > wrote: > > > > > > > > On Tue, 11 Dec 2018 at 10:06, Ard Biesheuvel > > > > wrote: > > > > > > > > > > On Tue, 11 Dec 2018 at 10:04, Sumit Garg > > > > > wrote: > > > > > > > > > > > > On Tue, 11 Dec 2018 at 13:56, Ard Biesheuvel > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 11 Dec 2018 at 08:46, Sumit Garg > > > > > > > wrote: > > > > > > > > > > > > > > > > This driver uses OpteeLib to interface with OP-TEE based RNG > > > > > > > > service > > > > > > > > (pseudo trusted application) to implement EFI_RNG_PROTOCOL that > > > > > > > > is used > > > > > > > > to seed kernel entropy pool. > > > > > > > > > > > > > > > > Cc: Ard Biesheuvel > > > > > > > > Cc: Leif Lindholm > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > > > > Signed-off-by: Sumit Garg > > > > > > > > > > > > > > Excellent! Happy to see this code going upstream. > > > > > > > > > > > > > > > > > > > Thanks Ard. > > > > > > > > > > > > > This code looks fine to me, but I'd like to test it with an > > > > > > > updated > > > > > > > OP-TEE build first before I merge it. > > > > > > > > > > > > > > > > > > > Agree, will wait for OP-TEE PR to be merged. BTW, if you need I > > > > > > could > > > > > > share updated "fip_all_arm_tf.bin" using OP-TEE PR for testing. > > > > > > > > > > > > > > > > Yes please, that would be useful. > > > > > > > > > > > > > > > > > > OK, I successfully tested this patch on my SynQuacer box. Very nice > > > > work! > > > > > > > > > > Thanks Ard for testing this patch. > > > > > > > So this is ready to go in as soon as the OP-TEE side is merged as > > > > well, so please keep me informed about that (and contribute a new > > > > ARM-TF + OP-TEE build to edk2-non-osi) > > > > > > Sure will let you know about OP-TEE PR merge and yes will contribute a > > > new ARM-TF + OP-TEE build to edk2-non-osi. > > > > > > > OP-TEE PR [1] has been merged. Also I have sent a patch to contribute > > new ARM-TF + OP-TEE build. Please have a look. > > > > [1] https://github.com/OP-TEE/optee_os/pull/2564 > > > > Wonderful! Thanks a lot. Reviewed-by: Ard Biesheuvel Pushed as c955b5129771..dc6b5ef8a6c2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi 1/1] Platform/Socionext: update ARM-TF binary to include OP-TEE
On Thu, 20 Dec 2018 at 06:34, Sumit Garg wrote: > > On Wed, 19 Dec 2018 at 20:37, Ard Biesheuvel > wrote: > > > > On Tue, 18 Dec 2018 at 14:05, Ard Biesheuvel > > wrote: > > > > > > On Tue, 18 Dec 2018 at 14:04, Sumit Garg wrote: > > > > > > > > On Tue, 18 Dec 2018 at 18:30, Ard Biesheuvel > > > > wrote: > > > > > > > > > > On Tue, 18 Dec 2018 at 13:58, Sumit Garg > > > > > wrote: > > > > > > > > > > > > On Tue, 18 Dec 2018 at 18:16, Ard Biesheuvel > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 18 Dec 2018 at 13:09, Sumit Garg > > > > > > > wrote: > > > > > > > > > > > > > > > > Include a prebuilt binary of OP-TEE OS built from commit > > > > > > > > a5d528c7e54fd7726230483bd4cd5c4786d7703f. > > > > > > > > (https://github.com/OP-TEE/optee_os.git master) > > > > > > > > > > > > > > > > Also update ARM-TF RELEASE build to commit 47577cbaaf4b. > > > > > > > > > > > > > > > > Cc: Ard Biesheuvel > > > > > > > > Cc: Leif Lindholm > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > > > > Signed-off-by: Sumit Garg > > > > > > > > --- > > > > > > > > Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin | Bin 46824 > > > > > > > > -> 415251 bytes > > > > > > > > > > > > > > Thanks Sumit! > > > > > > > > > > > > > > In the future, please use --no-binary when sending patches like > > > > > > > this one. > > > > > > > > > > > > > > > > > > > Sure will take care of this in future. > > > > > > > > > > > > > However, do you have any explanation why the size increases 10x? > > > > > > > This > > > > > > > patch adds the pseudo-TA, but OP-TEE was already included in the > > > > > > > previous build, so this is a bit unexpected. > > > > > > > > > > > > > > > > > > > Actually I think ARM-TF was not updated earlier to include OP-TEE in > > > > > > upstream (tee.bin size: 316392 bytes). > > > > > > > > > > > > > > > > Ah, right. So we added the OP-TEE aware ATF build but not OP-TEE > > > > > itself? That would indeed explain it. > > > > > > > > We didn't updated ATF build at all in upstream. I think you have > > > > updated ATF build in local repo [1] only. > > > > > > > > [1] git://git.linaro.org/leg/noupstream/edk2-non-osi.git > > > > > > > > > > Indeed. > > > > I cannot apply this patch. Could you please rebase it to latest > > upstream edk2-non-osi and send me a link to the repo? > > Here is the link [1] to upstream repo with this patch applied. > > [1] ssh://g...@git.linaro.org/people/sumit.garg/edk2-non-osi.git > Thanks Sumit. I triggered a new capsule build with this image (#48) Reviewed-by: Ard Biesheuvel Pushed as 047bb77dd938..1e2ca640be54 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/6] introduce MAX_ALLOC_ADDRESS to limit boot time allocations
On Wed, 19 Dec 2018 at 21:56, Ard Biesheuvel wrote: > > Since modifying MAX_ADDRESS to limit the memory used at boot time has > turned out to be intractible, this series proposes another approach to do > the same, by introducing MAX_ALLOC_ADDRESS for firmware internal use. > > I tested these patches with ArmVirtQemu in the following way: > - limit MAX_ALLOC_ADDRESS to 0x (4 GB) > - build QEMU_EFI.fd > - run it under mach-virt with 4 GB of DRAM and highmem=off > > This runs as expected, and produces a memory map ending in the following > lines > > BS_DataD000- 0003 0008 > Available 0001-00013FFF 0004 0008 > > which proves that the memory above the limit is recorded and reported by > the OS, but left untouched by the firmware memory allocation routines. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Jian J Wang > Cc: Hao Wu > Cc: Leif Lindholm > Cc: Laszlo Ersek > Cc: Eric Auger > Cc: Andrew Jones > Cc: Philippe Mathieu-Daude > > Ard Biesheuvel (6): > MdePkg/Base: introduce MAX_ALLOC_ADDRESS > MdeModulePkg/Dxe/Gcd: disregard memory above MAX_ALLOC_ADDRESS > MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account > ArmPkg/ArmMmuLib: take MAX_ALLOC_ADDRESS into account > ArmPlatformPkg/MemoryInitPeim: take MAX_ALLOC_ADDRESS into account > ArmVirtPkg/MemoryInitPeiLib: split memory HOB based on > MAX_ALLOC_ADDRESS > Pushed as 5c8bc8be9e5e..4a1500db2b42 Thanks all ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2] BaseTools: AutoGen and GenFds share the parser data.
OK. I'll look at this issue.
Thanks,
Bob
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, December 20, 2018 6:28 PM
To: Zhao, ZhiqiangX ; Gao, Liming
; Feng, Bob C
Cc: edk2-devel@lists.01.org; Carsey, Jaben
Subject: Re: [edk2] [PATCH V2] BaseTools: AutoGen and GenFds share the parser
data.
On Fri, 23 Nov 2018 at 08:04, Zhaozh1x wrote:
>
> V2:
> Extract the common part of new API and the original main() function
> into one function.
>
> V1:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1288
>
> Currently, AutoGen and GenFds run in different python interpreters.
> The parser are duplicated. This patch is going to create new API for
> GenFds and have the build to call that API instead of executing
> GenFds.py. As such, the GenFds and build can share the parser data.
>
> This patch is expected to save the time of GenFds about 2~3 seconds.
> More details will be logged in BZ.
>
> This is the summary measure data generated from python cProfile for
> building Ovmf.
>
> Currently:
> 8379147 function calls (8135450 primitive calls) in 12.580 seconds
>
> After applying this patch:
> 3428712 function calls (3418881 primitive calls) in 8.944 seconds
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: ZhiqiangX Zhao
> Cc: Liming Gao
> Cc: Carsey Jaben
> Cc: Bob Feng
> ---
> BaseTools/Source/Python/AutoGen/AutoGen.py | 4 +
> BaseTools/Source/Python/GenFds/GenFds.py | 141
> ++---
> BaseTools/Source/Python/build/build.py | 6 +-
> 3 files changed, 94 insertions(+), 57 deletions(-)
>
I am currently seeing a regression which is probably caused by this change (or
a related one)
When building several targets at a time, e.g.,
build -p -b DEBUG -b RELEASE
only the first one gets built completely (including the FD image), and the
latter one is only built partially.
I filed a bug here
https://bugzilla.tianocore.org/show_bug.cgi?id=1418
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index f3560bfc78..10ce7eb962 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -935,6 +935,10 @@ class WorkspaceAutoGen(AutoGen):
> def GenFdsCommand(self):
> return
> (GenMake.TopLevelMakefile(self)._TEMPLATE_.Replace(GenMake.TopLevelMak
> efile(self)._TemplateDict)).strip()
>
> +@property
> +def GenFdsCommandDict(self):
> +return GenMake.TopLevelMakefile(self)._TemplateDict
> +
> ## Create makefile for the platform and modules in it
> #
> # @param CreateDepsMakeFile Flag indicating if the makefile
> for
> diff --git a/BaseTools/Source/Python/GenFds/GenFds.py
> b/BaseTools/Source/Python/GenFds/GenFds.py
> index 0c8091b798..d24091c06c 100644
> --- a/BaseTools/Source/Python/GenFds/GenFds.py
> +++ b/BaseTools/Source/Python/GenFds/GenFds.py
> @@ -35,7 +35,7 @@ from Common.Misc import DirCache, PathClass,
> GuidStructureStringToGuidString from Common.Misc import
> SaveFileOnChange, ClearDuplicatedInf from Common.BuildVersion import
> gBUILD_VERSION from Common.MultipleWorkspace import MultipleWorkspace
> as mws -from Common.BuildToolError import FatalError, GENFDS_ERROR,
> CODE_ERROR, FORMAT_INVALID, RESOURCE_NOT_AVAILABLE, FILE_NOT_FOUND,
> OPTION_MISSING, FORMAT_NOT_SUPPORTED,OPTION_VALUE_INVALID
> +from Common.BuildToolError import FatalError, GENFDS_ERROR,
> +CODE_ERROR, FORMAT_INVALID, RESOURCE_NOT_AVAILABLE, FILE_NOT_FOUND,
> +OPTION_MISSING, FORMAT_NOT_SUPPORTED, OPTION_VALUE_INVALID,
> +PARAMETER_INVALID
> from Workspace.WorkspaceDatabase import WorkspaceDatabase
>
> from .FdfParser import FdfParser, Warning @@ -59,43 +59,45 @@
> __copyright__ = "Copyright (c) 2007 - 2018, Intel Corporation All
> rights reserv def main():
> global Options
> Options = myOptionParser()
> +EdkLogger.Initialize()
> +return GenFdsApi(OptionsToCommandDict(Options))
>
> +def GenFdsApi(FdsCommandDict, WorkSpaceDataBase=None):
> global Workspace
> Workspace = ""
> ArchList = None
> ReturnCode = 0
>
> -EdkLogger.Initialize()
> try:
> -if Options.verbose:
> +if FdsCommandDict.get("verbose"):
> EdkLogger.SetLevel(EdkLogger.VERBOSE)
> GenFdsGlobalVariable.VerboseMode = True
>
> -if Options.FixedAddress:
> +if FdsCommandDict.get("FixedAddress"):
> GenFdsGlobalVariable.FixedLoadAddress = True
>
> -if Options.quiet:
> +if FdsCommandDict.get("quiet"):
> EdkLogger.SetLevel(EdkLogger.QUIET)
> -if Options.debug:
> -EdkLogger.SetLevel(Options.debug + 1)
> -GenFdsGlobalVariable.DebugLevel = Options.debug
> +if FdsCommandDict.get("debug"):
> +EdkLogger.SetLevel(FdsCommandDict.get("debug") + 1)
> +GenFdsGlobalVariable.DebugLevel =
> + Fd
Re: [edk2] [PATCH V2] BaseTools: AutoGen and GenFds share the parser data.
On Fri, 23 Nov 2018 at 08:04, Zhaozh1x wrote:
>
> V2:
> Extract the common part of new API and the original main() function
> into one function.
>
> V1:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1288
>
> Currently, AutoGen and GenFds run in different python interpreters. The
> parser are duplicated. This patch is going to create new API for GenFds
> and have the build to call that API instead of executing GenFds.py. As
> such, the GenFds and build can share the parser data.
>
> This patch is expected to save the time of GenFds about 2~3 seconds.
> More details will be logged in BZ.
>
> This is the summary measure data generated from python cProfile for
> building Ovmf.
>
> Currently:
> 8379147 function calls (8135450 primitive calls) in 12.580 seconds
>
> After applying this patch:
> 3428712 function calls (3418881 primitive calls) in 8.944 seconds
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: ZhiqiangX Zhao
> Cc: Liming Gao
> Cc: Carsey Jaben
> Cc: Bob Feng
> ---
> BaseTools/Source/Python/AutoGen/AutoGen.py | 4 +
> BaseTools/Source/Python/GenFds/GenFds.py | 141
> ++---
> BaseTools/Source/Python/build/build.py | 6 +-
> 3 files changed, 94 insertions(+), 57 deletions(-)
>
I am currently seeing a regression which is probably caused by this
change (or a related one)
When building several targets at a time, e.g.,
build -p -b DEBUG -b RELEASE
only the first one gets built completely (including the FD image), and
the latter one is only built partially.
I filed a bug here
https://bugzilla.tianocore.org/show_bug.cgi?id=1418
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index f3560bfc78..10ce7eb962 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -935,6 +935,10 @@ class WorkspaceAutoGen(AutoGen):
> def GenFdsCommand(self):
> return
> (GenMake.TopLevelMakefile(self)._TEMPLATE_.Replace(GenMake.TopLevelMakefile(self)._TemplateDict)).strip()
>
> +@property
> +def GenFdsCommandDict(self):
> +return GenMake.TopLevelMakefile(self)._TemplateDict
> +
> ## Create makefile for the platform and modules in it
> #
> # @param CreateDepsMakeFile Flag indicating if the makefile
> for
> diff --git a/BaseTools/Source/Python/GenFds/GenFds.py
> b/BaseTools/Source/Python/GenFds/GenFds.py
> index 0c8091b798..d24091c06c 100644
> --- a/BaseTools/Source/Python/GenFds/GenFds.py
> +++ b/BaseTools/Source/Python/GenFds/GenFds.py
> @@ -35,7 +35,7 @@ from Common.Misc import DirCache, PathClass,
> GuidStructureStringToGuidString
> from Common.Misc import SaveFileOnChange, ClearDuplicatedInf
> from Common.BuildVersion import gBUILD_VERSION
> from Common.MultipleWorkspace import MultipleWorkspace as mws
> -from Common.BuildToolError import FatalError, GENFDS_ERROR, CODE_ERROR,
> FORMAT_INVALID, RESOURCE_NOT_AVAILABLE, FILE_NOT_FOUND, OPTION_MISSING,
> FORMAT_NOT_SUPPORTED,OPTION_VALUE_INVALID
> +from Common.BuildToolError import FatalError, GENFDS_ERROR, CODE_ERROR,
> FORMAT_INVALID, RESOURCE_NOT_AVAILABLE, FILE_NOT_FOUND, OPTION_MISSING,
> FORMAT_NOT_SUPPORTED, OPTION_VALUE_INVALID, PARAMETER_INVALID
> from Workspace.WorkspaceDatabase import WorkspaceDatabase
>
> from .FdfParser import FdfParser, Warning
> @@ -59,43 +59,45 @@ __copyright__ = "Copyright (c) 2007 - 2018, Intel
> Corporation All rights reserv
> def main():
> global Options
> Options = myOptionParser()
> +EdkLogger.Initialize()
> +return GenFdsApi(OptionsToCommandDict(Options))
>
> +def GenFdsApi(FdsCommandDict, WorkSpaceDataBase=None):
> global Workspace
> Workspace = ""
> ArchList = None
> ReturnCode = 0
>
> -EdkLogger.Initialize()
> try:
> -if Options.verbose:
> +if FdsCommandDict.get("verbose"):
> EdkLogger.SetLevel(EdkLogger.VERBOSE)
> GenFdsGlobalVariable.VerboseMode = True
>
> -if Options.FixedAddress:
> +if FdsCommandDict.get("FixedAddress"):
> GenFdsGlobalVariable.FixedLoadAddress = True
>
> -if Options.quiet:
> +if FdsCommandDict.get("quiet"):
> EdkLogger.SetLevel(EdkLogger.QUIET)
> -if Options.debug:
> -EdkLogger.SetLevel(Options.debug + 1)
> -GenFdsGlobalVariable.DebugLevel = Options.debug
> +if FdsCommandDict.get("debug"):
> +EdkLogger.SetLevel(FdsCommandDict.get("debug") + 1)
> +GenFdsGlobalVariable.DebugLevel = FdsCommandDict.get("debug")
> else:
> EdkLogger.SetLevel(EdkLogger.INFO)
>
> -if not Options.Workspace:
> +if not FdsCommandDict.get("Workspace",os.environ.get('WORKSPACE')):
> EdkLogger.error("GenFds", OPTION_MISSING, "WORKSPACE not
> defined",
> ExtraData="Please use '-w' switch to pass it
Re: [edk2] [PATCH edk2-platforms v2 3/3] Platform/ARM/SgiPkg: Enable MmCommunication module on the platform
On Thu Dec 20, 2018 at 09:52:46AM +0100, Ard Biesheuvel wrote: > On Thu, 20 Dec 2018 at 06:48, Sughosh Ganu wrote: > > > > The ArmMmCommunication module is used for communication between > > non-secure and secure world using Arm's Management Mode > > Specification. Enable this module on Sgi platforms. This would be used > > subsequently by the RAS and SecureBoot features, support for which > > is to be added on the platform. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Sughosh Ganu > > --- > > Platform/ARM/SgiPkg/SgiPlatform.dsc | 18 ++ > > Platform/ARM/SgiPkg/SgiPlatform.fdf | 5 + > > 2 files changed, 23 insertions(+) > > > > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc > > b/Platform/ARM/SgiPkg/SgiPlatform.dsc > > index 7995c7d132d6..948b75631a00 100644 > > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc > > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc > > @@ -197,6 +197,20 @@ [PcdsFixedAtBuild.common] > >gArmSgiTokenSpaceGuid.PcdVirtioNetSize|0x1 > >gArmSgiTokenSpaceGuid.PcdVirtioNetInterrupt|204 > > > > +!if $(ARM_STANDALONE_MM_ENABLE) == TRUE > > Why is this inclusion conditional (here and below)? I was under the > impression that the communicate driver fails gracefully if the secure > standalone MM is absent. If this is not the case, please propose how > to fix the core driver so that it does. I have tried it earlier, and it does fail gracefully -- will test it once more nonetheless before posting an updated version. -sughosh ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v2 1/3] Platform/ARM/SgiPkg: Build infrastructure for StandaloneMm image
On Thu Dec 20, 2018 at 09:46:34AM +0100, Ard Biesheuvel wrote: > On Thu, 20 Dec 2018 at 06:48, Sughosh Ganu wrote: > > > > Add the build infrastructure for compilation of StandaloneMm image > > files and FD file. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Sughosh Ganu > > --- > > Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 130 > > +++ > > Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 100 + > > 2 files changed, 230 insertions(+) > > create mode 100644 Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > > create mode 100644 Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > > > > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > > new file mode 100644 > > index ..4615c383c46a > > --- /dev/null > > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > > @@ -0,0 +1,130 @@ > > +# > > +# Copyright (c) 2018, ARM Limited. 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. > > +# > > + > > + > > +# > > +# Defines Section - statements that will be processed to create a Makefile. > > +# > > + > > +[Defines] > > + PLATFORM_NAME = sgi_mm_standalone > > Please use camel case Ok > > > + PLATFORM_GUID = 34B78C8F-CFD5-49D5-8360-E91143F6106D > > + PLATFORM_VERSION = 1.0 > > + DSC_SPECIFICATION = 0x00010011 > > + OUTPUT_DIRECTORY = Build/$(PLATFORM_NAME) > > + SUPPORTED_ARCHITECTURES= AARCH64|ARM > > Does this actually build for ARM? I haven't tried it. Will remove. > > > + BUILD_TARGETS = DEBUG|RELEASE > > Please include NOOPT Ok > > > + SKUID_IDENTIFIER = DEFAULT > > + FLASH_DEFINITION = > > Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > > + DEFINE DEBUG_MESSAGE = TRUE > > + > > + # LzmaF86 > > + DEFINE COMPRESSION_TOOL_GUID = D42AE6BD-1352-4bfb-909A-CA72A6EAE889 > > + > > + > > +# > > +# Library Class section - list of all Library Classes needed by this > > Platform. > > +# > > + > > +[LibraryClasses] > > + # > > + # Basic > > + # > > + BaseLib|MdePkg/Library/BaseLib/BaseLib.inf > > + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf > > + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf > > + > > DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf > > + FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf > > + > > HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf > > + IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf > > + MemLib|StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.inf > > + > > MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf > > + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf > > + PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf > > + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf > > + > > ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf > > + > > + # > > + # Entry point > > + # > > + > > StandaloneMmDriverEntryPoint|StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf > > + > > +[LibraryClasses.AARCH64] > > Are the pieces below specific to AARCH64? If not, drop the [] section header No, these are not specific to AArch64. Will remove the section header. > > > + ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf > > + > > StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf > > + ArmSvcLib|ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf > > + > > CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf > > + > > PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf > > + > > + # ARM PL011 UART Driver > > + > > PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf > > + PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf > > + > > SerialPortLib|ArmPl
Re: [edk2] [PATCH] Platform/FVP-AArch64: switch to the SBSA watchdog
On Wed, Dec 19, 2018 at 10:04 PM Leif Lindholm wrote: > > On Tue, Dec 18, 2018 at 05:46:21PM +0100, Ard Biesheuvel wrote: > > On the FVP Foundation model, the SP805 watchdog appears to be 'wired' > > incorrectly, resulting in a watchdog counter that decrements at the > > APB clock rate of 24 MHz instead of the usual 32 kHz. Since the > > timer start value is only 32-bits wide, this makes the watchdog > > unusable in UEFI, since the default timeout set by the DXE core is > > 5 minutes, which is not representable in 32-bit at this clock rate. > > > > So switch to the SBSA watchdog instead, which is wired up to the > > generic timer, and ticks at the correct rate. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > From my point of view: > Reviewed-by: Leif Lindholm > > But I'd like a nod from Sami or Thomas (added to cc) as well. I have not been able test this patch yet but the changes looks fine. - Thomas. > > > --- > > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 7 > > --- > > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf | 2 > > +- > > Platform/ARM/VExpressPkg/Include/Platform/RTSM/ArmPlatform.h | 3 > > +++ > > Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf | 3 > > +++ > > Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c | 7 > > ++- > > 5 files changed, 17 insertions(+), 5 deletions(-) > > > > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc > > b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc > > index 7db1c675c3d9..0941edeaf53c 100644 > > --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc > > +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc > > @@ -133,9 +133,10 @@ > >gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17 > > > >## SBSA Watchdog Count > > -!ifndef DISABLE_SBSA_WATCHDOG > >gArmPlatformTokenSpaceGuid.PcdWatchdogCount|1 > > -!endif > > + gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0x2a44 > > + gArmTokenSpaceGuid.PcdGenericWatchdogRefreshBase|0x2a45 > > + gArmTokenSpaceGuid.PcdGenericWatchdogEl2IntrNum|59 > > > > !ifdef EDK2_ENABLE_PL111 > >## PL111 Versatile Express Motherboard controller > > @@ -265,7 +266,7 @@ > > !ifdef EDK2_ENABLE_PL111 > >ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf > > !endif > > - ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf > > + ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf > > > ># SMBIOS Support > > > > diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf > > b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf > > index 239029d05cf1..c3e573e1bb4f 100644 > > --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf > > +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf > > @@ -116,7 +116,7 @@ FvNameGuid = > > 87940482-fc81-41c3-87e6-399cf85ac8a0 > > !ifdef EDK2_ENABLE_PL111 > >INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf > > !endif > > - INF ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf > > + INF ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf > > > ># > ># Semi-hosting filesystem > > diff --git a/Platform/ARM/VExpressPkg/Include/Platform/RTSM/ArmPlatform.h > > b/Platform/ARM/VExpressPkg/Include/Platform/RTSM/ArmPlatform.h > > index d856b6daa1d7..e267912ef5f5 100644 > > --- a/Platform/ARM/VExpressPkg/Include/Platform/RTSM/ArmPlatform.h > > +++ b/Platform/ARM/VExpressPkg/Include/Platform/RTSM/ArmPlatform.h > > @@ -76,4 +76,7 @@ > > #define PL111_CLCD_MOTHERBOARD_VIDEO_MODE_OSC_ID 1 > > #define PL111_CLCD_CORE_TILE_VIDEO_MODE_OSC_ID 1 > > > > +#define SBSA_WATCHDOG_BASE 0x2a44 > > +#define SBSA_WATCHDOG_SIZE (2 * SIZE_64KB) > > + > > #endif > > diff --git > > a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf > > b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf > > index 53898c5e957e..511a2ac99b75 100644 > > --- a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf > > +++ b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf > > @@ -60,5 +60,8 @@ > >gArmPlatformTokenSpaceGuid.PcdArmMaliDpBase > >gArmPlatformTokenSpaceGuid.PcdArmMaliDpMemoryRegionLength > > > > + gArmTokenSpaceGuid.PcdGenericWatchdogControlBase > > + gArmTokenSpaceGuid.PcdGenericWatchdogRefreshBase > > + > > [Ppis] > >gArmMpCoreInfoPpiGuid > > diff --git a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c > > b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c > > index c8eefa0cf28b..eb8f6a48cd02 100644 > > --- a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c > > +++ b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c > > @@ -23,7 +23,7 @@ > > #define DP_BASE_DESCRIPTOR ((Fix
Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add AsmLfence function
On Thu, 20 Dec 2018 at 10:01, Jagadeesh Ujja wrote: > > hi Ard, > > On Tue, Dec 18, 2018 at 7:38 AM Yao, Jiewen wrote: > > > > + Wu Hao, since he contributed the original patch. > > > > Ard > > Would you please file a Bugzilla for that? Then we can start working on > > that. > > > > Can you please file the Bugzilla, please do let me know, I am happy to > file Bugzilla > Done. https://bugzilla.tianocore.org/show_bug.cgi?id=1417 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add AsmLfence function
hi Ard, On Tue, Dec 18, 2018 at 7:38 AM Yao, Jiewen wrote: > > + Wu Hao, since he contributed the original patch. > > Ard > Would you please file a Bugzilla for that? Then we can start working on that. > Can you please file the Bugzilla, please do let me know, I am happy to file Bugzilla Thanks Ujja > Thank you > Yao Jiewen > > > -Original Message- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: Monday, December 17, 2018 5:28 PM > > To: Yao, Jiewen > > Cc: edk2-devel@lists.01.org; Gao, Liming ; Zhang, > > Chao B > > Subject: Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add > > AsmLfence function > > > > On Mon, 17 Dec 2018 at 09:44, Yao, Jiewen wrote: > > > > > > Thanks Ard. > > > I have little concern about "Spec", because people may read it as > > "Specification", especially in our team. :) > > > > > > > I understand :-) > > > > SpeculationBarrier() is fine with me. > > > > > > > > > > > -Original Message- > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of > > > > Ard Biesheuvel > > > > Sent: Monday, December 17, 2018 4:35 PM > > > > To: Yao, Jiewen > > > > Cc: edk2-devel@lists.01.org; Gao, Liming ; > > Zhang, > > > > Chao B > > > > Subject: Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: > > Add > > > > AsmLfence function > > > > > > > > On Mon, 17 Dec 2018 at 09:30, Yao, Jiewen > > wrote: > > > > > > > > > > I reviewed the ARM white paper - > > > > > > file:///C:/Users/jyao1/Downloads/Cache_Speculation_Side-channels-v2.4.p > > > > df > > > > > > > > > > I agree with you that LoadFence might not be the best idea. > > > > > > > > > > How about SpeculationBarrier() ? > > > > > > > > > > > > > That works for me. Or SpecFence (). As long as it does not conflate > > > > memory ordering with controlling the side effects of speculative > > > > execution, it is ok with me. > > > > > > > > I'll contribute the ARM and AARCH64 implementations asap once the > > > > generic changes are posted on the list. > > > > > > > > Thanks, > > > > > > > > > > -Original Message- > > > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On > > Behalf > > > > Of > > > > > > Yao, Jiewen > > > > > > Sent: Monday, December 17, 2018 4:25 PM > > > > > > To: Ard Biesheuvel ; Leif Lindholm > > > > > > > > > > > > Cc: edk2-devel@lists.01.org; Zhang, Chao B > > ; > > > > > > Gao, Liming > > > > > > Subject: Re: [edk2] [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: > > > > Add > > > > > > AsmLfence function > > > > > > > > > > > > Hi Ard > > > > > > I am OK to refine it now. > > > > > > > > > > > > Do you have any proposal on the naming from ARM side? > > > > > > > > > > > > Thank you > > > > > > Yao Jiewen > > > > > > > > > > > > > -Original Message- > > > > > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > > > > > Sent: Monday, December 17, 2018 4:11 PM > > > > > > > To: Yao, Jiewen ; Leif Lindholm > > > > > > > > > > > > > > Cc: Gao, Liming ; Jagadeesh Ujja > > > > > > > ; edk2-devel@lists.01.org; Zhang, Chao > > B > > > > > > > > > > > > > > Subject: Re: [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add > > > > > > > AsmLfence function > > > > > > > > > > > > > > On Mon, 17 Dec 2018 at 08:45, Ard Biesheuvel > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > On Mon, 17 Dec 2018 at 04:29, Yao, Jiewen > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > I think we have below definition. > > > > > > > > > -- MemoryFence: Serialize load and store operations. > > > > > > > > > -- LoadFence: Serialize load operations. > > > > > > > > > -- StoreFence: Serialize store operations. > > > > > > > > > > > > > > > > > > According to IA32 SDM, Intel has MFENCE, LFENCE and SFENCE. > > > > > > > > > If ARM only has DMB, it is possible to use DMB for > > MemoryFence, > > > > > > > LoadFence or StoreFence. > > > > > > > > > > > > > > > > > > Maybe it is better to use LoadFence, instead of AsmLFence? > > > > > > > > > Then we can align with MemoryFence. > > > > > > > > > > > > > > > > > > > > > > > > > I think using AsmLfence() all over the code to limit speculation > > was a > > > > > > > > mistake, and I am disappointed nobody from the ARM side was > > > > involved > > > > > > > > at all when these changes were proposed. > > > > > > > > > > > > > > > > > > > > > > OK, I have to apologize here. Hao did cc us on these patches, and > > > > > > > so > > > > > > > we did have the opportunity to respond at the time. > > > > > > > > > > > > > > But that doesn't change the fact that AsmLfence() should be > > replaced > > > > > > > by an abstraction that describes the specific semantics of the x86 > > > > > > > Lfence implemetation beyond memory ordering that we are relying > > on > > > > > > > here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The code changes rely on specific semantics of the x86 Lfence > > > > > > > > instructions, i.e., that beyond load serialization, the
Re: [edk2] [PATCH edk2-platforms v2 3/3] Platform/ARM/SgiPkg: Enable MmCommunication module on the platform
On Thu, 20 Dec 2018 at 06:48, Sughosh Ganu wrote: > > The ArmMmCommunication module is used for communication between > non-secure and secure world using Arm's Management Mode > Specification. Enable this module on Sgi platforms. This would be used > subsequently by the RAS and SecureBoot features, support for which > is to be added on the platform. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Sughosh Ganu > --- > Platform/ARM/SgiPkg/SgiPlatform.dsc | 18 ++ > Platform/ARM/SgiPkg/SgiPlatform.fdf | 5 + > 2 files changed, 23 insertions(+) > > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc > b/Platform/ARM/SgiPkg/SgiPlatform.dsc > index 7995c7d132d6..948b75631a00 100644 > --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc > +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc > @@ -197,6 +197,20 @@ [PcdsFixedAtBuild.common] >gArmSgiTokenSpaceGuid.PcdVirtioNetSize|0x1 >gArmSgiTokenSpaceGuid.PcdVirtioNetInterrupt|204 > > +!if $(ARM_STANDALONE_MM_ENABLE) == TRUE Why is this inclusion conditional (here and below)? I was under the impression that the communicate driver fails gracefully if the secure standalone MM is absent. If this is not the case, please propose how to fix the core driver so that it does. > + # > + # Set the base address and size of the buffer used > + # for communication between the Normal world edk2 > + # with StandaloneMm image at S-EL0 through MM_COMMUNICATE. > + # This buffer gets allocated in ATF and since we do not have > + # a mechanism currently to communicate the base address and > + # size of this buffer from ATF, hard-code it here > + # > + ## MM Communicate > + gArmTokenSpaceGuid.PcdMmBufferBase|0xFF60 > + gArmTokenSpaceGuid.PcdMmBufferSize|0x1 > +!endif > + > > > # > # Components Section - list of all EDK II Modules needed by this Platform > @@ -331,3 +345,7 @@ [Components.common] ># SATA Controller ># >MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf > + > +!if $(ARM_STANDALONE_MM_ENABLE) == TRUE > + ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf > +!endif > diff --git a/Platform/ARM/SgiPkg/SgiPlatform.fdf > b/Platform/ARM/SgiPkg/SgiPlatform.fdf > index 80c3412fd4ad..01799de8a0c8 100644 > --- a/Platform/ARM/SgiPkg/SgiPlatform.fdf > +++ b/Platform/ARM/SgiPkg/SgiPlatform.fdf > @@ -169,6 +169,11 @@ [FV.FvMain] ># >INF ShellPkg/Application/Shell/Shell.inf > > +!if $(ARM_STANDALONE_MM_ENABLE) == TRUE > + # MM Communicate > + INF ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf > +!endif > + ># ># Platform driver ># > -- > 2.7.4 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v2 1/3] Platform/ARM/SgiPkg: Build infrastructure for StandaloneMm image
On Thu, 20 Dec 2018 at 06:48, Sughosh Ganu wrote: > > Add the build infrastructure for compilation of StandaloneMm image > files and FD file. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Sughosh Ganu > --- > Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 130 > +++ > Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 100 + > 2 files changed, 230 insertions(+) > create mode 100644 Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > create mode 100644 Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > new file mode 100644 > index ..4615c383c46a > --- /dev/null > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > @@ -0,0 +1,130 @@ > +# > +# Copyright (c) 2018, ARM Limited. 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. > +# > + > + > +# > +# Defines Section - statements that will be processed to create a Makefile. > +# > + > +[Defines] > + PLATFORM_NAME = sgi_mm_standalone Please use camel case > + PLATFORM_GUID = 34B78C8F-CFD5-49D5-8360-E91143F6106D > + PLATFORM_VERSION = 1.0 > + DSC_SPECIFICATION = 0x00010011 > + OUTPUT_DIRECTORY = Build/$(PLATFORM_NAME) > + SUPPORTED_ARCHITECTURES= AARCH64|ARM Does this actually build for ARM? > + BUILD_TARGETS = DEBUG|RELEASE Please include NOOPT > + SKUID_IDENTIFIER = DEFAULT > + FLASH_DEFINITION = > Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf > + DEFINE DEBUG_MESSAGE = TRUE > + > + # LzmaF86 > + DEFINE COMPRESSION_TOOL_GUID = D42AE6BD-1352-4bfb-909A-CA72A6EAE889 > + > + > +# > +# Library Class section - list of all Library Classes needed by this > Platform. > +# > + > +[LibraryClasses] > + # > + # Basic > + # > + BaseLib|MdePkg/Library/BaseLib/BaseLib.inf > + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf > + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf > + > DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf > + FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf > + > HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf > + IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf > + MemLib|StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.inf > + > MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf > + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf > + PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf > + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf > + > ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf > + > + # > + # Entry point > + # > + > StandaloneMmDriverEntryPoint|StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf > + > +[LibraryClasses.AARCH64] Are the pieces below specific to AARCH64? If not, drop the [] section header > + ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf > + > StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf > + ArmSvcLib|ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf > + > CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf > + > PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf > + > + # ARM PL011 UART Driver > + > PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf > + PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf > + > SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf > + > + > StandaloneMmCoreEntryPoint|StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf > + > + > +# > +# Pcd Section - list of all EDK II PCD Entries defined by this Platform > +# > +###
Re: [edk2] [PATCH] Upgrade OpenSSL to 1.1.0j
Reviewed-by: Ye Ting
-Original Message-
From: Wang, Jian J
Sent: Wednesday, December 19, 2018 11:03 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Wei, Gang
Subject: [PATCH] Upgrade OpenSSL to 1.1.0j
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1393
BZ#1089 (https://bugzilla.tianocore.org/show_bug.cgi?id=1089) requests to
upgrade the OpenSSL to the latest 1.1.1 release. Since OpenSSL-1.1.1 has many
changes, more porting efforts and feature evaluation are needed.
This might lead to a situation that it cannot catch the Q1'19 stable tag.
One of the solution is upgrade current version (1.1.0h) to 1.1.0j.
According to following web page in openssl.org, all security issues solved in
1.1.1 have been also back-ported to 1.1.0.j. This can make sure that no
security vulnerabilities left in edk2 master before 1.1.1.
https://www.openssl.org/news/vulnerabilities-1.1.1.html
Cc: Ting Ye
Cc: Gang Wei
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang
---
CryptoPkg/CryptoPkg.dsc | 1 +
.../Library/Include/openssl/opensslconf.h | 20 ---
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 3 +++
.../Library/OpensslLib/OpensslLibCrypto.inf | 3 +++
CryptoPkg/Library/OpensslLib/openssl | 2 +-
CryptoPkg/Library/OpensslLib/process_files.pl | 0
6 files changed, 21 insertions(+), 8 deletions(-) mode change 100644 =>
100755 CryptoPkg/Library/OpensslLib/process_files.pl
diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc index
a0334d628b..321abe4d4c 100644
--- a/CryptoPkg/CryptoPkg.dsc
+++ b/CryptoPkg/CryptoPkg.dsc
@@ -121,6 +121,7 @@
CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
CryptoPkg/Library/TlsLib/TlsLib.inf
+ CryptoPkg/Library/OpensslLib/OpensslLib.inf
[Components.IA32, Components.X64]
CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
diff --git a/CryptoPkg/Library/Include/openssl/opensslconf.h
b/CryptoPkg/Library/Include/openssl/opensslconf.h
index 1917d7ab24..28dd9ab93c 100644
--- a/CryptoPkg/Library/Include/openssl/opensslconf.h
+++ b/CryptoPkg/Library/Include/openssl/opensslconf.h
@@ -2,7 +2,7 @@
* WARNING: do not edit!
* Generated from include/openssl/opensslconf.h.in
*
- * Copyright 2016 The OpenSSL Project Authors. All Rights Reserved.
+ * Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved.
*
* Licensed under the OpenSSL license (the "License"). You may not use
* this file except in compliance with the License. You can obtain a copy @@
-235,12 +235,18 @@ extern "C" {
* still won't see them if the library has been built to disable deprecated
* functions.
*/
-#if defined(OPENSSL_NO_DEPRECATED)
-# define DECLARE_DEPRECATED(f)
-#elif __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0)
-# define DECLARE_DEPRECATED(f)f __attribute__ ((deprecated));
-#else
-# define DECLARE_DEPRECATED(f) f;
+#ifndef DECLARE_DEPRECATED
+# if defined(OPENSSL_NO_DEPRECATED)
+# define DECLARE_DEPRECATED(f)
+# else
+# define DECLARE_DEPRECATED(f) f;
+# ifdef __GNUC__
+# if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0)
+#undef DECLARE_DEPRECATED
+#define DECLARE_DEPRECATED(f)f __attribute__ ((deprecated));
+# endif
+# endif
+# endif
#endif
#ifndef OPENSSL_FILE
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 0300856cf2..6162d29143 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -175,6 +175,7 @@
$(OPENSSL_PATH)/crypto/conf/conf_mall.c
$(OPENSSL_PATH)/crypto/conf/conf_mod.c
$(OPENSSL_PATH)/crypto/conf/conf_sap.c
+ $(OPENSSL_PATH)/crypto/conf/conf_ssl.c
$(OPENSSL_PATH)/crypto/cpt_err.c
$(OPENSSL_PATH)/crypto/cryptlib.c
$(OPENSSL_PATH)/crypto/cversion.c
@@ -281,6 +282,7 @@
$(OPENSSL_PATH)/crypto/evp/pmeth_lib.c
$(OPENSSL_PATH)/crypto/evp/scrypt.c
$(OPENSSL_PATH)/crypto/ex_data.c
+ $(OPENSSL_PATH)/crypto/getenv.c
$(OPENSSL_PATH)/crypto/hmac/hm_ameth.c
$(OPENSSL_PATH)/crypto/hmac/hm_pmeth.c
$(OPENSSL_PATH)/crypto/hmac/hmac.c
@@ -418,6 +420,7 @@
$(OPENSSL_PATH)/crypto/x509/x509_err.c
$(OPENSSL_PATH)/crypto/x509/x509_ext.c
$(OPENSSL_PATH)/crypto/x509/x509_lu.c
+ $(OPENSSL_PATH)/crypto/x509/x509_meth.c
$(OPENSSL_PATH)/crypto/x509/x509_obj.c
$(OPENSSL_PATH)/crypto/x509/x509_r2x.c
$(OPENSSL_PATH)/crypto/x509/x509_req.c
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
index 23be4e1e14..b04bf62b4e 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
@@ -175,6 +175,7 @@
$(OPENSSL_PATH)/crypto/conf/conf_mall.c
$(OPENSSL_PATH)/crypto/conf/conf_mod.c
$(OPENSSL_PATH)/crypto/conf/conf_sap.c
+ $(OPENSSL_PATH)/crypto/conf/conf_ssl.c
$(OPENSSL_PATH)/crypto/cpt_err.c
$(
Re: [edk2] [PATCH] BaseTools/tools_def ARM: use softfloat target for CLANG3x
On Thu, 20 Dec 2018 at 07:54, Gao, Liming wrote: > > Ard: > So, this change requires ARM users to install the additional tool chain? If > yes, could you list the detail impact to user? > As mentioned in the commit log > >Unfortunately, this requires all CLANG3x/ARM users to install > >another cross toolchain. but in fact, you only need arm-linux-gnueabi binutils, so I will update that. Could you elaborate on what level of detail you had in mind beyond that? > Thanks > Liming > >-Original Message- > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard > >Biesheuvel > >Sent: Wednesday, December 19, 2018 10:50 PM > >To: edk2-devel@lists.01.org > >Cc: Gao, Liming > >Subject: [edk2] [PATCH] BaseTools/tools_def ARM: use softfloat target for > >CLANG3x > > > >The target triplet we use for CLANG35 and CLANG38 specifies a > >hardfloat target, and so the binaries that are emitted are > >annotated as using VFP registers for passing floating point > >arguments, even though no VFP is used anywhere in the code. > > > >This works fine as long as we don't try to link against code > >that uses software floating point, since combining object files > >with different floating point calling conventions is not permitted. > > > >So switch to the softfloat arm-linux-gnueabi triplet instead. > >Unfortunately, this requires all CLANG3x/ARM users to install > >another cross toolchain. > > > >Contributed-under: TianoCore Contribution Agreement 1.1 > >Signed-off-by: Ard Biesheuvel > >--- > > BaseTools/Conf/tools_def.template | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >diff --git a/BaseTools/Conf/tools_def.template > >b/BaseTools/Conf/tools_def.template > >index 2ba833e1fb06..f82bc72327d8 100755 > >--- a/BaseTools/Conf/tools_def.template > >+++ b/BaseTools/Conf/tools_def.template > >@@ -5231,7 +5231,7 @@ RELEASE_GCC5_AARCH64_DLINK_XIPFLAGS = -z > >common-page-size=0x20 > > *_CLANG35_*_DLINK_PATH = ENV(CLANG35_BIN)clang > > *_CLANG35_*_ASLDLINK_PATH= ENV(CLANG35_BIN)clang > > > >-DEFINE CLANG35_ARM_TARGET= -target arm-linux-gnueabihf > >+DEFINE CLANG35_ARM_TARGET= -target arm-linux-gnueabi > > DEFINE CLANG35_AARCH64_TARGET= -target aarch64-linux-gnu > > > > DEFINE CLANG35_WARNING_OVERRIDES = -Wno-parentheses-equality - > >Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare > >-Wno-empty-body -Wno-unknown-warning-option > >@@ -5384,7 +5384,7 @@ NOOPT_CLANG38_X64_DLINK2_FLAGS = > >DEF(GCC5_X64_DLINK2_FLAGS) -O0 > > ## > > # CLANG38 ARM definitions > > ## > >-DEFINE CLANG38_ARM_TARGET= -target arm-linux-gnueabihf > >+DEFINE CLANG38_ARM_TARGET= -target arm-linux-gnueabi > > DEFINE CLANG38_ARM_CC_FLAGS = DEF(GCC_ARM_CC_FLAGS) > >DEF(CLANG38_ARM_TARGET) DEF(CLANG38_WARNING_OVERRIDES) -mno- > >movt > > DEFINE CLANG38_ARM_DLINK_FLAGS = DEF(CLANG38_ARM_TARGET) > >DEF(GCC_ARM_DLINK_FLAGS) > > > >-- > >2.19.2 > > > >___ > >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
