Re: [edk2] OVMF.fd and placement of EfiBootServicesData

2016-10-06 Thread spam collector 
- Original Message -
> From: "Laszlo Ersek" 
> To: "spam collector" 
> Cc: edk2-de...@ml01.01.org
> Sent: Thursday, October 6, 2016 12:39:39 AM
> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
> 
> > Remember that I am running this in WinXPSP3.
> 
> First, I can't "remember" it, because this is the first time you state
> that. :)

I apologize for that.  I thought I had mentioned it.
 
> Second, WinXPSP3 as host machine, really?... :)

What do you mean, "really?"  In my opinion, WinXP was the last usable, 
worth having OS from Microsoft.  As soon as they went to the platform
they have now, they lost all hope of ever getting anything back.
I haven't had to reboot this WinXP machine due to the OS for years.
It is less resource hungry, and much faster than the modern computers
I have around.  I would rather sit at this 10 year old machine running
WinXP any day of the week including Sunday over any of the more modern
Windows machine I have or seen.  Just my opinion though.  I, by no means,
intend to start a war over which Windows OS is better, nor do I want
to start a war over, "You should move to a Linux based machine."
If it isn't broke, I am not fixing it.

For that matter, I am not expecting a reply to that. :-)
 
> > Also, the version of
> > OVMF.fd is from http://www.tianocore.org/ovmf/ and I just noticed
> > that that page has been recently changed.
> 
> That's a coincidence, but not a random one. Users have been repeatedly
> confused by the r15214 binary, which at this point was more than 2.5
> years old. Just before your query, I noticed
>  (and marked it invalid);
> the reporter of that issue was also tripped up by the ancient r15214
> build. So I asked Jordan to please update the page you reference, with a
> link to Gerd's RPMs, which are bleeding edge builds.

Noted.

> >>
> >>   usr/share/edk2.git/ovmf-*/OVMF_CODE-pure-efi.fd
> >>   usr/share/edk2.git/ovmf-*/OVMF_VARS-pure-efi.fd
> >>   usr/share/edk2.git/ovmf-*/UefiShell.iso

As per another message in this thread, I changed the Subsystem value 
from the 0x0B to 0x0A and it now boots as expected.  There is still
OVMF stuff in the way :-), but boots as expected to that point.
 
> > Also, please note that the hard drive image is a VHD image, a
> > raw image with a single sector at the end for the VHD info so that
> > Oracles VM Box will boot it.  This means that the backup GPT header
> > is *not* the last sector of the disk.
> 
> As far as I know, QEMU supports VHDX. However, you pass a VHD image to
> -drive with format=raw. That looks very broken. I guess I'd suggest
> matching the actual image format with the format=... property. If you
> pass format=raw, the VHD metadata at the end of the image will be
> visible to the guest (as garbage).

The latest version of the Windows port of QEMU and OVMF as listed
above, boot and treat the drive as expected, ignoring the last sector.
i.e.: OVMF uses the value in the GPT header to find the backup instead
of finding the last sector.  It doesn't complain that it isn't the
last sector.

This image is just a test image that I can use with both QEMU and
Oracle's VMBox so I don't have to have two separate images.

I believe I have all of the information and the new/correct files
and can boot my code with these new files.

Thank you so much for your help and advice.  I appreciate the
effort you placed on my behalf.  

Thanks,
Ben
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] EmbeddedPkg/Library: Add Missing ARM defines for ACPI 6.0.

2016-10-06 Thread Supreeth Venkatesh 
1. Add Missing MADT ACPI 6.0 GIC Redistributor Init Macro.
2. Add Missing GTDT ACPI 6.0 Watchdog Timer Structure Init Macro.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Supreeth Venkatesh 
---
 EmbeddedPkg/Include/Library/AcpiLib.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/EmbeddedPkg/Include/Library/AcpiLib.h 
b/EmbeddedPkg/Include/Library/AcpiLib.h
index 704a2cd..a34d20e 100644
--- a/EmbeddedPkg/Include/Library/AcpiLib.h
+++ b/EmbeddedPkg/Include/Library/AcpiLib.h
@@ -76,6 +76,11 @@
 GicMsiFrameId, PhysicalBaseAddress, Flags, SPICount, SPIBase \
   }
 
+#define EFI_ACPI_6_0_GIC_REDISTRIBUTOR_INIT(RedisRegionAddr, RedisDiscLength) \
+  { \
+EFI_ACPI_6_0_GICR, sizeof (EFI_ACPI_6_0_GICR_STRUCTURE), 0, 
RedisRegionAddr, RedisDiscLength \
+  }
+
 //
 // SBSA Generic Watchdog
 //
@@ -87,6 +92,14 @@
 WatchdogTimerGSIV, WatchdogTimerFlags  
 \
   }
 
+#define 
EFI_ACPI_6_0_SBSA_GENERIC_WATCHDOG_STRUCTURE_INIT(RefreshFramePhysicalAddress,  
\
+ControlFramePhysicalAddress, WatchdogTimerGSIV, WatchdogTimerFlags)
 \
+  {
 \
+EFI_ACPI_6_0_GTDT_SBSA_GENERIC_WATCHDOG, 
sizeof(EFI_ACPI_6_0_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE), \
+EFI_ACPI_RESERVED_WORD, RefreshFramePhysicalAddress, 
ControlFramePhysicalAddress,   \
+WatchdogTimerGSIV, WatchdogTimerFlags  
 \
+  }
+
 typedef
 BOOLEAN
 (EFIAPI *EFI_LOCATE_ACPI_CHECK) (
-- 
2.8.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

2016-10-06 Thread Shah, Tapan 
Reviewed-by: Tapan Shah 


-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com] 
Sent: Thursday, October 06, 2016 5:02 PM
To: edk2-devel@lists.01.org; Shah, Tapan ; 
jaben.car...@intel.com
Cc: Vladimir Olovyannikov 
Subject: [PATCH] ShellPkg: Fix erroneous Status returned by 
ShellOpenFileByName()

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function should 
return that error immediately. However, this return was missing, and if 
UnicodeCollationProtocol has not been located by this time, the Status gets 
overwritten with LocateProtocol() call result, which eventually erroneously 
returns EFI_SUCCESS to the Shell.c, and this leads to attempt to execute a 
non-existent startup script, which fails, and which in turn leads to Shell 
being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..8db18b3b210f 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,9 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;
+}
 
 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid, NULL, 
(VOID**)&mUnicodeCollationProtocol);
--
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

2016-10-06 Thread Vladimir Olovyannikov 
In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function
should return that error immediately. However, this return was missing,
and if UnicodeCollationProtocol has not been located by this time, the
Status gets overwritten with LocateProtocol() call result, which
eventually erroneously returns EFI_SUCCESS to the Shell.c, and this
leads to attempt to execute a non-existent startup script, which fails,
and which in turn leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..8db18b3b210f 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,9 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;
+}
 
 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid, NULL, 
(VOID**)&mUnicodeCollationProtocol);
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

2016-10-06 Thread Vladimir Olovyannikov 
-Original Message-
From: Shah, Tapan [mailto:tapands...@hpe.com]
Sent: Thursday, October 06, 2016 2:52 PM
To: Vladimir Olovyannikov; edk2-devel@lists.01.org; jaben.car...@intel.com
Cc: Vladimir Olovyannikov
Subject: RE: [PATCH] ShellPkg: Fix erroneous Status returned by
ShellOpenFileByName()

+if (EFI_ERROR(Status)) {
+  return Status;
+}  Missing closing brace


Right. Please disregard this, will resubmit.

Reviewed-by: Tapan Shah 

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
Sent: Thursday, October 06, 2016 4:40 PM
To: edk2-devel@lists.01.org; Shah, Tapan ;
jaben.car...@intel.com
Cc: Vladimir Olovyannikov ; Vladimir Olovyannikov

Subject: [PATCH] ShellPkg: Fix erroneous Status returned by
ShellOpenFileByName()

From: Vladimir Olovyannikov 

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function should
return that error immediately. However, this return was missing, and if
UnicodeCollationProtocol has not been located by this time, the Status
gets overwritten with LocateProtocol() call result, which eventually
erroneously returns EFI_SUCCESS to the Shell.c, and this leads to attempt
to execute a non-existent startup script, which fails, and which in turn
leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..6fa67a3e751c 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,8 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;

 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid,
NULL, (VOID**)&mUnicodeCollationProtocol);
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

2016-10-06 Thread Shah, Tapan 
+if (EFI_ERROR(Status)) {
+  return Status;
+}  Missing closing brace

Reviewed-by: Tapan Shah 

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com] 
Sent: Thursday, October 06, 2016 4:40 PM
To: edk2-devel@lists.01.org; Shah, Tapan ; 
jaben.car...@intel.com
Cc: Vladimir Olovyannikov ; Vladimir Olovyannikov 

Subject: [PATCH] ShellPkg: Fix erroneous Status returned by 
ShellOpenFileByName()

From: Vladimir Olovyannikov 

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function should 
return that error immediately. However, this return was missing, and if 
UnicodeCollationProtocol has not been located by this time, the Status gets 
overwritten with LocateProtocol() call result, which eventually erroneously 
returns EFI_SUCCESS to the Shell.c, and this leads to attempt to execute a 
non-existent startup script, which fails, and which in turn leads to Shell 
being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..6fa67a3e751c 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,8 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;
 
 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid, NULL, 
(VOID**)&mUnicodeCollationProtocol);
--
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

2016-10-06 Thread Vladimir Olovyannikov 
From: Vladimir Olovyannikov 

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function
should return that error immediately. However, this return was missing,
and if UnicodeCollationProtocol has not been located by this time, the
Status gets overwritten with LocateProtocol() call result, which
eventually erroneously returns EFI_SUCCESS to the Shell.c, and this
leads to attempt to execute a non-existent startup script, which fails,
and which in turn leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..6fa67a3e751c 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,8 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;
 
 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid, NULL, 
(VOID**)&mUnicodeCollationProtocol);
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of UefiShellLib constructor

2016-10-06 Thread Vladimir Olovyannikov 
OK, will do

-Original Message-
From: Shah, Tapan [mailto:tapands...@hpe.com]
Sent: Thursday, October 06, 2016 1:05 PM
To: Vladimir Olovyannikov; Carsey, Jaben; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate
out of UefiShellLib constructor

Can you send a patch file with this error check added @726 ?

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
Sent: Thursday, October 06, 2016 2:58 PM
To: Carsey, Jaben ; Shah, Tapan
; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate
out of UefiShellLib constructor

Hi Carsey, Tapan,

This change breaks our platform's UEFI Shell at runtime (no asserts) :

...
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.

Error: Image at 000B97CF000 start failed: Invalid Parameter

remove-symbol-file
/uefi/Build/NS2Pkg/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/Shell/DEB
UG/Shell.dll 0xB97CF000

Image Return Status = Invalid Parameter


UnicodeCollation protocol is present.
Attempt to open fs1:startup.nsh which is not present.

There is a bug in UefiShellLib.c ShellOpenFileByName() which has nothing to
do to this commit.

723 Status = gEfiShellProtocol->OpenFileByName(FileName,
   FileHandle,
   OpenMode);

If there is no file available, the status is EFI_NOT_FOUND.
Line 726 (or 727) of the UefiShellLib.c must be

if (EFI_ERROR(Status)) {
  return Status;
}

But it is missing, and therefore EFI_SUCCESS is returned to the Shell.c from
ShellFindFilePath() (line 1228 of Shell.c), which leads to an attempt to run
a non-existent script which fails, and this leads to Shell unloading with
"Invalid parameter".

Thank you,
Vladimir

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Carsey, Jaben
Sent: Wednesday, October 05, 2016 3:20 PM
To: Tapan Shah; edk2-devel@lists.01.org
Cc: Carsey, Jaben
Subject: Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate
out of UefiShellLib constructor

And pushed.
Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016 1:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Tapan Shah
> 
> Subject: [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out
> of UefiShellLib constructor
> Importance: High
>
> Move gEfiUnicodeCollation2ProtocolGuid protocol outside of
> UefiShellLib constructor function.
> Locate gEfiUnicodeCollation2ProtocolGuid protocol in
> ShellOpenFileByName() which
> consumes this protocol API.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index e47d535..53f54e1 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -292,18 +292,12 @@ ShellLibConstructor (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> -  EFI_STATUS  Status;
> -
>mEfiShellEnvironment2   = NULL;
>gEfiShellProtocol   = NULL;
>gEfiShellParametersProtocol = NULL;
>mEfiShellInterface  = NULL;
>mEfiShellEnvironment2Handle = NULL;
> -
> -  if (mUnicodeCollationProtocol == NULL) {
> -Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid,
NULL,
> (VOID**)&mUnicodeCollationProtocol);
> -ASSERT_EFI_ERROR (Status);
> -  }
> +  mUnicodeCollationProtocol   = NULL;
>
>//
>// verify that auto initialize is not set false @@ -730,6 +724,14
> @@ ShellOpenFileByName(
> FileHandle,
> OpenMode);
>
> +if (mUnicodeCollationProtocol == NULL) {
> +  Status = gBS->LocateProtocol
> + (&gEfiUnicodeCollation2ProtocolGuid,
> NULL, (VOID**)&mUnicodeCollationProtocol);
> +  if (EFI_ERROR (Status)) {
> +gEfiShellProtocol->CloseFile (*FileHandle);
> +return Status;
> +  }
> +}
> +
>  if ((mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NUL") != 0) &&
>  (mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NULL") != 0) &&
>   !EFI_ERROR(Status) && ((OpenMode & EFI_FILE_MODE_CREATE) !=
0)){
> --
> 1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of UefiShellLib constructor

2016-10-06 Thread Shah, Tapan 
Can you send a patch file with this error check added @726 ?

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com] 
Sent: Thursday, October 06, 2016 2:58 PM
To: Carsey, Jaben ; Shah, Tapan ; 
edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out 
of UefiShellLib constructor

Hi Carsey, Tapan,

This change breaks our platform's UEFI Shell at runtime (no asserts) :

...
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.

Error: Image at 000B97CF000 start failed: Invalid Parameter

remove-symbol-file
/uefi/Build/NS2Pkg/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/Shell/DEB
UG/Shell.dll 0xB97CF000

Image Return Status = Invalid Parameter


UnicodeCollation protocol is present.
Attempt to open fs1:startup.nsh which is not present.

There is a bug in UefiShellLib.c ShellOpenFileByName() which has nothing to do 
to this commit.

723 Status = gEfiShellProtocol->OpenFileByName(FileName,
   FileHandle,
   OpenMode);

If there is no file available, the status is EFI_NOT_FOUND.
Line 726 (or 727) of the UefiShellLib.c must be

if (EFI_ERROR(Status)) {
  return Status;
}

But it is missing, and therefore EFI_SUCCESS is returned to the Shell.c from 
ShellFindFilePath() (line 1228 of Shell.c), which leads to an attempt to run a 
non-existent script which fails, and this leads to Shell unloading with 
"Invalid parameter".

Thank you,
Vladimir

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Wednesday, October 05, 2016 3:20 PM
To: Tapan Shah; edk2-devel@lists.01.org
Cc: Carsey, Jaben
Subject: Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out 
of UefiShellLib constructor

And pushed.
Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016 1:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Tapan Shah 
> 
> Subject: [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out 
> of UefiShellLib constructor
> Importance: High
>
> Move gEfiUnicodeCollation2ProtocolGuid protocol outside of 
> UefiShellLib constructor function.
> Locate gEfiUnicodeCollation2ProtocolGuid protocol in
> ShellOpenFileByName() which
> consumes this protocol API.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index e47d535..53f54e1 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -292,18 +292,12 @@ ShellLibConstructor (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> -  EFI_STATUS  Status;
> -
>mEfiShellEnvironment2   = NULL;
>gEfiShellProtocol   = NULL;
>gEfiShellParametersProtocol = NULL;
>mEfiShellInterface  = NULL;
>mEfiShellEnvironment2Handle = NULL;
> -
> -  if (mUnicodeCollationProtocol == NULL) {
> -Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid,
NULL,
> (VOID**)&mUnicodeCollationProtocol);
> -ASSERT_EFI_ERROR (Status);
> -  }
> +  mUnicodeCollationProtocol   = NULL;
>
>//
>// verify that auto initialize is not set false @@ -730,6 +724,14 
> @@ ShellOpenFileByName(
> FileHandle,
> OpenMode);
>
> +if (mUnicodeCollationProtocol == NULL) {
> +  Status = gBS->LocateProtocol 
> + (&gEfiUnicodeCollation2ProtocolGuid,
> NULL, (VOID**)&mUnicodeCollationProtocol);
> +  if (EFI_ERROR (Status)) {
> +gEfiShellProtocol->CloseFile (*FileHandle);
> +return Status;
> +  }
> +}
> +
>  if ((mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NUL") != 0) &&
>  (mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NULL") != 0) &&
>   !EFI_ERROR(Status) && ((OpenMode & EFI_FILE_MODE_CREATE) !=
0)){
> --
> 1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of UefiShellLib constructor

2016-10-06 Thread Vladimir Olovyannikov 
Hi Carsey, Tapan,

This change breaks our platform's UEFI Shell at runtime (no asserts) :

...
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.

Error: Image at 000B97CF000 start failed: Invalid Parameter

remove-symbol-file
/uefi/Build/NS2Pkg/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/Shell/DEB
UG/Shell.dll 0xB97CF000

Image Return Status = Invalid Parameter


UnicodeCollation protocol is present.
Attempt to open fs1:startup.nsh which is not present.

There is a bug in UefiShellLib.c ShellOpenFileByName() which has nothing
to do to this commit.

723 Status = gEfiShellProtocol->OpenFileByName(FileName,
   FileHandle,
   OpenMode);

If there is no file available, the status is EFI_NOT_FOUND.
Line 726 (or 727) of the UefiShellLib.c must be

if (EFI_ERROR(Status)) {
  return Status;
}

But it is missing, and therefore EFI_SUCCESS is returned to the Shell.c
from ShellFindFilePath() (line 1228 of Shell.c),
which leads to an attempt to run a non-existent script which fails, and
this leads to Shell unloading with "Invalid parameter".

Thank you,
Vladimir

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Carsey, Jaben
Sent: Wednesday, October 05, 2016 3:20 PM
To: Tapan Shah; edk2-devel@lists.01.org
Cc: Carsey, Jaben
Subject: Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol
locate out of UefiShellLib constructor

And pushed.
Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016 1:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Tapan Shah
> 
> Subject: [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of
> UefiShellLib constructor
> Importance: High
>
> Move gEfiUnicodeCollation2ProtocolGuid protocol outside of UefiShellLib
> constructor
> function.
> Locate gEfiUnicodeCollation2ProtocolGuid protocol in
> ShellOpenFileByName() which
> consumes this protocol API.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index e47d535..53f54e1 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -292,18 +292,12 @@ ShellLibConstructor (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> -  EFI_STATUS  Status;
> -
>mEfiShellEnvironment2   = NULL;
>gEfiShellProtocol   = NULL;
>gEfiShellParametersProtocol = NULL;
>mEfiShellInterface  = NULL;
>mEfiShellEnvironment2Handle = NULL;
> -
> -  if (mUnicodeCollationProtocol == NULL) {
> -Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid,
NULL,
> (VOID**)&mUnicodeCollationProtocol);
> -ASSERT_EFI_ERROR (Status);
> -  }
> +  mUnicodeCollationProtocol   = NULL;
>
>//
>// verify that auto initialize is not set false
> @@ -730,6 +724,14 @@ ShellOpenFileByName(
> FileHandle,
> OpenMode);
>
> +if (mUnicodeCollationProtocol == NULL) {
> +  Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid,
> NULL, (VOID**)&mUnicodeCollationProtocol);
> +  if (EFI_ERROR (Status)) {
> +gEfiShellProtocol->CloseFile (*FileHandle);
> +return Status;
> +  }
> +}
> +
>  if ((mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NUL") != 0) &&
>  (mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NULL") != 0) &&
>   !EFI_ERROR(Status) && ((OpenMode & EFI_FILE_MODE_CREATE) !=
0)){
> --
> 1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 0/5] QuarkPlatformPkg: Fix BOOT_IN_RECOVERY_MODE issues

2016-10-06 Thread Michael Kinney 
This patch series addresses the following 3 issues in Bugzilla:

https://bugzilla.tianocore.org/show_bug.cgi?id=137
https://bugzilla.tianocore.org/show_bug.cgi?id=138
https://bugzilla.tianocore.org/show_bug.cgi?id=139

It also removes a function and library that are no longer used.

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 

Michael Kinney (5):
  QuarkPlatformPkg/ForceRecovery: Add UEFI application to force recovery
  QuarkPlatformPkg/PlatformInit: Fix recovery detection issues
  QuarkPlatformPkg/PlatformHelperLib: Remove PlatformDebugPortGetChar8()
  QuarkPlatformPkg: Add ForceRecovery UEFI application
  QuarkPlatformPkg/RecoveryOemHookLib: Remove RecoveryOemHookLib

 .../Application/ForceRecovery/ForceRecovery.c  |  53 ++
 .../Application/ForceRecovery/ForceRecovery.inf|  39 +++
 .../Include/Library/PlatformHelperLib.h|  16 +--
 .../Include/Library/RecoveryOemHookLib.h   |  45 -
 .../Library/PlatformHelperLib/PlatformHelperLib.c  |  27 -
 .../Library/RecoveryOemHookLib/CommonHeader.h  |  30 --
 .../RecoveryOemHookLib/RecoveryOemHookLib.c|  61 ---
 .../RecoveryOemHookLib/RecoveryOemHookLib.inf  |  49 -
 .../Platform/Pei/PlatformInit/BootMode.c   |  89 ++--
 .../Platform/Pei/PlatformInit/CommonHeader.h   |   4 +-
 .../Platform/Pei/PlatformInit/MrcWrapper.c | 112 +
 .../Platform/Pei/PlatformInit/MrcWrapper.h |  11 +-
 .../Platform/Pei/PlatformInit/PlatformEarlyInit.c  |  67 +++-
 .../Pei/PlatformInit/PlatformEarlyInit.inf |   1 -
 QuarkPlatformPkg/Quark.dsc |   6 +-
 QuarkPlatformPkg/QuarkMin.dsc  |   1 -
 16 files changed, 196 insertions(+), 415 deletions(-)
 create mode 100644 QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.c
 create mode 100644 QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.inf
 delete mode 100644 QuarkPlatformPkg/Include/Library/RecoveryOemHookLib.h
 delete mode 100644 QuarkPlatformPkg/Library/RecoveryOemHookLib/CommonHeader.h
 delete mode 100644 
QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.c
 delete mode 100644 
QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.inf

-- 
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 3/5] QuarkPlatformPkg/PlatformHelperLib: Remove PlatformDebugPortGetChar8()

2016-10-06 Thread Michael Kinney 
Remove the library function PlatformDebugPortGetChar8() from the
PlatformHelperLib that is no longer used by any modules.

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 .../Include/Library/PlatformHelperLib.h| 16 +
 .../Library/PlatformHelperLib/PlatformHelperLib.c  | 27 --
 2 files changed, 1 insertion(+), 42 deletions(-)

diff --git a/QuarkPlatformPkg/Include/Library/PlatformHelperLib.h 
b/QuarkPlatformPkg/Include/Library/PlatformHelperLib.h
index 7b4119d..cf884e1 100644
--- a/QuarkPlatformPkg/Include/Library/PlatformHelperLib.h
+++ b/QuarkPlatformPkg/Include/Library/PlatformHelperLib.h
@@ -1,7 +1,7 @@
 /** @file
 PlatformHelperLib function prototype definitions.
 
-Copyright (c) 2013 - 2016 Intel Corporation.
+Copyright (c) 2013 - 2016 Intel Corporation.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -46,20 +46,6 @@ PlatformFindFvFileRawDataSection (
   );
 
 /**
-  Read 8bit character from debug stream.
-
-  Block until character is read.
-
-  @return 8bit character read from debug stream.
-
-**/
-CHAR8
-EFIAPI
-PlatformDebugPortGetChar8 (
-  VOID
-  );
-
-/**
   Find free spi protect register and write to it to protect a flash region.
 
   @param   DirectValue  Value to directly write to register.
diff --git a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperLib.c 
b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperLib.c
index f9ceda4..768ea14 100644
--- a/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperLib.c
+++ b/QuarkPlatformPkg/Library/PlatformHelperLib/PlatformHelperLib.c
@@ -91,33 +91,6 @@ WriteFirstFreeSpiProtect (
 //
 
 /**
-  Read 8bit character from debug stream.
-
-  Block until character is read.
-
-  @return 8bit character read from debug stream.
-
-**/
-CHAR8
-EFIAPI
-PlatformDebugPortGetChar8 (
-  VOID
-  )
-{
-  CHAR8 Got;
-
-  do {
-if (SerialPortPoll ()) {
-  if (SerialPortRead ((UINT8 *) &Got, 1) == 1) {
-break;
-  }
-}
-  } while (TRUE);
-
-  return Got;
-}
-
-/**
   Clear SPI Protect registers.
 
   @retval EFI_SUCCESSSPI protect registers cleared.
-- 
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 5/5] QuarkPlatformPkg/RecoveryOemHookLib: Remove RecoveryOemHookLib

2016-10-06 Thread Michael Kinney 
Remove the RecoveryOemHookLib class and instance that is no
longer used by any modules.

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 .../Include/Library/RecoveryOemHookLib.h   | 45 
 .../Library/RecoveryOemHookLib/CommonHeader.h  | 30 ---
 .../RecoveryOemHookLib/RecoveryOemHookLib.c| 61 --
 .../RecoveryOemHookLib/RecoveryOemHookLib.inf  | 49 -
 4 files changed, 185 deletions(-)
 delete mode 100644 QuarkPlatformPkg/Include/Library/RecoveryOemHookLib.h
 delete mode 100644 QuarkPlatformPkg/Library/RecoveryOemHookLib/CommonHeader.h
 delete mode 100644 
QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.c
 delete mode 100644 
QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.inf

diff --git a/QuarkPlatformPkg/Include/Library/RecoveryOemHookLib.h 
b/QuarkPlatformPkg/Include/Library/RecoveryOemHookLib.h
deleted file mode 100644
index ea265ad..000
--- a/QuarkPlatformPkg/Include/Library/RecoveryOemHookLib.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/** @file
-This library includes the recovery function that can be customized by OEM,
-including how to select the recovery capsule if more than one capsule found,
-and security check.
-
-Copyright (c) 2013-2015 Intel Corporation.
-
-This program and the accompanying materials
-are licensed and made available under the terms and conditions of the BSD 
License
-which accompanies this distribution.  The full text of the license may be 
found at
-http://opensource.org/licenses/bsd-license.php
-
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#ifndef __RECOVERY_OEM_HOOK_LIB_H__
-#define __RECOVERY_OEM_HOOK_LIB_H__
-
-/**
-  This function allows the user to force a system recovery
-
-**/
-VOID
-EFIAPI
-OemInitiateRecovery (
-  VOID
-  );
-
-/**
-  This function allows the user to force a system recovery and deadloop.
-
-  Deadloop required since system should not execute beyond this point.
-  Deadloop should never happen since OemInitiateRecovery () called within
-  this routine should never return since it executes a Warm Reset.
-
-**/
-VOID
-EFIAPI
-OemInitiateRecoveryAndWait (
-  VOID
-  );
-
-#endif
diff --git a/QuarkPlatformPkg/Library/RecoveryOemHookLib/CommonHeader.h 
b/QuarkPlatformPkg/Library/RecoveryOemHookLib/CommonHeader.h
deleted file mode 100644
index 7902254..000
--- a/QuarkPlatformPkg/Library/RecoveryOemHookLib/CommonHeader.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/** @file
-Common header file shared by all source files.
-
-This file includes package header files, library classes and protocol, PPI & 
GUID definitions.
-
-Copyright (c) 2013-2015 Intel Corporation.
-
-This program and the accompanying materials
-are licensed and made available under the terms and conditions of the BSD 
License
-which accompanies this distribution.  The full text of the license may be 
found at
-http://opensource.org/licenses/bsd-license.php
-
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-**/
-
-#ifndef __COMMON_HEADER_H_
-#define __COMMON_HEADER_H_
-
-
-
-#include 
-
-#include 
-
-#include 
-#include 
-#include 
-
-#endif
diff --git a/QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.c 
b/QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.c
deleted file mode 100644
index 28e8b11..000
--- a/QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.c
+++ /dev/null
@@ -1,61 +0,0 @@
-/** @file
-This file includes the function that can be customized by OEM.
-
-Copyright (c) 2013-2015 Intel Corporation.
-
-This program and the accompanying materials
-are licensed and made available under the terms and conditions of the BSD 
License
-which accompanies this distribution.  The full text of the license may be 
found at
-http://opensource.org/licenses/bsd-license.php
-
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "CommonHeader.h"
-
-/**
-  This function allows the user to force a system recovery
-
-**/
-VOID
-EFIAPI
-OemInitiateRecovery (
-  VOID
-  )
-{
-  UINT32  Data32;
-
-  //
-  // Set 'B_CFG_STICKY_RW_FORCE_RECOVERY' sticky bit so we know we need to do 
a recovery following warm reset
-  //
-  Data32 = QNCAltPortRead (QUARK_SCSS_SOC_UNIT_SB_PORT_ID, 
QUARK_SCSS_SOC_UNIT_CFG_STICKY_RW);
-  Data32 |= B_CFG_STICKY_RW_FORCE_RECOVERY;
-  QNCAltPortWrite (QUARK_SCSS_SOC_UNIT_SB_PORT_ID, 
QUARK_SCSS_SOC_UNIT_CFG_STICKY_RW, Data32);
-
-  //
-  // Initialte the warm reset
-  //
-  ResetWarm ();
-}
-
-/**
-  This function allows the user to force a system recovery and deadloop.
-
-  Deadloop required since system should not execute beyond this point.
-  D

[edk2] [Patch 1/5] QuarkPlatformPkg/ForceRecovery: Add UEFI application to force recovery

2016-10-06 Thread Michael Kinney 
https://bugzilla.tianocore.org/show_bug.cgi?id=138

This UEFI Application sets a sticky bit that persists across reset
to force a boot mode of BOOT_IN_RECOVERY_MODE.  It then performs
a warm reset using the UEFI Runtime Service ResetSystem().

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 .../Application/ForceRecovery/ForceRecovery.c  | 53 ++
 .../Application/ForceRecovery/ForceRecovery.inf| 39 
 2 files changed, 92 insertions(+)
 create mode 100644 QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.c
 create mode 100644 QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.inf

diff --git a/QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.c 
b/QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.c
new file mode 100644
index 000..82912b9
--- /dev/null
+++ b/QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.c
@@ -0,0 +1,53 @@
+/** @file
+  Application that sets a sticky bit to force recovery on next reset.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+
+#include 
+#include 
+
+/**
+  The user Entry Point for Application. The user code starts with this function
+  as the real entry point for the application.
+
+  @param[in] ImageHandleThe firmware allocated handle for the EFI image.
+  @param[in] SystemTableA pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The entry point is executed successfully.
+  @retval other Some error occurs when executing this entry point.
+
+**/
+EFI_STATUS
+EFIAPI
+UefiMain (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  //
+  // Set 'B_CFG_STICKY_RW_FORCE_RECOVERY' sticky bit so we know we need to do 
a recovery following warm reset
+  //
+  QNCAltPortWrite (
+QUARK_SCSS_SOC_UNIT_SB_PORT_ID,
+QUARK_SCSS_SOC_UNIT_CFG_STICKY_RW,
+QNCAltPortRead (QUARK_SCSS_SOC_UNIT_SB_PORT_ID, 
QUARK_SCSS_SOC_UNIT_CFG_STICKY_RW) | B_CFG_STICKY_RW_FORCE_RECOVERY
+);
+
+  //
+  // Do a warm reset
+  //
+  gRT->ResetSystem (EfiResetWarm, EFI_SUCCESS, 0, NULL);
+
+  return EFI_SUCCESS;
+}
diff --git a/QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.inf 
b/QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.inf
new file mode 100644
index 000..e0d174e
--- /dev/null
+++ b/QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.inf
@@ -0,0 +1,39 @@
+## @file
+#  Application that sets a sticky bit to force recovery on next reset.
+#
+#  Copyright (c) 2016, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = ForceRecovery
+  FILE_GUID  = 3A61FD45-69A0-42AD-B261-24DA451BF442
+  MODULE_TYPE= UEFI_APPLICATION
+  VERSION_STRING = 1.0
+  ENTRY_POINT= UefiMain
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32
+#
+
+[Sources]
+  ForceRecovery.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  QuarkSocPkg/QuarkSocPkg.dec
+
+[LibraryClasses]
+  UefiApplicationEntryPoint
+  UefiRuntimeServicesTableLib
+  QNCAccessLib
-- 
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 2/5] QuarkPlatformPkg/PlatformInit: Fix recovery detection issues

2016-10-06 Thread Michael Kinney 
https://bugzilla.tianocore.org/show_bug.cgi?id=137
https://bugzilla.tianocore.org/show_bug.cgi?id=139

There are four supported methods to generate a boot mode of
BOOT_IN_RECOVERY_MODE on the Galileo platforms:

* Detect a corrupt FV
* Detect a forced recovery from the ForceRecovery UEFI application
  that sets a bit in a sticky R/W register
* The RESET button for the Arduino shield is held while the system
  is powered up
* The RESET button for the Arduino shield is held while the system
  is rebooted using the REBOOT button.

The logic in the PlatformInit module is cleaned up and updated to
support all three of the recovery detection methods.  The clean
ups include:

* Remove extra debug messages
* Remove user input from serial port

In addition, once one of the recovery methods is detected and a
boot mode of BOOT_IN_RECOVERY_MODE is set, the Galileo platforms
would get an error attempting to use the USB host controller to
detect and read a recovery image from a USB drive.  The issue is
the IMR protection registers are programmed to prevent DMA to
memory owned by the PEI Core. The IMR register programming is
updated to allow DMA to memory that is allocated by the recovery
modules using the PEI AllocatePages() service.

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 .../Platform/Pei/PlatformInit/BootMode.c   |  89 ++--
 .../Platform/Pei/PlatformInit/CommonHeader.h   |   4 +-
 .../Platform/Pei/PlatformInit/MrcWrapper.c | 112 +
 .../Platform/Pei/PlatformInit/MrcWrapper.h |  11 +-
 .../Platform/Pei/PlatformInit/PlatformEarlyInit.c  |  67 +++-
 .../Pei/PlatformInit/PlatformEarlyInit.inf |   1 -
 6 files changed, 98 insertions(+), 186 deletions(-)

diff --git a/QuarkPlatformPkg/Platform/Pei/PlatformInit/BootMode.c 
b/QuarkPlatformPkg/Platform/Pei/PlatformInit/BootMode.c
index 0dd3d24..215f8f0 100644
--- a/QuarkPlatformPkg/Platform/Pei/PlatformInit/BootMode.c
+++ b/QuarkPlatformPkg/Platform/Pei/PlatformInit/BootMode.c
@@ -120,19 +120,6 @@ ValidateFvHeader (
 }
 
 /**
-
-  Check whether go to recovery path
-  @retval TRUE  Go to recovery path
-  @retval FALSE Go to normal path
-
-**/
-BOOLEAN
-OemRecoveryBootMode ()
-{
-  return PlatformIsBootWithRecoveryStage1 ();
-}
-
-/**
   Peform the boot mode determination logic
   If the box is closed, then
 1. If it's first time to boot, it's boot with full config .
@@ -154,31 +141,35 @@ UpdateBootMode (
   EFI_STATUS  Status;
   EFI_BOOT_MODE   NewBootMode;
   PEI_CAPSULE_PPI *Capsule;
-  CHAR8   UserSelection;
-  UINT32  Straps32;
+  UINT32  RegValue;
+
+  NewBootMode = *BootMode;
 
   //
-  // Read Straps. Used later if recovery boot.
+  // Read Sticky R/W Bits
   //
-  Straps32 = QNCAltPortRead (QUARK_SCSS_SOC_UNIT_SB_PORT_ID, 
QUARK_SCSS_SOC_UNIT_STPDDRCFG);
+  RegValue = QNCAltPortRead (QUARK_SCSS_SOC_UNIT_SB_PORT_ID, 
QUARK_SCSS_SOC_UNIT_CFG_STICKY_RW);
+  DEBUG ((EFI_D_ERROR, "RegValue = %08x\n", RegValue));
 
   //
   // Check if we need to boot in recovery mode
   //
-  if ((ValidateFvHeader (BootMode) != EFI_SUCCESS)) {
-DEBUG ((EFI_D_INFO, "Force Boot mode recovery\n"));
+  if ((RegValue & B_CFG_STICKY_RW_FORCE_RECOVERY) != 0) {
 NewBootMode = BOOT_IN_RECOVERY_MODE;
-Status = PeiServicesInstallPpi (&mPpiListRecoveryBootMode);
-ASSERT_EFI_ERROR (Status);
-if (OemRecoveryBootMode () == FALSE) {
-  DEBUG ((EFI_D_INFO, "Recovery stage1 not Active, reboot to activate 
recovery stage1 image\n"));
-  OemInitiateRecoveryAndWait ();
-}
-  } else if (OemRecoveryBootMode ()) {
-DEBUG ((EFI_D_INFO, "Boot mode recovery\n"));
+DEBUG ((EFI_D_ERROR, "RECOVERY from sticky bit\n"));;
+
+//
+// Clear force recovery sticky bit
+//
+QNCAltPortWrite (
+  QUARK_SCSS_SOC_UNIT_SB_PORT_ID,
+  QUARK_SCSS_SOC_UNIT_CFG_STICKY_RW,
+  RegValue &(~B_CFG_STICKY_RW_FORCE_RECOVERY)
+  );
+
+  } else if (ValidateFvHeader (BootMode) != EFI_SUCCESS) {
 NewBootMode = BOOT_IN_RECOVERY_MODE;
-Status = PeiServicesInstallPpi (&mPpiListRecoveryBootMode);
-ASSERT_EFI_ERROR (Status);
+DEBUG ((EFI_D_ERROR, "RECOVERY from corrupt FV\n"));;
   } else if (QNCCheckS3AndClearState ()) {
 //
 // Determine if we're in capsule update mode
@@ -217,41 +208,17 @@ UpdateBootMode (
   NewBootMode = BOOT_WITH_FULL_CONFIGURATION;
 }
   }
-  *BootMode = NewBootMode;
-  Status = PeiServicesSetBootMode (NewBootMode);
-  ASSERT_EFI_ERROR (Status);
 
-  //
-  // If Recovery Boot then prompt the user to insert a USB key with recovery 
nodule and
-  // continue with the recovery. Also give the user a chance to retry a normal 
boot.
-  //
   if (NewBootMode == BOOT_IN_RECOVERY_MODE) {
-if ((Straps32 & B_STPDDRCFG_FORCE_RECOVERY) == 0) {
-  DEBUG ((EFI_D_ERROR, 
"*

[edk2] [Patch 4/5] QuarkPlatformPkg: Add ForceRecovery UEFI application

2016-10-06 Thread Michael Kinney 
https://bugzilla.tianocore.org/show_bug.cgi?id=138

Add the ForceRecovery UEFI application to the Quark.dsc file
so this application can be put onto an SD card or USB drive
to test the Galileo firmware recovery feature.

The library mappings to the RecoveryOemHookLib are also
removed becuse this library is not longer used by any modules.

Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 QuarkPlatformPkg/Quark.dsc| 6 +-
 QuarkPlatformPkg/QuarkMin.dsc | 1 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/QuarkPlatformPkg/Quark.dsc b/QuarkPlatformPkg/Quark.dsc
index 51a7b63..d5988da 100644
--- a/QuarkPlatformPkg/Quark.dsc
+++ b/QuarkPlatformPkg/Quark.dsc
@@ -221,7 +221,6 @@
   #
   # Quark Platform
   #
-  
RecoveryOemHookLib|QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.inf
   PlatformSecLib|QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLib.inf
   
PlatformPcieHelperLib|QuarkPlatformPkg/Library/PlatformPcieHelperLib/PlatformPcieHelperLib.inf
   
PlatformHelperLib|QuarkPlatformPkg/Library/PlatformHelperLib/DxePlatformHelperLib.inf
@@ -863,6 +862,11 @@
   }
 !endif
 
+  #
+  # Force Recovery Application
+  #
+  QuarkPlatformPkg/Application/ForceRecovery/ForceRecovery.inf
+
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
diff --git a/QuarkPlatformPkg/QuarkMin.dsc b/QuarkPlatformPkg/QuarkMin.dsc
index 99ae067..1a4bd30 100644
--- a/QuarkPlatformPkg/QuarkMin.dsc
+++ b/QuarkPlatformPkg/QuarkMin.dsc
@@ -190,7 +190,6 @@
   #
   # Quark Platform
   #
-  
RecoveryOemHookLib|QuarkPlatformPkg/Library/RecoveryOemHookLib/RecoveryOemHookLib.inf
   PlatformSecLib|QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLib.inf
   
PlatformPcieHelperLib|QuarkPlatformPkg/Library/PlatformPcieHelperLib/PlatformPcieHelperLib.inf
   
PlatformHelperLib|QuarkPlatformPkg/Library/PlatformHelperLib/DxePlatformHelperLib.inf
-- 
2.6.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TE relocations

2016-10-06 Thread valerij zaporogeci 
Thank you.

 > So I have to ask why are you so interested in TE?

I wanted to use it for the Pei Core file and Peim's. One of the
machines I want to target my UEFI fw on has only 14KB SRAM available,
so I thought it would be nice there. But ok, that machine is MIPS SBC
and I did nothing yet for it. :) Other ARM targets have more SRAM. By
the way, are there chances that UEFI specification will add official
support for the MIPS architecture?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Urgent help -UefiBootManagerLib and LegacyBootManagerLib issue

2016-10-06 Thread Laszlo Ersek 
On 10/06/16 09:28, Saqib Khan wrote:
> Hi Andrew,
> 
> I think I did not address my problem well in my previous email.Please take
> a minute again to understand my problem.
> 
> here is my scenario
> 
>  have following  lib added to my *.inf file
> [LibraryClasses]
>   HiiLib
>   DebugLib
>   UefiLib
>   MemoryAllocationLib
>   UefiBootServicesTableLib
>   UefiApplicationEntryPoint
> 
> *UefiBootManagerLib  LegacyBootManagerLib*
>   UefiShellLib
> 
> And here is piece of code I am trying to compile
> 
> EfiBootManagerConnectAll ();
> EfiBootManagerRefreshAllBootOption ();
> 
> BootOption = EfiBootManagerGetLoadOptions (&BootOptionCount,
> LoadOptionTypeBoot);
> 
> Status = gBS->LocateProtocol (&gEfiLegacyBiosProtocolGuid, NULL, (VOID **)
> &LegacyBios);
> 
> it Compiles successfully but EFI hangs at
> 
> *EfiBootManagerRefreshAllBootOption () *
> When I remove * LegacyBootManagerLib* Libraries it does not hang
> 
> I think I missing something in it may be i need to add CSM libraries in my
> EFI?
> 
> I also tried NULL library resolution in DuetPkgx64.dsc like this
> 
> MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf {
> 
> 
> NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
> 
>   }
> 
> 
> If you still think that is a CSM issue then i will be go for another system
> as i am doing my development on physical system.
> 
> 
> *Thank you*

Andrew understood your problem just fine, and gave the correct answer.

(1) As I explained to you in one of my previous emails (or, well, I at
least alluded to it), namely in

  https://lists.01.org/pipermail/edk2-devel/2016-September/001799.html

LegacyBootManagerLib is a *plugin* for UefiBootManagerLib. That is, a
library to be used with NULL library class resolution in whatever driver
or application that you already use UefiBootManagerLib in. (If you know
that your module will always need LegacyBootManagerLib, then you can
explicitly specify it in your INF file too.)

(2) If you do not add LegacyBootManagerLib to your application like
explained above, then the following will happen:

- UefiBootManagerLib's EfiBootManagerRegisterLegacyBootSupport()
function will never be called,

- therefore UefiBootManagerLib's mBmRefreshLegacyBootOption global
variable will remain NULL,

- therefore EfiBootManagerRefreshAllBootOption() will never call
(*mBmRefreshLegacyBootOption)().

(3) In comprison, if you *do* add LegacyBootManagerLib to your
application, then the following will happen:

- LegacyBootManagerLib's constructor function, namely
LegacyBootManagerLibConstructor(), will call
EfiBootManagerRegisterLegacyBootSupport(), with the following two
function pointers:
  - LegacyBmRefreshAllBootOption
  - LegacyBmBoot

- In turn, UefiBootManagerLib's mBmRefreshLegacyBootOption will be set
to LegacyBmRefreshAllBootOption

- In turn, EfiBootManagerRefreshAllBootOption() will call
LegacyBmRefreshAllBootOption(), through the mBmRefreshLegacyBootOption
function pointer.

This is exactly what's happening in your case; it's just that
LegacyBmRefreshAllBootOption() -- in file
"IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBm.c" --
does not return.

(4) Why not? You can find out simply by adding DEBUG statements to the
function, and see how far it proceeds. But, as Andrew already said, the
only real suspect in that function is

  Status = LegacyBios->CheckPciRom (
 LegacyBios,
 HandleBuffer[Index],
 NULL,
 NULL,
 &Flags
 );

which calls into your CSM. So, if that's the function call that doesn't
return -- and it likely is --, then the CSM you use has the bug.

(5) For the future: please don't give up tracking down bugs so easily.
This time you stopped as early as

>mBmRefreshLegacyBootOption ();  //this method does not return

- Well, did you try to see what mBmRefreshLegacyBootOption was? Is there
a function declared with this name, somewhere in the tree? Well, no.

- Is mBmRefreshLegacyBootOption a function pointer? Yes.

- Okay, where is the function pointer set then? In
EfiBootManagerRegisterLegacyBootSupport().

- So what calls EfiBootManagerRegisterLegacyBootSupport()? The
LegacyBootManagerLibConstructor() function, in file
"IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBm.c".

- What arguments does LegacyBootManagerLibConstructor() pass? In
particular, it passes the address of the function
LegacyBmRefreshAllBootOption().

- And now you know what the function call

>mBmRefreshLegacyBootOption ();  //this method does not return

*actually* does, you can add DEBUG statements to it, and track it to the
LegacyBios->CheckPciRom() call that invokes your CSM.

Laszlo


> 
> On Thu, Oct 6, 2016 at 2:37 AM, Andrew Fish  wrote:
> 
>>
>>> On Oct 5, 2016, at 2:23 PM, Saqib Khan  wrote:
>>>
>>>
>>>
>>> Hi all,i need urgent help regarding this

Re: [edk2] [Patch V2] BaseTools: support the NOOPT target with the GCC tool chains

2016-10-06 Thread Ard Biesheuvel 
On 6 October 2016 at 09:19, Laszlo Ersek  wrote:
> On 10/06/16 00:39, Bruce Cran wrote:
>> On 10/04/2016 07:30 PM, Yonghong Zhu wrote:
>>
>>> Update the tools_def.template to add NOOPT support with GCC tool chains.
>>>
>>> Cc: Liming Gao 
>>> Cc: Laszlo Ersek 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Yonghong Zhu 
>>
>> Reviewed-by: Bruce Cran 
>> Tested-by: Bruce Cran 
>>
>> Tested with both GCC49 and GCC5 toolchain settings (using gcc 6.2.1 for
>> both) and verified that both have functional debugging, though gdb skips
>> around with GCC5 as expected due to LTCG.
>>
>
> Right; as I mentioned up-thread, I wonder if we should disable -flto and -Os 
> in NOOPT_GCC5_IA32_DLINK_FLAGS and NOOPT_GCC5_X64_DLINK_FLAGS.
>
> How about we add the following to Yonghong's v2?
> - first, move "-flto" from GCC5_IA32_X64_DLINK_FLAGS and GCC5_X64_DLINK_FLAGS 
> to the users of those macros (both GCC5- and CLANG38-related users exist),
> - second, for the GCC5 users of these macros: split them into 
> DEBUG/RELEASE/NOOPT, and remove -Os from NOOPT.
>
> The end result is that none of the earlier macro values change, except for 
> NOOPT_GCC5_(IA32|X64)_DLINK_FLAGS; those two lose both -flto and -Os, which 
> is our purpose. This would eliminate the skipping around that you mention.
>
> What do you guys think? See the patch below (again, to be applied on top of 
> Yonghong's v2, or to be squashed into it).
>

I agree. If we are going through the trouble of having a separate
NOOPT flavor, it should at least do what it says on the tin. If it
skips around, using it has no advantage over using DEBUG
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2] BaseTools: support the NOOPT target with the GCC tool chains

2016-10-06 Thread Laszlo Ersek 
On 10/06/16 00:39, Bruce Cran wrote:
> On 10/04/2016 07:30 PM, Yonghong Zhu wrote:
> 
>> Update the tools_def.template to add NOOPT support with GCC tool chains.
>>
>> Cc: Liming Gao 
>> Cc: Laszlo Ersek 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Yonghong Zhu 
> 
> Reviewed-by: Bruce Cran 
> Tested-by: Bruce Cran 
> 
> Tested with both GCC49 and GCC5 toolchain settings (using gcc 6.2.1 for
> both) and verified that both have functional debugging, though gdb skips
> around with GCC5 as expected due to LTCG.
> 

Right; as I mentioned up-thread, I wonder if we should disable -flto and -Os in 
NOOPT_GCC5_IA32_DLINK_FLAGS and NOOPT_GCC5_X64_DLINK_FLAGS.

How about we add the following to Yonghong's v2?
- first, move "-flto" from GCC5_IA32_X64_DLINK_FLAGS and GCC5_X64_DLINK_FLAGS 
to the users of those macros (both GCC5- and CLANG38-related users exist),
- second, for the GCC5 users of these macros: split them into 
DEBUG/RELEASE/NOOPT, and remove -Os from NOOPT.

The end result is that none of the earlier macro values change, except for 
NOOPT_GCC5_(IA32|X64)_DLINK_FLAGS; those two lose both -flto and -Os, which is 
our purpose. This would eliminate the skipping around that you mention.

What do you guys think? See the patch below (again, to be applied on top of 
Yonghong's v2, or to be squashed into it).

Thanks!
Laszlo

---
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2c0dcd67b906..60b2c2578f8d 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4477,9 +4477,9 @@ DEFINE GCC5_IA32_CC_FLAGS= 
DEF(GCC49_IA32_CC_FLAGS) -flto -fno-built
 DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto 
-fno-builtin -DUSING_LTO

 DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)

 DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)

-DEFINE GCC5_IA32_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) -flto

+DEFINE GCC5_IA32_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS)

 DEFINE GCC5_IA32_DLINK2_FLAGS= DEF(GCC49_IA32_DLINK2_FLAGS) -Wno-error

-DEFINE GCC5_X64_DLINK_FLAGS  = DEF(GCC49_X64_DLINK_FLAGS) -flto

+DEFINE GCC5_X64_DLINK_FLAGS  = DEF(GCC49_X64_DLINK_FLAGS)

 DEFINE GCC5_X64_DLINK2_FLAGS = DEF(GCC49_X64_DLINK2_FLAGS) -Wno-error

 DEFINE GCC5_ASM_FLAGS= DEF(GCC49_ASM_FLAGS)

 DEFINE GCC5_ARM_ASM_FLAGS= DEF(GCC49_ARM_ASM_FLAGS)

@@ -5288,7 +5288,6 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
DEF(GCC49_AARCH64_DLINK_FLAGS)
 *_GCC5_IA32_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto

 *_GCC5_IA32_ASLDLINK_FLAGS   = DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
-Wl,-m,elf_i386

 *_GCC5_IA32_ASM_FLAGS= DEF(GCC5_ASM_FLAGS) -m32 -march=i386

-*_GCC5_IA32_DLINK_FLAGS  = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Os 
-Wl,-m,elf_i386,--oformat=elf32-i386

 *_GCC5_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)

 *_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)

 *_GCC5_IA32_OBJCOPY_FLAGS=

@@ -5298,6 +5297,10 @@ RELEASE_GCC49_AARCH64_DLINK_FLAGS  = 
DEF(GCC49_AARCH64_DLINK_FLAGS)
 RELEASE_GCC5_IA32_CC_FLAGS   = DEF(GCC5_IA32_CC_FLAGS) -Os 
-Wno-unused-but-set-variable

   NOOPT_GCC5_IA32_CC_FLAGS   = DEF(GCC5_IA32_CC_FLAGS) -O0

 

+  DEBUG_GCC5_IA32_DLINK_FLAGS= DEF(GCC5_IA32_X64_DLINK_FLAGS) 
-Wl,-m,elf_i386,--oformat=elf32-i386 -flto -Os

+RELEASE_GCC5_IA32_DLINK_FLAGS= DEF(GCC5_IA32_X64_DLINK_FLAGS) 
-Wl,-m,elf_i386,--oformat=elf32-i386 -flto -Os

+  NOOPT_GCC5_IA32_DLINK_FLAGS= DEF(GCC5_IA32_X64_DLINK_FLAGS) 
-Wl,-m,elf_i386,--oformat=elf32-i386

+

 ##

 # GCC5 X64 definitions

 ##

@@ -5316,7 +5319,6 @@ RELEASE_GCC5_IA32_CC_FLAGS   = 
DEF(GCC5_IA32_CC_FLAGS) -Os -Wno-unused-but-s
 *_GCC5_X64_ASLCC_FLAGS   = DEF(GCC_ASLCC_FLAGS) -m64 -fno-lto

 *_GCC5_X64_ASLDLINK_FLAGS= DEF(GCC5_IA32_X64_ASLDLINK_FLAGS) 
-Wl,-m,elf_x86_64

 *_GCC5_X64_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m64

-*_GCC5_X64_DLINK_FLAGS   = DEF(GCC5_X64_DLINK_FLAGS) -Os

 *_GCC5_X64_DLINK2_FLAGS  = DEF(GCC5_X64_DLINK2_FLAGS)

 *_GCC5_X64_RC_FLAGS  = DEF(GCC_X64_RC_FLAGS)

 *_GCC5_X64_OBJCOPY_FLAGS =

@@ -5326,6 +5328,10 @@ RELEASE_GCC5_IA32_CC_FLAGS   = 
DEF(GCC5_IA32_CC_FLAGS) -Os -Wno-unused-but-s
 RELEASE_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) 
-Wno-unused-but-set-variable

   NOOPT_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -O0

 

+  DEBUG_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os

+RELEASE_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os

+  NOOPT_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS)

+

 ##

 # GCC5 ARM definitions

 ##

@@ -5516,7 +5522,7 @@ DEFINE CLANG38_ALL_CC_FLAGS = 
DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body -f
 *_CLAN

Re: [edk2] OVMF.fd and placement of EfiBootServicesData

2016-10-06 Thread Laszlo Ersek 
On 10/06/16 07:45, spam collector wrote:
> - Original Message -
>> From: "Laszlo Ersek" 
>> To: "spam collector" 
>> Cc: edk2-de...@ml01.01.org
>> Sent: Wednesday, October 5, 2016 8:28:46 AM
>> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
>>
>> I recommend trying the following (32-bit command line), with Gerd's package:
>>
>>   FW_BIN=/usr/share/edk2.git/ovmf-ia32/OVMF_CODE-pure-efi.fd
>>   VARS_TMPL=/usr/share/edk2.git/ovmf-ia32/OVMF_VARS-pure-efi.fd
>>   VARS=myvars.fd
>>   SHELL_ISO=/usr/share/edk2.git/ovmf-ia32/UefiShell.iso
>>   if ! [ -e "$VARS" ]; then
>> cp -v -- "$VARS_TMPL" "$VARS"
>>   fi
>>
>>   qemu-system-i386 \
>> -m 2048 \
>> -machine accel=kvm \
>> \
>> -drive if=pflash,format=raw,unit=0,readonly,file="$FW_BIN" \
>> -drive if=pflash,format=raw,unit=1,file="$VARS" \
>> \
>> -device virtio-scsi-pci,id=scsi0 \
>> -drive if=none,format=raw,readonly,file="$SHELL_ISO",id=shell \
>> -device scsi-cd,bus=scsi0.0,drive=shell,bootindex=1 \
>> \
>> -chardev file,id=debugfile,path=ovmf.log \
>> -device isa-debugcon,iobase=0x402,chardev=debugfile
>>
>> This will boot the shell for you, and even save the OVMF debug log in
>> the file "ovmf.log".
> 
> I used the following command line (again, a WinXP DOS Session .BAT file):
> 
> "..\qemu-system-i386w.exe" -m 256 -drive 
> if=pflash,format=raw,unit=0,readonly,file=..\OVMF_CODE.fd -drive 
> if=pflash,format=raw,unit=1,file=..\OVMF_VARS.fd -device 
> virtio-scsi-pci,id=scsi0 -drive 
> if=none,format=raw,readonly,file=..\UefiShell.iso,id=shell -device 
> scsi-cd,bus=scsi0.0,drive=shell,bootindex=1 
> -chardev file,id=debugfile,path=ovmf.log -device 
> isa-debugcon,iobase=0x402,chardev=debugfile -drive 
> file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0
> 
> The shell booted up as expected.  However, my BOOT.efi file is now a:
> 
>   "image is not an application"
> 
> I don't think I mentioned before, my BOOT.efi is an OS loader, not 
> a UEFI driver or other type application.

(A UEFI_DRIVER module is *not* an application.)

> Sorry, I should have mentioned
> that earlier, hope that did not confuse you.
> 
> My BOOT.efi file has a value of 0x0B as the Subsystem value.
> 
>PE Optional Header: Subsystem: 0x000B
> 
> I removed the UefiShell.iso part:
> 
> "..\qemu-system-i386w.exe" -m 256 -drive 
> if=pflash,format=raw,unit=0,readonly,file=..\OVMF_CODE.fd -drive 
> if=pflash,format=raw,unit=1,file=..\OVMF_VARS.fd -device 
> virtio-scsi-pci,id=scsi0 -chardev 
> file,id=debugfile,path=ovmf.log -device 
> isa-debugcon,iobase=0x402,chardev=debugfile -drive 
> file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0
> 
> and the shell was loaded, with the same result, "not an application".

Based on "MdePkg/Include/IndustryStandard/PeImage.h":

- Subsystem type 0xb (11 decimal) seems to correspond to
EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER. If your module is an
application however (and a boot loader is usually an application), it
should have EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION (= 0xa, 10 decimal).

- You might want to double-check if the bitnesses match (you can't
launch an IMAGE_FILE_MACHINE_I386 (0x014c) image on the X64 and Ia32X64
builds of OVMF, nor an IMAGE_FILE_MACHINE_X64 (0x8664) image on the Ia32
build).

Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] OVMF.fd and placement of EfiBootServicesData

2016-10-06 Thread Laszlo Ersek 
On 10/06/16 05:05, spam collector wrote:
> - Original Message -
>> From: "Laszlo Ersek" 
>> To: "spam collector" 
>> Cc: edk2-de...@ml01.01.org
>> Sent: Wednesday, October 5, 2016 8:28:46 AM
>> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
>>
>> On 10/05/16 04:47, spam collector wrote:
>>>
>>> - Original Message -
 From: "Laszlo Ersek" 
 To: "spam collector" 
 Cc: edk2-de...@ml01.01.org
 Sent: Tuesday, October 4, 2016 10:22:34 AM
 Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData
>>
 * The first stage improvement is the following command line:

   qemu-system-x86_64 -pflash OVMF.fd
>>>
>>> This did not work either with or without the NvVars file present.
>>
>> I think I'll need a more complete issue riport then -- what is your
>> exact QEMU command line, and what OVMF binary are you using?
> 
> "..\qemu-system-i386w.exe" -m 256 -localtime 
>   -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 
>   -pflash ..\OVMF.fd -parallel file:para.txt
> 
> Remember that I am running this in WinXPSP3.

First, I can't "remember" it, because this is the first time you state
that. :)

Second, WinXPSP3 as host machine, really?... :)

Anyway, if both your QEMU and OVMF builds are okay / fresh enough, using
OVMF with TCG (i.e., not KVM) should work, yes.

> Also, the version of
> OVMF.fd is from http://www.tianocore.org/ovmf/ and I just noticed
> that that page has been recently changed.

That's a coincidence, but not a random one. Users have been repeatedly
confused by the r15214 binary, which at this point was more than 2.5
years old. Just before your query, I noticed
 (and marked it invalid);
the reporter of that issue was also tripped up by the ancient r15214
build. So I asked Jordan to please update the page you reference, with a
link to Gerd's RPMs, which are bleeding edge builds.

> You use to be able to 
> download the OVMF.fd directly from that page.  It was r15214, which 
> I found out yesterday, is an older version.
> 
>>>  I did find a few RPM files and one of them contained:
>>>   OVMF_CODE-pure-efi.fd
>>>  and
>>>   OVMF_VARS-pure-efi.fd
>>
>> Yes, they are from Gerd's "edk2.git-ovmf-ia32" package (since you
>> mention IA32), from , and they are
>> recommended to use.
> 
> I also could not get these to work.  I will do a little more 
> research into why not and be sure to let you know.
> 
>> Otherwise, download the "edk2.git-ovmf-ia32" or "edk2.git-ovmf-x64" RPM
>> file (as needed) from , and
>> extract it with:
>>
>>   rpm2cpio FILENAME | pax -r -v
>>
>> The extracted files you want are:
>>
>>   usr/share/edk2.git/ovmf-*/OVMF_CODE-pure-efi.fd
>>   usr/share/edk2.git/ovmf-*/OVMF_VARS-pure-efi.fd
>>   usr/share/edk2.git/ovmf-*/UefiShell.iso
> 
> These are the three files I used and could not get the shell to load.
> I will try a few other things and get back with you.
> 
> Please note that I am using the Windows port of QEMU from 
> https://qemu.weilnetz.de/ on a WinXP host, if that makes any 
> difference.

It could make a difference. I've never ever used Windows binaries of
QEMU. OTOH several people on this list have used such with success, so I
can't say definitely either way.

> 
> Also, one more question.  I can make my GPT image either have a legacy
> MBR with two entries pointing to one partition each or I can have a
> Protected MBR that encompasses the whole GPT, both partitions, and the
> backup items.
> 
> With the r15214 version and:
> 
> "..\qemu-system-i386w.exe" -m 256 -localtime 
>   -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 
>   -bios ..\OVMF.fd -parallel file:para.txt
> 
> it would boot to the shell either way and load and run my BOOT.efi file
> just fine, whether I had a Legacy MBR or a PMBR.  Does this make a
> difference with the new image(s) you mention above.

Sorry, I don't have any particular expertise with GPT. I believe the
PartitionDxe driver that's built into OVMF received some updates over
that 2.5y interval that I mentioned above.

> Also, please note that the hard drive image is a VHD image, a
> raw image with a single sector at the end for the VHD info so that
> Oracles VM Box will boot it.  This means that the backup GPT header
> is *not* the last sector of the disk.

As far as I know, QEMU supports VHDX. However, you pass a VHD image to
-drive with format=raw. That looks very broken. I guess I'd suggest
matching the actual image format with the format=... property. If you
pass format=raw, the VHD metadata at the end of the image will be
visible to the guest (as garbage).

>  The
> 
>   -bios OVMF.fd
> 
> version boots it just fine in QEMU, but I thought I would mention
> this in case the new code expects it to be in the last sector.

I'm quite certain all GPT drivers in the guest expect a valid disk
image, and format=raw, on a VHD disk image, seems

Re: [edk2] Urgent help -UefiBootManagerLib and LegacyBootManagerLib issue

2016-10-06 Thread Saqib Khan 
Hi Andrew,

I think I did not address my problem well in my previous email.Please take
a minute again to understand my problem.

here is my scenario

 have following  lib added to my *.inf file
[LibraryClasses]
  HiiLib
  DebugLib
  UefiLib
  MemoryAllocationLib
  UefiBootServicesTableLib
  UefiApplicationEntryPoint

*UefiBootManagerLib  LegacyBootManagerLib*
  UefiShellLib

And here is piece of code I am trying to compile

EfiBootManagerConnectAll ();
EfiBootManagerRefreshAllBootOption ();

BootOption = EfiBootManagerGetLoadOptions (&BootOptionCount,
LoadOptionTypeBoot);

Status = gBS->LocateProtocol (&gEfiLegacyBiosProtocolGuid, NULL, (VOID **)
&LegacyBios);

it Compiles successfully but EFI hangs at

*EfiBootManagerRefreshAllBootOption () *
When I remove * LegacyBootManagerLib* Libraries it does not hang

I think I missing something in it may be i need to add CSM libraries in my
EFI?

I also tried NULL library resolution in DuetPkgx64.dsc like this

MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf {


NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf

  }


If you still think that is a CSM issue then i will be go for another system
as i am doing my development on physical system.


*Thank you*

On Thu, Oct 6, 2016 at 2:37 AM, Andrew Fish  wrote:

>
> > On Oct 5, 2016, at 2:23 PM, Saqib Khan  wrote:
> >
> >
> >
> > Hi all,i need urgent help regarding this issue.
> >
>
>
> Saqib,
>
> You likely have a bug in your CSM. So that is your
> gEfiLegacyBiosProtocolGuid implementation and all the 16-bit legacy BIOS
> code.
>
> So you should contact the people you got your CSM from.
>
> Thanks,
>
> Andrew Fish
>
> >> On 05-Oct-2016, at 9:05 PM, Saqib Khan 
> wrote:
> >>
> >>
> >> I have found that  it just dont return from  mBmRefreshLegacyBootOption
> (); .
> >>
> >> have a look at code. let me know the possible cause of it ...
> >> I need urgent help
> >>
> >> EfiBootManagerRefreshAllBootOption (
> >>  VOID
> >>  )
> >> {
> >>  EFI_STATUSStatus;
> >>  EFI_BOOT_MANAGER_LOAD_OPTION  *NvBootOptions;
> >>  UINTN NvBootOptionCount;
> >>  EFI_BOOT_MANAGER_LOAD_OPTION  *BootOptions;
> >>  UINTN BootOptionCount;
> >>  UINTN Index;
> >>  Print(L"indside refresh\n");
> >>  //
> >>  // Optionally refresh the legacy boot option
> >>  //
> >>  if (mBmRefreshLegacyBootOption != NULL) {
> >>  Print(L"Before legacy refresh \n");
> >>mBmRefreshLegacyBootOption ();  //this method does not return
> >>Print(L"legacy refresh complete\n");
> >>  }
> >>
> >>> On Wed, Oct 5, 2016 at 5:51 PM, Saqib Khan 
> wrote:
> >>> Hi,
> >>>
> >>> when i import both lib in my project my EFI hangs at
> EfiRefreshAllBootOptions, i removed LegacyBootManager and it worked fine .i
> need both lib as i need to boot legacy from EFI, how this issue can be
> resolved?
> >>>
> >>>
> >>> here is piece of inf file
> >>>
> >>> [Packages]
> >>>  MdePkg/MdePkg.dec
> >>>  MdeModulePkg/MdeModulePkg.dec
> >>>  IntelFrameworkPkg/
> >>> IntelFrameworkPkg.dec
> >>>  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> >>>  ShellPkg/ShellPkg.dec
> >>>
> >>> [LibraryClasses]
> >>>  HiiLib
> >>>  DebugLib
> >>>  UefiLib
> >>>  MemoryAllocationLib
> >>>  UefiBootServicesTableLib
> >>>  UefiApplicationEntryPoint
> >>>  UefiBootManagerLib
> >>>  LegacyBootManagerLib
> >>>
> >>>
> >>> --
> >>> Regards
> >>> Saqib Ahmed Khanzada
> >>
> >>
> >>
> >> --
> >> Regards
> >> Saqib Ahmed Khanzada
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
>


-- 
Regards
Saqib Ahmed Khanzada
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform

2016-10-06 Thread Laszlo Ersek 
On 10/06/16 00:17, Carsey, Jaben wrote:
> Laszlo,
> 
> As Tim clarified, the API already fail when the shell protocol was
> not present and the shell already needs the UnicodeCollation
> protocol.
> 
> The goal here is not to allow the library to function without the
> shell protocol (and thereby the UnicodeCollation protocol).  The goal
> is to allow the constructor to complete successfully. So that a DXE
> driver (or other driver) can be loaded into memory and wait for the
> shell to be present to increase shell functionality.
> 
> The reasons is that a non-functional ShellOpenFileByName() in the
> time gap between them is ok since it will fail as soon as the lib
> calls into the shell anyways.  This was already true since the
> protocol was not present for the API to work with...

I got it now. Makes sense. Thanks!
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel