Adapt the NorFlashDxe driver to be used as a MM_STANDALONE driver to
allow access to NOR flash for code executing in MM_STANDALONE mode.
This allows storing of EFI variables on NOR flash which is accessible
only via the MM STANDALONE mode software.
Contributed-under: TianoCore Contribution Agreeme
“VarCheckLib” library can be used by MM_STANDALONE drivers as well.
So add MM_STANDALONE as the module type this library supports
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf | 5 +++--
1 file changed,
Adapt the variable runtime dxe driver to be used as a MM_STANDALONE
driver to provide variable storage service in MM Standalone mode.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 3
Adapt the VariableSmmRuntimeDxe driver to communicate with a VariableSmm
driver that is implemented as a MM Standalone driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf| 1 +
Md
Adapt the FaultTolerantWriteDxe driver to be used as a MM_STANDALONE
driver to provide UEFI fault tolerant write protocol functionality
for variable reclaim operation on EFI variables stored on a NOR flash
that is only accessible to code executing in MM Standalone mode.
Contributed-under: TianoCor
To resuse some the libraries in both MM and non-MM mode, a mechanism to
determine the execution mode is required, i.e, in MM or non-MM. Add a
new library for use by non-MM code to determine the current execution
mode.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh
Variable service driver includes a call to AsmLfence. To reuse this
driver on AArch64 based platforms, add an implementation of AsmLfence
that acts as a wrapper on the AArch64 specific MemoryFence function.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
Some of the existing DXE drivers can be refactored to execute within
the Standalone MM execution environment as well. Allow such drivers to
get access to the Standalone MM services tables
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja
---
MdePkg/Include/Lib
Add a flag that allows selecting the variables to be stored on a
secure or a non-secure non-volatile memory. In case of secure storage
of variables, the variable service will be implemented by code executing
within the Standalone MM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-o
Three additional library packages are being pulled into StandaloneMmPkg
from the staging area in order to support the secure variable service.
The three packages being pulled in are
- StandaloneMmHobLib
- StandaloneMmMemoryAllocationLib
- StandaloneMmServicesTableLib
Contributed-under: Tiano
Changes since v3:
- Addressed all the comments from Liming Gao
- Added a AArch64 implementation of AsmLfence which is a wrapper for
MemoryFence. The changes in variable service driver in v3 of this
patchset that used MemoryFence instead of AsmLfence have been removed.
- Added Standalon
Hi Liming,
On Thu, Nov 29, 2018 at 9:27 PM Gao, Liming wrote:
>
> My comment is below.
>
> 1. Please don't update MemoryFence() implementation. It will impact all
> consumer code. AsmLfence() is X86 specific API. You can implement the
> internal function in the arch specific source file to call
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Saturday, December 08, 2018 6:25 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ruiyu; Ard Biesheuvel
> Subject: [PATCH] MdeModulePkg/FileExplorerLib: avoid packed struct for
> progra
Change EFI_RETURNING_FROM_EFI_APPLICATOIN to
EFI_RETURNING_FROM_EFI_APPLICATION.
https://bugzilla.tianocore.org/show_bug.cgi?id=1368
Cc: Chao Zhang
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang
---
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 4 ++-
Change EFI_RETURNING_FROM_EFI_APPLICATOIN to
EFI_RETURNING_FROM_EFI_APPLICATION.
https://bugzilla.tianocore.org/show_bug.cgi?id=1368
Cc: Michael D Kinney
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang
---
MdePkg/Include/IndustryStandard/Uef
Change EFI_RETURNING_FROM_EFI_APPLICATOIN to
EFI_RETURNING_FROM_EFI_APPLICATION.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Chao Zhang
Cc: Jiewen Yao
Shenglei Zhang (2):
MdePkg/IndustryStandard: Fix a typo in UefiTcgPlatform.h
SecurityPkg/Tcg: Fix typos in TcgDxe.c and Tcg2Dxe.c
MdePkg/Incl
If PCD is related to one structure in DEC/DSC, it can be refer as structure
pointer in C source code. Here is wiki for its usage:
https://github.com/lgao4/edk2/wiki/StrucutrePcd-Usage
Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf O
> On Dec 10, 2018, at 3:33 PM, Leif Lindholm wrote:
>
> On Mon, Dec 10, 2018 at 11:51:43PM +0100, Ard Biesheuvel wrote:
>> On Mon, 10 Dec 2018 at 23:14, Leif Lindholm wrote:
>>>
>>> On Wed, Dec 05, 2018 at 09:10:48PM +0100, Ard Biesheuvel wrote:
The PCDs containing the default MAC addre
On Mon, Dec 10, 2018 at 11:51:43PM +0100, Ard Biesheuvel wrote:
> On Mon, 10 Dec 2018 at 23:14, Leif Lindholm wrote:
> >
> > On Wed, Dec 05, 2018 at 09:10:48PM +0100, Ard Biesheuvel wrote:
> > > The PCDs containing the default MAC addresses are of type UINT64,
> > > and so the byte order needs to
On Mon, 10 Dec 2018 at 23:14, Leif Lindholm wrote:
>
> On Wed, Dec 05, 2018 at 09:10:48PM +0100, Ard Biesheuvel wrote:
> > The PCDs containing the default MAC addresses are of type UINT64,
> > and so the byte order needs to be inverted. As they are currently,
> > both default MAC addresses are inv
On Thu, Dec 06, 2018 at 01:12:02PM +0100, Ard Biesheuvel wrote:
> After fixing the iasl issue yesterday, I got a bit carried away and ended
> up rewriting most of the ACPI table generation logic for Styx. So this
> applies on top of the patches I sent out yesterday.
>
> Patch #1 merges the DXE dri
On Wed, Dec 05, 2018 at 09:10:48PM +0100, Ard Biesheuvel wrote:
> The PCDs containing the default MAC addresses are of type UINT64,
> and so the byte order needs to be inverted. As they are currently,
> both default MAC addresses are invalid since they have the multicast
> bit set.
Ah, oops.
That
On Wed, Dec 05, 2018 at 07:50:14PM +0100, Ard Biesheuvel wrote:
> Primarily, this series gets rid of the hacked up way this platform
> patches the DSDT at build time, by #include'ing intermediate output
> of the iasl compiler [or some version of it, at least]
>
> While at it, apply some other clea
On Wed, 2018-12-05 at 13:51 +0800, Eric Jin wrote:
> Enable the BBTestVerifySignatureFunctionTest()
> with 2 checkpoints below, it should be success.
> The Certificate/Hash/Digest/signedData are updated
> correspondingly.
> a)Signed hash was verified against caller-provided
> hash of content, the s
On Mon, Dec 10, 2018 at 03:13:39PM +0100, Ard Biesheuvel wrote:
> Since 4 KB section alignment is required when mapping PE/COFF images
> with strict permissions, update the default section alignment when
> using GCC49 and GCC5 in RELEASE mode. Note that XIP modules such as
> SEC, PEIMs or PEI core
Hi Marcin,
This EDK2 patch has been pushed, making all of the Armada platforms
stop building. Can you have a look please?
Regards,
Leif
On Thu, Nov 15, 2018 at 03:45:28PM +0800, Shenglei Zhang wrote:
> These wrapper header files are not referenced by all
> open source, so they are removed.
> ht
On 12/10/18 19:12, Ard Biesheuvel wrote:
> On Mon, 10 Dec 2018 at 19:08, Laszlo Ersek wrote:
>>
>> On 12/10/18 15:13, Ard Biesheuvel wrote:
>>> Since 4 KB section alignment is required when mapping PE/COFF images
>>> with strict permissions, update the default section alignment when
>>> using GCC4
On Mon, 10 Dec 2018 at 19:08, Laszlo Ersek wrote:
>
> On 12/10/18 15:13, Ard Biesheuvel wrote:
> > Since 4 KB section alignment is required when mapping PE/COFF images
> > with strict permissions, update the default section alignment when
> > using GCC49 and GCC5 in RELEASE mode. Note that XIP mod
On 12/10/18 15:13, Ard Biesheuvel wrote:
> Since 4 KB section alignment is required when mapping PE/COFF images
> with strict permissions, update the default section alignment when
> using GCC49 and GCC5 in RELEASE mode. Note that XIP modules such as
> SEC, PEIMs or PEI core are not affected by thi
Thanks Mike.
Looks good to me. I guess we can populate version field later to v2.7.0 (or
something other than "UNSPECIFIED" later) .
Leif,
Please go ahead and raise a feature request and let us know.
Supreeth
-Original Message-
From: Kinney, Michael D
Sent: Monday, December 10, 2018 1
Supreeth,
I have created the "EDK2 Test" product with the "UEFI-SCT" component.
Please review and let me know if there are any additional changes required.
Best regards,
Mike
> -Original Message-
> From: Supreeth Venkatesh
> [mailto:supreeth.venkat...@arm.com]
> Sent: Monday, December
I guess we are in agreement that "EDK2-Test" product and "UEFI-SCT" component
in Bugzilla is required.
Mike,
Can you please help create this and let us know?
Thanks,
Supreeth
-Original Message-
From: Jin, Eric
Sent: Monday, December 10, 2018 2:43 AM
To: Leif Lindholm ; Kinney, Michael
On Mon, 10 Dec 2018 at 15:40, Laszlo Ersek wrote:
>
> Hi Ard,
>
> On 12/10/18 09:36, Ard Biesheuvel wrote:
>
> > Could anyone remind me why we have OpensslLib and OpensslLibCrypto?
> > Since these are static libraries, only the referenced objects should
> > be included in the final module anyway,
On Mon, 10 Dec 2018 at 16:25, Laszlo Ersek wrote:
>
> On 12/08/18 10:32, Ard Biesheuvel wrote:
> > This drops ARM and AARCH64 support from the GCC46 and GCC47 toolchain
> > definitions, which are on the list to be removed, along with VS2003,
> > VS2005, VS2008, VS2010, DDK3790, UNIXGCC, GCC44, GCC
On 12/08/18 10:32, Ard Biesheuvel wrote:
> This drops ARM and AARCH64 support from the GCC46 and GCC47 toolchain
> definitions, which are on the list to be removed, along with VS2003,
> VS2005, VS2008, VS2010, DDK3790, UNIXGCC, GCC44, GCC45, ELFGCC, CYGGCC,
> ICC, ICC11 and MYTOOLS.
>
> Since GCC4
On Mon, Dec 10, 2018 at 02:39:01PM +, Gao, Liming wrote:
> Ard:
> I agree this change.
>
> Leif:
> On the duplicated definition of HII_VENDOR_DEVICE_PATH,
> MdeModulePkg DriverSampleDxe first defines it and use it as the
> driver level definition. Other UEFI HII driver may refer to the
Leif:
OK. I understand your point.
Thanks
Liming
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, December 10, 2018 10:45 PM
> To: Gao, Liming
> Cc: Feng, Bob C ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch V2] BaseTools: Fixed the b
On Mon, 10 Dec 2018 at 15:52, Gao, Liming wrote:
>
> Ard:
> I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in
> ProcessorBind.h. I don't want to leave the choice to override
> MAX_ALLOC_ADDRESS definition.
>
Seems reasonable. What should be the value for X64?
> Thanks
> Limin
Keep the same value of MAX_ADDRESS. There is no change now.
Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, December 10, 2018 10:54 PM
> To: Gao, Liming
> Cc: Wang, Jian J ; Andrew Jones ;
> Wu, Hao A ;
> edk2-devel@lists.01.o
Hi Ard,
On 12/10/18 09:36, Ard Biesheuvel wrote:
> Could anyone remind me why we have OpensslLib and OpensslLibCrypto?
> Since these are static libraries, only the referenced objects should
> be included in the final module anyway, so OpensslLibCrypto seems
> redundant to me.
please see commit 8
Ard:
I agree this change.
Leif:
On the duplicated definition of HII_VENDOR_DEVICE_PATH, MdeModulePkg
DriverSampleDxe first defines it and use it as the driver level definition.
Other UEFI HII driver may refer to the driver sample driver and define the same
structure. One centralized header
Ard:
I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in
ProcessorBind.h. I don't want to leave the choice to override MAX_ALLOC_ADDRESS
definition.
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheu
Leif:
So, you don't think to need highlight which commit causes the regression
issue in the commit message. I suggest to put this information into BZ
description instead of commit message.
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] O
On Mon, Dec 10, 2018 at 02:36:59PM +, Gao, Liming wrote:
> Leif:
> So, you don't think to need highlight which commit causes the
> regression issue in the commit message. I suggest to put this
> information into BZ description instead of commit message.
Oh, I absolutely want the commit h
Since 4 KB section alignment is required when mapping PE/COFF images
with strict permissions, update the default section alignment when
using GCC49 and GCC5 in RELEASE mode. Note that XIP modules such as
SEC, PEIMs or PEI core are not affected by this change, since the
override to 32 byte aligment
On Sat, Dec 08, 2018 at 10:32:42AM +0100, Ard Biesheuvel wrote:
> This drops ARM and AARCH64 support from the GCC46 and GCC47 toolchain
> definitions, which are on the list to be removed, along with VS2003,
> VS2005, VS2008, VS2010, DDK3790, UNIXGCC, GCC44, GCC45, ELFGCC, CYGGCC,
> ICC, ICC11 and M
On Mon, 10 Dec 2018 at 13:50, Leif Lindholm wrote:
>
> On Sat, Dec 08, 2018 at 10:32:42AM +0100, Ard Biesheuvel wrote:
> > This drops ARM and AARCH64 support from the GCC46 and GCC47 toolchain
> > definitions, which are on the list to be removed, along with VS2003,
> > VS2005, VS2008, VS2010, DDK3
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/DwUsbHostDxe/ComponentName.c | 219 +++
Platform/Broadcom/Bcm283x/Drivers/DwUsbHostDxe/DriverBinding.c | 269
Platform/Broadcom/Bcm283x/Drivers/DwUsbHostDxe/DwUsbHostD
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/DeviceTree/License.txt | 340 ++
Platform/Broadcom/Bcm283x/DeviceTree/bcm2710-rpi-3-b-plus.dtb | Bin 0 ->
25617 bytes
Platform/Broadcom/Bcm283x/DeviceTree/bcm2710-
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Binary/License.txt | 26 +
Platform/Broadcom/Bcm283x/Binary/README.md | 41
Platform/Broadcom/Bcm283x/Binary/bl1.bin | Bin 0 -> 18801 bytes
Pl
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/RaspberryPiPkg.dec | 63 ++
Platform/Broadcom/Bcm283x/RaspberryPiPkg.dsc | 636
Platform/Broadcom/Bcm283x/RaspberryPiPkg.fdf | 450 ++
Platform/Broadc
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/ConfigDxe/ConfigDxe.c| 356
Platform/Broadcom/Bcm283x/Drivers/ConfigDxe/ConfigDxe.inf | 81 +
Platform/Broadcom/Bcm283x/Drivers/
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/VarBlockServiceDxe/FileIo.c |
196
Platform/Broadcom/Bcm283x/Drivers/VarBlockServiceDxe/FvbInfo.c |
118 +++
Platform/Broadcom/Bcm283x/Drivers
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c |
915
Platform/Broadcom/Bcm283x/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf |
56 ++
2 files changed, 971 i
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/SdHostDxe/SdHostDxe.c| 830
Platform/Broadcom/Bcm283x/Drivers/SdHostDxe/SdHostDxe.inf | 54 ++
Platform/Broadcom/Bcm283x/Include/Ind
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 730
Platform/Broadcom/Bcm283x/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.h | 50
++
Platform/Broadcom/Bcm283x/
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/PiMmcDxe/ComponentName.c | 163
Platform/Broadcom/Bcm283x/Drivers/PiMmcDxe/Diagnostics.c | 256 +
Platform/Broadcom/Bcm283x/Drivers/PiMmcDxe/Mmc.c
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/GraphicsConsoleDxe/ComponentName.c
| 183 ++
Platform/Broadcom/Bcm283x/Drivers/GraphicsConsoleDxe/GraphicsConsole.c
| 1836
Platfo
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/DisplayDxe/ComponentName.c | 222 +++
Platform/Broadcom/Bcm283x/Drivers/DisplayDxe/DisplayDxe.c| 606
Platform/Broadcom/Bcm283x/Drivers/DisplayDxe
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 1085
Platform/Broadcom/Bcm283x/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.inf | 49 +
Platform/Broadcom/Bcm283x/Include/
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Drivers/Bcm2836InterruptDxe/Bcm2836InterruptDxe.c
| 367 +++
Platform/Broadcom/Bcm283x/Drivers/Bcm2836InterruptDxe/Bcm2836InterruptDxe.inf
| 48 +++
Platform/Broad
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Library/PlatformBootManagerLib/PlatformBm.c
| 831
Platform/Broadcom/Bcm283x/Library/PlatformBootManagerLib/PlatformBm.h
| 60 ++
P
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/AcpiTables/AcpiTables.inf | 51 ++
Platform/Broadcom/Bcm283x/AcpiTables/Csrt.aslc | 337 +
Platform/Broadcom/Bcm283x/AcpiTables/Dbg2.aslc | 32 ++
Platform/Broa
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2837Gpio.h
| 50 +
Platform/Broadcom/Bcm283x/Include/Library/GpioLib.h
| 33 +++
Platform/Bro
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
| 70 +
Platform/Broadcom/Bcm283x/Include/IndustryStandard/RpiFirmware.h
| 93
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/Broadcom/Bcm283x/Library/MemoryInitPeiLib/MemoryInitPeiLib.c | 183
Platform/Broadcom/Bcm283x/Library/MemoryInitPeiLib/MemoryInitPeiLib.inf | 51
++
Platform/Broadcom/Bcm2
Version History:
* v2: Break down the content into logical entities of more manageable size.
Please pay attention to the *NON-OSI* tagged patches, that should be
applied to edk2-non-osi instead of edk2-platforms.
Preamble:
Because of its price point, ease of use and availability, the
Leif:
Thanks for your suggestion. I will work out the patch set serials to remove
those tool chains. I don't remember the usage model of UNIXGCC. II will wait
for Rebecca response.
Thanks
Liming
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monda
On Mon, Dec 10, 2018 at 12:09:23PM +, Feng, Bob C wrote:
> For the "customized deepcopy" and "cache for uni file parser" data,
> you can see the AutoGen is not slower. The whole Build Duration is
> longer because Make Duration is longer while Make Duration time
> depends on the external make, c
Hi Bob,
On Mon, Dec 10, 2018 at 09:16:58AM +0800, BobCF wrote:
> From: "Feng, Bob C"
>
> V2:
Patch version information does not belong in the commit message.
It belongs in a cover letter, or if a cover letter is not used, you
can put these details below the --- line. This way it gets filtered
o
On Sat, Dec 08, 2018 at 11:24:31AM +0100, Ard Biesheuvel wrote:
> Struct packing is only necessary for data structures whose in-memory
> representation is covered by the PI or UEFI specs, and may deviate
> from the ordinary C rules for alignment.
>
> So in case of FileExplorerLib, this applies to
Hi Leif,
For the "customized deepcopy" and "cache for uni file parser" data, you can see
the AutoGen is not slower. The whole Build Duration is longer because Make
Duration is longer while Make Duration time depends on the external make,
compiler and linker. So it's not the patch make the build
On Thu, Dec 06, 2018 at 02:42:35PM +, Gao, Liming wrote:
> Hi, all
> tools_def.template includes all tool chains. Some are not used any
> more. And, there is no verification for them. So, I propose to
> remove them. They are VS2003, VS2005, VS2008, VS2010, DDK3790,
> UNIXGCC, GCC44, GCC
Hi Bob,
Thanks.
I am a little bit confused by the "customized deepcopy" and "cache for
uni file parser" data. These look like they are slowing down rather
than speeding up the build.
Regards,
Leif
On Wed, Dec 05, 2018 at 02:51:58AM +, Feng, Bob C wrote:
> Hi,
>
> I have added the performa
Hi Leif,
We had better use "UEFI SCT" as the component.
Other SCTs or test suites may be arranged in the EDK2-Test in future as the
intention of EDK2-Test if my understanding is correct. Thanks.
Best Regards
Eric
-Original Message-
From: Leif Lindholm
Sent: Monday, December 10, 2018
On Fri, 23 Nov 2018 at 11:57, Laszlo Ersek wrote:
>
> +Ard, +Leif
>
> On 11/22/18 06:21, Fu Siyuan wrote:
> > This patch provides a set of include segment files for platform owner to
> > easily enable/disable network stack support on their platform.
> >
> > For DSC, there are:
> > - a "NetworkDefi
Hi Mike,
I think we're agreed on an "EDK2 Test" product with an "SCT" component.
(Although that should probably be "UEFI SCT" for clarity.)
Regards,
Leif
On Mon, Dec 10, 2018 at 03:02:57AM +, Kinney, Michael D wrote:
> I can update BZ once there is a clear decision on what is required.
>
>
Hi Chasel,
Two minor comments are added inline.
On 2018/12/7 21:30, Chasel, Chiu wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1381
In Dispatch mode FSP may consume PPI directly so creating
FSPM_ARCH_CONFIG_PPI to align with FSPM_ARCH_UPD.
Test: Verified on internal platform to b
78 matches
Mail list logo
