Re: [edk2] [PATCH 3/3] MdeModulePkg/TerminalDxe: Handle more keys with TtyTerm

2016-10-14 Thread Roy Franz (HPE)
On Fri, Oct 7, 2016 at 7:54 AM, Brian J. Johnson  wrote:
> The TtyTerm terminal driver is missing support for sequences produced
> by the page up, page down, insert, home, and end keys in some terimnal
> emulators.  Add them.
>
> Tested under Ubuntu 16.04 using xterm 322-1ubuntu1, GNOME terminal
> 3.18.3-1ubuntu1, and XFCE terminal 0.6.3-2ubuntu1.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Kyle Roberts 
> Signed-off-by: Brian Johnson 
> Cc: Feng Tian 
> Cc: Star Zeng 
> ---
>  .../Universal/Console/TerminalDxe/TerminalConIn.c  | 24 
> +++---
>  1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c 
> b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
> index 3be877b..5c3ea86 100644
> --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
> @@ -3,6 +3,7 @@
>
>  (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
>  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +Copyright (C) 2016 Silicon Graphics, Inc. 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
> @@ -1374,7 +1375,7 @@ UnicodeToEfiKey (
>break;
>  }
>} else if (TerminalDevice->TerminalType == TTYTERMTYPE) {
> -/* Also accept VT100 escape codes for F1-F4 for TTY term */
> +/* Also accept VT100 escape codes for F1-F4, HOME and END for TTY 
> term */
>  switch (UnicodeChar) {
>  case 'P':
>Key.ScanCode = SCAN_F1;
> @@ -1388,6 +1389,12 @@ UnicodeToEfiKey (
>  case 'S':
>Key.ScanCode = SCAN_F4;
>break;
> +case 'H':
> +  Key.ScanCode = SCAN_HOME;
> +  break;
> +case 'F':
> +  Key.ScanCode = SCAN_END;
> +  break;
>  }
>}
>
> @@ -1429,12 +1436,14 @@ UnicodeToEfiKey (
>break;
>  case 'H':
>if (TerminalDevice->TerminalType == PCANSITYPE ||
> -  TerminalDevice->TerminalType == VT100TYPE) {
> +  TerminalDevice->TerminalType == VT100TYPE  ||
> +  TerminalDevice->TerminalType == TTYTERMTYPE) {
>  Key.ScanCode = SCAN_HOME;
>}
>break;
>  case 'F':
> -  if (TerminalDevice->TerminalType == PCANSITYPE) {
> +  if (TerminalDevice->TerminalType == PCANSITYPE ||
> +  TerminalDevice->TerminalType == TTYTERMTYPE) {
>  Key.ScanCode = SCAN_END;
>}
>break;
> @@ -1573,9 +1582,18 @@ UnicodeToEfiKey (
>TerminalDevice->TtyEscapeStr[TerminalDevice->TtyEscapeIndex] = 0; 
> /* Terminate string */
>EscCode = (UINT16) StrDecimalToUintn(TerminalDevice->TtyEscapeStr);
>switch (EscCode) {
> +  case 2:
> +  Key.ScanCode = SCAN_INSERT;
> +  break;
>case 3:
>Key.ScanCode = SCAN_DELETE;
>break;
> +  case 5:
> +  Key.ScanCode = SCAN_PAGE_UP;
> +  break;
> +  case 6:
> +  Key.ScanCode = SCAN_PAGE_DOWN;
> +  break;
>case 11:
>case 12:
>case 13:
> --
> 2.7.4
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


Reviewed-by:  Roy Franz 

This patch looks good to me - I'm not enough of a terminal expert to
review patches 1/2.

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


Re: [edk2] [PATCH 0/3] MdeModulePkg/TerminalDxe: TtyTerm improvements

2016-10-14 Thread Laszlo Ersek
On 10/14/16 21:39, Brian J. Johnson wrote:
> On 10/12/2016 03:17 AM, Ryan Harkin wrote:
>> On 7 October 2016 at 16:59, Leif Lindholm 
>> wrote:
>>> Roy can now be found at Roy Franz  (cc:d).
>>>
>>> On Fri, Oct 07, 2016 at 05:56:26PM +0200, Laszlo Ersek wrote:
 Roy, Ryan,

 On 10/07/16 16:53, Brian J. Johnson wrote:
> This patch series implements some improvements to the TtyTerm terminal
> type in the TerminalDxe driver.  It fixes an end case with cursor
> position tracking, and uses that to optimize cursor motion escape
> sequences.  It also adds support for the page up, page down, insert,
> home, and end keys on some additional common terminal emulators.
>
> The result is improved performance, especially at the shell prompt,
> and better compatibility with common terminal emulators.  In
> particular, as a side effect of the optimized cursor motion, terminal
> windows which are taller than the current mode setting (eg. 25 lines)
> work much better than before.
>
> Most of these fixes have been in production in some form on SGI's
> servers for years.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brian Johnson 
> Cc: Feng Tian 
> Cc: Star Zeng 
>
> Brian J. Johnson (3):
>   MdeModulePkg/TerminalDxe: Improve TtyTerm cursor position tracking
>   MdeModulePkg/TerminalDxe: Optimize TtyTerm cursor motion
>   MdeModulePkg/TerminalDxe: Handle more keys with TtyTerm
>
>  .../Universal/Console/TerminalDxe/Terminal.h   |  2 +
>  .../Universal/Console/TerminalDxe/TerminalConIn.c  | 24 +++--
>  .../Universal/Console/TerminalDxe/TerminalConOut.c | 61
> --
>  3 files changed, 79 insertions(+), 8 deletions(-)
>

 can you please provide feedback (testing or otherwise) on this series?

>>
>> Well, they "work" for me and I'd be happy with them being submitted.
>>
>> Tested-by: Ryan Harkin 
>>
>> The only curious effect I can see is the Print(L"xxx"); lines that
>> expect the \n to be missing will no longer "work".  For example, I
>> carry a patch by Daniil Egranov titled
>> "IntelFrameworkModulePkg/BdsDxe: Show boot timeout message" and it no
>> longer displays the countdown on the same line each time, it prints
>> each message on a new line.
>>
>> However, I don't see that as a blocking point, Daniil's patch could be
>> changed easily and there are other advantages to this series that make
>> it worthwhile, IMO, eg, Shell commands with lots of output (like
>> "help" or "dir fs0:") no longer create an awful mess on the serial
>> console.
>>
> 
> So, is this just waiting for a maintainer's review?

That's my understanding, yes.

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


Re: [edk2] [PATCH 3/5] ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg

2016-10-14 Thread Leif Lindholm
Much as I would like to kill off the LinuxLoader, I can't just yet,
and like Tim I approve of the core change.

Reviewed-by: Leif Lindholm 

On Fri, Oct 14, 2016 at 05:44:29PM +0800, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> ---
>  ArmPkg/Application/LinuxLoader/LinuxLoader.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ArmPkg/Application/LinuxLoader/LinuxLoader.h 
> b/ArmPkg/Application/LinuxLoader/LinuxLoader.h
> index 8a23d7f..0d18c24 100644
> --- a/ArmPkg/Application/LinuxLoader/LinuxLoader.h
> +++ b/ArmPkg/Application/LinuxLoader/LinuxLoader.h
> @@ -25,8 +25,8 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
> +#include 
> +#include 
>  
>  #include 
>  
> -- 
> 2.9.0.windows.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/3] MdeModulePkg/TerminalDxe: TtyTerm improvements

2016-10-14 Thread Brian J. Johnson

On 10/12/2016 03:17 AM, Ryan Harkin wrote:

On 7 October 2016 at 16:59, Leif Lindholm  wrote:

Roy can now be found at Roy Franz  (cc:d).

On Fri, Oct 07, 2016 at 05:56:26PM +0200, Laszlo Ersek wrote:

Roy, Ryan,

On 10/07/16 16:53, Brian J. Johnson wrote:

This patch series implements some improvements to the TtyTerm terminal
type in the TerminalDxe driver.  It fixes an end case with cursor
position tracking, and uses that to optimize cursor motion escape
sequences.  It also adds support for the page up, page down, insert,
home, and end keys on some additional common terminal emulators.

The result is improved performance, especially at the shell prompt,
and better compatibility with common terminal emulators.  In
particular, as a side effect of the optimized cursor motion, terminal
windows which are taller than the current mode setting (eg. 25 lines)
work much better than before.

Most of these fixes have been in production in some form on SGI's
servers for years.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brian Johnson 
Cc: Feng Tian 
Cc: Star Zeng 

Brian J. Johnson (3):
  MdeModulePkg/TerminalDxe: Improve TtyTerm cursor position tracking
  MdeModulePkg/TerminalDxe: Optimize TtyTerm cursor motion
  MdeModulePkg/TerminalDxe: Handle more keys with TtyTerm

 .../Universal/Console/TerminalDxe/Terminal.h   |  2 +
 .../Universal/Console/TerminalDxe/TerminalConIn.c  | 24 +++--
 .../Universal/Console/TerminalDxe/TerminalConOut.c | 61 --
 3 files changed, 79 insertions(+), 8 deletions(-)



can you please provide feedback (testing or otherwise) on this series?



Well, they "work" for me and I'd be happy with them being submitted.

Tested-by: Ryan Harkin 

The only curious effect I can see is the Print(L"xxx"); lines that
expect the \n to be missing will no longer "work".  For example, I
carry a patch by Daniil Egranov titled
"IntelFrameworkModulePkg/BdsDxe: Show boot timeout message" and it no
longer displays the countdown on the same line each time, it prints
each message on a new line.

However, I don't see that as a blocking point, Daniil's patch could be
changed easily and there are other advantages to this series that make
it worthwhile, IMO, eg, Shell commands with lots of output (like
"help" or "dir fs0:") no longer create an awful mess on the serial
console.



So, is this just waiting for a maintainer's review?
--

Brian J. Johnson



  My statements are my own, are not authorized by SGI, and do not
  necessarily represent SGI’s positions.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 1/5] ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h

2016-10-14 Thread Tim Lewis
Glad to see this is finally being done!

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Friday, October 14, 2016 2:44 AM
To: edk2-devel@lists.01.org
Cc: Jaben Carsey ; Michael D Kinney 
; Jiewen Yao 
Subject: [edk2] [PATCH 1/5] ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h 
to ShellLib.h

The more proper place for macro SHELL_FREE_NON_NULL is ShellLib.h instead of 
ShellBase.h.

Modify Compress.c to resolve build failure due to this change.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
Cc: Jiewen Yao 
Cc: Michael D Kinney 
---
 ShellPkg/Include/Library/ShellLib.h| 10 +-
 ShellPkg/Include/ShellBase.h   | 10 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c |  8 
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index fe4b9cf..fafa041 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to shell functionality for shell commands and 
applications.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 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 @@ -24,6 +24,14 @@  #include   #include 

 
+#define SHELL_FREE_NON_NULL(Pointer)  \
+  do {\
+if ((Pointer) != NULL) {  \
+  FreePool((Pointer));\
+  (Pointer) = NULL;   \
+} \
+  } while(FALSE)
+
 // (20 * (6+5+2))+1) unicode characters from EFI FAT spec (doubled for bytes)  
#define MAX_FILE_NAME_LEN 512
 
diff --git a/ShellPkg/Include/ShellBase.h b/ShellPkg/Include/ShellBase.h index 
09f87b4..4b7a3d1 100644
--- a/ShellPkg/Include/ShellBase.h
+++ b/ShellPkg/Include/ShellBase.h
@@ -1,7 +1,7 @@
 /** @file
   Root include file for Shell Package modules that utilize the SHELL_RETURN 
type
 
-  Copyright (c) 2009 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 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 @@ -17,14 +17,6 @@
 
 typedef VOID *SHELL_FILE_HANDLE;
 
-#define SHELL_FREE_NON_NULL(Pointer)  \
-  do {\
-if ((Pointer) != NULL) {  \
-  FreePool((Pointer));\
-  (Pointer) = NULL;   \
-} \
-  } while(FALSE)
-
 typedef enum {
 ///
 /// The operation completed successfully.
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
index dda2fed..da8e647 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
@@ -7,7 +7,7 @@
   This sequence is further divided into Blocks and Huffman codings
   are applied to each Block.
 
-  Copyright (c) 2007 - 2014, 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 @@ -17,12 +17,12 @@
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 **/
-
+#include 
+#include 
 #include   #include   
#include  -#include  -#include 
+#include 
 
 //
 // Macro Definitions
--
2.9.0.windows.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 0/5] Move Shell protocol definitions to MdePkg

2016-10-14 Thread Tim Lewis
I prefer the renamed .h file, even though I have substantial investment in the 
current infrastructure.

Why? Because engineers don't have time to remember "how does protocol X 
translate to header file Y" It should be a consistent rule. How many times have 
I needed to grep the header file name just because I got a build error because 
the rule wasn't predictable.

1) remove the EFI_ prefix and the _PROTOCOL  suffix (EFI_BLOCK_IO_PROTOCOL -> 
BLOCK_IO
2) Convert to upper-and-lower case, BLOCK_IO -> Block_Io 
3) Remove the _ (Block_Io -> BlockIo)
4)  add a .h BlockIo -> BlockIo.h

Most protocol and PPI header files already follow this rule. The current header 
files for shell are among the few exceptions, because they don't follow this.

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, October 14, 2016 6:14 AM
To: Yao, Jiewen ; Ni, Ruiyu ; 
edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

Or if you really think we should give a better name.

My recommendation is:

1)  We add content in MdePkg.

2)  We can keep the old protocol file in ShellPkg, but let .h in shellPkg 
include the .h in MdePkg.

Then we can avoid duplicated code and make it a compatible solution to avoid 
other module update.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, October 14, 2016 9:09 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

Hi
I think the requests is just to *move*.

There is no request to *rename*.

Can we just move to avoid other update?


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Ruiyu Ni
> Sent: Friday, October 14, 2016 5:44 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg
>
> The patches moves Shell spec defined protocol definitions to MdePkg 
> and updates all references.
> Content of ShellBase.h is moved to Protocol/Shell.h and ShellBase.h is 
> removed.
>
> Ruiyu Ni (5):
>   ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h
>   MdePkg: Include Shell/ShellDynamicCommand/ShellParameters
> definitions
>   ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg
>   EmbeddedPkg/FdtPlatformDxe: Reference Shell protocols in MdePkg
>   ShellPkg: Remove Shell/ShellDynamicCommand/ShellParameter
> definitions
>
>  ArmPkg/Application/LinuxLoader/LinuxLoader.h   |   4 +-
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h   |   4 +-
>  .../EfiShell.h => MdePkg/Include/Protocol/Shell.h  | 134
> +-
>  .../Include/Protocol/ShellDynamicCommand.h |   7 +-
>  .../Include/Protocol/ShellParameters.h |   4 +-
>  MdePkg/MdePkg.dec  |  15 ++
>  ShellPkg/Application/Shell/Shell.h |   5 +-
>  ShellPkg/Include/Library/ShellCommandLib.h |   5 +-
>  ShellPkg/Include/Library/ShellLib.h|  14 +-
>  ShellPkg/Include/ShellBase.h   | 157
> -
>  ShellPkg/Library/UefiDpLib/Dp.h|   3 +-
>  ShellPkg/Library/UefiDpLib/UefiDpLib.h |   7 +-
>  .../UefiHandleParsingLib/UefiHandleParsingLib.h|   8 +-
>  .../UefiShellBcfgCommandLib.c  |   5 +-
>  .../UefiShellCEntryLib/UefiShellCEntryLib.c|   6 +-
>  .../UefiShellCommandLib/UefiShellCommandLib.h  |   7 +-
>  .../Library/UefiShellDebug1CommandsLib/Compress.c  |   7 +-
>  .../UefiShellDebug1CommandsLib.h   |   7 +-
>  .../UefiShellDriver1CommandsLib.h  |   7 +-
>  .../UefiShellLevel1CommandsLib.h   |   7 +-
>  .../UefiShellLevel2CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c |   2 +-
>  .../UefiShellLevel3CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c   |   1 -
>  ShellPkg/Library/UefiShellLib/UefiShellLib.h   |   6 +-
>  .../UefiShellNetwork1CommandsLib.h |   3 +-
>  .../UefiShellTftpCommandLib.h  |   3 +-
>  ShellPkg/ShellPkg.dec  |   3 -
>  ShellPkg/ShellPkg.dsc  |   2 +
>  29 files changed, 213 insertions(+), 234 deletions(-)  rename 
> ShellPkg/Include/Protocol/EfiShell.h => 
> MdePkg/Include/Protocol/Shell.h (92%)  rename 
> ShellPkg/Include/Protocol/EfiShellDynamicCommand.h => 
> MdePkg/Include/Protocol/ShellDynamicCommand.h (92%)  rename 
> ShellPkg/Include/Protocol/EfiShellParameters.h => 
> MdePkg/Include/Protocol/ShellParameters.h (92%)  delete mode 100644 
> ShellPkg/Include/ShellBase.h
>
> --
> 2.9.0.windows.1
>
> 

Re: [edk2] [RFC V2] EDK2 Platform Proposal

2016-10-14 Thread Kinney, Michael D
Leif,

That makes sense to me.  I will update the Readme.md to cover
The edk2-platforms/master branch.

If a platform does not want to be maintained on master any 
longer, it could be moved to a stable-* branch against the most 
recent UDK20xx branch of edk2.

Once a platform is no longer used or maintained at all, then 
archiving sounds appropriate.

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Friday, October 14, 2016 5:59 AM
> To: Kinney, Michael D 
> Cc: Andrew Fish (af...@apple.com) ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC V2] EDK2 Platform Proposal
> 
> So, I don't actually disagree with what you're saying, but I think we
> already know that we are looking for different things out of this
> repository :)
> 
> This is not a problem, but I do want us to be able to agree on a
> wording that works for both of our use-cases.
> 
> I currently have no interest in the stable-* branches, but I
> completely understand why you need them.
> 
> I want _lots_ of platforms in master, but I want all of the platforms
> in master to be ones that have an active maintainer - and as such will
> be fixed up as required when core changes happen. To me, master should
> be drinking from the fire hose. But any platforms in master that are
> not being kept functional should be moved out and archived.
> 
> If we cannot agree on the meaning of master, then I would request
> another specific branch to fill the function I describe above.
> 
> Regards,
> 
> Leif
> 
> On Fri, Oct 14, 2016 at 07:25:19AM +, Kinney, Michael D wrote:
> > Leif,
> >
> > I could see edk2-platforms/master being the platform branch that
> > contains the set of platforms that are synced with edk2/master and
> > are required to be tested when changes are made to edk2/master.
> > Or at least guaranteed to be tested when a stable release of
> > edk2/master is made.
> >
> > Similar to what we expect for the platforms in edk2/master such
> > as OvmfPkg, EmulatorPkg, and Nt32Pkg.
> >
> > Given that not everyone would have access to platform targets to
> > run tests, the minimum requirement could be build tests.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Friday, October 14, 2016 12:15 AM
> > > To: Leif Lindholm ; Andrew Fish 
> > > (af...@apple.com)
> > > ; Kinney, Michael D 
> > > Cc: edk2-devel@lists.01.org
> > > Subject: RE: [edk2] [RFC V2] EDK2 Platform Proposal
> > >
> > > Leif and Andrew,
> > >
> > > I have added the content of this proposal to a new Readme.md file in
> > > the edk2-platforms/about branch and removed the old README file.
> > >
> > >   https://github.com/tianocore/edk2-platforms/tree/about
> > >
> > > I have also added a template at the bottom of the process description
> > > for a Readme.md that describes multiple platforms with links to a
> > > Readme.md in each platform specific subdirectory.
> > >
> > > I have also addressed the all the feedback from Leif except for
> > > adding platforms to edk2-platforms/master.  I think platforms
> > > should start in an edk2-platforms/devel-* branch and when they
> > > become stable move to an edk2-platforms/stable-* branch.  Stable
> > > branches may support multiple platform.
> > >
> > > Using this model, there would not be an edk2-platforms/master
> > > branch.
> > >
> > > Mike
> > >
> > >
> > > > -Original Message-
> > > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > > Sent: Wednesday, September 28, 2016 3:23 PM
> > > > To: Kinney, Michael D 
> > > > Cc: edk2-devel@lists.01.org
> > > > Subject: Re: [edk2] [RFC V2] EDK2 Platform Proposal
> > > >
> > > > Hi Mike,
> > > >
> > > > On Thu, Sep 22, 2016 at 08:54:50PM +, Kinney, Michael D wrote:
> > > > > Hello,
> > > > >
> > > > >
> > > > >
> > > > > Here is the V2 version of the proposal for the edk2-platforms repo.
> > > >
> > > > I'm happy with the proposal in this state, but have a few suggested
> > > > updates (mostly to clarify that, long term, we expect most platforms
> > > > to exist in master) and a small suggested addition.
> > > >
> > > > > Changes from V1:
> > > > >
> > > > > 
> > > > >
> > > > > * edk2-platform is not a fork of edk2.
> > > > >
> > > > > * edk2-platforms branches contain CPU, Chipset, SoC, and platform 
> > > > > specific
> > > > >
> > > > >   packages
> > > > >
> > > > > * edk2-plaforms/master contains all open platforms that are synced 
> > > > > with
> > > > >
> > > > >   edk2/master.
> > > > >
> > > > > * Each edk2-platforms branch may support many platforms (not just one)
> > > > >
> > > > > * Use PACKAGES_PATH to do builds using packages from multiple 
> > > > > repositories
> > > > >
> > > > > * Update edk2-platforms branch naming to clearly identify platforms 
> > > > > that
> > > > >
> > > > >   are considered stable 

Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

2016-10-14 Thread Laszlo Ersek
On 10/14/16 15:17, Bhupesh Sharma wrote:
> Hi Laszlo,
> 
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Friday, October 14, 2016 5:37 PM
>>
>> On 10/14/16 11:33, Bhupesh Sharma wrote:
>>> Various IPs on NXP/FSL SoCs having ARM64 cores have big-endian MMIO
>>> interfaces.
>>>
>>> This implies that a byte-swap operation is needed to read/write such
>>> BE MMIO registers from the LE ARM64 cores.
>>>
>>> This patch adds the support for the same.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Meenakshi Aggarwal 
>>> Signed-off-by: Bhupesh Sharma 
>>> ---
>>>  MdePkg/Include/Library/IoLib.h   | 364
>> 
>>>  MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c | 479
>>> +++
>>>  2 files changed, 843 insertions(+)
>>
>> I think this is both overkill and incomplete, at the same time :)
>>
>> - Incomplete because only one IoLib instance gets the implementation.
> 
> Agree, but do we have an example of similar BE MMIO IPs on other
> Architectures/soc? I was only aware of NXP/FSL having such MMIO
> interfaces as the IPs have been reused from PPC SoC, which used
> to have a BE core and hence did not require a SwapByte.

For example, the fw_cfg device of QEMU is big endian. OvmfPkg and
ArmVirtPkg call SwapBytesXX as necessary, in combination with MmioWriteXX.

In general, I think it's expected that a library declared under MdePkg
will not cause build failures (unresolved symbols) in any platform code,
once the library is resolved correctly in the platform DSC.

>  
>> - Overkill because you can easily use the SwapBytes16, SwapBytes32,
>> SwapBytes64 functions -- also from BaseLib --, for transforming
>> MmioWrite arguments and MmioRead results.
>>
> 
> Yes, but that means at every IP driver needs to especially carry such
> arguments and transform the results.

Indeed.

> That might be an overkill.

I think it should be possible to factor out these functions to a
separate library, or non-standard protocol, that is central enough for
the platform or device in question, but not core enough for putting into
MdePkg.

> We already have similar implementations MMIO implementations in Linux for e.g.
> http://lxr.free-electrons.com/source/include/asm-generic/io.h#L642

Hmmm. That does detract from the value of my "overkill" argument. So I
guess I'll have to defer to the MdePkg maintainers on that.

Regarding my "incomplete" argument, it still stands. I think it's
logically impossible to introduce a library class that is simultaneously
- central enough to merit a place under MdePkg, but
- not central enough to receive implementations (library instances) for
all the platforms supported by edk2 at the moment.

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


Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

2016-10-14 Thread Bhupesh Sharma
Hi Laszlo,

> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, October 14, 2016 5:37 PM
> 
> On 10/14/16 11:33, Bhupesh Sharma wrote:
> > Various IPs on NXP/FSL SoCs having ARM64 cores have big-endian MMIO
> > interfaces.
> >
> > This implies that a byte-swap operation is needed to read/write such
> > BE MMIO registers from the LE ARM64 cores.
> >
> > This patch adds the support for the same.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Meenakshi Aggarwal 
> > Signed-off-by: Bhupesh Sharma 
> > ---
> >  MdePkg/Include/Library/IoLib.h   | 364
> 
> >  MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c | 479
> > +++
> >  2 files changed, 843 insertions(+)
> 
> I think this is both overkill and incomplete, at the same time :)
> 
> - Incomplete because only one IoLib instance gets the implementation.

Agree, but do we have an example of similar BE MMIO IPs on other
Architectures/soc? I was only aware of NXP/FSL having such MMIO
interfaces as the IPs have been reused from PPC SoC, which used
to have a BE core and hence did not require a SwapByte.
 
> - Overkill because you can easily use the SwapBytes16, SwapBytes32,
> SwapBytes64 functions -- also from BaseLib --, for transforming
> MmioWrite arguments and MmioRead results.
> 

Yes, but that means at every IP driver needs to especially carry such
arguments and transform the results. That might be an overkill.

We already have similar implementations MMIO implementations in Linux for e.g.
http://lxr.free-electrons.com/source/include/asm-generic/io.h#L642

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


Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

2016-10-14 Thread Yao, Jiewen
Or if you really think we should give a better name.

My recommendation is:

1)  We add content in MdePkg.

2)  We can keep the old protocol file in ShellPkg, but let .h in shellPkg 
include the .h in MdePkg.

Then we can avoid duplicated code and make it a compatible solution to avoid 
other module update.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Friday, October 14, 2016 9:09 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

Hi
I think the requests is just to *move*.

There is no request to *rename*.

Can we just move to avoid other update?


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Friday, October 14, 2016 5:44 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg
>
> The patches moves Shell spec defined protocol definitions to
> MdePkg and updates all references.
> Content of ShellBase.h is moved to Protocol/Shell.h and
> ShellBase.h is removed.
>
> Ruiyu Ni (5):
>   ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h
>   MdePkg: Include Shell/ShellDynamicCommand/ShellParameters
> definitions
>   ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg
>   EmbeddedPkg/FdtPlatformDxe: Reference Shell protocols in MdePkg
>   ShellPkg: Remove Shell/ShellDynamicCommand/ShellParameter
> definitions
>
>  ArmPkg/Application/LinuxLoader/LinuxLoader.h   |   4 +-
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h   |   4 +-
>  .../EfiShell.h => MdePkg/Include/Protocol/Shell.h  | 134
> +-
>  .../Include/Protocol/ShellDynamicCommand.h |   7 +-
>  .../Include/Protocol/ShellParameters.h |   4 +-
>  MdePkg/MdePkg.dec  |  15 ++
>  ShellPkg/Application/Shell/Shell.h |   5 +-
>  ShellPkg/Include/Library/ShellCommandLib.h |   5 +-
>  ShellPkg/Include/Library/ShellLib.h|  14 +-
>  ShellPkg/Include/ShellBase.h   | 157
> -
>  ShellPkg/Library/UefiDpLib/Dp.h|   3 +-
>  ShellPkg/Library/UefiDpLib/UefiDpLib.h |   7 +-
>  .../UefiHandleParsingLib/UefiHandleParsingLib.h|   8 +-
>  .../UefiShellBcfgCommandLib.c  |   5 +-
>  .../UefiShellCEntryLib/UefiShellCEntryLib.c|   6 +-
>  .../UefiShellCommandLib/UefiShellCommandLib.h  |   7 +-
>  .../Library/UefiShellDebug1CommandsLib/Compress.c  |   7 +-
>  .../UefiShellDebug1CommandsLib.h   |   7 +-
>  .../UefiShellDriver1CommandsLib.h  |   7 +-
>  .../UefiShellLevel1CommandsLib.h   |   7 +-
>  .../UefiShellLevel2CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c |   2 +-
>  .../UefiShellLevel3CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c   |   1 -
>  ShellPkg/Library/UefiShellLib/UefiShellLib.h   |   6 +-
>  .../UefiShellNetwork1CommandsLib.h |   3 +-
>  .../UefiShellTftpCommandLib.h  |   3 +-
>  ShellPkg/ShellPkg.dec  |   3 -
>  ShellPkg/ShellPkg.dsc  |   2 +
>  29 files changed, 213 insertions(+), 234 deletions(-)
>  rename ShellPkg/Include/Protocol/EfiShell.h =>
> MdePkg/Include/Protocol/Shell.h (92%)
>  rename ShellPkg/Include/Protocol/EfiShellDynamicCommand.h =>
> MdePkg/Include/Protocol/ShellDynamicCommand.h (92%)
>  rename ShellPkg/Include/Protocol/EfiShellParameters.h =>
> MdePkg/Include/Protocol/ShellParameters.h (92%)
>  delete mode 100644 ShellPkg/Include/ShellBase.h
>
> --
> 2.9.0.windows.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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch] BaseTools: Update sign tool to make MonotonicCount *after* Payload

2016-10-14 Thread Yao, Jiewen
Reviewed-by: jiewen@intel.com
Tested-by: jiewen@intel.com


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Friday, October 14, 2016 8:57 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming
> 
> Subject: [edk2] [Patch] BaseTools: Update sign tool to make
> MonotonicCount *after* Payload
> 
> The WIN_CERTIFICATE_UEFI_GUID AuthInfo defined in the UEFI spec
> mentioned that It is a signature across the image data and the
> Monotonic Count value. After clarification, we do the signature
> calculation, we put MonotonicCount after Payload.
> 
> Cc: Liming Gao 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py | 8
> 
>  BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py | 8
> 
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
> b/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
> index b9f8c06..f0b2d8a 100644
> --- a/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
> +++ b/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
> @@ -195,12 +195,12 @@ if __name__ == '__main__':
>  args.OtherPublicCertFile.close()
>except:
>  print 'ERROR: test other public cert file %s missing' %
> (args.OtherPublicCertFileName)
>  sys.exit(1)
> 
> -format = "Q%ds" % len(args.InputFileBuffer)
> -FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue,
> args.InputFileBuffer)
> +format = "%dsQ" % len(args.InputFileBuffer)
> +FullInputFileBuffer = struct.pack(format, args.InputFileBuffer,
> args.MonotonicCountValue)
> 
>  #
>  # Sign the input file using the specified private key and capture
> signature from STDOUT
>  #
>  Process = subprocess.Popen('%s smime -sign -binary -signer "%s"
> -outform DER -md sha256 -certfile "%s"' % (OpenSslCommand,
> args.SignerPrivateCertFileName, args.OtherPublicCertFileName),
> stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
> @@ -259,12 +259,12 @@ if __name__ == '__main__':
>  sys.exit(1)
> 
>  args.SignatureBuffer = args.InputFileBuffer[0:SignatureSize]
>  args.InputFileBuffer = args.InputFileBuffer[SignatureSize:]
> 
> -format = "Q%ds" % len(args.InputFileBuffer)
> -FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue,
> args.InputFileBuffer)
> +format = "%dsQ" % len(args.InputFileBuffer)
> +FullInputFileBuffer = struct.pack(format, args.InputFileBuffer,
> args.MonotonicCountValue)
> 
>  #
>  # Save output file contents from input file
>  #
>  open(args.OutputFileName, 'wb').write(FullInputFileBuffer)
> diff --git
> a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
> b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
> index 3410668..199ebec 100644
> --- a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
> +++ b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
> @@ -167,12 +167,12 @@ if __name__ == '__main__':
>  pass
> 
>if args.Encode:
>  FullInputFileBuffer = args.InputFileBuffer
>  if args.MonotonicCountStr:
> -  format = "Q%ds" % len(args.InputFileBuffer)
> -  FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue,
> args.InputFileBuffer)
> +  format = "%dsQ" % len(args.InputFileBuffer)
> +  FullInputFileBuffer = struct.pack(format, args.InputFileBuffer,
> args.MonotonicCountValue)
>  #
>  # Sign the input file using the specified private key and capture
> signature from STDOUT
>  #
>  Process = subprocess.Popen('%s sha256 -sign "%s"' %
> (OpenSslCommand, args.PrivateKeyFileName), stdin=subprocess.PIPE,
> stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>  Signature = Process.communicate(input=FullInputFileBuffer)[0]
> @@ -210,12 +210,12 @@ if __name__ == '__main__':
>print 'ERROR: Public key in input file does not match public key from
> private key file'
>sys.exit(1)
> 
>  FullInputFileBuffer = args.InputFileBuffer
>  if args.MonotonicCountStr:
> -  format = "Q%ds" % len(args.InputFileBuffer)
> -  FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue,
> args.InputFileBuffer)
> +  format = "%dsQ" % len(args.InputFileBuffer)
> +  FullInputFileBuffer = struct.pack(format, args.InputFileBuffer,
> args.MonotonicCountValue)
> 
>  #
>  # Write Signature to output file
>  #
>  open(args.OutputFileName, 'wb').write(Header.Signature)
> --
> 2.6.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

2016-10-14 Thread Yao, Jiewen
Hi
I think the requests is just to *move*.

There is no request to *rename*.

Can we just move to avoid other update?


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Friday, October 14, 2016 5:44 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg
>
> The patches moves Shell spec defined protocol definitions to
> MdePkg and updates all references.
> Content of ShellBase.h is moved to Protocol/Shell.h and
> ShellBase.h is removed.
>
> Ruiyu Ni (5):
>   ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h
>   MdePkg: Include Shell/ShellDynamicCommand/ShellParameters
> definitions
>   ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg
>   EmbeddedPkg/FdtPlatformDxe: Reference Shell protocols in MdePkg
>   ShellPkg: Remove Shell/ShellDynamicCommand/ShellParameter
> definitions
>
>  ArmPkg/Application/LinuxLoader/LinuxLoader.h   |   4 +-
>  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h   |   4 +-
>  .../EfiShell.h => MdePkg/Include/Protocol/Shell.h  | 134
> +-
>  .../Include/Protocol/ShellDynamicCommand.h |   7 +-
>  .../Include/Protocol/ShellParameters.h |   4 +-
>  MdePkg/MdePkg.dec  |  15 ++
>  ShellPkg/Application/Shell/Shell.h |   5 +-
>  ShellPkg/Include/Library/ShellCommandLib.h |   5 +-
>  ShellPkg/Include/Library/ShellLib.h|  14 +-
>  ShellPkg/Include/ShellBase.h   | 157
> -
>  ShellPkg/Library/UefiDpLib/Dp.h|   3 +-
>  ShellPkg/Library/UefiDpLib/UefiDpLib.h |   7 +-
>  .../UefiHandleParsingLib/UefiHandleParsingLib.h|   8 +-
>  .../UefiShellBcfgCommandLib.c  |   5 +-
>  .../UefiShellCEntryLib/UefiShellCEntryLib.c|   6 +-
>  .../UefiShellCommandLib/UefiShellCommandLib.h  |   7 +-
>  .../Library/UefiShellDebug1CommandsLib/Compress.c  |   7 +-
>  .../UefiShellDebug1CommandsLib.h   |   7 +-
>  .../UefiShellDriver1CommandsLib.h  |   7 +-
>  .../UefiShellLevel1CommandsLib.h   |   7 +-
>  .../UefiShellLevel2CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c |   2 +-
>  .../UefiShellLevel3CommandsLib.h   |   7 +-
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c   |   1 -
>  ShellPkg/Library/UefiShellLib/UefiShellLib.h   |   6 +-
>  .../UefiShellNetwork1CommandsLib.h |   3 +-
>  .../UefiShellTftpCommandLib.h  |   3 +-
>  ShellPkg/ShellPkg.dec  |   3 -
>  ShellPkg/ShellPkg.dsc  |   2 +
>  29 files changed, 213 insertions(+), 234 deletions(-)
>  rename ShellPkg/Include/Protocol/EfiShell.h =>
> MdePkg/Include/Protocol/Shell.h (92%)
>  rename ShellPkg/Include/Protocol/EfiShellDynamicCommand.h =>
> MdePkg/Include/Protocol/ShellDynamicCommand.h (92%)
>  rename ShellPkg/Include/Protocol/EfiShellParameters.h =>
> MdePkg/Include/Protocol/ShellParameters.h (92%)
>  delete mode 100644 ShellPkg/Include/ShellBase.h
>
> --
> 2.9.0.windows.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] [RFC V2] EDK2 Platform Proposal

2016-10-14 Thread Leif Lindholm
So, I don't actually disagree with what you're saying, but I think we
already know that we are looking for different things out of this
repository :)

This is not a problem, but I do want us to be able to agree on a
wording that works for both of our use-cases.

I currently have no interest in the stable-* branches, but I
completely understand why you need them.

I want _lots_ of platforms in master, but I want all of the platforms
in master to be ones that have an active maintainer - and as such will
be fixed up as required when core changes happen. To me, master should
be drinking from the fire hose. But any platforms in master that are
not being kept functional should be moved out and archived.

If we cannot agree on the meaning of master, then I would request
another specific branch to fill the function I describe above.

Regards,

Leif

On Fri, Oct 14, 2016 at 07:25:19AM +, Kinney, Michael D wrote:
> Leif,
> 
> I could see edk2-platforms/master being the platform branch that
> contains the set of platforms that are synced with edk2/master and
> are required to be tested when changes are made to edk2/master.
> Or at least guaranteed to be tested when a stable release of 
> edk2/master is made.
> 
> Similar to what we expect for the platforms in edk2/master such
> as OvmfPkg, EmulatorPkg, and Nt32Pkg.
> 
> Given that not everyone would have access to platform targets to 
> run tests, the minimum requirement could be build tests.
> 
> Mike
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Friday, October 14, 2016 12:15 AM
> > To: Leif Lindholm ; Andrew Fish (af...@apple.com)
> > ; Kinney, Michael D 
> > Cc: edk2-devel@lists.01.org
> > Subject: RE: [edk2] [RFC V2] EDK2 Platform Proposal
> > 
> > Leif and Andrew,
> > 
> > I have added the content of this proposal to a new Readme.md file in
> > the edk2-platforms/about branch and removed the old README file.
> > 
> >   https://github.com/tianocore/edk2-platforms/tree/about
> > 
> > I have also added a template at the bottom of the process description
> > for a Readme.md that describes multiple platforms with links to a
> > Readme.md in each platform specific subdirectory.
> > 
> > I have also addressed the all the feedback from Leif except for
> > adding platforms to edk2-platforms/master.  I think platforms
> > should start in an edk2-platforms/devel-* branch and when they
> > become stable move to an edk2-platforms/stable-* branch.  Stable
> > branches may support multiple platform.
> > 
> > Using this model, there would not be an edk2-platforms/master
> > branch.
> > 
> > Mike
> > 
> > 
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Wednesday, September 28, 2016 3:23 PM
> > > To: Kinney, Michael D 
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] [RFC V2] EDK2 Platform Proposal
> > >
> > > Hi Mike,
> > >
> > > On Thu, Sep 22, 2016 at 08:54:50PM +, Kinney, Michael D wrote:
> > > > Hello,
> > > >
> > > >
> > > >
> > > > Here is the V2 version of the proposal for the edk2-platforms repo.
> > >
> > > I'm happy with the proposal in this state, but have a few suggested
> > > updates (mostly to clarify that, long term, we expect most platforms
> > > to exist in master) and a small suggested addition.
> > >
> > > > Changes from V1:
> > > >
> > > > 
> > > >
> > > > * edk2-platform is not a fork of edk2.
> > > >
> > > > * edk2-platforms branches contain CPU, Chipset, SoC, and platform 
> > > > specific
> > > >
> > > >   packages
> > > >
> > > > * edk2-plaforms/master contains all open platforms that are synced with
> > > >
> > > >   edk2/master.
> > > >
> > > > * Each edk2-platforms branch may support many platforms (not just one)
> > > >
> > > > * Use PACKAGES_PATH to do builds using packages from multiple 
> > > > repositories
> > > >
> > > > * Update edk2-platforms branch naming to clearly identify platforms that
> > > >
> > > >   are considered stable and platforms that are under active development.
> > > >
> > > > * edk2 developers may be required to verify platforms in edk2-platforms
> > > >
> > > >   builds as part of test criteria.  Especially platforms that are 
> > > > intended
> > > >
> > > >   to be used with edk2/master in edk2-platforms/stable-* branches.
> > > >
> > > >
> > > >
> > > > =
> > > >
> > > >
> > > >
> > > > Similar to edk2-staging, we also have a need to manage platforms
> > > >
> > > > that have been ported to edk2.  Jordan has created a repository
> > > >
> > > > called edk2-platforms and has created a branch for the
> > > >
> > > > minnowboard-max that uses a validated release of the UDK 2015 for
> > > >
> > > > the dependent packages:
> > > >
> > > >
> > > >
> > > > https://github.com/tianocore/edk2-platforms
> > > >
> > > >
> > > >
> > > > 

[edk2] [Patch] BaseTools: Update sign tool to make MonotonicCount *after* Payload

2016-10-14 Thread Yonghong Zhu
The WIN_CERTIFICATE_UEFI_GUID AuthInfo defined in the UEFI spec
mentioned that It is a signature across the image data and the
Monotonic Count value. After clarification, we do the signature
calculation, we put MonotonicCount after Payload.

Cc: Liming Gao 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py | 8 
 BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py 
b/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
index b9f8c06..f0b2d8a 100644
--- a/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
+++ b/BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
@@ -195,12 +195,12 @@ if __name__ == '__main__':
 args.OtherPublicCertFile.close()
   except:
 print 'ERROR: test other public cert file %s missing' % 
(args.OtherPublicCertFileName)
 sys.exit(1)
 
-format = "Q%ds" % len(args.InputFileBuffer)
-FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue, 
args.InputFileBuffer)
+format = "%dsQ" % len(args.InputFileBuffer)
+FullInputFileBuffer = struct.pack(format, args.InputFileBuffer, 
args.MonotonicCountValue)
 
 #
 # Sign the input file using the specified private key and capture 
signature from STDOUT
 #
 Process = subprocess.Popen('%s smime -sign -binary -signer "%s" -outform 
DER -md sha256 -certfile "%s"' % (OpenSslCommand, 
args.SignerPrivateCertFileName, args.OtherPublicCertFileName), 
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
@@ -259,12 +259,12 @@ if __name__ == '__main__':
 sys.exit(1)
 
 args.SignatureBuffer = args.InputFileBuffer[0:SignatureSize]
 args.InputFileBuffer = args.InputFileBuffer[SignatureSize:]
 
-format = "Q%ds" % len(args.InputFileBuffer)
-FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue, 
args.InputFileBuffer)
+format = "%dsQ" % len(args.InputFileBuffer)
+FullInputFileBuffer = struct.pack(format, args.InputFileBuffer, 
args.MonotonicCountValue)
 
 #
 # Save output file contents from input file
 #
 open(args.OutputFileName, 'wb').write(FullInputFileBuffer)
diff --git a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py 
b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
index 3410668..199ebec 100644
--- a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
+++ b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
@@ -167,12 +167,12 @@ if __name__ == '__main__':
 pass
 
   if args.Encode:
 FullInputFileBuffer = args.InputFileBuffer
 if args.MonotonicCountStr:
-  format = "Q%ds" % len(args.InputFileBuffer)
-  FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue, 
args.InputFileBuffer)
+  format = "%dsQ" % len(args.InputFileBuffer)
+  FullInputFileBuffer = struct.pack(format, args.InputFileBuffer, 
args.MonotonicCountValue)
 # 
 # Sign the input file using the specified private key and capture 
signature from STDOUT
 #
 Process = subprocess.Popen('%s sha256 -sign "%s"' % (OpenSslCommand, 
args.PrivateKeyFileName), stdin=subprocess.PIPE, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
 Signature = Process.communicate(input=FullInputFileBuffer)[0]
@@ -210,12 +210,12 @@ if __name__ == '__main__':
   print 'ERROR: Public key in input file does not match public key from 
private key file'
   sys.exit(1)
 
 FullInputFileBuffer = args.InputFileBuffer
 if args.MonotonicCountStr:
-  format = "Q%ds" % len(args.InputFileBuffer)
-  FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue, 
args.InputFileBuffer)
+  format = "%dsQ" % len(args.InputFileBuffer)
+  FullInputFileBuffer = struct.pack(format, args.InputFileBuffer, 
args.MonotonicCountValue)
 
 #
 # Write Signature to output file
 #
 open(args.OutputFileName, 'wb').write(Header.Signature)
-- 
2.6.1.windows.1

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


Re: [edk2] SmmCommunicationCommunicate question?

2016-10-14 Thread Laszlo Ersek
On 10/14/16 01:52, Ken Taylor wrote:
> I think there are a couple of assumptions here that should be
> reconsidered...
> 
> First, it is not always the case that entry into SMM on one CPU will
> always pull all CPUs into SMM.  There are methods to deliver targeted
> SMIs via the local APIC on some processors.  In addition, I have 2nd
> hand knowledge that some processors don't immediately return to SMM
> on RSM if other processors are still in SMM; this allows some
> processors to resume early and continue execution while execution on
> other cores continues in SMM.
> 
> Second, CPUs are not the only bus master capable of changing the
> contents of a CommBuffer that is passed to an SMI handler.  I could,
> for example, schedule a USB or a SATA transaction that will clobber
> CommBuffer contents some arbitrary amount of time after I've
> triggered an SMI, and CommBuffer would change on the fly even if all
> my processors are executing known good code in SMM.
> 
> If you want your SMI handler code to be safe, as a first step, either
> copy CommBuffer to a local buffer in SMM, or copy all critical
> parameters such as pointers, BARs, object lengths and commands to
> local variables. Operate only on local copies from that point
> forward.

Good points, thank you! (Practically elaborating on what Paolo said as
well.) I completely missed PCI DMA here.

Thanks!
Laszlo

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Anbazhagan, Baraneedharan
> Sent: Thursday, October 13, 2016 6:20 AM
> To: Paolo Bonzini; Laszlo Ersek
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] SmmCommunicationCommunicate question?
> 
>> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo 
>> Bonzini
>>
>> On 13/10/2016 11:07, Laszlo Ersek wrote:
>>>
>>> Instead, once the first CPU enters SMM, it brings all the other CPUs
>>> into SMM as well, where they will be executing known, secure code --
>>> i.e., the first CPU to enter SMM forces the other CPUs to temporarily
>>> abandon any (possibly malicious) code the runtime OS may have prepared.
>>> Only *then* will the verification of the communication buffer commence.
>>> If the malicious code managed to race the unpriv part of the service
>>> successfully, now the privileged part will catch that, undisturbed.
>>
>> Even this is not strictly necessary if you can set aside some memory in 
>> SMRAM for a
>> copy the communication buffer.  Then you can do:
>>
>>tmp = comm buffer size
>>if tmp > sizeof(privileged buffer)
>>return error
>>copy tmp bytes from comm buffer to privileged buffer
>>
>> and not look anymore at the buffer provided by the user.
>>
>> Of course, "bring all CPUs into SMM" can double as a poor man's mutex, so 
>> there
>> may be reasons to do that anyway.
>>
>> Paolo
> 
> Am thinking in BDS phase - if a module have periodic callback and uses 
> SmmCommunicate within the callback, then it could potentially overwrite those 
> gSmmCorePrivate pointer while another module trying to use SmmCommunicate.
> ___
> 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 v2] MdeModulePkg/BootMaintenanceUi: Enhance the codes logic

2016-10-14 Thread Laszlo Ersek
On 10/14/16 08:43, Dandan Bi wrote:
> This patch is mainly to:
> 1. Enhance the error handling codes when set variable fail.
> 2. Enhance the logic to fix some incorrect UI behaviors.

My apologies, but both the subject line and the commit message are
mostly impenetrable.

This patch should be split up into a series of two patches, minimally
(according to the two goals above that it implements), and each change
should be described correctly in both the subject line and in the commit
message.

If I got a bug report for OVMF that I managed to bisect back to this
patch, I'd be *completely* helpless figuring out what it does.

What kind of variables are set by the code? What happens now if setting
those variables fails? What is the expected behavior instead that the
(first) patch implements?

What are those incorrect UI behaviors? When do they happen? What does
the second patch do to address those issues?

Dear Developers, please *stop* writing subject lines like

  "Enhance the code in DNS driver"
  "Enhance the codes logic"

those subject lines are *completely* useless. You could replace all
those subject lines, without any loss of information, with the following
one:

  "Do Work"

Please spend time thinking about the granularity, the focus of your
patches, as a *standalone activity* during development. Ask yourselves,
"Is this patch small enough? Am I doing two or more independent things
here? Is the subject line clear enough? If a person sees the code for
the first time, will my commit message help them?"

You don't write the commit message for yourselves only, you write it for
other developers who might have absolutely no clue what's going on in
your module.

Thanks
Laszlo

> V2: Update the Console/Terminal menu when the related question changed.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  .../BootMaintenanceManagerUiLib/BootMaintenance.c  | 390 
> -
>  .../BootMaintenanceManagerUiLib/UpdatePage.c   |  42 ++-
>  .../Library/BootMaintenanceManagerUiLib/Variable.c |  28 +-
>  3 files changed, 357 insertions(+), 103 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c 
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
> index a190596..924eb49 100644
> --- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
> +++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
> @@ -442,10 +442,197 @@ BmmExtractDevicePathFromHiiHandle (
>return ConvertDevicePathToText(DevicePathFromHandle (DriverHandle), FALSE, 
> FALSE);
>  
>  }
>  
>  /**
> +  Converts the unicode character of the string from uppercase to lowercase.
> +  This is a internal function.
> +
> +  @param ConfigString  String to be converted
> +
> +**/
> +VOID
> +HiiToLower (
> +  IN EFI_STRING  ConfigString
> +  )
> +{
> +  EFI_STRING  String;
> +  BOOLEAN Lower;
> +
> +  ASSERT (ConfigString != NULL);
> +
> +  //
> +  // Convert all hex digits in range [A-F] in the configuration header to 
> [a-f]
> +  //
> +  for (String = ConfigString, Lower = FALSE; *String != L'\0'; String++) {
> +if (*String == L'=') {
> +  Lower = TRUE;
> +} else if (*String == L'&') {
> +  Lower = FALSE;
> +} else if (Lower && *String >= L'A' && *String <= L'F') {
> +  *String = (CHAR16) (*String - L'A' + L'a');
> +}
> +  }
> +}
> +
> +/**
> +  Update the progress string through the offset value.
> +
> +  @param Offset   The offset value
> +  @param ConfigurationPoint to the configuration string.
> +
> +**/
> +EFI_STRING
> +UpdateProgress(
> +  IN  UINTN   Offset,
> +  IN  EFI_STRING  Configuration
> +)
> +{
> +  UINTN   Length;
> +  EFI_STRING  StringPtr;
> +  EFI_STRING  ReturnString;
> +
> +  StringPtr= NULL;
> +  ReturnString = NULL;
> +
> +  //
> +  // = followed by a Null-terminator.
> +  // Length = StrLen (L"=") + 4 + 1
> +  //
> +  Length= StrLen (L"=") + 4 + 1;
> +
> +  StringPtr = AllocateZeroPool (Length * sizeof (CHAR16));
> +
> +  if (StringPtr == NULL) {
> +return  NULL;
> +  }
> +
> +  UnicodeSPrint (
> +StringPtr,
> +(8 + 4 + 1) * sizeof (CHAR16),
> +L"=%04x",
> +Offset
> +);
> +
> +  ReturnString = StrStr (Configuration, StringPtr);
> +
> +  if (ReturnString == NULL) {
> +//
> +// If doesn't find the string in Configuration, convert the string to 
> lower case then search again.
> +//
> +HiiToLower (StringPtr);
> +ReturnString = StrStr (Configuration, StringPtr);
> +  }
> +
> +  FreePool (StringPtr);
> +
> +  return ReturnString;
> +}
> +
> +/**
> +  Update the terminal content in TerminalMenu.
> +
> +  @param BmmData   The BMM fake NV data.
> +
> +**/
> +VOID
> +UpdateTerminalContent (
> +  IN BMM_FAKE_NV_DATA   *BmmData
> +  )
> +{
> +  UINT16 

Re: [edk2] [Patch] MdePkg BaseSynchronizationLib: Update InterlockedCompareExchange64.nasm

2016-10-14 Thread Laszlo Ersek
On 10/14/16 08:47, Liming Gao wrote:
> Remove extra qword in nasm code to make it pass build.
> This file is only built in INTEL ICC compiler. So, there is missing
> build check for it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  .../BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm   | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm
>  
> b/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm
> index ee63ff7..206de40 100644
> --- 
> a/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm
> +++ 
> b/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm
> @@ -41,7 +41,7 @@ ASM_PFX(InternalSyncCompareExchange64):
>  mov edx, [esp + 20]
>  mov ebx, [esp + 24]
>  mov ecx, [esp + 28]
> -lockcmpxchg8b   qword [esi]
> +lockcmpxchg8b [esi]
>  pop ebx
>  pop esi
>  ret
> 

Suggested subject line:

MdePkg BaseSynchronizationLib InterlockedCompareExchange64: fix ICC build

(73 characters)

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


Re: [edk2] [Patch] MdeModulePkg FileExplorerLib: Fix potential Integer Overflow.

2016-10-14 Thread Laszlo Ersek
On 10/14/16 08:49, Liming Gao wrote:
> In function 'LibAppendFileName' of 'FileExplorer.c':
> "
> MaxLen = (Size1 + Size2 + sizeof (CHAR16))/ sizeof (CHAR16);
> "
> Overflow may happen here. MaxLen might become a very small number.
> This patch adds integer overflow checker.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Reviewed-by: Jiewen Yao 
> ---
>  .../Library/FileExplorerLib/FileExplorer.c | 28 
> --
>  1 file changed, 26 insertions(+), 2 deletions(-)

The first hunk of the patch looks good to me.

The rest of the patch may also be good, but what it does is logically
separate -- it eliminates resource leaks and fixes return values on
error paths. For that reason, it belongs to a different patch, I think;
something like:

  MdeModulePkg FileExplorerLib: free resources and set retvals on errors

Thanks
Laszlo

> diff --git a/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c 
> b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
> index 59c851b..41a22aa 100644
> --- a/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
> +++ b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
> @@ -620,6 +620,14 @@ LibAppendFileName (
>  
>Size1 = StrSize (Str1);
>Size2 = StrSize (Str2);
> +  
> +  //
> +  // Check overflow
> +  //
> +  if (((MAX_UINTN - Size1) < Size2) || ((MAX_UINTN - Size1 - Size2) < 
> sizeof(CHAR16))) {
> +return NULL;
> +  }
> +  
>MaxLen = (Size1 + Size2 + sizeof (CHAR16))/ sizeof (CHAR16);
>Str   = AllocateZeroPool (Size1 + Size2 + sizeof (CHAR16));
>ASSERT (Str != NULL);
> @@ -963,6 +971,7 @@ LibGetFileHandleFromDevicePath (
>  // the file system support below to be skipped.
>  //
>  Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
>}
>  
>//
> @@ -992,6 +1001,11 @@ LibGetFileHandleFromDevicePath (
>*ParentFileName = AllocateCopyPool (StrSize (((FILEPATH_DEVICE_PATH *) 
> DevicePathNode)->PathName), ((FILEPATH_DEVICE_PATH *) 
> DevicePathNode)->PathName);
>  } else {
>TempPath = LibAppendFileName (*ParentFileName, ((FILEPATH_DEVICE_PATH 
> *) DevicePathNode)->PathName);
> +  if (TempPath == NULL) {
> +LastHandle->Close (LastHandle);
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> +  }
>FreePool (*ParentFileName);
>*ParentFileName = TempPath;
>  }
> @@ -1067,12 +1081,14 @@ LibFindFiles (
>// Pass 1 to get Directories
>// Pass 2 to get files that are EFI images
>//
> +  Status = EFI_SUCCESS;
>for (Pass = 1; Pass <= 2; Pass++) {
>  FileHandle->SetPosition (FileHandle, 0);
>  for (;;) {
>BufferSize  = DirBufferSize;
>Status  = FileHandle->Read (FileHandle, , DirInfo);
>if (EFI_ERROR (Status) || BufferSize == 0) {
> +Status = EFI_SUCCESS;
>  break;
>}
>  
> @@ -1095,12 +,18 @@ LibFindFiles (
>  
>NewMenuEntry = LibCreateMenuEntry ();
>if (NULL == NewMenuEntry) {
> -return EFI_OUT_OF_RESOURCES;
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
>}
>  
>NewFileContext = (FILE_CONTEXT *) NewMenuEntry->VariableContext;
>NewFileContext->DeviceHandle = DeviceHandle;
>NewFileContext->FileName = LibAppendFileName (FileName, 
> DirInfo->FileName);
> +  if  (NewFileContext->FileName == NULL) {
> +LibDestroyMenuEntry (NewMenuEntry);
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> +  }
>NewFileContext->FileHandle = FileHandle;
>NewFileContext->DevicePath = FileDevicePath 
> (NewFileContext->DeviceHandle, NewFileContext->FileName);
>NewMenuEntry->HelpString = NULL;
> @@ -1135,9 +1157,11 @@ LibFindFiles (
>  
>gFileExplorerPrivate.FsOptionMenu->MenuNumber = OptionNumber;
>  
> +Done:
> +
>FreePool (DirInfo);
>  
> -  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] NetworkPkg: Enhance the code in DNS driver.

2016-10-14 Thread Laszlo Ersek
On 10/14/16 08:54, Zhang Lubo wrote:
> There may be an error happens when we use the
> configure function to set or change the configuration
> data for the DNS6 instance, So we will free the
> DnsServerList without configured to NULL. If we reset
> the instance with the parameter DnsConfigData to NULL, the
> DnsServerList will be freed twice.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> ---
>  NetworkPkg/DnsDxe/DnsProtocol.c | 4 
>  1 file changed, 4 insertions(+)

The subject line of the patch is near useless, I'm afraid.

How about:

NetworkPkg/DnsDxe: eliminate double-free on DNS configuration failure

Thanks
Laszlo

> diff --git a/NetworkPkg/DnsDxe/DnsProtocol.c b/NetworkPkg/DnsDxe/DnsProtocol.c
> index 64fca6a..6d117b2 100644
> --- a/NetworkPkg/DnsDxe/DnsProtocol.c
> +++ b/NetworkPkg/DnsDxe/DnsProtocol.c
> @@ -285,10 +285,11 @@ Dns4Configure (
>  //
>  Status = Dns4ConfigUdp (Instance, Instance->UdpIo);
>  if (EFI_ERROR (Status)) {
>if (Instance->Dns4CfgData.DnsServerList != NULL) {
>  FreePool (Instance->Dns4CfgData.DnsServerList);
> +Instance->Dns4CfgData.DnsServerList = NULL;
>}
>goto ON_EXIT;
>  }
>  
>  //
> @@ -296,10 +297,11 @@ Dns4Configure (
>  //
>  Status = AddDns4ServerIp (>Dns4ServerList, 
> Instance->SessionDnsServer.v4);
>  if (EFI_ERROR (Status)) {
>if (Instance->Dns4CfgData.DnsServerList != NULL) {
>  FreePool (Instance->Dns4CfgData.DnsServerList);
> +Instance->Dns4CfgData.DnsServerList = NULL;
>}
>goto ON_EXIT;
>  }
>  
>  Instance->State = DNS_STATE_CONFIGED;
> @@ -1106,10 +1108,11 @@ Dns6Configure (
>  //
>  Status = Dns6ConfigUdp (Instance, Instance->UdpIo);
>  if (EFI_ERROR (Status)) {
>if (Instance->Dns6CfgData.DnsServerList != NULL) {
>  FreePool (Instance->Dns6CfgData.DnsServerList);
> +Instance->Dns6CfgData.DnsServerList = NULL;
>}
>goto ON_EXIT;
>  }
>  
>  //
> @@ -1117,10 +1120,11 @@ Dns6Configure (
>  //
>  Status = AddDns6ServerIp (>Dns6ServerList, 
> Instance->SessionDnsServer.v6);
>  if (EFI_ERROR (Status)) {
>if (Instance->Dns6CfgData.DnsServerList != NULL) {
>  FreePool (Instance->Dns6CfgData.DnsServerList);
> +Instance->Dns6CfgData.DnsServerList = NULL;
>}
>goto ON_EXIT;
>  }
>  
>  Instance->State = DNS_STATE_CONFIGED;
> 

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


Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

2016-10-14 Thread Laszlo Ersek
On 10/14/16 11:33, Bhupesh Sharma wrote:
> Various IPs on NXP/FSL SoCs having ARM64 cores have big-endian
> MMIO interfaces.
> 
> This implies that a byte-swap operation is needed to read/write
> such BE MMIO registers from the LE ARM64 cores.
> 
> This patch adds the support for the same.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Meenakshi Aggarwal 
> Signed-off-by: Bhupesh Sharma 
> ---
>  MdePkg/Include/Library/IoLib.h   | 364 
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c | 479 
> +++
>  2 files changed, 843 insertions(+)

I think this is both overkill and incomplete, at the same time :)

- Incomplete because only one IoLib instance gets the implementation.

- Overkill because you can easily use the SwapBytes16, SwapBytes32,
SwapBytes64 functions -- also from BaseLib --, for transforming
MmioWrite arguments and MmioRead results.

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


[edk2] [RESEND PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

2016-10-14 Thread Bhupesh Sharma
ARM TZASC-380 IP provides a mechanism to split memory regions being
protected via it into eight equal-sized sub-regions,
with a bit setting allowing the corresponding subregion to be disabled.

Several NXP/FSL SoCs support the TZASC-380 IP block and allow
the DDR connected via the TZASC to be partitioned into regions
having different security settings.

This patch enables this support and can be used for SoCs which
support such partition of DDR regions.

Details of the 'subregion_disable' register can be viewed here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/CJABCFHB.html

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bhupesh Sharma 
Cc: Ard Biesheuvel 
---
 .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21 ++---
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
 ArmPlatformPkg/Include/Drivers/ArmTrustzone.h   |  3 ++-
 3 files changed, 19 insertions(+), 10 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
index 6fa0774..d358d65 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
@@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
   // NOR Flash 0 non secure (BootMon)
   TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
   ARM_VE_SMB_NOR0_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
secure firmware (sec_uefi.bin)
   if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE,0,
-TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Base of SRAM. Only half of SRAM in Non Secure world
@@ -92,22 +95,26 @@ ArmPlatformSecTrustzoneInit (
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Memory Mapped Peripherals. All in non secure world
   TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
   ARM_VE_SMB_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // MotherBoard Peripherals and On-chip peripherals.
   TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
   ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 }
 
 /**
diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
index 070c0dc..5cd41ef 100644
--- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
+++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
@@ -87,7 +87,8 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
   IN  UINTN Size,
-  IN  UINTN Security
+  IN  UINTN Security,
+  IN  UINTN SubregionDisableMask
   )
 {
   UINT32* Region;
@@ -100,7 +101,7 @@ TZASCSetRegion (
 
   MmioWrite32((UINTN)(Region), LowAddress&0x8000);
   MmioWrite32((UINTN)(Region+1), HighAddress);
-  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | ((Size & 0x3F) << 
1) | (Enabled & 0x1));
+  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | 
((SubregionDisableMask & 0xFF) << 8) | ((Size & 0x3F) << 1) | (Enabled & 0x1));
 
   return EFI_SUCCESS;
 }
diff --git a/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h 
b/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h
index 78e98aa..1ba963d 100644
--- a/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h
+++ b/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h
@@ -82,7 +82,8 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
   IN  UINTN Size,
-  IN  UINTN Security
+  IN  UINTN Security,
+  IN  UINTN 

Re: [edk2] [PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

2016-10-14 Thread Bhupesh Sharma
This patch is missing a .h file. Please discard.
I will RESEND the patch with the fix.

Apologies for the inconvenience. 

Regards,
Bhupesh

> -Original Message-
> From: Bhupesh Sharma [mailto:bhupesh.sha...@nxp.com]
> Sent: Friday, October 14, 2016 4:22 PM
> To: edk2-de...@ml01.01.org
> Cc: linaro-u...@lists.linaro.org; Bhupesh Sharma
> ; Ard Biesheuvel 
> Subject: [PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for
> specifying Subregions to be disabled
> 
> ARM TZASC-380 IP provides a mechanism to split memory regions being
> protected via it into eight equal-sized sub-regions, with a bit setting
> allowing the corresponding subregion to be disabled.
> 
> Several NXP/FSL SoCs support the TZASC-380 IP block and allow the DDR
> connected via the TZASC to be partitioned into regions having different
> security settings.
> 
> This patch enables this support and can be used for SoCs which support
> such partition of DDR regions.
> 
> Details of the 'subregion_disable' register can be viewed here:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/CJ
> ABCFHB.html
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Bhupesh Sharma 
> Cc: Ard Biesheuvel 
> ---
>  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21
> ++---
>  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
>  2 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> index 6fa0774..d358d65 100644
> ---
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> +++
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9
> +++ x4Sec.c
> @@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
>// NOR Flash 0 non secure (BootMon)
>TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
>ARM_VE_SMB_NOR0_BASE,0,
> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
> 
>// NOR Flash 1. The first half of the NOR Flash1 must be secure for
> the secure firmware (sec_uefi.bin)
>if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
>  //Note: Your OS Kernel must be aware of the secure regions before
> to enable this region
>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>} else {
>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_NOR1_BASE,0,
> -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>}
> 
>// Base of SRAM. Only half of SRAM in Non Secure world @@ -92,22
> +95,26 @@ ArmPlatformSecTrustzoneInit (
>  //Note: Your OS Kernel must be aware of the secure regions before
> to enable this region
>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_SRAM_BASE,0,
> -TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>} else {
>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_SRAM_BASE,0,
> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>}
> 
>// Memory Mapped Peripherals. All in non secure world
>TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
>ARM_VE_SMB_PERIPH_BASE,0,
> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
> 
>// MotherBoard Peripherals and On-chip peripherals.
>TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
>ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
> -  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
>  }
> 
>  /**
> diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> index 070c0dc..5cd41ef 100644
> --- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> +++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> @@ -87,7 +87,8 @@ TZASCSetRegion (
>IN  UINTN LowAddress,
>IN  UINTN HighAddress,
>IN  UINTN Size,
> -  IN  UINTN Security
> +  IN  UINTN Security,
> +  IN  UINTN SubregionDisableMask
>)
>  {
>UINT32* Region;
> @@ -100,7 +101,7 @@ TZASCSetRegion (
> 
>MmioWrite32((UINTN)(Region), LowAddress&0x8000);
>MmioWrite32((UINTN)(Region+1), 

[edk2] [PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

2016-10-14 Thread Bhupesh Sharma
ARM TZASC-380 IP provides a mechanism to split memory regions being
protected via it into eight equal-sized sub-regions,
with a bit setting allowing the corresponding subregion to be disabled.

Several NXP/FSL SoCs support the TZASC-380 IP block and allow
the DDR connected via the TZASC to be partitioned into regions
having different security settings.

This patch enables this support and can be used for SoCs which
support such partition of DDR regions.

Details of the 'subregion_disable' register can be viewed here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/CJABCFHB.html

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bhupesh Sharma 
Cc: Ard Biesheuvel 
---
 .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21 ++---
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
index 6fa0774..d358d65 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
@@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
   // NOR Flash 0 non secure (BootMon)
   TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
   ARM_VE_SMB_NOR0_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
secure firmware (sec_uefi.bin)
   if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE,0,
-TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Base of SRAM. Only half of SRAM in Non Secure world
@@ -92,22 +95,26 @@ ArmPlatformSecTrustzoneInit (
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Memory Mapped Peripherals. All in non secure world
   TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
   ARM_VE_SMB_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // MotherBoard Peripherals and On-chip peripherals.
   TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
   ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 }
 
 /**
diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
index 070c0dc..5cd41ef 100644
--- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
+++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
@@ -87,7 +87,8 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
   IN  UINTN Size,
-  IN  UINTN Security
+  IN  UINTN Security,
+  IN  UINTN SubregionDisableMask
   )
 {
   UINT32* Region;
@@ -100,7 +101,7 @@ TZASCSetRegion (
 
   MmioWrite32((UINTN)(Region), LowAddress&0x8000);
   MmioWrite32((UINTN)(Region+1), HighAddress);
-  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | ((Size & 0x3F) << 
1) | (Enabled & 0x1));
+  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | 
((SubregionDisableMask & 0xFF) << 8) | ((Size & 0x3F) << 1) | (Enabled & 0x1));
 
   return EFI_SUCCESS;
 }
-- 
1.9.1


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


[edk2] [PATCH 2/5] MdePkg: Include Shell/ShellDynamicCommand/ShellParameters definitions

2016-10-14 Thread Ruiyu Ni
Copy Shell/ShellDynamicCommand/ShellParameters definitions from
ShellPkg to MdePkg.
Content of ShellBase.h is moved to Protocol/Shell.h.

The following patches will update ShellPkg to reference all protocol
definition to MdePkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
Cc: Jiewen Yao 
Cc: Michael D Kinney 
---
 MdePkg/Include/Protocol/Shell.h   | 1268 +
 MdePkg/Include/Protocol/ShellDynamicCommand.h |   85 ++
 MdePkg/Include/Protocol/ShellParameters.h |   60 ++
 MdePkg/MdePkg.dec |   15 +
 4 files changed, 1428 insertions(+)
 create mode 100644 MdePkg/Include/Protocol/Shell.h
 create mode 100644 MdePkg/Include/Protocol/ShellDynamicCommand.h
 create mode 100644 MdePkg/Include/Protocol/ShellParameters.h

diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Shell.h
new file mode 100644
index 000..cc1fbdc
--- /dev/null
+++ b/MdePkg/Include/Protocol/Shell.h
@@ -0,0 +1,1268 @@
+/** @file
+  EFI Shell protocol as defined in the UEFI Shell 2.0 specification including 
errata.
+
+  (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __EFI_SHELL_PROTOCOL__
+#define __EFI_SHELL_PROTOCOL__
+
+#include 
+
+#define EFI_SHELL_PROTOCOL_GUID \
+  { \
+  0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e 
} \
+  }
+typedef VOID *SHELL_FILE_HANDLE;
+
+typedef enum {
+  ///
+  /// The operation completed successfully.
+  ///
+  SHELL_SUCCESS   = 0,
+
+  ///
+  /// The image failed to load.
+  ///
+  SHELL_LOAD_ERROR= 1,
+
+  ///
+  /// The parameter was incorrect.
+  ///
+  SHELL_INVALID_PARAMETER = 2,
+
+  ///
+  /// The operation is not supported.
+  ///
+  SHELL_UNSUPPORTED   = 3,
+
+  ///
+  /// The buffer was not the proper size for the request.
+  ///
+  SHELL_BAD_BUFFER_SIZE   = 4,
+
+  ///
+  /// The buffer was not large enough to hold the requested data.
+  /// The required buffer size is returned in the appropriate
+  /// parameter when this error occurs.
+  ///
+  SHELL_BUFFER_TOO_SMALL  = 5,
+
+  ///
+  /// There is no data pending upon return.
+  ///
+  SHELL_NOT_READY = 6,
+
+  ///
+  /// The physical device reported an error while attempting the
+  /// operation.
+  ///
+  SHELL_DEVICE_ERROR  = 7,
+
+  ///
+  /// The device cannot be written to.
+  ///
+  SHELL_WRITE_PROTECTED   = 8,
+
+  ///
+  /// The resource has run out.
+  ///
+  SHELL_OUT_OF_RESOURCES  = 9,
+
+  ///
+  /// An inconsistency was detected on the file system causing the
+  /// operation to fail.
+  ///
+  SHELL_VOLUME_CORRUPTED  = 10,
+
+  ///
+  /// There is no more space on the file system.
+  ///
+  SHELL_VOLUME_FULL   = 11,
+
+  ///
+  /// The device does not contain any medium to perform the
+  /// operation.
+  ///
+  SHELL_NO_MEDIA  = 12,
+
+  ///
+  /// The medium in the device has changed since the last
+  /// access.
+  ///
+  SHELL_MEDIA_CHANGED = 13,
+
+  ///
+  /// The item was not found.
+  ///
+  SHELL_NOT_FOUND = 14,
+
+  ///
+  /// Access was denied.
+  ///
+  SHELL_ACCESS_DENIED = 15,
+
+  // note the skipping of 16 and 17
+
+  ///
+  /// A timeout time expired.
+  ///
+  SHELL_TIMEOUT   = 18,
+
+  ///
+  /// The protocol has not been started.
+  ///
+  SHELL_NOT_STARTED   = 19,
+
+  ///
+  /// The protocol has already been started.
+  ///
+  SHELL_ALREADY_STARTED   = 20,
+
+  ///
+  /// The operation was aborted.
+  ///
+  SHELL_ABORTED   = 21,
+
+  // note the skipping of 22, 23, and 24
+
+  ///
+  /// A function encountered an internal version that was
+  /// incompatible with a version requested by the caller.
+  ///
+  SHELL_INCOMPATIBLE_VERSION  = 25,
+
+  ///
+  /// The function was not performed due to a security violation.
+  ///
+  SHELL_SECURITY_VIOLATION= 26,
+
+  ///
+  /// The function was performed and resulted in an unequal
+  /// comparison..
+  ///
+  SHELL_NOT_EQUAL = 27
+} SHELL_STATUS;
+
+
+// replaced EFI_LIST_ENTRY with LIST_ENTRY for simplicity.
+// they are identical outside of the name.
+typedef struct {
+  LIST_ENTRYLink;   ///< Linked list members.
+  EFI_STATUSStatus; ///< Status of opening the file.  Valid only 
if Handle 

[edk2] [PATCH 5/5] ShellPkg: Remove Shell/ShellDynamicCommand/ShellParameter definitions

2016-10-14 Thread Ruiyu Ni
Remove Shell/ShellDynamicCommand/ShellParameter definitions and
update all sources to reference the ones in MdePkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
---
 ShellPkg/Application/Shell/Shell.h |5 +-
 ShellPkg/Include/Library/ShellCommandLib.h |5 +-
 ShellPkg/Include/Library/ShellLib.h|4 +-
 ShellPkg/Include/Protocol/EfiShell.h   | 1138 
 ShellPkg/Include/Protocol/EfiShellDynamicCommand.h |   86 --
 ShellPkg/Include/Protocol/EfiShellParameters.h |   60 --
 ShellPkg/Include/ShellBase.h   |  149 ---
 ShellPkg/Library/UefiDpLib/Dp.h|3 +-
 ShellPkg/Library/UefiDpLib/UefiDpLib.h |7 +-
 .../UefiHandleParsingLib/UefiHandleParsingLib.h|8 +-
 .../UefiShellBcfgCommandLib.c  |5 +-
 .../UefiShellCEntryLib/UefiShellCEntryLib.c|6 +-
 .../UefiShellCommandLib/UefiShellCommandLib.h  |7 +-
 .../Library/UefiShellDebug1CommandsLib/Compress.c  |1 -
 .../UefiShellDebug1CommandsLib.h   |7 +-
 .../UefiShellDriver1CommandsLib.h  |7 +-
 .../UefiShellLevel1CommandsLib.h   |7 +-
 .../UefiShellLevel2CommandsLib.h   |7 +-
 ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c |2 +-
 .../UefiShellLevel3CommandsLib.h   |7 +-
 ShellPkg/Library/UefiShellLib/UefiShellLib.c   |1 -
 ShellPkg/Library/UefiShellLib/UefiShellLib.h   |6 +-
 .../UefiShellNetwork1CommandsLib.h |3 +-
 .../UefiShellTftpCommandLib.h  |3 +-
 ShellPkg/ShellPkg.dec  |3 -
 ShellPkg/ShellPkg.dsc  |2 +
 26 files changed, 45 insertions(+), 1494 deletions(-)
 delete mode 100644 ShellPkg/Include/Protocol/EfiShell.h
 delete mode 100644 ShellPkg/Include/Protocol/EfiShellDynamicCommand.h
 delete mode 100644 ShellPkg/Include/Protocol/EfiShellParameters.h
 delete mode 100644 ShellPkg/Include/ShellBase.h

diff --git a/ShellPkg/Application/Shell/Shell.h 
b/ShellPkg/Application/Shell/Shell.h
index a93ea60..25ac114 100644
--- a/ShellPkg/Application/Shell/Shell.h
+++ b/ShellPkg/Application/Shell/Shell.h
@@ -17,17 +17,16 @@
 #define _SHELL_INTERNAL_HEADER_
 
 #include 
-#include 
 
 #include 
 #include 
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/ShellPkg/Include/Library/ShellCommandLib.h 
b/ShellPkg/Include/Library/ShellCommandLib.h
index 3ee8200..08de133 100644
--- a/ShellPkg/Include/Library/ShellCommandLib.h
+++ b/ShellPkg/Include/Library/ShellCommandLib.h
@@ -21,10 +21,9 @@
 #define _SHELL_COMMAND_LIB_
 
 #include 
-#include 
 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 
diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index fafa041..9b611d8 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -21,8 +21,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 
 #define SHELL_FREE_NON_NULL(Pointer)  \
   do {\
diff --git a/ShellPkg/Include/Protocol/EfiShell.h 
b/ShellPkg/Include/Protocol/EfiShell.h
deleted file mode 100644
index 5c7f4f6..000
--- a/ShellPkg/Include/Protocol/EfiShell.h
+++ /dev/null
@@ -1,1138 +0,0 @@
-/** @file
-  EFI Shell protocol as defined in the UEFI Shell 2.0 specification including 
errata.
-
-  (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#ifndef __EFI_SHELL_PROTOCOL__
-#define __EFI_SHELL_PROTOCOL__
-
-#include 
-#include 
-
-#define EFI_SHELL_PROTOCOL_GUID \
-  { \
-  0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda, 0x4e 
} \
-  }
-
-// replaced EFI_LIST_ENTRY with LIST_ENTRY for simplicity.
-// they are identical outside of the name.
-typedef struct {
-  LIST_ENTRYLink;   ///< Linked list members.
-  EFI_STATUSStatus; ///< Status of opening the file.  Valid only 
if Handle != NULL.
-  CONST CHAR16  *FullName;  ///< Fully qualified filename.
-  CONST CHAR16  *FileName;  ///< name of this file.
-  SHELL_FILE_HANDLE Handle; ///< Handle for interacting with the opened 
file or NULL if closed.
-  EFI_FILE_INFO *Info; 

[edk2] [PATCH 3/5] ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg

2016-10-14 Thread Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 ArmPkg/Application/LinuxLoader/LinuxLoader.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Application/LinuxLoader/LinuxLoader.h 
b/ArmPkg/Application/LinuxLoader/LinuxLoader.h
index 8a23d7f..0d18c24 100644
--- a/ArmPkg/Application/LinuxLoader/LinuxLoader.h
+++ b/ArmPkg/Application/LinuxLoader/LinuxLoader.h
@@ -25,8 +25,8 @@
 #include 
 #include 
 
-#include 
-#include 
+#include 
+#include 
 
 #include 
 
-- 
2.9.0.windows.1

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


[edk2] [PATCH 4/5] EmbeddedPkg/FdtPlatformDxe: Reference Shell protocols in MdePkg

2016-10-14 Thread Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h 
b/EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h
index d49dd42..a631f28 100644
--- a/EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h
+++ b/EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h
@@ -19,8 +19,8 @@
 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 
 #include 
 #include 
-- 
2.9.0.windows.1

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


[edk2] [PATCH 0/5] Move Shell protocol definitions to MdePkg

2016-10-14 Thread Ruiyu Ni
The patches moves Shell spec defined protocol definitions to
MdePkg and updates all references.
Content of ShellBase.h is moved to Protocol/Shell.h and
ShellBase.h is removed.

Ruiyu Ni (5):
  ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h
  MdePkg: Include Shell/ShellDynamicCommand/ShellParameters definitions
  ArmPkg/LinuxLoader: Reference Shell protocols in MdePkg
  EmbeddedPkg/FdtPlatformDxe: Reference Shell protocols in MdePkg
  ShellPkg: Remove Shell/ShellDynamicCommand/ShellParameter definitions

 ArmPkg/Application/LinuxLoader/LinuxLoader.h   |   4 +-
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h   |   4 +-
 .../EfiShell.h => MdePkg/Include/Protocol/Shell.h  | 134 +-
 .../Include/Protocol/ShellDynamicCommand.h |   7 +-
 .../Include/Protocol/ShellParameters.h |   4 +-
 MdePkg/MdePkg.dec  |  15 ++
 ShellPkg/Application/Shell/Shell.h |   5 +-
 ShellPkg/Include/Library/ShellCommandLib.h |   5 +-
 ShellPkg/Include/Library/ShellLib.h|  14 +-
 ShellPkg/Include/ShellBase.h   | 157 -
 ShellPkg/Library/UefiDpLib/Dp.h|   3 +-
 ShellPkg/Library/UefiDpLib/UefiDpLib.h |   7 +-
 .../UefiHandleParsingLib/UefiHandleParsingLib.h|   8 +-
 .../UefiShellBcfgCommandLib.c  |   5 +-
 .../UefiShellCEntryLib/UefiShellCEntryLib.c|   6 +-
 .../UefiShellCommandLib/UefiShellCommandLib.h  |   7 +-
 .../Library/UefiShellDebug1CommandsLib/Compress.c  |   7 +-
 .../UefiShellDebug1CommandsLib.h   |   7 +-
 .../UefiShellDriver1CommandsLib.h  |   7 +-
 .../UefiShellLevel1CommandsLib.h   |   7 +-
 .../UefiShellLevel2CommandsLib.h   |   7 +-
 ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c |   2 +-
 .../UefiShellLevel3CommandsLib.h   |   7 +-
 ShellPkg/Library/UefiShellLib/UefiShellLib.c   |   1 -
 ShellPkg/Library/UefiShellLib/UefiShellLib.h   |   6 +-
 .../UefiShellNetwork1CommandsLib.h |   3 +-
 .../UefiShellTftpCommandLib.h  |   3 +-
 ShellPkg/ShellPkg.dec  |   3 -
 ShellPkg/ShellPkg.dsc  |   2 +
 29 files changed, 213 insertions(+), 234 deletions(-)
 rename ShellPkg/Include/Protocol/EfiShell.h => MdePkg/Include/Protocol/Shell.h 
(92%)
 rename ShellPkg/Include/Protocol/EfiShellDynamicCommand.h => 
MdePkg/Include/Protocol/ShellDynamicCommand.h (92%)
 rename ShellPkg/Include/Protocol/EfiShellParameters.h => 
MdePkg/Include/Protocol/ShellParameters.h (92%)
 delete mode 100644 ShellPkg/Include/ShellBase.h

-- 
2.9.0.windows.1

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


[edk2] [PATCH 1/5] ShellPkg: Move SHELL_FREE_NON_NULL from ShellBase.h to ShellLib.h

2016-10-14 Thread Ruiyu Ni
The more proper place for macro SHELL_FREE_NON_NULL is ShellLib.h
instead of ShellBase.h.

Modify Compress.c to resolve build failure due to this change.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
Cc: Jiewen Yao 
Cc: Michael D Kinney 
---
 ShellPkg/Include/Library/ShellLib.h| 10 +-
 ShellPkg/Include/ShellBase.h   | 10 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c |  8 
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index fe4b9cf..fafa041 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to shell functionality for shell commands and 
applications.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 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
@@ -24,6 +24,14 @@
 #include 
 #include 
 
+#define SHELL_FREE_NON_NULL(Pointer)  \
+  do {\
+if ((Pointer) != NULL) {  \
+  FreePool((Pointer));\
+  (Pointer) = NULL;   \
+} \
+  } while(FALSE)
+
 // (20 * (6+5+2))+1) unicode characters from EFI FAT spec (doubled for bytes)
 #define MAX_FILE_NAME_LEN 512
 
diff --git a/ShellPkg/Include/ShellBase.h b/ShellPkg/Include/ShellBase.h
index 09f87b4..4b7a3d1 100644
--- a/ShellPkg/Include/ShellBase.h
+++ b/ShellPkg/Include/ShellBase.h
@@ -1,7 +1,7 @@
 /** @file
   Root include file for Shell Package modules that utilize the SHELL_RETURN 
type
 
-  Copyright (c) 2009 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 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
@@ -17,14 +17,6 @@
 
 typedef VOID *SHELL_FILE_HANDLE;
 
-#define SHELL_FREE_NON_NULL(Pointer)  \
-  do {\
-if ((Pointer) != NULL) {  \
-  FreePool((Pointer));\
-  (Pointer) = NULL;   \
-} \
-  } while(FALSE)
-
 typedef enum {
 ///
 /// The operation completed successfully.
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
index dda2fed..da8e647 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Compress.c
@@ -7,7 +7,7 @@
   This sequence is further divided into Blocks and Huffman codings
   are applied to each Block.
 
-  Copyright (c) 2007 - 2014, 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
@@ -17,12 +17,12 @@
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 **/
-
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
 
 //
 // Macro Definitions
-- 
2.9.0.windows.1

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


[edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

2016-10-14 Thread Bhupesh Sharma
Various IPs on NXP/FSL SoCs having ARM64 cores have big-endian
MMIO interfaces.

This implies that a byte-swap operation is needed to read/write
such BE MMIO registers from the LE ARM64 cores.

This patch adds the support for the same.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Meenakshi Aggarwal 
Signed-off-by: Bhupesh Sharma 
---
 MdePkg/Include/Library/IoLib.h   | 364 
 MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c | 479 +++
 2 files changed, 843 insertions(+)

diff --git a/MdePkg/Include/Library/IoLib.h b/MdePkg/Include/Library/IoLib.h
index a0dd16b..f5842e6 100644
--- a/MdePkg/Include/Library/IoLib.h
+++ b/MdePkg/Include/Library/IoLib.h
@@ -2658,6 +2658,370 @@ MmioWriteBuffer64 (
   IN  CONST UINT64 *Buffer
   );
 
+/**
+  Reads a 16-bit MMIO register in Big Endian format.
+
+  Reads the 16-bit MMIO register specified by Address. The 16-bit read value is
+  returned. This function must guarantee that all MMIO read and write
+  operations are serialized.
+
+  If 16-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT16
+EFIAPI
+MmioReadBe16 (
+  IN  UINTN Address
+  );
+
+/**
+  Writes a 16-bit MMIO register in Big Endian format.
+
+  Writes the 16-bit MMIO register specified by Address with the value specified
+  by Value and returns Value. This function must guarantee that all MMIO read
+  and write operations are serialized.
+
+  If 16-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT16
+EFIAPI
+MmioWriteBe16 (
+  IN  UINTN Address,
+  IN  UINT16Value
+  );
+
+/**
+  Reads a 32-bit MMIO register in Big Endian format.
+
+  Reads the 32-bit MMIO register specified by Address. The 32-bit read value is
+  returned. This function must guarantee that all MMIO read and write
+  operations are serialized.
+
+  If 32-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT32
+EFIAPI
+MmioReadBe32 (
+  IN  UINTN Address
+  );
+
+/**
+  Writes a 32-bit MMIO register in Big Endian format.
+
+  Writes the 32-bit MMIO register specified by Address with the value specified
+  by Value and returns Value. This function must guarantee that all MMIO read
+  and write operations are serialized.
+
+  If 32-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT32
+EFIAPI
+MmioWriteBe32 (
+  IN  UINTN Address,
+  IN  UINT32Value
+  );
+
+
+/**
+  Reads a 64-bit MMIO register in Big Endian format.
+
+  Reads the 64-bit MMIO register specified by Address. The 64-bit read value is
+  returned. This function must guarantee that all MMIO read and write
+  operations are serialized.
+
+  If 64-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT64
+EFIAPI
+MmioReadBe64 (
+  IN  UINTN Address
+  );
+
+
+/**
+  Writes a 64-bit MMIO register in Big Endian format.
+
+  Writes the 64-bit MMIO register specified by Address with the value specified
+  by Value and returns Value. This function must guarantee that all MMIO read
+  and write operations are serialized.
+
+  If 64-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT64
+EFIAPI
+MmioWriteBe64 (
+  IN  UINTN Address,
+  IN  UINT64Value
+  );
+
+/**
+  Clear and set a 8-bit MMIO register.
+
+  Mask the 8-bit MMIO register specified by Address with the mask specified
+  by Mask and then Writes the 8-bit MMIO register specified by Address with
+  the value specified by Value and returns current value on register. This
+  function must guarantee that all MMIO read and write operations are 
serialized.
+
+  @param  Address The MMIO register to write.
+  @param  MaskThe Mask to clear the MMIO register.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT8
+EFIAPI
+MmioClearSet8 (
+  IN  UINTNAddress,
+  IN  UINT8Mask,
+  IN  UINT8Value
+  );
+
+/**
+  Clear and set a 16-bit MMIO register in Big Endian format.
+
+  Mask the 16-bit MMIO register specified by Address with the mask specified
+  by Mask and then Writes the 16-bit MMIO register specified by Address 

Re: [edk2] AsciiPrint behavior with \n linefeed characters.

2016-10-14 Thread Gao, Liming
Tim:
  PrintLib only says \n in format string to be converted. It keeps other string 
as-is. So, this is the expected behavior. 

Thanks
Liming
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Friday, October 14, 2016 10:05 AM
> To: Gao, Liming ; edk2-devel-01  de...@lists.01.org>
> Subject: RE: AsciiPrint behavior with \n linefeed characters.
> 
> Liming --
> 
> And I agree that this should be the behavior. I was surprised by the lack of
> translation for the other string printed via %s.
> 
> Tim
> 
> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Thursday, October 13, 2016 6:24 PM
> To: Tim Lewis ; edk2-devel-01  de...@lists.01.org>
> Subject: RE: AsciiPrint behavior with \n linefeed characters.
> 
> Tim:
>   The first parameter in AsciiPrint() is the Format string. Per PrintLib.h
> definition, \n will be changed to \r\n in the format string.
> 
> The following end of line(EOL) translations must be performed on the
> contents of the format string:
>  - '\\r' is translated to '\\r'
>  - '\\r\\n' is translated to '\\r\\n'
>  - '\\n' is translated to '\\r\\n'
>  - '\\n\\r' is translated to '\\r\\n'
> 
> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Tim Lewis
> Sent: Friday, October 14, 2016 5:29 AM
> To: edk2-devel-01 
> Subject: [edk2] AsciiPrint behavior with \n linefeed characters.
> 
> In using AsciiPrint (I'm presuming the behavior is also in Print, but I 
> haven't
> tested), I found an interesting behavior for linefeed characters embedded in
> strings that are parameters. I post it here just so people who are mystified 
> by
> their output can understand it.
> 
> Consider this example:
> 
> CONST CHAR16 *XyzStr = "HI\nBYE";
> 
> AsciiPrint(XyzStr);
> AsciiPrint("Offset\n%s\n", XyzStr);
> 
> Output looks like this:
> 
> HI
> BYE
> Offset
> HI
>BYE
> 
> It turns out that \n characters in the format string are converted to \r\n, 
> but
> \n characters in strings that are embedded (as in the second example) are
> not converted. So only the linefeed character is interpreted, leading to "BYE"
> being suspended one character to the right and one row lower than "HI"
> ___
> 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] NetworkPkg: Record user configured TargetIP/Port in iBFT

2016-10-14 Thread Zhang, Lubo
Reviewed-by: Zhang Lubo 

-Original Message-
From: Ye, Ting 
Sent: Thursday, September 29, 2016 1:59 PM
To: edk2-devel@lists.01.org
Cc: Subramanian; Sriram ; Fu, Siyuan ; 
Zhang, Lubo 
Subject: [Patch] NetworkPkg: Record user configured TargetIP/Port in iBFT

Current ISCSI driver records redirected iSCSI targetIP/Port in iBFT once 
redirection occurs, which removes the possibility of the OS to reconnect to the 
configured IP for load balancing. The behavior is not explicitly described in 
IBFT spec, though the MSFT expert confirm we should record original user 
setting rather than publish the redirected IP.

Thanks Sriram for reviewing and validating this patch in his test-bed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ye Ting 
Cc: Subramanian, Sriram 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
---
 NetworkPkg/IScsiDxe/IScsiDriver.c | 19 +++
 NetworkPkg/IScsiDxe/IScsiMisc.c   | 10 +-
 NetworkPkg/IScsiDxe/IScsiMisc.h   |  7 ++-
 NetworkPkg/IScsiDxe/IScsiProto.c  | 36 +---
 4 files changed, 55 insertions(+), 17 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.c 
b/NetworkPkg/IScsiDxe/IScsiDriver.c
index c3ab2c9..279f1c0 100644
--- a/NetworkPkg/IScsiDxe/IScsiDriver.c
+++ b/NetworkPkg/IScsiDxe/IScsiDriver.c
@@ -356,10 +356,11 @@ IScsiStart (
   CHAR16  MacString[ISCSI_MAX_MAC_STRING_LEN];
   BOOLEAN NeedUpdate;
   VOID*Interface;
   EFI_GUID*ProtocolGuid;
   UINT8   NetworkBootPolicy;
+  ISCSI_SESSION_CONFIG_NVDATA *NvData;
 
   //
   // Test to see if iSCSI driver supports the given controller.
   //
 
@@ -699,10 +700,28 @@ IScsiStart (
   Status = IScsiSessionLogin (Session);
 } else if (Status == EFI_NOT_READY) {
   Status = IScsiSessionReLogin (Session);
 }
 
+//
+// Restore the origial user setting which specifies the proxy/virtual 
iSCSI target to NV region.
+//
+NvData = >SessionConfigData;
+if (NvData->RedirectFlag) {
+  NvData->TargetPort = NvData->OriginalTargetPort;
+  CopyMem (>TargetIp, >OriginalTargetIp, sizeof 
(EFI_IP_ADDRESS));
+  NvData->RedirectFlag = FALSE;
+
+  gRT->SetVariable (
+ mPrivate->PortString,
+ ,
+ ISCSI_CONFIG_VAR_ATTR,
+ sizeof (ISCSI_ATTEMPT_CONFIG_NVDATA),
+ AttemptConfigData
+ );
+}
+
 if (EFI_ERROR (Status)) {
   //
   // In Single path mode, only the successful attempt will be recorded in 
iBFT;
   // in multi-path mode, all the attempt entries in MPIO will be recorded 
in iBFT.
   //
diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c 
index a39c268..64bb2ad 100644
--- a/NetworkPkg/IScsiDxe/IScsiMisc.c
+++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
@@ -1186,15 +1186,15 @@ IScsiGetConfigData (
   MacString,
   (UINTN) AttemptConfigOrder[Index]
   );
 
 GetVariable2 (
- mPrivate->PortString,
- ,
- (VOID**),
- NULL
- );
+  mPrivate->PortString,
+  ,
+  (VOID**),
+  NULL
+  );
 
 if (AttemptConfigData == NULL) {
   continue;
 }
 
diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.h b/NetworkPkg/IScsiDxe/IScsiMisc.h 
index 1bcaeb8..912a871 100644
--- a/NetworkPkg/IScsiDxe/IScsiMisc.h
+++ b/NetworkPkg/IScsiDxe/IScsiMisc.h
@@ -48,13 +48,18 @@ typedef struct _ISCSI_SESSION_CONFIG_NVDATA {
   CHAR8 TargetName[ISCSI_NAME_MAX_SIZE];
   EFI_IP_ADDRESSTargetIp;
   UINT8 PrefixLength;
   UINT8 BootLun[8];
 
-  UINT16ConnectTimeout; ///< timout value in milliseconds
+  UINT16ConnectTimeout; ///< timout value in milliseconds.
   UINT8 ConnectRetryCount;
   UINT8 IsId[6];
+
+  BOOLEAN   RedirectFlag;
+  UINT16OriginalTargetPort; // The port of proxy/virtual 
target.
+  EFI_IP_ADDRESSOriginalTargetIp;   // The address of proxy/virtual 
target.
+  
 } ISCSI_SESSION_CONFIG_NVDATA;
 #pragma pack()
 
 /**
   Calculate the prefix length of the IPv4 subnet mask.
diff --git a/NetworkPkg/IScsiDxe/IScsiProto.c b/NetworkPkg/IScsiDxe/IScsiProto.c
index 5092365..88d9bdd 100644
--- a/NetworkPkg/IScsiDxe/IScsiProto.c
+++ b/NetworkPkg/IScsiDxe/IScsiProto.c
@@ -1067,24 +1067,26 @@ IScsiUpdateTargetAddress (
   IN OUT ISCSI_SESSION *Session,
   IN CHAR8 *Data,
   IN UINT32Len
   )
 {
-  LIST_ENTRY  *KeyValueList;
-  CHAR8   *TargetAddress;
-  CHAR8   *IpStr;
-  EFI_STATUS  Status;
-  UINTN   Number;
-  UINT8   IpMode;
+  LIST_ENTRY  

[edk2] [Patch] MdePkg ACPI51: Update GIC version per ACPI 5.1 Errata B

2016-10-14 Thread Liming Gao
Fix issue: https://bugzilla.tianocore.org/show_bug.cgi?id=95

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdePkg/Include/IndustryStandard/Acpi51.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi51.h 
b/MdePkg/Include/IndustryStandard/Acpi51.h
index 034094e..f38aa46 100644
--- a/MdePkg/Include/IndustryStandard/Acpi51.h
+++ b/MdePkg/Include/IndustryStandard/Acpi51.h
@@ -1,8 +1,8 @@
 /** @file   
-  ACPI 5.1 definitions from the ACPI Specification Revision 5.1 July, 2014.
+  ACPI 5.1 definitions from the ACPI Specification Revision 5.1 Errata B 
January, 2016.
 
   Copyright (c) 2014 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2014 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
   (C) Copyright 2015 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 
@@ -537,8 +537,8 @@ typedef struct {
 ///
 /// GIC Version
 ///
-#define EFI_ACPI_5_1_GIC_V2   0x01
-#define EFI_ACPI_5_1_GIC_V2m  0x02
+#define EFI_ACPI_5_1_GIC_V1   0x01
+#define EFI_ACPI_5_1_GIC_V2   0x02
 #define EFI_ACPI_5_1_GIC_V3   0x03
 #define EFI_ACPI_5_1_GIC_V4   0x04
 
-- 
2.8.0.windows.1

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


[edk2] [patch] NetworkPkg: Add dns support for pxe boot based on IPv6.

2016-10-14 Thread Zhang Lubo
The BootFileURL option (59) in dhcpv6 is used to deliver
the next server address with bootfile name, as an example
"tftp://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]/BOOTFILE_NAME;
mode=octet", it can also be “tftp://domain_name/BOOTFILE_NAME;
mode=octet”, this patch is to support this case.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
---
 NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c  |  18 ++-
 NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c | 269 +++
 NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.h |   5 +-
 NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h  |   3 +
 NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf |   4 +-
 5 files changed, 261 insertions(+), 38 deletions(-)

diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
index 8eff13c..fc50a82 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
@@ -619,31 +619,33 @@ PxeBcDhcp6BootInfo (
   }
 
   ASSERT (Cache6->OptList[PXEBC_DHCP6_IDX_BOOT_FILE_URL] != NULL);
 
   //
+  // Set the station address to IP layer.
+  //
+  Status = PxeBcSetIp6Address (Private);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+
+  //
   // Parse (m)tftp server ip address and bootfile name.
   //
   Status = PxeBcExtractBootFileUrl (
+ Private,
  >BootFileName,
  >ServerIp.v6,
  (CHAR8 *) (Cache6->OptList[PXEBC_DHCP6_IDX_BOOT_FILE_URL]->Data),
  NTOHS (Cache6->OptList[PXEBC_DHCP6_IDX_BOOT_FILE_URL]->OpLen)
  );
   if (EFI_ERROR (Status)) {
 return Status;
   }
 
   //
-  // Set the station address to IP layer.
-  //
-  Status = PxeBcSetIp6Address (Private);
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
-  
-  //
   // Parse the value of boot file size.
   //
   if (Cache6->OptList[PXEBC_DHCP6_IDX_BOOT_FILE_PARAM] != NULL) {
 //
 // Parse it out if have the boot file parameter option.
diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c
index 41d3d30..45377e3 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c
@@ -91,14 +91,15 @@ PxeBcBuildDhcp6Options (
 
   //
   // Append client option request option
   //
   OptList[Index]->OpCode = HTONS (DHCP6_OPT_ORO);
-  OptList[Index]->OpLen  = HTONS (4);
+  OptList[Index]->OpLen  = HTONS (6);
   OptEnt.Oro = (PXEBC_DHCP6_OPTION_ORO *) OptList[Index]->Data;
   OptEnt.Oro->OpCode[0]  = HTONS(DHCP6_OPT_BOOT_FILE_URL);
   OptEnt.Oro->OpCode[1]  = HTONS(DHCP6_OPT_BOOT_FILE_PARAM);
+  OptEnt.Oro->OpCode[2]  = HTONS(DHCP6_OPT_DNS_SERVERS);
   Index++;
   OptList[Index] = GET_NEXT_DHCP6_OPTION (OptList[Index - 1]);
 
   //
   // Append client network device interface option
@@ -214,14 +215,177 @@ PxeBcFreeBootFileOption (
 RemoveEntryList (Entry);
 FreePool (Node);
   }
 }
 
+/**
+  Retrieve the boot server address using the EFI_DNS6_PROTOCOL.
+
+  @param[in]  Private Pointer to PxeBc private data.
+  @param[in]  HostNamePointer to buffer containing hostname.
+  @param[out] IpAddress   On output, pointer to buffer containing IPv6 
address.
+
+  @retval EFI_SUCCESS Operation succeeded.
+  @retval EFI_OUT_OF_RESOURCESFailed to allocate needed resources.
+  @retval EFI_DEVICE_ERRORAn unexpected network error occurred.
+  @retval Others  Other errors as indicated.
+  
+**/
+EFI_STATUS
+PxeBcDns6 (
+  IN PXEBC_PRIVATE_DATA   *Private,
+  IN CHAR16   *HostName,
+ OUT EFI_IPv6_ADDRESS *IpAddress
+  )
+{
+  EFI_STATUS  Status;
+  EFI_DNS6_PROTOCOL   *Dns6;
+  EFI_DNS6_CONFIG_DATADns6ConfigData;
+  EFI_DNS6_COMPLETION_TOKEN   Token;
+  EFI_HANDLE  Dns6Handle;
+  EFI_IPv6_ADDRESS*DnsServerList;
+  BOOLEAN IsDone;
+  
+  Dns6= NULL;
+  Dns6Handle  = NULL;
+  DnsServerList   = Private->DnsServer;
+  ZeroMem (, sizeof (EFI_DNS6_COMPLETION_TOKEN));
+
+  //
+  // Create a DNSv6 child instance and get the protocol.
+  //
+  Status = NetLibCreateServiceChild (
+ Private->Controller,
+ Private->Image,
+ ,
+ 
+ );
+  if (EFI_ERROR (Status)) {
+goto Exit;
+  } 
+  
+  Status = gBS->OpenProtocol (
+  Dns6Handle,
+  ,
+  (VOID **) ,
+  Private->Image,
+  Private->Controller,
+  EFI_OPEN_PROTOCOL_BY_DRIVER
+  );
+  if (EFI_ERROR (Status)) {
+goto Exit;
+  }
+
+  //
+  // Configure DNS6 instance for the DNS server address and protocol.
+  //
+  ZeroMem (, sizeof 

Re: [edk2] [RFC V2] EDK2 Platform Proposal

2016-10-14 Thread Kinney, Michael D
Leif,

I could see edk2-platforms/master being the platform branch that
contains the set of platforms that are synced with edk2/master and
are required to be tested when changes are made to edk2/master.
Or at least guaranteed to be tested when a stable release of 
edk2/master is made.

Similar to what we expect for the platforms in edk2/master such
as OvmfPkg, EmulatorPkg, and Nt32Pkg.

Given that not everyone would have access to platform targets to 
run tests, the minimum requirement could be build tests.

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Friday, October 14, 2016 12:15 AM
> To: Leif Lindholm ; Andrew Fish (af...@apple.com)
> ; Kinney, Michael D 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [RFC V2] EDK2 Platform Proposal
> 
> Leif and Andrew,
> 
> I have added the content of this proposal to a new Readme.md file in
> the edk2-platforms/about branch and removed the old README file.
> 
>   https://github.com/tianocore/edk2-platforms/tree/about
> 
> I have also added a template at the bottom of the process description
> for a Readme.md that describes multiple platforms with links to a
> Readme.md in each platform specific subdirectory.
> 
> I have also addressed the all the feedback from Leif except for
> adding platforms to edk2-platforms/master.  I think platforms
> should start in an edk2-platforms/devel-* branch and when they
> become stable move to an edk2-platforms/stable-* branch.  Stable
> branches may support multiple platform.
> 
> Using this model, there would not be an edk2-platforms/master
> branch.
> 
> Mike
> 
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Wednesday, September 28, 2016 3:23 PM
> > To: Kinney, Michael D 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [RFC V2] EDK2 Platform Proposal
> >
> > Hi Mike,
> >
> > On Thu, Sep 22, 2016 at 08:54:50PM +, Kinney, Michael D wrote:
> > > Hello,
> > >
> > >
> > >
> > > Here is the V2 version of the proposal for the edk2-platforms repo.
> >
> > I'm happy with the proposal in this state, but have a few suggested
> > updates (mostly to clarify that, long term, we expect most platforms
> > to exist in master) and a small suggested addition.
> >
> > > Changes from V1:
> > >
> > > 
> > >
> > > * edk2-platform is not a fork of edk2.
> > >
> > > * edk2-platforms branches contain CPU, Chipset, SoC, and platform specific
> > >
> > >   packages
> > >
> > > * edk2-plaforms/master contains all open platforms that are synced with
> > >
> > >   edk2/master.
> > >
> > > * Each edk2-platforms branch may support many platforms (not just one)
> > >
> > > * Use PACKAGES_PATH to do builds using packages from multiple repositories
> > >
> > > * Update edk2-platforms branch naming to clearly identify platforms that
> > >
> > >   are considered stable and platforms that are under active development.
> > >
> > > * edk2 developers may be required to verify platforms in edk2-platforms
> > >
> > >   builds as part of test criteria.  Especially platforms that are intended
> > >
> > >   to be used with edk2/master in edk2-platforms/stable-* branches.
> > >
> > >
> > >
> > > =
> > >
> > >
> > >
> > > Similar to edk2-staging, we also have a need to manage platforms
> > >
> > > that have been ported to edk2.  Jordan has created a repository
> > >
> > > called edk2-platforms and has created a branch for the
> > >
> > > minnowboard-max that uses a validated release of the UDK 2015 for
> > >
> > > the dependent packages:
> > >
> > >
> > >
> > > https://github.com/tianocore/edk2-platforms
> > >
> > >
> > >
> > > https://github.com/tianocore/edk2-platforms/tree/minnowboard-max-udk2015
> > >
> > >
> > >
> > > Instead of creating a branch per feature in edk2-staging, the
> > >
> > > proposal is to create a branch per platform or set of platforms
> > >
> > > in edk2-platforms.  The maintainer(s) that create and support a
> > >
> > > platform branch can decide if the platform uses edk2/master for
> > >
> > > dependent packages, or uses a stable release of the edk2 for dependent
> > >
> > > packages.
> > >
> > >
> > >
> > > This proposal provides an area for platform development so we can
> > >
> > > minimize the number of platforms that are included in edk2/master.
> > >
> > > It is important to keep some platforms in edk2/master so we can use
> > >
> > > those platforms to validate features in non-platform packages in
> > >
> > > edk2/master.  If a new platform does not add feature coverage to
> > >
> > > edk2/master, then an edk2-platforms branch would be recommended.
> >
> > Suggest: ", then edk2-platforms would be recommended.".
> >
> > >
> > >
> > > Please review the proposal below for edk2-platforms.
> > >
> > >
> > >
> > > If this proposal is accepted, then a review of the platforms in
> > >
> > > edk2/master can be done to see if any of 

Re: [edk2] [Patch] MdeModulePkg: Support classless IP for DHCPv4 TransmitReceive()

2016-10-14 Thread Santhapur Naveen
Hello Jiaxin,

We've run into one more problem with PXE boot. The PXE boot is not 
happening when the server tries to assign an IP address whose last octet is 
zero.

The below is my configuration:

[Server Configuration]
Ipv4 address : 192.168.0.1/16
Netmask: 255.255.0.0

DHCPv4 Scope:
Range: 192.168.0.2 to 192.168.10.10
Netmask: 255.255.0.0

I've observed that in the given address range, if the server tries to 
allocate any IP address with the last octet as 0 i.e., for instance 192.168.A.0 
where A vary from 1 to 10, then the PXE boot fails saying "PXE-E09: Could not 
allocate I/O buffers." 

I agree that the x.y.z.0 and x.y.z.255 are network address any can't be 
assigned based on the subnet (In this case, 192.168.0.0 and 192.168.255.255). 
But here, the Netmask is different which expects the IP address x.y.a.0 which 
is within the range is valid and can be assigned to any client in the network.

I captured Wireshark log and as per it, the D.O.R.A process is finished 
but the client is sending a Decline packet. I suspect the function 
NetIp4IsUnicast() has a role to play in this.

Please provide your comments on this.

Best regards,
Naveen

-Original Message-
From: Santhapur Naveen 
Sent: Friday, September 02, 2016 11:46 AM
To: 'Wu, Jiaxin'; 'edk2-devel@lists.01.org'
Cc: 'Ye, Ting'; 'Fu, Siyuan'
Subject: RE: [edk2] [Patch] MdeModulePkg: Support classless IP for DHCPv4 
TransmitReceive()

Hello Jiaxin,

My sincere apologies for the delayed response.

I've verified the patch from my side and PXE boot is happening 
successfully even in classless IP network.

May I know whether this will be included in EDK2? If yes, can you 
please provide any schedule for the same?

Best regards,
Naveen

-Original Message-
From: Santhapur Naveen
Sent: Thursday, August 18, 2016 11:14 AM
To: 'Wu, Jiaxin'; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Sivaraman Nainar; Madhan B. Santharam
Subject: RE: [edk2] [Patch] MdeModulePkg: Support classless IP for DHCPv4 
TransmitReceive()

Jiaxin,

We will verify the patch and update you the result.

Thanks,
Naveen

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Thursday, August 18, 2016 11:12 AM
To: Santhapur Naveen; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Sivaraman Nainar; Madhan B. Santharam
Subject: RE: [edk2] [Patch] MdeModulePkg: Support classless IP for DHCPv4 
TransmitReceive()

Naveen,

Can you help to verify this patch to support the classless IP.

Thanks,
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Jiaxin Wu
> Sent: Thursday, August 18, 2016 1:39 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; 
> Santhapur Naveen 
> Subject: [edk2] [Patch] MdeModulePkg: Support classless IP for DHCPv4
> TransmitReceive()
> 
> The IP address should not be treated as classful one if DHCP options 
> contain a classless IP with its true subnet mask. Otherwise, DHCPv4
> TransmitReceive() will failed. This real subnet mask will be parsed 
> and recorded in DhcpSb->Netmask. So, we need check it before get the 
> IP's corresponding subnet mask.
> 
> Cc: Santhapur Naveen 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  .../Universal/Network/Dhcp4Dxe/Dhcp4Impl.c | 28 +++-
> --
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> index 4f491b4..79f7cde 100644
> --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> @@ -1,9 +1,9 @@
>  /** @file
>This file implement the EFI_DHCP4_PROTOCOL interface.
> 
> -Copyright (c) 2006 - 2015, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2006 - 2016, Intel Corporation. All rights 
> +reserved.
>  This program and the accompanying materials  are licensed and made 
> available under the terms and conditions of the BSD License  which 
> accompanies this distribution.  The full text of the license may be 
> found at http://opensource.org/licenses/bsd-license.php
> 
> @@ -1186,18 +1186,20 @@ Dhcp4InstanceConfigUdpIo (
>IN UDP_IO   *UdpIo,
>IN VOID *Context
>)
>  {
>DHCP_PROTOCOL *Instance;
> +  DHCP_SERVICE  *DhcpSb;
>EFI_DHCP4_TRANSMIT_RECEIVE_TOKEN  *Token;
>EFI_UDP4_CONFIG_DATA  UdpConfigData;
>IP4_ADDR  ClientAddr;
>IP4_ADDR  Ip;
>INTN  Class;
>IP4_ADDR  SubnetMask;
> 
>Instance = 

Re: [edk2] [RFC V2] EDK2 Platform Proposal

2016-10-14 Thread Kinney, Michael D
Leif and Andrew,

I have added the content of this proposal to a new Readme.md file in
the edk2-platforms/about branch and removed the old README file.

  https://github.com/tianocore/edk2-platforms/tree/about

I have also added a template at the bottom of the process description
for a Readme.md that describes multiple platforms with links to a 
Readme.md in each platform specific subdirectory.

I have also addressed the all the feedback from Leif except for 
adding platforms to edk2-platforms/master.  I think platforms
should start in an edk2-platforms/devel-* branch and when they
become stable move to an edk2-platforms/stable-* branch.  Stable
branches may support multiple platform.

Using this model, there would not be an edk2-platforms/master
branch.

Mike


> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Wednesday, September 28, 2016 3:23 PM
> To: Kinney, Michael D 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC V2] EDK2 Platform Proposal
> 
> Hi Mike,
> 
> On Thu, Sep 22, 2016 at 08:54:50PM +, Kinney, Michael D wrote:
> > Hello,
> >
> >
> >
> > Here is the V2 version of the proposal for the edk2-platforms repo.
> 
> I'm happy with the proposal in this state, but have a few suggested
> updates (mostly to clarify that, long term, we expect most platforms
> to exist in master) and a small suggested addition.
> 
> > Changes from V1:
> >
> > 
> >
> > * edk2-platform is not a fork of edk2.
> >
> > * edk2-platforms branches contain CPU, Chipset, SoC, and platform specific
> >
> >   packages
> >
> > * edk2-plaforms/master contains all open platforms that are synced with
> >
> >   edk2/master.
> >
> > * Each edk2-platforms branch may support many platforms (not just one)
> >
> > * Use PACKAGES_PATH to do builds using packages from multiple repositories
> >
> > * Update edk2-platforms branch naming to clearly identify platforms that
> >
> >   are considered stable and platforms that are under active development.
> >
> > * edk2 developers may be required to verify platforms in edk2-platforms
> >
> >   builds as part of test criteria.  Especially platforms that are intended
> >
> >   to be used with edk2/master in edk2-platforms/stable-* branches.
> >
> >
> >
> > =
> >
> >
> >
> > Similar to edk2-staging, we also have a need to manage platforms
> >
> > that have been ported to edk2.  Jordan has created a repository
> >
> > called edk2-platforms and has created a branch for the
> >
> > minnowboard-max that uses a validated release of the UDK 2015 for
> >
> > the dependent packages:
> >
> >
> >
> > https://github.com/tianocore/edk2-platforms
> >
> >
> >
> > https://github.com/tianocore/edk2-platforms/tree/minnowboard-max-udk2015
> >
> >
> >
> > Instead of creating a branch per feature in edk2-staging, the
> >
> > proposal is to create a branch per platform or set of platforms
> >
> > in edk2-platforms.  The maintainer(s) that create and support a
> >
> > platform branch can decide if the platform uses edk2/master for
> >
> > dependent packages, or uses a stable release of the edk2 for dependent
> >
> > packages.
> >
> >
> >
> > This proposal provides an area for platform development so we can
> >
> > minimize the number of platforms that are included in edk2/master.
> >
> > It is important to keep some platforms in edk2/master so we can use
> >
> > those platforms to validate features in non-platform packages in
> >
> > edk2/master.  If a new platform does not add feature coverage to
> >
> > edk2/master, then an edk2-platforms branch would be recommended.
> 
> Suggest: ", then edk2-platforms would be recommended.".
> 
> >
> >
> > Please review the proposal below for edk2-platforms.
> >
> >
> >
> > If this proposal is accepted, then a review of the platforms in
> >
> > edk2/master can be done to see if any of them should be moved to
> >
> > branches in edk2-platforms.
> 
> Suggest: "should be moved to edk2-platforms.".
> >
> >
> >
> > 
> >
> >
> >
> > Problem statement
> >
> > =
> >
> > Need place on tianocore.org where platforms can be maintained by the
> >
> > EDK II community.  This serves several purposes:
> >
> >
> >
> > * Encourage more platforms sources to be shared earlier in the
> >
> >   development process
> >
> > * Allow platform sources to be shared that may not yet meet all edk2
> >
> >   required quality criteria
> >
> > * Allow platform source to be shared so the EDK II community may
> >
> >   choose to help finish and validate
> >
> > * Allow more platforms to be used as part of the edk2 validation and
> >
> >   release cycle.
> >
> > * Not intended to be used for bug fixes.
> 
> Does this final point still apply, now we're going to be using
> PACKAGES_PATH rather than keep rebasing on top of edk2/master?
> 
> >
> >
> >
> > Proposal
> >
> > 
> >
> > 1) Create a new repo called edk2-platforms
> >
> > a) The default branch edk2-platforms/master contains 

Re: [edk2] [[patch]] UefiCpuPkg/Cpuid: Remove wrong while-loop check after for-loop

2016-10-14 Thread Gao, Liming
Reviewed-by: Liming Gao 

> -Original Message-
> From: Fan, Jeff
> Sent: Friday, October 14, 2016 3:04 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
> ; Tian, Feng 
> Subject: [[patch]] UefiCpuPkg/Cpuid: Remove wrong while-loop check after
> for-loop
> 
> while-loop check should not co-exist with for-loop. This should be typo when
> we
> check-in the original code. We should keep one loop only.
> 
> This issue caused CLANG38 build failure reported by
> https://tianocore.acgmultimedia.com/show_bug.cgi?id=148
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Cc: Liming Gao 
> Cc: Michael Kinney 
> Cc: Feng Tian 
> Signed-off-by: Jeff Fan 
> ---
>  UefiCpuPkg/Application/Cpuid/Cpuid.c | 3 +--
>  UefiCpuPkg/Include/Register/Cpuid.h  | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> index 8726a85..ac14c41 100644
> --- a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> +++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> @@ -617,8 +617,7 @@ CpuidStructuredExtendedFeatureFlags (
>PRINT_BIT_FIELD (Ecx, PKU);
>PRINT_BIT_FIELD (Ecx, OSPKE);
>  }
> -SubLeaf++;
> -  } while (SubLeaf <= Eax);
> +  }
>  }
> 
>  /**
> diff --git a/UefiCpuPkg/Include/Register/Cpuid.h
> b/UefiCpuPkg/Include/Register/Cpuid.h
> index eb24840..864108d 100644
> --- a/UefiCpuPkg/Include/Register/Cpuid.h
> +++ b/UefiCpuPkg/Include/Register/Cpuid.h
> @@ -1275,8 +1275,7 @@ typedef union {
>SubLeaf,
>NULL, , , NULL
>);
> -SubLeaf++;
> -  } while (SubLeaf <= Eax);
> +  }
>@endcode
>  **/
>  #define CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS0x07
> --
> 2.9.3.windows.2

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


[edk2] [Patch] MdePkg BaseSynchronizationLib: Update InterlockedCompareExchange64.nasm

2016-10-14 Thread Liming Gao
Remove extra qword in nasm code to make it pass build.
This file is only built in INTEL ICC compiler. So, there is missing
build check for it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 .../BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm
index ee63ff7..206de40 100644
--- 
a/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm
+++ 
b/MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange64.nasm
@@ -41,7 +41,7 @@ ASM_PFX(InternalSyncCompareExchange64):
 mov edx, [esp + 20]
 mov ebx, [esp + 24]
 mov ecx, [esp + 28]
-lockcmpxchg8b   qword [esi]
+lockcmpxchg8b [esi]
 pop ebx
 pop esi
 ret
-- 
2.8.0.windows.1

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


[edk2] [patch] NetworkPkg: Support bracketed IPv6 address during a redirection in iSCSI

2016-10-14 Thread Zhang Lubo
According to RFC 3720, the TargetAddress provided in a redirection
might be a DNS host name, a dotted-decimal IPv4 address, or a
bracketed IPv6 address. Current ISCSI driver in Networkpkg only
supports dotted-decimal IPv4 address, so we need add IPv6 address
support since it is a combo driver supporting dual stack.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
---
 NetworkPkg/IScsiDxe/IScsiProto.c | 51 ++--
 NetworkPkg/IScsiDxe/IScsiProto.h |  5 +++-
 2 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiProto.c b/NetworkPkg/IScsiDxe/IScsiProto.c
index 5092365..a9bf491 100644
--- a/NetworkPkg/IScsiDxe/IScsiProto.c
+++ b/NetworkPkg/IScsiDxe/IScsiProto.c
@@ -1087,26 +1087,53 @@ IScsiUpdateTargetAddress (
 TargetAddress = IScsiGetValueByKeyFromList (KeyValueList, 
ISCSI_KEY_TARGET_ADDRESS);
 if (TargetAddress == NULL) {
   break;
 }
 
-if (!NET_IS_DIGIT (TargetAddress[0])) {
+//
+// RFC 3720 defines format of the 
TargetAddress=domainname[:port][,portal-group-tag]
+// The domainname can be specified as either a DNS host name, 
adotted-decimal IPv4 address,
+// or a bracketed IPv6 address as specified in [RFC2732].
+//
+if (NET_IS_DIGIT (TargetAddress[0])) {
   //
-  // The domainname of the target may be presented in three formats: a DNS 
host name,
-  // a dotted-decimal IPv4 address, or a bracketed IPv6 address. Only 
accept dotted
-  // IPv4 address.
+  // The domainname of the target is presented in a dotted-decimal IPv4 
address format.
   //
-  continue;
-}
-
-IpStr = TargetAddress;
+  IpStr = TargetAddress;
 
-while ((*TargetAddress != 0) && (*TargetAddress != ':') && (*TargetAddress 
!= ',')) {
+  while ((*TargetAddress != '\0') && (*TargetAddress != ':') && 
(*TargetAddress != ',')) {
+//
+// NULL, ':', or ',' ends the IPv4 string.
+//
+TargetAddress++;
+  }
+  
+} else if (*TargetAddress == ISCSI_REDIRECT_ADDR_START_DELIMITER){
   //
-  // NULL, ':', or ',' ends the IPv4 string.
+  // The domainname of the target is presented in a bracketed IPv6 address 
format.
   //
-  TargetAddress++;
+  TargetAddress ++;
+  IpStr = TargetAddress;
+  while ((*TargetAddress != '\0') && (*TargetAddress != 
ISCSI_REDIRECT_ADDR_END_DELIMITER)) {
+//
+// ']' ends the IPv6 string.
+//
+TargetAddress++;
+  }
+
+  if (*TargetAddress != ISCSI_REDIRECT_ADDR_END_DELIMITER) {
+continue;
+  }
+
+  *TargetAddress = '\0';
+  TargetAddress ++;
+
+} else {
+  //
+  // The domainname of the target is presented in the format of a DNS host 
name.
+  // Temporary not supported.
+  continue;
 }
 
 if (*TargetAddress == ',') {
   //
   // Comma and the portal group tag MUST be ommitted if the TargetAddress 
is sent
@@ -1124,11 +1151,11 @@ IScsiUpdateTargetAddress (
   } else {
 Session->ConfigData->SessionConfigData.TargetPort = (UINT16) Number;
   }
 } else {
   //
-  // The string only contains the IPv4 address. Use the well-known port.
+  // The string only contains the Target address. Use the well-known port.
   //
   Session->ConfigData->SessionConfigData.TargetPort = 
ISCSI_WELL_KNOWN_PORT;
 }
 //
 // Update the target IP address.
diff --git a/NetworkPkg/IScsiDxe/IScsiProto.h b/NetworkPkg/IScsiDxe/IScsiProto.h
index 8099f34..367914d 100644
--- a/NetworkPkg/IScsiDxe/IScsiProto.h
+++ b/NetworkPkg/IScsiDxe/IScsiProto.h
@@ -1,9 +1,9 @@
 /** @file
   The header file of iSCSI Protocol that defines many specific data structures.
 
-Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -38,10 +38,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define DEFAULT_MAX_OUTSTANDING_R2T 1
 
 #define ISCSI_VERSION_MAX   0x00
 #define ISCSI_VERSION_MIN   0x00
 
+#define ISCSI_REDIRECT_ADDR_START_DELIMITER '['
+#define ISCSI_REDIRECT_ADDR_END_DELIMITER   ']'
+
 #define ISCSI_KEY_AUTH_METHOD   "AuthMethod"
 #define ISCSI_KEY_HEADER_DIGEST "HeaderDigest"
 #define ISCSI_KEY_DATA_DIGEST   "DataDigest"
 #define ISCSI_KEY_MAX_CONNECTIONS   "MaxConnections"
 #define ISCSI_KEY_TARGET_NAME   

[edk2] [PATCH v2] MdeModulePkg/BootMaintenanceUi: Enhance the codes logic

2016-10-14 Thread Dandan Bi
This patch is mainly to:
1. Enhance the error handling codes when set variable fail.
2. Enhance the logic to fix some incorrect UI behaviors.

V2: Update the Console/Terminal menu when the related question changed.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../BootMaintenanceManagerUiLib/BootMaintenance.c  | 390 -
 .../BootMaintenanceManagerUiLib/UpdatePage.c   |  42 ++-
 .../Library/BootMaintenanceManagerUiLib/Variable.c |  28 +-
 3 files changed, 357 insertions(+), 103 deletions(-)

diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
index a190596..924eb49 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
@@ -442,10 +442,197 @@ BmmExtractDevicePathFromHiiHandle (
   return ConvertDevicePathToText(DevicePathFromHandle (DriverHandle), FALSE, 
FALSE);
 
 }
 
 /**
+  Converts the unicode character of the string from uppercase to lowercase.
+  This is a internal function.
+
+  @param ConfigString  String to be converted
+
+**/
+VOID
+HiiToLower (
+  IN EFI_STRING  ConfigString
+  )
+{
+  EFI_STRING  String;
+  BOOLEAN Lower;
+
+  ASSERT (ConfigString != NULL);
+
+  //
+  // Convert all hex digits in range [A-F] in the configuration header to [a-f]
+  //
+  for (String = ConfigString, Lower = FALSE; *String != L'\0'; String++) {
+if (*String == L'=') {
+  Lower = TRUE;
+} else if (*String == L'&') {
+  Lower = FALSE;
+} else if (Lower && *String >= L'A' && *String <= L'F') {
+  *String = (CHAR16) (*String - L'A' + L'a');
+}
+  }
+}
+
+/**
+  Update the progress string through the offset value.
+
+  @param Offset   The offset value
+  @param ConfigurationPoint to the configuration string.
+
+**/
+EFI_STRING
+UpdateProgress(
+  IN  UINTN   Offset,
+  IN  EFI_STRING  Configuration
+)
+{
+  UINTN   Length;
+  EFI_STRING  StringPtr;
+  EFI_STRING  ReturnString;
+
+  StringPtr= NULL;
+  ReturnString = NULL;
+
+  //
+  // = followed by a Null-terminator.
+  // Length = StrLen (L"=") + 4 + 1
+  //
+  Length= StrLen (L"=") + 4 + 1;
+
+  StringPtr = AllocateZeroPool (Length * sizeof (CHAR16));
+
+  if (StringPtr == NULL) {
+return  NULL;
+  }
+
+  UnicodeSPrint (
+StringPtr,
+(8 + 4 + 1) * sizeof (CHAR16),
+L"=%04x",
+Offset
+);
+
+  ReturnString = StrStr (Configuration, StringPtr);
+
+  if (ReturnString == NULL) {
+//
+// If doesn't find the string in Configuration, convert the string to 
lower case then search again.
+//
+HiiToLower (StringPtr);
+ReturnString = StrStr (Configuration, StringPtr);
+  }
+
+  FreePool (StringPtr);
+
+  return ReturnString;
+}
+
+/**
+  Update the terminal content in TerminalMenu.
+
+  @param BmmData   The BMM fake NV data.
+
+**/
+VOID
+UpdateTerminalContent (
+  IN BMM_FAKE_NV_DATA   *BmmData
+  )
+{
+  UINT16  Index;
+  BM_TERMINAL_CONTEXT *NewTerminalContext;
+  BM_MENU_ENTRY   *NewMenuEntry;
+
+  for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+NewMenuEntry = BOpt_GetMenuEntry (, Index);
+ASSERT (NewMenuEntry != NULL);
+NewTerminalContext = (BM_TERMINAL_CONTEXT *) NewMenuEntry->VariableContext;
+NewTerminalContext->BaudRateIndex = BmmData->COMBaudRate[Index];
+ASSERT (BmmData->COMBaudRate[Index] < (sizeof (BaudRateList) / sizeof 
(BaudRateList[0])));
+NewTerminalContext->BaudRate  = 
BaudRateList[BmmData->COMBaudRate[Index]].Value;
+NewTerminalContext->DataBitsIndex = BmmData->COMDataRate[Index];
+ASSERT (BmmData->COMDataRate[Index] < (sizeof (DataBitsList) / sizeof 
(DataBitsList[0])));
+NewTerminalContext->DataBits  = (UINT8) 
DataBitsList[BmmData->COMDataRate[Index]].Value;
+NewTerminalContext->StopBitsIndex = BmmData->COMStopBits[Index];
+ASSERT (BmmData->COMStopBits[Index] < (sizeof (StopBitsList) / sizeof 
(StopBitsList[0])));
+NewTerminalContext->StopBits  = (UINT8) 
StopBitsList[BmmData->COMStopBits[Index]].Value;
+NewTerminalContext->ParityIndex   = BmmData->COMParity[Index];
+ASSERT (BmmData->COMParity[Index] < (sizeof (ParityList) / sizeof 
(ParityList[0])));
+NewTerminalContext->Parity= (UINT8) 
ParityList[BmmData->COMParity[Index]].Value;
+NewTerminalContext->TerminalType  = BmmData->COMTerminalType[Index];
+NewTerminalContext->FlowControl   = BmmData->COMFlowControl[Index];
+ChangeTerminalDevicePath (
+  NewTerminalContext->DevicePath,
+  FALSE
+  );
+  }
+}
+
+/**
+  Update the console content in ConsoleMenu.
+
+  @param BmmData   The BMM fake NV data.
+
+**/
+VOID
+UpdateConsoleContent(
+  IN CHAR16