Re: [edk2] [edk2-test][PATCH v1 30/30] UEFI/UEFI.dec: Add missing protocol GUIDs in declaration file.

[Jin, Eric]

Hi Supreeth,

Thanks a lot to fix this build issue at first.
Comments for this series of patches are replied below.

Patch 1/2 : 
1. Could the two patches can be re-organized? For example, merge the change of 
*.dsc in patch 2 to patch 1 to make it clear.
2. The change of CommonGenFramework.sh in patch 2 will remove the ebc from 
binary package. 
 
Patch 24 : 
1. Please don't forget change the copyright part
2. Do you meet the similar issue that "UEFI_CONFIG_LANG" : macro redefinition 
while build?

Other Patches :
1. Please remove "COMPONENT_TYPE   = BS_DRIVER"

With that
Reviewed-by: Eric Jin 

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Friday, March 29, 2019 7:12 AM
To: edk2-devel@lists.01.org
Cc: Supreeth Venkatesh ; Jin, Eric 

Subject: [edk2-test][PATCH v1 30/30] UEFI/UEFI.dec: Add missing protocol GUIDs 
in declaration file.

Fix compilation issues in inf files when compiled against edk2 stable tag 
edk2-stable201903.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 uefi-sct/SctPkg/UEFI/UEFI.dec | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-sct/SctPkg/UEFI/UEFI.dec 
index 8495a4e1..bdf3323f 100644
--- a/uefi-sct/SctPkg/UEFI/UEFI.dec
+++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
@@ -1,7 +1,7 @@
 ## @file
 #
 #  Copyright 2004 - 2017 Unified EFI, Inc. -#  Copyright (c) 2014 - 2018, 
ARM Limited. All rights reserved.
+#  Copyright (c) 2014 - 2019, ARM Limited. All rights reserved.
 #  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.  #  
(C) Copyright 2017 Hewlett Packard Enterprise Development LP  # @@ -119,14 
+119,22 @@
   gBlackBoxEfiHIIStringProtocolGuid = {0xfd96974, 0x23aa, 0x4cdc, { 0xb9, 
0xcb, 0x98, 0xd1, 0x77, 0x50, 0x32, 0x2a }}
   gBlackBoxEfiHIIImageProtocolGuid = { 0x31a6406a, 0x6bdf, 0x4e46, {0xb2, 
0xa2, 0xeb, 0xaa, 0x89, 0xc4, 0x9, 0x20 }}
   gBlackBoxEfiHIIImageExProtocolGuid = { 0x1a1241e6, 0x8f19, 0x41a9, { 0xbc, 
0xe, 0xe8, 0xef,0x39, 0xe0, 0x65, 0x46 }}
+  gBlackBoxEfiHIIDatabaseProtocolGuid = { 0xef9fc172, 0xa1b2, 0x4693, { 
+ 0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42 }}  
+ gBlackBoxEfiHIIPackageListProtocolGuid = { 0x6a1ee763, 0xd47a, 0x43b4, 
+ { 0xaa, 0xbe, 0xef, 0x1d, 0xe2, 0xab, 0x56, 0xfc }}  
+ gBlackBoxEfiHIIStringProtocolGuid = {0xfd96974, 0x23aa, 0x4cdc, { 
+ 0xb9, 0xcb, 0x98, 0xd1, 0x77, 0x50, 0x32, 0x2a }}  
+ gBlackBoxEfiHIIConfigAccessProtocolGuid = { 0x330d4706, 0xf2a0, 
+ 0x4e4f, { 0xa3, 0x69, 0xb6, 0x6f, 0xa8, 0xd5, 0x43, 0x85 }}  
+ gBlackBoxEfiHIIConfigRoutingProtocolGuid = { 0x587e72d7, 0xcc50, 
+ 0x4f79, { 0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f }}
   gBlackBoxEfiHIIFontProtocolGuid = { 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 
0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43, 0x24 }}
   gBlackBoxEfiHIIFontExProtocolGuid = { 0x849e6875, 0xdb35, 0x4df8, { 0xb4, 
0x1e, 0xc8, 0xf3, 0x37, 0x18, 0x7, 0x3f }}
   gBlackBoxEfiHttpProtocolGuid = { 0x7A59B29B, 0x910B, 0x4171, { 0x82, 0x42, 
0xA8, 0x5A, 0x0D, 0xF2, 0x5B, 0x5B }}
   gBlackBoxEfiHttpServiceBindingProtocolGuid = { 0xbdc8e6af, 0xd9bc, 0x4379, { 
0xa7, 0x2a, 0xe0, 0xc4, 0xe7, 0x5d, 0xae, 0x1c }}
   gBlackBoxEfiIp4ServiceBindingProtocolGuid = { 0xc51711e7, 0xb4bf, 0x404a, 
{0xbf, 0xb8, 0x0a, 0x04, 0x8e, 0xf1, 0xff, 0xe4 } }
   gBlackBoxEfiIp4ProtocolGuid = { 0x41d94cd2, 0x35b6, 0x455a, {0x82, 0x58, 
0xd4, 0xe5, 0x13, 0x34, 0xaa, 0xdd } }
+  gBlackBoxEfiIp4ConfigProtocolGuid = { 0x3B95AA31, 0x3793, 0x434B, 
+ {0x86, 0x67, 0xC8, 0x07, 0x08, 0x92, 0xE0, 0x5E } }  
+ gBlackBoxEfiIp4Config2ProtocolGuid = { 0x5b446ed1, 0xe30b, 0x4faa, 
+ {0x87, 0x1a, 0x36, 0x54, 0xec, 0xa3, 0x60, 0x80 } }
   gBlackBoxEfiIp6ServiceBindingProtocolGuid = { 0xec835dd3, 0xfe0f, 0x617b, 
{0xa6, 0x21, 0xb3, 0x50, 0xc3, 0xe1, 0x33, 0x88 } }
   gBlackBoxEfiIp6ProtocolGuid = { 0xec835dd3, 0xfe0f, 0x617b, {0xa6, 0x21, 
0xb3, 0x50, 0xc3, 0xe1, 0x33, 0x88 } }
+  gBlackBoxEfiIp6ConfigProtocolGuid = { 0x937fe521, 0x95ae, 0x4d1a, 
+ {0x89, 0x29, 0x48, 0xbc, 0xd9, 0x0a, 0xd3, 0x1a } }
   gBlackBoxEfiIPsec2ProtocolGuid = {0xa3979e64, 0xace8, 0x4ddc, { 0xbc, 0x7, 
0x4d, 0x66, 0xb8, 0xfd, 0x9, 0x77 }}
   gBlackBoxEfiIPsecConfigProtocolGuid = { 0xce5e5929, 0xc7a3, 0x4602, { 0xad, 
0x9e, 0xc9, 0xda, 0xf9, 0x4e, 0xbf, 0xcf }}
   gBlackBoxEfiIScsiInitiatorNameProtocolGuid = { 0x59324945, 0xec44, 0x4c0d, 
{0xb1, 0xcd, 0x9d, 0xb1, 0x39, 0xdf, 0x7, 0xc }}
--
2.17.1

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

Re: [edk2] [edk2-test][PATCH v2] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool

[Jin, Eric]

Hi Supreeth,

This patch can't be applied to the lasted code base SHA-1: 33022e. 
One patch from  may already fix the issue. Please check again.

Best Regards
Eric

-Original Message-
From: edk2-devel  On Behalf Of Supreeth 
Venkatesh
Sent: Friday, March 29, 2019 7:08 AM
To: supreeth.venkat...@arm.com; edk2-devel@lists.01.org
Subject: [edk2] [edk2-test][PATCH v2] SctPkg/Tools: Fix incorrect line ending 
detection by GenBin tool

From: Lokesh B V 

Some windows editors uses "\r\n" for line feed. While processing uefi sct 
testcase info file, the GenBin tool logic to skip line feed doesn't consider 
the presence of carraige return(\r) in line feed. So this results in incorrect 
format error.

Fixed this issue by changing logic of Trim and Getline functions used in GenBin 
source code.

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Lokesh B V 
---
Changes since v1:
* Adopted changes suggested by Supreeth.
* modified Copyright content

 uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 58 +---
 1 file changed, 26 insertions(+), 32 deletions(-)

diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index 61bb35b..6d8e844 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -2,6 +2,7 @@
 
   Copyright 2006 - 2010 Unified EFI, Inc.
   Copyright (c) 2010 Intel Corporation. All rights reserved.
+  Copyright (c) 2018 ARM Ltd. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License @@ -32,6 +33,7 @@ Abstract:
 #include 
 #include 
 #include 
+#include 
 
 //
 // Definitions
@@ -49,7 +51,7 @@ PrintUsage (
   void
   );
 
-void
+char *
 Trim (
   char*String
   );
@@ -159,50 +161,42 @@ PrintUsage (
 }
 
 
-void
+char *
 Trim (
   char*String
   )
 {
-  int   Index1;
-  int   Index2;
   int   Length;
+  char  *end;
 
   Length = strlen (String);
 
-  //
-  // Remove the space characters from the beginning of this string
-  //
-  for (Index1 = 0; Index1 < Length; Index1++) {
-if ((String[Index1] != ' ' ) &&
-(String[Index1] != '\t') &&
-(String[Index1] != '\n')) {
-  break;
-}
-  }
-
-  for (Index2 = Index1; Index2 < Length; Index2++) {
-String[Index2 - Index1] = String[Index2];
+  if (!Length) {
+return String;
   }
 
-  Length = Length - Index1;
+  end = String + Length - 1;
 
   //
   // Remove the space characters from the end of this string
   //
-  for (Index1 = 0; Index1 < Length; Index1++) {
-if ((String[Length - 1 - Index1] != ' ' ) &&
-(String[Length - 1 - Index1] != '\t') &&
-(String[Length - 1 - Index1] != '\n')) {
-  break;
-}
+  while (end >= String && isspace (*end)) {
+end--;
   }
 
-  String[Length - Index1] = '\0';
+  *(end + 1) = '\0';
+
+  //
+  // Remove the space characters from the beginning of this string  //  
+ while (*String && isspace (*String)) {
+String++;
+  }
 
   //
   // Done
   //
+  return String;
 }
 
 
@@ -227,20 +221,20 @@ GetLine (
   return -1;
 }
 
-(*LineNo)++;
-
 //
 // Remove the beginning and ending space characters
 //
-Trim (String);
+String = Trim (Result);
 
 //
-// Ignore the empty line and comment line
+// Skip the empty line and comment line
 //
-if ((String[0] != '\0') &&
-(String[0] != '#' )) {
-  break;
+if ((String[0] == '\0') ||
+(String[0] == '#' )) {
+  continue;
 }
+
+(*LineNo)++;
   }
 
   //
--
2.7.4


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

Re: [edk2] [edk2-test][Patch 1/1] uefi-sct/SctPkg: Size in EraseBlocks() is in bytes

[Jin, Eric]

Supreeth,

Thank for the rewording suggestion. 
Will commit the patch with accurate message.

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Tuesday, March 19, 2019 3:45 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Subject: Re: [edk2-test][Patch 1/1] uefi-sct/SctPkg: Size in EraseBlocks() is 
in bytes

On Mon, 2019-03-11 at 13:29 +0800, Eric Jin wrote:
> The erase size used in current test is blocks number,
Please reword. Block number or number of blocks?

> and should be corrected to the size in bytes to be erased. According 
> to UEFI spec, it must be a multiple of the physical block size of the 
> device, even the EraseLengthGranularity blocks for some device.
Please reword. 

Suggestion:
Currently, EFI_ERASE_BLOCK_PROTOCOL test to validate erase functionality of a 
device incorrectly used "BlockNumber" which does not reflect the actual size in 
bytes to be erased.
This patch corrects this by calculating size in bytes to be erased using 
"EraseLengthGranularity" and "BlockSize".
or Something similar.

With that
Reviewed-by: Supreeth Venkatesh 

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBl
> ockBBTestConformance.c | 25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBl
> ockBBTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBl
> ockBBTestConformance.c
> index df057b26667f..a6156b988f44 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBl
> ockBBTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/EraseBlock/BlackBoxTest/EraseBl
> ockBBTestConformance.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2017 Unified EFI, Inc.
> -  Copyright (c) 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2017 - 2019, 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 @@ -51,8 +51,8 @@ BBTestEraseBlocksConformanceTest (
>UINT32BlockSize;
>UINT32IoAlign;
>EFI_LBA   LastBlock;
> -
> -  UINT32BlockNumber;
> +  UINT32EraseLengthGranularity;
> +  UINTN EraseSize;
>  
>EFI_ERASE_BLOCK_TOKEN Token;
>  
> @@ -121,10 +121,11 @@ BBTestEraseBlocksConformanceTest (
>IoAlign   = Media->IoAlign;
>LastBlock = Media->LastBlock;
>  
> -  BlockNumber   = (UINT32) MINIMUM(LastBlock,
> MAX_NUMBER_OF_READ_BLOCK_BUFFER);
> +  EraseLengthGranularity = EraseBlock->EraseLengthGranularity;
> +  EraseSize  = (UINTN)SctMultU64x32
> (EraseLengthGranularity, BlockSize);
>  
>if (MediaPresent == FALSE) {
> -Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0, ,
> BlockNumber);
> +Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0, ,
> EraseSize);
>  if (Status == EFI_NO_MEDIA)
>AssertionType = EFI_TEST_ASSERTION_PASSED;
>  else
> @@ -141,7 +142,7 @@ BBTestEraseBlocksConformanceTest (
>   Status
>   );
>  
> -Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock
> + 1, , BlockNumber);
> +Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock 
> + 1, , EraseSize);
>  if (Status == EFI_NO_MEDIA)
>AssertionType = EFI_TEST_ASSERTION_PASSED;
>  else
> @@ -158,7 +159,7 @@ BBTestEraseBlocksConformanceTest (
>   Status
>   );
>  
> -Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock
> - 10, , BlockNumber + 1);
> +Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, LastBlock
> - 10, , EraseSize + 1);
>  if (Status == EFI_NO_MEDIA)
>AssertionType = EFI_TEST_ASSERTION_PASSED;
>  else
> @@ -177,7 +178,7 @@ BBTestEraseBlocksConformanceTest (
>   
>} else {
>  if (ReadOnly == TRUE) {
> -  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0,
> , BlockNumber);
> +  Status = EraseBlock->EraseBlocks(EraseBlock, MediaId, 0,
> , EraseSize);
>if (Status == EFI_WRITE_PROTECTED)
>  AssertionType = EFI_TEST_ASSERTION_PASSED;
>else
> @@ -195,7 +196,7 @@ BBTestEraseBlocksConformanceTest (
&

Re: [edk2] [edk2-test][Patch 1/1] uefi-sct/SctPkg:Fix flaw in BBTestCreateEventEx_Func_Sub3

[Jin, Eric]

Supreeth,

Thank for the comment and add buffer layout description in committed code for 
better readable. Thanks.

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh [mailto:supreeth.venkat...@arm.com] 
Sent: Friday, March 8, 2019 5:25 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Subject: Re: [edk2-test][Patch 1/1] uefi-sct/SctPkg:Fix flaw in 
BBTestCreateEventEx_Func_Sub3

On Thu, 2019-03-07 at 09:23 +0800, Eric Jin wrote:
> The intention of test is to validate the signal sequence among three 
> events with gEfiEventMemoryMapChangeGuid and different Tpl. The call 
> of AllocatePages() causes memorymap change and trigger event Notify.
> But the test has an assumption that CreateEventEx() will not cause 
> memorymap change itself, which is not true. When memory pool is out of 
> resource, the memory service will be called to reserve more memory 
> pool.
> The fix is to filter the exception and only leave memorymap change 
> caused by AllocatePages() in test.
> 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 


Minor comment about parenthesis to make multiple conditions priority more 
readable. Please fix this. With that
Reviewed-by: Supreeth Venkatesh 

> ---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h  
> |  5 +++--
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> | 26 +++---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/Support.c   
> | 23 +--
>  3 files changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h b/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
> index 4431b5b22888..87451f9f9a91 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2016, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2019, 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 @@ -49,7 +49,8 @@ Abstract:
>   Status \
>   );
>  
> -#define MAX_TEST_EVENT_NUM 3
> +#define MAX_TEST_EVENT_NUM3
> +#define SIGNAL_CONTEXT0xAA//To check the buffer content
> is modifed by exception or not
>  //
>  // Prototypes: Test Cases
>  //
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> index e2e173ab04c0..4a8e44e29b4e 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServi
> ces/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2016, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2019, 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 @@ -192,6 +192,10 @@ BBTestCreateEventEx_Func (
>BBTestCreateEventEx_Func_Sub2 (StandardLib);  #endif
>  
> +  //
> +  // The test for the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE  // This 
> + event group is notified by the system when the memory map
> has changed.
> +  //
>BBTestCreateEventEx_Func_Sub3 (StandardLib);
>  
>//
> @@ -599,12 +603,12 @@ BBTestCreateEventEx_Func_Sub1 (
>UINTN   Buffer[MAX_TEST_EVENT_NUM +
> MAX_TEST_EVEN

Re: [edk2] [edk2-test][Patch] uefi-sct/SctPkg:Correct Enable parameter in ReceiveFilters test

[Jin, Eric]

Supreeth,

Yes, the MAC here is the purpose for test data only.
I will add the comment to clarify it when I push the code.

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Friday, January 18, 2019 5:01 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Subject: Re: [edk2-test][Patch] uefi-sct/SctPkg:Correct Enable parameter in 
ReceiveFilters test


MAC address is hardcoded below which needs a comment or clarification to say it 
is test data (if it really is).
Otherwise, its good to go.

On Tue, 2018-11-27 at 14:02 +0800, Eric Jin wrote:
> The patch is applied to the EFI part.
> 
> Fix bug - set EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit in Enable 
> parameter to make sure Multicast is enabled.
> Add one checkpoint when MCastFilterCount is zero
> 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
Acked-by: Supreeth Venkatesh 

> ---
>  .../EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.c |   4 +-
>  .../EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid.h |   7 +-
>  .../BlackBoxTest/SimpleNetworkBBTestConformance.c  | 198
> -
>  3 files changed, 119 insertions(+), 90 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .c
> index 6ea6c4c..7234323 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2016, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2018, 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 @@ -112,6 +112,8 @@ EFI_GUID
> gSimpleNetworkBBTestConformanceAssertionGuid041 = 
> EFI_TEST_SIMPLENETWOR
>  
>  EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid042 = 
> EFI_TEST_SIMPLENETWORKBBTESTCONFORMANCE_ASSERTION_042_GUID;
>  
> +EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid043 =
> EFI_TEST_SIMPLENETWORKBBTESTCONFORMANCE_ASSERTION_043_GUID;
> +
>  EFI_GUID gSimpleNetworkBBTestFunctionAssertionGuid001 = 
> EFI_TEST_SIMPLENETWORKBBTESTFUNCTION_ASSERTION_001_GUID;
>  
>  EFI_GUID gSimpleNetworkBBTestFunctionAssertionGuid002 = 
> EFI_TEST_SIMPLENETWORKBBTESTFUNCTION_ASSERTION_002_GUID;
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .h b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .h
> index 281d893..bf909d1 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .h
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Guid
> .h
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2016, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2018, 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 @@ -235,6 +235,11 @@ extern EFI_GUID 
> gSimpleNetworkBBTestConformanceAssertionGuid041;
>  
>  extern EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid042;
>  
> +#define EFI_TEST_SIMPLENETWORKBBTESTCONFORMANCE_ASSERTION_043_GUID \ 
> +{ 0x8cec0b86, 0x7773, 0x4d3c, {0x84, 0x13, 0x26, 0x37, 0xfb, 0xd0,
> 0x8e, 0x1b }}
> +
> +extern EFI_GUID gSimpleNetworkBBTestConformanceAssertionGuid043;
> +
>  #define EFI_TEST_SIMPLENETWORKBBTESTFUNCTION_ASSERTION_001_GUID \  { 
> 0xf58651fe, 0x0538, 0x4407, {0x88, 0xe0, 0x88, 0xb8, 0xda, 0x18, 0x38, 
> 0x3a }}
>  
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Simp
> leNetworkBBTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Simp
> leNetworkBBTestConformance.c
> index ccbbad0..03a0d04 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Simp
> leNetworkBBTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Simp
> leNetworkBBTestConformance.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2016, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2018, Intel Corporation. All rights
> rese

Re: [edk2] [edk2-test][RFC] Integrating SBBR tests into SCT - A design proposal

[Jin, Eric]

Hi Sakar,

Thank for the clarification.
Now, I understand that the SBBR wants to add/modify in existing 
edk2-test/uefi-sct. In your description, '-s' is not suitable for sbbr purpose. 

The fundamental point to be discussed is that edk2-test/uefi-sct is UEFI Self 
Compliance Test and should keep the alignment to UEFI spec.
To my understanding, the SBBR is published by arm and gives special 
requirements on UEFI/ACPI/SMBIOS areas. 
I remember some new files/new directories with the prefix "sbbr" in 
file/directory name are adding into the edk2-test/uefi-sct In previous push 
request emails, it makes me confused. And it is the reason that I ask for the 
possible standalone space.

Could you please send the patches for review? We can discuss further based on 
them and explore the correct direction. At least, the baseline is it doesn't 
impact existing test result (I want to hear the comments from Supreeth on this 
baseline). 

Best Regards
Eric

-Original Message-
From: Sakar Arora  
Sent: Friday, January 11, 2019 8:23 PM
To: Jin, Eric ; Supreeth Venkatesh 
; edk2-devel@lists.01.org
Cc: Prasanth Pulla 
Subject: RE: [edk2][edk2-test][RFC] Integrating SBBR tests into SCT - A design 
proposal

Hi Supreeth, Eric,

My replies inlined.

Thanks,
Sakar
-Original Message-----
From: Jin, Eric 
Sent: Tuesday, January 8, 2019 7:30 AM
To: Supreeth Venkatesh ; Sakar Arora 
; edk2-devel@lists.01.org
Cc: Prasanth Pulla 
Subject: RE: [edk2][edk2-test][RFC] Integrating SBBR tests into SCT - A design 
proposal

Hello Sakar,

SBBR spec is not published by UEFI Forum and can be considered as a supplement 
to ARM UEFI. The evolution of edk2-test/uefi-sct should be tagged to UEFI Spec 
only.
Can we land SBBR test on standalone space under edk2-test currently or in 
short-term?  I mean SBBR test can leverage edk2-test/uefi-sct (as sub-module)or 
not to build test efi files itself and these test efi files can be integrated 
into UEFI SCT to execute with user usage.

[Sakar] If I understand correctly, you want a separate directory in edk2-test 
for SBBR code, rather than having it in edk2-test/uefi-sct.
The problem I see here is that apart from standalone SBBR test cases, there are 
some changes to the existing test cases inside edk2-test/uefi-sct, that we 
would need pushed for SBBR compliance (These changes will only take effect if 
"-sbbr" parameter is passed while running SCT). So SBBR tests are not exactly 
standalone. Keeping all SBBR specific stuff away, would mean maintaining 
patches to SCT code, which will be difficult. I hope I am making sense.

For the new attributes - SBBR and SBBR_EXCL, I agree with Supreeth that they 
are more like the additional parameters. So they are not the similar cases to 
(AUTO, MANUAL, DESTRUCTIVE, or RESET_REQUIRED).

[Sakar] The reasoning for proposing these 2 attributes is this.
There are some SBBR tests that are needed only for SBBR compliance. When SCT 
app is run *without* the "-sbbr" cmdline parameter, it should run all tests, 
excluding those specific to SBBR. So it needs to differentiate, at runtime, 
tests that are valid for both SBBR and UEFI compliance from the ones that are 
exclusively for SBBR. Tests with attribute SBBR are meant to run for both UEFI 
and SBBR compliance, while those with attribute SBBR_EXCL are only meant for 
SBBR compliance.

If the intention is to distinguish SBBR test from existing test, It can be 
implemented with "-s" parameter plus the SBBR test sequence easily.

[Sakar] Using the "-s" parameter with test sequence file is an option I 
explored a bit.
It doesn't seem to offer control over what sub-tests to run within a test 
scenario,  which is something we want while adding SBBR support in SCT. For 
example, there are some sub-tests that need to be removed from some main tests, 
for SBBR compliance. As far as I understand, sequence file does not provide 
that level of control. Please correct me if I am missing something.

Above is my quick response and I will continue to consider it these days and 
look at SBBR spec.  Any input is welcome.

Best Regards
Eric
-Original Message-
From: Supreeth Venkatesh 
Sent: Tuesday, January 8, 2019 4:14 AM
To: Sakar Arora ; edk2-devel@lists.01.org; Jin, Eric 

Cc: Prasanth Pulla 
Subject: RE: [edk2][edk2-test][RFC] Integrating SBBR tests into SCT - A design 
proposal

Sakar,

Looks good.
However, Why do we need two  additional parameters SBBR and SBBR_EXCL?

Since SBBR is a subset/superset of UEFI specifications, would "sbbr_standalone" 
or similar (just sbbr) which would run all the sbbr tests including ones that 
is already part of UEFI-SCT Suffice?

Lets wait for additional comments from Eric.

Thanks,
Supreeth

-Original Message-
From: Sakar Arora 
Sent: Monday, December 31, 2018 12:50 AM
To: edk2-devel@lists.01.org; eric@intel.com; Supreeth Venkatesh 

Cc: Prasanth Pulla 
Subject: [edk2][edk2-test][RFC] Integrating SBB

Re: [edk2] [edk2-test][PATCH v1 1/1] uefi-sct: Change line endings to CR LF.

[Jin, Eric]

Reviewed-by: Eric Jin 

-Original Message-
From: Supreeth Venkatesh  
Sent: Thursday, December 13, 2018 5:44 AM
To: edk2-devel@lists.01.org
Cc: Jin, Eric ; Supreeth Venkatesh 

Subject: [edk2][edk2-test][PATCH v1 1/1] uefi-sct: Change line endings to CR LF.

No functionality change.
Change line endings to CR LF (windows style) and avoid mixing unix and windows 
line endings for all source files with the exception for shell script files.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 .gitignore|   2 +-
 .../SCT/Framework/Include/SctDef.h|   6 +-
 uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c  |  50 ++---
 uefi-sct/SctPkg/UEFI/UEFI.dec | 204 +-
 4 files changed, 131 insertions(+), 131 deletions(-)

diff --git a/.gitignore b/.gitignore
index e04ef8de..3b8d818e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,3 @@
 Build/
 tags/
-*.[od]
+*.[od]
diff --git a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h
index 3a1afaae..ea488db0 100644
--- a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h
+++ b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h
@@ -2,7 +2,7 @@
 
   Copyright 2006 - 2017 Unified EFI, Inc.
   Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
-  Copyright (c) 2018, ARM Ltd. All rights reserved.
+  Copyright (c) 2018, ARM Ltd. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License @@ -47,8 +47,8 @@ Abstract:
 #define EFI_SCT_NAMEL"UEFI2.5 Self Certification 
Test(SCT2)"
 #elif (EFI_SPECIFICATION_VERSION == EFI_2_60_SYSTEM_TABLE_REVISION)
 #define EFI_SCT_NAMEL"UEFI2.6 Self Certification 
Test(SCT2)"
-#elif (EFI_SPECIFICATION_VERSION == EFI_2_70_SYSTEM_TABLE_REVISION)
-#define EFI_SCT_NAMEL"UEFI2.7 Self Certification 
Test(SCT2)"
+#elif (EFI_SPECIFICATION_VERSION == EFI_2_70_SYSTEM_TABLE_REVISION)
+#define EFI_SCT_NAMEL"UEFI2.7 Self Certification 
Test(SCT2)"
 #else
 #error Unknown EFI_SPECIFICATION_VERSION  #endif diff --git 
a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index f812e511..557a6207 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -2,7 +2,7 @@
 
   Copyright 2006 - 2010 Unified EFI, Inc.
   Copyright (c) 2010 Intel Corporation. All rights reserved.
-  Copyright (c) 2018 ARM Ltd. All rights reserved.
+  Copyright (c) 2018 ARM Ltd. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License @@ -33,7 +33,7 @@ Abstract:
 #include 
 #include 
 #include 
-#include 
+#include 
 
 //
 // Definitions
@@ -51,7 +51,7 @@ PrintUsage (
   void
   );
 
-char *
+char *
 Trim (
   char*String
   );
@@ -161,42 +161,42 @@ PrintUsage (
 }
 
 
-char *
+char *
 Trim (
   char*String
   )
 {
   int   Length;
-  char  *end;
+  char  *end;
 
   Length = strlen (String);
 
-  if (!Length) {
-return String;
+  if (!Length) {
+return String;
   }
 
-  end = String + Length - 1;
+  end = String + Length - 1;
 
   //
   // Remove the space characters from the end of this string
   //
-  while (end >= String && isspace (*end)) {
-end--;
+  while (end >= String && isspace (*end)) {
+end--;
   }
 
-  *(end + 1) = '\0';
-
-  //
-  // Remove the space characters from the beginning of this string
-  //
-  while (*String && isspace (*String)) {
-String++;
-  }
+  *(end + 1) = '\0';
+
+  //
+  // Remove the space characters from the beginning of this string  //  
+ while (*String && isspace (*String)) {
+String++;
+  }
 
   //
   // Done
   //
-  return String;
+  return String;
 }
 
 
@@ -226,15 +226,15 @@ GetLine (
 //
 // Remove the beginning and ending space characters
 //
-String = Trim (Result);
+String = Trim (Result);
 
 //
-// Skip the empty line and comment line
+// Skip the empty line and comment line
 //
-if ((String[0] == '\0') ||
-(String[0] == '#' )) {
-  continue;
-}
+if ((String[0] == '\0') ||
+(String[0] == '#' )) {
+  continue;
+}
   }
 
   //
diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-sct/SctPkg/UEFI/UEFI.dec 
index 8495a4e1..e3a6148c 100644
--- a/uefi-sct/SctPkg/UEFI/UEFI.dec
+++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
@@ -1,7 +1,7 @@
 ## @file
 #
 #  Copyright 2004 - 2017 Unified EFI, Inc. -#  Copyright (c) 2014 - 2018, 
ARM Limited. All rights reserved.
+#  Copyright (c) 2014 - 2018, ARM Limited. All rights reserved.
 #  Copyright (c

Re: [edk2] [edk2-test][RFC] Integrating SBBR tests into SCT - A design proposal

[Jin, Eric]

Hello Sakar,

SBBR spec is not published by UEFI Forum and can be considered as a supplement 
to ARM UEFI. The evolution of edk2-test/uefi-sct should be tagged to UEFI Spec 
only.  
Can we land SBBR test on standalone space under edk2-test currently or in 
short-term?  I mean SBBR test can leverage edk2-test/uefi-sct (as sub-module)or 
not to build test efi files itself and these test efi files can be integrated 
into UEFI SCT to execute with user usage.

For the new attributes - SBBR and SBBR_EXCL, I agree with Supreeth that they 
are more like the additional parameters. So they are not the similar cases to 
(AUTO, MANUAL, DESTRUCTIVE, or RESET_REQUIRED).
If the intention is to distinguish SBBR test from existing test, It can be 
implemented with "-s" parameter plus the SBBR test sequence easily. 

Above is my quick response and I will continue to consider it these days and 
look at SBBR spec.  Any input is welcome. 

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Tuesday, January 8, 2019 4:14 AM
To: Sakar Arora ; edk2-devel@lists.01.org; Jin, Eric 

Cc: Prasanth Pulla 
Subject: RE: [edk2][edk2-test][RFC] Integrating SBBR tests into SCT - A design 
proposal

Sakar,

Looks good.
However, Why do we need two  additional parameters SBBR and SBBR_EXCL?

Since SBBR is a subset/superset of UEFI specifications, would "sbbr_standalone" 
or similar (just sbbr) which would run all the sbbr tests including ones that 
is already part of UEFI-SCT Suffice?

Lets wait for additional comments from Eric.

Thanks,
Supreeth

-Original Message-
From: Sakar Arora 
Sent: Monday, December 31, 2018 12:50 AM
To: edk2-devel@lists.01.org; eric@intel.com; Supreeth Venkatesh 

Cc: Prasanth Pulla 
Subject: [edk2][edk2-test][RFC] Integrating SBBR tests into SCT - A design 
proposal

Hi All,

Introduction -->

The intent is to run SBBR  tests using SCT infrastructure. This is the SBBR 
specification link for reference 
http://infocenter.arm.com/help/topic/com.arm.doc.den0044c/Server_Base_Boot_Requirements_v1_1_Arm_DEN_0044C.pdf

Majority of SBBR requirements can be tested by current SCT code as is. A few 
more SBBR specific tests are needed to cover complete spec.

Proposal -->

An ideal setup is new SBBR specific code residing in edk2-test master. SCT test 
infrastructure will run tests for UEFI spec compliance or just SBBR spec 
compliance based on command line arguments. This would require run time 
classification of tests.

- Details

Each SCT test provides a list of sub-tests to verify various aspects of the 
requirement. Each sub-test is assigned some attributes (AUTO, MANUAL, 
DESTRUCTIVE, or RESET_REQUIRED) which are referred to by the test 
infrastructure to do pre and post processing for it.

The proposal is to add 2 new attributes SBBR and SBBR_EXCL to the existing set. 
The test infrastructure will decide whether to run or skip a test based on 
command line parameters and these new attributes.

- The new attributes

SBBR : Tests with this attribute are required by both SBBR and UEFI.
SBBR_EXCL : Tests with this attribute are required by SBBR exclusively.

- Examples

Shell> Sct.efi -a -sbbr

Would run tests required by SBBR, i.e., tests with attributes SBBR or SBBR_EXCL.

Shell> Sct.efi -a

Would run tests required by UEFI, i.e., all tests excluding those with 
attribute SBBR_EXCL.

-  SCT test pre-processing flow

The following logic will be added to the pre-processing flow.

If (SCT_FOR_SBBR) {
   If (!TEST_CASE_FOR_SBBR(TestCaseAttribute))
goto SkipTest;
} else {
If (TEST_CASE_FOR_SBBR_EXCL(TestCaseAttribute))
   goto SkipTest;
}

Comments are welcome.

Thanks,
Sakar
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Line endings: Was "Re: [edk2-test][Patch] uefi-sct/SctPkg:Correct macro name style in HwErrRecVariable Test"

[Jin, Eric]

Currently, the git am fail with " --ignore-space-change" switch on/off. It is 
better if we can solve it with "core.whitespace", "am.keepcr" and 
"core.autocrlf" in the meantime.

Should all existing patches hold until the conversion done or the conversion is 
tried on the branch until it is validated? 

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh [mailto:supreeth.venkat...@arm.com] 
Sent: Saturday, December 15, 2018 7:54 AM
To: Laszlo Ersek ; Leif Lindholm ; 
Andrew Fish ; Kinney, Michael D 
Cc: edk2-devel@lists.01.org; Jin, Eric 
Subject: Re: Line endings: Was "Re: [edk2-test][Patch] uefi-sct/SctPkg:Correct 
macro name style in HwErrRecVariable Test"

On Fri, 2018-12-14 at 20:57 +0100, Laszlo Ersek wrote:
> On 12/14/18 18:12, Supreeth Venkatesh wrote:
> > On Fri, 2018-12-14 at 14:24 +0100, Laszlo Ersek wrote:
> > > On 12/14/18 11:59, Leif Lindholm wrote:
> > > > Hmm, this gets me thinking...
> > > > 
> > > > We were discussing before about doing a line ending conversion 
> > > > in edk2, and let the git gools provide native line endings (as 
> > > > designed).
> > > > 
> > > > Is this a good opportunity to run a pilot with edk2-test, where 
> > > > much less history will be lost?
> > > 
> > > Well, history won't be lost, in the sense that people running "git 
> > > blame" will need one more execution of "git blame" (to "look past"
> > > the
> > > whitespace change commit), but yes, it will result in a minor 
> > > inconvenience.
> > > 
> > > And, I think, converting the edk2-test repo would not be a bad 
> > > test at all.
> > > 
> > 
> > Thanks Leif/Laszlo. I volunteer to try the tool. However, I admit
> > that
> > I have not tried this before, any pointers/instructions on how to
> > do
> > this?
> 
> I imagine you'd run a "find" command to locate all source/text files
> (skip ".git"), then feed them to xargs / dos2unix.
> 
> The trick is more in the git settings, once the internal
> representation
> has been converted to LF only. I'm thinking that "core.whitespace",
> "am.keepcr" and "core.autocrlf" should be set the "right way". (= to
> be
> researched)
Never mind. I think I misread the initial email. I was expecting some
git tool magic or script :). I can come up with one. Thanks.

> 
> Thanks
> Laszlo

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

Re: [edk2] [edk2-test][Patch] uefi-sct/SctPkg:Correct macro name style in HwErrRecVariable Test

[Jin, Eric]

Hello Supreeth,

I use "Apply Patch Serial" operation provided by TortoiseGit to do the applying.
The operation is equivalent to "git.exe am --3way --ignore-space-change 
--keep-cr Fix.patch"

What is your command to apply patch?

I observe the same failure with "git.exe am Fix.patch" and 
"--ignore-space-change " is the key.
I am not sure if it is the mail-patch-conversion cause or not.

And the patch "[edk2][edk2-test][PATCH v1 1/1] uefi-sct: Change line endings to 
CR LF. "  also has the same failure behavior without "--ignore-space-change " 
on my side. 

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Thursday, December 13, 2018 5:07 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Cc: Leif Lindholm 
Subject: Re: [edk2-test][Patch] uefi-sct/SctPkg:Correct macro name style in 
HwErrRecVariable Test


Eric,

Nothing wrong with code.

However, when applying this patch with git am, I encounter the below errors. 
(not sure if it is related to mailbox configuration).
Not sure if it is my mailbox, could you please test it on your side using git 
am and let me know?

git am
./patches/0001_SctPkg\:Correct_macro_name_style_in_HwErrRecVariable_Te
st.mbox
Applying: uefi-sct/SctPkg:Correct macro name style in HwErrRecVariable Test
error: patch failed: uefi-
sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxT
est/VariableServicesBBTestMain.h:131
error: uefi-
sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxT
est/VariableServicesBBTestMain.h: patch does not apply
error: patch failed: uefi-
sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxT
est/VariableServicesBBTestFunction.c:2855
error: uefi-
sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxT
est/VariableServicesBBTestFunction.c: patch does not apply Patch failed at 0001 
uefi-sct/SctPkg:Correct macro name style in HwErrRecVariable Test Use 'git am 
--show-current-patch' to see the failed patch When you have resolved this 
problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Thanks,
Supreeth
On Wed, 2018-12-12 at 11:32 +0800, Eric Jin wrote:
> Name macros appropriately to follow the rule in coding standards 
> specification.
> Change the following macro from variable style 
> HwErrRecVariableNameLength HwErrRecVariableNamePrefixLength 
> HwErrRecVariableNameIndexLength to macro style.
> HW_ERR_REC_VARIABLE_NAME_LEN
> HW_ERR_REC_VARIABLE_NAME_PREFIX_LEN
> HW_ERR_REC_VARIABLE_NAME_INDEX_LEN
> 
> Cc: Leif Lindholm 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestMain.h |  6 +++---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c | 22 +++---
>  2 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestMain.h b/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestMain.h
> index 426b762..7eaa56d 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestMain.h
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestMain.h
> @@ -131,9 +131,9 @@ Abstract:
>  // The prefix length is 8, index length is 4.
>  // Consider the tail of string, the name length is 13.
>  //
> -#define HwErrRecVariableNameLength   13
> -#define HwErrRecVariableNamePrefixLength 8 -#define 
> HwErrRecVariableNameIndexLength  4
> +#define HW_ERR_REC_VARIABLE_NAME_LEN   13
> +#define HW_ERR_REC_VARIABLE_NAME_PREFIX_LEN8
> +#define HW_ERR_REC_VARIABLE_NAME_INDEX_LEN 4
>  
>  //
>  // Global Variables
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c b/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> index a016476..015a78a 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> @@ -2855,7 +2855,7 @@ HardwareErrorRecordFuncTest (
>UINT64RemainingVariableStora

Re: [edk2] SCT bugzilla topic?

[Jin, Eric]

Hi Leif,

We had better use "UEFI SCT" as the component. 
Other SCTs or test suites may be arranged in the EDK2-Test in future as the 
intention of EDK2-Test if my understanding is correct. Thanks.

Best Regards
Eric

-Original Message-
From: Leif Lindholm  
Sent: Monday, December 10, 2018 4:14 PM
To: Kinney, Michael D 
Cc: Jin, Eric ; Supreeth Venkatesh 
; edk2-devel@lists.01.org; Dong Wei 

Subject: Re: SCT bugzilla topic?

Hi Mike,

I think we're agreed on an "EDK2 Test" product with an "SCT" component.
(Although that should probably be "UEFI SCT" for clarity.)

Regards,

Leif

On Mon, Dec 10, 2018 at 03:02:57AM +, Kinney, Michael D wrote:
> I can update BZ once there is a clear decision on what is required.
> 
> Mike
> 
> > -Original Message-
> > From: Jin, Eric
> > Sent: Sunday, December 9, 2018 6:19 PM
> > To: Supreeth Venkatesh ; Leif Lindholm 
> > ; edk2- de...@lists.01.org
> > Cc: Kinney, Michael D ; Dong Wei 
> > ; Jin, Eric 
> > Subject: RE: SCT bugzilla topic?
> > 
> > Supreeth and Leif,
> > 
> > UEFI-SCT is open source project now, the mantis is not proper 
> > option. We had better use the Bugzilla as edk2.
> > Could the stewards help to create the Edk2 Test Product and SCT 
> > component if most members want to split test with edk2?
> > 
> > Best Regards
> > Eric
> > 
> > -Original Message-
> > From: Supreeth Venkatesh 
> > Sent: Tuesday, December 4, 2018 3:37 AM
> > To: Leif Lindholm ; edk2- 
> > de...@lists.01.org
> > Cc: Jin, Eric ; Kinney, Michael D 
> > ; Dong Wei 
> > Subject: RE: SCT bugzilla topic?
> > 
> > Leif,
> > 
> > Earlier, we used to use UTWG Mantis (for feature requests
> > - https://mantis.uefi.org/mantis/view.php).
> > After, UEFI-SCT became Open source, we did discuss to have the same 
> > infrastructure setup as edk2, which means using Bugzilla.
> > However, I don't think we have created a SCT component or
> > Edk2 Test Product yet.
> > 
> > Your email reminds me one more task after the SCT component / Edk2 
> > Test product is created i.e., to migrate over remaining UTWG issues 
> > to Bugzilla.
> > 
> > Once Eric chimes in/agrees, we will request Mike to create
> > Edk2 Test Product within Bugzilla.
> > 
> > Thanks,
> > Supreeth
> > 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Monday, December 3, 2018 8:47 AM
> > To: edk2-devel@lists.01.org
> > Cc: Eric Jin ; Supreeth Venkatesh 
> > ; Michael D Kinney 
> > 
> > Subject: SCT bugzilla topic?
> > 
> > Hi Eric, Supreeth, Mike,
> > 
> > I was looking to raise a feature request on UEFI SCT and didn't spot 
> > such a product. Should we create one?
> > 
> > Or perhaps we should have an EDK2 Test product with an SCT 
> > component?
> > 
> > Regards,
> > 
> > Leif
> > IMPORTANT NOTICE: The contents of this email and any attachments are 
> > confidential and may also be privileged.
> > If you are not the intended recipient, please notify the sender 
> > immediately and do not disclose the contents to any other person, 
> > use it for any purpose, or store or copy the information in any 
> > medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SCT bugzilla topic?

[Jin, Eric]

Supreeth and Leif,

UEFI-SCT is open source project now, the mantis is not proper option. We had 
better use the Bugzilla as edk2.
Could the stewards help to create the Edk2 Test Product and SCT component if 
most members want to split test with edk2?

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Tuesday, December 4, 2018 3:37 AM
To: Leif Lindholm ; edk2-devel@lists.01.org
Cc: Jin, Eric ; Kinney, Michael D 
; Dong Wei 
Subject: RE: SCT bugzilla topic?

Leif,

Earlier, we used to use UTWG Mantis (for feature requests - 
https://mantis.uefi.org/mantis/view.php).
After, UEFI-SCT became Open source, we did discuss to have the same 
infrastructure setup as edk2, which means using Bugzilla.
However, I don't think we have created a SCT component or Edk2 Test Product yet.

Your email reminds me one more task after the SCT component / Edk2 Test product 
is created i.e., to migrate over remaining UTWG issues to Bugzilla.

Once Eric chimes in/agrees, we will request Mike to create Edk2 Test Product 
within Bugzilla.

Thanks,
Supreeth

-Original Message-
From: Leif Lindholm 
Sent: Monday, December 3, 2018 8:47 AM
To: edk2-devel@lists.01.org
Cc: Eric Jin ; Supreeth Venkatesh 
; Michael D Kinney 
Subject: SCT bugzilla topic?

Hi Eric, Supreeth, Mike,

I was looking to raise a feature request on UEFI SCT and didn't spot such a 
product. Should we create one?

Or perhaps we should have an EDK2 Test product with an SCT component?

Regards,

Leif
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-test][v2 Patch 0/3] Add VerifySignature() Test

[Jin, Eric]

Hi Laszlo,

Thank for the comments. Will send out new patch series later. 

Best Regards
Eric

-Original Message-
From: Laszlo Ersek  
Sent: Monday, December 3, 2018 9:50 PM
To: Jin, Eric 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-test][v2 Patch 0/3] Add VerifySignature() Test

On 12/03/18 08:53, Eric Jin wrote:
> This is the cover letter.
> The series of patches are listed below.
> 
>   uefi-sct/SctPkg:Format code style in PKCS7Verify
>   uefi-sct/SctPkg:Add VerifySignature() Func Test
>   uefi-sct/SctPkg:Add VerifySignature() Conf Test
> 
> 
>  .../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c   |   93 +-
>  .../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h   |  192 +--
>  .../PKCS7Verify/BlackBoxTest/Pkcs7BBTest.inf   |  126 +-
>  .../BlackBoxTest/Pkcs7BBTestConformance.c  | 1305 +---
>  .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestData.c | 1568 
> +---
>  .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestFunction.c |  553 ---
>  .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestMain.c |  458 +++---
>  .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestMain.h |  248 ++--
>  8 files changed, 2689 insertions(+), 1854 deletions(-)
> 

A cover letter like this doesn't make any sense.

- Please enable shallow threading for git-send-email, so that the patch emails 
are (direct) children of the cover letter. One of the goals of the cover letter 
is to group the patches under a common parent message.

- The other purpose of cover letters is to summarize the goal of the patch 
series (high level problem statement, chosen solution, maybe mention one or two 
details if they are important).

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

Re: [edk2] [edk2-test][Patch 3/3] uefi-sct/SctPkg:Add VerifySignature() Conf Test

[Jin, Eric]

Hello Supreeth,

Thank you for the comments.
V2 will be sent out. All clean up will be merged into the  patch 1/3 with INF 
version update.

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Saturday, December 1, 2018 6:28 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Subject: Re: [edk2-test][Patch 3/3] uefi-sct/SctPkg:Add VerifySignature() Conf 
Test

Commit message to mention what this patch is imlementing.

In addition, there is cleanup to remove #if 0 block below.
Both of this should be in commit message.

On Thu, 2018-11-29 at 16:46 +0800, Eric Jin wrote:
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  .../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c   |   5 +-
>  .../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h   |  16 ++
>  .../BlackBoxTest/Pkcs7BBTestConformance.c  | 303
> -
>  .../PKCS7Verify/BlackBoxTest/Pkcs7BBTestMain.c |   2 -
>  4 files changed, 319 insertions(+), 7 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c
> b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c
> index 4d433c3..8f6546a 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c
> @@ -36,7 +36,10 @@ EFI_GUID gPkcs7BBTestConformanceAssertionGuid007 = 
> EFI_TEST_PKCS7BBTESTCONFORMAN  EFI_GUID 
> gPkcs7BBTestConformanceAssertionGuid008 = 
> EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_008_GUID;
>  EFI_GUID gPkcs7BBTestConformanceAssertionGuid009 = 
> EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_009_GUID;
>  EFI_GUID gPkcs7BBTestConformanceAssertionGuid010 = 
> EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_010_GUID;
> -
> +EFI_GUID gPkcs7BBTestConformanceAssertionGuid011 =
> EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_011_GUID;
> +EFI_GUID gPkcs7BBTestConformanceAssertionGuid012 =
> EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_012_GUID;
> +EFI_GUID gPkcs7BBTestConformanceAssertionGuid013 =
> EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_013_GUID;
> +EFI_GUID gPkcs7BBTestConformanceAssertionGuid014 =
> EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_014_GUID;
>  
>  EFI_GUID gPkcs7BBTestFunctionAssertionGuid001 = 
> EFI_TEST_PKCS7BBTESTFUNCTION_ASSERTION_001_GUID;
>  EFI_GUID gPkcs7BBTestFunctionAssertionGuid002 = 
> EFI_TEST_PKCS7BBTESTFUNCTION_ASSERTION_002_GUID;
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h
> b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h
> index 32a00f6..f8d1b8f 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h
> @@ -65,6 +65,22 @@ extern EFI_GUID
> gPkcs7BBTestConformanceAssertionGuid009;
>  { 0xb136e016, 0x4f80, 0x44bd, {0xba, 0xb0, 0x1c, 0x34, 0x8a, 0x2d, 
> 0xa1, 0x8a }}  extern EFI_GUID 
> gPkcs7BBTestConformanceAssertionGuid010;
>  
> +#define EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_011_GUID \ { 
> +0xa58f3626, 0xf16e, 0x4cd5, { 0xba, 0x12, 0x7a, 0x9d, 0xd6, 0x9a,
> 0x7a, 0x71 }}
> +extern EFI_GUID gPkcs7BBTestConformanceAssertionGuid011;
> +
> +#define EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_012_GUID \ { 
> +0xbe4a0bf2, 0x2d46, 0x4d96, { 0xa6, 0x11, 0x21, 0x99, 0xa5, 0x5f,
> 0xa4, 0xee }}
> +extern EFI_GUID gPkcs7BBTestConformanceAssertionGuid012;
> +
> +#define EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_013_GUID \ { 
> +0xc0536a27, 0x304e, 0x497a, { 0xa5, 0xe3, 0x94, 0x11, 0x38, 0x53,
> 0x6e, 0x40 }}
> +extern EFI_GUID gPkcs7BBTestConformanceAssertionGuid013;
> +
> +#define EFI_TEST_PKCS7BBTESTCONFORMANCE_ASSERTION_014_GUID \ { 
> +0x8c5aa0e8, 0x17ff, 0x49cd, { 0x8f, 0xec, 0x37, 0xc3, 0xfd, 0x5f,
> 0x77, 0x0 }}
> +extern EFI_GUID gPkcs7BBTestConformanceAssertionGuid014;
> +
>  
>  #define EFI_TEST_PKCS7BBTESTFUNCTION_ASSERTION_001_GUID \  { 
> 0x5c0eec50, 0xa6ea, 0x413c, {0x8a, 0x46, 0x4a, 0xd1, 0x4a, 0x77, 0x76, 
> 0xf1 }} diff --git a/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Pkcs7B
> BTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Pkcs7B
> BTestConformance.c
> index b7bc19b..ce7d5bb 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Pkcs7B
> BTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/PKCS7Verify/BlackBoxTest/Pkcs7B
> BTestConformance.c
> @@ -278,10 +278,6 @@ BBTestVerifyBufferConformanceTest (
>   Status
>   );
>

Re: [edk2] [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending detection by GenBin tool

[Jin, Eric]

Please don't forget to change the copyright info when commit patch.
Reviewed-by: Eric Jin 

-Original Message-
From: Lokesh B V  
Sent: Tuesday, November 20, 2018 2:50 PM
To: edk2-devel@lists.01.org; supreeth.venkat...@arm.com; Jin, Eric 

Cc: Lokesh B V 
Subject: [edk2-test][PATCH] SctPkg/Tools: Fix incorrect line ending detection 
by GenBin tool

Some windows editors uses "\r\n" for line feed. While processing uefi testcase 
info file, the GenBin tool logic to skip line feed doesn't consider the 
presence of carraige return(\r) in line feed. So this results in incorrect 
format error.

Signed-off-by: Lokesh B V 
---
 uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c 
b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
index 61bb35b..ce271a1 100644
--- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
+++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
@@ -176,6 +176,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Index1] != ' ' ) &&
 (String[Index1] != '\t') &&
+(String[Index1] != '\r') &&
 (String[Index1] != '\n')) {
   break;
 }
@@ -193,6 +194,7 @@ Trim (
   for (Index1 = 0; Index1 < Length; Index1++) {
 if ((String[Length - 1 - Index1] != ' ' ) &&
 (String[Length - 1 - Index1] != '\t') &&
+(String[Length - 1 - Index1] != '\r') &&
 (String[Length - 1 - Index1] != '\n')) {
   break;
 }
--
2.7.4

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

Re: [edk2] [edk2-test][PATCH] SctPkg/UEFI: Fix invalid GUID value format error

[Jin, Eric]

Please don't forget to change the copyright info when commit patch.
Reviewed-by: Eric Jin 

-Original Message-
From: Lokesh B V  
Sent: Tuesday, November 20, 2018 2:50 PM
To: edk2-devel@lists.01.org; supreeth.venkat...@arm.com; Jin, Eric 

Cc: Lokesh B V 
Subject: [edk2-test][PATCH] SctPkg/UEFI: Fix invalid GUID value format error

Fix all GUID values that are defined with a invalid GUID value format.

Signed-off-by: Lokesh B V 
---
 uefi-sct/SctPkg/UEFI/UEFI.dec | 202 +-
 1 file changed, 101 insertions(+), 101 deletions(-)

diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-sct/SctPkg/UEFI/UEFI.dec 
index 14cc5b0..7e4d248 100644
--- a/uefi-sct/SctPkg/UEFI/UEFI.dec
+++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
@@ -44,25 +44,25 @@
   
 
 [Guids.common]
-  gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, 0x8e, 0x39, 0x0, 
0xa0, 0xc9, 0x69, 0x72, 0x3b }
-  gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, 0x8e, 0x39, 0x0, 
0xa0, 0xc9, 0x69, 0x72, 0x3b }
+  gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, { 0x8e, 0x39, 
+ 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }}  gBlackBoxEfiFileInfoIdGuid = { 
+ 0x9576e93, 0x6d3f, 0x11d2, { 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 
+ 0x3b }}
   gBlackBoxEfiFileSystemInfoGuid = { 0x09576E93, 0x6D3F, 0x11D2, { 0x8E, 0x39, 
0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B }}
-  gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3,0xFE81, 0x11d3, 
0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }
-  gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, 0xB1, 0x3D, 
0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F}
-  gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, 0x99, 0x87, 
0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }
+  gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3, 0xFE81, 
+ 0x11d3, { 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}  
+ gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, { 
+ 0xB1, 0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F }}  
+ gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, { 
+ 0x99, 0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }}
   gBlackBoxEfiPcAnsiGuid = { 0xE0C14753, 0xF9BE, 0x11D2, { 0x9A, 0x0C, 0x00, 
0x90, 0x27, 0x3F, 0xC1, 0x4D }}
   gBlackBoxEfiVT100Guid = { 0xDFA66065, 0xB419, 0x11D3, { 0x9A, 0x2D, 0x00, 
0x90, 0x27, 0x3F, 0xC1, 0x4D }}
   gBlackBoxEfiVT100PlusGuid = { 0x7BAEC70B, 0x57E0, 0x4C76, { 0x8E, 0x87, 
0x2F, 0x9E, 0x28, 0x08, 0x83, 0x43 }}
   gBlackBoxEfiVTUTF8Guid = { 0xAD15A0D6, 0x8BEC, 0x4ACF, { 0xA0, 0x73, 0xD0, 
0x1D, 0xE7, 0x7E, 0x2D, 0x88 }}
 
-  gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095, 0xb7, 
0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }
-  gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5, 0x4bf7, 0xb0, 
0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }
-  gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2, 0x4ea3, 0xbc, 
0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }
-  gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33, 0x4dd2, 0xae, 
0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }
-  gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c, 0x4770, 0xb8, 
0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }
-  gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, 0xb0, 0xae, 
0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }
-  gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2, 0x40ca, 
0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }
-  gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7, 0x4814, 
0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }
+  gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095, { 
+ 0xb7, 0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }}  
+ gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5, 0x4bf7, { 
+ 0xb0, 0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }}  
+ gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2, 0x4ea3, { 
+ 0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }}  
+ gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33, 0x4dd2, { 
+ 0xae, 0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }}  
+ gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c, 0x4770, { 
+ 0xb8, 0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }}  
+ gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, { 
+ 0xb0, 0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }}  
+ gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2, 
+ 0x40ca, { 0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }}  
+ gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7, 
+ 0x4814, { 0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }}
 
   
   gBlackBoxEfiCertSha256Guid = { 0xc1c41626, 0x504c, 0x4092, 
{0xac, 0xa9, 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28 }} 
@@ -79,109 +79,109 @@
   gBlackBoxEfiPersistentVirtualCdGuid = { 0x08018188, 0x42CD, 0xBB48, {0x10, 
0x0F, 0x53, 0x87, 0xD5, 0x3D, 0xED, 0x3D }}
 
 [Protocols.common]
-  gBlackBoxEfiAbsolutePointerProtocolGuid = { 0x8D59D32B, 0xC655, 0x4AE9, { 
0x9B, 0x15, 0xF2, 0x59, 0x04, 0x99, 0x2A, 0x43

Re: [edk2] [edk2-test][PATCH] Framework/Include: allow usage with EFI version 2.7

[Jin, Eric]

Please don't forget to change the copyright info when commit patch.
Reviewed-by: Eric Jin 

-Original Message-
From: Lokesh B V  
Sent: Tuesday, November 20, 2018 2:50 PM
To: edk2-devel@lists.01.org; supreeth.venkat...@arm.com; Jin, Eric 

Cc: Lokesh B V 
Subject: [edk2-test][PATCH] Framework/Include: allow usage with EFI version 2.7

EDK2 supports EFI version 2.7 and so allow UEFI-SCT to be usable with this 
version of EFI.

Signed-off-by: Lokesh B V 
---
 uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h
index d24c201..c861437 100644
--- a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h
+++ b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/Include/SctDef.h
@@ -46,6 +46,8 @@ Abstract:
 #define EFI_SCT_NAMEL"UEFI2.5 Self Certification 
Test(SCT2)"
 #elif (EFI_SPECIFICATION_VERSION == EFI_2_60_SYSTEM_TABLE_REVISION)
 #define EFI_SCT_NAMEL"UEFI2.6 Self Certification 
Test(SCT2)"
+#elif (EFI_SPECIFICATION_VERSION == EFI_2_70_SYSTEM_TABLE_REVISION)
+#define EFI_SCT_NAMEL"UEFI2.7 Self Certification 
Test(SCT2)"
 #else
 #error Unknown EFI_SPECIFICATION_VERSION  #endif
--
2.7.4

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

Re: [edk2] [edk2-test][RFC PATCH 11/12] uefi-sct/SctPkg: sbbr: Bugfix for MemoryMap Check Test.

[Jin, Eric]

Add the maintainer Supreeth.

Hello Sakar,

Thank for the patches in this series.
The common comments is: 
The keyword 'SBBR' exists on the FilePath or in the FileName. But 'SBBR' string 
or related description is not mentioned in UEFI spec at all. 
Could you please add more detail for the checkpoint requirement in the UEFI 
spec? Please remove the 'SBBR' in the new patch.
If the checkpoint is not related to UEFI spec, uefi-sct/sctpkg may not be the 
proper space for these patch landing. Thanks. 

Best Regards
Eric

-Original Message-
From: edk2-devel  On Behalf Of Sakar Arora
Sent: Tuesday, November 6, 2018 4:48 PM
To: edk2-devel@lists.01.org
Cc: prasanth.pu...@arm.com
Subject: [edk2] [edk2-test][RFC PATCH 11/12] uefi-sct/SctPkg: sbbr: Bugfix for 
MemoryMap Check Test.

As per SBBR specification, "A UEFI runtime environment compliant with SBBR must 
not be written with any assumption of an identity mapping between virtual and 
physical memory maps."

Test case implementation was failing the test, if it is not identity mapped, 
which is incorrect.

Corrected test case to warn the user that UEFI runtime environment is identity 
mapped, instead of failure.

Signed-off-by: Sakar Arora 
Reported-by: Felix Poludov 
---
 .../SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
index fb50702..c88d60b 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/BlackBoxTest/SbbrBootServicesBBTestFunction.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/SbbrBootServices/Bl
+++ ackBoxTest/SbbrBootServicesBBTestFunction.c
@@ -201,13 +201,13 @@ BBTestMemoryMapTest (
 //
 // Checking for identity mapping
 //
-if (MemoryMapDescriptor->PhysicalStart != 
MemoryMapDescriptor->VirtualStart) {
+if (MemoryMapDescriptor->PhysicalStart == 
+ MemoryMapDescriptor->VirtualStart) {
   StandardLib->RecordAssertion (
   StandardLib,
-  EFI_TEST_ASSERTION_FAILED,
+  EFI_TEST_ASSERTION_WARNING,
   gSbbrBootServicesAssertion001Guid,
   L"MemoryMap",
-  L"%a:%d - MemoryMap 0x%X Not Identity Mapped",
+  L"%a:%d - MemoryMap 0x%X is Identity Mapped. UEFI 
+ runtime environment must not be written with any assumption of an 
+ identity mapping between virtual and physical memory maps.",
   __FILE__,
   __LINE__,
   MemoryMapDescriptor
--
2.7.4

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

Re: [edk2] [edk2-test][Patch] uefi-sct/SctPkg:Add checkpoint of ReadKeyStrokeEx Toggle state

[Jin, Eric]

Supreeth,

The Patch will be split in 2 patches in series, one of the test driver in EFI 
part, and the other in the IHV part.
The attribute alignment can be ignored due to the wordwrap in mail format.
RecordMessage format will be consistent and extra parenthesis will be added in 
the if statement.
Besides above, more comments are added to describe the checkpoint intention.

The Patch V3 will be sent out later. 

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Thursday, November 8, 2018 4:00 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Subject: Re: [edk2-test][Patch] uefi-sct/SctPkg:Add checkpoint of 
ReadKeyStrokeEx Toggle state

Eric,

Could you please split these as PATCH (perhaps 3 or more) series as there are 
more than 10 files changed in a single patch?.

Please see comments inline.

On Wed, 2018-11-07 at 14:47 +0800, Eric Jin wrote:
> UEFI drivers which implement the EFI_SIMPLE_TEXT_INPUT_EX protocol are 
> required to return KeyData.Key and KeyData.KeyState values.
> These drivers must always return the most current state of 
> KeyData.KeyState.KeyShiftState and KeyData.KeyState.KeyToggleState.
> 
> The change in spec is "EFI_NOT_READY - There was no keystroke data 
> available. Current KeyData.KeyState values are exposed."
> 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
>  .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-  
> .../BlackBoxTest/SimpleTextInputExBBTestFunction.c | 211
> 
>  .../BlackBoxTest/SimpleTextInputExBBTestMain.c |  13 +-
>  .../BlackBoxTest/SimpleTextInputExBBTestMain.h |  22 ++-
>  .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
>  .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-  
> .../BlackBoxTest/SimpleTextInputExBBTestFunction.c | 213
> -
>  .../BlackBoxTest/SimpleTextInputExBBTestMain.c |  11 +-
>  .../BlackBoxTest/SimpleTextInputExBBTestMain.h |  20 +-
>  10 files changed, 515 insertions(+), 13 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.c
> index 9cb19f4..ff2d50f 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2012 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2012, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2018, 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 @@ -63,3 +63,8 @@ EFI_GUID
> gSimpleTextInputExBBTestFunctionAssertionGuid007 = 
> EFI_TEST_SIMPLETEXTI  EFI_GUID 
> gSimpleTextInputExBBTestFunctionAssertionGuid008 = 
> EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_008_GUID;
>  
>  EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009 = 
> EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_009_GUID;
> +
> +EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid010 =
> EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID;
> +
> +EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid011 =
> EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_011_GUID;
> +
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.h b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.h
> index 6c90fca..2a6be48 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.h
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/
> Guid.h
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2010 Unified EFI, Inc.
> -  Copyright (c) 2010, Intel Corporation. All rights reserved.
> +  Copyright (c) 2010 - 2018, 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 @@ -119,3 +119,13 @@ extern EFI_GUID 
> gSimpleTextInputExBBTestFunctionAssertionGuid008;
>  { 0x534369f7, 0x8399, 0x4353, { 0x94, 0xad, 0xc4, 0x48, 0xfa, 0xda, 
> 0xeb, 0x84 } }
>  
>  extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009;
> +
> +#define EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID
> \
> +{ 0xcf4d54eb, 0x6696, 0x4794, { 0x91, 0

Re: [edk2] [edk2-test][Patch v2] uefi-sct/SctPkg:Add checkpoint of ReadKeyStrokeEx Toggle state

[Jin, Eric]

It is  the patch v2 below. 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Jin
Sent: Wednesday, November 7, 2018 2:48 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-test][Patch] uefi-sct/SctPkg:Add checkpoint of 
ReadKeyStrokeEx Toggle state

UEFI drivers which implement the EFI_SIMPLE_TEXT_INPUT_EX protocol are required 
to return KeyData.Key and KeyData.KeyState values.
These drivers must always return the most current state of 
KeyData.KeyState.KeyShiftState and KeyData.KeyState.KeyToggleState.

The change in spec is "EFI_NOT_READY - There was no keystroke data available. 
Current KeyData.KeyState values are exposed."

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-  
.../BlackBoxTest/SimpleTextInputExBBTestFunction.c | 211 
 .../BlackBoxTest/SimpleTextInputExBBTestMain.c |  13 +-
 .../BlackBoxTest/SimpleTextInputExBBTestMain.h |  22 ++-
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c |   7 +-
 .../Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h |  12 +-  
.../BlackBoxTest/SimpleTextInputExBBTestFunction.c | 213 -
 .../BlackBoxTest/SimpleTextInputExBBTestMain.c |  11 +-
 .../BlackBoxTest/SimpleTextInputExBBTestMain.h |  20 +-
 10 files changed, 515 insertions(+), 13 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
index 9cb19f4..ff2d50f 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/Black
+++ BoxTest/Guid.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2012 Unified EFI, Inc.
-  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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 @@ -63,3 +63,8 @@ EFI_GUID 
gSimpleTextInputExBBTestFunctionAssertionGuid007 = EFI_TEST_SIMPLETEXTI  
EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid008 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_008_GUID;
 
 EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009 = 
EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_009_GUID;
+
+EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid010 = 
+EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID;
+
+EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid011 = 
+EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_011_GUID;
+
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
index 6c90fca..2a6be48 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/Guid.h
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/Black
+++ BoxTest/Guid.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2018, 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 @@ -119,3 +119,13 @@ extern EFI_GUID 
gSimpleTextInputExBBTestFunctionAssertionGuid008;
 { 0x534369f7, 0x8399, 0x4353, { 0x94, 0xad, 0xc4, 0x48, 0xfa, 0xda, 0xeb, 0x84 
} }
 
 extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid009;
+
+#define EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_010_GUID \ { 
+0xcf4d54eb, 0x6696, 0x4794, { 0x91, 0x74, 0x59, 0xd, 0x1c, 0x22, 0xa8, 
+0x67 } }
+
+extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid010;
+
+#define EFI_TEST_SIMPLETEXTINPUTEXBBTESTFUNCTION_ASSERTION_011_GUID \ { 
+0xf8e8f879, 0xa6d4, 0x4fd3, { 0x8b, 0x8e, 0xba, 0x1d, 0x18, 0xf1, 0x40, 
+0x71 } }
+
+extern EFI_GUID gSimpleTextInputExBBTestFunctionAssertionGuid011;
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
index 153ade0..4850627 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/Black
+++ BoxTest/SimpleTextInputExBBTestFunction.c
@@ -456,6 +456,78 @@ BBTestUnregisterKeyNotifyFunctionManualTest (  }
 
 
+EFI_STATUS
+BBTestReadKeyStrokeExFunctionAutoTest (
+  IN EFI_BB_TEST_PROTOCOL   *This,
+  IN VOID   *ClientInterface,

Re: [edk2] [PATCH] uefi-sct/SctPkg:The Lun display order issue in iSCSI device path text

[Jin, Eric]

Hi Supreeth,

The intention of the patch is to fix the LUN display issue in the iSCSI device 
path text.
In the UEFI spec, the according definition is clarified as " The LUN is an 8 
byte array 
that is displayed in hexadecimal format with byte 0 first (i.e., on the left) 
and byte 7 
last (i.e, on the right), and is required. "

The current test has the mistake and need make sure the display order is 
correct.
The input is required to check the TEXT to binary system format, vice versa. 
It is the reason for the magic string 
"iSCSI(MyTargetName,0x12AB,0x00567800,CRC32C,None,CHAP_BI,TCP)"
And the text format defined in the UEFI spec is:
iSCSI(TargetName, PortalGroup, LUN, HeaderDigest, DataDigest, Authentication, 
Protocol)

I will generate the new patch to do definition at first and then do 
initialization. Thank you for this comment.

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Monday, October 15, 2018 10:23 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Cc: Wu, Jiaxin 
Subject: Re: [PATCH] uefi-sct/SctPkg:The Lun display order issue in iSCSI 
device path text



On 10/13/2018 05:33 PM, Eric Jin wrote:
> Cc: Supreeth Venkatesh 
> Cc: Jiaxin Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>   .../BlackBoxTest/DevicePathFromTextBBTestCoverage.c  | 12 ++--
>   1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git 
> a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackB
> oxTest/DevicePathFromTextBBTestCoverage.c 
> b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackB
> oxTest/DevicePathFromTextBBTestCoverage.c
> index fc099d8e..6f97924a 100644
> --- 
> a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackB
> oxTest/DevicePathFromTextBBTestCoverage.c
> +++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/Bl
> +++ ackBoxTest/DevicePathFromTextBBTestCoverage.c
> @@ -1,7 +1,7 @@
>   /** @file
>   
> Copyright 2006 - 2017 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2017, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2018, 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 @@ -1442,7 +1442,7 @@ CreateiScsiDeviceNode (
> CHAR16  *DataDigestStr;
> CHAR16  *AuthenticationStr;
> CHAR16  *ProtocolStr;
> -  UINT64  LunNum;
> +  UINT64  LunNum = 0;
EFI coding convention does not allow initialization during definition.
> ISCSI_DEVICE_PATH_WITH_NAME *iSCSI;
>   
> NameStr   = SctSplitStr (, L',');
> @@ -1459,7 +1459,7 @@ CreateiScsiDeviceNode (
>   );
> SctUnicodeToAscii (iSCSI->iSCSITargetName, NameStr, SctStrLen (NameStr));
> iSCSI->TargetPortalGroupTag = (UINT16) SctStrToUInt 
> (PortalGroupStr);
> -  SctStrToUInt64 (LunStr, );
> +  StrToUInt8Array(LunStr, );
> iSCSI->Lun = LunNum;
>   
> Options = 0x;
> @@ -2846,12 +2846,12 @@ DevicePathFromTextConvertTextToDeviceNodeCoverageTest 
> (
>   (UINTN)__LINE__
>   );
> //
> -  // TDS 3.10.1.2.26
> +  // TDS 3.10.1.2.26   0x5678 - byte 3 is 0x56 and byte4 is 0x78
> //
> -  SctStrCpy (text, 
> L"MyTargetName,0x12AB,5678,CRC32C,None,CHAP_BI,TCP");
> +  SctStrCpy (text, 
> + L"MyTargetName,0x12AB,0x00567800,CRC32C,None,CHAP_BI,TCP");
Magic String.
> pDevicePath = CreateiScsiDeviceNode(text);
>   
> -  SctStrCpy (text, 
> L"iSCSI(MyTargetName,0x12AB,5678,CRC32C,None,CHAP_BI,TCP)");
> +  SctStrCpy (text, 
> + L"iSCSI(MyTargetName,0x12AB,0x00567800,CRC32C,None,CHAP_BI,T
> + CP)");
Magic String.
> pReDevicePath = DevicePathFromText->ConvertTextToDeviceNode (text);
> if (SctCompareMem (pDevicePath, pReDevicePath, SctDevicePathNodeLength 
> ((EFI_DEVICE_PATH_PROTOCOL *) pReDevicePath)) == 0) {
>   AssertionType = EFI_TEST_ASSERTION_PASSED;

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

Re: [edk2] [edk2-test][Patch v2] uefi-sct/SctPkg:Assign 0 to the tail of HwErrRecVariableName.

[Jin, Eric]

Supreeth,

Thank you for the reminder. I correct them in the commit. Thanks.

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Friday, November 2, 2018 4:23 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Subject: Re: [edk2-test][Patch v2] uefi-sct/SctPkg:Assign 0 to the tail of 
HwErrRecVariableName.


Reviewed-by: Supreeth Venkatesh 

There are some unintentional indentation changes in "switch" statement.
Please take care of that before (if intentional, ok as well) commit.

On Thu, 2018-11-01 at 10:52 +0800, Eric Jin wrote:
> Add definition of HwErrRecVariableNamePrefixLength, 
> HwErrRecVariableNameIndexLength and HwErrRecVariableNameLength Make 
> the HwErrRecVariableName as the valid string.
> Ensure the HwErrRecVariable could be deleted before the test exit.
> 
> Cc: Supreeth Venkatesh 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  .../BlackBoxTest/VariableServicesBBTestFunction.c  | 38
> +-
>  .../BlackBoxTest/VariableServicesBBTestMain.h  | 13 +++-
>  2 files changed, 35 insertions(+), 16 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c b/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> index d1064ce..defe71a 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2012 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2012, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2018, 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 @@ -2855,7 +2855,7 @@ HardwareErrorRecordFuncTest (
>UINT64RemainingVariableStorageSize;
>UINT64MaximumVariableSize;
>
> -  CHAR16HwErrRecVariableName[13];
> +  CHAR16HwErrRecVariableName[HwErrRecVariableNameLen
> gth];
>CHAR16HwErrRecVariable[] = L"This is a HwErrRec
> variable!";
>
>CHAR16GetVariableName[MAX_BUFFER_SIZE];
> @@ -2864,7 +2864,7 @@ HardwareErrorRecordFuncTest (
>
>UINTN Num;
>UINTN MaxNum = 0;
> -  CHAR16ErrorNum[5];
> +  CHAR16ErrorNum[HwErrRecVariableNameIndexLength+1];
>
>CHAR16HwErrRecGetVariable[255];
>
> @@ -2908,7 +2908,11 @@ HardwareErrorRecordFuncTest (
>}
>  
>//
> -  // Read reset record
> +  // Try to read reset record from the RecoveryData,  // and the 
> + magic num is saved in the RecoveryData[0].
> +  // When the status is EFI_SUCCESS and magic num is 2,  // it means 
> + useful data has been saved before the reset  // and the date should 
> + be retrived goto particular process
>//
>Status = RecoveryLib->ReadResetRecord (
>RecoveryLib, @@ -2916,12 +2920,12 @@ 
> HardwareErrorRecordFuncTest (
>RecoveryData
>);
>if ( !EFI_ERROR(Status) && (RecoveryDataSize > 0) ) {
> -  switch (RecoveryData[0]) {
> +switch (RecoveryData[0]) {
Is the indentation change intentional? It looked good to me earlier and is ok 
with edk2 C coding standards as well.
>case 2:
>  goto step2;
>default:
>  goto step3;
> -  }
> +}
Is the indentation change intentional? It looked good to me earlier and is ok 
with edk2 C coding standards as well.
>}
>
>//
> @@ -2978,7 +2982,7 @@ HardwareErrorRecordFuncTest (
>// Get a useable variable name
>//
>GetVariableName[0] = L'\0';
> -  ErrorNum[4] = L'\0';
> +  ErrorNum[HwErrRecVariableNameIndexLength] = L'\0';
>
>  
>while (TRUE) {
> @@ -3001,9 +3005,9 @@ HardwareErrorRecordFuncTest (
>break;
>  }
>  
> -if ( (SctStrnCmp (GetVariableName, L"HwErrRec", 8) == 0) &&
> +if ( (SctStrnCmp (GetVariableName, L"HwErrRec",
> HwErrRecVariableNamePrefixLength) == 0) &&
>   (SctCompareGuid (, ) == 0) ) {
> -  SctStrnCpy (ErrorNum, [8], 4);
> +  SctStrnCpy (ErrorNum,
> [HwErrRecVariableNamePrefixLength],
> HwErrRecVariableNameIndexLength);
> 

Re: [edk2] [edk2-test][Patch] uefi-sct/SctPkg:Assign 0 to the tail of the HwErrRecVariableName

[Jin, Eric]

Hi Supreeth,

Got your worry. It is difficult to define the clear/meaningful macro to express 
the implication and avoid the ambiguity in my eye.
How about to document the clear comments in the key process?  It is more help 
for reading by someone new and sustaining. 


Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Thursday, November 1, 2018 12:24 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Cc: Wu, Jiaxin 
Subject: Re: [edk2-test][Patch] uefi-sct/SctPkg:Assign 0 to the tail of the 
HwErrRecVariableName

On Wed, 2018-10-31 at 02:29 +, Jin, Eric wrote:
> Hi Supreeth,
Hi Eric,
> 
> Thank for the comments.
> I will re-create the patch to add the definition of the
> HwErrRecVariableNamePrefixLength(8) and 
> HwErrRecVariableNameIndexLength(4).
Thank you.

>   
> There are two meanings to 2. To record the step number(2) used  by the 
> recoverylib or address (byte[2]) to save the recovery data
> (HwErrRecVariableName)
> It is not applicable macro definition and just code logic here. What 
> is your opinion?
Array Index [2] - In general one iterates over an array, performing some 
operation on each element, because one doesn't know how long the array is and 
you can't just access it in a hardcoded manner.
Does index "2" have special meaning, since this index is chosen rather than 0?

RecoveryData[0] = 2;
Does only "2" have special meaning?

Looks like we can define (or similar)
#define SecondResetRecord 2 (or something more meaningful)

and for array
#define HwErrRecIndex 2 (or something more meaningful)

No strong opinion - but someone new who starts developing test on top of this 
file will have a proper context and documentation to get going.

>  
> 
> Best Regards
> Eric
> 
> -Original Message-
> From: Supreeth Venkatesh 
> Sent: Wednesday, October 31, 2018 1:00 AM
> To: Jin, Eric ; edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; supreeth.venkat...@arm.com
> Subject: Re: [edk2-test][Patch] uefi-sct/SctPkg:Assign 0 to the tail 
> of the HwErrRecVariableName
> 
> Reviewed-by: Supreeth Venkatesh  If the 
> below magic number comments(inline) are fixed before commit.
> 
> On Tue, 2018-10-30 at 16:38 +0800, Eric Jin wrote:
> > Make the HwErrRecVariableName as valid the string.
> > Ensure the HwErrRecVariable could be deleted before the test exit.
> > 
> > Cc: Supreeth Venkatesh 
> > Cc: Jiaxin Wu 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Jin 
> > ---
> >  .../BlackBoxTest/VariableServicesBBTestFunction.c| 12
> > +++-
> >  .../BlackBoxTest/VariableServicesBBTestMain.h| 10
> > +-
> >  2 files changed, 16 insertions(+), 6 deletions(-)
> > 
> > diff --git a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/Black
> > Bo
> > xTest/VariableServicesBBTestFunction.c b/uefi- 
> > sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/Black
> > Bo
> > xTest/VariableServicesBBTestFunction.c
> > index d1064ce..df1bbe7 100644
> > --- a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/Black
> > Bo
> > xTest/VariableServicesBBTestFunction.c
> > +++ b/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/Black
> > Bo
> > xTest/VariableServicesBBTestFunction.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >  
> >Copyright 2006 - 2012 Unified EFI, Inc.
> > -  Copyright (c) 2010 - 2012, Intel Corporation. All rights 
> > reserved.
> > +  Copyright (c) 2010 - 2018, 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 @@ -2855,7 +2855,7 @@ HardwareErrorRecordFuncTest (
> >UINT64RemainingVariableStorageSize;
> >UINT64MaximumVariableSize;
> >
> > -  CHAR16HwErrRecVariableName[13];
> > +  CHAR16HwErrRecVariableName[HwErrRecVariableNameL
> > en
> > gth];
> >CHAR16HwErrRecVariable[] = L"This is a HwErrRec
> > variable!";
> >
> >CHAR16GetVariableName[MAX_BUFFER_SIZE];
> > @@ -3015,6 +3015,7 @@ HardwareErrorRecordFuncTest (
> >HwErrRecVariableName[0] = L'\0';
> >SctStrCat ( HwErrRecVariableName, L"HwErrRec" );
> >Myitox( MaxNum, HwErrRecVariableName+8 );
> 
> I understand this line is not part of this patch, but however can we 
> define "#define" for magic number 8, while we are touching this file.
>

Re: [edk2] [edk2-test][Patch] uefi-sct/SctPkg:Assign 0 to the tail of the HwErrRecVariableName

[Jin, Eric]

Hi Supreeth,

Thank for the comments.
I will re-create the patch to add the definition of the 
HwErrRecVariableNamePrefixLength(8) and HwErrRecVariableNameIndexLength(4).

There are two meanings to 2. To record the step number(2) used  by the 
recoverylib or address (byte[2]) to save the recovery data 
(HwErrRecVariableName)
It is not applicable macro definition and just code logic here. What is your 
opinion? 

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Wednesday, October 31, 2018 1:00 AM
To: Jin, Eric ; edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; supreeth.venkat...@arm.com
Subject: Re: [edk2-test][Patch] uefi-sct/SctPkg:Assign 0 to the tail of the 
HwErrRecVariableName

Reviewed-by: Supreeth Venkatesh  If the below magic 
number comments(inline) are fixed before commit.

On Tue, 2018-10-30 at 16:38 +0800, Eric Jin wrote:
> Make the HwErrRecVariableName as valid the string.
> Ensure the HwErrRecVariable could be deleted before the test exit.
> 
> Cc: Supreeth Venkatesh 
> Cc: Jiaxin Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin 
> ---
>  .../BlackBoxTest/VariableServicesBBTestFunction.c| 12
> +++-
>  .../BlackBoxTest/VariableServicesBBTestMain.h| 10
> +-
>  2 files changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c b/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> index d1064ce..df1bbe7 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestFunction.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2012 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2012, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2018, 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 @@ -2855,7 +2855,7 @@ HardwareErrorRecordFuncTest (
>UINT64RemainingVariableStorageSize;
>UINT64MaximumVariableSize;
>
> -  CHAR16HwErrRecVariableName[13];
> +  CHAR16HwErrRecVariableName[HwErrRecVariableNameLen
> gth];
>CHAR16HwErrRecVariable[] = L"This is a HwErrRec
> variable!";
>
>CHAR16GetVariableName[MAX_BUFFER_SIZE];
> @@ -3015,6 +3015,7 @@ HardwareErrorRecordFuncTest (
>HwErrRecVariableName[0] = L'\0';
>SctStrCat ( HwErrRecVariableName, L"HwErrRec" );
>Myitox( MaxNum, HwErrRecVariableName+8 );
I understand this line is not part of this patch, but however can we define 
"#define" for magic number 8, while we are touching this file.

> +  HwErrRecVariableName[HwErrRecVariableNameLength-1] = L'\0';
>
>//
>// Set the new HwErrRec variable to the global variable @@ -3036,8 
> +3037,8 @@ HardwareErrorRecordFuncTest (
>// Write reset record
>//
>RecoveryData[0] = 2;
I understand this line is not part of this patch, but however can we define 
"#define" for magic number 2, while we are touching this file.

> -  SctStrnCpy ( (CHAR16*)([2]), HwErrRecVariableName, 12 
> );
> -  RecoveryLib->WriteResetRecord( RecoveryLib, 13*sizeof(CHAR16)+2, 
> RecoveryData );
> +  SctStrnCpy ( (CHAR16*)([2]), HwErrRecVariableName,
> HwErrRecVariableNameLength-1 );
"#define" for magic number 2

> +  RecoveryLib->WriteResetRecord( RecoveryLib,
> HwErrRecVariableNameLength*sizeof(CHAR16)+2, RecoveryData );
"#define" for magic number 2

>
>//
>// Prompt the user about the cold reset and reset the system @@ 
> -3052,7 +3053,8 @@ HardwareErrorRecordFuncTest (
>//
>  step2:
>DataSize = 255;
> -  SctStrnCpy ( HwErrRecVariableName, (CHAR16*)(RecoveryData+2), 12 );
> +  HwErrRecVariableName[HwErrRecVariableNameLength-1] = L'\0';  
> + SctStrnCpy ( HwErrRecVariableName, (CHAR16*)(RecoveryData+2),
"#define" for magic number 2

> HwErrRecVariableNameLength-1 );
>Status = RT->GetVariable (
>  HwErrRecVariableName,
>  , diff --git a/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestMain.h b/uefi- 
> sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBo
> xTest/VariableServicesBBTestMa

Re: [edk2] [edk2-test] [PATCH 1/1] uefi-sct: Update "how to build" instructions.

[Jin, Eric]

Reviewed-by: Eric Jin 

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Thursday, October 11, 2018 12:46 PM
To: edk2-devel@lists.01.org
Cc: Jin, Eric ; Supreeth Venkatesh 

Subject: [edk2-test] [PATCH 1/1] uefi-sct: Update "how to build" instructions.

Update Build Instructions for UEFI SCTII AARCH64 (Linux) after repository 
change.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 uefi-sct/HowToBuild/How to build SCT in UDK2017.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/uefi-sct/HowToBuild/How to build SCT in UDK2017.txt 
b/uefi-sct/HowToBuild/How to build SCT in UDK2017.txt index 1a3bf1e8..146c9269 
100644
--- a/uefi-sct/HowToBuild/How to build SCT in UDK2017.txt   
+++ b/uefi-sct/HowToBuild/How to build SCT in UDK2017.txt   
@@ -59,11 +59,11 @@ Linux Environment
 Build Instructions for UEFI SCTII AARCH64 (Linux)
1) mkdir "sct_workspace"
2) cd sct_workspace
-   3) git clone https://github.com/UEFI/UEFI-SCT
+   3) git clone https://github.com/tianocore/edk2-test.git
4) git clone https://github.com/tianocore/edk2
5) cd edk2
6) git checkout UDK2017
-   7) ln -s ../UEFI-SCT/SctPkg SctPkg
+   7) ln -s ../edk2-test/uefi-sct/SctPkg SctPkg
8) cd ..
9) mkdir -p "tools/gcc"
   10) cd "tools/gcc"
@@ -72,7 +72,7 @@ Build Instructions for UEFI SCTII AARCH64 (Linux)
   13) cd ../..
   14) export 
PATH=$PATH:"$PWD/tools/gcc/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/bin"
   15) export 
CROSS_COMPILE="$PWD/tools/gcc/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-"
-  16) ./SctPkg/build.sh AARCH64 GCC
+  16) ../edk2-test/uefi-sct/SctPkg/build.sh AARCH64 GCC
 
 
 Build EMS :
--
2.17.0

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

[edk2] [edk2-test] The initial version of UEFI SCT has been uploaded

[Jin, Eric]

Hi All,

The initial version of UEFI SCT has been uploaded to 
https://github.com/tianocore/edk2-test and under the uefi-sct sub directory.
If you have interest, please help review. If you find any issue, please contact 
Supreeth and Eric in the cc-list. Thank you.


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

Re: [edk2] SCT forum help

[Jin, Eric]

Hi Amit Kumar,

Please send email to u...@uefi.org for the UEFI SCT discussion.
BTW, please make sure to provide more detail, such as the log, and your concern.
I don't see any attachment in your before email - [edk2] [NVMe SCT] Mistakes in 
nvmepassthru sct test case..  

Best Regards
Eric

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Amit 
kumar
Sent: Friday, November 24, 2017 12:49 AM
To: edk2-devel@lists.01.org
Subject: [edk2] SCT forum help

HI
Can somebody tell me the mail chain where i can discuss sct spec and test cases 
related issue ?

Best Regards
Amit Kumar

___
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][Patch 2/4] MdePkg/UefiDevicePathLib: Add DevPathFromTextDns and DevPathToTextDns libraries

[Jin, Eric]

Jiaxin,

In V2, the input parameter, TextDeviceNode, in the DevPathFromTextDns() is 
parsed by GetNextParamStr() twice.
After the first parse, the content of TextDeviceNode is modified and can 
convert to correct device path node.

Suggest to duplicate the TextDeviceNode or restore the return value of 1st 
GetNextParamStr() for usage in next step. Thanks.

Best Regards
Eric

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Wednesday, July 26, 2017 11:41 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin 

Subject: [edk2] [PATCH v2][Patch 2/4] MdePkg/UefiDevicePathLib: Add 
DevPathFromTextDns and DevPathToTextDns libraries

V2:
* Add no IP instance case check.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 .../Library/UefiDevicePathLib/DevicePathFromText.c | 80 ++
 .../Library/UefiDevicePathLib/DevicePathToText.c   | 46 +
 2 files changed, 126 insertions(+)

diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c 
b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
index f50c11c..3cdc11f 100644
--- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
+++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
@@ -2723,10 +2723,89 @@ DevPathFromTextBluetoothLE (
 );
   return (EFI_DEVICE_PATH_PROTOCOL *) BluetoothLeDp;  }
 
 /**
+  Converts a text device path node to DNS device path structure.
+
+  @param TextDeviceNode  The input Text device path node.
+
+  @return A pointer to the newly-created DNS device path structure.
+
+**/
+EFI_DEVICE_PATH_PROTOCOL *
+DevPathFromTextDns (
+  IN CHAR16 *TextDeviceNode
+  )
+{
+  CHAR16*DeviceNodeStr;
+  UINT32DnsServerIpCount;
+  UINT16DnsDeviceNodeLength;
+  DNS_DEVICE_PATH   *DnsDeviceNode;
+  UINT32DnsServerIpIndex;
+  CHAR16*DnsServerIp;
+
+
+  //
+  // Count the DNS server address number.
+  //
+  DeviceNodeStr= TextDeviceNode;
+  DnsServerIpCount = 0;
+  while (DeviceNodeStr != NULL && *DeviceNodeStr != L'\0') {
+GetNextParamStr ();
+DnsServerIpCount ++;
+  }
+
+  //
+  // One or more instances of the DNS server address in EFI_IP_ADDRESS,  
+ // otherwise, NULL will be returned.
+  //
+  if (DnsServerIpCount == 0) {
+return NULL;
+  }
+
+  //
+  // Create the DNS DeviceNode.
+  //
+  DnsDeviceNodeLength = (UINT16) (sizeof (EFI_DEVICE_PATH_PROTOCOL) + sizeof 
(UINT8) + DnsServerIpCount * sizeof (EFI_IP_ADDRESS));
+  DnsDeviceNode   = (DNS_DEVICE_PATH *) CreateDeviceNode (
+  MESSAGING_DEVICE_PATH,
+  MSG_DNS_DP,
+  DnsDeviceNodeLength
+  );
+
+  //
+  // Confirm the DNS server address is IPv4 or IPv6 type.
+  //
+  DeviceNodeStr = TextDeviceNode;
+  while (!IS_NULL (*DeviceNodeStr)) {
+if (*DeviceNodeStr == L'.') {
+  DnsDeviceNode->IsIPv6 = 0x00;
+  break;
+}
+
+if (*DeviceNodeStr == L':') {
+  DnsDeviceNode->IsIPv6 = 0x01;
+  break;
+}
+
+DeviceNodeStr++;
+  }
+
+  for (DnsServerIpIndex = 0; DnsServerIpIndex < DnsServerIpCount; 
DnsServerIpIndex++) {
+DnsServerIp = GetNextParamStr ();
+if (DnsDeviceNode->IsIPv6 == 0x00) {
+  StrToIpv4Address (DnsServerIp,  NULL, 
&(DnsDeviceNode->DnsServerIp[DnsServerIpIndex].v4), NULL);
+} else {
+  StrToIpv6Address (DnsServerIp, NULL, 
&(DnsDeviceNode->DnsServerIp[DnsServerIpIndex].v6), NULL);
+}
+  }
+  
+  return (EFI_DEVICE_PATH_PROTOCOL *) DnsDeviceNode; }
+
+/**
   Converts a text device path node to URI device path structure.
 
   @param TextDeviceNode  The input Text device path node.
 
   @return A pointer to the newly-created URI device path structure.
@@ -3395,10 +3474,11 @@ GLOBAL_REMOVE_IF_UNREFERENCED 
DEVICE_PATH_FROM_TEXT_TABLE mUefiDevicePathLibDevP
   {L"UsbTestAndMeasurement",   DevPathFromTextUsbTestAndMeasurement   },
   {L"UsbWwid", DevPathFromTextUsbWwid },
   {L"Unit",DevPathFromTextUnit},
   {L"iSCSI",   DevPathFromTextiSCSI   },
   {L"Vlan",DevPathFromTextVlan},
+  {L"Dns", DevPathFromTextDns },
   {L"Uri", DevPathFromTextUri },
   {L"Bluetooth",   DevPathFromTextBluetooth   },
   {L"Wi-Fi",   DevPathFromTextWiFi},
   {L"BluetoothLE", DevPathFromTextBluetoothLE },
   {L"MediaPath",   DevPathFromTextMediaPath   },
diff --git 

Re: [edk2] SCT Test failed

[Jin, Eric]

Hi karunakar,

I forward this discussion to UTWG since the UEFI SCT is not opensource project.

Best Regards
Eric

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Karunakar P
Sent: Tuesday, July 4, 2017 8:38 PM
To: edk2-devel@lists.01.org
Subject: [edk2] SCT Test failed

Hi All,

SCT GenericTest  failed NetworkPkg.

SCT version used:- UEFI2.5A_SCT_II_Release\UEFISCT\SctPackageX64

[Following are the test results]

GenericTest\EFICompliantTest   5.22.1.2.5 0  0  
98551AE7-5020-4DDD-861A-CFFFB4D60382   FAIL
EFI Compliant - PXE_BC protocols and one of UNDI/SNP/MNP must be implemented if 
a platform supports to boot from a network device. 
x:\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:1428:SetupMode
 equal zero - No  0x00010001 
A0A8BED3-3D6F-4AD8-907A-84D52EE1543B   No device path   
 PlatformSpecificElements_0_0_A0A8BED3-3D6F-4AD8-907A-84D52EE1543B.log

GenericTest\EFICompliantTest   5.22.1.2.23   0  
0  CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 
  FAILUEFI-Compliant - EFI_TLS_PROTOCOL, 
EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be 
existed if the platform supports TLS feature.
x:\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:3261:TLSSB-Y,
 TLSConfig-N   0x00010001 
A0A8BED3-3D6F-4AD8-907A-84D52EE1543B   No device path 
PlatformSpecificElements_0_0_A0A8BED3-3D6F-4AD8-907A-84D52EE1543B.log

Note: Along with above two failures some other failures also present.

Please let us know the details if fix is already present for this failures.
Please look into it and provide your comments/suggestions.


Thanks,
karunakar
___
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] UEFI SCT2.5A cannot run with exception

[Jin, Eric]

Hi Xiaofeng,

Could you please resend the email to u...@uefi.org for this question? I mean 
UEFI SCT is not the scope of the EDK2 community. 
Please don't forget to attach the log file. I don't see it or filtered by 
system. Thanks.

Best Regards
Eric

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of wang 
xiaofeng
Sent: Wednesday, June 7, 2017 9:41 AM
To: edk2-devel@lists.01.org
Subject: [edk2] UEFI SCT2.5A cannot run with exception

Hi ,
 Thanks all for your kind help.
I just update SCT from 2.4B to 2.5A,
WIth the same platform, 2.4B cannot be installed on EDK2 shell , we have to 
switch to EDK1 shell and then switch back. 2.4B can run on edk2shell.
2.5A aslo cannot be installed on EDK2 shell , we have to switch to EDK1 shell 
and then switch back. Unfortunatelly , the tool cannot run with an CPU 
exception. The attached file shows the serial log we see when the CPU exception 
occurs.
Any suggestion? Where is the SCT2.5 source code link ? I can try to debug the 
issue to see which code lead to the exception.
 
___
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] SCT 2.3.1 v1.3

[Jin, Eric]

I agree it is the gap between current UEFI SCT and UEFI Spec.
Removing the checkpoint from the test is simple. But the Spec enhancement on 
these missed error description is the better choice.

Best Regards
Eric

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Friday, January 20, 2017 5:35 PM
To: Laszlo Ersek ; Daniel Samuelraj 

Cc: Jianning Wang ; edk2-devel@lists.01.org; Sathya 
Prakash ; Chidambara GR 

Subject: Re: [edk2] SCT 2.3.1 v1.3

Laszlo:
  I agree this is gap between SCT and UEFI spec. I think UEFI spec can be 
updated to describe these error conditions. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>Laszlo Ersek
>Sent: Wednesday, January 18, 2017 4:57 PM
>To: Daniel Samuelraj 
>Cc: Jianning Wang ; 
>edk2-devel@lists.01.org; Sathya Prakash ; 
>Chidambara GR 
>Subject: Re: [edk2] SCT 2.3.1 v1.3
>
>(Dropping the  and  email addresses; 
>please never cross-post the public edk2-devel list with the 
>confidential spec development / working group lists on UEFI.org!)
>
>On 01/17/17 22:22, Daniel Samuelraj wrote:
>> Hi,
>>
>> What SCT v1.3 states for HII Config Access Protocol seems not in 
>> align with UEFI spec? For example, for extract config, when Progress 
>> or Result or Request is NULL, SCT is expecting EFI Invalid Parameter; 
>> similarly for Route Config, when progress is NULL, SCT expects 
>> EFI_INVALID_PARAMETER. UEFI spec doesn\u2019t seem mention anything 
>> for these cases.
>>
>>
>>
>> Should driver adhere to what SCT expects? Or is this fixed in newer 
>> SCT or will this be addressed in future? Please advise!
>
>I confirm this is a problem between the SCT and the UEFI spec.
>
>I've never personally built or used the SCT, but in 2015, Heyi Guo from 
>Linaro submitted patches for OVMF's PlatformDxe, some of which, for 
>example
>
>  [PATCH 2/3] OvmfPkg: PlatformDxe: Add sanity check for 
> HiiConfigAccess
>
>suppressed this kind of SCT failure report, by modifying OvmfPkg code.
>
>I didn't accept the patch, because we couldn't find any normative 
>reference (released UEFI spec version, or pending Mantis ticket) that 
>justified the SCT's expectations.
>
>... I would like to provide you with a mailing list archive link, but 
>that discussion was apparently only captured in the old GMANE archive, 
>and GMANE went belly-up a few months ago. Albeit being resuscitated, 
>the edk2-devel messages seem to be lost from it for good (or at least 
>cannot be looked up based on Message-Id).
>
>For lack of a better means, I'll quote one message from that thread 
>below, with context.
>
>Thanks
>Laszlo
>
>On 06/01/15 16:27, Laszlo Ersek wrote:
>> On 06/01/15 16:14, Laszlo Ersek wrote:
>>> On 06/01/15 14:08, Heyi Guo wrote:
 During UEFI SCT, it will throw an exception because "Progress" is 
 passed in with NULL and RouteConfig will try to access the string 
 at *(EFI_STRING *0), i.e. 0x14000400.

 Add sanity check for ExtractConfig and RouteConfig to avoid NULL 
 pointer dereference.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo 
 ---
  OvmfPkg/PlatformDxe/Platform.c | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/OvmfPkg/PlatformDxe/Platform.c
>b/OvmfPkg/PlatformDxe/Platform.c
 index 4ec327e..35fabf8 100644
 --- a/OvmfPkg/PlatformDxe/Platform.c
 +++ b/OvmfPkg/PlatformDxe/Platform.c
 @@ -234,6 +234,11 @@ ExtractConfig (
MAIN_FORM_STATE MainFormState;
EFI_STATUS  Status;

 +  if (Progress == NULL || Results == NULL)  {
 +return EFI_INVALID_PARAMETER;
 +  }
 +
DEBUG ((EFI_D_VERBOSE, "%a: Request=\"%s\"\n", __FUNCTION__,
>Request));

Status = PlatformConfigToFormState ();
>>>
>>> EFI_HII_CONFIG_ROUTING_PROTOCOL.ExtractConfig() does not require
>any of
>>> these checks. Both Progress and Results are OUT parameters (ie.
>>> pointers) and nothing in the spec resolves the caller from passing 
>>> in NULL (or non-NULL garbage, for that matter, which you couldn't 
>>> catch anyway).
>>>
>>> I can ACK this hunk if you show me a confirmed Mantis ticket for the 
>>> UEFI spec.
>>
>> Sorry, I just noticed that above I referenced 
>> EFI_HII_CONFIG_ROUTING_PROTOCOL rather than
>EFI_HII_CONFIG_ACCESS_PROTOCOL.
>>
>> However, after checking
>EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig()
>> specifically, I still can't see any requirement for these checks.
>>
 @@ -327,6 +332,11 @@ RouteConfig (
UINTN   BlockSize;
EFI_STATUS  Status;

 +  if 

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

[Jin, Eric]

"Memory Page size Minimum (MPSMIN)" is Controller Capability and impl-spec.
Is it possible for high level driver to get this attribute in UEFI scope?
To detect the  LIST LENGTH with (>8) buffer size and then get the whole list 
sounds like a reasonable method.

For SCT to handle this case, change the code to 
if(Status == EFI_SUCCESS) ||(Status == EFI_DEVICE_ERROR) || (Status == 
EFI_WARN_BUFFER_TOO_SMALL)){


Thanks
Eric

-Original Message-
From: Tian, Feng 
Sent: Monday, September 5, 2016 11:18 AM
To: Ramesh R. <rame...@ami.com>; edk2-devel <edk2-devel@lists.01.org>; Jin, 
Eric <eric@intel.com>
Cc: Tian, Feng <feng.t...@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Ramesh,

I suspect even if you send the buffer size as 512 all the devices should return 
EFI_SUCCESS as well.

As for different NVMe device behavior for length 10, it may be different 
understanding on spec.

Eric, 

Do you know how to handle such case in SCT?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Saturday, September 3, 2016 2:06 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

Some Nvme devices returns EFI_DEVICE_ERROR for the SCT test code ( when the 
buffer passed with 10 bytes) and that creates failure in the SCT report. 
Some Nvme devices returns EFI_SUCCESS also. 

All the devices return EFI_SUCCESS if the we send the buffer size as "Memory 
Page size Minimum (MPSMIN)"
   
Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 01 September 2016 8:12
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

I checked the ATA spec, it says the transfer length of "Trust-Send" ATA cmd 
should be 512.

But for NVMe and other SCSI device, I didn't see any length limitation on 
"Security Protocol In" cmd with security protocol field 0 and security protocol 
specific field 0.

It seems user could pass in any length value to get security protocol 
information. And last, user could get the whole one by passing down "supported 
security protocol list length" + 8.

Ramesh, do you meet real failure case?

Eric, what's your opinion on this?

Thanks
Feng

-Original Message-
From: Ramesh R. [mailto:rame...@ami.com] 
Sent: Wednesday, August 31, 2016 1:20 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

  Any update or suggestion on this? Can we consider this as SCT tool issue and 
would be fixed in next version ?

Thanks,
Ramesh

-Original Message-----
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 26 August 2016 12:54
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Yes, I agree it's weird. 

We are looking at this and will get back to you if we have findings.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Thursday, August 25, 2016 4:44 PM
To: edk2-devel <edk2-devel@lists.01.org>
Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi,

   When the we run the 
"BootableImageSupportTest\StorageSecurityCommandProtocolTest" test on the NVME 
devices we are getting into error because of the below testing code.

//
// According to TCG definition, when the Security Protocol field is set to 
00h, and SP
// Specific is set to h in a TRUSTED RECEIVE command, return security 
protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
   StorageSecurityCommand,
   BlockIo->Media->MediaId,
   1,// Timeout 
10-sec
   0,// 
SecurityProtocol
   0,// 
SecurityProtocolSpecifcData
   10,   // 
PayloadBufferSize,
   DataBuffer,   // 
PayloadBuffer
   
   );
//
// for ATA8-ACS SecurityProtocol, 512 byte is a request
//
if (IsAtaDevice) {
  if((Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

[Jin, Eric]

For the TRUSTED RECEIVE commands of the ATA8-ACS command, 
in the ATA8-ACS spec, the total data length shall be 512 bytes. Pad bytes are 
appended as needed to meet this requirement. Pad bytes shall have a value of 
00h.

For the SECURITY PROTOCOL IN commands of the SPC-4 command,
In the SPC-4 spec, when INC_512 is 0, the ALLOCATION LENGTH field expresses the 
number of bytes to be transferred. It means any value.
If the length is larger than 8 bytes, the byte 6-7 indicate the SUPPORTED 
SECURITY PROTOCOL LIST LENGTH. If the length is larger than (SECURITY PROTOCOL 
LIST LENGTH + 8), all are returned and plus the pad data.


Best Regards
Eric

-Original Message-
From: Tian, Feng 
Sent: Thursday, September 1, 2016 10:42 AM
To: Ramesh R. <rame...@ami.com>; edk2-devel <edk2-devel@lists.01.org>; Jin, 
Eric <eric@intel.com>
Cc: Tian, Feng <feng.t...@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

I checked the ATA spec, it says the transfer length of "Trust-Send" ATA cmd 
should be 512.

But for NVMe and other SCSI device, I didn't see any length limitation on 
"Security Protocol In" cmd with security protocol field 0 and security protocol 
specific field 0.

It seems user could pass in any length value to get security protocol 
information. And last, user could get the whole one by passing down "supported 
security protocol list length" + 8.

Ramesh, do you meet real failure case?

Eric, what's your opinion on this?

Thanks
Feng

-Original Message-
From: Ramesh R. [mailto:rame...@ami.com] 
Sent: Wednesday, August 31, 2016 1:20 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

  Any update or suggestion on this? Can we consider this as SCT tool issue and 
would be fixed in next version ?

Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 26 August 2016 12:54
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Yes, I agree it's weird. 

We are looking at this and will get back to you if we have findings.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Thursday, August 25, 2016 4:44 PM
To: edk2-devel <edk2-devel@lists.01.org>
Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi,

   When the we run the 
"BootableImageSupportTest\StorageSecurityCommandProtocolTest" test on the NVME 
devices we are getting into error because of the below testing code.

//
// According to TCG definition, when the Security Protocol field is set to 
00h, and SP
// Specific is set to h in a TRUSTED RECEIVE command, return security 
protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
   StorageSecurityCommand,
   BlockIo->Media->MediaId,
   1,// Timeout 
10-sec
   0,// 
SecurityProtocol
   0,// 
SecurityProtocolSpecifcData
   10,   // 
PayloadBufferSize,
   DataBuffer,   // 
PayloadBuffer
   
   );
//
// for ATA8-ACS SecurityProtocol, 512 byte is a request
//
if (IsAtaDevice) {
  if((Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
} else {
  if((!EFI_ERROR(Status)) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
}

For Ata devices, EFI_DEVICE_ERROR considered as valid error case and for the 
Nvme ( Non ATA) device it's considered as error. Could you please let us know 
why there is difference in this case ?.

Thanks,
Ramesh


___
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] MdeModulePkg/PciSioSerialDxe: Do not flush the UART

[Jin, Eric]

Reviewed-by: Eric Jin <eric@intel.com>

-Original Message-
From: Ni, Ruiyu 
Sent: Monday, May 9, 2016 1:04 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Jin, Eric <eric@intel.com>
Subject: [Patch] MdeModulePkg/PciSioSerialDxe: Do not flush the UART

The patch aligns to the IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe
driver not flush the UART in Reset() and SetAttributes() function.
It was found the flush causes hang on certain PCI serial devices.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
Cc: Eric Jin <eric@intel.com>
---
 MdeModulePkg/Bus/Pci/PciSioSerialDxe/SerialIo.c | 27 +
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/SerialIo.c 
b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/SerialIo.c
index f1870f3..cce61d7 100644
--- a/MdeModulePkg/Bus/Pci/PciSioSerialDxe/SerialIo.c
+++ b/MdeModulePkg/Bus/Pci/PciSioSerialDxe/SerialIo.c
@@ -1,7 +1,7 @@
 /** @file
   SerialIo implementation for PCI or SIO UARTs.
 
-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 @@ -442,27 +442,6 
@@ SerialReceiveTransmit (
   return EFI_SUCCESS;
 }
 
-/**
-  Flush the serial hardware transmit FIFO and shift register.
-
-  @param SerialDevice  The device to flush.
-**/
-VOID
-SerialFlushTransmitFifo (
-  SERIAL_DEV  *SerialDevice
-  )
-{
-  SERIAL_PORT_LSR  Lsr;
-
-  //
-  // Wait for the serial port to be ready, to make sure both the transmit FIFO
-  // and shift register empty.
-  //
-  do {
-Lsr.Data = READ_LSR (SerialDevice);
-  } while (Lsr.Bits.Temt == 0);
-}
-
 //
 // Interface Functions
 //
@@ -503,8 +482,6 @@ SerialReset (
 
   Tpl = gBS->RaiseTPL (TPL_NOTIFY);
 
-  SerialFlushTransmitFifo (SerialDevice);
-
   //
   // Make sure DLAB is 0.
   //
@@ -683,8 +660,6 @@ SerialSetAttributes (
 
   Tpl = gBS->RaiseTPL (TPL_NOTIFY);
 
-  SerialFlushTransmitFifo (SerialDevice);
-
   //
   // Put serial port on Divisor Latch Mode
   //
--
2.7.0.windows.1

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

Re: [edk2] SCT compilation failed with UEFI spec 2.5

[Jin, Eric]

Meenakshi,

Could you please the more information about the build step and the SCT/EDK2 
version?
BTW, since SCT is not the open source project, please send email to 
u...@uefi.org for discussion.

Best Regards
Eric

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Supreeth 
Venkatesh
Sent: Thursday, January 28, 2016 6:01 PM
To: Meenakshi Aggarwal; edk2-devel@lists.01.org
Subject: Re: [edk2] SCT compilation failed with UEFI spec 2.5

What is the SCT version that is being used?
Is the latest master from
git clone https://github.com/UEFI/UEFI-SCT.git being used?

Thanks,
Supreeth
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Meenakshi Aggarwal
Sent: Thursday, January 28, 2016 3:34 AM
To: edk2-devel@lists.01.org
Subject: [edk2] SCT compilation failed with UEFI spec 2.5

Hi,


I am facing following error while compiling SCT package:


n file included from 
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/MdePkg/Include/Uefi.h:24:0,
 from 
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/Build/UefiSct/DEBUG_GCC48/AARCH64/SctPkg/TestInfrastructure/SCT/Framework/Sct/DEBUG/AutoGen.h:17,
 from :0:
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/MdePkg/Include/Uefi/UefiSpec.h:1768:0:
 warning: "EFI_SPECIFICATION_VERSION" redefined [enabled by default]
#define EFI_SPECIFICATION_VERSION   EFI_SYSTEM_TABLE_REVISION
^
:0:0: note: this is the location of the previous definition
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/SctPkg/TestInfrastructure/SCT/Framework/Core/Sct.c:66:1:
 warning: missing braces around initializer [-Wmissing-braces] EFI_GUID 
gEfiSystemHangAssertionGuid = EFI_SYSTEM_HANG_ASSERTION_GUID; ^
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/SctPkg/TestInfrastructure/SCT/Framework/Core/Sct.c:66:1:
 warning: (near initialization for 'gEfiSystemHangAssertionGuid.Data4') 
[-Wmissing-braces]
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/SctPkg/TestInfrastructure/SCT/Framework/Core/Sct.c:
 In function 'PrintUsage':
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/SctPkg/TestInfrastructure/SCT/Framework/Core/Sct.c:226:5:
 error: 'EFI_SCT_NAME' undeclared (first use in this function)
 EFI_SCT_NAME,
 ^
/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/SctPkg/TestInfrastructure/SCT/Framework/Core/Sct.c:226:5:
 note: each undeclared identifier is reported only once for each function it 
appears in
make: *** 
[/proj/nmgsw_be/users/b46476/code/UEFI/stash/new/ls2080a-uefi-new/Build/UefiSct/DEBUG_GCC48/AARCH64/SctPkg/TestInfrastructure/SCT/Framework/Sct/OUTPUT/Core/Sct.obj]
 Error 1




Kindly help on what is the issue.



Thanks & Regards,
Meenakshi

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

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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] Nt32Pkg: Fix PlatformBootManagerLib to respect PcdShellFile.

[Jin, Eric]

Reviewed-by: Eric Jin <eric@intel.com>

-Original Message-
From: Ni, Ruiyu 
Sent: Wednesday, September 16, 2015 2:10 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Jin, Eric
Subject: [Patch] Nt32Pkg: Fix PlatformBootManagerLib to respect PcdShellFile.

Fix the code to use PcdShellFile instead of using hard code GUID
which always points to new UEFI shell.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
Cc: Eric Jin <eric@intel.com>
---
 Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c  | 5 +
 Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 5 +++--
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 3f634fc..e944105 100644
--- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -15,9 +15,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include "PlatformBootManager.h"
 
-
-EFI_GUID mUefiShellFileGuid = { 0x7C04A583, 0x9E3E, 0x4f1c, 0xAD, 0x65, 0xE0, 
0x52, 0x68, 0xD0, 0xB4, 0xD1 };
-
 /**
   Perform the platform diagnostic, such like test memory. OEM/IBV also
   can customize this function to support specific platform diagnostic.
@@ -220,7 +217,7 @@ PlatformBootManagerBeforeConsole (
   //
   // Register UEFI Shell
   //
-  PlatformRegisterFvBootOption (, L"UEFI Shell", 
LOAD_OPTION_ACTIVE);
+  PlatformRegisterFvBootOption (PcdGetPtr (PcdShellFile), L"UEFI Shell", 
LOAD_OPTION_ACTIVE);
 }
 
 /**
diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index d617538..9b1eeab 100644
--- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -65,9 +65,10 @@
 
 [Pcd]
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
+  gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn
-  gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport
+  gEfiMdeModulePkgTokenSpaceGuid.PcdConInConnectOnDemand
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdBootlogoOnlyEnable
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile
-  gEfiMdeModulePkgTokenSpaceGuid.PcdConInConnectOnDemand
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
-- 
1.9.5.msysgit.1

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