Liming
Why halt on finding the DEC statement? Why not wait to see how the PCD is used
in the build? As long as it is only used one way in a given build, why does
the other option matter at all?
-Jaben
From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, October 08, 2014 7:28 PM
T
If you've found issues on Apple systems, please report them:
https://developer.apple.com/bug-reporting/
Cameron Esfahani
di...@apple.com
> On Oct 8, 2014, at 19:46, Thomas Rognon wrote:
>
> Even popular ones. Microsoft's Surface's Flush() for simple file system
> doesn't work properly, for e
Thought as much, ok thanks for the info. I have worked around the issue.
Date: Wed, 8 Oct 2014 21:46:45 -0500
From: tcrog...@gmail.com
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] BltLibVideoToBltBuffer returns black pixels
If you know you have the right handle, the most likely proble
If you know you have the right handle, the most likely problem is the GOP
driver. Almost every system I've come across has problems with driver
implementations. Even popular ones. Microsoft's Surface's Flush() for
simple file system doesn't work properly, for example. Many systems will
crash with i
Sure, I've attached a few related functions.
Date: Wed, 8 Oct 2014 22:32:10 -0300
From: rafaelrodrigues.mach...@gmail.com
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] BltLibVideoToBltBuffer returns black pixels
Hi J. E.
Is it possible for you to send us some code related to this ? Ma
Tim:
Now, PcdsFeatureFlag can't be extended to other PCD type, like DynamicEx. You
have meet with this issue.
To use it as DynamicEx, one solution is to change its type from
PcdsFeatureFlag to FixedAtBuild, DynamicEx in Package DEC file. This change is
incompatible and impact Platform DSC f
Jordan,
For single patch sync, I agree with using "patch+message" in the first line is
better for git to summarize the log history. But it is rare case.
On most cases, to reduce the maintain effort (hundreds of patches for each
branch release. Also sometimes, some patch maybe hard to be applied
Hi J. E.
Is it possible for you to send us some code related to this ? Maybe the
important parts only.
I think it'll be easier to try to help.
Thanks
Rafael R. Machado
2014-10-08 19:43 GMT-03:00 J. E. :
> I always use the last handle in the handle list, it works on 100% of the
> PC's Ive teste
Yes. This is an issue. Library instance should implement all library APIs. We
will follow up it.
Thanks
Liming
From: Andrew Fish [mailto:af...@apple.com]
Sent: Thursday, October 09, 2014 7:34 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Why does the SMM_CORE instance of the SmmServices
InSmm() is part of the LibraryClass definition, but not in the SMM_CORE
implementation. Is this is a bug?
Thanks,
Andrew Fish
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/SmmServicesTableLib.h
extern EFI_SMM_SYSTEM_TABLE2 *gSmst;
/**
This function allows the caller
On Oct 8, 2014, at 3:59 PM, Toto Lebolo wrote:
> Is it possible to consume a protocol from a different package?
> For example I am creating a shell application in MdeModulePkg and I want to
> use an SPI protocol in a platform specific in my case in IntelE6xxRuPkg.
> How do I do that? should I
Is it possible to consume a protocol from a different package?
For example I am creating a shell application in MdeModulePkg and I want to use
an SPI protocol in a platform specific in my case in IntelE6xxRuPkg.
How do I do that? should I copy files from one package to another?
Thank for the hel
I always use the last handle in the handle list, it works on 100% of the PC's
Ive tested. Some PC's have 3 or 4 handles.
However I'd prefer to do it the correct way so I will query the protocol as
suggested.
I currently use:
nGOPHandleIndex = handleCount - 1;
Status = gBS->HandleProtocol(
Nice tip Thomas!!!
Thanks
2014-10-08 14:27 GMT-03:00 Thomas Rognon :
> Another way is to get it from the ConOut device path. There's a UEFI
> variable called "ConOut" (refer to UEFI spec) that holds a device path.
> Doing a LocateDevicePath() with gEfiGraphicsOutputProtocolGuid and this
> device
On 8 October 2014 17:56, Laszlo Ersek wrote:
> Please consider adding "tags" as well.
Good call.
Not added as it isn't a build artefact as such, but if people would
accept taking this patch to begin with, I agree that tags would be a
useful addition.
Regards,
Leif
-
On Mon, Oct 6, 2014 at 8:42 AM, Gabriel L. Somlo wrote:
> Hi Jordan,
>
> On Sat, Oct 04, 2014 at 07:35:25PM -0700, Jordan Justen wrote:
>> > On Wed, Oct 01, 2014 at 12:31:58AM +0200, Laszlo Ersek wrote:
>> >> On 09/30/14 23:42, Jordan Justen wrote:
>> >> > BaseTimerLib:
>> >> > * Reads host bridg
Another way is to get it from the ConOut device path. There's a UEFI
variable called "ConOut" (refer to UEFI spec) that holds a device path.
Doing a LocateDevicePath() with gEfiGraphicsOutputProtocolGuid and this
device path gives you the handle to GOP that ConOut is using. Just
OpenProtocol() with
On 10/08/14 17:33, Leif Lindholm wrote:
> From: Ryan Harkin
>
> From: Ryan Harkin
>
> While edk2 is still maintained in SVN, Many edk2 developers use git
> for their main workflow, using the official mirrors.
> This .gitignore file prevents files generated as part of the build
> from cluttering
Hi J. E.
Just one question.
Are you sure that this GOP you are using is handled by the current active
graphic device ?
I'm asking this because some time ago I had one problem like this, and the
situation was that my system had two gop handles, but the first one that
was detected was not related t
Liming -
I don't understand. DynamicEx supports BOOLEAN also. Why is it incompatible? It
seems like a backward-compatible extension to the existing design. And, as
mentioned, the restriction that is not useful.
Having two PCDs that have the exact same meaning just adds a DynamicEx PCD
that, mo
Sergey,
No, it is not a bug. The code you copied is reading the handle to use in the
performance code. If CoreLoadImageCommon above it was successful, then
*ImageHandle will already have the correct value. If CoreLoadImageCommon
failed, NULL will be used (Handle was set to NULL just above the i
From: Ryan Harkin
From: Ryan Harkin
While edk2 is still maintained in SVN, Many edk2 developers use git
for their main workflow, using the official mirrors.
This .gitignore file prevents files generated as part of the build
from cluttering up "git status" output.
Contributed-under: TianoCore C
Reviewed-by: Jaben Carsey
From: Qiu, Shumin
Sent: Tuesday, October 07, 2014 11:46 PM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] ShellPkg: Add a typecast to 'BOOLEAN' to avoid build
failure in VS2005.
Importance: High
Hi Jaben,
Could you help review the patc
Sigh, and I generated that against the wrong branch.
Here is one that actually applies on current master:
>From 34f8069eb293d524824fe10efba30993c2cb1eb4 Mon Sep 17 00:00:00 2001
From: Leif Lindholm
Date: Wed, 8 Oct 2014 15:20:04 +0100
Subject: [PATCH] ArmVExpressPkg: enable specifying firmware ve
If FIRMWARE_VER is defined on the build command line, set
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString based on it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm
---
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc |3 +++
1 file changed, 3
Hi, experts:
I found PI Spec included EFI_SIO_PROTOCOL description.
But not find EFI_ISA_IO_PROTOCOL.
So, EFI_ISA_IO_Protocol is depreciated?
Best wishes,
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog
Dear sirs,
In the module /MdeModulePkg/Core/Dxe/Image/Image.c I see the procedure
--
EFI_STATUS
EFIAPI
CoreLoadImage (
IN BOOLEANBootPolicy,
IN EFI_HANDLE ParentImageHandle,
IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
IN VOID *Sour
Tim:
In current design, PcdsFeatureFlag is BOOLEAN FixedAtBuild PCD. It can't be
extended to other PCD type. To use it as PcdDynamicEx, its type has to be
changed. But, this change is incompatible. To avoid its impact, could you
introduce new PCD for PcdDynamicEx usage?
Thanks
Liming
From: Ti
Sergey:
It means TextTwo in this opcode is not used. It can be removed. For example,
the highlighted statement is unused. Now, VfrCompiler tool directly ignores it.
The better code should remove it.
FrontPageVfr.Vfr:
text
help= STRING_TOKEN(STR_CONTINUE_HELP),
text=
Scott:
Does MINGW base on GCC? If yes, is it similar to which version GCC? If I
verify the code in MINGW tool chain, do I need to verify it in native GCC tool
chain?
For size issue, have you compared the size between native GCC tool chain and
MINGW tool chain?
For Nasm issue in BaseL
30 matches
Mail list logo
