Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Andrew Fish]

> On Nov 10, 2015, at 12:06 AM, Gao, Liming  wrote:
> 
> Andrew:
>  The patch is missing.
> 

Liming,

My sent mail shows these 3 patches attached?
0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch

I attached again here:




Thanks,

Andrew Fish

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Tuesday, November 10, 2015 3:18 PM
> To: edk2-devel
> Cc: Tian, Feng
> Subject: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.
> 
> Please review the following patches as they are required to build with Xcode 
> 6.3.2.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Andrew Fish]

> On Nov 10, 2015, at 7:04 AM, Andrew Fish  wrote:
> 
> 
>> On Nov 10, 2015, at 12:06 AM, Gao, Liming  wrote:
>> 
>> Andrew:
>> The patch is missing.
>> 
> 
> Liming,
> 
> My sent mail shows these 3 patches attached?
> 0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
> 0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
> 0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch
> 
> I attached again here:
> 
> 

>cat 0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
>From 7f82886d42a82d939760562ab3f992ae6a3a70b7 Mon Sep 17 00:00:00 2001
From: andrew fish 
Date: Mon, 9 Nov 2015 22:31:03 -0800
Subject: [PATCH 2/4] MdeModulePkg: RegularExpressionDxe Xcode warnings fixes

ErrorMessage generates a Wpointer-sign error, char * vs unsigned char *
assigning structures with = generate memcpy link failures.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
---
 MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c  | 9 ++---
 MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c | 2 +-
 .../Universal/RegularExpressionDxe/RegularExpressionDxe.c| 4 ++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c
index 25b768b..7c9771f 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c
@@ -70,7 +70,10 @@ static void
 swap_node(Node* a, Node* b)
 {
   Node c;
-  c = *a; *a = *b; *b = c;
+  //c = *a; *a = *b; *b = c;
+  xmemcpy (, a, sizeof (Node));
+  xmemcpy (a, b, sizeof (Node));
+  xmemcpy (b, , sizeof (Node));
 
   if (NTYPE(a) == NT_STR) {
 StrNode* sn = NSTR(a);
@@ -4348,7 +4351,7 @@ clear_opt_map_info(OptMapInfo* map)
 static void
 copy_opt_map_info(OptMapInfo* to, OptMapInfo* from)
 {
-  *to = *from;
+  xmemcpy(to, from, sizeof(OptMapInfo));
 }
 
 static void
@@ -4463,7 +4466,7 @@ clear_node_opt_info(NodeOptInfo* opt)
 static void
 copy_node_opt_info(NodeOptInfo* to, NodeOptInfo* from)
 {
-  *to = *from;
+  xmemcpy(to, from, sizeof (NodeOptInfo));
 }
 
 static void
diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c
index 01ac2b3..38fceb4 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c
@@ -2211,7 +2211,7 @@ onig_reduce_nested_quantifier(Node* pnode, Node* cnode)
 
   switch(ReduceTypeTable[cnum][pnum]) {
   case RQ_DEL:
-*pnode = *cnode;
+xmemcpy (pnode, cnode, sizeof (Node));
 break;
   case RQ_A:
 p->target = c->target;
diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
index a3eebf7..453c1eb 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
@@ -120,7 +120,7 @@ OnigurumaMatch (
  );
 
   if (OnigResult != ONIG_NORMAL) {
-onig_error_code_to_str (ErrorMessage, OnigResult, );
+onig_error_code_to_str ((OnigUChar *)ErrorMessage, OnigResult, );
 DEBUG ((DEBUG_ERROR, "Regex compilation failed: %a\n", ErrorMessage));
 return EFI_DEVICE_ERROR;
   }
@@ -144,7 +144,7 @@ OnigurumaMatch (
   } else {
 *Result = FALSE;
 if (OnigResult != ONIG_MISMATCH) {
-  onig_error_code_to_str (ErrorMessage, OnigResult);
+  onig_error_code_to_str ((OnigUChar *)ErrorMessage, OnigResult);
   DEBUG ((DEBUG_ERROR, "Regex match failed: %a\n", ErrorMessage));
 }
   }
-- 
2.3.2 (Apple Git-55)


> 
> 
> Thanks,
> 
> Andrew Fish
> 
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Andrew Fish
>> Sent: Tuesday, November 10, 2015 3:18 PM
>> To: edk2-devel
>> Cc: Tian, Feng
>> Subject: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.
>> 
>> Please review the following patches as they are required to build with Xcode 
>> 6.3.2.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

[edk2] Filesystem issues since "OvmfPkg: enable SATA controller"

[Mark Rutland]

I've been trying to test an EFI application on x86_64 using Ubuntu 14.04's QEMU
2.0.0. I have a directory 'foo' containing the application, and I get QEMU to
create a virtual FAT device:

$ qemu-system-x86_64 -nographic \
-bios src/edk2/Build/OvmfX64/RELEASE_GCC48/FV/OVMF.fd \
-hda fat:foo

However, I'm unable to access the root filesystem:

UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (EDK II, 0x0001)
Mapping table
  FS0: Alias(s):HD7a1:;BLK3:
  PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
 BLK2: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
 BLK4: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
 BLK0: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
 BLK1: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:
FS0:\> dir
ls: File Not Found - 'FS0:\'

With git, I bisected this down to the commit "OvmfPkg: enable SATA controller".

Any ideas as to what the problem could be?

I don't have a newer qemu-system-x86_64 lying around, so I haven't been able to
test with that.

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

Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Andrew Fish]

> On Nov 10, 2015, at 7:04 AM, Andrew Fish  wrote:
> 
> 
>> On Nov 10, 2015, at 12:06 AM, Gao, Liming  wrote:
>> 
>> Andrew:
>> The patch is missing.
>> 
> 
> Liming,
> 
> My sent mail shows these 3 patches attached?
> 0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
> 0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
> 0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch
> 
> I attached again here:
> 


>cat 0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
>From 4eb94d539de6ee8e4b8eebc43d67dfdfe68e64bf Mon Sep 17 00:00:00 2001
From: andrew fish 
Date: Mon, 9 Nov 2015 22:29:54 -0800
Subject: [PATCH 1/4] MdeModulePkg:PeiCore Fix Xcode -Wempty-body warning The
 single line for(); construct is followd by code that is indented. This
 trigers the -Wempty-body warning. Fix indentation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
---
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 7480b66..dbcd800 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -681,15 +681,15 @@ PeiCheckAndSwitchStack (
&& (*StackPointer == INIT_CAR_VALUE);
StackPointer ++);
 
-DEBUG ((EFI_D_INFO, "Temp Stack : BaseAddress=0x%p Length=0x%X\n", 
SecCoreData->StackBase, (UINT32)SecCoreData->StackSize));
-DEBUG ((EFI_D_INFO, "Temp Heap  : BaseAddress=0x%p Length=0x%X\n", 
Private->HobList.Raw, (UINT32)((UINTN) 
Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - (UINTN) 
Private->HobList.Raw)));
-DEBUG ((EFI_D_INFO, "Total temporary memory:%d bytes.\n", 
(UINT32)SecCoreData->TemporaryRamSize));
-DEBUG ((EFI_D_INFO, "  temporary memory stack ever used: %d bytes.\n",
-   (UINT32)(SecCoreData->StackSize - ((UINTN) StackPointer - 
(UINTN)SecCoreData->StackBase))
-  ));
-DEBUG ((EFI_D_INFO, "  temporary memory heap used:   %d bytes.\n",
-   
(UINT32)((UINTN)Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - 
(UINTN)Private->HobList.Raw)
-  ));
+  DEBUG ((EFI_D_INFO, "Temp Stack : BaseAddress=0x%p Length=0x%X\n", 
SecCoreData->StackBase, (UINT32)SecCoreData->StackSize));
+  DEBUG ((EFI_D_INFO, "Temp Heap  : BaseAddress=0x%p Length=0x%X\n", 
Private->HobList.Raw, (UINT32)((UINTN) 
Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - (UINTN) 
Private->HobList.Raw)));
+  DEBUG ((EFI_D_INFO, "Total temporary memory:%d bytes.\n", 
(UINT32)SecCoreData->TemporaryRamSize));
+  DEBUG ((EFI_D_INFO, "  temporary memory stack ever used: %d bytes.\n",
+ (UINT32)(SecCoreData->StackSize - ((UINTN) StackPointer - 
(UINTN)SecCoreData->StackBase))
+));
+  DEBUG ((EFI_D_INFO, "  temporary memory heap used:   %d bytes.\n",
+ 
(UINT32)((UINTN)Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - 
(UINTN)Private->HobList.Raw)
+));
 DEBUG_CODE_END ();
 
 if (PcdGet64(PcdLoadModuleAtFixAddressEnable) != 0 && 
(Private->HobList.HandoffInformationTable->BootMode != BOOT_ON_S3_RESUME)) {
-- 
2.3.2 (Apple Git-55)


> 
> 
> 
> Thanks,
> 
> Andrew Fish
> 
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Andrew Fish
>> Sent: Tuesday, November 10, 2015 3:18 PM
>> To: edk2-devel
>> Cc: Tian, Feng
>> Subject: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.
>> 
>> Please review the following patches as they are required to build with Xcode 
>> 6.3.2.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-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] ShellPkg: Network commands (ifconfig/ping) broken

[Laszlo Ersek]

On 11/10/15 15:36, Carsey, Jaben wrote:
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, November 10, 2015 3:54 AM
>> To: Leif Lindholm 
>> Cc: edk2-devel@lists.01.org ; Wu, Jiaxin
>> 
>> Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
>> Importance: High
>>
>> On 11/10/15 11:43, Leif Lindholm wrote:
>>> On Tue, Nov 10, 2015 at 11:28:10AM +0100, Laszlo Ersek wrote:
 On 11/10/15 11:20, Conen, Johannes wrote:
> Hmm, you're right. is it briefly mentioned in the "ShellPkg
> Notes.txt" - I must admit, I only took a look at the
> "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major
>> changes
> to mentioned there (and well, they were, like the moving of the
> library files). So this non-backwards-compatibility from UDK2015 to
> UDK2014 regarding network-related stuff is intended?

 I'll have to let Jiaxin answer this question; I'm not a participant in
 UDK feature planning. And, I have no idea how UDK releases account for
 compatibility in general.

 (My *guess* is that UDK2015 generally targets (or moved towards) UEFI
 2.5, and Ip4Config (version 1) is apparently deprecated in UEFI 2.5.)
>>>
>>> The actual wording from the specification is:
>>> ---
>>> The EFI_IP4_CONFIG_PROTOCOL has been replaced with the new
>>> EFI_IP4_CONFIG2_PROTOCOL.
>>> • All new designs based on this specification should exclusively use
>>>   EFI_IP4_CONFIG2_PROTOCOL .
>>> • The EFI_IP4_CONFIG_PROTOCOL will be removed in the next revision of
>>>   this specification.
>>> ---
>>>
>>> Clearly this creates a compatibility breakage at some point.
>>>
>>> Is this something we consider "not a problem", or should the shell
>>> implement (providing a reference for how to implement) fallback to
>>> EFI_IP4_CONFIG_PROTOCOL if EFI_IP4_CONFIG2_PROTOCOL is not available?
>>
>> Whether the shell in edk2 should or should not provide fallback code for
>> EFI_IP4_CONFIG_PROTOCOL is for Intel to answer :), but I think I can ask
>> one more question as to "how".
>>
>> Namely, if one adds (or keeps) the Ip4Config fallback code to (in) the
>> shell in edk2, how does that compat feature get tested, staying within
>> the tree? It would require keeping the Ip4Config protocol implementation
>> around just for the sake of testing the fallback.
>>
>> I don't think that's a good idea.
>>
>> Instead, any dependencies on specific versions of the UEFI spec should
>> be spelled out loud and clear. (I believe I've read such requirements
>> presented by Windows, on MSDN.) Mapping each UDK release to a UEFI spec
>> version would be a bonus.
> 
> Seems like the short answer here is that the config command has a missing 
> error condition/printout.  If this has simply stated something like "the 
> required protocol (EFI_IP4_CONFIG2_PROTOCOL) was not found." I think we would 
> have gotten to the answer a lot closer.
> 
> The intention was to replace support for EFI_IP4_CONFIG_PROTOCOL with 
> EFI_IP4_CONFIG2_PROTOCOL, we do not believe that we can successfully maintain 
> functional support for EFI_IP4_CONFIG_PROTOCOL.
> 
> Should (used above) is one of those words where the meaning is vague.  Should 
> it do backwards compatibility and if so, for how long?

What I care about is bisectability within edk2. We had discussed that at
length with Jiaxin, and the end result (that is, how the patches were
ultimately organized) was good.

Personally I don't need UDK to maintain compatibility between its
various components cross-release. (I'm not a UDK user at all.)
Generally, I don't think that it would be an easily supportable position.

I'll draw a crude analogy here. (I hope to be corrected if I'm wrong in
the details.)

The upstream Linux kernel doesn't provide any kind of binary (or even
source) compatibility for kernel modules that exist outside of the
central tree.

Red Hat guarantees kernel ABI compatibility between minor releases of
any given major RHEL release, as a value-add, for an explicit white-list
of symbols.

Keeping the kernel ABI intact between minor releases is resource
demanding. It also leads to accumulation of cruft and ossification of
internals (which is why the upstream Linux kernel community doesn't care
about this external stability at all). At each new major RHEL release,
the kABI white-list is redesigned from zero, and there is no promise of
kABI stability between major releases. (The cruft accumulated in the
previous major release is not carried forward.)

(Disclaimer: the above is my personal recollection; I'm not a kABI
specialist, and my words are *not* an official statement or
representation from RH. They just illustrate the idea.)

My point is, for any kind of stability guarantee / compatibility with
code that exists *outside* of the open source tree, a whole separate
*program* is necessary. 

Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Andrew Fish]

> On Nov 10, 2015, at 7:04 AM, Andrew Fish  wrote:
> 
>> 
>> On Nov 10, 2015, at 12:06 AM, Gao, Liming > > wrote:
>> 
>> Andrew:
>> The patch is missing.
>> 
> 
> Liming,
> 
> My sent mail shows these 3 patches attached?
> 0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
> 0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
> 0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch
> 
> I attached again here:
> 
> 


>cat 0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch
>From 56cea06ce806fd0ac9295e1211964f30e6baaac1 Mon Sep 17 00:00:00 2001
From: andrew fish 
Date: Mon, 9 Nov 2015 22:42:57 -0800
Subject: [PATCH 3/4] MdeModulePkg: Variable add mising VA_COPY

Xcode fails to compile:
error: array type 'VA_LIST' (aka '__builtin_va_list') is not assignable

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 621ce16..8a07f0e 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -1716,7 +1716,7 @@ CheckRemainingSpaceForConsistencyInternal (
   ASSERT_EFI_ERROR (Status);
 
   TotalNeededSize = 0;
-  Args = Marker;
+  VA_COPY (Args, Marker);
   VariableEntry = VA_ARG (Args, VARIABLE_ENTRY_CONSISTENCY *);
   while (VariableEntry != NULL) {
 //
@@ -1745,7 +1745,7 @@ CheckRemainingSpaceForConsistencyInternal (
 return FALSE;
   }
 
-  Args = Marker;
+  VA_COPY (Args, Marker);
   VariableEntry = VA_ARG (Args, VARIABLE_ENTRY_CONSISTENCY *);
   while (VariableEntry != NULL) {
 //
-- 
2.3.2 (Apple Git-55)


> 
> 
> Thanks,
> 
> Andrew Fish
> 
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Andrew Fish
>> Sent: Tuesday, November 10, 2015 3:18 PM
>> To: edk2-devel
>> Cc: Tian, Feng
>> Subject: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.
>> 
>> Please review the following patches as they are required to build with Xcode 
>> 6.3.2.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-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] Authentication status for signed FVs extracted in PEI

[Cohen, Eugene]

Liming and Star,

Thanks for the suggestion for extending the FV HOB.  I'm not sure if the length 
change will be considered forwards and backwards compatible for all 
implementations.  If people refer to the HOB by pointer it shouldn't be a 
problem but if they try to copy the HOB using the header length they may have a 
compatibility problem.

I'll raise your suggestion at PIWG and see what the group recommends.

Thanks,

Eugene

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Tuesday, November 10, 2015 3:27 AM
To: Zeng, Star ; Cohen, Eugene ; 
edk2-devel@lists.01.org
Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI

Eugene:
  Another idea is to update FV HOB to include authentication status instead of 
adding FV HOB3. The consumer code can check FV HOB Length to know whether FV 
HOB includes authentication status. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
> Star
> Sent: Tuesday, November 10, 2015 6:19 PM
> To: Cohen, Eugene; edk2-devel@lists.01.org
> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
> 
> On 2015/11/9 21:57, Cohen, Eugene wrote:
> > Star,
> >
> >> The authentication status and its inheritance support in FvInfo2 and FvPpi 
> >> were covered by the mantis we submitted to support PEI
> security and to be equivalent with DXE.
> > You raised another issue here to inherit authentication status from PEI to 
> > DXE.
> >
> > Correct.
> >
> >> Currently, only verified pass FV in PEI will be processed and reported 
> >> with FV HOB to DXE.
> >
> > The FV HOB doesn't explicitly say whether the FV was verified or not.  We 
> > have a use case where we have one FV that contains code
> and is verified and another FV that contains some data and is not verified.  
> With the current FV HOB definitions there's no way to
> differentiate these two.
> 
> Curious about the FV you said is root or child FV?
> 
> >
> > The DXE core just assumes that all FVs passed through FV hobs are unsigned 
> > (AuthenticationStatus = 0).  So in DXE-phase security
> policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting 
> accurate AuthenticationStatus values with which to make a
> decision.
> >
> > So in a way this just seems wrong since the security callbacks are saying 
> > that FVs are unsigned when in reality there are signed and
> verified.
> >
> > I'm thinking this could be as simple as an updated FV HOB definition that 
> > adds an AuthenticationStatus field.
> 
> I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to
> include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one
> FV. Seemingly, we could not to just extend FV HOB to include
> AuthenticationStatus, right?
> 
> Thanks,
> Star
> 
> >
> > Eugene
> >
> > -Original Message-
> > From: Zeng, Star [mailto:star.z...@intel.com]
> > Sent: Monday, November 09, 2015 6:43 AM
> > To: Cohen, Eugene ; edk2-devel@lists.01.org
> > Cc: Zeng, Star 
> > Subject: RE: Authentication status for signed FVs extracted in PEI
> >
> > The authentication status and its inheritance support in FvInfo2 and FvPpi 
> > were covered by the mantis we submitted to support PEI
> security and to be equivalent with DXE.
> > You raised another issue here to inherit authentication status from PEI to 
> > DXE.
> >
> > Currently, only verified pass FV in PEI will be processed and reported with 
> > FV HOB to DXE.
> > Your real case will have different policy to verify FV in PEI and DXE phase?
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Cohen, Eugene
> > Sent: Monday, November 9, 2015 9:03 PM
> > To: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
> >
> > I raised this as an issue with PIWG.  In the meantime feel free to provide 
> > some historical context for why this hasn't been an issue in
> other implementations.
> >
> > Thanks,
> >
> > Eugene
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Cohen, Eugene
> > Sent: Friday, November 06, 2015 5:49 PM
> > To: edk2-devel@lists.01.org
> > Cc: Thompson, Mark L. (Boise IPG) 
> > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
> >
> > [Corrected the typos with a new version - proofreading is a good thing]
> >
> >
> > I'm confused about something and hope I can get some help understanding 
> > this.
> >
> > If we have a signed FV that is extracted in PEI it doesn't look like the 
> > AuthenticationStatus gets propagated to DXE.
> >
> > The hob doesn't store authentication status and the core produces FVB with 
> > AuthenticationStatus forced to zero, even though the FV
> was signed and verified.
> >
> > 

Re: [edk2] [patch] NetworkPkg: Report Http Errors to screen when http layer occurs an error

[El-Haj-Mahmoud, Samer]

Reviewed-by: Samer El-Haj-Mahmoud 

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com] 
Sent: Monday, November 09, 2015 7:52 PM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Wu, Jiaxin ; 
El-Haj-Mahmoud, Samer 
Subject: RE: [patch] NetworkPkg: Report Http Errors to screen when http layer 
occurs an error

Looks good to me.

Reviewed-by: Ye Ting  

-Original Message-
From: Zhang, Lubo
Sent: Monday, November 09, 2015 5:57 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin; Samer El-Haj-Mahmoud
Subject: [patch] NetworkPkg: Report Http Errors to screen when http layer 
occurs an error

v2:
* Change the print message to a more readable string and add the redirection 
status code
(3xx)

Cc: Ye Ting 
Cc: Fu Siyuan 
CC: Wu Jiaxin 
CC: Samer El-Haj-Mahmoud 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/HttpBootDxe/HttpBootSupport.c | 151 ++-
 1 file changed, 150 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootSupport.c 
b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
index d08111f..1fc4e76 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootSupport.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
@@ -145,10 +145,153 @@ HttpBootShowIp6Addr (
 }
   }
 }
 
 /**
+  This function is to display the HTTP error status.
+
+  @param[in]  StatusCode  The status code value in HTTP message.
+
+**/
+VOID
+HttpBootPrintErrorMessage (
+  EFI_HTTP_STATUS_CODEStatusCode
+  )
+{
+  AsciiPrint ("\n");
+
+  switch (StatusCode) {
+  case HTTP_STATUS_300_MULTIPLE_CHIOCES:
+AsciiPrint ("\n  Redirection: 300 Multiple Choices");
+break;
+
+  case HTTP_STATUS_301_MOVED_PERMANENTLY:
+AsciiPrint ("\n  Redirection: 301 Moved Permanently");
+break;
+
+  case HTTP_STATUS_302_FOUND:
+AsciiPrint ("\n  Redirection: 302 Found");
+break;
+
+  case HTTP_STATUS_303_SEE_OTHER:
+AsciiPrint ("\n  Redirection: 303 See Other");
+break;
+
+  case HTTP_STATUS_304_NOT_MODIFIED:
+AsciiPrint ("\n  Redirection: 304 Not Modified");
+break;
+
+  case HTTP_STATUS_305_USE_PROXY:
+AsciiPrint ("\n  Redirection: 305 Use Proxy");
+break;
+
+  case HTTP_STATUS_307_TEMPORARY_REDIRECT:
+AsciiPrint ("\n  Redirection: 307 Temporary Redirect");
+break;
+
+  case HTTP_STATUS_400_BAD_REQUEST:
+AsciiPrint ("\n  Client Error: 400 Bad Request");
+break;
+
+  case HTTP_STATUS_401_UNAUTHORIZED:
+AsciiPrint ("\n  Client Error: 401 Unauthorized");
+break;
+
+  case HTTP_STATUS_402_PAYMENT_REQUIRED:
+AsciiPrint ("\n  Client Error: 402 Payment Required");
+break;
+
+  case HTTP_STATUS_403_FORBIDDEN:
+AsciiPrint ("\n  Client Error: 403 Forbidden");
+break;
+
+  case HTTP_STATUS_404_NOT_FOUND:
+AsciiPrint ("\n  Client Error: 404 Not Found");
+break;
+
+  case HTTP_STATUS_405_METHOD_NOT_ALLOWED:
+AsciiPrint ("\n  Client Error: 405 Method Not Allowed");
+break;
+
+  case HTTP_STATUS_406_NOT_ACCEPTABLE:
+AsciiPrint ("\n  Client Error: 406 Not Acceptable");
+break;
+
+  case HTTP_STATUS_407_PROXY_AUTHENTICATION_REQUIRED:
+AsciiPrint ("\n  Client Error: 407 Proxy Authentication Required");
+break;
+
+  case HTTP_STATUS_408_REQUEST_TIME_OUT:
+AsciiPrint ("\n  Client Error: 408 Request Timeout");
+break;
+
+  case HTTP_STATUS_409_CONFLICT:
+AsciiPrint ("\n  Client Error: 409 Conflict");
+break;
+
+  case HTTP_STATUS_410_GONE:
+AsciiPrint ("\n  Client Error: 410 Gone");
+break;
+
+  case HTTP_STATUS_411_LENGTH_REQUIRED:
+AsciiPrint ("\n  Client Error: 411 Length Required");
+break;
+
+  case HTTP_STATUS_412_PRECONDITION_FAILED:
+AsciiPrint ("\n  Client Error: 412 Precondition Failed");
+break;
+
+  case HTTP_STATUS_413_REQUEST_ENTITY_TOO_LARGE:
+AsciiPrint ("\n  Client Error: 413 Request Entity Too Large");
+break;
+
+  case HTTP_STATUS_414_REQUEST_URI_TOO_LARGE:
+AsciiPrint ("\n  Client Error: 414 Request URI Too Long");
+break;
+
+  case HTTP_STATUS_415_UNSUPPORTED_MEDIA_TYPE:
+AsciiPrint ("\n  Client Error: 415 Unsupported Media Type");
+break;
+
+  case HTTP_STATUS_416_REQUESTED_RANGE_NOT_SATISFIED:
+AsciiPrint ("\n  Client Error: 416 Requested Range Not Satisfiable");
+break;
+
+  case HTTP_STATUS_417_EXPECTATION_FAILED:
+AsciiPrint ("\n  Client Error: 417 Expectation Failed");
+break;
+
+  case HTTP_STATUS_500_INTERNAL_SERVER_ERROR:
+AsciiPrint ("\n  Server Error: 500 Internal Server Error");
+break;
+
+  case HTTP_STATUS_501_NOT_IMPLEMENTED:
+AsciiPrint ("\n  Server Error: 501 Not Implemented");
+break;
+
+  case HTTP_STATUS_502_BAD_GATEWAY:
+AsciiPrint ("\n  

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Vladimir Olovyannikov]

Ard,
Many thanks for your help. It works.

Vladimir

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Monday, November 09, 2015 10:31 PM
To: Vladimir Olovyannikov
Cc: Cohen, Eugene; edk2-devel@lists.01.org
Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
step-by-step debugging in uefi

On 9 November 2015 at 19:01, Vladimir Olovyannikov
 wrote:
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Sunday, November 08, 2015 10:52 PM
> To: Vladimir Olovyannikov
> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
> step-by-step debugging in uefi
>
> On 6 November 2015 at 21:32, Vladimir Olovyannikov
> > wrote:
>>> Hello Ard, Eugene,
>>> Thank you for explanation.
>>>
>>> Ard, I tried the patch, but it cannot be applied to the latest (pulled a 
>>> minute ago, git-svn-id: 
>>> https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 
>>> 6f19259b-4bc3-4df7-8a09-765794883524)
>>> tree: all 3 hunks failed. Which commit should I be based on to apply the 
>>> patch?
>>>
>>> Anyway I found the lines manually and changed them. However, when I try to
>>>
>>> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
>>> (0x8500,0x0028) -m (0x8000,0x4000) -a
>>> I am getting
>>>
>>> ERROR(?): ValueError: need more than 1 value to unpack
>>>   File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py", line 94, in 
>>> >
>>> armplatform_debugger.load_all_symbols()
>>> ERROR(CMD656):
>>> # in /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2 while 
>>> executing: source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
>>> (0x8500,0x0028) -m (0x8000,0x4000) -a
>>> ! The script /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py failed to 
>>> complete due to an error during execution of the script
>>>
>>> Replacing the script with the older version makes it work as before, but 
>>> again the debugger is useless.
>>>
>>> Any idea what is wrong?
>>>
>
>>No, not a clue. But could you please share the diff between the
>>version of the script that works for you and the version that doesn't?
>>I don't think the patch I sent could trigger the error you are seeing,
>>so it must be something else that changed.
> Here is the diff.
>
> --- firmware_volume_old.py  2015-06-24 15:15:37.0 -0700
> +++ firmware_volume_new.py  2015-11-06 11:49:24.321730539 -0800
> @@ -91,12 +91,7 @@
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -stripped_size = struct.unpack(" self.ec.getMemoryService().read(self.base_te + 0x6, 2, 32))[0]
> -stripped_size -= EfiSectionTE.SIZEOF_EFI_TE_IMAGE_HEADER
> -
> -base_of_code = self.ec.getMemoryService().readMemory32(self.base_te 
> + 0xC)
> -
> -return self.base_te + base_of_code - stripped_size
> +return self.base_pe32
>

This hunk is incorrect. Could you please try the patch instead?
(attached, this time, so it should apply more easily)

Thanks,
Ard.

>  class EfiSectionPE32:
>  def __init__(self, ec, base_pe32):
> @@ -131,17 +126,7 @@
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -# Offset from dos hdr to PE file hdr
> -pe_file_header = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(self.base_pe32 + 0x3C)
> -
> -base_of_code = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
> -base_of_data = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
> -
> -if (base_of_code < base_of_data) and (base_of_code != 0):
> -return base_of_code
> -else:
> -return base_of_data
> -
> +return self.base_pe32
>  class EfiSectionPE64:
>  def __init__(self, ec, base_pe64):
>  self.ec = ec
> @@ -176,16 +161,7 @@
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -# Offset from dos hdr to PE file hdr
> -pe_file_header = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(self.base_pe64 + 0x3C)
> -
> -base_of_code = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
> -base_of_data = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
> -
> -if (base_of_code < base_of_data) and (base_of_code != 0):
> -return base_of_code
> -else:
> -return base_of_data
> +return self.base_pe64
>
>  class FirmwareFile:
>  EFI_FV_FILETYPE_RAW   = 0x01
>
>>> Eugene, so you do not use the so convenient cmd_load_symbols.py script to 
>>> load all symbols?
>>> I dumped efi and dll as you suggested. The .text and .data sections in 
>>> 

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Ard Biesheuvel]

On 10 November 2015 at 18:41, Vladimir Olovyannikov
 wrote:
> Ard,
> Many thanks for your help. It works.
>

Great! Thanks for reporting back.

-- 
Ard.

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, November 09, 2015 10:31 PM
> To: Vladimir Olovyannikov
> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
> step-by-step debugging in uefi
>
> On 9 November 2015 at 19:01, Vladimir Olovyannikov
>  wrote:
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Sunday, November 08, 2015 10:52 PM
>> To: Vladimir Olovyannikov
>> Cc: Cohen, Eugene; edk2-devel@lists.01.org
>> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
>> step-by-step debugging in uefi
>>
>> On 6 November 2015 at 21:32, Vladimir Olovyannikov
>> > wrote:
 Hello Ard, Eugene,
 Thank you for explanation.

 Ard, I tried the patch, but it cannot be applied to the latest (pulled a 
 minute ago, git-svn-id: 
 https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 
 6f19259b-4bc3-4df7-8a09-765794883524)
 tree: all 3 hunks failed. Which commit should I be based on to apply the 
 patch?

 Anyway I found the lines manually and changed them. However, when I try to

 source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
 (0x8500,0x0028) -m (0x8000,0x4000) -a
 I am getting

 ERROR(?): ValueError: need more than 1 value to unpack
   File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py", line 94, 
 in >
 armplatform_debugger.load_all_symbols()
 ERROR(CMD656):
 # in /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2 while 
 executing: source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
 (0x8500,0x0028) -m (0x8000,0x4000) -a
 ! The script /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py failed 
 to complete due to an error during execution of the script

 Replacing the script with the older version makes it work as before, but 
 again the debugger is useless.

 Any idea what is wrong?

>>
>>>No, not a clue. But could you please share the diff between the
>>>version of the script that works for you and the version that doesn't?
>>>I don't think the patch I sent could trigger the error you are seeing,
>>>so it must be something else that changed.
>> Here is the diff.
>>
>> --- firmware_volume_old.py  2015-06-24 15:15:37.0 -0700
>> +++ firmware_volume_new.py  2015-11-06 11:49:24.321730539 -0800
>> @@ -91,12 +91,7 @@
>>  return filename[0:string.find(filename,'\0')]
>>
>>  def get_debug_elfbase(self):
>> -stripped_size = struct.unpack("> self.ec.getMemoryService().read(self.base_te + 0x6, 2, 32))[0]
>> -stripped_size -= EfiSectionTE.SIZEOF_EFI_TE_IMAGE_HEADER
>> -
>> -base_of_code = self.ec.getMemoryService().readMemory32(self.base_te 
>> + 0xC)
>> -
>> -return self.base_te + base_of_code - stripped_size
>> +return self.base_pe32
>>
>
> This hunk is incorrect. Could you please try the patch instead?
> (attached, this time, so it should apply more easily)
>
> Thanks,
> Ard.
>
>>  class EfiSectionPE32:
>>  def __init__(self, ec, base_pe32):
>> @@ -131,17 +126,7 @@
>>  return filename[0:string.find(filename,'\0')]
>>
>>  def get_debug_elfbase(self):
>> -# Offset from dos hdr to PE file hdr
>> -pe_file_header = self.base_pe32 + 
>> self.ec.getMemoryService().readMemory32(self.base_pe32 + 0x3C)
>> -
>> -base_of_code = self.base_pe32 + 
>> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
>> -base_of_data = self.base_pe32 + 
>> self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
>> -
>> -if (base_of_code < base_of_data) and (base_of_code != 0):
>> -return base_of_code
>> -else:
>> -return base_of_data
>> -
>> +return self.base_pe32
>>  class EfiSectionPE64:
>>  def __init__(self, ec, base_pe64):
>>  self.ec = ec
>> @@ -176,16 +161,7 @@
>>  return filename[0:string.find(filename,'\0')]
>>
>>  def get_debug_elfbase(self):
>> -# Offset from dos hdr to PE file hdr
>> -pe_file_header = self.base_pe64 + 
>> self.ec.getMemoryService().readMemory32(self.base_pe64 + 0x3C)
>> -
>> -base_of_code = self.base_pe64 + 
>> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
>> -base_of_data = self.base_pe64 + 
>> self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
>> -
>> -if (base_of_code < base_of_data) and (base_of_code != 0):
>> -return base_of_code
>> -else:
>> -return base_of_data
>> +return self.base_pe64
>>

Re: [edk2] Filesystem issues since "OvmfPkg: enable SATA controller"

[Laszlo Ersek]

On 11/10/15 19:48, John Snow wrote:
> 
> 
> On 11/10/2015 01:17 PM, Laszlo Ersek wrote:
>> Adding John Snow (IDE maintainer in QEMU)
>>
>> On 11/10/15 17:55, Mark Rutland wrote:
>>> I've been trying to test an EFI application on x86_64 using Ubuntu 14.04's 
>>> QEMU
>>> 2.0.0. I have a directory 'foo' containing the application, and I get QEMU 
>>> to
>>> create a virtual FAT device:
>>>
>>> $ qemu-system-x86_64 -nographic \
>>> -bios src/edk2/Build/OvmfX64/RELEASE_GCC48/FV/OVMF.fd \
>>> -hda fat:foo
>>>
>>> However, I'm unable to access the root filesystem:
>>>
>>> UEFI Interactive Shell v2.1
>>> EDK II
>>> UEFI v2.50 (EDK II, 0x0001)
>>> Mapping table
>>>   FS0: Alias(s):HD7a1:;BLK3:
>>>   
>>> PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
>>>  BLK2: Alias(s):
>>>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
>>>  BLK4: Alias(s):
>>>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
>>>  BLK0: Alias(s):
>>>   PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
>>>  BLK1: Alias(s):
>>>   PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
>>> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
>>> Shell> fs0:
>>> FS0:\> dir
>>> ls: File Not Found - 'FS0:\'
>>>
>>> With git, I bisected this down to the commit "OvmfPkg: enable SATA 
>>> controller".
>>>
>>> Any ideas as to what the problem could be?
>>>
>>> I don't have a newer qemu-system-x86_64 lying around, so I haven't been 
>>> able to
>>> test with that.
>>
>> I just tested the above, with upstream QEMU at git ce278618, and OVMF at
>> edk2 git 07c70785. It works for me.
>>
>> Can you please retest with upstream QEMU? As far as I understand, many
>> IDE emulation fixes have gone into QEMU since 2.0.0. Some of those were
>> directly related to the SATA enablement in OVMF.
>>
> 
> Hmm, I had a big long email typed out explaining the state of SATA disk
> support in QEMU and how there are known SATA HDD bugs until 2.3.0 and
> known SATA CDROM bugs until 2.4.1, but your command-line doesn't appear
> to be using SATA -- unless that QEMU is modified -- it appears to be
> using traditional ATA disk emulation.

Correct, but even for using the same ATA/IDE controller, the driver was
replaced completely in OVMF, so any small tweak on the QEMU side could
have an impact.

> 
> Of which I haven't fixed any data corruption bugs that I *know* of.
> There have been a lot of changes in general, so it's still possible I
> fixed this by "accident."
> 
> Please retest with 2.4.1 if possible. If you still find problems, keep
> in touch.

Also, using the most recent edk2 version, Mark could elect to
reverse-bisect QEMU (2.0 to 2.4) for the fix, whatever it was. :)

> 
>> I'm not sure if you are used to building QEMU; one set of commands that
>> works for me (although building in a separate build directory is
>> recommended, officially), is:
>>
>>   git clone git://git.qemu.org/qemu.git
>>   cd qemu
>>   ./configure --target-list=x86_64-softmmu --prefix=$PREFIX
>>   nice make -j $N
>>   make install
>>
>>   $PREFIX/bin/qemu-system-x86_64 ...
>>
>> In general I'd recommend using virtio-blk over IDE for such testing
>> anyway. If you'd like to stick with the Ubuntu-shipped binary, please
>> try to replace the "-hda ..." shorthand with the following shorthand:
>>
>>   -drive if=virtio,file=fat:blargh
>>
>> For completeness, let me reformat your command line the way I'd write it:
>>
>>   cp .../OVMF_VARS.fd my-vars.fd
>>
>>   $PREFIX/bin/qemu-system-x86_64 \
>> -machine pc,accel=kvm \
>> -net none \
>> -nographic \
>> \
>> -drive if=pflash,readonly,file=.../OVMF_CODE.fd,format=raw \
>> -drive if=pflash,file=my-vars.fd,format=raw \
>> \
>> -drive if=none,file=fat:foo,id=drive0,format=raw \
>> -device virtio-blk-pci,drive=drive0 \
>> \
>> -debugcon file:ovmf.log \
>> -global isa-debugcon.iobase=0x402
>>
>> Thanks
>> Laszlo
>>
> 
> ...And my ultimate advice is just to listen to Laszlo. ;)

My ultimate advice is just to listen to John; he always makes good
points. (See above, for example.)

;)

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

Re: [edk2] Filesystem issues since "OvmfPkg: enable SATA controller"

[Laszlo Ersek]

Adding John Snow (IDE maintainer in QEMU)

On 11/10/15 17:55, Mark Rutland wrote:
> I've been trying to test an EFI application on x86_64 using Ubuntu 14.04's 
> QEMU
> 2.0.0. I have a directory 'foo' containing the application, and I get QEMU to
> create a virtual FAT device:
> 
> $ qemu-system-x86_64 -nographic \
>   -bios src/edk2/Build/OvmfX64/RELEASE_GCC48/FV/OVMF.fd \
>   -hda fat:foo
> 
> However, I'm unable to access the root filesystem:
> 
> UEFI Interactive Shell v2.1
> EDK II
> UEFI v2.50 (EDK II, 0x0001)
> Mapping table
>   FS0: Alias(s):HD7a1:;BLK3:
>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
>  BLK2: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
>  BLK4: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
>  BLK0: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
>  BLK1: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
> Shell> fs0:
> FS0:\> dir
> ls: File Not Found - 'FS0:\'
> 
> With git, I bisected this down to the commit "OvmfPkg: enable SATA 
> controller".
> 
> Any ideas as to what the problem could be?
> 
> I don't have a newer qemu-system-x86_64 lying around, so I haven't been able 
> to
> test with that.

I just tested the above, with upstream QEMU at git ce278618, and OVMF at
edk2 git 07c70785. It works for me.

Can you please retest with upstream QEMU? As far as I understand, many
IDE emulation fixes have gone into QEMU since 2.0.0. Some of those were
directly related to the SATA enablement in OVMF.

I'm not sure if you are used to building QEMU; one set of commands that
works for me (although building in a separate build directory is
recommended, officially), is:

  git clone git://git.qemu.org/qemu.git
  cd qemu
  ./configure --target-list=x86_64-softmmu --prefix=$PREFIX
  nice make -j $N
  make install

  $PREFIX/bin/qemu-system-x86_64 ...

In general I'd recommend using virtio-blk over IDE for such testing
anyway. If you'd like to stick with the Ubuntu-shipped binary, please
try to replace the "-hda ..." shorthand with the following shorthand:

  -drive if=virtio,file=fat:blargh

For completeness, let me reformat your command line the way I'd write it:

  cp .../OVMF_VARS.fd my-vars.fd

  $PREFIX/bin/qemu-system-x86_64 \
-machine pc,accel=kvm \
-net none \
-nographic \
\
-drive if=pflash,readonly,file=.../OVMF_CODE.fd,format=raw \
-drive if=pflash,file=my-vars.fd,format=raw \
\
-drive if=none,file=fat:foo,id=drive0,format=raw \
-device virtio-blk-pci,drive=drive0 \
\
-debugcon file:ovmf.log \
-global isa-debugcon.iobase=0x402

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

Re: [edk2] [PATCH] ArmPlatformPkg: bring DS-5 scripts in line with linker script changes

[Ard Biesheuvel]

On 6 November 2015 at 08:25, Ard Biesheuvel  wrote:
> The ARM and AARCH64 linker scripts have recently been updated so that
> the memory layouts of the ELF and PE/COFF versions of each module are
> identical. In particular, this means that the ELF images now have a
> hole before the first section rather than starting at offset 0x0, which
> means we no longer have to correct for this difference when loading the
> ELF image into the debugger.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Leif,

Vladimir has confirmed that this patch fixes the DS-5 problems he was observing.
Are you happy with me merging this patch?

Thanks,
Ard.

> ---
>  ArmPlatformPkg/Scripts/Ds5/firmware_volume.py | 26 +++-
>  1 file changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py 
> b/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
> index 8e3a8adc9bc8..c434e3de19da 100644
> --- a/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
> +++ b/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
> @@ -94,9 +94,7 @@ class EfiSectionTE:
>  stripped_size = struct.unpack(" self.ec.getMemoryService().read(self.base_te + 0x6, 2, 32))[0]
>  stripped_size -= EfiSectionTE.SIZEOF_EFI_TE_IMAGE_HEADER
>
> -base_of_code = self.ec.getMemoryService().readMemory32(self.base_te 
> + 0xC)
> -
> -return self.base_te + base_of_code - stripped_size
> +return self.base_te - stripped_size
>
>  class EfiSectionPE32:
>  def __init__(self, ec, base_pe32):
> @@ -131,16 +129,7 @@ class EfiSectionPE32:
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -# Offset from dos hdr to PE file hdr
> -pe_file_header = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(self.base_pe32 + 0x3C)
> -
> -base_of_code = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
> -base_of_data = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
> -
> -if (base_of_code < base_of_data) and (base_of_code != 0):
> -return base_of_code
> -else:
> -return base_of_data
> +return self.base_pe32
>
>  class EfiSectionPE64:
>  def __init__(self, ec, base_pe64):
> @@ -176,16 +165,7 @@ class EfiSectionPE64:
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -# Offset from dos hdr to PE file hdr
> -pe_file_header = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(self.base_pe64 + 0x3C)
> -
> -base_of_code = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
> -base_of_data = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
> -
> -if (base_of_code < base_of_data) and (base_of_code != 0):
> -return base_of_code
> -else:
> -return base_of_data
> +return self.base_pe64
>
>  class FirmwareFile:
>  EFI_FV_FILETYPE_RAW   = 0x01
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg: bring DS-5 scripts in line with linker script changes

[Leif Lindholm]

On 10 November 2015 at 18:10, Ard Biesheuvel  wrote:
> On 6 November 2015 at 08:25, Ard Biesheuvel  wrote:
>> The ARM and AARCH64 linker scripts have recently been updated so that
>> the memory layouts of the ELF and PE/COFF versions of each module are
>> identical. In particular, this means that the ELF images now have a
>> hole before the first section rather than starting at offset 0x0, which
>> means we no longer have to correct for this difference when loading the
>> ELF image into the debugger.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>
> Leif,
>
> Vladimir has confirmed that this patch fixes the DS-5 problems he was 
> observing.
> Are you happy with me merging this patch?

Sure, go ahead.
(I lost track of the state of this thread somewhere.)

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

Re: [edk2] Authentication status for signed FVs extracted in PEI

[Kinney, Michael D]

Eugene,

I believe the current behavior is that only FVs that are either unsigned or FVs 
that are signed and pass authentication can be passed from PEI to DXE.

I believe your use case is to pass an FV from PEI to DXE that is signed, but 
has not been authenticated yet.

Given the current PI architecture constraints, would it be a reasonable 
solution to have an early DXE driver publish the FV that is signed but not 
authenticated yet, so the DXE phase can do the authentication?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
>Eugene
>Sent: Tuesday, November 10, 2015 7:12 AM
>To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org
>Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>
>Liming and Star,
>
>Thanks for the suggestion for extending the FV HOB.  I'm not sure if the 
>length change will be considered forwards and backwards
>compatible for all implementations.  If people refer to the HOB by pointer it 
>shouldn't be a problem but if they try to copy the HOB
>using the header length they may have a compatibility problem.
>
>I'll raise your suggestion at PIWG and see what the group recommends.
>
>Thanks,
>
>Eugene
>
>-Original Message-
>From: Gao, Liming [mailto:liming@intel.com]
>Sent: Tuesday, November 10, 2015 3:27 AM
>To: Zeng, Star ; Cohen, Eugene ; 
>edk2-devel@lists.01.org
>Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI
>
>Eugene:
>  Another idea is to update FV HOB to include authentication status instead of 
> adding FV HOB3. The consumer code can check FV HOB
>Length to know whether FV HOB includes authentication status.
>
>Thanks
>Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
>> Star
>> Sent: Tuesday, November 10, 2015 6:19 PM
>> To: Cohen, Eugene; edk2-devel@lists.01.org
>> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>>
>> On 2015/11/9 21:57, Cohen, Eugene wrote:
>> > Star,
>> >
>> >> The authentication status and its inheritance support in FvInfo2 and 
>> >> FvPpi were covered by the mantis we submitted to support
>PEI
>> security and to be equivalent with DXE.
>> > You raised another issue here to inherit authentication status from PEI to 
>> > DXE.
>> >
>> > Correct.
>> >
>> >> Currently, only verified pass FV in PEI will be processed and reported 
>> >> with FV HOB to DXE.
>> >
>> > The FV HOB doesn't explicitly say whether the FV was verified or not.  We 
>> > have a use case where we have one FV that contains
>code
>> and is verified and another FV that contains some data and is not verified.  
>> With the current FV HOB definitions there's no way to
>> differentiate these two.
>>
>> Curious about the FV you said is root or child FV?
>>
>> >
>> > The DXE core just assumes that all FVs passed through FV hobs are unsigned 
>> > (AuthenticationStatus = 0).  So in DXE-phase security
>> policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting 
>> accurate AuthenticationStatus values with which to
>make a
>> decision.
>> >
>> > So in a way this just seems wrong since the security callbacks are saying 
>> > that FVs are unsigned when in reality there are signed and
>> verified.
>> >
>> > I'm thinking this could be as simple as an updated FV HOB definition that 
>> > adds an AuthenticationStatus field.
>>
>> I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to
>> include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one
>> FV. Seemingly, we could not to just extend FV HOB to include
>> AuthenticationStatus, right?
>>
>> Thanks,
>> Star
>>
>> >
>> > Eugene
>> >
>> > -Original Message-
>> > From: Zeng, Star [mailto:star.z...@intel.com]
>> > Sent: Monday, November 09, 2015 6:43 AM
>> > To: Cohen, Eugene ; edk2-devel@lists.01.org
>> > Cc: Zeng, Star 
>> > Subject: RE: Authentication status for signed FVs extracted in PEI
>> >
>> > The authentication status and its inheritance support in FvInfo2 and FvPpi 
>> > were covered by the mantis we submitted to support
>PEI
>> security and to be equivalent with DXE.
>> > You raised another issue here to inherit authentication status from PEI to 
>> > DXE.
>> >
>> > Currently, only verified pass FV in PEI will be processed and reported 
>> > with FV HOB to DXE.
>> > Your real case will have different policy to verify FV in PEI and DXE 
>> > phase?
>> >
>> > Thanks,
>> > Star
>> > -Original Message-
>> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> > Cohen, Eugene
>> > Sent: Monday, November 9, 2015 9:03 PM
>> > To: edk2-devel@lists.01.org
>> > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>> >
>> > I raised this as an issue with PIWG.  In the meantime feel free to provide 
>> > some historical context for why this hasn't been 

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Kinney, Michael D]

Heyi,

All timers in UEFI are the minimum time.  So the only way to guarantee that a 
FIFO will never overflow is to use flow control.

Setting the poll rate based on FIFO depth and baud rate, data bits, and stop 
bits with flow control disabled means it should work most of the time, but 
another UEFI event notification function running at the same TPL or higher can 
block the Terminal event notification function and input characters could be 
lost.

I agree that the current 20ms periodic timer can overflow depending in the FIFO 
depth and the baud rate, and that we could reduce data loss in flow control 
disabled configurations if this periodic rate was computed instead of using a 
hard coded #define.  Another constraint is the system timer interrupt rate 
provided by the Timer Architectural Protocol.  A request for a periodic timer 
event that is faster than the current system timer rate will call the event 
notification function at the rate of the system timer.  So even if you reduce 
the periodic timer event time to a computed value, the time between event 
notification function calls may not change.  

In order to prevent overflows, I think the timer rate in 100ns units could be 
computed as follows:

Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000

--
BaudRate  

For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 115200 
would be:

16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277

Which is 0.00153 seconds or 1.53 ms.

Best regards,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
>Sent: Monday, November 09, 2015 10:23 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Cc: Tian, Feng
>Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval
>
>Hi Michael,
>
>Yes we can see terminal input truncated when we use copy-paste to input
>characters.
>
>I don't quite understand the relationship between SerialInTimeOut and
>timer event poll rate; and I don't see the periodic timer rate is to be
>updated later; we are using 0.02ms period all over, aren't we?
>
>If the timer event polls the serial device at a fixed rate, how can we
>guarantee the FIFO of the device will not overflow during a burst input?
>
>Thanks.
>
>On 11/10/2015 01:25 AM, Kinney, Michael D wrote:
>> Heyi,
>>
>> The function TerminalConInTimerHandler () computes a timeout based on the 
>> baud rate, data bits, and stop bits
>>
>>//
>>// According to BAUD rate to calculate the timeout value.
>>//
>>SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 100 
>> / (UINTN) Mode->BaudRate;
>>
>> The #define is used to set the initial periodic timer rate before the rest 
>> of the information to compute a timeout is known.
>>
>> Are you observing an issue?
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi
>>> Guo
>>> Sent: Monday, November 09, 2015 1:48 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Tian, Feng
>>> Subject: [edk2] [RFC] Adaptively set serial terminal input polling interval
>>>
>>> Hi All,
>>>
>>> In MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf, the
>>> polling interval is fixed by macro:
>>>
>>> #define KEYBOARD_TIMER_INTERVAL 20  // 0.02s
>>>
>>> However, this may cause fast input to be truncated on some platform. For
>>> example, we have a serial console with below features:
>>> 1. Baud rate: 115200
>>> 2. FIFO depth of UART device: 32
>>>
>>> If we want to capture all input, we need to poll with the interval of 32
>>> / (115200 / (8 + 1 + 1)) = 2.8 ms, 8 + 1 + 1 for data bits + start bit +
>>> stop bit.
>>>
>>> So, I suppose to use a PCD to set the interval per platform, or
>>> calculate from serial IO protocol IO Mode, which contains FIFO depth and
>>> data bits, etc, and we can use 20 as the maximum for compatibility,
>>> or default value when fifo depth is 0.
>>>
>>> Please let me know your comments.
>>>
>>> Thanks.
>>>
>>> Heyi
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Authentication status for signed FVs extracted in PEI

[Cohen, Eugene]

Mike,

> I believe the current behavior is that only FVs that are either unsigned or 
> FVs that are signed and pass authentication can be passed from PEI to DXE.
> I believe your use case is to pass an FV from PEI to DXE that is signed, but 
> has not been authenticated yet.

Our use case is PEI signing and verifying FVs (the first case) using the GUIDed 
encapsulation scheme you contributed a while back (thank you!).  From what I 
can see both in edk2 and in the PI spec there is not an architected mechanism 
to pass this information.  As I mentioned in my first message, the DXE core 
seems to jam AuthenticationStatus to zero (in calling 
ProduceFVBProtocolOnBuffer) as it processes FV HOBs.  Are you aware of a 
channel where this information is already being passed from PEI to DXE?

The other lingering question I had was why others hadn't seen this before me.  
I'm guessing that people are choosing different approaches for packaging up PEI 
and DXE phase components than we are.

Thanks,

Eugene

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Tuesday, November 10, 2015 12:54 PM
To: Cohen, Eugene ; Gao, Liming ; Zeng, 
Star ; edk2-devel@lists.01.org; Kinney, Michael D 

Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI

Eugene,

I believe the current behavior is that only FVs that are either unsigned or FVs 
that are signed and pass authentication can be passed from PEI to DXE.

I believe your use case is to pass an FV from PEI to DXE that is signed, but 
has not been authenticated yet.

Given the current PI architecture constraints, would it be a reasonable 
solution to have an early DXE driver publish the FV that is signed but not 
authenticated yet, so the DXE phase can do the authentication?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
>Eugene
>Sent: Tuesday, November 10, 2015 7:12 AM
>To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org
>Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>
>Liming and Star,
>
>Thanks for the suggestion for extending the FV HOB.  I'm not sure if the 
>length change will be considered forwards and backwards
>compatible for all implementations.  If people refer to the HOB by pointer it 
>shouldn't be a problem but if they try to copy the HOB
>using the header length they may have a compatibility problem.
>
>I'll raise your suggestion at PIWG and see what the group recommends.
>
>Thanks,
>
>Eugene
>
>-Original Message-
>From: Gao, Liming [mailto:liming@intel.com]
>Sent: Tuesday, November 10, 2015 3:27 AM
>To: Zeng, Star ; Cohen, Eugene ; 
>edk2-devel@lists.01.org
>Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI
>
>Eugene:
>  Another idea is to update FV HOB to include authentication status instead of 
> adding FV HOB3. The consumer code can check FV HOB
>Length to know whether FV HOB includes authentication status.
>
>Thanks
>Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
>> Star
>> Sent: Tuesday, November 10, 2015 6:19 PM
>> To: Cohen, Eugene; edk2-devel@lists.01.org
>> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
>>
>> On 2015/11/9 21:57, Cohen, Eugene wrote:
>> > Star,
>> >
>> >> The authentication status and its inheritance support in FvInfo2 and 
>> >> FvPpi were covered by the mantis we submitted to support
>PEI
>> security and to be equivalent with DXE.
>> > You raised another issue here to inherit authentication status from PEI to 
>> > DXE.
>> >
>> > Correct.
>> >
>> >> Currently, only verified pass FV in PEI will be processed and reported 
>> >> with FV HOB to DXE.
>> >
>> > The FV HOB doesn't explicitly say whether the FV was verified or not.  We 
>> > have a use case where we have one FV that contains
>code
>> and is verified and another FV that contains some data and is not verified.  
>> With the current FV HOB definitions there's no way to
>> differentiate these two.
>>
>> Curious about the FV you said is root or child FV?
>>
>> >
>> > The DXE core just assumes that all FVs passed through FV hobs are unsigned 
>> > (AuthenticationStatus = 0).  So in DXE-phase security
>> policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting 
>> accurate AuthenticationStatus values with which to
>make a
>> decision.
>> >
>> > So in a way this just seems wrong since the security callbacks are saying 
>> > that FVs are unsigned when in reality there are signed and
>> verified.
>> >
>> > I'm thinking this could be as simple as an updated FV HOB definition that 
>> > adds an AuthenticationStatus field.
>>
>> I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to
>> include AuthenticationStatus. Then there will be 

[edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

Hello,

I am not sure this is the right forum to ask this question, so I am sorry in 
advance if this is an offtopic here (please point me to the proper one).

I brought up UEFI on the device and am trying to load linux from the SD card 
(loading from the network using GRUB is a topic for another message).

Linux kernel starts and shortly after that (as soon as local_async is enabled 
which is simple "MSR DAIfclr,4") there is a kernel crash with
"Bad mode in Error handler detected, code 0xbf00 -- SError"

Here is the log:

The default boot selection will start in  10 seconds
[1] Linux Kernel from SD Card
- SD(0x0)/HD(1,MBR,0x,0x89,0x3A9F77)/Image
- Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8 
earlycon=uart8250,mmio32,0x6613,maxcpus=1
[2] GRUB
- MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi
- Arguments:
[3] Shell
[4] Boot Manager
Start: 1
InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB9DA0
BlockSize : 512
LastBlock : 3A9FFF
InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B BEDB9798
InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B BEDB9670
InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB95A0
InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B BEDAF030
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BE2E6040
Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BEDB0718
EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: Using DTB from command line
EFI stub: Exiting boot services and installing virtual address map...
MmcHost: ExitBootServicesEvent+
Marked card brcm-SDIO1 as removed
Resetting Card brcm-SDIO1
brcm-SDIO1 Card reset done.
MmcHost: ExitBootServicesEvent-
MmcHost: ExitBootServicesEvent+
Marked card brcm-SDIO0 as removed
Resetting Card brcm-SDIO0
brcm-SDIO0 Card reset done.
MmcHost: ExitBootServicesEvent-
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc version 
4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro 
GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015
[0.00] CPU: AArch64 Processor [411fd073] revision 3
[0.00] Detected PIPT I-cache on CPU0
[0.00] earlycon: Early serial console at MMIO32 0x6613 (options 
'maxcpus=1')
[0.00] bootconsole [uart0] enabled
[0.00] Bad mode in Error handler detected, code 0xbf00 -- SError
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
[0.00] Hardware name: SVK proto (DT)
[0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti: 
ffc00074c000
[0.00] PC is at setup_arch+0x260/0x5b4
[0.00] LR is at setup_arch+0x25c/0x5b4
[0.00] pc : [] lr : [] pstate: 
02c5
[0.00] sp : ffc00074ff20
[0.00] x29: ffc00074ff20 x28: 
[0.00] x27: ffc81198 x26: 807cd000
[0.00] x25: 807ca000 x24: 8000
[0.00] x23:  x22: ffc000752000
[0.00] x21: ffc000752610 x20: ffbffa80
[0.00] x19: ffc8 x18: 
[0.00] x17: 05e3 x16: 1000
[0.00] x15: 1c00 x14: 0ffe
[0.00] x13: 0020 x12: 0028
[0.00] x11: 0007 x10: 0101010101010101
[0.00] x9 : fffb x8 : 0008
[0.00] x7 : 0003 x6 : 0080
[0.00] x5 : 005f x4 : 
[0.00] x3 :  x2 : 0065
[0.00] x1 :  x0 : 0001
[0.00]
[0.00] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
[0.00] Hardware name: SVK proto (DT)
[0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti: 
ffc00074c000
[0.00] PC is at setup_arch+0x260/0x5b4
[0.00] LR is at setup_arch+0x25c/0x5b4
[0.00] pc : [] lr : [] pstate: 
02c5
[0.00] sp : ffc00074ff20
[0.00] x29: ffc00074ff20 x28: 
[0.00] x27: ffc81198 x26: 807cd000
[0.00] x25: 807ca000 x24: 8000
[0.00] x23:  x22: ffc000752000
[0.00] x21: ffc000752610 x20: ffbffa80
[0.00] x19: ffc8 x18: 
[0.00] x17: 05e3 x16: 1000
[0.00] x15: 1c00 x14: 0ffe
[0.00] x13: 0020 

Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Gao, Liming]

Andrew:
  The patch is missing.

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Tuesday, November 10, 2015 3:18 PM
To: edk2-devel
Cc: Tian, Feng
Subject: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

Please review the following patches as they are required to build with Xcode 
6.3.2.

Thanks,

Andrew Fish


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

Re: [edk2] Authentication status for signed FVs extracted in PEI

[Zeng, Star]

On 2015/11/9 21:57, Cohen, Eugene wrote:

Star,


The authentication status and its inheritance support in FvInfo2 and FvPpi were 
covered by the mantis we submitted to support PEI security and to be equivalent 
with DXE.

You raised another issue here to inherit authentication status from PEI to DXE.

Correct.


Currently, only verified pass FV in PEI will be processed and reported with FV 
HOB to DXE.


The FV HOB doesn't explicitly say whether the FV was verified or not.  We have 
a use case where we have one FV that contains code and is verified and another 
FV that contains some data and is not verified.  With the current FV HOB 
definitions there's no way to differentiate these two.


Curious about the FV you said is root or child FV?



The DXE core just assumes that all FVs passed through FV hobs are unsigned 
(AuthenticationStatus = 0).  So in DXE-phase security policy callbacks (part of 
EFI_SECURITY_ARCH_PROTOCOL) we are not getting accurate AuthenticationStatus 
values with which to make a decision.

So in a way this just seems wrong since the security callbacks are saying that 
FVs are unsigned when in reality there are signed and verified.

I'm thinking this could be as simple as an updated FV HOB definition that adds 
an AuthenticationStatus field.


I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to 
include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one 
FV. Seemingly, we could not to just extend FV HOB to include 
AuthenticationStatus, right?


Thanks,
Star



Eugene

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Monday, November 09, 2015 6:43 AM
To: Cohen, Eugene ; edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: RE: Authentication status for signed FVs extracted in PEI

The authentication status and its inheritance support in FvInfo2 and FvPpi were 
covered by the mantis we submitted to support PEI security and to be equivalent 
with DXE.
You raised another issue here to inherit authentication status from PEI to DXE.

Currently, only verified pass FV in PEI will be processed and reported with FV 
HOB to DXE.
Your real case will have different policy to verify FV in PEI and DXE phase?

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Monday, November 9, 2015 9:03 PM
To: edk2-devel@lists.01.org
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI

I raised this as an issue with PIWG.  In the meantime feel free to provide some 
historical context for why this hasn't been an issue in other implementations.

Thanks,

Eugene

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Friday, November 06, 2015 5:49 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG) 
Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI

[Corrected the typos with a new version - proofreading is a good thing]


I'm confused about something and hope I can get some help understanding this.

If we have a signed FV that is extracted in PEI it doesn't look like the 
AuthenticationStatus gets propagated to DXE.

The hob doesn't store authentication status and the core produces FVB with 
AuthenticationStatus forced to zero, even though the FV was signed and verified.

This seems to mess up policy code in DXE because it is the AuthenticationStatus 
is not accurate.

MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:

   while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
 //
 // Produce an FVB protocol for it
 //
 ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress, 
FvHob.FirmwareVolume->Length, NULL, 0, NULL);
 FvHob.Raw = GET_NEXT_HOB (FvHob);
   }

Note the hardcoded zero in the second-to-last argument.

Is this expected?  How would DXE policy code know if the FV was verified in 
PEI?  It looks like the HOB definitions do not propagate PEI-phase 
Authentication status forward.

Thanks,

Eugene

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Friday, November 06, 2015 11:12 AM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG) 
Subject: [edk2] Authentication status for signed FVs extracted in PEI

I'm confused about something and hope I can help some help understanding this.

If we have a signed FV that is extracted in PEI it doesn't look like the 
AuthenticationStatus gets propagated to DXE.

The hob doesn't store authentication status and the core products FVB with 
AuthenticationStatus forced to zero, even though the FV was signed and verified.

This seems to mess up policy code we want to have in DXE because it is not 
accurate.

MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:

   while 

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Laszlo Ersek]

On 11/10/15 10:49, Conen, Johannes wrote:
> Hi there,
> 
> I made my tests with the binary shell from ShellBinPkg from UDK2014,
> from UDK2015, the current master and a few commits in between and
> rebuilt the shell from ShellPkg for UDK2014, UDK2015, the current
> master and a few commits in between UDK2014 and UDK2015.
> 
> It worked fine with r17868 and didn't work anymore with r17869, so it
> has to be that commit (I of course rebuilt the shell from ShellPkg).
> If I put both shells on a USB-stick and switch between them on the
> fly, it works in the one built from r17868 and doesn't work in the
> one built from r17869. Regarding ShellBinPkg: the last version that
> worked is r17619 (which is quite logical since the version after
> that, r18187, is built from ShellPkg r18186, which didn't work for me
> anymore).
>
> I'm not working on OVMF, but on real hardware (X64) - don't know
> exactly with which version the UEFI firmware was written, but I
> assume it's UDK2014. I found nothing in the release notes that would
> break backwards compatibility to firmware versions built with older
> EDKII versions in this regard.

Okay, that seems to explain it. The platform firmware on your physical
machine provides Ip4Config (version 1) only, but the shell built from
recent edk2 (and probably the binary shipped in UDK2015) requires
Ip4Config2.

Hm... I have not been a UDK user, but now I downloaded
"UDK2015.Notes.zip", and in "ShellPkg Notes.txt", it says under "NEW
FEATURES AND CHANGES", point 15:

  Change "ping" and "ifconfig" code to consume Ip4Config2 protocol.

So I think this has been (technically) documented in the UDK2015
release. Perhaps the lack of compatibility with UDK2014 should have been
emphasized.

(But, I'm just a curious bystander in this discussion anwyay...)

Thanks
Laszlo

> 
> With best regards,
> Johannes Conen
> 
> Siemens AG
> Process Industries and Drives Division
> Process Automation
> Manufacturing Karlsruhe
> PD PA MF-K IPC 2
> Oestliche Rheinbrueckenstr. 50
> 76187 Karlsruhe, Germany 
> mailto:johannes.co...@siemens.com
> 
> 
> -Ursprüngliche Nachricht-
> Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
> Gesendet: Dienstag, 10. November 2015 02:42
> An: Laszlo Ersek; Conen, Johannes; edk2-devel@lists.01.org
> Cc: Leif Lindholm (Linaro address)
> Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> 
> Hi Laszlo and Conen,
> Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg in 
> UDK2015 release version, Both of them have included my patch for Ip4Config 
> Protocol deprecated work.
> I'm also confused by the test result below, seems only time appeared abnormal.
> 
> Conen: Are you using the shell binary released in UDK2015?
> 
> Thanks.
> Jiaxin
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 10, 2015 4:30 AM
> To: Conen, Johannes; edk2-devel@lists.01.org
> Cc: Leif Lindholm (Linaro address); Wu, Jiaxin
> Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> 
> On 11/09/15 16:52, Conen, Johannes wrote:
>> Hello everyone,
>>
>> after switching from UDK2014 to UDK2015, I noticed that the network 
>> commands (ifconfig / ping) don't work anymore. ifconfig just exits 
>> with no feedback and ping says "Config no mapping" (logical, as it is 
>> not possible to get an IP address via ifconfig). In UDK2014 everything 
>> worked fine.
>>
>> With the help of unixsmurf (thanks a lot)
> 
> Argh. Can we stop using these "funny" nicks on IRC?
> 
> "unixsmurf" is Leif.
> 
> What do you think, Leif? :)
> 
>> I went on bughunting and
>> found out that commit r17869 / git sha 
>> 7c25b7ea5b2c029a9e7a0be57f7c20f31d720c7d broke it. Wild guess: it has 
>> something to do with the new protocol.
> 
> That's close, but my take is not that exact commit. Instead, what about
> this:
> 
> https://github.com/tianocore/edk2/commit/2aa0eb5df61e
> 
> == SVN rev 17917.
> 
> (I reviewed that commit.)
> 
> But, it works for me:
> 
>> Shell> ifconfig -s eth0 dhcp
>> Shell> ifconfig -l eth0
>>
>> -
>>
>> name : eth0
>> Media State : Media present
>> policy : dhcp
>> mac addr : 52:54:00:29:80:AE
>>
>> ipv4 address : 192.168.122.182
>>
>> subnet mask : 255.255.255.0
>>
>> default gateway: 192.168.122.1
>>
>> Routes (2 entries):
>> Entry[0]
>> Subnet : 192.168.122.0
>> Netmask: 255.255.255.0
>> Gateway: 0.0.0.0
>> Entry[1]
>> Subnet : 0.0.0.0
>> Netmask: 0.0.0.0
>> Gateway: 192.168.122.1
>>
>> DNS server :
>> 192.168.122.1
>>
>>
>> -
>> Shell> ping 8.8.8.8
>> Ping 8.8.8.8 16 data bytes.
>> 16 bytes from 8.8.8.8 : icmp_seq=1 ttl=0 time=30640ms
>> 16 bytes from 8.8.8.8 : icmp_seq=2 ttl=0 time=31249ms
>> 16 bytes from 8.8.8.8 : icmp_seq=3 ttl=0 time=33280ms
>> 16 bytes from 8.8.8.8 : icmp_seq=4 ttl=0 time=38577ms
>> 16 bytes from 8.8.8.8 : icmp_seq=5 ttl=0 time=28432ms
>> 16 

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Conen, Johannes]

Hmm, you're right. is it briefly mentioned in the "ShellPkg Notes.txt" - I 
must admit, I only took a look at the "UDK2015-ReleaseNotes-MyWorkSpace.txt" 
and expected all major changes to mentioned there (and well, they were, like 
the moving of the library files). So this non-backwards-compatibility from 
UDK2015 to UDK2014 regarding network-related stuff is intended?

Greetings
Johannes

-Ursprüngliche Nachricht-
Von: Laszlo Ersek [mailto:ler...@redhat.com] 
Gesendet: Dienstag, 10. November 2015 11:06
An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Leif Lindholm (Linaro address)
Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

On 11/10/15 10:49, Conen, Johannes wrote:
> Hi there,
> 
> I made my tests with the binary shell from ShellBinPkg from UDK2014, 
> from UDK2015, the current master and a few commits in between and 
> rebuilt the shell from ShellPkg for UDK2014, UDK2015, the current 
> master and a few commits in between UDK2014 and UDK2015.
> 
> It worked fine with r17868 and didn't work anymore with r17869, so it 
> has to be that commit (I of course rebuilt the shell from ShellPkg).
> If I put both shells on a USB-stick and switch between them on the 
> fly, it works in the one built from r17868 and doesn't work in the one 
> built from r17869. Regarding ShellBinPkg: the last version that worked 
> is r17619 (which is quite logical since the version after that, 
> r18187, is built from ShellPkg r18186, which didn't work for me 
> anymore).
>
> I'm not working on OVMF, but on real hardware (X64) - don't know 
> exactly with which version the UEFI firmware was written, but I assume 
> it's UDK2014. I found nothing in the release notes that would break 
> backwards compatibility to firmware versions built with older EDKII 
> versions in this regard.

Okay, that seems to explain it. The platform firmware on your physical machine 
provides Ip4Config (version 1) only, but the shell built from recent edk2 (and 
probably the binary shipped in UDK2015) requires Ip4Config2.

Hm... I have not been a UDK user, but now I downloaded "UDK2015.Notes.zip", and 
in "ShellPkg Notes.txt", it says under "NEW FEATURES AND CHANGES", point 15:

  Change "ping" and "ifconfig" code to consume Ip4Config2 protocol.

So I think this has been (technically) documented in the UDK2015 release. 
Perhaps the lack of compatibility with UDK2014 should have been emphasized.

(But, I'm just a curious bystander in this discussion anwyay...)

Thanks
Laszlo

> 
> With best regards,
> Johannes Conen
> 
> Siemens AG
> Process Industries and Drives Division Process Automation 
> Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. 
> 50
> 76187 Karlsruhe, Germany
> mailto:johannes.co...@siemens.com
> 
> 
> -Ursprüngliche Nachricht-
> Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
> Gesendet: Dienstag, 10. November 2015 02:42
> An: Laszlo Ersek; Conen, Johannes; edk2-devel@lists.01.org
> Cc: Leif Lindholm (Linaro address)
> Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> 
> Hi Laszlo and Conen,
> Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg in 
> UDK2015 release version, Both of them have included my patch for Ip4Config 
> Protocol deprecated work.
> I'm also confused by the test result below, seems only time appeared abnormal.
> 
> Conen: Are you using the shell binary released in UDK2015?
> 
> Thanks.
> Jiaxin
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 10, 2015 4:30 AM
> To: Conen, Johannes; edk2-devel@lists.01.org
> Cc: Leif Lindholm (Linaro address); Wu, Jiaxin
> Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> 
> On 11/09/15 16:52, Conen, Johannes wrote:
>> Hello everyone,
>>
>> after switching from UDK2014 to UDK2015, I noticed that the network 
>> commands (ifconfig / ping) don't work anymore. ifconfig just exits 
>> with no feedback and ping says "Config no mapping" (logical, as it is 
>> not possible to get an IP address via ifconfig). In UDK2014 everything 
>> worked fine.
>>
>> With the help of unixsmurf (thanks a lot)
> 
> Argh. Can we stop using these "funny" nicks on IRC?
> 
> "unixsmurf" is Leif.
> 
> What do you think, Leif? :)
> 
>> I went on bughunting and
>> found out that commit r17869 / git sha 
>> 7c25b7ea5b2c029a9e7a0be57f7c20f31d720c7d broke it. Wild guess: it has 
>> something to do with the new protocol.
> 
> That's close, but my take is not that exact commit. Instead, what about
> this:
> 
> https://github.com/tianocore/edk2/commit/2aa0eb5df61e
> 
> == SVN rev 17917.
> 
> (I reviewed that commit.)
> 
> But, it works for me:
> 
>> Shell> ifconfig -s eth0 dhcp
>> Shell> ifconfig -l eth0
>>
>> -
>>
>> name : eth0
>> Media State : Media present
>> policy : dhcp
>> mac addr : 52:54:00:29:80:AE
>>
>> ipv4 address : 192.168.122.182
>>
>> subnet mask : 

Re: [edk2] Authentication status for signed FVs extracted in PEI

[Gao, Liming]

Eugene:
  Another idea is to update FV HOB to include authentication status instead of 
adding FV HOB3. The consumer code can check FV HOB Length to know whether FV 
HOB includes authentication status. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, 
> Star
> Sent: Tuesday, November 10, 2015 6:19 PM
> To: Cohen, Eugene; edk2-devel@lists.01.org
> Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
> 
> On 2015/11/9 21:57, Cohen, Eugene wrote:
> > Star,
> >
> >> The authentication status and its inheritance support in FvInfo2 and FvPpi 
> >> were covered by the mantis we submitted to support PEI
> security and to be equivalent with DXE.
> > You raised another issue here to inherit authentication status from PEI to 
> > DXE.
> >
> > Correct.
> >
> >> Currently, only verified pass FV in PEI will be processed and reported 
> >> with FV HOB to DXE.
> >
> > The FV HOB doesn't explicitly say whether the FV was verified or not.  We 
> > have a use case where we have one FV that contains code
> and is verified and another FV that contains some data and is not verified.  
> With the current FV HOB definitions there's no way to
> differentiate these two.
> 
> Curious about the FV you said is root or child FV?
> 
> >
> > The DXE core just assumes that all FVs passed through FV hobs are unsigned 
> > (AuthenticationStatus = 0).  So in DXE-phase security
> policy callbacks (part of EFI_SECURITY_ARCH_PROTOCOL) we are not getting 
> accurate AuthenticationStatus values with which to make a
> decision.
> >
> > So in a way this just seems wrong since the security callbacks are saying 
> > that FVs are unsigned when in reality there are signed and
> verified.
> >
> > I'm thinking this could be as simple as an updated FV HOB definition that 
> > adds an AuthenticationStatus field.
> 
> I agree it is a gap. I have seen the mantis you filed to add FV3 HOB to
> include AuthenticationStatus. Then there will be FV/FV2/FV3 HOB for one
> FV. Seemingly, we could not to just extend FV HOB to include
> AuthenticationStatus, right?
> 
> Thanks,
> Star
> 
> >
> > Eugene
> >
> > -Original Message-
> > From: Zeng, Star [mailto:star.z...@intel.com]
> > Sent: Monday, November 09, 2015 6:43 AM
> > To: Cohen, Eugene ; edk2-devel@lists.01.org
> > Cc: Zeng, Star 
> > Subject: RE: Authentication status for signed FVs extracted in PEI
> >
> > The authentication status and its inheritance support in FvInfo2 and FvPpi 
> > were covered by the mantis we submitted to support PEI
> security and to be equivalent with DXE.
> > You raised another issue here to inherit authentication status from PEI to 
> > DXE.
> >
> > Currently, only verified pass FV in PEI will be processed and reported with 
> > FV HOB to DXE.
> > Your real case will have different policy to verify FV in PEI and DXE phase?
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Cohen, Eugene
> > Sent: Monday, November 9, 2015 9:03 PM
> > To: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
> >
> > I raised this as an issue with PIWG.  In the meantime feel free to provide 
> > some historical context for why this hasn't been an issue in
> other implementations.
> >
> > Thanks,
> >
> > Eugene
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Cohen, Eugene
> > Sent: Friday, November 06, 2015 5:49 PM
> > To: edk2-devel@lists.01.org
> > Cc: Thompson, Mark L. (Boise IPG) 
> > Subject: Re: [edk2] Authentication status for signed FVs extracted in PEI
> >
> > [Corrected the typos with a new version - proofreading is a good thing]
> >
> >
> > I'm confused about something and hope I can get some help understanding 
> > this.
> >
> > If we have a signed FV that is extracted in PEI it doesn't look like the 
> > AuthenticationStatus gets propagated to DXE.
> >
> > The hob doesn't store authentication status and the core produces FVB with 
> > AuthenticationStatus forced to zero, even though the FV
> was signed and verified.
> >
> > This seems to mess up policy code in DXE because it is the 
> > AuthenticationStatus is not accurate.
> >
> > MdeModulePkg\Core\Dxe\FwVolBlock\FwVolBlock.c, FwVolBlockDriverInit:
> >
> >while ((FvHob.Raw = GetNextHob (EFI_HOB_TYPE_FV, FvHob.Raw)) != NULL) {
> >  //
> >  // Produce an FVB protocol for it
> >  //
> >  ProduceFVBProtocolOnBuffer (FvHob.FirmwareVolume->BaseAddress, 
> > FvHob.FirmwareVolume->Length, NULL, 0, NULL);
> >  FvHob.Raw = GET_NEXT_HOB (FvHob);
> >}
> >
> > Note the hardcoded zero in the second-to-last argument.
> >
> > Is this expected?  How would DXE policy code know if the FV was verified in 
> > PEI?  It looks like the HOB definitions do not propagate
> 

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Conen, Johannes]

Hi there,

I made my tests with the binary shell from ShellBinPkg from UDK2014, from 
UDK2015, the current master and a few commits in between and rebuilt the shell 
from ShellPkg for UDK2014, UDK2015, the current master and a few commits in 
between UDK2014 and UDK2015.

It worked fine with r17868 and didn't work anymore with r17869, so it has to be 
that commit (I of course rebuilt the shell from ShellPkg). If I put both shells 
on a USB-stick and switch between them on the fly, it works in the one built 
from r17868 and doesn't work in the one built from r17869. Regarding 
ShellBinPkg: the last version that worked is r17619 (which is quite logical 
since the version after that, r18187, is built from ShellPkg r18186, which 
didn't work for me anymore).
I'm not working on OVMF, but on real hardware (X64) - don't know exactly with 
which version the UEFI firmware was written, but I assume it's UDK2014. I found 
nothing in the release notes that would break backwards compatibility to 
firmware versions built with older EDKII versions in this regard.

With best regards,
Johannes Conen

Siemens AG
Process Industries and Drives Division
Process Automation
Manufacturing Karlsruhe
PD PA MF-K IPC 2
Oestliche Rheinbrueckenstr. 50
76187 Karlsruhe, Germany 
mailto:johannes.co...@siemens.com


-Ursprüngliche Nachricht-
Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Gesendet: Dienstag, 10. November 2015 02:42
An: Laszlo Ersek; Conen, Johannes; edk2-devel@lists.01.org
Cc: Leif Lindholm (Linaro address)
Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

Hi Laszlo and Conen,
Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg in 
UDK2015 release version, Both of them have included my patch for Ip4Config 
Protocol deprecated work.
I'm also confused by the test result below, seems only time appeared abnormal.

Conen: Are you using the shell binary released in UDK2015?

Thanks.
Jiaxin

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, November 10, 2015 4:30 AM
To: Conen, Johannes; edk2-devel@lists.01.org
Cc: Leif Lindholm (Linaro address); Wu, Jiaxin
Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

On 11/09/15 16:52, Conen, Johannes wrote:
> Hello everyone,
> 
> after switching from UDK2014 to UDK2015, I noticed that the network 
> commands (ifconfig / ping) don't work anymore. ifconfig just exits 
> with no feedback and ping says "Config no mapping" (logical, as it is 
> not possible to get an IP address via ifconfig). In UDK2014 everything 
> worked fine.
> 
> With the help of unixsmurf (thanks a lot)

Argh. Can we stop using these "funny" nicks on IRC?

"unixsmurf" is Leif.

What do you think, Leif? :)

> I went on bughunting and
> found out that commit r17869 / git sha 
> 7c25b7ea5b2c029a9e7a0be57f7c20f31d720c7d broke it. Wild guess: it has 
> something to do with the new protocol.

That's close, but my take is not that exact commit. Instead, what about
this:

https://github.com/tianocore/edk2/commit/2aa0eb5df61e

== SVN rev 17917.

(I reviewed that commit.)

But, it works for me:

> Shell> ifconfig -s eth0 dhcp
> Shell> ifconfig -l eth0
>
> -
>
> name : eth0
> Media State : Media present
> policy : dhcp
> mac addr : 52:54:00:29:80:AE
>
> ipv4 address : 192.168.122.182
>
> subnet mask : 255.255.255.0
>
> default gateway: 192.168.122.1
>
> Routes (2 entries):
> Entry[0]
> Subnet : 192.168.122.0
> Netmask: 255.255.255.0
> Gateway: 0.0.0.0
> Entry[1]
> Subnet : 0.0.0.0
> Netmask: 0.0.0.0
> Gateway: 192.168.122.1
>
> DNS server :
> 192.168.122.1
>
>
> -
> Shell> ping 8.8.8.8
> Ping 8.8.8.8 16 data bytes.
> 16 bytes from 8.8.8.8 : icmp_seq=1 ttl=0 time=30640ms
> 16 bytes from 8.8.8.8 : icmp_seq=2 ttl=0 time=31249ms
> 16 bytes from 8.8.8.8 : icmp_seq=3 ttl=0 time=33280ms
> 16 bytes from 8.8.8.8 : icmp_seq=4 ttl=0 time=38577ms
> 16 bytes from 8.8.8.8 : icmp_seq=5 ttl=0 time=28432ms
> 16 bytes from 8.8.8.8 : icmp_seq=6 ttl=0 time=31275ms
> 16 bytes from 8.8.8.8 : icmp_seq=7 ttl=0 time=26576ms
> 16 bytes from 8.8.8.8 : icmp_seq=8 ttl=0 time=33192ms
> 16 bytes from 8.8.8.8 : icmp_seq=9 ttl=0 time=31112ms
> 16 bytes from 8.8.8.8 : icmp_seq=10 ttl=0 time=28237ms
>
> 10 packets transmitted, 10 received, 0% packet loss, time 312570ms
>
> Rtt(round trip time) min=26576ms max=38577ms avg=31257ms

This on OVMF just built from edk2 at SVN rev18759. (Note that in OVMF the shell 
is built from source as well.)

> Personally I think this is a critical issue - it practically makes it 
> impossible to use any network related stuff in the UEFI shell.

I suspect that you are using an old (UDK2014) shell binary on top of a new 
(UDK2015) network stack, or vice-versa.

If you check the commit message of SVN rev 17917 / git 2aa0eb5df61e, it said 
that it was safe to remove the Ip4Config protocol *because* SVN rev

Re: [edk2] [PATCH] MdeModulePkg: PeiCore: fix issue where AuthenticationStatus is not propagated correctly to encapsulated FVs by ensuring that the FvInfo2 PPI is installed before the FvInfo PPI

[Cohen, Eugene]

Star, Feel free to shorten the title as necessary and commit.

Thanks for reviewing this.

Eugene

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Monday, November 09, 2015 10:14 PM
To: Cohen, Eugene ; Tian, Feng ; 
edk2-devel@lists.01.org
Cc: Thompson, Mark L. ; Dellaquila, Katie 

Subject: Re: [edk2] [PATCH] MdeModulePkg: PeiCore: fix issue where 
AuthenticationStatus is not propagated correctly to encapsulated FVs by 
ensuring that the FvInfo2 PPI is installed before the FvInfo PPI

On 2015/11/10 9:01, Zeng, Star wrote:
> On 2015/11/9 22:02, Cohen, Eugene wrote:
>> Star,
>>
>> Apologies - the copyright change was a merge error from an older edk2 
>> snapshot.  Updated patch below.
>>
>> ---
>>
>> MdeModulePkg: PeiCore: fix issue where AuthenticationStatus is not 
>> propagated correctly to encapsulated FVs by ensuring that the FvInfo2 
>> PPI is installed before the FvInfo PPI
>>
>> This patch fixes an issue in PEI with encapsulated FV images where 
>> the AuthenticationStatus is not correctly propagated down to child FV 
>> handles.  The PEI core registers for callbacks for both FvInfo and
>> FvInfo2 PPIs.  These callbacks process the FVs which will recurse as 
>> necessary to find more encapsulated FVs.  (FvInfo2 is an updated PPI 
>> that includes an AuthenticationStatus field - the original FvInfo did 
>> not include this.)
>>
>> When encapsulated FV processing occurs the PEI core installs both 
>> FvInfo and FvInfo2 PPIs.  The original implementation installs FvInfo 
>> first and FvInfo2 second.  As soon as the FvInfo PPI is installed the 
>> notification callback handler immediately fires causing recursive FV 
>> processing to occur.  Since there is no AuthenticationStatus provided 
>> for the original FvInfo the callback assumes AuthenticationStatus is 
>> zero (unsigned / unverified) even though the parent FV may have been 
>> verified.
>>
>> This changes the order of FvInfo and FvInfo2 installs to ensure that 
>> the notification callback occurs for FvInfo2 first and appropriate 
>> AuthenticationStatus data can be propagated from parent FV to child 
>> FV.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Eugene Cohen eug...@hp.com
>>
>> ---
>>   MdeModulePkg/Core/Pei/FwVol/FwVol.c | 17 ++---
>>   1 file changed, 10 insertions(+), 7 deletions(-)
>
> Reviewed-by: Star Zeng 

The patch title is too long to commit.
You can resend the patch with refined title and my Reviewed-by, or let me to 
refine the title and then commit the patch.

Thanks,
Star
>
>>
>> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
>> b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
>> index 363ff7e..8f6e2ef 100644
>> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
>> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
>> @@ -1,6 +1,7 @@
>>   /** @file
>> Pei Core Firmware File System service routines.
>>
>> +Copyright (c) 2015 HP Development Company, L.P.
>>   Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
>>   This program and the accompanying materials
>>   are licensed and made available under the terms and conditions of 
>> the BSD License @@ -1381,22 +1382,24 @@ ProcessFvFile (
>>
>> //
>> // Install FvInfo(2) Ppi
>> +  // NOTE: FvInfo2 must be installed before FvInfo so that recursive
>> processing of encapsulated
>> +  // FVs inherit the proper AuthenticationStatus.
>> //
>> -  PeiServicesInstallFvInfoPpi (
>> +  PeiServicesInstallFvInfo2Ppi(
>>   >FileSystemGuid,
>> -(VOID**) FvHeader,
>> -(UINT32) FvHeader->FvLength,
>> +(VOID**)FvHeader,
>> +(UINT32)FvHeader->FvLength,
>>   ,
>> -
>> +,
>> +AuthenticationStatus
>>   );
>>
>> -  PeiServicesInstallFvInfo2Ppi (
>> +  PeiServicesInstallFvInfoPpi (
>>   >FileSystemGuid,
>>   (VOID**) FvHeader,
>>   (UINT32) FvHeader->FvLength,
>>   ,
>> -,
>> -AuthenticationStatus
>> +
>>   );
>>
>> //
>>

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

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Laszlo Ersek]

On 11/10/15 11:20, Conen, Johannes wrote:
> Hmm, you're right. is it briefly mentioned in the "ShellPkg
> Notes.txt" - I must admit, I only took a look at the
> "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major changes
> to mentioned there (and well, they were, like the moving of the
> library files). So this non-backwards-compatibility from UDK2015 to
> UDK2014 regarding network-related stuff is intended?

I'll have to let Jiaxin answer this question; I'm not a participant in
UDK feature planning. And, I have no idea how UDK releases account for
compatibility in general.

(My *guess* is that UDK2015 generally targets (or moved towards) UEFI
2.5, and Ip4Config (version 1) is apparently deprecated in UEFI 2.5.)

Thanks
Laszlo

> 
> Greetings
> Johannes
> 
> -Ursprüngliche Nachricht-
> Von: Laszlo Ersek [mailto:ler...@redhat.com] 
> Gesendet: Dienstag, 10. November 2015 11:06
> An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org
> Cc: Leif Lindholm (Linaro address)
> Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> 
> On 11/10/15 10:49, Conen, Johannes wrote:
>> Hi there,
>>
>> I made my tests with the binary shell from ShellBinPkg from UDK2014, 
>> from UDK2015, the current master and a few commits in between and 
>> rebuilt the shell from ShellPkg for UDK2014, UDK2015, the current 
>> master and a few commits in between UDK2014 and UDK2015.
>>
>> It worked fine with r17868 and didn't work anymore with r17869, so it 
>> has to be that commit (I of course rebuilt the shell from ShellPkg).
>> If I put both shells on a USB-stick and switch between them on the 
>> fly, it works in the one built from r17868 and doesn't work in the one 
>> built from r17869. Regarding ShellBinPkg: the last version that worked 
>> is r17619 (which is quite logical since the version after that, 
>> r18187, is built from ShellPkg r18186, which didn't work for me 
>> anymore).
>>
>> I'm not working on OVMF, but on real hardware (X64) - don't know 
>> exactly with which version the UEFI firmware was written, but I assume 
>> it's UDK2014. I found nothing in the release notes that would break 
>> backwards compatibility to firmware versions built with older EDKII 
>> versions in this regard.
> 
> Okay, that seems to explain it. The platform firmware on your physical 
> machine provides Ip4Config (version 1) only, but the shell built from recent 
> edk2 (and probably the binary shipped in UDK2015) requires Ip4Config2.
> 
> Hm... I have not been a UDK user, but now I downloaded "UDK2015.Notes.zip", 
> and in "ShellPkg Notes.txt", it says under "NEW FEATURES AND CHANGES", point 
> 15:
> 
>   Change "ping" and "ifconfig" code to consume Ip4Config2 protocol.
> 
> So I think this has been (technically) documented in the UDK2015 release. 
> Perhaps the lack of compatibility with UDK2014 should have been emphasized.
> 
> (But, I'm just a curious bystander in this discussion anwyay...)
> 
> Thanks
> Laszlo
> 
>>
>> With best regards,
>> Johannes Conen
>>
>> Siemens AG
>> Process Industries and Drives Division Process Automation 
>> Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. 
>> 50
>> 76187 Karlsruhe, Germany
>> mailto:johannes.co...@siemens.com
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
>> Gesendet: Dienstag, 10. November 2015 02:42
>> An: Laszlo Ersek; Conen, Johannes; edk2-devel@lists.01.org
>> Cc: Leif Lindholm (Linaro address)
>> Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
>>
>> Hi Laszlo and Conen,
>> Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg in 
>> UDK2015 release version, Both of them have included my patch for Ip4Config 
>> Protocol deprecated work.
>> I'm also confused by the test result below, seems only time appeared 
>> abnormal.
>>
>> Conen: Are you using the shell binary released in UDK2015?
>>
>> Thanks.
>> Jiaxin
>>
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, November 10, 2015 4:30 AM
>> To: Conen, Johannes; edk2-devel@lists.01.org
>> Cc: Leif Lindholm (Linaro address); Wu, Jiaxin
>> Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
>>
>> On 11/09/15 16:52, Conen, Johannes wrote:
>>> Hello everyone,
>>>
>>> after switching from UDK2014 to UDK2015, I noticed that the network 
>>> commands (ifconfig / ping) don't work anymore. ifconfig just exits 
>>> with no feedback and ping says "Config no mapping" (logical, as it is 
>>> not possible to get an IP address via ifconfig). In UDK2014 everything 
>>> worked fine.
>>>
>>> With the help of unixsmurf (thanks a lot)
>>
>> Argh. Can we stop using these "funny" nicks on IRC?
>>
>> "unixsmurf" is Leif.
>>
>> What do you think, Leif? :)
>>
>>> I went on bughunting and
>>> found out that commit r17869 / git sha 
>>> 7c25b7ea5b2c029a9e7a0be57f7c20f31d720c7d broke it. Wild guess: it has 
>>> something to do with the new protocol.
>>
>> 

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Leif Lindholm]

On Tue, Nov 10, 2015 at 11:28:10AM +0100, Laszlo Ersek wrote:
> On 11/10/15 11:20, Conen, Johannes wrote:
> > Hmm, you're right. is it briefly mentioned in the "ShellPkg
> > Notes.txt" - I must admit, I only took a look at the
> > "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major changes
> > to mentioned there (and well, they were, like the moving of the
> > library files). So this non-backwards-compatibility from UDK2015 to
> > UDK2014 regarding network-related stuff is intended?
> 
> I'll have to let Jiaxin answer this question; I'm not a participant in
> UDK feature planning. And, I have no idea how UDK releases account for
> compatibility in general.
> 
> (My *guess* is that UDK2015 generally targets (or moved towards) UEFI
> 2.5, and Ip4Config (version 1) is apparently deprecated in UEFI 2.5.)

The actual wording from the specification is:
---
The EFI_IP4_CONFIG_PROTOCOL has been replaced with the new
EFI_IP4_CONFIG2_PROTOCOL.
• All new designs based on this specification should exclusively use
  EFI_IP4_CONFIG2_PROTOCOL .
• The EFI_IP4_CONFIG_PROTOCOL will be removed in the next revision of
  this specification.
---

Clearly this creates a compatibility breakage at some point.

Is this something we consider "not a problem", or should the shell
implement (providing a reference for how to implement) fallback to
EFI_IP4_CONFIG_PROTOCOL if EFI_IP4_CONFIG2_PROTOCOL is not available?

Regards,

Leif

> Thanks
> Laszlo
> 
> > 
> > Greetings
> > Johannes
> > 
> > -Ursprüngliche Nachricht-
> > Von: Laszlo Ersek [mailto:ler...@redhat.com] 
> > Gesendet: Dienstag, 10. November 2015 11:06
> > An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org
> > Cc: Leif Lindholm (Linaro address)
> > Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> > 
> > On 11/10/15 10:49, Conen, Johannes wrote:
> >> Hi there,
> >>
> >> I made my tests with the binary shell from ShellBinPkg from UDK2014, 
> >> from UDK2015, the current master and a few commits in between and 
> >> rebuilt the shell from ShellPkg for UDK2014, UDK2015, the current 
> >> master and a few commits in between UDK2014 and UDK2015.
> >>
> >> It worked fine with r17868 and didn't work anymore with r17869, so it 
> >> has to be that commit (I of course rebuilt the shell from ShellPkg).
> >> If I put both shells on a USB-stick and switch between them on the 
> >> fly, it works in the one built from r17868 and doesn't work in the one 
> >> built from r17869. Regarding ShellBinPkg: the last version that worked 
> >> is r17619 (which is quite logical since the version after that, 
> >> r18187, is built from ShellPkg r18186, which didn't work for me 
> >> anymore).
> >>
> >> I'm not working on OVMF, but on real hardware (X64) - don't know 
> >> exactly with which version the UEFI firmware was written, but I assume 
> >> it's UDK2014. I found nothing in the release notes that would break 
> >> backwards compatibility to firmware versions built with older EDKII 
> >> versions in this regard.
> > 
> > Okay, that seems to explain it. The platform firmware on your physical 
> > machine provides Ip4Config (version 1) only, but the shell built from 
> > recent edk2 (and probably the binary shipped in UDK2015) requires 
> > Ip4Config2.
> > 
> > Hm... I have not been a UDK user, but now I downloaded "UDK2015.Notes.zip", 
> > and in "ShellPkg Notes.txt", it says under "NEW FEATURES AND CHANGES", 
> > point 15:
> > 
> >   Change "ping" and "ifconfig" code to consume Ip4Config2 protocol.
> > 
> > So I think this has been (technically) documented in the UDK2015 release. 
> > Perhaps the lack of compatibility with UDK2014 should have been emphasized.
> > 
> > (But, I'm just a curious bystander in this discussion anwyay...)
> > 
> > Thanks
> > Laszlo
> > 
> >>
> >> With best regards,
> >> Johannes Conen
> >>
> >> Siemens AG
> >> Process Industries and Drives Division Process Automation 
> >> Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. 
> >> 50
> >> 76187 Karlsruhe, Germany
> >> mailto:johannes.co...@siemens.com
> >>
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
> >> Gesendet: Dienstag, 10. November 2015 02:42
> >> An: Laszlo Ersek; Conen, Johannes; edk2-devel@lists.01.org
> >> Cc: Leif Lindholm (Linaro address)
> >> Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> >>
> >> Hi Laszlo and Conen,
> >> Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg 
> >> in UDK2015 release version, Both of them have included my patch for 
> >> Ip4Config Protocol deprecated work.
> >> I'm also confused by the test result below, seems only time appeared 
> >> abnormal.
> >>
> >> Conen: Are you using the shell binary released in UDK2015?
> >>
> >> Thanks.
> >> Jiaxin
> >>
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Tuesday, November 10, 2015 4:30 AM
> >> To: Conen, Johannes; 

Re: [edk2] MdePkg: Enable Xcode build of BaseLib without

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, November 10, 2015 3:18 PM
> To: edk2-devel
> Cc: Gao, Liming; Kinney, Michael D
> Subject: MdePkg: Enable Xcode build of BaseLib without
> 
> Please review.
> 
> To build with Xcode without installing NASM I had to make the following 
> change.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] PiCpuSmmEntry() function in PiSmmCpuDxeSmm.c - What is the algorithm to tile the CPU save state and code for the SMI entry point in SMRAM?

[Anh Luong]

Hi,

The comments in
https://github.com/mdkinney/edk2/blob/AddSmmUefiCpuPkg/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
show an example of how CPU save state and SMI hanlder are tiled in SMRAM,
but I cannot find where is the save state for CPU m+2 to 2m. Besides, I
cannot tell the relation between the processor number of the CPU save state
and the processor number of SMI handler in each 32KB area. Can someone
clarify this for me?

Comments are copied below:

  //  +-+  <-- 2^n offset from Base of
allocated buffer
  //  |   CPU m+1 Save State|
  //  +-+
  //  |   CPU m+1 Extra Data|
  //  +-+
  //  |   Padding   |
  //  +-+
  //  |   CPU 2m  SMI Entry |
  //  +#+  <-- Base of allocated buffer + 64 KB
  //  |   CPU m-1 Save State|
  //  +-+
  //  |   CPU m-1 Extra Data|
  //  +-+
  //  |   Padding   |
  //  +-+
  //  |   CPU 2m-1 SMI Entry|
  //  +=+  <-- 2^n offset from Base of
allocated buffer
  //  |   . . . . . . . . . . . .   |
  //  +=+  <-- 2^n offset from Base of
allocated buffer
  //  |   CPU 2 Save State  |
  //  +-+
  //  |   CPU 2 Extra Data  |
  //  +-+
  //  |   Padding   |
  //  +-+
  //  |   CPU m+1 SMI Entry |
  //  +=+  <-- Base of allocated buffer + 32 KB
  //  |   CPU 1 Save State  |
  //  +-+
  //  |   CPU 1 Extra Data  |
  //  +-+
  //  |   Padding   |
  //  +-+
  //  |   CPU m SMI Entry   |
  //  +#+  <-- Base of allocated buffer + 32 KB
== CPU 0 SMBASE + 64 KB
  //  |   CPU 0 Save State  |
  //  +-+
  //  |   CPU 0 Extra Data  |
  //  +-+
  //  |   Padding   |
  //  +-+
  //  |   CPU m-1 SMI Entry |
  //  +=+  <-- 2^n offset from Base of
allocated buffer
  //  |   . . . . . . . . . . . .   |
  //  +=+  <-- 2^n offset from Base of
allocated buffer
  //  |   Padding   |
  //  +-+
  //  |   CPU 1 SMI Entry   |
  //  +=+  <-- 2^n offset from Base of
allocated buffer
  //  |   Padding   |
  //  +-+
  //  |   CPU 0 SMI Entry   |
  //  +#+  <-- Base of allocated buffer == CPU
0 SMBASE + 32 KB

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

Re: [edk2] MdePkg: Enable Xcode build of BaseLib without

[Gao, Liming]

This patch is committed at r18766.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Tuesday, November 10, 2015 11:31 PM
To: Gao, Liming
Cc: edk2-devel; Kinney, Michael D
Subject: Re: MdePkg: Enable Xcode build of BaseLib without


On Nov 10, 2015, at 12:22 AM, Gao, Liming 
> wrote:

Reviewed-by: Liming Gao >

Liming,

Can you commit the patch?

Thanks,

Andrew Fsih

>cat 0004-MdePkg-BaseLib-don-t-require-NASM-with-Xcode.patch
>From 8f4666bc80d6d4844e73b3a221e50d587ef09cec Mon Sep 17 00:00:00 2001
From: andrew fish >
Date: Mon, 9 Nov 2015 22:46:32 -0800
Subject: [PATCH 4/4] MdePkg: BaseLib don't require NASM with Xcode

Don't require NASM for simple edk2 Xcode projects.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish >
Reviewed-by: Liming Gao >
---
 MdePkg/Library/BaseLib/BaseLib.inf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 4cc86d7..e83a569 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -257,6 +257,7 @@

   Ia32/GccInline.c | GCC
   Ia32/Thunk16.nasm | GCC
+  Ia32/Thunk16.S | XCODE
   Ia32/EnableDisableInterrupts.S | GCC
   Ia32/EnablePaging64.S | GCC
   Ia32/DisablePaging32.S | GCC
@@ -413,6 +414,7 @@
   X86DisablePaging32.c
   X64/GccInline.c | GCC
   X64/Thunk16.nasm | GCC
+  X64/Thunk16.S | XCODE
   X64/SwitchStack.S | GCC
   X64/SetJump.S | GCC
   X64/LongJump.S | GCC
--
2.3.2 (Apple Git-55)

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

Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Zeng, Star]

On 2015/11/10 23:31, Andrew Fish wrote:



On Nov 10, 2015, at 7:04 AM, Andrew Fish  wrote:



On Nov 10, 2015, at 12:06 AM, Gao, Liming  wrote:

Andrew:
The patch is missing.



Liming,

My sent mail shows these 3 patches attached?
0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch

I attached again here:





cat 0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch

 From 4eb94d539de6ee8e4b8eebc43d67dfdfe68e64bf Mon Sep 17 00:00:00 2001
From: andrew fish 
Date: Mon, 9 Nov 2015 22:29:54 -0800
Subject: [PATCH 1/4] MdeModulePkg:PeiCore Fix Xcode -Wempty-body warning The
  single line for(); construct is followd by code that is indented. This
  trigers the -Wempty-body warning. Fix indentation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
---
  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)


Reviewed-by: Star Zeng 



diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 7480b66..dbcd800 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -681,15 +681,15 @@ PeiCheckAndSwitchStack (
 && (*StackPointer == INIT_CAR_VALUE);
 StackPointer ++);

-DEBUG ((EFI_D_INFO, "Temp Stack : BaseAddress=0x%p Length=0x%X\n", 
SecCoreData->StackBase, (UINT32)SecCoreData->StackSize));
-DEBUG ((EFI_D_INFO, "Temp Heap  : BaseAddress=0x%p Length=0x%X\n", 
Private->HobList.Raw, (UINT32)((UINTN) 
Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - (UINTN) 
Private->HobList.Raw)));
-DEBUG ((EFI_D_INFO, "Total temporary memory:%d bytes.\n", 
(UINT32)SecCoreData->TemporaryRamSize));
-DEBUG ((EFI_D_INFO, "  temporary memory stack ever used: %d bytes.\n",
-   (UINT32)(SecCoreData->StackSize - ((UINTN) StackPointer - 
(UINTN)SecCoreData->StackBase))
-  ));
-DEBUG ((EFI_D_INFO, "  temporary memory heap used:   %d bytes.\n",
-   
(UINT32)((UINTN)Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - 
(UINTN)Private->HobList.Raw)
-  ));
+  DEBUG ((EFI_D_INFO, "Temp Stack : BaseAddress=0x%p Length=0x%X\n", 
SecCoreData->StackBase, (UINT32)SecCoreData->StackSize));
+  DEBUG ((EFI_D_INFO, "Temp Heap  : BaseAddress=0x%p Length=0x%X\n", 
Private->HobList.Raw, (UINT32)((UINTN) 
Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - (UINTN) 
Private->HobList.Raw)));
+  DEBUG ((EFI_D_INFO, "Total temporary memory:%d bytes.\n", 
(UINT32)SecCoreData->TemporaryRamSize));
+  DEBUG ((EFI_D_INFO, "  temporary memory stack ever used: %d bytes.\n",
+ (UINT32)(SecCoreData->StackSize - ((UINTN) StackPointer - 
(UINTN)SecCoreData->StackBase))
+));
+  DEBUG ((EFI_D_INFO, "  temporary memory heap used:   %d bytes.\n",
+ 
(UINT32)((UINTN)Private->HobList.HandoffInformationTable->EfiFreeMemoryBottom - 
(UINTN)Private->HobList.Raw)
+));
  DEBUG_CODE_END ();

  if (PcdGet64(PcdLoadModuleAtFixAddressEnable) != 0 && 
(Private->HobList.HandoffInformationTable->BootMode != BOOT_ON_S3_RESUME)) {



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

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Wu, Jiaxin]

Yes, Laszlo, we have discussed this topic for a long time, and also we have 
declared that dependent network drivers, libraries and applications have been 
migrated to the new protocol version. But no one have more comments for that 
compatibility change. 
Since UEFI2.5 Spec also declares the EFI_IP4_CONFIG_PROTOCOL has been replaced 
with the new EFI_IP4_CONFIG2_PROTOCOL,  we think it's ok to deprecate the old 
protocol.

Thanks.
Jiaxin

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, November 10, 2015 7:54 PM
To: Leif Lindholm
Cc: Wu, Jiaxin; edk2-devel@lists.01.org
Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

On 11/10/15 11:43, Leif Lindholm wrote:
> On Tue, Nov 10, 2015 at 11:28:10AM +0100, Laszlo Ersek wrote:
>> On 11/10/15 11:20, Conen, Johannes wrote:
>>> Hmm, you're right. is it briefly mentioned in the "ShellPkg 
>>> Notes.txt" - I must admit, I only took a look at the 
>>> "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major 
>>> changes to mentioned there (and well, they were, like the moving of 
>>> the library files). So this non-backwards-compatibility from UDK2015 
>>> to
>>> UDK2014 regarding network-related stuff is intended?
>>
>> I'll have to let Jiaxin answer this question; I'm not a participant 
>> in UDK feature planning. And, I have no idea how UDK releases account 
>> for compatibility in general.
>>
>> (My *guess* is that UDK2015 generally targets (or moved towards) UEFI 
>> 2.5, and Ip4Config (version 1) is apparently deprecated in UEFI 2.5.)
> 
> The actual wording from the specification is:
> ---
> The EFI_IP4_CONFIG_PROTOCOL has been replaced with the new 
> EFI_IP4_CONFIG2_PROTOCOL.
> . All new designs based on this specification should exclusively use
>   EFI_IP4_CONFIG2_PROTOCOL .
> . The EFI_IP4_CONFIG_PROTOCOL will be removed in the next revision of
>   this specification.
> ---
> 
> Clearly this creates a compatibility breakage at some point.
> 
> Is this something we consider "not a problem", or should the shell 
> implement (providing a reference for how to implement) fallback to 
> EFI_IP4_CONFIG_PROTOCOL if EFI_IP4_CONFIG2_PROTOCOL is not available?

Whether the shell in edk2 should or should not provide fallback code for 
EFI_IP4_CONFIG_PROTOCOL is for Intel to answer :), but I think I can ask one 
more question as to "how".

Namely, if one adds (or keeps) the Ip4Config fallback code to (in) the shell in 
edk2, how does that compat feature get tested, staying within the tree? It 
would require keeping the Ip4Config protocol implementation around just for the 
sake of testing the fallback.

I don't think that's a good idea.

Instead, any dependencies on specific versions of the UEFI spec should be 
spelled out loud and clear. (I believe I've read such requirements presented by 
Windows, on MSDN.) Mapping each UDK release to a UEFI spec version would be a 
bonus.

Thanks
Laszlo

> 
> Regards,
> 
> Leif
> 
>> Thanks
>> Laszlo
>>
>>>
>>> Greetings
>>> Johannes
>>>
>>> -Ursprüngliche Nachricht-
>>> Von: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Gesendet: Dienstag, 10. November 2015 11:06
>>> An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org
>>> Cc: Leif Lindholm (Linaro address)
>>> Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) 
>>> broken
>>>
>>> On 11/10/15 10:49, Conen, Johannes wrote:
 Hi there,

 I made my tests with the binary shell from ShellBinPkg from 
 UDK2014, from UDK2015, the current master and a few commits in 
 between and rebuilt the shell from ShellPkg for UDK2014, UDK2015, 
 the current master and a few commits in between UDK2014 and UDK2015.

 It worked fine with r17868 and didn't work anymore with r17869, so 
 it has to be that commit (I of course rebuilt the shell from ShellPkg).
 If I put both shells on a USB-stick and switch between them on the 
 fly, it works in the one built from r17868 and doesn't work in the 
 one built from r17869. Regarding ShellBinPkg: the last version that 
 worked is r17619 (which is quite logical since the version after 
 that, r18187, is built from ShellPkg r18186, which didn't work for 
 me anymore).

 I'm not working on OVMF, but on real hardware (X64) - don't know 
 exactly with which version the UEFI firmware was written, but I 
 assume it's UDK2014. I found nothing in the release notes that 
 would break backwards compatibility to firmware versions built with 
 older EDKII versions in this regard.
>>>
>>> Okay, that seems to explain it. The platform firmware on your physical 
>>> machine provides Ip4Config (version 1) only, but the shell built from 
>>> recent edk2 (and probably the binary shipped in UDK2015) requires 
>>> Ip4Config2.
>>>
>>> Hm... I have not been a UDK user, but now I downloaded "UDK2015.Notes.zip", 
>>> and in "ShellPkg Notes.txt", it says under "NEW FEATURES AND CHANGES", 
>>> point 15:
>>>
>>>   

Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Zeng, Star]

On 2015/11/10 23:33, Andrew Fish wrote:



On Nov 10, 2015, at 7:04 AM, Andrew Fish  wrote:



On Nov 10, 2015, at 12:06 AM, Gao, Liming > wrote:

Andrew:
The patch is missing.



Liming,

My sent mail shows these 3 patches attached?
0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch

I attached again here:






cat 0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch

 From 56cea06ce806fd0ac9295e1211964f30e6baaac1 Mon Sep 17 00:00:00 2001
From: andrew fish 
Date: Mon, 9 Nov 2015 22:42:57 -0800
Subject: [PATCH 3/4] MdeModulePkg: Variable add mising VA_COPY

Xcode fails to compile:
error: array type 'VA_LIST' (aka '__builtin_va_list') is not assignable

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
---
  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Star Zeng 



diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 621ce16..8a07f0e 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -1716,7 +1716,7 @@ CheckRemainingSpaceForConsistencyInternal (
ASSERT_EFI_ERROR (Status);

TotalNeededSize = 0;
-  Args = Marker;
+  VA_COPY (Args, Marker);
VariableEntry = VA_ARG (Args, VARIABLE_ENTRY_CONSISTENCY *);
while (VariableEntry != NULL) {
  //
@@ -1745,7 +1745,7 @@ CheckRemainingSpaceForConsistencyInternal (
  return FALSE;
}

-  Args = Marker;
+  VA_COPY (Args, Marker);
VariableEntry = VA_ARG (Args, VARIABLE_ENTRY_CONSISTENCY *);
while (VariableEntry != NULL) {
  //



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

Re: [edk2] [patch] NetworkPkg: Report Http Errors to screen when http layer occurs an error

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 


-Original Message-
From: Zhang, Lubo 
Sent: Monday, November 9, 2015 5:57 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin; Samer El-Haj-Mahmoud
Subject: [patch] NetworkPkg: Report Http Errors to screen when http layer 
occurs an error

v2:
* Change the print message to a more readable string and add the redirection 
status code
(3xx)

Cc: Ye Ting 
Cc: Fu Siyuan 
CC: Wu Jiaxin 
CC: Samer El-Haj-Mahmoud 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/HttpBootDxe/HttpBootSupport.c | 151 ++-
 1 file changed, 150 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootSupport.c 
b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
index d08111f..1fc4e76 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootSupport.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
@@ -145,10 +145,153 @@ HttpBootShowIp6Addr (
 }
   }
 }
 
 /**
+  This function is to display the HTTP error status.
+
+  @param[in]  StatusCode  The status code value in HTTP message.
+
+**/
+VOID
+HttpBootPrintErrorMessage (
+  EFI_HTTP_STATUS_CODEStatusCode
+  )
+{
+  AsciiPrint ("\n");
+
+  switch (StatusCode) {
+  case HTTP_STATUS_300_MULTIPLE_CHIOCES:
+AsciiPrint ("\n  Redirection: 300 Multiple Choices");
+break;
+
+  case HTTP_STATUS_301_MOVED_PERMANENTLY:
+AsciiPrint ("\n  Redirection: 301 Moved Permanently");
+break;
+
+  case HTTP_STATUS_302_FOUND:
+AsciiPrint ("\n  Redirection: 302 Found");
+break;
+
+  case HTTP_STATUS_303_SEE_OTHER:
+AsciiPrint ("\n  Redirection: 303 See Other");
+break;
+
+  case HTTP_STATUS_304_NOT_MODIFIED:
+AsciiPrint ("\n  Redirection: 304 Not Modified");
+break;
+
+  case HTTP_STATUS_305_USE_PROXY:
+AsciiPrint ("\n  Redirection: 305 Use Proxy");
+break;
+
+  case HTTP_STATUS_307_TEMPORARY_REDIRECT:
+AsciiPrint ("\n  Redirection: 307 Temporary Redirect");
+break;
+
+  case HTTP_STATUS_400_BAD_REQUEST:
+AsciiPrint ("\n  Client Error: 400 Bad Request");
+break;
+
+  case HTTP_STATUS_401_UNAUTHORIZED:
+AsciiPrint ("\n  Client Error: 401 Unauthorized");
+break;
+
+  case HTTP_STATUS_402_PAYMENT_REQUIRED:
+AsciiPrint ("\n  Client Error: 402 Payment Required");
+break;
+
+  case HTTP_STATUS_403_FORBIDDEN:
+AsciiPrint ("\n  Client Error: 403 Forbidden");
+break;
+
+  case HTTP_STATUS_404_NOT_FOUND:
+AsciiPrint ("\n  Client Error: 404 Not Found");
+break;
+
+  case HTTP_STATUS_405_METHOD_NOT_ALLOWED:
+AsciiPrint ("\n  Client Error: 405 Method Not Allowed");
+break;
+
+  case HTTP_STATUS_406_NOT_ACCEPTABLE:
+AsciiPrint ("\n  Client Error: 406 Not Acceptable");
+break;
+
+  case HTTP_STATUS_407_PROXY_AUTHENTICATION_REQUIRED:
+AsciiPrint ("\n  Client Error: 407 Proxy Authentication Required");
+break;
+
+  case HTTP_STATUS_408_REQUEST_TIME_OUT:
+AsciiPrint ("\n  Client Error: 408 Request Timeout");
+break;
+
+  case HTTP_STATUS_409_CONFLICT:
+AsciiPrint ("\n  Client Error: 409 Conflict");
+break;
+
+  case HTTP_STATUS_410_GONE:
+AsciiPrint ("\n  Client Error: 410 Gone");
+break;
+
+  case HTTP_STATUS_411_LENGTH_REQUIRED:
+AsciiPrint ("\n  Client Error: 411 Length Required");
+break;
+
+  case HTTP_STATUS_412_PRECONDITION_FAILED:
+AsciiPrint ("\n  Client Error: 412 Precondition Failed");
+break;
+
+  case HTTP_STATUS_413_REQUEST_ENTITY_TOO_LARGE:
+AsciiPrint ("\n  Client Error: 413 Request Entity Too Large");
+break;
+
+  case HTTP_STATUS_414_REQUEST_URI_TOO_LARGE:
+AsciiPrint ("\n  Client Error: 414 Request URI Too Long");
+break;
+
+  case HTTP_STATUS_415_UNSUPPORTED_MEDIA_TYPE:
+AsciiPrint ("\n  Client Error: 415 Unsupported Media Type");
+break;
+
+  case HTTP_STATUS_416_REQUESTED_RANGE_NOT_SATISFIED:
+AsciiPrint ("\n  Client Error: 416 Requested Range Not Satisfiable");
+break;
+
+  case HTTP_STATUS_417_EXPECTATION_FAILED:
+AsciiPrint ("\n  Client Error: 417 Expectation Failed");
+break;
+
+  case HTTP_STATUS_500_INTERNAL_SERVER_ERROR:
+AsciiPrint ("\n  Server Error: 500 Internal Server Error");
+break;
+
+  case HTTP_STATUS_501_NOT_IMPLEMENTED:
+AsciiPrint ("\n  Server Error: 501 Not Implemented");
+break;
+
+  case HTTP_STATUS_502_BAD_GATEWAY:
+AsciiPrint ("\n  Server Error: 502 Bad Gateway");
+break;
+
+  case HTTP_STATUS_503_SERVICE_UNAVAILABLE:
+AsciiPrint ("\n  Server Error: 503 Service Unavailable");
+break;
+
+  case HTTP_STATUS_504_GATEWAY_TIME_OUT:
+AsciiPrint ("\n  Server Error: 504 Gateway Timeout");
+break;
+
+  case HTTP_STATUS_505_HTTP_VERSION_NOT_SUPPORTED:
+AsciiPrint ("\n  Server Error: 505 HTTP Version Not Supported");
+break;
+
+  default: ;
+  
+  }
+}
+
+/**
   Notify the 

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Heyi Guo]

On 11/11/2015 04:34 AM, Kinney, Michael D wrote:

Heyi,

All timers in UEFI are the minimum time.  So the only way to guarantee that a 
FIFO will never overflow is to use flow control.

Setting the poll rate based on FIFO depth and baud rate, data bits, and stop 
bits with flow control disabled means it should work most of the time, but 
another UEFI event notification function running at the same TPL or higher can 
block the Terminal event notification function and input characters could be 
lost.

I agree that the current 20ms periodic timer can overflow depending in the FIFO 
depth and the baud rate, and that we could reduce data loss in flow control 
disabled configurations if this periodic rate was computed instead of using a 
hard coded #define.  Another constraint is the system timer interrupt rate 
provided by the Timer Architectural Protocol.  A request for a periodic timer 
event that is faster than the current system timer rate will call the event 
notification function at the rate of the system timer.  So even if you reduce 
the periodic timer event time to a computed value, the time between event 
notification function calls may not change.
Totally agree. However normally we will have platform configuration 
interface for interrupt rate of system timer, like PCD or even driver 
override, but I can't find any interface to configure polling rate of 
the terminal driver, and I really don't like to override the whole 
terminal driver when I only want to change the polling rate :). That's 
the reason why I want to make a patch for terminal driver.




In order to prevent overflows, I think the timer rate in 100ns units could be 
computed as follows:

Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000

--
BaudRate

For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 115200 
would be:

16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277

Which is 0.00153 seconds or 1.53 ms.
Can I consider this as your agreement on calculating polling rate in 
terminal driver?


After all, really appreciate your detailed answer on this issue.

Heyi



Best regards,

Mike


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Monday, November 09, 2015 10:23 PM
To: Kinney, Michael D; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

Hi Michael,

Yes we can see terminal input truncated when we use copy-paste to input
characters.

I don't quite understand the relationship between SerialInTimeOut and
timer event poll rate; and I don't see the periodic timer rate is to be
updated later; we are using 0.02ms period all over, aren't we?

If the timer event polls the serial device at a fixed rate, how can we
guarantee the FIFO of the device will not overflow during a burst input?

Thanks.

On 11/10/2015 01:25 AM, Kinney, Michael D wrote:

Heyi,

The function TerminalConInTimerHandler () computes a timeout based on the baud 
rate, data bits, and stop bits

//
// According to BAUD rate to calculate the timeout value.
//
SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 100 / 
(UINTN) Mode->BaudRate;

The #define is used to set the initial periodic timer rate before the rest of 
the information to compute a timeout is known.

Are you observing an issue?

Mike


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi
Guo
Sent: Monday, November 09, 2015 1:48 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: [edk2] [RFC] Adaptively set serial terminal input polling interval

Hi All,

In MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf, the
polling interval is fixed by macro:

#define KEYBOARD_TIMER_INTERVAL 20  // 0.02s

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

If we want to capture all input, we need to poll with the interval of 32
/ (115200 / (8 + 1 + 1)) = 2.8 ms, 8 + 1 + 1 for data bits + start bit +
stop bit.

So, I suppose to use a PCD to set the interval per platform, or
calculate from serial IO protocol IO Mode, which contains FIFO depth and
data bits, etc, and we can use 20 as the maximum for compatibility,
or default value when fifo depth is 0.

Please let me know your comments.

Thanks.

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

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


___
edk2-devel mailing list

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Kinney, Michael D]

Heyi,

Yes.  I think computing the poll rate is a good addition to the TerminalDxe 
module.

If any of the information required to compute the rate is not available, then 
the #define default rate can be used.

Do you want to prepare a patch with this enhancement?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
>Sent: Tuesday, November 10, 2015 5:27 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Cc: Tian, Feng
>Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval
>
>
>
>On 11/11/2015 04:34 AM, Kinney, Michael D wrote:
>> Heyi,
>>
>> All timers in UEFI are the minimum time.  So the only way to guarantee that 
>> a FIFO will never overflow is to use flow control.
>>
>> Setting the poll rate based on FIFO depth and baud rate, data bits, and stop 
>> bits with flow control disabled means it should work
>most of the time, but another UEFI event notification function running at the 
>same TPL or higher can block the Terminal event
>notification function and input characters could be lost.
>>
>> I agree that the current 20ms periodic timer can overflow depending in the 
>> FIFO depth and the baud rate, and that we could reduce
>data loss in flow control disabled configurations if this periodic rate was 
>computed instead of using a hard coded #define.  Another
>constraint is the system timer interrupt rate provided by the Timer 
>Architectural Protocol.  A request for a periodic timer event that is
>faster than the current system timer rate will call the event notification 
>function at the rate of the system timer.  So even if you
>reduce the periodic timer event time to a computed value, the time between 
>event notification function calls may not change.
>Totally agree. However normally we will have platform configuration
>interface for interrupt rate of system timer, like PCD or even driver
>override, but I can't find any interface to configure polling rate of
>the terminal driver, and I really don't like to override the whole
>terminal driver when I only want to change the polling rate :). That's
>the reason why I want to make a patch for terminal driver.
>
>>
>> In order to prevent overflows, I think the timer rate in 100ns units could 
>> be computed as follows:
>>
>>  Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000
>>  
>> --
>>  BaudRate
>>
>> For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 
>> 115200 would be:
>>
>>  16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277
>>
>> Which is 0.00153 seconds or 1.53 ms.
>Can I consider this as your agreement on calculating polling rate in
>terminal driver?
>
>After all, really appreciate your detailed answer on this issue.
>
>Heyi
>
>>
>> Best regards,
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Monday, November 09, 2015 10:23 PM
>>> To: Kinney, Michael D; edk2-devel@lists.01.org
>>> Cc: Tian, Feng
>>> Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling 
>>> interval
>>>
>>> Hi Michael,
>>>
>>> Yes we can see terminal input truncated when we use copy-paste to input
>>> characters.
>>>
>>> I don't quite understand the relationship between SerialInTimeOut and
>>> timer event poll rate; and I don't see the periodic timer rate is to be
>>> updated later; we are using 0.02ms period all over, aren't we?
>>>
>>> If the timer event polls the serial device at a fixed rate, how can we
>>> guarantee the FIFO of the device will not overflow during a burst input?
>>>
>>> Thanks.
>>>
>>> On 11/10/2015 01:25 AM, Kinney, Michael D wrote:
 Heyi,

 The function TerminalConInTimerHandler () computes a timeout based on the 
 baud rate, data bits, and stop bits

 //
 // According to BAUD rate to calculate the timeout value.
 //
 SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 
 100 / (UINTN) Mode->BaudRate;

 The #define is used to set the initial periodic timer rate before the rest 
 of the information to compute a timeout is known.

 Are you observing an issue?

 Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Heyi
> Guo
> Sent: Monday, November 09, 2015 1:48 AM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng
> Subject: [edk2] [RFC] Adaptively set serial terminal input polling 
> interval
>
> Hi All,
>
> In MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf, the
> polling interval is fixed by macro:
>
> #define KEYBOARD_TIMER_INTERVAL 20  // 0.02s
>
> However, this may cause fast input to be truncated on some platform. For
> example, 

Re: [edk2] [Patch] BaseTools/GenFw: add new option to not zero PE/COFF optional header fields

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Yonghong Zhu
> Sent: Monday, November 09, 2015 3:33 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; carl.mil...@pnnl.gov
> Subject: [edk2] [Patch] BaseTools/GenFw: add new option to not zero PE/COFF 
> optional header fields
> 
> Add new option --keepoptionalheader and that flag does not zero PE/COFF
> optional header fields including the version fields. It can support the
> case that the PE/COFF optional header would be kept.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  Source/C/GenFw/GenFw.c | 82 
> +-
>  1 file changed, 48 insertions(+), 34 deletions(-)
> 
> diff --git a/Source/C/GenFw/GenFw.c b/Source/C/GenFw/GenFw.c
> index 4756c52..9ddd18e 100644
> --- a/Source/C/GenFw/GenFw.c
> +++ b/Source/C/GenFw/GenFw.c
> @@ -1,9 +1,9 @@
>  /** @file
>  Converts a pe32+ image to an FW, Te image type, or other specific image.
> 
> -Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
>  http://opensource.org/licenses/bsd-license.php
> 
> @@ -166,11 +166,11 @@ Returns:
>fprintf (stdout, "\nUsage: %s [options] \n\n", UTILITY_NAME);
> 
>//
>// Copyright declaration
>//
> -  fprintf (stdout, "Copyright (c) 2007 - 2014, Intel Corporation. All rights 
> reserved.\n\n");
> +  fprintf (stdout, "Copyright (c) 2007 - 2015, Intel Corporation. All rights 
> reserved.\n\n");
> 
>//
>// Details Option
>//
>fprintf (stdout, "Options:\n");
> @@ -182,23 +182,23 @@ Returns:
>  SEC, DXE_SAL_DRIVER, UEFI_DRIVER, 
> DXE_RUNTIME_DRIVER,\n\
>  DXE_SMM_DRIVER, SECURITY_CORE, 
> COMBINED_PEIM_DRIVER,\n\
>  PIC_PEIM, RELOCATABLE_PEIM, BS_DRIVER, RT_DRIVER,\n\
>  APPLICATION, SAL_RT_DRIVER to support all module 
> types\n\
>  It can only be used together with 
> --keepexceptiontable,\n\
> ---keepzeropending, -r, -o option.It is a action 
> option.\n\
> -If it is combined with other action options, the 
> later\n\
> -input action option will override the previous 
> one.\n");
> +--keepzeropending, --keepoptionalheader, -r, -o 
> option.\n\
> +It is a action option. If it is combined with other 
> action options,\n\
> +the later input action option will override the 
> previous one.\n");
>fprintf (stdout, "  -c, --acpiCreate Acpi table.\n\
>  It can't be combined with other action options\n\
>  except for -o, -r option. It is a action option.\n\
>  If it is combined with other action options, the 
> later\n\
>  input action option will override the previous 
> one.\n");
>fprintf (stdout, "  -t, --terse   Create Te Image.\n\
>  It can only be used together with 
> --keepexceptiontable,\n\
> ---keepzeropending, -r, -o option.It is a action 
> option.\n\
> -If it is combined with other action options, the 
> later\n\
> -input action option will override the previous 
> one.\n");
> +--keepzeropending, --keepoptionalheader, -r, -o 
> option.\n\
> +It is a action option. If it is combined with other 
> action options,\n\
> +the later input action option will override the 
> previous one.\n");
>fprintf (stdout, "  -u, --dumpDump TeImage Header.\n\
>  It can't be combined with other action options\n\
>  except for -o, -r option. It is a action option.\n\
>  If it is combined with other action options, the 
> later\n\
>  input action option will override the previous 
> one.\n");
> @@ -244,10 +244,13 @@ Returns:
>fprintf (stdout, "  -p NUM, --pad NUM NUM is one HEX or DEC format 
> padding value.\n\
>  This option is only used together with -j 
> option.\n");
>fprintf (stdout, "  --keepexceptiontable  Don't clear exception table.\n\
>  This option can be used together with -e or -t.\n\
>  It doesn't work for other options.\n");
> +  fprintf (stdout, "  --keepoptionalheader  Don't zero PE/COFF 

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Laszlo Ersek]

On 11/10/15 11:43, Leif Lindholm wrote:
> On Tue, Nov 10, 2015 at 11:28:10AM +0100, Laszlo Ersek wrote:
>> On 11/10/15 11:20, Conen, Johannes wrote:
>>> Hmm, you're right. is it briefly mentioned in the "ShellPkg
>>> Notes.txt" - I must admit, I only took a look at the
>>> "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major changes
>>> to mentioned there (and well, they were, like the moving of the
>>> library files). So this non-backwards-compatibility from UDK2015 to
>>> UDK2014 regarding network-related stuff is intended?
>>
>> I'll have to let Jiaxin answer this question; I'm not a participant in
>> UDK feature planning. And, I have no idea how UDK releases account for
>> compatibility in general.
>>
>> (My *guess* is that UDK2015 generally targets (or moved towards) UEFI
>> 2.5, and Ip4Config (version 1) is apparently deprecated in UEFI 2.5.)
> 
> The actual wording from the specification is:
> ---
> The EFI_IP4_CONFIG_PROTOCOL has been replaced with the new
> EFI_IP4_CONFIG2_PROTOCOL.
> • All new designs based on this specification should exclusively use
>   EFI_IP4_CONFIG2_PROTOCOL .
> • The EFI_IP4_CONFIG_PROTOCOL will be removed in the next revision of
>   this specification.
> ---
> 
> Clearly this creates a compatibility breakage at some point.
> 
> Is this something we consider "not a problem", or should the shell
> implement (providing a reference for how to implement) fallback to
> EFI_IP4_CONFIG_PROTOCOL if EFI_IP4_CONFIG2_PROTOCOL is not available?

Whether the shell in edk2 should or should not provide fallback code for
EFI_IP4_CONFIG_PROTOCOL is for Intel to answer :), but I think I can ask
one more question as to "how".

Namely, if one adds (or keeps) the Ip4Config fallback code to (in) the
shell in edk2, how does that compat feature get tested, staying within
the tree? It would require keeping the Ip4Config protocol implementation
around just for the sake of testing the fallback.

I don't think that's a good idea.

Instead, any dependencies on specific versions of the UEFI spec should
be spelled out loud and clear. (I believe I've read such requirements
presented by Windows, on MSDN.) Mapping each UDK release to a UEFI spec
version would be a bonus.

Thanks
Laszlo

> 
> Regards,
> 
> Leif
> 
>> Thanks
>> Laszlo
>>
>>>
>>> Greetings
>>> Johannes
>>>
>>> -Ursprüngliche Nachricht-
>>> Von: Laszlo Ersek [mailto:ler...@redhat.com] 
>>> Gesendet: Dienstag, 10. November 2015 11:06
>>> An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org
>>> Cc: Leif Lindholm (Linaro address)
>>> Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
>>>
>>> On 11/10/15 10:49, Conen, Johannes wrote:
 Hi there,

 I made my tests with the binary shell from ShellBinPkg from UDK2014, 
 from UDK2015, the current master and a few commits in between and 
 rebuilt the shell from ShellPkg for UDK2014, UDK2015, the current 
 master and a few commits in between UDK2014 and UDK2015.

 It worked fine with r17868 and didn't work anymore with r17869, so it 
 has to be that commit (I of course rebuilt the shell from ShellPkg).
 If I put both shells on a USB-stick and switch between them on the 
 fly, it works in the one built from r17868 and doesn't work in the one 
 built from r17869. Regarding ShellBinPkg: the last version that worked 
 is r17619 (which is quite logical since the version after that, 
 r18187, is built from ShellPkg r18186, which didn't work for me 
 anymore).

 I'm not working on OVMF, but on real hardware (X64) - don't know 
 exactly with which version the UEFI firmware was written, but I assume 
 it's UDK2014. I found nothing in the release notes that would break 
 backwards compatibility to firmware versions built with older EDKII 
 versions in this regard.
>>>
>>> Okay, that seems to explain it. The platform firmware on your physical 
>>> machine provides Ip4Config (version 1) only, but the shell built from 
>>> recent edk2 (and probably the binary shipped in UDK2015) requires 
>>> Ip4Config2.
>>>
>>> Hm... I have not been a UDK user, but now I downloaded "UDK2015.Notes.zip", 
>>> and in "ShellPkg Notes.txt", it says under "NEW FEATURES AND CHANGES", 
>>> point 15:
>>>
>>>   Change "ping" and "ifconfig" code to consume Ip4Config2 protocol.
>>>
>>> So I think this has been (technically) documented in the UDK2015 release. 
>>> Perhaps the lack of compatibility with UDK2014 should have been emphasized.
>>>
>>> (But, I'm just a curious bystander in this discussion anwyay...)
>>>
>>> Thanks
>>> Laszlo
>>>

 With best regards,
 Johannes Conen

 Siemens AG
 Process Industries and Drives Division Process Automation 
 Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. 
 50
 76187 Karlsruhe, Germany
 mailto:johannes.co...@siemens.com


 -Ursprüngliche Nachricht-
 Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] 

[edk2] [Patch] [Patch V3] MdeModulePkg DxeFileExplorerProtocol: Create wrapper file explorer library.

[Eric Dong]

This library wrapper explorer protocol and produce the file explorer library.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 .../DxeFileExplorerProtocol.c  |  88 +
 .../DxeFileExplorerProtocol.inf|  41 ++
 .../DxeFileExplorerProtocol.uni| Bin 0 -> 1950 bytes
 3 files changed, 129 insertions(+)
 create mode 100644 
MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.c
 create mode 100644 
MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.inf
 create mode 100644 
MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.uni

diff --git 
a/MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.c 
b/MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.c
new file mode 100644
index 000..1c22248
--- /dev/null
+++ b/MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.c
@@ -0,0 +1,88 @@
+/** @file
+  Instance of file explorer Library based on gEfiFileExplorerProtocolGuid.
+
+  Implement the file explorer library instance by wrap the interface 
+  provided in the file explorer protocol. This protocol is defined as the 
internal
+  protocol related to this implementation, not in the public spec. So, this 
+  library instance is only for this code base.
+
+Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+#include 
+
+#include 
+#include 
+
+EFI_FILE_EXPLORER_PROTOCOL *mProtocol = NULL;
+
+/**
+  The constructor function caches the pointer to file explorer protocol.
+  
+  The constructor function locates Print2 protocol from protocol database.
+  It will ASSERT() if that operation fails and it will always return 
EFI_SUCCESS. 
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+  
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+FileExplorerConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS   Status;
+
+  Status = SystemTable->BootServices->LocateProtocol (
+,
+NULL,
+(VOID**) 
+);
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (mProtocol != NULL);
+
+  return Status;
+}
+
+/**
+  Choose a file in the specified directory. 
+
+  If user input NULL for the RootDirectory, will choose file in the system.
+
+  If user input *File != NULL, function will return the allocate device path
+  info for the choosed file, caller has to free the memory after use it.
+
+  @param  RootDirectoryPointer to the root directory.
+  @param  FileType The file type need to choose.
+  @param  ChooseHandlerFunction pointer to the extra task need to do
+   after choose one file.
+  @param  File Return the device path for the last time chosed 
file.
+
+  @retval EFI_SUCESS Choose file success.
+  @retval EFI_INVALID_PARAMETER  Both ChooseHandler and return device path are 
NULL
+ One of them must not NULL.
+  @retval Other errors   Choose file failed.
+**/
+EFI_STATUS
+EFIAPI
+ChooseFile (
+  IN  EFI_DEVICE_PATH_PROTOCOL  *RootDirectory,
+  IN  CHAR16*FileType,  OPTIONAL
+  IN  CHOOSE_HANDLERChooseHandler,  OPTIONAL
+  OUT EFI_DEVICE_PATH_PROTOCOL  **File  OPTIONAL
+  )
+{
+  return mProtocol->ChooseFile (RootDirectory, FileType, ChooseHandler, File);
+}
+
diff --git 
a/MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.inf 
b/MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.inf
new file mode 100644
index 000..a9b04c4
--- /dev/null
+++ b/MdeModulePkg/Library/DxeFileExplorerProtocol/DxeFileExplorerProtocol.inf
@@ -0,0 +1,41 @@
+## @file
+#  Library instance that implements File explorer Library class based on 
protocol gEfiFileExplorerProtocolGuid.
+#
+#  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  

Re: [edk2] [Patch V3 2/2] MdeModulePkg FileExplorerDxe: Create file explorer Protocol.

[Dong, Eric]

Yes, will update when check in the code.

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Wednesday, November 11, 2015 1:41 PM
To: Dong, Eric
Cc: edk2-devel@lists.01.org; cecil.sh...@hpe.com; samer.el-haj-mahm...@hpe.com; 
Gao, Liming
Subject: Re: [edk2] [Patch V3 2/2] MdeModulePkg FileExplorerDxe: Create file 
explorer Protocol.


> On Nov 10, 2015, at 9:34 PM, Eric Dong  wrote:
> 
> This driver produces file explorer protocol layered on top of the 
> FileExplorerLib.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eric Dong 
> ---
> MdeModulePkg/Include/Protocol/FileExplorer.h   |  75 +
> .../Library/FileExplorerLib/FileExplorerLib.inf|   3 +-
> MdeModulePkg/MdeModulePkg.dec  |   3 +
> MdeModulePkg/MdeModulePkg.dsc  |   2 +
> .../Universal/FileExplorerDxe/FileExplorerDxe.c|  58 
> .../Universal/FileExplorerDxe/FileExplorerDxe.inf  |  53 
> +++ .../Universal/FileExplorerDxe/FileExplorerDxe.uni  | Bin 0 -> 
> 2038 bytes
> .../FileExplorerDxe/FileExplorerDxeExtra.uni   | Bin 0 -> 1362 bytes
> 8 files changed, 193 insertions(+), 1 deletion(-) create mode 100644 
> MdeModulePkg/Include/Protocol/FileExplorer.h
> create mode 100644 
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.c
> create mode 100644 
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf
> create mode 100644 
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.uni
> create mode 100644 
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxeExtra.uni
> 
> diff --git a/MdeModulePkg/Include/Protocol/FileExplorer.h 
> b/MdeModulePkg/Include/Protocol/FileExplorer.h
> new file mode 100644
> index 000..7f6cbd9
> --- /dev/null
> +++ b/MdeModulePkg/Include/Protocol/FileExplorer.h
> @@ -0,0 +1,75 @@
> +/** @file
> +
> +  This file explorer protocol defines defines a set of interfaces for  
> + how to do file explorer.
> +
> +Copyright (c) 2006 - 2010, Intel Corporation. All rights 
> +reserved.

Should this be 2015?

Thanks,

Andrew Fish

> +This program and the accompanying materials are licensed and made 
> +available under the terms and conditions of the BSD License that accompanies 
> this distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.  
>   
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>  
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __FILE_EXPLORER_H__
> +#define __FILE_EXPLORER_H__
> +
> +#define EFI_FILE_EXPLORER_PROTOCOL_GUID  \
> +  { 0x2C03C536, 0x4594, 0x4515, { 0x9E, 0x7A, 0xD3, 0xD2, 0x04, 0xFE, 
> +0x13, 0x63 } }
> +
> +//
> +// Forward reference for pure ANSI compatability // typedef struct 
> +_EFI_FILE_EXPLORER_PROTOCOL  EFI_FILE_EXPLORER_PROTOCOL;
> +
> +/**
> +  Prototype for the next process after user chosed one file.
> +
> +  @param[in] FilePath The device path of the find file.
> +
> +  @retvalTRUE Need exit file explorer after do the extra task.
> +  @retvalFALSENot need to exit file explorer after do the extra 
> task.
> +
> +**/
> +typedef
> +BOOLEAN
> +(EFIAPI *CHOOSE_HANDLER)(
> +  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath
> +  );
> +
> +/**
> +  Choose a file in the specified directory. 
> +
> +  If user input NULL for the RootDirectory, will choose file in the system.
> +
> +  If user input *File != NULL, function will return the allocate 
> + device path  info for the choosed file, caller has to free the memory after 
> use it.
> +
> +  @param  RootDirectoryPointer to the root directory.
> +  @param  FileType The file type need to choose.
> +  @param  ChooseHandlerFunction pointer to the extra task need to do
> +   after choose one file.
> +  @param  File Return the device path for the last time chosed 
> file.
> +
> +  @retval EFI_SUCESS   Choose the file success.
> +  @retval Other errors Choose the file failed.
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI   *CHOOSE_FILE) (
> +  IN  EFI_DEVICE_PATH_PROTOCOL  *RootDirectory,
> +  IN  CHAR16*FileType,  OPTIONAL
> +  IN  CHOOSE_HANDLERChooseHandler,  OPTIONAL
> +  OUT EFI_DEVICE_PATH_PROTOCOL  **File  OPTIONAL
> +  );
> +
> +struct _EFI_FILE_EXPLORER_PROTOCOL {
> +  CHOOSE_FILE  ChooseFile;
> +};
> +
> +extern EFI_GUID gEfiFileExplorerProtocolGuid;
> +
> +#endif
> diff --git a/MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf 
> b/MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> index c52a220..a2be614 100644
> --- a/MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +++ 

Re: [edk2] Filesystem issues since "OvmfPkg: enable SATA controller"

[Gary Ching-Pang Lin]

On Tue, Nov 10, 2015 at 04:55:16PM +, Mark Rutland wrote:
> I've been trying to test an EFI application on x86_64 using Ubuntu 14.04's 
> QEMU
> 2.0.0. I have a directory 'foo' containing the application, and I get QEMU to
> create a virtual FAT device:
> 
> $ qemu-system-x86_64 -nographic \
>   -bios src/edk2/Build/OvmfX64/RELEASE_GCC48/FV/OVMF.fd \
>   -hda fat:foo
> 
> However, I'm unable to access the root filesystem:
> 
> UEFI Interactive Shell v2.1
> EDK II
> UEFI v2.50 (EDK II, 0x0001)
> Mapping table
>   FS0: Alias(s):HD7a1:;BLK3:
>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
>  BLK2: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
>  BLK4: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
>  BLK0: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
>  BLK1: Alias(s):
>   PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
> Shell> fs0:
> FS0:\> dir
> ls: File Not Found - 'FS0:\'
> 
> With git, I bisected this down to the commit "OvmfPkg: enable SATA 
> controller".
> 
> Any ideas as to what the problem could be?
> 
I also encountered the error before, and it only happened when I used '-bios'
to specify the OVMF image. It never happened while using 'pflash'.

Cheers,

Gary Lin

> I don't have a newer qemu-system-x86_64 lying around, so I haven't been able 
> to
> test with that.
> 
> Thanks,
> Mark.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Kinney, Michael D]

Heyi,

I think it should be ok to always calculate it.  

I think the only time the #define default rate should be used is if the 
BaudRate is 0.

Similar to setting the SerialInTimeOut, you can check in the periodic timer 
event notification function to see if the Baud Rate, Data Bits, Stop Bits, or 
Receive FIFO depth have changed, and if they have, compute and set the new 
periodic timer rate for the event.

Mike

>-Original Message-
>From: Heyi Guo [mailto:heyi@linaro.org]
>Sent: Tuesday, November 10, 2015 7:07 PM
>To: Kinney, Michael D; edk2-devel@lists.01.org
>Cc: Tian, Feng
>Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval
>
>
>
>On 11/11/2015 10:06 AM, Kinney, Michael D wrote:
>> Heyi,
>>
>> Yes.  I think computing the poll rate is a good addition to the TerminalDxe 
>> module.
>>
>> If any of the information required to compute the rate is not available, 
>> then the #define default rate can be used.
>>
>> Do you want to prepare a patch with this enhancement?
>Sure, it's my pleasure.
>
>Do you think it is necessary to still use the default rate if the
>calculated result is *larger* than it, to make it back compatible? It is
>possible some old code has wrong FIFO depth stated.
>
>Thanks.
>>
>> Thanks,
>>
>> Mike
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Tuesday, November 10, 2015 5:27 PM
>>> To: Kinney, Michael D; edk2-devel@lists.01.org
>>> Cc: Tian, Feng
>>> Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling 
>>> interval
>>>
>>>
>>>
>>> On 11/11/2015 04:34 AM, Kinney, Michael D wrote:
 Heyi,

 All timers in UEFI are the minimum time.  So the only way to guarantee 
 that a FIFO will never overflow is to use flow control.

 Setting the poll rate based on FIFO depth and baud rate, data bits, and 
 stop bits with flow control disabled means it should work
>>> most of the time, but another UEFI event notification function running at 
>>> the same TPL or higher can block the Terminal event
>>> notification function and input characters could be lost.
 I agree that the current 20ms periodic timer can overflow depending in the 
 FIFO depth and the baud rate, and that we could
>reduce
>>> data loss in flow control disabled configurations if this periodic rate was 
>>> computed instead of using a hard coded #define.
>Another
>>> constraint is the system timer interrupt rate provided by the Timer 
>>> Architectural Protocol.  A request for a periodic timer event
>that is
>>> faster than the current system timer rate will call the event notification 
>>> function at the rate of the system timer.  So even if you
>>> reduce the periodic timer event time to a computed value, the time between 
>>> event notification function calls may not change.
>>> Totally agree. However normally we will have platform configuration
>>> interface for interrupt rate of system timer, like PCD or even driver
>>> override, but I can't find any interface to configure polling rate of
>>> the terminal driver, and I really don't like to override the whole
>>> terminal driver when I only want to change the polling rate :). That's
>>> the reason why I want to make a patch for terminal driver.
>>>
 In order to prevent overflows, I think the timer rate in 100ns units could 
 be computed as follows:

Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000

 --
BaudRate

 For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 
 115200 would be:

16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277

 Which is 0.00153 seconds or 1.53 ms.
>>> Can I consider this as your agreement on calculating polling rate in
>>> terminal driver?
>>>
>>> After all, really appreciate your detailed answer on this issue.
>>>
>>> Heyi
>>>
 Best regards,

 Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Heyi Guo
> Sent: Monday, November 09, 2015 10:23 PM
> To: Kinney, Michael D; edk2-devel@lists.01.org
> Cc: Tian, Feng
> Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling 
> interval
>
> Hi Michael,
>
> Yes we can see terminal input truncated when we use copy-paste to input
> characters.
>
> I don't quite understand the relationship between SerialInTimeOut and
> timer event poll rate; and I don't see the periodic timer rate is to be
> updated later; we are using 0.02ms period all over, aren't we?
>
> If the timer event polls the serial device at a fixed rate, how can we
> guarantee the FIFO of the device will not overflow during a burst input?
>
> Thanks.
>
> On 11/10/2015 01:25 AM, Kinney, Michael D 

[edk2] [Patch 1/2] MdeModulePkg FileExplorerLib: Create file explorer library.

[Eric Dong]

This library support select one file from the specified directory or from 
system root directory.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Include/Library/FileExplorerLib.h |   60 +
 .../Library/FileExplorerLib/FileExplorer.c | 1504 
 .../Library/FileExplorerLib/FileExplorer.h |  239 
 .../Library/FileExplorerLib/FileExplorerLib.inf|   59 +
 .../Library/FileExplorerLib/FileExplorerString.uni |  Bin 0 -> 1852 bytes
 .../Library/FileExplorerLib/FileExplorerVfr.vfr|   32 +
 MdeModulePkg/Library/FileExplorerLib/FormGuid.h|   27 +
 MdeModulePkg/MdeModulePkg.dec  |4 +
 8 files changed, 1925 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/FileExplorerLib.h
 create mode 100644 MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
 create mode 100644 MdeModulePkg/Library/FileExplorerLib/FileExplorer.h
 create mode 100644 MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
 create mode 100644 MdeModulePkg/Library/FileExplorerLib/FileExplorerString.uni
 create mode 100644 MdeModulePkg/Library/FileExplorerLib/FileExplorerVfr.vfr
 create mode 100644 MdeModulePkg/Library/FileExplorerLib/FormGuid.h

diff --git a/MdeModulePkg/Include/Library/FileExplorerLib.h 
b/MdeModulePkg/Include/Library/FileExplorerLib.h
new file mode 100644
index 000..fbe1fc2
--- /dev/null
+++ b/MdeModulePkg/Include/Library/FileExplorerLib.h
@@ -0,0 +1,60 @@
+/** @file
+
+  This library class defines a set of interfaces for how to do file explorer.
+
+Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under 
+the terms and conditions of the BSD License that accompanies this 
distribution.  
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.

+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
   
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __FILE_EXPLORER_LIB_H__
+#define __FILE_EXPLORER_LIB_H__
+
+/**
+  Prototype for the next process after user chosed one file.
+
+  @param[in] FilePath The device path of the find file.
+
+  @retvalTRUE Need exit file explorer after do the extra task.
+  @retvalFALSENot need to exit file explorer after do the extra 
task.
+
+**/
+typedef
+BOOLEAN
+(EFIAPI *CHOOSE_HANDLER)(
+  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath
+  );
+
+/**
+  Choose a file in the specified directory. 
+
+  If user input NULL for the RootDirectory, will choose file in the system.
+
+  If user input *File != NULL, function will return the allocate device path
+  info for the choosed file, caller has to free the memory after use it.
+
+  @param  RootDirectoryPointer to the root directory.
+  @param  FileType The file type need to choose.
+  @param  ChooseHandlerFunction pointer to the extra task need to do
+   after choose one file.
+  @param  File Return the device path for the last time chosed 
file.
+
+  @retval EFI_SUCESS   Choose the file success.
+  @retval Other errors Choose the file failed.
+**/
+EFI_STATUS
+EFIAPI
+ChooseFile (
+  IN  EFI_DEVICE_PATH_PROTOCOL  *RootDirectory,
+  IN  CHAR16*FileType,  OPTIONAL
+  IN  CHOOSE_HANDLERChooseHandler,  OPTIONAL
+  OUT EFI_DEVICE_PATH_PROTOCOL  **File  OPTIONAL
+  );
+
+#endif
diff --git a/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c 
b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
new file mode 100644
index 000..4e25efc
--- /dev/null
+++ b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
@@ -0,0 +1,1504 @@
+/** @file
+  File explorer related functions.
+
+  Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.
+  This software and associated documentation (if any) is furnished
+  under a license and may only be used or copied in accordance
+  with the terms of the license. Except as permitted by such
+  license, no part of this software or documentation may be
+  reproduced, stored in a retrieval system, or transmitted in any
+  form or by any means without the express written consent of
+  Intel Corporation.
+
+**/
+
+#include "FileExplorer.h"
+
+EFI_GUID FileExplorerGuid   = EFI_FILE_EXPLORE_FORMSET_GUID;
+
+///
+/// File system selection menu
+///
+MENU_OPTION  mFsOptionMenu = {
+  MENU_OPTION_SIGNATURE,
+  {NULL},
+  0,
+  FALSE
+};
+
+FILE_EXPLORER_CALLBACK_DATA  gFileExplorerPrivate = {
+  FILE_EXPLORER_CALLBACK_DATA_SIGNATURE,
+  NULL,
+  NULL,
+  {
+LibExtractConfig,
+LibRouteConfig,
+LibCallback
+  },
+  NULL,
+  ,
+  0
+};
+
+HII_VENDOR_DEVICE_PATH  *gHiiVendorDevicePath;
+
+HII_VENDOR_DEVICE_PATH  FeHiiVendorDevicePath = {
+  {

[edk2] [Patch V3 2/2] MdeModulePkg FileExplorerDxe: Create file explorer Protocol.

[Eric Dong]

This driver produces file explorer protocol layered on top of the 
FileExplorerLib.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Include/Protocol/FileExplorer.h   |  75 +
 .../Library/FileExplorerLib/FileExplorerLib.inf|   3 +-
 MdeModulePkg/MdeModulePkg.dec  |   3 +
 MdeModulePkg/MdeModulePkg.dsc  |   2 +
 .../Universal/FileExplorerDxe/FileExplorerDxe.c|  58 
 .../Universal/FileExplorerDxe/FileExplorerDxe.inf  |  53 +++
 .../Universal/FileExplorerDxe/FileExplorerDxe.uni  | Bin 0 -> 2038 bytes
 .../FileExplorerDxe/FileExplorerDxeExtra.uni   | Bin 0 -> 1362 bytes
 8 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 MdeModulePkg/Include/Protocol/FileExplorer.h
 create mode 100644 MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.c
 create mode 100644 MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf
 create mode 100644 MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.uni
 create mode 100644 
MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxeExtra.uni

diff --git a/MdeModulePkg/Include/Protocol/FileExplorer.h 
b/MdeModulePkg/Include/Protocol/FileExplorer.h
new file mode 100644
index 000..7f6cbd9
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/FileExplorer.h
@@ -0,0 +1,75 @@
+/** @file
+
+  This file explorer protocol defines defines a set of interfaces for 
+  how to do file explorer.
+
+Copyright (c) 2006 - 2010, 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 that accompanies this 
distribution.  
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.

+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
   
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __FILE_EXPLORER_H__
+#define __FILE_EXPLORER_H__
+
+#define EFI_FILE_EXPLORER_PROTOCOL_GUID  \
+  { 0x2C03C536, 0x4594, 0x4515, { 0x9E, 0x7A, 0xD3, 0xD2, 0x04, 0xFE, 0x13, 
0x63 } }
+
+//
+// Forward reference for pure ANSI compatability
+//
+typedef struct _EFI_FILE_EXPLORER_PROTOCOL  EFI_FILE_EXPLORER_PROTOCOL;
+
+/**
+  Prototype for the next process after user chosed one file.
+
+  @param[in] FilePath The device path of the find file.
+
+  @retvalTRUE Need exit file explorer after do the extra task.
+  @retvalFALSENot need to exit file explorer after do the extra 
task.
+
+**/
+typedef
+BOOLEAN
+(EFIAPI *CHOOSE_HANDLER)(
+  IN EFI_DEVICE_PATH_PROTOCOL  *FilePath
+  );
+
+/**
+  Choose a file in the specified directory. 
+
+  If user input NULL for the RootDirectory, will choose file in the system.
+
+  If user input *File != NULL, function will return the allocate device path
+  info for the choosed file, caller has to free the memory after use it.
+
+  @param  RootDirectoryPointer to the root directory.
+  @param  FileType The file type need to choose.
+  @param  ChooseHandlerFunction pointer to the extra task need to do
+   after choose one file.
+  @param  File Return the device path for the last time chosed 
file.
+
+  @retval EFI_SUCESS   Choose the file success.
+  @retval Other errors Choose the file failed.
+**/
+typedef
+EFI_STATUS
+(EFIAPI   *CHOOSE_FILE) (
+  IN  EFI_DEVICE_PATH_PROTOCOL  *RootDirectory,
+  IN  CHAR16*FileType,  OPTIONAL
+  IN  CHOOSE_HANDLERChooseHandler,  OPTIONAL
+  OUT EFI_DEVICE_PATH_PROTOCOL  **File  OPTIONAL
+  );
+
+struct _EFI_FILE_EXPLORER_PROTOCOL {
+  CHOOSE_FILE  ChooseFile;
+};
+
+extern EFI_GUID gEfiFileExplorerProtocolGuid;
+
+#endif
diff --git a/MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf 
b/MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
index c52a220..a2be614 100644
--- a/MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
+++ b/MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
@@ -44,11 +44,12 @@
   BaseLib
   MemoryAllocationLib
   UefiBootServicesTableLib
   BaseMemoryLib
   DebugLib
-  
+  HiiLib
+
 [Guids]
   gEfiFileSystemVolumeLabelInfoIdGuid   ## CONSUMES ## GUID (Indicate 
the information type is volume)
   gEfiIfrTianoGuid  ## CONSUMES ## GUID (Extended 
IFR Guid Opcode)
  
 [Protocols]
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index d45e49a..0f53608 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -451,10 +451,13 @@
   gEdkiiSmmLegacyBootProtocolGuid = { 0x85a8ab57, 0x644, 0x4110, { 0x85, 0xf, 
0x98, 0x13, 0x22, 0x4, 0x70, 0x70 } }
 
   ## 

Re: [edk2] MdePkg: Enable Xcode build of BaseLib without

[Gao, Liming]

Jordan:
  I find BaseTools has one issue to support BUILDRULEORDER. It will generate 
two commands in Makefile to compile Thunk16.S and Thunk16.nasm both. So, Andrew 
will report the build failure if nasm is not installed. I will fix BaseTools 
issue first. 

  Now, nasm is restricted to GCC tool chain, because nasm compiler has one 
issue to generate Debug Format. Do you know the latest status for it?

Thanks
Liming
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, November 11, 2015 12:25 PM
> To: Justen, Jordan L
> Cc: Gao, Liming; Kinney, Michael D; edk2-devel
> Subject: Re: [edk2] MdePkg: Enable Xcode build of BaseLib without
> 
> 
> > On Nov 10, 2015, at 8:06 PM, Jordan Justen  
> > wrote:
> >
> > On 2015-11-10 19:18:01, Andrew Fish wrote:
> >>  On Nov 10, 2015, at 7:11 PM, Jordan Justen 
> >>  wrote:
> >>  Liming, Andrew,
> >>
> >>  Wasn't BUILDRULEORDER supposed to help with this?
> >>
> >> I asked about that too? I was testing with XCODE5, so the BUILDRULEORDER
> >> should have been S s nasm?
> >>> git grep BUILDRULEORDER
> >> BaseTools/Conf/tools_def.template:6367:*_XCODE32_*_*_BUILDRULEORDER= S
> >> s nasm
> >> BaseTools/Conf/tools_def.template:6477:*_XCLANG_*_*_BUILDRULEORDER= S
> >> s nasm
> >> BaseTools/Conf/tools_def.template:6541:*_XCODE5_*_*_BUILDRULEORDER= S
> >> s nasm
> >> BaseTools/Conf/tools_def.template:6850:*_*_*_*_BUILDRULEORDER = nasm asm
> >> Asm ASM S s
> >> BaseTools/Source/Python/AutoGen/AutoGen.py:2093:if
> >> Attr == TAB_TOD_DEFINES_BUILDRULEORDER:
> >> BaseTools/Source/Python/AutoGen/AutoGen.py:2112:if
> >> Attr == TAB_TOD_DEFINES_BUILDRULEORDER:
> >> BaseTools/Source/Python/Common/DataType.py:435:TAB_TOD_DEFINES_BUILDRULEORDER
> >> = 'BUILDRULEORDER'
> >> I realize now that my previous test may have been flawed since I had NASM
> >> installed.
> >
> > Hmm, maybe we could have added:
> >
> > Ia32/Thunk16.S
> >
> 
> I think it would be `| GCC` as all the other .S files have that.
> 
>   X64/Thunk16.nasm | GCC
>   X64/Thunk16.S | GCC
> 
> As far as I can remember you don't need the `| GCC` with a .S, but BaseLib 
> seems to use them, maybe for comments.
> 
> But that brings up the other question is nasm restricted to GCC in the 
> BaseLib? It is scoped via `| GCC`.
> 
> Thanks,
> 
> Andrew Fish
> 
> > instead of
> >
> > Ia32/Thunk16.S | XCODE
> >
> > Perhaps, that was why BUILDRULEORDER didn't work?
> >
> > -Jordan
> >
> >>   Thanks,
> >>   Andrew Fish
> >>
> >> -Jordan
> >>
> >> On 2015-11-10 18:30:39, Gao, Liming wrote:
> >>
> >>   This patch is committed at r18766.
> >>
> >>   Thanks
> >>   Liming
> >>   From: af...@apple.com [mailto:af...@apple.com]
> >>   Sent: Tuesday, November 10, 2015 11:31 PM
> >>   To: Gao, Liming
> >>   Cc: edk2-devel; Kinney, Michael D
> >>   Subject: Re: MdePkg: Enable Xcode build of BaseLib without
> >>
> >>   On Nov 10, 2015, at 12:22 AM, Gao, Liming
> >>   > wrote:
> >>
> >>   Reviewed-by: Liming Gao
> >>   >
> >>
> >>   Liming,
> >>
> >>   Can you commit the patch?
> >>
> >>   Thanks,
> >>
> >>   Andrew Fsih
> >>
> >> cat 0004-MdePkg-BaseLib-don-t-require-NASM-with-Xcode.patch
> >>
> >>   From 8f4666bc80d6d4844e73b3a221e50d587ef09cec Mon Sep 17 00:00:00 
> >> 2001
> >>   From: andrew fish >
> >>   Date: Mon, 9 Nov 2015 22:46:32 -0800
> >>   Subject: [PATCH 4/4] MdePkg: BaseLib don't require NASM with Xcode
> >>
> >>   Don't require NASM for simple edk2 Xcode projects.
> >>
> >>   Contributed-under: TianoCore Contribution Agreement 1.0
> >>   Signed-off-by: Andrew Fish >
> >>   Reviewed-by: Liming Gao
> >>   >
> >>   ---
> >>   MdePkg/Library/BaseLib/BaseLib.inf | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >>   diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
> >>   b/MdePkg/Library/BaseLib/BaseLib.inf
> >>   index 4cc86d7..e83a569 100644
> >>   --- a/MdePkg/Library/BaseLib/BaseLib.inf
> >>   +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> >>   @@ -257,6 +257,7 @@
> >>
> >> Ia32/GccInline.c | GCC
> >> Ia32/Thunk16.nasm | GCC
> >>   +  Ia32/Thunk16.S | XCODE
> >> Ia32/EnableDisableInterrupts.S | GCC
> >> Ia32/EnablePaging64.S | GCC
> >> Ia32/DisablePaging32.S | GCC
> >>   @@ -413,6 +414,7 @@
> >> X86DisablePaging32.c
> >> X64/GccInline.c | GCC
> >> X64/Thunk16.nasm | GCC
> >>   +  X64/Thunk16.S | XCODE
> >> X64/SwitchStack.S | GCC
> >> X64/SetJump.S | GCC
> >> X64/LongJump.S | GCC
> >>   --
> >>   2.3.2 (Apple 

Re: [edk2] [Patch V2 0/5] Create BootLogoLib to provide common interfaces for LOGO drawing

[Tian, Feng]

Series look good to me after responding Jordan's feedback

Viewed-by: Feng Tian 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Monday, November 09, 2015 13:24
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu
Subject: [edk2] [Patch V2 0/5] Create BootLogoLib to provide common interfaces 
for LOGO drawing

Ruiyu Ni (5):
  MdeModulePkg: Add EdkiiPlatformLogo protocol definition.
  MdeModulePkg: Add ImageDecoderLib to provide image decoding service.
  MdeModulePkg: Add BmpImageDecoderLib to provide BMP decoding
capability
  MdeModulePkg: Add BootLogoLib to provide interfaces about logo
display.
  Nt32Pkg: Use LogoLib for LOGO and progress bar drawing.

 MdeModulePkg/Include/Library/BootLogoLib.h |  82 ++
 MdeModulePkg/Include/Library/ImageDecoderLib.h |  76 ++
 MdeModulePkg/Include/Protocol/PlatformLogo.h   |  86 +++
 .../BmpImageDecoderLib/BmpImageDecoderLib.c| 272 +++
 .../BmpImageDecoderLib/BmpImageDecoderLib.inf  |  42 ++
 MdeModulePkg/Library/BootLogoLib/BootLogoLib.c | 584 +++
 MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf   |  59 ++
 .../Library/ImageDecoderLib/ImageDecoderLib.c  | 121 +++
 .../Library/ImageDecoderLib/ImageDecoderLib.inf|  42 ++
 MdeModulePkg/MdeModulePkg.dec  |  11 +
 MdeModulePkg/MdeModulePkg.dsc  |   4 +
 .../Library/PlatformBootManagerLib/MemoryTest.c| 833 +
 .../PlatformBootManagerLib/PlatformBootManager.c   |   6 +-
 .../PlatformBootManagerLib/PlatformBootManager.h   |   6 +-
 .../PlatformBootManagerLib.inf |   2 +-
 Nt32Pkg/Nt32Pkg.dsc|   7 +-
 16 files changed, 1393 insertions(+), 840 deletions(-)  create mode 100644 
MdeModulePkg/Include/Library/BootLogoLib.h
 create mode 100644 MdeModulePkg/Include/Library/ImageDecoderLib.h
 create mode 100644 MdeModulePkg/Include/Protocol/PlatformLogo.h
 create mode 100644 MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
 create mode 100644 
MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
 create mode 100644 MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
 create mode 100644 MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
 create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.c
 create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf

--
1.9.5.msysgit.1

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

Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.

[Tian, Feng]

RegularExpressionDxe change is ok for me.

Reviewed-by: Feng Tian 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Tuesday, November 10, 2015 23:33
To: Gao, Liming
Cc: edk2-devel; Tian, Feng
Subject: Re: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.


> On Nov 10, 2015, at 7:04 AM, Andrew Fish  wrote:
> 
> 
>> On Nov 10, 2015, at 12:06 AM, Gao, Liming  wrote:
>> 
>> Andrew:
>> The patch is missing.
>> 
> 
> Liming,
> 
> My sent mail shows these 3 patches attached?
> 0001-MdeModulePkg-PeiCore-Fix-Xcode-Wempty-body-warning.patch
> 0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
> 0003-MdeModulePkg-Variable-add-mising-VA_COPY.patch
> 
> I attached again here:
> 
> 

>cat 0002-MdeModulePkg-RegularExpressionDxe-Xcode-warnings-fix.patch
>From 7f82886d42a82d939760562ab3f992ae6a3a70b7 Mon Sep 17 00:00:00 2001
From: andrew fish 
Date: Mon, 9 Nov 2015 22:31:03 -0800
Subject: [PATCH 2/4] MdeModulePkg: RegularExpressionDxe Xcode warnings fixes

ErrorMessage generates a Wpointer-sign error, char * vs unsigned char * 
assigning structures with = generate memcpy link failures.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
---
 MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c  | 9 ++--- 
 MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c | 2 +-
 .../Universal/RegularExpressionDxe/RegularExpressionDxe.c| 4 ++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c
index 25b768b..7c9771f 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c
@@ -70,7 +70,10 @@ static void
 swap_node(Node* a, Node* b)
 {
   Node c;
-  c = *a; *a = *b; *b = c;
+  //c = *a; *a = *b; *b = c;
+  xmemcpy (, a, sizeof (Node));
+  xmemcpy (a, b, sizeof (Node));
+  xmemcpy (b, , sizeof (Node));
 
   if (NTYPE(a) == NT_STR) {
 StrNode* sn = NSTR(a);
@@ -4348,7 +4351,7 @@ clear_opt_map_info(OptMapInfo* map)  static void
 copy_opt_map_info(OptMapInfo* to, OptMapInfo* from)  {
-  *to = *from;
+  xmemcpy(to, from, sizeof(OptMapInfo));
 }
 
 static void
@@ -4463,7 +4466,7 @@ clear_node_opt_info(NodeOptInfo* opt)  static void
 copy_node_opt_info(NodeOptInfo* to, NodeOptInfo* from)  {
-  *to = *from;
+  xmemcpy(to, from, sizeof (NodeOptInfo));
 }
 
 static void
diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c
index 01ac2b3..38fceb4 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c
@@ -2211,7 +2211,7 @@ onig_reduce_nested_quantifier(Node* pnode, Node* cnode)
 
   switch(ReduceTypeTable[cnum][pnum]) {
   case RQ_DEL:
-*pnode = *cnode;
+xmemcpy (pnode, cnode, sizeof (Node));
 break;
   case RQ_A:
 p->target = c->target;
diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c 
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
index a3eebf7..453c1eb 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.c
@@ -120,7 +120,7 @@ OnigurumaMatch (
  );
 
   if (OnigResult != ONIG_NORMAL) {
-onig_error_code_to_str (ErrorMessage, OnigResult, );
+onig_error_code_to_str ((OnigUChar *)ErrorMessage, OnigResult, 
+ );
 DEBUG ((DEBUG_ERROR, "Regex compilation failed: %a\n", ErrorMessage));
 return EFI_DEVICE_ERROR;
   }
@@ -144,7 +144,7 @@ OnigurumaMatch (
   } else {
 *Result = FALSE;
 if (OnigResult != ONIG_MISMATCH) {
-  onig_error_code_to_str (ErrorMessage, OnigResult);
+  onig_error_code_to_str ((OnigUChar *)ErrorMessage, OnigResult);
   DEBUG ((DEBUG_ERROR, "Regex match failed: %a\n", ErrorMessage));
 }
   }
--
2.3.2 (Apple Git-55)


> 
> 
> Thanks,
> 
> Andrew Fish
> 
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Andrew Fish
>> Sent: Tuesday, November 10, 2015 3:18 PM
>> To: edk2-devel
>> Cc: Tian, Feng
>> Subject: [edk2] MdeModulePkg: Fix Xcode 6.3.2/clang compilation issues.
>> 
>> Please review the following patches as they are required to build with Xcode 
>> 6.3.2.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> 

Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

[Heyi Guo]

On 11/11/2015 10:06 AM, Kinney, Michael D wrote:

Heyi,

Yes.  I think computing the poll rate is a good addition to the TerminalDxe 
module.

If any of the information required to compute the rate is not available, then 
the #define default rate can be used.

Do you want to prepare a patch with this enhancement?

Sure, it's my pleasure.

Do you think it is necessary to still use the default rate if the 
calculated result is *larger* than it, to make it back compatible? It is 
possible some old code has wrong FIFO depth stated.


Thanks.


Thanks,

Mike


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Tuesday, November 10, 2015 5:27 PM
To: Kinney, Michael D; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval



On 11/11/2015 04:34 AM, Kinney, Michael D wrote:

Heyi,

All timers in UEFI are the minimum time.  So the only way to guarantee that a 
FIFO will never overflow is to use flow control.

Setting the poll rate based on FIFO depth and baud rate, data bits, and stop 
bits with flow control disabled means it should work

most of the time, but another UEFI event notification function running at the 
same TPL or higher can block the Terminal event
notification function and input characters could be lost.

I agree that the current 20ms periodic timer can overflow depending in the FIFO 
depth and the baud rate, and that we could reduce

data loss in flow control disabled configurations if this periodic rate was 
computed instead of using a hard coded #define.  Another
constraint is the system timer interrupt rate provided by the Timer 
Architectural Protocol.  A request for a periodic timer event that is
faster than the current system timer rate will call the event notification 
function at the rate of the system timer.  So even if you
reduce the periodic timer event time to a computed value, the time between 
event notification function calls may not change.
Totally agree. However normally we will have platform configuration
interface for interrupt rate of system timer, like PCD or even driver
override, but I can't find any interface to configure polling rate of
the terminal driver, and I really don't like to override the whole
terminal driver when I only want to change the polling rate :). That's
the reason why I want to make a patch for terminal driver.


In order to prevent overflows, I think the timer rate in 100ns units could be 
computed as follows:

Receive FIFO depth * (1 + DataBits + StopBits) * 10,000,000

--
BaudRate

For example, a 16 byte receive FIFO with 8 data bits and 1 stop bit at 115200 
would be:

16 * (1 + 8 + 1) * 10,000,000 / 115200 = 15277

Which is 0.00153 seconds or 1.53 ms.

Can I consider this as your agreement on calculating polling rate in
terminal driver?

After all, really appreciate your detailed answer on this issue.

Heyi


Best regards,

Mike


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Monday, November 09, 2015 10:23 PM
To: Kinney, Michael D; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: Re: [edk2] [RFC] Adaptively set serial terminal input polling interval

Hi Michael,

Yes we can see terminal input truncated when we use copy-paste to input
characters.

I don't quite understand the relationship between SerialInTimeOut and
timer event poll rate; and I don't see the periodic timer rate is to be
updated later; we are using 0.02ms period all over, aren't we?

If the timer event polls the serial device at a fixed rate, how can we
guarantee the FIFO of the device will not overflow during a burst input?

Thanks.

On 11/10/2015 01:25 AM, Kinney, Michael D wrote:

Heyi,

The function TerminalConInTimerHandler () computes a timeout based on the baud 
rate, data bits, and stop bits

 //
 // According to BAUD rate to calculate the timeout value.
 //
 SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 100 / 
(UINTN) Mode->BaudRate;

The #define is used to set the initial periodic timer rate before the rest of 
the information to compute a timeout is known.

Are you observing an issue?

Mike


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi
Guo
Sent: Monday, November 09, 2015 1:48 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: [edk2] [RFC] Adaptively set serial terminal input polling interval

Hi All,

In MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf, the
polling interval is fixed by macro:

#define KEYBOARD_TIMER_INTERVAL 20  // 0.02s

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

Re: [edk2] MdePkg: Enable Xcode build of BaseLib without

[Jordan Justen]

Liming, Andrew,

Wasn't BUILDRULEORDER supposed to help with this?

-Jordan

On 2015-11-10 18:30:39, Gao, Liming wrote:
> This patch is committed at r18766.
> 
> Thanks
> Liming
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, November 10, 2015 11:31 PM
> To: Gao, Liming
> Cc: edk2-devel; Kinney, Michael D
> Subject: Re: MdePkg: Enable Xcode build of BaseLib without
> 
> 
> On Nov 10, 2015, at 12:22 AM, Gao, Liming 
> > wrote:
> 
> Reviewed-by: Liming Gao >
> 
> Liming,
> 
> Can you commit the patch?
> 
> Thanks,
> 
> Andrew Fsih
> 
> >cat 0004-MdePkg-BaseLib-don-t-require-NASM-with-Xcode.patch
> From 8f4666bc80d6d4844e73b3a221e50d587ef09cec Mon Sep 17 00:00:00 2001
> From: andrew fish >
> Date: Mon, 9 Nov 2015 22:46:32 -0800
> Subject: [PATCH 4/4] MdePkg: BaseLib don't require NASM with Xcode
> 
> Don't require NASM for simple edk2 Xcode projects.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Andrew Fish >
> Reviewed-by: Liming Gao >
> ---
>  MdePkg/Library/BaseLib/BaseLib.inf | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 4cc86d7..e83a569 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -257,6 +257,7 @@
> 
>Ia32/GccInline.c | GCC
>Ia32/Thunk16.nasm | GCC
> +  Ia32/Thunk16.S | XCODE
>Ia32/EnableDisableInterrupts.S | GCC
>Ia32/EnablePaging64.S | GCC
>Ia32/DisablePaging32.S | GCC
> @@ -413,6 +414,7 @@
>X86DisablePaging32.c
>X64/GccInline.c | GCC
>X64/Thunk16.nasm | GCC
> +  X64/Thunk16.S | XCODE
>X64/SwitchStack.S | GCC
>X64/SetJump.S | GCC
>X64/LongJump.S | GCC
> --
> 2.3.2 (Apple Git-55)
> 
> ___
> 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] MdePkg: Enable Xcode build of BaseLib without

[Andrew Fish]

> On Nov 10, 2015, at 7:11 PM, Jordan Justen  wrote:
> 
> Liming, Andrew,
> 
> Wasn't BUILDRULEORDER supposed to help with this?
> 

I asked about that too? I was testing with XCODE5, so the BUILDRULEORDER  
should have been S s nasm?

>git grep BUILDRULEORDER
BaseTools/Conf/tools_def.template:6367:*_XCODE32_*_*_BUILDRULEORDER= S s 
nasm
BaseTools/Conf/tools_def.template:6477:*_XCLANG_*_*_BUILDRULEORDER= S s nasm
BaseTools/Conf/tools_def.template:6541:*_XCODE5_*_*_BUILDRULEORDER= S s nasm
BaseTools/Conf/tools_def.template:6850:*_*_*_*_BUILDRULEORDER = nasm asm Asm 
ASM S s
BaseTools/Source/Python/AutoGen/AutoGen.py:2093:if Attr == 
TAB_TOD_DEFINES_BUILDRULEORDER:
BaseTools/Source/Python/AutoGen/AutoGen.py:2112:if Attr == 
TAB_TOD_DEFINES_BUILDRULEORDER:
BaseTools/Source/Python/Common/DataType.py:435:TAB_TOD_DEFINES_BUILDRULEORDER = 
'BUILDRULEORDER'

I realize now that my previous test may have been flawed since I had NASM 
installed. 

Thanks,

Andrew Fish

> -Jordan
> 
> On 2015-11-10 18:30:39, Gao, Liming wrote:
>> This patch is committed at r18766.
>> 
>> Thanks
>> Liming
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Tuesday, November 10, 2015 11:31 PM
>> To: Gao, Liming
>> Cc: edk2-devel; Kinney, Michael D
>> Subject: Re: MdePkg: Enable Xcode build of BaseLib without
>> 
>> 
>> On Nov 10, 2015, at 12:22 AM, Gao, Liming 
>> > wrote:
>> 
>> Reviewed-by: Liming Gao >
>> 
>> Liming,
>> 
>> Can you commit the patch?
>> 
>> Thanks,
>> 
>> Andrew Fsih
>> 
>>> cat 0004-MdePkg-BaseLib-don-t-require-NASM-with-Xcode.patch
>> From 8f4666bc80d6d4844e73b3a221e50d587ef09cec Mon Sep 17 00:00:00 2001
>> From: andrew fish >
>> Date: Mon, 9 Nov 2015 22:46:32 -0800
>> Subject: [PATCH 4/4] MdePkg: BaseLib don't require NASM with Xcode
>> 
>> Don't require NASM for simple edk2 Xcode projects.
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Andrew Fish >
>> Reviewed-by: Liming Gao >
>> ---
>> MdePkg/Library/BaseLib/BaseLib.inf | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
>> b/MdePkg/Library/BaseLib/BaseLib.inf
>> index 4cc86d7..e83a569 100644
>> --- a/MdePkg/Library/BaseLib/BaseLib.inf
>> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
>> @@ -257,6 +257,7 @@
>> 
>>   Ia32/GccInline.c | GCC
>>   Ia32/Thunk16.nasm | GCC
>> +  Ia32/Thunk16.S | XCODE
>>   Ia32/EnableDisableInterrupts.S | GCC
>>   Ia32/EnablePaging64.S | GCC
>>   Ia32/DisablePaging32.S | GCC
>> @@ -413,6 +414,7 @@
>>   X86DisablePaging32.c
>>   X64/GccInline.c | GCC
>>   X64/Thunk16.nasm | GCC
>> +  X64/Thunk16.S | XCODE
>>   X64/SwitchStack.S | GCC
>>   X64/SetJump.S | GCC
>>   X64/LongJump.S | GCC
>> --
>> 2.3.2 (Apple Git-55)
>> 
>> ___
>> 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] Armv8 64bit: System error booting linux from the UEFI

[Haojian Zhuang]

On 11 November 2015 at 08:20, Vladimir Olovyannikov
 wrote:
> Hello,
>
> I am not sure this is the right forum to ask this question, so I am sorry in 
> advance if this is an offtopic here (please point me to the proper one).
>
> I brought up UEFI on the device and am trying to load linux from the SD card 
> (loading from the network using GRUB is a topic for another message).
>
> Linux kernel starts and shortly after that (as soon as local_async is enabled 
> which is simple "MSR DAIfclr,4") there is a kernel crash with
> "Bad mode in Error handler detected, code 0xbf00 -- SError"
>
> Here is the log:
>
> The default boot selection will start in  10 seconds
> [1] Linux Kernel from SD Card
> - SD(0x0)/HD(1,MBR,0x,0x89,0x3A9F77)/Image
> - Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8 
> earlycon=uart8250,mmio32,0x6613,maxcpus=1
> [2] GRUB
> - MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi
> - Arguments:
> [3] Shell
> [4] Boot Manager
> Start: 1
> InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB9DA0
> BlockSize : 512
> LastBlock : 3A9FFF
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B BEDB9798
> InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B BEDB9670
> InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB95A0
> InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B BEDAF030
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BE2E6040
> Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
> Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BEDB0718
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: Using DTB from command line
> EFI stub: Exiting boot services and installing virtual address map...
> MmcHost: ExitBootServicesEvent+
> Marked card brcm-SDIO1 as removed
> Resetting Card brcm-SDIO1
> brcm-SDIO1 Card reset done.
> MmcHost: ExitBootServicesEvent-
> MmcHost: ExitBootServicesEvent+
> Marked card brcm-SDIO0 as removed
> Resetting Card brcm-SDIO0
> brcm-SDIO0 Card reset done.
> MmcHost: ExitBootServicesEvent-
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpu
> [0.00] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc version 
> 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro 
> GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015
> [0.00] CPU: AArch64 Processor [411fd073] revision 3
> [0.00] Detected PIPT I-cache on CPU0
> [0.00] earlycon: Early serial console at MMIO32 0x6613 (options 
> 'maxcpus=1')
> [0.00] bootconsole [uart0] enabled
> [0.00] Bad mode in Error handler detected, code 0xbf00 -- SError
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
> [0.00] Hardware name: SVK proto (DT)
> [0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti: 
> ffc00074c000
> [0.00] PC is at setup_arch+0x260/0x5b4
> [0.00] LR is at setup_arch+0x25c/0x5b4
> [0.00] pc : [] lr : [] pstate: 
> 02c5
> [0.00] sp : ffc00074ff20
> [0.00] x29: ffc00074ff20 x28: 
> [0.00] x27: ffc81198 x26: 807cd000
> [0.00] x25: 807ca000 x24: 8000
> [0.00] x23:  x22: ffc000752000
> [0.00] x21: ffc000752610 x20: ffbffa80
> [0.00] x19: ffc8 x18: 
> [0.00] x17: 05e3 x16: 1000
> [0.00] x15: 1c00 x14: 0ffe
> [0.00] x13: 0020 x12: 0028
> [0.00] x11: 0007 x10: 0101010101010101
> [0.00] x9 : fffb x8 : 0008
> [0.00] x7 : 0003 x6 : 0080
> [0.00] x5 : 005f x4 : 
> [0.00] x3 :  x2 : 0065
> [0.00] x1 :  x0 : 0001
> [0.00]
> [0.00] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
> [0.00] Hardware name: SVK proto (DT)
> [0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti: 
> ffc00074c000
> [0.00] PC is at setup_arch+0x260/0x5b4
> [0.00] LR is at setup_arch+0x25c/0x5b4
> [0.00] pc : [] lr : [] pstate: 
> 02c5
> [0.00] sp : ffc00074ff20
> [0.00] x29: ffc00074ff20 x28: 
> [0.00] x27: ffc81198 x26: 807cd000
> [0.00] x25: 807ca000 x24: 8000
> [0.00] x23:  x22: