On 22 August 2017 at 23:23, Leif Lindholm wrote:
> Initial version contained only myself and Mike. While a more granular
> structure will be needed long-term, let's have two ARM-maintainers for now.
>
> Cc: Ard Biesheuvel
> Cc: Michael D Kinney
> Contributed-under: TianoCore Contribution Agreeme
Fix the issue of creating duplicate UNI file names
Fix the issue of removing packages
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: hesschen
---
BaseTools/Source/Python/UPT/Core/DependencyRules.py| 2 ++
BaseTools/Source/Python/UPT/GenMetaFile/GenInfFile.py | 6
Current calculate timeout logic may have overflow if the input
timeout value too large. This patch fix this potential overflow
issue.
Cc: Michael Kinney
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
UefiCpuPkg/Library/MpInitLib/MpLib.c | 30 +
Hi, experts:
There is an Open Compute Project(OCP).
They provided open server design guide, and reference schematic.
I have a question about its bios.
Is there open source uefi bios for this project?
Thanks
best wishes,
保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL
Got it, thanks.
Best Regards,
Bell Song
From: Yao, Jiewen
Sent: Wednesday, August 23, 2017 11:03 AM
To: Song, BinX ; Gao, Liming ;
Kinney, Michael D ; Kinney, Michael D
Cc: edk2-devel@lists.01.org
Subject: RE: [PATCH V2] IntelFsp2Pkg: Fix build error with WHOLEARCHIVE option
Never mind.
If we
Never mind.
If we agree to use "empty" in comment, I can update for you when I check in.
Thank you
Yao Jiewen
From: Song, BinX
Sent: Wednesday, August 23, 2017 11:02 AM
To: Yao, Jiewen ; Gao, Liming ;
Kinney, Michael D ; Kinney, Michael D
Cc: edk2-devel@lists.01.org
Subject: RE: [PATCH V2] Int
Hi Jiewen,
Do I need to update this patch?
Best Regards,
Bell Song
From: Yao, Jiewen
Sent: Wednesday, August 23, 2017 10:54 AM
To: Gao, Liming ; Kinney, Michael D
; Song, BinX ; Kinney, Michael
D
Cc: edk2-devel@lists.01.org
Subject: RE: [PATCH V2] IntelFsp2Pkg: Fix build error with WHOLEARCHI
I checked existing code, we have below styles:
MD4 Digest Wrapper Implementation which does not provide real capabilities.
Null Base Debug Library instance with empty functions.
A emptry template implementation of PCD Library.
Base Performance Library which provides no service.
I think we
Frank:
This is unsupported feature. Now, FeatureFlagExpression is ignored.
Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, August 23, 2017 7:55 AM
>To: frank@dell.com; edk2-devel@lists.01.org
>
Mike:
TempRamInitApi() is referred in
Library\SecFspSecPlatformLibNull\Ia32\Flat32.nasm. FspSecCoreM, FspSecCoreS and
FspSecCoreT all link this library.
How about describe this function as the empty implementation?
Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2
The EnumProcTraceMemDisable/OutputSchemeInvalid are redundant
definitions. These definitions can be handled by other code,
so remove them.
Cc: Michael Kinney
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
UefiCpuPkg/Library/CpuCommonFeaturesLi
These two definitions have redundant definition which can be handle by code.
This patch update them to follow new code definitions.
Cc: Michael Kinney
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
UefiCpuPkg/UefiCpuPkg.dec | 14 ++
These two PCD have redundant definition which can be handle by code. This patch
series update the
code and default value for these two PCDs.
Eric Dong (2):
UefiCpuPkg/CpuCommonFeaturesLib: Remove redundant definition.
UefiCpuPkg: Update default for
PcdCpuProcTraceMemSize/PcdCpuProcTraceOu
On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote:
> On 08/17/17 00:37, Jordan Justen wrote:
> > On 2017-08-16 12:23:49, Leif Lindholm wrote:
>
> [snip]
>
> >> - the value proposition
> >> for Linaro is that having maintainer parity ArmVirtPkg/OvmfPkg
> >> simplifies the task of mainta
On 08/23/17 01:21, frank@dell.com wrote:
> Dell - Internal Use - Confidential
>
> I'm trying to use this feature as described in various edk2 documents with
> zero success.
> For example, in the INF spec 1.25, the following is defined for the protocols
> section :
>
>
>
> The formats for
Reviewed-by: Michael D Kinney
Mike
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, August 21, 2017 7:30 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D
> Subject: [PATCH edk2-platforms] Contributions.txt: update to
> latest version f
Dell - Internal Use - Confidential
I'm trying to use this feature as described in various edk2 documents with
zero success.
For example, in the INF spec 1.25, the following is defined for the protocols
section :
The formats for entries in this section is:
gEfiProtocolCName [ | FeatureFlagEx
Reviewed-by: Michael D Kinney
Mike
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, August 22, 2017 3:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael
> D
> Subject: [PATCH edk2-platforms] Maintainers.txt: Add Ard
>
> On Aug 22, 2017, at 10:56 AM, Paulo Alcantara wrote:
>
> Hi,
>
> On 8/22/2017 2:21 PM, Andrew Fish wrote:
>>> On Aug 22, 2017, at 6:14 AM, Paulo Alcantara wrote:
>>>
>>> Hi,
>>>
>>> I do apologize my late replies. At the moment, I'm only able to work on
>>> this during my free time. Thank
Eric,
Yes. I like the idea of removing both OutputSchemeInvalid
and ProcTraceMemDisable values.
Mike
> -Original Message-
> From: Dong, Eric
> Sent: Monday, August 21, 2017 6:43 PM
> To: Kinney, Michael D ; edk2-
> de...@lists.01.org
> Cc: Ni, Ruiyu ; Gao, Liming
>
> Subject: RE: [edk2
Bell Song,
Why is it documented as a "Dummy" function?
There must be a reference to this symbol somewhere or it would
not generate a link error. The implementation is an empty
function. Is that a better way to describe this function?
Mike
> -Original Message-
> From: edk2-devel [mail
Initial version contained only myself and Mike. While a more granular
structure will be needed long-term, let's have two ARM-maintainers for now.
Cc: Ard Biesheuvel
Cc: Michael D Kinney
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm
---
Maintainers.txt | 2
On 22 August 2017 at 20:05, Leif Lindholm wrote:
> On Tue, Aug 22, 2017 at 07:38:03PM +0200, Laszlo Ersek wrote:
>> On 08/22/17 18:57, Leif Lindholm wrote:
>> > On Tue, Aug 22, 2017 at 05:30:13PM +0100, Ard Biesheuvel wrote:
>> >> One of the reasons for introducing virtio-gpu support to OvmfPkg an
On Tue, Aug 22, 2017 at 07:38:03PM +0200, Laszlo Ersek wrote:
> On 08/22/17 18:57, Leif Lindholm wrote:
> > On Tue, Aug 22, 2017 at 05:30:13PM +0100, Ard Biesheuvel wrote:
> >> One of the reasons for introducing virtio-gpu support to OvmfPkg and
> >> ArmVirtpkg was the fact that under KVM virtualiz
Hi,
On 8/22/2017 2:21 PM, Andrew Fish wrote:
On Aug 22, 2017, at 6:14 AM, Paulo Alcantara wrote:
Hi,
I do apologize my late replies. At the moment, I'm only able to work on this
during my free time. Thank you all for the reviews!
FWIW, my comments below.
On 8/20/2017 11:29 PM, Ni, Ruiyu
On 08/22/17 19:21, Andrew Fish wrote:
>
>> On Aug 22, 2017, at 6:14 AM, Paulo Alcantara wrote:
>>
>> Hi,
>>
>> I do apologize my late replies. At the moment, I'm only able to work on this
>> during my free time. Thank you all for the reviews!
>>
>> FWIW, my comments below.
>>
>> On 8/20/2017 11:
On 08/22/17 18:57, Leif Lindholm wrote:
> On Tue, Aug 22, 2017 at 05:30:13PM +0100, Ard Biesheuvel wrote:
>> One of the reasons for introducing virtio-gpu support to OvmfPkg and
>> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
>> legacy VGA cannot be used reliably. This is due t
> On Aug 22, 2017, at 6:14 AM, Paulo Alcantara wrote:
>
> Hi,
>
> I do apologize my late replies. At the moment, I'm only able to work on this
> during my free time. Thank you all for the reviews!
>
> FWIW, my comments below.
>
> On 8/20/2017 11:29 PM, Ni, Ruiyu wrote:
>> Paulo,
>> 1. Could
On 22 August 2017 at 18:02, Laszlo Ersek wrote:
> On 08/22/17 18:30, Ard Biesheuvel wrote:
>> One of the reasons for introducing virtio-gpu support to OvmfPkg and
>> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
>> legacy VGA cannot be used reliably. This is due to an implement
On 22 August 2017 at 17:57, Leif Lindholm wrote:
> On Tue, Aug 22, 2017 at 05:30:13PM +0100, Ard Biesheuvel wrote:
>> One of the reasons for introducing virtio-gpu support to OvmfPkg and
>> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
>> legacy VGA cannot be used reliably. Thi
On 08/22/17 18:30, Ard Biesheuvel wrote:
> One of the reasons for introducing virtio-gpu support to OvmfPkg and
> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
> legacy VGA cannot be used reliably. This is due to an implementation
> detail of QEMU+KVM, which remaps cached host m
On Tue, Aug 22, 2017 at 05:30:13PM +0100, Ard Biesheuvel wrote:
> One of the reasons for introducing virtio-gpu support to OvmfPkg and
> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
> legacy VGA cannot be used reliably. This is due to an implementation
> detail of QEMU+KVM, whi
On 08/22/17 18:30, Ard Biesheuvel wrote:
> One of the reasons for introducing virtio-gpu support to OvmfPkg and
> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
> legacy VGA cannot be used reliably. This is due to an implementation
> detail of QEMU+KVM, which remaps cached host m
One of the reasons for introducing virtio-gpu support to OvmfPkg and
ArmVirtpkg was the fact that under KVM virtualization on ARM, the
legacy VGA cannot be used reliably. This is due to an implementation
detail of QEMU+KVM, which remaps cached host memory into the guest
address space as a framebuff
On 08/22/17 17:44, Brijesh Singh wrote:
>
>
> On 08/21/2017 09:05 AM, Laszlo Ersek wrote:
>
> [...]
>
>>
>>> for (Index = 0; Index < RNGValueLength; Index++) {
>>> RNGValue[Index] = Buffer[Index];
>>> }
>>> Status = EFI_SUCCESS;
>>> + //
>>> + // Buffer is already Unmaped(), g
On 22/08/2017 18:04, Laszlo Ersek wrote:
>> That said, the extra "-Wl," in "-Wl,-pie" is not necessary; the compiler
>> driver knows "-pie" and swallows it when compiling (and passes it to the
>> linker).
> Now *that* I can get behind. If this works, then please let us do it --
> replace "-fpie" wi
On 08/22/17 16:15, Paolo Bonzini wrote:
> On 22/08/2017 16:03, Ard Biesheuvel wrote:
>> On 22 August 2017 at 14:27, Paolo Bonzini wrote:
>>> On 22/08/2017 13:59, Laszlo Ersek wrote:
This seems to suggest that "-pie" is the *master* switch (used only when
linking), and "-fpie" is a *prere
On 08/22/17 16:29, Brijesh Singh wrote:
> Thanks for detail explanation, I was trying driver unload and reload
> from the UEFI shell but that did not trigger the BindStop hence I was
> not sure how it all works.
*Unload* is a different thing. Clearly a driver can only be unloaded
after all its cu
On 08/21/2017 09:05 AM, Laszlo Ersek wrote:
[...]
for (Index = 0; Index < RNGValueLength; Index++) {
RNGValue[Index] = Buffer[Index];
}
Status = EFI_SUCCESS;
+ //
+ // Buffer is already Unmaped(), goto free it.
+ //
+ goto FreeBuffer;
(6) We restrict "goto" state
On 08/22/17 16:31, Ard Biesheuvel wrote:
> [...]
>>>
>>> (1) When we added VirtioGpuDxe to the ArmVirtPkg platforms, the only
>>> reason I didn't propose removing QemuVideoDxe from the same platforms
>>> was that QemuVideoDxe was usable on QEMU/TCG, and I figured it wouldn't
>>> hurt to keep it.
>>
[...]
>>
>> (1) When we added VirtioGpuDxe to the ArmVirtPkg platforms, the only
>> reason I didn't propose removing QemuVideoDxe from the same platforms
>> was that QemuVideoDxe was usable on QEMU/TCG, and I figured it wouldn't
>> hurt to keep it.
>>
>> Other than that, I see zero point in using t
Hi Laszlo,
On 08/22/2017 06:14 AM, Laszlo Ersek wrote:
So the question: is it possible that we may get called from both
ExitBootService notify and device uninit functions ?
This is a valid problem statement / question, and I verified your code
with regard to it, in the patches that I review
On 22/08/2017 16:03, Ard Biesheuvel wrote:
> On 22 August 2017 at 14:27, Paolo Bonzini wrote:
>> On 22/08/2017 13:59, Laszlo Ersek wrote:
>>> This seems to suggest that "-pie" is the *master* switch (used only when
>>> linking), and "-fpie" is a *prerequisite* for it (to be used both when
>>> link
On 22 August 2017 at 14:27, Paolo Bonzini wrote:
> On 22/08/2017 13:59, Laszlo Ersek wrote:
>> This seems to suggest that "-pie" is the *master* switch (used only when
>> linking), and "-fpie" is a *prerequisite* for it (to be used both when
>> linking and compiling). Is this right?
>>
>> If so, t
On 22/08/2017 13:59, Laszlo Ersek wrote:
> This seems to suggest that "-pie" is the *master* switch (used only when
> linking), and "-fpie" is a *prerequisite* for it (to be used both when
> linking and compiling). Is this right?
>
> If so, then I think this is a gcc usability bug. We don't genera
Hi,
On 8/20/2017 11:37 PM, Gao, Liming wrote:
I suggest to run PatchCheck tool first. It is mentioned in
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
Yes, I will! Thanks for remembering me that. I've also found some broken
formatting all over the code. I'l
Hi,
I do apologize my late replies. At the moment, I'm only able to work on
this during my free time. Thank you all for the reviews!
FWIW, my comments below.
On 8/20/2017 11:29 PM, Ni, Ruiyu wrote:
Paulo,
1. Could you please run the ECC check tool (BaseTools\Source\Python\Ecc\)
"CRC" migh
Hello
I have tried to use VFR's "inconsistentif prompt" and discovered that
problem with prompt's message for "inconsistentif prompt" remains unfixed.
When I use:
inconsistedif prompt = STRING_TOKEN(STR_ERROR_POPUP)
#string STR_ERROR_POPUP#language en-US "You typed in
something ba
Reviewed-by: Liming Gao
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan
> Bi
> Sent: Tuesday, August 22, 2017 8:17 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Gao, Liming
> Subject: [edk2] [PATCH V5 0/3] Add HII Popup Protocol
Laszlo:
I will take BZ#671 and create the formal patch for review.
Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, August 22, 2017 7:59 PM
> To: Shi, Steven ; Ard Biesheuvel
>
> Cc: edk2-devel-01 ; Alex Williamson
> ; Justen, Jordan
Add one sample case about how to use HiiPopup protocol to draw message box.
Cc: Eric Dong
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
.../Universal/DriverSampleDxe/DriverSample.c | 29 ++
.../Universal/DriverSamp
V5:
Move the protocol GUID to the part fot UEFI2.7 protocol in dec.
Add definitions for HII Popup Protocol according to UEFI2.7.
Cc: Eric Dong
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
MdePkg/Include/Protocol/HiiPopup.h | 81 ++
Patch 1: Add the definition of HII Popup Protocol.
Patch 2: Add the implementation of HII Popup Protocol.
Patch 3: Add one sample use case of HII Popup Protocol.
V5:
Move the protocol GUID to the part fot UEFI2.7 protocol in dec.
V4:
Updates in pacth 2:
Add more comments and remove one unnecessar
V4:
Add more comments and remove one unnecessary
check in function ParseMessageString().
V3:
Separate DrawMessageBox() function into CalculatePopupPosition()
DrawMessageBox() and GetUserSelection() three functions and refine
related codes.
V2:
Addstring "ERROR", "WARNING", "INFO" at the top of th
On 08/22/17 10:00, Shi, Steven wrote:
> It is a link flag misuse in our GCC build toolchains, not
> compiler/linker's problem. Below patch can fix the wrong assembly
> function relocation type in PIE binary. With below patch, all the
> GCC5, GCC49 and GCC48 can build correctly images of OvmfPkgIa32
Dandan:
I have one minor comments. This protocol is in UEFI2.7. Please add it below
UEFI2.7 comment in MdePkg.dec
Thanks
Liming
> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, August 22, 2017 3:18 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Gao, Liming
> Subject: [PATC
On 08/22/17 03:42, Brijesh Singh wrote:
>
>
> On 8/21/17 10:24 AM, Laszlo Ersek wrote:
>
> [Snip]...
>
>> (25) I think you intended to add the empty line above the "ReleaseQueue"
>> label, not below it.
>>
>>>VirtioRingUninit (Dev->VirtIo, &Dev->Ring);
>>>
>>> Failed:
>> (26) You forgot
thanks for sharing information , Liming
At 2017-08-22 16:45:33, "Gao, Liming" wrote:
>You can check OvmfPkg\build.sh. The default tool chain is GCC5, not GCC46.
>
>Your build uses GCC46 tool chain with GCC62, which is wrong.
>
>>-Original Message-
>>From: edk2-devel [mailto:edk2
You can check OvmfPkg\build.sh. The default tool chain is GCC5, not GCC46.
Your build uses GCC46 tool chain with GCC62, which is wrong.
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>wang xiaofeng
>Sent: Tuesday, August 22, 2017 4:26 PM
>To:
Hello,
I just try to build OVMF with GCC62 in Ubuntu. The following errors shows:
GenFw: ERROR 3000: Invalid
/home/jerry/EDKII/edk2/Build/OvmfIa32/DEBUG_GCC46/IA32/OvmfPkg/Sec/SecMain/DEBUG/SecMain.dll
unsupported ELF EM_386 relocation 0x4.
From tools_def.txt it seems the latest suppor
It is a link flag misuse in our GCC build toolchains, not compiler/linker’s
problem. Below patch can fix the wrong assembly function relocation type in PIE
binary. With below patch, all the GCC5, GCC49 and GCC48 can build correctly
images of OvmfPkgIa32X64 and OvmfPkgX64 platforms without my pre
From: Daniel Verkamp
This is a patch to implement writing and dumping of PCI 3.0 Device ID
lists in EFI option ROMs in the EfiRom tool.
Using this modification, multiple space-delimited device IDs can be
specified after -i. The first device in the list is used for the main
PCI ROM header Device
Add one sample case about how to use HiiPopup protocol to draw message box.
Cc: Eric Dong
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
.../Universal/DriverSampleDxe/DriverSample.c | 29 ++
.../Universal/DriverSamp
V4:
Add more comments and remove one unnecessary
check in function ParseMessageString().
V3:
Separate DrawMessageBox() function into CalculatePopupPosition()
DrawMessageBox() and GetUserSelection() three functions and refine
related codes.
V2:
Addstring "ERROR", "WARNING", "INFO" at the top of th
Add definitions for HII Popup Protocol according to UEFI2.7.
Cc: Eric Dong
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
MdePkg/Include/Protocol/HiiPopup.h | 81 ++
MdePkg/MdePkg.dec | 3
Patch 1: Add the definition of HII Popup Protocol.
Patch 2: Add the implementation of HII Popup Protocol.
Patch 3: Add one sample use case of HII Popup Protocol.
V4:
Updates in pacth 2:
Add more comments and remove one unnecessary
check in function ParseMessageString().
V3:
Updates in pacth 2:
Se
66 matches
Mail list logo
