Re: [edk2] [Patch] BaseTools: generate alignment when the FV content come from the filesystem

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Wednesday, March 23, 2016 5:58 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] BaseTools: generate alignment when the FV content
> come from the filesystem
> 
> when the FV contents come from the filesystem instead of from a named
> FDF
> section, the build tool missed to generate alignment for this FV. The fix
> is get the alignment value from FV header and use this value to generate
> alignment.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/GenFds/FvImageSection.py | 20
> +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/FvImageSection.py
> b/BaseTools/Source/Python/GenFds/FvImageSection.py
> index caf8de1..b577de2 100644
> --- a/BaseTools/Source/Python/GenFds/FvImageSection.py
> +++ b/BaseTools/Source/Python/GenFds/FvImageSection.py
> @@ -1,9 +1,9 @@
>  ## @file
>  # process FV image section generation
>  #
> -#  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the
> BSD License
>  #  which accompanies this distribution.  The full text of the license may be
> found at
>  #  http://opensource.org/licenses/bsd-license.php
> @@ -81,10 +81,28 @@ class FvImageSection(FvImageSectionClassObject):
>  if GenFdsGlobalVariable.GetAlignment 
> (Fv.FvAlignment) >
> GenFdsGlobalVariable.GetAlignment (self.Alignment):
>  self.Alignment = Fv.FvAlignment
>  else:
>  if self.FvFileName != None:
>  FvFileName =
> GenFdsGlobalVariable.ReplaceWorkspaceMacro(self.FvFileName)
> +if os.path.isfile(FvFileName):
> +FvFileObj = open (FvFileName,'r+b')
> +FvFileObj.seek(0)
> +# PI FvHeader is 0x48 byte
> +FvHeaderBuffer = FvFileObj.read(0x48)
> +# FV alignment position.
> +FvAlignmentValue = 1 << (ord (FvHeaderBuffer[0x2E]) 
> & 0x1F)
> +# FvAlignmentValue is larger than or equal to 1K
> +if FvAlignmentValue >= 0x400:
> +if FvAlignmentValue >= 0x1:
> +#The max alignment supported by FFS is 64K.
> +self.Alignment = "64K"
> +else:
> +self.Alignment = str (FvAlignmentValue / 
> 0x400) + "K"
> +else:
> +# FvAlignmentValue is less than 1K
> +self.Alignment = str (FvAlignmentValue)
> +FvFileObj.close()
>  else:
>  EdkLogger.error("GenFds", GENFDS_ERROR, "FvImageSection
> Failed! %s NOT found in FDF" % self.FvName)
> 
>  #
>  # Prepare the parameter of GenSection
> --
> 2.6.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] SecurityPkg/SecureBootConfigDxe: Remove type casting from the ChooseFile handlers

[Bi, Dandan]

Hi Laszlo,

Please help to commit these patches. Thanks!


Thanks,
Dandan

-Original Message-
From: Gary Lin [mailto:g...@suse.com] 
Sent: Thursday, March 24, 2016 11:29 AM
To: Bi, Dandan 
Cc: edk2-de...@ml01.01.org; Laszlo Ersek 
Subject: Re: [edk2] [PATCH 2/2] SecurityPkg/SecureBootConfigDxe: Remove type 
casting from the ChooseFile handlers

On Mon, Mar 21, 2016 at 10:34:17AM +0100, Laszlo Ersek wrote:
> On 03/21/16 10:04, Gary Lin wrote:
> > The type casting in the ChooseFile is not necessary and it actually 
> > hided the incompatible handlers from the compiler.
> 
> s/hided/hid/
> 
> Other than that: series
> Reviewed-by: Laszlo Ersek 
> 
> Dandan, if you want me to, I can help commit these patches.
> 
Hi Dandan,

Will you commit the patches? or would you like Laszlo to commit the patches?

Gary Lin

> Thanks, Gary!
> Laszlo
> 
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Gary Lin 
> > ---
> >  .../SecureBootConfigDxe/SecureBootConfigImpl.c | 10 
> > +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git 
> > a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
> > nfigImpl.c 
> > b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
> > nfigImpl.c
> > index 8ca6d62..e840316 100644
> > --- 
> > a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
> > nfigImpl.c
> > +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBo
> > +++ otConfigImpl.c
> > @@ -3590,23 +3590,23 @@ SecureBootCallback (
> >break;
> >  
> >  case FORMID_ENROLL_PK_FORM:
> > -  ChooseFile( NULL, NULL, (CHOOSE_HANDLER) UpdatePKFromFile, );
> > +  ChooseFile (NULL, NULL, UpdatePKFromFile, );
> >break;
> >  
> >  case FORMID_ENROLL_KEK_FORM:
> > -  ChooseFile( NULL, NULL, (CHOOSE_HANDLER) UpdateKEKFromFile, );
> > +  ChooseFile (NULL, NULL, UpdateKEKFromFile, );
> >break;
> >  
> >  case SECUREBOOT_ENROLL_SIGNATURE_TO_DB:
> > -  ChooseFile( NULL, NULL, (CHOOSE_HANDLER) UpdateDBFromFile, );
> > +  ChooseFile (NULL, NULL, UpdateDBFromFile, );
> >break;
> >  
> >  case SECUREBOOT_ENROLL_SIGNATURE_TO_DBX:
> > -  ChooseFile( NULL, NULL, (CHOOSE_HANDLER) UpdateDBXFromFile, );
> > +  ChooseFile (NULL, NULL, UpdateDBXFromFile, );
> >break;
> >  
> >  case SECUREBOOT_ENROLL_SIGNATURE_TO_DBT:
> > -  ChooseFile( NULL, NULL, (CHOOSE_HANDLER) UpdateDBTFromFile, );
> > +  ChooseFile (NULL, NULL, UpdateDBTFromFile, );
> >break;
> >  
> >  case KEY_SECURE_BOOT_DELETE_PK:
> > 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ni, Ruiyu]

Regards,
Ray


>-Original Message-
>From: Heyi Guo [mailto:heyi@linaro.org]
>Sent: Thursday, March 24, 2016 9:09 AM
>To: Ryan Harkin ; Laszlo Ersek 
>Cc: Ni, Ruiyu ; Tian, Feng ; 
>edk2-devel@lists.01.org ;
>Zeng, Star ; Ard Biesheuvel 
>Subject: Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>PCD
>
>Hi folks,
>
>Please see my thoughts below:
>
>On 03/24/2016 12:26 AM, Ryan Harkin wrote:
>> On 23 March 2016 at 16:24, Ryan Harkin  wrote:
>>> On 23 March 2016 at 08:53, Laszlo Ersek  wrote:
 On 03/23/16 09:33, Ni, Ruiyu wrote:
> Laszlo,
> Since the patch below lets SerialDxe driver use the new introduced
> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
> Would you mind to revert the check in @ 31ae446b
> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO 
> depth?
 If I understand correctly, this series increases the terminal polling
 rate, so that cursor movement escape sequences (and other burst-like
 sequences) can be processed even with a receive fifo depth of 1. Hence
 31ae446b should become unnecessary.

 If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
 your revert of 31ae446b -- on top of this series from Heyi --, and the
 cursor keys work with 31ae446b reverted, then I don't mind, sure.

>>> Unfortunately TC2 and Juno no longer with with 31ae446b reverted and
>>> these 3 patches from the series applied.
>
>I think my patches may not be sufficient to replace patch 31ae446b; they
>have some different results.
>
>The result of patch 31ae446b is absolute; it does not rely on timer
>event or code execution but only on UART hardware.
>
>My patches are actually complementary software solution for platforms
>which have certain length of FIFO depth, e.g. 40 characters continuous
>input to UART with 32 FIFO depth. I don't think it will work well on
>FIFO depth of 1, as it does not have enough scalability for software
>processing. This also the reason why I reduce the precisely calculated
>interval.
>
>It also depends on the timer interrupt period (should be
>gEmbeddedTokenSpaceGuid.PcdTimerPeriod on ARM platforms), which must be
>less than the calculated polling interval.
>
>So my opinion is to keep patch 31ae446b if it is reasonable on its own,
>and take my patches as further enhancement.

NO.
I understand the fact that the patch 31ae446b did fix an issue in certain 
platform.
But the patch lets TerminalDxe driver changes the underlying UART's Receive
FIFO depth. Such behavior is bad.

Now since we have added the new PCD PcdDefaultUartReceiveFifoDepth,
we can fix the original problem by setting the PCD value to 16 from platform 
DSC.

In all, I wanted to say, with the new PCD patch, the patch 31ae446b can be 
reverted
without functionality impact.

And I will still talk with Heyi to understand why 3/3 timer interval patch 
needs to
coded like that.

>
>Thanks.
>
>Heyi
>
>
>> I'm sure you would all work it out ok, but that should have been:
>>
>> "Unfortunately TC2 and Juno no longer work with 31ae446b reverted and
>> these 3 patches from the series applied."
>>
>>
>>> It's a shame, because it works on FVP models and copy/paste then works.
>>>
>>> I haven't made any investigations on what's going wrong.  But regular
>>> ASCII keys work, control codes like cursor keys don't.  So it looks
>>> like the old FIFO setting problem we discussed a few weeks ago.
>>>
>>>
 Thanks
 Laszlo

> Regards,
> Ray
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Heyi Guo
>> Sent: Thursday, March 17, 2016 10:37 PM
>> To: edk2-devel@lists.01.org
>> Cc: Heyi Guo ; Tian, Feng ; 
>> Zeng, Star 
>> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth 
>> with PCD
>>
>> Set UART receive FIFO depth with PCD instead of fixed number "1".
>> The default value of PCD is also 1, so it makes no difference for
>> platforms which do not explicitly set this PCD.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Heyi Guo 
>> Cc: Feng Tian 
>> Cc: Star Zeng 
>> ---
>> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
>> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> index 164060b..a1453bd 100644
>> --- 

Re: [edk2] [Patch] MdeModulePkg/Bds: Fix VS2012 build failure.

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, March 24, 2016 10:34 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Tian, Feng 
Subject: [Patch] MdeModulePkg/Bds: Fix VS2012 build failure.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c
index 4cc4fb4..b49758b 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c
@@ -458,6 +458,9 @@ BmGetActiveConsoleIn (
   EFI_STATUSStatus;
   EFI_HANDLE*Handles;
 
+  Handles = NULL;
+  *Count  = 0;
+
   if (gST->ConsoleInHandle != NULL) {
 Status = gBS->OpenProtocol (
 gST->ConsoleInHandle, @@ -480,10 +483,6 @@ 
BmGetActiveConsoleIn (
 
 );
   }
-  if (EFI_ERROR (Status)) {
-Handles = NULL;
-*Count  = 0;
-  }
 
   return Handles;
 }
--
2.7.0.windows.1

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

Re: [edk2] [PATCH v2 1/1] MdePkg: Move SMBIOS data into the IndustryStandard header.

[Zeng, Star]

On 2016/3/23 10:37, Zeng, Star wrote:

On 2016/3/22 22:53, Marvin Häuser wrote:

As the SMBIOS table types belong to the SMBIOS standard, they were
moved from the SMBIOS Protocol header into the SMBIOS
IndustryStandard header without the EFI_-prefix. Defines with the
EFI_-prefix have been kept in the Protocol header for
backwards-compatibility, resolving to the IndustryStandard defines.
The same has been done with the C types.

The SMBIOS table header structure had been duplicated -
SMBIOS_STRUCTURE in the IndustryStandard header and
EFI_SMBIOS_TABLE_HEADER in the Protocol file - and thus the
Protocol type was replaced with a typedef to the InudstryStandard's.
This doesn't only make it easier to maintain, but it also prevents
potential future issues as the Protocol type has been aligned, while
the standard and the IndustryStandard header declare it as
byte-packed.
This has worked well till now only because the members of the
structure do not require alignment yet.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 


Reviewed-by: Star Zeng 


Pushed at bb7051eba96f87bbb6544cad9cd7390207b4dcc0.

Thanks for the contribution.

Star




---
  MdePkg/Include/IndustryStandard/SmBios.h |  84 +++-
  MdePkg/Include/Protocol/Smbios.h | 139 
  2 files changed, 133 insertions(+), 90 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h
b/MdePkg/Include/IndustryStandard/SmBios.h
index b7c54f2fac12..c66422fc3af4 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -51,6 +51,53 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
EITHER EXPRESS OR IMPLIED.
  //
  #define SMBIOS_3_0_TABLE_MAX_LENGTH 0x

+//
+// SMBIOS type macros which is according to SMBIOS 2.7 specification.
+//
+#define SMBIOS_TYPE_BIOS_INFORMATION 0
+#define SMBIOS_TYPE_SYSTEM_INFORMATION   1
+#define SMBIOS_TYPE_BASEBOARD_INFORMATION2
+#define SMBIOS_TYPE_SYSTEM_ENCLOSURE 3
+#define SMBIOS_TYPE_PROCESSOR_INFORMATION4
+#define SMBIOS_TYPE_MEMORY_CONTROLLER_INFORMATION5
+#define SMBIOS_TYPE_MEMORY_MODULE_INFORMATON 6
+#define SMBIOS_TYPE_CACHE_INFORMATION7
+#define SMBIOS_TYPE_PORT_CONNECTOR_INFORMATION   8
+#define SMBIOS_TYPE_SYSTEM_SLOTS 9
+#define SMBIOS_TYPE_ONBOARD_DEVICE_INFORMATION   10
+#define SMBIOS_TYPE_OEM_STRINGS  11
+#define SMBIOS_TYPE_SYSTEM_CONFIGURATION_OPTIONS 12
+#define SMBIOS_TYPE_BIOS_LANGUAGE_INFORMATION13
+#define SMBIOS_TYPE_GROUP_ASSOCIATIONS   14
+#define SMBIOS_TYPE_SYSTEM_EVENT_LOG 15
+#define SMBIOS_TYPE_PHYSICAL_MEMORY_ARRAY16
+#define SMBIOS_TYPE_MEMORY_DEVICE17
+#define SMBIOS_TYPE_32BIT_MEMORY_ERROR_INFORMATION   18
+#define SMBIOS_TYPE_MEMORY_ARRAY_MAPPED_ADDRESS  19
+#define SMBIOS_TYPE_MEMORY_DEVICE_MAPPED_ADDRESS 20
+#define SMBIOS_TYPE_BUILT_IN_POINTING_DEVICE 21
+#define SMBIOS_TYPE_PORTABLE_BATTERY 22
+#define SMBIOS_TYPE_SYSTEM_RESET 23
+#define SMBIOS_TYPE_HARDWARE_SECURITY24
+#define SMBIOS_TYPE_SYSTEM_POWER_CONTROLS25
+#define SMBIOS_TYPE_VOLTAGE_PROBE26
+#define SMBIOS_TYPE_COOLING_DEVICE   27
+#define SMBIOS_TYPE_TEMPERATURE_PROBE28
+#define SMBIOS_TYPE_ELECTRICAL_CURRENT_PROBE 29
+#define SMBIOS_TYPE_OUT_OF_BAND_REMOTE_ACCESS30
+#define SMBIOS_TYPE_BOOT_INTEGRITY_SERVICE   31
+#define SMBIOS_TYPE_SYSTEM_BOOT_INFORMATION  32
+#define SMBIOS_TYPE_64BIT_MEMORY_ERROR_INFORMATION   33
+#define SMBIOS_TYPE_MANAGEMENT_DEVICE34
+#define SMBIOS_TYPE_MANAGEMENT_DEVICE_COMPONENT  35
+#define SMBIOS_TYPE_MANAGEMENT_DEVICE_THRESHOLD_DATA 36
+#define SMBIOS_TYPE_MEMORY_CHANNEL   37
+#define SMBIOS_TYPE_IPMI_DEVICE_INFORMATION  38
+#define SMBIOS_TYPE_SYSTEM_POWER_SUPPLY  39
+#define SMBIOS_TYPE_ADDITIONAL_INFORMATION   40
+#define SMBIOS_TYPE_ONBOARD_DEVICES_EXTENDED_INFORMATION 41
+#define SMBIOS_TYPE_MANAGEMENT_CONTROLLER_HOST_INTERFACE 42
+
  ///
  /// Inactive type is added from SMBIOS 2.2. Reference SMBIOS 2.6,
chapter 3.3.43.
  /// Upper-level software that interprets the SMBIOS structure-table
should bypass an
@@ -64,6 +111,27 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
EITHER EXPRESS OR IMPLIED.
  ///
  #define SMBIOS_TYPE_END_OF_TABLE 0x007F

+#define SMBIOS_OEM_BEGIN 128
+#define SMBIOS_OEM_END   255
+
+///
+/// Types 0 through 127 (7Fh) are reserved for and defined by this
+/// 

[edk2] [Patch] MdeModulePkg/Bds: Fix VS2012 build failure.

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c
index 4cc4fb4..b49758b 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c
@@ -458,6 +458,9 @@ BmGetActiveConsoleIn (
   EFI_STATUSStatus;
   EFI_HANDLE*Handles;
 
+  Handles = NULL;
+  *Count  = 0;
+
   if (gST->ConsoleInHandle != NULL) {
 Status = gBS->OpenProtocol (
 gST->ConsoleInHandle,
@@ -480,10 +483,6 @@ BmGetActiveConsoleIn (
 
 );
   }
-  if (EFI_ERROR (Status)) {
-Handles = NULL;
-*Count  = 0;
-  }
 
   return Handles;
 }
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ni, Ruiyu]

Regards,
Ray


>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
>Ersek
>Sent: Wednesday, March 23, 2016 4:53 PM
>To: Ni, Ruiyu 
>Cc: Tian, Feng ; Ard Biesheuvel 
>; edk2-devel@lists.01.org
>; Heyi Guo ; Ryan Harkin 
>; Zeng, Star
>
>Subject: Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>PCD
>
>On 03/23/16 09:33, Ni, Ruiyu wrote:
>> Laszlo,
>> Since the patch below lets SerialDxe driver use the new introduced
>> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
>> Would you mind to revert the check in @ 31ae446b
>> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?
>
>If I understand correctly, this series increases the terminal polling
>rate, so that cursor movement escape sequences (and other burst-like
>sequences) can be processed even with a receive fifo depth of 1. Hence
>31ae446b should become unnecessary.

If the FIFO depth is 16, we can just set the newly added
PcdUartDefaultReceiveFIfoDepth to 16 to test the functionality.
Rather than waiting the 3/3 terminal polling rate adjustment patch.

>
>If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
>your revert of 31ae446b -- on top of this series from Heyi --, and the
>cursor keys work with 31ae446b reverted, then I don't mind, sure.
>
>Thanks
>Laszlo
>
>>
>> Regards,
>> Ray
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Thursday, March 17, 2016 10:37 PM
>>> To: edk2-devel@lists.01.org
>>> Cc: Heyi Guo ; Tian, Feng ; Zeng, 
>>> Star 
>>> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>>> PCD
>>>
>>> Set UART receive FIFO depth with PCD instead of fixed number "1".
>>> The default value of PCD is also 1, so it makes no difference for
>>> platforms which do not explicitly set this PCD.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Heyi Guo 
>>> Cc: Feng Tian 
>>> Cc: Star Zeng 
>>> ---
>>> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
>>> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> index 164060b..a1453bd 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> @@ -41,10 +41,11 @@
>>>   gEfiDevicePathProtocolGuid## PRODUCES
>>>
>>> [Pcd]
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>>>
>>> [Depex]
>>>   TRUE
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> index f5b3064..d2383e5 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> @@ -236,7 +236,7 @@ SerialReset (
>>>   //
>>>   // Set the Serial I/O mode
>>>   //
>>> -  This->Mode->ReceiveFifoDepth  = 1;
>>> +  This->Mode->ReceiveFifoDepth  = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   This->Mode->Timeout   = 1000 * 1000;
>>>   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>>>   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>> @@ -508,6 +508,7 @@ SerialDxeInitialize (
>>>   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
>>>   mSerialIoMode.StopBits = (UINT32) PcdGet8 (PcdUartDefaultStopBits);
>>> +  mSerialIoMode.ReceiveFifoDepth = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   mSerialDevicePath.Uart.BaudRate = PcdGet64 (PcdUartDefaultBaudRate);
>>>   mSerialDevicePath.Uart.DataBits = PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialDevicePath.Uart.Parity   = PcdGet8 (PcdUartDefaultParity);
>>> --
>>> 2.7.0
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>> 

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

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Thursday, March 17, 2016 9:23 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Gao, Liming ; 
Ard Biesheuvel 
Subject: [PATCH] BaseTools: use unsigned chars on ARM architectures

By default, the ARM architectures have unsigned chars, whereas the other
architectures supported by EDK2 by default have signed chars.
However, EDK2 uses -funsigned-chars on those architectures to change the
default behaviour.

Unfortunately, the ARM architectures explicitly break their default
behaviour by specifying -fsigned-chars (I presume in a pre-emptive
attempt at avoiding incompatibility).

Since this situation is already confusing enough, switch the ARM
architectures to also specify -funsigned-chars explicitly rather than
just dropping the current parameter.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---
 BaseTools/Conf/tools_def.template | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

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

Re: [edk2] [Patch] NetworkPkg: Fix HII related problem in HTTP boot driver.

[Wu, Jiaxin]

Looks good to me.

Reviewed-by: Jiaxin Wu 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu
> Siyuan
> Sent: Wednesday, March 23, 2016 3:39 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Dong, Eric 
> Subject: [edk2] [Patch] NetworkPkg: Fix HII related problem in HTTP boot
> driver.
> 
> According to UEFI spec, HII_Config_Access.RouteConfig() should return
> success if the required configuration has been processed. Current HTTP boot
> driver may return error code in some situation, which failed the UEFI SCT 
> test.
> This patch fix this issue by removing the returned error status code and
> adding extra check point in the Callback() function, which will pop up a
> message box if user input an unsupported URI string.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan 
> Cc: Dong Eric 
> Cc: Wu Jiaxin 
> ---
>  NetworkPkg/HttpBootDxe/HttpBootConfig.c| 77
> +++---
>  NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h | 19 --
>  NetworkPkg/HttpBootDxe/HttpBootConfigVfr.vfr   |  6 +-
>  3 files changed, 85 insertions(+), 17 deletions(-)
> 
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> index 0c1ff43..e7dd5db 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> @@ -351,6 +351,7 @@ HttpBootFormExtractConfig (
>//
>BufferSize = sizeof (HTTP_BOOT_CONFIG_IFR_NVDATA);
>ZeroMem (>HttpBootNvData, BufferSize);
> +  StrCpyS (CallbackInfo->HttpBootNvData.Description,
> + DESCRIPTION_STR_MAX_SIZE / sizeof (CHAR16),
> + HTTP_BOOT_DEFAULT_DESCRIPTION_STR);
> 
>ConfigRequest = Request;
>if ((Request == NULL) || (StrStr (Request, L"OFFSET") == NULL)) { @@ -
> 376,7 +377,6 @@ HttpBootFormExtractConfig (
>  Results,
>  Progress
>  );
> -  ASSERT_EFI_ERROR (Status);
> 
>//
>// Free the allocated config request string.
> @@ -487,14 +487,14 @@ HttpBootFormRouteConfig (
>//
>// Create a new boot option according to the configuration data.
>//
> -  Status = HttpBootAddBootOption (
> - Private,
> - (CallbackInfo->HttpBootNvData.IpVersion ==
> HTTP_BOOT_IP_VERSION_6) ? TRUE : FALSE,
> - CallbackInfo->HttpBootNvData.Description,
> - CallbackInfo->HttpBootNvData.Uri
> - );
> +  HttpBootAddBootOption (
> +Private,
> +(CallbackInfo->HttpBootNvData.IpVersion ==
> HTTP_BOOT_IP_VERSION_6) ? TRUE : FALSE,
> +CallbackInfo->HttpBootNvData.Description,
> +CallbackInfo->HttpBootNvData.Uri
> +);
> 
> -  return Status;
> +  return EFI_SUCCESS;
>  }
> 
>  /**
> @@ -533,7 +533,66 @@ HttpBootFormCallback (
>OUT   EFI_BROWSER_ACTION_REQUEST   *ActionRequest
>)
>  {
> -  return EFI_UNSUPPORTED;
> +  EFI_INPUT_KEY   Key;
> +  UINTN   Index;
> +  CHAR16  *Uri;
> +  HTTP_BOOT_FORM_CALLBACK_INFO*CallbackInfo;
> +
> +  if (This == NULL || Value == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  CallbackInfo =
> HTTP_BOOT_FORM_CALLBACK_INFO_FROM_CONFIG_ACCESS
> + (This);
> +
> +  if (Action != EFI_BROWSER_ACTION_CHANGING) {
> +return EFI_UNSUPPORTED;
> +  }
> +
> +  switch (QuestionId) {
> +  case KEY_INITIATOR_URI:
> +//
> +// Get user input URI string
> +//
> +Uri = HiiGetString (CallbackInfo->RegisteredHandle, Value->string,
> + NULL);
> +
> +//
> +// Convert the scheme to all lower case.
> +//
> +for (Index = 0; Index < StrLen (Uri); Index++) {
> +  if (Uri[Index] == L':') {
> +break;
> +  }
> +  if (Uri[Index] >= L'A' && Uri[Index] <= L'Z') {
> +Uri[Index] -= (CHAR16)(L'A' - L'a');
> +  }
> +}
> +
> +//
> +// Set the converted URI string back
> +//
> +HiiSetString (CallbackInfo->RegisteredHandle, Value->string, Uri,
> + NULL);
> +
> +//
> +// We only accept http and https, pop up a message box for unsupported
> URI.
> +//
> +if ((StrnCmp (Uri, L"http://;, 7) != 0) && (StrnCmp (Uri, L"https://;, 
> 7) != 0))
> {
> +  CreatePopUp (
> +EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
> +,
> +L"ERROR: Unsupported URI!",
> +L"Only supports HTTP and HTTPS",
> +NULL
> +);
> +}
> +
> +FreePool (Uri);
> +break;
> +
> +  default:
> +break;
> +  }
> +
> +  return EFI_SUCCESS;
>  }
> 
>  /**
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> index 07043e7..37ce440 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> +++ 

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Heyi Guo]

Hi folks,

Please see my thoughts below:

On 03/24/2016 12:26 AM, Ryan Harkin wrote:

On 23 March 2016 at 16:24, Ryan Harkin  wrote:

On 23 March 2016 at 08:53, Laszlo Ersek  wrote:

On 03/23/16 09:33, Ni, Ruiyu wrote:

Laszlo,
Since the patch below lets SerialDxe driver use the new introduced
PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
Would you mind to revert the check in @ 31ae446b
--> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?

If I understand correctly, this series increases the terminal polling
rate, so that cursor movement escape sequences (and other burst-like
sequences) can be processed even with a receive fifo depth of 1. Hence
31ae446b should become unnecessary.

If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
your revert of 31ae446b -- on top of this series from Heyi --, and the
cursor keys work with 31ae446b reverted, then I don't mind, sure.


Unfortunately TC2 and Juno no longer with with 31ae446b reverted and
these 3 patches from the series applied.


I think my patches may not be sufficient to replace patch 31ae446b; they 
have some different results.


The result of patch 31ae446b is absolute; it does not rely on timer 
event or code execution but only on UART hardware.


My patches are actually complementary software solution for platforms 
which have certain length of FIFO depth, e.g. 40 characters continuous 
input to UART with 32 FIFO depth. I don't think it will work well on 
FIFO depth of 1, as it does not have enough scalability for software 
processing. This also the reason why I reduce the precisely calculated 
interval.


It also depends on the timer interrupt period (should be 
gEmbeddedTokenSpaceGuid.PcdTimerPeriod on ARM platforms), which must be 
less than the calculated polling interval.


So my opinion is to keep patch 31ae446b if it is reasonable on its own, 
and take my patches as further enhancement.


Thanks.

Heyi



I'm sure you would all work it out ok, but that should have been:

"Unfortunately TC2 and Juno no longer work with 31ae446b reverted and
these 3 patches from the series applied."



It's a shame, because it works on FVP models and copy/paste then works.

I haven't made any investigations on what's going wrong.  But regular
ASCII keys work, control codes like cursor keys don't.  So it looks
like the old FIFO setting problem we discussed a few weeks ago.



Thanks
Laszlo


Regards,
Ray



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Thursday, March 17, 2016 10:37 PM
To: edk2-devel@lists.01.org
Cc: Heyi Guo ; Tian, Feng ; Zeng, Star 

Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

Set UART receive FIFO depth with PCD instead of fixed number "1".
The default value of PCD is also 1, so it makes no difference for
platforms which do not explicitly set this PCD.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo 
Cc: Feng Tian 
Cc: Star Zeng 
---
MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
index 164060b..a1453bd 100644
--- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
+++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
@@ -41,10 +41,11 @@
   gEfiDevicePathProtocolGuid## PRODUCES

[Pcd]
-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES

[Depex]
   TRUE
diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
index f5b3064..d2383e5 100644
--- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
+++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
@@ -236,7 +236,7 @@ SerialReset (
   //
   // Set the Serial I/O mode
   //
-  This->Mode->ReceiveFifoDepth  = 1;
+  This->Mode->ReceiveFifoDepth  = PcdGet16 (PcdUartDefaultReceiveFifoDepth);
   This->Mode->Timeout   = 1000 * 1000;
   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
@@ -508,6 +508,7 @@ SerialDxeInitialize (
   

Re: [edk2] [Patch] NetworkPkg: Fix HII related problem in HTTP boot driver.

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu 
> Siyuan
> Sent: Wednesday, March 23, 2016 3:39 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin; Dong, Eric
> Subject: [edk2] [Patch] NetworkPkg: Fix HII related problem in HTTP boot 
> driver.
> 
> According to UEFI spec, HII_Config_Access.RouteConfig() should return success
> if the required configuration has been processed. Current HTTP boot driver
> may return error code in some situation, which failed the UEFI SCT test.
> This patch fix this issue by removing the returned error status code and 
> adding
> extra check point in the Callback() function, which will pop up a message box
> if user input an unsupported URI string.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan 
> Cc: Dong Eric 
> Cc: Wu Jiaxin 
> ---
>  NetworkPkg/HttpBootDxe/HttpBootConfig.c| 77 
> +++---
>  NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h | 19 --
>  NetworkPkg/HttpBootDxe/HttpBootConfigVfr.vfr   |  6 +-
>  3 files changed, 85 insertions(+), 17 deletions(-)
> 
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c 
> b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> index 0c1ff43..e7dd5db 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> @@ -351,6 +351,7 @@ HttpBootFormExtractConfig (
>//
>BufferSize = sizeof (HTTP_BOOT_CONFIG_IFR_NVDATA);
>ZeroMem (>HttpBootNvData, BufferSize);
> +  StrCpyS (CallbackInfo->HttpBootNvData.Description, 
> DESCRIPTION_STR_MAX_SIZE / sizeof (CHAR16),
> HTTP_BOOT_DEFAULT_DESCRIPTION_STR);
> 
>ConfigRequest = Request;
>if ((Request == NULL) || (StrStr (Request, L"OFFSET") == NULL)) {
> @@ -376,7 +377,6 @@ HttpBootFormExtractConfig (
>  Results,
>  Progress
>  );
> -  ASSERT_EFI_ERROR (Status);
> 
>//
>// Free the allocated config request string.
> @@ -487,14 +487,14 @@ HttpBootFormRouteConfig (
>//
>// Create a new boot option according to the configuration data.
>//
> -  Status = HttpBootAddBootOption (
> - Private,
> - (CallbackInfo->HttpBootNvData.IpVersion == 
> HTTP_BOOT_IP_VERSION_6) ? TRUE : FALSE,
> - CallbackInfo->HttpBootNvData.Description,
> - CallbackInfo->HttpBootNvData.Uri
> - );
> +  HttpBootAddBootOption (
> +Private,
> +(CallbackInfo->HttpBootNvData.IpVersion == HTTP_BOOT_IP_VERSION_6) ? 
> TRUE : FALSE,
> +CallbackInfo->HttpBootNvData.Description,
> +CallbackInfo->HttpBootNvData.Uri
> +);
> 
> -  return Status;
> +  return EFI_SUCCESS;
>  }
> 
>  /**
> @@ -533,7 +533,66 @@ HttpBootFormCallback (
>OUT   EFI_BROWSER_ACTION_REQUEST   *ActionRequest
>)
>  {
> -  return EFI_UNSUPPORTED;
> +  EFI_INPUT_KEY   Key;
> +  UINTN   Index;
> +  CHAR16  *Uri;
> +  HTTP_BOOT_FORM_CALLBACK_INFO*CallbackInfo;
> +
> +  if (This == NULL || Value == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  CallbackInfo = HTTP_BOOT_FORM_CALLBACK_INFO_FROM_CONFIG_ACCESS (This);
> +
> +  if (Action != EFI_BROWSER_ACTION_CHANGING) {
> +return EFI_UNSUPPORTED;
> +  }
> +
> +  switch (QuestionId) {
> +  case KEY_INITIATOR_URI:
> +//
> +// Get user input URI string
> +//
> +Uri = HiiGetString (CallbackInfo->RegisteredHandle, Value->string, NULL);
> +
> +//
> +// Convert the scheme to all lower case.
> +//
> +for (Index = 0; Index < StrLen (Uri); Index++) {
> +  if (Uri[Index] == L':') {
> +break;
> +  }
> +  if (Uri[Index] >= L'A' && Uri[Index] <= L'Z') {
> +Uri[Index] -= (CHAR16)(L'A' - L'a');
> +  }
> +}
> +
> +//
> +// Set the converted URI string back
> +//
> +HiiSetString (CallbackInfo->RegisteredHandle, Value->string, Uri, NULL);
> +
> +//
> +// We only accept http and https, pop up a message box for unsupported 
> URI.
> +//
> +if ((StrnCmp (Uri, L"http://;, 7) != 0) && (StrnCmp (Uri, L"https://;, 
> 7) != 0)) {
> +  CreatePopUp (
> +EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
> +,
> +L"ERROR: Unsupported URI!",
> +L"Only supports HTTP and HTTPS",
> +NULL
> +);
> +}
> +
> +FreePool (Uri);
> +break;
> +
> +  default:
> +break;
> +  }
> +
> +  return EFI_SUCCESS;
>  }
> 
>  /**
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h 
> b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> index 07043e7..37ce440 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> @@ -17,24 +17,31 @@ WITHOUT WARRANTIES OR 

Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Zeng, Star 
Sent: Thursday, March 24, 2016 8:44 AM
To: Alcantara, Paulo ; edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message

Reviewed-by: Star Zeng 

On 2016/3/24 1:25, Alcantara, Paulo wrote:
> Forgot to add another S-b, sorry. Please add it:
>
> Signed-off-by: Juliano Ciocari 
>
> Thanks,
>
> Paulo
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Alcantara, Paulo
> Sent: quarta-feira, 23 de março de 2016 14:20
> To: edk2-devel@lists.01.org
> Cc: Feng Tian ; Star Zeng 
> Subject: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message
>
> s/Configutation/Configuration/
>
> Cc: Feng Tian 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paulo Alcantara 
> ---
>   MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni 
> b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
> index 3329f90..ee5f6e6 100644
> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
> @@ -15,7 +15,7 @@
>
>   #langdef en-US  "English"
>
> -#string STR_FORM_SET_TITLE #language en-US "RAM Disk 
> Configutation"
> +#string STR_FORM_SET_TITLE #language en-US "RAM Disk 
> Configuration"
>   #string STR_FORM_SET_TITLE_HELP#language en-US "Press  to 
> add/remove RAM disks."
>
>   #string STR_MAIN_FORM_TITLE#language en-US "RAM Disk HII Main 
> Screen"
>

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

Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message

[Zeng, Star]

Reviewed-by: Star Zeng 

On 2016/3/24 1:25, Alcantara, Paulo wrote:

Forgot to add another S-b, sorry. Please add it:

Signed-off-by: Juliano Ciocari 

Thanks,

Paulo

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Alcantara, Paulo
Sent: quarta-feira, 23 de março de 2016 14:20
To: edk2-devel@lists.01.org
Cc: Feng Tian ; Star Zeng 
Subject: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message

s/Configutation/Configuration/

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara 
---
  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
index 3329f90..ee5f6e6 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
@@ -15,7 +15,7 @@

  #langdef en-US  "English"

-#string STR_FORM_SET_TITLE #language en-US "RAM Disk Configutation"
+#string STR_FORM_SET_TITLE #language en-US "RAM Disk Configuration"
  #string STR_FORM_SET_TITLE_HELP#language en-US "Press  to 
add/remove RAM disks."

  #string STR_MAIN_FORM_TITLE#language en-US "RAM Disk HII Main 
Screen"




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

[edk2] UEFI Device PXE Boot fron MS Server

[Jim Slaughter]

 Hello,
I need to do a PXE boot :: UEFI Device Booting (Intel based) <--->  Microsoft 
Server.
Is this possible?
Does documentation exist? 
I need to size this task so what are the steps from high level?
Any tips?
Thanks.
Jim S.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] CrytoPkg: GCC build failing after update to openssl-1.0.2g

[David Van Arnem]

On 03/23/2016 02:58 PM, Ard Biesheuvel wrote:

On 23 March 2016 at 21:39, David Van Arnem  wrote:

Hi all,

I pulled the UDK2015 branch from the Tianocore github repository today and
merged it into my local master branch so I have a stable release to base my
work off of.  Then, I

1. did a clean and rebuild of BaseTools,

2. downloaded openssl-1.0.2g, patched it, and installed using Install.sh

3. deleted the openssl headers from CryptoPkg/Include/openssl (they appear
to have been moved to
CryptoPkg/Library/OpensslLib/openssl-1.0.2g/include/openssl according to
CryptoPkg/Library/OpensslLib/Install.sh),

4. did "build cleanall".

However, then when I build CryptoPkg, I get the following error (apologies
for the formatting, I tried to break the lines up):

`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
defined in discarded section `COMMON' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)

`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
defined in discarded section `COMMON' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)

`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
defined in discarded section `COMMON' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)

GNUmakefile:384: recipe for target
'/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll'
failed

make: ***
[/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll]
Error 1

As the errors indicate, I'm building using GCC on Linux.  A search online
for this error didn't return any useful results.  I'm assuming something
with the merge may have messed up my local build, although git did not
indicate any merge conflicts.  Is there something else I may need to do to
make sure I'm building from a "clean" state?



You should verify whether your Conf/tools_def.txt file is up to date.
If you don't have any local changes, you can simply remove it and
re-run 'source edksetup.sh', and it will be regenerated based on
BaseTools/Conf/tools_def.template.


That was it, thank you.

David



Please refer to commit 214a3b79417f64bf2faae74af42c1b9d23f50dc8 for more details
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel




--
Thanks,
David Van Arnem

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

Re: [edk2] CrytoPkg: GCC build failing after update to openssl-1.0.2g

[David Van Arnem]

On 03/23/2016 02:39 PM, David Van Arnem wrote:

Hi all,

I pulled the UDK2015 branch from the Tianocore github repository today
and merged it into my local master branch so I have a stable release to
base my work off of.  Then, I

1. did a clean and rebuild of BaseTools,

2. downloaded openssl-1.0.2g, patched it, and installed using Install.sh

3. deleted the openssl headers from CryptoPkg/Include/openssl (they
appear to have been moved to
CryptoPkg/Library/OpensslLib/openssl-1.0.2g/include/openssl according to
CryptoPkg/Library/OpensslLib/Install.sh),

4. did "build cleanall".


Ugh, sorry for the noise.  This wasn't a CryptoPkg-specific problem, I 
needed an extra step here:


5. Delete the auto-generated files in Conf/* and regenerate with ". 
edksetup.sh"


All is working correctly now.

David



However, then when I build CryptoPkg, I get the following error
(apologies for the formatting, I tried to break the lines up):

`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
defined in discarded section `COMMON' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)


`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
defined in discarded section `COMMON' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)


`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
defined in discarded section `COMMON' of
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)


GNUmakefile:384: recipe for target
'/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll'
failed

make: ***
[/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll]
Error 1

As the errors indicate, I'm building using GCC on Linux.  A search
online for this error didn't return any useful results.  I'm assuming
something with the merge may have messed up my local build, although git
did not indicate any merge conflicts.  Is there something else I may
need to do to make sure I'm building from a "clean" state?

Thanks in advance for your time.



--
Thanks,
David Van Arnem

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

Re: [edk2] CrytoPkg: GCC build failing after update to openssl-1.0.2g

[Ard Biesheuvel]

On 23 March 2016 at 21:39, David Van Arnem  wrote:
> Hi all,
>
> I pulled the UDK2015 branch from the Tianocore github repository today and
> merged it into my local master branch so I have a stable release to base my
> work off of.  Then, I
>
> 1. did a clean and rebuild of BaseTools,
>
> 2. downloaded openssl-1.0.2g, patched it, and installed using Install.sh
>
> 3. deleted the openssl headers from CryptoPkg/Include/openssl (they appear
> to have been moved to
> CryptoPkg/Library/OpensslLib/openssl-1.0.2g/include/openssl according to
> CryptoPkg/Library/OpensslLib/Install.sh),
>
> 4. did "build cleanall".
>
> However, then when I build CryptoPkg, I get the following error (apologies
> for the formatting, I tried to break the lines up):
>
> `sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
> /home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
> defined in discarded section `COMMON' of
> /home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)
>
> `sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
> /home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
> defined in discarded section `COMMON' of
> /home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)
>
> `sig_app' referenced in section `.text.OBJ_find_sigid_algs' of
> /home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj):
> defined in discarded section `COMMON' of
> /home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)
>
> GNUmakefile:384: recipe for target
> '/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll'
> failed
>
> make: ***
> [/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll]
> Error 1
>
> As the errors indicate, I'm building using GCC on Linux.  A search online
> for this error didn't return any useful results.  I'm assuming something
> with the merge may have messed up my local build, although git did not
> indicate any merge conflicts.  Is there something else I may need to do to
> make sure I'm building from a "clean" state?
>

You should verify whether your Conf/tools_def.txt file is up to date.
If you don't have any local changes, you can simply remove it and
re-run 'source edksetup.sh', and it will be regenerated based on
BaseTools/Conf/tools_def.template.

Please refer to commit 214a3b79417f64bf2faae74af42c1b9d23f50dc8 for more details
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] CrytoPkg: GCC build failing after update to openssl-1.0.2g

[David Van Arnem]

Hi all,

I pulled the UDK2015 branch from the Tianocore github repository today 
and merged it into my local master branch so I have a stable release to 
base my work off of.  Then, I


1. did a clean and rebuild of BaseTools,

2. downloaded openssl-1.0.2g, patched it, and installed using Install.sh

3. deleted the openssl headers from CryptoPkg/Include/openssl (they 
appear to have been moved to 
CryptoPkg/Library/OpensslLib/openssl-1.0.2g/include/openssl according to 
CryptoPkg/Library/OpensslLib/Install.sh),


4. did "build cleanall".

However, then when I build CryptoPkg, I get the following error 
(apologies for the formatting, I tried to break the lines up):


`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of 
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj): 
defined in discarded section `COMMON' of 
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)


`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of 
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj): 
defined in discarded section `COMMON' of 
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)


`sig_app' referenced in section `.text.OBJ_find_sigid_algs' of 
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj): 
defined in discarded section `COMMON' of 
/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(obj_xref.obj)


GNUmakefile:384: recipe for target 
'/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll' 
failed


make: *** 
[/home/dvanarnem/edk2/Build/CryptoPkg/DEBUG_GCC49/X64/CryptoPkg/Application/Cryptest/Cryptest/DEBUG/Cryptest.dll] 
Error 1


As the errors indicate, I'm building using GCC on Linux.  A search 
online for this error didn't return any useful results.  I'm assuming 
something with the merge may have messed up my local build, although git 
did not indicate any merge conflicts.  Is there something else I may 
need to do to make sure I'm building from a "clean" state?


Thanks in advance for your time.
--
Thanks,
David Van Arnem

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

[edk2] Is EsrtDxe broken?

[Felix Poludov]

EsrtDxe publishes EsrtManagement protocol.
It has (among others) SyncEsrtFmp() and LockEsrtRepository() functions.

Here is the description of the functions from the protocol header file:
SyncEsrtFmp():
  This function syn up Cached ESRT with data from FMP instances
  Function should be called after Connect All in order to locate all FMP 
protocols installed
LockEsrtRepository():
  This function locks up Esrt repository to be readonly. It should be called
  before gEfiEndOfDxeEventGroupGuid event signaled

According to description LockEsrtRepository() has to be called before 
SyncEsrtFmp() because gEfiEndOfDxeEventGroupGuid event is signaled prior to 
connecting all the drivers.
However, once repository is locked it can no longer be updated, so 
SyncEsrtFmp() is guaranteed to fail.

Am I missing something?

Thanks
Felix

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EmulatorPkg build && run mode

[Jordan Justen]

On 2016-03-23 07:07:57, 王石磊 wrote:
>Hello EDK build Team:
>Well I now require help in building the EmulatorPkg on X64
>architecture.  According to the "README" file under EmulatorPKg Dir, I can
>build and run (./build.sh && ./build.sh run) EmulatorPkg , everythis is
>right and no exceptions or errors.  The following step change the Dir to
>EDKII WORKSPACE(envrionment variable setted up by edksetup.sh) ,run
>command "build run", I get the following errors:

The 'build run' command was not very well thought out. It basically
was a hack to launch the NT32 platform.

There is a related bug that was closed recently:

https://github.com/tianocore/edk2/issues/15

Yonghong or Liming, Do either of you have any thoughts about how to
make build run be more generic? (Support other operating systems.
Maybe allow the platform to specify the command to run?)

-Jordan

>build.py...
> : error 7000: Failed to start command
>.\SecMain
>[/home/vans/VansProjects/EDKII/Build/Emulator/DEBUG_GCC49/X64]
>also the followings:
>(Please send email to edk2-de...@lists.sourceforge.net for help, attaching
>following call stack trace!)
>(Python 2.7.8 on linux2) Traceback (most recent call last):
>  File
>
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>line 2047, in Main
>MyBuild.Launch()
>  File
>
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>line 1800, in Launch
>self._BuildPlatform()
>  File
>
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>line 1439, in _BuildPlatform
>self._BuildPa(self.Target, Pa)
>  File
>
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>line 954, in _BuildPa
>LaunchCommand(Command, RunDir)
>  File
>
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>line 297, in LaunchCommand
>if Proc.stdout:
>AttributeError: 'NoneType' object has no attribute 'stdout'
>so, I want to know  the difference of  the tow methods(./build.sh  VS
> build ) that  building  && running  EmulatorPkg, and some deep message
>about the error posted in front.
> 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message

[Alcantara, Paulo]

Forgot to add another S-b, sorry. Please add it:
 
Signed-off-by: Juliano Ciocari 

Thanks,

Paulo

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Alcantara, Paulo
Sent: quarta-feira, 23 de março de 2016 14:20
To: edk2-devel@lists.01.org
Cc: Feng Tian ; Star Zeng 
Subject: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message

s/Configutation/Configuration/

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara 
---
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
index 3329f90..ee5f6e6 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
@@ -15,7 +15,7 @@
 
 #langdef en-US  "English"
 
-#string STR_FORM_SET_TITLE #language en-US "RAM Disk Configutation"
+#string STR_FORM_SET_TITLE #language en-US "RAM Disk Configuration"
 #string STR_FORM_SET_TITLE_HELP#language en-US "Press  to 
add/remove RAM disks."
 
 #string STR_MAIN_FORM_TITLE#language en-US "RAM Disk HII Main 
Screen"
-- 
2.6.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg/RamDiskDxe: Fix typo in HII message

[Alcantara, Paulo]

s/Configutation/Configuration/

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara 
---
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
index 3329f90..ee5f6e6 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni
@@ -15,7 +15,7 @@
 
 #langdef en-US  "English"
 
-#string STR_FORM_SET_TITLE #language en-US "RAM Disk Configutation"
+#string STR_FORM_SET_TITLE #language en-US "RAM Disk Configuration"
 #string STR_FORM_SET_TITLE_HELP#language en-US "Press  to 
add/remove RAM disks."
 
 #string STR_MAIN_FORM_TITLE#language en-US "RAM Disk HII Main 
Screen"
-- 
2.6.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [wave 2 PATCH 0/3] OvmfPkg: enable 64-bit PCI MMIO

[Laszlo Ersek]

On 03/22/16 07:10, Jordan Justen wrote:
> o/ #2
> 
> Reviewed-by: Jordan Justen 

Many thanks. After version 2 of wave 1, I pushed this (= wave 2) as
well, commit range 8f35eb92c419..4f5eff819309.

Only wave 3 remains. I won't be poking you for reviews until next week! :)

Cheers!
Laszlo

> On 2016-03-14 05:52:57, Laszlo Ersek wrote:
>> Identical repost of
>> .
>>
>> Public branch:
>> .
>>
>> Cc: Gerd Hoffmann 
>> Cc: Jordan Justen 
>> Cc: Marcel Apfelbaum 
>> Cc: Thomas Lamprecht 
>> Ref: https://github.com/tianocore/edk2/issues/59
>>
>> Laszlo Ersek (3):
>>   OvmfPkg: PlatformPei: factor out GetFirstNonAddress()
>>   OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64
>> DXE
>>   OvmfPkg: PciHostBridgeLib: install 64-bit PCI host aperture
>>
>>  OvmfPkg/OvmfPkg.dec   |   5 +
>>  OvmfPkg/OvmfPkgIa32X64.dsc|   2 +
>>  OvmfPkg/OvmfPkgX64.dsc|   2 +
>>  OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf |   2 +
>>  OvmfPkg/PlatformPei/PlatformPei.inf   |   2 +
>>  OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c   |   7 ++
>>  OvmfPkg/PlatformPei/MemDetect.c   | 128 
>> +++-
>>  7 files changed, 147 insertions(+), 1 deletion(-)
>>
>> -- 
>> 1.8.3.1
>>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] [wave 1 PATCH v2 0/6] OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU tables

[Laszlo Ersek]

On 03/23/16 16:43, Jordan Justen wrote:
> Series Reviewed-by: Jordan Justen 

Thanks an awful lot for the reviews; pushed as 36e8e6992d0c..8f35eb92c419.

Cheers!
Laszlo

> On 2016-03-23 07:46:04, Laszlo Ersek wrote:
>> Version 2 of
>> .
>>
>> In this version, BDS notifies AcpiPlatformDxe by signaling an event
>> group, rather than by installing a non-standard protocol interface. This
>> was suggested by Jordan
>> .
>>
>> All patches except the last one had to be modified for this.
>>
>> The question (raised by Ard) of what exactly edk2 developers should put
>> into GUID and protocol headers should be discussed separately
>> ; in
>> this series I'm sticking with the current practice (both initializer for
>> static storage duration objects and the declaration with external
>> linkage).
>>
>> Public branch:
>> .
>>
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (6):
>>   OvmfPkg: OvmfPkg.dec: add horizontal whitespace under Guids and
>> Protocols
>>   OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid
>>   OvmfPkg: PlatformBdsLib: signal gRootBridgesConnectedEventGroupGuid
>>   ArmVirtPkg: PlatformIntelBdsLib: signal
>> gRootBridgesConnectedEventGroupGuid
>>   OvmfPkg: AcpiPlatformDxe: when PCI is enabled, wait for Platform BDS's
>> cue
>>   OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU
>> tables
>>
>>  OvmfPkg/OvmfPkg.dec|  19 +-
>>  ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |   1 +
>>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf|   4 +-
>>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf   |   6 +-
>>  OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf  |   1 +
>>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h |  18 ++
>>  OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h  |  33 
>>  ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  |   6 +
>>  OvmfPkg/AcpiPlatformDxe/EntryPoint.c   |  48 ++---
>>  OvmfPkg/AcpiPlatformDxe/PciDecoding.c  | 186 
>> 
>>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c|   4 +
>>  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c   |   6 +
>>  12 files changed, 287 insertions(+), 45 deletions(-)
>>  create mode 100644 OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h
>>  create mode 100644 OvmfPkg/AcpiPlatformDxe/PciDecoding.c
>>
>> -- 
>> 1.8.3.1
>>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Laszlo Ersek]

On 03/23/16 17:26, Ryan Harkin wrote:
> On 23 March 2016 at 16:24, Ryan Harkin  wrote:
>> On 23 March 2016 at 08:53, Laszlo Ersek  wrote:
>>> On 03/23/16 09:33, Ni, Ruiyu wrote:
 Laszlo,
 Since the patch below lets SerialDxe driver use the new introduced
 PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
 Would you mind to revert the check in @ 31ae446b
 --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO 
 depth?
>>>
>>> If I understand correctly, this series increases the terminal polling
>>> rate, so that cursor movement escape sequences (and other burst-like
>>> sequences) can be processed even with a receive fifo depth of 1. Hence
>>> 31ae446b should become unnecessary.
>>>
>>> If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
>>> your revert of 31ae446b -- on top of this series from Heyi --, and the
>>> cursor keys work with 31ae446b reverted, then I don't mind, sure.
>>>
>>
>> Unfortunately TC2 and Juno no longer with with 31ae446b reverted and
>> these 3 patches from the series applied.
> 
> I'm sure you would all work it out ok, but that should have been:
> 
> "Unfortunately TC2 and Juno no longer work with 31ae446b reverted and
> these 3 patches from the series applied."

Thank you very much for the feedback.

Ray, can you please work with Heyi, Ryan and others to analyze why this
series of Heyi's doesn't supplant 31ae446b?

And, until that is determined, could you please hold off on reverting
31ae446b?

Thank you,
Laszlo




>>
>> It's a shame, because it works on FVP models and copy/paste then works.
>>
>> I haven't made any investigations on what's going wrong.  But regular
>> ASCII keys work, control codes like cursor keys don't.  So it looks
>> like the old FIFO setting problem we discussed a few weeks ago.
>>
>>
>>> Thanks
>>> Laszlo
>>>

 Regards,
 Ray


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Heyi Guo
> Sent: Thursday, March 17, 2016 10:37 PM
> To: edk2-devel@lists.01.org
> Cc: Heyi Guo ; Tian, Feng ; 
> Zeng, Star 
> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth 
> with PCD
>
> Set UART receive FIFO depth with PCD instead of fixed number "1".
> The default value of PCD is also 1, so it makes no difference for
> platforms which do not explicitly set this PCD.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Heyi Guo 
> Cc: Feng Tian 
> Cc: Star Zeng 
> ---
> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> index 164060b..a1453bd 100644
> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> @@ -41,10 +41,11 @@
>   gEfiDevicePathProtocolGuid## PRODUCES
>
> [Pcd]
> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>
> [Depex]
>   TRUE
> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> index f5b3064..d2383e5 100644
> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> @@ -236,7 +236,7 @@ SerialReset (
>   //
>   // Set the Serial I/O mode
>   //
> -  This->Mode->ReceiveFifoDepth  = 1;
> +  This->Mode->ReceiveFifoDepth  = PcdGet16 
> (PcdUartDefaultReceiveFifoDepth);
>   This->Mode->Timeout   = 1000 * 1000;
>   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>   This->Mode->DataBits  = (UINT32) PcdGet8 
> (PcdUartDefaultDataBits);
> @@ -508,6 +508,7 @@ SerialDxeInitialize (
>   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
>   mSerialIoMode.StopBits = (UINT32) PcdGet8 

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ryan Harkin]

On 23 March 2016 at 16:24, Ryan Harkin  wrote:
> On 23 March 2016 at 08:53, Laszlo Ersek  wrote:
>> On 03/23/16 09:33, Ni, Ruiyu wrote:
>>> Laszlo,
>>> Since the patch below lets SerialDxe driver use the new introduced
>>> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
>>> Would you mind to revert the check in @ 31ae446b
>>> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?
>>
>> If I understand correctly, this series increases the terminal polling
>> rate, so that cursor movement escape sequences (and other burst-like
>> sequences) can be processed even with a receive fifo depth of 1. Hence
>> 31ae446b should become unnecessary.
>>
>> If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
>> your revert of 31ae446b -- on top of this series from Heyi --, and the
>> cursor keys work with 31ae446b reverted, then I don't mind, sure.
>>
>
> Unfortunately TC2 and Juno no longer with with 31ae446b reverted and
> these 3 patches from the series applied.

I'm sure you would all work it out ok, but that should have been:

"Unfortunately TC2 and Juno no longer work with 31ae446b reverted and
these 3 patches from the series applied."


>
> It's a shame, because it works on FVP models and copy/paste then works.
>
> I haven't made any investigations on what's going wrong.  But regular
> ASCII keys work, control codes like cursor keys don't.  So it looks
> like the old FIFO setting problem we discussed a few weeks ago.
>
>
>> Thanks
>> Laszlo
>>
>>>
>>> Regards,
>>> Ray
>>>
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
 Heyi Guo
 Sent: Thursday, March 17, 2016 10:37 PM
 To: edk2-devel@lists.01.org
 Cc: Heyi Guo ; Tian, Feng ; 
 Zeng, Star 
 Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
 PCD

 Set UART receive FIFO depth with PCD instead of fixed number "1".
 The default value of PCD is also 1, so it makes no difference for
 platforms which do not explicitly set this PCD.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo 
 Cc: Feng Tian 
 Cc: Star Zeng 
 ---
 MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
 MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

 diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
 b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
 index 164060b..a1453bd 100644
 --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
 +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
 @@ -41,10 +41,11 @@
   gEfiDevicePathProtocolGuid## PRODUCES

 [Pcd]
 -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
 -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
 -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
 -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
 +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
 +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
 +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
 +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
 +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES

 [Depex]
   TRUE
 diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
 b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
 index f5b3064..d2383e5 100644
 --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
 +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
 @@ -236,7 +236,7 @@ SerialReset (
   //
   // Set the Serial I/O mode
   //
 -  This->Mode->ReceiveFifoDepth  = 1;
 +  This->Mode->ReceiveFifoDepth  = PcdGet16 
 (PcdUartDefaultReceiveFifoDepth);
   This->Mode->Timeout   = 1000 * 1000;
   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
   This->Mode->DataBits  = (UINT32) PcdGet8 
 (PcdUartDefaultDataBits);
 @@ -508,6 +508,7 @@ SerialDxeInitialize (
   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
   mSerialIoMode.StopBits = (UINT32) PcdGet8 (PcdUartDefaultStopBits);
 +  mSerialIoMode.ReceiveFifoDepth = PcdGet16 
 (PcdUartDefaultReceiveFifoDepth);
   mSerialDevicePath.Uart.BaudRate = PcdGet64 (PcdUartDefaultBaudRate);
   mSerialDevicePath.Uart.DataBits = PcdGet8 (PcdUartDefaultDataBits);
   mSerialDevicePath.Uart.Parity   = PcdGet8 (PcdUartDefaultParity);
 --
 2.7.0

 ___
 

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ryan Harkin]

On 23 March 2016 at 08:53, Laszlo Ersek  wrote:
> On 03/23/16 09:33, Ni, Ruiyu wrote:
>> Laszlo,
>> Since the patch below lets SerialDxe driver use the new introduced
>> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
>> Would you mind to revert the check in @ 31ae446b
>> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?
>
> If I understand correctly, this series increases the terminal polling
> rate, so that cursor movement escape sequences (and other burst-like
> sequences) can be processed even with a receive fifo depth of 1. Hence
> 31ae446b should become unnecessary.
>
> If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
> your revert of 31ae446b -- on top of this series from Heyi --, and the
> cursor keys work with 31ae446b reverted, then I don't mind, sure.
>

Unfortunately TC2 and Juno no longer with with 31ae446b reverted and
these 3 patches from the series applied.

It's a shame, because it works on FVP models and copy/paste then works.

I haven't made any investigations on what's going wrong.  But regular
ASCII keys work, control codes like cursor keys don't.  So it looks
like the old FIFO setting problem we discussed a few weeks ago.


> Thanks
> Laszlo
>
>>
>> Regards,
>> Ray
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Thursday, March 17, 2016 10:37 PM
>>> To: edk2-devel@lists.01.org
>>> Cc: Heyi Guo ; Tian, Feng ; Zeng, 
>>> Star 
>>> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>>> PCD
>>>
>>> Set UART receive FIFO depth with PCD instead of fixed number "1".
>>> The default value of PCD is also 1, so it makes no difference for
>>> platforms which do not explicitly set this PCD.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Heyi Guo 
>>> Cc: Feng Tian 
>>> Cc: Star Zeng 
>>> ---
>>> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
>>> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> index 164060b..a1453bd 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> @@ -41,10 +41,11 @@
>>>   gEfiDevicePathProtocolGuid## PRODUCES
>>>
>>> [Pcd]
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>>>
>>> [Depex]
>>>   TRUE
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> index f5b3064..d2383e5 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> @@ -236,7 +236,7 @@ SerialReset (
>>>   //
>>>   // Set the Serial I/O mode
>>>   //
>>> -  This->Mode->ReceiveFifoDepth  = 1;
>>> +  This->Mode->ReceiveFifoDepth  = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   This->Mode->Timeout   = 1000 * 1000;
>>>   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>>>   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>> @@ -508,6 +508,7 @@ SerialDxeInitialize (
>>>   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
>>>   mSerialIoMode.StopBits = (UINT32) PcdGet8 (PcdUartDefaultStopBits);
>>> +  mSerialIoMode.ReceiveFifoDepth = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   mSerialDevicePath.Uart.BaudRate = PcdGet64 (PcdUartDefaultBaudRate);
>>>   mSerialDevicePath.Uart.DataBits = PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialDevicePath.Uart.Parity   = PcdGet8 (PcdUartDefaultParity);
>>> --
>>> 2.7.0
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [wave 1 PATCH v2 0/6] OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU tables

[Jordan Justen]

Series Reviewed-by: Jordan Justen 

On 2016-03-23 07:46:04, Laszlo Ersek wrote:
> Version 2 of
> .
> 
> In this version, BDS notifies AcpiPlatformDxe by signaling an event
> group, rather than by installing a non-standard protocol interface. This
> was suggested by Jordan
> .
> 
> All patches except the last one had to be modified for this.
> 
> The question (raised by Ard) of what exactly edk2 developers should put
> into GUID and protocol headers should be discussed separately
> ; in
> this series I'm sticking with the current practice (both initializer for
> static storage duration objects and the declaration with external
> linkage).
> 
> Public branch:
> .
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (6):
>   OvmfPkg: OvmfPkg.dec: add horizontal whitespace under Guids and
> Protocols
>   OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid
>   OvmfPkg: PlatformBdsLib: signal gRootBridgesConnectedEventGroupGuid
>   ArmVirtPkg: PlatformIntelBdsLib: signal
> gRootBridgesConnectedEventGroupGuid
>   OvmfPkg: AcpiPlatformDxe: when PCI is enabled, wait for Platform BDS's
> cue
>   OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU
> tables
> 
>  OvmfPkg/OvmfPkg.dec|  19 +-
>  ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |   1 +
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf|   4 +-
>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf   |   6 +-
>  OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf  |   1 +
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h |  18 ++
>  OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h  |  33 
>  ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  |   6 +
>  OvmfPkg/AcpiPlatformDxe/EntryPoint.c   |  48 ++---
>  OvmfPkg/AcpiPlatformDxe/PciDecoding.c  | 186 
> 
>  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c|   4 +
>  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c   |   6 +
>  12 files changed, 287 insertions(+), 45 deletions(-)
>  create mode 100644 OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/PciDecoding.c
> 
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Make the USB mouse behavior in 'edit' consistent with 'hexedit'.

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Qiu, Shumin
> Sent: Tuesday, March 22, 2016 1:36 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH] ShellPkg: Make the USB mouse behavior in 'edit' consistent
> with 'hexedit'.
> Importance: High
> 
> 1. Make the USB mouse cursor move smoothly in 'edit'.
> 2. Make the USB mouse can drag and select text in 'edit'.
> 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 
> ---
>  .../UefiShellDebug1CommandsLib/Edit/FileBuffer.c   | 329
> +++--
>  .../UefiShellDebug1CommandsLib/Edit/FileBuffer.h   |  12 +-
>  .../Edit/MainTextEditor.c  | 166 ++-
>  .../UefiShellDebug1CommandsLib/Edit/TextEditor.h   |   3 +-
>  .../Edit/TextEditorTypes.h |   9 +-
>  5 files changed, 480 insertions(+), 39 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> index acd8512..fb0c76e 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> @@ -1,7 +1,7 @@
>  /** @file
>Implements filebuffer interface functions.
> 
> -  Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved. 
> +  Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved. 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at
> @@ -257,6 +257,71 @@ MoveLine (
>  }
> 
>  /**
> +  Decide if a point is in the already selected area.
> +
> +  @param[in] MouseRow The row of the point to test.
> +  @param[in] MouseCol The col of the point to test.
> +
> +  @retval TRUE  The point is in the selected area.
> +  @retval FALSE The point is not in the selected area.
> +**/
> +BOOLEAN
> +FileBufferIsInSelectedArea (
> +  IN UINTN MouseRow,
> +  IN UINTN MouseCol
> +  )
> +{
> +  UINTN FRow;
> +  UINTN RowStart;
> +  UINTN RowEnd;
> +  UINTN ColStart;
> +  UINTN ColEnd;
> +  UINTN MouseColStart;
> +  UINTN MouseColEnd;
> +
> +  //
> +  // judge mouse position whether is in selected area
> +  //
> +  //
> +  // not select
> +  //
> +  if (MainEditor.SelectStart == 0 || MainEditor.SelectEnd == 0) {
> +return FALSE;
> +  }
> +  //
> +  // calculate the select area
> +  //
> +  RowStart  = (MainEditor.SelectStart - 1) / SHELL_EDIT_MAX_LINE_SIZE + 1;
> +  RowEnd= (MainEditor.SelectEnd - 1) / SHELL_EDIT_MAX_LINE_SIZE + 1;
> +
> +  ColStart  = (MainEditor.SelectStart - 1) % SHELL_EDIT_MAX_LINE_SIZE + 1;
> +  ColEnd= (MainEditor.SelectEnd - 1) % SHELL_EDIT_MAX_LINE_SIZE + 1;
> +
> +  FRow  = FileBuffer.LowVisibleRange.Row + MouseRow - 2;
> +  if (FRow < RowStart || FRow > RowEnd) {
> +return FALSE;
> +  }
> +
> +  if (FRow > RowStart) {
> +ColStart = 1;
> +  }
> +
> +  if (FRow < RowEnd) {
> +ColEnd = SHELL_EDIT_MAX_LINE_SIZE;
> +  }
> +
> +  MouseColStart = ColStart;
> +
> +  MouseColEnd = ColEnd;
> +
> +  if (MouseCol < MouseColStart || MouseCol > MouseColEnd) {
> +return FALSE;
> +  }
> +
> +  return TRUE;
> +}
> +
> +/**
>Function to update the 'screen' to display the mouse position.
> 
>@retval EFI_SUCCESS   The backup operation was successful.
> @@ -311,6 +376,29 @@ FileBufferRestoreMousePosition (
> 
>FColumn   = FileBuffer.LowVisibleRange.Column +
> FileBufferBackupVar.MousePosition.Column - 1;
> 
> +  if (FRow <= FileBuffer.NumLines) {
> +CurrentLine = FileBuffer.CurrentLine;
> +Line= MoveLine (FRow - FileBuffer.FilePosition.Row);
> +FileBuffer.CurrentLine = CurrentLine;
> +  }
> +
> +  //
> +  // if in selected area,
> +  // so do not need to refresh mouse
> +  //
> +  if (!FileBufferIsInSelectedArea (
> +FileBufferBackupVar.MousePosition.Row,
> +FileBufferBackupVar.MousePosition.Column
> +) ||
> +  (Line == NULL || FColumn > Line->Size)
> +  ) {
> +gST->ConOut->SetAttribute (gST->ConOut, Orig.Data);
> +  } else {
> +gST->ConOut->SetAttribute (gST->ConOut, New.Data & 0x7F);
> +  }
> +
> +  Line = NULL;
> +
>HasCharacter  = TRUE;
>if (FRow > FileBuffer.NumLines) {
>  HasCharacter = FALSE;
> @@ -343,8 +431,15 @@ FileBufferRestoreMousePosition (
>//
>// set the new mouse position
>//
> -  gST->ConOut->SetAttribute (gST->ConOut, New.Data & 0x7F);
> -
> +  if (!FileBufferIsInSelectedArea (
> +FileBuffer.MousePosition.Row,
> +FileBuffer.MousePosition.Column
> +)
> +  ) {
> +

Re: [edk2] EmulatorPkg build && run mode

[Andrew Fish]

> On Mar 23, 2016, at 7:07 AM, 王石磊  wrote:
> 
> Hello EDK build Team:
> Well I now require help in building the EmulatorPkg on X64 
> architecture.  According to the "README" file under EmulatorPKg Dir, I can 
> build and run (./build.sh && ./build.sh run) EmulatorPkg , everythis is right 
> and no exceptions or errors.  The following step change the Dir to EDKII 
> WORKSPACE(envrionment variable setted up by edksetup.sh) ,run command "build 
> run", I get the following errors:
> 
> build.py...
>  : error 7000: Failed to start command
> .\SecMain 
> [/home/vans/VansProjects/EDKII/Build/Emulator/DEBUG_GCC49/X64]
> 
> also the followings:
> (Please send email to edk2-de...@lists.sourceforge.net 
>  for help, attaching following call 
> stack trace!)
> 
> (Python 2.7.8 on linux2) Traceback (most recent call last):
>   File 
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 2047, in Main
> MyBuild.Launch()
>   File 
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 1800, in Launch
> self._BuildPlatform()
>   File 
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 1439, in _BuildPlatform
> self._BuildPa(self.Target, Pa)
>   File 
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 954, in _BuildPa
> LaunchCommand(Command, RunDir)
>   File 
> "/home/vans/VansProjects/EDKII/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 297, in LaunchCommand
> if Proc.stdout:
> AttributeError: 'NoneType' object has no attribute 'stdout'
> 
> so, I want to know  the difference of  the tow methods(./build.sh  VS  build 
> ) that  building  && running  EmulatorPkg, and some deep message about the 
> error posted in front.
> 
> 

Actually if you look at the ./build.py script it does not look like it calls 
build if you pass in the argument run. It looks like you may have typed `build 
run` vs. `./build.sh run`. If you type `./build.sh run` do you still get an 
error message from build.py?

`build run` only works with NT32 and it is not used by the EmulatorPkg.  

Thanks,

Andrew Fish

>  

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

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

[Shivamurthy Shastri]

Driver code is modified to support multiple ethernet dongles, which uses
similar ASIX chips. Also, it can be used for multiple ASIX chips with
similar register map.

Enabled support for Apple Ethernet Adapter

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shivamurthy Shastri 
---
 .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h   | 16 ---
 .../Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c | 33 +-
 2 files changed, 32 insertions(+), 17 deletions(-)

diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h 
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
index ab75ec2..286bdab 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
@@ -141,9 +141,6 @@
 
 #define DEV_SIGNATURE SIGNATURE_32 ('A','X','8','8')  ///<  Signature of 
data structures in memory
 
-#define VENDOR_ID 0x0B95  ///<  Vendor ID for Asix
-#define PRODUCT_ID0x772B  ///<  Product ID for the AX88772 USB 10/100 
Ethernet controller
-
 #define RESET_MSEC1000///<  Reset duration
 #define PHY_RESET_MSEC 500///<  PHY reset duration
 
@@ -297,12 +294,23 @@
 #define AN_10_HDX   0x0020  ///<  1 = 10BASE-T support
 #define AN_CSMA_CD  0x0001  ///<  1 = IEEE 802.3 CSMA/CD 
support
 
-
+// asix_flags defines
+#define FLAG_NONE   0
+#define FLAG_TYPE_AX88172   BIT0
+#define FLAG_TYPE_AX88772   BIT1
+#define FLAG_TYPE_AX88772B  BIT2
+#define FLAG_EEPROM_MAC BIT3  // initial mac address in eeprom
 
 
//--
 //  Data Types
 
//--
 
+typedef struct {
+   UINT16  VendorId;
+   UINT16  ProductId;
+   INT32   Flags;
+}ASIX_DONGLE;
+
 /**
   Ethernet header layout
 
diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c 
b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
index 3b73040..5aed2ec 100644
--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
@@ -14,6 +14,13 @@
 
 #include "Ax88772.h"
 
+ASIX_DONGLE ASIX_DONGLES[] = {
+  { 0x05AC, 0x1402, FLAG_TYPE_AX88772 }, // Apple USB Ethernet Adapter
+  // ASIX 88772B
+  { 0x0B95, 0x772B, FLAG_TYPE_AX88772B | FLAG_EEPROM_MAC },
+  { 0x, 0x, FLAG_NONE }   // END - Do not remove
+};
+
 /**
   Verify the controller type
 
@@ -36,6 +43,8 @@ DriverSupported (
   EFI_USB_DEVICE_DESCRIPTOR Device;
   EFI_USB_IO_PROTOCOL * pUsbIo;
   EFI_STATUS Status;
+  UINT32 Index;
+
   //
   //  Connect to the USB stack
   //
@@ -60,19 +69,17 @@ DriverSupported (
 else {
   //
   //  Validate the adapter
-  //   
-  if ( VENDOR_ID == Device.IdVendor ) {
-
-if (PRODUCT_ID == Device.IdProduct) {
-DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
-}
-   else  {
-Status = EFI_UNSUPPORTED;
-   }
-  }
-   else {
- Status = EFI_UNSUPPORTED;
-   }   
+  //
+  for (Index = 0; ASIX_DONGLES[Index].VendorId != 0; Index++) {
+if (ASIX_DONGLES[Index].VendorId == Device.IdVendor &&
+ASIX_DONGLES[Index].ProductId == Device.IdProduct) {
+  DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
+  break;
+}
+  }
+
+  if (ASIX_DONGLES[Index].VendorId == 0)
+ Status = EFI_UNSUPPORTED;
 }

 //
-- 
1.9.1

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

Re: [edk2] [wave 1 PATCH v2 4/6] ArmVirtPkg: PlatformIntelBdsLib: signal gRootBridgesConnectedEventGroupGuid

[Ard Biesheuvel]

On 23 March 2016 at 15:46, Laszlo Ersek  wrote:
> The explanation is in the patch titled
>
>   OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid
>
> At this point, this signal doesn't do anything yet.
>
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>
> Notes:
> v2:
> - replace protocol with event group [Jordan]
>
>  ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf | 1 +
>  ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 6 ++
>  2 files changed, 7 insertions(+)
>
> diff --git a/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf 
> b/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
> index 79ba7b2afbf7..f104accc0334 100644
> --- a/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
> +++ b/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
> @@ -67,14 +67,15 @@ [Pcd]
>gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer
>
>  [Guids]
>gEfiFileInfoGuid
>gEfiFileSystemInfoGuid
>gEfiFileSystemVolumeLabelInfoIdGuid
>gEfiEndOfDxeEventGroupGuid
> +  gRootBridgesConnectedEventGroupGuid
>
>  [Protocols]
>gEfiDevicePathProtocolGuid
>gEfiGraphicsOutputProtocolGuid
>gEfiLoadedImageProtocolGuid
>gEfiPciRootBridgeIoProtocolGuid
>gEfiSimpleFileSystemProtocolGuid
> diff --git a/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c 
> b/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> index 9267a188e810..02d698b455b3 100644
> --- a/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> +++ b/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> @@ -21,14 +21,15 @@
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "IntelBdsPlatform.h"
>
>  #define DP_NODE_LEN(Type) { (UINT8)sizeof (Type), (UINT8)(sizeof (Type) >> 
> 8) }
>
>
>  #pragma pack (1)
> @@ -366,14 +367,19 @@ PlatformBdsPolicyBehavior (
>// Locate the PCI root bridges and make the PCI bus driver connect each,
>// non-recursively. This will produce a number of child handles with PciIo 
> on
>// them.
>//
>FilterAndProcess (, NULL, Connect);
>
>//
> +  // Signal the ACPI platform driver that it can download QEMU ACPI tables.
> +  //
> +  EfiEventGroupSignal ();
> +
> +  //
>// Find all display class PCI devices (using the handles from the previous
>// step), and connect them non-recursively. This should produce a number of
>// child handles with GOPs on them.
>//
>FilterAndProcess (, IsPciDisplay, Connect);
>
>//
> --
> 1.8.3.1
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [wave 1 PATCH v2 5/6] OvmfPkg: AcpiPlatformDxe: when PCI is enabled, wait for Platform BDS's cue

[Laszlo Ersek]

This patch doesn't change the behavior of AcpiPlatformDxe when
PcdPciDisableBusEnumeration is TRUE -- that is, when the driver runs on
Xen (OvmfPkg and ArmVirtPkg both), or when the driver runs on QEMU as part
of ArmVirtPkg but no PCI host bridge was found by VirtFdtDxe. In these
cases the driver continues to install the ACPI tables immediately.

However, when PcdPciDisableBusEnumeration is FALSE (i.e., when the driver
runs on QEMU as part of OVMF, or as part of ArmVirtPkg and VirtFdtDxe
finds a PCI host bridge), we now delay the ACPI table download from QEMU.
We wait until the Platform BDS tells us that root bridges have been
connected, and PciIo instances are available.

The explanation is in the patch titled

  OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- replace protocol with event group [Jordan]

 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf  |  2 +-
 OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf |  4 +-
 OvmfPkg/AcpiPlatformDxe/EntryPoint.c | 48 ++--
 3 files changed, 18 insertions(+), 36 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 055f3ad0ee0f..8e98053994eb 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -53,18 +53,18 @@ [LibraryClasses]
   MemoryAllocationLib
   BaseLib
   DxeServicesTableLib
   OrderedCollectionLib
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
-  gEfiPciEnumerationCompleteProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
 
 [Guids]
   gEfiXenInfoGuid
+  gRootBridgesConnectedEventGroupGuid
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
   gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
index 22ce165852f9..c073b2a47ec6 100644
--- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
@@ -43,14 +43,16 @@ [LibraryClasses]
   OrderedCollectionLib
   QemuFwCfgLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
-  gEfiPciEnumerationCompleteProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
+
+[Guids]
+  gRootBridgesConnectedEventGroupGuid
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
 
 [Depex]
   gEfiAcpiTableProtocolGuid
diff --git a/OvmfPkg/AcpiPlatformDxe/EntryPoint.c 
b/OvmfPkg/AcpiPlatformDxe/EntryPoint.c
index d713b0d44b1b..1bfd31a0371a 100644
--- a/OvmfPkg/AcpiPlatformDxe/EntryPoint.c
+++ b/OvmfPkg/AcpiPlatformDxe/EntryPoint.c
@@ -9,15 +9,15 @@
   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 "AcpiPlatform.h"
 
 STATIC
 EFI_ACPI_TABLE_PROTOCOL *
 FindAcpiTableProtocol (
   VOID
   )
@@ -34,22 +34,23 @@ FindAcpiTableProtocol (
   return AcpiTable;
 }
 
 
 STATIC
 VOID
 EFIAPI
-OnPciEnumerated (
+OnRootBridgesConnected (
   IN EFI_EVENT Event,
   IN VOID  *Context
   )
 {
   EFI_STATUS Status;
 
-  DEBUG ((EFI_D_INFO, "%a: PCI enumeration complete, installing ACPI tables\n",
+  DEBUG ((EFI_D_INFO,
+"%a: root bridges have been connected, installing ACPI tables\n",
 __FUNCTION__));
   Status = InstallAcpiTables (FindAcpiTableProtocol ());
   if (EFI_ERROR (Status)) {
 DEBUG ((EFI_D_ERROR, "%a: InstallAcpiTables: %r\n", __FUNCTION__, Status));
   }
   gBS->CloseEvent (Event);
 }
@@ -59,58 +60,37 @@ EFI_STATUS
 EFIAPI
 AcpiPlatformEntryPoint (
   IN EFI_HANDLE ImageHandle,
   IN EFI_SYSTEM_TABLE   *SystemTable
   )
 {
   EFI_STATUS Status;
-  VOID   *Interface;
-  EFI_EVENT  PciEnumerated;
-  VOID   *Registration;
+  EFI_EVENT  RootBridgesConnected;
 
   //
   // If the platform doesn't support PCI, or PCI enumeration has been disabled,
   // install the tables at once, and let the entry point's return code reflect
   // the full functionality.
   //
   if (PcdGetBool (PcdPciDisableBusEnumeration)) {
 DEBUG ((EFI_D_INFO, "%a: PCI or its enumeration disabled, installing "
   "ACPI tables\n", __FUNCTION__));
 return InstallAcpiTables (FindAcpiTableProtocol ());
   }
 
   //
-  // Similarly, if PCI enumeration has already completed, install the 

[edk2] [wave 1 PATCH v2 1/6] OvmfPkg: OvmfPkg.dec: add horizontal whitespace under Guids and Protocols

[Laszlo Ersek]

We'll need more room in the next patch. No functional changes.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2

 OvmfPkg/OvmfPkg.dec | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 784542f62368..c04a6f4afd7f 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -49,25 +49,25 @@ [LibraryClasses]
   XenHypercallLib|Include/Library/XenHypercallLib.h
 
   ##  @libraryclass  Manage XenBus device path and I/O handles
   #
   XenIoMmioLib|Include/Library/XenIoMmioLib.h
 
 [Guids]
-  gUefiOvmfPkgTokenSpaceGuid  = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 0x62, 
0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
-  gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12, 
0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
-  gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac, 
0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
-  gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a, 
0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
-  gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 
0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
+  gUefiOvmfPkgTokenSpaceGuid  = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 
0x62, 0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
+  gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
+  gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 
0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
+  gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+  gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
 
 [Protocols]
-  gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec, 
0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
-  gBlockMmioProtocolGuid  = {0x6b558ce3, 0x69e5, 0x4c67, {0xa6, 0x34, 
0xf7, 0xfe, 0x72, 0xad, 0xbe, 0x84}}
-  gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 0x5d, 
0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
-  gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe, 
0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
+  gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 
0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
+  gBlockMmioProtocolGuid  = {0x6b558ce3, 0x69e5, 0x4c67, {0xa6, 
0x34, 0xf7, 0xfe, 0x72, 0xad, 0xbe, 0x84}}
+  gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 
0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
+  gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
 
 [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize|0x0|UINT32|1
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|0x0|UINT32|0x15
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize|0x0|UINT32|0x16
 
-- 
1.8.3.1


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

[edk2] [wave 1 PATCH v2 4/6] ArmVirtPkg: PlatformIntelBdsLib: signal gRootBridgesConnectedEventGroupGuid

[Laszlo Ersek]

The explanation is in the patch titled

  OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid

At this point, this signal doesn't do anything yet.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- replace protocol with event group [Jordan]

 ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf | 1 +
 ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf 
b/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
index 79ba7b2afbf7..f104accc0334 100644
--- a/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
+++ b/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
@@ -67,14 +67,15 @@ [Pcd]
   gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer
 
 [Guids]
   gEfiFileInfoGuid
   gEfiFileSystemInfoGuid
   gEfiFileSystemVolumeLabelInfoIdGuid
   gEfiEndOfDxeEventGroupGuid
+  gRootBridgesConnectedEventGroupGuid
 
 [Protocols]
   gEfiDevicePathProtocolGuid
   gEfiGraphicsOutputProtocolGuid
   gEfiLoadedImageProtocolGuid
   gEfiPciRootBridgeIoProtocolGuid
   gEfiSimpleFileSystemProtocolGuid
diff --git a/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c 
b/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
index 9267a188e810..02d698b455b3 100644
--- a/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
+++ b/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
@@ -21,14 +21,15 @@
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "IntelBdsPlatform.h"
 
 #define DP_NODE_LEN(Type) { (UINT8)sizeof (Type), (UINT8)(sizeof (Type) >> 8) }
 
 
 #pragma pack (1)
@@ -366,14 +367,19 @@ PlatformBdsPolicyBehavior (
   // Locate the PCI root bridges and make the PCI bus driver connect each,
   // non-recursively. This will produce a number of child handles with PciIo on
   // them.
   //
   FilterAndProcess (, NULL, Connect);
 
   //
+  // Signal the ACPI platform driver that it can download QEMU ACPI tables.
+  //
+  EfiEventGroupSignal ();
+
+  //
   // Find all display class PCI devices (using the handles from the previous
   // step), and connect them non-recursively. This should produce a number of
   // child handles with GOPs on them.
   //
   FilterAndProcess (, IsPciDisplay, Connect);
 
   //
-- 
1.8.3.1


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

[edk2] [wave 1 PATCH v2 3/6] OvmfPkg: PlatformBdsLib: signal gRootBridgesConnectedEventGroupGuid

[Laszlo Ersek]

The explanation is in the patch titled

  OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid

At this point, this signal doesn't do anything yet.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- replace protocol with event group [Jordan]

 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf | 1 +
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c  | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf 
b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
index ab5468368da5..6a04b458032f 100644
--- a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
+++ b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
@@ -66,7 +66,8 @@ [Protocols]
   gEfiDecompressProtocolGuid
   gEfiPciRootBridgeIoProtocolGuid
   gEfiS3SaveStateProtocolGuid   # PROTOCOL SOMETIMES_CONSUMED
   gEfiDxeSmmReadyToLockProtocolGuid # PROTOCOL SOMETIMES_PRODUCED
 
 [Guids]
   gEfiEndOfDxeEventGroupGuid
+  gRootBridgesConnectedEventGroupGuid
diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
index 4a2f7f332d34..0bc02baf0371 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
@@ -9,14 +9,15 @@
 
   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 "BdsPlatform.h"
+#include 
 #include 
 
 
 //
 // Global data
 //
 
@@ -1241,14 +1242,19 @@ Returns:
 
   DEBUG ((EFI_D_INFO, "PlatformBdsPolicyBehavior\n"));
 
   VisitAllInstancesOfProtocol (,
 ConnectRootBridge, NULL);
 
   //
+  // Signal the ACPI platform driver that it can download QEMU ACPI tables.
+  //
+  EfiEventGroupSignal ();
+
+  //
   // We can't signal End-of-Dxe earlier than this. Namely, End-of-Dxe triggers
   // the preparation of S3 system information. That logic has a hard dependency
   // on the presence of the FACS ACPI table. Since our ACPI tables are only
   // installed after PCI enumeration completes, we must not trigger the S3 save
   // earlier, hence we can't signal End-of-Dxe earlier.
   //
   EfiEventGroupSignal ();
-- 
1.8.3.1


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

[edk2] [wave 1 PATCH v2 6/6] OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU tables

[Laszlo Ersek]

Now that the previous patches ensure that we can access all PCI devices in
AcpiPlatformDxe, we can enable IO and MMIO decoding for all of them while
we contact QEMU for the ACPI tables. See more details in the patch titled:

  OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid

In particular, this patch will prevent the bug when the 64-bit MMIO
aperture is completely missing from QEMU's _CRS, and consequently Linux
rejects 64-bit BARs with the error message

  pci :00:03.0: can't claim BAR 4 [mem 0x8-0x8007f 64bit
pref]: no compatible bridge window

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf  |   2 +
 OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf |   2 +
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h   |  18 ++
 OvmfPkg/AcpiPlatformDxe/PciDecoding.c| 186 
 OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c  |   4 +
 5 files changed, 212 insertions(+)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 8e98053994eb..654d3a03905d 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -28,14 +28,15 @@ [Defines]
 
 [Sources]
   AcpiPlatform.c
   Qemu.c
   QemuFwCfgAcpi.c
   Xen.c
   EntryPoint.c
+  PciDecoding.c
 
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   OvmfPkg/OvmfPkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
   PcAtChipsetPkg/PcAtChipsetPkg.dec
@@ -53,14 +54,15 @@ [LibraryClasses]
   MemoryAllocationLib
   BaseLib
   DxeServicesTableLib
   OrderedCollectionLib
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
+  gEfiPciIoProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
 
 [Guids]
   gEfiXenInfoGuid
   gRootBridgesConnectedEventGroupGuid
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
index c073b2a47ec6..d99f2d5a95c7 100644
--- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
@@ -26,14 +26,15 @@ [Defines]
 #  VALID_ARCHITECTURES   = IA32 X64 ARM AARCH64
 #
 
 [Sources]
   QemuFwCfgAcpiPlatform.c
   QemuFwCfgAcpi.c
   EntryPoint.c
+  PciDecoding.c
 
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
@@ -43,14 +44,15 @@ [LibraryClasses]
   OrderedCollectionLib
   QemuFwCfgLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
+  gEfiPciIoProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
 
 [Guids]
   gRootBridgesConnectedEventGroupGuid
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
 
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index 55b380b28505..08dd7f8f7dd7 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -15,22 +15,28 @@
 #ifndef _ACPI_PLATFORM_H_INCLUDED_
 #define _ACPI_PLATFORM_H_INCLUDED_
 
 #include 
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 
 #include 
 
+typedef struct {
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  UINT64  PciAttributes;
+} ORIGINAL_ATTRIBUTES;
+
 EFI_STATUS
 EFIAPI
 InstallAcpiTable (
   IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol,
   IN   VOID  *AcpiTableBuffer,
   IN   UINTN AcpiTableBufferSize,
   OUT  UINTN *TableKey
@@ -69,9 +75,21 @@ InstallQemuFwCfgTables (
 
 EFI_STATUS
 EFIAPI
 InstallAcpiTables (
   IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiTable
   );
 
+VOID
+EnablePciDecoding (
+  OUT ORIGINAL_ATTRIBUTES **OriginalAttributes,
+  OUT UINTN   *Count
+  );
+
+VOID
+RestorePciDecoding (
+  IN ORIGINAL_ATTRIBUTES *OriginalAttributes,
+  IN UINTN   Count
+  );
+
 #endif
 
diff --git a/OvmfPkg/AcpiPlatformDxe/PciDecoding.c 
b/OvmfPkg/AcpiPlatformDxe/PciDecoding.c
new file mode 100644
index ..3b9b12ccc8a6
--- /dev/null
+++ b/OvmfPkg/AcpiPlatformDxe/PciDecoding.c
@@ -0,0 +1,186 @@
+/** @file
+  Temporarily enable IO and MMIO decoding for all PCI devices while QEMU
+  regenerates the ACPI tables.
+
+  Copyright (C) 2016, Red Hat, Inc.
+
+  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 

[edk2] [wave 1 PATCH v2 2/6] OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid

[Laszlo Ersek]

QEMU's ACPI table generator can only create meaningful _CRS objects --
apertures -- for the root buses if all of the PCI devices behind those
buses are actively decoding their IO and MMIO resources, at the time of
the firmware fetching the "etc/table-loader" fw_cfg file. This is not a
QEMU error; QEMU follows the definition of BARs (which are meaningless
when decoding is disabled).

Currently we hook up AcpiPlatformDxe to the PCI Bus driver's
gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI
Bus driver installs this protocol, it's *still* not the right time for
fetching "etc/table-loader": although resources have been allocated and
BARs have been programmed with them, the PCI Bus driver has also cleared
IO and MMIO decoding in the command registers of the devices.

Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our
gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to,
because at that time the PCI Bus driver has not produced PciIo instances
yet.

Our Platform BDSes are responsible for connecting the root bridges, hence
they know exactly when the PciIo instances become available -- not when
PCI enumeration completes (signaled by the above protocol), but when the
ConnectController() calls return.

This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe.
Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all
devices, while it contacts QEMU for the ACPI payload.

This patch introduces the event group GUID that we'll use for unleashing
AcpiPlatformDxe from our Platform BDSes.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- replace protocol with event group [Jordan]

 OvmfPkg/OvmfPkg.dec   |  1 +
 OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h | 33 
 2 files changed, 34 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index c04a6f4afd7f..d4ee152b16de 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -54,14 +54,15 @@ [LibraryClasses]
 
 [Guids]
   gUefiOvmfPkgTokenSpaceGuid  = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 
0x62, 0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
   gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
   gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 
0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
   gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
   gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
+  gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
 
 [Protocols]
   gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 
0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
   gBlockMmioProtocolGuid  = {0x6b558ce3, 0x69e5, 0x4c67, {0xa6, 
0x34, 0xf7, 0xfe, 0x72, 0xad, 0xbe, 0x84}}
   gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 
0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
   gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
 
diff --git a/OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h 
b/OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h
new file mode 100644
index ..b6803d419557
--- /dev/null
+++ b/OvmfPkg/Include/Guid/RootBridgesConnectedEventGroup.h
@@ -0,0 +1,33 @@
+/** @file
+  An event group GUID with which BDS indicates that PCI root bridges have been
+  connected, and PciIo protocol instances have become available.
+
+  Note that this differs from the PCI Enumeration Complete Protocol as defined
+  in the PI 1.1 specification. That protocol is installed by the PCI bus driver
+  after enumeration and resource allocation have been completed, but before
+  PciIo protocol instances are created.
+
+  Copyright (C) 2016, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef _ROOT_BRIDGES_CONNECTED_EVENT_GROUP_H_
+#define _ROOT_BRIDGES_CONNECTED_EVENT_GROUP_H_
+
+#define ROOT_BRIDGES_CONNECTED_EVENT_GROUP_GUID \
+  { 0x24a2d66f, \
+0xeedd, \
+0x4086, \
+{ 0x90, 0x42, 0xf2, 

Re: [edk2] [PATCH 0/6] introduce EfiEventGroupSignal(), rebase ArmVirtPkg and OvmfPkg

[Laszlo Ersek]

On 03/23/16 10:55, Gao, Liming wrote:
> Laszlo:
>   I agree new API EfiEventGroupSignal() is useful. Your change is good to me. 
> Reviewed-by: Liming Gao 

Thank you!

I pushed this series with feedback labels from Ard, Jordan and Liming:
3570e3324835..36e8e6992d0c. Should Jeff or Mike find that something is
amiss (although I really don't expect that), I'll strive to fix it up ASAP.

Thanks!
Laszlo

> Thanks
> Liming
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, March 23, 2016 1:21 AM
>> To: edk2-de...@ml01.01.org
>> Cc: Ard Biesheuvel; Fan, Jeff; Justen, Jordan L; Gao, Liming; Kinney, 
>> Michael D
>> Subject: [PATCH 0/6] introduce EfiEventGroupSignal(), rebase ArmVirtPkg
>> and OvmfPkg
>>
>> This is a trivial refactoring series, implementing an earlier idea from
>> Jordan (IIRC). I would greatly appreciate if you guys could ACK it
>> quickly, so I can commit it today.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Jeff Fan 
>> Cc: Jordan Justen 
>> Cc: Liming Gao 
>> Cc: Michael D Kinney 
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (6):
>>   MdePkg/UefiLib: move InternalEmptyFunction to UefiLib.c
>>   MdePkg/UefiLib: introduce EfiEventGroupSignal
>>   IntelFrameworkPkg/FrameworkUefiLib: move InternalEmptyFunction to
>> UefiLib.c
>>   IntelFrameworkPkg/FrameworkUefiLib: implement EfiEventGroupSignal
>>   ArmVirtPkg/PlatformIntelBdsLib: rebase to EfiEventGroupSignal
>>   OvmfPkg/PlatformBdsLib: rebase to EfiEventGroupSignal
>>
>>  ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c| 34 
>> +--
>>  ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h|  1 +
>>  ArmVirtPkg/Library/PlatformIntelBdsLib/QemuKernel.c  |  1 -
>>  IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c | 62
>> 
>>  IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibInternal.h | 18
>> ++
>>  IntelFrameworkPkg/Library/FrameworkUefiLib/UefiNotTiano.c| 25 +---
>>  MdePkg/Include/Library/UefiLib.h | 18 ++
>>  MdePkg/Library/UefiLib/UefiLib.c | 62
>> 
>>  MdePkg/Library/UefiLib/UefiLibInternal.h | 18 ++
>>  MdePkg/Library/UefiLib/UefiNotTiano.c| 21 ---
>>  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c | 30 +-
>>  11 files changed, 183 insertions(+), 107 deletions(-)
>>
>> --
>> 1.8.3.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

[edk2] [Patch] BaseTools: generate alignment when the FV content come from the filesystem

[Yonghong Zhu]

when the FV contents come from the filesystem instead of from a named FDF
section, the build tool missed to generate alignment for this FV. The fix
is get the alignment value from FV header and use this value to generate
alignment.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/GenFds/FvImageSection.py | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/GenFds/FvImageSection.py 
b/BaseTools/Source/Python/GenFds/FvImageSection.py
index caf8de1..b577de2 100644
--- a/BaseTools/Source/Python/GenFds/FvImageSection.py
+++ b/BaseTools/Source/Python/GenFds/FvImageSection.py
@@ -1,9 +1,9 @@
 ## @file
 # process FV image section generation
 #
-#  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
 #  http://opensource.org/licenses/bsd-license.php
@@ -81,10 +81,28 @@ class FvImageSection(FvImageSectionClassObject):
 if GenFdsGlobalVariable.GetAlignment (Fv.FvAlignment) 
> GenFdsGlobalVariable.GetAlignment (self.Alignment):
 self.Alignment = Fv.FvAlignment
 else:
 if self.FvFileName != None:
 FvFileName = 
GenFdsGlobalVariable.ReplaceWorkspaceMacro(self.FvFileName)
+if os.path.isfile(FvFileName):
+FvFileObj = open (FvFileName,'r+b')
+FvFileObj.seek(0)
+# PI FvHeader is 0x48 byte
+FvHeaderBuffer = FvFileObj.read(0x48)
+# FV alignment position.
+FvAlignmentValue = 1 << (ord (FvHeaderBuffer[0x2E]) & 
0x1F)
+# FvAlignmentValue is larger than or equal to 1K
+if FvAlignmentValue >= 0x400:
+if FvAlignmentValue >= 0x1:
+#The max alignment supported by FFS is 64K.
+self.Alignment = "64K"
+else:
+self.Alignment = str (FvAlignmentValue / 
0x400) + "K"
+else:
+# FvAlignmentValue is less than 1K
+self.Alignment = str (FvAlignmentValue)
+FvFileObj.close()
 else:
 EdkLogger.error("GenFds", GENFDS_ERROR, "FvImageSection 
Failed! %s NOT found in FDF" % self.FvName)
 
 #
 # Prepare the parameter of GenSection
-- 
2.6.1.windows.1

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

Re: [edk2] [PATCH v2 3/3] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

[Heyi Guo]

Hi Ruiyu,

Many thanks for your review.

For questions 2#, I tested equation #1 with copy-paste on serial 
terminal, and found it still missing some characters when the FIFO was 
almost full (i.e. near the end of input). I think it is because time 
event is not real-time interrupt; it may be pending for equal or higher TPL.


And a little faster polling rate tested well on real environment.

Please let me know your suggestion.

Regards.

Heyi

On 03/23/2016 04:03 PM, Ni, Ruiyu wrote:

Heyi,
I have comments in below.

Regards,
Ray



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Thursday, March 17, 2016 10:37 PM
To: edk2-devel@lists.01.org
Cc: Heyi Guo ; Tian, Feng ; Zeng, Star 

Subject: [edk2] [PATCH v2 3/3] MdeModulePkg/TerminalDxe: Set polling rate by 
serial IO mode

Calculate serial input polling rate according to parameters from
serial IO mode as below, to fix potential input truncation with fixed
polling interval 0.02s.

Polling interval (100ns) =
FifoDepth * (ParityBits + StopBits + DataBits) * 10,000,000 / BaudRate

1. The above equation (let's call it equation #1) looks good.


However, as UEFI events will probably delayed by other code of higher
TPL, we use below equation to make polling rate fast enough:

FifoDepth * DataBits * 10,000,000 * 2 / (BaudRate * 3)

2. Can you tell me why you multiple two in the left of "/" and multiple 3 in 
the right?
Did you meet any real problem when using the original equation (#1)?

I have more comments in below.


Signed-off-by: Heyi Guo 
Cc: Feng Tian 
Cc: Star Zeng 
---
.../Universal/Console/TerminalDxe/Terminal.c   |  5 +-
.../Universal/Console/TerminalDxe/Terminal.h   | 27 -
.../Universal/Console/TerminalDxe/TerminalConIn.c  | 68 ++
3 files changed, 98 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
index 5adaa97..db790f3 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
@@ -71,6 +71,7 @@ TERMINAL_DEV  mTerminalDevTemplate = {
   },
   NULL, // TerminalConsoleModeData
   0,  // SerialInTimeOut
+  DEFAULT_KEYBOARD_TIMER_INTERVAL, // KeyboardTimerInterval

3. Can you remove the default timer interval?
We should be able to calculate the timer interval from the default
setting (DataBits, StopBits, BaudRate, etc).


   NULL, // RawFifo
   NULL, // UnicodeFiFo
@@ -984,10 +985,12 @@ TerminalDriverBindingStart (
 );
 ASSERT_EFI_ERROR (Status);

+TerminalDevice->KeyboardTimerInterval = GetKeyboardTimerInterval (Mode);
+
 Status = gBS->SetTimer (
 TerminalDevice->TimerEvent,
 TimerPeriodic,
-KEYBOARD_TIMER_INTERVAL
+TerminalDevice->KeyboardTimerInterval
 );
 ASSERT_EFI_ERROR (Status);

diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
index 269d2ae..58d5664 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
@@ -68,7 +68,7 @@ typedef struct {
   UINTN   Rows;
} TERMINAL_CONSOLE_MODE_DATA;

-#define KEYBOARD_TIMER_INTERVAL 20  // 0.02s
+#define DEFAULT_KEYBOARD_TIMER_INTERVAL 20  // 0.02s


4. Same question as #3.


#define TERMINAL_DEV_SIGNATURE  SIGNATURE_32 ('t', 'm', 'n', 'l')

@@ -91,6 +91,7 @@ typedef struct {
   EFI_SIMPLE_TEXT_OUTPUT_MODE SimpleTextOutputMode;
   TERMINAL_CONSOLE_MODE_DATA  *TerminalConsoleModeData;
   UINTN   SerialInTimeOut;
+  UINT64  KeyboardTimerInterval;
   RAW_DATA_FIFO   *RawFiFo;
   UNICODE_FIFO*UnicodeFiFo;
   EFI_KEY_FIFO*EfiKeyFiFo;
@@ -1358,4 +1359,28 @@ TerminalConInTimerHandler (
   IN EFI_EVENTEvent,
   IN VOID *Context
   );
+
+/**
+  Calculate input polling timer interval by serial IO mode.
+
+  @param  Mode  Pointer to serial IO mode.
+
+  @retval The required polling timer interval in 100ns.
+
+**/
+UINT64
+GetKeyboardTimerInterval (
+  IN EFI_SERIAL_IO_MODE   *Mode
+  );
+
+/**
+  Update period of polling timer event.
+
+  @param  TerminalDeviceThe terminal device to update.
+**/
+VOID
+UpdatePollingRate (
+  IN TERMINAL_DEV *TerminalDevice
+  );
+
#endif
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
index 2215df6..22349a0 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
+++ 

[edk2] [Patch] BaseTools: Add two new sections for PCD in the build report

[Yonghong Zhu]

Build Spec updated to add two new sections for PCD in the build report.
1.Conditional directives section:If the DSC or FDF file contains
conditional directive statements.
2.Unused PCDs section: If the DSC or FDF file define values for PCDs that
are not used by any module and are not used in conditional directive
statements.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Common/Expression.py |   6 +-
 BaseTools/Source/Python/Common/GlobalData.py |   3 +
 BaseTools/Source/Python/build/BuildReport.py | 112 +++
 3 files changed, 104 insertions(+), 17 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Expression.py 
b/BaseTools/Source/Python/Common/Expression.py
index 3c8d14e..7b3030c 100644
--- a/BaseTools/Source/Python/Common/Expression.py
+++ b/BaseTools/Source/Python/Common/Expression.py
@@ -1,9 +1,9 @@
 ## @file
 # This file is used to parse and evaluate expression in directive or PCD value.
 #
-# Copyright (c) 2011, Intel Corporation. All rights reserved.
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 #
@@ -74,10 +74,14 @@ def ReplaceExprMacro(String, Macros, ExceptionList = None):
 InQuote = False
 if String.startswith('"'):
 InQuote = True
 MacroStartPos = String.find('$(')
 if MacroStartPos < 0:
+for Pcd in gPlatformPcds.keys():
+if Pcd in String:
+if Pcd not in gConditionalPcds:
+gConditionalPcds.append(Pcd)
 continue
 RetStr = ''
 while MacroStartPos >= 0:
 RetStr = String[0:MacroStartPos]
 MacroEndPos = String.find(')', MacroStartPos)
diff --git a/BaseTools/Source/Python/Common/GlobalData.py 
b/BaseTools/Source/Python/Common/GlobalData.py
index 8f544bd..c3439eb 100644
--- a/BaseTools/Source/Python/Common/GlobalData.py
+++ b/BaseTools/Source/Python/Common/GlobalData.py
@@ -76,5 +76,8 @@ gFdfParser = None
 # when build exits.
 #
 gTempInfs = []
 
 BuildOptionPcd = []
+
+# Pcd name for the Pcd which used in the Conditional directives
+gConditionalPcds = []
diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 2dc02c2..aee50fb 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -656,10 +656,12 @@ class PcdReport(object):
 # @param selfThe object pointer
 # @param Wa  Workspace context information
 #
 def __init__(self, Wa):
 self.AllPcds = {}
+self.UnusedPcds = {}
+self.ConditionalPcds = {}
 self.MaxLen = 0
 if Wa.FdfProfile:
 self.FdfPcdSet = Wa.FdfProfile.PcdDict
 else:
 self.FdfPcdSet = {}
@@ -674,10 +676,67 @@ class PcdReport(object):
 PcdList = self.AllPcds.setdefault(Pcd.TokenSpaceGuidCName, 
{}).setdefault(Pcd.Type, [])
 if Pcd not in PcdList:
 PcdList.append(Pcd)
 if len(Pcd.TokenCName) > self.MaxLen:
 self.MaxLen = len(Pcd.TokenCName)
+#
+# Collect the PCD defined in DSC/FDF file, but not used in module
+#
+UnusedPcdFullList = []
+for item in Pa.Platform.Pcds:
+Pcd = Pa.Platform.Pcds[item]
+if not Pcd.Type:
+PcdTypeFlag = False
+for package in Pa.PackageList:
+for T in ["FixedAtBuild", "PatchableInModule", 
"FeatureFlag", "Dynamic", "DynamicEx"]:
+if (Pcd.TokenCName, Pcd.TokenSpaceGuidCName, T) in 
package.Pcds:
+Pcd.Type = T
+PcdTypeFlag = True
+if not Pcd.DatumType:
+Pcd.DatumType = 
package.Pcds[(Pcd.TokenCName, Pcd.TokenSpaceGuidCName, T)].DatumType
+break
+if PcdTypeFlag:
+break
+if not Pcd.DatumType:
+PcdType = Pcd.Type
+# Try to remove Hii and Vpd suffix
+if PcdType.startswith("DynamicEx"):
+PcdType = "DynamicEx"
+elif PcdType.startswith("Dynamic"):
+PcdType = "Dynamic"
+for package in Pa.PackageList:
+if (Pcd.TokenCName, Pcd.TokenSpaceGuidCName, PcdType) 
in package.Pcds:
+Pcd.DatumType = 

Re: [edk2] Error while loading a symbol file (No Debug Directory)

[Ard Biesheuvel]

On 22 March 2016 at 19:19, Vladimir Olovyannikov
 wrote:
> Sorry for the spam,
> Sending to the proper list now
>
> -Original Message-
> From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
> Sent: Tuesday, March 22, 2016 11:15 AM
> To: 'edk2-de...@lists.sourceforge.net'
> Cc: 'Ard Biesheuvel'
> Subject: Error while loading a symbol file (No Debug Directory)
>
> Hi All,
>
> After been away from the UEFI development and bring-up, I noticed that I
> could not DS-5 debug some of the UEFI modules anymore (some are OK)
> after returning back to the UEFI (ARMv8 64 bit platform).
>
> I am using the cmd_load_symbols.py to load symbols via this line:
> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -v -f
> (0x8500, 0x000F) -m (0x8000,0x4000) -a
>
> From .fdf:
> [FD.BL33_AP_UEFI]
> BaseAddress   = 0x8500|gArmTokenSpaceGuid.PcdFdBaseAddress
> Size  = 0x000F|gArmTokenSpaceGuid.PcdFdSize
>
> From .dsc:
> gArmTokenSpaceGuid.PcdSystemMemoryBase|0x8000
> gArmTokenSpaceGuid.PcdSystemMemorySize|0x4000
>
> When I run the cmd_load_symbols.py script I am getting
>
> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)
> Add symbols of /
> uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/MdeModulePkg/Universal/PCD/Dxe/Pcd/D
> EBUG/PcdDxe.dll at 0xbbf44000
> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)
> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)
> Add symbols of
> /uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/MdeModulePkg/Universal/SecurityStub
> Dxe/SecurityStubDxe/DEBUG/SecurityStubDxe.dll at 0xbbf2f000
> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)
>
> And only assembly is available for debug.
> I did not have this problem earlier (well, much earlier, in Oct 2015)
>
> Please let me know what I am doing wrong, and/or what I need to do to
> enable source level debugging; I was following
> https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg-Ds5
>

Any chance you could bisect this?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2] BaseTools: not include the undefined macro in response file

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Wednesday, March 23, 2016 3:05 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch v2] BaseTools: not include the undefined macro in
> response file
> 
> In last Nmake patch, when we generate the response file, we would replace
> all the Macros in the make file. Once there have undefined macro used,
> the tool direct report error. In this patch, we use following solution to
> resolve the failure.
> 1. Add all the defined macros into AutoGenObject macro dict
> 2. For the undefined macros which used in the Make file, when we generate
> the response file, we not include this macro, let make phase to handle.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py |  6 +
>  BaseTools/Source/Python/AutoGen/GenMake.py | 42
> +-
>  2 files changed, 41 insertions(+), 7 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index 4934c57..e9e46c2 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -2478,10 +2478,16 @@ class ModuleAutoGen(AutoGen):
>  self._Macro["MODULE_BUILD_DIR"  ] = self.BuildDir
>  self._Macro["OUTPUT_DIR"] = self.OutputDir
>  self._Macro["DEBUG_DIR" ] = self.DebugDir
>  self._Macro["DEST_DIR_OUTPUT"   ] = self.OutputDir
>  self._Macro["DEST_DIR_DEBUG"] = self.DebugDir
> +self._Macro["PLATFORM_NAME" ] = self.PlatformInfo.Name
> +self._Macro["PLATFORM_GUID" ] = self.PlatformInfo.Guid
> +self._Macro["PLATFORM_VERSION"  ] = self.PlatformInfo.Version
> +self._Macro["PLATFORM_RELATIVE_DIR" ] =
> self.PlatformInfo.SourceDir
> +self._Macro["PLATFORM_DIR"  ] = 
> mws.join(self.WorkspaceDir,
> self.PlatformInfo.SourceDir)
> +self._Macro["PLATFORM_OUTPUT_DIR"   ] =
> self.PlatformInfo.OutputDir
>  return self._Macro
> 
>  ## Return the module build data object
>  def _GetModule(self):
>  if self._Module == None:
> diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py
> b/BaseTools/Source/Python/AutoGen/GenMake.py
> index 59ac2e8..a4844be 100644
> --- a/BaseTools/Source/Python/AutoGen/GenMake.py
> +++ b/BaseTools/Source/Python/AutoGen/GenMake.py
> @@ -475,10 +475,21 @@ cleanlib:
>  ImageEntryPoint = ModuleEntryPoint
>  else:
>  # EdkII modules always use "_ModuleEntryPoint" as entry point
>  ImageEntryPoint = "_ModuleEntryPoint"
> 
> +for k, v in self._AutoGenObject.Module.Defines.iteritems():
> +if k not in self._AutoGenObject.Macros.keys():
> +self._AutoGenObject.Macros[k] = v
> +
> +if 'MODULE_ENTRY_POINT' not in self._AutoGenObject.Macros.keys():
> +self._AutoGenObject.Macros['MODULE_ENTRY_POINT'] =
> ModuleEntryPoint
> +if 'ARCH_ENTRY_POINT' not in self._AutoGenObject.Macros.keys():
> +self._AutoGenObject.Macros['ARCH_ENTRY_POINT'] =
> ArchEntryPoint
> +if 'IMAGE_ENTRY_POINT' not in self._AutoGenObject.Macros.keys():
> +self._AutoGenObject.Macros['IMAGE_ENTRY_POINT'] =
> ImageEntryPoint
> +
>  # tools definitions
>  ToolsDef = []
>  IncPrefix = self._INC_FLAG_[self._AutoGenObject.ToolChainFamily]
>  for Tool in self._AutoGenObject.BuildOption:
>  for Attr in self._AutoGenObject.BuildOption[Tool]:
> @@ -502,14 +513,24 @@ cleanlib:
>  RespFileList = os.path.join(self._AutoGenObject.OutputDir,
> 'respfilelist.txt')
>  if RespDict:
>  RespFileListContent = ''
>  for Resp in RespDict.keys():
>  RespFile = os.path.join(self._AutoGenObject.OutputDir,
> str(Resp).lower() + '.txt')
> -SaveFileOnChange(RespFile, RespDict[Resp], False)
> -ToolsDef.append("%s = %s" % (Resp, '@' + RespFile))
> +StrList = RespDict[Resp].split(' ')
> +UnexpandMacro = []
> +NewStr = []
> +for Str in StrList:
> +if '$' in Str:
> +UnexpandMacro.append(Str)
> +else:
> +NewStr.append(Str)
> +UnexpandMacroStr = ' '.join(UnexpandMacro)
> +NewRespStr = ' '.join(NewStr)
> +SaveFileOnChange(RespFile, NewRespStr, False)
> +ToolsDef.append("%s = %s" % (Resp, UnexpandMacroStr + ' @' +
> RespFile))
>  RespFileListContent += '@' + RespFile + os.linesep
> -

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ni, Ruiyu]

Thanks for the understanding.

I will post the patch to revert the change.

Regards,
Ray


>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
>Ersek
>Sent: Wednesday, March 23, 2016 4:53 PM
>To: Ni, Ruiyu 
>Cc: Tian, Feng ; Ard Biesheuvel 
>; edk2-devel@lists.01.org
>; Heyi Guo ; Ryan Harkin 
>; Zeng, Star
>
>Subject: Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>PCD
>
>On 03/23/16 09:33, Ni, Ruiyu wrote:
>> Laszlo,
>> Since the patch below lets SerialDxe driver use the new introduced
>> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
>> Would you mind to revert the check in @ 31ae446b
>> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?
>
>If I understand correctly, this series increases the terminal polling
>rate, so that cursor movement escape sequences (and other burst-like
>sequences) can be processed even with a receive fifo depth of 1. Hence
>31ae446b should become unnecessary.
>
>If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
>your revert of 31ae446b -- on top of this series from Heyi --, and the
>cursor keys work with 31ae446b reverted, then I don't mind, sure.
>
>Thanks
>Laszlo
>
>>
>> Regards,
>> Ray
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Thursday, March 17, 2016 10:37 PM
>>> To: edk2-devel@lists.01.org
>>> Cc: Heyi Guo ; Tian, Feng ; Zeng, 
>>> Star 
>>> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>>> PCD
>>>
>>> Set UART receive FIFO depth with PCD instead of fixed number "1".
>>> The default value of PCD is also 1, so it makes no difference for
>>> platforms which do not explicitly set this PCD.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Heyi Guo 
>>> Cc: Feng Tian 
>>> Cc: Star Zeng 
>>> ---
>>> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
>>> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> index 164060b..a1453bd 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> @@ -41,10 +41,11 @@
>>>   gEfiDevicePathProtocolGuid## PRODUCES
>>>
>>> [Pcd]
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>>>
>>> [Depex]
>>>   TRUE
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> index f5b3064..d2383e5 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> @@ -236,7 +236,7 @@ SerialReset (
>>>   //
>>>   // Set the Serial I/O mode
>>>   //
>>> -  This->Mode->ReceiveFifoDepth  = 1;
>>> +  This->Mode->ReceiveFifoDepth  = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   This->Mode->Timeout   = 1000 * 1000;
>>>   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>>>   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>> @@ -508,6 +508,7 @@ SerialDxeInitialize (
>>>   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
>>>   mSerialIoMode.StopBits = (UINT32) PcdGet8 (PcdUartDefaultStopBits);
>>> +  mSerialIoMode.ReceiveFifoDepth = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   mSerialDevicePath.Uart.BaudRate = PcdGet64 (PcdUartDefaultBaudRate);
>>>   mSerialDevicePath.Uart.DataBits = PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialDevicePath.Uart.Parity   = PcdGet8 (PcdUartDefaultParity);
>>> --
>>> 2.7.0
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> 

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Laszlo Ersek]

On 03/23/16 09:33, Ni, Ruiyu wrote:
> Laszlo,
> Since the patch below lets SerialDxe driver use the new introduced
> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
> Would you mind to revert the check in @ 31ae446b
> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?

If I understand correctly, this series increases the terminal polling
rate, so that cursor movement escape sequences (and other burst-like
sequences) can be processed even with a receive fifo depth of 1. Hence
31ae446b should become unnecessary.

If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
your revert of 31ae446b -- on top of this series from Heyi --, and the
cursor keys work with 31ae446b reverted, then I don't mind, sure.

Thanks
Laszlo

> 
> Regards,
> Ray
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>> Guo
>> Sent: Thursday, March 17, 2016 10:37 PM
>> To: edk2-devel@lists.01.org
>> Cc: Heyi Guo ; Tian, Feng ; Zeng, 
>> Star 
>> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>> PCD
>>
>> Set UART receive FIFO depth with PCD instead of fixed number "1".
>> The default value of PCD is also 1, so it makes no difference for
>> platforms which do not explicitly set this PCD.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Heyi Guo 
>> Cc: Feng Tian 
>> Cc: Star Zeng 
>> ---
>> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
>> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> index 164060b..a1453bd 100644
>> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>> @@ -41,10 +41,11 @@
>>   gEfiDevicePathProtocolGuid## PRODUCES
>>
>> [Pcd]
>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>>
>> [Depex]
>>   TRUE
>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>> index f5b3064..d2383e5 100644
>> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>> @@ -236,7 +236,7 @@ SerialReset (
>>   //
>>   // Set the Serial I/O mode
>>   //
>> -  This->Mode->ReceiveFifoDepth  = 1;
>> +  This->Mode->ReceiveFifoDepth  = PcdGet16 (PcdUartDefaultReceiveFifoDepth);
>>   This->Mode->Timeout   = 1000 * 1000;
>>   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>>   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>> @@ -508,6 +508,7 @@ SerialDxeInitialize (
>>   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
>>   mSerialIoMode.StopBits = (UINT32) PcdGet8 (PcdUartDefaultStopBits);
>> +  mSerialIoMode.ReceiveFifoDepth = PcdGet16 
>> (PcdUartDefaultReceiveFifoDepth);
>>   mSerialDevicePath.Uart.BaudRate = PcdGet64 (PcdUartDefaultBaudRate);
>>   mSerialDevicePath.Uart.DataBits = PcdGet8 (PcdUartDefaultDataBits);
>>   mSerialDevicePath.Uart.Parity   = PcdGet8 (PcdUartDefaultParity);
>> --
>> 2.7.0
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] ld -z being used linking PE (not ELF) binaries?

[Ard Biesheuvel]

(+ Jordan, Liming)

On 23 March 2016 at 01:11, Charles Duffy  wrote:
> Howdy --
>
> I'm running an edk2 build with TOOL_CHAIN_TAG=UNIXGCC.
>
> This eventually fails as follows:
>
> Building ...
> /home/cduffy/VC/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.inf
> [X64]
> "x86_64-w64-mingw32-ld" -o
> /home/cduffy/VC/edk2/Build/OvmfX64/DEBUG_UNIXGCC/X64/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll
> -nostdlib --pie --gc-sections --entry __ModuleEntryP
> oint --file-alignment 0x20 --section-alignment 0x20 -Map
> /home/cduffy/VC/edk2/Build/OvmfX64/DEBUG_UNIXGCC/X64/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.map
> --image-base=0 -z comm
> on-page-size=0x1000 --start-group
>  
> @/home/cduffy/VC/edk2/Build/OvmfX64/DEBUG_UNIXGCC/X64/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe/OUTPUT/static_library_files.lst
> --end-group
> x86_64-w64-mingw32-ld: unrecognized option '-z'
> x86_64-w64-mingw32-ld: use the --help option for usage information
> GNUmakefile:433: recipe for target
> '/home/cduffy/VC/edk2/Build/OvmfX64/DEBUG_UNIXGCC/X64/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll'
> failed
> make: ***
> [/home/cduffy/VC/edk2/Build/OvmfX64/DEBUG_UNIXGCC/X64/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll]
> Error 1
>
> The "-z" option to ld is ELF-specific, and doesn't make sense for PE
> binaries (as generated by the mingw toolchain). Are we using the wrong
> linker here, or is the option (specified in OvmfPkg/OvmfPkgX64.dsc) being
> applied overbroadly?

That is a bug, indeed. The -z option is required to align the ELF
sections to 4 KB, which is required for DXE runtime drivers with the
recently introduced strict mapping permissions under the OS.

The correct way for UNIXGCC would be to pass a '--section-alignment
0x1000' linker argument instead, but doing that in the .DSC, we end up
with

 [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
-  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+  GCC:*_GCC44_*_DLINK_FLAGS = -z common-page-size=0x1000
+  GCC:*_GCC45_*_DLINK_FLAGS = -z common-page-size=0x1000
+  GCC:*_GCC46_*_DLINK_FLAGS = -z common-page-size=0x1000
+  GCC:*_GCC47_*_DLINK_FLAGS = -z common-page-size=0x1000
+  GCC:*_GCC48_*_DLINK_FLAGS = -z common-page-size=0x1000
+  GCC:*_GCC49_*_DLINK_FLAGS = -z common-page-size=0x1000
+  GCC:*_UNIXGCC_*_DLINK_FLAGS = --section-alignment 0x1000

Since this arguably does not belong in the .DSC files anyway (i.e., a
DSC should be able to opt-in to 4k section alignment without inventing
its own linker command line), perhaps Liming or Yonghong have an idea
how to better support this in the BaseTools?

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

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ni, Ruiyu]

Laszlo,
Since the patch below lets SerialDxe driver use the new introduced
PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
Would you mind to revert the check in @ 31ae446b
--> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?

Regards,
Ray


>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
>Sent: Thursday, March 17, 2016 10:37 PM
>To: edk2-devel@lists.01.org
>Cc: Heyi Guo ; Tian, Feng ; Zeng, 
>Star 
>Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD
>
>Set UART receive FIFO depth with PCD instead of fixed number "1".
>The default value of PCD is also 1, so it makes no difference for
>platforms which do not explicitly set this PCD.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Heyi Guo 
>Cc: Feng Tian 
>Cc: Star Zeng 
>---
> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
>diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>index 164060b..a1453bd 100644
>--- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>+++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>@@ -41,10 +41,11 @@
>   gEfiDevicePathProtocolGuid## PRODUCES
>
> [Pcd]
>-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>-  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>
> [Depex]
>   TRUE
>diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>index f5b3064..d2383e5 100644
>--- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>+++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>@@ -236,7 +236,7 @@ SerialReset (
>   //
>   // Set the Serial I/O mode
>   //
>-  This->Mode->ReceiveFifoDepth  = 1;
>+  This->Mode->ReceiveFifoDepth  = PcdGet16 (PcdUartDefaultReceiveFifoDepth);
>   This->Mode->Timeout   = 1000 * 1000;
>   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>@@ -508,6 +508,7 @@ SerialDxeInitialize (
>   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
>   mSerialIoMode.StopBits = (UINT32) PcdGet8 (PcdUartDefaultStopBits);
>+  mSerialIoMode.ReceiveFifoDepth = PcdGet16 (PcdUartDefaultReceiveFifoDepth);
>   mSerialDevicePath.Uart.BaudRate = PcdGet64 (PcdUartDefaultBaudRate);
>   mSerialDevicePath.Uart.DataBits = PcdGet8 (PcdUartDefaultDataBits);
>   mSerialDevicePath.Uart.Parity   = PcdGet8 (PcdUartDefaultParity);
>--
>2.7.0
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Ni, Ruiyu]

I have no concern about the logic.
Just some comments about the coding style.

Regards,
Ray


>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>Shivamurthy Shastri
>Sent: Wednesday, February 10, 2016 10:10 PM
>To: edk2-devel@lists.01.org
>Cc: fathi.bou...@linaro.org
>Subject: [edk2] [PATCH] Ax88772b: support for multiple dongles and chips
>
>Driver code is modified to support multiple ethernet dongles, which uses
>similar ASIX chips. Also, it can be used for multiple ASIX chips with
>similar register map.
>
>Enabled support for Apple Ethernet Adapter
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Shivamurthy Shastri 
>---
> .../Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h   | 13 -
> .../Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c | 33 +-
> 2 files changed, 32 insertions(+), 14 deletions(-)
>
>diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>index ab75ec2..816f2b2 100644
>--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772.h
>@@ -297,12 +297,23 @@
> #define AN_10_HDX   0x0020  ///<  1 = 10BASE-T support
> #define AN_CSMA_CD  0x0001  ///<  1 = IEEE 802.3 CSMA/CD 
> support
>
>-
>+/* asix_flags defines */
>+#define FLAG_NONE   0
>+#define FLAG_TYPE_AX88172   (1U << 0)
>+#define FLAG_TYPE_AX88772   (1U << 1)
>+#define FLAG_TYPE_AX88772B  (1U << 2)
>+#define FLAG_EEPROM_MAC (1U << 3) /* initial mac address in eeprom */

1. Please use "//" to start the comments. Please use BIT0, BIT1, BIT2, BIT3 
macro.

>
> //--
> //  Data Types
> //--
>
>+struct ASIX_DONGLE {
>+  UINT16  VendorId;
>+  UINT16  ProductId;
>+  INT32   Flags;
>+};

2. please use "typedef struct {...} ASIX_DONGLE"


>+
> /**
>   Ethernet header layout
>
>diff --git a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>index 3b73040..6a10cbf 100644
>--- a/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>+++ b/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/DriverBinding.c
>@@ -14,6 +14,13 @@
>
> #include "Ax88772.h"
>
>+struct ASIX_DONGLE ASIX_DONGLES[] = {
>+{ 0x05AC, 0x1402, FLAG_TYPE_AX88772 }, /* Apple USB Ethernet Adapter 
>*/
>+/* ASIX 88772B */
>+{ 0x0B95, 0x772B, FLAG_TYPE_AX88772B | FLAG_EEPROM_MAC },
>+{ 0x, 0x, FLAG_NONE }   /* END - Do not remove */
>+};

3. When you follow my proposal #2, you can remove "struct" keyword in above.

>+
> /**
>   Verify the controller type
>
>@@ -36,6 +43,8 @@ DriverSupported (
>   EFI_USB_DEVICE_DESCRIPTOR Device;
>   EFI_USB_IO_PROTOCOL * pUsbIo;
>   EFI_STATUS Status;
>+  UINT32 i;

4. Better to use Index rather than i.

>+
>   //
>   //  Connect to the USB stack
>   //
>@@ -60,19 +69,17 @@ DriverSupported (
> else {
>   //
>   //  Validate the adapter
>-  //
>-  if ( VENDOR_ID == Device.IdVendor ) {
>-
>-if (PRODUCT_ID == Device.IdProduct) {
>-DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
>-}

5. Since you removed the above code, can you also remove
VENDOR_ID and PRODUCT_ID macro in header file?

>-  else  {
>-   Status = EFI_UNSUPPORTED;
>-  }
>-  }
>-  else {
>-Status = EFI_UNSUPPORTED;
>-   }
>+  //
>+  for (i = 0; ASIX_DONGLES[i].VendorId != 0; i++) {
>+   if (ASIX_DONGLES[i].VendorId == Device.IdVendor &&
>+   ASIX_DONGLES[i].ProductId == Device.IdProduct) {
>+ DEBUG ((EFI_D_INFO, "Found the AX88772B\r\n"));
>+ break;
>+   }
>+   }

6. Please do not use TAB and use 2 spaces to indent.

>+
>+   if (ASIX_DONGLES[i].VendorId == 0)
>+  Status = EFI_UNSUPPORTED;
> }
>
> //
>--
>1.9.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 3/3] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

[Ni, Ruiyu]

Heyi,
I have comments in below.

Regards,
Ray


>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
>Sent: Thursday, March 17, 2016 10:37 PM
>To: edk2-devel@lists.01.org
>Cc: Heyi Guo ; Tian, Feng ; Zeng, 
>Star 
>Subject: [edk2] [PATCH v2 3/3] MdeModulePkg/TerminalDxe: Set polling rate by 
>serial IO mode
>
>Calculate serial input polling rate according to parameters from
>serial IO mode as below, to fix potential input truncation with fixed
>polling interval 0.02s.
>
>Polling interval (100ns) =
>FifoDepth * (ParityBits + StopBits + DataBits) * 10,000,000 / BaudRate

1. The above equation (let's call it equation #1) looks good.

>
>However, as UEFI events will probably delayed by other code of higher
>TPL, we use below equation to make polling rate fast enough:
>
>FifoDepth * DataBits * 10,000,000 * 2 / (BaudRate * 3)

2. Can you tell me why you multiple two in the left of "/" and multiple 3 in 
the right?
Did you meet any real problem when using the original equation (#1)?

I have more comments in below.

>
>Signed-off-by: Heyi Guo 
>Cc: Feng Tian 
>Cc: Star Zeng 
>---
> .../Universal/Console/TerminalDxe/Terminal.c   |  5 +-
> .../Universal/Console/TerminalDxe/Terminal.h   | 27 -
> .../Universal/Console/TerminalDxe/TerminalConIn.c  | 68 ++
> 3 files changed, 98 insertions(+), 2 deletions(-)
>
>diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>index 5adaa97..db790f3 100644
>--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>@@ -71,6 +71,7 @@ TERMINAL_DEV  mTerminalDevTemplate = {
>   },
>   NULL, // TerminalConsoleModeData
>   0,  // SerialInTimeOut
>+  DEFAULT_KEYBOARD_TIMER_INTERVAL, // KeyboardTimerInterval

3. Can you remove the default timer interval?
We should be able to calculate the timer interval from the default
setting (DataBits, StopBits, BaudRate, etc).

>
>   NULL, // RawFifo
>   NULL, // UnicodeFiFo
>@@ -984,10 +985,12 @@ TerminalDriverBindingStart (
> );
> ASSERT_EFI_ERROR (Status);
>
>+TerminalDevice->KeyboardTimerInterval = GetKeyboardTimerInterval (Mode);
>+
> Status = gBS->SetTimer (
> TerminalDevice->TimerEvent,
> TimerPeriodic,
>-KEYBOARD_TIMER_INTERVAL
>+TerminalDevice->KeyboardTimerInterval
> );
> ASSERT_EFI_ERROR (Status);
>
>diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>index 269d2ae..58d5664 100644
>--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>@@ -68,7 +68,7 @@ typedef struct {
>   UINTN   Rows;
> } TERMINAL_CONSOLE_MODE_DATA;
>
>-#define KEYBOARD_TIMER_INTERVAL 20  // 0.02s
>+#define DEFAULT_KEYBOARD_TIMER_INTERVAL 20  // 0.02s


4. Same question as #3.

>
> #define TERMINAL_DEV_SIGNATURE  SIGNATURE_32 ('t', 'm', 'n', 'l')
>
>@@ -91,6 +91,7 @@ typedef struct {
>   EFI_SIMPLE_TEXT_OUTPUT_MODE SimpleTextOutputMode;
>   TERMINAL_CONSOLE_MODE_DATA  *TerminalConsoleModeData;
>   UINTN   SerialInTimeOut;
>+  UINT64  KeyboardTimerInterval;
>   RAW_DATA_FIFO   *RawFiFo;
>   UNICODE_FIFO*UnicodeFiFo;
>   EFI_KEY_FIFO*EfiKeyFiFo;
>@@ -1358,4 +1359,28 @@ TerminalConInTimerHandler (
>   IN EFI_EVENTEvent,
>   IN VOID *Context
>   );
>+
>+/**
>+  Calculate input polling timer interval by serial IO mode.
>+
>+  @param  Mode  Pointer to serial IO mode.
>+
>+  @retval The required polling timer interval in 100ns.
>+
>+**/
>+UINT64
>+GetKeyboardTimerInterval (
>+  IN EFI_SERIAL_IO_MODE   *Mode
>+  );
>+
>+/**
>+  Update period of polling timer event.
>+
>+  @param  TerminalDeviceThe terminal device to update.
>+**/
>+VOID
>+UpdatePollingRate (
>+  IN TERMINAL_DEV *TerminalDevice
>+  );
>+
> #endif
>diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>index 2215df6..22349a0 100644
>--- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>+++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>@@ -502,6 +502,71 @@ TerminalConInWaitForKey (
> }
>
> /**
>+  Calculate input polling timer interval by serial IO mode.
>+
>+  @param  Mode  Pointer to serial IO mode.
>+
>+  @retval The required polling timer interval in 100ns.
>+
>+**/
>+UINT64
>+GetKeyboardTimerInterval (
>+  IN EFI_SERIAL_IO_MODE *Mode
>+  )
>+{
>+  UINT32 

Re: [edk2] [patch 1/2] MdeModulePkg/BootMaintManagerUiLib: Declare EFIAPI for ChooseFile handler

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, March 22, 2016 11:37 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Dong, Eric
> Subject: [patch 1/2] MdeModulePkg/BootMaintManagerUiLib: Declare EFIAPI for 
> ChooseFile handler
> 
> The BootMaintenanceManagerUiLib use ChooseFile() from FileExplorerLib
> to select files. And the third parameter in ChooseFile() is CHOOSE_HANDLER,
> per the definition of CHOOSE_HANDLER, it must use EFIAPI as the calling
> convention. But the calling convention was not specified for following
> handlers: CreateBootOptionFromFile, CreateDriverOptionFromFile,
> BootFromFile. Now specifies the calling convention for those functions.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  .../Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h   | 3 
> +++
>  MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c  | 3 
> +++
>  2 files changed, 6 insertions(+)
> 
> diff --git 
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> index 2c93446..d607314 100644
> --- 
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> +++ 
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManager.h
> @@ -1303,10 +1303,11 @@ BootMaintCallback (
>@retval TRUE   Exit caller function.
>@retval FALSE  Not exit caller function.
> 
>  **/
>  BOOLEAN
> +EFIAPI
>  CreateBootOptionFromFile (
>IN EFI_DEVICE_PATH_PROTOCOL*FilePath
>);
> 
>  /**
> @@ -1316,10 +1317,11 @@ CreateBootOptionFromFile (
> 
>@retval TRUE   Exit caller function.
>@retval FALSE  Not exit caller function.
>  **/
>  BOOLEAN
> +EFIAPI
>  CreateDriverOptionFromFile (
>IN EFI_DEVICE_PATH_PROTOCOL*FilePath
>);
> 
>  /**
> @@ -1330,10 +1332,11 @@ CreateDriverOptionFromFile (
>@retval TRUE   Exit caller function.
>@retval FALSE  Not exit caller function.
> 
>  **/
>  BOOLEAN
> +EFIAPI
>  BootFromFile (
>IN EFI_DEVICE_PATH_PROTOCOL*FilePath
>);
> 
>  //
> diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> index 0bd3170..7a014c9 100644
> --- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> +++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> @@ -855,10 +855,11 @@ GetDriverOrder (
> 
>@retval TRUE   Exit caller function.
>@retval FALSE  Not exit caller function.
>  **/
>  BOOLEAN
> +EFIAPI
>  BootFromFile (
>IN EFI_DEVICE_PATH_PROTOCOL*FilePath
>)
>  {
>EFI_BOOT_MANAGER_LOAD_OPTION BootOption;
> @@ -927,10 +928,11 @@ ReSendForm(
> 
>@retval TRUE   Exit caller function.
>@retval FALSE  Not exit caller function.
>  **/
>  BOOLEAN
> +EFIAPI
>  CreateBootOptionFromFile (
>IN EFI_DEVICE_PATH_PROTOCOL*FilePath
>)
>  {
>return ReSendForm(FilePath, FORM_BOOT_ADD_ID);
> @@ -944,10 +946,11 @@ CreateBootOptionFromFile (
>@retval TRUE   Exit caller function.
>@retval FALSE  Not exit caller function.
> 
>  **/
>  BOOLEAN
> +EFIAPI
>  CreateDriverOptionFromFile (
>IN EFI_DEVICE_PATH_PROTOCOL*FilePath
>)
>  {
>return ReSendForm(FilePath, FORM_DRV_ADD_FILE_ID);
> --
> 1.9.5.msysgit.1

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

[edk2] [Patch] NetworkPkg: Fix HII related problem in HTTP boot driver.

[Fu Siyuan]

According to UEFI spec, HII_Config_Access.RouteConfig() should return success
if the required configuration has been processed. Current HTTP boot driver
may return error code in some situation, which failed the UEFI SCT test.
This patch fix this issue by removing the returned error status code and adding
extra check point in the Callback() function, which will pop up a message box
if user input an unsupported URI string.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Cc: Dong Eric 
Cc: Wu Jiaxin 
---
 NetworkPkg/HttpBootDxe/HttpBootConfig.c| 77 +++---
 NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h | 19 --
 NetworkPkg/HttpBootDxe/HttpBootConfigVfr.vfr   |  6 +-
 3 files changed, 85 insertions(+), 17 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c 
b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
index 0c1ff43..e7dd5db 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
@@ -351,6 +351,7 @@ HttpBootFormExtractConfig (
   //
   BufferSize = sizeof (HTTP_BOOT_CONFIG_IFR_NVDATA);
   ZeroMem (>HttpBootNvData, BufferSize);
+  StrCpyS (CallbackInfo->HttpBootNvData.Description, DESCRIPTION_STR_MAX_SIZE 
/ sizeof (CHAR16), HTTP_BOOT_DEFAULT_DESCRIPTION_STR);
 
   ConfigRequest = Request;
   if ((Request == NULL) || (StrStr (Request, L"OFFSET") == NULL)) {
@@ -376,7 +377,6 @@ HttpBootFormExtractConfig (
 Results,
 Progress
 );
-  ASSERT_EFI_ERROR (Status);
   
   //
   // Free the allocated config request string.
@@ -487,14 +487,14 @@ HttpBootFormRouteConfig (
   //
   // Create a new boot option according to the configuration data.
   //
-  Status = HttpBootAddBootOption (
- Private,
- (CallbackInfo->HttpBootNvData.IpVersion == 
HTTP_BOOT_IP_VERSION_6) ? TRUE : FALSE,
- CallbackInfo->HttpBootNvData.Description,
- CallbackInfo->HttpBootNvData.Uri
- );
+  HttpBootAddBootOption (
+Private,
+(CallbackInfo->HttpBootNvData.IpVersion == HTTP_BOOT_IP_VERSION_6) ? TRUE 
: FALSE,
+CallbackInfo->HttpBootNvData.Description,
+CallbackInfo->HttpBootNvData.Uri
+);
   
-  return Status;
+  return EFI_SUCCESS;
 }
 
 /**
@@ -533,7 +533,66 @@ HttpBootFormCallback (
   OUT   EFI_BROWSER_ACTION_REQUEST   *ActionRequest
   )
 {
-  return EFI_UNSUPPORTED;
+  EFI_INPUT_KEY   Key;
+  UINTN   Index;
+  CHAR16  *Uri;
+  HTTP_BOOT_FORM_CALLBACK_INFO*CallbackInfo;
+  
+  if (This == NULL || Value == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  CallbackInfo = HTTP_BOOT_FORM_CALLBACK_INFO_FROM_CONFIG_ACCESS (This);
+  
+  if (Action != EFI_BROWSER_ACTION_CHANGING) {
+return EFI_UNSUPPORTED;
+  }
+  
+  switch (QuestionId) {
+  case KEY_INITIATOR_URI:
+//
+// Get user input URI string
+//
+Uri = HiiGetString (CallbackInfo->RegisteredHandle, Value->string, NULL);
+
+//
+// Convert the scheme to all lower case.
+//
+for (Index = 0; Index < StrLen (Uri); Index++) {
+  if (Uri[Index] == L':') {
+break;
+  }
+  if (Uri[Index] >= L'A' && Uri[Index] <= L'Z') {
+Uri[Index] -= (CHAR16)(L'A' - L'a');
+  }
+}
+
+//
+// Set the converted URI string back
+//
+HiiSetString (CallbackInfo->RegisteredHandle, Value->string, Uri, NULL);
+
+//
+// We only accept http and https, pop up a message box for unsupported URI.
+//
+if ((StrnCmp (Uri, L"http://;, 7) != 0) && (StrnCmp (Uri, L"https://;, 7) 
!= 0)) {
+  CreatePopUp (
+EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
+,
+L"ERROR: Unsupported URI!",
+L"Only supports HTTP and HTTPS",
+NULL
+);
+}
+
+FreePool (Uri);
+break;
+
+  default:
+break;
+  }
+
+  return EFI_SUCCESS;
 }
 
 /**
diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h 
b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
index 07043e7..37ce440 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
@@ -17,24 +17,31 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 
-#define HTTP_BOOT_IP_VERSION_4 0
-#define HTTP_BOOT_IP_VERSION_6 1
+#define HTTP_BOOT_IP_VERSION_4   0
+#define HTTP_BOOT_IP_VERSION_6   1
 
 //
 // Macros used for an IPv4 or an IPv6 address.
 //
-#define URI_STR_MIN_SIZE   8
-#define URI_STR_MAX_SIZE   255
+#define URI_STR_MIN_SIZE 8
+#define URI_STR_MAX_SIZE 255
+
+#define DESCRIPTION_STR_MIN_SIZE 6
+#define DESCRIPTION_STR_MAX_SIZE 75
 
 #define CONFIGURATION_VARSTORE_ID0x1234
 
-#define FORMID_MAIN_FORM1
+#define 

Re: [edk2] [Patch] MdeModulePkg/PciBus: Should reserve enough bus number for HPC

[Fan, Jeff]

Reviewed-off-by: Jeff Fan 

-Original Message-
From: Ni, Ruiyu 
Sent: Wednesday, March 23, 2016 2:16 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Fan, Jeff
Subject: [Patch] MdeModulePkg/PciBus: Should reserve enough bus number for HPC

When there is no bridge before the HPC (hot plug controller), the issue cannot 
be seen.
But when there are bridges before the HPC, the PciBus will only use the value 
(=  + ) as the sub-ordinary bus number for 
HPC.
The correct sub-ordinary bus number should be:
 + (by earlier bridges) + 
.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
index 12647be..f3407bc 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
@@ -1,7 +1,7 @@
 /** @file
   Internal library implementation for PCI Bus module.
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett Packard Enterprise Development LP  This program 
and the accompanying materials  are licensed and made available under the terms 
and conditions of the BSD License @@ -1232,7 +1232,7 @@ PciScanBus (
 //
 // Reserve the larger one between the actual occupied bus number 
and padded bus number
 //
-Status = PciAllocateBusNumber (PciDevice, StartBusNumber, (UINT8) 
(BusRange), );
+Status = PciAllocateBusNumber (PciDevice, SecondBus, 
+ (UINT8) (BusRange), );
 if (EFI_ERROR (Status)) {
   return Status;
 }
--
2.7.0.windows.1

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

[edk2] [Patch v2] BaseTools: not include the undefined macro in response file

[Yonghong Zhu]

In last Nmake patch, when we generate the response file, we would replace
all the Macros in the make file. Once there have undefined macro used,
the tool direct report error. In this patch, we use following solution to
resolve the failure.
1. Add all the defined macros into AutoGenObject macro dict
2. For the undefined macros which used in the Make file, when we generate
the response file, we not include this macro, let make phase to handle.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py |  6 +
 BaseTools/Source/Python/AutoGen/GenMake.py | 42 +-
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 4934c57..e9e46c2 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2478,10 +2478,16 @@ class ModuleAutoGen(AutoGen):
 self._Macro["MODULE_BUILD_DIR"  ] = self.BuildDir
 self._Macro["OUTPUT_DIR"] = self.OutputDir
 self._Macro["DEBUG_DIR" ] = self.DebugDir
 self._Macro["DEST_DIR_OUTPUT"   ] = self.OutputDir
 self._Macro["DEST_DIR_DEBUG"] = self.DebugDir
+self._Macro["PLATFORM_NAME" ] = self.PlatformInfo.Name
+self._Macro["PLATFORM_GUID" ] = self.PlatformInfo.Guid
+self._Macro["PLATFORM_VERSION"  ] = self.PlatformInfo.Version
+self._Macro["PLATFORM_RELATIVE_DIR" ] = self.PlatformInfo.SourceDir
+self._Macro["PLATFORM_DIR"  ] = 
mws.join(self.WorkspaceDir, self.PlatformInfo.SourceDir)
+self._Macro["PLATFORM_OUTPUT_DIR"   ] = self.PlatformInfo.OutputDir
 return self._Macro
 
 ## Return the module build data object
 def _GetModule(self):
 if self._Module == None:
diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 59ac2e8..a4844be 100644
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -475,10 +475,21 @@ cleanlib:
 ImageEntryPoint = ModuleEntryPoint
 else:
 # EdkII modules always use "_ModuleEntryPoint" as entry point
 ImageEntryPoint = "_ModuleEntryPoint"
 
+for k, v in self._AutoGenObject.Module.Defines.iteritems():
+if k not in self._AutoGenObject.Macros.keys():
+self._AutoGenObject.Macros[k] = v
+
+if 'MODULE_ENTRY_POINT' not in self._AutoGenObject.Macros.keys():
+self._AutoGenObject.Macros['MODULE_ENTRY_POINT'] = ModuleEntryPoint
+if 'ARCH_ENTRY_POINT' not in self._AutoGenObject.Macros.keys():
+self._AutoGenObject.Macros['ARCH_ENTRY_POINT'] = ArchEntryPoint
+if 'IMAGE_ENTRY_POINT' not in self._AutoGenObject.Macros.keys():
+self._AutoGenObject.Macros['IMAGE_ENTRY_POINT'] = ImageEntryPoint
+
 # tools definitions
 ToolsDef = []
 IncPrefix = self._INC_FLAG_[self._AutoGenObject.ToolChainFamily]
 for Tool in self._AutoGenObject.BuildOption:
 for Attr in self._AutoGenObject.BuildOption[Tool]:
@@ -502,14 +513,24 @@ cleanlib:
 RespFileList = os.path.join(self._AutoGenObject.OutputDir, 
'respfilelist.txt')
 if RespDict:
 RespFileListContent = ''
 for Resp in RespDict.keys():
 RespFile = os.path.join(self._AutoGenObject.OutputDir, 
str(Resp).lower() + '.txt')
-SaveFileOnChange(RespFile, RespDict[Resp], False)
-ToolsDef.append("%s = %s" % (Resp, '@' + RespFile))
+StrList = RespDict[Resp].split(' ')
+UnexpandMacro = []
+NewStr = []
+for Str in StrList:
+if '$' in Str:
+UnexpandMacro.append(Str)
+else:
+NewStr.append(Str)
+UnexpandMacroStr = ' '.join(UnexpandMacro)
+NewRespStr = ' '.join(NewStr)
+SaveFileOnChange(RespFile, NewRespStr, False)
+ToolsDef.append("%s = %s" % (Resp, UnexpandMacroStr + ' @' + 
RespFile))
 RespFileListContent += '@' + RespFile + os.linesep
-RespFileListContent += RespDict[Resp] + os.linesep
+RespFileListContent += NewRespStr + os.linesep
 SaveFileOnChange(RespFileList, RespFileListContent, False)
 else:
 if os.path.exists(RespFileList):
 os.remove(RespFileList)
 
@@ -676,18 +697,22 @@ cleanlib:
 if Tool:
 SingleCommandLength += 
len(self._AutoGenObject._BuildOption[Tool]['PATH'])
 for item in SingleCommandList[1:]:

[edk2] [Patch] MdeModulePkg/PciBus: Should reserve enough bus number for HPC

[Ruiyu Ni]

When there is no bridge before the HPC (hot plug controller),
the issue cannot be seen.
But when there are bridges before the HPC, the PciBus will only
use the value (=  + ) as the
sub-ordinary bus number for HPC.
The correct sub-ordinary bus number should be:
 + (by earlier bridges) +
.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
index 12647be..f3407bc 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
@@ -1,7 +1,7 @@
 /** @file
   Internal library implementation for PCI Bus module.
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -1232,7 +1232,7 @@ PciScanBus (
 //
 // Reserve the larger one between the actual occupied bus number 
and padded bus number
 //
-Status = PciAllocateBusNumber (PciDevice, StartBusNumber, (UINT8) 
(BusRange), );
+Status = PciAllocateBusNumber (PciDevice, SecondBus, (UINT8) 
(BusRange), );
 if (EFI_ERROR (Status)) {
   return Status;
 }
-- 
2.7.0.windows.1

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