[edk2] [PATCH v2] MdeModulePkg/SdDxe: Fix potential NULL pointer access
SdReadWrite can be called with a NULL Token for synchronous operations.
Add guard for DEBUG print to only print event pointer with Token is not
NULL.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen
---
MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
b/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
index b8d115a..a4695ff 100644
--- a/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
+++ b/MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c
@@ -670,8 +670,9 @@ SdReadWrite (
if (EFI_ERROR (Status)) {
return Status;
}
-DEBUG ((DEBUG_BLKIO, "Sd%a(): Lba 0x%x BlkNo 0x%x Event %p with %r\n",
IsRead ? "Read" : "Write", Lba, BlockNum, Token->Event, Status));
-
+DEBUG ((DEBUG_BLKIO, "Sd%a(): Lba 0x%x BlkNo 0x%x Event %p with %r\n",
+ IsRead ? "Read" : "Write", Lba, BlockNum,
+ (Token != NULL) ? Token->Event : NULL, Status));
Lba += BlockNum;
Buffer = (UINT8*)Buffer + BufferSize;
Remaining -= BlockNum;
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v2 3/4] Hisilicon/D06: Fix set usb reg failed issue
The default link timeout value of USB 3.0 controller is a bit short for some USB devices, and may cause it timeout in some cases. We have modify the registers in IoInitDxe,but a bug let the modifying not successful. Build commit informations: edk2:53caffc33b6 edk2-platforms:d4d7e39886a HwPkg:2a7ee82855a TrustedFirmware:5888a78d43c Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 229248 -> 230784 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi index c9172ff..8b6d740 100644 Binary files a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi and b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v2 2/4] Hisilicon/D06: Fix SBSA test case 42 failed issues
As SBSA uefi tool can't configuare interrupt following WatchdogTimerFlags in GTDT, and watchdog interrupt in Hi1620 is edge-trigger, so modify watchdog interrupt type for SBSA test case 42. Build commit informations: edk2:53caffc33b6 edk2-platforms:d4d7e39886a HwPkg:bf0bdef14d5 TrustedFirmware:5888a78d43c Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm --- Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 229216 -> 229248 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi index afd3ebe..c9172ff 100644 Binary files a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi and b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v2 4/4] Hisilicon/D06: Fix SBSA PE-15 failed issue
PE test case 15 flow:
Primary core(cacheable shareable) and slave cores(non-cacheable)
access the same memory area for communication.
For each slave core{
1 Turn on slave core;
2 run the payload function;
3 Write result in memory to notify primary core and follow
clean and invalidate instruction;
4 Slave core turn off itself;
}
The result in DDR may rewrite by cache data. The essence of
this problem is that primary core and slave core access the
same area with different cache attribute.
Configure L3T register to fix this issue;
Build commit informations:
edk2:53caffc33b6
edk2-platforms:d4d7e39886a
HwPkg:6e91ea20fda
TrustedFirmware:5888a78d43c
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 230784 -> 232832
bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi
b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi
index 8b6d740..e32c056 100644
Binary files a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi and
b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi differ
--
2.9.5
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v2 0/4] Upload D06 binary modules for SBSA test
Main Change since v1: 1 Modify comments; Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: d06-acs-non-osi-v2 Ming Huang (4): Hisilicon/D06: Add cpu on/off feature in TrustedFirmware Hisilicon/D06: Fix SBSA test case 42 failed issues Hisilicon/D06: Fix set usb reg failed issue Hisilicon/D06: Fix SBSA PE-15 failed issue Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 229216 -> 232832 bytes Platform/Hisilicon/D06/bl1.bin | Bin 12432 -> 12432 bytes Platform/Hisilicon/D06/fip.bin | Bin 113578 -> 113450 bytes 3 files changed, 0 insertions(+), 0 deletions(-) -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-non-osi v2 1/4] Hisilicon/D06: Add cpu on/off feature in TrustedFirmware
Add cpu on/off feature to support SBSA-PE test. This patch also fix bug 3996: https://bugs.linaro.org/show_bug.cgi?id=3996 Build commit information: TrustedFirmware:5888a78d43c Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ming Huang --- Platform/Hisilicon/D06/bl1.bin | Bin 12432 -> 12432 bytes Platform/Hisilicon/D06/fip.bin | Bin 113578 -> 113450 bytes 2 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/Hisilicon/D06/bl1.bin b/Platform/Hisilicon/D06/bl1.bin index d291359..416535f 100644 Binary files a/Platform/Hisilicon/D06/bl1.bin and b/Platform/Hisilicon/D06/bl1.bin differ diff --git a/Platform/Hisilicon/D06/fip.bin b/Platform/Hisilicon/D06/fip.bin index a72bef8..c9b7ca0 100644 Binary files a/Platform/Hisilicon/D06/fip.bin and b/Platform/Hisilicon/D06/fip.bin differ -- 2.9.5 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit ADMA2 support.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Friday, November 09, 2018 2:58 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit
> ADMA2 support.
>
> If V4 64 bit address mode is enabled in compatibility register,
> program controller to enable V4 host mode and use appropriate
> ADMA descriptors supporting 64 bit addresses.
Hi,
I have a quick check on the SD Host Controller Simplified Specification Version
4.20. When the 'Host Version 4 Enable' bit in the HC2 Register is set, for host
controller with version newer than 3.0:
SDMA mode transfer no longer use SDMA System Address Register for system
address, and this SDMA System Address Register will be used as 32-bit Block
Count instead under certain case.
So I think the way to start an SDMA mode transfer is not the same between host
controllers with different versions. However, I do not see this patch handle
this potential behavior change. Please correct me if my understanding is
incorrect here.
Also, could you help to provide information on what tests have been performed
on this series?
Thanks in advance.
Best Regards,
Hao Wu
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 4 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 183
> +
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 28 +++-
> 3 files changed, 183 insertions(+), 32 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index c683600..22795df 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,6 +2,7 @@
>
>Provides some data structure definitions used by the SD/MMC host controller
> driver.
>
> +Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 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
> @@ -144,7 +145,8 @@ typedef struct {
>BOOLEAN Started;
>UINT64 Timeout;
>
> - SD_MMC_HC_ADMA_DESC_LINE*AdmaDesc;
> + SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
> + SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
>EFI_PHYSICAL_ADDRESSAdmaDescPhy;
>VOID*AdmaMap;
>UINT32 AdmaPages;
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index e506875..bcd2707 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -4,6 +4,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> + Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -418,6 +419,36 @@ SdMmcHcWaitMmioSet (
> }
>
> /**
> + Get the controller version information from the specified slot.
> +
> + @param[in] PciIo The PCI IO protocol instance.
> + @param[in] SlotThe slot number of the SD card to send the
> command to.
> + @param[out] Version The buffer to store the version information.
> +
> + @retval EFI_SUCCESS The operation executes successfully.
> + @retval Others The operation fails.
> +
> +**/
> +EFI_STATUS
> +SdMmcHcGetControllerVersion (
> + IN EFI_PCI_IO_PROTOCOL *PciIo,
> + IN UINT8Slot,
> + OUT UINT16 *Version
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_CTRL_VER, TRUE,
> sizeof (UINT16), Version);
> + if (EFI_ERROR (Status)) {
> +return Status;
> + }
> +
> + *Version &= 0xFF;
> +
> + return EFI_SUCCESS;
> +}
> +
> +/**
>Software reset the specified SD/MMC host controller and enable all
> interrupts.
>
>@param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA
> instance.
> @@ -776,18 +807,18 @@ SdMmcHcClockSupply (
>
>DEBUG ((DEBUG_INFO, "BaseClkFreq %dMHz Divisor %d ClockFreq %dKhz\n",
> BaseClkFreq, Divisor, ClockFreq));
>
> - Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_CTRL_VER, TRUE,
> sizeof (ControllerVer), &ControllerVer);
> + Status = SdMmcHcGetControllerVersion (PciIo, Slot, &ControllerVer);
>if (EFI_ERROR (Status)) {
> return Status;
>}
>//
>// Set SDCLK Frequency Select and Internal Clock Enable fields in Clock
> Control regi
[edk2] [RFC] Proposal on Python3 Migration
Hi, all https://pythonclock.org/ say Python 2.7 will not be maintained past 2020. One BZ https://bugzilla.tianocore.org/show_bug.cgi?id=55 also requests this migration. And, Python37 does good performance optimization. In EDK2 build, Python37 can improve 20% performance than Python27 in Build AutoGen phase. So, we plan to add Python3 support in BaseTools. In previous discussion, the feedback is not to drop Python2 support in short term, and keep Python2 and Python3 coexist. My proposal is to add two copy BaseTools Python code in BaseTools/Source directory. One is current BaseTools/Source/Python, another is new BaseTools/Source/Python3. edksetup.bat/edksetup.sh base on environment variable (PYTHON3_HOME) to know whether Python3 is used. If PYTHON3_HOME is not set, Python2 is still used as current way. If user wants to enable Python3, he needs to set PYTHON3_HOME. After 201811 release tag, BaseTools Python2 source code is kept as the stable release. Python3 is as the active trunk. By default, any change will be for Python3. If the submitter also request the change for Python2, he needs to list it in BZ description. If the submitter has the clear request, Python2 can add new feature or enhancement. If you have any comments or suggestion on Python3 migration, please join this discussion. Thanks Liming ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch v1 1/1] BaseTools: cleanup LongFilePathSupport usage
1) remove an identical function and import it from Common.LongFilePathSupport
2) remove an import that is not needed/used.
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/AutoGen/UniClassObject.py | 14 +-
BaseTools/Source/Python/build/build.py| 1 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py
b/BaseTools/Source/Python/AutoGen/UniClassObject.py
index 384f31b165de..764d95ec660b 100644
--- a/BaseTools/Source/Python/AutoGen/UniClassObject.py
+++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py
@@ -24,7 +24,7 @@ from io import BytesIO
from Common.BuildToolError import *
from Common.StringUtils import GetLineNo
from Common.Misc import PathClass
-from Common.LongFilePathSupport import LongFilePath
+from Common.LongFilePathSupport import LongFilePath, UniToStr
from Common.GlobalData import *
##
# Static definitions
@@ -46,18 +46,6 @@ BACK_SLASH_PLACEHOLDER = u'\u0006'
gIncludePattern = re.compile("^#include +[\"<]+([^\"< >]+)[>\"]+$",
re.MULTILINE | re.UNICODE)
-## Convert a python unicode string to a normal string
-#
-# Convert a python unicode string to a normal string
-# UniToStr(u'I am a string') is 'I am a string'
-#
-# @param Uni: The python unicode string
-#
-# @retval: The formatted normal string
-#
-def UniToStr(Uni):
-return repr(Uni)[2:-1]
-
## Convert a unicode string to a Hex list
#
# Convert a unicode string to a Hex list
diff --git a/BaseTools/Source/Python/build/build.py
b/BaseTools/Source/Python/build/build.py
index d74082fc2666..5eeb626cfbbb 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -36,7 +36,6 @@ from subprocess import *
from Common import Misc as Utils
from Common.LongFilePathSupport import OpenLongFilePath as open
-from Common.LongFilePathSupport import LongFilePath
from Common.TargetTxtClassObject import *
from Common.ToolDefClassObject import *
from Common.DataType import *
--
2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch v1 1/1] BaseTools: create and use a standard shared variable for '*'
add a variable for the string '*' and then use it instead of lots of '*'
Cc: Yonghong Zhu
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 54
++--
BaseTools/Source/Python/AutoGen/BuildEngine.py | 10 ++--
BaseTools/Source/Python/BPDG/GenVpd.py | 14 ++---
BaseTools/Source/Python/Common/DataType.py | 1 +
BaseTools/Source/Python/Common/Expression.py | 4 +-
BaseTools/Source/Python/Common/Misc.py | 2 +-
BaseTools/Source/Python/Common/ToolDefClassObject.py | 23 +
BaseTools/Source/Python/Common/VpdInfoFile.py | 8 +--
BaseTools/Source/Python/GenFds/FdfParser.py| 5 +-
BaseTools/Source/Python/GenFds/GenFds.py | 2 +-
BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py | 8 +--
BaseTools/Source/Python/GenFds/Section.py | 2 +-
BaseTools/Source/Python/Workspace/DscBuildData.py | 6 +--
13 files changed, 70 insertions(+), 69 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index f3560bfc787d..25417c447061 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -1438,7 +1438,7 @@ class PlatformAutoGen(AutoGen):
PcdValue = Sku.DefaultValue
if PcdValue == "":
PcdValue = Pcd.DefaultValue
-if Sku.VpdOffset != '*':
+if Sku.VpdOffset != TAB_STAR:
if PcdValue.startswith("{"):
Alignment = 8
elif PcdValue.startswith("L"):
@@ -1462,7 +1462,7 @@ class PlatformAutoGen(AutoGen):
VpdFile.Add(Pcd, SkuName, Sku.VpdOffset)
SkuValueMap[PcdValue].append(Sku)
# if the offset of a VPD is *, then it need to be
fixed up by third party tool.
-if not NeedProcessVpdMapFile and Sku.VpdOffset == "*":
+if not NeedProcessVpdMapFile and Sku.VpdOffset ==
TAB_STAR:
NeedProcessVpdMapFile = True
if self.Platform.VpdToolGuid is None or
self.Platform.VpdToolGuid == '':
EdkLogger.error("Build", FILE_NOT_FOUND, \
@@ -1522,7 +1522,7 @@ class PlatformAutoGen(AutoGen):
PcdValue = Sku.DefaultValue
if PcdValue == "":
PcdValue = DscPcdEntry.DefaultValue
-if Sku.VpdOffset != '*':
+if Sku.VpdOffset != TAB_STAR:
if PcdValue.startswith("{"):
Alignment = 8
elif PcdValue.startswith("L"):
@@ -1545,7 +1545,7 @@ class PlatformAutoGen(AutoGen):
SkuValueMap[PcdValue] = []
VpdFile.Add(DscPcdEntry, SkuName,
Sku.VpdOffset)
SkuValueMap[PcdValue].append(Sku)
-if not NeedProcessVpdMapFile and Sku.VpdOffset
== "*":
+if not NeedProcessVpdMapFile and Sku.VpdOffset
== TAB_STAR:
NeedProcessVpdMapFile = True
if DscPcdEntry.DatumType == TAB_VOID and
PcdValue.startswith("L"):
UnicodePcdArray.add(DscPcdEntry)
@@ -1573,7 +1573,7 @@ class PlatformAutoGen(AutoGen):
if os.path.exists(VpdMapFilePath):
VpdFile.Read(VpdMapFilePath)
-# Fixup "*" offset
+# Fixup TAB_STAR offset
for pcd in VpdSkuMap:
vpdinfo = VpdFile.GetVpdInfo(pcd)
if vpdinfo is None:
@@ -2210,15 +2210,15 @@ class PlatformAutoGen(AutoGen):
def CalculatePriorityValue(self, Key):
Target, ToolChain, Arch, CommandType, Attr = Key.split('_')
PriorityValue = 0x1
-if Target == "*":
+if Target == TAB_STAR:
PriorityValue &= 0x0
-if ToolChain == "*":
+if ToolChain == TAB_STAR:
PriorityValue &= 0x10111
-if Arch == "*":
+if Arch == TAB_STAR:
PriorityValue &= 0x11011
-if CommandType == "*":
+if CommandType == TAB_STAR:
PriorityValue &= 0x11101
-if Attr == "*":
+if Attr == TAB_STAR:
PriorityValue &= 0x0
return self.PrioList["0x%0.5x" % PriorityValue]
@@ -2253,9 +2253,9 @@ class PlatformAutoGen(AutoGen):
[edk2] [Patch v1 1/1] BaseTools: Move Identification file to Eot
Move the Identification file.
This file is only ever imported into the Eot tool.
Cc: Yonghong Zhu
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/{Common => Eot}/Identification.py | 0
BaseTools/Source/Python/Eot/InfParserLite.py | 3 ++-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/BaseTools/Source/Python/Common/Identification.py
b/BaseTools/Source/Python/Eot/Identification.py
similarity index 100%
rename from BaseTools/Source/Python/Common/Identification.py
rename to BaseTools/Source/Python/Eot/Identification.py
diff --git a/BaseTools/Source/Python/Eot/InfParserLite.py
b/BaseTools/Source/Python/Eot/InfParserLite.py
index c910c129a719..0cfe0398f05f 100644
--- a/BaseTools/Source/Python/Eot/InfParserLite.py
+++ b/BaseTools/Source/Python/Eot/InfParserLite.py
@@ -16,11 +16,12 @@
#
from __future__ import print_function
from __future__ import absolute_import
+
import Common.LongFilePathOs as os
import Common.EdkLogger as EdkLogger
from Common.DataType import *
from CommonDataClass.DataClass import *
-from Common.Identification import *
+from Eot.Identification import Identification
from Common.StringUtils import *
from Eot.Parser import *
from Eot import Database
--
2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Proposal on Python3 Migration
Liming, Adding a new Python3 directory will increase the maintenance and testing of the python-based BaseTools. It would be better if we could have one version of the python sources that work with both Python2 and Python3. We should use the edk2-staging branch to work towards this goal. Please explain why we can't support both in single set of sources. Are there technical reasons or resource reasons? Thanks, Mike From: Gao, Liming Sent: Friday, November 16, 2018 7:02 AM To: edk2-devel@lists.01.org Cc: Kinney, Michael D ; leif.lindh...@linaro.org; Laszlo Ersek (ler...@redhat.com) ; af...@apple.com Subject: [RFC] Proposal on Python3 Migration Hi, all https://pythonclock.org/ say Python 2.7 will not be maintained past 2020. One BZ https://bugzilla.tianocore.org/show_bug.cgi?id=55 also requests this migration. And, Python37 does good performance optimization. In EDK2 build, Python37 can improve 20% performance than Python27 in Build AutoGen phase. So, we plan to add Python3 support in BaseTools. In previous discussion, the feedback is not to drop Python2 support in short term, and keep Python2 and Python3 coexist. My proposal is to add two copy BaseTools Python code in BaseTools/Source directory. One is current BaseTools/Source/Python, another is new BaseTools/Source/Python3. edksetup.bat/edksetup.sh base on environment variable (PYTHON3_HOME) to know whether Python3 is used. If PYTHON3_HOME is not set, Python2 is still used as current way. If user wants to enable Python3, he needs to set PYTHON3_HOME. After 201811 release tag, BaseTools Python2 source code is kept as the stable release. Python3 is as the active trunk. By default, any change will be for Python3. If the submitter also request the change for Python2, he needs to list it in BZ description. If the submitter has the clear request, Python2 can add new feature or enhancement. If you have any comments or suggestion on Python3 migration, please join this discussion. Thanks Liming ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [edk2-announce][RFC] Collaboration Software
We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. Cheers, Stephano ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
If we get to vote, I’d vote against Google Groups. Their interface is very geared toward their internal work flow and seems to change on a whim. Thanks,Kevin On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" wrote: We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. Cheers, Stephano ___ 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] [edk2-announce][RFC] Collaboration Software
https://slack.com/ -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kevin D Davis Sent: Friday, November 16, 2018 9:35 AM To: stephano ; edk2-devel@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software If we get to vote, I’d vote against Google Groups. Their interface is very geared toward their internal work flow and seems to change on a whim. Thanks,Kevin On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" wrote: We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. Cheers, Stephano ___ 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
Re: [edk2] [edk2-announce][RFC] Collaboration Software
The only reason I didn't include Slack is that it will only log so much information before things start falling off into the ether. Does anyone in the community currently use Slack and know of an easy way of archiving conversations publicly? On 11/16/2018 9:56 AM, Zimmer, Vincent wrote: https://slack.com/ -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kevin D Davis Sent: Friday, November 16, 2018 9:35 AM To: stephano ; edk2-devel@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software If we get to vote, I’d vote against Google Groups. Their interface is very geared toward their internal work flow and seems to change on a whim. Thanks,Kevin On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" wrote: We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. Cheers, Stephano ___ 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
Re: [edk2] [edk2-announce][RFC] Collaboration Software
Hi Stephano, GitHub supports discussions for teams. If we added a new team to the GitHub TianoCore organization for all developers that want to be involved in community topics and design discussions (which should closely match the current members of edk2-devel) then that may be a simple option that uses services that already there. Another option is to use discussions for one of the exiting teams (e.g. Tianocore Maintainers) and make posts for these discussion topics public. https://blog.github.com/2017-11-20-introducing-team-discussions/ https://help.github.com/articles/about-team-discussions/ Best regards, Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] > On Behalf Of stephano > Sent: Friday, November 16, 2018 11:14 AM > To: Zimmer, Vincent ; edk2- > de...@lists.01.org > Subject: Re: [edk2] [edk2-announce][RFC] Collaboration > Software > > The only reason I didn't include Slack is that it will > only log so much > information before things start falling off into the > ether. > > Does anyone in the community currently use Slack and know > of an easy way > of archiving conversations publicly? > > > On 11/16/2018 9:56 AM, Zimmer, Vincent wrote: > > https://slack.com/ > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel- > boun...@lists.01.org] On Behalf Of Kevin D Davis > > Sent: Friday, November 16, 2018 9:35 AM > > To: stephano ; edk2- > de...@lists.01.org > > Subject: Re: [edk2] [edk2-announce][RFC] Collaboration > Software > > > > > > > > > > > > > > If we get to vote, I’d vote against Google > Groups. Their interface is very geared toward their > internal work flow and seems to change on a whim. > Thanks,Kevin > > > > > > > > > > > > On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" > wrote: > > > > > > > > > > > > > > > > > > > > > > We are looking to augment our current communication > methods (mailing list / IRC) with a modern solution for > group collaboration. The goal is to allow folks to > communicate effectively without interrupting the current > patch review system, as well as enabling any future > systems with more robust options. > > > > Specific features we are looking for include > attachments (currently blocked by the list), robust > logging, modern chat, and integration with tools like bug > trackers and source repositories (APIs, or better yet, > pre-rolled plugins). > > > > Our current contenders are Google Groups and Groups.io. > This RFC is in hopes of finding other options to > evaluate. > > > > Cheers, > > Stephano > > ___ > > 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-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On Friday, 16 November 2018 12:13:37 MST stephano wrote: > The only reason I didn't include Slack is that it will only log so much > information before things start falling off into the ether. > > Does anyone in the community currently use Slack and know of an easy way > of archiving conversations publicly? I'm in several Slack teams: it seems to be the go-to solution for persistent chat nowadays. None of those pay (i.e. they're on the free tier), so are subject to its 10,000 message history limit. Another option may be Conpherence, which comes with Phabricator: https:// www.phacility.com/phabricator/conpherence/ : "Conpherence is a group messaging application integrated into Phabricator. Message one-on-one or with a group of people, name your room, and keep a history of everything in one place. Reply via email, on the web, or on your mobile device. Conpherence supports Remarkup that makes it easy to link to Maniphest tasks and code reviews, share code snippets, format tables, and share memes. Conpherence even has a persistent chat sidebar built-in, so you don't need to keep another tab open." -- Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
This looks great. I'm going to dig in a bit and see if we can export discussions for logging purposes or if they are locked into Github. git clone git://tianocore.discussion ? :) On 11/16/2018 11:55 AM, Kinney, Michael D wrote: Hi Stephano, GitHub supports discussions for teams. If we added a new team to the GitHub TianoCore organization for all developers that want to be involved in community topics and design discussions (which should closely match the current members of edk2-devel) then that may be a simple option that uses services that already there. Another option is to use discussions for one of the exiting teams (e.g. Tianocore Maintainers) and make posts for these discussion topics public. https://blog.github.com/2017-11-20-introducing-team-discussions/ https://help.github.com/articles/about-team-discussions/ Best regards, Mike -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of stephano Sent: Friday, November 16, 2018 11:14 AM To: Zimmer, Vincent ; edk2- de...@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software The only reason I didn't include Slack is that it will only log so much information before things start falling off into the ether. Does anyone in the community currently use Slack and know of an easy way of archiving conversations publicly? On 11/16/2018 9:56 AM, Zimmer, Vincent wrote: https://slack.com/ -Original Message- From: edk2-devel [mailto:edk2-devel- boun...@lists.01.org] On Behalf Of Kevin D Davis Sent: Friday, November 16, 2018 9:35 AM To: stephano ; edk2- de...@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software If we get to vote, I’d vote against Google Groups. Their interface is very geared toward their internal work flow and seems to change on a whim. Thanks,Kevin On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" wrote: We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. Cheers, Stephano ___ 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-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On 11/16/2018 12:52 PM, Rebecca Cran wrote: I'm in several Slack teams: it seems to be the go-to solution for persistent chat nowadays. None of those pay (i.e. they're on the free tier), so are subject to its 10,000 message history limit. I have found the same situation in other open source communities. We want to be sure that our conversations are not lost, so I'm not sure if Slack is a viable option. We certainly open to this idea though, if others have found solutions to this issue. Another option may be Conpherence, which comes with Phabricator: https:// www.phacility.com/phabricator/conpherence/ : "Conpherence is a group messaging application integrated into Phabricator. Message one-on-one or with a group of people, name your room, and keep a history of everything in one place. Reply via email, on the web, or on your mobile device. Conpherence supports Remarkup that makes it easy to link to Maniphest tasks and code reviews, share code snippets, format tables, and share memes. Conpherence even has a persistent chat sidebar built-in, so you don't need to keep another tab open." This is a great suggestion, thanks! Two questions: 1. Does it allow you to export your conversations in some way? 2. Is there a "file sharing" option if we wanted to, for example, share a JPG or ODF file? ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On Friday, 16 November 2018 14:42:44 MST stephano wrote: > This is a great suggestion, thanks! Two questions: > 1. Does it allow you to export your conversations in some way? Conversations can followed via email, so that's one way of 'exporting' them. But otherwise, I suspect you'd need to either query the database directly or use "./bin/storage dump": DUMP WORKFLOW dump [options] Dump all data in storage to stdout. --compress With --output, write a compressed file to disk instead of a plaintext file. --for-replica Add --master-data to the mysqldump command, generating a CHANGE MASTER statement in the output. --no-indexes Do not dump data in rebuildable index tables. This means backups are smaller and faster, but you will need to manually rebuild indexes after performing a restore. --output file Write output directly to disk. This handles errors better than using pipes. Use with --compress to gzip the output. --overwrite With --output, overwrite the output file if it already exists. > 2. Is there a "file sharing" option if we wanted to, for example, share > a JPG or ODF file? Yes: Phabricator has a general file storage service, and files can be uploaded via that and shared in Conpherence. -- Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On 16/11/18 21:46, stephano wrote: This looks great. I'm going to dig in a bit and see if we can export discussions for logging purposes or if they are locked into Github. For people on the move, having bad internet (3rd world countries), email system is very powerful, you can download once and work offline, reading/answering. You can also download the list archive and refers to it offline. You also have access to all patches and can apply them offline too. Is this possible with GitHub? Maybe the open source alternative, GitLab, offers a such feature. Googling "gitlab offline" I get: "Many of our customers do not have regular Internet access and many of them, being highly regulated, cannot install local copies of GitLab to be able to run against the provided API. [...] The work, published as the gitlab-ci-yaml_lint gem, is my attempt at a start to solving the issue." This is not what I expected, but it confirms some people have troubles working with online-only services. Regards, Phil. git clone git://tianocore.discussion ? :) On 11/16/2018 11:55 AM, Kinney, Michael D wrote: Hi Stephano, GitHub supports discussions for teams. If we added a new team to the GitHub TianoCore organization for all developers that want to be involved in community topics and design discussions (which should closely match the current members of edk2-devel) then that may be a simple option that uses services that already there. Another option is to use discussions for one of the exiting teams (e.g. Tianocore Maintainers) and make posts for these discussion topics public. https://blog.github.com/2017-11-20-introducing-team-discussions/ https://help.github.com/articles/about-team-discussions/ Best regards, Mike -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of stephano Sent: Friday, November 16, 2018 11:14 AM To: Zimmer, Vincent ; edk2- de...@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software The only reason I didn't include Slack is that it will only log so much information before things start falling off into the ether. Does anyone in the community currently use Slack and know of an easy way of archiving conversations publicly? On 11/16/2018 9:56 AM, Zimmer, Vincent wrote: https://slack.com/ -Original Message- From: edk2-devel [mailto:edk2-devel- boun...@lists.01.org] On Behalf Of Kevin D Davis Sent: Friday, November 16, 2018 9:35 AM To: stephano ; edk2- de...@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software If we get to vote, I’d vote against Google Groups. Their interface is very geared toward their internal work flow and seems to change on a whim. Thanks,Kevin On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" wrote: We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. Cheers, Stephano ___ 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-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/2] ArmVirtPkg/PrePi: clear frame pointer in startup code
When setting up the stack in the startup code and jumping into C code for the first time, ensure that the frame pointer register is cleared so that backtraces terminate correctly. Otherwise, output like the below is shown when encountering an exception on a DEBUG build: Synchronous Exception at 0x78A14780 PC 0x78A14780 (0x78A0+0x00014780) [ 0] ArmVeNorFlashDxe.dll PC 0x78A10634 (0x78A0+0x00010634) [ 0] ArmVeNorFlashDxe.dll PC 0x78A11CF0 (0x78A0+0x00011CF0) [ 0] ArmVeNorFlashDxe.dll PC 0x78A11DD0 (0x78A0+0x00011DD0) [ 0] ArmVeNorFlashDxe.dll PC 0x7BC9D87C (0x7BC98000+0x587C) [ 1] PartitionDxe.dll PC 0x7BC99B3C (0x7BC98000+0x1B3C) [ 1] PartitionDxe.dll PC 0x7F362F50 (0x7F359000+0x9F50) [ 2] DxeCore.dll PC 0x7BD63BB0 (0x7BD5B000+0x8BB0) [ 3] BdsDxe.dll PC 0x7BD6EE00 (0x7BD5B000+0x00013E00) [ 3] BdsDxe.dll PC 0x7BD67C70 (0x7BD5B000+0xCC70) [ 3] BdsDxe.dll PC 0x7F3724F0 (0x7F359000+0x000194F0) [ 4] DxeCore.dll PC 0x4008FC30 PC 0x40090130 PC 0x5800F6025800F5E1 Recursive exception occurred while dumping the CPU state which is rather unhelpful, given that this prevent the remaining debug output from being printed (register dump, stack dump, fault related system registers etc) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S index 891cf1fcab40..86b9fbee6e67 100644 --- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S +++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S @@ -121,6 +121,9 @@ _GetStackBase: mov x1, x21 mov x2, x22 + // Set the frame pointer to 0x0 so any backtraces terminate here + mov x29, xzr + // Jump to PrePiCore C code //x0 = MpId //x1 = UefiMemoryBase -- 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/2] Clear frame pointer in startup code on AARCH64 systems
The backtrace code on AARCH64 does not sanitize the frame pointer values it pulls of the stack when attempting to do a backtrace, and so junk left in the frame pointer register may result in a recursive exception and a truncated backtrace. Ard Biesheuvel (2): ArmPlatformPkg: clear frame pointer in startup code ArmVirtPkg/PrePi: clear frame pointer in startup code ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S | 3 +++ ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ 3 files changed, 9 insertions(+) -- 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/2] ArmPlatformPkg: clear frame pointer in startup code
When setting up the stack in the startup code and jumping into C code for the first time, ensure that the frame pointer register is cleared so that backtraces terminate correctly. Otherwise, output like the below is shown when encountering an exception on a DEBUG build: Synchronous Exception at 0x78A14780 PC 0x78A14780 (0x78A0+0x00014780) [ 0] ArmVeNorFlashDxe.dll PC 0x78A10634 (0x78A0+0x00010634) [ 0] ArmVeNorFlashDxe.dll PC 0x78A11CF0 (0x78A0+0x00011CF0) [ 0] ArmVeNorFlashDxe.dll PC 0x78A11DD0 (0x78A0+0x00011DD0) [ 0] ArmVeNorFlashDxe.dll PC 0x7BC9D87C (0x7BC98000+0x587C) [ 1] PartitionDxe.dll PC 0x7BC99B3C (0x7BC98000+0x1B3C) [ 1] PartitionDxe.dll PC 0x7F362F50 (0x7F359000+0x9F50) [ 2] DxeCore.dll PC 0x7BD63BB0 (0x7BD5B000+0x8BB0) [ 3] BdsDxe.dll PC 0x7BD6EE00 (0x7BD5B000+0x00013E00) [ 3] BdsDxe.dll PC 0x7BD67C70 (0x7BD5B000+0xCC70) [ 3] BdsDxe.dll PC 0x7F3724F0 (0x7F359000+0x000194F0) [ 4] DxeCore.dll PC 0x4008FC30 PC 0x40090130 PC 0x5800F6025800F5E1 Recursive exception occurred while dumping the CPU state which is rather unhelpful, given that this prevent the remaining debug output from being printed (register dump, stack dump, fault related system registers etc) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S | 3 +++ ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 3 +++ 2 files changed, 6 insertions(+) diff --git a/ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S b/ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S index 0950fd0c0cdb..dc52e1138199 100644 --- a/ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S +++ b/ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S @@ -76,6 +76,9 @@ _PrepareArguments: // Ensure we're jumping to FV version of the code (not boot remapped alias) ldr x3, =ASM_PFX(CEntryPoint) + // Set the frame pointer to 0x0 so any backtraces terminate here + mov x29, xzr + // Jump to PrePeiCore C code //x0 = mp_id //x1 = pei_core_address diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S index a81709d5d12d..8db022dcf05e 100644 --- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S +++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S @@ -109,6 +109,9 @@ _PrepareArguments: // Ensure we're jumping to FV version of the code (not boot remapped alias) ldr x4, =ASM_PFX(CEntryPoint) + // Set the frame pointer to 0x0 so any backtraces terminate here + mov x29, xzr + // Jump to PrePiCore C code //x0 = MpId //x1 = UefiMemoryBase -- 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On 11/16/2018 1:51 PM, Rebecca Cran wrote> Conversations can followed via email, so that's one way of 'exporting' them. But otherwise, I suspect you'd need to either query the database directly or use "./bin/storage dump": Perfect. As long as we have a way to store history of conversations I think we are keeping the best part of the current system. 2. Is there a "file sharing" option if we wanted to, for example, share a JPG or ODF file? Yes: Phabricator has a general file storage service, and files can be uploaded via that and shared in Conpherence. Also great. I assumed this but thank you for confirming. Cheers, Stephano ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On Friday, 16 November 2018 17:34:09 MST stephano wrote: > Rebecca Cran also brought up that Phabricator allows discussions to be > interacted with via email. A quick search for Phabricator and > "Configuring Inbound Email" it seems that one can both receive and send > discussion messages if configured properly. > > Rebecca, can you confirm this? Yes, it can do. From what I posted earlier: "Conpherence is a group messaging application integrated into Phabricator. Message one-on-one or with a group of people, name your room, and keep a history of everything in one place. **Reply via email**, on the web, or on your mobile device." -- Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On 11/16/2018 2:14 PM, Philippe Mathieu-Daudé wrote> For people on the move, having bad internet (3rd world countries), email system is very powerful, you can download once and work offline, reading/answering. You can also download the list archive and refers to it offline. You also have access to all patches and can apply them offline too. Is this possible with GitHub? I am going to guess that GitHub assumes a stable internet connection to participate in discussions. I'll double check this. You bring up a good point. Maybe the open source alternative, GitLab, offers a such feature. Googling "gitlab offline" I get: "Many of our customers do not have regular Internet access and many of them, being highly regulated, cannot install local copies of GitLab to be able to run against the provided API. [...] The work, published as the gitlab-ci-yaml_lint gem, is my attempt at a start to solving the issue." This is not what I expected, but it confirms some people have troubles working with online-only services. We are currently evaluating Gitlab to improve our code review needs. I will look into Gitlab as a discussion platform as well. Specifically how it interacts with email. Rebecca Cran also brought up that Phabricator allows discussions to be interacted with via email. A quick search for Phabricator and "Configuring Inbound Email" it seems that one can both receive and send discussion messages if configured properly. Rebecca, can you confirm this? ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/2] ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
has its own VendorHw GUID, and instances of NorFlashPlatformLib
describe each bank to the driver, along with the GUID for each.
This works ok for bare metal platforms, but it would be useful for
virtual platforms if we could obtain this information from a
device tree, which would require us to invent GUIDs on the fly,
given that the 'cfi-flash' binding does not include a GUID.
So instead, let's switch to a single GUID for all flash banks,
and update the driver's device path handling to include an index
to identify each bank uniquely.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 15 +--
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h | 3 +++
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
index 46e815beb343..60a06e4a5058 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
@@ -82,10 +82,14 @@ NOR_FLASH_INSTANCE mNorFlashInstanceTemplate = {
{
HARDWARE_DEVICE_PATH,
HW_VENDOR_DP,
-{ (UINT8)sizeof(VENDOR_DEVICE_PATH),
(UINT8)((sizeof(VENDOR_DEVICE_PATH)) >> 8) }
+{
+ (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End)),
+ (UINT8)(OFFSET_OF(NOR_FLASH_DEVICE_PATH, End) >> 8)
+}
},
{ 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }, // GUID
... NEED TO BE FILLED
},
+0, // Index
{
END_DEVICE_PATH_TYPE,
END_ENTIRE_DEVICE_PATH_SUBTYPE,
@@ -99,10 +103,9 @@ NorFlashCreateInstance (
IN UINTN NorFlashDeviceBase,
IN UINTN NorFlashRegionBase,
IN UINTN NorFlashSize,
- IN UINT32 MediaId,
+ IN UINT32 Index,
IN UINT32 BlockSize,
IN BOOLEANSupportFvb,
- IN CONST GUID *NorFlashGuid,
OUT NOR_FLASH_INSTANCE** NorFlashInstance
)
{
@@ -121,11 +124,12 @@ NorFlashCreateInstance (
Instance->Size = NorFlashSize;
Instance->BlockIoProtocol.Media = &Instance->Media;
- Instance->Media.MediaId = MediaId;
+ Instance->Media.MediaId = Index;
Instance->Media.BlockSize = BlockSize;
Instance->Media.LastBlock = (NorFlashSize / BlockSize)-1;
- CopyGuid (&Instance->DevicePath.Vendor.Guid, NorFlashGuid);
+ CopyGuid (&Instance->DevicePath.Vendor.Guid, &gEfiCallerIdGuid);
+ Instance->DevicePath.Index = Index;
Instance->ShadowBuffer = AllocateRuntimePool (BlockSize);;
if (Instance->ShadowBuffer == NULL) {
@@ -1311,7 +1315,6 @@ NorFlashInitialise (
Index,
NorFlashDevices[Index].BlockSize,
ContainVariableStorage,
- &NorFlashDevices[Index].Guid,
&mNorFlashInstances[Index]
);
if (EFI_ERROR(Status)) {
diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
index 5c07694fbfaa..8886aa43d9f3 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
@@ -122,10 +122,13 @@
typedef struct _NOR_FLASH_INSTANCENOR_FLASH_INSTANCE;
+#pragma pack(1)
typedef struct {
VENDOR_DEVICE_PATH Vendor;
+ UINT8 Index;
EFI_DEVICE_PATH_PROTOCOLEnd;
} NOR_FLASH_DEVICE_PATH;
+#pragma pack()
struct _NOR_FLASH_INSTANCE {
UINT32 Signature;
--
2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/2] ArmPlatformPkg, ArmVirtPkg: discover NOR flash banks from DTB
This series fixes an issue reported by Hongbo and Philippe, where ArmVirtQemuKernel will crash on an attempt to access flash bank #0, which is secure-only when running QEMU with support for EL3. So let's switch to discovering the NOR flash banks from the device tree instead. This requires some preparatory changes in the NOR flash driver to avoid having to invent GUIDs on the fly. Ard Biesheuvel (2): ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically .../Drivers/NorFlashDxe/NorFlashDxe.c | 15 ++-- .../Drivers/NorFlashDxe/NorFlashDxe.h | 3 + .../Library/NorFlashQemuLib/NorFlashQemuLib.c | 84 ++- .../NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++ 4 files changed, 87 insertions(+), 27 deletions(-) -- 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
that are not based on the device tree received from QEMU.
For ArmVirtQemu, this does not really matter, given that the NOR
flash banks are always the same: the PEI code is linked to execute
in place from flash bank #0, and the fixed varstore PCDs refer to
flash bank #1 directly.
However, ArmVirtQemuKernel can execute at any offset, and flash bank
In this case, NorFlashQemuLib should not expose the first flash bank
at all.
To prevent introducing too much internal knowledge about which flash
bank is accessible under which circumstances, let's switch to using
the DTB to decide which flash banks to expose to the NOR flash driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84
+++-
ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
2 files changed, 75 insertions(+), 21 deletions(-)
diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
index e3bbae5b06c5..dc0a15e77170 100644
--- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
+++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2014, Linaro Ltd. All rights reserved.
+ Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
@@ -12,13 +12,16 @@
**/
+#include
+#include
#include
+#include
+
+#include
#define QEMU_NOR_BLOCK_SIZESIZE_256KB
-#define QEMU_NOR0_BASE 0x0
-#define QEMU_NOR0_SIZE SIZE_64MB
-#define QEMU_NOR1_BASE 0x0400
-#define QEMU_NOR1_SIZE SIZE_64MB
+
+#define MAX_FLASH_BANKS4
EFI_STATUS
NorFlashPlatformInitialization (
@@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
return EFI_SUCCESS;
}
-NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
- {
-QEMU_NOR0_BASE,
-QEMU_NOR0_BASE,
-QEMU_NOR0_SIZE,
-QEMU_NOR_BLOCK_SIZE,
-{0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5, 0x3C,
0xB3}}
- }, {
-QEMU_NOR1_BASE,
-QEMU_NOR1_BASE,
-QEMU_NOR1_SIZE,
-QEMU_NOR_BLOCK_SIZE,
-{0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA, 0xCE,
0x8F}}
- }
-};
+NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
EFI_STATUS
NorFlashPlatformGetDevices (
@@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
OUT UINT32 *Count
)
{
+ FDT_CLIENT_PROTOCOL *FdtClient;
+ INT32 Node;
+ EFI_STATUS Status;
+ EFI_STATUS FindNodeStatus;
+ CONST UINT64*Reg;
+ UINT32 RegSize;
+ CONST CHAR8 *NodeStatus;
+ UINTN Num;
+
+ Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
+ (VOID **)&FdtClient);
+ ASSERT_EFI_ERROR (Status);
+
+ Num = 0;
+ for (FindNodeStatus = FdtClient->FindCompatibleNode (FdtClient,
+ "cfi-flash", &Node);
+ !EFI_ERROR (FindNodeStatus);
+ FindNodeStatus = FdtClient->FindNextCompatibleNode (FdtClient,
+ "cfi-flash", Node, &Node)) {
+
+Status = FdtClient->GetNodeProperty (FdtClient, Node, "status",
+ (CONST VOID **)&NodeStatus, NULL);
+if (!EFI_ERROR (Status) && AsciiStrnCmp (NodeStatus, "ok", 2) != 0) {
+ continue;
+}
+
+Status = FdtClient->GetNodeProperty (FdtClient, Node, "reg",
+ (CONST VOID **)&Reg, &RegSize);
+if (EFI_ERROR (Status)) {
+ DEBUG ((EFI_D_ERROR, "%a: GetNodeProperty () failed (Status == %r)\n",
+__FUNCTION__, Status));
+ continue;
+}
+
+ASSERT ((RegSize % (2 * sizeof(UINT64))) == 0);
+
+while (RegSize > 0) {
+ mNorFlashDevices[Num].DeviceBaseAddress = (UINTN)SwapBytes64 (Reg[0]);
+ mNorFlashDevices[Num].RegionBaseAddress = (UINTN)SwapBytes64 (Reg[0]);
+ mNorFlashDevices[Num].Size = (UINTN)SwapBytes64 (Reg[1]);
+ mNorFlashDevices[Num].BlockSize = QEMU_NOR_BLOCK_SIZE;
+
+ Num++;
+ Reg += 2;
+ RegSize -= 2 * sizeof(UINT64);
+
+ if (Num >= MAX_FLASH_BANKS) {
+goto Finished;
+ }
+}
+ }
+
+Finished:
*NorFlashDescriptions = mNorFlashDevices;
- *Count = ARRAY_SIZE (mNorFlashDevices);
+ *Count = Num;
return EFI_SUCCESS;
}
diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
index 126d1671f544..d86ff36dbd58 100644
--- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
+++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
@@ -28,3 +28,15 @@
[Packages]
MdePkg/MdePkg.dec
ArmPlatformPkg/ArmPlatformPkg.dec
+ ArmVirt
[edk2] [PATCH edk2-platforms] Platform/ARM: replace hardcoded VenHW() device paths referring to NOR flash
The ArmPlatformPkg NOR flash driver has been updated to use device paths consisting of a fixed GUID and a numeric index rather than a separate GUID for each flash bank on a given system. This means all explicit device path references to NOR flash banks have to be brought up to date as well. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/JunoPkg/ArmJuno.dec | 2 +- Platform/ARM/JunoPkg/ArmJuno.dsc | 2 +- Platform/ARM/SgiPkg/SgiPlatform.dsc | 2 +- Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 +- Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec b/Platform/ARM/JunoPkg/ArmJuno.dec index edbbb827ad45..c511796d8913 100644 --- a/Platform/ARM/JunoPkg/ArmJuno.dec +++ b/Platform/ARM/JunoPkg/ArmJuno.dec @@ -44,7 +44,7 @@ gArmJunoTokenSpaceGuid.PcdSynopsysUsbEhciBaseAddress|0x7FFC|UINT32|0x0005 # Juno Device Trees are loaded from NOR Flash - gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/board.dtb"|VOID*|0x0008 + gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/board.dtb"|VOID*|0x0008 # MHU Register base used by SCMI Mailbox transport gArmJunoTokenSpaceGuid.PcdArmMtlDoorBell|0x2B1F|UINT64|0x0024 diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc index ac3d63bd4d39..55b9d64d3deb 100644 --- a/Platform/ARM/JunoPkg/ArmJuno.dsc +++ b/Platform/ARM/JunoPkg/ArmJuno.dsc @@ -176,7 +176,7 @@ gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24 # List of Device Paths that support BootMonFs - gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" + gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" # # ARM Architectural Timer Frequency diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc b/Platform/ARM/SgiPkg/SgiPlatform.dsc index 3f0ca9872e79..06d866d6dc30 100644 --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc @@ -163,7 +163,7 @@ gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17 # List of Device Paths that support BootMonFs - gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)" + gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)" # ARM OS Loader gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3 diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc index 0542808f7d0c..3a3b4e3dbbc8 100644 --- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc +++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc @@ -172,7 +172,7 @@ # # Define the device path to the FDT for the platform # - gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/ca15a7" + gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)/ca15a7" # # ARM Architectural Timer Frequency diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc index 752e525c3469..713c5637b074 100644 --- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc +++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc @@ -355,7 +355,7 @@ # # List of Device Paths that support BootMonFs - gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59);VenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)" + gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00);VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,02)" # RunAxf support via Dynamic Shell Command protocol # We want to use the Shell Libraries but don't want it to initialise -- 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel wrote:
>
> NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> that are not based on the device tree received from QEMU.
>
> For ArmVirtQemu, this does not really matter, given that the NOR
> flash banks are always the same: the PEI code is linked to execute
> in place from flash bank #0, and the fixed varstore PCDs refer to
> flash bank #1 directly.
>
> However, ArmVirtQemuKernel can execute at any offset, and flash bank
#0 is configured as secure-only when running with support for EL3 enabled.
> In this case, NorFlashQemuLib should not expose the first flash bank
> at all.
>
> To prevent introducing too much internal knowledge about which flash
> bank is accessible under which circumstances, let's switch to using
> the DTB to decide which flash banks to expose to the NOR flash driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c | 84
> +++-
> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf | 12 +++
> 2 files changed, 75 insertions(+), 21 deletions(-)
>
> diff --git a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> index e3bbae5b06c5..dc0a15e77170 100644
> --- a/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> +++ b/ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c
> @@ -1,6 +1,6 @@
> /** @file
>
> - Copyright (c) 2014, Linaro Ltd. All rights reserved.
> + Copyright (c) 2014-2018, Linaro Ltd. All rights reserved.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -12,13 +12,16 @@
>
> **/
>
> +#include
> +#include
> #include
> +#include
> +
> +#include
>
> #define QEMU_NOR_BLOCK_SIZESIZE_256KB
> -#define QEMU_NOR0_BASE 0x0
> -#define QEMU_NOR0_SIZE SIZE_64MB
> -#define QEMU_NOR1_BASE 0x0400
> -#define QEMU_NOR1_SIZE SIZE_64MB
> +
> +#define MAX_FLASH_BANKS4
>
> EFI_STATUS
> NorFlashPlatformInitialization (
> @@ -28,21 +31,7 @@ NorFlashPlatformInitialization (
>return EFI_SUCCESS;
> }
>
> -NOR_FLASH_DESCRIPTION mNorFlashDevices[] = {
> - {
> -QEMU_NOR0_BASE,
> -QEMU_NOR0_BASE,
> -QEMU_NOR0_SIZE,
> -QEMU_NOR_BLOCK_SIZE,
> -{0xF9B94AE2, 0x8BA6, 0x409B, {0x9D, 0x56, 0xB9, 0xB4, 0x17, 0xF5, 0x3C,
> 0xB3}}
> - }, {
> -QEMU_NOR1_BASE,
> -QEMU_NOR1_BASE,
> -QEMU_NOR1_SIZE,
> -QEMU_NOR_BLOCK_SIZE,
> -{0x8047DB4B, 0x7E9C, 0x4C0C, {0x8E, 0xBC, 0xDF, 0xBB, 0xAA, 0xCA, 0xCE,
> 0x8F}}
> - }
> -};
> +NOR_FLASH_DESCRIPTION mNorFlashDevices[MAX_FLASH_BANKS];
>
> EFI_STATUS
> NorFlashPlatformGetDevices (
> @@ -50,7 +39,60 @@ NorFlashPlatformGetDevices (
>OUT UINT32 *Count
>)
> {
> + FDT_CLIENT_PROTOCOL *FdtClient;
> + INT32 Node;
> + EFI_STATUS Status;
> + EFI_STATUS FindNodeStatus;
> + CONST UINT64*Reg;
> + UINT32 RegSize;
> + CONST CHAR8 *NodeStatus;
> + UINTN Num;
> +
> + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
> + (VOID **)&FdtClient);
> + ASSERT_EFI_ERROR (Status);
> +
> + Num = 0;
> + for (FindNodeStatus = FdtClient->FindCompatibleNode (FdtClient,
> + "cfi-flash", &Node);
> + !EFI_ERROR (FindNodeStatus);
> + FindNodeStatus = FdtClient->FindNextCompatibleNode (FdtClient,
> + "cfi-flash", Node, &Node)) {
> +
> +Status = FdtClient->GetNodeProperty (FdtClient, Node, "status",
> + (CONST VOID **)&NodeStatus, NULL);
> +if (!EFI_ERROR (Status) && AsciiStrnCmp (NodeStatus, "ok", 2) != 0) {
> + continue;
> +}
> +
> +Status = FdtClient->GetNodeProperty (FdtClient, Node, "reg",
> + (CONST VOID **)&Reg, &RegSize);
> +if (EFI_ERROR (Status)) {
> + DEBUG ((EFI_D_ERROR, "%a: GetNodeProperty () failed (Status == %r)\n",
> +__FUNCTION__, Status));
> + continue;
> +}
> +
> +ASSERT ((RegSize % (2 * sizeof(UINT64))) == 0);
> +
> +while (RegSize > 0) {
> + mNorFlashDevices[Num].DeviceBaseAddress = (UINTN)SwapBytes64 (Reg[0]);
> + mNorFlashDevices[Num].RegionBaseAddress = (UINTN)SwapBytes64 (Reg[0]);
> + mNorFlashDevices[Num].Size = (UINTN)SwapBytes64 (Reg[1]);
> + mNorFlashDevices[Num].BlockSize = QEMU_NOR_BLOCK_SIZE;
> +
> + Num++;
> + Reg += 2;
> + RegSize -= 2 * sizeof(UINT64);
> +
> + if (Num >= MAX_FLASH_BANKS) {
> +goto Finished;
> + }
> +}
> + }
> +
> +Finished:
>*NorFlashDescriptions = mNorFlashDevices;
> - *Count = ARRAY_SIZE (mNorFlashDevices);
> + *Count = Num;
>return EF
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On 11/16/2018 4:37 PM, Rebecca Cran wrote: On Friday, 16 November 2018 17:34:09 MST stephano wrote: Rebecca Cran also brought up that Phabricator allows discussions to be interacted with via email. A quick search for Phabricator and "Configuring Inbound Email" it seems that one can both receive and send discussion messages if configured properly. Rebecca, can you confirm this? Yes, it can do. From what I posted earlier: "Conpherence is a group messaging application integrated into Phabricator. Message one-on-one or with a group of people, name your room, and keep a history of everything in one place. **Reply via email**, on the web, or on your mobile device." Perfect, thanks! ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
Mike, I like the github teams option for discussion as it is just there, free, and easy. It integrates nicely with all other parts of github. Notifications are supported for those that want email. Is there any reason this path doesn't get used now as a test since tianocore is already in github? I really can't get behind the Phabricator tool suite as it just has too many downsides (self-hosted or pay, lack of integrations, lack of support and limited searchability, poor ci integration, etc). Thanks Sean -Original Message- From: edk2-devel On Behalf Of Kinney, Michael D Sent: Friday, November 16, 2018 11:55 AM To: stephano ; Zimmer, Vincent ; edk2-devel@lists.01.org; Kinney, Michael D Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software Hi Stephano, GitHub supports discussions for teams. If we added a new team to the GitHub TianoCore organization for all developers that want to be involved in community topics and design discussions (which should closely match the current members of edk2-devel) then that may be a simple option that uses services that already there. Another option is to use discussions for one of the exiting teams (e.g. Tianocore Maintainers) and make posts for these discussion topics public. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.github.com%2F2017-11-20-introducing-team-discussions%2F&data=02%7C01%7Csean.brogan%40microsoft.com%7C90c7b5b8e6544710547308d64bfd68ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636779949096981093&sdata=m%2BL8FRVa3yxdwLYUaCF1qC%2FfZ9IUp5kigjiUMJxSzJo%3D&reserved=0 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-team-discussions%2F&data=02%7C01%7Csean.brogan%40microsoft.com%7C90c7b5b8e6544710547308d64bfd68ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636779949096991106&sdata=5QLuiHfs%2FmgR3UHC4BeYasDWAkf5zBR5s71ttRmeNAg%3D&reserved=0 Best regards, Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] > On Behalf Of stephano > Sent: Friday, November 16, 2018 11:14 AM > To: Zimmer, Vincent ; edk2- > de...@lists.01.org > Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software > > The only reason I didn't include Slack is that it will only log so > much information before things start falling off into the ether. > > Does anyone in the community currently use Slack and know of an easy > way of archiving conversations publicly? > > > On 11/16/2018 9:56 AM, Zimmer, Vincent wrote: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsla > > ck.com%2F&data=02%7C01%7Csean.brogan%40microsoft.com%7C90c7b5b8e > > 6544710547308d64bfd68ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 > > C636779949096991106&sdata=flNeQfd9Tq2yX7ZUouV8pkINvofIRjeSoaTB6Y > > ojWPg%3D&reserved=0 > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel- > boun...@lists.01.org] On Behalf Of Kevin D Davis > > Sent: Friday, November 16, 2018 9:35 AM > > To: stephano ; edk2- > de...@lists.01.org > > Subject: Re: [edk2] [edk2-announce][RFC] Collaboration > Software > > > > > > > > > > > > > > If we get to vote, I’d vote against Google > Groups. Their interface is very geared toward their internal work > flow and seems to change on a whim. > Thanks,Kevin > > > > > > > > > > > > On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" > wrote: > > > > > > > > > > > > > > > > > > > > > > We are looking to augment our current communication > methods (mailing list / IRC) with a modern solution for group > collaboration. The goal is to allow folks to communicate effectively > without interrupting the current patch review system, as well as > enabling any future systems with more robust options. > > > > Specific features we are looking for include > attachments (currently blocked by the list), robust logging, modern > chat, and integration with tools like bug trackers and source > repositories (APIs, or better yet, pre-rolled plugins). > > > > Our current contenders are Google Groups and Groups.io. > This RFC is in hopes of finding other options to evaluate. > > > > Cheers, > > Stephano > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=02%7C01%7Csean. > > brogan%40microsoft.com%7C90c7b5b8e6544710547308d64bfd68ac%7C72f988bf > > 86f141af91ab2d7cd011db47%7C1%7C0%7C636779949096991106&sdata=B147 > > wIbtDPoPYvHzds53CFlU6BBa9UKjoAuCJ8LMWFc%3D&reserved=0 > > > > > > > > > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-devel&data=02%7C01%7Csean. > > brogan%40microsoft.com%7C90c7b5b8e6544710547308d64bfd68ac%7C72f988bf > > 86f14
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On November 16, 2018 at 7:42:51 PM, Sean Brogan via edk2-devel (edk2-devel@lists.01.org(mailto:edk2-devel@lists.01.org)) wrote: > I really can't get behind the Phabricator tool suite as it just has too many > downsides (self-hosted or pay, lack of integrations, lack of support and > limited searchability, poor ci integration, etc). > At least with Phabricator you don’t have to pay to self-host it. And look at all the features you don’t get with Github unless you pay them: https://github.com/pricing Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
