date:20160617

Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and Dhcpv6 configuration.

2016-06-17 Thread Zhang, Lubo

Hi Sriram

 I intend to add more arch for PXE boot ones according to your comments, 
but I find in Pxe driver, the macro EFI_PXE_CLIENT_SYSTEM_ARCHITECTURE is 
already defined in PxeBaseCode.h under mdepkg\include\protocol, so I think it 
is on need to redefine these arch,  how do you think.


thanks 
lubo

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Subramanian, Sriram (EG Servers Platform SW)
Sent: Friday, June 17, 2016 11:57 AM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin 
; Gao, Liming 
Subject: Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and 
Dhcpv6 configuration.

Hi Lubo,

For these:
+/// Processor Architecture Types
+/// These identifiers are defined by IETF:
+/// 
+http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml
+///
+#define DHCP6_ARCH_IA320x000F/// x86 uefi boot from http
+#define DHCP6_ARCH_X64 0x0010/// x64 uefi boot from http
+#define DHCP6_ARCH_ARM 0x0012/// Arm uefi 32 boot from http
+#define DHCP6_ARCH_AARCH64 0x0013/// Arm uefi 64 boot from http
+#define DHCP6_ARCH_EBC 0x0011/// EBC boot from http
+

These are not DHCP6 specific. These are client arch types used for both DHCP4 
and 6, and as such must not have the DHCP6_ prefix.

Also, I think we must define the other arch types: especially for the PXE boot 
ones (0x, 0x0002, 0x0006, 0x0007, 0x0009, etc.)

Thanks,
Sriram.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang 
Lubo
Sent: Friday, June 17, 2016 8:39 AM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Fu Siyuan ; Wu Jiaxin 
; Liming Gao 
Subject: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and Dhcpv6 
configuration.

Add a new head file Dhcp.h in Mde/Include/IndustryStandard, normalize the 
universal option numbers and other network number tags.

Cc: Liming Gao 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 MdePkg/Include/IndustryStandard/Dhcp.h | 273 +
 1 file changed, 273 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/Dhcp.h

diff --git a/MdePkg/Include/IndustryStandard/Dhcp.h 
b/MdePkg/Include/IndustryStandard/Dhcp.h
new file mode 100644
index 000..a0d3c9f
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Dhcp.h
@@ -0,0 +1,273 @@
+/** @file
+  This file contains the DHCPv4 and DHCPv6 option definitions and other 
configuration.
+  They are used to carry additional information and parameters in DHCP 
messages.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.  This 
+ program and the accompanying materials  are licensed and made 
+ available under the terms and conditions of the BSD License  which 
+ accompanies this distribution.  The full text of the license may be 
+ found at  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef _DHCP_H_
+#define _DHCP_H_
+
+///
+/// Dynamic Host Configuration Protocol for IPv4 (DHCPv4) /// /// 
+Dhcpv4 Options, definitions from RFC 2132 ///
+#define DHCP4_TAG_PAD0/// Pad Option
+#define DHCP4_TAG_EOP255  /// End Option
+#define DHCP4_TAG_NETMASK1/// Subnet Mask
+#define DHCP4_TAG_TIME_OFFSET2/// Time Offset from UTC
+#define DHCP4_TAG_ROUTER 3/// Router option,
+#define DHCP4_TAG_TIME_SERVER4/// Time Server
+#define DHCP4_TAG_NAME_SERVER5/// Name Server
+#define DHCP4_TAG_DNS_SERVER 6/// Domain Name Server
+#define DHCP4_TAG_LOG_SERVER 7/// Log Server
+#define DHCP4_TAG_COOKIE_SERVER  8/// Cookie Server
+#define DHCP4_TAG_LPR_SERVER 9/// LPR Print Server
+#define DHCP4_TAG_IMPRESS_SERVER 10   /// Impress Server
+#define DHCP4_TAG_RL_SERVER  11   /// Resource Location Server
+#define DHCP4_TAG_HOSTNAME   12   /// Host Name
+#define DHCP4_TAG_BOOTFILE_LEN   13   /// Boot File Size
+#define DHCP4_TAG_DUMP   14   /// Merit Dump File
+#define DHCP4_TAG_DOMAINNAME 15   /// Domain Name
+#define DHCP4_TAG_SWAP_SERVER16   /// Swap Server
+#define DHCP4_TAG_ROOTPATH   17   /// Root path
+#define DHCP4_TAG_EXTEND_PATH18   /// Extensions Path
+#define DHCP4_TAG_IPFORWARD  19   /// IP Forwarding Enable/Disable
+#define DHCP4_TAG_NONLOCAL_SRR   20   /// on-Local Source Routing 
Enable/Disable
+#define DHCP4_TAG_POLICY_SRR 21   /// Policy Filter
+#define DHCP4_TAG_EMTU   22   /// Maximum Datagram Reassembly Size
+#define DHCP4_TAG_TTL23   /// Default IP Time-to-live
+#define DHCP4_TAG_PATHMTU_AGE24

Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and Dhcpv6 configuration.

2016-06-17 Thread Subramanian, Sriram (EG Servers Platform SW)

OK, in that case how about move those macros from 
MdePkg/Include/Protocol/PxeBaseCode.h to this MdePkg/Include/IndustryStandard/? 
Because these are defined in RFCs and assignments controlled by IANA, so more 
wider scope and not specific to the UEFI protocols.

What do you think Ting/Siyuan?

Thanks,
Sriram.

-Original Message-
From: Zhang, Lubo [mailto:lubo.zh...@intel.com] 
Sent: Friday, June 17, 2016 12:43 PM
To: Subramanian, Sriram (EG Servers Platform SW) ; 
edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin 
; Gao, Liming 
Subject: RE: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and 
Dhcpv6 configuration.

Hi Sriram

 I intend to add more arch for PXE boot ones according to your comments, 
but I find in Pxe driver, the macro EFI_PXE_CLIENT_SYSTEM_ARCHITECTURE is 
already defined in PxeBaseCode.h under mdepkg\include\protocol, so I think it 
is on need to redefine these arch,  how do you think.


thanks 
lubo

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Subramanian, Sriram (EG Servers Platform SW)
Sent: Friday, June 17, 2016 11:57 AM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin 
; Gao, Liming 
Subject: Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and 
Dhcpv6 configuration.

Hi Lubo,

For these:
+/// Processor Architecture Types
+/// These identifiers are defined by IETF:
+/// 
+http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml
+///
+#define DHCP6_ARCH_IA320x000F/// x86 uefi boot from http
+#define DHCP6_ARCH_X64 0x0010/// x64 uefi boot from http
+#define DHCP6_ARCH_ARM 0x0012/// Arm uefi 32 boot from http
+#define DHCP6_ARCH_AARCH64 0x0013/// Arm uefi 64 boot from http
+#define DHCP6_ARCH_EBC 0x0011/// EBC boot from http
+

These are not DHCP6 specific. These are client arch types used for both DHCP4 
and 6, and as such must not have the DHCP6_ prefix.

Also, I think we must define the other arch types: especially for the PXE boot 
ones (0x, 0x0002, 0x0006, 0x0007, 0x0009, etc.)

Thanks,
Sriram.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang 
Lubo
Sent: Friday, June 17, 2016 8:39 AM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Fu Siyuan ; Wu Jiaxin 
; Liming Gao 
Subject: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and Dhcpv6 
configuration.

Add a new head file Dhcp.h in Mde/Include/IndustryStandard, normalize the 
universal option numbers and other network number tags.

Cc: Liming Gao 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 MdePkg/Include/IndustryStandard/Dhcp.h | 273 +
 1 file changed, 273 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/Dhcp.h

diff --git a/MdePkg/Include/IndustryStandard/Dhcp.h 
b/MdePkg/Include/IndustryStandard/Dhcp.h
new file mode 100644
index 000..a0d3c9f
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Dhcp.h
@@ -0,0 +1,273 @@
+/** @file
+  This file contains the DHCPv4 and DHCPv6 option definitions and other 
configuration.
+  They are used to carry additional information and parameters in DHCP 
messages.
+
+  Copyright (c) 2016, Intel Corporation. All rights reserved.  This 
+ program and the accompanying materials  are licensed and made 
+ available under the terms and conditions of the BSD License  which 
+ accompanies this distribution.  The full text of the license may be 
+ found at  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef _DHCP_H_
+#define _DHCP_H_
+
+///
+/// Dynamic Host Configuration Protocol for IPv4 (DHCPv4) /// /// 
+Dhcpv4 Options, definitions from RFC 2132 ///
+#define DHCP4_TAG_PAD0/// Pad Option
+#define DHCP4_TAG_EOP255  /// End Option
+#define DHCP4_TAG_NETMASK1/// Subnet Mask
+#define DHCP4_TAG_TIME_OFFSET2/// Time Offset from UTC
+#define DHCP4_TAG_ROUTER 3/// Router option,
+#define DHCP4_TAG_TIME_SERVER4/// Time Server
+#define DHCP4_TAG_NAME_SERVER5/// Name Server
+#define DHCP4_TAG_DNS_SERVER 6/// Domain Name Server
+#define DHCP4_TAG_LOG_SERVER 7/// Log Server
+#define DHCP4_TAG_COOKIE_SERVER  8/// Cookie Server
+#define DHCP4_TAG_LPR_SERVER 9/// LPR Print Server
+#define DHCP4_TAG_IMPRESS_SERVER 10   /// Impress Server
+#define DHCP4_TAG_RL_SERVER  11   /// Resource Location Server
+#define DHCP4_TAG_HOSTNAME   12   /// Host Name
+#define DHCP4_TAG_BOOTFILE_LEN   13   /// Boot File Size
+#define DHCP4_TAG_DUMP   14   /// Merit Dump Fi

Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and Dhcpv6 configuration.

2016-06-17 Thread Fu, Siyuan

Sriram,

I vote for adding them to the IndustryStandard header, but I think we'd better 
to also keep the existing macros in PxeBaseCode.h. So we won't need to update 
all the C files to include the new header file.

Best Regards
Siyuan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Subramanian, Sriram (EG Servers Platform SW)
> Sent: Friday, June 17, 2016 3:29 PM
> To: Zhang, Lubo ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin ; Gao, Liming 
> Subject: Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> OK, in that case how about move those macros from
> MdePkg/Include/Protocol/PxeBaseCode.h to this
> MdePkg/Include/IndustryStandard/? Because these are defined in RFCs and
> assignments controlled by IANA, so more wider scope and not specific to the
> UEFI protocols.
> 
> What do you think Ting/Siyuan?
> 
> Thanks,
> Sriram.
> 
> -Original Message-
> From: Zhang, Lubo [mailto:lubo.zh...@intel.com]
> Sent: Friday, June 17, 2016 12:43 PM
> To: Subramanian, Sriram (EG Servers Platform SW) ;
> edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin ; Gao, Liming 
> Subject: RE: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> Hi Sriram
> 
>  I intend to add more arch for PXE boot ones according to your comments,
> but I find in Pxe driver, the macro EFI_PXE_CLIENT_SYSTEM_ARCHITECTURE is
> already defined in PxeBaseCode.h under mdepkg\include\protocol, so I think
> it is on need to redefine these arch,  how do you think.
> 
> 
> thanks
> lubo
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Subramanian, Sriram (EG Servers Platform SW)
> Sent: Friday, June 17, 2016 11:57 AM
> To: Zhang, Lubo ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin ; Gao, Liming 
> Subject: Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> Hi Lubo,
> 
> For these:
> +/// Processor Architecture Types
> +/// These identifiers are defined by IETF:
> +///
> +http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-
> parameters.xml
> +///
> +#define DHCP6_ARCH_IA320x000F/// x86 uefi boot from http
> +#define DHCP6_ARCH_X64 0x0010/// x64 uefi boot from http
> +#define DHCP6_ARCH_ARM 0x0012/// Arm uefi 32 boot from http
> +#define DHCP6_ARCH_AARCH64 0x0013/// Arm uefi 64 boot from http
> +#define DHCP6_ARCH_EBC 0x0011/// EBC boot from http
> +
> 
> These are not DHCP6 specific. These are client arch types used for both
> DHCP4 and 6, and as such must not have the DHCP6_ prefix.
> 
> Also, I think we must define the other arch types: especially for the PXE boot
> ones (0x, 0x0002, 0x0006, 0x0007, 0x0009, etc.)
> 
> Thanks,
> Sriram.
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Zhang Lubo
> Sent: Friday, June 17, 2016 8:39 AM
> To: edk2-devel@lists.01.org
> Cc: Ye Ting ; Fu Siyuan ; Wu Jiaxin
> ; Liming Gao 
> Subject: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> Add a new head file Dhcp.h in Mde/Include/IndustryStandard, normalize the
> universal option numbers and other network number tags.
> 
> Cc: Liming Gao 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> ---
>  MdePkg/Include/IndustryStandard/Dhcp.h | 273
> +
>  1 file changed, 273 insertions(+)
>  create mode 100644 MdePkg/Include/IndustryStandard/Dhcp.h
> 
> diff --git a/MdePkg/Include/IndustryStandard/Dhcp.h
> b/MdePkg/Include/IndustryStandard/Dhcp.h
> new file mode 100644
> index 000..a0d3c9f
> --- /dev/null
> +++ b/MdePkg/Include/IndustryStandard/Dhcp.h
> @@ -0,0 +1,273 @@
> +/** @file
> +  This file contains the DHCPv4 and DHCPv6 option definitions and other
> configuration.
> +  They are used to carry additional information and parameters in DHCP
> messages.
> +
> +  Copyright (c) 2016, Intel Corporation. All rights reserved.  This
> + program and the accompanying materials  are licensed and made
> + available under the terms and conditions of the BSD License  which
> + accompanies this distribution.  The full text of the license may be
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +**/
> +
> +#ifndef _DHCP_H_
> +#define _DHCP_H_
> +
> +///
> +/// Dynamic Host Configuration Protocol for IPv4 (DHCPv4) /// ///
> +Dhcpv4 Options, definitions from RFC 2132 ///
> +#define DHCP4_TAG_PAD0/// Pad Option
> +#define DHCP4_TAG_EOP255  /// End Option
> +#define DHCP4

Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and Dhcpv6 configuration.

2016-06-17 Thread Subramanian, Sriram (EG Servers Platform SW)

Sounds good!

-Original Message-
From: Fu, Siyuan [mailto:siyuan...@intel.com] 
Sent: Friday, June 17, 2016 1:09 PM
To: Subramanian, Sriram (EG Servers Platform SW) ; Zhang, 
Lubo ; edk2-devel@lists.01.org
Cc: Ye, Ting ; Wu, Jiaxin ; Gao, Liming 

Subject: RE: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and 
Dhcpv6 configuration.

Sriram,

I vote for adding them to the IndustryStandard header, but I think we'd better 
to also keep the existing macros in PxeBaseCode.h. So we won't need to update 
all the C files to include the new header file.

Best Regards
Siyuan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Subramanian, Sriram (EG Servers Platform SW)
> Sent: Friday, June 17, 2016 3:29 PM
> To: Zhang, Lubo ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin ; Gao, Liming 
> Subject: Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> OK, in that case how about move those macros from
> MdePkg/Include/Protocol/PxeBaseCode.h to this
> MdePkg/Include/IndustryStandard/? Because these are defined in RFCs and
> assignments controlled by IANA, so more wider scope and not specific to the
> UEFI protocols.
> 
> What do you think Ting/Siyuan?
> 
> Thanks,
> Sriram.
> 
> -Original Message-
> From: Zhang, Lubo [mailto:lubo.zh...@intel.com]
> Sent: Friday, June 17, 2016 12:43 PM
> To: Subramanian, Sriram (EG Servers Platform SW) ;
> edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin ; Gao, Liming 
> Subject: RE: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> Hi Sriram
> 
>  I intend to add more arch for PXE boot ones according to your comments,
> but I find in Pxe driver, the macro EFI_PXE_CLIENT_SYSTEM_ARCHITECTURE is
> already defined in PxeBaseCode.h under mdepkg\include\protocol, so I think
> it is on need to redefine these arch,  how do you think.
> 
> 
> thanks
> lubo
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Subramanian, Sriram (EG Servers Platform SW)
> Sent: Friday, June 17, 2016 11:57 AM
> To: Zhang, Lubo ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin ; Gao, Liming 
> Subject: Re: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> Hi Lubo,
> 
> For these:
> +/// Processor Architecture Types
> +/// These identifiers are defined by IETF:
> +///
> +http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-
> parameters.xml
> +///
> +#define DHCP6_ARCH_IA320x000F/// x86 uefi boot from http
> +#define DHCP6_ARCH_X64 0x0010/// x64 uefi boot from http
> +#define DHCP6_ARCH_ARM 0x0012/// Arm uefi 32 boot from http
> +#define DHCP6_ARCH_AARCH64 0x0013/// Arm uefi 64 boot from http
> +#define DHCP6_ARCH_EBC 0x0011/// EBC boot from http
> +
> 
> These are not DHCP6 specific. These are client arch types used for both
> DHCP4 and 6, and as such must not have the DHCP6_ prefix.
> 
> Also, I think we must define the other arch types: especially for the PXE boot
> ones (0x, 0x0002, 0x0006, 0x0007, 0x0009, etc.)
> 
> Thanks,
> Sriram.
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Zhang Lubo
> Sent: Friday, June 17, 2016 8:39 AM
> To: edk2-devel@lists.01.org
> Cc: Ye Ting ; Fu Siyuan ; Wu Jiaxin
> ; Liming Gao 
> Subject: [edk2] [patch 3/3] MdePkg: Refine codes related to Dhcpv4 and
> Dhcpv6 configuration.
> 
> Add a new head file Dhcp.h in Mde/Include/IndustryStandard, normalize the
> universal option numbers and other network number tags.
> 
> Cc: Liming Gao 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo 
> ---
>  MdePkg/Include/IndustryStandard/Dhcp.h | 273
> +
>  1 file changed, 273 insertions(+)
>  create mode 100644 MdePkg/Include/IndustryStandard/Dhcp.h
> 
> diff --git a/MdePkg/Include/IndustryStandard/Dhcp.h
> b/MdePkg/Include/IndustryStandard/Dhcp.h
> new file mode 100644
> index 000..a0d3c9f
> --- /dev/null
> +++ b/MdePkg/Include/IndustryStandard/Dhcp.h
> @@ -0,0 +1,273 @@
> +/** @file
> +  This file contains the DHCPv4 and DHCPv6 option definitions and other
> configuration.
> +  They are used to carry additional information and parameters in DHCP
> messages.
> +
> +  Copyright (c) 2016, Intel Corporation. All rights reserved.  This
> + program and the accompanying materials  are licensed and made
> + available under the terms and conditions of the BSD License  which
> + accompanies this distribution.  The full text of the license may be
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF

[edk2] [PATCH] ShellPkg/UefiHandleParsing: Show handle's loaded image device path

2016-06-17 Thread Ruiyu Ni

The patch fixed a bug in UefiHandleParsingLib to show handle's loaded
image device path.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jaben Carsey 
Cc: Shumin Qiu 
---
 .../UefiHandleParsingLib/UefiHandleParsingLib.c| 83 ++
 1 file changed, 68 insertions(+), 15 deletions(-)

diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
index 9789471..b82f925 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
@@ -731,6 +731,42 @@ DriverEfiVersionProtocolDumpInformation(
   UnicodeSPrint(RetVal, VersionStringSize, L"0x%08x", 
DriverEfiVersion->FirmwareVersion);
   return (RetVal);
 }
+/**
+  Function to convert device path to string.
+
+  This will allocate the return buffer from boot services pool.
+
+  @param[in] DevPathPointer to device path instance.
+  @param[in] VerboseTRUE for additional information, FALSE otherwise.
+  @param[in] Length Maximum allowed text length of the device path.
+
+  @retval A pointer to a string containing the information.
+**/
+CHAR16*
+ConvertDevicePathToShortText(
+  IN CONST EFI_DEVICE_PATH_PROTOCOL *DevPath,
+  IN CONST BOOLEAN  Verbose,
+  IN CONST UINTNLength
+  )
+{
+  CHAR16*Temp;
+  CHAR16*Temp2;
+  UINTN Size;
+
+  //
+  // I cannot decide whether to allow shortcuts here (the second BOOLEAN on 
the next line)
+  //
+  Temp = ConvertDevicePathToText(DevPath, TRUE, TRUE);
+  if (!Verbose && Temp != NULL && StrLen(Temp) > Length) {
+Temp2 = NULL;
+Size  = 0;
+Temp2 = StrnCatGrow(&Temp2, &Size, L"..", 0);
+Temp2 = StrnCatGrow(&Temp2, &Size, Temp+(StrLen(Temp) - (Length - 2)), 0);
+FreePool(Temp);
+Temp = Temp2;
+  }
+  return (Temp);
+}
 
 /**
   Function to dump information about DevicePath protocol.
@@ -740,7 +776,7 @@ DriverEfiVersionProtocolDumpInformation(
   @param[in] TheHandle  The handle that has the protocol installed.
   @param[in] VerboseTRUE for additional information, FALSE otherwise.
 
-  @retval A poitner to a string containing the information.
+  @retval A pointer to a string containing the information.
 **/
 CHAR16*
 EFIAPI
@@ -751,26 +787,43 @@ DevicePathProtocolDumpInformation(
 {
   EFI_DEVICE_PATH_PROTOCOL  *DevPath;
   CHAR16*Temp;
-  CHAR16*Temp2;
   EFI_STATUSStatus;
-  UINTN Size;
   Temp = NULL;
 
   Status = gBS->OpenProtocol(TheHandle, &gEfiDevicePathProtocolGuid, 
(VOID**)&DevPath, gImageHandle, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
   if (!EFI_ERROR(Status)) {
-//
-// I cannot decide whether to allow shortcuts here (the second BOOLEAN on 
the next line)
-//
-Temp = ConvertDevicePathToText(DevPath, TRUE, TRUE);
+Temp = ConvertDevicePathToShortText (DevPath, Verbose, 30);
 gBS->CloseProtocol(TheHandle, &gEfiDevicePathProtocolGuid, gImageHandle, 
NULL);
   }
-  if (!Verbose && Temp != NULL && StrLen(Temp) > 30) {
-Temp2 = NULL;
-Size  = 0;
-Temp2 = StrnCatGrow(&Temp2, &Size, L"..", 0);
-Temp2 = StrnCatGrow(&Temp2, &Size, Temp+(StrLen(Temp) - 28), 0);
-FreePool(Temp);
-Temp = Temp2;
+  return (Temp);
+}
+
+/**
+  Function to dump information about LoadedImageDevicePath protocol.
+
+  This will allocate the return buffer from boot services pool.
+
+  @param[in] TheHandle  The handle that has the protocol installed.
+  @param[in] VerboseTRUE for additional information, FALSE otherwise.
+
+  @retval A pointer to a string containing the information.
+**/
+CHAR16*
+EFIAPI
+LoadedImageDevicePathProtocolDumpInformation(
+  IN CONST EFI_HANDLE TheHandle,
+  IN CONST BOOLEANVerbose
+  )
+{
+  EFI_DEVICE_PATH_PROTOCOL  *DevPath;
+  CHAR16*Temp;
+  EFI_STATUSStatus;
+  Temp = NULL;
+
+  Status = gBS->OpenProtocol(TheHandle, 
&gEfiLoadedImageDevicePathProtocolGuid, (VOID**)&DevPath, gImageHandle, NULL, 
EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+  if (!EFI_ERROR(Status)) {
+Temp = ConvertDevicePathToShortText (DevPath, Verbose, 30);
+gBS->CloseProtocol(TheHandle, &gEfiDevicePathProtocolGuid, gImageHandle, 
NULL);
   }
   return (Temp);
 }
@@ -1454,7 +1507,7 @@ STATIC CONST GUID_INFO_BLOCK mGuidStringListNT[] = {
 STATIC CONST GUID_INFO_BLOCK mGuidStringList[] = {
   {STRING_TOKEN(STR_LOADED_IMAGE),  &gEfiLoadedImageProtocolGuid,  
   LoadedImageProtocolDumpInformation},
   {STRING_TOKEN(STR_DEVICE_PATH),   &gEfiDevicePathProtocolGuid,   
   DevicePathProtocolDumpInformation},
-  {STRING_TOKEN(STR_IMAGE_PATH),
&gEfiLoadedImageDevicePathProtocolGuid,

[edk2] [patch] NetworkPkg: Replace ASSERT with error handling in Http boot and IScsi

2016-06-17 Thread Zhang Lubo

This patch is used to replace ASSERT with error handling in Http boot
Driver and IScsi driver.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/HttpBootDxe/HttpBootConfig.c |  5 +++--
 NetworkPkg/HttpBootDxe/HttpBootDhcp6.c  |  5 -
 NetworkPkg/IScsiDxe/IScsiConfig.c   |  6 --
 NetworkPkg/IScsiDxe/IScsiDriver.c   |  1 +
 NetworkPkg/IScsiDxe/IScsiMisc.c |  5 -
 NetworkPkg/IScsiDxe/IScsiProto.c| 17 +
 6 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c 
b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
index 04c2f3e..3708995 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
@@ -271,11 +271,13 @@ HttpBootFormExtractConfig (
 // followed by "&OFFSET=0&WIDTH=" followed by a 
Null-terminator
 //
 ConfigRequestHdr = HiiConstructConfigHdr (&gHttpBootConfigGuid, 
mHttpBootConfigStorageName, CallbackInfo->ChildHandle);
 Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
 ConfigRequest = AllocateZeroPool (Size);
-ASSERT (ConfigRequest != NULL);
+if (ConfigRequest == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
 AllocatedRequest = TRUE;
 UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX", 
ConfigRequestHdr, (UINT64)BufferSize);
 FreePool (ConfigRequestHdr);
   }
 
@@ -462,11 +464,10 @@ HttpBootFormCallback (
   case KEY_INITIATOR_URI:
 //
 // Get user input URI string
 //
 Uri = HiiGetString (CallbackInfo->RegisteredHandle, Value->string, NULL);
-ASSERT (Uri != NULL);
 if (Uri == NULL) {
   return EFI_UNSUPPORTED;
 }
 
 //
diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c 
b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
index 0157095..9ea421d 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
@@ -399,10 +399,11 @@ HttpBootCacheDhcp6Offer (
 
   @retval EFI_SUCCESS   Told the EFI DHCPv6 Protocol driver to 
continue the DHCP process.
   @retval EFI_NOT_READY Only used in the Dhcp6Selecting state. The EFI 
DHCPv6 Protocol
 driver will continue to wait for more packets.
   @retval EFI_ABORTED   Told the EFI DHCPv6 Protocol driver to abort 
the current process.
+  @retval EFI_OUT_OF_RESOURCES  There are not enough resources.
 
 **/
 EFI_STATUS
 EFIAPI
 HttpBootDhcp6CallBack (
@@ -449,11 +450,13 @@ HttpBootDhcp6CallBack (
Status = EFI_ABORTED;
  } else {
ASSERT (NewPacket != NULL);
SelectAd   = &Private->OfferBuffer[Private->SelectIndex - 
1].Dhcp6.Packet.Offer;
*NewPacket = AllocateZeroPool (SelectAd->Size);
-   ASSERT (*NewPacket != NULL);
+   if (*NewPacket == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+   }
CopyMem (*NewPacket, SelectAd, SelectAd->Size);
  }
  break;
  
default:
diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c 
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index 69a4003..bd24de2 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -1,9 +1,9 @@
 /** @file
   Helper functions for configuring or getting the parameters relating to iSCSI.
 
-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
 
@@ -1957,11 +1957,13 @@ IScsiFormExtractConfig (
 // followed by "&OFFSET=0&WIDTH=" followed by a 
Null-terminator
 //
 ConfigRequestHdr = HiiConstructConfigHdr (&gIScsiConfigGuid, 
mVendorStorageName, Private->DriverHandle);
 Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
 ConfigRequest = AllocateZeroPool (Size);
-ASSERT (ConfigRequest != NULL);
+if (ConfigRequest == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
 AllocatedRequest = TRUE;
 UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX", 
ConfigRequestHdr, (UINT64)BufferSize);
 FreePool (ConfigRequestHdr);
   }
 
diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.c 
b/NetworkPkg/IScsiDxe/IScsiDriver.c
index 5a121ce..285f151 100644
--- a/NetworkPkg/IScsiDxe/IScsiDriver.c
+++ b/NetworkPkg/IScsiDxe/IScsiDriver.c
@@ -321,10 +321,11 @@ IScsiSupported (
   @retval EFI_SUCCESThis driver was started.
   @retval EFI_ALREADY_STARTED   This driver is already running on this device.
   @retval EFI_INVALID_PARAMETER Any input parameter is invalid.
   @retval EFI_NOT_FOUND There is no sufficient information to establish
 the iScsi session.
+  @retval EFI_OUT

Re: [edk2] [Patch] Vlv2TbltDevicePkg: Fixed build error issue.

2016-06-17 Thread Wei, David

Reviewed-by: David Wei  


Thanks,
David  Wei   
  
Intel SSG BIOS Team

-Original Message-
From: Lu, ShifeiX A 
Sent: Tuesday, June 14, 2016 4:27 PM
To: edk2-devel@lists.01.org
Cc: Wei; Wei, David 
Subject: [Patch] Vlv2TbltDevicePkg: Fixed build error issue.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 Vlv2TbltDevicePkg/PlatformDxe/PlatformDxe.inf | 4 ++--
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc   | 2 +-
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 2 +-
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc  | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformDxe/PlatformDxe.inf 
b/Vlv2TbltDevicePkg/PlatformDxe/PlatformDxe.inf
index f1f2635..c19edac 100644
--- a/Vlv2TbltDevicePkg/PlatformDxe/PlatformDxe.inf
+++ b/Vlv2TbltDevicePkg/PlatformDxe/PlatformDxe.inf
@@ -1,8 +1,8 @@
 ## @file
 #
-#  Copyright (c)  1999  - 2015, Intel Corporation. All rights reserved
+#  Copyright (c)  1999  - 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 that accompanies this 
distribution.
 # The full text of the license may be found at
 # http://opensource.org/licenses/bsd-license.php.
@@ -134,11 +134,11 @@
   gPlatformModuleTokenSpaceGuid.PcdPBTNDisableInterval
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
   gPlatformModuleTokenSpaceGuid.PcdFlashAreaBaseAddress
   gPlatformModuleTokenSpaceGuid.PcdFlashMicroCodeAddress
   gPlatformModuleTokenSpaceGuid.PcdFlashMicroCodeSize
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdFastPS2Detection
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFastPS2Detection
   gPlatformModuleTokenSpaceGuid.PcdFlashFvMainBase
   gPlatformModuleTokenSpaceGuid.PcdFlashFvRecoveryBase
   gPlatformModuleTokenSpaceGuid.PcdFlashFvRecoverySize
   gFspWrapperTokenSpaceGuid.PcdFlashFvFspBase
 
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index ace2d73..466de88 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -696,11 +696,11 @@
   
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x$(PLATFORM_PCIEXPRESS_BASE)
   
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion|FALSE
 
   ## This PCD specifies whether to use the optimized timing for best PS2 
detection performance.
   #  Note this PCD could be set to TRUE for best boot performance and set to 
FALSE for best device compatibility.
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdFastPS2Detection|TRUE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFastPS2Detection|TRUE
 
   
###
   #
   # Begin of MRC parameters
   #
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 9af9088..b7e1446 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -696,11 +696,11 @@
   
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x$(PLATFORM_PCIEXPRESS_BASE)
   
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion|FALSE
 
   ## This PCD specifies whether to use the optimized timing for best PS2 
detection performance.
   #  Note this PCD could be set to TRUE for best boot performance and set to 
FALSE for best device compatibility.
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdFastPS2Detection|TRUE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFastPS2Detection|TRUE
 
   
###
   #
   # Begin of MRC parameters
   #
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index 152bf67..b4a35ee 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -696,11 +696,11 @@
   
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x$(PLATFORM_PCIEXPRESS_BASE)
   
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion|FALSE
 
   ## This PCD specifies whether to use the optimized timing for best PS2 
detection performance.
   #  Note this PCD could be set to TRUE for best boot performance and set to 
FALSE for best device compatibility.
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdFastPS2Detection|TRUE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFastPS2Detection|TRUE
 
   
###
   #
   # Begin of MRC parameters
   #
-- 
2.6.2.windows.1


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

Re: [edk2] [Patch] NetworkPkg: Remove ASSERT and use error handling in IpSecDxe

2016-06-17 Thread Ye, Ting

Reviewed-by: Ye Ting  

-Original Message-
From: Wu, Jiaxin 
Sent: Friday, June 17, 2016 1:20 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Zhang, Lubo 
; Yao, Jiewen 
Subject: [Patch] NetworkPkg: Remove ASSERT and use error handling in IpSecDxe

This patch is used to refine the code by removing ASSERT and
using error handling in IpSecDxe driver.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Cc: Yao Jiewen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/IpSecDxe/Ikev2/Info.c  |   6 +-
 NetworkPkg/IpSecDxe/Ikev2/Payload.c   | 203 +++---
 NetworkPkg/IpSecDxe/Ikev2/Sa.c|  76 ++---
 NetworkPkg/IpSecDxe/Ikev2/Utility.c   | 151 -
 NetworkPkg/IpSecDxe/Ikev2/Utility.h   |   7 +-
 NetworkPkg/IpSecDxe/IpSecConfigImpl.c |   5 +-
 NetworkPkg/IpSecDxe/IpSecCryptIo.c|   7 +-
 NetworkPkg/IpSecDxe/IpSecImpl.c   |  21 ++--
 8 files changed, 379 insertions(+), 97 deletions(-)

diff --git a/NetworkPkg/IpSecDxe/Ikev2/Info.c b/NetworkPkg/IpSecDxe/Ikev2/Info.c
index fe75d6c..23e47ce 100644
--- a/NetworkPkg/IpSecDxe/Ikev2/Info.c
+++ b/NetworkPkg/IpSecDxe/Ikev2/Info.c
@@ -1,10 +1,10 @@
 /** @file
   The Implementations for Information Exchange.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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.
@@ -45,11 +45,13 @@ Ikev2InfoGenerator (
   IKEV2_INFO_EXCHANGE_CONTEXT *InfoContext;
 
   InfoContext  = NULL;
   IkeSaSession = (IKEV2_SA_SESSION *) SaSession;
   IkePacket= IkePacketAlloc ();
-  ASSERT (IkePacket != NULL);
+  if (IkePacket == NULL) {
+return NULL;
+  }
 
   //
   // Fill IkePacket Header.
   //
   IkePacket->Header->ExchangeType= IKEV2_EXCHANGE_TYPE_INFO;
diff --git a/NetworkPkg/IpSecDxe/Ikev2/Payload.c 
b/NetworkPkg/IpSecDxe/Ikev2/Payload.c
index b92ae3a..d5fe1ab 100644
--- a/NetworkPkg/IpSecDxe/Ikev2/Payload.c
+++ b/NetworkPkg/IpSecDxe/Ikev2/Payload.c
@@ -1,10 +1,10 @@
 /** @file
   The implementation of Payloads Creation.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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.
@@ -50,11 +50,14 @@ Ikev2GenerateSaPayload (
   IKE_PAYLOAD   *SaPayload;
   IKEV2_SA_DATA *SaData;
   UINTN SaDataSize;
 
   SaPayload = IkePayloadAlloc ();
-  ASSERT (SaPayload != NULL);
+  if (SaPayload == NULL) {
+return NULL;
+  }
+  
   //
   // TODO: Get the Proposal Number and Transform Number from IPsec Config,
   // after the Ipsecconfig Application is support it.
   //
 
@@ -68,11 +71,14 @@ Ikev2GenerateSaPayload (
  sizeof (IKEV2_TRANSFORM_DATA) * SessionSaData->NumProposals * 
3;
 
   }
 
   SaData = AllocateZeroPool (SaDataSize);
-  ASSERT (SaData != NULL);
+  if (SaData == NULL) {
+IkePayloadFree (SaPayload);
+return NULL;
+  }
 
   CopyMem (SaData, SessionSaData, SaDataSize);
   SaData->SaHeader.Header.NextPayload = NextPayload;
   SaPayload->PayloadType  = IKEV2_PAYLOAD_TYPE_SA;
   SaPayload->PayloadBuf   = (UINT8 *) SaData;
@@ -116,18 +122,24 @@ Ikev2GenerateNoncePayload (
   //
   Size= sizeof (IKEV2_NONCE) + NonceSize;
   NonceBlock  = NonceBuf;
 
   Nonce   = AllocateZeroPool (Size);
-  ASSERT (Nonce != NULL);
+  if (Nonce == NULL) {
+return NULL;
+  }
+  
   CopyMem (Nonce + 1, NonceBlock, Size - sizeof (IKEV2_NONCE));
 
   Nonce->Header.NextPayload   = NextPayload;
   Nonce->Header.PayloadLength = (UINT16) Size;
   NoncePayload= IkePayloadAlloc ();
-
-  ASSERT (NoncePayload != NULL);
+  if (NoncePayload == NULL) {
+FreePool (Nonce);
+return NULL;
+  }
+  
   NoncePayload->PayloadType = IKEV2_PAYLOAD_TYPE_NONCE;
   NoncePayload->PayloadBuf  = (UINT8 *) Nonce;
   NoncePayload->PayloadSize = Size;
 
   return NoncePayload;
@@ -178,11 +190,13 @@ Ikev2GenerateKePayload (
 
   //
   // Allocate buffer for Key Exchange
   //
   Ke = AllocateZeroPool (KeSize);
-  ASSERT (Ke != NULL);
+  if (Ke == NULL) {
+return NULL;
+  }
 
   Ke->Header.NextPayload= NextPayload;
   Ke->Header.PayloadLength  = (UINT16) KeSize;
   Ke->DhGroup   = IkeSaSession->SessionCommon.PreferDhGroup;
 
@@ -190,11 +204,14 @@ Ikev2GenerateKePayload (

Re: [edk2] [Patch] NetworkPkg: Replace ASSERT with error handling in DnsDxe

2016-06-17 Thread Ye, Ting

Jiaxin,

Is it possible to use goto to handle the error cases instead of duplicating the 
logic?

Thanks,
Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Friday, June 17, 2016 2:46 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Zhang, Lubo ; Fu, 
Siyuan 
Subject: [edk2] [Patch] NetworkPkg: Replace ASSERT with error handling in DnsDxe

This patch is used to replace ASSERT with error handling in DnsDxe driver.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/DnsDxe/DnsProtocol.c | 34 ++
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/NetworkPkg/DnsDxe/DnsProtocol.c b/NetworkPkg/DnsDxe/DnsProtocol.c 
index e9101d6..1102fab 100644
--- a/NetworkPkg/DnsDxe/DnsProtocol.c
+++ b/NetworkPkg/DnsDxe/DnsProtocol.c
@@ -110,11 +110,17 @@ Dns4GetModeData (
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4ServerList) {
 Index++;
   }
   DnsModeData->DnsServerCount = (UINT32) Index;
   ServerList = AllocatePool (sizeof (EFI_IPv4_ADDRESS) * 
DnsModeData->DnsServerCount);
-  ASSERT (ServerList != NULL);
+  if (ServerList == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+Dns4CleanConfigure (&DnsModeData->DnsConfigData);
+gBS->RestoreTPL (OldTpl);
+return Status;
+  }
+  
   Index = 0;
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4ServerList) {
 ServerItem = NET_LIST_USER_STRUCT (Entry, DNS4_SERVER_IP, AllServerLink);
 CopyMem (ServerList + Index, &ServerItem->Dns4ServerIp, sizeof 
(EFI_IPv4_ADDRESS));
 Index++;
@@ -128,11 +134,18 @@ Dns4GetModeData (
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4CacheList) {
 Index++;
   }
   DnsModeData->DnsCacheCount = (UINT32) Index;
   CacheList = AllocatePool (sizeof (EFI_DNS4_CACHE_ENTRY) * 
DnsModeData->DnsCacheCount);
-  ASSERT (CacheList != NULL);
+  if (CacheList == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+Dns4CleanConfigure (&DnsModeData->DnsConfigData);
+FreePool (ServerList);
+gBS->RestoreTPL (OldTpl);
+return Status;
+  }
+  
   Index =0;
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4CacheList) {
 CacheItem = NET_LIST_USER_STRUCT (Entry, DNS4_CACHE, AllCacheLink);
 CopyMem (CacheList + Index, &CacheItem->DnsCache, sizeof 
(EFI_DNS4_CACHE_ENTRY));
 Index++;
@@ -931,11 +944,17 @@ Dns6GetModeData (
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6ServerList) {
 Index++;
   }
   DnsModeData->DnsServerCount = (UINT32) Index;
   ServerList = AllocatePool (sizeof(EFI_IPv6_ADDRESS) * 
DnsModeData->DnsServerCount);
-  ASSERT (ServerList != NULL);
+  if (ServerList == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+Dns6CleanConfigure (&DnsModeData->DnsConfigData);
+gBS->RestoreTPL (OldTpl);
+return Status;
+  }
+  
   Index = 0;
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6ServerList) {
 ServerItem = NET_LIST_USER_STRUCT (Entry, DNS6_SERVER_IP, AllServerLink);
 CopyMem (ServerList + Index, &ServerItem->Dns6ServerIp, sizeof 
(EFI_IPv6_ADDRESS));
 Index++;
@@ -949,11 +968,18 @@ Dns6GetModeData (
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6CacheList) {
 Index++;
   }
   DnsModeData->DnsCacheCount = (UINT32) Index;
   CacheList = AllocatePool (sizeof(EFI_DNS6_CACHE_ENTRY) * 
DnsModeData->DnsCacheCount);
-  ASSERT (CacheList != NULL);
+  if (CacheList == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+Dns6CleanConfigure (&DnsModeData->DnsConfigData);
+FreePool (ServerList);
+gBS->RestoreTPL (OldTpl);
+return Status;
+  }
+  
   Index =0;
   NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6CacheList) {
 CacheItem = NET_LIST_USER_STRUCT (Entry, DNS6_CACHE, AllCacheLink);
 CopyMem (CacheList + Index, &CacheItem->DnsCache, sizeof 
(EFI_DNS6_CACHE_ENTRY));
 Index++;
--
1.9.5.msysgit.1

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

[edk2] [PATCH] IntelFsp2Pkg: rename GetFspVpdDataPointer() to GetFspCfgRegionDataPointer()

2016-06-17 Thread Jiewen Yao

FSP2.0 removed VPD concept.
Rename GetFspVpdDataPointer() to GetFspCfgRegionDataPointer() to follow FSP2.0
specification (CfgRegionOffset).

Cc: Giri P Mudusuru 
Cc: Amy Chan 
Cc: Satya Yarlagadda 
Cc: Maurice Ma 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 IntelFsp2Pkg/Include/Library/FspCommonLib.h  | 6 +++---
 IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/IntelFsp2Pkg/Include/Library/FspCommonLib.h 
b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
index 0bb0c53..e13d0c3 100644
--- a/IntelFsp2Pkg/Include/Library/FspCommonLib.h
+++ b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
@@ -234,13 +234,13 @@ GetFspInfoHeaderFromApiContext (
   );
 
 /**
-  This function gets the VPD data pointer.
+  This function gets the CfgRegion data pointer.
 
-  @return VpdDataRgnPtr   VPD data pointer.
+  @return CfgRegion data pointer.
 **/
 VOID *
 EFIAPI
-GetFspVpdDataPointer (
+GetFspCfgRegionDataPointer (
   VOID
   );
 
diff --git a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c 
b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
index efd55f4..151b189 100644
--- a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
+++ b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
@@ -425,13 +425,13 @@ GetFspInfoHeaderFromApiContext (
 }
 
 /**
-  This function gets the VPD data pointer.
+  This function gets the CfgRegion data pointer.
 
-  @return VpdDataRgnPtr   VPD data pointer.
+  @return CfgRegion data pointer.
 **/
 VOID *
 EFIAPI
-GetFspVpdDataPointer (
+GetFspCfgRegionDataPointer (
   VOID
   )
 {
-- 
2.7.4.windows.1

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

Re: [edk2] [PATCH 4/4] ArmPkg/ArmMmuLib: add PEI specific version of ArmMmuLib

2016-06-17 Thread Leif Lindholm

On Thu, Jun 16, 2016 at 12:29:30PM +0200, Ard Biesheuvel wrote:
> This introduces a special version of ArmMmuLib for PEIMs that takes care
> only to perform cache maintenance on the live entry replacement routine
> if the module is not executing in place. Not only is such cache maintenance
> unnecessary in that case, it may be actively harmful on some systems that
> fail to tolerate cache maintenance operations on NOR flash regions.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c | 60 
> 
>  ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf  | 36 
>  2 files changed, 96 insertions(+)
> 
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c 
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
> new file mode 100644
> index ..91dc1157e79a
> --- /dev/null
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
> @@ -0,0 +1,60 @@
> +#/* @file
> +#
> +#  Copyright (c) 2016, Linaro Limited. All rights reserved.
> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD 
> License
> +#  which accompanies this distribution.  The full text of the license may be 
> found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +#*/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_STATUS
> +EFIAPI
> +ArmMmuPeiLibConstructor (
> +  IN   EFI_PEI_FILE_HANDLE   FileHandle,
> +  IN CONST EFI_PEI_SERVICES  **PeiServices
> +  )
> +{
> +  extern UINT32 ArmReplaceLiveTranslationEntrySize;
> +
> +  EFI_FV_FILE_INFO  FileInfo;
> +  EFI_STATUSStatus;
> +
> +  ASSERT (FileHandle != NULL);
> +
> +  Status = (*PeiServices)->FfsGetFileInfo (FileHandle, &FileInfo);
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Some platforms do not cope very well with cache maintenance being
> +  // performed on regions backed by NOR flash. Since the cache maintenance
> +  // is unnecessary to begin with in that case, perform it only when not
> +  // executing in place.
> +  //

I think perhaps the wording of the above is confusing me a little bit;
the thing that makes it not matter is that it is executing in place,
not that it is backed by NOR, right? Could the statement be flipped?:

"Perform it only when not executing in place, since otherwise the
cache maintenance is unnecessary."

Someone who is less fond of multiple negations in a singe sentence
than me may prefer to reword it further...

/
Leif

> +  if ((UINTN)FileInfo.Buffer <= (UINTN)ArmReplaceLiveTranslationEntry &&
> +  ((UINTN)FileInfo.Buffer + FileInfo.BufferSize >=
> +   (UINTN)ArmReplaceLiveTranslationEntry + 
> ArmReplaceLiveTranslationEntrySize)) {
> +DEBUG ((EFI_D_INFO, "ArmMmuLib: skipping cache maintenance on XIP 
> PEIM\n"));
> +  } else {
> +DEBUG ((EFI_D_INFO, "ArmMmuLib: performing cache maintenance on shadowed 
> PEIM\n"));
> +//
> +// The ArmReplaceLiveTranslationEntry () helper function may be invoked
> +// with the MMU off so we have to ensure that it gets cleaned to the PoC
> +//
> +WriteBackDataCacheRange (ArmReplaceLiveTranslationEntry,
> +  ArmReplaceLiveTranslationEntrySize);
> +  }
> +
> +  return RETURN_SUCCESS;
> +}
> diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf 
> b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
> new file mode 100644
> index ..14ebf8de673d
> --- /dev/null
> +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
> @@ -0,0 +1,36 @@
> +#/** @file
> +#
> +#  Copyright (c) 2016 Linaro Ltd. All rights reserved.
> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD 
> License
> +#  which accompanies this distribution. The full text of the license may be 
> found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +#
> +#**/
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = ArmMmuPeiLib
> +  FILE_GUID  = b50d8d53-1ad1-44ea-9e69-8c89d4a6d08b
> +  MODULE_TYPE= PEIM
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = ArmMmuLib|PEIM
> +  CONSTRUCTOR= ArmMmuPeiLibConstructor
> +
> +[Sources.AARCH64]
> +  AArch64/ArmMmuLibCore.c
> +  AArch64/ArmMmuPeiLibConstructor.c
> +  AArch64/ArmMmuLibReplaceEntry.S
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  MdePkg/MdePkg.dec
> +
> +[Li

Re: [edk2] [PATCH] IntelFsp2Pkg: rename GetFspVpdDataPointer() to GetFspCfgRegionDataPointer()

2016-06-17 Thread Mudusuru, Giri P

Thanks for aligning to the FSP spec.
Reviewed-by: Giri P Mudusuru 


> -Original Message-
> From: Chan, Amy
> Sent: Friday, June 17, 2016 2:40 AM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Mudusuru, Giri P ; Yarlagadda, Satya P
> ; Ma, Maurice 
> Subject: RE: [PATCH] IntelFsp2Pkg: rename GetFspVpdDataPointer() to
> GetFspCfgRegionDataPointer()
> 
> Thanks Jiewen. Looks good to me.
> 
> Reviewed-by: Chan, Amy 
> 
> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, June 17, 2016 5:25 PM
> To: edk2-devel@lists.01.org
> Cc: Mudusuru, Giri P ; Chan, Amy
> ; Yarlagadda, Satya P ;
> Ma, Maurice 
> Subject: [PATCH] IntelFsp2Pkg: rename GetFspVpdDataPointer() to
> GetFspCfgRegionDataPointer()
> 
> FSP2.0 removed VPD concept.
> Rename GetFspVpdDataPointer() to GetFspCfgRegionDataPointer() to follow
> FSP2.0 specification (CfgRegionOffset).
> 
> Cc: Giri P Mudusuru 
> Cc: Amy Chan 
> Cc: Satya Yarlagadda 
> Cc: Maurice Ma 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  IntelFsp2Pkg/Include/Library/FspCommonLib.h  | 6 +++---
>  IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> index 0bb0c53..e13d0c3 100644
> --- a/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> +++ b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> @@ -234,13 +234,13 @@ GetFspInfoHeaderFromApiContext (
>);
> 
>  /**
> -  This function gets the VPD data pointer.
> +  This function gets the CfgRegion data pointer.
> 
> -  @return VpdDataRgnPtr   VPD data pointer.
> +  @return CfgRegion data pointer.
>  **/
>  VOID *
>  EFIAPI
> -GetFspVpdDataPointer (
> +GetFspCfgRegionDataPointer (
>VOID
>);
> 
> diff --git a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> index efd55f4..151b189 100644
> --- a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> +++ b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> @@ -425,13 +425,13 @@ GetFspInfoHeaderFromApiContext (  }
> 
>  /**
> -  This function gets the VPD data pointer.
> +  This function gets the CfgRegion data pointer.
> 
> -  @return VpdDataRgnPtr   VPD data pointer.
> +  @return CfgRegion data pointer.
>  **/
>  VOID *
>  EFIAPI
> -GetFspVpdDataPointer (
> +GetFspCfgRegionDataPointer (
>VOID
>)
>  {
> --
> 2.7.4.windows.1

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

Re: [edk2] [PATCH] ShellPkg/UefiHandleParsing: Show handle's loaded image device path

2016-06-17 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, June 17, 2016 12:59 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Qiu, Shumin
> 
> Subject: [PATCH] ShellPkg/UefiHandleParsing: Show handle's loaded image
> device path
> Importance: High
> 
> The patch fixed a bug in UefiHandleParsingLib to show handle's loaded
> image device path.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> Cc: Shumin Qiu 
> ---
>  .../UefiHandleParsingLib/UefiHandleParsingLib.c| 83
> ++
>  1 file changed, 68 insertions(+), 15 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> index 9789471..b82f925 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> @@ -731,6 +731,42 @@ DriverEfiVersionProtocolDumpInformation(
>UnicodeSPrint(RetVal, VersionStringSize, L"0x%08x", DriverEfiVersion-
> >FirmwareVersion);
>return (RetVal);
>  }
> +/**
> +  Function to convert device path to string.
> +
> +  This will allocate the return buffer from boot services pool.
> +
> +  @param[in] DevPathPointer to device path instance.
> +  @param[in] VerboseTRUE for additional information, FALSE otherwise.
> +  @param[in] Length Maximum allowed text length of the device path.
> +
> +  @retval A pointer to a string containing the information.
> +**/
> +CHAR16*
> +ConvertDevicePathToShortText(
> +  IN CONST EFI_DEVICE_PATH_PROTOCOL *DevPath,
> +  IN CONST BOOLEAN  Verbose,
> +  IN CONST UINTNLength
> +  )
> +{
> +  CHAR16*Temp;
> +  CHAR16*Temp2;
> +  UINTN Size;
> +
> +  //
> +  // I cannot decide whether to allow shortcuts here (the second BOOLEAN
> on the next line)
> +  //
> +  Temp = ConvertDevicePathToText(DevPath, TRUE, TRUE);
> +  if (!Verbose && Temp != NULL && StrLen(Temp) > Length) {
> +Temp2 = NULL;
> +Size  = 0;
> +Temp2 = StrnCatGrow(&Temp2, &Size, L"..", 0);
> +Temp2 = StrnCatGrow(&Temp2, &Size, Temp+(StrLen(Temp) - (Length -
> 2)), 0);
> +FreePool(Temp);
> +Temp = Temp2;
> +  }
> +  return (Temp);
> +}
> 
>  /**
>Function to dump information about DevicePath protocol.
> @@ -740,7 +776,7 @@ DriverEfiVersionProtocolDumpInformation(
>@param[in] TheHandle  The handle that has the protocol installed.
>@param[in] VerboseTRUE for additional information, FALSE otherwise.
> 
> -  @retval A poitner to a string containing the information.
> +  @retval A pointer to a string containing the information.
>  **/
>  CHAR16*
>  EFIAPI
> @@ -751,26 +787,43 @@ DevicePathProtocolDumpInformation(
>  {
>EFI_DEVICE_PATH_PROTOCOL  *DevPath;
>CHAR16*Temp;
> -  CHAR16*Temp2;
>EFI_STATUSStatus;
> -  UINTN Size;
>Temp = NULL;
> 
>Status = gBS->OpenProtocol(TheHandle, &gEfiDevicePathProtocolGuid,
> (VOID**)&DevPath, gImageHandle, NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>if (!EFI_ERROR(Status)) {
> -//
> -// I cannot decide whether to allow shortcuts here (the second BOOLEAN
> on the next line)
> -//
> -Temp = ConvertDevicePathToText(DevPath, TRUE, TRUE);
> +Temp = ConvertDevicePathToShortText (DevPath, Verbose, 30);
>  gBS->CloseProtocol(TheHandle, &gEfiDevicePathProtocolGuid,
> gImageHandle, NULL);
>}
> -  if (!Verbose && Temp != NULL && StrLen(Temp) > 30) {
> -Temp2 = NULL;
> -Size  = 0;
> -Temp2 = StrnCatGrow(&Temp2, &Size, L"..", 0);
> -Temp2 = StrnCatGrow(&Temp2, &Size, Temp+(StrLen(Temp) - 28), 0);
> -FreePool(Temp);
> -Temp = Temp2;
> +  return (Temp);
> +}
> +
> +/**
> +  Function to dump information about LoadedImageDevicePath protocol.
> +
> +  This will allocate the return buffer from boot services pool.
> +
> +  @param[in] TheHandle  The handle that has the protocol installed.
> +  @param[in] VerboseTRUE for additional information, FALSE otherwise.
> +
> +  @retval A pointer to a string containing the information.
> +**/
> +CHAR16*
> +EFIAPI
> +LoadedImageDevicePathProtocolDumpInformation(
> +  IN CONST EFI_HANDLE TheHandle,
> +  IN CONST BOOLEANVerbose
> +  )
> +{
> +  EFI_DEVICE_PATH_PROTOCOL  *DevPath;
> +  CHAR16*Temp;
> +  EFI_STATUSStatus;
> +  Temp = NULL;
> +
> +  Status = gBS->OpenProtocol(TheHandle,
> &gEfiLoadedImageDevicePathProtocolGuid, (VOID**)&DevPath,
> gImageHandle, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> +  if (!EFI_ERROR(Status)) {
> +Temp = ConvertDevicePathToShortText (DevPath, Verbose, 30);
> +gBS->CloseProtocol(TheHandle, &gEfiDevicePathProto

Re: [edk2] [PATCH 3/4] ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib

2016-06-17 Thread Laszlo Ersek

On 06/16/16 12:29, Ard Biesheuvel wrote:
> Switch all users of ArmLib that depend on the MMU routines to the new,
> separate ArmMmuLib. This needs to occur in one go, since the MMU
> routines are removed from ArmLib build at the same time, to prevent
> conflicting symbols.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf   |   1 
> +
>  ArmPkg/Include/Library/ArmLib.h|  38 
> -
>  ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c  |  36 
> -
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   |   3 
> -
>  ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  |   1 
> -
>  ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 751 
> 
>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S  |   6 
> -
>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|   6 
> -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h |  12 
> -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf   |   1 
> -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf  |   1 
> -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 418 
> ---
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |   5 
> -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |   4 
> -
>  ArmVirtPkg/ArmVirtQemu.dsc |   2 
> +
>  ArmVirtPkg/ArmVirtXen.dsc  |   2 
> +
>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   |   1 
> +
>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf |   1 
> +
>  MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c |   1 
> +
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   1 
> +
>  20 files changed, 9 insertions(+), 1282 deletions(-)

[snip]

> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 32a5aa977401..3decb11712ff 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -47,6 +47,8 @@ [LibraryClasses.ARM]
>ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>  
>  [LibraryClasses.common]
> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> +
># Virtio Support
>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>
> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca6491b7a..ba7ec10db224 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -45,6 +45,8 @@ [LibraryClasses.ARM]
>ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>  
>  [LibraryClasses.common]
> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> +
># Virtio Support
>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>
> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> diff --git 
> a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c 
> b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
> index f6c69152848e..251e5314e61d 100644
> --- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
> +++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
> @@ -15,6 +15,7 @@
>  
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git 
> a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf 
> b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
> index 9fba16f90f1f..028d6fb5ac28 100644
> --- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
> +++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
> @@ -34,6 +34,7 @@ [LibraryClasses]
>DebugLib
>HobLib
>ArmLib
> +  ArmMmuLib
>ArmPlatformLib
>CacheMaintenanceLib
>  

Shouldn't you add the library resolution to "ArmVirtQemuKernel.dsc" too?
That DSC too resolves ArmLib.

Acked-by: Laszlo Ersek 

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

Re: [edk2] [PATCH 0/8] Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr

2016-06-17 Thread Kinney, Michael D

Star,

Thanks.  I missed that behavior.  I agree that ASSERT() is still in place.

Mike

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, June 16, 2016 5:31 PM
> To: Kinney, Michael D ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming ; 
> Dong,
> Eric ; Tian, Feng ; Ni, Ruiyu
> ; Fu, Siyuan ; Wu, Jiaxin
> ; Carsey, Jaben ; Zhang, Chao B
> ; Fan, Jeff ; Zeng, Star
> 
> Subject: RE: [PATCH 0/8] Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> 
> Mike,
> 
> Good comments.
> The new functions have below comments for the error return codes.
> 
>   If an error would be returned, then the function will also ASSERT().
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Kinney, Michael D
> Sent: Friday, June 17, 2016 3:31 AM
> To: Zeng, Star ; edk2-devel@lists.01.org; Kinney, 
> Michael D
> 
> Cc: Yao, Jiewen ; Gao, Liming ; 
> Dong,
> Eric ; Tian, Feng ; Ni, Ruiyu
> ; Fu, Siyuan ; Wu, Jiaxin
> ; Carsey, Jaben ; Zhang, Chao B
> ; Fan, Jeff 
> Subject: RE: [PATCH 0/8] Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> 
> Star,
> 
> In many places in this patch series the return status is not checked.
> 
> This means there is actually a behavior change with this series.  The original
> version had ASSERT() conditions.  With this new version, the
> ASSERT() conditions are replaced with error return codes.  If the error 
> return codes
> are not evaluated, then a build that has ASSERT() enabled and an ASSERT() 
> would be
> triggered, will no longer see an ASSERT().
> 
> Mike
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Wednesday, June 15, 2016 1:44 AM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen ; Gao, Liming
> > ; Kinney, Michael D
> > ; Dong, Eric ; Tian,
> > Feng ; Ni, Ruiyu ; Fu, Siyuan
> > ; Wu, Jiaxin ; Carsey, Jaben
> > ; Zhang, Chao B ; Fan,
> > Jeff 
> > Subject: [PATCH 0/8] Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> >
> > It is the follow up of 3ab41b7a325ca11a12b42f5ad1661c4b6791cb49
> > to replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr with
> > UnicodeStrToAsciiStrS/AsciiStrToUnicodeStrS.
> >
> > Cc: Jiewen Yao 
> > Cc: Liming Gao 
> > Cc: Michael D Kinney 
> > Cc: Eric Dong 
> > Cc: Feng Tian 
> > Cc: Ruiyu Ni 
> > Cc: Siyuan Fu 
> > Cc: Jiaxin Wu 
> > Cc: Jaben Carsey 
> > Cc: Chao Zhang 
> > Cc: Jeff Fan 
> > Star Zeng (8):
> >   MdePkg: Replace UnicodeStrToAsciiStr() with UnicodeStrToAsciiStrS()
> >   MdeModulePkg: Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> >   NetworkPkg: Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> >   PerformancePkg: Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> >   SecurityPkg: Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> >   ShellPkg: Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> >   IntelFrameworkModulePkg: Replace
> > UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
> >   MdePkg: Indicate UnicodeStrToAsciiStr/AsciiStrToUnicodeStr to be
> > deprecated
> >
> >  .../Library/GenericBdsLib/BdsBoot.c|  4 +-
> >  .../Library/LegacyBootManagerLib/LegacyBm.c|  6 +-
> >  .../Universal/BdsDxe/FrontPage.c   | 10 ++-
> >  MdeModulePkg/Application/UiApp/FrontPage.c |  2 +-
> >  .../UiApp/FrontPageCustomizedUiSupport.c   |  6 +-
> >  MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c  |  2 +-
> >  MdeModulePkg/Bus/Sd/SdDxe/SdDxe.c  |  2 +-
> >  MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 18 +++--
> >  .../Library/UefiBootManagerLib/BmBootDescription.c |  4 +-
> >  .../Library/VarCheckHiiLib/VarCheckHiiGen.c|  6 +-
> >  .../HiiDatabaseDxe/ConfigKeywordHandler.c  | 46 ++-
> >  .../Universal/HiiDatabaseDxe/ConfigRouting.c   | 42 +++
> >  MdePkg/Include/Library/BaseLib.h   | 11 +++
> >  MdePkg/Library/BaseLib/String.c| 11 ++-
> >  .../Library/UefiDevicePathLib/DevicePathFromText.c |  4 +-
> > .../Library/UefiFileHandleLib/UefiFileHandleLib.c  |  4 +-
> > .../Application/IpsecConfig/PolicyEntryOperation.c |  6 +-
> >  NetworkPkg/HttpBootDxe/HttpBootClient.c| 19 +++--
> >  NetworkPkg/HttpBootDxe/HttpBootConfig.c|  2 +-
> >  NetworkPkg/HttpDxe/HttpImpl.c  |  8 +-
> >  NetworkPkg/HttpDxe/HttpProto.c |  8 +-
> >  NetworkPkg/IScsiDxe/IScsiConfig.c  | 88 
> > +++---
> >  NetworkPkg/IScsiDxe/IScsiDriver.c  |  2 +-
> >  NetworkPkg/IScsiDxe/IScsiMisc.c|  6 +-
> >  PerformancePkg/Dp_App/Dp.c |  6 +-
> >  PerformancePkg/Dp_App/DpTrace.c| 12 +--
> >  SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalDriver.c  |  4 +-
> >  SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c |  6 +-
> >  .../Tcg/Opal/OpalPasswordDxe/OpalHiiPrivate.h  |  2 +-
> >  ShellPkg/Library/UefiDpLib/Dp.c|  8 +-
> >  ShellPkg/Library/UefiDpLib/DpTrace.c   | 10 +--
> >  ShellPkg/Libr

Re: [edk2] [PATCH 1/8] MdePkg: Replace UnicodeStrToAsciiStr() with UnicodeStrToAsciiStrS()

2016-06-17 Thread Kinney, Michael D


Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, June 15, 2016 1:44 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming ; 
> Kinney,
> Michael D 
> Subject: [PATCH 1/8] MdePkg: Replace UnicodeStrToAsciiStr() with
> UnicodeStrToAsciiStrS()
> 
> It is the follow up of 3ab41b7a325ca11a12b42f5ad1661c4b6791cb49
> to replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr with
> UnicodeStrToAsciiStrS/AsciiStrToUnicodeStrS.
> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c | 4 ++--
>  MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
> b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
> index 961ccb5489fb..c167b4ce031e 100644
> --- a/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
> +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathFromText.c
> @@ -1,7 +1,7 @@
>  /** @file
>DevicePathFromText protocol as defined in the UEFI 2.0 specification.
> 
> -Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2013 - 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
> @@ -2873,7 +2873,7 @@ DevPathFromTextWiFi (
>DataLen = 32;
>  }
> 
> -UnicodeStrToAsciiStr (SSIdStr, AsciiStr);
> +UnicodeStrToAsciiStrS (SSIdStr, AsciiStr, sizeof (AsciiStr));
>  CopyMem (WiFiDp->SSId, AsciiStr, DataLen);
>}
> 
> diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> index dfec5fa4d47d..8f3cde0f6c41 100644
> --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> @@ -1,7 +1,7 @@
>  /** @file
>Provides interface to EFI_FILE_HANDLE functionality.
> 
> -  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved. 
> +  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved. 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
>which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -1136,7 +1136,7 @@ FileHandleWriteLine(
>  if (AsciiBuffer == NULL) {
>return EFI_OUT_OF_RESOURCES;
>  }
> -UnicodeStrToAsciiStr (Buffer, AsciiBuffer);
> +UnicodeStrToAsciiStrS (Buffer, AsciiBuffer, Size);
>  for (Index = 0; Index < Size; Index++) {
>if (!((AsciiBuffer[Index] >= 0) && (AsciiBuffer[Index] < 128))){
>  FreePool(AsciiBuffer);
> --
> 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 8/8] MdePkg: Indicate UnicodeStrToAsciiStr/AsciiStrToUnicodeStr to be deprecated

2016-06-17 Thread Kinney, Michael D

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, June 15, 2016 1:44 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming ; 
> Kinney,
> Michael D 
> Subject: [PATCH 8/8] MdePkg: Indicate 
> UnicodeStrToAsciiStr/AsciiStrToUnicodeStr to be
> deprecated
> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdePkg/Include/Library/BaseLib.h | 11 +++
>  MdePkg/Library/BaseLib/String.c  | 11 +--
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index 79f421a97111..7e085b93a669 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -1020,7 +1020,11 @@ StrHexToUint64 (
>IN  CONST CHAR16 *String
>);
> 
> +#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
> +
>  /**
> +  [ATTENTION] This function is deprecated for security reason.
> +
>Convert a Null-terminated Unicode string to a Null-terminated
>ASCII string and returns the ASCII string.
> 
> @@ -1060,6 +1064,8 @@ UnicodeStrToAsciiStr (
>OUT CHAR8 *Destination
>);
> 
> +#endif
> +
>  /**
>Convert a Null-terminated Unicode string to a Null-terminated
>ASCII string.
> @@ -1611,8 +1617,11 @@ AsciiStrHexToUint64 (
>IN  CONST CHAR8*String
>);
> 
> +#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
> 
>  /**
> +  [ATTENTION] This function is deprecated for security reason.
> +
>Convert one Null-terminated ASCII string to a Null-terminated
>Unicode string and returns the Unicode string.
> 
> @@ -1646,6 +1655,8 @@ AsciiStrToUnicodeStr (
>OUT CHAR16*Destination
>);
> 
> +#endif
> +
>  /**
>Convert one Null-terminated ASCII string to a Null-terminated
>Unicode string.
> diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
> index 92992a5d27e0..07c0562f3bfc 100644
> --- a/MdePkg/Library/BaseLib/String.c
> +++ b/MdePkg/Library/BaseLib/String.c
> @@ -1000,7 +1000,11 @@ InternalAsciiIsHexaDecimalDigitCharacter (
>  (Char >= 'a' && Char <= 'f'));
>  }
> 
> +#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
> +
>  /**
> +  [ATTENTION] This function is deprecated for security reason.
> +
>Convert a Null-terminated Unicode string to a Null-terminated
>ASCII string and returns the ASCII string.
> 
> @@ -1078,8 +1082,6 @@ UnicodeStrToAsciiStr (
>return ReturnValue;
>  }
> 
> -#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
> -
>  /**
>[ATTENTION] This function will be deprecated for security reason.
> 
> @@ -1986,8 +1988,11 @@ AsciiStrHexToUint64 (
>return Result;
>  }
> 
> +#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
> 
>  /**
> +  [ATTENTION] This function is deprecated for security reason.
> +
>Convert one Null-terminated ASCII string to a Null-terminated
>Unicode string and returns the Unicode string.
> 
> @@ -2054,6 +2059,8 @@ AsciiStrToUnicodeStr (
>return ReturnValue;
>  }
> 
> +#endif
> +
>  /**
>Converts an 8-bit value to an 8-bit BCD value.
> 
> --
> 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 0/2] Update UNIXGCC toolchain and make it work again

2016-06-17 Thread Bill Paul

Of all the gin joints in all the towns in all the world, Jordan Justen had to 
walk into mine at 16:46:07 on Thursday 16 June 2016 and say:

> On 2016-06-16 16:11:34, Bill Paul wrote:
> > Of all the gin joints in all the towns in all the world, Jordan Justen
> > had to
> > 
> > walk into mine at 15:47:05 on Thursday 16 June 2016 and say:
> > > On 2016-06-16 14:11:01, Bill Paul wrote:
> > > > Really there are two paths here:
> > > > 
> > > > 1) Support the OS host compiler
> > > > 2) Use a cross-build compiler
> > > 
> > > You can also just build and install GCC 4.9 under your home dir, or
> > > another location that doesn't take over the system GCC.
> > 
> > So I either bootstrap a new host GCC or bootstrap a cross-build GCC. I
> > have to build GCC either way.
> 
> Yeah, so build the one that is better supported and tested for EDK II.

I've already made it clear that I'm willing to shoulder the burden of using 
the cross-build toolchain even if it's not considered officially supported. I 
know that if it breaks I get to keep both pieces.

> Relatedly ... If Steven gets clang working for EDK II, will you
> consider using that toolchain instead? That seems like a toolchain for
> EDK II that actually might have a future.

a) Getting _which_ clang working? If you still mean host-based versions of 
clang instead of a cross-build target that I can bootstrap anywhere, then I've 
already explained why I'm against that.

b) Why not have both since the only thing needed to make UNIXGCC work again is 
to FIX THE BITROT.

c) I've already got a patch to fix UNIXGCC now. Why should have to wait until 
later? (I always waited almost a year for someone to fix UNIXGCC.) If you can 
add a clang cross-compiler option instead of the GNU option that's great, but 
until then, why not have a temporary stop-gap?

> > > > Today all I want to do is FIX THE BITROT, especially given that the
> > > > fix is pretty trivial.
> > > 
> > > UNIXGCC is MinGW GCC 4.3, so fixing the bitrot would mean updating the
> > > script to allow it to build MinGW GCC 4.3.
> > 
> > [I think you meant "to build something newer than MinGW GCC 4.3."]
> 
> No, I did not. UNIXGCC is an ancient GCC (4.3) MinGW toolchain. Which
> nobody uses.

But they can use a newer version. (Like I do.)

> And nobody tests. And probably doesn't build. But for
> some readon we can't deprecate it.

I think that's a misinterpretation. It occurred to on the way home from work 
yesterday that what you were trying to say was that the UNIXGCC toolchain 
option is tied to GCC 4.3. It's more accurate to say that UNIXGCC is to the 
MinGW compiler generated by the mingw-build.py script. I don't think there's 
anything written down anywhere that says that script can't be updated to use a 
newer version of GCC.

You may be inferring that it's stuck at that version forever because nobody 
has taken the time to fix it, but I don't think anyone else is saying that's 
the case, and there's no documentation that I can find to support that 
position. The instructions for using the cross-build option are here:

https://github.com/tianocore/tianocore.github.io/wiki/Unix-like-systems

(And on a few descendant pages.)

It says it uses the MinGW compiler. It doesn't specify exactly which version 
nor say that it will always be pegged at the same version forever.

So please, I implore you: stop trying to make it sound that way.

> I assumed that the script no longer managed to build MinGW GCC 4.3,
> but maybe it still works...

Yes,  it still does build a working GCC 4.3. But you can't use GCC 4.3 
anymore. Also, it could be arguably considered a bug to have it use that 
version. The 4.3 MinGW target assumes you have to use underscore decoration 
for both IA32 and X64 targets. That's actually wrong (and the wrongness was 
perpetuated in the tools_def file too -- that's something else that I fixed). 
Newer versions fix that (it only applies to IA32).

And as I said, there is nothing written in stone that says the script can't be 
updated to use a newer version of GCC. And doing that took barely more than 
just changing the download paths and MD5 sums. It was not rocket science. No 
animals were harmed.

> > > If we want to add support for MinGW GCC 4.9, then I'd rather see it
> > > called MINGWGCC49.
> > 
> > And when you that, you're still going to have to apply the patch that I
> > just gave you to fix the .dsc files in OVMF because _any_ MinGW build
> > will be missing the support for the -z flag.
> 
> Or, you can try to build ELF GCC 4.9 and then try GCC49 to see if it
> can also work for you.

You're going in circles. I explained already:

1) I don't want to use a host compiler for what is fundamentally a cross-build 
target.
2) It makes no sense for me to replace my host compiler (which may be tightly 
integrated with my host environment and work perfectly well for its intended 
use)
3) I could build a "x86-none-elf" cross-build compiler instead, but I'm 
basically trying to do that anyway. A

Re: [edk2] [PATCH 3/4] ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib

2016-06-17 Thread Ard Biesheuvel

On 17 June 2016 at 18:30, Laszlo Ersek  wrote:
> On 06/16/16 12:29, Ard Biesheuvel wrote:
>> Switch all users of ArmLib that depend on the MMU routines to the new,
>> separate ArmMmuLib. This needs to occur in one go, since the MMU
>> routines are removed from ArmLib build at the same time, to prevent
>> conflicting symbols.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf   |   
>> 1 +
>>  ArmPkg/Include/Library/ArmLib.h|  
>> 38 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c  |  
>> 36 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   |   
>> 3 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  |   
>> 1 -
>>  ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 
>> 751 
>>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S  |   
>> 6 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|   
>> 6 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h |  
>> 12 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf   |   
>> 1 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf  |   
>> 1 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 
>> 418 ---
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |   
>> 5 -
>>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |   
>> 4 -
>>  ArmVirtPkg/ArmVirtQemu.dsc |   
>> 2 +
>>  ArmVirtPkg/ArmVirtXen.dsc  |   
>> 2 +
>>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   |   
>> 1 +
>>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf |   
>> 1 +
>>  MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c |   
>> 1 +
>>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   
>> 1 +
>>  20 files changed, 9 insertions(+), 1282 deletions(-)
>
> [snip]
>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index 32a5aa977401..3decb11712ff 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -47,6 +47,8 @@ [LibraryClasses.ARM]
>>ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>>
>>  [LibraryClasses.common]
>> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>> +
>># Virtio Support
>>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>
>> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
>> index 594ca6491b7a..ba7ec10db224 100644
>> --- a/ArmVirtPkg/ArmVirtXen.dsc
>> +++ b/ArmVirtPkg/ArmVirtXen.dsc
>> @@ -45,6 +45,8 @@ [LibraryClasses.ARM]
>>ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>>
>>  [LibraryClasses.common]
>> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>> +
>># Virtio Support
>>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>
>> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>> diff --git 
>> a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c 
>> b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
>> index f6c69152848e..251e5314e61d 100644
>> --- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
>> +++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
>> @@ -15,6 +15,7 @@
>>
>>  #include 
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git 
>> a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf 
>> b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
>> index 9fba16f90f1f..028d6fb5ac28 100644
>> --- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
>> +++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
>> @@ -34,6 +34,7 @@ [LibraryClasses]
>>DebugLib
>>HobLib
>>ArmLib
>> +  ArmMmuLib
>>ArmPlatformLib
>>CacheMaintenanceLib
>>
>
> Shouldn't you add the library resolution to "ArmVirtQemuKernel.dsc" too?
> That DSC too resolves ArmLib.
>

You're quite right. Thanks for spotting that. I will add it before committing

> Acked-by: Laszlo Ersek 
>

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

Re: [edk2] [RFC V2] Proposal to organize packages into directories

2016-06-17 Thread Kinney, Michael D

Hi Jordan,

Yes.  Many terms were considered other than Silicon, except Carbon :)

None of the terms we have considered are a perfect match. 

We are wanting to keep modules for controllers attached to I/O subsystems
and modules for peripherals separate from modules that perform basic 
CPU/Memory/Chipset/SoC init.

Is there any preference on the list between Silicon, Chip, or Device
or other names for basic CPU/Memory/Chipset/SoC init?

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
> Justen
> Sent: Wednesday, June 1, 2016 1:07 PM
> To: Kinney, Michael D ; edk2-devel@lists.01.org; 
> Kinney,
> Michael D 
> Subject: Re: [edk2] [RFC V2] Proposal to organize packages into directories
> 
> On 2016-05-25 19:03:38, Kinney, Michael D wrote:
> > # Top Level Directory Structure (Listed Alphabetically)
> > ```
> > edk2
> >   Application   Applications and application support libraries
> >   BaseTools EDK II build tools/scripts
> >   Conf  EDK II build configuration files
> >   Core  Platform agnostic packages for core FW services
> >   DeprecatedPackages that will be removed from edk2/master soon
> >   DriverEDK II Drivers (no platform assumptions)
> >   Non-Vendor specific EDK II drivers
> >   Non-Vendor specific EDK II drivers
> > . . .
> > Vendor  Vendor specific EDK II drivers
> >   
> >   
> >   Platform  Platforms used to validate edk2/master features
> > Common  Non-vendor specific platform packages
> > EmulatedNon-vendor specific emulated platform packages
> > Arm ARM specific platform packages
> > Intel   Intel specific platform packages
> > specific platform packages
> > specific platform packages
> >   Silicon   CPU/Chipset/SoC packages
> 
> Were any other terms considered? Chip, Device?
> 
> Carbon? ;)
> 
> -Jordan
> 
> > Common  Non-vendor specific CPU/Chipset/SoC drivers
> > Arm Arm specific CPU/Chipset/SoC drivers
> > Intel   Intel specific CPU/Chipset/SoC drivers
> > specific CPU/Chipset/SoC drivers
> > specific CPU/Chipset/SoC drivers
> > ```
> >
> ___
> 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] 32-bit MMIO degradation for VFBARs -- why?

2016-06-17 Thread Laszlo Ersek

(Alex, if you would like to comment on this thread, please go to
 first, and subscribe
to the list. Await your subscription confirmation, and follow up only
then. Regrettably, this list does not reflect messages from people who
are not subscribed. I think it's very bad practice, but thus far I've
been unsuccessful in convincing the existent subscribers otherwise.)

Ray,

from the following git commit:

https://github.com/tianocore/edk2/commit/05070c1b471b0

we have such logic in place, in the DegradeResources() function, that
64-bit MMIO BARs of a PCI dev/fun are degraded to 32-bit address space
*iff*:

- the device has an option ROM, *and*
  - the BAR is either a VF BAR, *or*
  - the platform's IncompatiblePciDeviceSupport driver does not report
fixed 64-bit granularity for the BAR.

Equivalently, we do *not* degrade the 64-bit MMIO resource *iff*:

- the device has no option ROM, *or*
  - the BAR is not a VF BAR, *and*
  - the platform's IncompatiblePciDeviceSupport driver reports fixed
64-bit granularity for the BAR.

Now, the very last sub-condition is always satisfied by OVMF, since
commit . However,
that is not sufficient -- if the BAR is a Virtual Function BAR, then the
degradation happens regardless.

This behavior seems to cause the following problem
:

An Intel 82576 SR-IOV Physical Function is assigned (with VFIO) to a
QEMU/KVM virtual machine running OVMF. PciBusDxe parses the resources of
the device correctly, apparently:

> PciBus: Discovered PCI @ [07|00|00]
>  ARI: forwarding enabled for PPB[05:01:00]
>  ARI: CapOffset = 0x150
>  SR-IOV: SupportedPageSize = 0x553; SystemPageSize = 0x1; FirstVFOffset = 
> 0x180;
>  InitialVFs = 0x8; ReservedBusNum = 0x2; CapOffset = 0x160
>BAR[0]: Type =  Mem32; Alignment = 0x1;Length = 0x2;   
> Offset = 0x10
>BAR[1]: Type =  Mem32; Alignment = 0x3F;   Length = 0x40;  
> Offset = 0x14
>BAR[2]: Type =   Io32; Alignment = 0x1F;   Length = 0x20;  Offset = 0x18
>BAR[3]: Type =  Mem32; Alignment = 0x3FFF; Length = 0x4000;Offset 
> = 0x1C
>  VFBAR[0]: Type =  Mem64; Alignment = 0xEF49; Length = 0xEF4A;
> Offset = 0x184
>  VFBAR[2]: Type =  Mem64; Alignment = 0xEF47; Length = 0xEF48;
> Offset = 0x190
>
> PCI-IOV ScanBus - SubBusNumber - 0x9

Notice that the VFBARs have Type=Mem64.

However, by the time the resources are submitted to PciHostBridgeDxe, we
get:

> PciHostBridge: SubmitResources for PciRoot(0x0)
>  I/O: Granularity/SpecificFlag = 0 / 01
>   Length/Alignment = 0x3000 / 0xFFF
>  Mem: Granularity/SpecificFlag = 32 / 00
>   Length/Alignment = 0x1E820 / 0xEF49
> PciBus: HostBridge->SubmitResources() - Invalid Parameter
>
> ASSERT_EFI_ERROR (Status = Invalid Parameter)
> ASSERT 
> /builddir/build/BUILD/ovmf-988715a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c(561):
>  !EFI_ERROR (Status)

The cumulative MMIO resources for the root bridge have size 0x1E820
(which is larger than 4GB), but the granularity (= address space
restriction) is 32. This cannot be satisfied, hence PciHostBridgeDxe
returns EFI_INVALID_PARAMETER, in the SubmitResources() function
[MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c]:

> switch (Descriptor->ResType) {
> case ACPI_ADDRESS_SPACE_TYPE_MEM:
>   if (Descriptor->AddrSpaceGranularity != 32 && 
> Descriptor->AddrSpaceGranularity != 64) {
> return EFI_INVALID_PARAMETER;
>   }
>   if (Descriptor->AddrSpaceGranularity == 32 && Descriptor->AddrLen 
> >= SIZE_4GB) {
> return EFI_INVALID_PARAMETER;
>   }

Now, the Alignment and the Length values look very strange for the
VFBARs, but from the SR-IOV spec it seems that those values have special
meaning. So I guess *that* part of PciBusDxe is actually correct.

I just don't understand why (oprom + VFBAR) implies degradation. Can you
please enlighten us?

Without the degradation, OVMF would actually provide enough room for the
64-bit MMIO BARs:

> RootBridge: PciRoot(0x0)
>   Support/Attr: 70069 / 70069
> DmaAbove4G: No
> NoExtConfSpace: No
>  AllocAttr: 3 (CombineMemPMem Mem64Decode)
>Bus: 0 - FF
> Io: 6000 - 
>Mem: 9000 - FBFF
> MemAbove4G: 8 - F
>   PMem:  - 0
>PMemAbove4G:  - 0
> PciHostBridgeDxe: IntersectMemoryDescriptor: add [8, 10): 
> Success

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

Re: [edk2] 32-bit MMIO degradation for VFBARs -- why?

2016-06-17 Thread Laszlo Ersek

On 06/17/16 21:19, Laszlo Ersek wrote:

> This behavior seems to cause the following problem
> :
> 
> An Intel 82576 SR-IOV Physical Function is assigned (with VFIO) to a
> QEMU/KVM virtual machine running OVMF. PciBusDxe parses the resources of
> the device correctly, apparently:
> 
>> PciBus: Discovered PCI @ [07|00|00]
>>  ARI: forwarding enabled for PPB[05:01:00]
>>  ARI: CapOffset = 0x150
>>  SR-IOV: SupportedPageSize = 0x553; SystemPageSize = 0x1; FirstVFOffset = 
>> 0x180;
>>  InitialVFs = 0x8; ReservedBusNum = 0x2; CapOffset = 0x160
>>BAR[0]: Type =  Mem32; Alignment = 0x1;   Length = 0x2;   
>> Offset = 0x10
>>BAR[1]: Type =  Mem32; Alignment = 0x3F;  Length = 0x40;  
>> Offset = 0x14
>>BAR[2]: Type =   Io32; Alignment = 0x1F;  Length = 0x20;  Offset = 0x18
>>BAR[3]: Type =  Mem32; Alignment = 0x3FFF;Length = 0x4000;
>> Offset = 0x1C
>>  VFBAR[0]: Type =  Mem64; Alignment = 0xEF49;Length = 0xEF4A;
>> Offset = 0x184
>>  VFBAR[2]: Type =  Mem64; Alignment = 0xEF47;Length = 0xEF48;
>> Offset = 0x190
>>
>> PCI-IOV ScanBus - SubBusNumber - 0x9
> 
> Notice that the VFBARs have Type=Mem64.
> 
> However, by the time the resources are submitted to PciHostBridgeDxe, we
> get:
> 
>> PciHostBridge: SubmitResources for PciRoot(0x0)
>>  I/O: Granularity/SpecificFlag = 0 / 01
>>   Length/Alignment = 0x3000 / 0xFFF
>>  Mem: Granularity/SpecificFlag = 32 / 00
>>   Length/Alignment = 0x1E820 / 0xEF49
>> PciBus: HostBridge->SubmitResources() - Invalid Parameter
>>
>> ASSERT_EFI_ERROR (Status = Invalid Parameter)
>> ASSERT 
>> /builddir/build/BUILD/ovmf-988715a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c(561):
>>  !EFI_ERROR (Status)
> 
> The cumulative MMIO resources for the root bridge have size 0x1E820
> (which is larger than 4GB), but the granularity (= address space
> restriction) is 32. This cannot be satisfied, hence PciHostBridgeDxe
> returns EFI_INVALID_PARAMETER, in the SubmitResources() function
> [MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c]:
> 
>> switch (Descriptor->ResType) {
>> case ACPI_ADDRESS_SPACE_TYPE_MEM:
>>   if (Descriptor->AddrSpaceGranularity != 32 && 
>> Descriptor->AddrSpaceGranularity != 64) {
>> return EFI_INVALID_PARAMETER;
>>   }
>>   if (Descriptor->AddrSpaceGranularity == 32 && Descriptor->AddrLen 
>> >= SIZE_4GB) {
>> return EFI_INVALID_PARAMETER;
>>   }
> 
> Now, the Alignment and the Length values look very strange for the
> VFBARs, but from the SR-IOV spec it seems that those values have special
> meaning. So I guess *that* part of PciBusDxe is actually correct.

I could be wrong about that -- in
, Alex just
commented:

> Laszlo, note that 82576 has very modest MMIO requirements for the
> MMIO space, this is typically the "works anywhere" SR-IOV device
> because it requires <= 2MB of MMIO space, which is the minimum bridge
> granularity.  If we're coming up with needing more than 4G, it's
> probably because the read-only SR-IOV capability is being
> misinterpreted, ie. no sanity checks on the sizing.

And earlier Alex wrote (but I forgot to quote him),

> NB, vfio exposes the SR-IOV capability as read-only, in case that's
> confusing OVMF, but it would seem unusual for OVMF to blindly attempt
> to enable SR-IOV.

So maybe even the VFBAR parsing is not correct in PciBusDxe -- I don't know.

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

[edk2] Guidelines in Patching

2016-06-17 Thread Fagner Nascimento

Guys,

Me and the team that I'm working with needed to change a dxe lib in order
to comunicate with a device. I've already exchanged messages with David
(david.wei) and Sara (mang.guo), and they advised me to send the patch here.

But I wanted to know if there are any guidelines on posting patches to
Edk2-platforms, to avoid flooding in this list regarding to wrong
submitions. Is there a specific revision where should we diff from? Are
unit Tests necessary in order to submit?

I'm sorry if this is not the appropriate medium to ask this question, but I
couldn't find it in Minnowboard's wiki.

Thanks in advance,

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

Re: [edk2] [PATCH 0/2] Update UNIXGCC toolchain and make it work again

2016-06-17 Thread Laszlo Ersek

On 06/16/16 19:14, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Jordan Justen had to 
> walk into mine at 09:37:31 on Thursday 16 June 2016 and say:
> 
>> On 2016-06-16 09:19:41, Bill Paul wrote:
>>> Of all the gin joints in all the towns in all the world, Jordan Justen
>>> had to
>>>
>>> walk into mine at 18:11:27 on Wednesday 15 June 2016 and say:
 Can you use git send-email rather than KMail to send your patches, so
 they will be threaded?
>>>
>>> You know, I spent about 10 minutes looking over my patches trying to
>>> think of there was *anything* I'd forgotten to do that someone might
>>> nitpick me over and for once I thought I'd gotten everything right. I
>>> guess should have known better.
>>>
>>> No, actually, I can't use git send-email. I only have one machine that's
>>> setup to send e-mail and it's not the one I used for development.
>>
>> Yeah. I've had a similar situation with some temp dev machines. Two
>> things that I've used in the past are:
>>
>> 1. Push the branch to a personal git repo. Fetch it on the machine
>>that can send email. Generate and send the patches.
>>
>> 2. Generate the patches, and copy them to a machine that can send the
>>patches. Use git send-email to send the patches.
> 
> That's fine, but are you saying I have to do one of these thing right now in 
> order to get these patches accepted?

Assuming you would like me to *find* your patches, it would not hurt :)

Yesterday I was out of the office unexpectedly -- for one day. When I
downloaded my emails today, I was greeted by 85 (eighty five) emails
just in my INBOX (needing my personal attention). It took me more than
eight hours to wade through them, handling each one to its merit -- some
quickly, some very carefully.

After eight hours, I've now reached my edk2-devel folder, with ~40
unread messages. At the top, there is your message, with subject

[edk2] [PATCH 0/2] Update UNIXGCC toolchain and make it work again

Given that neither your blurb subject says OvmfPkg, nor was I CC'd as
OvmfPkg co-maintainer, in general I would have blissfully slid over your
email. However, in Thunderbird's threaded view, I noticed that Jordan
responded, which made me slightly curious, and I started reading your
email. That's when I found the OVMF mention at the bottom, and saw the
OvmfPkg/ paths in the diffstat.

And then you expect me to hunt down your un-threaded patches, scattered
all over my (obviously) threaded edk2-devel folder. Are you serious? :)

If you follow the rules, you waste a little bit of your time, and save
the maintainers time. If you ignore the rules, you save time for
yourself, and waste the maintainers' time. There are more contributors
than maintainers. Please do the math.

Laszlo

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

Re: [edk2] [PATCH v2 0/2] ShellPkg: Use ".." to indicate device path is partially displayed

2016-06-17 Thread Laszlo Ersek

On 06/16/16 05:20, Ruiyu Ni wrote:
> The output of "dh " originally is like below:
> 12C: USBIO DevicePath(x0)/Pci(0x14,0x0)/USB(0x6,0x0))
> 
> The device path part is very confusing. Use ".." in front of the
> partially displayed device path is better and it also aligns to
> the example output in Shell spec.
> 12C: USBIO DevicePath(..)/Pci(0x14,0x0)/USB(0x6,0x0))
> 
> Ruiyu Ni (2):
>   ShellPkg: Use ".." to indicate device path is partially displayed
>   ShellPkg/UefiHandleParsingLib.c: Unify EOL and remove trailing space
> 
>  .../UefiHandleParsingLib/UefiHandleParsingLib.c| 361 
> ++---
>  1 file changed, 177 insertions(+), 184 deletions(-)
> 

Assuming this patch is not committed yet: please consider "..."
(triple-dot) instead of ".." (dot-dot). The latter has confusing
connotations with "parent directory". As far as I'm concerned, this
could be done on commit too, if Jaben doesn't mind.

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

Re: [edk2] [PATCH v2 0/2] ShellPkg: Use ".." to indicate device path is partially displayed

2016-06-17 Thread Carsey, Jaben


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, June 17, 2016 2:22 PM
> To: Ni, Ruiyu ; edk2-de...@ml01.01.org
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] [PATCH v2 0/2] ShellPkg: Use ".." to indicate device path
> is partially displayed
> Importance: High
> 
> On 06/16/16 05:20, Ruiyu Ni wrote:
> > The output of "dh " originally is like below:
> > 12C: USBIO DevicePath(x0)/Pci(0x14,0x0)/USB(0x6,0x0))
> >
> > The device path part is very confusing. Use ".." in front of the
> > partially displayed device path is better and it also aligns to
> > the example output in Shell spec.
> > 12C: USBIO DevicePath(..)/Pci(0x14,0x0)/USB(0x6,0x0))
> >
> > Ruiyu Ni (2):
> >   ShellPkg: Use ".." to indicate device path is partially displayed
> >   ShellPkg/UefiHandleParsingLib.c: Unify EOL and remove trailing space
> >
> >  .../UefiHandleParsingLib/UefiHandleParsingLib.c| 361 ++---
> 
> >  1 file changed, 177 insertions(+), 184 deletions(-)
> >
> 
> Assuming this patch is not committed yet: please consider "..."
> (triple-dot) instead of ".." (dot-dot). The latter has confusing
> connotations with "parent directory". As far as I'm concerned, this
> could be done on commit too, if Jaben doesn't mind.

The devicepath is not really a file path, but I could see that some people 
would be confused.  I think changing on this same commit is also fine.

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

Re: [edk2] [Patch 000/351] Convert EDK II core packages to NASM for IA32/X64

2016-06-17 Thread Laszlo Ersek

On 06/16/16 03:46, Liming Gao wrote:
> These patches are available in https://github.com/lgao4/edk2.git nasm-v1. 
> The nasm-v1 branch sha1 is 42bec457c575b6cb7c9fc1730cbea263ffce7b1c
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> Signed-off-by: Jordan Justen 
> 
> These patches base on previous patches in 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10977. 
> New changes in these patches includes: 
> 1. Keep ASM, GAS and NASM all. User can configure BUILDRULEORDER to specify 
>which one will be used. 

The current catch-all rule seems to be

Conf/tools_def.template:*_*_*_*_BUILDRULEORDER = nasm asm Asm ASM S s

I guess that should continue working for me, right?

> 2. Add NASM in new modules from UefiCpuPkg, IntelFsp2Pkg and 
> IntelFsp2WrapperPkg.
> 3. Use 16bit and 32bit assembly code to replace hard code db.

This last step looks pretty error prone -- was this automated, or
converted manually?

> The done test includes:
> 1. Verify the output obj file from ASM and NASM to make sure the output obj
>have the same disassembly code. 

OTOH, binary comparison should make it pretty safe.

> 2. Verify OvmfIa32X64 boot to Shell on VS2015x86. 
> 3. Verify OVMF X64 when booting to arch linux, and with S3 suspend/resume.
> 
> These patches convert these package to use NASM for IA32 & X64
> * MdePkg
> * MdeModulePkg
> * IntelFrameworkModulePkg
> * UefiCpuPkg
> * SourceLevelDebugPkg
> * PcAtChipsetPkg
> * IntelFsp2Pkg
> * IntelFsp2WrapperPkg
> 
> Package maintainers: Could you help review and verify your package? If you 
> find
> any issues, please let us know. 

I'm adding this to my TODO list. Hopefully I can play a little with this
next week.

Just to make sure, the above BUILDRULEORDER should ensure that the new
NASM files will be utilized in my build, right?

> Notes: these patches will cause NASM compiler to be required for all IA32 and 
> X64
> toolchains with the default tool configuration. 
> NASM compiler can be downloaded from http://www.nasm.us/
> After download it, please configure NASM_PREFIX env to point to its directory.
> For example, I place nasm.exe in C:\nasm directory, then set 
> NASM_PREFIX=C:\nasm\

(I think this advice is Windows-specific; for me the "nasm" binary is
simply on PATH -- /usr/bin/nasm.)

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

Re: [edk2] [patch 0/2] Connect all devices in UiApp if needed

2016-06-17 Thread Laszlo Ersek

On 06/16/16 03:37, Dandan Bi wrote:
> Do the connect all action in UiApp if needed,
> and no need to do the connect action in other UI library.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> Reviewed-by: Eric Dong 
> 
> Dandan Bi (2):
>   MdeModulePkg/UiApp: Connect all devices in UiApp if needed
>   MdeModulePkg/BootManagerUiLib: No need to connect all devices
> 
>  MdeModulePkg/Application/UiApp/FrontPage.c  | 6 +++---
>  MdeModulePkg/Application/UiApp/FrontPage.h  | 3 +--
>  MdeModulePkg/Library/BootManagerUiLib/BootManager.c | 7 ++-
>  3 files changed, 6 insertions(+), 10 deletions(-)
> 

Is this a performance improvement primarily?

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

Re: [edk2] [PATCH 0/2] Update UNIXGCC toolchain and make it work again

2016-06-17 Thread Laszlo Ersek

On 06/17/16 23:18, Laszlo Ersek wrote:

> After eight hours, I've now reached my edk2-devel folder, with ~40
> unread messages.

Haha, that was incorrect, after the next refresh, I saw ~50 more
messages in there.

Among those, I've found new messages in this very thread, so I'm no
longer suggesting that the patches be reposted with correct threading.
But, for the future, it would be appreciated.

Thanks
Laszlo

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

Re: [edk2] Guidelines in Patching

2016-06-17 Thread Laszlo Ersek

On 06/17/16 21:57, Fagner Nascimento wrote:
> Guys,
> 
> Me and the team that I'm working with needed to change a dxe lib in order
> to comunicate with a device. I've already exchanged messages with David
> (david.wei) and Sara (mang.guo), and they advised me to send the patch here.
> 
> But I wanted to know if there are any guidelines on posting patches to
> Edk2-platforms, to avoid flooding in this list regarding to wrong
> submitions. Is there a specific revision where should we diff from? Are
> unit Tests necessary in order to submit?
> 
> I'm sorry if this is not the appropriate medium to ask this question, but I
> couldn't find it in Minnowboard's wiki.

As far as I remember, the edk2-platforms proposal is under work between
Mike, Liming, and Leif, and perhaps others (I apologize for failing to
recall further names!)

http://thread.gmane.org/gmane.comp.bios.edk2.devel/11624

Until it concludes, I believe it's best to write your patch against the
current edk2 master branch, and post it to this list.

The official development process is described here:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

My personal preferences / recommendations are documented here, in
excruciating detail:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

Unit tests are not a requirement ATM, but asking others to test your
patches is useful, and "Tested-by:" replies from others are definitely
welcome.

Thanks
Laszlo

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

Re: [edk2] [Announcement] Tianocore Community Leadership

2016-06-17 Thread Laszlo Ersek

On 06/15/16 21:59, Mangefeste, Tony wrote:
> Dear Community,
> 
> I want to take this opportunity to announce that I will be stepping
> aside as the Tianocore Community Manager.

Thank you very much for your work, Tony!

> Michael Kinney, one of our
> stewards, is taking on the role.  Nothing changes, all the
> initiatives move forward.  And we have a gentlemen you will soon
> meet, Neil, who will drive Bugzilla to completion!  I wish you all
> the best, and don't be surprised if I resurface in this community in
> the coming months, with a different company.
> 
> If you have any questions or concerns, do not hesitate to contact one
> of the stewards (Michael, Leif, or Andrew).
> 
> Best Wishes, and see you soon...

So be it :)

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

[edk2] [RFC V3] Proposal to organize packages into directories

2016-06-17 Thread Kinney, Michael D

Hello,



I have looked through all the feedback from the mail threads below

and updated this RFC to V3.



  http://thread.gmane.org/gmane.comp.bios.edk2.devel/12364

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/12754





Please let me know if I missed any feedback and if there is new

feedback on this revised proposal for the directory structure or the

directory names.



I have setup a branch with this directory structure in this proposal to help

with the review.  I have verified that I can build some platforms in this

branch using the PACKAGES_PATH settings shown below.



https://github.com/mdkinney/edk2/tree/NewDirStruct_V3





==

Updates in V3:

==

* IntelFspPkg   -> Silicon/Intel

* IntelFspWrapperPkg-> Silicon/Intel

* IntelFsp2Pkg  -> Silicon/Intel

* IntelFsp2WrapperPkg   -> Silicon/Intel

* CorebootModulePkg -> Driver

* EmulatorPkg   -> Platform/Common

* Nt32Pkg   -> Platform/Common

   Merge into EmulatorPkg in future

* UnixPkg   -> Deprecated

   Next step is a request to delete

* BeagleBoardPkg-> Platform/BeagleBoard

* Omap35xxPkg   -> Silicon/TexasInstruments

* IntelSiliconPkg   -> Silicon/Intel

==



==

Updates in V2:

==

* IntelFrameworkModulePkg   -> Deprecated

* IntelFrameworkPkg -> Deprecated

* IntelFspPkg   -> Deprecated

* IntelFspWrapperPkg-> Deprecated

* PerformancePkg-> Deprecated

* CorebootPayloadPkg-> Platform

* EmbeddedPkg   -> Driver

* ArmPlatformPkg/ArmJunoPkg -> Silicon/Arm/ArmJunoPkg

* ArmPlatformPkg/ArmVExpressPkg -> Silicon/Arm/ ArmVExpressPkg

* Change Drivers to Driver so no top level directories are plural.

* Remove Vendor directory from Silicon and Platform to reduce directory depth

* Add Platform/Common directory for non-vendor specific platform packages

* Add Silicon/Common directory for non-vendor specific packages of

  CPU/Chipset/SoC drivers

* Keep Vendor directory in Driver.

  Non-vendor specific packages of drivers are flat just below Driver.

  Provides area to migrate non-vendor specific drivers from Core over time

==







# EDK II - Proposal to organize packages into directories



There have been some discussions about organizing packages into directories.

Below is a proposal for a top level directory structure and a mapping of the

packages from edk2/master.  Where applicable, vendor specific directories

can be added.



The PACKAGES_PATH feature documented in the link below is used to support

this proposed directory structure with no source file changes.  An example

of setting PACKAGES_PATH in a windows environment is also shown below and

I have verified that platforms can be built using this proposal.



https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace



# Top Level Directory Structure (Listed Alphabetically)

```

edk2

  Application Applications and application support libraries

  BaseTools   EDK II build tools/scripts

  ConfEDK II build configuration files

  CorePlatform agnostic packages for core FW services

  Deprecated  Packages that may be removed from edk2/master

  Driver  EDK II Drivers (no platform assumptions)

Non-Vendor specific EDK II drivers

Non-Vendor specific EDK II drivers

. . .

VendorVendor specific EDK II drivers

  

  

  PlatformPlatforms used to validate edk2/master features

Arm   ARM specific platform packages

BeagleBoard   Beagle Board specific platform packages

CommonNon-vendor specific platform packages

Intel Intel specific platform packages

  specific platform packages

  specific platform packages

  Silicon CPU/Chipset/SoC packages

Arm   Arm specific CPU/Chipset/SoC drivers

CommonNon-vendor specific CPU/Chipset/SoC drivers

Intel Intel specific CPU/Chipset/SoC drivers

TexasInstruments  Texas Instruments specific

  specific CPU/Chipset/SoC drivers

  specific CPU/Chipset/SoC drivers

```



# Mapping packages from edk2/master into proposed directory structure

```

edk2

  Application

AppPkg

ShellPkg

StdLib

StdLibPrivateInternalFiles

  Core

CryptoPkg

IntelFsp2Pkg

IntelFsp2WrapperPkg

MdeModulePkg

MdePkg

SecurityPkg

SourceLevelDebugPkg

  Deprecated

EdkCompatibilityPkg

EdkShellBinPkg

EdkShellPkg

FatBinPkg

IntelFrameworkModulePkg

IntelFrameworkPkg

IntelFspPkg

Intel

Re: [edk2] [PATCH 0/2] Update UNIXGCC toolchain and make it work again

2016-06-17 Thread Bill Paul

Of all the gin joints in all the towns in all the world, Laszlo Ersek had to 
walk into mine at 15:03:16 on Friday 17 June 2016 and say:

> On 06/17/16 23:18, Laszlo Ersek wrote:
> > After eight hours, I've now reached my edk2-devel folder, with ~40
> > unread messages.
> 
> Haha, that was incorrect, after the next refresh, I saw ~50 more
> messages in there.
> 
> Among those, I've found new messages in this very thread, so I'm no
> longer suggesting that the patches be reposted with correct threading.
> But, for the future, it would be appreciated.

Fair enough.

However I'm still concerned about whether or not they'll actually be accepted. 
If there are issues with their technical validity I'd be happy to rework them. 
I'm mainly concerned about the method used to select the appropriate section 
alignment flags in the OVMF .dsc files. I believe it to be functionally 
correct, but maybe there is a better way.

-Bill

> Thanks
> Laszlo

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC V3.1] Proposal to organize packages into directories

2016-06-17 Thread Kinney, Michael D

Hello,



Please review this one.  I missed a few updates to the dir changes

in edk2/master near the bottom.







I have looked through all the feedback from the mail threads below

and updated this RFC to V3.



  http://thread.gmane.org/gmane.comp.bios.edk2.devel/12364

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/12754





Please let me know if I missed any feedback and if there is new

feedback on this revised proposal for the directory structure or the

directory names.



I have setup a branch with this directory structure in this proposal to help

with the review.  I have verified that I can build some platforms in this

branch using the PACKAGES_PATH settings shown below.



https://github.com/mdkinney/edk2/tree/NewDirStruct_V3





==

Updates in V3:

==

* IntelFspPkg   -> Silicon/Intel

* IntelFspWrapperPkg-> Silicon/Intel

* IntelFsp2Pkg  -> Silicon/Intel

* IntelFsp2WrapperPkg   -> Silicon/Intel

* CorebootModulePkg -> Driver

* EmulatorPkg   -> Platform/Common

* Nt32Pkg   -> Platform/Common

   Merge into EmulatorPkg in future

* UnixPkg   -> Deprecated

   Next step is a request to delete

* BeagleBoardPkg-> Platform/BeagleBoard

* Omap35xxPkg   -> Silicon/TexasInstruments

* IntelSiliconPkg   -> Silicon/Intel

==



==

Updates in V2:

==

* IntelFrameworkModulePkg   -> Deprecated

* IntelFrameworkPkg -> Deprecated

* IntelFspPkg   -> Deprecated

* IntelFspWrapperPkg-> Deprecated

* PerformancePkg-> Deprecated

* CorebootPayloadPkg-> Platform

* EmbeddedPkg   -> Driver

* ArmPlatformPkg/ArmJunoPkg -> Silicon/Arm/ArmJunoPkg

* ArmPlatformPkg/ArmVExpressPkg -> Silicon/Arm/ ArmVExpressPkg

* Change Drivers to Driver so no top level directories are plural.

* Remove Vendor directory from Silicon and Platform to reduce directory depth

* Add Platform/Common directory for non-vendor specific platform packages

* Add Silicon/Common directory for non-vendor specific packages of

  CPU/Chipset/SoC drivers

* Keep Vendor directory in Driver.

  Non-vendor specific packages of drivers are flat just below Driver.

  Provides area to migrate non-vendor specific drivers from Core over time

==







# EDK II - Proposal to organize packages into directories



There have been some discussions about organizing packages into directories.

Below is a proposal for a top level directory structure and a mapping of the

packages from edk2/master.  Where applicable, vendor specific directories

can be added.



The PACKAGES_PATH feature documented in the link below is used to support

this proposed directory structure with no source file changes.  An example

of setting PACKAGES_PATH in a windows environment is also shown below and

I have verified that platforms can be built using this proposal.



https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace



# Top Level Directory Structure (Listed Alphabetically)

```

edk2

  Application Applications and application support libraries

  BaseTools   EDK II build tools/scripts

  ConfEDK II build configuration files

  CorePlatform agnostic packages for core FW services

  Deprecated  Packages that may be removed from edk2/master

  Driver  EDK II Drivers (no platform assumptions)

Non-Vendor specific EDK II drivers

Non-Vendor specific EDK II drivers

. . .

VendorVendor specific EDK II drivers

  

  

  PlatformPlatforms used to validate edk2/master features

Arm   ARM specific platform packages

BeagleBoard   Beagle Board specific platform packages

CommonNon-vendor specific platform packages

Intel Intel specific platform packages

  specific platform packages

  specific platform packages

  Silicon CPU/Chipset/SoC packages

Arm   Arm specific CPU/Chipset/SoC drivers

CommonNon-vendor specific CPU/Chipset/SoC drivers

Intel Intel specific CPU/Chipset/SoC drivers

TexasInstruments  Texas Instruments specific

  specific CPU/Chipset/SoC drivers

  specific CPU/Chipset/SoC drivers

```



# Mapping packages from edk2/master into proposed directory structure

```

edk2

  Application

AppPkg

ShellPkg

StdLib

StdLibPrivateInternalFiles

  Core

CryptoPkg

MdeModulePkg

MdePkg

SecurityPkg

SourceLevelDebugPkg

  Deprecated

EdkCompatibilityPkg

EdkShellBinPkg

EdkShellPkg

FatBinPkg

IntelFrame

Re: [edk2] [RFC V2] Proposal to organize packages into directories

2016-06-17 Thread Mudusuru, Giri P

Thanks Mike. My preference is Silicon as it is generic and represents broadly 
CPU/Memory/Chipset/SoC etc...

Thanks,
-Giri

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Friday, June 17, 2016 10:50 AM
> To: Justen, Jordan L ; edk2-devel@lists.01.org;
> Kinney, Michael D 
> Subject: Re: [edk2] [RFC V2] Proposal to organize packages into directories
> 
> Hi Jordan,
> 
> Yes.  Many terms were considered other than Silicon, except Carbon :)
> 
> None of the terms we have considered are a perfect match.
> 
> We are wanting to keep modules for controllers attached to I/O subsystems
> and modules for peripherals separate from modules that perform basic
> CPU/Memory/Chipset/SoC init.
> 
> Is there any preference on the list between Silicon, Chip, or Device
> or other names for basic CPU/Memory/Chipset/SoC init?
> 
> Thanks,
> 
> Mike
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jordan Justen
> > Sent: Wednesday, June 1, 2016 1:07 PM
> > To: Kinney, Michael D ; edk2-
> de...@lists.01.org; Kinney,
> > Michael D 
> > Subject: Re: [edk2] [RFC V2] Proposal to organize packages into directories
> >
> > On 2016-05-25 19:03:38, Kinney, Michael D wrote:
> > > # Top Level Directory Structure (Listed Alphabetically)
> > > ```
> > > edk2
> > >   Application   Applications and application support libraries
> > >   BaseTools EDK II build tools/scripts
> > >   Conf  EDK II build configuration files
> > >   Core  Platform agnostic packages for core FW services
> > >   DeprecatedPackages that will be removed from edk2/master soon
> > >   DriverEDK II Drivers (no platform assumptions)
> > >   Non-Vendor specific EDK II drivers
> > >   Non-Vendor specific EDK II drivers
> > > . . .
> > > Vendor  Vendor specific EDK II drivers
> > >   
> > >   
> > >   Platform  Platforms used to validate edk2/master features
> > > Common  Non-vendor specific platform packages
> > > EmulatedNon-vendor specific emulated platform packages
> > > Arm ARM specific platform packages
> > > Intel   Intel specific platform packages
> > > specific platform packages
> > > specific platform packages
> > >   Silicon   CPU/Chipset/SoC packages
> >
> > Were any other terms considered? Chip, Device?
> >
> > Carbon? ;)
> >
> > -Jordan
> >
> > > Common  Non-vendor specific CPU/Chipset/SoC drivers
> > > Arm Arm specific CPU/Chipset/SoC drivers
> > > Intel   Intel specific CPU/Chipset/SoC drivers
> > > specific CPU/Chipset/SoC drivers
> > > specific CPU/Chipset/SoC drivers
> > > ```
> > >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib

2016-06-17 Thread Zeng, Star

Reviewed-by: Star Zeng  to MdeModulePkg change.

Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Thursday, June 16, 2016 6:29 PM
To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com
Cc: mark.rutl...@arm.com; heyi@linaro.org; Tian, Feng 
; Zeng, Star ; Ard Biesheuvel 

Subject: [PATCH 3/4] ArmPkg ArmVirtPkg MdeModulePkg: switch to separate 
ArmMmuLib

Switch all users of ArmLib that depend on the MMU routines to the new,
separate ArmMmuLib. This needs to occur in one go, since the MMU
routines are removed from ArmLib build at the same time, to prevent
conflicting symbols.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Drivers/CpuDxe/CpuDxe.inf   |   1 +
 ArmPkg/Include/Library/ArmLib.h|  38 -
 ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c  |  36 -
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   |   3 -
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  |   1 -
 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 751 

 ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S  |   6 -
 ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm|   6 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h |  12 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf   |   1 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf  |   1 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 418 
---
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S |   5 -
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   |   4 -
 ArmVirtPkg/ArmVirtQemu.dsc |   2 +
 ArmVirtPkg/ArmVirtXen.dsc  |   2 +
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   |   1 +
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf |   1 +
 MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c |   1 +
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   1 +
 20 files changed, 9 insertions(+), 1282 deletions(-)

diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
index 21cdf319d45b..b31c994f43e2 100644
--- a/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
+++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.inf
@@ -45,6 +45,7 @@ [Packages]
 
 [LibraryClasses]
   ArmLib
+  ArmMmuLib
   BaseMemoryLib
   CacheMaintenanceLib
   CpuLib
diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
index 4608b0cc..40d97e09b566 100644
--- a/ArmPkg/Include/Library/ArmLib.h
+++ b/ArmPkg/Include/Library/ArmLib.h
@@ -371,14 +371,6 @@ ArmGetTTBR0BaseAddress (
   VOID
   );
 
-RETURN_STATUS
-EFIAPI
-ArmConfigureMmu (
-  IN  ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable,
-  OUT VOID **TranslationTableBase OPTIONAL,
-  OUT UINTN *TranslationTableSize  OPTIONAL
-  );
-
 BOOLEAN
 EFIAPI
 ArmMmuEnabled (
@@ -595,34 +587,4 @@ ArmUnsetCpuActlrBit (
   IN  UINTNBits
   );
 
-RETURN_STATUS
-ArmSetMemoryRegionNoExec (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-RETURN_STATUS
-ArmClearMemoryRegionNoExec (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-RETURN_STATUS
-ArmSetMemoryRegionReadOnly (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-RETURN_STATUS
-ArmClearMemoryRegionReadOnly (
-  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
-  IN  UINT64Length
-  );
-
-VOID
-ArmReplaceLiveTranslationEntry (
-  IN  UINT64  *Entry,
-  IN  UINT64  Value
-  );
-
 #endif // __ARM_LIB__
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
deleted file mode 100644
index d2d0d3c15ee3..
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
+++ /dev/null
@@ -1,36 +0,0 @@
-#/* @file
-#
-#  Copyright (c) 2016, Linaro Limited. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#*/
-
-#include 
-
-#include 
-#include 
-
-RETURN_STATUS
-EFIAPI
-AArch64LibConstructor (
-  VOID
-  )
-{
-  extern UINT32 ArmReplaceLiveTranslationEntrySize;
-
-  //
-

Re: [edk2] [PATCH 0/2] Update UNIXGCC toolchain and make it work again

2016-06-17 Thread Bruce Cran


On 6/17/16 3:18 PM, Laszlo Ersek wrote:


Given that neither your blurb subject says OvmfPkg, nor was I CC'd as
OvmfPkg co-maintainer, in general I would have blissfully slid over your
email. However, in Thunderbird's threaded view, I noticed that Jordan
responded, which made me slightly curious, and I started reading your
email. That's when I found the OVMF mention at the bottom, and saw the
OvmfPkg/ paths in the diffstat.


This is one of the advantages of having a tool which manages reviews - 
the ability to specify people who should automatically be CC'd on review 
requests given a specified path in the source tree :)


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

37 matches

Mail list logo