Reviewed-by: Zailiang Sun
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, January 3, 2019 10:48 AM
> To: edk2-devel-01
> Cc: Sun, Zailiang ; Qian, Yi
> Subject: [PATCH 03/26] Vlv2TbltDevicePkg: assume GCC48 or later
>
> We're about to remove
Reviewed-by: Bob Feng
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, January 4, 2019 2:28 AM
To: edk2-devel@lists.01.org
Cc: Ard Biesheuvel ; Laszlo Ersek
; Leif Lindholm ; Kinney, Michael
D ; Gao, Liming ; Wang, Jian
J ; Wu, Hao A ;
Reviewed-by: Jian J Wang
> -Original Message-
> From: Wu, Hao A
> Sent: Friday, January 04, 2019 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Bi, Dandan ;
> Wang, Jian J ; Ni, Ray
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT
> build failure
>
>
Reviewed-by: Bi Dandan
Thanks,
Dandan
> -Original Message-
> From: Wu, Hao A
> Sent: Friday, January 4, 2019 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Bi, Dandan ;
> Wang, Jian J ; Ni, Ray
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT
> build
Laszlo:
This issue has been fixed in edk2 master. I just cherry pick those fixes from
edk2 master to my Python3 branch (https://github.com/lgao4/edk2/tree/Python3).
Thanks
Liming
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Monday, December 31, 2018 8:16
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425
This commit will resolve the VS2015 IA32 NOOPT build failure within
SdMmcPciHcDxe.
More specifically, this commit will use BaseLib API RShiftU64() to perform
right-shift operations for UINT64 type operators.
Cc: Dandan Bi
Cc: Jian J Wang
Reviewed-by: Liming Gao
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>BobCF
>Sent: Saturday, December 29, 2018 4:43 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming
>Subject: [edk2] [Patch] BaseTools: Correct PcdArray value assigment
Hi Mike,
Call to UninstallMultipleProtocolInterfaces at
https://github.com/tianocore/edk2/blob/master/NetworkPkg/IScsiDxe/IScsiDriver.c#L1864
fails because the component name interface may not be installed depending on
the state of PCD.
Thanks
Ashish
From: Kinney, Michael D
Sent: Thursday,
Hi Ashish,
Can you provide a pointer to the UninstallMultipleProtocolInterfaces() call
that is causing this failure?
I agree that the UefiLib could provide additional services to simplify the
implementation of the unload handlers. Matching the UefiLib APIs that install
the Uefi Driver Model
Hello,
As part of moving from MdeModulePkg implementation of IScsiDxe to the
implementation in NetworkPkg, I started hitting exception in the driver loaded
after IScsiDxe if IScsiDxe's installation fails for some reason. Upon
debugging, I found out that calls to
On the topic of Microsoft Teams, it has a free option, limited to 300 users.
More than 300 users requires an enterprise license, starting at $8/user/month.
There is a steep discount for some types of non-profits, but I don't know if we
would qualify.
More details on the offering here:
On 2019-01-02 18:47:50, Laszlo Ersek wrote:
> Repo: https://github.com/lersek/edk2.git
> Branch: drop_gcc44_gcc47_tiano1377
>
> (0) This series is meant as an alternative to
>
> [edk2] [Patch 0/5] Remove unused tool chains in tools_def.template
>
On Thu, 3 Jan 2019 at 19:28, Ard Biesheuvel wrote:
>
> This series proposed an alternative approach to the series sent out by
> Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
> special PCD, as well as some other if() conditionals.
>
That would be
[0]
Reuse most of the existing code to implement a variable runtime
driver that will be able to execute in the context of standalone
MM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c |
In preparation of providing a standalone MM based FTW driver, move
the existing SMM driver to the new MM services table, and factor out
some pieces that are specific to the traditional driver, mainly
related to the use of UEFI boot services, which are not accessible
to standalone MM drivers.
In preparation of providing a standalone MM based variable runtime
driver, move the existing SMM driver to the new MM services table,
and factor out some pieces that are specific to the traditional
driver, mainly related to the use of UEFI boot services, which are
not accessible to standalone MM
This series proposed an alternative approach to the series sent out by
Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
special PCD, as well as some other if() conditionals.
The primary difference is that this series defines and implements
MmServicesTableLib in such a way
From: Jagadeesh Ujja
SMM has been rebranded as MM, and can be implemented in traditional
mode or standalone mode, using the same prototype for the services
table. Expose this table via MmServicesTableLib, permitting the
respective implementations to expose a traditional or standalone
version.
The standalone MM core is executed in place, and resides in a
separate execution context which may be space constrained.
Since code and data may be mapped with different attributes for
security reasons, the PE/COFF binary could have a section
alignment of 4 KB.
This means that any relocation data
On 01/03/19 12:03, Ard Biesheuvel wrote:
> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja wrote:
>>
>> 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.
>>
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Thursday, January 03, 2019 4:13 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [edk2] [PATCH] BaseTools/GenFds: permit
> -Original Message-
> From: Laszlo Ersek
> Sent: Thursday, January 3, 2019 3:48 AM
> To: edk2-devel-01
> Cc: Ard Biesheuvel ; Liming Gao
> ; Marvin Haeuser ;
> Michael D Kinney
> Subject: [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on
> GCC v4.4"
>
> This reverts
The standalone MM core is executed in place, and resides in a
separate execution context which may be space constrained.
Since code and data may be mapped with different attributes for
security reasons, the PE/COFF binary could have a section
alignment of 4 KB.
This means that any relocation data
On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja wrote:
>
> 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.
>
> Add a mechanism to determine the execution
On Thu, 3 Jan 2019 at 10:52, Ard Biesheuvel wrote:
>
> On Thu, 3 Jan 2019 at 08:43, Jagadeesh Ujja wrote:
> >
> > hi Ard
> >
> > On Wed, Jan 2, 2019 at 10:45 PM Ard Biesheuvel
> > wrote:
> > >
> > > On Thu, 20 Dec 2018 at 15:23, Gao, Liming wrote:
> > > >
> > > > Jagadeesh:
> > > >
On Thu, 3 Jan 2019 at 08:43, Jagadeesh Ujja wrote:
>
> hi Ard
>
> On Wed, Jan 2, 2019 at 10:45 PM Ard Biesheuvel
> wrote:
> >
> > On Thu, 20 Dec 2018 at 15:23, Gao, Liming wrote:
> > >
> > > Jagadeesh:
> > > MdeModulePkg Variable service/Fault tolerant/Nor Flash driver depends
> > > on
On Thu, 3 Jan 2019 at 03:49, Laszlo Ersek wrote:
>
> This reverts commit 357cec385d4f ("MdePkg: avoid __builtin_unreachable()
> on GCC v4.4", 2016-07-21).
>
> We've removed BaseTools support for GCC44..GCC47, therefore we need not
> catch the GCC44 corner case for __builtin_unreachable().
>
> No
On Thu, 3 Jan 2019 at 03:49, Laszlo Ersek wrote:
>
> We've removed BaseTools support for GCC44..GCC47. Drop
> ArmPkg/ArmSoftFloatLib build flags that are specific to any of those gcc
> versions. (See also commit 01627dba0911, "ArmPkg/ArmSoftfloatLib: restrict
> -fno-tree-vrp option to GCC46 and
On Thu, 3 Jan 2019 at 03:48, Laszlo Ersek wrote:
>
> We're about to remove BaseTools support for GCC44..GCC47. Reject those gcc
> versions cleanly in "OvmfPkg/build.sh". In "OvmfPkg/README", upgrade any
> mentions of the same gcc versions to GCC48.
>
> No GCC44..GCC47 references remain under
29 matches
Mail list logo
