Re: [edk2] [PATCH] MdeModulePkg/Bds: MemoryTypeInformation excludes boot option mem use

2016-07-05 Thread Wang, Sunny (HPS SW) 
The patch looks good. I also tested this patch on my system to boot a large 
size HTTP image (.iso), and it works well. Thanks for quickly working out the 
permanent fix.

Reviewed-by: Sunny Wang 

Regards,
Sunny Wang

-Original Message-
From: Ruiyu Ni [mailto:ruiyu...@intel.com] 
Sent: Tuesday, July 05, 2016 5:47 PM
To: edk2-devel@lists.01.org
Cc: Wang, Sunny (HPS SW) ; Star Zeng 
Subject: [PATCH] MdeModulePkg/Bds: MemoryTypeInformation excludes boot option 
mem use

The patch re-orders the sequences by putting updating memory type information 
before loading the boot option so that the reserved memory usage by HTTP RAM 
disk boot can be excluded by the memory type information updating.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Sunny Wang 
Cc: Star Zeng 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   | 41 +-
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 13 +--
 .../Library/UefiBootManagerLib/InternalBm.h|  5 +--
 3 files changed, 19 insertions(+), 40 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 4da401d..bb38f00 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1569,7 +1569,6 @@ EfiBootManagerBoot (
   UINTN FileSize;
   EFI_BOOT_LOGO_PROTOCOL*BootLogo;
   EFI_EVENT LegacyBootEvent;
-  UINTN RamDiskSizeInPages;
 
   if (BootOption == NULL) {
 return;
@@ -1643,8 +1642,24 @@ EfiBootManagerBoot (
   PERF_START_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) OptionNumber);
 
   //
-  // 5. Load EFI boot option to ImageHandle
+  // 5. Adjust the different type memory page number just before booting
+  //and save the updated info into the variable for next boot to use
+  //
+  BmSetMemoryTypeInformationVariable (
+(BOOLEAN) ((BootOption->Attributes & LOAD_OPTION_CATEGORY) == 
+ LOAD_OPTION_CATEGORY_BOOT)  );
+
   //
+  // 6. Load EFI boot option to ImageHandle  //  DEBUG_CODE_BEGIN ();  
+ if (BootOption->Description == NULL) {
+DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting from unknown device 
+ path\n"));  } else {
+DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting %s\n", 
+ BootOption->Description));  }  DEBUG_CODE_END ();
+
   ImageHandle   = NULL;
   RamDiskDevicePath = NULL;
   if (DevicePathType (BootOption->FilePath) != BBS_DEVICE_PATH) { @@ -1701,28 
+1716,6 @@ EfiBootManagerBoot (
   }
 
   //
-  // 6. Adjust the different type memory page number just before booting
-  //and save the updated info into the variable for next boot to use
-  //
-  if (RamDiskDevicePath == NULL) {
-RamDiskSizeInPages = 0;
-  } else {
-BmGetRamDiskMemoryInfo (RamDiskDevicePath, &RamDiskSizeInPages);
-  }
-  BmSetMemoryTypeInformationVariable (
-(BOOLEAN) ((BootOption->Attributes & LOAD_OPTION_CATEGORY) == 
LOAD_OPTION_CATEGORY_BOOT),
-RamDiskSizeInPages
-);
-
-  DEBUG_CODE_BEGIN();
-if (BootOption->Description == NULL) {
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting from unknown device 
path\n"));
-} else {
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting %s\n", 
BootOption->Description));
-}
-  DEBUG_CODE_END();
-
-  //
   // Check to see if we should legacy BOOT. If yes then do the legacy boot
   // Write boot to OS performance data for Legacy boot
   //
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index 93502fe..2a60f06 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -130,13 +130,10 @@ BmMatchDevicePaths (
 
   @param Boot   TRUE if current boot option belongs to boot
 category instead of application category.
-  @param RamDiskSizeInPages Reserved memory size in pages occupied by
-RAM Disk.
 **/
 VOID
 BmSetMemoryTypeInformationVariable (
-  IN BOOLEANBoot,
-  IN UINTN  RamDiskSizeInPages
+  IN BOOLEANBoot
   )
 {
   EFI_STATUS   Status;
@@ -230,14 +227,6 @@ BmSetMemoryTypeInformationVariable (
 }
 
 //
-// Do not count the reserved memory occupied by RAM Disk.
-//
-if ((CurrentMemoryTypeInformation[Index1].Type == EfiReservedMemoryType) &&
-(CurrentMemoryTypeInformation[Index1].NumberOfPages > ((UINT32) 
RamDiskSizeInPages))) {
-  CurrentMemoryTypeInformation[Index1].NumberOfPages -= (UINT32) 
RamDiskSizeInPages;
-}
-
-//
 // Previous is the number of pages pre-allocated
 // Current is the number of pages actually needed
 //
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index e1c5a96..07ee45b 100644
--- a/MdeModulePkg/Library/Uef

Re: [edk2] [PATCH] CryptoPkg: Fix openssl bn_exp to avoid alloca on RVCT

2016-07-05 Thread Long, Qin 
Will check this.
I didn't validate RVCT build before. I am curious if this is one new link 
issue? 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Wednesday, July 06, 2016 4:07 AM
> To: David Woodhouse; Ard Biesheuvel; leif.lindh...@linaro.org; Long, Qin;
> Ye, Ting
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] CryptoPkg: Fix openssl bn_exp to avoid alloca on
> RVCT
> 
> One more thing, I'm not sure how you want to address it, upstreaming or
> modifying the edk2 patch...
> 
> We also ran into an issue where we had to qualify the __GNUC__ check to
> exclude RVCT so that alloca wasn't used for allocations (it caused linker 
> errors
> trying to get library support that didn't exist).  Not defining it causes 
> openssl
> to use malloc instead.
> 
> Can you help upstream this one-liner?
> 
> Thanks,
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eugene Cohen 
> --
> 
> edk2/CryptoPkg/Library/OpensslLib/openssl-1.0.2g/crypto/bn/bn_exp.c | 2
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/edk2/CryptoPkg/Library/OpensslLib/openssl-
> 1.0.2g/crypto/bn/bn_exp.c b/edk2/CryptoPkg/Library/OpensslLib/openssl-
> 1.0.2g/crypto/bn/bn_exp.c
> index 1670f01..960228f 100644
> --- a/edk2/CryptoPkg/Library/OpensslLib/openssl-
> 1.0.2g/crypto/bn/bn_exp.c
> +++ b/edk2/CryptoPkg/Library/OpensslLib/openssl-
> 1.0.2g/crypto/bn/bn_exp.
> +++ c
> @@ -119,7 +119,7 @@
>  # ifndef alloca
>  #  define alloca _alloca
>  # endif
> -#elif defined(__GNUC__)
> +#elif defined(__GNUC__) && !defined(__CC_ARM)
>  # ifndef alloca
>  #  define alloca(s) __builtin_alloca((s))  # endif
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Cohen, Eugene
> > Sent: Tuesday, July 05, 2016 11:07 AM
> > To: David Woodhouse ; Ard Biesheuvel
> > ; leif.lindh...@linaro.org; Qin Long
> > ; Ting Ye 
> > Cc: edk2-devel@lists.01.org 
> > Subject: Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT
> > 3079
> >
> > > > corrects x509_vfy.c(875): error C3017: ok may be used before being
> > > set
> > > >
> > > > Change-Id: I0d38193569b29f96861a191908c343831fd957c2
> > > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > > Signed-off-by: Eugene Cohen 
> > >
> > > Can we "fix" the upstream code instead?
> >
> > No objection here - could I provide a patch that initializes 'ok' and
> > work with someone who already contributes to openssl to upstream it?
> >
> > Eugene
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] EmbeddedPkg/AcpiLib: add GICC table init macro for ACPI 6.0

2016-07-05 Thread Graeme Gregory 
ACPI 6.0 added a processor efficiency field and 3 reserved bytes at the
end of the GICC structure so add a new macro to initialise the new
field.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Graeme Gregory 
---
 EmbeddedPkg/Include/Library/AcpiLib.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/EmbeddedPkg/Include/Library/AcpiLib.h 
b/EmbeddedPkg/Include/Library/AcpiLib.h
index e5bcf56..704a2cd 100644
--- a/EmbeddedPkg/Include/Library/AcpiLib.h
+++ b/EmbeddedPkg/Include/Library/AcpiLib.h
@@ -61,6 +61,15 @@
 GsivId, GicRBase, Mpidr
  \
   }
 
+#define EFI_ACPI_6_0_GICC_STRUCTURE_INIT(GicId, AcpiCpuUid, Mpidr, Flags, 
PmuIrq,\
+GicBase, GicVBase, GicHBase, GsivId, GicRBase, Efficiency) 
  \
+  {
  \
+EFI_ACPI_6_0_GIC, sizeof (EFI_ACPI_6_0_GIC_STRUCTURE), 
EFI_ACPI_RESERVED_WORD,   \
+GicId, AcpiCpuUid, Flags, 0, PmuIrq, 0, GicBase, GicVBase, GicHBase,   
  \
+GsivId, GicRBase, Mpidr, Efficiency,   
  \
+{EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE}   
  \
+  }
+
 #define EFI_ACPI_6_0_GIC_MSI_FRAME_INIT(GicMsiFrameId, PhysicalBaseAddress, 
Flags, SPICount, SPIBase) \
   { \
 EFI_ACPI_6_0_GIC_MSI_FRAME, sizeof (EFI_ACPI_6_0_GIC_MSI_FRAME_STRUCTURE), 
EFI_ACPI_RESERVED_WORD, \
-- 
2.8.1

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

[edk2] [PATCH] CryptoPkg: Fix openssl bn_exp to avoid alloca on RVCT

2016-07-05 Thread Cohen, Eugene 
One more thing, I'm not sure how you want to address it, upstreaming or 
modifying the edk2 patch...

We also ran into an issue where we had to qualify the __GNUC__ check to exclude 
RVCT so that alloca wasn't used for allocations (it caused linker errors trying 
to get library support that didn't exist).  Not defining it causes openssl to 
use malloc instead.

Can you help upstream this one-liner?

Thanks,

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen 
--

edk2/CryptoPkg/Library/OpensslLib/openssl-1.0.2g/crypto/bn/bn_exp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/edk2/CryptoPkg/Library/OpensslLib/openssl-1.0.2g/crypto/bn/bn_exp.c 
b/edk2/CryptoPkg/Library/OpensslLib/openssl-1.0.2g/crypto/bn/bn_exp.c
index 1670f01..960228f 100644
--- a/edk2/CryptoPkg/Library/OpensslLib/openssl-1.0.2g/crypto/bn/bn_exp.c
+++ b/edk2/CryptoPkg/Library/OpensslLib/openssl-1.0.2g/crypto/bn/bn_exp.c
@@ -119,7 +119,7 @@
 # ifndef alloca
 #  define alloca _alloca
 # endif
-#elif defined(__GNUC__)
+#elif defined(__GNUC__) && !defined(__CC_ARM)
 # ifndef alloca
 #  define alloca(s) __builtin_alloca((s))
 # endif

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of Cohen, Eugene
> Sent: Tuesday, July 05, 2016 11:07 AM
> To: David Woodhouse ; Ard Biesheuvel
> ; leif.lindh...@linaro.org; Qin Long
> ; Ting Ye 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT
> 3079
> 
> > > corrects x509_vfy.c(875): error C3017: ok may be used before being
> > set
> > >
> > > Change-Id: I0d38193569b29f96861a191908c343831fd957c2
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Eugene Cohen 
> >
> > Can we "fix" the upstream code instead?
> 
> No objection here - could I provide a patch that initializes 'ok' and work
> with someone who already contributes to openssl to upstream it?
> 
> Eugene
> 
> ___
> 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] CryptoPkg: update openssl to ignore RVCT 3079

2016-07-05 Thread Cohen, Eugene 
> > corrects x509_vfy.c(875): error C3017: ok may be used before being
> set
> >
> > Change-Id: I0d38193569b29f96861a191908c343831fd957c2
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Eugene Cohen 
> 
> Can we "fix" the upstream code instead?

No objection here - could I provide a patch that initializes 'ok' and work with 
someone who already contributes to openssl to upstream it?

Eugene

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

Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT 3079

2016-07-05 Thread Long, Qin 
Yes, this unset issue was already fixed in OpenSSL HEAD.
The patch is OK for me to ignore the warning for current 1.0.2 version. Or we 
can backport some cleanups into our 1.0.2xx patch. 

Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David 
> Woodhouse
> Sent: Tuesday, July 5, 2016 11:59 PM
> To: Cohen, Eugene ; Ard Biesheuvel 
> ; leif.lindh...@linaro.org; Long, Qin
> ; Ye, Ting 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT 3079
> 
> On Tue, 2016-07-05 at 15:53 +, Cohen, Eugene wrote:
> > Getting openssl 1.0.2g building with ARM RVCT requires a change to ignore 
> > an unset
> > variable used before set was necessary.
> >
> > corrects x509_vfy.c(875): error C3017: ok may be used before being set
> >
> > Change-Id: I0d38193569b29f96861a191908c343831fd957c2
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Eugene Cohen 
> 
> Can we "fix" the upstream code instead?
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT 3079

2016-07-05 Thread David Woodhouse 
On Tue, 2016-07-05 at 15:53 +, Cohen, Eugene wrote:
> Getting openssl 1.0.2g building with ARM RVCT requires a change to ignore an 
> unset
> variable used before set was necessary.
> 
> corrects x509_vfy.c(875): error C3017: ok may be used before being set
> 
> Change-Id: I0d38193569b29f96861a191908c343831fd957c2
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eugene Cohen 

Can we "fix" the upstream code instead?

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

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

[edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT 3079

2016-07-05 Thread Cohen, Eugene 
Getting openssl 1.0.2g building with ARM RVCT requires a change to ignore an 
unset
variable used before set was necessary.

corrects x509_vfy.c(875): error C3017: ok may be used before being set

Change-Id: I0d38193569b29f96861a191908c343831fd957c2
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen 
---
 edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 8757100..0c3b609 100644
--- a/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/edk2/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -531,6 +531,7 @@
   #  546: transfer of control bypasses initialization - may be emitted 
inappropriately if the uninitialized
   #   variable is never referenced after the jump
   #1: ignore "#1-D: last line of file ends without a newline"
-  RVCT:*_*_ARM_CC_FLAGS = $(OPENSSL_FLAGS) 
--library_interface=aeabi_clib99 
--diag_suppress=1296,1295,550,1293,111,68,177,223,144,513,188,128,546,1 
-JCryptoPkg/Include
+  # 3017:  may be used before being set
+  RVCT:*_*_ARM_CC_FLAGS = $(OPENSSL_FLAGS) 
--library_interface=aeabi_clib99 
--diag_suppress=1296,1295,550,1293,111,68,177,223,144,513,188,128,546,1,3017 
-JCryptoPkg/Include
   XCODE:*_*_IA32_CC_FLAGS   = -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -w
   XCODE:*_*_X64_CC_FLAGS= -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -w
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-capable PCIe ports

2016-07-05 Thread Laszlo Ersek 
On 07/05/16 12:54, Laszlo Ersek wrote:
> On 07/04/16 09:38, Ni, Ruiyu wrote:
>> Adding Kinney.
>>
>> Laszlo,
>> Your patch assumes all PCIE slot are hot plug capable.
> 
> Yes, it does assume that.
> 
>> But why PCIE spec 3.0 chapter 7.8.9 Slot Capabilities Register (Offset 14h)
>> contains a BIT called Hot-Plug Capable?
>> Does your patch also need to check the Hot-Plug Capable bit as well?
> 
> I don't know :) I tried to follow the logic that I found in SeaBIOS and
> in UefiShellDebug1CommandsLib.
> 
> I think this is a valid question, of course. I'd just like to forward it
> to Marcel and Alex :) It is perfectly possible, as far as I understand,
> that QEMU's virtual hardware guarantees a "shortcut" that is not a given
> with physical hardware. So if the check must be restricted a bit, I'm
> glad to do it.

I checked the QEMU implementation in:
- hw/pci-bridge/xio3130_downstream.c (downstream port)
- hw/pci-bridge/ioh3420.c (root port)

They both call pcie_cap_slot_init().

The pcie_cap_slot_init() function [hw/pci/pcie.c] sets the "Hot-Plug Capable" 
bit (= bit 6) in the Slot Capabilities Register (Offset 14h):

uint32_t pos = dev->exp.exp_cap;
...
pci_long_test_and_set_mask(dev->config + pos + PCI_EXP_SLTCAP,
   (slot << PCI_EXP_SLTCAP_PSN_SHIFT) |
   PCI_EXP_SLTCAP_EIP |
   PCI_EXP_SLTCAP_HPS |
   PCI_EXP_SLTCAP_HPC |
   PCI_EXP_SLTCAP_PIP |
   PCI_EXP_SLTCAP_AIP |
   PCI_EXP_SLTCAP_ABP);

where the relevant macros are [include/standard-headers/linux/pci_regs.h]:

#define PCI_EXP_SLTCAP  20  /* Slot Capabilities */
...
#define  PCI_EXP_SLTCAP_HPC 0x0040 /* Hot-Plug Capable */

Also, from the PCIe spec ("7.8. PCI Express Capability Structure"):

[...] The Slot Capabilities register is required if the Slot Implemented 
bit is
Set (see Section 7.8.2). [...]

so it shouldn't be hard to implement your suggestion for v2 of this patch; I'll 
do it.

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

Re: [edk2] [PATCH] OvmfPkg/build.sh: update gcc detection

2016-07-05 Thread Laszlo Ersek 
On 06/30/16 12:16, Laszlo Ersek wrote:
> On 06/30/16 07:00, Olaf Hering wrote:
>> On Wed, Jun 29, Jordan Justen wrote:
>>
>>> Missing Contributed-under. (See OvmfPkg/Contributions.txt)
>>
>> Looks like this project tries to avoid simple fixes from third party.
> 
> It's not the case. Every project has its contribution rules (I reckon
> xen-devel is no exception). It takes some time to set everything up in
> order to contribute in accordance with the rules, but that's a one time
> cost for every contributor.
> 
> If we encouraged drive-by patches without regard to the process, then it
> would be a constant cost for long term participants / maintainers.
> 
> I do agree with you on two points -- I find these unjustified /
> gratuitous burdens:
> - the Contributed-under line
> - having to subscribe to the mailing list in order to post
> 
> The first is alas a legal requirement, and I can't do anything about it.
> Luckily, it can be automated at least. See for example
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-07
> 
> The second (the subscription requirement) is terrible. No other open
> source project I'm aware of follows that requirement. I've raised it
> several times, but other subscribers on the list disagree with me.
> 
>> I'm done with it.
> 
> I'm sorry to hear that. I don't really see why you can't post a v2 of
> your patch, with all the remarks addressed, considering you will likely
> carry such a patch in your downstream anyway. I encourage you to send a v2.

I guess you decided not to do it. :(

Jordan: do you think I can pick up Olaf's patch and resubmit it with
your remarks addressed? I'm asking because the original patch did not
have the Contributed-under line, and I wonder if it's okay if I add:

  Signed-off-by: Olaf Hering 
  Fixes: https://github.com/tianocore/edk2/issues/99
  [ler...@redhat.com: update commit message]
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Laszlo Ersek 

I think we've seen such examples on the list recently (i.e., one author
writing the original patch internally at a company, without the
Contributed-under line, then another contributor picking it up and
posting it according to Contributions.txt, preserving the original
authorship too). I think it should work but I figured I'd ask you first.

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

Re: [edk2] multiprocessing in PEI?

2016-07-05 Thread Fan, Jeff 
When CPU MP PPI installed, CPU MP PPI Services will be fully usable.

Thanks!
Jeff
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, July 05, 2016 9:10 PM
To: Kinney, Michael D; Fan, Jeff; Justen, Jordan L
Cc: Paolo Bonzini; edk2-devel-01
Subject: Re: [edk2] multiprocessing in PEI?

On 07/05/16 12:01, Laszlo Ersek wrote:

> Not sure if we should add this client code to OvmfPkg/PlatformPei, due 
> to the DEPEX. OvmfPkg/PlatformPei is the PEIM that installs the 
> permanent PEI RAM, so if we added this DEPEX to it, that would force 
> CpuMpPei to run from temporary PEI RAM. I don't know if that would be 
> feasible. ... Actually, it would lead to a DEPEX circle: CpuMpPei 
> explicitly depends on gEfiPeiMemoryDiscoveredPpiGuid (it can only run 
> from permament PEI RAM). So a separate client PEIM for OvmfPkg would 
> be mandatory.

Alternatively, we could use EFI_PEI_SERVICES.NotifyPpi() from 
OvmfPkg/PlatformPei, I guess. That would require that the 
EFI_PEI_MP_SERVICES_PPI services be fully usable as soon as the callback is 
called.

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

Re: [edk2] multiprocessing in PEI?

2016-07-05 Thread Laszlo Ersek 
On 07/05/16 12:01, Laszlo Ersek wrote:

> Not sure if we should add this client code to OvmfPkg/PlatformPei, due
> to the DEPEX. OvmfPkg/PlatformPei is the PEIM that installs the
> permanent PEI RAM, so if we added this DEPEX to it, that would force
> CpuMpPei to run from temporary PEI RAM. I don't know if that would be
> feasible. ... Actually, it would lead to a DEPEX circle: CpuMpPei
> explicitly depends on gEfiPeiMemoryDiscoveredPpiGuid (it can only run
> from permament PEI RAM). So a separate client PEIM for OvmfPkg would be
> mandatory.

Alternatively, we could use EFI_PEI_SERVICES.NotifyPpi() from
OvmfPkg/PlatformPei, I guess. That would require that the
EFI_PEI_MP_SERVICES_PPI services be fully usable as soon as the callback
is called.

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

[edk2] UEFI driver for USB CDC ACM Serial device

2016-07-05 Thread GN Keshava 
Hi all,

I'm new to UEFI development.
So far, I have learnt about UEFI shell, build procedure and application
basics.

My task is to communicate to a custom board from UEFI using uefi app
through a USB serial cable from the PC.

Currently, the PC is booted to UEFI shell and connected the board through
serial cable and I type "devices" command, I see that the board is listed as

"344 : CDC Abstract Control Model (CDC)"
and
"345: CDC ACM Data"

Please help me to understand how I can proceed? and what works I need to do
in order to detect my board as Serial port? Is there any driver available
for this? If I need to develop the driver, please help me on what would be
the starting point?

Thanks.
With regards.
Keshava GN
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-capable PCIe ports

2016-07-05 Thread Laszlo Ersek 
On 07/04/16 09:38, Ni, Ruiyu wrote:
> Adding Kinney.
> 
> Laszlo,
> Your patch assumes all PCIE slot are hot plug capable.

Yes, it does assume that.

> But why PCIE spec 3.0 chapter 7.8.9 Slot Capabilities Register (Offset 14h)
> contains a BIT called Hot-Plug Capable?
> Does your patch also need to check the Hot-Plug Capable bit as well?

I don't know :) I tried to follow the logic that I found in SeaBIOS and
in UefiShellDebug1CommandsLib.

I think this is a valid question, of course. I'd just like to forward it
to Marcel and Alex :) It is perfectly possible, as far as I understand,
that QEMU's virtual hardware guarantees a "shortcut" that is not a given
with physical hardware. So if the check must be restricted a bit, I'm
glad to do it.

> BTW, though I am the owner of PciBus driver in EDKII, I am really a newbie to
> this area.
> Before your patch, I always thought PciHotPlugInit.GetRootHpcList() should
> return all hot plug PCIE ports. But after seeing your patch, I went back to
> re-read the PI spec and found some words like "root HPCs", "may not be
> able to detect these HPCs", which let me agree with your understanding
> that GetRootHpcList() only returns these HPCs that cannot be detected by
> PciBus.

Thank you very much for spending time on this. I stared at the same PI
spec pages that you mention for a long time, and ultimately I thought
that GetRootHpcList() should return only those hotplug-providing ports
that are non-enumerable. In other words, the spec's wording "root Hot
Plug Controllers" does not mean "PCIe root ports"; instead it seems to
mean "a hotplug controller that cannot be found by way of the usual
enumeration (and might need special initialization)".

To my knowledge, QEMU has no such thing. (Definitely not in the scope of
this series.)

Thanks!
Laszlo

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, July 1, 2016 9:11 AM
>> To: edk2-devel-01 
>> Cc: Ni, Ruiyu ; Tian, Feng ;
>> Johnson, Brian J. ; Andrew Fish ;
>> Justen, Jordan L ; Marcel Apfelbaum
>> ; Zeng, Star 
>> Subject: [edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-
>> capable PCIe ports
>>
>> Section 7.8.2 of the PCI Express specification (r4.0 v0.3), entitled "PCI 
>> Express
>> Capabilities Register (Offset 02h)", describes the conditions when a PCIe 
>> port
>> should be considered "supporting hotplug":
>> - it should be a root complex port or a switch downstream port, and
>> - it should have the "Slot Implemented" bit set.
>>
>> This logic is already implemented in at least two open source projects I 
>> could
>> find:
>>
>> - in SeaBIOS by Marcel Apfelbaum: "hw/pci: reserve IO and mem for pci
>>   express downstream ports with no devices attached"
>>   ,
>>
>> - in edk2 itself, in the implementation of the "PCI" UEFI Shell command:
>>   see the "PcieExplainTypeSlot" case label in function
>>   PciExplainPciExpress(), file
>>   "ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c".
>>
>> PciBusDxe recognizes such PCIe ports as bridges, but it doesn't realize they
>> support hotplug. In turn PciBusDxe omits getting any resource padding
>> information from the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL for
>> these
>> bridges:
>>
>>   GatherPpbInfo()[PciEnumeratorSupport.c]
>> GetResourcePaddingPpb()  [PciResourceSupport.c]
>>   GetResourcePaddingForHpb() [PciHotPlugSupport.c]
>> IsPciHotPlugBus()[PciHotPlugSupport.c]
>>   //
>>   // returns FALSE
>>   //
>> //
>> // the following is not reached:
>> //
>> gPciHotPlugInit->GetResourcePadding()
>>
>> Implement a function called SupportsPcieHotplug() for identifying such ports,
>> and call it from IsPciHotPlugBus() (after the call to IsSHPC()).
>>
>> Cc: "Johnson, Brian J." 
>> Cc: Alex Williamson 
>> Cc: Andrew Fish 
>> Cc: Feng Tian 
>> Cc: Jordan Justen 
>> Cc: Marcel Apfelbaum 
>> Cc: Ruiyu Ni 
>> Cc: Star Zeng 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h | 19 ++
>> MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c | 71
>> 
>>  2 files changed, 90 insertions(+)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
>> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
>> index 1fb9ba972091..6e02b8b98bf0 100644
>> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
>> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
>> @@ -177,6 +177,25 @@ IsSHPC (
>>);
>>
>>  /**
>> +  Check whether PciIoDevice supports PCIe hotplug.
>> +
>> +  This is equivalent to the following condition:
>> +  - the device is either a PCIe switch downstream port or a root port,
>> +  - and the device has the SlotImplemented bit set in its PCIe capability
>> +register.
>>

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

2016-07-05 Thread Laszlo Ersek 
On 07/04/16 08:20, Gao, Liming wrote:
> Laszlo:
> MdeModulePkg ones follows PI spec to implement StatusCode
> Router/Handler and provide StatusCode service. It allows the
> different status code handlers to be registered.
> IntelFrameworkModulePkg one just provides StatusCode service. It has
> no Router services.
> 
> StatusCode service is used to report the boot status. It is also used
> to print debug message. For example, PeiDxeDebugLibReportStatusCode
> library instance bases on StatusCode to print DEBUG message.

Thanks!

For now I filed , so that
we don't forget about this.

Cheers
Laszlo

> 
> Thanks
> Liming
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, June 30, 2016 6:18 PM
>> To: Gao, Liming ; Bruce Cran ;
>> Cinnamon Shia ; edk2-de...@ml01.01.org
>> Cc: Tian, Feng ; Zeng, Star 
>> Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose
>> the DXE memory status code table.
>>
>> On 06/30/16 04:40, Gao, Liming wrote:
>>> Laszlo:
>>> I have sent the patch to fix it.
>>
>> Thanks!
>>
>>> Besides, I suggest to update Ovmf
>>> DSC/FDF to use StatusCode Router and Handler from MdeModulePkg
>>> instead of IntelFrameworkModulePkg.
>>
>> What's the difference between them?
>>
>> Actually, what do these drivers do? (I don't know why we include them in
>> OVMF.)
>>
>> Thanks!
>> Laszlo
>>
>>>
>>> Thanks
>>> Liming
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 Gao, Liming
 Sent: Thursday, June 30, 2016 9:02 AM
 To: Laszlo Ersek ; Bruce Cran ;
 Cinnamon Shia ; edk2-de...@ml01.01.org
 Cc: Tian, Feng ; Zeng, Star 
 Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode:
>> Expose
 the DXE memory status code table.

 Yes. I will make one patch to fix it. Thanks for your report.

 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: Thursday, June 30, 2016 1:40 AM
 To: Bruce Cran ; Cinnamon Shia
 ; edk2-de...@ml01.01.org
 Cc: Tian, Feng ; Gao, Liming
>> ;
 Zeng, Star 
 Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode:
>> Expose
 the DXE memory status code table.

 On 06/29/16 16:47, Bruce Cran wrote:
> On 6/27/2016 1:25 AM, Cinnamon Shia wrote:
>> Let data of DXE memory status code can be used by other modules.
>> 1. Save the address of DXE memory status code table to
>> DxeConfigurationTable.
>> 2. Save the address of SMM memory status code table to
>> SmmConfigurationTable.
>> 3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public
>> header
 file.
>
> I'm getting an error building OVMF today, which appears related:
>
> In file included from
>

>> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
 sCode/RuntimeDxe/SerialStatusCodeWorker.c:15:0:
>
>

>> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
 sCode/RuntimeDxe/StatusCodeRuntimeDxe.h:63:3:
> error: conflicting types for 'RUNTIME_MEMORY_STATUSCODE_HEADER'
> } RUNTIME_MEMORY_STATUSCODE_HEADER;
> ^~~~
> In file included from
>

>> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
 sCode/RuntimeDxe/StatusCodeRuntimeDxe.h:22:0,
>
> from
>

>> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
 sCode/RuntimeDxe/SerialStatusCodeWorker.c:15:
>
>

>> /home/bcran/workspace/edk2/MdeModulePkg/Include/Guid/MemoryStat
 usCodeRecord.h:76:3:
> note: previous declaration of
>> 'RUNTIME_MEMORY_STATUSCODE_HEADER'
 was here
> } RUNTIME_MEMORY_STATUSCODE_HEADER;
> ^~~~
>

 Yes, the file


>> IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCode
 RuntimeDxe.h

 includes

 MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h

 but also defines the RUNTIME_MEMORY_STATUSCODE_HEADER type,
>> which
 has
 now become redundant.

 As far as I can see, it should be fixable by removing the
 RUNTIME_MEMORY_STATUSCODE_HEADER typedef from

>> "IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCod
 eRuntimeDxe.h".

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

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

Re: [edk2] [Patch] MdeModulePkg: Fix IPv4 stack potential disappeared issue

2016-07-05 Thread Zhang, Lubo 
The patch is good to me, already tested.
Reviewed-by: Zhang Lubo 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Thursday, June 30, 2016 3:59 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Zhang, Lubo ; Fu, 
Siyuan 
Subject: [edk2] [Patch] MdeModulePkg: Fix IPv4 stack potential disappeared issue

IP4_CONFIG2_INSTANCE->DataItem is used to save the configuration data to NV 
variable. When the policy is changed from static to DHCP, DnsServers info will 
be cleaned from DataItem first (See Ip4Config2SetPolicy), it's correct because 
DnsServers info should not be saved to NV variable.
But if there is any DnsServers info received from DHCP message, it will be 
reset to DataItem again (See Ip4Config2SetDnsServerWorker), which may cause the 
NV variable contain the DnsServers info while the policy is DHCP (See 
Ip4Config2WriteConfigData).
Then, while the platform is reset, the issue happened. Because 
Ip4Config2DataTypeDnsServer is set under DHCP policy, which is not allowed by 
UEFI Spec and error returned.

This patch is used to resolve this potential issue.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 12 +++-  
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.h |  1 +
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c  |  4 
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index 028c61d..f91a935 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -1058,11 +1058,10 @@ Ip4Config2GetIfInfo (
   IN IP4_CONFIG2_INSTANCE *Instance,
   IN OUT UINTN*DataSize,
   IN VOID *Data  OPTIONAL
   )
 {
-
   IP4_SERVICE*IpSb;
   UINTN  Length;
   IP4_CONFIG2_DATA_ITEM  *Item;
   EFI_IP4_CONFIG2_INTERFACE_INFO *IfInfo;
   IP4_ADDR   Address;
@@ -1177,10 +1176,11 @@ Ip4Config2SetPolicy (
 FreePool (DataItem->Data.Ptr);
   }
   DataItem->Data.Ptr = NULL;
   DataItem->DataSize = 0;
   DataItem->Status   = EFI_NOT_FOUND;
+  SET_DATA_ATTRIB (DataItem->Attribute, DATA_ATTRIB_VOLATILE);
   NetMapIterate (&DataItem->EventMap, Ip4Config2SignalEvent, NULL);
 } else {
   //
   // The policy is changed from dhcp to static. Stop the DHCPv4 process
   // and destroy the DHCPv4 child.
@@ -1457,14 +1457,24 @@ Ip4Config2SetDnsServer (
   IN IP4_CONFIG2_INSTANCE *Instance,
   IN UINTNDataSize,
   IN VOID *Data
   )
 {
+  IP4_CONFIG2_DATA_ITEM *Item;
+
+  Item = NULL;
+
   if (Instance->Policy != Ip4Config2PolicyStatic) {
 return EFI_WRITE_PROTECTED;
   }
 
+  Item = &Instance->DataItem[Ip4Config2DataTypeDnsServer];
+
+  if (DATA_ATTRIB_SET (Item->Attribute, DATA_ATTRIB_VOLATILE)) {
+REMOVE_DATA_ATTRIB (Item->Attribute, DATA_ATTRIB_VOLATILE);  }
+
   return Ip4Config2SetDnsServerWorker (Instance, DataSize, Data);  }
 
 /**
   Generate the operational state of the interface this IP4 config2 instance 
manages diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.h 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.h
index b2665bd..b6da11f 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.h
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.h
@@ -25,10 +25,11 @@
 #define DATA_ATTRIB_SIZE_FIXED  0x1
 #define DATA_ATTRIB_VOLATILE0x2
 
 #define DATA_ATTRIB_SET(Attrib, Bits)   (BOOLEAN)((Attrib) & (Bits))
 #define SET_DATA_ATTRIB(Attrib, Bits)   ((Attrib) |= (Bits))
+#define REMOVE_DATA_ATTRIB(Attrib, Bits)((Attrib) &= (~Bits))
 
 typedef struct _IP4_CONFIG2_INSTANCE IP4_CONFIG2_INSTANCE;
 
 #define IP4_CONFIG2_INSTANCE_FROM_PROTOCOL(Proto) \
   CR ((Proto), \
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index fcd3ccb..20bc21f 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -596,10 +596,14 @@ Ip4DriverBindingStart (
   DataItem->Data.Ptr
   );
   if (EFI_ERROR(Status)) {
 goto UNINSTALL_PROTOCOL;
   }
+  
+  if (Index == Ip4Config2DataTypePolicy && (*(DataItem->Data.Policy) == 
Ip4Config2PolicyDhcp)) {
+break;
+  }
 }
   }
  
   //
   // Ready to go: start the receiving and timer.
--
1.9.5.msysgit.1

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

[edk2] multiprocessing in PEI?

2016-07-05 Thread Laszlo Ersek 
Hi,

for this item :

  RFE: OvmfPkg: Set MSR_IA32_FEATURE_CONTROL by following QEMU
  fw_cfg file

the goal is to do the following:
- fetch a UINT64 value from QEMU via fw_cfg
- write that UINT64 value to a specific MSR on *all* logical processors
  (BSP and all APs)
- write the MSR on the normal boot path and the S3 resume boot path.

I've been wrecking my brain on this. Everything I've come up with thus
far looks convoluted and ugly (the multiprocessing part).

I realize there is "UefiCpuPkg/CpuMpPei", producing
EFI_PEI_MP_SERVICES_PPI. Do you guys think it would be appropriate for
this purpose?

We could add this driver to OVMF's PEI phase. And, add another PEIM that
would:
- depend on this PPI with a DEPEX,
- fetch the UINT64 from fw-cfg, and call
  EFI_PEI_MP_SERVICES_PPI.StartupAllAPs()s to set the MSR.

Not sure if we should add this client code to OvmfPkg/PlatformPei, due
to the DEPEX. OvmfPkg/PlatformPei is the PEIM that installs the
permanent PEI RAM, so if we added this DEPEX to it, that would force
CpuMpPei to run from temporary PEI RAM. I don't know if that would be
feasible. ... Actually, it would lead to a DEPEX circle: CpuMpPei
explicitly depends on gEfiPeiMemoryDiscoveredPpiGuid (it can only run
from permament PEI RAM). So a separate client PEIM for OvmfPkg would be
mandatory.

Another question is if I'd be allowed to call AsmWriteMsr64() in the AP
routine (reading the UINT64 from a global variable or the main thread's
stack via the ProcedureArgument pointer). That routine seems very small
and self-contained, so I think assembly code would not be necessary.

What do you guys think?

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

Re: [edk2] [PATCH] MdeModulePkg/Bds: MemoryTypeInformation excludes boot option mem use

2016-07-05 Thread Zeng, Star 
Reviewed-by: Star Zeng 

-Original Message-
From: Ni, Ruiyu 
Sent: Tuesday, July 5, 2016 5:47 PM
To: edk2-devel@lists.01.org
Cc: Sunny Wang ; Zeng, Star 
Subject: [PATCH] MdeModulePkg/Bds: MemoryTypeInformation excludes boot option 
mem use

The patch re-orders the sequences by putting updating memory type information 
before loading the boot option so that the reserved memory usage by HTTP RAM 
disk boot can be excluded by the memory type information updating.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Sunny Wang 
Cc: Star Zeng 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   | 41 +-
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 13 +--
 .../Library/UefiBootManagerLib/InternalBm.h|  5 +--
 3 files changed, 19 insertions(+), 40 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 4da401d..bb38f00 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1569,7 +1569,6 @@ EfiBootManagerBoot (
   UINTN FileSize;
   EFI_BOOT_LOGO_PROTOCOL*BootLogo;
   EFI_EVENT LegacyBootEvent;
-  UINTN RamDiskSizeInPages;
 
   if (BootOption == NULL) {
 return;
@@ -1643,8 +1642,24 @@ EfiBootManagerBoot (
   PERF_START_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) OptionNumber);
 
   //
-  // 5. Load EFI boot option to ImageHandle
+  // 5. Adjust the different type memory page number just before booting
+  //and save the updated info into the variable for next boot to use
+  //
+  BmSetMemoryTypeInformationVariable (
+(BOOLEAN) ((BootOption->Attributes & LOAD_OPTION_CATEGORY) == 
+ LOAD_OPTION_CATEGORY_BOOT)  );
+
   //
+  // 6. Load EFI boot option to ImageHandle  //  DEBUG_CODE_BEGIN ();  
+ if (BootOption->Description == NULL) {
+DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting from unknown device 
+ path\n"));  } else {
+DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting %s\n", 
+ BootOption->Description));  }  DEBUG_CODE_END ();
+
   ImageHandle   = NULL;
   RamDiskDevicePath = NULL;
   if (DevicePathType (BootOption->FilePath) != BBS_DEVICE_PATH) { @@ -1701,28 
+1716,6 @@ EfiBootManagerBoot (
   }
 
   //
-  // 6. Adjust the different type memory page number just before booting
-  //and save the updated info into the variable for next boot to use
-  //
-  if (RamDiskDevicePath == NULL) {
-RamDiskSizeInPages = 0;
-  } else {
-BmGetRamDiskMemoryInfo (RamDiskDevicePath, &RamDiskSizeInPages);
-  }
-  BmSetMemoryTypeInformationVariable (
-(BOOLEAN) ((BootOption->Attributes & LOAD_OPTION_CATEGORY) == 
LOAD_OPTION_CATEGORY_BOOT),
-RamDiskSizeInPages
-);
-
-  DEBUG_CODE_BEGIN();
-if (BootOption->Description == NULL) {
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting from unknown device 
path\n"));
-} else {
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting %s\n", 
BootOption->Description));
-}
-  DEBUG_CODE_END();
-
-  //
   // Check to see if we should legacy BOOT. If yes then do the legacy boot
   // Write boot to OS performance data for Legacy boot
   //
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index 93502fe..2a60f06 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -130,13 +130,10 @@ BmMatchDevicePaths (
 
   @param Boot   TRUE if current boot option belongs to boot
 category instead of application category.
-  @param RamDiskSizeInPages Reserved memory size in pages occupied by
-RAM Disk.
 **/
 VOID
 BmSetMemoryTypeInformationVariable (
-  IN BOOLEANBoot,
-  IN UINTN  RamDiskSizeInPages
+  IN BOOLEANBoot
   )
 {
   EFI_STATUS   Status;
@@ -230,14 +227,6 @@ BmSetMemoryTypeInformationVariable (
 }
 
 //
-// Do not count the reserved memory occupied by RAM Disk.
-//
-if ((CurrentMemoryTypeInformation[Index1].Type == EfiReservedMemoryType) &&
-(CurrentMemoryTypeInformation[Index1].NumberOfPages > ((UINT32) 
RamDiskSizeInPages))) {
-  CurrentMemoryTypeInformation[Index1].NumberOfPages -= (UINT32) 
RamDiskSizeInPages;
-}
-
-//
 // Previous is the number of pages pre-allocated
 // Current is the number of pages actually needed
 //
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index e1c5a96..07ee45b 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
+++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
@@ -207,13 +207,10 @@ BmWriteBootToOsPerformanceData (
 
   @param Boot   TRUE if current boot option belongs to boot

[edk2] [PATCH] MdeModulePkg/Bds: MemoryTypeInformation excludes boot option mem use

2016-07-05 Thread Ruiyu Ni 
The patch re-orders the sequences by putting updating memory type
information before loading the boot option so that the reserved
memory usage by HTTP RAM disk boot can be excluded by the memory
type information updating.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Sunny Wang 
Cc: Star Zeng 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   | 41 +-
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 13 +--
 .../Library/UefiBootManagerLib/InternalBm.h|  5 +--
 3 files changed, 19 insertions(+), 40 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 4da401d..bb38f00 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1569,7 +1569,6 @@ EfiBootManagerBoot (
   UINTN FileSize;
   EFI_BOOT_LOGO_PROTOCOL*BootLogo;
   EFI_EVENT LegacyBootEvent;
-  UINTN RamDiskSizeInPages;
 
   if (BootOption == NULL) {
 return;
@@ -1643,8 +1642,24 @@ EfiBootManagerBoot (
   PERF_START_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) OptionNumber);
 
   //
-  // 5. Load EFI boot option to ImageHandle
+  // 5. Adjust the different type memory page number just before booting
+  //and save the updated info into the variable for next boot to use
+  //
+  BmSetMemoryTypeInformationVariable (
+(BOOLEAN) ((BootOption->Attributes & LOAD_OPTION_CATEGORY) == 
LOAD_OPTION_CATEGORY_BOOT)
+  );
+
   //
+  // 6. Load EFI boot option to ImageHandle
+  //
+  DEBUG_CODE_BEGIN ();
+  if (BootOption->Description == NULL) {
+DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting from unknown device 
path\n"));
+  } else {
+DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting %s\n", 
BootOption->Description));
+  }
+  DEBUG_CODE_END ();
+
   ImageHandle   = NULL;
   RamDiskDevicePath = NULL;
   if (DevicePathType (BootOption->FilePath) != BBS_DEVICE_PATH) {
@@ -1701,28 +1716,6 @@ EfiBootManagerBoot (
   }
 
   //
-  // 6. Adjust the different type memory page number just before booting
-  //and save the updated info into the variable for next boot to use
-  //
-  if (RamDiskDevicePath == NULL) {
-RamDiskSizeInPages = 0;
-  } else {
-BmGetRamDiskMemoryInfo (RamDiskDevicePath, &RamDiskSizeInPages);
-  }
-  BmSetMemoryTypeInformationVariable (
-(BOOLEAN) ((BootOption->Attributes & LOAD_OPTION_CATEGORY) == 
LOAD_OPTION_CATEGORY_BOOT),
-RamDiskSizeInPages
-);
-
-  DEBUG_CODE_BEGIN();
-if (BootOption->Description == NULL) {
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting from unknown device 
path\n"));
-} else {
-  DEBUG ((DEBUG_INFO | DEBUG_LOAD, "[Bds]Booting %s\n", 
BootOption->Description));
-}
-  DEBUG_CODE_END();
-
-  //
   // Check to see if we should legacy BOOT. If yes then do the legacy boot
   // Write boot to OS performance data for Legacy boot
   //
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index 93502fe..2a60f06 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -130,13 +130,10 @@ BmMatchDevicePaths (
 
   @param Boot   TRUE if current boot option belongs to boot
 category instead of application category.
-  @param RamDiskSizeInPages Reserved memory size in pages occupied by
-RAM Disk.
 **/
 VOID
 BmSetMemoryTypeInformationVariable (
-  IN BOOLEANBoot,
-  IN UINTN  RamDiskSizeInPages
+  IN BOOLEANBoot
   )
 {
   EFI_STATUS   Status;
@@ -230,14 +227,6 @@ BmSetMemoryTypeInformationVariable (
 }
 
 //
-// Do not count the reserved memory occupied by RAM Disk.
-//
-if ((CurrentMemoryTypeInformation[Index1].Type == EfiReservedMemoryType) &&
-(CurrentMemoryTypeInformation[Index1].NumberOfPages > ((UINT32) 
RamDiskSizeInPages))) {
-  CurrentMemoryTypeInformation[Index1].NumberOfPages -= (UINT32) 
RamDiskSizeInPages;
-}
-
-//
 // Previous is the number of pages pre-allocated
 // Current is the number of pages actually needed
 //
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index e1c5a96..07ee45b 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
+++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
@@ -207,13 +207,10 @@ BmWriteBootToOsPerformanceData (
 
   @param Boot   TRUE if current boot option belongs to boot
 category instead of application category.
-  @param RamDiskSizeInPages Reserved memory size in pages occupied by
-RAM Disk.
 **/
 VOID
 BmSetMemoryTypeInformationVariable (
-  IN BOOLEAN

[edk2] [patch] MdeModulePkg/HiiDB: Record fail info if fail to save data for EfiVarStore

2016-07-05 Thread Dandan Bi 
HiiConfigRoutingRouteConfig function returns 'Progress' to indicate
the failure info in the ConfigResp string. But when fail to route the
ConfigResp for EfiVarStore, it doesn't return the correct failure info.
Now this patch is to fix this issue and add debug info let user know the
reason of failure.

Cc: Liming Gao 
Cc: Eric Dong 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
---
 MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index 106f25d..0578352 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -4058,10 +4058,11 @@ RouteConfigRespForEfiVarStore (
 
   Status   = EFI_SUCCESS;
   BufferSize   = 0;
   VarStore = NULL;
   VarStoreName = NULL;
+  *Result = RequestResp;
 
   NameSize = AsciiStrSize ((CHAR8 *)EfiVarStoreInfo->Name);
   VarStoreName = AllocateZeroPool (NameSize * sizeof (CHAR16));
   if (VarStoreName == NULL) {
 Status = EFI_OUT_OF_RESOURCES;
@@ -4069,10 +4070,11 @@ RouteConfigRespForEfiVarStore (
   }
   AsciiStrToUnicodeStrS ((CHAR8 *) EfiVarStoreInfo->Name, VarStoreName, 
NameSize);
   
   Status = gRT->GetVariable (VarStoreName, &EfiVarStoreInfo->Guid, NULL, 
&BufferSize, NULL);
   if (Status != EFI_BUFFER_TOO_SMALL) {
+DEBUG ((DEBUG_ERROR, "The variable does not exist!"));
 goto Done;
   }
 
   BlockSize = BufferSize;
   VarStore = AllocateZeroPool (BufferSize);
@@ -4087,10 +4089,11 @@ RouteConfigRespForEfiVarStore (
 goto Done;
   }
 
   Status = gRT->SetVariable (VarStoreName, &EfiVarStoreInfo->Guid, 
EfiVarStoreInfo->Attributes, BufferSize, VarStore);
   if (EFI_ERROR (Status)) {
+*Result = RequestResp;
 goto Done;
   }
 
 Done:
   if (VarStoreName != NULL) {
-- 
1.9.5.msysgit.1

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

[edk2] [patch] MdeModulePkg/BootMaintUi: Add error handling codes when AllocatePool fail

2016-07-05 Thread Dandan Bi 
The AllocateCopyPool in function ExtractFileNameFromDevicePath
may return NULL, so need to do error handling. This patch is to
add error handling codes for function ExtractFileNameFromDevicePath
and its caller functions.

Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
---
 .../BootMaintenanceManagerUiLib/BootMaintenance.c  |  5 ++-
 .../BootMaintenanceManagerUiLib/BootOption.c   | 42 --
 .../BootMaintenanceManagerUiLib/UpdatePage.c   | 14 
 3 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
index b35e938..393091f 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
@@ -377,19 +377,22 @@ ExtractFileNameFromDevicePath (
   ASSERT(DevicePath != NULL);
 
   String = UiDevicePathToStr(DevicePath);
   MatchString = String;
   LastMatch   = String;
+  FileName= NULL;
 
   while(MatchString != NULL){
 LastMatch   = MatchString + 1;
 MatchString = StrStr(LastMatch,L"\\");
   }
 
   Length = StrLen(LastMatch);
   FileName = AllocateCopyPool ((Length + 1) * sizeof(CHAR16), LastMatch);
-  *(FileName + Length) = 0;
+  if (FileName != NULL) {
+*(FileName + Length) = 0;
+  }
 
   FreePool(String);
 
   return FileName;
 }
diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
index c660c73..890728a 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
@@ -863,33 +863,37 @@ BootFromFile (
   )
 {
   EFI_BOOT_MANAGER_LOAD_OPTION BootOption;
   CHAR16   *FileName;
 
+  FileName = NULL;
+
   FileName = ExtractFileNameFromDevicePath(FilePath);
-  EfiBootManagerInitializeLoadOption (
-&BootOption,
-0,
-LoadOptionTypeBoot,
-LOAD_OPTION_ACTIVE,
-FileName,
-FilePath,
-NULL,
-0
-);
-  //
-  // Since current no boot from removable media directly is allowed */
-  //
-  gST->ConOut->ClearScreen (gST->ConOut);
+  if (FileName != NULL) {
+EfiBootManagerInitializeLoadOption (
+  &BootOption,
+  0,
+  LoadOptionTypeBoot,
+  LOAD_OPTION_ACTIVE,
+  FileName,
+  FilePath,
+  NULL,
+  0
+  );
+//
+// Since current no boot from removable media directly is allowed */
+//
+gST->ConOut->ClearScreen (gST->ConOut);
 
-  BmmSetConsoleMode (FALSE);
-  EfiBootManagerBoot (&BootOption);
-  BmmSetConsoleMode (TRUE);
+BmmSetConsoleMode (FALSE);
+EfiBootManagerBoot (&BootOption);
+BmmSetConsoleMode (TRUE);
 
-  FreePool(FileName);
+FreePool(FileName);
 
-  EfiBootManagerFreeLoadOption (&BootOption);
+EfiBootManagerFreeLoadOption (&BootOption);
+  }
 
   return FALSE;
 }
 
 /**
diff --git a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c 
b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
index 13a29db..9e79826 100644
--- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
+++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
@@ -1,9 +1,9 @@
 /** @file
 Dynamically update the pages.
 
-Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
 http://opensource.org/licenses/bsd-license.php
 
@@ -1018,21 +1018,23 @@ UpdateOptionPage(
   )
 {
   CHAR16*String;
   EFI_STRING_ID StringToken;
 
+  String = NULL;
+
   if (DevicePath != NULL){
 String = ExtractFileNameFromDevicePath(DevicePath);
-StringToken = HiiSetString (CallbackData->BmmHiiHandle, 0, String, NULL);
-FreePool(String);
-  } else {
+  }
+  if (String == NULL) {
 String = HiiGetString (CallbackData->BmmHiiHandle, STRING_TOKEN 
(STR_NULL_STRING), NULL);
 ASSERT (String != NULL);
-StringToken =  HiiSetString (CallbackData->BmmHiiHandle, 0, String, NULL);
-FreePool (String);
   }
 
+  StringToken = HiiSetString (CallbackData->BmmHiiHandle, 0, String, NULL);
+  FreePool (String);
+
   if(FormId == FORM_BOOT_ADD_ID){
 if (!CallbackData->BmmFakeNvData.BootOptionChanged) {
   ZeroMem (CallbackData->BmmFakeNvData.BootOptionalData, sizeof 
(CallbackData->BmmFakeNvData.BootOptionalData));
   ZeroMem (CallbackData->BmmFakeNvData.BootDescriptionData, sizeof 
(CallbackData->BmmFakeNvData.BootDescriptionData));
 }
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.0

Re: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler

2016-07-05 Thread Wu, Jiaxin 
Reviewed-By: Wu Jiaxin 

Best Regards!
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hao Wu
> Sent: Tuesday, July 5, 2016 12:59 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ye, Ting ; Fu,
> Siyuan ; Wu, Jiaxin 
> Subject: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for
> lastest VS2015 compiler
> 
> The UefiPxeBcDxe module encounters a build error for IA32 arch using the
> latest version of VS2015:
> 
> UefiPxe4BcDxe.lib(PxeBcDhcp.obj) : error LNK2001: unresolved external
> symbol __allmul
> 
> The cause is line 1659 in file
> MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c. The third
> parameter for gBS->SetTimer() function is of type UINT64, so the
> multiplication should use the MultU64x32() function.
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> index 3849613..eac955c 100644
> --- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> +++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> @@ -1656,7 +1656,7 @@ PxeBcSelectBootPrompt (
>Status = gBS->SetTimer (
>TimeoutEvent,
>TimerRelative,
> -  Timeout * TICKS_PER_SECOND
> +  MultU64x32 (Timeout, TICKS_PER_SECOND)
>);
> 
>if (EFI_ERROR (Status)) {
> --
> 1.9.5.msysgit.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] [PATCH] Change ShellPkg&ShellBinPkg maintainer

2016-07-05 Thread Ruiyu Ni 
Since Shumin has left Intel to pursue a better job, I will temporary
be on his position to maintain ShellPkg and ShellBinPkg with Jaben.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Carsey Jaben 
---
 Maintainers.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 03979a1..d0d5f5c 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -189,14 +189,14 @@ M: Chao Zhang 
 ShellBinPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
 M: Jaben Carsey   (Ia32/X64)
-M: Shumin Qiu   (Ia32/X64)
+M: Ruiyu Ni   (Ia32/X64)
 M: Leif Lindholm(ARM/AArch64)
 M: Ard Biesheuvel  (ARM/AArch64)
 
 ShellPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
 M: Jaben Carsey 
-M: Shumin Qiu 
+M: Ruiyu Ni 
 
 SourceLevelDebugPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
-- 
2.8.3.windows.1

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