date:20131203

Re: [edk2] Is there a reason that the AcpiSystemDescriptionTable protocol does not have a value for ACPI 5.0?

2013-12-03 Thread Tian, Hot

The definitions are from PI spec. Seems the latest PI spec hasn't been updated 
to add ACPI 5.0 definition.

Thanks,
Hot

From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, December 04, 2013 0:44
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Is there a reason that the AcpiSystemDescriptionTable protocol 
does not have a value for ACPI 5.0?

Is there a reason that the AcpiSystemDescriptionTable protocol does not have a 
value for ACPI 5.0?

>From 
>https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h

#define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)

#define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)

#define EFI_ACPI_TABLE_VERSION_2_0  (1 << 2)

#define EFI_ACPI_TABLE_VERSION_3_0  (1 << 3)

#define EFI_ACPI_TABLE_VERSION_4_0  (1 << 4)

Thanks,

Andrew Fish
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] SEC code support big.LITTLE tech?

2013-12-03 Thread TigerLiu

Hi, Oliver:
Does current ArmPlatformPackage's sec code support big.LITTLE tech?
Such as :
An ARM SOC --- with 4 Cores Cortex-A15, 4 Cores Cortex-A7

So, if sec code support big.LITTLE tech, how does it let one core as
boot strap cpu, others go into wfe(or other sleeping state)?

Best wishes,

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Getting PCD values for tools that post process the build.

2013-12-03 Thread Andrew Fish


On Dec 3, 2013, at 5:34 PM, Gao, Liming  wrote:

> Andrew:
>  You mean Build Report file. Build command has -y REPORTFILE and -Y 
> REPORTTYPE option to generate build text report file. You can just generate 
> PCD report, then parse report file to get PCD value. The command can be: 
> build -y Pcd_Log.txt -Y PCD
> 

That is what I prototyped, a Python script to extract a PCD value from the log 
file. I was thinking I might as well build the entire log file and place it in 
a build products location as part of the build. 

Thanks,

Andrew Fish

> Thanks
> Liming
> -Original Message-
> From: Andrew Fish [mailto:af...@apple.com] 
> Sent: Wednesday, December 04, 2013 3:19 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] Getting PCD values for tools that post process the build.
> 
> Is there a recommended solution to get PCD values for consumption in a post 
> build step?
> 
> The only thing I could think of is to post process the build log?
> 
> Thanks,
> 
> Andrew Fish
> 
> --
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 
> --
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Getting PCD values for tools that post process the build.

2013-12-03 Thread Gao, Liming

Andrew:
  You mean Build Report file. Build command has -y REPORTFILE and -Y REPORTTYPE 
option to generate build text report file. You can just generate PCD report, 
then parse report file to get PCD value. The command can be: build -y 
Pcd_Log.txt -Y PCD

Thanks
Liming
-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Wednesday, December 04, 2013 3:19 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Getting PCD values for tools that post process the build.

Is there a recommended solution to get PCD values for consumption in a post 
build step?

The only thing I could think of is to post process the build log?

Thanks,

Andrew Fish

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance affects 
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & 
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

2013-12-03 Thread Laszlo Ersek

On 12/04/13 01:57, Yao, Jiewen wrote:
> Hi Laszlo
> Your analysis below is exactly what the code implemented.
> Now I believe you and me have different understanding on PI specification, 
> not the UDK implementation. :-)
> 
> 
> "Normally this would be a violation of the protocol, because the pointer I'm 
> passing to BootScript->Write() doesn't point to runtime memory or ACPI NVS."
> Per my understanding, the word in UEFI/PI specification is to limit the 
> caller. So caller need follow UEFI/PI specification to make sure call the 
> function correctly.
> I do not believe callee need to do any check in this case. It is caller's 
> responsibility.
> You may also find some examples in UEFI spec, such as TPL. If caller did 
> wrong thing, system may crash.
> 
> 
> "But the implementation should save the pointer that I pass in, not the 
> pointed-to data."
> Again, since PI spec does not define format, an implementation can choose to 
> save pointer or save data.
> Personally, I cannot draw to the conclusion that we must save pointer based 
> on current PI specification.

The PI spec I have (Version 1.2.1) says in Vol 5, 8.7.1,

EFI_BOOT_SCRIPT_INFORMATION_OPCODE

  Summary

Store the pointer to the arbitrary information in the boot script
table. [...]

> My personal understanding for PI specification is to focus on data.
> Because if PI specification just need save pointer, there is no need to pass 
> InfomrationLength. This argument is not needed.

The InformationLength field makes sense in this case because it
describes how many bytes you can read after dereferencing the stored
pointer. The pointer identifies the base of an array in AcpiNVS or
runtime memory, and the InformationLength field describes the size.

> Anyway, your suggest on "save pointer" is another possible implementation for 
> Boot Script. You may add it in your own package and use the new one in your 
> modules.
> That is possible, since UDK package supports library override.
> 
> 
> All in all, since there is different understanding on PI specification, if 
> you want, I suggest we could discuss this topic in PIWG meeting - where we 
> discuss the PI specification.

Thanks for looking into this! I don't have strong feelings either way. I
was just surprised because the first opcode I added to the table was "do
nothing just show me something".

The current implementation makes perfect sense of course (one could
argue it makes *more* sense, because the boot script becomes
self-contained). I just perceive it to be different from the Summary
quoted above.

Thanks!
Laszlo

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] please clarify "PcdDxeIplSwitchToLongMode"

2013-12-03 Thread Yao, Jiewen

Hi Laszlo
"I'm asking because I'm now reaching the assembly code in 
"MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S" that would jump 
to the (real mode) OSPM waking vector, and it reboots the machine. I think that 
maybe the wrong routine is invoked, due to confusion around 
PcdDxeIplSwitchToLongMode."

OSPM waking vector mode is NOT related to PcdDxeIplSwitchToLongMode.
OSPM waking vector is defined by ACPI spec, and set by OS, and referred by BIOS.

PcdDxeIplSwitchToLongMode is only UDK internal implementation. It is not used 
by any OSPM.

Thank you
Yao Jiewen

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, December 04, 2013 5:56 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] please clarify "PcdDxeIplSwitchToLongMode"

Hi,

it's as if different parts of the code thought differently about 
PcdDxeIplSwitchToLongMode.

Interpretation #1:
- PcdDxeIplSwitchToLongMode means that we have to *switch* from 32-bit PEI to 
64-bit DXE. Emphasis on "switch", that is, "PEI and DXE have different bitness".

Interpretation #2:
- PcdDxeIplSwitchToLongMode means that DXE is 64-bit, independently of PEI 
bitness.

  PcdDxeIplSwitchToLongMode
PEI  DXE  Interp#1  Interp#2 result
32   32   0 0OK
32   64   1 1OK
64   64   0 1oops

I checked the documentation in MdeModulePkg/MdeModulePkg.dec, and I have no 
clue which interpretation it follows.

The picture is further complicated by "PcdDxeIplBuildPageTables" (added in SVN 
r12016. It seems to allow one to say (by setting it to FALSE), "64-bit PEI, 
64-bit DXE, but please don't rebuild page tables".

Now, in OVMF, the 32/32 platform DSC file sets PcdDxeIplSwitchToLongMode to 
FALSE. No difference between interp#1 and interp#2.

The 32/64 DSC file sets it to TRUE. Detto.

The 64/64 DSC file it to FALSE again, clearly following interp#1 -- "no 
switching needed".

Maybe, we should set this PCD to TRUE (ie. follow Interp#2), and turn off 
rebuilding the page tables by setting the newer PcdDxeIplBuildPageTables to 
FALSE. I have no clue. (We don't use this second PCD in OVMF, only EmulatorPkg 
and Nt32Pkg do -- they both set it to FALSE.)

If OVMF interprets PcdDxeIplSwitchToLongMode differently (==interp#1) from some 
other parts of the code (interp#2), well that has not been causing problems 
until now, apparently.

But now I'm looking at the S3 suspend/resume code, and it is full of comments 
that apparently *equate*

  PcdDxeIplSwitchToLongMode==FALSE

with

  DXE is 32-bit

Which corresponds to Interp#2.

I'm asking because I'm now reaching the assembly code in 
"MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S" that would jump 
to the (real mode) OSPM waking vector, and it reboots the machine. I think that 
maybe the wrong routine is invoked, due to confusion around 
PcdDxeIplSwitchToLongMode.

(The reboot happens when LRET pops RIP and CS from the stack. Apparently the 
idea behind this exercise is to stay/continue in the same ASM file, but change 
the CS. It doesn't work.)

Thanks!
Laszlo

--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

2013-12-03 Thread Yao, Jiewen

Hi Laszlo
Your analysis below is exactly what the code implemented.
Now I believe you and me have different understanding on PI specification, not 
the UDK implementation. :-)

"Normally this would be a violation of the protocol, because the pointer I'm 
passing to BootScript->Write() doesn't point to runtime memory or ACPI NVS."
Per my understanding, the word in UEFI/PI specification is to limit the caller. 
So caller need follow UEFI/PI specification to make sure call the function 
correctly.
I do not believe callee need to do any check in this case. It is caller's 
responsibility.
You may also find some examples in UEFI spec, such as TPL. If caller did wrong 
thing, system may crash.

"But the implementation should save the pointer that I pass in, not the 
pointed-to data."
Again, since PI spec does not define format, an implementation can choose to 
save pointer or save data.
Personally, I cannot draw to the conclusion that we must save pointer based on 
current PI specification.

My personal understanding for PI specification is to focus on data.
Because if PI specification just need save pointer, there is no need to pass 
InfomrationLength. This argument is not needed.

Anyway, your suggest on "save pointer" is another possible implementation for 
Boot Script. You may add it in your own package and use the new one in your 
modules.
That is possible, since UDK package supports library override.

All in all, since there is different understanding on PI specification, if you 
want, I suggest we could discuss this topic in PIWG meeting - where we discuss 
the PI specification.

Thank you
Yao Jiewen

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, December 04, 2013 3:51 AM
To: Yao, Jiewen
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Save State protocol violation in S3SaveState.c 
(MdeModulePkg)

Hi!

On 12/03/13 16:03, Yao, Jiewen wrote:
> Hi Laszlo

> "According to the PI spec, Information is a pointer pointing to 
> runtime memory or ACPI NVS, and the BootScript record will store the 
> pointer (ie. not the data pointed-to)."

> I agree with you on first part - According to the PI spec, Information 
> is a pointer pointing to runtime memory or ACPI NVS.

> And I hold different view on second part - the BootScript record will 
> store the pointer (ie. not the data pointed-to)

I disagree (and I tested it too). My example code goes like:

>   EFI_STATUS Status;
>   EFI_S3_SAVE_STATE_PROTOCOL *BootScript;
>   STATIC CONST UINT8 Info[] = { 0xDE, 0xAD, 0xBE, 0xEF };
>
>   Status = gBS->LocateProtocol (&gEfiS3SaveStateProtocolGuid, NULL,
>   (VOID **) &BootScript);
>   ASSERT_EFI_ERROR (Status);
>
>   //
>   // Despite the opcode documentation in the PI spec, the protocol
>   // implementation embeds a deep copy of the info in the boot script, rather
>   // than storing just a pointer to runtime or NVS storage.
>   //
>   Status = BootScript->Write(BootScript, EFI_BOOT_SCRIPT_INFORMATION_OPCODE,
>  (UINT32) sizeof Info,
>  (EFI_PHYSICAL_ADDRESS)(UINTN) &Info);
>   ASSERT_EFI_ERROR (Status);

Normally this would be a violation of the protocol, because the pointer I'm 
passing to BootScript->Write() doesn't point to runtime memory or ACPI NVS.

The implementation behind BootScript->Write() is the BootScriptWrite() function 
in "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c".
Relevant part:

>   case EFI_BOOT_SCRIPT_INFORMATION_OPCODE:
> VA_START (Marker, OpCode);
> Status = BootScriptWriteInformation (Marker);
> VA_END (Marker);
> break;

The BootScriptWriteInformation() function says (still in the same file):

> EFI_STATUS
> BootScriptWriteInformation (
>   IN VA_LIST   Marker
>   )
> {
>   UINT32InformationLength;
>   EFI_PHYSICAL_ADDRESS  Information;
>
>   InformationLength = VA_ARG (Marker, UINT32);
>   Information = VA_ARG (Marker, EFI_PHYSICAL_ADDRESS);
>   return S3BootScriptSaveInformation (InformationLength, 
> (VOID*)(UINTN)Information); }

The retrieval of "InformationLength" and "Information" from the stack via the 
outer ellipsis / inner VA_LIST notation is correct.

When calling S3BootScriptSaveInformation(), "Information" is converted to a 
pointer type. I agree that it is not dereferenced (yet), but this is already 
wrong, because the caller is entitled to pass in a 64-bit EFI_PHYSICAL_ADDRESS, 
and by converting it to UINTN (and then to VOID*) we could be truncating it, if 
the DXE phase is 32-bit.

Anyway, this is not the main issue; let's suppose that the pointer passed to 
S3BootScriptSaveInformation() still carries the full EFI_PHYSICAL_ADDRESS.

Then, in file
"MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c":

> RETURN_STATUS
> EFIAPI
> S3BootScriptSaveInformation (
>   IN  UINT32InformationLength,
>   IN  VOID

Re: [edk2] please clarify "PcdDxeIplSwitchToLongMode"

2013-12-03 Thread Jordan Justen

On Tue, Dec 3, 2013 at 1:56 PM, Laszlo Ersek  wrote:
> it's as if different parts of the code thought differently about
> PcdDxeIplSwitchToLongMode.
>
> Interpretation #1:
> - PcdDxeIplSwitchToLongMode means that we have to *switch* from 32-bit
> PEI to 64-bit DXE. Emphasis on "switch", that is, "PEI and DXE have
> different bitness".
>
> Interpretation #2:
> - PcdDxeIplSwitchToLongMode means that DXE is 64-bit, independently of
> PEI bitness.

Clearly the name indicates that DxeIpl needs to switch into long-mode.
It seems there are two cases where this can be false, yet DXE can be
64-bit:
* 64-bit only OVMF
* 64-bit EmulatorPkg

Is a new PCD needed, or can PEI code use:
Has64BitDxe =
  (sizeof(UINTN) == sizeof(UINT64)) ||
  (FeaturePcdGet (PcdDxeIplSwitchToLongMode);

I don't think 64-bit PEI with a 32-bit DXE is supported.

-Jordan

>   PcdDxeIplSwitchToLongMode
> PEI  DXE  Interp#1  Interp#2 result
> 32   32   0 0OK
> 32   64   1 1OK
> 64   64   0 1oops
>
> I checked the documentation in MdeModulePkg/MdeModulePkg.dec, and I have
> no clue which interpretation it follows.
>
> The picture is further complicated by "PcdDxeIplBuildPageTables" (added
> in SVN r12016. It seems to allow one to say (by setting it to FALSE),
> "64-bit PEI, 64-bit DXE, but please don't rebuild page tables".
>
> Now, in OVMF, the 32/32 platform DSC file sets PcdDxeIplSwitchToLongMode
> to FALSE. No difference between interp#1 and interp#2.
>
> The 32/64 DSC file sets it to TRUE. Detto.
>
> The 64/64 DSC file it to FALSE again, clearly following interp#1 -- "no
> switching needed".
>
> Maybe, we should set this PCD to TRUE (ie. follow Interp#2), and turn
> off rebuilding the page tables by setting the newer
> PcdDxeIplBuildPageTables to FALSE. I have no clue. (We don't use this
> second PCD in OVMF, only EmulatorPkg and Nt32Pkg do -- they both set it
> to FALSE.)
>
> If OVMF interprets PcdDxeIplSwitchToLongMode differently (==interp#1)
> from some other parts of the code (interp#2), well that has not been
> causing problems until now, apparently.
>
> But now I'm looking at the S3 suspend/resume code, and it is full of
> comments that apparently *equate*
>
>   PcdDxeIplSwitchToLongMode==FALSE
>
> with
>
>   DXE is 32-bit
>
> Which corresponds to Interp#2.
> I'm asking because I'm now reaching the assembly code in
> "MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S" that
> would jump to the (real mode) OSPM waking vector, and it reboots the
> machine. I think that maybe the wrong routine is invoked, due to
> confusion around PcdDxeIplSwitchToLongMode.
> (The reboot happens when LRET pops RIP and CS from the stack. Apparently
> the idea behind this exercise is to stay/continue in the same ASM file,
> but change the CS. It doesn't work.)
>
> Thanks!
> Laszlo
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Socket connection non-blocking

2013-12-03 Thread Daniel Moura

I'm trying to use select() in a non-blocking connection with O_NONBLOCK
applied before connect(), but, connect() returns -1 and errno == "Device
not configured". If I don't set the O_NONBLOCK flags the connection works
fine, but with blocking behaviour using the default timeout. Someone has
any idea of how to solve this or even provide some way to change the
connect() timeout? I wrote an C Cygwin/Linux application that does the same
thing and everything works as expected.

Thanks.

Daniel Moura
@danielgvmoura 
oxes...@gmail.com
http://www.oxesoft.com
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] please clarify "PcdDxeIplSwitchToLongMode"

2013-12-03 Thread Laszlo Ersek

Hi,

it's as if different parts of the code thought differently about
PcdDxeIplSwitchToLongMode.

Interpretation #1:
- PcdDxeIplSwitchToLongMode means that we have to *switch* from 32-bit
PEI to 64-bit DXE. Emphasis on "switch", that is, "PEI and DXE have
different bitness".

Interpretation #2:
- PcdDxeIplSwitchToLongMode means that DXE is 64-bit, independently of
PEI bitness.

  PcdDxeIplSwitchToLongMode
PEI  DXE  Interp#1  Interp#2 result
32   32   0 0OK
32   64   1 1OK
64   64   0 1oops

I checked the documentation in MdeModulePkg/MdeModulePkg.dec, and I have
no clue which interpretation it follows.

The picture is further complicated by "PcdDxeIplBuildPageTables" (added
in SVN r12016. It seems to allow one to say (by setting it to FALSE),
"64-bit PEI, 64-bit DXE, but please don't rebuild page tables".

Now, in OVMF, the 32/32 platform DSC file sets PcdDxeIplSwitchToLongMode
to FALSE. No difference between interp#1 and interp#2.

The 32/64 DSC file sets it to TRUE. Detto.

The 64/64 DSC file it to FALSE again, clearly following interp#1 -- "no
switching needed".

Maybe, we should set this PCD to TRUE (ie. follow Interp#2), and turn
off rebuilding the page tables by setting the newer
PcdDxeIplBuildPageTables to FALSE. I have no clue. (We don't use this
second PCD in OVMF, only EmulatorPkg and Nt32Pkg do -- they both set it
to FALSE.)

If OVMF interprets PcdDxeIplSwitchToLongMode differently (==interp#1)
from some other parts of the code (interp#2), well that has not been
causing problems until now, apparently.

But now I'm looking at the S3 suspend/resume code, and it is full of
comments that apparently *equate*

  PcdDxeIplSwitchToLongMode==FALSE

with

  DXE is 32-bit

Which corresponds to Interp#2.

I'm asking because I'm now reaching the assembly code in
"MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S" that
would jump to the (real mode) OSPM waking vector, and it reboots the
machine. I think that maybe the wrong routine is invoked, due to
confusion around PcdDxeIplSwitchToLongMode.

(The reboot happens when LRET pops RIP and CS from the stack. Apparently
the idea behind this exercise is to stay/continue in the same ASM file,
but change the CS. It doesn't work.)

Thanks!
Laszlo

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Getting PCD values for tools that post process the build.

2013-12-03 Thread Tim Lewis

Andrew --

That's how we do it :-) 

Tim

-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Tuesday, December 03, 2013 11:19 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Getting PCD values for tools that post process the build.

Is there a recommended solution to get PCD values for consumption in a post 
build step?

The only thing I could think of is to post process the build log?

Thanks,

Andrew Fish

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance affects 
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & 
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

2013-12-03 Thread Laszlo Ersek

Hi!

On 12/03/13 16:03, Yao, Jiewen wrote:
> Hi Laszlo

> "According to the PI spec, Information is a pointer pointing to
> runtime memory or ACPI NVS, and the BootScript record will store the
> pointer (ie. not the data pointed-to)."

> I agree with you on first part - According to the PI spec, Information
> is a pointer pointing to runtime memory or ACPI NVS.

> And I hold different view on second part - the BootScript record will
> store the pointer (ie. not the data pointed-to)

I disagree (and I tested it too). My example code goes like:

>   EFI_STATUS Status;
>   EFI_S3_SAVE_STATE_PROTOCOL *BootScript;
>   STATIC CONST UINT8 Info[] = { 0xDE, 0xAD, 0xBE, 0xEF };
>
>   Status = gBS->LocateProtocol (&gEfiS3SaveStateProtocolGuid, NULL,
>   (VOID **) &BootScript);
>   ASSERT_EFI_ERROR (Status);
>
>   //
>   // Despite the opcode documentation in the PI spec, the protocol
>   // implementation embeds a deep copy of the info in the boot script, rather
>   // than storing just a pointer to runtime or NVS storage.
>   //
>   Status = BootScript->Write(BootScript, EFI_BOOT_SCRIPT_INFORMATION_OPCODE,
>  (UINT32) sizeof Info,
>  (EFI_PHYSICAL_ADDRESS)(UINTN) &Info);
>   ASSERT_EFI_ERROR (Status);

Normally this would be a violation of the protocol, because the pointer
I'm passing to BootScript->Write() doesn't point to runtime memory or
ACPI NVS.

The implementation behind BootScript->Write() is the BootScriptWrite()
function in "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c".
Relevant part:

>   case EFI_BOOT_SCRIPT_INFORMATION_OPCODE:
> VA_START (Marker, OpCode);
> Status = BootScriptWriteInformation (Marker);
> VA_END (Marker);
> break;

The BootScriptWriteInformation() function says (still in the same file):

> EFI_STATUS
> BootScriptWriteInformation (
>   IN VA_LIST   Marker
>   )
> {
>   UINT32InformationLength;
>   EFI_PHYSICAL_ADDRESS  Information;
>
>   InformationLength = VA_ARG (Marker, UINT32);
>   Information = VA_ARG (Marker, EFI_PHYSICAL_ADDRESS);
>   return S3BootScriptSaveInformation (InformationLength, 
> (VOID*)(UINTN)Information);
> }

The retrieval of "InformationLength" and "Information" from the stack
via the outer ellipsis / inner VA_LIST notation is correct.

When calling S3BootScriptSaveInformation(), "Information" is converted
to a pointer type. I agree that it is not dereferenced (yet), but this
is already wrong, because the caller is entitled to pass in a 64-bit
EFI_PHYSICAL_ADDRESS, and by converting it to UINTN (and then to VOID*)
we could be truncating it, if the DXE phase is 32-bit.

Anyway, this is not the main issue; let's suppose that the pointer
passed to S3BootScriptSaveInformation() still carries the full
EFI_PHYSICAL_ADDRESS.

Then, in file
"MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c":

> RETURN_STATUS
> EFIAPI
> S3BootScriptSaveInformation (
>   IN  UINT32InformationLength,
>   IN  VOID *Information
>   )
> {
>   UINT8 Length;
>   UINT8 *Script;
>   EFI_BOOT_SCRIPT_INFORMATION  ScriptInformation;
>
>   Length = (UINT8)(sizeof (EFI_BOOT_SCRIPT_INFORMATION) + InformationLength);
>
>   Script = S3BootScriptGetEntryAddAddress (Length);
>   if (Script == NULL) {
> return RETURN_OUT_OF_RESOURCES;
>   }
>   //
>   // Build script data
>   //
>   ScriptInformation.OpCode = EFI_BOOT_SCRIPT_INFORMATION_OPCODE;
>   ScriptInformation.Length = Length;
>
>
>   ScriptInformation.InformationLength = InformationLength;
>
>   CopyMem ((VOID*)Script, (VOID*)&ScriptInformation, sizeof 
> (EFI_BOOT_SCRIPT_INFORMATION));
>   CopyMem ((VOID*)(Script + sizeof (EFI_BOOT_SCRIPT_INFORMATION)), (VOID *) 
> Information, (UINTN) InformationLength);
>
>   SyncBootScript (Script);
>
>   return RETURN_SUCCESS;
>
> }

With my example in mind, the Length local variable is set to

  sizeof (EFI_BOOT_SCRIPT_INFORMATION) + 4

The "ScriptInformation" structure contains:

  OpCode= EFI_BOOT_SCRIPT_INFORMATION_OPCODE
  Length= sizeof (EFI_BOOT_SCRIPT_INFORMATION) + 4
  InformationLength = 4

The first CopyMem() call copies this header to the beginning of the new
entry in the boot script.

The second CopyMem() call copies data into the same new entry, right
behind the header. However, it does not copy the address that has been
passed in -- it dereferences the address and copies the data. In my
case, it copies the four bytes { 0xDE, 0xAD, 0xBE, 0xEF } into the
entry.

When replaying this entry after resume, the boot script executor calls
into the same library, function S3BootScriptExecute(), file
"MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptExecute.c":

S3BootScriptExecute()
  BootScriptExecuteInformation()

> VOID
> BootScriptExecuteInformation (
>   IN UINT8   *Script
>   )
>
> {
>   UINT32

Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce PcdPciDisableBusEnumeration

2013-12-03 Thread Jordan Justen

On Tue, Dec 3, 2013 at 1:30 AM, Ni, Ruiyu  wrote:
> For your information, I tried to replace the DUET PciBus driver using 
> MdeModulePkg one.
> It works well after a small fix to the DUET PciRootBridgeNoEnumerationDxe 
> driver.

Nice. :)

I wonder if there is a chance of moving DUET to use
PcAtChipsetPkg/PciHostBridgeDxe, since it appears to work for Xen with
the no-enumeration PCD.

-Jordan

> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Tuesday, December 03, 2013 3:44 AM
> To: Jordan Justen; Wei Liu
> Cc: edk2-devel@lists.sourceforge.net; xen-devel
> Subject: Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce 
> PcdPciDisableBusEnumeration
>
> Jordan,
>
> Only rule is that TokenNumber must be unique within the TokenSpaceGuid.
>
> Reviewed-by: Michael Kinney <>
>
> Mike
>
> -Original Message-
> From: Jordan Justen [mailto:jljus...@gmail.com]
> Sent: Saturday, November 30, 2013 3:56 PM
> To: Kinney, Michael D; Wei Liu
> Cc: xen-devel; edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce 
> PcdPciDisableBusEnumeration
>
> On Fri, Nov 29, 2013 at 6:13 AM, Wei Liu  wrote:
>> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c 
>> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
>> index 5afbb82..cc6be8b 100644
>> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
>> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
>> @@ -284,7 +284,10 @@ PciBusDriverBindingStart (
>>);
>>}
>>
>> -  gFullEnumeration = (BOOLEAN) ((SearchHostBridgeHandle (Controller) ? 
>> FALSE : TRUE));
>> +  if (PcdGetBool (PcdPciDisableBusEnumeration))
>> +gFullEnumeration = FALSE;
>> +  else
>> +gFullEnumeration = (BOOLEAN) ((SearchHostBridgeHandle (Controller) ? 
>> FALSE : TRUE));
>
> Code style { }
>
> I think this could be fixed at commit time.
>
>> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
>> index b627eb1..5198451 100644
>> --- a/MdeModulePkg/MdeModulePkg.dec
>> +++ b/MdeModulePkg/MdeModulePkg.dec
>> @@ -878,6 +878,9 @@
>>## This PCD specified whether the S.M.A.R.T feature of attached ATA hard 
>> disks are enabled.
>>gEfiMdeModulePkgTokenSpaceGuid.PcdAtaSmartEnable|TRUE|BOOLEAN|0x00010065
>>
>> +  ## This PCD specifies whether full PCI enumeration is disabled.
>> +  
>> gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE|BOOLEAN|0x1048
>
> Mike,
>
> Any preference on token number other than don't clash?
>
> Do you give your Reviewed-by for this patch? If so, I could take care
> of committing it.
>
> -Jordan
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] gBS->LocateProtocol

2013-12-03 Thread Jordan Justen

Try removing "gBS = SystemTable->BootServices;"

Your SystemTable global variable is not initialized, so that
assignment is invalid. You should remove the SystemTable variable.

Since your .inf must already include UefiBootServicesTableLib, gBS
should already be initialized for you.

-Jordan

On Tue, Dec 3, 2013 at 12:40 AM, Nishit Patira  wrote:
> Hi Ramesh,
>
> PFA the source code.
>
>
> On Tue, Dec 3, 2013 at 11:39 AM, Ramesh R.  wrote:
>>
>> Nishit,
>>
>>
>>
>>   Could you please attach your draft source where the locate protocol
>> works and doesn’t work. That might give us some idea where are going wrong.
>>
>>
>>
>> Thanks,
>>
>> Ramesh
>>
>>
>>
>> From: Nishit Patira [mailto:nishitpat...@gmail.com]
>> Sent: Tuesday, December 03, 2013 9:39 AM
>>
>>
>> To: edk2-devel@lists.sourceforge.net
>> Subject: Re: [edk2] gBS->LocateProtocol
>>
>>
>>
>> Hi Justen,
>>
>>
>>
>> No, it is not even returning an error. The GUIDs match, I have verified
>> them.
>>
>> Regards,
>>
>> Nishit
>>
>>
>>
>> On Sun, Dec 1, 2013 at 3:12 AM, Jordan Justen  wrote:
>>
>> On Sat, Nov 30, 2013 at 10:35 AM, Nishit Patira 
>> wrote:
>> > Hii,
>> >
>> > Yes, it is by a DXE Driver. However, it is not returning anything.
>>
>> I think you mean that it is returning an error. In other words, the
>> call returns, but EFI_ERROR (Status) shows an error was returned. ??
>>
>> gEfiIntelDimmToolProtocolGuid is not a UEFI protocol, so it probably
>> is not surprising that it would not be found on your average UEFI
>> system. In that case, your application should exit indicating that it
>> was not found.
>>
>> Are you sure it is being installed by a driver on the system you are
>> testing with? If so, then I guess you might double check that the
>> GUIDs match.
>>
>> -Jordan
>>
>>
>> > On Sat, Nov 30, 2013 at 4:06 PM, Galla Rao 
>> > wrote:
>> >>
>> >> Is this Protocol installed by any DXE driver?
>> >> The Status should return EFI_NOT_FOUND atleast
>> >>
>> >>
>> >>
>> >> On Sat, Nov 30, 2013 at 12:28 PM, Nishit Patira
>> >> 
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I am writing an UEFI Application. I am using gBS_>LocateProtocol to
>> >>> return the instance where the protocl is found.
>> >>>
>> >>> EFI_STATUS Status;
>> >>> gBS = SystemTable->BootServices;
>> >>> Status = gBS->LocateProtocol (&gEfiIntelDimmToolProtocolGuid,
>> >>> NULL,(void
>> >>> **) &mDimmToolProtocol);
>> >>>
>> >>> However, the function is not returning anything.
>> >>>
>> >>> Could someone point out the error to me??
>> >>>
>> >>> Regards,
>> >>> Nishit H Patira
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Rapidly troubleshoot problems before they affect your business. Most
>> >>> IT
>> >>> organizations don't have a clear picture of how application
>> >>> performance
>> >>> affects their revenue. With AppDynamics, you get 100% visibility into
>> >>> your
>> >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>> >>> AppDynamics
>> >>> Pro!
>> >>>
>> >>>
>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> >>> ___
>> >>> edk2-devel mailing list
>> >>> edk2-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Rapidly troubleshoot problems before they affect your business. Most IT
>> >> organizations don't have a clear picture of how application performance
>> >> affects their revenue. With AppDynamics, you get 100% visibility into
>> >> your
>> >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>> >> AppDynamics
>> >> Pro!
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> >> ___
>> >> edk2-devel mailing list
>> >> edk2-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>> >>
>> >
>> >
>> >
>> > --
>> > Rapidly troubleshoot problems before they affect your business. Most IT
>> > organizations don't have a clear picture of how application performance
>> > affects their revenue. With AppDynamics, you get 100% visibility into
>> > your
>> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>> > AppDynamics
>> > Pro!
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> > ___
>> > edk2-devel mailing list
>> > edk2-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>> >
>>
>>
>> --
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects the

[edk2] Getting PCD values for tools that post process the build.

2013-12-03 Thread Andrew Fish

Is there a recommended solution to get PCD values for consumption in a post 
build step?

The only thing I could think of is to post process the build log?

Thanks,

Andrew Fish

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Is there a reason that the AcpiSystemDescriptionTable protocol does not have a value for ACPI 5.0?

2013-12-03 Thread Andrew Fish

Is there a reason that the AcpiSystemDescriptionTable protocol does not have a 
value for ACPI 5.0?

>From 
>https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
#define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
#define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
#define EFI_ACPI_TABLE_VERSION_2_0  (1 << 2)
#define EFI_ACPI_TABLE_VERSION_3_0  (1 << 3)
#define EFI_ACPI_TABLE_VERSION_4_0  (1 << 4)

Thanks,

Andrew Fish
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC 00/15] S3 suspend/resume for OVMF (WIP)

2013-12-03 Thread David Woodhouse

On Mon, 2013-12-02 at 13:42 -0800, Jordan Justen wrote:
> 
> SMM for OVMF would be interesting from a sample code perspective for
> EDK II, but probably not bring any other benefits.

Surely if it's sample code in EDK II we are thinking about, would be far
better off showing how things could be done *without* resorting to SMM.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC 00/15] S3 suspend/resume for OVMF (WIP)

2013-12-03 Thread Laszlo Ersek

On 12/02/13 18:04, Laszlo Ersek wrote:

> The big problem is that nothing ever installs
> EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL. As a consequence, the boot script is
> never saved (not even an empty one), *and* BootScriptExecutorDxe never
> copies itself to reserved memory (in order to survive the suspension).
> Symptoms are:
> 
> - the "SMM IPL!  DXE SMM Ready To Lock Protocol not installed before
>   Ready To Boot signal" warning when I boot a boot option,
> 
> - when I try to resume, the third RestoreLockBox() call in
>   S3RestoreConfig2() fails, and the next assertion fails:
> 
>   VarSize   = sizeof (EFI_PHYSICAL_ADDRESS);
>   Status = RestoreLockBox (
>  &gEfiBootScriptExecutorVariableGuid,
>  &TempEfiBootScriptExecutorVariable,
>  &VarSize
>  );
>   ASSERT_EFI_ERROR (Status);
> 
> Of course I can install/emit EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL myself.
> I just don't know *when* to install it.
> 
> As I wrote in the commit messages below, BdsLibBootViaBootOption() calls
> into EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe], and it needs SMRAM
> access. So, I can't install DXE_SMM_READY_TO_LOCK earlier than that.
> OTOH, I don't have control over any code that runs *after* it.
> 
> Maybe I could install DXE_SMM_READY_TO_LOCK from a ready-to-boot event
> handler, but the SMM core & drivers already seem to install a bunch of
> stuff on that event, and I'm not sure the ordering between the handlers
> would be correct.

In patch 07/15 I created a customized copy of AcpiS3SaveDxe anyway, so I
just patched the S3Ready() function in a new patch (inserted between 09
and 10. The last step of S3Ready() is now to prepare the boot script at
once, and install DXE_SMM_READY_TO_LOCK too.

This way everything is prepared and saved in correct order, and the call
in BdsLibBootViaBootOption() is what triggers the whole thing.

After resume, the boot script executor runs the script (yay!), but I ran
into other trouble.  After a point S3Resume.c starts calling functions
by switching stacks explicitly (and such functions can't return
normally, they have to switch back, to an address they take as parameter):

S3RestoreConfig2() -- main function of the PEIM
  S3ResumeExecuteBootScript()
S3BootScriptExecutorEntryFunction() -- called via stack switching

Before S3ResumeExecuteBootScript() calls
S3BootScriptExecutorEntryFunction() via stack switching, it describes
the function the latter has to "return" (actually, jump) to. The target
function is S3ResumeBootOs() (which would jump to the OS wakeup vector
in the FACS):

S3RestoreConfig2() -- main function of the PEIM
  S3ResumeExecuteBootScript()
S3BootScriptExecutorEntryFunction() -- called via stack switching
S3ResumeBootOs() -- jumped-to via stach switching
  jump to vector in FACS

S3BootScriptExecutorEntryFunction() indeed runs (it interprets the boot
script), and wants to jump to S3ResumeBootOs(). However, the stack that
S3ResumeExecuteBootScript() has prepared for it is wrong:

  PeiS3ResumeState->ReturnStackPointer =
(EFI_PHYSICAL_ADDRESS)(UINTN)&Status;

"Status" is the first local variable in S3ResumeExecuteBootScript().
Presumably, S3ResumeExecuteBootScript() wants
S3BootScriptExecutorEntryFunction() to restore the original stack.

This doesn't work however, because gcc juggles the layout of
auto-variables on the stack freely, and in this case "Status" ends up at
an address that is not a multiple of CPU_STACK_ALIGNMENT. Hence
SwitchStack() ASSERT()s.

I'm fixing this with another patch -- instead of relying on the layout
of local variables and calling convention, I use a statically (or maybe
dynamically) allocated array as stack.

S3ResumeBootOs() is reached in fact and seems to call the FACS vector,
but now I'm getting an infinite reboot loop... :)

Thanks
Laszlo

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

2013-12-03 Thread Yao, Jiewen

Hi Laszlo
"According to the PI spec, Information is a pointer pointing to runtime memory 
or ACPI NVS, and the BootScript record will store the pointer (ie. not the data 
pointed-to)."
I agree with you on first part - According to the PI spec, Information is a 
pointer pointing to runtime memory or ACPI NVS.
And I hold different view on second part - the BootScript record will store the 
pointer (ie. not the data pointed-to)

NOTE: PI spec does not say anything on boot script format in memory, this is 
implementation specific.

For security reason, BIOS S3 module will try its best to save the all S3 data 
to lockbox, so current S3 module implementation purposely save the information 
part into boot script and into lockbox later.

Personally, I believe this implementation still follows PI spec, since Boot 
Script format is NOT defined by PI spec.


"The current code also limits the size of the information to less than 255 
bytes, and makes the InformationLength argument redundant."
I agree with you on first part - The current code also limits the size of the 
information to less than 255 bytes.
And I hold different view on second part - makes the InformationLength argument 
redundant.

Right, current implementation does have such limitation. If you have concern, I 
agree to fix 255 bytes limitation.
S3 module does use InformationLength field in current implementation. Would you 
please point out why it is "redundant"?


Thank you
Yao Jiewen

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, December 03, 2013 7:08 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

Probably a known bug that cannot be fixed for compatibility reasons:

EFI_BOOT_SCRIPT_INFORMATION_OPCODE takes two arguments, "InformationLength" and 
"Information". According to the PI spec, Information is a pointer pointing to 
runtime memory or ACPI NVS, and the BootScript record will store the pointer 
(ie. not the data pointed-to).

However the implementation in

  BootScriptWriteInformation()
  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c

and in the underlying library function

  S3BootScriptSaveInformation()
  MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c

dereference the pointer when the opcode is added, and the pointed-to data is 
copied into the script.

This is no problem per se, it's just not what the spec says. The spec would 
need something like:

  diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
  index c087dd9..655496f 100644
  --- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
  +++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
  @@ -1449,14 +1449,14 @@ RETURN_STATUS
   EFIAPI
   S3BootScriptSaveInformation (
 IN  UINT32InformationLength,
  -  IN  VOID *Information
  +  IN  EFI_PHYSICAL_ADDRESS  Information
 )
   {
 UINT8 Length;
 UINT8 *Script;
 EFI_BOOT_SCRIPT_INFORMATION  ScriptInformation;

  -  Length = (UINT8)(sizeof (EFI_BOOT_SCRIPT_INFORMATION) + InformationLength);
  +  Length = (UINT8)(sizeof (EFI_BOOT_SCRIPT_INFORMATION) + sizeof 
Information);

 Script = S3BootScriptGetEntryAddAddress (Length);
 if (Script == NULL) {
  @@ -1472,7 +1472,7 @@ S3BootScriptSaveInformation (
 ScriptInformation.InformationLength = InformationLength;

 CopyMem ((VOID*)Script, (VOID*)&ScriptInformation, sizeof 
(EFI_BOOT_SCRIPT_INFORMATION));
  -  CopyMem ((VOID*)(Script + sizeof (EFI_BOOT_SCRIPT_INFORMATION)), (VOID *) 
Information, (UINTN) InformationLength);
  +  CopyMem ((VOID*)(Script + sizeof (EFI_BOOT_SCRIPT_INFORMATION)), 
&Information, sizeof Information);

 SyncBootScript (Script);

  diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
  index 60cd9b1..70e206f 100644
  --- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
  +++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
  @@ -418,7 +418,7 @@ BootScriptWriteInformation (

 InformationLength = VA_ARG (Marker, UINT32);
 Information = VA_ARG (Marker, EFI_PHYSICAL_ADDRESS);
  -  return S3BootScriptSaveInformation (InformationLength, 
(VOID*)(UINTN)Information);
  +  return S3BootScriptSaveInformation (InformationLength, Information);
   }
   /**
 Internal function to add IO poll opcode node  to the table

The replay code would need the corresponding change.

The current code also limits the size of the information to less than 255 
bytes, and makes the InformationLength argument redundant.

Thanks
Laszlo

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a cle

Re: [edk2] gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint not working in DxeServicesLib.c)

2013-12-03 Thread Olivier Martin

Because you are using SerialDxe (see
'VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)'), ensure you have the
following drivers in your DSC and FDF files:
- MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
- MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
- MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf

ConSplitterDxe is the driver that will set gST->ConOut in this scenario.

Olivier


> -Original Message-
> From: Bhupesh Sharma [mailto:bhupesh.sha...@freescale.com]
> Sent: 02 December 2013 11:09
> To: Olivier Martin; 'Andrew Fish'; 'edk2-devel@lists.sourceforge.net'
> Subject: gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint not
> working in DxeServicesLib.c)
> 
> Hi,
> 
> I managed to trace down the issues with my UEFI ported code for a
> Cortex-A9 MP core based SoC.
> 
> I see two issues (after solving a few on the way) on which I cannot
> seem to make any headway.
> 
> 1. gST->ConOut is NULL causing the Print routines inside
> StartDefaultBootOnTimeout
> 
> (https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/Bds/Bds.c
> #L327), to not print
>   anything on the UART console.
> 
>   - At first, I suspected this to be an issue with my .dsc file as I
> don't have a LCD available on my SoC
> and I had serial port as well as (a left over) LCD configured as
> SIMPLE TEXT protocols for ConOut.
> I have hence changed my .dsc to something like:
> 
>   # Use the serial console for both ConIn & ConOut
>   gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-
> 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();"
>   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-
> 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
> 
>   However, still I see that gST->ConOut is NULL (via the DS-5 source
> debugger).
> 
> 2. Timer support in UEFI:
> 
>  - For every BoardPkg (e.g. ArmPlatformPkg/SP804, BeagleBoardPkg and
> Samsung etc), I can see that there are two Timer helper layers:
> 
>   # [1] Timer Dxe Driver:
> 
>   https://github.com/tianocore/edk2/tree/master/ArmPlatformPkg/Driv
> ers/SP804TimerDxe
> 
>   # [2] Timer Lib:
> 
>   https://github.com/tianocore/edk2/tree/master/ArmPlatformPkg/Libr
> ary/SP804TimerLib
> 
> 
>   When I start to look at this code it seems that the UEFI code
> requires support for atleast 2 timers: Performance Timer (used in [1])
>   and another free SoC timer which is used to provide delays ([2]).
> 
>   Is this understanding correct? Does UEFI require atleast 2 timers
> to be supported by the SoC and are these timers used in parallel
>   by the UEFI framework?
> 
> Thanks for any pointers on the above two aspects.
> 
> Regards,
> Bhupesh
> 
> 
> > -Original Message-
> > From: Sharma Bhupesh-B45370
> > Sent: Tuesday, November 26, 2013 5:02 PM
> > To: Olivier Martin; 'Andrew Fish'; edk2-devel@lists.sourceforge.net
> > Cc: Kushwaha Prabhakar-B32579
> > Subject: RE: SerialPrint not working in DxeServicesLib.c
> >
> > Hi Olivier,
> >
> > Thanks for your mail.
> >
> > I have a SerialPortLib which tries to configure Serial controller
> > specific to my board (so *no* 'SerialPortLib' pointing to
> > 'MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf'
> > in my DSC).
> >
> > I am getting the UEFI firmware .. banner at the very start.
> >
> > I will now try to add some SerialPortWrite() before calling
> > GetSectionFromAnyFv().
> >
> > Regards,
> > Bhupesh
> >
> >
> > > -Original Message-
> > > From: Olivier Martin [mailto:olivier.mar...@arm.com]
> > > Sent: Tuesday, November 26, 2013 4:27 PM
> > > To: Sharma Bhupesh-B45370; 'Andrew Fish'; edk2-
> > > de...@lists.sourceforge.net
> > > Cc: Kushwaha Prabhakar-B32579
> > > Subject: RE: SerialPrint not working in DxeServicesLib.c
> > >
> > > Sorry to not reply earlier, I was on holiday in the last two weeks.
> > >
> > > If you do not see any output from the serial, ensure your are using
> > > the appropriate 'SerialPortLib'.
> > > Check in your DSC file, there is no 'SerialPortLib' pointing to
> > > 'MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf'.
> > > Example:
> > >
> > > [LibraryClasses.common]
> > >   (...)
> > >
> > >
> SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNu
> > > SerialPortLib|ll
> > > SerialPortLib|.inf
> > >   (...)
> > >
> > > SerialPortLib should use the implementation for your Serial
> controller.
> > >
> > > Try also to add some SerialPortWrite() before calling
> > > GetSectionFromAnyFv().
> > > I would not be surprised if the crash happens much earlier than the
> > > DXE phase.
> > >
> > >
> > > > -Original Message-
> > > > From: Bhupesh Sharma [mailto:bhupesh.sha...@freescale.com]
> > > > Sent: 20 November 2013 11:50
> > > > To: 'Andrew Fish'; 'edk2-devel@lists.sourceforge.net'; Olivier
> > > > Martin
> > > > Cc: Prabhakar Kushwaha
> > > > Subject: RE: SerialPrint not working in DxeServicesLib.c
> > > >
>

[edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

2013-12-03 Thread Laszlo Ersek

Probably a known bug that cannot be fixed for compatibility reasons:

EFI_BOOT_SCRIPT_INFORMATION_OPCODE takes two arguments, "InformationLength" and
"Information". According to the PI spec, Information is a pointer pointing to
runtime memory or ACPI NVS, and the BootScript record will store the pointer
(ie. not the data pointed-to).

However the implementation in

  BootScriptWriteInformation()
  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c

and in the underlying library function

  S3BootScriptSaveInformation()
  MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c

dereference the pointer when the opcode is added, and the pointed-to data is
copied into the script.

This is no problem per se, it's just not what the spec says. The spec would
need something like:

  diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
  index c087dd9..655496f 100644
  --- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
  +++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
  @@ -1449,14 +1449,14 @@ RETURN_STATUS
   EFIAPI
   S3BootScriptSaveInformation (
 IN  UINT32InformationLength,
  -  IN  VOID *Information
  +  IN  EFI_PHYSICAL_ADDRESS  Information
 )
   {
 UINT8 Length;
 UINT8 *Script;
 EFI_BOOT_SCRIPT_INFORMATION  ScriptInformation;

  -  Length = (UINT8)(sizeof (EFI_BOOT_SCRIPT_INFORMATION) + InformationLength);
  +  Length = (UINT8)(sizeof (EFI_BOOT_SCRIPT_INFORMATION) + sizeof 
Information);

 Script = S3BootScriptGetEntryAddAddress (Length);
 if (Script == NULL) {
  @@ -1472,7 +1472,7 @@ S3BootScriptSaveInformation (
 ScriptInformation.InformationLength = InformationLength;

 CopyMem ((VOID*)Script, (VOID*)&ScriptInformation, sizeof 
(EFI_BOOT_SCRIPT_INFORMATION));
  -  CopyMem ((VOID*)(Script + sizeof (EFI_BOOT_SCRIPT_INFORMATION)), (VOID *) 
Information, (UINTN) InformationLength);
  +  CopyMem ((VOID*)(Script + sizeof (EFI_BOOT_SCRIPT_INFORMATION)), 
&Information, sizeof Information);

 SyncBootScript (Script);

  diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
  index 60cd9b1..70e206f 100644
  --- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
  +++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
  @@ -418,7 +418,7 @@ BootScriptWriteInformation (

 InformationLength = VA_ARG (Marker, UINT32);
 Information = VA_ARG (Marker, EFI_PHYSICAL_ADDRESS);
  -  return S3BootScriptSaveInformation (InformationLength, 
(VOID*)(UINTN)Information);
  +  return S3BootScriptSaveInformation (InformationLength, Information);
   }
   /**
 Internal function to add IO poll opcode node  to the table

The replay code would need the corresponding change.

The current code also limits the size of the information to less than 255
bytes, and makes the InformationLength argument redundant.

Thanks
Laszlo

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce PcdPciDisableBusEnumeration

2013-12-03 Thread Ni, Ruiyu

For your information, I tried to replace the DUET PciBus driver using 
MdeModulePkg one.
It works well after a small fix to the DUET PciRootBridgeNoEnumerationDxe 
driver.

Thanks,
Ray

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Tuesday, December 03, 2013 3:44 AM
To: Jordan Justen; Wei Liu
Cc: edk2-devel@lists.sourceforge.net; xen-devel
Subject: Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce 
PcdPciDisableBusEnumeration

Jordan,

Only rule is that TokenNumber must be unique within the TokenSpaceGuid.

Reviewed-by: Michael Kinney <>

Mike

-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Saturday, November 30, 2013 3:56 PM
To: Kinney, Michael D; Wei Liu
Cc: xen-devel; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce 
PcdPciDisableBusEnumeration

On Fri, Nov 29, 2013 at 6:13 AM, Wei Liu  wrote:
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> index 5afbb82..cc6be8b 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> @@ -284,7 +284,10 @@ PciBusDriverBindingStart (
>);
>}
>
> -  gFullEnumeration = (BOOLEAN) ((SearchHostBridgeHandle (Controller) ? FALSE 
> : TRUE));
> +  if (PcdGetBool (PcdPciDisableBusEnumeration))
> +gFullEnumeration = FALSE;
> +  else
> +gFullEnumeration = (BOOLEAN) ((SearchHostBridgeHandle (Controller) ? 
> FALSE : TRUE));

Code style { }

I think this could be fixed at commit time.

> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index b627eb1..5198451 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -878,6 +878,9 @@
>## This PCD specified whether the S.M.A.R.T feature of attached ATA hard 
> disks are enabled.
>gEfiMdeModulePkgTokenSpaceGuid.PcdAtaSmartEnable|TRUE|BOOLEAN|0x00010065
>
> +  ## This PCD specifies whether full PCI enumeration is disabled.
> +  
> gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE|BOOLEAN|0x1048

Mike,

Any preference on token number other than don't clash?

Do you give your Reviewed-by for this patch? If so, I could take care
of committing it.

-Jordan

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC 04/15] MdeModulePkg: SmmLockBox: remove wrong DepEx

2013-12-03 Thread Laszlo Ersek

On 12/03/13 04:48, Yao, Jiewen wrote:
> Hi Laszlo
> Thanks! This update seems good.
> And we need more test to see if there is any impact on real platforms, 
> because of dependency change.
> 
> Reviewed-by: Jiewen Yao 

Thanks! :)
Laszlo

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] gBS->LocateProtocol

2013-12-03 Thread Nishit Patira

Hi Ramesh,

PFA the source code.


On Tue, Dec 3, 2013 at 11:39 AM, Ramesh R.  wrote:

>  Nishit,
>
>
>
>   Could you please attach your draft source where the locate protocol
> works and doesn’t work. That might give us some idea where are going wrong.
>
>
>
> Thanks,
>
> Ramesh
>
>
>
> *From:* Nishit Patira [mailto:nishitpat...@gmail.com]
> *Sent:* Tuesday, December 03, 2013 9:39 AM
>
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] gBS->LocateProtocol
>
>
>
> Hi Justen,
>
>
> No, it is not even returning an error. The GUIDs match, I have verified
> them.
>
>  Regards,
>
> Nishit
>
>
>
> On Sun, Dec 1, 2013 at 3:12 AM, Jordan Justen  wrote:
>
> On Sat, Nov 30, 2013 at 10:35 AM, Nishit Patira 
> wrote:
> > Hii,
> >
> > Yes, it is by a DXE Driver. However, it is not returning anything.
>
> I think you mean that it is returning an error. In other words, the
> call returns, but EFI_ERROR (Status) shows an error was returned. ??
>
> gEfiIntelDimmToolProtocolGuid is not a UEFI protocol, so it probably
> is not surprising that it would not be found on your average UEFI
> system. In that case, your application should exit indicating that it
> was not found.
>
> Are you sure it is being installed by a driver on the system you are
> testing with? If so, then I guess you might double check that the
> GUIDs match.
>
> -Jordan
>
>
> > On Sat, Nov 30, 2013 at 4:06 PM, Galla Rao 
> wrote:
> >>
> >> Is this Protocol installed by any DXE driver?
> >> The Status should return EFI_NOT_FOUND atleast
> >>
> >>
> >>
> >> On Sat, Nov 30, 2013 at 12:28 PM, Nishit Patira  >
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am writing an UEFI Application. I am using gBS_>LocateProtocol to
> >>> return the instance where the protocl is found.
> >>>
> >>> EFI_STATUS Status;
> >>> gBS = SystemTable->BootServices;
> >>> Status = gBS->LocateProtocol (&gEfiIntelDimmToolProtocolGuid,
> NULL,(void
> >>> **) &mDimmToolProtocol);
> >>>
> >>> However, the function is not returning anything.
> >>>
> >>> Could someone point out the error to me??
> >>>
> >>> Regards,
> >>> Nishit H Patira
> >>>
> >>>
> >>>
> --
> >>> Rapidly troubleshoot problems before they affect your business. Most IT
> >>> organizations don't have a clear picture of how application performance
> >>> affects their revenue. With AppDynamics, you get 100% visibility into
> >>> your
> >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics
> >>> Pro!
> >>>
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> >>>
> >>
> >>
> >>
> >>
> --
> >> Rapidly troubleshoot problems before they affect your business. Most IT
> >> organizations don't have a clear picture of how application performance
> >> affects their revenue. With AppDynamics, you get 100% visibility into
> your
> >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics
> >> Pro!
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> >>
> >
> >
> >
> --
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> > Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> >
>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> The information contained in this message may be confidential and
> proprietary to American Megatrends, Inc. This communication is intended to
> be read only by

Re: [edk2] [RFC 00/15] S3 suspend/resume for OVMF (WIP)

2013-12-03 Thread Laszlo Ersek

On 12/02/13 22:42, Jordan Justen wrote:
> On Mon, Dec 2, 2013 at 9:04 AM, Laszlo Ersek  wrote:
>> Please refer to the last patch in the series to appreciate the
>> complexity here. I'd like to ask interested people in the community to
>> read through the commit messages (*) and point out if I'm missing
>> something.
>>
>> (*) There isn't much code in the series, it's mostly duct tape. The
>> difficulty is figuring out what depends on what and how. I'm not even
>> trying to create an S3 Boot Script yet, just getting up the
>> infrastructure.
>>
>> Currently I have two problems, a small one and a big one.
>>
>> The small one is that S3Resume2Pei depends on a PPI
>> (EFI_PEI_SMM_COMMUNICATION_PPI) that doesn't exist in the edk2 tree. The
>> implementation would be interesting, considering that during DXE the
>> entire SMM core, 2-3 libraries, and a dedicated driver are necessary to
>> implement it.
> 
> SMM for OVMF would be interesting from a sample code perspective for
> EDK II, but probably not bring any other benefits.

Fully agreed.

> Has SMM in QEMU
> ever been used? I can't remember if QEMU actually claims to support
> SMM.

Gerd has informed me that TCG supports SMM and KVM doesn't.

But, in the series I'm faking SMRAM with an early allocation from the
runtime pool (same as the original NvVars trick), which is good enough.
Actual support for system management interrupts and the like doesn't
seem necessary in practice.

The main headache is the huge complexity of the modules, and the missing
(or rather, not open sourced) communication module in PEI (which I did
hack around, but it hurts).

This stuff seems to work in OVMF (although I'm sure I'll run into more
problems); right now I need to figure out when to issue the "dxe smm
ready to boot" protocol/notification (I could use a few pointers from
people who have implemented that...).

Later I'll need to look into composing a Boot Script. I intend not to do
anything at first, but, if OSPM doesn't wake up after jumping to its
vector in FACS, I'll patch qemu to log all PCI and IO accesses "from
below", and I'll try to see what I need to copy from that into a boot
script.

> Mike,
> 
> Do you think it would be better for OVMF to add EMU SMM modules, or to
> fix the core S3 modules to not require SMM?

Yes, that's the crucial question. My approach was to use whatever's
in-tree and provide shims for the missing protocols etc.

FWIW I agree with Eugene too -- the ~40 hours I've spent on this since
Friday evening tell me (maybe incorrectly) that "fixing" the S3 modules
not to require SMM looks rather like "rearchitecting" them.

Thanks,
Laszlo

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Is there a reason that the AcpiSystemDescriptionTable protocol does not have a value for ACPI 5.0?

[edk2] SEC code support big.LITTLE tech?

Re: [edk2] Getting PCD values for tools that post process the build.

Re: [edk2] Getting PCD values for tools that post process the build.

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

Re: [edk2] please clarify "PcdDxeIplSwitchToLongMode"

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

Re: [edk2] please clarify "PcdDxeIplSwitchToLongMode"

[edk2] Socket connection non-blocking

[edk2] please clarify "PcdDxeIplSwitchToLongMode"

Re: [edk2] Getting PCD values for tools that post process the build.

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce PcdPciDisableBusEnumeration

Re: [edk2] gBS->LocateProtocol

[edk2] Getting PCD values for tools that post process the build.

[edk2] Is there a reason that the AcpiSystemDescriptionTable protocol does not have a value for ACPI 5.0?

Re: [edk2] [RFC 00/15] S3 suspend/resume for OVMF (WIP)

Re: [edk2] [RFC 00/15] S3 suspend/resume for OVMF (WIP)

Re: [edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

Re: [edk2] gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint not working in DxeServicesLib.c)

[edk2] Save State protocol violation in S3SaveState.c (MdeModulePkg)

Re: [edk2] [PATCH v4 1/7] MdeModulePkg: introduce PcdPciDisableBusEnumeration

Re: [edk2] [RFC 04/15] MdeModulePkg: SmmLockBox: remove wrong DepEx

Re: [edk2] gBS->LocateProtocol

Re: [edk2] [RFC 00/15] S3 suspend/resume for OVMF (WIP)

25 matches

Site Navigation

Mail list logo

Footer information