[edk2] [PATCH 1/7] ArmPkg/AsmMacroIoLibV8: remove undocumented assumption from ELx macros

[Ard Biesheuvel]

The macros EL1_OR_EL2() and EL1_OR_EL2_OR_EL3() allow conditional execution
of assembly sequences based on the current exception level, by jumping to
caller supplied labels 1f, 2f or 3f. However, the jump to 1f is actually
a fallthrough, which means the EL1 code needs to follow right after the
macro invocation, and the 1f label is ignored.

So let's fix this by making all jumps explicit.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Include/AsmMacroIoLibV8.h | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/ArmPkg/Include/AsmMacroIoLibV8.h b/ArmPkg/Include/AsmMacroIoLibV8.h
index a9f8491bc922..efc47d3bbbc7 100644
--- a/ArmPkg/Include/AsmMacroIoLibV8.h
+++ b/ArmPkg/Include/AsmMacroIoLibV8.h
@@ -25,9 +25,9 @@
 mrsSAFE_XREG, CurrentEL ;\
 cmpSAFE_XREG, #0x8  ;\
 b.eq   2f   ;\
-cmpSAFE_XREG, #0x4  ;\
-b.ne   .;// We should never get here
-// EL1 code starts here
+tbnz   SAFE_XREG, #2, 1f;\
+b  .;// We should never get here
+
 
 // CurrentEL : 0xC = EL3; 8 = EL2; 4 = EL1
 // This only selects between EL1 and EL2 and EL3, else we die.
@@ -36,11 +36,10 @@
 mrsSAFE_XREG, CurrentEL ;\
 cmpSAFE_XREG, #0xC  ;\
 b.eq   3f   ;\
-cmpSAFE_XREG, #0x8  ;\
-b.eq   2f   ;\
-cmpSAFE_XREG, #0x4  ;\
-b.ne   .;// We should never get here
-// EL1 code starts here
+tbnz   SAFE_XREG, #3, 2f;\
+tbnz   SAFE_XREG, #2, 1f;\
+b  .;// We should never get here
+
 #if defined(__clang__)
 
 // load x0 with _Data
-- 
2.5.0

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

Re: [edk2] [PATCH] MdePkg: add UNUSED notation to Base.h

[Laszlo Ersek]

On 03/18/16 15:48, Gao, Liming wrote:
> Laszlo:
> 
>   I understand the request to BaseTools is that AutoGen code can pass
> GCC or MSFT compiler without any warning. If so, EDKII module can enable
> non default warnings in itself. I will evaluate BaseTools.

Thank you!

>  And, you raise one issue that the different ARCHs have the different
> warning setting. I suggest to keep them consistent to avoid the
> different build results. How about adding -Wno-unused-but-set-variable
> option to AARCH64 DEBUG.

Can we move in the other direction perhaps? Can we remove
-Wno-unused-but-set-variable from the following settings:

- GCC46_IA32_CC_FLAGS
- GCC46_X64_CC_FLAGS

(these are inherited by the >= 4.6 GCC settings for IA32 and X64,)

- RELEASE_GCC46_ARM_CC_FLAGS
- RELEASE_GCC47_ARM_CC_FLAGS
- RELEASE_GCC47_AARCH64_CC_FLAGS
- RELEASE_GCC48_ARM_CC_FLAGS
- RELEASE_GCC48_AARCH64_CC_FLAGS
- RELEASE_GCC49_ARM_CC_FLAGS
- RELEASE_GCC49_AARCH64_CC_FLAGS

I believe all of the above settings include
"-Wno-unused-but-set-variable" only for the following reason:

When GCC46 was enabled in BaseTools, the "-Wall" option (which we do
enable as a basis) suddenly started including
"-Wunused-but-set-variable" too. Namely, that warning option was new in
the gcc-4.6 release, and "-Wall" by default included it:

https://gcc.gnu.org/gcc-4.6/changes.html

The edk2 tree wouldn't build with "-Wunused-but-set-variable"; so, in
order to expedite GCC46 enablement, the "-Wno-unused-but-set-variable"
was set. See commit 2bcc713e74b94.

However, in reality, the number of warnings triggered by this setting is
very low, in my testing -- just a handful. I listed them yesterday; the
following modules are affected (while building ArmVirtPkg and OvmfPkg):

- MdeModulePkg/Bus/Pci/PciHostBridgeDxe
- UefiCpuPkg/Library/MtrrLib
- UefiCpuPkg/PiSmmCpuDxeSmm

If I send a series that cleans up these warnings, would you agree (and
perhaps even test with your own platforms) to remove
"-Wno-unused-but-set-variable"?

I agree that we should unify the warning flags, but I think we should
move towards stricter warnings, not laxer warnings -- provided we can
adapt the tree more or less easily.

> Besides, Shumin is a young man. J

Thanks, I'll keep it in mind. :)

Laszlo

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

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[Kinney, Michael D]

David,

I responded to an earlier email:

==
I think there are several methods we can support for development.

1) Simple bug fixes/features sent directly to edk2-devel for PRs.
2) A larger or more complex bug fix/feature can optionally post a link
   to a branch on personal github fork to help simplify the review process 
   for those reviewers that prefer to use that method.  This type of bug 
   fix or feature is usually owned by a single subject matter expert.
3) A larger or more complex feature that requires design/dev/test by more
   than one subject matter expert.

We already support (1) and (2) today.  Feature branches on edk2-staging are 
intended for (3).

I can think of a couple ways we end up in (3). The first is a feature we know
requires multiple subject matter experts and the request is made to add
to edk2-staging from the beginning.  The second is a PR that is sent to 
edk2-devel, and the community believes it needs more design/dev/test work
that requires cooperation of multiple subject matter experts and the PR 
is re-directed to a feature branch in edk2-staging.
==

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David
> Woodhouse
> Sent: Wednesday, March 16, 2016 2:05 PM
> To: Mangefeste, Tony ; edk2-devel@lists.01.org 
>  de...@ml01.01.org>
> Subject: Re: [edk2] EDK2 Staging Proposal 3rd draft, final?
> 
> On Wed, 2016-03-16 at 20:17 +, Mangefeste, Tony wrote:
> >
> > Here's the 3rd iteration based on your input.  Please take one last
> > opportunity to review, we'll settle on this if there are no major
> > requests by Friday of this week.
> 
> I still haven't seen an answer to my question of what this buys us,
> over the normal process of having such submissions come via
> contributors' github repositories, with associated pull requests.
> 
> Why invent new processes and not just use the existing tools that are
> basically *designed* for this workflow?
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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

Re: [edk2] [PATCH v3] MdeModulePkg: Fixed incorrect return value of MatchString

[Zeng, Star]

On 2016/3/17 10:46, Zeng, Star wrote:

On 2016/3/17 10:23, Cecil Sheng wrote:

In UEFI2.6, CapturePtr's in the Captures array returned by MatchString
are to be separatedly allocated so that they can be freed by the
caller.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cecil Sheng 
Reviewed-by: Samer El-Haj-Mahmoud 


Reviewed-by: Star Zeng 


Pushed at 04c30dd5718d5f927b2ec31010032b2b5a714a2c.




Thanks for the effort.
Star


---
  .../RegularExpressionDxe/RegularExpressionDxe.c| 34
++
  1 file changed, 29 insertions(+), 5 deletions(-)

diff --git
a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
index cffbcb8..a5ee7d5 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
@@ -2,7 +2,7 @@

EFI_REGULAR_EXPRESSION_PROTOCOL Implementation

-  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP

This program and the accompanying materials are licensed and made
available
under the terms and conditions of the BSD License that accompanies
this
@@ -91,6 +91,10 @@ OnigurumaMatch (
CHAR8   ErrorMessage[ONIG_MAX_ERROR_MESSAGE_LEN];
UINT32  Index;
OnigUChar   *Start;
+  EFI_STATUS  Status;
+
+
+  Status = EFI_SUCCESS;

//
// Detemine the internal syntax type
@@ -102,7 +106,7 @@ OnigurumaMatch (
  OnigSyntax = ONIG_SYNTAX_PERL;
} else {
  DEBUG ((DEBUG_ERROR, "Unsupported regex syntax - using
default\n"));
-ASSERT (FALSE);
+return EFI_UNSUPPORTED;
}

//
@@ -143,6 +147,7 @@ OnigurumaMatch (
   Region,
   ONIG_OPTION_NONE
   );
+
if (OnigResult >= 0) {
  *Result = TRUE;
} else {
@@ -150,6 +155,9 @@ OnigurumaMatch (
  if (OnigResult != ONIG_MISMATCH) {
onig_error_code_to_str (ErrorMessage, OnigResult);
DEBUG ((DEBUG_ERROR, "Regex match failed: %a\n", ErrorMessage));
+  onig_region_free (Region, 1);
+  onig_free (OnigRegex);
+  return EFI_DEVICE_ERROR;
  }
}

@@ -158,14 +166,30 @@ OnigurumaMatch (
//
if (*Result && Captures != NULL) {
  *CapturesCount = Region->num_regs;
-*Captures = AllocatePool (*CapturesCount * sizeof(**Captures));
+*Captures = AllocateZeroPool (*CapturesCount * sizeof(**Captures));
  if (*Captures != NULL) {
for (Index = 0; Index < *CapturesCount; ++Index) {
  //
  // Region beg/end values represent bytes, not characters
  //
-(*Captures)[Index].CapturePtr = (CHAR16*)((UINTN)String +
Region->beg[Index]);
  (*Captures)[Index].Length = (Region->end[Index] -
Region->beg[Index]) / sizeof(CHAR16);
+(*Captures)[Index].CapturePtr = AllocateCopyPool (
+  ((*Captures)[Index].Length)
* sizeof (CHAR16),
+  (CHAR16*)((UINTN)String +
Region->beg[Index])
+  );
+if ((*Captures)[Index].CapturePtr == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  break;
+}
+  }
+
+  if (EFI_ERROR (Status)) {
+for (Index = 0; Index < *CapturesCount; ++Index) {
+  if ((*Captures)[Index].CapturePtr != NULL) {
+FreePool ((CHAR16*)(*Captures)[Index].CapturePtr);
+  }
+}
+FreePool (*Captures);
}
  }
}
@@ -173,7 +197,7 @@ OnigurumaMatch (
onig_region_free (Region, 1);
onig_free (OnigRegex);

-  return EFI_SUCCESS;
+  return Status;
  }

  /**



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

Re: [edk2] [PATCH v3] MdeModulePkg: Fixed incorrect return value of MatchString

[Zeng, Star]

On 2016/3/17 10:23, Cecil Sheng wrote:

In UEFI2.6, CapturePtr's in the Captures array returned by MatchString
are to be separatedly allocated so that they can be freed by the
caller.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cecil Sheng 
Reviewed-by: Samer El-Haj-Mahmoud 


Reviewed-by: Star Zeng 


Thanks for the effort.
Star


---
  .../RegularExpressionDxe/RegularExpressionDxe.c| 34 ++
  1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
index cffbcb8..a5ee7d5 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
@@ -2,7 +2,7 @@

EFI_REGULAR_EXPRESSION_PROTOCOL Implementation

-  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP

This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License that accompanies this
@@ -91,6 +91,10 @@ OnigurumaMatch (
CHAR8   ErrorMessage[ONIG_MAX_ERROR_MESSAGE_LEN];
UINT32  Index;
OnigUChar   *Start;
+  EFI_STATUS  Status;
+
+
+  Status = EFI_SUCCESS;

//
// Detemine the internal syntax type
@@ -102,7 +106,7 @@ OnigurumaMatch (
  OnigSyntax = ONIG_SYNTAX_PERL;
} else {
  DEBUG ((DEBUG_ERROR, "Unsupported regex syntax - using default\n"));
-ASSERT (FALSE);
+return EFI_UNSUPPORTED;
}

//
@@ -143,6 +147,7 @@ OnigurumaMatch (
   Region,
   ONIG_OPTION_NONE
   );
+
if (OnigResult >= 0) {
  *Result = TRUE;
} else {
@@ -150,6 +155,9 @@ OnigurumaMatch (
  if (OnigResult != ONIG_MISMATCH) {
onig_error_code_to_str (ErrorMessage, OnigResult);
DEBUG ((DEBUG_ERROR, "Regex match failed: %a\n", ErrorMessage));
+  onig_region_free (Region, 1);
+  onig_free (OnigRegex);
+  return EFI_DEVICE_ERROR;
  }
}

@@ -158,14 +166,30 @@ OnigurumaMatch (
//
if (*Result && Captures != NULL) {
  *CapturesCount = Region->num_regs;
-*Captures = AllocatePool (*CapturesCount * sizeof(**Captures));
+*Captures = AllocateZeroPool (*CapturesCount * sizeof(**Captures));
  if (*Captures != NULL) {
for (Index = 0; Index < *CapturesCount; ++Index) {
  //
  // Region beg/end values represent bytes, not characters
  //
-(*Captures)[Index].CapturePtr = (CHAR16*)((UINTN)String + 
Region->beg[Index]);
  (*Captures)[Index].Length = (Region->end[Index] - Region->beg[Index]) 
/ sizeof(CHAR16);
+(*Captures)[Index].CapturePtr = AllocateCopyPool (
+  ((*Captures)[Index].Length) * sizeof 
(CHAR16),
+  (CHAR16*)((UINTN)String + 
Region->beg[Index])
+  );
+if ((*Captures)[Index].CapturePtr == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  break;
+}
+  }
+
+  if (EFI_ERROR (Status)) {
+for (Index = 0; Index < *CapturesCount; ++Index) {
+  if ((*Captures)[Index].CapturePtr != NULL) {
+FreePool ((CHAR16*)(*Captures)[Index].CapturePtr);
+  }
+}
+FreePool (*Captures);
}
  }
}
@@ -173,7 +197,7 @@ OnigurumaMatch (
onig_region_free (Region, 1);
onig_free (OnigRegex);

-  return EFI_SUCCESS;
+  return Status;
  }

  /**



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

[edk2] [PATCH] BaseTools: Updated BuildNotes URLs

[Peter Kirmeier]

Updated URLs (git repository and step-by-step instructions)

CC: Yonghong Zhu 
CC: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Peter Kirmeier 
---
 BaseTools/BuildNotes.txt |  4 ++--
 BuildNotes2.txt  | 24 +---
 2 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/BaseTools/BuildNotes.txt b/BaseTools/BuildNotes.txt
index 045e8fc..31e4f3c 100644
--- a/BaseTools/BuildNotes.txt
+++ b/BaseTools/BuildNotes.txt
@@ -18,7 +18,7 @@ Windows:
 
 Unix-like:
   a) make -C /BaseTools
-  b) Look over https://edk2.tianocore.org/step-by-step-instructions.html
+  b) Look over 
https://github.com/tianocore/tianocore.github.io/wiki/Getting%20Started%20with%20EDK%20II
  for a helpful step-by-step guide for building 'Hello World' on
  various operating systems with edk2.
 
@@ -34,7 +34,7 @@ Tools in Python
 * Convert Python source to exe file
 
   The tools written in Python can be converted into executable program which 
can 
-  be executed without installing a Python interpreter.  (Generally it is easier
+  be executed without installing a Python interpreter. (Generally it is easier
   to run the scripts from their source on operating systems other than 
Windows.)
 
   For Windows and Linux, the conversion tool package is called cx_Freeze, its
diff --git a/BuildNotes2.txt b/BuildNotes2.txt
index 2c000f6..4552053 100644
--- a/BuildNotes2.txt
+++ b/BuildNotes2.txt
@@ -7,8 +7,8 @@ subsidiaries in the United States and other countries.
 * Other names and brands may be claimed as the property of others.
 Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.
 
-EDK II packages can be checked out from the following SVN address:
-https://svn.code.sf.net/p/edk2/code/trunk/edk2
+EDK II packages can be gathered from the following address:
+  https://github.com/tianocore/edk2.git
 
 The detailed introduction of these packages can be found in each package
 description file. (The *.dec file under the package directory)
@@ -17,7 +17,7 @@ description file. (The *.dec file under the package directory)
 ---
 The most recent version of the setup instructions is available on the EDK II
 web-site:
-  
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Step-by-step_instructions
+  
https://github.com/tianocore/tianocore.github.io/wiki/Getting%20Started%20with%20EDK%20II
 
 
 ---
@@ -54,18 +54,18 @@ the Supported Tool Chains comment.
 Alternatively, you may use the build command's -t option to specify a different
 tool chain tag name: build -t VS2008 ... , for example.  Using this method will
 require that you always use the build command's -t option. If you use 64-bit 
-windows OS, you should use tool chain tag name with x86, such as VS2008x86.
+Windows OS, you should use tool chain tag name with x86, such as VS2008x86.
 
 
-Next, go to the module directory and begin to build.  This example is for the
+Next, go to the module directory and begin to build. This example is for the
 HelloWorld application.
 
 c:\MyWork\edk2\> cd MdeModulePkg\Application\HelloWorld
 c:\MyWork\edk2\> build
 
 If you want to build the a module in another package (for example, 
-MdePkg\Library\BaseLib\BaseLib.inf), please edit the file,
-%WORKSPACE%\Conf\Target.txt, first.
+MdePkg\Library\BaseLib\BaseLib.inf), please edit the file
+%WORKSPACE%\Conf\Target.txt first.
 
 Change the following line
 ACTIVE_PLATFORM   = MdeModulePkg/MdeModulePkg.dsc
@@ -119,12 +119,10 @@ run   - Launch NT32 shell (only valid for NT32 
platform)
 Tools in Python
 ---
 
-* Run buld tool written in Python from source
-  The build tool written in Python can be executed from its source directly as
-  long as you have the Python interpreter (version 2.5.4) installed. The source
-  of Python code is locating at:
-
-https://svn.code.sf.net/p/edk2-buildtools/code/trunk/BaseTools
+* Run build tool written in Python from source
+  It can be executed from its source directly as long as you have the Python
+  interpreter (version 2.5.4) installed. The source code is located at
+  WORKSPACE/BaseTools.
 
   where:
 
-- 
2.7.2.windows.1

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

Re: [edk2] [PATCH] Ax88772b: Fixing compilation error variable set but not used

[Shivamurthy Shastri]

On 19 February 2016 at 18:06, Shivamurthy Shastri <
shivamurthy.shas...@linaro.org> wrote:

>
> On 19 February 2016 at 17:45, Laszlo Ersek  wrote:
>
>> On 02/19/16 13:04, Shivamurthy Shastri wrote:
>> > On 19 February 2016 at 16:30, Laszlo Ersek  wrote:
>> >
>> >> On 02/10/16 15:07, Shivamurthy Shastri wrote:
>> >>> error: pNicDevice variable set but not used
>> >>>
>> >>> Contributed-under: TianoCore Contribution Agreement 1.0
>> >>> Signed-off-by: Shivamurthy Shastri 
>> >>> ---
>> >>>  OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c | 2 --
>> >>>  1 file changed, 2 deletions(-)
>> >>>
>> >>> diff --git
>> a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
>> >> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
>> >>> index 9eeb61f..c061a6b 100644
>> >>> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
>> >>> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/SimpleNetwork.c
>> >>> @@ -700,10 +700,8 @@ SN_ReceiveFilters (
>> >>>EFI_SIMPLE_NETWORK_MODE * pMode;
>> >>>EFI_STATUS Status = EFI_SUCCESS;
>> >>>EFI_TPL TplPrevious;
>> >>> -  NIC_DEVICE * pNicDevice;
>> >>>
>> >>>TplPrevious = gBS->RaiseTPL(TPL_CALLBACK);
>> >>> -  pNicDevice = DEV_FROM_SIMPLE_NETWORK ( pSimpleNetwork );
>> >>>pMode = pSimpleNetwork->Mode;
>> >>>
>> >>>if (pSimpleNetwork == NULL) {
>> >>>
>> >>
>> >> As I said in the other (similar) thread, the subject should identify
>> the
>> >> top level package. It should go:
>> >>
>> >> OptionRomPkg: Ax88772b: ...
>> >>
>> >> Thanks
>> >> Laszlo
>> >>
>> >
>> > ​I will send new patch for that.
>>
>> If there are no other changes required for your patch(es), then the
>> maintainer who commits the patch(es) can fix up the subject(s) at commit
>> time. No need to resend just for the subject change.
>>
>> Thanks
>> Laszlo
>>
>>
> ​OK, Thanks for review.
> I will add ​Ruiyu Ni
>
>
​Hi Ruiyu Ni,

Please look into the patch.

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

Re: [edk2] [PATCH] MdePkg: add UNUSED notation to Base.h

[Kinney, Michael D]

Hello,

I am curious what value enabling the warning for an unused argument adds.  Can 
someone provide some examples where enabling this warning and adding the UNUSED 
tag addresses real issues?  I am concerned that we are enabling a warning that 
would impose a large number of source changes with little or no value.  I can 
be convinced otherwise, but would like to see some supporting data.

Also, what are the requirements for maintenance of code once if this new UNUSED 
macro is used?  We have function implementations where an argument may not be 
used today, but a bug fix/feature enhancement later may use the UNUSED 
argument.  Do we get a different warning because it was tagged as UNUSED, but 
it is actually used now? Or is that silent?

I think there are a few categories of functions to consider here:

1) Protocol/PPI functions.  The parameters for functions are defined for a wide 
usage sometimes with optional behavior.  Specific implementations may choose to 
not implement some optional behavior, and hence may not require some of the 
parameters.  I do not think a warning or an error should be generated by a 
conformant implementation that does not use a parameter.

2) Library Class functions.  The parameters for functions are also defined for 
a wide usage sometimes with optional behavior.  Specific implementations may 
choose to not implement optional behavior, and hence may not require some of 
the parameters.  I do not think a warning or an error should be generated by a 
specific library instance that does not use a parameter in a public library 
class API.

3) Internal functions.  If an internal function does not use a parameter, then 
remove the parameter from the function call.

Can we enable /Wall and disable this specific warning?  Or is there a concern 
that category (3) cannot be detected without enabling this warning?  Maybe it 
would be better if we could find a way to disable this warning for all APIs 
that are decorated with EFIAPI?

Thanks,

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, March 17, 2016 8:53 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> 
> Subject: [PATCH] MdePkg: add UNUSED notation to Base.h
> 
> To permit many existing platforms to build with -Wunused-parameter, on
> GCC and CLANG, the unused parameters need to be annotated as such.
> Existing regexp code already uses ARG_UNUSED for this, but it is really
> needed across the codebase - so add a version called UNUSED in Base.h.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm 
> ---
> 
> Change since RFC: rename ARG_UNUSED -> UNUSED.
> 
>  MdePkg/Include/Base.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> index 89b2aed..a68b209 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -189,6 +189,15 @@ struct _LIST_ENTRY {
>  ///
>  #define OPTIONAL
> 
> +///
> +/// Function argument intentionally unused in function.
> +///
> +#if defined(__GNUC__) || defined(__clang__)
> +  #define UNUSED  __attribute__ ((unused))
> +#else
> +  #define UNUSED
> +#endif
> +
>  //
>  //  UEFI specification claims 1 and 0. We are concerned about the
>  //  complier portability so we did it this way.
> --
> 2.1.4

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

Re: [edk2] [PATCH] OvmfPkg/PlatformPei: suppress wrong VS2008 warning (use of uninited local)

[Laszlo Ersek]

On 03/19/16 00:35, Laszlo Ersek wrote:
> VS2008 seems to think that the "PciExBarBase" variable (introduced in
> commit 7b8fe63561b4) can be evaluated for the
> AddReservedMemoryBaseSizeHob() function call with its value being
> uninitialized / indeterminate. This is not the case (see
> "mHostBridgeDevId"); suppress the warning.
> 
> Reported-by: David Woodhouse 
> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/8871/focus=9431
> Cc: David Woodhouse 
> Cc: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> - Public branch: https://github.com/lersek/edk2/commits/suppress_vs2008
> - Patch formatted with --function-context for easier review
> 
>  OvmfPkg/PlatformPei/Platform.c | 1 +
>  1 file changed, 1 insertion(+)

Committed / pushed as 02d6f4ce0c84f2d7e9abfcde2e092a5701ff33c4 (now with
the default (UTF-8) commit msg encoding...)

Thanks
Laszlo

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

Re: [edk2] signedness of CHAR8

[Laszlo Ersek]

On 03/17/16 13:16, Leif Lindholm wrote:
> So, as further fallout from my -Weverything experiments, I've come
> across this...
> 
> Ia32 and X64 ProcessorBind.h (BaseTools and MdePkg) both define CHAR8 as 
> 'char'.
> ARM and AArch64 both do the same.
> 
> However, default 'char' signedness is unsigned in the ARM
> architectures, and signed in the others.

In "BaseTools/Conf/tools_def.template", the ARM toolchains are
instructed to use signed chars.

DEFINE GCC_ARM_CC_FLAGS = ... -fsigned-char ...
DEFINE GCC_AARCH64_CC_FLAGS = ... -fsigned-char ...
DEFINE RVCT_ALL_CC_FLAGS = ... --signed_chars ...

> Meanwhile, the UEFI specification describes CHAR8 as
> ---
> 1-byte character. Unless otherwise specified, all 1-byte or ASCII characters 
> and
> strings are stored in 8-bit ASCII encoding format, using the
> ISO-Latin-1 character
> set.
> ---
> 
> Now, ISO-Latin-1 holds values all the way up to 255, which clearly
> does not fit into a signed 8-bit char.
> 
> Would I be correct in my interpretation that Ia32/X64 should be
> defining CHAR8 as 'unsigned char', or am I losing my mind?

ARM and AARCH64 seem to be consistent with Ia32 and X64 (when the latter
are built for with GCC), they all use signed chars.

However, that doesn't seem to match Latin1; a comparison like (ch1https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/7] ArmPkg/ArmExceptionLib: fold exception handler prologue into vector table

[Ard Biesheuvel]

Unlike the AArch32 vector table, which has room for a single instruction
for each exception type, the AArch64 exception table has 128 byte slots,
which can easily hold the shared prologues that are emitted out of line.

So refactor this code into a single macro, and expand it into each vector
table slot. Since the address of the command handler entry point is no
longer patched in by the C code, we can just emit the literal into each
vector entry directly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 112 
+++-
 1 file changed, 39 insertions(+), 73 deletions(-)

diff --git a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S 
b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
index 790ce009b8de..c47974b81e8b 100644
--- a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
+++ b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
@@ -99,8 +99,6 @@
 */
 
 GCC_ASM_EXPORT(ExceptionHandlersEnd)
-GCC_ASM_EXPORT(CommonExceptionEntry)
-GCC_ASM_EXPORT(AsmCommonExceptionEntry)
 GCC_ASM_EXPORT(CommonCExceptionHandler)
 
 .text
@@ -172,142 +170,110 @@ ASM_PFX(ExceptionHandlersStart):
 VECTOR_BASE(ExceptionHandlersStart)
 #endif
 
+#undef  REG_PAIR
+#undef  REG_ONE
+#define REG_PAIR(REG1, REG2, OFFSET, CONTEXT_SIZE)  stp  REG1, REG2, [sp, 
#(OFFSET-CONTEXT_SIZE)]
+#define REG_ONE(REG1, OFFSET, CONTEXT_SIZE) stur REG1, [sp, 
#(OFFSET-CONTEXT_SIZE)]
+
+  .macro  ExceptionEntry, val
+  // Move the stackpointer so we can reach our structure with the str 
instruction.
+  sub sp, sp, #(FP_CONTEXT_SIZE + SYS_CONTEXT_SIZE)
+
+  // Save all the General regs before touching x0 and x1.
+  // This does not save r31(SP) as it is special. We do that later.
+  ALL_GP_REGS
+
+  // Record the type of exception that occurred.
+  mov   x0, #\val
+
+  // Jump to our general handler to deal with all the common parts and process 
the exception.
+  ldr   x1, =ASM_PFX(CommonExceptionEntry)
+  brx1
+  .ltorg
+  .endm
+
 //
 // Current EL with SP0 : 0x0 - 0x180
 //
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SP0_SYNC)
 ASM_PFX(SynchronousExceptionSP0):
-  b   ASM_PFX(SynchronousExceptionEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SP0_IRQ)
 ASM_PFX(IrqSP0):
-  b   ASM_PFX(IrqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_IRQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SP0_FIQ)
 ASM_PFX(FiqSP0):
-  b   ASM_PFX(FiqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_FIQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SP0_SERR)
 ASM_PFX(SErrorSP0):
-  b   ASM_PFX(SErrorEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SERROR
 
 //
 // Current EL with SPx: 0x200 - 0x380
 //
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SPx_SYNC)
 ASM_PFX(SynchronousExceptionSPx):
-  b   ASM_PFX(SynchronousExceptionEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SPx_IRQ)
 ASM_PFX(IrqSPx):
-  b   ASM_PFX(IrqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_IRQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SPx_FIQ)
 ASM_PFX(FiqSPx):
-  b   ASM_PFX(FiqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_FIQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_CUR_SPx_SERR)
 ASM_PFX(SErrorSPx):
-  b   ASM_PFX(SErrorEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SERROR
 
 //
 // Lower EL using AArch64 : 0x400 - 0x580
 //
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A64_SYNC)
 ASM_PFX(SynchronousExceptionA64):
-  b   ASM_PFX(SynchronousExceptionEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A64_IRQ)
 ASM_PFX(IrqA64):
-  b   ASM_PFX(IrqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_IRQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A64_FIQ)
 ASM_PFX(FiqA64):
-  b   ASM_PFX(FiqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_FIQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A64_SERR)
 ASM_PFX(SErrorA64):
-  b   ASM_PFX(SErrorEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SERROR
 
 //
 // Lower EL using AArch32 : 0x600 - 0x780
 //
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A32_SYNC)
 ASM_PFX(SynchronousExceptionA32):
-  b   ASM_PFX(SynchronousExceptionEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A32_IRQ)
 ASM_PFX(IrqA32):
-  b   ASM_PFX(IrqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_IRQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A32_FIQ)
 ASM_PFX(FiqA32):
-  b   ASM_PFX(FiqEntry)
+  ExceptionEntry  EXCEPT_AARCH64_FIQ
 
 VECTOR_ENTRY(ExceptionHandlersStart, ARM_VECTOR_LOW_A32_SERR)
 ASM_PFX(SErrorA32):
-  b   ASM_PFX(SErrorEntry)
+  ExceptionEntry  EXCEPT_AARCH64_SERROR
 
 VECTOR_END(ExceptionHandlersStart)
 
-#undef  REG_PAIR
-#undef  REG_ONE
-#define REG_PAIR(REG1, REG2, OFFSET, CONTEXT_SIZE)  stp  REG1, RE

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[David Woodhouse]

On Fri, 2016-03-18 at 14:24 +0100, Laszlo Ersek wrote:
> Except my own actions. I'm already watching the github issue tracker and
> get emails of the actions of others. No emails about my own actions. It
> makes the email audit trail completely unusable.

That's your personal email notification. If it's set up to mail
everything to the list (even if we create a dummy github user for the
list, and subscribe it to everything), then that won't be an issue,
will it?

Actually, I just went poking about in the settings for repositories. I
see there appears to be a setting to disable merges by merge commit or
by squashing. If you turn those both off on a repository, what happens?
Does that not prevent the merges you were worried about, in either
form?

> I must have missed those discoverability criteria, apologies. In any
> case, I can hardly imagine anything more discoverable than a [PULL] on
> the mailing list.

I think the idea is you should be able to go to e web page and easily
find a list of the stuff that is currently outstanding.

Searching a mailing list for pull requests doesn't really help, because
there's no easy way to see which are merged and which are not.

Patchwork does that kind of thing for some projects, but I don't think
patchwork is the right tool for managing submissions which are intended
to be outstanding for some time, as they undergo refinement and testing
— like the OpenSSL one, for example. There's no way we want that until
the final 1.1 release but we *do* want people to be playing with it.


> I disagree. It is costly. We've had two unintended merges thus far (from
> incorrect command line usage), and they took me personally hours to
> analyze and explain.

I love you, Laszlo, and I *love* the fact that you will take hours to
analyse and explain things. You do it *very* well, and it has been
extremely useful to me and to a lot of other people.

But sometimes perhaps you need to resist the temptation to do it :)

Sometimes, stuff just broke and you just fix it up and move on. Let the
people who *did* it work it out for themselves and that actually forms
a *better* learning experience for them.

And as for committing trivial fixes without review... well, sometimes
it's better to ask for forgiveness than permission. We should never
allow a process to get in the way of getting real work done.

> The fact that these issues were introduced while using the git command
> line supports your point that such problems can occur "anyway". My point
> is that I would like to keep them as rare as possible, and github pull
> requests don't point in that direction.

As noted above, do you want to look in
https://github.com/tianocore/edk2/settings and try turning off the
'Allow merge commits with the merge button' and 'Allow squash merging
with the merge button' options? Or is that only for personal projects?
I don't see it in other github repositories that I have write access
to; only my own.

> If you are volunteering to analyze and undo unintended or incorrectly
> resolved merges from github pull reqs -- I have no further comments then.
> 
> > 
> > And the chances of the CRLF conversion one actually *applying* if
> > someone stupidly hits the button, after *one* more commit hits the
> > tree, are fairly much zero anyway. So you're defending against an
> > impossibility in that case.
> In this specific case, you are right. My point was to prevent building a
> precedent.
> 
> > 
> > I don't know if I should be offended on behalf of the maintainers who
> > are mostly my colleagues, that you have such a low opinion of their
> > capabilities.
> I don't have a low opinion of the capabilities of other edk2
> maintainers. It's a fact that they have just recently started using git.
> It is another fact that I personally mis-click a button (or mistype a
> shortcut) in this or that GUI application occasionally.
> 
> Fixing build breakage (or functional breakage) in the edk2 repository is
> not exactly fun. I find myself analyzing and fixing up bugs from others
> (outside of OvmfPkg/) more and more. Simply because I tend to run into
> them with OVMF (and with Gerd's Jenkins instance) earlier than most
> other people. (I'm not always the first to find out, of course.) I think
> it's natural from me not wanting to ease the introduction of such issues.

Hm, don't we have automatic CI on our pull requests? That's an
oversight... the tools can run builds on various platforms and right
there in the ticket it can show that it doesn't build in certain
configurations. With a big red cross right above the 'merge' button :)

(Which reminds me, I must try to fix things up so that OpenSSL PRs get
tested in something as close to the EDK2 build setup as possible.)

> I'd like to invite other edk2 maintainers to chime in on a github PR
> centered workflow. If the consensus is to use them,

The point here was to have a *look* at them, to make an informed
decision.

>  I'll try to adapt the best I can, although I think it's a h

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[Kinney, Michael D]

David,

Yes.  Use of developer github forks is supported.  I had summarized
3 development methods earlier in this thread.

1) PR emails send to edk2-devel.  There is a Wiki page that details process
for developers and maintainer.  

2) Branch on developer owned github fork of edk2.  There have been discussions 
on
how to support a pull request.  This is still under investigation.  In the 
meantime, a link to the branch and pull request can be included in
the PR emails to edk2-devel.

3) Branch on edk2-staging (Specific process being discussed in this thread)

In order to properly capture your feedback, I think a higher level overview
Wiki page on the development methods available needs to be written up with
edk2-staging just being one of the 3 methods (and likely most rare).

I will work with Tony to get Wiki pages updated with all this information.

Will this address your concerns?

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David
> Woodhouse
> Sent: Thursday, March 17, 2016 1:39 PM
> To: Kinney, Michael D ; Mangefeste, Tony
> ; edk2-devel@lists.01.org 
> Subject: Re: [edk2] EDK2 Staging Proposal 3rd draft, final?
> 
> I could have sworn I'd responded to this last night, but it was late,
> and I see no evidence of such in my outbox or on the list. Apologies if
> I'm repeating myself...
> 
> On Thu, 2016-03-17 at 00:15 +, Kinney, Michael D wrote:
> > Jordan asked a similar question about adding a 'staging' directory or 
> > 'staging'
> > branches to the edk2 repo.  If you look at the edk2 repo today, it has 
> > master
> > and the supported UDK* branches.  In the transition from SVN -> GIT, the 
> > old tags
> > were removed and archived.
> >
> > The reason for suggesting a new edk2-staging repo is to keep content that
> > is not ready for products to be clearly separated.  We do not want anyone
> > to pick up any of the staging content and put it into shipping FW images.
> >
> > There was also a minor concern about the size of the edk2 repo, but it
> > was shown that this is not really an issue at this time.
> >
> > So the choice here is a set of staging feature branches in the current
> > edk2 repo with clear communication that none of them are product ready.
> > Or a new edk2-staging repo with feature branches (current proposal).
> 
> This seems to me to be a false dichotomy. You've left out the third
> option, which is just to use the tools as they were designed to be
> used.
> 
> Let people set up their submissions in github repositories of their own
> (which works for groups as well as individuals, and allows loosely-
> formed collaborative groups as well as more formal projects). And you
> can already track their submissions at
> https://github.com/tianocore/edk2/pulls
> 
> > I think a process to create/merge/remove feature branches in the
> > tianocore.org repos is required because we really do not want too
> > many branches.  If the feature being developed is smaller in
> > scope, developer owned github branches or email PRs should be sufficient.
> 
> Developer-owned github repositories are suitable for larger submissions
> too, surely? (With associated discussion on the mailing list which was
> always part of the plan, of course. I'm not suggesting that it should
> necessarily happen *only* in the github PR format.)
> 
> --
> dwmw2

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

Re: [edk2] [PATCH v2] MdeModulePkg: Fixed incorrect Regular expression protocol MatchString return value.

[Zeng, Star]

Cecil,

I had two comments for the first patch, this V2 patch only covers one of 
the comments.


And one further comment below for this V2 patch.

On 2016/3/17 9:33, Cecil Sheng wrote:

According to UEFI2.6, CapturePtr in the Captures array returned by 
MatchString() should be separatedly allocated so that they can be freed by the 
caller.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cecil Sheng 
Reviewed-by: Samer El-Haj-Mahmoud 
---
  .../RegularExpressionDxe/RegularExpressionDxe.c| 33 ++
  1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
index cffbcb8..87912c5 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
@@ -2,7 +2,7 @@

EFI_REGULAR_EXPRESSION_PROTOCOL Implementation

-  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP

This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License that accompanies this
@@ -91,6 +91,8 @@ OnigurumaMatch (
CHAR8   ErrorMessage[ONIG_MAX_ERROR_MESSAGE_LEN];
UINT32  Index;
OnigUChar   *Start;
+  EFI_STATUS  Status;
+

//
// Detemine the internal syntax type
@@ -102,7 +104,7 @@ OnigurumaMatch (
  OnigSyntax = ONIG_SYNTAX_PERL;
} else {
  DEBUG ((DEBUG_ERROR, "Unsupported regex syntax - using default\n"));
-ASSERT (FALSE);
+return EFI_UNSUPPORTED;
}

//
@@ -143,6 +145,8 @@ OnigurumaMatch (
   Region,
   ONIG_OPTION_NONE
   );
+
+  Status = EFI_SUCCESS;
if (OnigResult >= 0) {
  *Result = TRUE;
} else {
@@ -150,6 +154,9 @@ OnigurumaMatch (
  if (OnigResult != ONIG_MISMATCH) {
onig_error_code_to_str (ErrorMessage, OnigResult);
DEBUG ((DEBUG_ERROR, "Regex match failed: %a\n", ErrorMessage));
+  onig_region_free (Region, 1);
+  onig_free (OnigRegex);
+  return EFI_DEVICE_ERROR;
  }
}

@@ -158,14 +165,30 @@ OnigurumaMatch (
//
if (*Result && Captures != NULL) {
  *CapturesCount = Region->num_regs;
-*Captures = AllocatePool (*CapturesCount * sizeof(**Captures));
+*Captures = AllocateZeroPool (*CapturesCount * sizeof(**Captures));
  if (*Captures != NULL) {
for (Index = 0; Index < *CapturesCount; ++Index) {
  //
  // Region beg/end values represent bytes, not characters
  //
-(*Captures)[Index].CapturePtr = (CHAR16*)((UINTN)String + 
Region->beg[Index]);
  (*Captures)[Index].Length = (Region->end[Index] - Region->beg[Index]) 
/ sizeof(CHAR16);
+(*Captures)[Index].CapturePtr = AllocateCopyPool (
+  ((*Captures)[Index].Length) * sizeof 
(CHAR16),
+  (CHAR16*)((UINTN)String + 
Region->beg[Index])
+  );
+if ((*Captures)[Index].CapturePtr == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  break;
+}
+  }
+
+  if (EFI_ERROR (Status)) {
+for (Index = 0; Index < *CapturesCount; ++Index) {
+  if ((*Captures)[Index].CapturePtr != NULL) {
+FreePool ((CHAR16*)(*Captures)[Index].CapturePtr);
+  }
+}
+FreePool (Captures);


Here, the parameter to FreePool() should be *Captures, right?

Thanks,
Star

}
  }
}
@@ -173,7 +196,7 @@ OnigurumaMatch (
onig_region_free (Region, 1);
onig_free (OnigRegex);

-  return EFI_SUCCESS;
+  return Status;
  }

  /**



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

Re: [edk2] [PATCH] MdePkg: add UNUSED notation to Base.h

[Laszlo Ersek]

(adding Ard and Shumin because the below will tie in with another thread)

On 03/17/16 19:05, Leif Lindholm wrote:

> I must confess to no small amount of surprise that optionally adding
> the ability to tag an unused argument as unused is controversial.

I'm also surprised, but by a different thing. :)

(1) This is a side point, but I think it is a bit relevant.

See this sub-thread:

http://thread.gmane.org/gmane.comp.bios.edk2.devel/8848/focus=9254

Shumin did build his patch in question with GCC46, but the warning was
not reported to him. (Side side point: I will assume that Shumin is a
male name. I googled it and found nothing conclusive; apologies!) Ard
and myself stumbled upon it because we built the code for aarch64 as
well.

So the difference is ("obviously" in retrospect) in the different build
flags. Compare, in "BaseTools/Conf/tools_def.template":

DEFINE GCC46_IA32_CC_FLAGS   = DEF(GCC45_IA32_CC_FLAGS) -Wno-address 
-Wno-unused-but-set-variable
DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) -Wno-address 
-Wno-unused-but-set-variable

vs.

  DEBUG_GCC48_AARCH64_CC_FLAGS   = DEF(GCC48_AARCH64_CC_FLAGS) -O0
RELEASE_GCC48_AARCH64_CC_FLAGS   = DEF(GCC48_AARCH64_CC_FLAGS) 
-Wno-unused-but-set-variable

Only the DEBUG target for AARCH64 does not include
"-Wno-unused-but-set-variable"; that's why Ard and I got that warning,
and Shumin didn't.

I think it might be feasible to remove -Wno-unused-but-set-variable. I
removed it and built OvmfPkg and ArmVirtPkg with a number of settings
(for the DEBUG target, with gcc-4.8). The warnings that surfaced were
only:

> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:1114:29: warning: 
> variable 'BusEnd' set but not used [-Wunused-but-set-variable]
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:1114:9: warning: 
> variable 'BusEnd' set but not used [-Wunused-but-set-variable]
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:631:10: warning: 
> variable 'AddrLen' set but not used [-Wunused-but-set-variable]
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:631:41: warning: 
> variable 'AddrLen' set but not used [-Wunused-but-set-variable]
> UefiCpuPkg/Library/MtrrLib/MtrrLib.c:462:11: warning: variable 'TempQword' 
> set but not used [-Wunused-but-set-variable]
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c:1314:25: warning: variable 
> 'SwSmiCpuIndex' set but not used [-Wunused-but-set-variable]
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c:1314:9: warning: variable 
> 'SwSmiCpuIndex' set but not used [-Wunused-but-set-variable]
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c:345:14: warning: variable 'Status' set 
> but not used [-Wunused-but-set-variable]
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c:345:36: warning: variable 'Status' set 
> but not used [-Wunused-but-set-variable]
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c:779:14: warning: variable 'Status' set 
> but not used [-Wunused-but-set-variable]
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c:779:22: warning: variable 'Status' set 
> but not used [-Wunused-but-set-variable]

Side point ends.

(2) Beyond removing "-Wno-unused-but-set-variable", I then added
"-Wunused-parameter -Wunused-but-set-parameter".

Oh boy. :) First, a large number of "AutoGen.c" files (maybe all of
them?) seem to hit it. I simply filtered those out.

Second, the remaining set of warnings is also huge: almost 4000
instances. The list of locations is too large to attach or paste (and I
don't think the list will allow compressed attachments), so I'm
uploading it here:
.

If I understand correctly, if we wanted to enable "-Wunused-parameter
-Wunused-but-set-parameter" even just occasionally, these ~4000
instances would have to be audited, and each should be either fixed
(i.e., internal functions should drop the parameters) or marked UNUSED
(i.e., library instances and PPI/protocol implementations should
annotate their definitions of public functions).

Thus, this is what surprises me. It looks daunting.

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

Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h

[Andrew Fish]

> On Mar 16, 2016, at 10:06 AM, Laszlo Ersek  wrote:
> 
> On 03/16/16 17:50, Andrew Fish wrote:
>> 
>>> On Mar 16, 2016, at 6:54 AM, Laszlo Ersek  wrote:
>>> 
>>> On 03/14/16 16:38, Leif Lindholm wrote:
 To permit many existing platforms to build with -Wunused-parameter, on
 GCC and CLANG, the unused parameters need to be annotated as such.
 Existing regexp code already uses ARG_UNUSED for this, but it is really
 needed across the codebase - so add a version in Base.h.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Leif Lindholm 
 ---
 
 This is really the result of a friendly toolchain engineer informing me
 CLANG has the -Weverything flag, to actually enable all possible
 warnings.
 
 One problem trying to pick out the real bugs from the just not entirely
 clear code is that basically a lot of *LibNull implementations, and
 some libraries that should be usable, trip build failures due to unused
 parameters.
 
 MdePkg/Include/Base.h | 9 +
 1 file changed, 9 insertions(+)
 
 diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
 index 89b2aed..f789094 100644
 --- a/MdePkg/Include/Base.h
 +++ b/MdePkg/Include/Base.h
 @@ -189,6 +189,15 @@ struct _LIST_ENTRY {
 ///
 #define OPTIONAL
 
 +///
 +/// Function argument intentionally unused in function.
 +///
 +#if defined(__GNUC__) || defined(__clang__)
 +  #define ARG_UNUSED  __attribute__ ((unused))
 +#else
 +  #define ARG_UNUSED
 +#endif
 +
 //
 //  UEFI specification claims 1 and 0. We are concerned about the
 //  complier portability so we did it this way.
 
>>> 
>>> Support for this seems to go back to gcc-4.4:
>>> 
>>> https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Variable-Attributes.html
>>> 
>>> So it looks safe. (And I agree with the idea.)
>>> 
>> 
>> I'm confused by the usage, or really when the compiler detects the
>> warning?
>> 
>> For example how is this going to work on public interfaces?
>> Protocols, PPIs,  or library class definitions? There is a single
>> definition of the function, but multiple implementations. Some
>> implementations may not use some arguments. But what arguments get
>> used seems to be an implementation choice and not part of the API?
>> Thus it seems like this macro is not going to enable changing
>> compiler flags?
> 
> I think this attribute would be used in library instances and protocol
> implementations. It would not be used in library class headers nor
> protocol definitions.
> 
> Example:
> 
>/* included from library class hdr of protocol def hdr */
>int f(int x);
> 
>/* code in library instance or protocol impl */
>int f(int x __attribute__ ((unused)))
>{
>  return 0;
>}
> 
>int main(void)
>{
>  return f(-2);
>}
> 
> Compiles silently with
> 
> $ gcc -Wall -Wextra -ansi -pedantic -Werror -o x x.c
> 
> If I remove __attribute__ ((unused)), I get:
> 
> x.c:5:15: error: unused parameter 'x' [-Werror=unused-parameter]
> int f(int x)
>   ^
> cc1: all warnings being treated as errors
> 

OK that makes sense. That is feels like it is going to be a very very large 
change to the codebase given almost every protocol and PPI member pass the 
"This" pointer, but may not use it in code.

Do we need something for VC++?

Thanks,

Andrew Fish

> Thanks
> Laszlo
> 
>> 
>> Or am I just confused?
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>>> Acked-by: Laszlo Ersek 
>>> ___
>>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] PcAtChipsetPkg/PciHostBridge: Remove PciHostBridge driver

[Laszlo Ersek]

On 03/18/16 07:34, Ruiyu Ni wrote:
> MdeModulePkg contains a new PciHostBridgeDxe driver which is a
> super set of PcAtChipsetPkg/PciHostBridgeDxe.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Laszlo Ersek 
> Cc: Xiaofeng Wang 
> ---
>  PcAtChipsetPkg/PcAtChipsetPkg.dsc  |1 -
>  PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S  |  134 -
>  PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm|  140 --
>  PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h   |  176 --
>  PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c| 1396 ---
>  PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h|  649 -
>  PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.uni  |   22 -
>  .../PciHostBridgeDxe/PciHostBridgeDxe.inf  |   68 -
>  .../PciHostBridgeDxe/PciHostBridgeExtra.uni|   20 -
>  PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c  | 2626 
> 
>  PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S   |  122 -
>  PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm |  126 -
>  12 files changed, 5480 deletions(-)
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.uni
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridgeExtra.uni
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S
>  delete mode 100644 PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm

Reviewed-by: Laszlo Ersek 

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

[edk2] Is there any exiting way in edk2 to format a partition with FAT file system?

[Heyi Guo]

Hi experts,

Is there any exiting way in edk2 to format a partition with FAT file system?

If not, shall we implement an interface to do that? It is useful when we 
are using a ramdisk in UEFI, or a raw hard disk not relying on OS utilities.


Thanks.

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

Re: [edk2] [PATCH] Ax88772b: support for multiple dongles and chips

[Shivamurthy Shastri]

On 18 February 2016 at 22:11, Shivamurthy Shastri <
shivamurthy.shas...@linaro.org> wrote:

> Adding Ruiyu Ni
>
> --
>
> Thanks and Regards,
>
> Shivamurthy Shastri,
>
> M: +919742508553, IRC: shivamurthy,
> *Linaro.org* |Open Source Software for ARM SOCs
>
>
> On 18 February 2016 at 16:50, Shivamurthy Shastri <
> shivamurthy.shas...@linaro.org> wrote:
>
>> Hi All,
>>
>> Please let me know your opinion about this patch.
>>
>> --
>>
>> Thanks and Regards,
>>
>> Shivamurthy Shastri,
>>
>> M: +919742508553, IRC: shiva_murthy,
>> *Linaro.org* |Open Source Software for ARM SOCs
>>
>>
>> -- Forwarded message --
>> From: Shivamurthy Shastri 
>> Date: 10 February 2016 at 19:40
>> Subject: [edk2] [PATCH] Ax88772b: support for multiple dongles and chips
>> To: edk2-devel@lists.01.org
>> Cc: fathi.bou...@linaro.org, Shivamurthy Shastri <
>> shivamurthy.shas...@linaro.org>
>>
>>
>> Driver code is modified to support multiple ethernet dongles, which uses
>> similar ASIX chips. Also, it can be used for multiple ASIX chips with
>> similar register map.
>>
>> Enabled support for Apple Ethernet Adapter
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Shivamurthy Shastri 
>> ---
>>  .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h   | 13 -
>>  .../Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c | 33
>> +-
>>  2 files changed, 32 insertions(+), 14 deletions(-)
>>
>> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>> index ab75ec2..816f2b2 100644
>> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>> @@ -297,12 +297,23 @@
>>  #define AN_10_HDX   0x0020  ///<  1 = 10BASE-T
>> support
>>  #define AN_CSMA_CD  0x0001  ///<  1 = IEEE 802.3
>> CSMA/CD support
>>
>> -
>> +/* asix_flags defines */
>> +#define FLAG_NONE   0
>> +#define FLAG_TYPE_AX88172   (1U << 0)
>> +#define FLAG_TYPE_AX88772   (1U << 1)
>> +#define FLAG_TYPE_AX88772B  (1U << 2)
>> +#define FLAG_EEPROM_MAC (1U << 3) /* initial mac address in
>> eeprom */
>>
>>
>>  
>> //--
>>  //  Data Types
>>
>>  
>> //--
>>
>> +struct ASIX_DONGLE {
>> +   UINT16  VendorId;
>> +   UINT16  ProductId;
>> +   INT32   Flags;
>> +};
>> +
>>  /**
>>Ethernet header layout
>>
>> diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>> b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>> index 3b73040..6a10cbf 100644
>> --- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>> +++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>> @@ -14,6 +14,13 @@
>>
>>  #include "Ax88772.h"
>>
>> +struct ASIX_DONGLE ASIX_DONGLES[] = {
>> +{ 0x05AC, 0x1402, FLAG_TYPE_AX88772 }, /* Apple USB Ethernet
>> Adapter */
>> +/* ASIX 88772B */
>> +{ 0x0B95, 0x772B, FLAG_TYPE_AX88772B | FLAG_EEPROM_MAC },
>> +{ 0x, 0x, FLAG_NONE }   /* END - Do not remove */
>> +};
>> +
>>  /**
>>Verify the controller type
>>
>> @@ -36,6 +43,8 @@ DriverSupported (
>>EFI_USB_DEVICE_DESCRIPTOR Device;
>>EFI_USB_IO_PROTOCOL * pUsbIo;
>>EFI_STATUS Status;
>> +  UINT32 i;
>> +
>>//
>>//  Connect to the USB stack
>>//
>> @@ -60,19 +69,17 @@ DriverSupported (
>>  else {
>>//
>>//  Validate the adapter
>> -  //
>> -  if ( VENDOR_ID == Device.IdVendor ) {
>> -
>> -if (PRODUCT_ID == Device.IdProduct) {
>> -DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
>> -}
>> -   else  {
>> -Status = EFI_UNSUPPORTED;
>> -   }
>> -  }
>> -   else {
>> - Status = EFI_UNSUPPORTED;
>> -   }
>> +  //
>> +  for (i = 0; ASIX_DONGLES[i].VendorId != 0; i++) {
>> +   if (ASIX_DONGLES[i].VendorId == Device.IdVendor &&
>> +   ASIX_DONGLES[i].ProductId == Device.IdProduct) {
>> + DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
>> + break;
>> +   }
>> +   }
>> +
>> +   if (ASIX_DONGLES[i].VendorId == 0)
>> +   Status = EFI_UNSUPPORTED;
>>  }
>>
>>  //
>> --
>> 1.9.1
>>
>>
>>
> ​Hi Ruiyu Ni,

Please look into the patch.

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

Re: [edk2] [PATCH v2] OvmfPkg/PlatformPei: Fix VS2008 build breakage

[Laszlo Ersek]

On 03/18/16 16:12, David Woodhouse wrote:
> Commit 7b8fe6356 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG /
> ECAM) on Q35") broke the VS2008 build, causing it to complain of
> "potentially uninitialized local variable 'PciExBarBase' used" at
> line 275.
> 
> On this occasion it isn't actually wrong — the mHostBridgeDevId variable
> is global, so theoretically it *could* change between the two if()
> statements.
> 
> Of course VS2008 is also a steaming pile of poo, and even if we use
> a local boolean variable which definitely *can't* change in the middle,
> it still can't work it out and still emits the warning.
> 
> So just initialise PciExBarBase to zero to shut the compiler up.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: David Woodhouse 
> ---
> Oops, my build test on Windows still had the temporary 'PciExBarBase=0'
> to shut the compiler up, so wasn't really exercising the fix I was
> submitting. Sorry for the noise.
> 
> It turns out that VS2008 really is just a stupid pile of crap.
> 
> OvmfPkg/PlatformPei/Platform.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 0fc2278..20008d0 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -212,7 +212,7 @@ MemMapInitialization (
>  
>if (!mXen) {
>  UINT32  TopOfLowRam;
> -UINT64  PciExBarBase;
> +UINT64  PciExBarBase = 0;
>  UINT32  PciBase;
>  UINT32  PciSize;
>  
> -- 
> 2.5.5
> 

Thank you for the patch.

I have three problems with it:

(1) The commit message uses at least one non-ASCII character, the EM
DASH (U+2014). Can you please replace it with a "--"? Yes, I know you
hate me for asking this. Please just write me off as stupid and replace
the character.

(2) In the edk2 coding style, initialization of local variables is not
permitted. Can you please add an assignment instead?

(3) I tried to apply your patch nonetheless. It doesn't apply. I looked
at the patch email that I saved from Thunderbird. The code section of
the email contains =C2=A0 quoted-printable sequences. Since the charset
is UTF-8 (according to the Content-Type header), 0xC2 0xA0 translates to
U+00A0, "NO-BREAK SPACE".

In the code, we just have plain space characters.

Can you please submit a v3 with the above addressed?

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

[edk2] [PATCH 0/7] ArmPkg/ArmExceptionLib cleanup

[Ard Biesheuvel]

After Eugene has kindly contributed his refactored version of the
ArmExceptionLib, this series cleans up the original migrated code,
as a general cleanup and optimization effort.

Ard Biesheuvel (7):
  ArmPkg/AsmMacroIoLibV8: remove undocumented assumption from ELx macros
  ArmPkg/ArmExceptionLib: fold exception handler prologue into vector
table
  ArmPkg/ArmExceptionLib: stack FPSR on common path
  ArmPkg/ArmExceptionLib: don't restore ESR and FAR upon exception
return
  ArmPkg/ArmExceptionLib: make build time define visible to the compiler
  ArmPkg/ArmExceptionLib: avoid indirect call if using vector table in
place
  ArmPkg/ArmExceptionLib: reimplement register stack/unstack routines

 ArmPkg/Include/AsmMacroIoLibV8.h  |  15 +-
 ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 345 

 ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c  |   6 +-
 3 files changed, 156 insertions(+), 210 deletions(-)

-- 
2.5.0

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

Re: [edk2] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Andrew Fish]

> On Mar 16, 2016, at 6:59 PM, Zeng, Star  wrote:
> 
> On 2016/3/17 7:12, Andrew Fish wrote:
>> I was trying to move over to DxeDebugPrintErrorLevelLib, but I can't get it 
>> to build
>> 
>> For example I made DXE use 
>> DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
>>  in the EmulatorPkg and I get this error:
>> 
>> /Users/andrewfish/work/src/edk2/EmulatorPkg/EmulatorPkg.dsc(...): error 
>> F002: Library 
>> [/Users/andrewfish/work/src/edk2/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf]
>>  with constructors has a cycle
>>  consumed by 
>> /Users/andrewfish/work/src/edk2/MdePkg/Library/UefiLib/UefiLib.inf
>> 
>> The error message is not very helpful on root causing the issue
>> 
>> But a circular constructor issue does not seem that strange in the DebugLib 
>> stack as everything uses that! If I go into DxeDebugPrintErrorLevelLib.inf  
>> and remove the HobLib I don't get the Constructor error, but I do get a link 
>> error.
>> 
>> So it looks like the DxeDebugPrintErrorLevelLib depends on the Hob lib that 
>> depends on the DebugLib that depends on the DxeDebugPrintErrorLevelLib. How 
>> did this every work? The only place I see it used is the Nt32Pkg, and I 
>> don't have a system to test that on
> 
> Just tried NT32 with VS2015, and it builds and works well.
> 
> Liming & Yonghong, any idea on this?
> 

I was wondering if it had to do with the lower level libraries having a 
constructor? So maybe library implementation matters?

Thanks,

Andrew Fish

> Thanks,
> Star
>> 
>> Any ideas?
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
> 
> ___
> 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] signedness of CHAR8

[Leif Lindholm]

So, as further fallout from my -Weverything experiments, I've come
across this...

Ia32 and X64 ProcessorBind.h (BaseTools and MdePkg) both define CHAR8 as 'char'.
ARM and AArch64 both do the same.

However, default 'char' signedness is unsigned in the ARM
architectures, and signed in the others.

Meanwhile, the UEFI specification describes CHAR8 as
---
1-byte character. Unless otherwise specified, all 1-byte or ASCII characters and
strings are stored in 8-bit ASCII encoding format, using the
ISO-Latin-1 character
set.
---

Now, ISO-Latin-1 holds values all the way up to 255, which clearly
does not fit into a signed 8-bit char.

Would I be correct in my interpretation that Ia32/X64 should be
defining CHAR8 as 'unsigned char', or am I losing my mind?

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

Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h

[Marvin Häuser]

I think this question on StackOverflow might be helpful: 
https://stackoverflow.com/questions/7090998/portable-unused-parameter-macro-used-on-function-signature-for-c-and-c

The comment by 'the swine' suggests '__pragma(warning(suppress:4100))' to be 
used for MSVC. I also believe the answer by 'doc_ds' is a nice hint, as he 
states it is better to use '__attribute__((__unused__))' rather than 
'__attribute__((unused))' for the case 'unused' might eventually be defined as 
a macro. With '__unused__' you would be on the safe side as the EDK2 Coding 
Standard prohibits the usage of one or two underscores as prefix (reserved for 
compiler usage) for EDK2 macros.

The post by Steve-o includes a GNU version check with the macro definition; 
might that be a good idea?

Regards,
Marvin.


Von: edk2-devel  im Auftrag von Andrew Fish 

Gesendet: Mittwoch, 16. März 2016 18:12
An: Laszlo Ersek
Cc: Mike Kinney; edk2-de...@ml01.01.org; Leif Lindholm; Liming Gao
Betreff: Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h

> On Mar 16, 2016, at 10:06 AM, Laszlo Ersek  wrote:
>
> On 03/16/16 17:50, Andrew Fish wrote:
>>
>>> On Mar 16, 2016, at 6:54 AM, Laszlo Ersek  wrote:
>>>
>>> On 03/14/16 16:38, Leif Lindholm wrote:
 To permit many existing platforms to build with -Wunused-parameter, on
 GCC and CLANG, the unused parameters need to be annotated as such.
 Existing regexp code already uses ARG_UNUSED for this, but it is really
 needed across the codebase - so add a version in Base.h.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Leif Lindholm 
 ---

 This is really the result of a friendly toolchain engineer informing me
 CLANG has the -Weverything flag, to actually enable all possible
 warnings.

 One problem trying to pick out the real bugs from the just not entirely
 clear code is that basically a lot of *LibNull implementations, and
 some libraries that should be usable, trip build failures due to unused
 parameters.

 MdePkg/Include/Base.h | 9 +
 1 file changed, 9 insertions(+)

 diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
 index 89b2aed..f789094 100644
 --- a/MdePkg/Include/Base.h
 +++ b/MdePkg/Include/Base.h
 @@ -189,6 +189,15 @@ struct _LIST_ENTRY {
 ///
 #define OPTIONAL

 +///
 +/// Function argument intentionally unused in function.
 +///
 +#if defined(__GNUC__) || defined(__clang__)
 +  #define ARG_UNUSED  __attribute__ ((unused))
 +#else
 +  #define ARG_UNUSED
 +#endif
 +
 //
 //  UEFI specification claims 1 and 0. We are concerned about the
 //  complier portability so we did it this way.

>>>
>>> Support for this seems to go back to gcc-4.4:
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Variable-Attributes.html
>>>
>>> So it looks safe. (And I agree with the idea.)
>>>
>>
>> I'm confused by the usage, or really when the compiler detects the
>> warning?
>>
>> For example how is this going to work on public interfaces?
>> Protocols, PPIs,  or library class definitions? There is a single
>> definition of the function, but multiple implementations. Some
>> implementations may not use some arguments. But what arguments get
>> used seems to be an implementation choice and not part of the API?
>> Thus it seems like this macro is not going to enable changing
>> compiler flags?
>
> I think this attribute would be used in library instances and protocol
> implementations. It would not be used in library class headers nor
> protocol definitions.
>
> Example:
>
>/* included from library class hdr of protocol def hdr */
>int f(int x);
>
>/* code in library instance or protocol impl */
>int f(int x __attribute__ ((unused)))
>{
>  return 0;
>}
>
>int main(void)
>{
>  return f(-2);
>}
>
> Compiles silently with
>
> $ gcc -Wall -Wextra -ansi -pedantic -Werror -o x x.c
>
> If I remove __attribute__ ((unused)), I get:
>
> x.c:5:15: error: unused parameter 'x' [-Werror=unused-parameter]
> int f(int x)
>   ^
> cc1: all warnings being treated as errors
>

OK that makes sense. That is feels like it is going to be a very very large 
change to the codebase given almost every protocol and PPI member pass the 
"This" pointer, but may not use it in code.

Do we need something for VC++?

Thanks,

Andrew Fish

> Thanks
> Laszlo
>
>>
>> Or am I just confused?
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>>> Acked-by: Laszlo Ersek 
>>> ___
>>> 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-devel mailing list

[edk2] Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65 causes UEFI boot freeze (armv8 platform)

[Vladimir Olovyannikov]

Hi Eugene,

This commit:

Author: Cohen, Eugene   2016-03-07 07:16:38
Committer: Ard Biesheuvel   2016-03-17 01:15:14
Parent: 8a47a6cb9e77e4cc4bf42391f7f970173bcead27 (Omap35xxPkg: drop
CpuExceptionHandlerLib library class resolution)
Branch: remotes/origin/master
Follows:
Precedes:

ArmPkg: update CpuDxe to use CpuExceptionHandlerLib

Use the new ARM/AArch64 implementation of the base
CpuExceptionHandlerLib library from CpuDxe to centralize
exception handling.

makes UEFI to hang on my v8 board.
The latest log lines are:

InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BB7F2300

add-symbol-file
/home/volovyan/work/stingray/uefi-orig/Build/NS2Pkg/DEBUG_GCC49/AARCH64/In
telFrameworkModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll 0xBBE29240

Loading driver at 0x000BBE29000 EntryPoint=0x000BBE29280 BdsDxe.efi

InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BB7F2558

InstallProtocolInterface: 665E3FF6-46CC-11D4-9A38-0090273FC14D BBE67780

Loading driver 49EA041E-6752-42CA-B0B1-7344FE2546B7

InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BB7F1180

add-symbol-file
/home/volovyan/work/stingray/uefi-orig/Build/NS2Pkg/DEBUG_GCC49/AARCH64/Ar
mPkg/Drivers/TimerDxe/TimerDxe/DEBUG/ArmTimerDxe.dll 0xBBE23240

Loading driver at 0x000BBE23000 EntryPoint=0x000BBE23280 ArmTimerDxe.efi

InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBE28B28

Loading driver E660EA85-058E-4B55-A54B-F02F83A24

The last one is "DisplayEngine", but it is not the culprit.
JTAG debug shows that the CPU is looping in IrqSpx:
EL2:0x85008A80 : BIrqSPx ; 0x85008A80

As soon as I revert the patch, everything returns to "normal" (no issues
on boot, etc.).

Please let me know if I am missing anything here.

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

Re: [edk2] [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 structure definition.

[Carsey, Jaben]

Looks good.

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, March 16, 2016 10:31 AM
> To: edk2-devel@lists.01.org
> Cc: samer.el-haj-mahm...@hpe.com; Carsey, Jaben
> ; Tapan Shah 
> Subject: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and
> V2 structure definition.
> 
> Add V1 and V2 structure definitions for EFI_FIRMWARE_IMAGE_DESCRIPTOR
> structure. Consumer of the protocol needs correct structure definition to
> decode structure fields correctly.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah 
> ---
>  MdePkg/Include/Protocol/FirmwareManagement.h | 116
> +++
>  1 file changed, 116 insertions(+)
> 
> diff --git a/MdePkg/Include/Protocol/FirmwareManagement.h
> b/MdePkg/Include/Protocol/FirmwareManagement.h
> index e615573..67f19fd 100644
> --- a/MdePkg/Include/Protocol/FirmwareManagement.h
> +++ b/MdePkg/Include/Protocol/FirmwareManagement.h
> @@ -10,6 +10,7 @@
> 
>Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
>Copyright (c) 2013 - 2014, Hewlett-Packard Development Company,
> L.P.
> +  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>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
> @@ -119,6 +120,121 @@ typedef struct {
>UINT64   HardwareInstance;
>  } EFI_FIRMWARE_IMAGE_DESCRIPTOR;
> 
> +#define   EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V1   1
> +#define   EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V2   2
> +
> +///
> +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec < 2.4a
> +///
> +typedef struct {
> +  ///
> +  /// A unique number identifying the firmware image within the device.  The
> number is
> +  /// between 1 and DescriptorCount.
> +  ///
> +  UINT8ImageIndex;
> +  ///
> +  /// A unique number identifying the firmware image type.
> +  ///
> +  EFI_GUID ImageTypeId;
> +  ///
> +  /// A unique number identifying the firmware image.
> +  ///
> +  UINT64   ImageId;
> +  ///
> +  /// A pointer to a null-terminated string representing the firmware image
> name.
> +  ///
> +  CHAR16   *ImageIdName;
> +  ///
> +  /// Identifies the version of the device firmware. The format is vendor
> specific and new
> +  /// version must have a greater value than an old version.
> +  ///
> +  UINT32   Version;
> +  ///
> +  /// A pointer to a null-terminated string representing the firmware image
> version name.
> +  ///
> +  CHAR16   *VersionName;
> +  ///
> +  /// Size of the image in bytes.  If size=0, then only ImageIndex and
> ImageTypeId are valid.
> +  ///
> +  UINTNSize;
> +  ///
> +  /// Image attributes that are supported by this device.  See 'Image 
> Attribute
> Definitions'
> +  /// for possible returned values of this parameter.  A value of 1 indicates
> the attribute is
> +  /// supported and the current setting value is indicated in 
> AttributesSetting.
> A
> +  /// value of 0 indicates the attribute is not supported and the current
> setting value in
> +  /// AttributesSetting is meaningless.
> +  ///
> +  UINT64   AttributesSupported;
> +  ///
> +  /// Image attributes.  See 'Image Attribute Definitions' for possible 
> returned
> values of
> +  /// this parameter.
> +  ///
> +  UINT64   AttributesSetting;
> +  ///
> +  /// Image compatibilities.  See 'Image Compatibility Definitions' for 
> possible
> returned
> +  /// values of this parameter.
> +  ///
> +  UINT64   Compatibilities;
> +} EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1;
> +
> +
> +///
> +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec > 2.4a and < 2.5
> +///
> +typedef struct {
> +  ///
> +  /// A unique number identifying the firmware image within the device.  The
> number is
> +  /// between 1 and DescriptorCount.
> +  ///
> +  UINT8ImageIndex;
> +  ///
> +  /// A unique number identifying the firmware image type.
> +  ///
> +  EFI_GUID ImageTypeId;
> +  ///
> +  /// A unique number identifying the firmware image.
> +  ///
> +  UINT64   ImageId;
> +  ///
> +  /// A pointer to a null-terminated string representing the firmware image
> name.
> +  ///
> +  CHAR16   *ImageIdName;
> +  ///
> +  /// Identifies the version of the device firmware. The format is vendor
> specific and new
> +  /// version must have a greater value than an old version.
> +  ///
> +  UINT32   Version;
> +  ///
> +  /// A pointer to a null-terminated string representing the firmware image
> version name.
> +  ///
> +  CHAR16

Re: [edk2] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Andrew Fish]

> On Mar 16, 2016, at 7:37 PM, Andrew Fish  wrote:
> 
>> 
>> On Mar 16, 2016, at 7:18 PM, Zeng, Star  wrote:
>> 
>> On 2016/3/17 10:02, Andrew Fish wrote:
>>> 
 On Mar 16, 2016, at 6:59 PM, Zeng, Star  wrote:
 
 On 2016/3/17 7:12, Andrew Fish wrote:
> I was trying to move over to DxeDebugPrintErrorLevelLib, but I can't get 
> it to build
> 
> For example I made DXE use 
> DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
>  in the EmulatorPkg and I get this error:
> 
> /Users/andrewfish/work/src/edk2/EmulatorPkg/EmulatorPkg.dsc(...): error 
> F002: Library 
> [/Users/andrewfish/work/src/edk2/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf]
>  with constructors has a cycle
>   consumed by 
> /Users/andrewfish/work/src/edk2/MdePkg/Library/UefiLib/UefiLib.inf
> 
> The error message is not very helpful on root causing the issue
> 
> But a circular constructor issue does not seem that strange in the 
> DebugLib stack as everything uses that! If I go into 
> DxeDebugPrintErrorLevelLib.inf  and remove the HobLib I don't get the 
> Constructor error, but I do get a link error.
> 
> So it looks like the DxeDebugPrintErrorLevelLib depends on the Hob lib 
> that depends on the DebugLib that depends on the 
> DxeDebugPrintErrorLevelLib. How did this every work? The only place I see 
> it used is the Nt32Pkg, and I don't have a system to test that on
 
 Just tried NT32 with VS2015, and it builds and works well.
 
 Liming & Yonghong, any idea on this?
 
>>> 
>>> I was wondering if it had to do with the lower level libraries having a 
>>> constructor? So maybe library implementation matters?
>> 
>> If this circular constructor issue could be reproduced with only one module 
>> linked with DxeDebugPrintErrorLevelLib (I mean other modules to link with 
>> BaseDebugPrintErrorLevelLib, only the module links to 
>> DxeDebugPrintErrorLevelLib), then that may be helpful to scrub all the 
>> library instances the module links to find out what is the matter. :)
>> 
> 
> OK in the EmulatorPkg the DXE Core compiles, but 
> MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
>  will error out.
> 

I think it is as simple as you can't have a library with a constructor required 
by the DebugLib (and child libraries) for a library that depends on the 
DebugLib. So the chain to get the DebugLib started depends on the DebugLib.

That kind of makes DxeDebugPrintErrorLevelLib hard to use I guess?

Thanks,

Andrew Fish

> Library
> 
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> {PcdLib}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BaseLib/BaseLib.inf
> {BaseLib}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> {BaseMemoryLib}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
> {DxeCoreEntryPoint}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> {HobLib}
> /Users/andrewfish/work/src/edk2/MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
> {DebugPrintErrorLevelLib:  C = DxeDebugPrintErrorLevelLibConstructor D = 
> DxeDebugPrintErrorLevelLibDestructor}
> /Users/andrewfish/work/src/edk2/EmulatorPkg/Library/DxeEmuStdErrSerialPortLib/DxeEmuStdErrSerialPortLib.inf
> {SerialPortLib}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BasePrintLib/BasePrintLib.inf
> {PrintLib}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> {DebugLib:  C = BaseDebugLibSerialPortConstructor}
> /Users/andrewfish/work/src/edk2/EmulatorPkg/Library/DxeEmuLib/DxeEmuLib.inf
> {EmuThunkLib:  C = DxeEmuLibConstructor}
> /Users/andrewfish/work/src/edk2/MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
> {MemoryAllocationLib}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
> {UefiBootServicesTableLib:  C = UefiBootServicesTableLibConstructor}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
> {UefiRuntimeServicesTableLib:  C = UefiRuntimeServicesTableLibConstructor}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
> {DevicePathLib}
> /Users/andrewfish/work/src/edk2/MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
> {ExtractGuidedSectionLib:  C = DxeExtractGuidedSectionLibConstructor}
> /Users/andrewfish/work/src/edk2/EmulatorPkg/Library/DxeEmuPeCoffExtraActionLib/DxeEmuPeCoffExtraActionLib.inf
> {PeCoffExtraActionLib:  C = DxeEmuPeCoffLibExtraActionConstructor}
> /Users/andrewfish

Re: [edk2] [RFC 1/3] MdePkg: Add PCD for UART default receive FIFO depth

[Heyi Guo]

Hi Ruiyu,

Does it also mean the type in EFI_SERIAL_IO_MODE is mainly for data 
alignment?


Heyi


On 03/17/2016 10:29 AM, Ni, Ruiyu wrote:

Heyi,
I agree with the general idea of the patch to add a PCD for 
DefaultReceiveFifoDepth.

I understand you choose UINT32 for the FIFO depth because the
EFI_SERIAL_IO_MODE.ReceiveFifoDepth is of UINT32 type.
But in real world, I believe UINT16 should be enough.

Could you please change the PCD type to UINT16?

Regards,
Ray



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Wednesday, March 16, 2016 6:58 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Heyi Guo ; 
Gao, Liming 
Subject: [edk2] [RFC 1/3] MdePkg: Add PCD for UART default receive FIFO depth

PcdUartDefaultReceiveFifoDepth is added to indicate UART default
receive FIFO depth.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo 
Cc: Michael D Kinney 
Cc: Liming Gao 
---
MdePkg/MdePkg.dec | 4 
1 file changed, 4 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 47a1cd7..87ec552 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2074,6 +2074,10 @@
   # @ValidRange 0x8001 | 0 - 4
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x0024

+  ## Indicates the receive FIFO depth of UART controller.
+  # @Prompt Default UART Receive FIFO Depth.
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|1|UINT32|0x0030
+
   ## Error level for hardware recorder.
   #  If value 0, platform does not support feature of hardware error record.
   # @Prompt Error Level For Hardware Recorder
--
2.7.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 0/7] ArmPkg/ArmExceptionLib cleanup

[Leif Lindholm]

On Thu, Mar 17, 2016 at 02:20:08PM +0100, Ard Biesheuvel wrote:
> After Eugene has kindly contributed his refactored version of the
> ArmExceptionLib, this series cleans up the original migrated code,
> as a general cleanup and optimization effort.

Nice bit of cleanup.

For the series:
Reviewed-by: Leif Lindholm 

> Ard Biesheuvel (7):
>   ArmPkg/AsmMacroIoLibV8: remove undocumented assumption from ELx macros
>   ArmPkg/ArmExceptionLib: fold exception handler prologue into vector
> table
>   ArmPkg/ArmExceptionLib: stack FPSR on common path
>   ArmPkg/ArmExceptionLib: don't restore ESR and FAR upon exception
> return
>   ArmPkg/ArmExceptionLib: make build time define visible to the compiler
>   ArmPkg/ArmExceptionLib: avoid indirect call if using vector table in
> place
>   ArmPkg/ArmExceptionLib: reimplement register stack/unstack routines
> 
>  ArmPkg/Include/AsmMacroIoLibV8.h  |  15 +-
>  ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 345 
> 
>  ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c  |   6 +-
>  3 files changed, 156 insertions(+), 210 deletions(-)
> 
> -- 
> 2.5.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65 causes UEFI boot freeze (armv8 platform)

[Ard Biesheuvel]

On 18 March 2016 at 14:34, Cohen, Eugene  wrote:
> Vladimir,
>
>> Loading driver at 0x000BBE23000 EntryPoint=0x000BBE23280
>> ArmTimerDxe.efi
>
> This is the point where the Timer driver will register with the interrupt 
> controller driver and enable timer tick interrupts so the first IRQ interrupt 
> will fire shortly thereafter.
>
>> JTAG debug shows that the CPU is looping in IrqSpx:
>> EL2:0x85008A80 : BIrqSPx ; 0x85008A80
>
> This instruction does not correspond to the new exception handling code 
> (ArmExceptionLib).  Based on my searching the only place I see a construct 
> like this is in DebugAgentException.S 
> (ArmPkg\Library\DebugAgentSymbolsBaseLib).
>
> I haven't used this library but understand that it (the library class, at 
> least) intended to assist with source level debugging (GDB agent over serial 
> port or equivalent).  This particular instance doesn't actually appear to be 
> a debug agent nor does it implement the SaveAndSetDebugTimerInterrupt.   This 
> instance is installing exception handlers that just spin but now that's 
> overlapping with the responsibilities of CpuExceptionHandlerLib (and the 
> DefaultExceptionHandlerLib which provides more useful output than a 
> spinloop).  We don't want yet another copy of exception handlers floating 
> around (which is the whole point behind ArmExceptionLib), instead we need to 
> find a way to make them work together or at least rip out the exception 
> vector init from this driver.
>
> Regardless, when CpuDxe initializes exceptions it should be taking over 
> exception vectors including the IRQ handler.  Since I don't have a platform 
> to test this with at the moment, can you help debug it by stepping through  
> InitializeExceptions in CpuDxe and see what is happening with regard to the 
> exception table (VBAR programming, and the contents at that address)?
>
> Also please help me duplicate your setup - can you confirm which libraries 
> you are using (are you using the ArmPkg DebugAgentSymbolsBaseLib?) and which 
> components (SEC or otherwise) are using it?
>

You need to change the resolution for CpuExceptionHandlerLib in your
platform definition:

-  
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
+  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: add UNUSED notation to Base.h

[Leif Lindholm]

On 17 March 2016 at 19:51, Laszlo Ersek  wrote:
>> I must confess to no small amount of surprise that optionally adding
>> the ability to tag an unused argument as unused is controversial.
>
> I'm also surprised, but by a different thing. :)

> (2) Beyond removing "-Wno-unused-but-set-variable", I then added
> "-Wunused-parameter -Wunused-but-set-parameter".
>
> Oh boy. :) First, a large number of "AutoGen.c" files (maybe all of
> them?) seem to hit it. I simply filtered those out.

Yeah, so far I have:

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py
b/BaseTools/Source/Python/AutoGen/GenC.py
index 842d8bd..418bc47 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -59,6 +59,9 @@ gAutoGenHeaderString = TemplateString("""\
 ${FileName}
   Abstract:   Auto-generated ${FileName} for building module or library.
 **/
+#pragma GCC diagnostic ignored "-Wunused-macros"
+#pragma GCC diagnostic ignored "-Wmissing-variable-declarations"
+#pragma GCC diagnostic ignored "-Wunused-parameter"
 """)

 gAutoGenHPrologueString = TemplateString("""


(No, I'm _not_ suggesting merging that. Hilariously, that snippet
causes build failures with GCC due to unknown pragmas...)

> Second, the remaining set of warnings is also huge: almost 4000
> instances. The list of locations is too large to attach or paste (and I
> don't think the list will allow compressed attachments), so I'm
> uploading it here:
> .
>
> If I understand correctly, if we wanted to enable "-Wunused-parameter
> -Wunused-but-set-parameter" even just occasionally, these ~4000
> instances would have to be audited, and each should be either fixed
> (i.e., internal functions should drop the parameters) or marked UNUSED
> (i.e., library instances and PPI/protocol implementations should
> annotate their definitions of public functions).
>
> Thus, this is what surprises me. It looks daunting.

Oh indeed.
I just wanted to tools to enable it - and it sounds like that bit is
not the controversial one.

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

Re: [edk2] [PATCH] ArmPkg/AArch64Mmu: use correct AP[] bits in ArmClearMemoryRegionReadOnly

[Leif Lindholm]

On Thu, Mar 17, 2016 at 02:55:00PM +0100, Ard Biesheuvel wrote:
> The function ArmClearMemoryRegionReadOnly() was supposed to undo the
> effect of ArmSetMemoryRegionReadOnly(), but instead, it sets the permissions
> to EL0-no access, EL1-read-only. Since the EL0 bit should be 1 to align
> with EL2/3 (where the bit is SBO), use TT_AP_RW_RW instead, which makes the
> entry read-write for EL0 when executing at EL1, and read-write for all other
> levels.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Happy with the RO->RW, confused by the NO->RW.
I presume this is about consistency?
Why do we need access for EL0?

> ---
>  ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
> index f967a6478840..b7d23c6f3286 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
> @@ -558,7 +558,7 @@ ArmClearMemoryRegionReadOnly (
>return SetMemoryRegionAttribute (
> BaseAddress,
> Length,
> -   TT_AP_NO_RO,
> +   TT_AP_RW_RW,
> ~(TT_ADDRESS_MASK_BLOCK_ENTRY | TT_AP_MASK));
>  }
>  
> -- 
> 2.5.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 1/3] MdePkg: Add PCD for UART default receive FIFO depth

[Heyi Guo]

PcdUartDefaultReceiveFifoDepth is added to indicate UART default
receive FIFO depth.
Type of UINT16 is enough for FIFO depth.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ruiyu Ni 
---
 MdePkg/MdePkg.dec | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 47a1cd7..6f416fd 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2074,6 +2074,10 @@
   # @ValidRange 0x8001 | 0 - 4
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x0024
 
+  ## Indicates the receive FIFO depth of UART controller.
+  # @Prompt Default UART Receive FIFO Depth.
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|1|UINT16|0x0030
+
   ## Error level for hardware recorder.
   #  If value 0, platform does not support feature of hardware error record.
   # @Prompt Error Level For Hardware Recorder
-- 
2.7.0

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

Re: [edk2] [PATCH v2] OvmfPkg/PlatformPei: Fix VS2008 build breakage

[Laszlo Ersek]

On 03/19/16 01:19, David Woodhouse wrote:

> Isn't that i18n.commitencoding=latin2 config on your part somewhat
> gratuitous? The idea is that the tools are converting everything on the
> way in and out, and that *only* affects the commit objects that are
> actually encoded in the repository, right? So letting that be UTF-8 to
> match the default shouldn't even be *visible* to you, should it? Except
> that you probably wouldn't have suffered that git-send-email bug you
> mentioned?

With i18n.commitencoding=UTF-8, git expects me to write the commit
messages in UTF-8. My main editor doesn't do UTF-8.

Most of the time neither UTF-8 nor latin[12] are necessary; I write my
own commit messages only in ASCII. So that is certainly accommodated by
sticking with the default (UTF-8).

However, occasionally I have to make an excursion into latin2 (which
partially overlaps latin1 too), for people's names. This can be covered
by setting i18n.commitencoding to latin2 -- it doesn't break ASCII, and
allows me to paste most (latin script) names transparently, using my
main editor.

If I switched i18n.commitencoding back to UTF-8, then I'd have to edit
commit messages with a UTF-8 capable editor whenever ASCII didn't
suffice, even for names in simple latin script that would otherwise fit
in latin2. That's a huge chore for me.

I utterly hate most wide-spread editors that happen to have good UTF-8
support (emacs, vi*, gedit). "joe" I don't hate, but it still doesn't
have all the macros and commands that I use all the time in my main
editor, even while editing commit messages. (Sometimes I draw ASCII
diagrams in commit messages. I have shortcuts for pasting frequent Cc:'s
quickly. I have a dedicated wrapping mode for commit messages. And so on.)

People customize the heck out of their programmable editors (mostly
emacs and vim); I do the same with mine, it just happens to lack UTF-8.

Hm Wait a second. I just realized there is a git hook called
"commit-msg":

   commit-msg
   This hook is invoked by git commit, and can be bypassed with
   --no-verify option. It takes a single parameter, the name of
   the file that holds the proposed commit log message. Exiting
   with non-zero status causes the git commit to abort.

   The hook is allowed to edit the message file in place, and can
   be used to normalize the message into some project standard
   format (if the project has one). It can also be used to refuse
   the commit after inspecting the message file.

   The default commit-msg hook, when enabled, detects duplicate
   "Signed-off-by" lines, and aborts the commit if one is found.

Okay, here's what I'll do. I will switch i18n.commitencoding back to
UTF-8. And, I will add a commit-msg hook that converts the commit
message in-place from latin2 to UTF-8, with "iconv". That should keep us
both happy. Deal?

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

Re: [edk2] [PATCH] MdePkg: add UNUSED notation to Base.h

[Kinney, Michael D]

Andrew,

I agree that adding UNUSED to Base.h solves the issues that multiple packages
may want to enable that warning and have a way to decorate implementation so
the warning is not generated.

I did mix two topics in this discussion.  One is code review of UNUSED macro,
and the other is an EDK II C Coding Style topic.  As long as use of UNUSED
is optional, and each package/module owner gets to decide if use of UNUSED
is required or not, then I am ok with adding the macro to Base.h.

We may want to add comments above the UNUSED macro in Base.h to provide a 
more detailed description that describes that it is optional and if/when it
should be used.

We will also need to decide if we want any statements in the EDK II  C Coding 
Style document about use of the UNUSED macro, but that is likely its own thread.

Mike

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Thursday, March 17, 2016 2:03 PM
> To: Laszlo Ersek 
> Cc: Leif Lindholm ; Kinney, Michael D
> ; edk2-devel@lists.01.org 
> ; Qiu,
> Shumin ; Gao, Liming ; Ard 
> Biesheuvel
> 
> Subject: Re: [edk2] [PATCH] MdePkg: add UNUSED notation to Base.h
> 
> 
> > On Mar 17, 2016, at 12:57 PM, Laszlo Ersek  wrote:
> >
> > On 03/17/16 20:51, Laszlo Ersek wrote:
> >> (adding Ard and Shumin because the below will tie in with another thread)
> >>
> >> On 03/17/16 19:05, Leif Lindholm wrote:
> >>
> >>> I must confess to no small amount of surprise that optionally adding
> >>> the ability to tag an unused argument as unused is controversial.
> >
> >> If I understand correctly, if we wanted to enable "-Wunused-parameter
> >> -Wunused-but-set-parameter" even just occasionally, these ~4000
> >> instances would have to be audited, and each should be either fixed
> >> (i.e., internal functions should drop the parameters) or marked UNUSED
> >> (i.e., library instances and PPI/protocol implementations should
> >> annotate their definitions of public functions).
> >>
> >> Thus, this is what surprises me. It looks daunting.
> >
> > Small clarification: if you'd like to selectively add
> > "-Wunused-parameter -Wunused-but-set-parameter" to the [BuildOptions] of
> > a number of (non-core?) modules (in their INF files), and employ UNUSED
> > in connection with that, I certainly think that's a valid use case.
> >
> > To me it does justify this patch. Namely, perhaps marking parameters as
> > UNUSED will not be enforced across the entire tree, but if a module
> > owner would like to enable those warnings on his/her turf, then he/she
> > should be able to annotate the unused parameters with a macro that is
> > centrally defined. The macro definition should be universal, even though
> > its application might not be.
> >
> 
> That sounds reasonable to me.
> 
> I think in general you will find that Mike Kinney and I are for turning on 
> every
> compiler warning that is practical to use.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks
> > Laszlo
> >
> > ___
> > 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 V2 1/2] MdeModulePkg DxeCore: Check Start consistently in CoreConvertPagesEx

[Star Zeng]

Current check:
ASSERT (NumberOfPages);
ASSERT ((Start & EFI_PAGE_MASK) == 0);
ASSERT (End > Start) ;

if (NumberOfPages == 0 ||
((Start & EFI_PAGE_MASK) != 0) ||
(Start > (Start + NumberOfBytes))) {

This patch is to update "(Start > (Start + NumberOfBytes))" to "(Start >= End)"
to be consistent with "ASSERT (End > Start)"

Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 9dbb85da7c87..62738a187546 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1,7 +1,7 @@
 /** @file
   UEFI Memory page management functions.
 
-Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 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
@@ -725,7 +725,7 @@ CoreConvertPagesEx (
   ASSERT_LOCKED (&gMemoryLock);
   ASSERT ( (ChangingType == FALSE) || (ChangingAttributes == FALSE) );
 
-  if (NumberOfPages == 0 || ((Start & EFI_PAGE_MASK) != 0) || (Start > (Start 
+ NumberOfBytes))) {
+  if (NumberOfPages == 0 || ((Start & EFI_PAGE_MASK) != 0) || (Start >= End)) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 structure definition.

[Gao, Liming]

Tapan:
  Consumer can base on version value to know the structure size and date. We 
don't need to add old version structure definition.

Thanks
Liming
From: Shah, Tapan [mailto:tapands...@hpe.com]
Sent: Thursday, March 17, 2016 3:54 AM
To: edk2-devel@lists.01.org; Kinney, Michael D ; 
Gao, Liming 
Cc: Carsey, Jaben ; El-Haj-Mahmoud, Samer 

Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 
structure definition.

Michael / Liming,
Can you please help review this change?

Thanks,
Tapan

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, March 16, 2016 12:58 PM
To: Shah, Tapan ; edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer ; Carsey, Jaben
Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 
structure definition.

Looks good.

Reviewed-by: Jaben Carsey

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, March 16, 2016 10:31 AM
> To: edk2-devel@lists.01.org
> Cc: samer.el-haj-mahm...@hpe.com; 
> Carsey, Jaben
> ; Tapan Shah
> Subject: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and
> V2 structure definition.
>
> Add V1 and V2 structure definitions for EFI_FIRMWARE_IMAGE_DESCRIPTOR
> structure. Consumer of the protocol needs correct structure definition
> to decode structure fields correctly.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah
> ---
> MdePkg/Include/Protocol/FirmwareManagement.h | 116
> +++
> 1 file changed, 116 insertions(+)
>
> diff --git a/MdePkg/Include/Protocol/FirmwareManagement.h
> b/MdePkg/Include/Protocol/FirmwareManagement.h
> index e615573..67f19fd 100644
> --- a/MdePkg/Include/Protocol/FirmwareManagement.h
> +++ b/MdePkg/Include/Protocol/FirmwareManagement.h
> @@ -10,6 +10,7 @@
>
> Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.

> Copyright (c) 2013 - 2014, Hewlett-Packard Development Company,
> L.P.

> + (C) Copyright 2016 Hewlett Packard Enterprise Development LP

> 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 @@ -119,6 +120,121 @@ typedef struct {
> UINT64 HardwareInstance;
> } EFI_FIRMWARE_IMAGE_DESCRIPTOR;
>
> +#define EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V1 1
> +#define EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V2 2
> +
> +///
> +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec < 2.4a /// typedef
> +struct {
> + ///
> + /// A unique number identifying the firmware image within the
> +device. The
> number is
> + /// between 1 and DescriptorCount.
> + ///
> + UINT8 ImageIndex;
> + ///
> + /// A unique number identifying the firmware image type.
> + ///
> + EFI_GUID ImageTypeId;
> + ///
> + /// A unique number identifying the firmware image.
> + ///
> + UINT64 ImageId;
> + ///
> + /// A pointer to a null-terminated string representing the firmware
> + image
> name.
> + ///
> + CHAR16 *ImageIdName;
> + ///
> + /// Identifies the version of the device firmware. The format is
> + vendor
> specific and new
> + /// version must have a greater value than an old version.
> + ///
> + UINT32 Version;
> + ///
> + /// A pointer to a null-terminated string representing the firmware
> + image
> version name.
> + ///
> + CHAR16 *VersionName;
> + ///
> + /// Size of the image in bytes. If size=0, then only ImageIndex
> + and
> ImageTypeId are valid.
> + ///
> + UINTN Size;
> + ///
> + /// Image attributes that are supported by this device. See 'Image
> + Attribute
> Definitions'
> + /// for possible returned values of this parameter. A value of 1
> + indicates
> the attribute is
> + /// supported and the current setting value is indicated in 
> AttributesSetting.
> A
> + /// value of 0 indicates the attribute is not supported and the
> + current
> setting value in
> + /// AttributesSetting is meaningless.
> + ///
> + UINT64 AttributesSupported;
> + ///
> + /// Image attributes. See 'Image Attribute Definitions' for
> + possible returned
> values of
> + /// this parameter.
> + ///
> + UINT64 AttributesSetting;
> + ///
> + /// Image compatibilities. See 'Image Compatibility Definitions'
> + for possible
> returned
> + /// values of this parameter.
> + ///
> + UINT64 Compatibilities;
> +} EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1;
> +
> +
> +///
> +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec > 2.4a and < 2.5 ///
> +typedef struct {
> + ///
> + /// A unique number identifying the firmware image within the
> +device. The
> number is
> + /// between 1 and DescriptorCount.
> + ///
> + UINT8 ImageIndex;
> + ///
> + /// A unique number identifying the firmware image type.
> + ///
> + EFI_GUID ImageTypeId;
> + ///
> + /// A unique number identifying the firmware image.
> + ///
> + UINT64 ImageId;
> + ///
> + /// A pointer to

Re: [edk2] Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65 causes UEFI boot freeze (armv8 platform)

[Vladimir Olovyannikov]

Hi Ard, Eugene,

Thanks a lot for your help.
You were absolutely right: I forgot to switch from
CpuExceptionhandlerLibNull to ArmExceptionLib in my platform dsc file.

Everything is OK now.

Eugene, please let me know if you still want to do some testing on the
platform.

Thank you,
Vladimir
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, March 18, 2016 7:00 AM
To: Cohen, Eugene
Cc: Vladimir Olovyannikov; edk2-devel@lists.01.org
Subject: Re: Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65
causes UEFI boot freeze (armv8 platform)

On 18 March 2016 at 14:34, Cohen, Eugene  wrote:
> Vladimir,
>
>> Loading driver at 0x000BBE23000 EntryPoint=0x000BBE23280
>> ArmTimerDxe.efi
>
> This is the point where the Timer driver will register with the interrupt
> controller driver and enable timer tick interrupts so the first IRQ
> interrupt will fire shortly thereafter.
>
>> JTAG debug shows that the CPU is looping in IrqSpx:
>> EL2:0x85008A80 : BIrqSPx ; 0x85008A80
>
> This instruction does not correspond to the new exception handling code
> (ArmExceptionLib).  Based on my searching the only place I see a construct
> like this is in DebugAgentException.S
> (ArmPkg\Library\DebugAgentSymbolsBaseLib).
>
> I haven't used this library but understand that it (the library class, at
> least) intended to assist with source level debugging (GDB agent over
> serial port or equivalent).  This particular instance doesn't actually
> appear to be a debug agent nor does it implement the
> SaveAndSetDebugTimerInterrupt.   This instance is installing exception
> handlers that just spin but now that's overlapping with the
> responsibilities of CpuExceptionHandlerLib (and the
> DefaultExceptionHandlerLib which provides more useful output than a
> spinloop).  We don't want yet another copy of exception handlers floating
> around (which is the whole point behind ArmExceptionLib), instead we need
> to find a way to make them work together or at least rip out the exception
> vector init from this driver.
>
> Regardless, when CpuDxe initializes exceptions it should be taking over
> exception vectors including the IRQ handler.  Since I don't have a
> platform to test this with at the moment, can you help debug it by
> stepping through  InitializeExceptions in CpuDxe and see what is happening
> with regard to the exception table (VBAR programming, and the contents at
> that address)?
>
> Also please help me duplicate your setup - can you confirm which libraries
> you are using (are you using the ArmPkg DebugAgentSymbolsBaseLib?) and
> which components (SEC or otherwise) are using it?
>

You need to change the resolution for CpuExceptionHandlerLib in your
platform definition:

-
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
+  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[David Woodhouse]

On Fri, 2016-03-18 at 17:08 +0100, Laszlo Ersek wrote:
> On 03/18/16 14:59, David Woodhouse wrote:
> > Sometimes, stuff just broke and you just fix it up and move on. Let the
> > people who *did* it work it out for themselves and that actually forms
> > a *better* learning experience for them.
>
> Yes, this is how it should work, but if the fix takes an inconveniently
> long time, the problem will likely impede my own work.

If we can agree on a policy of "if it breaks, revert it", then such
things *shouldn't* take an inconveniently long time.

As long as history is preserved correctly and subsequent work hasn't
been rebased on top of the offending commit(s), of course. If you have
a full history, even if merges have happened, then it's not so hard to
take out the offending commits as long as they're recent.

Of course, CI on submissions helps to avoid the problem altogether. To
a certain extent, at least.
   
> > That's an
> > oversight... the tools can run builds on various platforms and right
> > there in the ticket it can show that it doesn't build in certain
> > configurations. With a big red cross right above the 'merge' button :)
>
> I've never heard of this. Would github operate the CI, or would it be
> some external CI, to be integrated with github?

External, triggered by github.

See https://github.com/openssl/openssl/pulls for example.

Each PR has a green tick or a red cross by it, indicating whether the
automatic builds succeeded. Although it's perhaps a bad example because
OpenSSL has a lot of false failures at the moment. But still you get
the idea. Go into one of the failed, and one of the succeeded, PRs and
you'll see what it looks like in the ticket itself as you view it.

> > > Feel free to reopen the pull requests (if you don't have the
> > > credentials, I can reopen them for you).
>
> You didn't respond to this. Is it okay with you if we delay reopening
> your pulls (#70 and #71) until we can disable the merge button (with
> those two settings you discovered)?

That was the intention implicit in the fact that I waited. I may reopen
the CRLF one as soon as the commit *after* my Windows build fix (qv)
goes into the tree, because that will be *guaranteed* not to merge even
if someone does hit the button :)

> I'll probably feel less threatened about github PRs once the merge
> button is disabled, but I would nonetheless like all patches in a pull
> request to be posted to the list, with the pull request details present
> in the blurb.

Yes, I think that's an important part of any process we come up with
even when it includes github PRs. It doesn't *bypass* the mailing list.

> > Perhaps if we can fix the CRLF thing then applying patches will get a
> > little easier.

> It should, yes.

FWIW this seems to be working. I can do checkouts on Windows and if I
have core.autocrlf set in my git config then I get CRLF line endings in
all the checked out files just as before. And if I *don't* have that
set, then I get LF but it works fine anywy.,

With core.autocrlf set, just pulling the commit which changes the
*internal* representation from CRLF to LF basically does nothing to the
checked-out files since they remain CRLF.

I haven't worked out how to *automatically* set the core.autocrlf for
the repository, similar to the way that .gitattributes works. But given
that things work OK even without it, I think that's fine.

I want to redo all my testing after that VS2008 build fix has landed,
so I'm not perturbing all my tests. And obviously let some other people
test it. But I'm fairly happy with it.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Rescale ConSplitter Absolute Pointer.

[Lin, Derek (HPS UEFI Dev)]

The U64 mult/div fix seems good. Thanks for fixing it!

Thanks,
Derek

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Thursday, March 17, 2016 9:13 AM
To: Laszlo Ersek 
Cc: Ni, Ruiyu ; Tian, Feng ; Lin, 
Derek (HPS UEFI Dev) ; edk2-devel@lists.01.org 

Subject: Re: [edk2] [PATCH] MdeModulePkg: Rescale ConSplitter Absolute Pointer.

On 2016/3/16 19:53, Laszlo Ersek wrote:
> On 03/16/16 09:22, Zeng, Star wrote:
>> Pushed at 30ed3422ab2de03abf7c1433ebb482f6e5e16f45.
>>
>> Thanks,
>> Star
>
> This patch breaks the Ia32 build of OVMF (found by Gerd's Jenkins 
> auto-builder):
>
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe/OUTPUT/ConSplitterDxe.lib(ConSplitter.obj):
>  In function `ConSplitterAbsolutePointerGetState':
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c:4159: undefined 
> reference to `__udivdi3'
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c:4162: undefined 
> reference to `__udivdi3'
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c:4165: undefined 
> reference to `__udivdi3'

First saw this email, then I was going to update the code.
When I was trying to send patch for this, I saw the email that has 
pushed the fix and I am glad to see it.


Thanks,
Star

>
> Namely,
>
>> On 2016/3/15 10:11, Ni, Ruiyu wrote:
>>>
>>>
>>> Reviewed-by: Ruiyu Ni 
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
 Of Derek Lin
 Sent: Wednesday, March 9, 2016 4:35 PM
 To: edk2-devel@lists.01.org
 Cc: Derek Lin 
 Subject: [edk2] [PATCH] MdeModulePkg: Rescale ConSplitter Absolute
 Pointer.

 ConSplitter's Absolute Pointer should scale virtual device's
 resolution like what Simple Pointer do.
 Before this change, caller will get Virtual device's resolution but
 physical device's current point.
 This change let caller get Virtual device's resolution with virtual
 device's current point.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Derek Lin 
 ---
 .../Universal/Console/ConSplitterDxe/ConSplitter.c | 43
 ++
 1 file changed, 36 insertions(+), 7 deletions(-)

 diff --git a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
 b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
 index dae97b0..af90d5e 100644
 --- a/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
 +++ b/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c
 @@ -17,6 +17,7 @@
 device situation.

 Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
 +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 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
 @@ -4096,7 +4097,18 @@ ConSplitterAbsolutePointerGetState (
 EFI_STATUSReturnStatus;
 UINTN Index;
 EFI_ABSOLUTE_POINTER_STATECurrentState;
 -
 +  UINT64MinX;
 +  UINT64MinY;
 +  UINT64MinZ;
 +  UINT64MaxX;
 +  UINT64MaxY;
 +  UINT64MaxZ;
 +  UINT64VirtualMinX;
 +  UINT64VirtualMinY;
 +  UINT64VirtualMinZ;
 +  UINT64VirtualMaxX;
 +  UINT64VirtualMaxY;
 +  UINT64VirtualMaxZ;

 Private = TEXT_IN_SPLITTER_PRIVATE_DATA_FROM_ABSOLUTE_POINTER_THIS
 (This);

 @@ -4107,6 +4119,13 @@ ConSplitterAbsolutePointerGetState (
 State->CurrentZ= 0;
 State->ActiveButtons   = 0;

 +  VirtualMinX = Private->AbsolutePointerMode.AbsoluteMinX;
 +  VirtualMinY = Private->AbsolutePointerMode.AbsoluteMinY;
 +  VirtualMinZ = Private->AbsolutePointerMode.AbsoluteMinZ;
 +  VirtualMaxX = Private->AbsolutePointerMode.AbsoluteMaxX;
 +  VirtualMaxY = Private->AbsolutePointerMode.AbsoluteMaxY;
 +  VirtualMaxZ = Private->AbsolutePointerMode.AbsoluteMaxZ;
 +
 //
 // if no physical pointer device exists, return EFI_NOT_READY;
 // if any physical pointer device has changed state,
 @@ -4124,16 +4143,26 @@ ConSplitterAbsolutePointerGetState (
   ReturnStatus = EFI_SUCCESS;
 }

 +  MinX = Private->AbsolutePointerList[Index]->Mode->AbsoluteMinX;
 +  MinY = Private->AbsolutePointerList[Index]->Mode->AbsoluteMinY;
 +  MinZ = Private->AbsolutePointerList[Index]->Mode->AbsoluteMinZ;
 +  MaxX = Private-

Re: [edk2] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Gao, Liming]

Andrew:
  DxeDebugPrintErrorLevelLib has Constructor. DxeHobLib has Constructor. If 
DebugLib also has Constructor, the circle of Constructor() will happen and 
cause build break. DxeDebugPrintErrorLevelLib instance increases the 
possibility of the circle Constructor(). To resolve it, we can update 
DxeDebugPrintErrorLevelLib or DxeHobLib library instance by moving their 
constructor into every function API. 

Thanks
Liming
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Thursday, March 17, 2016 10:50 AM
> To: Zeng, Star
> Cc: edk2-devel; Gao, Liming
> Subject: Re: [edk2] Has any one else had issues trying to use
> DxeDebugPrintErrorLevelLib?
> DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelL
> ib/DxeDebugPrintErrorLevelLib.inf
> 
> 
> > On Mar 16, 2016, at 7:37 PM, Andrew Fish  wrote:
> >
> >>
> >> On Mar 16, 2016, at 7:18 PM, Zeng, Star  wrote:
> >>
> >> On 2016/3/17 10:02, Andrew Fish wrote:
> >>>
>  On Mar 16, 2016, at 6:59 PM, Zeng, Star  wrote:
> 
>  On 2016/3/17 7:12, Andrew Fish wrote:
> > I was trying to move over to DxeDebugPrintErrorLevelLib, but I can't
> get it to build
> >
> > For example I made DXE use
> DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelL
> ib/DxeDebugPrintErrorLevelLib.inf in the EmulatorPkg and I get this error:
> >
> > /Users/andrewfish/work/src/edk2/EmulatorPkg/EmulatorPkg.dsc(...):
> error F002: Library
> [/Users/andrewfish/work/src/edk2/MdePkg/Library/UefiBootServicesTable
> Lib/UefiBootServicesTableLib.inf] with constructors has a cycle
> > consumed by
> /Users/andrewfish/work/src/edk2/MdePkg/Library/UefiLib/UefiLib.inf
> >
> > The error message is not very helpful on root causing the issue
> >
> > But a circular constructor issue does not seem that strange in the
> DebugLib stack as everything uses that! If I go into
> DxeDebugPrintErrorLevelLib.inf  and remove the HobLib I don't get the
> Constructor error, but I do get a link error.
> >
> > So it looks like the DxeDebugPrintErrorLevelLib depends on the Hob
> lib that depends on the DebugLib that depends on the
> DxeDebugPrintErrorLevelLib. How did this every work? The only place I see it
> used is the Nt32Pkg, and I don't have a system to test that on
> 
>  Just tried NT32 with VS2015, and it builds and works well.
> 
>  Liming & Yonghong, any idea on this?
> 
> >>>
> >>> I was wondering if it had to do with the lower level libraries having a
> constructor? So maybe library implementation matters?
> >>
> >> If this circular constructor issue could be reproduced with only one
> module linked with DxeDebugPrintErrorLevelLib (I mean other modules to
> link with BaseDebugPrintErrorLevelLib, only the module links to
> DxeDebugPrintErrorLevelLib), then that may be helpful to scrub all the library
> instances the module links to find out what is the matter. :)
> >>
> >
> > OK in the EmulatorPkg the DXE Core compiles, but
> MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHan
> dlerRuntimeDxe.inf will error out.
> >
> 
> I think it is as simple as you can't have a library with a constructor 
> required by
> the DebugLib (and child libraries) for a library that depends on the DebugLib.
> So the chain to get the DebugLib started depends on the DebugLib.
> 
> That kind of makes DxeDebugPrintErrorLevelLib hard to use I guess?
> 
> Thanks,
> 
> Andrew Fish
> 
> > Library
> > ---
> -
> >
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BasePcdLibNull/BasePc
> dLibNull.inf
> > {PcdLib}
> > /Users/andrewfish/work/src/edk2/MdePkg/Library/BaseLib/BaseLib.inf
> > {BaseLib}
> >
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BaseMemoryLib/BaseM
> emoryLib.inf
> > {BaseMemoryLib}
> >
> /Users/andrewfish/work/src/edk2/MdePkg/Library/DxeCoreEntryPoint/Dxe
> CoreEntryPoint.inf
> > {DxeCoreEntryPoint}
> >
> /Users/andrewfish/work/src/edk2/MdePkg/Library/DxeCoreHobLib/DxeCor
> eHobLib.inf
> > {HobLib}
> >
> /Users/andrewfish/work/src/edk2/MdeModulePkg/Library/DxeDebugPrintE
> rrorLevelLib/DxeDebugPrintErrorLevelLib.inf
> > {DebugPrintErrorLevelLib:  C = DxeDebugPrintErrorLevelLibConstructor D =
> DxeDebugPrintErrorLevelLibDestructor}
> >
> /Users/andrewfish/work/src/edk2/EmulatorPkg/Library/DxeEmuStdErrSerial
> PortLib/DxeEmuStdErrSerialPortLib.inf
> > {SerialPortLib}
> >
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BasePrintLib/BasePrintLi
> b.inf
> > {PrintLib}
> >
> /Users/andrewfish/work/src/edk2/MdePkg/Library/BaseDebugLibSerialPort
> /BaseDebugLibSerialPort.inf
> > {DebugLib:  C = BaseDebugLibSerialPortConstructor}
> >
> /Users/andrewfish/work/src/edk2/EmulatorPkg/Library/DxeEmuLib/DxeEm
> uLib.inf
> > {EmuThunkLib:  C = DxeEmuLibConstructor}
> >
> /Users/andrewfish/work/src/edk2/MdeModulePkg/Library/DxeCoreMemor
> yAllocati

Re: [edk2] [RFC 1/3] MdePkg: Add PCD for UART default receive FIFO depth

[Heyi Guo]

Hi Ruiyu,

I've changed the code and sent out v2 patches. Please help to review.

Thanks.

Heyi

On 03/17/2016 10:29 AM, Ni, Ruiyu wrote:

Heyi,
I agree with the general idea of the patch to add a PCD for 
DefaultReceiveFifoDepth.

I understand you choose UINT32 for the FIFO depth because the
EFI_SERIAL_IO_MODE.ReceiveFifoDepth is of UINT32 type.
But in real world, I believe UINT16 should be enough.

Could you please change the PCD type to UINT16?

Regards,
Ray



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Wednesday, March 16, 2016 6:58 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Heyi Guo ; 
Gao, Liming 
Subject: [edk2] [RFC 1/3] MdePkg: Add PCD for UART default receive FIFO depth

PcdUartDefaultReceiveFifoDepth is added to indicate UART default
receive FIFO depth.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo 
Cc: Michael D Kinney 
Cc: Liming Gao 
---
MdePkg/MdePkg.dec | 4 
1 file changed, 4 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 47a1cd7..87ec552 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2074,6 +2074,10 @@
   # @ValidRange 0x8001 | 0 - 4
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x0024

+  ## Indicates the receive FIFO depth of UART controller.
+  # @Prompt Default UART Receive FIFO Depth.
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|1|UINT32|0x0030
+
   ## Error level for hardware recorder.
   #  If value 0, platform does not support feature of hardware error record.
   # @Prompt Error Level For Hardware Recorder
--
2.7.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] BaseTools: use unsigned chars on ARM architectures

[Andrew Fish]

> On Mar 17, 2016, at 10:51 AM, Leif Lindholm  wrote:
> 
> Hi Andrew,
> 
> On Thu, Mar 17, 2016 at 10:41:37AM -0700, Andrew Fish wrote:
>> FYI, the char sign issue clang hit recently was due to mixing edk2
>> types with standard C type. The edk2 type system does not assume
>> that char is signed or unsigned.
> 
> I agree the type system gets it right, but the processor bindings do
> not :)
> 
>> MdePkg/Include/X64/ProcessorBind.h
>>  ///
>>  /// 1-byte unsigned value
>>  ///
>>  typedef unsigned char   UINT8;
>>  ///
>>  /// 1-byte Character
>>  ///
>>  typedef charCHAR8;
> 
> On X64 and IA32, this will be unsigned with XCODE5 toolchains and
> signed with other toolchains.
> 

Depends how you look at it CHAR8 is compatible with char. But you can't assume 
that char or CHAR8 is the same as UINT8 or INT8. 

Are you advocating we force CHAR8 to be signed? 

Thanks,

Andrew Fish

> Regards,
> 
> Leif
> 
>>  ///
>>  /// 1-byte signed value
>>  ///
>>  typedef signed char INT8;
>> 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Mar 17, 2016, at 6:22 AM, Leif Lindholm  wrote:
>>> 
>>> By default, the ARM architectures have unsigned chars, whereas the other
>>> architectures supported by EDK2 by default have signed chars.
>>> However, EDK2 uses -funsigned-chars on those architectures to change the
>>> default behaviour.
>>> 
>>> Unfortunately, the ARM architectures explicitly break their default
>>> behaviour by specifying -fsigned-chars (I presume in a pre-emptive
>>> attempt at avoiding incompatibility).
>>> 
>>> Since this situation is already confusing enough, switch the ARM
>>> architectures to also specify -funsigned-chars explicitly rather than
>>> just dropping the current parameter.
>>> 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Leif Lindholm 
>>> ---
>>> BaseTools/Conf/tools_def.template | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index b1577af..eedf80f 100644
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -4322,8 +4322,8 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os 
>>> -fshort-wchar -fno-strict-aliasing -
>>> DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
>>> -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
>>> -mno-stack-arg-probe
>>> DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
>>> -Wno-address -mno-stack-arg-probe
>>> DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
>>> -minline-int-divide-min-latency
>>> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>>> -mabi=aapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections 
>>> -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
>>> -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>>> -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
>>> -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
>>> -Wno-address -fno-asynchronous-unwind-tables
>>> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>>> -mabi=aapcs -fno-short-enums -save-temps -funsigned-char 
>>> -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address 
>>> -mthumb -mfloat-abi=soft
>>> +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
>>> -fno-short-enums -save-temps -fverbose-asm -funsigned-char  
>>> -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
>>> -Wno-address -fno-asynchronous-unwind-tables
>>> DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
>>> DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
>>> DEFINE GCC_DLINK2_FLAGS_COMMON = 
>>> --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
>>> -- 
>>> 2.1.4
>>> 
>>> ___
>>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Zeng, Star]

On 2016/3/17 17:11, Laszlo Ersek wrote:

Adding Ard

On 03/17/16 08:28, Zeng, Star wrote:

On 2016/3/17 15:16, Andrew Fish wrote:



On Mar 17, 2016, at 12:10 AM, Gao, Liming  wrote:

Andrew:
   DxeDebugPrintErrorLevelLib has Constructor. DxeHobLib has
Constructor. If DebugLib also has Constructor, the circle of
Constructor() will happen and cause build break.
DxeDebugPrintErrorLevelLib instance increases the possibility of the
circle Constructor(). To resolve it, we can update
DxeDebugPrintErrorLevelLib or DxeHobLib library instance by moving
their constructor into every function API.



Liming,

Thanks, I came to the same conclusion. I'm making a local copy
DxeDebugPrintErrorLevelLib that does the HOB accesses in the driver
without the HobLib and that will solve our issue. I was just surprised
the edk2 library was not very useful in the real world. Not to mention
the build error message did not help find the real issue, the HOB lib.


I reproduced the issue locally. With the change below to integrate
HobLibConstructor() to GetHobList(), since all other interface of
DxeHobLib are just to call GetHobList(), the issue is gone. What is your
opinion?


This could make it possible for ArmVirtPkg to remove the
ArmVirtDxeHobLib library instance. That library instance was cloned
exactly in order to break this dependency cycle, see commit ad90df8ac0.

I think the proposal and the patch are good.


Thanks for the comments.
Got more information (interesting for me, but seems bad news) after 
running NT32 with the code change.


1. With the code change, the AutoGen.c of PcdDxe(The first executed DXE 
driver except DxeMain) has below list for 
ProcessLibraryConstructorList(), that makes NT32 run into exception.


VOID
EFIAPI
ProcessLibraryConstructorList ( // With the code change
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
  Status = DxeDebugPrintErrorLevelLibConstructor (ImageHandle, 
SystemTable);

  ASSERT_EFI_ERROR (Status);

  Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
  ASSERT_EFI_ERROR (Status);

...

}

Why do the exception happen? Because
DxeDebugPrintErrorLevelLibConstructor() ->
GetDebugPrintErrorLevel() ->
GetFirstGuidHob() ->
GetHobList() ->
EfiGetSystemConfigurationTable() ->
gST->XXX (in UefiLib.c)

But gST is still NULL at this moment as 
UefiBootServicesTableLibConstructor() is not run yet.
To fix it, I still need to refine the code in 
DxeDebugPrintErrorLevelLib.c to do not get HOB in Constructor.


2. Without the code change, the AutoGen.c of PcdDxe(The first executed 
DXE driver except DxeMain) has below list for 
ProcessLibraryConstructorList().


VOID
EFIAPI
ProcessLibraryConstructorList ( // Without the code change
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
  Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
  ASSERT_EFI_ERROR (Status);

...

  Status = DxeDebugPrintErrorLevelLibConstructor (ImageHandle, 
SystemTable);

  ASSERT_EFI_ERROR (Status);
}

So according to this practice, a Library instance has Constructor makes 
the dependency relationship to be more accurate, but more possible to 
have circular issue. Oppositely without Constructor.


Thanks,
Star



Thanks
Laszlo




9281d5a1b5c201e58a6d1d64ea8d1fe1058dbfc3
  MdePkg/Library/DxeHobLib/DxeHobLib.inf |  1 -
  MdePkg/Library/DxeHobLib/HobLib.c  | 37
+++---
  2 files changed, 7 insertions(+), 31 deletions(-)

diff --git a/MdePkg/Library/DxeHobLib/DxeHobLib.inf
b/MdePkg/Library/DxeHobLib/DxeHobLib.inf
index 32cd5546ab37..cb6e9fa21684 100644
--- a/MdePkg/Library/DxeHobLib/DxeHobLib.inf
+++ b/MdePkg/Library/DxeHobLib/DxeHobLib.inf
@@ -24,7 +24,6 @@ [Defines]
MODULE_TYPE= DXE_DRIVER
VERSION_STRING = 1.0
LIBRARY_CLASS  = HobLib|DXE_DRIVER DXE_RUNTIME_DRIVER
DXE_SAL_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
-  CONSTRUCTOR= HobLibConstructor

  #
  #  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
diff --git a/MdePkg/Library/DxeHobLib/HobLib.c
b/MdePkg/Library/DxeHobLib/HobLib.c
index f0861ffcb4e6..24c14a228adb 100644
--- a/MdePkg/Library/DxeHobLib/HobLib.c
+++ b/MdePkg/Library/DxeHobLib/HobLib.c
@@ -24,35 +24,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
EITHER EXPRESS OR IMPLIED.
  VOID  *mHobList = NULL;

  /**
-  The constructor function caches the pointer to HOB list.
-
-  The constructor function gets the start address of HOB list from
system configuration table.
-  It will ASSERT() if that operation fails and it will always return
EFI_SUCCESS.
-
-  @param  ImageHandle   The firmware allocated handle for the EFI image.
-  @param  SystemTable   A pointer to the EFI System Table.
-
-  @retval EFI_SUCCESS   The constructor successfully gets HobList.
-  @retval Other value   The constructor can't get HobList.
-
-**/
-EFI_STATUS
-EFIAPI
-HobLibConstructor (
-  IN EFI_HANDLEImageHandle,
-  IN

[edk2] [PATCH v2] OvmfPkg/PlatformPei: Fix VS2008 build breakage

[David Woodhouse]

Commit 7b8fe6356 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG /
ECAM) on Q35") broke the VS2008 build, causing it to complain of
"potentially uninitialized local variable 'PciExBarBase' used" at
line 275.

On this occasion it isn't actually wrong — the mHostBridgeDevId variable
is global, so theoretically it *could* change between the two if()
statements.

Of course VS2008 is also a steaming pile of poo, and even if we use
a local boolean variable which definitely *can't* change in the middle,
it still can't work it out and still emits the warning.

So just initialise PciExBarBase to zero to shut the compiler up.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse 
---
Oops, my build test on Windows still had the temporary 'PciExBarBase=0'
to shut the compiler up, so wasn't really exercising the fix I was
submitting. Sorry for the noise.

It turns out that VS2008 really is just a stupid pile of crap.

OvmfPkg/PlatformPei/Platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 0fc2278..20008d0 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -212,7 +212,7 @@ MemMapInitialization (
 
   if (!mXen) {
 UINT32  TopOfLowRam;
-UINT64  PciExBarBase;
+UINT64  PciExBarBase = 0;
 UINT32  PciBase;
 UINT32  PciSize;
 
-- 
2.5.5

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Problem with Author, Sign Off, and IP concerns

[David Woodhouse]

On Wed, 2016-03-16 at 12:15 +0100, Laszlo Ersek wrote:
> My only request is that the "Author:" git metadata header be matched by
> the first Signed-off-by tag.

We use the Signed-off-by tag the same way as everyone else does, don't
we? With reference to the "Developer's Certificate of Origin" as seen
at http://developercertificate.org/? See item (b) therein:

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications,


This covers the case of a Signed-off-by: which doesn't come from the
author, doesn't it? 

The 'Signed-off-by' is something that only that individual can create —
it should never be 'assumed' and constructed by someone else.

So if someone has written some code and committed it to an internal
repository (without a signed-off-by), and has then left the company, it
seems perfectly reasonable for them to still be listed as the *author*
of the work when it's pushed upstream, but for their Signed-off-by to
be absent. And for someone *else* in the company to provide a
Signed-off-by: tag indicating that they have the right to submit it.


-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] OvmfPkg/PlatformPei: Fix VS2008 build breakage

[David Woodhouse]

On Fri, 2016-03-18 at 17:53 +0100, Laszlo Ersek wrote:
> 
> (1) The commit message uses at least one non-ASCII character, the EM
> DASH (U+2014). Can you please replace it with a "--"? Yes, I know you
> hate me for asking this. Please just write me off as stupid and replace
> the character.

No. This isn't 1994. If you wish to change it, go ahead. Don't ask me
to do stupid things for no good reason.

> (2) In the edk2 coding style, initialization of local variables is not
> permitted. Can you please add an assignment instead?

Er, really? What insanity is this? Where did these guidelines come from
and can they be fixed? Why would initialisation of local variables
*ever* be frowned upon? How do they make this stuff up?

> (3) I tried to apply your patch nonetheless. It doesn't apply. I looked
> at the patch email that I saved from Thunderbird. The code section of
> the email contains =C2=A0 quoted-printable sequences. Since the charset
> is UTF-8 (according to the Content-Type header), 0xC2 0xA0 translates to
> U+00A0, "NO-BREAK SPACE".

Hm, that would appear to be an Evolution bug. I think it triggers when
lines have trailing whitespace. I'll investigate. Thanks for pointing
it out.

I can put it in a PR if you prefer... :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] OvmfPkg/PlatformPei: Fix VS2008 build breakage

[Laszlo Ersek]

On 03/18/16 18:45, David Woodhouse wrote:
> On Fri, 2016-03-18 at 17:53 +0100, Laszlo Ersek wrote:
>>
>> (1) The commit message uses at least one non-ASCII character, the EM
>> DASH (U+2014). Can you please replace it with a "--"? Yes, I know you
>> hate me for asking this. Please just write me off as stupid and replace
>> the character.
> 
> No. This isn't 1994.

Really? I wouldn't know. If I look at what ISO C features we're allowed
to use, we certainly seem to be stuck in 1995. Or, well, sometime before
1989, because we can't even use structure assignment.

> If you wish to change it, go ahead.

Thank you, I will.

> Don't ask me
> to do stupid things for no good reason.

There is a good reason. You know it and you don't care about it. Not a
problem; I'll fix up the commit message.

>> (2) In the edk2 coding style, initialization of local variables is not
>> permitted. Can you please add an assignment instead?
> 
> Er, really? What insanity is this?

Please ask your colleagues at Intel (but please also make sure that you
don't take offense on their behalf, when you call their guidelines
insane ;) ).

> Where did these guidelines come from
> and can they be fixed? Why would initialisation of local variables
> *ever* be frowned upon? How do they make this stuff up?

Please consult "EDK II C Coding Standards Specification.pdf", section
6.8 "C Function Layout":

  *Initializing a variable as part of its declaration is illegal.*

(Emphasis theirs.)

> 
>> (3) I tried to apply your patch nonetheless. It doesn't apply. I looked
>> at the patch email that I saved from Thunderbird. The code section of
>> the email contains =C2=A0 quoted-printable sequences. Since the charset
>> is UTF-8 (according to the Content-Type header), 0xC2 0xA0 translates to
>> U+00A0, "NO-BREAK SPACE".
> 
> Hm, that would appear to be an Evolution bug.

\o/

Finally something I'm not held responsible for!

(BTW, why did you mail out the patch with Evolution, rather than
git-send-email? Are you sure you are using the tools as they were
intended? :))

> I think it triggers when
> lines have trailing whitespace. I'll investigate. Thanks for pointing
> it out.
> 
> I can put it in a PR if you prefer... :)

Works for me, but please send the pull request to the mailing list. I'll
rebase the commit for the commit message fixup, and for adding my R-b,
but I'll keep the base commit / history intact.

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

[edk2] [PATCH 7/7] ArmPkg/ArmExceptionLib: reimplement register stack/unstack routines

[Ard Biesheuvel]

This replaces the somewhat opaque preprocessor based stack/unstack macros
with open coded ldp/stp sequences to preserve the interrupted context
before handing over to the exception handler in C.

This removes various arithmetic operations on the stack pointer, and
reduces the exception return critical section to its minimum size (i.e.,
the bare minimum required to populate the ELR and SPSR registers and invoke
the eret).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 235 
+---
 1 file changed, 109 insertions(+), 126 deletions(-)

diff --git a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S 
b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
index 0fd304db2dbf..fef7d908c1cc 100644
--- a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
+++ b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
@@ -107,54 +107,6 @@ GCC_ASM_EXPORT(CommonCExceptionHandler)
 #define FP_CONTEXT_SIZE(32 * 16)
 #define SYS_CONTEXT_SIZE   ( 6 *  8) // 5 SYS regs + Alignment requirement 
(ie: the stack must be aligned on 0x10)
 
-// Cannot str x31 directly
-#define ALL_GP_REGS \
-REG_PAIR (x0,  x1,  0x000, GP_CONTEXT_SIZE);\
-REG_PAIR (x2,  x3,  0x010, GP_CONTEXT_SIZE);\
-REG_PAIR (x4,  x5,  0x020, GP_CONTEXT_SIZE);\
-REG_PAIR (x6,  x7,  0x030, GP_CONTEXT_SIZE);\
-REG_PAIR (x8,  x9,  0x040, GP_CONTEXT_SIZE);\
-REG_PAIR (x10, x11, 0x050, GP_CONTEXT_SIZE);\
-REG_PAIR (x12, x13, 0x060, GP_CONTEXT_SIZE);\
-REG_PAIR (x14, x15, 0x070, GP_CONTEXT_SIZE);\
-REG_PAIR (x16, x17, 0x080, GP_CONTEXT_SIZE);\
-REG_PAIR (x18, x19, 0x090, GP_CONTEXT_SIZE);\
-REG_PAIR (x20, x21, 0x0a0, GP_CONTEXT_SIZE);\
-REG_PAIR (x22, x23, 0x0b0, GP_CONTEXT_SIZE);\
-REG_PAIR (x24, x25, 0x0c0, GP_CONTEXT_SIZE);\
-REG_PAIR (x26, x27, 0x0d0, GP_CONTEXT_SIZE);\
-REG_PAIR (x28, x29, 0x0e0, GP_CONTEXT_SIZE);\
-REG_ONE  (x30,  0x0f0, GP_CONTEXT_SIZE);
-
-// In order to save the SP we need to put it somewhere else first.
-// STR only works with XZR/WZR directly
-#define SAVE_SP \
-add x1, sp, #(FP_CONTEXT_SIZE + SYS_CONTEXT_SIZE); \
-REG_ONE (x1,0x0f8, GP_CONTEXT_SIZE);
-
-#define ALL_FP_REGS \
-REG_PAIR (q0,  q1,  0x000, FP_CONTEXT_SIZE);\
-REG_PAIR (q2,  q3,  0x020, FP_CONTEXT_SIZE);\
-REG_PAIR (q4,  q5,  0x040, FP_CONTEXT_SIZE);\
-REG_PAIR (q6,  q7,  0x060, FP_CONTEXT_SIZE);\
-REG_PAIR (q8,  q9,  0x080, FP_CONTEXT_SIZE);\
-REG_PAIR (q10, q11, 0x0a0, FP_CONTEXT_SIZE);\
-REG_PAIR (q12, q13, 0x0c0, FP_CONTEXT_SIZE);\
-REG_PAIR (q14, q15, 0x0e0, FP_CONTEXT_SIZE);\
-REG_PAIR (q16, q17, 0x100, FP_CONTEXT_SIZE);\
-REG_PAIR (q18, q19, 0x120, FP_CONTEXT_SIZE);\
-REG_PAIR (q20, q21, 0x140, FP_CONTEXT_SIZE);\
-REG_PAIR (q22, q23, 0x160, FP_CONTEXT_SIZE);\
-REG_PAIR (q24, q25, 0x180, FP_CONTEXT_SIZE);\
-REG_PAIR (q26, q27, 0x1a0, FP_CONTEXT_SIZE);\
-REG_PAIR (q28, q29, 0x1c0, FP_CONTEXT_SIZE);\
-REG_PAIR (q30, q31, 0x1e0, FP_CONTEXT_SIZE);
-
-#define ALL_SYS_REGS\
-REG_PAIR (x1,  x2,  0x000, SYS_CONTEXT_SIZE);   \
-REG_PAIR (x3,  x4,  0x010, SYS_CONTEXT_SIZE);   \
-REG_ONE  (x5,   0x020, SYS_CONTEXT_SIZE);
-
 //
 // There are two methods for installing AArch64 exception vectors:
 //  1. Install a copy of the vectors to a location specified by a PCD
@@ -170,18 +122,35 @@ ASM_PFX(ExceptionHandlersStart):
 VECTOR_BASE(ExceptionHandlersStart)
 #endif
 
-#undef  REG_PAIR
-#undef  REG_ONE
-#define REG_PAIR(REG1, REG2, OFFSET, CONTEXT_SIZE)  stp  REG1, REG2, [sp, 
#(OFFSET-CONTEXT_SIZE)]
-#define REG_ONE(REG1, OFFSET, CONTEXT_SIZE) stur REG1, [sp, 
#(OFFSET-CONTEXT_SIZE)]
-
   .macro  ExceptionEntry, val
   // Move the stackpointer so we can reach our structure with the str 
instruction.
   sub sp, sp, #(FP_CONTEXT_SIZE + SYS_CONTEXT_SIZE)
 
-  // Save all the General regs before touching x0 and x1.
-  // This does not save r31(SP) as it is special. We do that later.
-  ALL_GP_REGS
+  // Push some GP registers so we can record the exception context
+  stp  x0, x1, [sp, #-GP_CONTEXT_SIZE]!
+  stp  x2, x3, [sp, #0x10]
+  stp  x4, x5, [sp, #0x20]
+  stp  x6, x7, [sp, #0x30]
+
+  EL1_OR_EL2_OR_EL3(x1)
+1:mrs  x2, elr_el1   // Exception Link Register
+  mrs  x3, spsr_el1  // Saved Processor Status Register 32bit
+  mrs  x5, esr_el1   // EL1 Exception syndrome register 32bit
+  mrs  x6, far_el1   // EL1 Fault Address Register
+  b4f
+
+2:mrs  x2, elr_el2   // 

Re: [edk2] [PATCH] PcAtChipsetPkg/PciHostBridgeDxe: Remove it since MdeModulePkg contains a new one.

[Laszlo Ersek]

On 03/18/16 04:02, Ni, Ruiyu wrote:
> All,
> 
> I would like to hear your concerns by the next weekend (Mar 26/27).
> 
> If there is no concern, I will remove it on the Monday after that (Mar 28).
> 
>  
> 
> And I think I can take Laszlo’s mail below as a r-b response. Can I?

Please post the removal patch first, I'll respond then.

Thanks!
Laszlo

> 
>  
> 
> Regards,
> 
> Ray
> 
>  
> 
> *From:*Laszlo Ersek [mailto:ler...@redhat.com]
> *Sent:* Wednesday, March 16, 2016 9:39 PM
> *To:* Ni, Ruiyu ; edk2-devel@lists.01.org
> 
> *Cc:* Ard Biesheuvel ; Justen, Jordan L
> 
> *Subject:* Re: [edk2] [PATCH] PcAtChipsetPkg/PciHostBridgeDxe: Remove it
> since MdeModulePkg contains a new one.
> 
>  
> 
> On 03/15/16 08:58, Ni, Ruiyu wrote:
>> All,
>> I am going to remove the PciHostBridgeDxe driver from PcAtChipsetPkg.
>> This driver is not used by any platform as far as I know.
>> Any concerns?
> 
> No objection from me (as far as OvmfPkg and ArmVirtPkg are concerned).
> 
> The new core PciHostBridgeDxe has been working out very well for OVMF.
> (ArmVirtPkg will have to stick with its own fork for a while now.)
> 
> Thanks
> Laszlo
> 

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

Re: [edk2] [PATCH] ArmPkg/AArch64Mmu: use correct AP[] bits in ArmClearMemoryRegionReadOnly

[Ard Biesheuvel]

On 17 March 2016 at 16:31, Leif Lindholm  wrote:
> On Thu, Mar 17, 2016 at 02:55:00PM +0100, Ard Biesheuvel wrote:
>> The function ArmClearMemoryRegionReadOnly() was supposed to undo the
>> effect of ArmSetMemoryRegionReadOnly(), but instead, it sets the permissions
>> to EL0-no access, EL1-read-only. Since the EL0 bit should be 1 to align
>> with EL2/3 (where the bit is SBO), use TT_AP_RW_RW instead, which makes the
>> entry read-write for EL0 when executing at EL1, and read-write for all other
>> levels.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>
> Happy with the RO->RW, confused by the NO->RW.
> I presume this is about consistency?
> Why do we need access for EL0?
>

We don't. But when running on EL2 or EL3, the same bit needs to be
set, so either we have two separate definitions, for EL1 and EL2/3, or
we just set the bit for EL0 as well, which shouldn't matter anyway
since we never return to EL0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Laszlo Ersek]

Adding Ard

On 03/17/16 08:28, Zeng, Star wrote:
> On 2016/3/17 15:16, Andrew Fish wrote:
>>
>>> On Mar 17, 2016, at 12:10 AM, Gao, Liming  wrote:
>>>
>>> Andrew:
>>>   DxeDebugPrintErrorLevelLib has Constructor. DxeHobLib has
>>> Constructor. If DebugLib also has Constructor, the circle of
>>> Constructor() will happen and cause build break.
>>> DxeDebugPrintErrorLevelLib instance increases the possibility of the
>>> circle Constructor(). To resolve it, we can update
>>> DxeDebugPrintErrorLevelLib or DxeHobLib library instance by moving
>>> their constructor into every function API.
>>>
>>
>> Liming,
>>
>> Thanks, I came to the same conclusion. I'm making a local copy
>> DxeDebugPrintErrorLevelLib that does the HOB accesses in the driver
>> without the HobLib and that will solve our issue. I was just surprised
>> the edk2 library was not very useful in the real world. Not to mention
>> the build error message did not help find the real issue, the HOB lib.
> 
> I reproduced the issue locally. With the change below to integrate
> HobLibConstructor() to GetHobList(), since all other interface of
> DxeHobLib are just to call GetHobList(), the issue is gone. What is your
> opinion?

This could make it possible for ArmVirtPkg to remove the
ArmVirtDxeHobLib library instance. That library instance was cloned
exactly in order to break this dependency cycle, see commit ad90df8ac0.

I think the proposal and the patch are good.

Thanks
Laszlo


> 
> 9281d5a1b5c201e58a6d1d64ea8d1fe1058dbfc3
>  MdePkg/Library/DxeHobLib/DxeHobLib.inf |  1 -
>  MdePkg/Library/DxeHobLib/HobLib.c  | 37
> +++---
>  2 files changed, 7 insertions(+), 31 deletions(-)
> 
> diff --git a/MdePkg/Library/DxeHobLib/DxeHobLib.inf
> b/MdePkg/Library/DxeHobLib/DxeHobLib.inf
> index 32cd5546ab37..cb6e9fa21684 100644
> --- a/MdePkg/Library/DxeHobLib/DxeHobLib.inf
> +++ b/MdePkg/Library/DxeHobLib/DxeHobLib.inf
> @@ -24,7 +24,6 @@ [Defines]
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>LIBRARY_CLASS  = HobLib|DXE_DRIVER DXE_RUNTIME_DRIVER
> DXE_SAL_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
> -  CONSTRUCTOR= HobLibConstructor
> 
>  #
>  #  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
> diff --git a/MdePkg/Library/DxeHobLib/HobLib.c
> b/MdePkg/Library/DxeHobLib/HobLib.c
> index f0861ffcb4e6..24c14a228adb 100644
> --- a/MdePkg/Library/DxeHobLib/HobLib.c
> +++ b/MdePkg/Library/DxeHobLib/HobLib.c
> @@ -24,35 +24,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
>  VOID  *mHobList = NULL;
> 
>  /**
> -  The constructor function caches the pointer to HOB list.
> -
> -  The constructor function gets the start address of HOB list from
> system configuration table.
> -  It will ASSERT() if that operation fails and it will always return
> EFI_SUCCESS.
> -
> -  @param  ImageHandle   The firmware allocated handle for the EFI image.
> -  @param  SystemTable   A pointer to the EFI System Table.
> -
> -  @retval EFI_SUCCESS   The constructor successfully gets HobList.
> -  @retval Other value   The constructor can't get HobList.
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -HobLibConstructor (
> -  IN EFI_HANDLEImageHandle,
> -  IN EFI_SYSTEM_TABLE  *SystemTable
> -  )
> -{
> -  EFI_STATUS  Status;
> -
> -  Status = EfiGetSystemConfigurationTable (&gEfiHobListGuid, &mHobList);
> -  ASSERT_EFI_ERROR (Status);
> -  ASSERT (mHobList != NULL);
> -
> -  return Status;
> -}
> -
> -/**
>Returns the pointer to the HOB list.
> 
>This function returns the pointer to first HOB in the list.
> @@ -74,7 +45,13 @@ GetHobList (
>VOID
>)
>  {
> -  ASSERT (mHobList != NULL);
> +  EFI_STATUS  Status;
> +
> +  if (mHobList == NULL) {
> +Status = EfiGetSystemConfigurationTable (&gEfiHobListGuid, &mHobList);
> +ASSERT_EFI_ERROR (Status);
> +ASSERT (mHobList != NULL);
> +  }
>return mHobList;
>  }
> 
> 
> 
> 
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> Thanks
>>> Liming
 -Original Message-
 From: af...@apple.com [mailto:af...@apple.com]
 Sent: Thursday, March 17, 2016 10:50 AM
 To: Zeng, Star
 Cc: edk2-devel; Gao, Liming
 Subject: Re: [edk2] Has any one else had issues trying to use
 DxeDebugPrintErrorLevelLib?
 DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelL
 ib/DxeDebugPrintErrorLevelLib.inf


> On Mar 16, 2016, at 7:37 PM, Andrew Fish  wrote:
>
>>
>> On Mar 16, 2016, at 7:18 PM, Zeng, Star  wrote:
>>
>> On 2016/3/17 10:02, Andrew Fish wrote:
>>>
 On Mar 16, 2016, at 6:59 PM, Zeng, Star 
 wrote:

 On 2016/3/17 7:12, Andrew Fish wrote:
> I was trying to move over to DxeDebugPrintErrorLevelLib, but I
> can't
 get it to build
>
> For example I made DXE use
 DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelL

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[Laszlo Ersek]

On 03/18/16 13:43, David Woodhouse wrote:
> On Fri, 2016-03-18 at 13:30 +0100, Laszlo Ersek wrote:
>>
>> Our workflow should not be centered on github pull requests in any case,
>> so I don't see the point in testing them out. 
> 
> Well, thanks for destroying the test I spent this morning setting up,
> because you don't believe it would have useful results.

I feel very bad about it. My main reason was that I found it too risky,
setting a precedent.

> I happen to disagree about using github pull requests. Every change
> there triggers an email,

Except my own actions. I'm already watching the github issue tracker and
get emails of the actions of others. No emails about my own actions. It
makes the email audit trail completely unusable.

> and we can set things up so that email is also
> copied to the mailing list. So it's just as well-archived as the other
> list traffic, and we don't have to worry about github.com disappearing
> in a puff of smoke any more than we already did.
> 
>> workflow centered on pull requests that are sent to the mailing list
>> should be tested out, and I'd like to work with you on that.
> 
> That works for me, but doesn't seem to cover the criteria that Michael
> set out for discoverability.

I must have missed those discoverability criteria, apologies. In any
case, I can hardly imagine anything more discoverable than a [PULL] on
the mailing list.

>> I understand that the PRs you created on github explicitly stated they
>> weren't to be merged. It doesn't matter. One misclick from an edk2
>> maintainer who happens to be paying a bit less attention, and poof, we
>> have mess in the git history.
> 
> Which is fairly much true of *any* work, right? Any of those people
> could 'accidentally' push stuff from their working tree out to the main
> repository, at any time. We either revert it with a new commit, or we
> quickly undo the commit and rewind the contents of the tree before too
> many people update from it. It's hardly the end of the world.

I disagree. It is costly. We've had two unintended merges thus far (from
incorrect command line usage), and they took me personally hours to
analyze and explain.

Even without github pull requests, we frequently see build breakage too.
Fixing them up is anything but fast. The fixup patch has to be mailed
out, reviewed, committed. When the build fixup is trivial, I
occasionally take the liberty and commit it without review (and them I'm
super worried if I'll be called out for committing without review).

The fact that these issues were introduced while using the git command
line supports your point that such problems can occur "anyway". My point
is that I would like to keep them as rare as possible, and github pull
requests don't point in that direction.

If you are volunteering to analyze and undo unintended or incorrectly
resolved merges from github pull reqs -- I have no further comments then.

> And the chances of the CRLF conversion one actually *applying* if
> someone stupidly hits the button, after *one* more commit hits the
> tree, are fairly much zero anyway. So you're defending against an
> impossibility in that case.

In this specific case, you are right. My point was to prevent building a
precedent.

> I don't know if I should be offended on behalf of the maintainers who
> are mostly my colleagues, that you have such a low opinion of their
> capabilities.

I don't have a low opinion of the capabilities of other edk2
maintainers. It's a fact that they have just recently started using git.
It is another fact that I personally mis-click a button (or mistype a
shortcut) in this or that GUI application occasionally.

Fixing build breakage (or functional breakage) in the edk2 repository is
not exactly fun. I find myself analyzing and fixing up bugs from others
(outside of OvmfPkg/) more and more. Simply because I tend to run into
them with OVMF (and with Gerd's Jenkins instance) earlier than most
other people. (I'm not always the first to find out, of course.) I think
it's natural from me not wanting to ease the introduction of such issues.

I'd like to invite other edk2 maintainers to chime in on a github PR
centered workflow. If the consensus is to use them, I'll try to adapt
the best I can, although I think it's a huge step backward. I will also
stop analyzing and undoing problems introduced by others. I hope those
in favor of github PRs will step up.

Feel free to reopen the pull requests (if you don't have the
credentials, I can reopen them for you). I'm not offering to help
testing them out any longer; I disagree with the github workflow and
won't be supporting it until I'm forced to, by maintainer consensus.

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

Re: [edk2] [patch] NetworkPkg:Fix Http boot download issue.

[Fu, Siyuan]

Hi, Lubo

Since the Private->FilePathUri is extracted from the URI device path node in 
the FilePath, the (Private->FilePathUri != NULL) implied that the FilePath is 
not end device path node. So I thinke the whole change could be simplified to 
  
  if ((UsingIpv6 != Private->UsingIpv6) || 
((Private->FilePathUri != NULL) && 
 (AsciiStrCmp (Private->BootFileUri, Private->FilePathUri) != 0))) {
 // stop and restart driver
  }

Best Regards
Siyuan

> -Original Message-
> From: Zhang, Lubo
> Sent: Thursday, March 17, 2016 5:19 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting ; Wu,
> Jiaxin 
> Subject: [patch] NetworkPkg:Fix Http boot download issue.
> 
> When http boot download the second time without return
> to the boot manager, the DHCP process will start twice
> wiht the same Boot file uri and print the information twice
> which we not expected. This is caused by wrong logic
> of handling the device path of the boot file when loading it.
> 
> Cc: Fu Siyuan 
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> ---
>  NetworkPkg/HttpBootDxe/HttpBootImpl.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> index 3adb08d..487a01e 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c
> @@ -385,10 +385,11 @@ HttpBootDxeLoadFile (
>  {
>HTTP_BOOT_PRIVATE_DATA*Private;
>HTTP_BOOT_VIRTUAL_NIC *VirtualNic;
>BOOLEAN   MediaPresent;
>BOOLEAN   UsingIpv6;
> +  BOOLEAN   IsFilePathUriEqual;
>EFI_STATUSStatus;
> 
>if (This == NULL || BufferSize == NULL || FilePath == NULL) {
>  return EFI_INVALID_PARAMETER;
>}
> @@ -428,12 +429,18 @@ HttpBootDxeLoadFile (
>  //
>  // Restart the HTTP boot driver in 2 cases:
>  // 1. Http boot Driver has already been started but not on the required 
> IP
> version.
>  // 2. The required boot FilePath is different with the one we produced in
> the device path
>  // protocol.
> -//
> -if ((UsingIpv6 != Private->UsingIpv6) || !IsDevicePathEnd(FilePath)) {
> +IsFilePathUriEqual = FALSE;
> +if (!IsDevicePathEnd (FilePath)) {
> +  if ((Private->FilePathUri != NULL) && (AsciiStrCmp 
> (Private->BootFileUri,
> Private->FilePathUri) == 0)) {
> +IsFilePathUriEqual =TRUE;
> +  }
> +}
> +
> +if ((UsingIpv6 != Private->UsingIpv6) || ((Private->FilePathUri != NULL)
> && !IsFilePathUriEqual)) {
>Status = HttpBootStop (Private);
>if (!EFI_ERROR (Status)) {
>  Status = HttpBootStart (Private, UsingIpv6, FilePath);
>}
>  }
> --
> 1.9.5.msysgit.1

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

Re: [edk2] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Ard Biesheuvel]

On 17 March 2016 at 10:11, Laszlo Ersek  wrote:
> Adding Ard
>
> On 03/17/16 08:28, Zeng, Star wrote:
>> On 2016/3/17 15:16, Andrew Fish wrote:
>>>
 On Mar 17, 2016, at 12:10 AM, Gao, Liming  wrote:

 Andrew:
   DxeDebugPrintErrorLevelLib has Constructor. DxeHobLib has
 Constructor. If DebugLib also has Constructor, the circle of
 Constructor() will happen and cause build break.
 DxeDebugPrintErrorLevelLib instance increases the possibility of the
 circle Constructor(). To resolve it, we can update
 DxeDebugPrintErrorLevelLib or DxeHobLib library instance by moving
 their constructor into every function API.

>>>
>>> Liming,
>>>
>>> Thanks, I came to the same conclusion. I'm making a local copy
>>> DxeDebugPrintErrorLevelLib that does the HOB accesses in the driver
>>> without the HobLib and that will solve our issue. I was just surprised
>>> the edk2 library was not very useful in the real world. Not to mention
>>> the build error message did not help find the real issue, the HOB lib.
>>
>> I reproduced the issue locally. With the change below to integrate
>> HobLibConstructor() to GetHobList(), since all other interface of
>> DxeHobLib are just to call GetHobList(), the issue is gone. What is your
>> opinion?
>
> This could make it possible for ArmVirtPkg to remove the
> ArmVirtDxeHobLib library instance. That library instance was cloned
> exactly in order to break this dependency cycle, see commit ad90df8ac0.
>
> I think the proposal and the patch are good.
>

As I have mentioned in the past, there is a general issue with the
EDK2 BaseTools where a transitive dependency on a library that has a
constructor is not taken into account when checking for cycles.

For example,

lib A depends on lib B, which has a constructor
lib B depends on lib C, which has no constructor
lib C depends on lib D, which has a constructor
lib D depends on lib A, which has no constructor

In this case, the build will happily succeed, but which constructor
executes first (lib B or lib D) is undefined, and there is generally
no correct solution as either constructor could transitively depend on
the other library having been constructed already.

So I think it would be a good step to fix the build tools to detect
this case, but I am afraid it will expose errors in many places in the
code base.

I am kind of glad someone else is hitting this right now, since the
last time I brought it up, nobody really cared afair.

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

Re: [edk2] [PATCH] PcAtChipsetPkg/PciHostBridgeDxe: Remove it since MdeModulePkg contains a new one.

[Jordan Justen]

On 2016-03-17 23:13:46, Laszlo Ersek wrote:
> On 03/18/16 04:02, Ni, Ruiyu wrote:
> > All,
> > 
> > I would like to hear your concerns by the next weekend (Mar 26/27).
> > 
> > If there is no concern, I will remove it on the Monday after that (Mar 28).
> > 
> >  
> > 
> > And I think I can take Laszlo’s mail below as a r-b response. Can I?
> 
> Please post the removal patch first, I'll respond then.
> 

Yes. I think we can remove it, and I'll try to review the patch when
you post it.

A follow on question: Can we use the new driver for CorebootPayloadPkg
and DuetPkg? In particular, I think it is bad for CorebootPayloadPkg
to depend on DuetPkg.

-Jordan

> > 
> > *From:*Laszlo Ersek [mailto:ler...@redhat.com]
> > *Sent:* Wednesday, March 16, 2016 9:39 PM
> > *To:* Ni, Ruiyu ; edk2-devel@lists.01.org
> > 
> > *Cc:* Ard Biesheuvel ; Justen, Jordan L
> > 
> > *Subject:* Re: [edk2] [PATCH] PcAtChipsetPkg/PciHostBridgeDxe: Remove it
> > since MdeModulePkg contains a new one.
> > 
> >  
> > 
> > On 03/15/16 08:58, Ni, Ruiyu wrote:
> >> All,
> >> I am going to remove the PciHostBridgeDxe driver from PcAtChipsetPkg.
> >> This driver is not used by any platform as far as I know.
> >> Any concerns?
> > 
> > No objection from me (as far as OvmfPkg and ArmVirtPkg are concerned).
> > 
> > The new core PciHostBridgeDxe has been working out very well for OVMF.
> > (ArmVirtPkg will have to stick with its own fork for a while now.)
> > 
> > Thanks
> > Laszlo
> > 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdePkg: Add NORESTART flag to I2C header

[Marcin Wojtas]

From: Bartosz Szczepanek 

I2C_NORESTART_FLAG allows to continue transmission without repeated
start operation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bartosz Szczepanek 
---
 MdePkg/Include/Pi/PiI2c.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/Include/Pi/PiI2c.h b/MdePkg/Include/Pi/PiI2c.h
index d7e0e2d..2c941cb 100644
--- a/MdePkg/Include/Pi/PiI2c.h
+++ b/MdePkg/Include/Pi/PiI2c.h
@@ -112,6 +112,7 @@ typedef struct {
 ///
 /// I2C read operation when set
 #define I2C_FLAG_READ   0x0001
+#define I2C_FLAG_NORESTART  0x0002
 
 ///
 /// Define the flags for SMBus operation
-- 
1.8.3.1

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

Re: [edk2] [PATCH v2 3/3] ArmPkg: Update CpuDxe to use CpuExceptionHandlerLib

[Cohen, Eugene]

Ard,

> The patches look fine to me. I will proceed and apply the first two.
> However, this third one needs to wait until all users of CpuDxe have
> the correct resolution for CpuExceptionHandlerLib. I think this is
> only ArmVirtPkg/ArmVirt.dsc.inc, but I'd like a nod from Leif before
> pushing this final change through.

By my analysis across edk2 and OpenPlatformPkg the following platforms need to 
get updated to pick up the library to prevent build breakage:

For edk2 it's ArmVirtQemu, ArmVirtQemuKernel, ArmVirtXen, and BeagleBoardPkg
For OpenPlatformPkg it's ArmJuno, ArmVExpress-CTA15-A7, 
ArmVExpress-FVP-AArch64.dsc, and BeagleBoardPkg

This was obtained just by searching for platforms that use the ARM CpuDxe 
driver.

Thanks,

Eugene

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

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

[Ni, Ruiyu]

Laszlo,
Which kernel version are you using? Yes I indeed used 4.4.1 from ppa wily.
I would more likely to assume 4.4.1 has a regression. Will try 4.4 tomorrow.

Thanks a lot for your long mail.

Thanks,
Ray

> 在 2016年3月16日，下午8:38，Laszlo Ersek  写道：
> 
>> On 03/16/16 01:55, Ni, Ruiyu wrote:
>> 
>> 
>> Regards,
>> Ray
>> 
>> 
>>> -Original Message-
>>> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
>>> Sent: Wednesday, March 16, 2016 12:06 AM
>>> To: Ni, Ruiyu 
>>> Cc: Laszlo Ersek ; Justen, Jordan L 
>>> ; edk2-devel@lists.01.org
>>> 
>>> Subject: Re: [edk2] Software SMI STS bit is not set when writing port B2 in 
>>> QEMU Q35
>>> 
>>> 
>>> 
 On 15/03/2016 16:48, Ni, Ruiyu wrote:
 I don't think CSM matters and the bin I am using cannot be
 distributed. Does the qemu build steps matters? I ran configure
 --target-list=x86_64-softmmu. I traced the code and found the code
 hung when SMM is relocating. The code was waiting for mRebased flag
 be set.
>>> 
>>> First of all, can you reproduce the problem without CSM?
>> 
>> Yes. I also attached the OVMF_CODE.fd and OVMF_VARS.fd
>> (in OVMF.zip).
>> Can you help to try whether it can boot to shell in your qemu?
>> I can confirm when accel=tcg the OVMF can boot well.
>> But when accel=kvm it cannot.
>> SMM emulation over KVM has certain requirements for
>> HOST PC which I am not aware of?
> 
> Your binary works for me (it boots to the UEFI shell) on KVM.
> 
> As far as I understand, for the host kernel (= KVM), the requirement is
> Linux 4.4 or later.
> 
> I'm not using an upstream host kernel; at the moment I'm using one of
> Paolo's RHEL-7 backport kernels. So, my testing didn't repeat that part
> of your setup.
> 
> I can see from your earlier email that you upgraded your host kernel to
> 4.4.1 and you rebooted your PC with it. Is this an upstream kernel that
> you built, or is it packaged by Ubuntu?
> 
> As far as I can see, the latest release for Ubuntu 14.04 is 14.04.4. By
> default it comes with a 4.2 based kernel:
> 
> https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Updated_Packages
> 
> I think something is wrong with your host kernel. Based on the
> information available, I cannot decide if it is actually a Ubuntu kernel
> that is simply too old, or an upstream 4.4.1 stable kernel release that
> you built yourself, and maybe 4.4.1 regressed relative to 4.4.0.
> 
> If you built the host kernel manually, why did you pick 4.4.1 exactly?
> As far as I can see, 4.4.5 is also available from stable git:
> 
> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.4.y&id=62e21959dc6f25c5fce0c1a0934e4a9d982bf99b
> 
> Hmm, I googled "Ubuntu" and "4.4.1" together, and the only relevant hits
> I seem to be getting are from:
> 
>  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/
> 
> I wouldn't recommend using those -- PPA means "Personal Package
> Archives", plus the "wily" suffix implies the 15.10 release of Ubuntu,
> not 14.04.
> 
> If you insist on using Ubuntu, please at least try 16.04 LTS ("Xenial
> Xerus"), which is apparently based on 4.4 *officially*.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

[Laszlo Ersek]

On 03/16/16 14:47, Ni, Ruiyu wrote:
> Laszlo,
> Which kernel version are you using? Yes I indeed used 4.4.1 from ppa wily.
> I would more likely to assume 4.4.1 has a regression. Will try 4.4 tomorrow.

I am using a RHEL-7 kernel that is not publicly released yet. While I
was working on SMM for OVMF, I built upstream kernels manually.

It is not justified to suspect a 4.4.1 regression until you test a
hand-built upstream 4.4.1 kernel (or, even better, the latest in the
4.4.y stable series, 4.4.5 at this moment).

What a PPA offers has zero relevance. Please build your kernel manually
from the upstream sources, or use an official (and fully updated)
distribution release that is built on the 4.4 kernel.

(The difference between my using an unreleased, development RHEL-7
kernel and your using some random Ubuntu PPA is that my RHEL-7 kernel
was built by the upstream KVM maintainer: Paolo, as part of his work at
Red Hat. He knows what he's doing. The official distro releases also
tend to. I wouldn't be so sure about a random *personal* packaging
archive (PPA) though.

It is *possible* that upstream 4.4.1 indeed contains a regression, but
when using a PPA, your first suspect should be the PPA.)

Thanks
Laszlo

> Thanks a lot for your long mail.
> 
> Thanks,
> Ray
> 
>> 在 2016年3月16日，下午8:38，Laszlo Ersek  写道：
>>
>>> On 03/16/16 01:55, Ni, Ruiyu wrote:
>>>
>>>
>>> Regards,
>>> Ray
>>>
>>>
 -Original Message-
 From: Paolo Bonzini [mailto:pbonz...@redhat.com]
 Sent: Wednesday, March 16, 2016 12:06 AM
 To: Ni, Ruiyu 
 Cc: Laszlo Ersek ; Justen, Jordan L 
 ; edk2-devel@lists.01.org
 
 Subject: Re: [edk2] Software SMI STS bit is not set when writing port B2 
 in QEMU Q35



> On 15/03/2016 16:48, Ni, Ruiyu wrote:
> I don't think CSM matters and the bin I am using cannot be
> distributed. Does the qemu build steps matters? I ran configure
> --target-list=x86_64-softmmu. I traced the code and found the code
> hung when SMM is relocating. The code was waiting for mRebased flag
> be set.

 First of all, can you reproduce the problem without CSM?
>>>
>>> Yes. I also attached the OVMF_CODE.fd and OVMF_VARS.fd
>>> (in OVMF.zip).
>>> Can you help to try whether it can boot to shell in your qemu?
>>> I can confirm when accel=tcg the OVMF can boot well.
>>> But when accel=kvm it cannot.
>>> SMM emulation over KVM has certain requirements for
>>> HOST PC which I am not aware of?
>>
>> Your binary works for me (it boots to the UEFI shell) on KVM.
>>
>> As far as I understand, for the host kernel (= KVM), the requirement is
>> Linux 4.4 or later.
>>
>> I'm not using an upstream host kernel; at the moment I'm using one of
>> Paolo's RHEL-7 backport kernels. So, my testing didn't repeat that part
>> of your setup.
>>
>> I can see from your earlier email that you upgraded your host kernel to
>> 4.4.1 and you rebooted your PC with it. Is this an upstream kernel that
>> you built, or is it packaged by Ubuntu?
>>
>> As far as I can see, the latest release for Ubuntu 14.04 is 14.04.4. By
>> default it comes with a 4.2 based kernel:
>>
>> https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Updated_Packages
>>
>> I think something is wrong with your host kernel. Based on the
>> information available, I cannot decide if it is actually a Ubuntu kernel
>> that is simply too old, or an upstream 4.4.1 stable kernel release that
>> you built yourself, and maybe 4.4.1 regressed relative to 4.4.0.
>>
>> If you built the host kernel manually, why did you pick 4.4.1 exactly?
>> As far as I can see, 4.4.5 is also available from stable git:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.4.y&id=62e21959dc6f25c5fce0c1a0934e4a9d982bf99b
>>
>> Hmm, I googled "Ubuntu" and "4.4.1" together, and the only relevant hits
>> I seem to be getting are from:
>>
>>  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/
>>
>> I wouldn't recommend using those -- PPA means "Personal Package
>> Archives", plus the "wily" suffix implies the 15.10 release of Ubuntu,
>> not 14.04.
>>
>> If you insist on using Ubuntu, please at least try 16.04 LTS ("Xenial
>> Xerus"), which is apparently based on 4.4 *officially*.
>>
>> Thanks
>> Laszlo

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

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[Laszlo Ersek]

On 03/18/16 12:21, David Woodhouse wrote:
> On Thu, 2016-03-17 at 21:28 +, Kinney, Michael D wrote:
>>
>> Yes.  Use of developer github forks is supported.  I had summarized
>> 3 development methods earlier in this thread.
>>
>> 1) PR emails send to edk2-devel.  There is a Wiki page that details process
>> for developers and maintainer.  
>>
>> 2) Branch on developer owned github fork of edk2.  There have been 
>> discussions on
>> how to support a pull request.  This is still under investigation.  In the 
>> meantime, a link to the branch and pull request can be included in
>> the PR emails to edk2-devel.
>>
>> 3) Branch on edk2-staging (Specific process being discussed in this thread)
> 
> Let's *test* my assertion that github PRs should be sufficient even to
> cover #3.
> 
> They're discoverable — at https://github.com/tianocore/edk2/pulls you
> can see that I've just filed a couple of tickets. I believe they
> satisfies all the other criteria you've mentioned, but let's have an
> experiment and find out.
> 
> I think these two test cases are precisely the kind of submission which
> want to be handled via 'staging', aren't they?
> 
> The first — https://github.com/tianocore/edk2/pull/70 — is the update
> to build against OpenSSL 1.1. I've thrown in a "line note" on the code,
> so you can see how that works as well as the general discussion in the
> ticket.
> 
> The second — https://github.com/tianocore/edk2/pull/71 — is a test of
> converting the internal representation of all files to use git's native
> LF line endings. This should mean that the tools can do the right thing
> and check out the working files according to the norms of the platform
> — you'll get CRLF on Windows, and LF on Linux. It would be good to test
> that, iron out any problems and get it fixed. But again, definitely
> something that wants staging for review and testing first.

Thanks for the work. I'm willing to help you test these.

I'm going to close the github pull requests now. We have a quite large
number of maintainers, and everyone has the credentials to click that
button in the github pull requests. If someone clicks it out of
oversight, that won't lead to happiness. (Your pull requests target
"tianocore:master".)

Instead, please post the pull request to the development mailing list.
That is discoverable too, and has a much lower chance of (a) someone
pulling it into his local clone accidentally, and then (b) pushing the
merge commit to the central repo accidentally. The so-called "ease of
merging" that github offers is a minus for us, not a plus.

The pull request posted to the list should look like this: it should be
a formatted patch series, where the subject prefix is PULL, not PATCH.
The blurb (00/nn) message should contain the output of the
"git-request-pull" command, plus any other comments you might want to add.

Posting the pull request to the mailing list like this allows our
workflow to remain independent of github. GitHub should only remain a
repository hosting site for us. Maybe a wiki too.

(The github issue tracker is already too much, but Tony has been working
on setting up Bugzilla @ Intel, so I hope in the mid term we can move
off of the github issue tracker.)

The discussion of your pull requests should happen on the list, not in
the github pull request ticket. Once we have an independent Bugzilla
instance, one that supports perfect email integration and mass data
archival / export, then we can also discuss technical stuff in Bugzilla
entries at depth.

Now, specifically for the CRLF conversion, I expect the patches to be
huge, and also mechanic, so posting those to the mailing list is
probably not useful. In this case just the blurb should suffice.

The OpenSSL 1.1 support pull is perfectly suitable for patch-wise
posting (as a PULL).

(
Side point: for the CRLF conversion, I repeated your command in a bit
different form:

$ git ls-tree -r --full-tree --name-only master: \
  | file --files-from - \
  | grep CRLF \
  | cut -f1 -d: \
  | xargs cat \
  | wc -l

The intent is to count the number of lines in all those files --
presumably all lines have to be converted. The result is 4,383,397
lines. Okay. (For 14,108 files.)

However, looking at the github pull request,
, the line count in the
cumulative diffstat looks wrong. The number of changed files seems okay
(14,105), but the diffstat says "20,557 lines changed". That's a
fraction of what I expect to be changed, and it doesn't really increase
my trust in github.
)

--*--

github.com is a for-profit company that doesn't seem to have any
official relationship with edk2 contributors. I trust them to host the
repositories (the central one and the personal ones). If something
breaks, we can immediately move those elsewhere. Same for the wiki.

The same is not true of the discussions led in pull request items or
other issue tracker items; github.com practically owns those. If they
lock down their issue tracker t

Re: [edk2] [PATCH v2] NetworkPkg:Fix Http boot download issue.

[Zhang, Lubo]

Yes,   I not notice that, will correct when checked in.

Thanks

From: Fu, Siyuan
Sent: Friday, March 18, 2016 4:29 PM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Ye, Ting ; Wu, Jiaxin 
Subject: RE: [edk2] [PATCH v2] NetworkPkg:Fix Http boot download issue.


Lubo



I think the AsciiStrCmp should be "!=" zero (not zero means not identical).





> -Original Message-

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of

> Zhang Lubo

> Sent: Friday, March 18, 2016 2:51 PM

> To: edk2-devel@lists.01.org

> Cc: Ye, Ting mailto:ting...@intel.com>>; Fu, Siyuan 
> mailto:siyuan...@intel.com>>; Wu,

> Jiaxin mailto:jiaxin...@intel.com>>

> Subject: [edk2] [PATCH v2] NetworkPkg:Fix Http boot download issue.

>

> v2:

> * Simplify the code logic.

>

> When http boot download the second time without return

> out of the boot manager, the DHCP process will start twice

> with the same Boot file uri and print the information twice

> which we not expected. This is caused by wrong logic

> of handling the device path of the boot file when loading it.

>

> Cc: Fu Siyuan mailto:siyuan...@intel.com>>

> Cc: Ye Ting mailto:ting...@intel.com>>

> Cc: Wu Jiaxin mailto:jiaxin...@intel.com>>

> Contributed-under: TianoCore Contribution Agreement 1.0

> Signed-off-by: Zhang Lubo mailto:lubo.zh...@intel.com>>

> ---

>  NetworkPkg/HttpBootDxe/HttpBootImpl.c | 3 +--

>  1 file changed, 1 insertion(+), 2 deletions(-)

>

> diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> b/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> index 3adb08d..451b24d 100644

> --- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> +++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> @@ -428,12 +428,11 @@ HttpBootDxeLoadFile (

>  //

>  // Restart the HTTP boot driver in 2 cases:

>  // 1. Http boot Driver has already been started but not on the required 
> IP

> version.

>  // 2. The required boot FilePath is different with the one we produced in

> the device path

>  // protocol.

> -//

> -if ((UsingIpv6 != Private->UsingIpv6) || !IsDevicePathEnd(FilePath)) {

> +if ((UsingIpv6 != Private->UsingIpv6) || ((Private->FilePathUri != NULL) 
> &&

> (AsciiStrCmp (Private->BootFileUri, Private->FilePathUri) == 0))) {

>Status = HttpBootStop (Private);

>if (!EFI_ERROR (Status)) {

>  Status = HttpBootStart (Private, UsingIpv6, FilePath);

>}

>  }

> --

> 1.9.5.msysgit.1

>

> ___

> 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] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Gao, Liming]

Andrew:
  First, I suggest to enhance BaseTools to report the detail information on the 
constructor circle. Next, we can add comments in DxeDebugPrintErrorLevelLib 
library instance to note it can't be used together with DxeHobLib and 
BaseDebugLibSerialPort instance until we have the complete solution to resolve 
it.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Friday, March 18, 2016 2:06 AM
To: peter.kirme...@ts.fujitsu.com
Cc: Ard Biesheuvel ; Laszlo Ersek 
; Gao, Liming ; edk2-devel 
; Zeng, Star 
Subject: Re: [edk2] Has any one else had issues trying to use 
DxeDebugPrintErrorLevelLib? 
DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf


> On Mar 17, 2016, at 5:15 AM, 
> peter.kirme...@ts.fujitsu.com wrote:
>
> Hi all,
>
> from my point of view a library should use a constructor to initialize OWN 
> resources only. That means that there is no need for external resources at 
> this point. The library can use PeiService/SystemTable to register for events 
> or protocols (when they need to react to them). Or they finalize 
> initialization on the first time a library function gets called.
> I don't know how many EDK2 libraries would fulfill this requirement and if it 
> is worth to note that rule into specification (when you agree) but this way 
> one can get rid of dependency loops.
>

Peter,

It might not be a bad idea to make this a recommendation, and implement it in 
the key packages (MdePkg, MdeModulePkg, etc.).

I've been working on the edk2 since the beginning and this is the 1st time I 
every remember hitting this issue in a real world situation. I'm guessing since 
most libraries are small and have limited dependencies we don't hit this a lot. 
However given the error messages you get it is quite painful to debug. I 
basically had to do a binary search of disabling dependent libraries to figure 
this out. I think the DebugLib is a special case since it is used by almost 
every other library, and it has the possibility of being complex and depend on 
a lot of other libraries.

Thanks,

Andrew Fish

> Best Regards,
> Peter Kirmeier
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Thursday, March 17, 2016 11:16 AM
> To: Laszlo Ersek; Gao, Liming
> Cc: edk2-devel; Andrew Fish; Zeng, Star
> Subject: Re: [edk2] Has any one else had issues trying to use 
> DxeDebugPrintErrorLevelLib? 
> DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
>
> On 17 March 2016 at 10:11, Laszlo Ersek wrote:
>> Adding Ard
>>
>> On 03/17/16 08:28, Zeng, Star wrote:
>>> On 2016/3/17 15:16, Andrew Fish wrote:

> On Mar 17, 2016, at 12:10 AM, Gao, Liming wrote:
>
> Andrew:
> DxeDebugPrintErrorLevelLib has Constructor. DxeHobLib has
> Constructor. If DebugLib also has Constructor, the circle of
> Constructor() will happen and cause build break.
> DxeDebugPrintErrorLevelLib instance increases the possibility of
> the circle Constructor(). To resolve it, we can update
> DxeDebugPrintErrorLevelLib or DxeHobLib library instance by moving
> their constructor into every function API.
>

 Liming,

 Thanks, I came to the same conclusion. I'm making a local copy
 DxeDebugPrintErrorLevelLib that does the HOB accesses in the driver
 without the HobLib and that will solve our issue. I was just
 surprised the edk2 library was not very useful in the real world.
 Not to mention the build error message did not help find the real issue, 
 the HOB lib.
>>>
>>> I reproduced the issue locally. With the change below to integrate
>>> HobLibConstructor() to GetHobList(), since all other interface of
>>> DxeHobLib are just to call GetHobList(), the issue is gone. What is
>>> your opinion?
>>
>> This could make it possible for ArmVirtPkg to remove the
>> ArmVirtDxeHobLib library instance. That library instance was cloned
>> exactly in order to break this dependency cycle, see commit ad90df8ac0.
>>
>> I think the proposal and the patch are good.
>>
>
> As I have mentioned in the past, there is a general issue with the
> EDK2 BaseTools where a transitive dependency on a library that has a 
> constructor is not taken into account when checking for cycles.
>
> For example,
>
> lib A depends on lib B, which has a constructor lib B depends on lib C, which 
> has no constructor lib C depends on lib D, which has a constructor lib D 
> depends on lib A, which has no constructor
>
> In this case, the build will happily succeed, but which constructor executes 
> first (lib B or lib D) is undefined, and there is generally no correct 
> solution as either constructor could transitively depend on the other library 
> having been constructed already.
>
> So I think it would be a good step to fix the build tools to detect this 
> case, but I 

[edk2] [PATCH] MdeModulePkg PlatformVarCleanupLib: Locate VarCheck protocol when using

[Star Zeng]

Do not locate VarCheck protocol in Constructor, then the
gEdkiiVarCheckProtocolGuid could be removed from [Depex].
It will be more flexible for the library Consumer to work without VarCheck
protocol installed, for example at recovery boot mode with EmuRuntimeDxe.

The unused UefiLib is also been removed from [LibraryClasses] in *.inf.

Cc: Ruiyu Ni 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 .../Library/PlatformVarCleanupLib/PlatVarCleanupLib.c  | 18 ++
 .../PlatformVarCleanupLib/PlatformVarCleanupLib.inf|  4 +---
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c 
b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
index d99174c4b962..74655c6dadd2 100644
--- a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
+++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
@@ -1,7 +1,7 @@
 /** @file
   Sample platform variable cleanup library implementation.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 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
@@ -100,6 +100,15 @@ IsUserVariable (
   EFI_STATUSStatus;
   VAR_CHECK_VARIABLE_PROPERTY   Property;
 
+  if (mVarCheck == NULL) {
+gBS->LocateProtocol (
+   &gEdkiiVarCheckProtocolGuid,
+   NULL,
+   (VOID **) &mVarCheck
+   );
+  }
+  ASSERT (mVarCheck != NULL);
+
   ZeroMem (&Property, sizeof (Property));
   Status = mVarCheck->VariablePropertyGet (
 Name,
@@ -1225,13 +1234,6 @@ PlatformVarCleanupLibConstructor (
   mLastVarErrorFlag = InternalGetVarErrorFlag ();
   DEBUG ((EFI_D_INFO, "mLastVarErrorFlag - 0x%02x\n", mLastVarErrorFlag));
 
-  Status = gBS->LocateProtocol (
-  &gEdkiiVarCheckProtocolGuid,
-  NULL,
-  (VOID **) &mVarCheck
-  );
-  ASSERT_EFI_ERROR (Status);
-
   //
   // Register EFI_END_OF_DXE_EVENT_GROUP_GUID event.
   //
diff --git 
a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf 
b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf
index c56a17584a9f..a3498cca5073 100644
--- a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf
+++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Sample platform variable cleanup library instance.
 #
-#  Copyright (c) 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions
@@ -44,7 +44,6 @@ [Packages]
 [LibraryClasses]
   UefiBootServicesTableLib
   UefiRuntimeServicesTableLib
-  UefiLib
   BaseLib
   DebugLib
   BaseMemoryLib
@@ -68,6 +67,5 @@ [Protocols]
   gEfiHiiConfigRoutingProtocolGuid  ## SOMETIMES_CONSUMES
 
 [Depex]
-  gEdkiiVarCheckProtocolGuid AND
   gEfiVariableArchProtocolGuid
 
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH] MdePkg: Add NORESTART flag to I2C header

[Gao, Liming]

I don't find I2C_FLAG_NORESTART definition in PI spec 1.4. Where is to get it?

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marcin 
Wojtas
Sent: Wednesday, March 16, 2016 11:33 PM
To: edk2-devel@lists.01.org
Cc: ha...@marvell.com; leif.lindh...@linaro.org; b...@semihalf.com; 
n...@marvell.com; Gao, Liming ; Kinney, Michael D 

Subject: [edk2] [PATCH] MdePkg: Add NORESTART flag to I2C header

From: Bartosz Szczepanek 

I2C_NORESTART_FLAG allows to continue transmission without repeated
start operation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bartosz Szczepanek 
---
 MdePkg/Include/Pi/PiI2c.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/Include/Pi/PiI2c.h b/MdePkg/Include/Pi/PiI2c.h
index d7e0e2d..2c941cb 100644
--- a/MdePkg/Include/Pi/PiI2c.h
+++ b/MdePkg/Include/Pi/PiI2c.h
@@ -112,6 +112,7 @@ typedef struct {
 ///
 /// I2C read operation when set
 #define I2C_FLAG_READ   0x0001
+#define I2C_FLAG_NORESTART  0x0002
 
 ///
 /// Define the flags for SMBus operation
-- 
1.8.3.1

___
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] MdePkg: Add NORESTART flag to I2C header

[Marcin Wojtas]

Hi Liming,

Thank you for the information, the flag will be handled within
OpenPlatformPkg then.

Best regards,
Marcin

2016-03-17 14:49 GMT+01:00 Gao, Liming :
> Bartosz:
>
>   MdePkg definition conforms to UEFI/PI and Industry specification. If it is
> not in spec, it will not be added into MdePkg. For this case, it can locally
> be added into OpenPlatformPkg. If you think it is valuable to be in PI spec,
> you can contribute PI spec mantis to uefi.org.
>
>
>
> Thanks
>
> Liming
>
> From: Bartosz Szczepanek [mailto:b...@semihalf.com]
> Sent: Thursday, March 17, 2016 6:55 PM
> To: Gao, Liming 
> Cc: Marcin Wojtas ; edk2-devel@lists.01.org;
> ha...@marvell.com; leif.lindh...@linaro.org; n...@marvell.com; Kinney,
> Michael D 
> Subject: Re: [edk2] [PATCH] MdePkg: Add NORESTART flag to I2C header
>
>
>
> Hello Liming,
>
> indeed it's not in PI specification. This flag was introduced in order
> to ease development of EEPROM drivers, as these devices expect no
> repeated start condition in write operation. It's neither vendor nor
> platform specific, so we didn't stick that to our platform package. Do
> you think it's possible to amend the specification, or should we add
> the flag locally in OpenPlatformPkg?
>
> Best regards,
> Bartosz
>
> 2016-03-17 2:33 GMT+01:00 Gao, Liming :
>> I don't find I2C_FLAG_NORESTART definition in PI spec 1.4. Where is to get
>> it?
>>
>> Thanks
>> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Marcin Wojtas
>> Sent: Wednesday, March 16, 2016 11:33 PM
>> To: edk2-devel@lists.01.org
>> Cc: ha...@marvell.com; leif.lindh...@linaro.org; b...@semihalf.com;
>> n...@marvell.com; Gao, Liming ; Kinney, Michael D
>> Subject: [edk2] [PATCH] MdePkg: Add NORESTART flag to I2C header
>>
>> From: Bartosz Szczepanek
>>
>> I2C_NORESTART_FLAG allows to continue transmission without repeated
>> start operation.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Bartosz Szczepanek
>> ---
>> MdePkg/Include/Pi/PiI2c.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/MdePkg/Include/Pi/PiI2c.h b/MdePkg/Include/Pi/PiI2c.h
>> index d7e0e2d..2c941cb 100644
>> --- a/MdePkg/Include/Pi/PiI2c.h
>> +++ b/MdePkg/Include/Pi/PiI2c.h
>> @@ -112,6 +112,7 @@ typedef struct {
>> ///
>> /// I2C read operation when set
>> #define I2C_FLAG_READ 0x0001
>> +#define I2C_FLAG_NORESTART 0x0002
>>
>> ///
>> /// Define the flags for SMBus operation
>> --
>> 1.8.3.1
>>
>> ___
>> 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] signedness of CHAR8

[Leif Lindholm]

On Thu, Mar 17, 2016 at 12:16:31PM +, Leif Lindholm wrote:
> So, as further fallout from my -Weverything experiments, I've come
> across this...
> 
> Ia32 and X64 ProcessorBind.h (BaseTools and MdePkg) both define CHAR8 as 
> 'char'.
> ARM and AArch64 both do the same.
> 
> However, default 'char' signedness is unsigned in the ARM
> architectures, and signed in the others.
> 
> Meanwhile, the UEFI specification describes CHAR8 as
> ---
> 1-byte character. Unless otherwise specified, all 1-byte or ASCII characters 
> and
> strings are stored in 8-bit ASCII encoding format, using the
> ISO-Latin-1 character
> set.
> ---
> 
> Now, ISO-Latin-1 holds values all the way up to 255, which clearly
> does not fit into a signed 8-bit char.
> 
> Would I be correct in my interpretation that Ia32/X64 should be
> defining CHAR8 as 'unsigned char', or am I losing my mind?

I'll reply to myself.

BaseTools/Conf/tools_def.template sets -funsigned-chars for X64/Ia32 -
so it is already correct for these.

Hilariously (?) ARM/AArch64 sets -fsigned-chars, making what would
otherwise be correct default behaviour broken.

Patch for the ARM architectures coming up.

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

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[David Woodhouse]

I could have sworn I'd responded to this last night, but it was late,
and I see no evidence of such in my outbox or on the list. Apologies if
I'm repeating myself...

On Thu, 2016-03-17 at 00:15 +, Kinney, Michael D wrote:
> Jordan asked a similar question about adding a 'staging' directory or 
> 'staging'
> branches to the edk2 repo.  If you look at the edk2 repo today, it has master 
> and the supported UDK* branches.  In the transition from SVN -> GIT, the old 
> tags
> were removed and archived.
> 
> The reason for suggesting a new edk2-staging repo is to keep content that
> is not ready for products to be clearly separated.  We do not want anyone
> to pick up any of the staging content and put it into shipping FW images.
> 
> There was also a minor concern about the size of the edk2 repo, but it
> was shown that this is not really an issue at this time.
> 
> So the choice here is a set of staging feature branches in the current 
> edk2 repo with clear communication that none of them are product ready.  
> Or a new edk2-staging repo with feature branches (current proposal).

This seems to me to be a false dichotomy. You've left out the third
option, which is just to use the tools as they were designed to be
used.

Let people set up their submissions in github repositories of their own
(which works for groups as well as individuals, and allows loosely-
formed collaborative groups as well as more formal projects). And you
can already track their submissions at
https://github.com/tianocore/edk2/pulls

> I think a process to create/merge/remove feature branches in the 
> tianocore.org repos is required because we really do not want too 
> many branches.  If the feature being developed is smaller in 
> scope, developer owned github branches or email PRs should be sufficient.

Developer-owned github repositories are suitable for larger submissions
too, surely? (With associated discussion on the mailing list which was
always part of the plan, of course. I'm not suggesting that it should
necessarily happen *only* in the github PR format.)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/2] Omap35xxPkg: move to ARM version of CpuExceptionHandlerLib

[Ard Biesheuvel]

Change our resolution for the previously unused CpuExceptionHandlerLib
from the null implementation to the newly added implementation specific
to AARCH64 and ARM. This is needed since our CpuDxe will start using it
in a subsequent patch.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---

This package does not actually refer to any modules that depend on
CpuExceptionHandlerLib, but for the sake of completeness, let's change
it anyway

 Omap35xxPkg/Omap35xxPkg.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Omap35xxPkg/Omap35xxPkg.dsc b/Omap35xxPkg/Omap35xxPkg.dsc
index 5943e716c469..b719652b5a08 100644
--- a/Omap35xxPkg/Omap35xxPkg.dsc
+++ b/Omap35xxPkg/Omap35xxPkg.dsc
@@ -43,7 +43,7 @@ [LibraryClasses.common]
 
   
CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
   
DefaultExceptioHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
-  
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
+  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
   PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
 
   
RealTimeClockLib|EmbeddedPkg/Library/TemplateRealTimeClockLib/TemplateRealTimeClockLib.inf
-- 
2.5.0

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

Re: [edk2] [RFC 1/3] MdePkg: Add PCD for UART default receive FIFO depth

[Ni, Ruiyu]

No. I don't think the UINT32 is for data alignment.
Because EFI_SERIAL_IO_MODE isn't decorated by #pragma pack(1),
it's naturally aligned.

Regards,
Ray

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Thursday, March 17, 2016 3:13 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 

Subject: Re: [edk2] [RFC 1/3] MdePkg: Add PCD for UART default receive FIFO 
depth

Hi Ruiyu,

Does it also mean the type in EFI_SERIAL_IO_MODE is mainly for data
alignment?

Heyi


On 03/17/2016 10:29 AM, Ni, Ruiyu wrote:
> Heyi,
> I agree with the general idea of the patch to add a PCD for 
> DefaultReceiveFifoDepth.
>
> I understand you choose UINT32 for the FIFO depth because the
> EFI_SERIAL_IO_MODE.ReceiveFifoDepth is of UINT32 type.
> But in real world, I believe UINT16 should be enough.
>
> Could you please change the PCD type to UINT16?
>
> Regards,
> Ray
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>> Guo
>> Sent: Wednesday, March 16, 2016 6:58 PM
>> To: edk2-devel@lists.01.org
>> Cc: Kinney, Michael D 
>> mailto:michael.d.kin...@intel.com>>; Heyi Guo 
>> mailto:heyi@linaro.org>>; Gao, Liming 
>> mailto:liming@intel.com>>
>> Subject: [edk2] [RFC 1/3] MdePkg: Add PCD for UART default receive FIFO depth
>>
>> PcdUartDefaultReceiveFifoDepth is added to indicate UART default
>> receive FIFO depth.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Heyi Guo mailto:heyi@linaro.org>>
>> Cc: Michael D Kinney 
>> mailto:michael.d.kin...@intel.com>>
>> Cc: Liming Gao mailto:liming@intel.com>>
>> ---
>> MdePkg/MdePkg.dec | 4 
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>> index 47a1cd7..87ec552 100644
>> --- a/MdePkg/MdePkg.dec
>> +++ b/MdePkg/MdePkg.dec
>> @@ -2074,6 +2074,10 @@
>># @ValidRange 0x8001 | 0 - 4
>>gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x0024
>>
>> +  ## Indicates the receive FIFO depth of UART controller.
>> +  # @Prompt Default UART Receive FIFO Depth.
>> +  
>> gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|1|UINT32|0x0030
>> +
>>## Error level for hardware recorder.
>>#  If value 0, platform does not support feature of hardware error record.
>># @Prompt Error Level For Hardware Recorder
>> --
>> 2.7.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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [MdeModulePkg][RegularExpressionDxe] Does not link NOOPT for Xcode clang.

[Andrew Fish]

I can't compile RegularExpressionDxe NOOPT for Xcode clang as I get a linker 
failure on memset().
  "_memset", referenced from:
  _onigenc_unicode_get_case_fold_codes_by_str in 
RegularExpressionDxe.lib(unicode.obj)

It looks like this is the issue:
diff --git 
a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
index 6747b3d..1ec72c6 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/enc/unicode.c
@@ -11239,7 +11239,8 @@ onigenc_unicode_get_case_fold_codes_by_str(OnigEncoding 
enc,
 }
 else if ((flag & INTERNAL_ONIGENC_CASE_FOLD_MULTI_CHAR) != 0) {
   OnigCodePoint cs[3][4];
-  int fn, ncs[3]={0, 0, 0};
+  int fn, ncs[3];
+  ZeroMem (ncs, sizeof(ncs));
 
   for (fn = 0; fn < to->n; fn++) {
cs[fn][0] = to->code[fn];


Contributed-under: TianoCore Contribution Agreement 1.0

Thanks,

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

[edk2] [PATCH 6/7] ArmPkg/ArmExceptionLib: avoid indirect call if using vector table in place

[Ard Biesheuvel]

If we are using the vector table in place, there is no need to make an
indirect call to the common handler routine from the vector table entries,
so just use a straight branch instruction in that case.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S 
b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
index c7ea061a93ea..0fd304db2dbf 100644
--- a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
+++ b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
@@ -187,9 +187,13 @@ VECTOR_BASE(ExceptionHandlersStart)
   mov   x0, #\val
 
   // Jump to our general handler to deal with all the common parts and process 
the exception.
+#if defined(ARM_RELOCATE_VECTORS)
   ldr   x1, =ASM_PFX(CommonExceptionEntry)
   brx1
   .ltorg
+#else
+  b ASM_PFX(CommonExceptionEntry)
+#endif
   .endm
 
 //
-- 
2.5.0

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

Re: [edk2] [PATCH] BaseTools: use unsigned chars on ARM architectures

[Ard Biesheuvel]

On 17 March 2016 at 14:22, Leif Lindholm  wrote:
> By default, the ARM architectures have unsigned chars, whereas the other
> architectures supported by EDK2 by default have signed chars.
> However, EDK2 uses -funsigned-chars on those architectures to change the
> default behaviour.
>
> Unfortunately, the ARM architectures explicitly break their default
> behaviour by specifying -fsigned-chars (I presume in a pre-emptive
> attempt at avoiding incompatibility).
>
> Since this situation is already confusing enough, switch the ARM
> architectures to also specify -funsigned-chars explicitly rather than
> just dropping the current parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm 

Reviewed-by: Ard Biesheuvel 

> ---
>  BaseTools/Conf/tools_def.template | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index b1577af..eedf80f 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4322,8 +4322,8 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os 
> -fshort-wchar -fno-strict-aliasing -
>  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
> -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
> -mno-stack-arg-probe
>  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
> -Wno-address -mno-stack-arg-probe
>  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> -minline-int-divide-min-latency
> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -mabi=aapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
> -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -fno-short-enums -save-temps -fverbose-asm -fsigned-char  -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
> -fno-asynchronous-unwind-tables
> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -mabi=aapcs -fno-short-enums -save-temps -funsigned-char -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
> +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -fno-short-enums -save-temps -fverbose-asm -funsigned-char  
> -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
> -Wno-address -fno-asynchronous-unwind-tables
>  DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
>  DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
>  DEFINE GCC_DLINK2_FLAGS_COMMON = 
> --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
> --
> 2.1.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] signedness of CHAR8

[Leif Lindholm]

On Thu, Mar 17, 2016 at 01:41:12PM +0100, Laszlo Ersek wrote:
> On 03/17/16 13:34, Leif Lindholm wrote:
> > On Thu, Mar 17, 2016 at 12:16:31PM +, Leif Lindholm wrote:
> >> So, as further fallout from my -Weverything experiments, I've come
> >> across this...
> >>
> >> Ia32 and X64 ProcessorBind.h (BaseTools and MdePkg) both define CHAR8 as 
> >> 'char'.
> >> ARM and AArch64 both do the same.
> >>
> >> However, default 'char' signedness is unsigned in the ARM
> >> architectures, and signed in the others.
> >>
> >> Meanwhile, the UEFI specification describes CHAR8 as
> >> ---
> >> 1-byte character. Unless otherwise specified, all 1-byte or ASCII 
> >> characters and
> >> strings are stored in 8-bit ASCII encoding format, using the
> >> ISO-Latin-1 character
> >> set.
> >> ---
> >>
> >> Now, ISO-Latin-1 holds values all the way up to 255, which clearly
> >> does not fit into a signed 8-bit char.
> >>
> >> Would I be correct in my interpretation that Ia32/X64 should be
> >> defining CHAR8 as 'unsigned char', or am I losing my mind?
> > 
> > I'll reply to myself.
> > 
> > BaseTools/Conf/tools_def.template sets -funsigned-chars for X64/Ia32 -
> 
> Where? I can only see that for XCODE5.

I stand corrected.

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

Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h

[Andrew Fish]

> On Mar 16, 2016, at 6:54 AM, Laszlo Ersek  wrote:
> 
> On 03/14/16 16:38, Leif Lindholm wrote:
>> To permit many existing platforms to build with -Wunused-parameter, on
>> GCC and CLANG, the unused parameters need to be annotated as such.
>> Existing regexp code already uses ARG_UNUSED for this, but it is really
>> needed across the codebase - so add a version in Base.h.
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Leif Lindholm 
>> ---
>> 
>> This is really the result of a friendly toolchain engineer informing me
>> CLANG has the -Weverything flag, to actually enable all possible
>> warnings.
>> 
>> One problem trying to pick out the real bugs from the just not entirely
>> clear code is that basically a lot of *LibNull implementations, and
>> some libraries that should be usable, trip build failures due to unused
>> parameters.
>> 
>> MdePkg/Include/Base.h | 9 +
>> 1 file changed, 9 insertions(+)
>> 
>> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
>> index 89b2aed..f789094 100644
>> --- a/MdePkg/Include/Base.h
>> +++ b/MdePkg/Include/Base.h
>> @@ -189,6 +189,15 @@ struct _LIST_ENTRY {
>> ///
>> #define OPTIONAL
>> 
>> +///
>> +/// Function argument intentionally unused in function.
>> +///
>> +#if defined(__GNUC__) || defined(__clang__)
>> +  #define ARG_UNUSED  __attribute__ ((unused))
>> +#else
>> +  #define ARG_UNUSED
>> +#endif
>> +
>> //
>> //  UEFI specification claims 1 and 0. We are concerned about the
>> //  complier portability so we did it this way.
>> 
> 
> Support for this seems to go back to gcc-4.4:
> 
> https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Variable-Attributes.html
> 
> So it looks safe. (And I agree with the idea.)
> 

I'm confused by the usage, or really when the compiler detects the warning? 

For example how is this going to work on public interfaces? Protocols, PPIs,  
or library class definitions? There is a single definition of the function, but 
multiple implementations. Some implementations may not use some arguments. But 
what arguments get used seems to be an implementation choice and not part of 
the API? Thus it seems like this macro is not going to enable changing compiler 
flags?

Or am I just confused?

Thanks,

Andrew Fish
 

> Acked-by: Laszlo Ersek 
> ___
> 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] MdeModulePkg DiskIoDxe: Media status check not be done at DiskIo level

[Hao Wu]

Found an issue that file system cannot be started on a DVD when doing the
following process:

Boot to shell with a DVD inside a SATA DVDROM. Eject the DVD and run
"reconnect -r". Put the DVD inside again and run "reconnect -r".

The cause is that after executing the second reconnect action, DiskIo
immediately returns EFI_NO_MEDIA in function DiskIo2ReadWriteDisk() when
checking the media information. However, at this time, the media
information does not get updated by the ScsiDisk driver. Therefore, DiskIo
driver should left the no media check to ScsiDisk driver.

Generally, the media changed and media write protect check should also be
left to lower-level device driver. Thus, these two checks in function
DiskIo2ReadWriteDisk() are also removed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c 
b/MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c
index 97f2d50..2b2e576 100644
--- a/MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c
+++ b/MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c
@@ -833,18 +833,6 @@ DiskIo2ReadWriteDisk (
   Status= EFI_SUCCESS;
   Blocking  = (BOOLEAN) ((Token == NULL) || (Token->Event == NULL));
 
-  if (!(Media->MediaPresent)) {
-return EFI_NO_MEDIA;
-  }
-
-  if (Media->MediaId != MediaId) {
-return EFI_MEDIA_CHANGED;
-  }
-  
-  if (Write && Media->ReadOnly) {
-return EFI_WRITE_PROTECTED;
-  }
-
   if (Blocking) {
 //
 // Wait till pending async task is completed.
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH] PcAtChipsetPkg/PciHostBridgeDxe: Remove it since MdeModulePkg contains a new one.

[Ni, Ruiyu]

All,
I would like to hear your concerns by the next weekend (Mar 26/27).
If there is no concern, I will remove it on the Monday after that (Mar 28).

And I think I can take Laszlo's mail below as a r-b response. Can I?

Regards,
Ray

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, March 16, 2016 9:39 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org 

Cc: Ard Biesheuvel ; Justen, Jordan L 

Subject: Re: [edk2] [PATCH] PcAtChipsetPkg/PciHostBridgeDxe: Remove it since 
MdeModulePkg contains a new one.

On 03/15/16 08:58, Ni, Ruiyu wrote:
> All,
> I am going to remove the PciHostBridgeDxe driver from PcAtChipsetPkg.
> This driver is not used by any platform as far as I know.
> Any concerns?

No objection from me (as far as OvmfPkg and ArmVirtPkg are concerned).

The new core PciHostBridgeDxe has been working out very well for OVMF.
(ArmVirtPkg will have to stick with its own fork for a while now.)

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

Re: [edk2] [PATCH] BaseTools: use unsigned chars on ARM architectures

[Leif Lindholm]

On Thu, Mar 17, 2016 at 02:09:56PM -0700, Andrew Fish wrote:
> 
> > On Mar 17, 2016, at 10:51 AM, Leif Lindholm  
> > wrote:
> > 
> > Hi Andrew,
> > 
> > On Thu, Mar 17, 2016 at 10:41:37AM -0700, Andrew Fish wrote:
> >> FYI, the char sign issue clang hit recently was due to mixing edk2
> >> types with standard C type. The edk2 type system does not assume
> >> that char is signed or unsigned.
> > 
> > I agree the type system gets it right, but the processor bindings do
> > not :)
> > 
> >> MdePkg/Include/X64/ProcessorBind.h
> >>  ///
> >>  /// 1-byte unsigned value
> >>  ///
> >>  typedef unsigned char   UINT8;
> >>  ///
> >>  /// 1-byte Character
> >>  ///
> >>  typedef charCHAR8;
> > 
> > On X64 and IA32, this will be unsigned with XCODE5 toolchains and
> > signed with other toolchains.
> > 
> 
> Depends how you look at it CHAR8 is compatible with char. But you
> can't assume that char or CHAR8 is the same as UINT8 or INT8.
> 
> Are you advocating we force CHAR8 to be signed? 

I am saying that by my interpretation of the UEFI specification, CHAR8
must be unsigned - as it cannot otherwise correctly represent the
ISO-Latin-1 charset.

If that interpretation is incorrect, I'm happy to be told so.

Regards,

Leif

> Thanks,
> 
> Andrew Fish
> 
> > Regards,
> > 
> > Leif
> > 
> >>  ///
> >>  /// 1-byte signed value
> >>  ///
> >>  typedef signed char INT8;
> >> 
> >> 
> >> Thanks,
> >> 
> >> Andrew Fish
> >> 
> >>> On Mar 17, 2016, at 6:22 AM, Leif Lindholm  
> >>> wrote:
> >>> 
> >>> By default, the ARM architectures have unsigned chars, whereas the other
> >>> architectures supported by EDK2 by default have signed chars.
> >>> However, EDK2 uses -funsigned-chars on those architectures to change the
> >>> default behaviour.
> >>> 
> >>> Unfortunately, the ARM architectures explicitly break their default
> >>> behaviour by specifying -fsigned-chars (I presume in a pre-emptive
> >>> attempt at avoiding incompatibility).
> >>> 
> >>> Since this situation is already confusing enough, switch the ARM
> >>> architectures to also specify -funsigned-chars explicitly rather than
> >>> just dropping the current parameter.
> >>> 
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: Leif Lindholm 
> >>> ---
> >>> BaseTools/Conf/tools_def.template | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/BaseTools/Conf/tools_def.template 
> >>> b/BaseTools/Conf/tools_def.template
> >>> index b1577af..eedf80f 100644
> >>> --- a/BaseTools/Conf/tools_def.template
> >>> +++ b/BaseTools/Conf/tools_def.template
> >>> @@ -4322,8 +4322,8 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os 
> >>> -fshort-wchar -fno-strict-aliasing -
> >>> DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
> >>> -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
> >>> -mno-stack-arg-probe
> >>> DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
> >>> -Wno-address -mno-stack-arg-probe
> >>> DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> >>> -minline-int-divide-min-latency
> >>> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> >>> -mlittle-endian -mabi=aapcs -fno-short-enums -save-temps -fsigned-char 
> >>> -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address 
> >>> -mthumb -mfloat-abi=soft
> >>> -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> >>> -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
> >>> -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
> >>> -Wno-address -fno-asynchronous-unwind-tables
> >>> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> >>> -mlittle-endian -mabi=aapcs -fno-short-enums -save-temps -funsigned-char 
> >>> -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address 
> >>> -mthumb -mfloat-abi=soft
> >>> +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> >>> -mlittle-endian -fno-short-enums -save-temps -fverbose-asm 
> >>> -funsigned-char  -ffunction-sections -fdata-sections -fomit-frame-pointer 
> >>> -fno-builtin -Wno-address -fno-asynchronous-unwind-tables
> >>> DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
> >>> DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
> >>> DEFINE GCC_DLINK2_FLAGS_COMMON = 
> >>> --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
> >>> -- 
> >>> 2.1.4
> >>> 
> >>> ___
> >>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdePkg: add UNUSED notation to Base.h

[Leif Lindholm]

To permit many existing platforms to build with -Wunused-parameter, on
GCC and CLANG, the unused parameters need to be annotated as such.
Existing regexp code already uses ARG_UNUSED for this, but it is really
needed across the codebase - so add a version called UNUSED in Base.h.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---

Change since RFC: rename ARG_UNUSED -> UNUSED.

 MdePkg/Include/Base.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 89b2aed..a68b209 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -189,6 +189,15 @@ struct _LIST_ENTRY {
 ///
 #define OPTIONAL
 
+///
+/// Function argument intentionally unused in function.
+///
+#if defined(__GNUC__) || defined(__clang__)
+  #define UNUSED  __attribute__ ((unused))
+#else
+  #define UNUSED
+#endif
+
 //
 //  UEFI specification claims 1 and 0. We are concerned about the
 //  complier portability so we did it this way.
-- 
2.1.4

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

Re: [edk2] [Patch V3] OvmfPkg/LegacyRegion: Support legacy region manipulation of Q35

[Laszlo Ersek]

On 03/16/16 00:33, Jordan Justen wrote:
> Regarding the subject, how about "PATCH v3" rather than "Patch V3"?
> 
> Reviewed-by: Jordan Justen 
> 
> Pushed as db27e9f3d8f007bf26bcb8907ecab5b5f1fb8f24.

Thanks guys, I skimmed it (found it in the git history already); it
looks good. Nice work.

Cheers
Laszlo

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

Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h

[Andrew Fish]

> On Mar 16, 2016, at 7:02 PM, Gao, Liming  wrote:
> 
> Andrew:
>   If we enable -Wunused-parameter option for GCC and CLANG, it will bring the 
> big change to edk2 project. This patch is just to add ARG_UNUSED notation to 
> Base.h. It has no impact. So, I think this patch is fine. 
>  

Liming,

I don't really have an issue adding it for source compatibility with other 
projects.

The comments from Leif imply an across the codebase change? I was trying to 
point out what a large undertaking that would be. 

> >>> On 03/14/16 16:38, Leif Lindholm wrote:
>  To permit many existing platforms to build with -Wunused-parameter, on
>  GCC and CLANG, the unused parameters need to be annotated as such.
>  Existing regexp code already uses ARG_UNUSED for this, but it is really
>  needed across the codebase - so add a version in Base.h.


Thanks,

Andrew Fish


> Thanks
> Liming <>
>  <>From: af...@apple.com  [mailto:af...@apple.com 
> ] 
> Sent: Thursday, March 17, 2016 1:12 AM
> To: Laszlo Ersek mailto:ler...@redhat.com>>
> Cc: Kinney, Michael D  >; edk2-de...@ml01.01.org 
> ; Gao, Liming  >; Leif Lindholm  >
> Subject: Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h
>  
> 
> > On Mar 16, 2016, at 10:06 AM, Laszlo Ersek wrote:
> > 
> > On 03/16/16 17:50, Andrew Fish wrote:
> >> 
> >>> On Mar 16, 2016, at 6:54 AM, Laszlo Ersek wrote:
> >>> 
> >>> On 03/14/16 16:38, Leif Lindholm wrote:
>  To permit many existing platforms to build with -Wunused-parameter, on
>  GCC and CLANG, the unused parameters need to be annotated as such.
>  Existing regexp code already uses ARG_UNUSED for this, but it is really
>  needed across the codebase - so add a version in Base.h.
>  
>  Contributed-under: TianoCore Contribution Agreement 1.0
>  Signed-off-by: Leif Lindholm 
>  ---
>  
>  This is really the result of a friendly toolchain engineer informing me
>  CLANG has the -Weverything flag, to actually enable all possible
>  warnings.
>  
>  One problem trying to pick out the real bugs from the just not entirely
>  clear code is that basically a lot of *LibNull implementations, and
>  some libraries that should be usable, trip build failures due to unused
>  parameters.
>  
>  MdePkg/Include/Base.h | 9 +
>  1 file changed, 9 insertions(+)
>  
>  diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
>  index 89b2aed..f789094 100644
>  --- a/MdePkg/Include/Base.h
>  +++ b/MdePkg/Include/Base.h
>  @@ -189,6 +189,15 @@ struct _LIST_ENTRY {
>  ///
>  #define OPTIONAL
>  
>  +///
>  +/// Function argument intentionally unused in function.
>  +///
>  +#if defined(__GNUC__) || defined(__clang__)
>  + #define ARG_UNUSED __attribute__ ((unused))
>  +#else
>  + #define ARG_UNUSED
>  +#endif
>  +
>  //
>  // UEFI specification claims 1 and 0. We are concerned about the
>  // complier portability so we did it this way.
>  
> >>> 
> >>> Support for this seems to go back to gcc-4.4:
> >>> 
> >>> https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Variable-Attributes.html 
> >>> 
> >>> 
> >>> So it looks safe. (And I agree with the idea.)
> >>> 
> >> 
> >> I'm confused by the usage, or really when the compiler detects the
> >> warning?
> >> 
> >> For example how is this going to work on public interfaces?
> >> Protocols, PPIs, or library class definitions? There is a single
> >> definition of the function, but multiple implementations. Some
> >> implementations may not use some arguments. But what arguments get
> >> used seems to be an implementation choice and not part of the API?
> >> Thus it seems like this macro is not going to enable changing
> >> compiler flags?
> > 
> > I think this attribute would be used in library instances and protocol
> > implementations. It would not be used in library class headers nor
> > protocol definitions.
> > 
> > Example:
> > 
> > /* included from library class hdr of protocol def hdr */
> > int f(int x);
> > 
> > /* code in library instance or protocol impl */
> > int f(int x __attribute__ ((unused)))
> > {
> > return 0;
> > }
> > 
> > int main(void)
> > {
> > return f(-2);
> > }
> > 
> > Compiles silently with
> > 
> > $ gcc -Wall -Wextra -ansi -pedantic -Werror -o x x.c
> > 
> > If I remove __attribute__ ((unused)), I get:
> > 
> > x.c:5:15: error: unused parameter 'x' [-Werror=unused-parameter]
> > int f(int x)
> > ^
> > cc1: all warnings being treated as errors
> > 
> 
> OK that makes sense. That is feels like it is going to be a very very large 
> change to the codebase given almost every protocol and PPI member pass the 
> "This" pointer, but may not use it in c

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

[Laszlo Ersek]

On 03/18/16 04:23, Ni, Ruiyu wrote:
> Laszlo,
> I downloaded the stable 4.4.6 and build it myself.
> 1. enable KVM as a module in "make menuconfig"
> 2. "make -j3"
> 2. install the modules/kernel: "sudo make install_modules" and "sudo make 
> install"
> 3. update the boot loader "sudo update-grub2"
> 4. reboot to use the new kernel "sudo reboot"
> 
> I can confirm that the new kernel is used because in the first time I built 
> the kernel,
> I forgot to turn on KVM which resulted the QEMU failed to start.
> After I turned on the KVM in "make menuconfig", the new kernel can start QEMU.
> 
> However, I got the same result as that when I used the 4.4.1 in ppa.
> The QEMU stops at UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c : 
> SmmRelocateBases()
> in the line: while (!mRebased[BspIndex]);
> 
> What else did I miss?
> 
> Is there any advanced feature requirement to the HOST CPU besides the 
> fundamental VT?
> Could it because my HOST CPU is too old?
> Please forgive my ignorance. :(
> I attached the /proc/cpuinfo.

I think you didn't miss anything. Thank you for going the extra mile and
building your kernel.

I believe it is possible that your host CPU is too old, but I can't say
for sure. I'd like to ask Paolo for help with that.

Can you please post the output of the following command:

  tail /sys/module/kvm_intel/parameters/*

If the output says that "unrestricted_guest" is "N", then it could be a
problem. Paolo should correct me if necessary, but when entering SMM, it
is real mode, and for virtualizing real mode, you need "unrestricted_guest".

KVM can also emulate some aspects of real mode, if you lack
"unrestricted_guest" (see "emulate_invalid_guest_state" as well in the
output of the above command -- it defaults to Y).

... Hm, according to wikipedia
,

Intel started to include Extended Page Tables (EPT), a technology
for page-table virtualization, since the Nehalem architecture,
released in 2008. In 2010, Westmere added support for launching the
logical processor directly in real mode – a feature called
"unrestricted guest", which requires EPT to work.

I don't see "ept" in your "cpuinfo.txt" file.

http://ark.intel.com/products/30784/Intel-Core2-Duo-Processor-E6750-4M-Cache-2_66-GHz-1333-MHz-FSB

FWIW, my old company workstation, a HP Z400 with "Intel(R) Xeon(R) CPU
W3550", also lacks "unrestricted_guest" (although it does have EPT).

http://ark.intel.com/products/39720/Intel-Xeon-Processor-W3550-8M-Cache-3_06-GHz-4_80-GTs-Intel-QPI

I've retested SMM in OVMF just now, on that workstation, and it works
fine. (The host kernel is "4.4.3-201.fc22.x86_64", for the record.)

So I think your host processor might be too old indeed, but I can't tell
which feature exactly is missing. :(

... Hm, wait a second, maybe I can. It could be EPT after all. I
reloaded my kvm_intel module with ept=N (i.e., it wouldn't use EPT even
if the host processor provided it), and indeed my guest failed to boot
as well; it got stuck in OVMF while pegging a few host CPU cores. The
last lines I saw in the log were:

Detect CPU count: 8
Does not find any HOB stored CPU BIST information!

Can you try on a less ancient machine?

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

[edk2] [PATCH] ArmPkg/AArch64Mmu: use correct AP[] bits in ArmClearMemoryRegionReadOnly

[Ard Biesheuvel]

The function ArmClearMemoryRegionReadOnly() was supposed to undo the
effect of ArmSetMemoryRegionReadOnly(), but instead, it sets the permissions
to EL0-no access, EL1-read-only. Since the EL0 bit should be 1 to align
with EL2/3 (where the bit is SBO), use TT_AP_RW_RW instead, which makes the
entry read-write for EL0 when executing at EL1, and read-write for all other
levels.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
index f967a6478840..b7d23c6f3286 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
@@ -558,7 +558,7 @@ ArmClearMemoryRegionReadOnly (
   return SetMemoryRegionAttribute (
BaseAddress,
Length,
-   TT_AP_NO_RO,
+   TT_AP_RW_RW,
~(TT_ADDRESS_MASK_BLOCK_ENTRY | TT_AP_MASK));
 }
 
-- 
2.5.0

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

Re: [edk2] EDK2 Staging Repository 2nd Draft

[David Woodhouse]

> On 03/15/16 18:20, Kinney, Michael D wrote:
> I don't object to pulling, if the submitter explicitly requests it, and
> if we're making this option official now.

Let's say "at the discretion of the person doing the merge" rather than
writing down that it should need an explicit request.

Over time, as people get used to using the tools properly, I would expect
that pulling will become the default behaviour. By choosing to rebase
instead, *you* are choosing to discard the correct history of the original
development vs. the merge, and to take the responsibility for any
resulting problems.

> Regarding Reviewed-by tags, I like to review series per-patch, and I
> also like the tags to be present in the commit history per-patch. For
> example, when a series modifies several top-level packages, I don't /
> can't always review all patches in full depth; so I might give an
> Acked-by for some patches, or even nothing.
>
> In this case I'm fine with the submitter rebasing one last time, adding
> the tags, and then I can do the pull. (I'll have to remember to verify
> the individual patches on the branch being pulled, and the labels on the
> commit messages, against the mailing list traffic.)

Of course you had to do that verification anyway, as the patch in your
inbox might not actually match the "same" message on the list. So no
change there.

It's also worth noting that we use "rebase" for two different things. In
normal usage it's considered bad form just to recommit the same patch on
the *same* parent. We will probably continue to do that freely here, and
as long as you don't move it to a new parent, that's OK. But people
generally still call that "rebasing".


-- 
dwmw2

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

[edk2] [PATCH 4/7] ArmPkg/ArmExceptionLib: don't restore ESR and FAR upon exception return

[Ard Biesheuvel]

ESR and FAR are populated by the hardware upon exception entry, and
describe the exception, not the interrupted context. So there is no point
in restoring their values before returning from the exception.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 6 --
 1 file changed, 6 deletions(-)

diff --git a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S 
b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
index 3117e710fa53..c7ea061a93ea 100644
--- a/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
+++ b/ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S
@@ -356,18 +356,12 @@ ASM_PFX(CommonExceptionEntry):
   EL1_OR_EL2_OR_EL3(x6)
 1:msr  elr_el1, x1   // Exception Link Register
   msr  spsr_el1,x2   // Saved Processor Status Register 32bit
-  msr  esr_el1, x4   // EL1 Exception syndrome register 32bit
-  msr  far_el1, x5   // EL1 Fault Address Register
   b4f
 2:msr  elr_el2, x1   // Exception Link Register
   msr  spsr_el2,x2   // Saved Processor Status Register 32bit
-  msr  esr_el2, x4   // EL2 Exception syndrome register 32bit
-  msr  far_el2, x5   // EL2 Fault Address Register
   b4f
 3:msr  elr_el3, x1   // Exception Link Register
   msr  spsr_el3,x2   // Saved Processor Status Register 32bit
-  msr  esr_el3, x4   // EL3 Exception syndrome register 32bit
-  msr  far_el3, x5   // EL3 Fault Address Register
 4:msr  fpsr, x3  // Floating point Status Register  32bit
 
   // pop all regs and return from exception.
-- 
2.5.0

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

Re: [edk2] [PATCH] MdePkg: add UNUSED notation to Base.h

[Andrew Fish]

> On Mar 17, 2016, at 2:34 PM, Kinney, Michael D  
> wrote:
> 
> Andrew,
> 
> I agree that adding UNUSED to Base.h solves the issues that multiple packages
> may want to enable that warning and have a way to decorate implementation so
> the warning is not generated.
> 
> I did mix two topics in this discussion.  One is code review of UNUSED macro,
> and the other is an EDK II C Coding Style topic.  As long as use of UNUSED
> is optional, and each package/module owner gets to decide if use of UNUSED
> is required or not, then I am ok with adding the macro to Base.h.
> 
> We may want to add comments above the UNUSED macro in Base.h to provide a 
> more detailed description that describes that it is optional and if/when it
> should be used.
> 
> We will also need to decide if we want any statements in the EDK II  C Coding 
> Style document about use of the UNUSED macro, but that is likely its own 
> thread.
> 

Mike,

Sounds good to me.

Thanks,

Andrew Fish

> Mike

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

Re: [edk2] [PATCH v2] NetworkPkg:Fix Http boot download issue.

[Fu, Siyuan]

Lubo



I think the AsciiStrCmp should be "!=" zero (not zero means not identical).



> -Original Message-

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of

> Zhang Lubo

> Sent: Friday, March 18, 2016 2:51 PM

> To: edk2-devel@lists.01.org

> Cc: Ye, Ting ; Fu, Siyuan ; Wu,

> Jiaxin 

> Subject: [edk2] [PATCH v2] NetworkPkg:Fix Http boot download issue.

>

> v2:

> * Simplify the code logic.

>

> When http boot download the second time without return

> out of the boot manager, the DHCP process will start twice

> with the same Boot file uri and print the information twice

> which we not expected. This is caused by wrong logic

> of handling the device path of the boot file when loading it.

>

> Cc: Fu Siyuan mailto:siyuan...@intel.com>>

> Cc: Ye Ting mailto:ting...@intel.com>>

> Cc: Wu Jiaxin mailto:jiaxin...@intel.com>>

> Contributed-under: TianoCore Contribution Agreement 1.0

> Signed-off-by: Zhang Lubo mailto:lubo.zh...@intel.com>>

> ---

>  NetworkPkg/HttpBootDxe/HttpBootImpl.c | 3 +--

>  1 file changed, 1 insertion(+), 2 deletions(-)

>

> diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> b/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> index 3adb08d..451b24d 100644

> --- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> +++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c

> @@ -428,12 +428,11 @@ HttpBootDxeLoadFile (

>  //

>  // Restart the HTTP boot driver in 2 cases:

>  // 1. Http boot Driver has already been started but not on the required 
> IP

> version.

>  // 2. The required boot FilePath is different with the one we produced in

> the device path

>  // protocol.

> -//

> -if ((UsingIpv6 != Private->UsingIpv6) || !IsDevicePathEnd(FilePath)) {

> +if ((UsingIpv6 != Private->UsingIpv6) || ((Private->FilePathUri != NULL) 
> &&

> (AsciiStrCmp (Private->BootFileUri, Private->FilePathUri) == 0))) {

>Status = HttpBootStop (Private);

>if (!EFI_ERROR (Status)) {

>  Status = HttpBootStart (Private, UsingIpv6, FilePath);

>}

>  }

> --

> 1.9.5.msysgit.1

>

> ___

> 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] MdePkg: add UNUSED notation to Base.h

[Laszlo Ersek]

On 03/17/16 20:51, Laszlo Ersek wrote:
> (adding Ard and Shumin because the below will tie in with another thread)
> 
> On 03/17/16 19:05, Leif Lindholm wrote:
> 
>> I must confess to no small amount of surprise that optionally adding
>> the ability to tag an unused argument as unused is controversial.

> If I understand correctly, if we wanted to enable "-Wunused-parameter
> -Wunused-but-set-parameter" even just occasionally, these ~4000
> instances would have to be audited, and each should be either fixed
> (i.e., internal functions should drop the parameters) or marked UNUSED
> (i.e., library instances and PPI/protocol implementations should
> annotate their definitions of public functions).
> 
> Thus, this is what surprises me. It looks daunting.

Small clarification: if you'd like to selectively add
"-Wunused-parameter -Wunused-but-set-parameter" to the [BuildOptions] of
a number of (non-core?) modules (in their INF files), and employ UNUSED
in connection with that, I certainly think that's a valid use case.

To me it does justify this patch. Namely, perhaps marking parameters as
UNUSED will not be enforced across the entire tree, but if a module
owner would like to enable those warnings on his/her turf, then he/she
should be able to annotate the unused parameters with a macro that is
centrally defined. The macro definition should be universal, even though
its application might not be.

Thanks
Laszlo

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

Re: [edk2] Has any one else had issues trying to use DxeDebugPrintErrorLevelLib? DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf

[Andrew Fish]

> On Mar 17, 2016, at 5:15 AM, peter.kirme...@ts.fujitsu.com wrote:
> 
> Hi all,
> 
> from my point of view a library should use a constructor to initialize OWN 
> resources only. That means that there is no need for external resources at 
> this point. The library can use PeiService/SystemTable to register for events 
> or protocols (when they need to react to them). Or they finalize 
> initialization on the first time a library function gets called.
> I don't know how many EDK2 libraries would fulfill this requirement and if it 
> is worth to note that rule into specification (when you agree) but this way 
> one can get rid of dependency loops.
> 

Peter,

It might not be a bad idea to make this a recommendation, and implement it in 
the key packages (MdePkg, MdeModulePkg, etc.). 

I've been working on the edk2 since the beginning and this is the 1st time I 
every remember hitting this issue in a real world situation. I'm guessing since 
most libraries are small and have limited dependencies we don't hit this a lot. 
However given the error messages you get it is quite painful to debug. I 
basically had to do a binary search of disabling dependent libraries to figure 
this out. I think the DebugLib is a special case since it is used by almost 
every other library, and it has the possibility of being complex and depend on 
a lot of other libraries. 

Thanks,

Andrew Fish

> Best Regards,
>  Peter Kirmeier
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Thursday, March 17, 2016 11:16 AM
> To: Laszlo Ersek; Gao, Liming
> Cc: edk2-devel; Andrew Fish; Zeng, Star
> Subject: Re: [edk2] Has any one else had issues trying to use 
> DxeDebugPrintErrorLevelLib? 
> DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
> 
> On 17 March 2016 at 10:11, Laszlo Ersek  wrote:
>> Adding Ard
>> 
>> On 03/17/16 08:28, Zeng, Star wrote:
>>> On 2016/3/17 15:16, Andrew Fish wrote:
 
> On Mar 17, 2016, at 12:10 AM, Gao, Liming  wrote:
> 
> Andrew:
>  DxeDebugPrintErrorLevelLib has Constructor. DxeHobLib has 
> Constructor. If DebugLib also has Constructor, the circle of
> Constructor() will happen and cause build break.
> DxeDebugPrintErrorLevelLib instance increases the possibility of 
> the circle Constructor(). To resolve it, we can update 
> DxeDebugPrintErrorLevelLib or DxeHobLib library instance by moving 
> their constructor into every function API.
> 
 
 Liming,
 
 Thanks, I came to the same conclusion. I'm making a local copy 
 DxeDebugPrintErrorLevelLib that does the HOB accesses in the driver 
 without the HobLib and that will solve our issue. I was just 
 surprised the edk2 library was not very useful in the real world. 
 Not to mention the build error message did not help find the real issue, 
 the HOB lib.
>>> 
>>> I reproduced the issue locally. With the change below to integrate
>>> HobLibConstructor() to GetHobList(), since all other interface of 
>>> DxeHobLib are just to call GetHobList(), the issue is gone. What is 
>>> your opinion?
>> 
>> This could make it possible for ArmVirtPkg to remove the 
>> ArmVirtDxeHobLib library instance. That library instance was cloned 
>> exactly in order to break this dependency cycle, see commit ad90df8ac0.
>> 
>> I think the proposal and the patch are good.
>> 
> 
> As I have mentioned in the past, there is a general issue with the
> EDK2 BaseTools where a transitive dependency on a library that has a 
> constructor is not taken into account when checking for cycles.
> 
> For example,
> 
> lib A depends on lib B, which has a constructor lib B depends on lib C, which 
> has no constructor lib C depends on lib D, which has a constructor lib D 
> depends on lib A, which has no constructor
> 
> In this case, the build will happily succeed, but which constructor executes 
> first (lib B or lib D) is undefined, and there is generally no correct 
> solution as either constructor could transitively depend on the other library 
> having been constructed already.
> 
> So I think it would be a good step to fix the build tools to detect this 
> case, but I am afraid it will expose errors in many places in the code base.
> 
> I am kind of glad someone else is hitting this right now, since the last time 
> I brought it up, nobody really cared afair.
> 
> Thanks,
> Ard.
> ___
> 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] ArmVirtPkg/ArmVirtQemu: move to ARM version of CpuExceptionHandlerLib

[Ard Biesheuvel]

On 16 March 2016 at 12:40, Laszlo Ersek  wrote:
> On 03/16/16 12:39, Laszlo Ersek wrote:
>> On 03/16/16 12:24, Ard Biesheuvel wrote:
>>> Change our resolution for the previously unused CpuExceptionHandlerLib
>>> from the null implementation to the newly added implementation specific
>>> to AARCH64 and ARM. This is needed since our CpuDxe will start using it
>>> in a subsequent patch.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  ArmVirtPkg/ArmVirt.dsc.inc | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>>> index 5938cb4ebfcb..db31b2dc4cfe 100644
>>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>>> @@ -83,7 +83,7 @@ [LibraryClasses.common]
>>># ARM Architectural Libraries
>>>
>>> CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
>>>
>>> DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
>>> -  
>>> CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
>>> +  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
>>>
>>> ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
>>>DmaLib|ArmPkg/Library/ArmDmaLib/ArmDmaLib.inf
>>>ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
>>>
>>
>> Acked-by: Laszlo Ersek 
>>

Thanks

>> Can you pls summarize in a few words what the exception handlers will
>> do? For example, in OVMF's case, a register dump is written to the
>> serial port, and the image and the exception address into it are named too.
>
> I mean: it's enough to educate me on the list; this wasn't a suggestion
> to update the commit message.
>

This is just the plumbing to register and unregister exception
handlers. If an exception occurs for which no handler has been
registered, the DefaultExceptionHandler() implementation supplied by
DefaultExceptionHandlerLib is invoked. This aligns with how CpuDxe is
implemented currently, but moves it to a separate library.

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

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[David Woodhouse]

On Wed, 2016-03-16 at 22:05 +, Kinney, Michael D wrote:
> 
> I responded to an earlier email:

Ah, apologies — it wasn't clear this was intended as an answer to that
question. This is one of those examples with the common email behaviour
of placing the response below a carefully-selected citation would have
helped a great deal, FWIW.

> I think there are several methods we can support for development.
> 
> 1) Simple bug fixes/features sent directly to edk2-devel for PRs.
> 2) A larger or more complex bug fix/feature can optionally post a link
>    to a branch on personal github fork to help simplify the review process 
>    for those reviewers that prefer to use that method.  This type of bug 
>    fix or feature is usually owned by a single subject matter expert.
> 3) A larger or more complex feature that requires design/dev/test by more
>    than one subject matter expert.
> 
> We already support (1) and (2) today.  Feature branches on edk2-staging are 
> intended for (3).

So the answer would be that it allows more than one person to
collaborate on a submission? I'm not sure we need a whole new process
document just for that, do we? It's not as if it's hard for people to
share access to their repositories, or just pull from each other's.

==

On Wed, 2016-03-16 at 15:15 -0700, Andrew Fish wrote:
> I think David's point is any github repository can be used for this,
> if I understand David's point?

Precisely so.

> So the only value to branches is an official place for them to live?
> Thus a way they can be discovered.

Can't they already be discovered at
https://github.com/tianocore/edk2/pulls ?

This is the normal workflow. People (individuals or otherwise) put
together some work, discussion happens (and is archived and
discoverable) in a pull request. New versions of the tree can be
submitted to the PR at any time.

We don't need to invent anything new and different, just to allow more
than one person to work together on a submission.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/9] DuetPkg/PciBusNoEnumerationDxe: Skip disabled devices

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 



-Original Message-
From: Bjorge, Erik C
Sent: Friday, March 4, 2016 10:01 AM
To: Leahy, Leroy P mailto:leroy.p.le...@intel.com>>; 
Ni, Ruiyu mailto:ruiyu...@intel.com>>; 
edk2-devel@lists.01.org
Subject: RE: [PATCH 4/9] DuetPkg/PciBusNoEnumerationDxe: Skip disabled devices

Reviewed-by: Erik Bjorge 
mailto:erik.c.bjo...@intel.com>>

> -Original Message-
> From: Leahy, Leroy P
> Sent: Friday, March 4, 2016 8:59 AM
> To: Ni, Ruiyu mailto:ruiyu...@intel.com>>; 
> edk2-devel@lists.01.org; Bjorge,
> Erik C mailto:erik.c.bjo...@intel.com>>
> Cc: Leahy, Leroy P mailto:leroy.p.le...@intel.com>>
> Subject: [PATCH 4/9] DuetPkg/PciBusNoEnumerationDxe: Skip disabled
> devices
>
> Skip non-bridge devices which are not enabled either for memory or I/O
> access.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Lee Leahy 
> mailto:leroy.p.le...@intel.com>>
> ---
>  DuetPkg/PciBusNoEnumerationDxe/PciEnumeratorSupport.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/DuetPkg/PciBusNoEnumerationDxe/PciEnumeratorSupport.c
> b/DuetPkg/PciBusNoEnumerationDxe/PciEnumeratorSupport.c
> index ca300cf..3802424 100644
> --- a/DuetPkg/PciBusNoEnumerationDxe/PciEnumeratorSupport.c
> +++ b/DuetPkg/PciBusNoEnumerationDxe/PciEnumeratorSupport.c
> @@ -227,6 +227,15 @@ Returns:
>if (!EFI_ERROR (Status)) {
>
>  //
> +// Skip non-bridge devices which are not enabled
> +//
> +if (((Pci.Hdr.Command & (EFI_PCI_COMMAND_IO_SPACE
> +  | EFI_PCI_COMMAND_MEMORY_SPACE)) ==
> 0)
> +  && (!(IS_PCI_BRIDGE (&Pci) || IS_CARDBUS_BRIDGE (&Pci {
> +  continue;
> +}
> +
> +//
>  // Collect all the information about the PCI device discovered
>  //
>  Status = PciSearchDevice (
> --
> 1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h

[Laszlo Ersek]

On 03/16/16 17:50, Andrew Fish wrote:
> 
>> On Mar 16, 2016, at 6:54 AM, Laszlo Ersek  wrote:
>>
>> On 03/14/16 16:38, Leif Lindholm wrote:
>>> To permit many existing platforms to build with -Wunused-parameter, on
>>> GCC and CLANG, the unused parameters need to be annotated as such.
>>> Existing regexp code already uses ARG_UNUSED for this, but it is really
>>> needed across the codebase - so add a version in Base.h.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Leif Lindholm 
>>> ---
>>>
>>> This is really the result of a friendly toolchain engineer informing me
>>> CLANG has the -Weverything flag, to actually enable all possible
>>> warnings.
>>>
>>> One problem trying to pick out the real bugs from the just not entirely
>>> clear code is that basically a lot of *LibNull implementations, and
>>> some libraries that should be usable, trip build failures due to unused
>>> parameters.
>>>
>>> MdePkg/Include/Base.h | 9 +
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
>>> index 89b2aed..f789094 100644
>>> --- a/MdePkg/Include/Base.h
>>> +++ b/MdePkg/Include/Base.h
>>> @@ -189,6 +189,15 @@ struct _LIST_ENTRY {
>>> ///
>>> #define OPTIONAL
>>>
>>> +///
>>> +/// Function argument intentionally unused in function.
>>> +///
>>> +#if defined(__GNUC__) || defined(__clang__)
>>> +  #define ARG_UNUSED  __attribute__ ((unused))
>>> +#else
>>> +  #define ARG_UNUSED
>>> +#endif
>>> +
>>> //
>>> //  UEFI specification claims 1 and 0. We are concerned about the
>>> //  complier portability so we did it this way.
>>>
>>
>> Support for this seems to go back to gcc-4.4:
>>
>> https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Variable-Attributes.html
>>
>> So it looks safe. (And I agree with the idea.)
>>
> 
> I'm confused by the usage, or really when the compiler detects the
> warning?
> 
> For example how is this going to work on public interfaces?
> Protocols, PPIs,  or library class definitions? There is a single
> definition of the function, but multiple implementations. Some
> implementations may not use some arguments. But what arguments get
> used seems to be an implementation choice and not part of the API?
> Thus it seems like this macro is not going to enable changing
> compiler flags?

I think this attribute would be used in library instances and protocol
implementations. It would not be used in library class headers nor
protocol definitions.

Example:

/* included from library class hdr of protocol def hdr */
int f(int x);

/* code in library instance or protocol impl */
int f(int x __attribute__ ((unused)))
{
  return 0;
}

int main(void)
{
  return f(-2);
}

Compiles silently with

$ gcc -Wall -Wextra -ansi -pedantic -Werror -o x x.c

If I remove __attribute__ ((unused)), I get:

x.c:5:15: error: unused parameter 'x' [-Werror=unused-parameter]
 int f(int x)
   ^
cc1: all warnings being treated as errors

Thanks
Laszlo

> 
> Or am I just confused?
> 
> Thanks,
> 
> Andrew Fish
>  
> 
>> Acked-by: Laszlo Ersek 
>> ___
>> 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 1/2] MdeModulePkg DxeCore: Check Start consistently in CoreConvertPagesEx

[Star Zeng]

Current check:
ASSERT (NumberOfPages);
ASSERT ((Start & EFI_PAGE_MASK) == 0);
ASSERT (End > Start) ;

if (NumberOfPages == 0 ||
((Start & EFI_PAGE_MASK) != 0) ||
(Start > (Start + NumberOfBytes))) {

This patch is to update "(Start > (Start + NumberOfBytes))" to "(Start >= End)"
to be consistent with "ASSERT (End > Start)"

Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 9dbb85da7c87..62738a187546 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1,7 +1,7 @@
 /** @file
   UEFI Memory page management functions.
 
-Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 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
@@ -725,7 +725,7 @@ CoreConvertPagesEx (
   ASSERT_LOCKED (&gMemoryLock);
   ASSERT ( (ChangingType == FALSE) || (ChangingAttributes == FALSE) );
 
-  if (NumberOfPages == 0 || ((Start & EFI_PAGE_MASK) != 0) || (Start > (Start 
+ NumberOfBytes))) {
+  if (NumberOfPages == 0 || ((Start & EFI_PAGE_MASK) != 0) || (Start >= End)) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.7.0.windows.1

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

Re: [edk2] [Patch] MdePkg/Pci22.h: Fix a coding style issue

[Qiu, Shumin]

Reviewed-by: Qiu Shumin 

-Original Message-
From: Ni, Ruiyu 
Sent: Friday, March 18, 2016 2:05 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Qiu, Shumin
Subject: [Patch] MdePkg/Pci22.h: Fix a coding style issue

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Shumin Qiu 
---
 MdePkg/Include/IndustryStandard/Pci22.h | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Pci22.h 
b/MdePkg/Include/IndustryStandard/Pci22.h
index 78ec6b3..0b3a785 100644
--- a/MdePkg/Include/IndustryStandard/Pci22.h
+++ b/MdePkg/Include/IndustryStandard/Pci22.h
@@ -5,11 +5,10 @@
 PCI Local Bus Specification, 2.2
 PCI-to-PCI Bridge Architecture Specification, Revision 1.2
 PC Card Standard, 8.0
+PCI Power Management Interface Specifiction, Revision 1.2
 
-
-
-  Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
-  Copyright (c) 2014 - 2105, Hewlett-Packard Development Company, L.P.
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights 
+ reserved.  Copyright (c) 2014 - 2015, Hewlett-Packard Development 
+ Company, L.P.
   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
@@ -666,7 +665,7 @@ typedef union {
   struct {
 UINT16 Version : 3;
 UINT16 PmeClock : 1;
-UINT16 : 1;
+UINT16 Reserved : 1;
 UINT16 DeviceSpecificInitialization : 1;
 UINT16 AuxCurrent : 3;
 UINT16 D1Support : 1;
@@ -685,7 +684,7 @@ typedef union {
 typedef union {
   struct {
 UINT16 PowerState : 2;
-UINT16 : 6;
+UINT16 Reserved : 6;
 UINT16 PmeEnable : 1;
 UINT16 DataSelect : 4;
 UINT16 DataScale : 2;
--
2.7.0.windows.1

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

Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h

[Gao, Liming]

Andrew:
  If we enable -Wunused-parameter option for GCC and CLANG, it will bring the 
big change to edk2 project. This patch is just to add ARG_UNUSED notation to 
Base.h. It has no impact. So, I think this patch is fine.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Thursday, March 17, 2016 1:12 AM
To: Laszlo Ersek 
Cc: Kinney, Michael D ; edk2-de...@ml01.01.org; 
Gao, Liming ; Leif Lindholm 
Subject: Re: [edk2] [RFC] MdePkg: add ARG_UNUSED notation to Base.h


> On Mar 16, 2016, at 10:06 AM, Laszlo Ersek wrote:
>
> On 03/16/16 17:50, Andrew Fish wrote:
>>
>>> On Mar 16, 2016, at 6:54 AM, Laszlo Ersek wrote:
>>>
>>> On 03/14/16 16:38, Leif Lindholm wrote:
 To permit many existing platforms to build with -Wunused-parameter, on
 GCC and CLANG, the unused parameters need to be annotated as such.
 Existing regexp code already uses ARG_UNUSED for this, but it is really
 needed across the codebase - so add a version in Base.h.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Leif Lindholm
 ---

 This is really the result of a friendly toolchain engineer informing me
 CLANG has the -Weverything flag, to actually enable all possible
 warnings.

 One problem trying to pick out the real bugs from the just not entirely
 clear code is that basically a lot of *LibNull implementations, and
 some libraries that should be usable, trip build failures due to unused
 parameters.

 MdePkg/Include/Base.h | 9 +
 1 file changed, 9 insertions(+)

 diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
 index 89b2aed..f789094 100644
 --- a/MdePkg/Include/Base.h
 +++ b/MdePkg/Include/Base.h
 @@ -189,6 +189,15 @@ struct _LIST_ENTRY {
 ///
 #define OPTIONAL

 +///
 +/// Function argument intentionally unused in function.
 +///
 +#if defined(__GNUC__) || defined(__clang__)
 + #define ARG_UNUSED __attribute__ ((unused))
 +#else
 + #define ARG_UNUSED
 +#endif
 +
 //
 // UEFI specification claims 1 and 0. We are concerned about the
 // complier portability so we did it this way.

>>>
>>> Support for this seems to go back to gcc-4.4:
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Variable-Attributes.html
>>>
>>> So it looks safe. (And I agree with the idea.)
>>>
>>
>> I'm confused by the usage, or really when the compiler detects the
>> warning?
>>
>> For example how is this going to work on public interfaces?
>> Protocols, PPIs, or library class definitions? There is a single
>> definition of the function, but multiple implementations. Some
>> implementations may not use some arguments. But what arguments get
>> used seems to be an implementation choice and not part of the API?
>> Thus it seems like this macro is not going to enable changing
>> compiler flags?
>
> I think this attribute would be used in library instances and protocol
> implementations. It would not be used in library class headers nor
> protocol definitions.
>
> Example:
>
> /* included from library class hdr of protocol def hdr */
> int f(int x);
>
> /* code in library instance or protocol impl */
> int f(int x __attribute__ ((unused)))
> {
> return 0;
> }
>
> int main(void)
> {
> return f(-2);
> }
>
> Compiles silently with
>
> $ gcc -Wall -Wextra -ansi -pedantic -Werror -o x x.c
>
> If I remove __attribute__ ((unused)), I get:
>
> x.c:5:15: error: unused parameter 'x' [-Werror=unused-parameter]
> int f(int x)
> ^
> cc1: all warnings being treated as errors
>

OK that makes sense. That is feels like it is going to be a very very large 
change to the codebase given almost every protocol and PPI member pass the 
"This" pointer, but may not use it in code.

Do we need something for VC++?

Thanks,

Andrew Fish

> Thanks
> Laszlo
>
>>
>> Or am I just confused?
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>>> Acked-by: Laszlo Ersek
>>> ___
>>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Modify the 'dh' Shell command to dump the Firmware Management Protocol Image Descriptor Information.

[Carsey, Jaben]

We need to split into 2 patches (a series), one for MdePkg and one for 
ShellPkg.  Comments below inline.

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, March 16, 2016 8:55 AM
> To: edk2-devel@lists.01.org
> Cc: samer.el-haj-mahm...@hpe.com; Carsey, Jaben
> ; Tapan Shah 
> Subject: [PATCH] ShellPkg: Modify the 'dh' Shell command to dump the
> Firmware Management Protocol Image Descriptor Information.
> Importance: High
> 
> Modify 'dh' shell command to dump FirmwareManagement Protocol
> information.
> Add FirmwareManagement image descriptor V1 and V2 structure definition to
> support decoding all 3 revisions.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah 
> ---
>  MdePkg/Include/Protocol/FirmwareManagement.h   | 116 ++
>  .../UefiHandleParsingLib/UefiHandleParsingLib.c| 396
> -
>  .../UefiHandleParsingLib/UefiHandleParsingLib.uni  |  54 +++
>  3 files changed, 564 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/FirmwareManagement.h
> b/MdePkg/Include/Protocol/FirmwareManagement.h
> index e615573..67f19fd 100644
> --- a/MdePkg/Include/Protocol/FirmwareManagement.h
> +++ b/MdePkg/Include/Protocol/FirmwareManagement.h
> @@ -10,6 +10,7 @@
> 
>Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
>Copyright (c) 2013 - 2014, Hewlett-Packard Development Company,
> L.P.
> +  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>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
> @@ -119,6 +120,121 @@ typedef struct {
>UINT64   HardwareInstance;
>  } EFI_FIRMWARE_IMAGE_DESCRIPTOR;
> 
> +#define   EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V1   1
> +#define   EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V2   2
> +
> +///
> +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec < 2.4a
> +///
> +typedef struct {
> +  ///
> +  /// A unique number identifying the firmware image within the device.  The
> number is
> +  /// between 1 and DescriptorCount.
> +  ///
> +  UINT8ImageIndex;
> +  ///
> +  /// A unique number identifying the firmware image type.
> +  ///
> +  EFI_GUID ImageTypeId;
> +  ///
> +  /// A unique number identifying the firmware image.
> +  ///
> +  UINT64   ImageId;
> +  ///
> +  /// A pointer to a null-terminated string representing the firmware image
> name.
> +  ///
> +  CHAR16   *ImageIdName;
> +  ///
> +  /// Identifies the version of the device firmware. The format is vendor
> specific and new
> +  /// version must have a greater value than an old version.
> +  ///
> +  UINT32   Version;
> +  ///
> +  /// A pointer to a null-terminated string representing the firmware image
> version name.
> +  ///
> +  CHAR16   *VersionName;
> +  ///
> +  /// Size of the image in bytes.  If size=0, then only ImageIndex and
> ImageTypeId are valid.
> +  ///
> +  UINTNSize;
> +  ///
> +  /// Image attributes that are supported by this device.  See 'Image 
> Attribute
> Definitions'
> +  /// for possible returned values of this parameter.  A value of 1 indicates
> the attribute is
> +  /// supported and the current setting value is indicated in 
> AttributesSetting.
> A
> +  /// value of 0 indicates the attribute is not supported and the current
> setting value in
> +  /// AttributesSetting is meaningless.
> +  ///
> +  UINT64   AttributesSupported;
> +  ///
> +  /// Image attributes.  See 'Image Attribute Definitions' for possible 
> returned
> values of
> +  /// this parameter.
> +  ///
> +  UINT64   AttributesSetting;
> +  ///
> +  /// Image compatibilities.  See 'Image Compatibility Definitions' for 
> possible
> returned
> +  /// values of this parameter.
> +  ///
> +  UINT64   Compatibilities;
> +} EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1;
> +
> +
> +///
> +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec > 2.4a and < 2.5

What happens at UEFI Spec 2.5?

> +///
> +typedef struct {
> +  ///
> +  /// A unique number identifying the firmware image within the device.  The
> number is
> +  /// between 1 and DescriptorCount.
> +  ///
> +  UINT8ImageIndex;
> +  ///
> +  /// A unique number identifying the firmware image type.
> +  ///
> +  EFI_GUID ImageTypeId;
> +  ///
> +  /// A unique number identifying the firmware image.
> +  ///
> +  UINT64   ImageId;
> +  ///
> +  /// A pointer to a null-terminated string representing the firmware image
> name.
> +  ///
> +  CHAR16   *ImageIdName;
> +  ///
> +  /// Identifies the version 

[edk2] [PATCH 5/7] ArmPkg/ArmExceptionLib: make build time define visible to the compiler

[Ard Biesheuvel]

The global gArmRelocateVectorTable is a build time constant, but due to
its external linkage and lack of constness, the compiler does not see that.
So turn it into a static boolean, and at the same time, make the function
CopyExceptionHandlers() (which is only called if gArmRelocateVectorTable is
set) static as well, so that the compiler can eliminate it completely if
we are using the vector table in place.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c 
b/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c
index 5977a3e8fae1..0cf0766b9cbf 100644
--- a/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c
+++ b/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+STATIC
 RETURN_STATUS
 CopyExceptionHandlers(
   IN  PHYSICAL_ADDRESSBaseAddress
@@ -66,9 +67,9 @@ extern UINTNgDebuggerNoHandlerValue;
 // library we cannot represent this in a PCD since PCDs are evaluated on
 // a per-module basis.
 #if defined(ARM_RELOCATE_VECTORS)
-BOOLEAN gArmRelocateVectorTable = TRUE;
+STATIC CONST BOOLEAN gArmRelocateVectorTable = TRUE;
 #else
-BOOLEAN gArmRelocateVectorTable = FALSE;
+STATIC CONST BOOLEAN gArmRelocateVectorTable = FALSE;
 #endif
 
 
@@ -151,6 +152,7 @@ with default exception handlers.
 @retval EFI_UNSUPPORTED   This function is not supported.
 
 **/
+STATIC
 RETURN_STATUS
 CopyExceptionHandlers(
   IN  PHYSICAL_ADDRESSBaseAddress
-- 
2.5.0

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

[edk2] [PATCH v2 0/3] Adaptively set serial terminal polling rate

[Heyi Guo]

The serial terminal polling interval is now fixed by macro:

#define KEYBOARD_TIMER_INTERVAL 20  // 0.02s

However, this may cause fast input to be truncated on some platforms. For 
example, we have a serial console with below features:
1. Baud rate: 115200
2. FIFO depth of UART device: 32

If we want to capture all input, we need to poll with the interval of 32 / 
(115200 / (8 + 1 + 1)) = 2.8 ms, 8 + 1 + 1 for data bits + start bit + stop 
bit. Due to UEFI event potential delay, we will need even shorter polling 
interval than the ideal calculation result. 

These patches are to set serial terminal polling rate adaptively.

Heyi Guo (3):
  MdePkg: Add PCD for UART default receive FIFO depth
  MdeModulePkg/SerialDxe: Set FIFO depth with PCD
  MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

 .../Universal/Console/TerminalDxe/Terminal.c   |  5 +-
 .../Universal/Console/TerminalDxe/Terminal.h   | 27 -
 .../Universal/Console/TerminalDxe/TerminalConIn.c  | 68 ++
 MdeModulePkg/Universal/SerialDxe/SerialDxe.inf |  9 +--
 MdeModulePkg/Universal/SerialDxe/SerialIo.c|  3 +-
 MdePkg/MdePkg.dec  |  4 ++
 6 files changed, 109 insertions(+), 7 deletions(-)

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ruiyu Ni 
Cc: Feng Tian 
Cc: Star Zeng 
-- 
2.7.0

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

Re: [edk2] EDK2 Staging Proposal 3rd draft, final?

[Kinney, Michael D]

David,

Jordan asked a similar question about adding a 'staging' directory or 'staging'
branches to the edk2 repo.  If you look at the edk2 repo today, it has master 
and the supported UDK* branches.  In the transition from SVN -> GIT, the old 
tags
were removed and archived.

The reason for suggesting a new edk2-staging repo is to keep content that
is not ready for products to be clearly separated.  We do not want anyone
to pick up any of the staging content and put it into shipping FW images.

There was also a minor concern about the size of the edk2 repo, but it
was shown that this is not really an issue at this time.

So the choice here is a set of staging feature branches in the current 
edk2 repo with clear communication that none of them are product ready.  
Or a new edk2-staging repo with feature branches (current proposal).
 
I think a process to create/merge/remove feature branches in the 
tianocore.org repos is required because we really do not want too 
many branches.  If the feature being developed is smaller in 
scope, developer owned github branches or email PRs should be sufficient.

Thanks,

Mike


> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Wednesday, March 16, 2016 3:23 PM
> To: Kinney, Michael D ; Mangefeste, Tony
> ; edk2-devel@lists.01.org 
> Subject: Re: [edk2] EDK2 Staging Proposal 3rd draft, final?
> 
> On Wed, 2016-03-16 at 22:05 +, Kinney, Michael D wrote:
> >
> > I responded to an earlier email:
> 
> Ah, apologies — it wasn't clear this was intended as an answer to that
> question. This is one of those examples with the common email behaviour
> of placing the response below a carefully-selected citation would have
> helped a great deal, FWIW.
> 
> > I think there are several methods we can support for development.
> >
> > 1) Simple bug fixes/features sent directly to edk2-devel for PRs.
> > 2) A larger or more complex bug fix/feature can optionally post a link
> >    to a branch on personal github fork to help simplify the review process
> >    for those reviewers that prefer to use that method.  This type of bug
> >    fix or feature is usually owned by a single subject matter expert.
> > 3) A larger or more complex feature that requires design/dev/test by more
> >    than one subject matter expert.
> >
> > We already support (1) and (2) today.  Feature branches on edk2-staging are
> > intended for (3).
> 
> So the answer would be that it allows more than one person to
> collaborate on a submission? I'm not sure we need a whole new process
> document just for that, do we? It's not as if it's hard for people to
> share access to their repositories, or just pull from each other's.
> 
> ==
> 
> On Wed, 2016-03-16 at 15:15 -0700, Andrew Fish wrote:
> > I think David's point is any github repository can be used for this,
> > if I understand David's point?
> 
> Precisely so.
> 
> > So the only value to branches is an official place for them to live?
> > Thus a way they can be discovered.
> 
> Can't they already be discovered at
> https://github.com/tianocore/edk2/pulls ?
> 
> This is the normal workflow. People (individuals or otherwise) put
> together some work, discussion happens (and is archived and
> discoverable) in a pull request. New versions of the tree can be
> submitted to the PR at any time.
> 
> We don't need to invent anything new and different, just to allow more
> than one person to work together on a submission.
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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