[edk2] [Patch] NetworkPkg: Update the DnsDhcp.c to use BSD license
This patch is used to update the DnsDhcp.c to use BSD license. Cc: Ye Ting Cc: Siyuan Fu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu --- NetworkPkg/DnsDxe/DnsDhcp.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/NetworkPkg/DnsDxe/DnsDhcp.c b/NetworkPkg/DnsDxe/DnsDhcp.c index a9fdfb6..6b409ba 100644 --- a/NetworkPkg/DnsDxe/DnsDhcp.c +++ b/NetworkPkg/DnsDxe/DnsDhcp.c @@ -1,16 +1,16 @@ /** @file Functions implementation related with DHCPv4/v6 for DNS driver. Copyright (c) 2015, Intel Corporation. All rights reserved. -This software and associated documentation (if any) is furnished -under a license and may only be used or copied in accordance -with the terms of the license. Except as permitted by such -license, no part of this software or documentation may be -reproduced, stored in a retrieval system, or transmitted in any -form or by any means without the express written consent of -Intel Corporation. +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 "DnsImpl.h" -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 2/3] MdePkg/Library/UefiFileHandleLib: Make the FileHandleGetFileName return the file name in right format.
1. If the file is not a directory remove the redundant '\' char in file name
string returned from FileHandleGetFileName.
2. Update function comments.
Cc: Jaben Carsey
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin
Reviewed-by: Jaben Carsey
---
MdePkg/Include/Library/FileHandleLib.h | 4 +++-
MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 12 +++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/MdePkg/Include/Library/FileHandleLib.h
b/MdePkg/Include/Library/FileHandleLib.h
index fdbdc3a..00706f9 100644
--- a/MdePkg/Include/Library/FileHandleLib.h
+++ b/MdePkg/Include/Library/FileHandleLib.h
@@ -356,7 +356,9 @@ FileHandleSetSize (
/**
Function to get a full filename given a EFI_FILE_HANDLE somewhere lower on
the
- directory 'stack'.
+ directory 'stack'. If the file is a directory, then append the '\' char at
the
+ end of name string. If it's not a directory, then the last '\' should not be
+ added.
@param[in] Handle Handle to the Directory or File to create path
to.
@param[out] FullFileName Pointer to pointer to generated full file
name. It
diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index a31d12b..04a2f18 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -769,7 +769,9 @@ StrnCatGrowLeft (
/**
Function to get a full filename given a EFI_FILE_HANDLE somewhere lower on
the
- directory 'stack'.
+ directory 'stack'. If the file is a directory, then append the '\' char at
the
+ end of name string. If it's not a directory, then the last '\' should not be
+ added.
if Handle is NULL, return EFI_INVALID_PARAMETER
@@ -856,6 +858,14 @@ FileHandleGetFileName (
*FullFileName = StrnCatGrowLeft(FullFileName, &Size, L"\\", 0);
}
+ if (*FullFileName != NULL &&
+ (*FullFileName)[StrLen(*FullFileName) - 1] == L'\\' &&
+ StrLen(*FullFileName) > 1 &&
+ FileHandleIsDirectory(Handle) == EFI_NOT_FOUND
+ ) {
+(*FullFileName)[StrLen(*FullFileName) - 1] = CHAR_NULL;
+ }
+
if (CurrentHandle != NULL) {
CurrentHandle->Close (CurrentHandle);
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory reservation from PrePi to DXE
Seemly, the patch is ignored. I send patch mail. Please check. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, Liming Sent: Tuesday, August 25, 2015 2:13 PM To: Benjamin Herrenschmidt; Tian, Feng Cc: Kinney, Michael D; edk2-devel@lists.01.org; Laszlo Ersek; Andrew Fish Subject: Re: [edk2] Question about memory reservation from PrePi to DXE Ben: I agree this is an issue. PI spec has no limitation to create memory allocation hob. Memory may be allocated in either the HOB producer phase memory area or other areas of present and initialized system memory. DxeCore shouldn't assume the memory allocation hob are all created by PEI AllocatePages() service. I attach my patch to add the check in CoreInitializeMemoryServices(). Could you help review and try first? Thanks Liming -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Benjamin Herrenschmidt Sent: Saturday, August 22, 2015 12:35 PM To: Tian, Feng Cc: Kinney, Michael D; edk2-devel@lists.01.org; Laszlo Ersek; Andrew Fish Subject: Re: [edk2] Question about memory reservation from PrePi to DXE On Mon, 2015-08-10 at 16:18 -0700, Andrew Fish wrote: > Laszlo and I are not the maintainers for this code. > https://github.com/tianocore/edk2/blob/master/Maintainers.txt < > https://github.com/tianocore/edk2/blob/master/Maintainers.txt> > > But it does feel like the assumption in the DXE Core is not implied by > the PI Specifications. Hi Feng ! You never replied to that thread ... my problem is that the code in CoreInitializeMemoryServices() will essentially pickup a piece of memory out of *any* memory descriptor HOB completely ignoring the memory allocation HOBs. That means that if Sec or Peim (or in my case, a special PrePei that transfers controls to DXE from a different firmware layer) has marked some memory as reserved via some memory allocation HOBs, there is still a chance that this memory gets overwriten early during DXE initialization, because CoreInitializeMemoryServices() ignores those allocations completely to pick up the initial core memory, which it then makes available to the allocator with CoreAddMemoryDescriptor(). It appears that the Gcd code is generally trying to honor the existing allocation HOBs since later on, CoreInitializeGcdServices() will iterate them and allocates them, but this happens after the above initialization and some allocations do happen in between. Is there a non-documented (or maybe I missed the documentation) requirement that all the Memory resource descriptor HOBs passed to DXE have been modified to *remove* all allocated space from them to avoid that problem or is this mainly a bug ? It does make the transition from a Flat Device Tree to DXE tricky, since in the FDT world, we have on one hand the "memory" modes that give us the regions of physical memory in the system, which would nicely translate to memory resource descriptors, and separately we have a reserve map which describes ranges of addresses that are reserved, either by some firmware layer or in some cases by the HW itself. Unless I missed something, while the spec allows us to match this to memory resource descriptors and memory allocation HOBs respectively, the DXE implementation will fail to honor such overlap properly. Am I correct ? Cheers, Ben. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] MdeModulePkg: Fix the issue in DxeCore CoreInitializeMemoryServices()
CoreInitializeMemoryServices() will essentially pickup a piece of memory out
of *any* memory descriptor HOB completely ignoring the memory allocation HOBs.
This change considers memory allocation hobs in this API.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 36
1 file changed, 36 insertions(+)
diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
index a50fda2..24f4ba7 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -2001,10 +2001,39 @@
CoreConvertResourceDescriptorHobAttributesToCapabilities (
}
return Capabilities;
}
+/**
+ Check whether the memory allocation hob is in the specified resource hob
range.
+
+ @param HobStart The start address of the HOB.
+ @param ResourceHob Resource range to be checked.
+
+ @retval TRUE Memory allocation hob is in the specified
ResourceHob.
+ @retval FALSENo memory allocation hob is in the specified
ResourceHob.
+
+**/
+BOOLEAN
+OverlapWithMemoryAllocationHob (
+ IN VOID**HobStart,
+ IN EFI_HOB_RESOURCE_DESCRIPTOR *ResourceHob
+ )
+{
+ EFI_PEI_HOB_POINTERS Hob;
+
+ for (Hob.Raw = *HobStart; !END_OF_HOB_LIST(Hob); Hob.Raw =
GET_NEXT_HOB(Hob)) {
+if (GET_HOB_TYPE (Hob) == EFI_HOB_TYPE_MEMORY_ALLOCATION) {
+ if (Hob.MemoryAllocation->AllocDescriptor.MemoryBaseAddress >=
ResourceHob->PhysicalStart &&
+ Hob.MemoryAllocation->AllocDescriptor.MemoryBaseAddress <
ResourceHob->PhysicalStart + ResourceHob->ResourceLength) {
+return TRUE;
+ }
+}
+ }
+
+ return FALSE;
+}
/**
External function. Initializes memory services based on the memory
descriptor HOBs. This function is responsible for priming the memory
map, so memory allocations and resource allocations can be made.
@@ -2216,10 +2245,17 @@ CoreInitializeMemoryServices (
if (TestedMemoryLength < MINIMUM_INITIAL_MEMORY_SIZE) {
continue;
}
//
+// Skip Resource Descriptor HOBs that some of resource have been allocated
in PEI.
+//
+if (OverlapWithMemoryAllocationHob (HobStart, ResourceHob)) {
+ continue;
+}
+
+//
// Save the Resource Descriptor HOB context that is large enough to
initilize the DXE Core
//
MaxMemoryBaseAddress = TestedMemoryBaseAddress;
MaxMemoryLength = TestedMemoryLength;
MaxMemoryAttributes = ResourceHob->ResourceAttribute;
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory reservation from PrePi to DXE
Ben: I agree this is an issue. PI spec has no limitation to create memory allocation hob. Memory may be allocated in either the HOB producer phase memory area or other areas of present and initialized system memory. DxeCore shouldn't assume the memory allocation hob are all created by PEI AllocatePages() service. I attach my patch to add the check in CoreInitializeMemoryServices(). Could you help review and try first? Thanks Liming -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Benjamin Herrenschmidt Sent: Saturday, August 22, 2015 12:35 PM To: Tian, Feng Cc: Kinney, Michael D; edk2-devel@lists.01.org; Laszlo Ersek; Andrew Fish Subject: Re: [edk2] Question about memory reservation from PrePi to DXE On Mon, 2015-08-10 at 16:18 -0700, Andrew Fish wrote: > Laszlo and I are not the maintainers for this code. > https://github.com/tianocore/edk2/blob/master/Maintainers.txt < > https://github.com/tianocore/edk2/blob/master/Maintainers.txt> > > But it does feel like the assumption in the DXE Core is not implied by > the PI Specifications. Hi Feng ! You never replied to that thread ... my problem is that the code in CoreInitializeMemoryServices() will essentially pickup a piece of memory out of *any* memory descriptor HOB completely ignoring the memory allocation HOBs. That means that if Sec or Peim (or in my case, a special PrePei that transfers controls to DXE from a different firmware layer) has marked some memory as reserved via some memory allocation HOBs, there is still a chance that this memory gets overwriten early during DXE initialization, because CoreInitializeMemoryServices() ignores those allocations completely to pick up the initial core memory, which it then makes available to the allocator with CoreAddMemoryDescriptor(). It appears that the Gcd code is generally trying to honor the existing allocation HOBs since later on, CoreInitializeGcdServices() will iterate them and allocates them, but this happens after the above initialization and some allocations do happen in between. Is there a non-documented (or maybe I missed the documentation) requirement that all the Memory resource descriptor HOBs passed to DXE have been modified to *remove* all allocated space from them to avoid that problem or is this mainly a bug ? It does make the transition from a Flat Device Tree to DXE tricky, since in the FDT world, we have on one hand the "memory" modes that give us the regions of physical memory in the system, which would nicely translate to memory resource descriptors, and separately we have a reserve map which describes ranges of addresses that are reserved, either by some firmware layer or in some cases by the HW itself. Unless I missed something, while the spec allows us to match this to memory resource descriptors and memory allocation HOBs respectively, the DXE implementation will fail to honor such overlap properly. Am I correct ? Cheers, Ben. ___ 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] MdeModulePkg/Xhci: Remove TDs from transfer ring when timeout happens
Thanks for your comments, Baranee. I updated the patch as below. Please review
again.
---
MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 75 +++---
MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 193 +
MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.h | 80 +++
MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c | 51 +--
MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c | 235 +++
MdeModulePkg/Bus/Pci/XhciPei/XhciSched.h | 81 ++-
6 files changed, 618 insertions(+), 97 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 390ca0a..39c28ab 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -905,17 +905,28 @@ XhcControlTransfer (
*TransferResult = Urb->Result;
*DataLength = Urb->Completed;
- if (*TransferResult == EFI_USB_NOERROR) {
-Status = EFI_SUCCESS;
- } else if (*TransferResult == EFI_USB_ERR_STALL) {
-RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
-if (EFI_ERROR (RecoveryStatus)) {
- DEBUG ((EFI_D_ERROR, "XhcControlTransfer: XhcRecoverHaltedEndpoint
failed\n"));
+ if (Status == EFI_TIMEOUT) {
+//
+// The transfer timed out. Abort the transfer by dequeueing of the TD.
+//
+RecoveryStatus = XhcDequeueTrbFromEndpoint(Xhc, Urb);
+if (EFI_ERROR(RecoveryStatus)) {
+ DEBUG((EFI_D_ERROR, "XhcControlTransfer: XhcDequeueTrbFromEndpoint
failed\n"));
}
-Status = EFI_DEVICE_ERROR;
goto FREE_URB;
} else {
-goto FREE_URB;
+if (*TransferResult == EFI_USB_NOERROR) {
+ Status = EFI_SUCCESS;
+} else if (*TransferResult == EFI_USB_ERR_STALL) {
+ RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
+ if (EFI_ERROR (RecoveryStatus)) {
+DEBUG ((EFI_D_ERROR, "XhcControlTransfer: XhcRecoverHaltedEndpoint
failed\n"));
+ }
+ Status = EFI_DEVICE_ERROR;
+ goto FREE_URB;
+} else {
+ goto FREE_URB;
+}
}
Xhc->PciIo->Flush (Xhc->PciIo);
@@ -1241,14 +1252,24 @@ XhcBulkTransfer (
*TransferResult = Urb->Result;
*DataLength = Urb->Completed;
- if (*TransferResult == EFI_USB_NOERROR) {
-Status = EFI_SUCCESS;
- } else if (*TransferResult == EFI_USB_ERR_STALL) {
-RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
-if (EFI_ERROR (RecoveryStatus)) {
- DEBUG ((EFI_D_ERROR, "XhcBulkTransfer: XhcRecoverHaltedEndpoint
failed\n"));
+ if (Status == EFI_TIMEOUT) {
+//
+// The transfer timed out. Abort the transfer by dequeueing of the TD.
+//
+RecoveryStatus = XhcDequeueTrbFromEndpoint(Xhc, Urb);
+if (EFI_ERROR(RecoveryStatus)) {
+ DEBUG((EFI_D_ERROR, "XhcBulkTransfer: XhcDequeueTrbFromEndpoint
failed\n"));
+}
+ } else {
+if (*TransferResult == EFI_USB_NOERROR) {
+ Status = EFI_SUCCESS;
+} else if (*TransferResult == EFI_USB_ERR_STALL) {
+ RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
+ if (EFI_ERROR (RecoveryStatus)) {
+DEBUG ((EFI_D_ERROR, "XhcBulkTransfer: XhcRecoverHaltedEndpoint
failed\n"));
+ }
+ Status = EFI_DEVICE_ERROR;
}
-Status = EFI_DEVICE_ERROR;
}
Xhc->PciIo->Flush (Xhc->PciIo);
@@ -1538,14 +1559,24 @@ XhcSyncInterruptTransfer (
*TransferResult = Urb->Result;
*DataLength = Urb->Completed;
- if (*TransferResult == EFI_USB_NOERROR) {
-Status = EFI_SUCCESS;
- } else if (*TransferResult == EFI_USB_ERR_STALL) {
-RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
-if (EFI_ERROR (RecoveryStatus)) {
- DEBUG ((EFI_D_ERROR, "XhcSyncInterruptTransfer: XhcRecoverHaltedEndpoint
failed\n"));
+ if (Status == EFI_TIMEOUT) {
+//
+// The transfer timed out. Abort the transfer by dequeueing of the TD.
+//
+RecoveryStatus = XhcDequeueTrbFromEndpoint(Xhc, Urb);
+if (EFI_ERROR(RecoveryStatus)) {
+ DEBUG((EFI_D_ERROR, "XhcSyncInterruptTransfer: XhcDequeueTrbFromEndpoint
failed\n"));
+}
+ } else {
+if (*TransferResult == EFI_USB_NOERROR) {
+ Status = EFI_SUCCESS;
+} else if (*TransferResult == EFI_USB_ERR_STALL) {
+ RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
+ if (EFI_ERROR (RecoveryStatus)) {
+DEBUG ((EFI_D_ERROR, "XhcSyncInterruptTransfer:
XhcRecoverHaltedEndpoint failed\n"));
+ }
+ Status = EFI_DEVICE_ERROR;
}
-Status = EFI_DEVICE_ERROR;
}
Xhc->PciIo->Flush (Xhc->PciIo);
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 05cd616..c25342d 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -645,12 +645,8 @@ XhcRecoverHaltedEndpoint (
)
{
EFI_STATUS Status;
- EVT_TRB_COMMAND_COMPLETION *EvtTrb;
- CMD_TRB_RESET_ENDPOINT CmdTrbResetED;
- CMD_SET_TR_DEQ_POINTER CmdSetTRDeq;
UINT8 Dci;
UINT8 SlotId;
- EFI_PHYSICAL_ADDR
Re: [edk2] [Patch] BaseTools: Fix the missing depex file in GenFds
Reviewed-by: Yingke Liu
Dennis
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming
Gao
Sent: Tuesday, August 25, 2015 10:23
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools: Fix the missing depex file in GenFds
If FDF FfsRule describes |.depex for depex file on source build, it may be
missed in the generated FD image. GenFds tool needs to check the output file
list and find the matched one.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
Reviewed-by: Yingke Liu
---
BaseTools/Source/Python/GenFds/Section.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/BaseTools/Source/Python/GenFds/Section.py
b/BaseTools/Source/Python/GenFds/Section.py
index 32314d6..fc25447 100644
--- a/BaseTools/Source/Python/GenFds/Section.py
+++ b/BaseTools/Source/Python/GenFds/Section.py
@@ -1,9 +1,9 @@
## @file
# section base class
#
-# Copyright (c) 2007-2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2007-2015, 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
@@ -147,24 +147,24 @@ class Section (SectionClassObject):
#
MakefileDir = FfsInf.EfiOutputPath[:-len('OUTPUT')]
Makefile = os.path.join(MakefileDir, 'Makefile')
if not os.path.exists(Makefile):
Makefile = os.path.join(MakefileDir, 'GNUmakefile')
-if not os.path.exists(Makefile):
-SuffixMap = FfsInf.GetFinalTargetSuffixMap()
-if Suffix in SuffixMap:
-FileList.extend(SuffixMap[Suffix])
-else:
+if os.path.exists(Makefile):
# Update to search files with suffix in all sub-dirs.
Tuple = os.walk(FfsInf.EfiOutputPath)
for Dirpath, Dirnames, Filenames in Tuple:
for F in Filenames:
if os.path.splitext(F)[1] in (Suffix):
FullName = os.path.join(Dirpath, F)
if os.path.getmtime(FullName) >
os.path.getmtime(Makefile):
FileList.append(FullName)
-
+if not FileList:
+SuffixMap = FfsInf.GetFinalTargetSuffixMap()
+if Suffix in SuffixMap:
+FileList.extend(SuffixMap[Suffix])
+
#Process the file lists is alphabetical for a same section type
if len (FileList) > 1:
FileList.sort()
return FileList, IsSect
--
1.9.5.msysgit.0
___
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] MdeModulePkg PeiCore: Recheck SwitchStackSignal after ProcessNotifyList()
Reviewed-by:
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Friday, August 21, 2015 4:10 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Gao, Liming
Subject: [edk2] [PATCH] MdeModulePkg PeiCore: Recheck SwitchStackSignal after
ProcessNotifyList()
in case PeiInstallPeiMemory() is done in a callback with
EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH, and the callback is registered on a PPI
that is installed in the last PEIM.
At the case, PeiCore SwitchStack code will be not being invoked.
Cc: Jiewen Yao
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 547 +-
1 file changed, 284 insertions(+), 263 deletions(-)
diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 46e990d..b6e71b8 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -626,6 +626,282 @@ PeiCoreEntry (
PeiCore (SecCoreData, NULL, Private); }
+VOID
+PeiCheckAndSwitchStack (
+ IN CONST EFI_SEC_PEI_HAND_OFF *SecCoreData,
+ IN PEI_CORE_INSTANCE *Private
+ )
+{
+ VOID *LoadFixPeiCodeBegin;
+ EFI_STATUSStatus;
+ CONST EFI_PEI_SERVICES**PeiServices;
+ UINT64NewStackSize;
+ EFI_PHYSICAL_ADDRESS TopOfOldStack;
+ EFI_PHYSICAL_ADDRESS TopOfNewStack;
+ UINTN StackOffset;
+ BOOLEAN StackOffsetPositive;
+ EFI_PHYSICAL_ADDRESS TemporaryRamBase;
+ UINTN TemporaryRamSize;
+ UINTN TemporaryStackSize;
+ VOID *TemporaryStackBase;
+ UINTN PeiTemporaryRamSize;
+ VOID *PeiTemporaryRamBase;
+ EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI *TemporaryRamSupportPpi;
+ EFI_PHYSICAL_ADDRESS BaseOfNewHeap;
+ EFI_PHYSICAL_ADDRESS HoleMemBase;
+ UINTN HoleMemSize;
+ UINTN HeapTemporaryRamSize;
+ EFI_PHYSICAL_ADDRESS TempBase1;
+ UINTN TempSize1;
+ EFI_PHYSICAL_ADDRESS TempBase2;
+ UINTN TempSize2;
+ UINTN Index;
+
+ PeiServices = (CONST EFI_PEI_SERVICES **) &Private->Ps;
+
+ if (Private->SwitchStackSignal) {
+//
+// Before switch stack from temporary memory to permenent memory,
calculate the heap and stack
+// usage in temporary memory for debuging.
+//
+DEBUG_CODE_BEGIN ();
+ UINT32 *StackPointer;
+
+ for (StackPointer = (UINT32*)SecCoreData->StackBase;
+ (StackPointer < (UINT32*)((UINTN)SecCoreData->StackBase +
SecCoreData->StackSize)) \
+ && (*StackPointer == INIT_CAR_VALUE);
+ StackPointer ++);
+
+DEBUG ((EFI_D_INFO, "Temp Stack : BaseAddress=0x%p Length=0x%X\n",
SecCoreData->StackBase, (UINT32)SecCoreData->StackSize));
+DEBUG ((EFI_D_INFO, "Temp Heap : BaseAddress=0x%p Length=0x%X\n",
Private->HobList.Raw, (UINT32)((UINTN)
Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - (UINTN)
Private->HobList.Raw)));
+DEBUG ((EFI_D_INFO, "Total temporary memory:%d bytes.\n",
(UINT32)SecCoreData->TemporaryRamSize));
+DEBUG ((EFI_D_INFO, " temporary memory stack ever used: %d bytes.\n",
+ (UINT32)(SecCoreData->StackSize - ((UINTN) StackPointer -
(UINTN)SecCoreData->StackBase))
+ ));
+DEBUG ((EFI_D_INFO, " temporary memory heap used: %d bytes.\n",
+
(UINT32)((UINTN)Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom -
(UINTN)Private->HobList.Raw)
+ ));
+DEBUG_CODE_END ();
+
+if (PcdGet64(PcdLoadModuleAtFixAddressEnable) != 0 &&
(Private->HobList.HandoffInformationTable->BootMode != BOOT_ON_S3_RESUME)) {
+ //
+ // Loading Module at Fixed Address is enabled
+ //
+ PeiLoadFixAddressHook (Private);
+
+ //
+ // If Loading Module at Fixed Address is enabled, Allocating memory
range for Pei code range.
+ //
+ LoadFixPeiCodeBegin =
AllocatePages((UINTN)PcdGet32(PcdLoadFixAddressPeiCodePageNumber));
+ DEBUG ((EFI_D_INFO, "LOADING MODULE FIXED INFO: PeiCodeBegin = 0x%lX,
PeiCodeTop= 0x%lX\n", (UINT64)(UINTN)LoadFixPeiCodeBegin,
(UINT64)((UINTN)LoadFixPeiCodeBegin +
PcdGet32(PcdLoadFixAddressPeiCodePageNumber) * EFI_PAGE_SIZE)));
+}
+
+//
+// Reserve the size of new stack at bottom of physical memory
+//
+// The size of new stack in permenent memory must be the
[edk2] [Patch] BaseTools: Fix the missing depex file in GenFds
If FDF FfsRule describes |.depex for depex file on source build, it may
be missed in the generated FD image. GenFds tool needs to check the
output file list and find the matched one.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
Reviewed-by: Yingke Liu
---
BaseTools/Source/Python/GenFds/Section.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/BaseTools/Source/Python/GenFds/Section.py
b/BaseTools/Source/Python/GenFds/Section.py
index 32314d6..fc25447 100644
--- a/BaseTools/Source/Python/GenFds/Section.py
+++ b/BaseTools/Source/Python/GenFds/Section.py
@@ -1,9 +1,9 @@
## @file
# section base class
#
-# Copyright (c) 2007-2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2007-2015, 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
@@ -147,24 +147,24 @@ class Section (SectionClassObject):
#
MakefileDir = FfsInf.EfiOutputPath[:-len('OUTPUT')]
Makefile = os.path.join(MakefileDir, 'Makefile')
if not os.path.exists(Makefile):
Makefile = os.path.join(MakefileDir, 'GNUmakefile')
-if not os.path.exists(Makefile):
-SuffixMap = FfsInf.GetFinalTargetSuffixMap()
-if Suffix in SuffixMap:
-FileList.extend(SuffixMap[Suffix])
-else:
+if os.path.exists(Makefile):
# Update to search files with suffix in all sub-dirs.
Tuple = os.walk(FfsInf.EfiOutputPath)
for Dirpath, Dirnames, Filenames in Tuple:
for F in Filenames:
if os.path.splitext(F)[1] in (Suffix):
FullName = os.path.join(Dirpath, F)
if os.path.getmtime(FullName) >
os.path.getmtime(Makefile):
FileList.append(FullName)
-
+if not FileList:
+SuffixMap = FfsInf.GetFinalTargetSuffixMap()
+if Suffix in SuffixMap:
+FileList.extend(SuffixMap[Suffix])
+
#Process the file lists is alphabetical for a same section type
if len (FileList) > 1:
FileList.sort()
return FileList, IsSect
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg PeiCore: Recheck SwitchStackSignal after ProcessNotifyList()
Reviewed-by: Liming Gao
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Friday, August 21, 2015 4:10 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Gao, Liming
Subject: [edk2] [PATCH] MdeModulePkg PeiCore: Recheck SwitchStackSignal after
ProcessNotifyList()
in case PeiInstallPeiMemory() is done in a callback with
EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH, and the callback is registered on a PPI
that is installed in the last PEIM.
At the case, PeiCore SwitchStack code will be not being invoked.
Cc: Jiewen Yao
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 547 +-
1 file changed, 284 insertions(+), 263 deletions(-)
diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 46e990d..b6e71b8 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -626,6 +626,282 @@ PeiCoreEntry (
PeiCore (SecCoreData, NULL, Private); }
+VOID
+PeiCheckAndSwitchStack (
+ IN CONST EFI_SEC_PEI_HAND_OFF *SecCoreData,
+ IN PEI_CORE_INSTANCE *Private
+ )
+{
+ VOID *LoadFixPeiCodeBegin;
+ EFI_STATUSStatus;
+ CONST EFI_PEI_SERVICES**PeiServices;
+ UINT64NewStackSize;
+ EFI_PHYSICAL_ADDRESS TopOfOldStack;
+ EFI_PHYSICAL_ADDRESS TopOfNewStack;
+ UINTN StackOffset;
+ BOOLEAN StackOffsetPositive;
+ EFI_PHYSICAL_ADDRESS TemporaryRamBase;
+ UINTN TemporaryRamSize;
+ UINTN TemporaryStackSize;
+ VOID *TemporaryStackBase;
+ UINTN PeiTemporaryRamSize;
+ VOID *PeiTemporaryRamBase;
+ EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI *TemporaryRamSupportPpi;
+ EFI_PHYSICAL_ADDRESS BaseOfNewHeap;
+ EFI_PHYSICAL_ADDRESS HoleMemBase;
+ UINTN HoleMemSize;
+ UINTN HeapTemporaryRamSize;
+ EFI_PHYSICAL_ADDRESS TempBase1;
+ UINTN TempSize1;
+ EFI_PHYSICAL_ADDRESS TempBase2;
+ UINTN TempSize2;
+ UINTN Index;
+
+ PeiServices = (CONST EFI_PEI_SERVICES **) &Private->Ps;
+
+ if (Private->SwitchStackSignal) {
+//
+// Before switch stack from temporary memory to permenent memory,
calculate the heap and stack
+// usage in temporary memory for debuging.
+//
+DEBUG_CODE_BEGIN ();
+ UINT32 *StackPointer;
+
+ for (StackPointer = (UINT32*)SecCoreData->StackBase;
+ (StackPointer < (UINT32*)((UINTN)SecCoreData->StackBase +
SecCoreData->StackSize)) \
+ && (*StackPointer == INIT_CAR_VALUE);
+ StackPointer ++);
+
+DEBUG ((EFI_D_INFO, "Temp Stack : BaseAddress=0x%p Length=0x%X\n",
SecCoreData->StackBase, (UINT32)SecCoreData->StackSize));
+DEBUG ((EFI_D_INFO, "Temp Heap : BaseAddress=0x%p Length=0x%X\n",
Private->HobList.Raw, (UINT32)((UINTN)
Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - (UINTN)
Private->HobList.Raw)));
+DEBUG ((EFI_D_INFO, "Total temporary memory:%d bytes.\n",
(UINT32)SecCoreData->TemporaryRamSize));
+DEBUG ((EFI_D_INFO, " temporary memory stack ever used: %d bytes.\n",
+ (UINT32)(SecCoreData->StackSize - ((UINTN) StackPointer -
(UINTN)SecCoreData->StackBase))
+ ));
+DEBUG ((EFI_D_INFO, " temporary memory heap used: %d bytes.\n",
+
(UINT32)((UINTN)Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom -
(UINTN)Private->HobList.Raw)
+ ));
+DEBUG_CODE_END ();
+
+if (PcdGet64(PcdLoadModuleAtFixAddressEnable) != 0 &&
(Private->HobList.HandoffInformationTable->BootMode != BOOT_ON_S3_RESUME)) {
+ //
+ // Loading Module at Fixed Address is enabled
+ //
+ PeiLoadFixAddressHook (Private);
+
+ //
+ // If Loading Module at Fixed Address is enabled, Allocating memory
range for Pei code range.
+ //
+ LoadFixPeiCodeBegin =
AllocatePages((UINTN)PcdGet32(PcdLoadFixAddressPeiCodePageNumber));
+ DEBUG ((EFI_D_INFO, "LOADING MODULE FIXED INFO: PeiCodeBegin = 0x%lX,
PeiCodeTop= 0x%lX\n", (UINT64)(UINTN)LoadFixPeiCodeBegin,
(UINT64)((UINTN)LoadFixPeiCodeBegin +
PcdGet32(PcdLoadFixAddressPeiCodePageNumber) * EFI_PAGE_SIZE)));
+}
+
+//
+// Reserve the size of new stack at bottom of physical memory
+//
+// The size of new stack in permenent memory m
Re: [edk2] [PATCH] BaseTools: Add support for nested !include in FDF and DSC files
Reviewed-by: Yingke Liu
Dennis
-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 25, 2015 0:50
To: edk2-devel@lists.01.org
Cc: Liu, Yingke D; Sheng, Cecil (HPS SW)
Subject: [PATCH] BaseTools: Add support for nested !include in FDF and DSC files
Posting to the new list in case this got missed
Reviewed-by: Samer El-Haj-Mahmoud
>From 839512c7d9e74c2de0234299538220968826a4b7 Mon Sep 17 00:00:00 2001
From: Cecil Sheng
Date: Mon, 6 Jul 2015 12:15:59 +0800
Subject: [PATCH] BaseTools: Nested !include support in DSC and FDF files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cecil Sheng
---
BaseTools/Source/Python/GenFds/FdfParser.py| 98 ++
.../Source/Python/Workspace/MetaFileParser.py | 12 +--
2 files changed, 91 insertions(+), 19 deletions(-)
diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
b/BaseTools/Source/Python/GenFds/FdfParser.py
index 83d3e19..664bf8e 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -2,6 +2,7 @@
# parse FDF file
#
# Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2015, Hewlett Packard Enterprise Development, L.P.
#
# This program and the accompanying materials # are licensed and made
available under the terms and conditions of the BSD License @@ -81,16 +82,31 @@
RegionSizeGuidPattern = re.compile("\s*(?P\w+\.\w+)\s*\|\s*(?P\w+\.\
RegionOffsetPcdPattern = re.compile("\s*(?P\w+\.\w+)\s*$")
ShortcutPcdPattern =
re.compile("\s*\w+\s*=\s*(?P(?:0x|0X)?[a-fA-F0-9]+)\s*\|\s*(?P\w+\.\w+)\s*")
-IncludeFileList = []
+AllIncludeFileList = []
+
+# Get the closest parent
+def GetParentAtLine (Line):
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile
+return None
+
+# Check include loop
+def IsValidInclude (File, Line):
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line) and Profile.FileName == File:
+return False
+
+return True
def GetRealFileLine (File, Line):
InsertedLines = 0
-for Profile in IncludeFileList:
-if Line >= Profile.InsertStartLineNumber and Line <
Profile.InsertStartLineNumber + Profile.InsertAdjust +
len(Profile.FileLinesList):
-return (Profile.FileName, Line - Profile.InsertStartLineNumber + 1)
-if Line >= Profile.InsertStartLineNumber + Profile.InsertAdjust +
len(Profile.FileLinesList):
-InsertedLines += Profile.InsertAdjust + len(Profile.FileLinesList)
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile.GetLineInFile(Line)
+elif Line >= Profile.InsertStartLineNumber and Profile.Level == 1:
+ InsertedLines += Profile.GetTotalLines()
return (File, Line - InsertedLines)
@@ -111,6 +127,7 @@ class Warning (Exception):
FileLineTuple = GetRealFileLine(File, Line)
self.FileName = FileLineTuple[0]
self.LineNumber = FileLineTuple[1]
+self.OriginalLineNumber = Line
self.Message = Str
self.ToolName = 'FdfParser'
@@ -157,6 +174,38 @@ class IncludeFileProfile :
self.InsertStartLineNumber = None
self.InsertAdjust = 0
+self.IncludeFileList = []
+self.Level = 1 # first level include file
+
+def GetTotalLines(self):
+TotalLines = self.InsertAdjust + len(self.FileLinesList)
+
+for Profile in self.IncludeFileList:
+ TotalLines += Profile.GetTotalLines()
+
+return TotalLines
+
+def IsLineInFile(self, Line):
+if Line >= self.InsertStartLineNumber and Line <
self.InsertStartLineNumber + self.GetTotalLines():
+return True
+
+return False
+
+def GetLineInFile(self, Line):
+if not self.IsLineInFile (Line):
+return (self.FileName, -1)
+
+InsertedLines = self.InsertStartLineNumber
+
+for Profile in self.IncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile.GetLineInFile(Line)
+elif Line >= Profile.InsertStartLineNumber:
+InsertedLines += Profile.GetTotalLines()
+
+return (self.FileName, Line - InsertedLines + 1)
+
+
## The FDF content class that used to record file data when parsing FDF # @@
-306,10 +355,12 @@ class FdfParser:
# Reset file data buffer to the initial state
#
# @param selfThe object pointer
+# @param DestLineOptional new destination line number.
+# @param DestOffset Optional new destination offset.
#
-def Rewind(self):
-self.CurrentLineNumber = 1
-self.CurrentOffsetWithinLine = 0
+def Rewind(self, DestLine = 1, DestOffset = 0):
+self.CurrentLineNumber = DestLine
+self.CurrentOffsetWithinLine = DestOffset
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 19 August 2015 at 00:27, Laszlo Ersek wrote: > On 08/18/15 22:04, Paolo Bonzini wrote: >> >> >> On 18/08/2015 08:52, Ard Biesheuvel wrote: Personally, I would not mind deprecating GCC44, but the biggest question I would have is what toolchains do the latest UDK releases claim to support. We also have the issue that every time I ask about deprecating a toolchain, Larry looks at me like I'm crazy. :) >>> >>> Well, perhaps he can chime in and explain his motivation behind this? >>> At some point, we need to start removing things, surely. Larry just >>> has a higher tolerance for pain :-) >> >> RHEL 6 is shipping GCC 4.4. True, there are software collections to >> overcome that, but I think supporting GCC 4.4 is a good idea for at >> least a couple more years. >> >> Laszlo, do you still use RHEL 6? Are you building with GCC 4.4? > > My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I > need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays > practically "never", thankfully. > > In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because > the RHEL-6 components lack support for the pflash-backed varstore. > Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too. > > I have a number of Fedora virtual machines just for build-testing with > gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler > support, not the reason for it. :) > > So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms, > gcc-4.4 corresponds to fc13.) > OK, so [supposedly] Larry is the only one who objects to deprecating toolchains, but since he has not responded to the suggestion, I think we should proceed anyway. I will respin this series, and instead of bringing CYGGCC and ELFGCC etc in line, I will propose to move them to tools_def.attic or whichever name is preferred by the group. Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead iff we want the MinGW PE/COFF GCC, and I think we do, if only so that we have a LLP64 environment for X64 available to those without the possibility or the desire to run a MS toolchains under Windows. GCC44 could perhaps be moved to the attic as well, but it does not need to be in this series imo -- Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to walk into mine at 09:54:08 on Monday 24 August 2015 and say: > On 19 August 2015 at 00:27, Laszlo Ersek wrote: > > On 08/18/15 22:04, Paolo Bonzini wrote: > >> On 18/08/2015 08:52, Ard Biesheuvel wrote: > Personally, I would not mind deprecating GCC44, but the biggest > question I would have is what toolchains do the latest UDK releases > claim to support. > > We also have the issue that every time I ask about deprecating a > toolchain, Larry looks at me like I'm crazy. :) > >>> > >>> Well, perhaps he can chime in and explain his motivation behind this? > >>> At some point, we need to start removing things, surely. Larry just > >>> has a higher tolerance for pain :-) > >> > >> RHEL 6 is shipping GCC 4.4. True, there are software collections to > >> overcome that, but I think supporting GCC 4.4 is a good idea for at > >> least a couple more years. > >> > >> Laszlo, do you still use RHEL 6? Are you building with GCC 4.4? > > > > My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I > > need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays > > practically "never", thankfully. > > > > In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because > > the RHEL-6 components lack support for the pflash-backed varstore. > > Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too. > > > > I have a number of Fedora virtual machines just for build-testing with > > gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler > > support, not the reason for it. :) > > > > So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms, > > gcc-4.4 corresponds to fc13.) > > OK, so [supposedly] Larry is the only one who objects to deprecating > toolchains, but since he has not responded to the suggestion, I think > we should proceed anyway. > > I will respin this series, and instead of bringing CYGGCC and ELFGCC > etc in line, I will propose to move them to tools_def.attic or > whichever name is preferred by the group. > > Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead > iff we want the MinGW PE/COFF GCC, and I think we do, if only so that > we have a LLP64 environment for X64 available to those without the > possibility or the desire to run a MS toolchains under Windows. People should be able to build a known-good crossbuild toolchain. This is the simplest way to provide that option. By the way, do you think I can get you to update the mingw-gcc-build.py script while you're at it? :) -Bill > > GCC44 could perhaps be moved to the attic as well, but it does not > need to be in this series imo -- = -Bill Paul(510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems = "I put a dollar in a change machine. Nothing changed." - George Carlin = ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 24 August 2015 at 19:02, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to > walk into mine at 09:54:08 on Monday 24 August 2015 and say: > >> On 19 August 2015 at 00:27, Laszlo Ersek wrote: >> > On 08/18/15 22:04, Paolo Bonzini wrote: >> >> On 18/08/2015 08:52, Ard Biesheuvel wrote: >> Personally, I would not mind deprecating GCC44, but the biggest >> question I would have is what toolchains do the latest UDK releases >> claim to support. >> >> We also have the issue that every time I ask about deprecating a >> toolchain, Larry looks at me like I'm crazy. :) >> >>> >> >>> Well, perhaps he can chime in and explain his motivation behind this? >> >>> At some point, we need to start removing things, surely. Larry just >> >>> has a higher tolerance for pain :-) >> >> >> >> RHEL 6 is shipping GCC 4.4. True, there are software collections to >> >> overcome that, but I think supporting GCC 4.4 is a good idea for at >> >> least a couple more years. >> >> >> >> Laszlo, do you still use RHEL 6? Are you building with GCC 4.4? >> > >> > My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I >> > need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays >> > practically "never", thankfully. >> > >> > In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because >> > the RHEL-6 components lack support for the pflash-backed varstore. >> > Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too. >> > >> > I have a number of Fedora virtual machines just for build-testing with >> > gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler >> > support, not the reason for it. :) >> > >> > So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms, >> > gcc-4.4 corresponds to fc13.) >> >> OK, so [supposedly] Larry is the only one who objects to deprecating >> toolchains, but since he has not responded to the suggestion, I think >> we should proceed anyway. >> >> I will respin this series, and instead of bringing CYGGCC and ELFGCC >> etc in line, I will propose to move them to tools_def.attic or >> whichever name is preferred by the group. >> >> Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead >> iff we want the MinGW PE/COFF GCC, and I think we do, if only so that >> we have a LLP64 environment for X64 available to those without the >> possibility or the desire to run a MS toolchains under Windows. > > People should be able to build a known-good crossbuild toolchain. This is the > simplest way to provide that option. > Meh. The primary audience of this feature are people building UEFI for X64 on X64, in which case the GCC4x options are arguably simpler. But apparently we agree that we should keep it /and/ support it. > By the way, do you think I can get you to update the mingw-gcc-build.py script > while you're at it? :) > I proposed some updates here http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297 (with you on cc). Care to ack those? Thanks, Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] MdeModulePkg/Xhci: Remove TDs from transfer ring when timeout happens
Could you please create a separate function for 'Set dequeue pointer' since
it's already in XhcRecoverHaltedEndpoint as well?
-Baranee
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian
> Feng
> Sent: Monday, August 24, 2015 12:53 AM
> To: star.z...@intel.com
> Cc: edk2-devel@lists.01.org; Feng Tian
> Subject: [edk2] [patch] MdeModulePkg/Xhci: Remove TDs from transfer ring when
> timeout happens
>
> The error handling for timeout case is enhanced to remove TDs from transfer
> ring.
> The original code only removed s/w URB, but the h/w transfer descriptor TDs
> didn't
> get removed. It would cause data lost for data stream peripheral, such as
> usb-to-
> serial device, from the s/w perspective.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian
> Cc: Star Zeng
> ---
> MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 75
> MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 77
> MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.h | 39 +++
> MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c | 51 +--
> MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c | 86
> MdeModulePkg/Bus/Pci/XhciPei/XhciSched.h
> | 21 +++-
> 6 files changed, 311 insertions(+), 38 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> index 390ca0a..39c28ab 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> @@ -905,17 +905,28 @@ XhcControlTransfer (
>*TransferResult = Urb->Result;
>*DataLength = Urb->Completed;
>
> - if (*TransferResult == EFI_USB_NOERROR) {
> -Status = EFI_SUCCESS;
> - } else if (*TransferResult == EFI_USB_ERR_STALL) {
> -RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
> -if (EFI_ERROR (RecoveryStatus)) {
> - DEBUG ((EFI_D_ERROR, "XhcControlTransfer: XhcRecoverHaltedEndpoint
> failed\n"));
> + if (Status == EFI_TIMEOUT) {
> +//
> +// The transfer timed out. Abort the transfer by dequeueing of the TD.
> +//
> +RecoveryStatus = XhcDequeueTrbFromEndpoint(Xhc, Urb);
> +if (EFI_ERROR(RecoveryStatus)) {
> + DEBUG((EFI_D_ERROR, "XhcControlTransfer:
> + XhcDequeueTrbFromEndpoint failed\n"));
> }
> -Status = EFI_DEVICE_ERROR;
> goto FREE_URB;
>} else {
> -goto FREE_URB;
> +if (*TransferResult == EFI_USB_NOERROR) {
> + Status = EFI_SUCCESS;
> +} else if (*TransferResult == EFI_USB_ERR_STALL) {
> + RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
> + if (EFI_ERROR (RecoveryStatus)) {
> +DEBUG ((EFI_D_ERROR, "XhcControlTransfer: XhcRecoverHaltedEndpoint
> failed\n"));
> + }
> + Status = EFI_DEVICE_ERROR;
> + goto FREE_URB;
> +} else {
> + goto FREE_URB;
> +}
>}
>
>Xhc->PciIo->Flush (Xhc->PciIo);
> @@ -1241,14 +1252,24 @@ XhcBulkTransfer (
>*TransferResult = Urb->Result;
>*DataLength = Urb->Completed;
>
> - if (*TransferResult == EFI_USB_NOERROR) {
> -Status = EFI_SUCCESS;
> - } else if (*TransferResult == EFI_USB_ERR_STALL) {
> -RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
> -if (EFI_ERROR (RecoveryStatus)) {
> - DEBUG ((EFI_D_ERROR, "XhcBulkTransfer: XhcRecoverHaltedEndpoint
> failed\n"));
> + if (Status == EFI_TIMEOUT) {
> +//
> +// The transfer timed out. Abort the transfer by dequeueing of the TD.
> +//
> +RecoveryStatus = XhcDequeueTrbFromEndpoint(Xhc, Urb);
> +if (EFI_ERROR(RecoveryStatus)) {
> + DEBUG((EFI_D_ERROR, "XhcBulkTransfer: XhcDequeueTrbFromEndpoint
> failed\n"));
> +}
> + } else {
> +if (*TransferResult == EFI_USB_NOERROR) {
> + Status = EFI_SUCCESS;
> +} else if (*TransferResult == EFI_USB_ERR_STALL) {
> + RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
> + if (EFI_ERROR (RecoveryStatus)) {
> +DEBUG ((EFI_D_ERROR, "XhcBulkTransfer: XhcRecoverHaltedEndpoint
> failed\n"));
> + }
> + Status = EFI_DEVICE_ERROR;
> }
> -Status = EFI_DEVICE_ERROR;
>}
>
>Xhc->PciIo->Flush (Xhc->PciIo);
> @@ -1538,14 +1559,24 @@ XhcSyncInterruptTransfer (
>*TransferResult = Urb->Result;
>*DataLength = Urb->Completed;
>
> - if (*TransferResult == EFI_USB_NOERROR) {
> -Status = EFI_SUCCESS;
> - } else if (*TransferResult == EFI_USB_ERR_STALL) {
> -RecoveryStatus = XhcRecoverHaltedEndpoint(Xhc, Urb);
> -if (EFI_ERROR (RecoveryStatus)) {
> - DEBUG ((EFI_D_ERROR, "XhcSyncInterruptTransfer:
> XhcRecoverHaltedEndpoint
> failed\n"));
> + if (Status == EFI_TIMEOUT) {
> +//
> +// The transfer timed out. Abort the transfer by dequeueing of the TD.
> +//
> +RecoveryStatus = XhcDequeueTrbFromEndpoint(Xhc, Urb);
> +if (EFI_ERROR(RecoveryStatus)) {
> + DEBUG((EFI_D_ERROR, "XhcSyncInterruptTransfer:
> XhcDequeueTrbFromEndpoint
>
Re: [edk2] [PATCH 3/3] MdePkg/Library/UefiFileHandleLib: Make FileHandleReadLine return the right buffer size.
Reviewed-by: Jaben Carsey
> -Original Message-
> From: Qiu, Shumin
> Sent: Friday, August 21, 2015 1:03 AM
> To: edk2-devel@lists.01.org
> Cc: Qiu, Shumin ; Carsey, Jaben
> ; Gao, Liming
> Subject: [PATCH 3/3] MdePkg/Library/UefiFileHandleLib: Make
> FileHandleReadLine return the right buffer size.
> Importance: High
>
> 1. '\r' char will not return in buffer so buffer size should exclude the
> number
> of '\r' char.
> 2. When 'Truncate' is TRUE return the truncated string with 'EFI_SUCCESS'
> status.
>
> Cc: Jaben Carsey
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin
> ---
> MdePkg/Include/Library/FileHandleLib.h | 2 ++
> .../Library/UefiFileHandleLib/UefiFileHandleLib.c | 34 +++---
>
> 2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/MdePkg/Include/Library/FileHandleLib.h
> b/MdePkg/Include/Library/FileHandleLib.h
> index b5ac19a..fdbdc3a 100644
> --- a/MdePkg/Include/Library/FileHandleLib.h
> +++ b/MdePkg/Include/Library/FileHandleLib.h
> @@ -379,6 +379,8 @@ FileHandleGetFileName (
>
>If the position upon start is 0, then the Ascii Boolean will be set. This
> should
> be
>maintained and not changed for all operations with the same file.
> + The function will not return the \r and \n character in buffer. When an
> empty line is
> + read a CHAR_NULL character will be returned in buffer.
>
>@param[in] HandleFileHandle to read from.
>@param[in, out] BufferThe pointer to buffer to read into.
> diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> index 4223796..fee3f6e 100644
> --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> @@ -917,6 +917,8 @@ FileHandleReturnLine(
>
>If the position upon start is 0, then the Ascii Boolean will be set. This
> should
> be
>maintained and not changed for all operations with the same file.
> + The function will not return the \r and \n character in buffer. When an
> empty line is
> + read a CHAR_NULL character will be returned in buffer.
>
>@param[in] HandleFileHandle to read from.
>@param[in, out] BufferThe pointer to buffer to read into.
> @@ -953,6 +955,7 @@ FileHandleReadLine(
>UINT64 FileSize;
>UINTN CharSize;
>UINTN CountSoFar;
> + UINTN CrCount;
>UINT64 OriginalFilePosition;
>
>if (Handle == NULL
> @@ -962,14 +965,15 @@ FileHandleReadLine(
> return (EFI_INVALID_PARAMETER);
>}
>
> - if (Buffer != NULL) {
> + if (Buffer != NULL && *Size != 0) {
> *Buffer = CHAR_NULL;
> - }
> + }
>
>Status = FileHandleGetSize (Handle, &FileSize);
>if (EFI_ERROR (Status)) {
> return Status;
>} else if (FileSize == 0) {
> +*Ascii = TRUE;
> return EFI_SUCCESS;
>}
>
> @@ -986,6 +990,7 @@ FileHandleReadLine(
> }
>}
>
> + CrCount = 0;
>for (CountSoFar = 0;;CountSoFar++){
> CharBuffer = 0;
> if (*Ascii) {
> @@ -1000,31 +1005,38 @@ FileHandleReadLine(
> || (CharBuffer == '\n' && *Ascii)
> ){
>break;
> +} else if (
> +(CharBuffer == L'\r' && !(*Ascii)) ||
> +(CharBuffer == '\r' && *Ascii)
> + ) {
> + CrCount++;
> + continue;
> }
> //
> // if we have space save it...
> //
> -if ((CountSoFar+1)*sizeof(CHAR16) < *Size){
> +if ((CountSoFar+1-CrCount)*sizeof(CHAR16) < *Size){
>ASSERT(Buffer != NULL);
> - ((CHAR16*)Buffer)[CountSoFar] = CharBuffer;
> - ((CHAR16*)Buffer)[CountSoFar+1] = CHAR_NULL;
> + ((CHAR16*)Buffer)[CountSoFar-CrCount] = CharBuffer;
> + ((CHAR16*)Buffer)[CountSoFar+1-CrCount] = CHAR_NULL;
> }
>}
>
>//
>// if we ran out of space tell when...
>//
> - if ((CountSoFar+1)*sizeof(CHAR16) > *Size){
> -*Size = (CountSoFar+1)*sizeof(CHAR16);
> + if ((CountSoFar+1-CrCount)*sizeof(CHAR16) > *Size){
> +*Size = (CountSoFar+1-CrCount)*sizeof(CHAR16);
> if (!Truncate) {
> + if (Buffer != NULL && *Size != 0) {
> +ZeroMem(Buffer, *Size);
> + }
>FileHandleSetPosition(Handle, OriginalFilePosition);
> + return (EFI_BUFFER_TOO_SMALL);
> } else {
>DEBUG((DEBUG_WARN, "The line was truncated in
> FileHandleReadLine"));
> + return (EFI_SUCCESS);
> }
> -return (EFI_BUFFER_TOO_SMALL);
> - }
> - while(Buffer[StrLen(Buffer)-1] == L'\r') {
> -Buffer[StrLen(Buffer)-1] = CHAR_NULL;
>}
>
>return (Status);
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/3] MdePkg/Library/UefiFileHandleLib: Update the module Basename and module type to 'UEFI*'.
Reviewed-by: Jaben Carsey > -Original Message- > From: Qiu, Shumin > Sent: Friday, August 21, 2015 1:03 AM > To: edk2-devel@lists.01.org > Cc: Qiu, Shumin ; Carsey, Jaben > ; Gao, Liming > Subject: [PATCH 1/3] MdePkg/Library/UefiFileHandleLib: Update the module > Basename and module type to 'UEFI*'. > Importance: High > > The library instance is not BASE type, to follow naming convention this patch > change Basename into 'Uefi*Lib' and module type into 'UEFI_DRIVER'. > > Cc: Jaben Carsey > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Qiu Shumin > --- > MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf > b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf > index 6c98df0..f813eae 100644 > --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf > +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf > @@ -13,9 +13,9 @@ > > [Defines] >INF_VERSION= 0x00010006 > - BASE_NAME = BaseFileHandleLib > + BASE_NAME = UefiFileHandleLib >FILE_GUID = 9495D344-9D8A-41f3-8D17-E2FD238C4E71 > - MODULE_TYPE= DXE_DRIVER > + MODULE_TYPE= UEFI_DRIVER >VERSION_STRING = 1.0 >LIBRARY_CLASS = FileHandleLib|DXE_DRIVER UEFI_APPLICATION > UEFI_DRIVER DXE_RUNTIME_DRIVER > > -- > 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to
walk into mine at 10:22:59 on Monday 24 August 2015 and say:
> On 24 August 2015 at 19:20, Bill Paul wrote:
> > Of all the gin joints in all the towns in all the world, Ard Biesheuvel
> > had to
> >
> > walk into mine at 10:06:10 on Monday 24 August 2015 and say:
> >> On 24 August 2015 at 19:02, Bill Paul wrote:
> >> > Of all the gin joints in all the towns in all the world, Ard
> >> > Biesheuvel had to
>
> >> > walk into mine at 09:54:08 on Monday 24 August 2015 and say:
> [...]
>
> >> >> Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
> >> >> iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
> >> >> we have a LLP64 environment for X64 available to those without the
> >> >> possibility or the desire to run a MS toolchains under Windows.
> >> >
> >> > People should be able to build a known-good crossbuild toolchain. This
> >> > is the simplest way to provide that option.
> >>
> >> Meh. The primary audience of this feature are people building UEFI for
> >> X64 on X64, in which case the GCC4x options are arguably simpler. But
> >> apparently we agree that we should keep it /and/ support it.
> >>
> >> > By the way, do you think I can get you to update the
> >> > mingw-gcc-build.py script while you're at it? :)
> >>
> >> I proposed some updates here
> >> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
> >> (with you on cc). Care to ack those?
> >
> > Is there a particular reason why you chose to use binutils from
> > www.kernel.org rather than from ftpmirror.gnu.org (other than "that's
> > what it was doing before")?
>
> Nope, that was it :-)
>
> In fact, I vaguely remember noticing the kernel.org URL and thinking
> "hmm that's odd" but for some reason, it did not provoke any action on
> my part
My attention was drawn to it before because the specific version the script
was looking for previously ceased to exist on www.kernel.org, which broke the
script.
> > In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
> > thought it made more sense to get both packages from the same place.
> >
> > source_files_common = {
> >
> > 'binutils': {
> >
> > 'url': 'http://ftpmirror.gnu.org/binutils/' + \
> >
> >'binutils-$version.tar.bz2',
> >
> > 'version': '2.25',
> > 'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
> > },
> >
> > }
>
> Yes, 2.25 would be even better. In fact, it might make sense to wait
> for 2.26 to appear, since it adds support for --gc-sections (see the
> other part of this thread) which brings performance of mingw in line
> with ELF based GCC regarding code size.
Fair enough, as long as we don't have to wait too long. In any case, aside
from this, the changes look ok to me.
-Bill
--
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
"I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 24 August 2015 at 19:20, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to
> walk into mine at 10:06:10 on Monday 24 August 2015 and say:
>
>> On 24 August 2015 at 19:02, Bill Paul wrote:
>> > Of all the gin joints in all the towns in all the world, Ard Biesheuvel
>> > had to
>> >
>> > walk into mine at 09:54:08 on Monday 24 August 2015 and say:
[...]
>> >> Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
>> >> iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
>> >> we have a LLP64 environment for X64 available to those without the
>> >> possibility or the desire to run a MS toolchains under Windows.
>> >
>> > People should be able to build a known-good crossbuild toolchain. This is
>> > the simplest way to provide that option.
>>
>> Meh. The primary audience of this feature are people building UEFI for
>> X64 on X64, in which case the GCC4x options are arguably simpler. But
>> apparently we agree that we should keep it /and/ support it.
>>
>> > By the way, do you think I can get you to update the mingw-gcc-build.py
>> > script while you're at it? :)
>>
>> I proposed some updates here
>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
>> (with you on cc). Care to ack those?
>
> Is there a particular reason why you chose to use binutils from www.kernel.org
> rather than from ftpmirror.gnu.org (other than "that's what it was doing
> before")?
Nope, that was it :-)
In fact, I vaguely remember noticing the kernel.org URL and thinking
"hmm that's odd" but for some reason, it did not provoke any action on
my part
> In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
> thought it made more sense to get both packages from the same place.
>
> source_files_common = {
> 'binutils': {
> 'url': 'http://ftpmirror.gnu.org/binutils/' + \
>'binutils-$version.tar.bz2',
> 'version': '2.25',
> 'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
> },
> }
>
Yes, 2.25 would be even better. In fact, it might make sense to wait
for 2.26 to appear, since it adds support for --gc-sections (see the
other part of this thread) which brings performance of mingw in line
with ELF based GCC regarding code size.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to
walk into mine at 10:06:10 on Monday 24 August 2015 and say:
> On 24 August 2015 at 19:02, Bill Paul wrote:
> > Of all the gin joints in all the towns in all the world, Ard Biesheuvel
> > had to
> >
> > walk into mine at 09:54:08 on Monday 24 August 2015 and say:
> >> On 19 August 2015 at 00:27, Laszlo Ersek wrote:
> >> > On 08/18/15 22:04, Paolo Bonzini wrote:
> >> >> On 18/08/2015 08:52, Ard Biesheuvel wrote:
> >> Personally, I would not mind deprecating GCC44, but the biggest
> >> question I would have is what toolchains do the latest UDK releases
> >> claim to support.
> >>
> >> We also have the issue that every time I ask about deprecating a
> >> toolchain, Larry looks at me like I'm crazy. :)
> >> >>>
> >> >>> Well, perhaps he can chime in and explain his motivation behind
> >> >>> this? At some point, we need to start removing things, surely.
> >> >>> Larry just has a higher tolerance for pain :-)
> >> >>
> >> >> RHEL 6 is shipping GCC 4.4. True, there are software collections to
> >> >> overcome that, but I think supporting GCC 4.4 is a good idea for at
> >> >> least a couple more years.
> >> >>
> >> >> Laszlo, do you still use RHEL 6? Are you building with GCC 4.4?
> >> >
> >> > My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I
> >> > need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is
> >> > nowadays practically "never", thankfully.
> >> >
> >> > In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because
> >> > the RHEL-6 components lack support for the pflash-backed varstore.
> >> > Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot
> >> > too.
> >> >
> >> > I have a number of Fedora virtual machines just for build-testing with
> >> > gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler
> >> > support, not the reason for it. :)
> >> >
> >> > So, I'm in favor of dropping gcc-4.4 support. (In Fedora release
> >> > terms, gcc-4.4 corresponds to fc13.)
> >>
> >> OK, so [supposedly] Larry is the only one who objects to deprecating
> >> toolchains, but since he has not responded to the suggestion, I think
> >> we should proceed anyway.
> >>
> >> I will respin this series, and instead of bringing CYGGCC and ELFGCC
> >> etc in line, I will propose to move them to tools_def.attic or
> >> whichever name is preferred by the group.
> >>
> >> Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
> >> iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
> >> we have a LLP64 environment for X64 available to those without the
> >> possibility or the desire to run a MS toolchains under Windows.
> >
> > People should be able to build a known-good crossbuild toolchain. This is
> > the simplest way to provide that option.
>
> Meh. The primary audience of this feature are people building UEFI for
> X64 on X64, in which case the GCC4x options are arguably simpler. But
> apparently we agree that we should keep it /and/ support it.
>
> > By the way, do you think I can get you to update the mingw-gcc-build.py
> > script while you're at it? :)
>
> I proposed some updates here
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
> (with you on cc). Care to ack those?
Is there a particular reason why you chose to use binutils from www.kernel.org
rather than from ftpmirror.gnu.org (other than "that's what it was doing
before")? In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
thought it made more sense to get both packages from the same place.
source_files_common = {
'binutils': {
'url': 'http://ftpmirror.gnu.org/binutils/' + \
'binutils-$version.tar.bz2',
'version': '2.25',
'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
},
}
-Bill
> Thanks,
> Ard.
--
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
"I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] BaseTools: Add support for nested !include in FDF and DSC files
Posting to the new list in case this got missed
Reviewed-by: Samer El-Haj-Mahmoud
>From 839512c7d9e74c2de0234299538220968826a4b7 Mon Sep 17 00:00:00 2001
From: Cecil Sheng
Date: Mon, 6 Jul 2015 12:15:59 +0800
Subject: [PATCH] BaseTools: Nested !include support in DSC and FDF files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cecil Sheng
---
BaseTools/Source/Python/GenFds/FdfParser.py| 98 ++
.../Source/Python/Workspace/MetaFileParser.py | 12 +--
2 files changed, 91 insertions(+), 19 deletions(-)
diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
b/BaseTools/Source/Python/GenFds/FdfParser.py
index 83d3e19..664bf8e 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -2,6 +2,7 @@
# parse FDF file
#
# Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2015, Hewlett Packard Enterprise Development, L.P.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -81,16 +82,31 @@ RegionSizeGuidPattern =
re.compile("\s*(?P\w+\.\w+)\s*\|\s*(?P\w+\.\
RegionOffsetPcdPattern = re.compile("\s*(?P\w+\.\w+)\s*$")
ShortcutPcdPattern =
re.compile("\s*\w+\s*=\s*(?P(?:0x|0X)?[a-fA-F0-9]+)\s*\|\s*(?P\w+\.\w+)\s*")
-IncludeFileList = []
+AllIncludeFileList = []
+
+# Get the closest parent
+def GetParentAtLine (Line):
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile
+return None
+
+# Check include loop
+def IsValidInclude (File, Line):
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line) and Profile.FileName == File:
+return False
+
+return True
def GetRealFileLine (File, Line):
InsertedLines = 0
-for Profile in IncludeFileList:
-if Line >= Profile.InsertStartLineNumber and Line <
Profile.InsertStartLineNumber + Profile.InsertAdjust +
len(Profile.FileLinesList):
-return (Profile.FileName, Line - Profile.InsertStartLineNumber + 1)
-if Line >= Profile.InsertStartLineNumber + Profile.InsertAdjust +
len(Profile.FileLinesList):
-InsertedLines += Profile.InsertAdjust + len(Profile.FileLinesList)
+for Profile in AllIncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile.GetLineInFile(Line)
+elif Line >= Profile.InsertStartLineNumber and Profile.Level == 1:
+ InsertedLines += Profile.GetTotalLines()
return (File, Line - InsertedLines)
@@ -111,6 +127,7 @@ class Warning (Exception):
FileLineTuple = GetRealFileLine(File, Line)
self.FileName = FileLineTuple[0]
self.LineNumber = FileLineTuple[1]
+self.OriginalLineNumber = Line
self.Message = Str
self.ToolName = 'FdfParser'
@@ -157,6 +174,38 @@ class IncludeFileProfile :
self.InsertStartLineNumber = None
self.InsertAdjust = 0
+self.IncludeFileList = []
+self.Level = 1 # first level include file
+
+def GetTotalLines(self):
+TotalLines = self.InsertAdjust + len(self.FileLinesList)
+
+for Profile in self.IncludeFileList:
+ TotalLines += Profile.GetTotalLines()
+
+return TotalLines
+
+def IsLineInFile(self, Line):
+if Line >= self.InsertStartLineNumber and Line <
self.InsertStartLineNumber + self.GetTotalLines():
+return True
+
+return False
+
+def GetLineInFile(self, Line):
+if not self.IsLineInFile (Line):
+return (self.FileName, -1)
+
+InsertedLines = self.InsertStartLineNumber
+
+for Profile in self.IncludeFileList:
+if Profile.IsLineInFile(Line):
+return Profile.GetLineInFile(Line)
+elif Line >= Profile.InsertStartLineNumber:
+InsertedLines += Profile.GetTotalLines()
+
+return (self.FileName, Line - InsertedLines + 1)
+
+
## The FDF content class that used to record file data when parsing FDF
#
@@ -306,10 +355,12 @@ class FdfParser:
# Reset file data buffer to the initial state
#
# @param selfThe object pointer
+# @param DestLineOptional new destination line number.
+# @param DestOffset Optional new destination offset.
#
-def Rewind(self):
-self.CurrentLineNumber = 1
-self.CurrentOffsetWithinLine = 0
+def Rewind(self, DestLine = 1, DestOffset = 0):
+self.CurrentLineNumber = DestLine
+self.CurrentOffsetWithinLine = DestOffset
## __UndoOneChar() method
#
@@ -565,10 +616,12 @@ class FdfParser:
# @param selfThe object pointer
#
def PreprocessIncludeFile(self):
-
+ # nested include support
+Processed = False
while self.__GetNextToken():
if self.__Token == '
Re: [edk2] [Patch] NetworkPkg: Update HttpDxe to consume EFI_HTTP_UTILITIES_PROTOCOL
Reviewed-by: Samer El-Haj-Mahmoud
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Monday, August 24, 2015 12:47 AM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Siyuan Fu
Subject: [edk2] [Patch] NetworkPkg: Update HttpDxe to consume
EFI_HTTP_UTILITIES_PROTOCOL
Since we add EFI_HTTP_UTILITIES_PROTOCOL support, HttpDxe driver should be
updated to remove internal http utilities functions and consume this protocol
directly.
Cc: Ye Ting
Cc: Siyuan Fu
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu
---
NetworkPkg/HttpDxe/HttpDriver.h| 4 +-
NetworkPkg/HttpDxe/HttpDxe.inf | 3 +-
NetworkPkg/HttpDxe/HttpImpl.c | 21 +-
NetworkPkg/HttpDxe/HttpProto.c | 33 +-
NetworkPkg/HttpDxe/HttpUtilities.c | 622 -
NetworkPkg/HttpDxe/HttpUtilities.h | 82 -
6 files changed, 46 insertions(+), 719 deletions(-) delete mode 100644
NetworkPkg/HttpDxe/HttpUtilities.c
delete mode 100644 NetworkPkg/HttpDxe/HttpUtilities.h
diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index 5bad705..d95b05b 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -39,10 +39,11 @@
#include
//
// Consumed Protocols
//
+#include
#include
#include
#include
//
@@ -60,18 +61,19 @@
//
extern EFI_DRIVER_BINDING_PROTOCOL gHttpDxeDriverBinding; extern
EFI_COMPONENT_NAME2_PROTOCOL gHttpDxeComponentName2; extern
EFI_COMPONENT_NAME_PROTOCOL gHttpDxeComponentName;
+extern EFI_HTTP_UTILITIES_PROTOCOL *mHttpUtilities;
+
//
// Include files with function prototypes // #include "ComponentName.h"
#include "HttpImpl.h"
#include "HttpProto.h"
#include "HttpDns.h"
-#include "HttpUtilities.h"
typedef struct {
EFI_SERVICE_BINDING_PROTOCOL *ServiceBinding;
UINTN NumberOfChildren;
EFI_HANDLE*ChildHandleBuffer;
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index 4632934..d9652b3 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -36,12 +36,10 @@
HttpDriver.c
HttpImpl.h
HttpImpl.c
HttpProto.h
HttpProto.c
- HttpUtilities.h
- HttpUtilities.c
[LibraryClasses]
UefiDriverEntryPoint
UefiBootServicesTableLib
MemoryAllocationLib
@@ -52,10 +50,11 @@
HttpLib
[Protocols]
gEfiHttpServiceBindingProtocolGuid ## BY_START
gEfiHttpProtocolGuid ## BY_START
+ gEfiHttpUtilitiesProtocolGuid## TO_START
gEfiTcp4ServiceBindingProtocolGuid ## TO_START
gEfiTcp4ProtocolGuid ## TO_START
gEfiDns4ServiceBindingProtocolGuid ## SOMETIMES_CONSUMES
gEfiDns4ProtocolGuid ## SOMETIMES_CONSUMES
gEfiIp4Config2ProtocolGuid ## SOMETIMES_CONSUMES
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 80e8192..37d1c83 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -13,10 +13,12 @@
**/
#include "HttpDriver.h"
+EFI_HTTP_UTILITIES_PROTOCOL *mHttpUtilities = NULL;
+
EFI_HTTP_PROTOCOL mEfiHttpTemplate = {
EfiHttpGetModeData,
EfiHttpConfigure,
EfiHttpRequest,
EfiHttpCancel,
@@ -951,14 +953,31 @@ HttpResponseWorker (
}
CopyMem (HeaderTmp, Tmp, SizeofHeaders);
FreePool (HttpHeaders);
HttpHeaders = HeaderTmp;
+
+//
+// Locate and check whether the EFI_HTTP_UTILITIES_PROTOCOL is available.
+//
+if (mHttpUtilities == NULL) {
+ Status = gBS->LocateProtocol (&gEfiHttpUtilitiesProtocolGuid, NULL,
(VOID **) &mHttpUtilities);
+ if (EFI_ERROR (Status) || mHttpUtilities == NULL) {
+goto Error;
+ }
+}
+
//
// Parse the HTTP header into array of key/value pairs.
//
-Status = HttpUtilitiesParse (HttpHeaders, SizeofHeaders,
&HttpMsg->Headers, &HttpMsg->HeaderCount);
+Status = mHttpUtilities->Parse (
+ mHttpUtilities,
+ HttpHeaders,
+ SizeofHeaders,
+ &HttpMsg->Headers,
+ &HttpMsg->HeaderCount
+ );
if (EFI_ERROR (Status)) {
goto Error;
}
FreePool (HttpHeaders);
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index 50ade4c..06e1b9d 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1070,22 +1070,33 @@ HttpGenRequestString (
for(Index = 0; Index < Message->HeaderCount; Index++){
AppendList[Index] = &Message->Headers[Index];
}
//
+ // Locate and check whether the EFI_HTTP_UTILITIES_PROTOCOL is available.
+ //
+ if (mHttpUtilities == NULL) {
+gBS->LocateProtocol (&gEfiHttpUtil
Re: [edk2] [PATCH v2 0/3] unify FVP Base and Foundation model support
On 18 August 2015 at 16:10, Ard Biesheuvel wrote: > Instead of omitting some drivers that are known to break the Foundation > model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they > simply fail to load without interfering with the boot. > > Changes since v1: > - Print a diagnostic at EFI_D_WARN level that we are about to access the > PrimeCell ID registers. This is currently not required, since the Foundation > model deals gracefully with the reads to the unpopulated range, but this may > change in future versions > - Added Leif's R-b > - Rebased onto latest upstream > @Ryan, Please let me know if you have any concerns regarding this series. Thanks, Ard. > Ard Biesheuvel (3): > ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing > ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before > initializing > ArmPlatformPkg/FVP: unify support for Foundation and Base models > > ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 13 > > ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 4 > ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c | 5 + > ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h | 2 +- > ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 22 > > ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c | 16 > ++ > ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h | 17 > +++ > ArmPlatformPkg/Include/Drivers/PL111Lcd.h | 9 > > 8 files changed, 70 insertions(+), 18 deletions(-) > > -- > 1.9.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg/CpuDxe: Disable interrupt before restoring context
On 23 August 2015 at 17:59, Ard Biesheuvel wrote:
> On 23 August 2015 at 15:39, Heyi Guo wrote:
>>
>>
>> On 08/17/2015 05:52 PM, Ard Biesheuvel wrote:
>>>
>>> On 13 August 2015 at 05:10, Heyi Guo wrote:
Interrupt must be disabled before we storing ELR and other system
registers, or else ELR will be overridden by interrupt reentrance.
This bug is critical as we may get occasional exception or dead loop
when interrupt reentrance occurs:
After increasing SP ... Before popping out registers
Or
After restoring ELR
The 1st circumstance could also be resolved by optimizing SP operation
(Pop out registers before adding SP back), but the 2nd could not be
resolved by disabling interrupt.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Cc: Leif Lindholm
Cc: Ard Biesheuvel
---
ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S | 8
1 file changed, 8 insertions(+)
diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
b/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
index 2682f4f..ca6c9a1 100644
--- a/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
+++ b/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
@@ -358,6 +358,14 @@ ASM_PFX(AsmCommonExceptionEntry):
#define REG_PAIR(REG1, REG2, OFFSET, CONTEXT_SIZE)ldp REG1, REG2,
[sp, #(OFFSET-CONTEXT_SIZE)]
#define REG_ONE(REG1, OFFSET, CONTEXT_SIZE) ldur REG1, [sp,
#(OFFSET-CONTEXT_SIZE)]
+ //
+ // Disable interrupt(IRQ and FIQ) before restoring context,
+ // or else the context will be corrupted by interrupt reentrance.
+ // Interrupt mask will be restored from spsr by hardware when we call
eret
+ //
+ msr daifset, #3
+ isb
+
>>>
>>> Are you sure this is necessary? According to the ARM ARM
>>>
>>> """
>>> On taking any exception to an Exception level using AArch64, all of
>>> PSTATE.{A, I, F} are set to 1, masking all
>>> interrupts that target that Exception level.
>>> """
>>
>> Yes. However, in timer interrupt handler, we will raise TPL to HIGH_LEVEL
>> and then restore TPL, while restore TPL will enable interrupt.
>>
>
> Is that in the generic ARM timer code? Perhaps we should raise and
> lower the TPL in the common interrupt entry/exit path, since the
> architecture implicitly raises the TPL by entering the interrupt
> handler with interrupts disabled. In general, I don't think it is
> correct for TPL lowering code to enable interrupts if it did not find
> the enabled when it raised the TPL.
>
>> So I think we can't avoid interrupt reentering in UEFI architecture and need
>> protection when restoring interrupt context.
>>
Yes, it seems you are right. Even though I am not happy with the idea
that we are supporting nested interrupts without exactly understanding
the implication and without there being a real need (since we use
interrupts for the timer tick only), the core does not really allow us
to change that for AARCH64 only.
So I think your patch is correct. There are still two issues to resolve, though:
1. Could you update the comment in the code to mention that interrupts
have been re-enabled by the TPL lowering code, and that we need to
disable them again only to protect the critical section that restores
the interrupted context from the stack?
2. The 32-bit ARM code appears to suffer from the same problem, so we
should fix that as well.
--
Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdeModulePkg PiSmmCore: Prevent overlap for gSmmCorePrivate and CommBuffer
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 55dcf31..9f47d27 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -427,9 +427,13 @@ SmmEntryPoint (
//
// Synchronous SMI for SMM Core or request from Communicate protocol
//
- if (!SmmIsBufferOutsideSmmValid
((UINTN)gSmmCorePrivate->CommunicationBuffer, gSmmCorePrivate->BufferSize)) {
+ if (!SmmIsBufferOutsideSmmValid
((UINTN)gSmmCorePrivate->CommunicationBuffer, gSmmCorePrivate->BufferSize) ||
+ !UINTN) gSmmCorePrivate->CommunicationBuffer +
gSmmCorePrivate->BufferSize) <= (UINTN) gSmmCorePrivate) ||
+((UINTN) gSmmCorePrivate->CommunicationBuffer >= ((UINTN)
gSmmCorePrivate + sizeof (*gSmmCorePrivate) {
//
-// If CommunicationBuffer is not in valid address scope, return
EFI_INVALID_PARAMETER
+// If CommunicationBuffer is not in valid address scope,
+// or there is overlap between gSmmCorePrivate and CommunicationBuffer,
+// return EFI_INVALID_PARAMETER
//
gSmmCorePrivate->CommunicationBuffer = NULL;
gSmmCorePrivate->ReturnStatus = EFI_INVALID_PARAMETER;
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory reservation from PrePi to DXE
Ben, We are looking into the issue you raised, will get back to you if we have comments. Thanks Feng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Benjamin Herrenschmidt Sent: Saturday, August 22, 2015 12:35 To: Tian, Feng Cc: Kinney, Michael D; edk2-devel@lists.01.org; Laszlo Ersek; Andrew Fish Subject: Re: [edk2] Question about memory reservation from PrePi to DXE On Mon, 2015-08-10 at 16:18 -0700, Andrew Fish wrote: > Laszlo and I are not the maintainers for this code. > https://github.com/tianocore/edk2/blob/master/Maintainers.txt < > https://github.com/tianocore/edk2/blob/master/Maintainers.txt> > > But it does feel like the assumption in the DXE Core is not implied by > the PI Specifications. Hi Feng ! You never replied to that thread ... my problem is that the code in CoreInitializeMemoryServices() will essentially pickup a piece of memory out of *any* memory descriptor HOB completely ignoring the memory allocation HOBs. That means that if Sec or Peim (or in my case, a special PrePei that transfers controls to DXE from a different firmware layer) has marked some memory as reserved via some memory allocation HOBs, there is still a chance that this memory gets overwriten early during DXE initialization, because CoreInitializeMemoryServices() ignores those allocations completely to pick up the initial core memory, which it then makes available to the allocator with CoreAddMemoryDescriptor(). It appears that the Gcd code is generally trying to honor the existing allocation HOBs since later on, CoreInitializeGcdServices() will iterate them and allocates them, but this happens after the above initialization and some allocations do happen in between. Is there a non-documented (or maybe I missed the documentation) requirement that all the Memory resource descriptor HOBs passed to DXE have been modified to *remove* all allocated space from them to avoid that problem or is this mainly a bug ? It does make the transition from a Flat Device Tree to DXE tricky, since in the FDT world, we have on one hand the "memory" modes that give us the regions of physical memory in the system, which would nicely translate to memory resource descriptors, and separately we have a reserve map which describes ranges of addresses that are reserved, either by some firmware layer or in some cases by the HW itself. Unless I missed something, while the spec allows us to match this to memory resource descriptors and memory allocation HOBs respectively, the DXE implementation will fail to honor such overlap properly. Am I correct ? Cheers, Ben. ___ 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] Some pages on new TianoCore wiki not being indexed (no results on Google)?
(+ Leif) On 24 August 2015 at 06:27, Bruce Cran wrote: > It seems indexing of the new wiki at http://tianocore.org is rather poor: I > was looking for some information about the BeagleBoard/BeagleBone, Those instructions are slightly outdated after some recent cleanup work (I was not aware of the existence of these pages or I would have cleaned them up as well) We removed the build scripts since you can now use 'build -a ARM -p BeagleBoardPkg/BeagleBoardPkg.dsc' directly. We also removed ARMGCC and ARMLINUXGCC because GCC44 - GCC49 are better supported, and so they should be used instead. Also note that BeagleBoard != BeagleBone; the former is TI OMAP3 and the latter is TI AM33xx, which is also Cortex-A8, but a completely different SoC otherwise. We do have a port for BeagleBone Black; Leif should be able to tell you where to find it. -- Ard. > and have found that even > https://www.google.com/search?q=Beagle+Board+Wiki#q=tianocore+%22Beagle+Board+Wiki%22 > doesn't have any results on tianocore.org - or github.com, since the page is > actually at > https://github.com/tianocore/tianocore.github.io/wiki/Beagle-Board-Wiki . > > Is there a way to improve this, and also should the wiki on sourceforge.net > be turned off to prevent confusion? > > -- > Bruce > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 2/3] MdePkg/Library/UefiFileHandleLib: Make the FileHandleGetFileName return the file name in right format.
If the file is not a directory remove the redundant '\' char in file name
string returned from FileHandleGetFileName.
Cc: Jaben Carsey
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin
Reviewed-by: Jaben Carsey
---
MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 8
1 file changed, 8 insertions(+)
diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index f6cbfad..0bb82be 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -856,6 +856,14 @@ FileHandleGetFileName (
*FullFileName = StrnCatGrowLeft(FullFileName, &Size, L"\\", 0);
}
+ if (*FullFileName != NULL &&
+ (*FullFileName)[StrLen(*FullFileName) - 1] == L'\\' &&
+ StrLen(*FullFileName) > 1 &&
+ FileHandleIsDirectory(Handle) == EFI_NOT_FOUND
+ ) {
+(*FullFileName)[StrLen(*FullFileName) - 1] = CHAR_NULL;
+ }
+
if (CurrentHandle != NULL) {
CurrentHandle->Close (CurrentHandle);
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
