Yes, it's feasible.
I still prefer to use "Library/Include" path setting for this, since only
CryptoPkg/Library/*
will refer to these internal header files.
It may be cleaner to keep the current directory in root of CryptoPkg.
Best Regards & Thanks,
LONG, Qin
> -Original Message-
> Fro
Qin:
How about creating new Private directory in CryptoPkg, then move those
internal header files into it?
Thanks
Liming
>-Original Message-
>From: Long, Qin
>Sent: Thursday, April 06, 2017 1:56 PM
>To: Gao, Liming ; Ye, Ting
>Cc: edk2-devel@lists.01.org; Long, Qin
>Subject: [Patch]
Moving the header files for openssl and CRT wrappers to the private
include section, since these files should be referenced by CryptoPkg
internally. This update was supported by new [Includes.Common.Private]
setting in Package DEC file.
The external consumer modules should only use the interfaces d
Cc: Feng Tian
Cc: Michael Kinney
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan
---
UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
b
Hi Gary,
The issue has been gone since the version of
9f5ca5efbd0bb00c9d3577b95e6322e85cb0b118. Please check that.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Guoheyi
> Sent: Wednesday, April 5, 2017 6:56 PM
> To: edk2-d
Apologies, I noticed something else:
On 04/05/17 14:55, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan
>
> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
> a basic version of VMWare's SVGA display device. Drivers for this
> device exist for some guest OSes which do
Reviewed-by: Liming Gao
>-Original Message-
>From: Wu, Hao A
>Sent: Thursday, April 06, 2017 10:25 AM
>To: edk2-devel@lists.01.org
>Cc: Wu, Hao A ; Kinney, Michael D
>; Gao, Liming
>Subject: [PATCH 5/6] MdePkg: Convert files to CRLF line ending
>
>Cc: Michael Kinney
>Cc: Liming Gao
>Co
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: Kinney, Michael D
Sent: Thursday, April 6, 2017 11:38 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ;
Shaw, Kevin W
Subject: [edk2-FdfSpecification Patch] IMAGE_TYPE_ID is required in
[Fmp
https://bugzilla.tianocore.org/show_bug.cgi?id=426
Update the EBNF for [FmpPayload] in Section 3.8
so IMAGE_TYPE_ID is required and must always be assigned
to a valid registry format GUID value.
Cc: Liming Gao
Cc: Yonghong Zhu
Cc: Kevin W Shaw
Contributed-under: TianoCore Contribution Agreemen
https://bugzilla.tianocore.org/show_bug.cgi?id=426
Update the EBNF for [FmpPayload] in Section 3.8
so IMAGE_TYPE_ID is required and must always be assigned
to a valid registry format GUID value.
Cc: Liming Gao
Cc: Yonghong Zhu
Cc: Kevin W Shaw
Contributed-under: TianoCore Contribution Agreemen
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, April 6, 2017 10:25 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen
> Subject: [PATCH 2/6] IntelFsp2Pkg: Convert files to CRLF line ending
>
> Cc: Jiewen Yao
> Contributed-under: Ti
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, April 6, 2017 10:25 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen
> Subject: [PATCH 4/6] SignedCapsulePkg: Convert files to CRLF line ending
>
> Cc: Jiewen Yao
> Contributed-under
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, April 6, 2017 10:25 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen
> Subject: [PATCH 3/6] IntelFsp2WrapperPkg: Convert files to CRLF line ending
>
> Cc: Jiewen Yao
> Contributed-un
Add additional SATA initialization code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex
---
.../BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScInit.c | 3 +
.../BroxtonSiPkg/SouthCluster/ScInit/Dxe/ScSata.c | 91 +-
2 files changed, 93 insertions(+
Cc: Michael Kinney
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu
---
MdePkg/Include/IndustryStandard/Tls1.h | 186 ++--
MdePkg/Include/Protocol/Tls.h | 921 ++--
MdePkg/Include/Protocol/TlsConfig.h| 265 +++---
MdePkg/L
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu
---
SignedCapsulePkg/Readme.md | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/SignedCapsulePkg/Readme.md b/SignedCapsulePkg/Readme.md
index 67c78edfb4..03358e9
This series converts the following file formats to CRLF line ending:
.c
.h
.inf
.uni
.vfr
.pl
Hao Wu (6):
CryptoPkg: Convert files to CRLF line ending
IntelFsp2Pkg: Convert files to CRLF line ending
IntelFsp2WrapperPkg: Convert files to CRLF line ending
SignedCapsulePkg: Convert files to
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu
---
IntelFsp2WrapperPkg/Readme.md | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/IntelFsp2WrapperPkg/Readme.md b/IntelFsp2WrapperPkg/Readme.md
index 0b0f81b033..dfcb4c
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu
---
IntelFsp2Pkg/Readme.md | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/IntelFsp2Pkg/Readme.md b/IntelFsp2Pkg/Readme.md
index 6e38e8ca61..719ce099e4 100644
--- a/Int
Reviewed-by: zwei4
Thanks,
David Wei
-Original Message-
From: Guo, Mang
Sent: Wednesday, April 05, 2017 2:58 PM
To: edk2-devel@lists.01.org
Cc: Wei, David ; Lu, ShifeiX A
Subject: [Patch][edk2-platforms/devel-MinnowBoard3 3/3] Fix set variable issue
Reviewed-by: zwei4
Thanks,
David Wei
-Original Message-
From: Guo, Mang
Sent: Wednesday, April 05, 2017 2:57 PM
To: edk2-devel@lists.01.org
Cc: Wei, David ; Lu, ShifeiX A
Subject: [Patch][edk2-platforms/devel-MinnowBoard3 1/3] Fix get variable issue
On 04/06/17 02:45, Liming Gao wrote:
> Now, -fno-builtin option is added for the specific GCC tool chain.
> It is a generic option. It can be moved to common GCC option to keep
> the consistent compiler option.
>
> Cc: Ard Biesheuvel
> Cc: Yonghong Zhu
> Contributed-under: TianoCore Contribution
Reviewed-by: Jeff Fan
Thanks!
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan Bi
Sent: Thursday, April 06, 2017 8:53 AM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff
Subject: [edk2] [patch] UefiCpuPkg: Fix typos in UefiCpuPkg.dec
Cc: Jeff Fan
Cc: Jeff Fan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
UefiCpuPkg/UefiCpuPkg.dec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index e87f103..6f30ad0 100644
--- a/UefiCpuPkg/Uef
Reviewed-by: Liming Gao
> -Original Message-
> From: Zhu, Yonghong
> Sent: Saturday, April 1, 2017 1:59 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [Patch] BaseTools: update error message for SKUID_IDENTIFIER format
>
> Per DSC spec, the SkuUiName use '|' as separator,
Leo:
Seemly, this patch doesn't include new INF file. Could you create it again?
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leo
> Duran
> Sent: Wednesday, April 5, 2017 9:20 PM
> To: edk2-de...@ml01.01.org
> Cc: Kinney, Mi
Reviewed-by: Star Zeng
Thanks,
Star
-Original Message-
From: Gao, Liming
Sent: Friday, March 31, 2017 1:04 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star
Subject: [Patch] MdeModulePkg: Remove unsupported PcdExpression usage in module
INF
https://bugzilla.tianocore.org/show
Now, -fno-builtin option is added for the specific GCC tool chain.
It is a generic option. It can be moved to common GCC option to keep
the consistent compiler option.
Cc: Ard Biesheuvel
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
Signed-of
* Changed the FDF_SPECIFICATION value from 0x0001001A to
0x0001001B or 1.27
* Extended the FV and Capsule, FILE RAW statement formats to
support multiple binary files.
* Changed section 3.8 [FmpPayload] to add definitions for
MONOTONIC_COUNT and CERTIFICATE_GUID, plus some notes about
how t
* Changed the FDF_SPECIFICATION value from 0x0001001A to
0x0001001B or 1.27
* Extended the FV and Capsule, FILE RAW statement formats to
support multiple binary files.
* Changed section 3.8 [FmpPayload] to add definitions for
MONOTONIC_COUNT and CERTIFICATE_GUID, plus some notes about
how t
On 5 April 2017 at 22:28, Jeremy Linton wrote:
> Hi,
>
>
> On 04/05/2017 03:34 PM, Ard Biesheuvel wrote:
>>
>> On 5 April 2017 at 21:12, Jeremy Linton wrote:
>>>
>>> Hi,
>>>
>>> On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:
The new accelerated ARM and AARCH64 implementations take a
Hi,
On 04/05/2017 03:34 PM, Ard Biesheuvel wrote:
On 5 April 2017 at 21:12, Jeremy Linton wrote:
Hi,
On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:
The new accelerated ARM and AARCH64 implementations take advantage of
features that are only available when the MMU and Dcache are on. So
restri
Replace the uncached memory mapping of the framebuffer with a write-
combining one. This improves performance, and avoids issues with
unaligned accesses and DC ZVA instructions performed by the accelerated
memcpy/memset routines.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-b
Replace the uncached memory mapping of the framebuffer with a write-
combining one. This improves performance, and avoids issues with
unaligned accesses and DC ZVA instructions performed by the accelerated
memcpy/memset routines.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-b
On 5 April 2017 at 21:12, Jeremy Linton wrote:
> Hi,
>
> On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:
>>
>> The new accelerated ARM and AARCH64 implementations take advantage of
>> features that are only available when the MMU and Dcache are on. So
>> restrict the use of this library to the DXE p
Hi,
On 09/09/2016 09:00 AM, Ard Biesheuvel wrote:
The new accelerated ARM and AARCH64 implementations take advantage of
features that are only available when the MMU and Dcache are on. So
restrict the use of this library to the DXE phase or later.
I don't think this is sufficient because DC ZV
On 2017-04-05 06:58:33, Laszlo Ersek wrote:
>
> This is #2.
>
> Which one do you want to keep? I think we should drop #1, and keep #2.
>
> Do you wish to submit v5, or are you okay if I remove #1 for you at
> commit time?
>
> With this tweak,
>
> Reviewed-by: Laszlo Ersek
>
> Before committi
There are "load options" that are passed to drivers (as a part of the
EFI_LOADED_IMAGE_PROTOCOL), but there is no guarantee as to their format
(binary data or ASCII string or UCS-2 string). It is possible for "load" to be
modified to create this data and populate it between the calls to LoadImag
Glad to help.
I do not think that UEFI drivers really have the concept of command line
parameters... they use other methods for configuration...
-Jaben
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jim.dai...@dell.com
> Sent: Wednesday
On 5 April 2017 at 16:38, Leif Lindholm wrote:
> On Wed, Apr 05, 2017 at 11:01:05AM +0100, Ard Biesheuvel wrote:
>> On 5 April 2017 at 10:49, Laszlo Ersek wrote:
>> > On 04/05/17 11:38, Ard Biesheuvel wrote:
>> >> Given the agreement on the edk2-devel regarding the fact that the
>> >> notion whet
On Wed, Apr 05, 2017 at 11:01:05AM +0100, Ard Biesheuvel wrote:
> On 5 April 2017 at 10:49, Laszlo Ersek wrote:
> > On 04/05/17 11:38, Ard Biesheuvel wrote:
> >> Given the agreement on the edk2-devel regarding the fact that the
> >> notion whether or not a 'platform has ACPI' is a universal one, m
Thanks, Jaben. That makes sense.
Now I see the real issue is with the "app" I ran across. It is a driver,
and it was trying to access command line args. The driver crashed when
it tried to access the command line, but it had been loaded in memory via
the "load" command.
So, it seems "load" has
On 5 April 2017 at 15:11, Ard Biesheuvel wrote:
> On 5 April 2017 at 15:10, Ryan Harkin wrote:
>> On 5 April 2017 at 15:00, Ard Biesheuvel wrote:
>>> Counterpart to the EDK2 series switching Juno to the generic
>>> non-discoverable
>>> device driver and generic PCI host bridge driver.
>>>
>>> v
Jim,
That protocol must be installed on your applications own image handle for it to
be valid. Locating the protocol on some other image would result with finding
the other image's command line parameters and the like...
-Jaben
> -Original Message-
> From: edk2-devel [mailto:edk2-dev
On Wed, Apr 05, 2017 at 03:00:53PM +0100, Ard Biesheuvel wrote:
> In order to be able to switch to the generic PCI host bridge driver,
> implement the glue library that exposes the PCIe parameters to the
> common driver. Since the Juno performs some initialization of the
> PCIe control registers as
On Wed, Apr 05, 2017 at 02:58:06PM +0100, Ard Biesheuvel wrote:
> We are switching the Juno platform to the generic host bridge driver,
> which involves implementing PciHostBridgeLib for this platform, and
> plugging it into MdeModulePkg's PciHostBridgeDxe.inf.
>
> Since the platform descriptions
On Wed, Apr 05, 2017 at 02:11:44PM +0100, Ard Biesheuvel wrote:
> On 5 April 2017 at 14:09, Leif Lindholm wrote:
> > On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
> >> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
> >> cloning the ShutdownUefiBootServices() ro
On 5 April 2017 at 15:10, Ryan Harkin wrote:
> On 5 April 2017 at 15:00, Ard Biesheuvel wrote:
>> Counterpart to the EDK2 series switching Juno to the generic non-discoverable
>> device driver and generic PCI host bridge driver.
>>
>> v4: fixed a number of non-functional issues -- include orderin
On 5 April 2017 at 15:00, Ard Biesheuvel wrote:
> Counterpart to the EDK2 series switching Juno to the generic non-discoverable
> device driver and generic PCI host bridge driver.
>
> v4: fixed a number of non-functional issues -- include ordering, incorrect
> BASE_NAME, commit log clarificati
A question or two for all shell experts:
In the UEFI Shell Lib constructor code, if the Shell protocol cannot
be opened, then an attempt is made to locate it before "giving up".
However, if the Shell parameters protocol cannot be opened, no attempt
is made to locate it---the code simply leaves t
In order to be able to switch to the generic PCI host bridge driver,
implement the glue library that exposes the PCIe parameters to the
common driver. Since the Juno performs some initialization of the
PCIe control registers as well, copy that code from the old EDK2
driver into the library's constr
In preparation of moving ArmJunoDxe's support of the OHCI and EHCI
controllers to the generic non-discoverable device infrastructure,
add the prerequisite driver and library class resolution to the
Juno platform description.
Note that the FD image size needs to be increased slightly to
accommodate
Counterpart to the EDK2 series switching Juno to the generic non-discoverable
device driver and generic PCI host bridge driver.
v4: fixed a number of non-functional issues -- include ordering, incorrect
BASE_NAME, commit log clarifications
add RBs and TBs
Ard Biesheuvel (4):
Platforms/J
ArmJunoDxe no longer depends on BdsLib so we no longer have to specify
a library class resolution for it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
Platforms/ARM/Juno/ArmJuno.dsc | 5 +
1 file changed, 1 insertion(+)
Now that we have the prerequisites in place, switch to the generic PCI
host bridge driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
Platforms/ARM/Juno/ArmJuno.dsc | 17 +++--
Platforms/ARM/Juno/ArmJuno.fdf |
Having a three way conditional with callbacks would make sense if the
callbacks weren't (a) identical and (b) didn't return TRUE all the
time. So get rid of the kludge.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Tested-by: Ryan Harkin
Reviewed-by: Leif
On 04/05/17 14:55, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan
>
> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
> a basic version of VMWare's SVGA display device. Drivers for this
> device exist for some guest OSes which do not support Qemu's other
> display ad
We are switching the Juno platform to the generic host bridge driver,
which involves implementing PciHostBridgeLib for this platform, and
plugging it into MdeModulePkg's PciHostBridgeDxe.inf.
Since the platform descriptions no longer live in upstream EDK2, the
PciHostBridgeLib implementation (whic
This series is specific to Juno; it replaces the cargo culted and ancient
PCI 'emulation' code with calls into the new non-discoverable device API,
and removes the Juno specific PCI host bridge driver in favor of the generic
one.
v4: add missing commit log
add TBs and RBs
*no* code changes
The ArmJunoDxe driver code registers a callback for the EndOfDxe event,
at which time it does some manipulation of the PCI peripherals on the
board. Given that R0 has no working PCIe, instead of conditionally
performing these operations, omit the registration of the
callback altogether on that plat
Replace the open coded reimplementation of 'PCI emulation' with a pair
of calls into NonDiscoverableDeviceRegistrationLib to register the OHCI
and EHCI controllers. These will be picked up by the generic driver instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Bie
The ArmJunoDxe driver does not actually depend on the deprecated BdsLib
so remove the dependency declaration from the INF file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Tested-by: Ryan Harkin
Reviewed-by: Leif Lindholm
---
ArmPlatformPkg/ArmJunoPkg/
Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
cloning the ShutdownUefiBootServices() routine into a local source
file; this is the only BdsLib feature 'runaxf' depends on.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Tested-by: Ryan Har
Please disregard -- I failed to add Ryan's Tested-by
On 5 April 2017 at 14:53, Ard Biesheuvel wrote:
> This series is specific to Juno; it replaces the cargo culted and ancient
> PCI 'emulation' code with calls into the new non-discoverable device API,
> and removes the Juno specific PCI host br
Replace the open coded reimplementation of 'PCI emulation' with a pair
of calls into NonDiscoverableDeviceRegistrationLib to register the OHCI
and EHCI controllers. These will be picked up by the generic driver instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Bie
The ArmJunoDxe driver code registers a callback for the EndOfDxe event,
at which time it does some manipulation of the PCI peripherals on the
board. Given that R0 has no working PCIe, instead of conditionally
performing these operations, omit the registration of the
callback altogether on that plat
This series is specific to Juno; it replaces the cargo culted and ancient
PCI 'emulation' code with calls into the new non-discoverable device API,
and removes the Juno specific PCI host bridge driver in favor of the generic
one.
v4: add missing commit log
add acks
*no* code changes
Ard B
Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
cloning the ShutdownUefiBootServices() routine into a local source
file; this is the only BdsLib feature 'runaxf' depends on.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif L
The ArmJunoDxe driver does not actually depend on the deprecated BdsLib
so remove the dependency declaration from the INF file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJu
On Tue, Apr 04, 2017 at 01:30:07PM +0100, Ard Biesheuvel wrote:
> Replace the open coded reimplementation of 'PCI emulation' with a pair
> of calls into NonDiscoverableDeviceRegistrationLib to register the OHCI
> and EHCI controllers. These will be picked up by the generic driver instead.
>
That
On Tue, Apr 04, 2017 at 01:30:06PM +0100, Ard Biesheuvel wrote:
> The ArmJunoDxe driver does not actually depend on the deprecated BdsLib
> so remove the dependency declaration from the INF file.
>
Reviewed-by: Leif Lindholm
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off
This patch adds an SEV-specific .INF and corresponding assembly
files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.
The new .INF only supports the IA32 and X64 architectures.
Cc: Michael D Kinney
Cc: Liming Gao
Contribu
This patch adds an SEV-specific .INF and corresponding assembly
files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.
The new .INF only supports the IA32 and X64 architectures.
This patch follows the series "[PATCH v3 0
On 5 April 2017 at 14:18, Leif Lindholm wrote:
> On Tue, Apr 04, 2017 at 01:30:09PM +0100, Ard Biesheuvel wrote:
>
> Should this not have come kind of commit message?
>
Oops, sorry about that. I'm pretty sure I added one at some point, but
it got lost along the way.
>> Contributed-under: TianoCo
On Tue, Apr 04, 2017 at 01:30:10PM +0100, Ard Biesheuvel wrote:
> Having a three way conditional with callbacks would make sense if the
> callbacks weren't (a) identical and (b) didn't return TRUE all the
> time. So get rid of the kludge.
>
Reviewed-by: Leif Lindholm
> Contributed-under: TianoC
On Tue, Apr 04, 2017 at 01:30:09PM +0100, Ard Biesheuvel wrote:
Should this not have come kind of commit message?
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
>
On Tue, Apr 04, 2017 at 01:30:08PM +0100, Ard Biesheuvel wrote:
> The ArmJunoDxe driver code registers a callback for the EndOfDxe event,
> at which time it does some manipulation of the PCI peripherals on the
> board. Given that R0 has no working PCIe, we can omit the registration
> of the callbac
On 5 April 2017 at 14:11, Ard Biesheuvel wrote:
> On 5 April 2017 at 14:09, Leif Lindholm wrote:
>> On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
>>> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
>>> cloning the ShutdownUefiBootServices() routine into a local
Liming,
Yes, agreed... I'll push a v5.
Leo.
> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Tuesday, April 04, 2017 8:48 PM
> To: Duran, Leo ; edk2-de...@ml01.01.org
> Cc: Kinney, Michael D ; Singh, Brijesh
>
> Subject: RE: [edk2] [PATCH v4] MdePkg: BaseIoLi
On 5 April 2017 at 14:09, Leif Lindholm wrote:
> On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
>> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
>> cloning the ShutdownUefiBootServices() routine into a local source
>> file; this is the only BdsLib feature 'runa
On Tue, Apr 04, 2017 at 01:30:05PM +0100, Ard Biesheuvel wrote:
> Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
> cloning the ShutdownUefiBootServices() routine into a local source
> file; this is the only BdsLib feature 'runaxf' depends on.
I was going to go through these indi
On 04/05/17 14:37, Phil Dennis-Jordan wrote:
>> In fact, above you already have a (BitsPerPixel == 32) check. At the end
>> of that block, you could set PixelMask to MAX_UINT32 explicitly. And,
>> you could add an "else" branch, simply with
>>
>> PixelMask = (1u << (BitsPerPixel - 1)) - 1;
>>
>>
From: Phil Dennis-Jordan
In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
a basic version of VMWare's SVGA display device. Drivers for this
device exist for some guest OSes which do not support Qemu's other
display adapters, so supporting it in OVMF is useful in conjunction
From: Phil Dennis-Jordan
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. (The register value port has an offset of 1 and req
From: Phil Dennis-Jordan
This adds a header file defining symbolic constants for the VMWare SVGA
virtual display device in preparation for supporting it in
QemuVideoDxe.
It is mostly an extract of the file lib/vmware/svga_reg.h from commit
329dd537456f93a806841ec8a8213aed11395def of VMWare's vmw
This extends the QemuVideoDxe driver to support the VMWare SVGA display
device implemented by Qemu. Drivers for this device exist for guest OSes
which do not support Qemu's other display adapters, so supporting it in
OVMF is useful in conjunction with those OSes.
I've tried to follow the existing
On Wed, Apr 5, 2017 at 11:41 PM, Laszlo Ersek wrote:
> On 04/05/17 11:58, Phil Dennis-Jordan wrote:
>> From: Phil Dennis-Jordan
>>
>> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
>> a basic version of VMWare's SVGA display device. Drivers for this
>> device exist for so
On 04/05/17 11:58, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan
>
> In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
> a basic version of VMWare's SVGA display device. Drivers for this
> device exist for some guest OSes which do not support Qemu's other
> display ad
Hi folks,
We are using NetLibAsciiStrToIp6 function in DxeNetLib.c of MdeModulePkg to
convert string to IPv6 address. We found this function will return invalid
parameter with below input:
2001:3456:789a::f012:2:2003:2005
We trace the code and believe it is handled by the branch in line 295
On 04/05/17 11:57, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan
>
> The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
> an I/O-type BAR which is laid out such that some register offsets are
> not aligned to the read/write width with which they are expected to be
> acce
On 04/05/17 11:57, Phil Dennis-Jordan wrote:
> From: Phil Dennis-Jordan
>
> This adds a header file defining symbolic constants for the VMWare SVGA
> virtual display device in preparation for supporting it in
> QemuVideoDxe.
>
> It is mostly an extract of the file lib/vmware/svga_reg.h from comm
On 5 April 2017 at 10:49, Laszlo Ersek wrote:
> On 04/05/17 11:38, Ard Biesheuvel wrote:
>> Given the agreement on the edk2-devel regarding the fact that the
>> notion whether or not a 'platform has ACPI' is a universal one, move
>> the PlatformHasAcpi GUID to MdeModulePkg.
>>
>> Contributed-under
From: Phil Dennis-Jordan
This adds a header file defining symbolic constants for the VMWare SVGA
virtual display device in preparation for supporting it in
QemuVideoDxe.
It is mostly an extract of the file lib/vmware/svga_reg.h from commit
329dd537456f93a806841ec8a8213aed11395def of VMWare's vmw
From: Phil Dennis-Jordan
In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
a basic version of VMWare's SVGA display device. Drivers for this
device exist for some guest OSes which do not support Qemu's other
display adapters, so supporting it in OVMF is useful in conjunction
From: Phil Dennis-Jordan
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. (The register value port has an offset of 1 and req
This extends the QemuVideoDxe driver to support the VMWare SVGA display
device implemented by Qemu. Drivers for this device exist for guest OSes
which do not support Qemu's other display adapters, so supporting it in
OVMF is useful in conjunction with those OSes.
I've tried to follow the existing
When I try to set break point after launching the application and
CpuBreakpoint() is hit and symbols are seen in lmv command, the
breakpoints are set using F9. I can list them with bl. But if I
attempt to set a breakpoint with F9 before CpuBreakpoint is called
WinDbg pops up a dialog box throwing t
On 04/05/17 11:38, Ard Biesheuvel wrote:
> Given the agreement on the edk2-devel regarding the fact that the
> notion whether or not a 'platform has ACPI' is a universal one, move
> the PlatformHasAcpi GUID to MdeModulePkg.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-b
Hi, Andrey
When the client received such a segment that moves the right edge of send
window back to the left said, the client actually have no idea about whether
the server is "shrinking the window" or just "reducing window size". Actually,
if the server reduced the advertised windows size too
Given the agreement on the edk2-devel regarding the fact that the
notion whether or not a 'platform has ACPI' is a universal one, move
the PlatformHasAcpi GUID to MdeModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: "Zeng, Star"
---
Ar
1 - 100 of 104 matches
Mail list logo
