date:20141008

Re: [edk2] DynamicEx and FeatureFlag

2014-10-08 Thread Carsey, Jaben

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
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DynamicEx and FeatureFlag

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 file. Another solution is to introduce new 
PCD for DynamicEx purpose.

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, October 09, 2014 12:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DynamicEx and FeatureFlag

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, most of the time, will never be used, but will still be in the PCD 
database. 90% of the time, this PCD would be FeatureFlag. That means that 90% 
of the time I would have an unused DynamicEx PCD in the PCD database.

Tim

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, October 08, 2014 2:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DynamicEx and FeatureFlag

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: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, October 01, 2014 2:23 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] DynamicEx and FeatureFlag

Currently the flag PcdDxeIplSwitchToLongMode is declared as storage type 
PcdFeatureFlag.

But we tried to change it to DynamicEx. Ok, that works great. We changed the 
.dec file to say [PcdDynamicEx]. No problem.

But then we tried to make it selectable by .dsc by making it [PcdFeatureFlag, 
PcdDynamicEx] in the .dec file.

Then we get this error:

"PcdsFeatureFlag must not be in the same section of other types of PCD"
While I understand that there are cases where feature-flag PCDs must be 
resolved during the build process, this is not always the case and I would 
rather I get the error when I try to use the non-feature-flag PCD in the wrong 
place. Do I really have to change this to PcdFixedAtBuild?

Tim
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread Cameron Esfahani

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 example. Many systems will crash with improperly 
> formatted boot entries. The list goes on. A lot of stuff doesn't get used 
> heavily and probably doesn't get tested heavily, either. You just kinda have 
> to work around it or limit your software to specific machines that you've 
> tested. I'm sure it will get better over time.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread J. 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 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 
improperly formatted boot entries. The list goes on. A lot of stuff doesn't get 
used heavily and probably doesn't get tested heavily, either. You just kinda 
have to work around it or limit your software to specific machines that you've 
tested. I'm sure it will get better over time.
On Wed, Oct 8, 2014 at 5:43 PM, J. E.  wrote:

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(
handleBuffer[nGOPHandleIndex],
&gEfiGraphicsOutputProtocolGuid,
(VOID **)&(GraphicsOutput));

The PC that returns black pixels has 2 total handles.
If I choose the 1st handle, there is no graphics output at all. It stays on the 
console text screen.
If I choose the 2nd handle, there is graphics output, but 
BltLibVideoToBltBuffer returns black pixels.

So I am definitely using the correct handle for GOP graphics.

I was thinking maybe the BlitLib was using the 1st handle instead of the 2nd 
handle, but I couldn't find a way to set the handle index in BlitLib. Even if 
it was using the 1st handle, wouldn't I see bits of ASCII characters in the 
returned blit from the console? I see no text, just black.
BltLibVideoToBltBuffer also has no option to set the handle.

So it seems the BIOS in question simply hasn't implemented proper 
Screen-to-Blit functionality.
I suppose it's not a feature many people would use so it would be easy for some 
BIOS developers to forget to test/implement this function.

Thanks.

Date: Wed, 8 Oct 2014 12:27:18 -0500
From: tcrog...@gmail.com
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] BltLibVideoToBltBuffer returns black pixels

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 this 
handle to get the GOP instance.
On Wed, Oct 8, 2014 at 11:17 AM, Rafael Machado 
 wrote:
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 to the active device.
To check this I used the Edid protocol.
Thanks and RegardsRafael R. Machado

2014-10-03 3:15 GMT-03:00 J. E. :

BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work fine, but 
a select few return black pixels, no errors. EFI_STATUS = EFI_SUCCESS.

If BltLibVideoToBltBuffer returns black pixels does that mean the 
hardware/firmware doesn't support screen-to-buffer functionality?
I assume this is because someone didnt test the function or feel the need to 
implement the function in the BIOS code or GOP driver, rather than a GOP handle 
issue.

--

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer

Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports

Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper

Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___

edk2-devel mailing list

edk2-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/edk2-devel

--

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer

Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports

Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper

Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___

edk2-devel mailing list

edk2-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread Thomas Rognon

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 improperly formatted boot entries. The list goes on. A lot of
stuff doesn't get used heavily and probably doesn't get tested heavily,
either. You just kinda have to work around it or limit your software to
specific machines that you've tested. I'm sure it will get better over time.

On Wed, Oct 8, 2014 at 5:43 PM, J. E.  wrote:

> 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(
> handleBuffer[nGOPHandleIndex],
> &gEfiGraphicsOutputProtocolGuid,
> (VOID **)&(GraphicsOutput));
>
> The PC that returns black pixels has *2 total handles*.
> If I choose the *1st handle*, there is no graphics output at all. It
> stays on the console text screen.
> If I choose the *2nd handle*, there is graphics output, but
> BltLibVideoToBltBuffer returns black pixels.
>
> So I am definitely using the correct handle for GOP graphics.
>
> I was thinking maybe the BlitLib was using the 1st handle instead of the
> 2nd handle, but I couldn't find a way to set the handle index in BlitLib.
> Even if it was using the 1st handle, wouldn't I see bits of ASCII
> characters in the returned blit from the console? I see no text, just black.
> BltLibVideoToBltBuffer also has no option to set the handle.
>
> So it seems the BIOS in question simply hasn't implemented proper
> Screen-to-Blit functionality.
> I suppose it's not a feature many people would use so it would be easy for
> some BIOS developers to forget to test/implement this function.
>
> Thanks.
>
> --
> Date: Wed, 8 Oct 2014 12:27:18 -0500
> From: tcrog...@gmail.com
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] BltLibVideoToBltBuffer returns black pixels
>
>
> 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 this handle to get the GOP instance.
>
> On Wed, Oct 8, 2014 at 11:17 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
> 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 to the active device.
>
> To check this I used the Edid protocol.
>
> Thanks and Regards
> Rafael R. Machado
>
>
> 2014-10-03 3:15 GMT-03:00 J. E. :
>
> BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work
> fine, but a select few return black pixels, no errors. EFI_STATUS =
> EFI_SUCCESS.
>
> If BltLibVideoToBltBuffer returns black pixels does that mean the
> hardware/firmware doesn't support screen-to-buffer functionality?
> I assume this is because someone didnt test the function or feel the need
> to implement the function in the BIOS code or GOP driver, rather than a GOP
> handle issue.
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> --
> Meet PCI DSS 3.0 Compl

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread J. E.

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 ? 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 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(
handleBuffer[nGOPHandleIndex],
&gEfiGraphicsOutputProtocolGuid,
(VOID **)&(GraphicsOutput));

The PC that returns black pixels has 2 total handles.
If I choose the 1st handle, there is no graphics output at all. It stays on the 
console text screen.
If I choose the 2nd handle, there is graphics output, but 
BltLibVideoToBltBuffer returns black pixels.

So I am definitely using the correct handle for GOP graphics.

I was thinking maybe the BlitLib was using the 1st handle instead of the 2nd 
handle, but I couldn't find a way to set the handle index in BlitLib. Even if 
it was using the 1st handle, wouldn't I see bits of ASCII characters in the 
returned blit from the console? I see no text, just black.
BltLibVideoToBltBuffer also has no option to set the handle.

So it seems the BIOS in question simply hasn't implemented proper 
Screen-to-Blit functionality.
I suppose it's not a feature many people would use so it would be easy for some 
BIOS developers to forget to test/implement this function.

Thanks.

Date: Wed, 8 Oct 2014 12:27:18 -0500
From: tcrog...@gmail.com
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] BltLibVideoToBltBuffer returns black pixels

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 this 
handle to get the GOP instance.
On Wed, Oct 8, 2014 at 11:17 AM, Rafael Machado 
 wrote:
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 to the active device.
To check this I used the Edid protocol.
Thanks and RegardsRafael R. Machado

2014-10-03 3:15 GMT-03:00 J. E. :

BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work fine, but 
a select few return black pixels, no errors. EFI_STATUS = EFI_SUCCESS.

If BltLibVideoToBltBuffer returns black pixels does that mean the 
hardware/firmware doesn't support screen-to-buffer functionality?
I assume this is because someone didnt test the function or feel the need to 
implement the function in the BIOS code or GOP driver, rather than a GOP handle 
issue.

--

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer

Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports

Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper

Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___

edk2-devel mailing list

edk2-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/edk2-devel

--

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer

Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports

Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper

Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___

edk2-devel mailing list

edk2-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-de

Re: [edk2] DynamicEx and FeatureFlag

2014-10-08 Thread Gao, Liming

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 file. Another solution is to introduce new 
PCD for DynamicEx purpose.

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, October 09, 2014 12:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DynamicEx and FeatureFlag

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, most of the time, will never be used, but will still be in the PCD 
database. 90% of the time, this PCD would be FeatureFlag. That means that 90% 
of the time I would have an unused DynamicEx PCD in the PCD database.

Tim

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, October 08, 2014 2:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DynamicEx and FeatureFlag

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: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, October 01, 2014 2:23 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] DynamicEx and FeatureFlag

Currently the flag PcdDxeIplSwitchToLongMode is declared as storage type 
PcdFeatureFlag.

But we tried to change it to DynamicEx. Ok, that works great. We changed the 
.dec file to say [PcdDynamicEx]. No problem.

But then we tried to make it selectable by .dsc by making it [PcdFeatureFlag, 
PcdDynamicEx] in the .dec file.

Then we get this error:

"PcdsFeatureFlag must not be in the same section of other types of PCD"
While I understand that there are cases where feature-flag PCDs must be 
resolved during the build process, this is not always the case and I would 
rather I get the error when I try to use the non-feature-flag PCD in the wrong 
place. Do I really have to change this to PcdFixedAtBuild?

Tim
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] UDK2014.SP1 maintenance - Re: edk2[16182] Sync patch r16181 from main trunk.

2014-10-08 Thread Fan, Jeff

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 or to be 
synced to branch) and to reduce the revision number increasing, we shall 
check-in a serial of patches together.
One example in MdeModulePkg as blow:
  Sync patches r14006, r14034 and r14035 from main trunk.
  1. Base on the value type to get the value for default opcode.
  2. Base on the type field to generate numeric opcode.
  3. Base on the type field to generate oneof opcode.
We already provided enough original patches information. If the git developer 
wants for details of some patch, he/she could use get the whole log body 
instead of from the summary log. Do you any better suggestion on it?

Why we delete the BaseTools and copy the updated BaseTools from main trunk is 
to try best to keep original log information from main trunk. You could see the 
log of BaseTools on branches for it.

Thanks!
Jeff

-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Tuesday, September 30, 2014 6:50 AM
To: edk2-devel@lists.sourceforge.net; Fan, Jeff
Subject: UDK2014.SP1 maintenance - Re: edk2[16182] Sync patch r16181 from main 
trunk.

Just wanted to note that git cherry-pick would make this type of maintenance 
easier, and would produce a more useful result is the branch history. (You'd 
see the original patch+message rather than 'sync patch r#...')

r16182 | Sync patch r16181 from main trunk.
r16180 | Sync patch r16179 from main trunk.

===

I don't think it is a good idea to update the branch packages by deleting and 
copying newer versions. This means if anyone checks out r16176, they will have 
an unusable tree. Normally you'd want to avoid that so a tree could be bisected 
to locate the source of some breakage.

Once again, I think this is something where git cherry-pick could produce a 
more useful result by having each patch appear individually on the branch's 
history.

But, lacking git, perhaps creating a patch with svn and applying it to the 
branch would allow you to sync in the new changes from the main branch. 
(Without having to delete and copy.)

r16177 | Copy BaseTools r16160 to UDK2014.SP1 Branch.
r16176 | Delete BaseTools from UDK2014.SP1 Branch.

-Jordan

===

r16175 | Copy ShellBinPkg r16166 to UDK2014.SP1 Branch.
r16174 | Copy ShellPkg r16163 to UDK2014.SP1 Branch.
r16173 | Delete ShellPkg and ShellBinPkg from UDK2014.SP1 Branch.
r16164 | Sync patch r16128 from main trunk.
r16151 | Correct the convert hex string to decimal value logic.
r16130 | Sync patch r16129 from main trunk.
r16119 | Create UDK2014.SP1 BaseTools branch based on revision 16114
r16118 | Create UDK2014.SP1 BaseTools branch based on revision 16114
r16117 | Remove UDK2014.SP1 BaseTools branch.
r16111 | Create UDK2014.SP1 branch

On Sat, Sep 27, 2014 at 6:15 PM,   wrote:
> Revision: 16182
>   http://sourceforge.net/p/edk2/code/16182
> Author:   vanjeff
> Date: 2014-09-28 01:15:46 + (Sun, 28 Sep 2014)
> Log Message:
> ---
> Sync patch r16181 from main trunk.
> Fix an issue on FixedMtreProgramming - AND/OR mask incorrect.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
>
> Revision Links:
> --
> http://sourceforge.net/p/edk2/code/16181
>
> Modified Paths:
> --
> branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c
>
> Modified: 
> branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c
> ===
> --- branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c
> 2014-09-28 01:07:13 UTC (rev 16181)
> +++ branches/UDK2014.SP1/IntelFspPkg/Library/BaseCacheLib/CacheLib.c
> 2014-09-28 01:15:46 UTC (rev 16182)
> @@ -381,7 +381,7 @@
>  *Len -= mFixedMtrrTable[MsrNum].Length;
>  *Base += mFixedMtrrTable[MsrNum].Length;
>}
> -  TempQword = AsmReadMsr64 (mFixedMtrrTable[MsrNum].Msr) & 
> (~ClearMask | OrMask);
> +  TempQword = (AsmReadMsr64 (mFixedMtrrTable[MsrNum].Msr) & 
> + (~ClearMask)) | OrMask;
>AsmWriteMsr64 (mFixedMtrrTable[MsrNum].Msr, TempQword);
>
>return EFI_SUCCESS;
>
>
> --
>  Meet PCI DSS 3.0 Compliance Requirements with EventLog 
> Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI 
> DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download 
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with 
> EventLog Analyzer 
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.
> clktrk ___
> edk2-commits mailing list
> edk2-comm...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-commits
---

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread Rafael Machado

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 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(
> handleBuffer[nGOPHandleIndex],
> &gEfiGraphicsOutputProtocolGuid,
> (VOID **)&(GraphicsOutput));
>
> The PC that returns black pixels has *2 total handles*.
> If I choose the *1st handle*, there is no graphics output at all. It
> stays on the console text screen.
> If I choose the *2nd handle*, there is graphics output, but
> BltLibVideoToBltBuffer returns black pixels.
>
> So I am definitely using the correct handle for GOP graphics.
>
> I was thinking maybe the BlitLib was using the 1st handle instead of the
> 2nd handle, but I couldn't find a way to set the handle index in BlitLib.
> Even if it was using the 1st handle, wouldn't I see bits of ASCII
> characters in the returned blit from the console? I see no text, just black.
> BltLibVideoToBltBuffer also has no option to set the handle.
>
> So it seems the BIOS in question simply hasn't implemented proper
> Screen-to-Blit functionality.
> I suppose it's not a feature many people would use so it would be easy for
> some BIOS developers to forget to test/implement this function.
>
> Thanks.
>
> --
> Date: Wed, 8 Oct 2014 12:27:18 -0500
> From: tcrog...@gmail.com
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] BltLibVideoToBltBuffer returns black pixels
>
>
> 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 this handle to get the GOP instance.
>
> On Wed, Oct 8, 2014 at 11:17 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
> 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 to the active device.
>
> To check this I used the Edid protocol.
>
> Thanks and Regards
> Rafael R. Machado
>
>
> 2014-10-03 3:15 GMT-03:00 J. E. :
>
> BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work
> fine, but a select few return black pixels, no errors. EFI_STATUS =
> EFI_SUCCESS.
>
> If BltLibVideoToBltBuffer returns black pixels does that mean the
> hardware/firmware doesn't support screen-to-buffer functionality?
> I assume this is because someone didnt test the function or feel the need
> to implement the function in the BIOS code or GOP driver, rather than a GOP
> handle issue.
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI
> DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you
> Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI
> DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___ edk2-devel mailing list
> edk2-de

Re: [edk2] Why does the SMM_CORE instance of the SmmServicesTableLib not implement InSmm()?

2014-10-08 Thread Gao, Liming

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 SmmServicesTableLib not 
implement InSmm()?

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 to determine if the driver is executing in

  System Management Mode(SMM).

  This function returns TRUE if the driver is executing in SMM and FALSE if the

  driver is not executing in SMM.

  @retval  TRUE  The driver is executing in System Management Mode (SMM).

  @retval  FALSE The driver is not executing in System Management Mode (SMM).

**/

BOOLEAN

EFIAPI

InSmm (

  VOID

  );

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.c

BOOLEAN

EFIAPI

InSmm (

  VOID

  )

{

  BOOLEAN  InSmm;

  //

  // Check to see if we are already in SMM

  //

  mInternalSmmBase2->InSmm (mInternalSmmBase2, &InSmm);

  return InSmm;

}

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.c

EFI_SMM_SYSTEM_TABLE2 *gSmst = NULL;

extern EFI_SMM_SYSTEM_TABLE2  gSmmCoreSmst;

/**

  The constructor function caches the pointer of SMM Services Table.

  @param  ImageHandle   The firmware allocated handle for the EFI image.

  @param  SystemTable   A pointer to the EFI System Table.

  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.

**/

EFI_STATUS

EFIAPI

SmmCoreSmmServicesTableLibConstructor (

  IN EFI_HANDLEImageHandle,

  IN EFI_SYSTEM_TABLE  *SystemTable

  )

{

  gSmst = &gSmmCoreSmst;

  return EFI_SUCCESS;

}

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Why does the SMM_CORE instance of the SmmServicesTableLib not implement InSmm()?

2014-10-08 Thread Andrew Fish

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 to determine if the driver is executing in 
  System Management Mode(SMM).

  This function returns TRUE if the driver is executing in SMM and FALSE if the 
  driver is not executing in SMM.

  @retval  TRUE  The driver is executing in System Management Mode (SMM).
  @retval  FALSE The driver is not executing in System Management Mode (SMM). 

**/
BOOLEAN
EFIAPI
InSmm (
  VOID
  );

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.c
BOOLEAN
EFIAPI
InSmm (
  VOID
  )
{
  BOOLEAN  InSmm;

  //
  // Check to see if we are already in SMM
  //
  mInternalSmmBase2->InSmm (mInternalSmmBase2, &InSmm);
  return InSmm;
}

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.c

EFI_SMM_SYSTEM_TABLE2 *gSmst = NULL;
extern EFI_SMM_SYSTEM_TABLE2  gSmmCoreSmst;

/**
  The constructor function caches the pointer of SMM Services Table.

  @param  ImageHandle   The firmware allocated handle for the EFI image.
  @param  SystemTable   A pointer to the EFI System Table.

  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.

**/
EFI_STATUS
EFIAPI
SmmCoreSmmServicesTableLibConstructor (
  IN EFI_HANDLEImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  gSmst = &gSmmCoreSmst;
  return EFI_SUCCESS;
}

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] consume a protocol from a different package

2014-10-08 Thread Andrew Fish


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 copy files from one package to another?

No you list the packages you depend on in the [Packages] section of your INF 
file. This will set your include paths to the public include paths of these 
packages, and give you access to Protocols and GUIDs defined in those packages. 

Thanks,

Andrew Fish

> Thank for the help.
> MiKL~
>  
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] consume a protocol from a different package

2014-10-08 Thread Toto Lebolo

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 help.
MiKL~--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread J. E.

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(
handleBuffer[nGOPHandleIndex],
&gEfiGraphicsOutputProtocolGuid,
(VOID **)&(GraphicsOutput));

The PC that returns black pixels has 2 total handles.
If I choose the 1st handle, there is no graphics output at all. It stays on the 
console text screen.
If I choose the 2nd handle, there is graphics output, but 
BltLibVideoToBltBuffer returns black pixels.

So I am definitely using the correct handle for GOP graphics.

I was thinking maybe the BlitLib was using the 1st handle instead of the 2nd 
handle, but I couldn't find a way to set the handle index in BlitLib. Even if 
it was using the 1st handle, wouldn't I see bits of ASCII characters in the 
returned blit from the console? I see no text, just black.
BltLibVideoToBltBuffer also has no option to set the handle.

So it seems the BIOS in question simply hasn't implemented proper 
Screen-to-Blit functionality.
I suppose it's not a feature many people would use so it would be easy for some 
BIOS developers to forget to test/implement this function.

Thanks.

Date: Wed, 8 Oct 2014 12:27:18 -0500
From: tcrog...@gmail.com
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] BltLibVideoToBltBuffer returns black pixels

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 this 
handle to get the GOP instance.
On Wed, Oct 8, 2014 at 11:17 AM, Rafael Machado 
 wrote:
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 to the active device.
To check this I used the Edid protocol.
Thanks and RegardsRafael R. Machado

2014-10-03 3:15 GMT-03:00 J. E. :



BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work fine, but 
a select few return black pixels, no errors. EFI_STATUS = EFI_SUCCESS.

If BltLibVideoToBltBuffer returns black pixels does that mean the 
hardware/firmware doesn't support screen-to-buffer functionality?
I assume this is because someone didnt test the function or feel the need to 
implement the function in the BIOS code or GOP driver, rather than a GOP handle 
issue.
  

--

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer

Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports

Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper

Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___

edk2-devel mailing list

edk2-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/edk2-devel





--

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer

Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports

Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper

Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer

http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___

edk2-devel mailing list

edk2-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/edk2-devel





--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel 
  --
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread Rafael Machado

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 path gives you the handle to GOP that ConOut is using. Just
> OpenProtocol() with this handle to get the GOP instance.
>
> On Wed, Oct 8, 2014 at 11:17 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
>> 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 to the active device.
>>
>> To check this I used the Edid protocol.
>>
>> Thanks and Regards
>> Rafael R. Machado
>>
>>
>> 2014-10-03 3:15 GMT-03:00 J. E. :
>>
>>> BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work
>>> fine, but a select few return black pixels, no errors. EFI_STATUS =
>>> EFI_SUCCESS.
>>>
>>> If BltLibVideoToBltBuffer returns black pixels does that mean the
>>> hardware/firmware doesn't support screen-to-buffer functionality?
>>> I assume this is because someone didnt test the function or feel the
>>> need to implement the function in the BIOS code or GOP driver, rather than
>>> a GOP handle issue.
>>>
>>>
>>> --
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>>
>>>
>>
>>
>> --
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Add .gitignore

2014-10-08 Thread Leif Lindholm

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

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

2014-10-08 Thread Jordan Justen

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 bridge ID (duplicate code)
>> >> >  * Used for Sec, PeiCore, Pei drivers and DxeCore
>> >> > DxeTimerLib:
>> >> >  * Reads dynamic PCD in constructor
>> >> >  * Used for everything else
>> >>
>> >> I'm fine with your proposal. The tradeoff is of course DxeCore, and that
>> >> this way the common bits of AcpiTimerLib.c will have to be split out
>> >> into a third .c file, potentially requiring some refactoring. Example:
>> >> OvmfPkg/Library/QemuFwCfgLib.
>> >>
>> >> [...]
>> >>
>> >> Let's go with BaseTimerLib / DxeTimerLib.
>>
>> [...]
>>
>> Can you make three versions?
>> OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
>> OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
>> OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>>
>> Set BaseAcpiTimerLib.inf as default under:
>> [LibraryClasses]
>>
>> Use BaseRomAcpiTimerLib.inf for:
>> [LibraryClasses.common.SEC]
>>
>> Use DxeAcpiTimerLib.inf version for these:
>> [LibraryClasses.common.UEFI_DRIVER]
>> [LibraryClasses.common.DXE_DRIVER]
>> [LibraryClasses.common.UEFI_APPLICATION]
>>
>> BaseRomAcpiTimerLib.inf
>>  * Shares a common file with BaseAcpiTimerLib.inf for reading the host
>> bus to determine the system type.
>>  * Reads host bus every time, and doesn't set any global variables
>>
>> BaseAcpiTimerLib.inf
>>  * Shares a common file with BaseAcpiTimerLib.inf for reading the host
>> bus to determine the system type.
>>  * Sets a global module variable that allows the library to not have
>> to read the host bus id every time.
>>
>> DxeAcpiTimerLib.inf
>>  * Read the PCD once and save it in a global module variable
>>
>> PlatformPei should also read the host bus id, and set a PCD to allow
>> DxeAcpiTimerLib.inf to work.
>
> My plan was to tackle splitting out AcpiTimerLib first, then learn
> about and understand how PCDs work in practice :)
>
> The first bit (how to create multiple instances of a library, and
> connect instances to various stages like PEIM, DXE_CORE, etc) is done,
> and I'm wondering whether the second bit (using PCDs) is actually worth
> the complexity of adding a *third* version of AcpiTimerLib.
>
> Right now, BaseAcpiTimerLib and DxeAcpiTimerLib share everything
> except for the constructor and the GetTimerTick method.
>
> The "Base" version queries the host bridge indiscriminately, both in
> the constructor and in the GetTimerTick function. In my tests, the
> GetTimerTick function never did get called (maybe because I'm not
> using SEC and/or the debugger?)
>
> The "Dxe" version queries the host bridge in the constructor, and
> computes the IO address of the ACPI timer; In the GetTimerTick method,
> we just do an IoRead32 on the cached ACPI timer IO address.
>
> So, to decide how I feel about further splitting out DxeAcpiTimerLib
> into a version which does use PCDs and another version which does not,
> I added some DEBUG statements to track every time the host bridge
> gets queried right now, and here's what I got:
>
>
> PlatformPei:MiscInitialization()
> Base:AcpiTimerLibConstructor()  (PEIM)
> Dxe:AcpiTimerLibConstructor()   (DXE_CORE)
> Dxe:AcpiTimerLibConstructor()   (DXE_RUNTIME_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_RUNTIME_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_RUNTIME_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_RUNTIME_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (UEFI_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (UEFI_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (UEFI_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (UEFI_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (DXE_DRIVER)
> Dxe:AcpiTimerLibConstructor()   (UEFI_DRIVER)
> BdsPlatform:PciInitialization()
> BdsPlatform:AcpiInitialization()
> Dxe:AcpiTimerLibConstructor()   (DXE_DRIVER)
>
>
> I guess adding PCDs would save us from querying the host bridge about
> half the time, at the expense of adding a third version of
> AcpiTimerLib. I'm inclined to think the added complexity isn't worth
> it, but then again I'm new at this and I may be missing some other
> set of criteria which would make the whole thing worth it regardless.

Regarding IS_Q35_HOSTBRIDGE (or, is it IS_PLATFORM_Q35 now?), I see
these negatives:
 * Doesn't look like EDK II code
 * Reads PCI registers inside a macro
 * It seems very focused: "Is this Q35?"

Laszlo had another suggestion, but it add a new library interface. So,
it seems about as complex as my suggestion.

This idea m

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread 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 path gives you the handle to GOP that ConOut is using. Just
OpenProtocol() with this handle to get the GOP instance.

On Wed, Oct 8, 2014 at 11:17 AM, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> wrote:

> 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 to the active device.
>
> To check this I used the Edid protocol.
>
> Thanks and Regards
> Rafael R. Machado
>
>
> 2014-10-03 3:15 GMT-03:00 J. E. :
>
>> BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work
>> fine, but a select few return black pixels, no errors. EFI_STATUS =
>> EFI_SUCCESS.
>>
>> If BltLibVideoToBltBuffer returns black pixels does that mean the
>> hardware/firmware doesn't support screen-to-buffer functionality?
>> I assume this is because someone didnt test the function or feel the need
>> to implement the function in the BIOS code or GOP driver, rather than a GOP
>> handle issue.
>>
>>
>> --
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Add .gitignore

2014-10-08 Thread Laszlo Ersek

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 up "git status" output.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ryan Harkin 
> [removed Linaro-specific bits]
> Signed-off-by: Leif Lindholm 
> ---
>  .gitignore |   20 
>  1 file changed, 20 insertions(+)
>  create mode 100644 .gitignore
> 
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 000..8b6147b
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,20 @@
> +*.d
> +*.o
> +*.pyc
> +BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
> +BaseTools/Source/C/VfrCompile/EfiVfrParser.h
> +BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
> +BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
> +BaseTools/Source/C/VfrCompile/VfrLexer.cpp
> +BaseTools/Source/C/VfrCompile/VfrLexer.h
> +BaseTools/Source/C/VfrCompile/VfrParser.dlg
> +BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
> +BaseTools/Source/C/VfrCompile/VfrTokens.h
> +BaseTools/Source/C/bin/
> +BaseTools/Source/C/libs/
> +Build/
> +Conf/.cache/
> +Conf/BuildEnv.sh
> +Conf/build_rule.txt
> +Conf/target.txt
> +Conf/tools_def.txt
> 

Please consider adding "tags" as well.

Thanks
Laszlo

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

2014-10-08 Thread Rafael Machado

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 to the active device.

To check this I used the Edid protocol.

Thanks and Regards
Rafael R. Machado


2014-10-03 3:15 GMT-03:00 J. E. :

> BltLibVideoToBltBuffer seems to be unreliable on some PC's. Most work
> fine, but a select few return black pixels, no errors. EFI_STATUS =
> EFI_SUCCESS.
>
> If BltLibVideoToBltBuffer returns black pixels does that mean the
> hardware/firmware doesn't support screen-to-buffer functionality?
> I assume this is because someone didnt test the function or feel the need
> to implement the function in the BIOS code or GOP driver, rather than a GOP
> handle issue.
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] DynamicEx and FeatureFlag

2014-10-08 Thread Tim Lewis

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, most of the time, will never be used, but will still be in the PCD 
database. 90% of the time, this PCD would be FeatureFlag. That means that 90% 
of the time I would have an unused DynamicEx PCD in the PCD database.

Tim

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, October 08, 2014 2:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DynamicEx and FeatureFlag

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: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, October 01, 2014 2:23 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] DynamicEx and FeatureFlag

Currently the flag PcdDxeIplSwitchToLongMode is declared as storage type 
PcdFeatureFlag.

But we tried to change it to DynamicEx. Ok, that works great. We changed the 
.dec file to say [PcdDynamicEx]. No problem.

But then we tried to make it selectable by .dsc by making it [PcdFeatureFlag, 
PcdDynamicEx] in the .dec file.

Then we get this error:

"PcdsFeatureFlag must not be in the same section of other types of PCD"
While I understand that there are cases where feature-flag PCDs must be 
resolved during the build process, this is not always the case and I would 
rather I get the error when I try to use the non-feature-flag PCD in the wrong 
place. Do I really have to change this to PcdFixedAtBuild?

Tim
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] CoreLoadImage output bug?

2014-10-08 Thread Deric Cole

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 if). We don't 
want this function to use *ImageHandle in the performance code in case of 
failure, since it is not to be modified in that case, and we don't know what 
value the caller left there.

Deric Cole
Sr. Customer Engineer
Phoenix Technologies Ltd.

From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Wednesday, October 08, 2014 3:01 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] CoreLoadImage output bug?

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   *SourceBuffer   OPTIONAL,
  IN UINTN  SourceSize,
  OUT EFI_HANDLE*ImageHandle
  )

--
It means ImageHandle will be output parameter?
But the procedure ended with
-
  if (!EFI_ERROR (Status)) {
//
// ImageHandle will be valid only Status is success.
//
Handle = *ImageHandle;
  }

  PERF_START (Handle, "LoadImage:", NULL, Tick);
  PERF_END (Handle, "LoadImage:", NULL, 0);

  return Status;
}

-
Should it be reversed?
*ImageHandle = Handle;

Sergey


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] Add .gitignore

2014-10-08 Thread Leif Lindholm

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 Contribution Agreement 1.0
Signed-off-by: Ryan Harkin 
[removed Linaro-specific bits]
Signed-off-by: Leif Lindholm 
---
 .gitignore |   20 
 1 file changed, 20 insertions(+)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..8b6147b
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,20 @@
+*.d
+*.o
+*.pyc
+BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
+BaseTools/Source/C/VfrCompile/EfiVfrParser.h
+BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
+BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
+BaseTools/Source/C/VfrCompile/VfrLexer.cpp
+BaseTools/Source/C/VfrCompile/VfrLexer.h
+BaseTools/Source/C/VfrCompile/VfrParser.dlg
+BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
+BaseTools/Source/C/VfrCompile/VfrTokens.h
+BaseTools/Source/C/bin/
+BaseTools/Source/C/libs/
+Build/
+Conf/.cache/
+Conf/BuildEnv.sh
+Conf/build_rule.txt
+Conf/target.txt
+Conf/tools_def.txt
-- 
1.7.10.4


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] ShellPkg: Add a typecast to 'BOOLEAN' to avoid build failure in VS2005.

2014-10-08 Thread Carsey, Jaben

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 patch? The patch adds a typecast to 'BOOLEAN' to 
avoid build failure in VS2005.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin mailto:shumin@intel.com>>

Thanks,
Shumin

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVExpressPkg: enable specifying firmware version string on build

2014-10-08 Thread Leif Lindholm

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 version string on
 build

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 insertions(+)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
index fb2efd5..c97aa58 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
@@ -256,6 +256,9 @@
 
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Versatile Express"
+!ifdef $(FIRMWARE_VER)
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)"
+!endif
 
   gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"VExpress"
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
-- 
1.7.10.4


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] ArmVExpressPkg: enable specifying firmware version string on build

2014-10-08 Thread Leif Lindholm

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 insertions(+)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
index e12d5cd..08b6817 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
@@ -259,6 +259,9 @@
 
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Versatile Express"
+!ifdef $(FIRMWARE_VER)
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)"
+!endif
 
   gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"VExpress"
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
-- 
1.7.10.4


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] EFI_ISA_IO_PROTOCOL / EFI_SIO_PROTOCOL

2014-10-08 Thread TigerLiu

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 Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] CoreLoadImage output bug?

2014-10-08 Thread Sergey Isakov

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   *SourceBuffer   OPTIONAL,
  IN UINTN  SourceSize,
  OUT EFI_HANDLE*ImageHandle
  )

--
It means ImageHandle will be output parameter?
But the procedure ended with
-
  if (!EFI_ERROR (Status)) {
//
// ImageHandle will be valid only Status is success. 
//
Handle = *ImageHandle;
  }

  PERF_START (Handle, "LoadImage:", NULL, Tick);
  PERF_END (Handle, "LoadImage:", NULL, 0);

  return Status;
}

-
Should it be reversed?
*ImageHandle = Handle;

Sergey--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] DynamicEx and FeatureFlag

2014-10-08 Thread Gao, Liming

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: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, October 01, 2014 2:23 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] DynamicEx and FeatureFlag

Currently the flag PcdDxeIplSwitchToLongMode is declared as storage type 
PcdFeatureFlag.

But we tried to change it to DynamicEx. Ok, that works great. We changed the 
.dec file to say [PcdDynamicEx]. No problem.

But then we tried to make it selectable by .dsc by making it [PcdFeatureFlag, 
PcdDynamicEx] in the .dec file.

Then we get this error:

"PcdsFeatureFlag must not be in the same section of other types of PCD"

While I understand that there are cases where feature-flag PCDs must be 
resolved during the build process, this is not always the case and I would 
rather I get the error when I try to use the non-feature-flag PCD in the wrong 
place. Do I really have to change this to PcdFixedAtBuild?

Tim
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Action opcode should not have TextTwo part

2014-10-08 Thread Gao, Liming

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= STRING_TOKEN(STR_CONTINUE_PROMPT),

  text= STRING_TOKEN(STR_NULL_STRING),  // TextTwo

  flags   = INTERACTIVE,

  key = FRONT_PAGE_KEY_CONTINUE;



The warning message doesn't point to the source VFR file, because VfrCompiler 
tool doesn't support line format in GCC preprocess file. VfrCompiler could be 
enhanced.



Thanks

Liming

-Original Message-
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Friday, October 03, 2014 4:31 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Action opcode should not have TextTwo part



Hi sirs,

What is means this warning:

VfrCompile...

Bm.i(110): WARNING: 0x0002

: Action opcode should not have TextTwo part Same in 
FrontPageVfr.i(40), FE.i(106) (112, 147, 153) I see no correlation between 
these digits (line numbers?) with real lines.

BaseTools and Vfr sources are most recent.



Sergey



--

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 
3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready 
for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 
Requirement 10 and 11.5 with EventLog Analyzer 
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

___

edk2-devel mailing list

edk2-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BaseTools: Add MINGW tool chain

2014-10-08 Thread Gao, Liming

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 BaseLib, MINGW output is COFF format. So, NASM_FLAGS should 
be -f win32 and -f win64. I just try them and pass build. 

  For tool_def.txt, on MAKE and RC path, could we directly use make and objcopy 
from MINGW like the native GCC tool chain? If so, MINGW is a standalone tool 
chain. 
+*_MINGW_*_MAKE_PATH  = ENV(MS_MISC_BIN)\nmake.exe
+*_MINGW_IA32_RC_PATH = ENV(MS_MISC_BIN)\rc.exe

Thanks
Liming
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org] 
Sent: Saturday, October 04, 2014 11:42 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] BaseTools: Add MINGW tool chain

Nikolai Saoukh [mailto:n...@otdel-1.org] wrote:

]I was under impression that mingw-win64 can be used for X64 AND IA32 builds.

You are right. Thanks for pointing that out. The revised email and patch 
follows.
I also added the requirement for an environment variable pointing to Microsoft 
nmake.exe and rc.exe. Still needed is nasm.exe and iasl.exe, but these work the 
same as with Microsoft tool chains.
-- 

Here is a work in progress patch for those building X64 or IA32 targets from 
Windows. It allows building with gcc instead of a Microsoft compiler.
Building has been tested with Windows 7 x64 using MINGW archives from 
http://www.drangon.org/mingw/ or 
http://sourceforge.net/projects/mingw-w64-dgn/files/mingw-w64/

Unpack mingw-w64-bin-x86_64-20140425.7z and set environment variable
MINGW64 to its path. Also set environment variable MINGW32 to its path.
Set environment variable MS_MISC_BIN to a directory containing Microsoft 
nmake.exe and rc.exe. For example, the bin\x86 directory of DDK-7600:
http://www.microsoft.com/en-us/download/details.aspx?id=11800. 

Apply the patch then build using -t MINGW. It's that easy. No unix shell port 
is involved. Just build from a cmd.exe prompt as normal.
Because mingw requires no install or setup, your registry, path and other 
environment variables are unaffected.

The MINGW port of gcc brings C99 support to those using Windows to develop EDK2 
code. Wouldn't it be nice if one day UEFI could drop support for non-C99 
compilers so that C99 features could be used in the code? There is actually a 
lot of work to be done before gcc could replace Microsoft tools. One problem is 
that some UEFI source level debuggers understand only Microsoft debug 
information. Another problem is that right now gcc is producing bigger code. 
Getting gcc link time optimization working may solve this problem. Build speed 
with MINGW is not quite as fast as with Microsoft tools, but it is reasonable.
For example, a test of 18 builds that takes 523 seconds using VS2008 takes 694 
seconds using MINGW.

Index: BaseTools/Conf/tools_def.template 
===
--- BaseTools/Conf/tools_def.template   (revision 16195)
+++ BaseTools/Conf/tools_def.template   (working copy)
@@ -4815,6 +4815,103 @@
 
 

 #
+# Mingw GCC And Intel ACPI Compiler
+#
+
+#   MINGW- MINGW GCC
+#   ASL   - Intel ACPI Source Language Compiler (iasl.exe)
+*_MINGW_*_*_FAMILY   = GCC
+
+DEFINE MINGW_BINIA32 = ENV(MINGW32)\bin\
+DEFINE MINGW_BINX64  = ENV(MINGW64)\bin\
+
+*_MINGW_*_MAKE_PATH  = ENV(MS_MISC_BIN)\nmake.exe
+*_MINGW_*_ASL_PATH   = DEF(DEFAULT_WIN_ASL_BIN)
+*_MINGW_IA32_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pe  
--entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 
-Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map --image-base=0 --strip-all
+*_MINGW_X64_DLINK_FLAGS  = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pep 
--entry  $(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 
-Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map --image-base=0 --strip-all
+*_MINGW_IA32_ASLDLINK_FLAGS  = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pe  
--entry _ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) --strip-all
+*_MINGW_X64_ASLDLINK_FLAGS   = DEF(GCC_IA32_X64_DLINK_COMMON) -m i386pep 
--entry  ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) --strip-all
+
+*_MINGW_*_MAKE_FLAGS = /nologo
+*_MINGW_*_ASL_FLAGS  = DEF(DEFAULT_WIN_ASL_FLAGS)
+*_MINGW_*_ASL_OUTFLAGS   = DEF(DEFAULT_WIN_ASL_OUTFLAGS)
+
+##
+# IA32 definitions
+##
+*_MINGW_IA32_CC_PATH = DEF(MINGW_BINIA32)gcc
+*_MINGW_IA32_SLINK_PATH  = DEF(MINGW_BINIA32)ar
+*_MINGW_IA32_DLINK_PATH  = DEF(MINGW_BINIA32)ld
+*_MINGW_IA32_ASM_PATH= DEF(MINGW_BINIA32)gcc
+*_MINGW_IA32_PP_PATH = DEF(MINGW_BINIA32

Re: [edk2] DynamicEx and FeatureFlag

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] DynamicEx and FeatureFlag

Re: [edk2] UDK2014.SP1 maintenance - Re: edk2[16182] Sync patch r16181 from main trunk.

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] Why does the SMM_CORE instance of the SmmServicesTableLib not implement InSmm()?

[edk2] Why does the SMM_CORE instance of the SmmServicesTableLib not implement InSmm()?

Re: [edk2] consume a protocol from a different package

[edk2] consume a protocol from a different package

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] [PATCH] Add .gitignore

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] [PATCH] Add .gitignore

Re: [edk2] BltLibVideoToBltBuffer returns black pixels

Re: [edk2] DynamicEx and FeatureFlag

Re: [edk2] CoreLoadImage output bug?

[edk2] [PATCH] Add .gitignore

Re: [edk2] [Patch] ShellPkg: Add a typecast to 'BOOLEAN' to avoid build failure in VS2005.

Re: [edk2] [PATCH] ArmVExpressPkg: enable specifying firmware version string on build

[edk2] [PATCH] ArmVExpressPkg: enable specifying firmware version string on build

[edk2] EFI_ISA_IO_PROTOCOL / EFI_SIO_PROTOCOL

[edk2] CoreLoadImage output bug?

Re: [edk2] DynamicEx and FeatureFlag

Re: [edk2] Action opcode should not have TextTwo part

Re: [edk2] BaseTools: Add MINGW tool chain

30 matches

Site Navigation

Mail list logo

Footer information