Re: [edk2] [ edk2-BuildSpecification PATCH] Add support for Private declarations in a package

2017-04-24 Thread Kinney, Michael D
Yonghong,

Thanks.  I have updated #480 with that recommendation.

Mike

> -Original Message-
> From: Zhu, Yonghong
> Sent: Monday, April 24, 2017 7:38 PM
> To: Kinney, Michael D ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Shaw, Kevin W 
> ;
> Zhu, Yonghong 
> Subject: RE: [ edk2-BuildSpecification PATCH] Add support for Private 
> declarations
> in a package
> 
> Yes, I think we should remove it as part of #480. Thanks.
> 
> Best Regards,
> Zhu Yonghong
> 
> 
> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, April 25, 2017 10:36 AM
> To: Zhu, Yonghong ; edk2-devel@lists.01.org; Kinney,
> Michael D 
> Cc: Gao, Liming ; Shaw, Kevin W 
> Subject: RE: [ edk2-BuildSpecification PATCH] Add support for Private 
> declarations
> in a package
> 
> Yonghong,
> 
> The sentence about setting a PCD from the command line is related to
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=480
> 
> #480 Build spec: add description for Override PCD value on the command line
> 
> This will update the Build Specification to add the --pcd command line flag 
> to set
> PCD values.
> 
> Should the following item be removed as part of #480?
> 
> " 5. Command > line cannot be used to set the PCD value."
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Zhu, Yonghong
> > Sent: Monday, April 24, 2017 6:54 PM
> > To: Kinney, Michael D ;
> > edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Shaw, Kevin W
> > ; Zhu, Yonghong 
> > Subject: RE: [ edk2-BuildSpecification PATCH] Add support for Private
> > declarations in a package
> >
> > Hi Mike,
> >
> > This patch is good to me.  Reviewed-by: Yonghong Zhu
> > 
> >
> > while during review this patch, I found one update we wound made for "
> > 5. Command line cannot be used to set the PCD value.". It is not
> > related with this topic, but we can create another patch to update this
> sentence. Thanks.
> >
> > Best Regards,
> > Zhu Yonghong
> >
> >
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Tuesday, April 25, 2017 9:12 AM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Zhu, Yonghong
> > ; Shaw, Kevin W 
> > Subject: [ edk2-BuildSpecification PATCH] Add support for Private
> > declarations in a package
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=465
> >
> > Process new syntax in the DEC file that specifies information that can
> > only be used by modules within the package. When modules outside the
> > packages attempt to use this content, the EDK II build system must
> > break with an error regarding content not found.
> >
> > The four sections, Includes, Ppis, Guids and Protocols headers will be
> > the keyword, Private, following the architecture modifier. If Private
> > is not present, then the content is usable by modules outside the package.
> >
> > Cc: Liming Gao 
> > Cc: Yonghong Zhu 
> > Cc: Kevin W Shaw 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Michael Kinney 
> > ---
> >  .../82_auto-generation_process.md  | 35 
> > ++
> >  .../84_auto-generated_pcd_database_file.md |  6 
> >  README.md  |  3 +-
> >  3 files changed, 30 insertions(+), 14 deletions(-)
> >
> > diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md
> > b/8_pre- build_autogen_stage/82_auto-generation_process.md
> > index 6868d62..22a8b08 100644
> > --- a/8_pre-build_autogen_stage/82_auto-generation_process.md
> > +++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
> > @@ -1034,16 +1034,25 @@ II module:
> >- DSC file's architecture specific modifier only `[LibraryClasses.arch]`
> >- The DSC file's common `[LibraryClasses]` section
> >
> > -**
> > -**Note:** For modules of type **USER_DEFINED**_, if a `NULL` library
> > class -is required, the library instance should be listed in the INF
> > scoping - `` section of the component.
> > -**
> > +  **
> > +  **Note:** For modules of type **USER_DEFINED**_, if a `NULL`
> > + library class  is required, the library instance should be listed in
> > + the INF scoping  `` section of the component.
> > +  **
> >
> >  * Inherit GUIDs, Protocols and PPIs from all library instances obtained 
> > above,
> >and determine values or type of them. The value of a GUID, Protocol or 
> > PPI is
> >defined in DEC file.
> >
> > +  **
> > +  **Note:** If GUID, Protocol or PPI is listed in a DEC file, where
> > + the `Private` 

Re: [edk2] [ edk2-BuildSpecification PATCH] Add support for Private declarations in a package

2017-04-24 Thread Zhu, Yonghong
Yes, I think we should remove it as part of #480. Thanks.

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, April 25, 2017 10:36 AM
To: Zhu, Yonghong ; edk2-devel@lists.01.org; Kinney, 
Michael D 
Cc: Gao, Liming ; Shaw, Kevin W 
Subject: RE: [ edk2-BuildSpecification PATCH] Add support for Private 
declarations in a package

Yonghong,

The sentence about setting a PCD from the command line is related to

https://bugzilla.tianocore.org/show_bug.cgi?id=480

#480 Build spec: add description for Override PCD value on the command line

This will update the Build Specification to add the --pcd command line flag to 
set PCD values. 

Should the following item be removed as part of #480?

" 5. Command > line cannot be used to set the PCD value."

Thanks,

Mike

> -Original Message-
> From: Zhu, Yonghong
> Sent: Monday, April 24, 2017 6:54 PM
> To: Kinney, Michael D ; 
> edk2-devel@lists.01.org
> Cc: Gao, Liming ; Shaw, Kevin W 
> ; Zhu, Yonghong 
> Subject: RE: [ edk2-BuildSpecification PATCH] Add support for Private 
> declarations in a package
> 
> Hi Mike,
> 
> This patch is good to me.  Reviewed-by: Yonghong Zhu 
> 
> 
> while during review this patch, I found one update we wound made for " 
> 5. Command line cannot be used to set the PCD value.". It is not 
> related with this topic, but we can create another patch to update this 
> sentence. Thanks.
> 
> Best Regards,
> Zhu Yonghong
> 
> 
> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, April 25, 2017 9:12 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zhu, Yonghong 
> ; Shaw, Kevin W 
> Subject: [ edk2-BuildSpecification PATCH] Add support for Private 
> declarations in a package
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=465
> 
> Process new syntax in the DEC file that specifies information that can 
> only be used by modules within the package. When modules outside the 
> packages attempt to use this content, the EDK II build system must 
> break with an error regarding content not found.
> 
> The four sections, Includes, Ppis, Guids and Protocols headers will be 
> the keyword, Private, following the architecture modifier. If Private 
> is not present, then the content is usable by modules outside the package.
> 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Cc: Kevin W Shaw 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael Kinney 
> ---
>  .../82_auto-generation_process.md  | 35 
> ++
>  .../84_auto-generated_pcd_database_file.md |  6 
>  README.md  |  3 +-
>  3 files changed, 30 insertions(+), 14 deletions(-)
> 
> diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md 
> b/8_pre- build_autogen_stage/82_auto-generation_process.md
> index 6868d62..22a8b08 100644
> --- a/8_pre-build_autogen_stage/82_auto-generation_process.md
> +++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
> @@ -1034,16 +1034,25 @@ II module:
>- DSC file's architecture specific modifier only `[LibraryClasses.arch]`
>- The DSC file's common `[LibraryClasses]` section
> 
> -**
> -**Note:** For modules of type **USER_DEFINED**_, if a `NULL` library 
> class -is required, the library instance should be listed in the INF 
> scoping - `` section of the component.
> -**
> +  **
> +  **Note:** For modules of type **USER_DEFINED**_, if a `NULL` 
> + library class  is required, the library instance should be listed in 
> + the INF scoping  `` section of the component.
> +  **
> 
>  * Inherit GUIDs, Protocols and PPIs from all library instances obtained 
> above,
>and determine values or type of them. The value of a GUID, Protocol or PPI 
> is
>defined in DEC file.
> 
> +  **
> +  **Note:** If GUID, Protocol or PPI is listed in a DEC file, where 
> + the `Private` modifier is used in the section tag 
> + (`[Guids.common.Private]` for  example), only modules within the 
> + package are permitted to use the GUID,  Protocol or PPI. If a module 
> + or library instance outside of the package  attempts to use the 
> + item, the build must fail with an appropriate error  message.
> +  **
> +
>  * Inherit PCDs from all library instances obtained above and determine values
>and type. The value and type of a PCD are obtained from a DSC file, INF 
> file
>or DEC file if it cannot be found in the DSC or INF file. For each 
> EDK II @@ -
> 1058,14 +1067,14 @@ is required, the library instance should be listed 
> in the INF 

Re: [edk2] [PATCH 0/2] Borrow the space below 1MB for AP reset vector

2017-04-24 Thread Tian, Feng
Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Fan, Jeff 
Sent: Friday, April 21, 2017 2:04 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Kinney, Michael D 

Subject: [PATCH 0/2] Borrow the space below 1MB for AP reset vector

Current, CpuMpPei will find the available memory space below 1MB for AP reset 
vector. And CpuMpPei will build resource HOB on this range to prevent other PEI 
modules to use this range.

However, on some FSP usage model, this range maybe used by the code out of FSP.
CpuMpPei may change the original memory contents and cause other code crash.

We could update CpuMpPei not to change the original contents of this range 
around AP waking up. Thus, it will not impact the other code on FSP usage model.

This updating is tiny and less impact on performance.

https://bugzilla.tianocore.org/show_bug.cgi?id=500

Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 

Jeff Fan (2):
  UefiCpuPkg/MpInitLib: save/restore original contents
  UefiCpuPkg/MpInitLib: needn't to allocate AP reset vector

 UefiCpuPkg/Library/MpInitLib/MpLib.h  |  22 +-
 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf |   6 +-
 UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   | 107 +-
 3 files changed, 5 insertions(+), 130 deletions(-)

--
2.9.3.windows.2

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


Re: [edk2] [ edk2-BuildSpecification PATCH] Add support for Private declarations in a package

2017-04-24 Thread Kinney, Michael D
Yonghong,

The sentence about setting a PCD from the command line is related to

https://bugzilla.tianocore.org/show_bug.cgi?id=480

#480 Build spec: add description for Override PCD value on the command line

This will update the Build Specification to add the --pcd command line
flag to set PCD values. 

Should the following item be removed as part of #480?

" 5. Command > line cannot be used to set the PCD value."

Thanks,

Mike

> -Original Message-
> From: Zhu, Yonghong
> Sent: Monday, April 24, 2017 6:54 PM
> To: Kinney, Michael D ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Shaw, Kevin W 
> ;
> Zhu, Yonghong 
> Subject: RE: [ edk2-BuildSpecification PATCH] Add support for Private 
> declarations
> in a package
> 
> Hi Mike,
> 
> This patch is good to me.  Reviewed-by: Yonghong Zhu 
> 
> while during review this patch, I found one update we wound made for " 5. 
> Command
> line cannot be used to set the PCD value.". It is not related with this 
> topic, but
> we can create another patch to update this sentence. Thanks.
> 
> Best Regards,
> Zhu Yonghong
> 
> 
> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, April 25, 2017 9:12 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zhu, Yonghong 
> ;
> Shaw, Kevin W 
> Subject: [ edk2-BuildSpecification PATCH] Add support for Private 
> declarations in
> a package
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=465
> 
> Process new syntax in the DEC file that specifies information that can only be
> used by modules within the package. When modules outside the packages attempt 
> to
> use this content, the EDK II build system must break with an error regarding
> content not found.
> 
> The four sections, Includes, Ppis, Guids and Protocols headers will be the
> keyword, Private, following the architecture modifier. If Private is not 
> present,
> then the content is usable by modules outside the package.
> 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Cc: Kevin W Shaw 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael Kinney 
> ---
>  .../82_auto-generation_process.md  | 35 
> ++
>  .../84_auto-generated_pcd_database_file.md |  6 
>  README.md  |  3 +-
>  3 files changed, 30 insertions(+), 14 deletions(-)
> 
> diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md b/8_pre-
> build_autogen_stage/82_auto-generation_process.md
> index 6868d62..22a8b08 100644
> --- a/8_pre-build_autogen_stage/82_auto-generation_process.md
> +++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
> @@ -1034,16 +1034,25 @@ II module:
>- DSC file's architecture specific modifier only `[LibraryClasses.arch]`
>- The DSC file's common `[LibraryClasses]` section
> 
> -**
> -**Note:** For modules of type **USER_DEFINED**_, if a `NULL` library class 
> -is
> required, the library instance should be listed in the INF scoping -
> `` section of the component.
> -**
> +  **
> +  **Note:** For modules of type **USER_DEFINED**_, if a `NULL` library
> + class  is required, the library instance should be listed in the INF
> + scoping  `` section of the component.
> +  **
> 
>  * Inherit GUIDs, Protocols and PPIs from all library instances obtained 
> above,
>and determine values or type of them. The value of a GUID, Protocol or PPI 
> is
>defined in DEC file.
> 
> +  **
> +  **Note:** If GUID, Protocol or PPI is listed in a DEC file, where the
> + `Private` modifier is used in the section tag
> + (`[Guids.common.Private]` for  example), only modules within the
> + package are permitted to use the GUID,  Protocol or PPI. If a module
> + or library instance outside of the package  attempts to use the item,
> + the build must fail with an appropriate error  message.
> +  **
> +
>  * Inherit PCDs from all library instances obtained above and determine values
>and type. The value and type of a PCD are obtained from a DSC file, INF 
> file
>or DEC file if it cannot be found in the DSC or INF file. For each EDK II 
> @@ -
> 1058,14 +1067,14 @@ is required, the library instance should be listed in the 
> INF
> scoping
>- The INF file's PCD sections
>- The DEC file's PCD sections
> 
> -**
> -**Note:** Values of PCDs using the FeatureFlag, PatchableInModule and -
> FixedAtBuild access methods set for this INF file are local to the INF file 
> and -
> do not pertain to any other INF files. Dynamic and DynamicEx access method 
> PCD -
> values are global to a platform and should not be overridden by specifying 
> them -
> here. If, however, the dynamic PCDs are 

Re: [edk2] [ edk2-BuildSpecification PATCH] Update build report to support -Y HASH option

2017-04-24 Thread Zhu, Yonghong
Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, April 25, 2017 9:58 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [ edk2-BuildSpecification PATCH] Update build report to support -Y 
HASH option

https://bugzilla.tianocore.org/show_bug.cgi?id=504

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 13_build_reports/131_build_report_generation_options.md   |  4 
 13_build_reports/132_sample_launch_steps_nt32_platform.md | 11 ++-
 13_build_reports/133_output.md|  2 +-
 13_build_reports/138_module_section.md|  4 
 README.md |  1 +
 appendix_d_buildexe_command/d4_usage.md   |  7 ---
 6 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/13_build_reports/131_build_report_generation_options.md 
b/13_build_reports/131_build_report_generation_options.md
index fc32590..05d7eb2 100644
--- a/13_build_reports/131_build_report_generation_options.md
+++ b/13_build_reports/131_build_report_generation_options.md
@@ -61,6 +61,10 @@ notification invoking sequence; Also the predicted addresses 
of module image  loading, entry point and notification functions. Generating 
this report does  take a significant amount of time, more than 2x the standard 
build time.
 
+**_Module Information_**
+
+Details of the module, may include the HASH of the `.efi` file.
+
 **
 **Note:** The execution order prediction report output is an html file,  
separate from the rest of the reports. All remaining reports are generated in a 
diff --git a/13_build_reports/132_sample_launch_steps_nt32_platform.md 
b/13_build_reports/132_sample_launch_steps_nt32_platform.md
index 33ca1bf..099dc07 100644
--- a/13_build_reports/132_sample_launch_steps_nt32_platform.md
+++ b/13_build_reports/132_sample_launch_steps_nt32_platform.md
@@ -42,17 +42,18 @@ command. The following steps output the build report for 
NT32 platform:
 5. Run **build.exe -a IA32 -p Nt32Pkg\Nt32Pkg.dsc -y ReportFile.txt**
   * **-y**: This option specifies the output file name for build report.
   * **-Y**: This option specifies flags that control the type of build report.
-It must be from the set of **PCD**, **LIBRARY**, **DEPEX**, 
**BUILD_FLAGS**,
-**FLASH**, **FIXED_ADDRESS** and **EXECUTION_ORDER**. To specify more than
-one flag, repeat the option on the command line. Example of usage:
+It must be from the set of **PCD**, **LIBRARY**, **DEPEX**, **HASH**,
+**BUILD_FLAGS**, **FLASH**, **FIXED_ADDRESS** and **EXECUTION_ORDER**. To
+specify more than one flag, repeat the option on the command line. Example
+of usage:
 
 On the command line, append the following arguments:
 
 **-y report_filename.txt -Y PCD -Y FLASH -Y DEPEX**
 
 The default set of flags (if **-Y** is not specified) is: **PCD**,
-**LIBRARY**, **FLASH**, **DEPEX**, **BUILD_FLAGS** and **FIXED_ADDRESS**.
-
+**LIBRARY**, **FLASH**, **DEPEX**, **HASH**, **BUILD_FLAGS** and
+**FIXED_ADDRESS**.
 
 [^1] On Microsoft Windows 7, you must be an administrator to create a 
directory  in the root of the C: drive. It recommended that you checkout edk2 
into your diff --git a/13_build_reports/133_output.md 
b/13_build_reports/133_output.md index ce64efd..73afb0c 100644
--- a/13_build_reports/133_output.md
+++ b/13_build_reports/133_output.md
@@ -101,7 +101,7 @@ Target: DEBUG
 Output Path:s:\edk2\Build\NT32IA32
 Build Environment:  Windows-7-6.1.7601-SP1
 Build Duration: 00:01:53
-Report Contents:PCD, LIBRARY, BUILD_FLAGS, DEPEX, FLASH, FIXED_ADDRESS
+Report Contents:PCD, LIBRARY, BUILD_FLAGS, DEPEX, HASH, FLASH, 
FIXED_ADDRESS
 >==<
 Firmware Device (FD)
 FD Name:NT32
diff --git a/13_build_reports/138_module_section.md 
b/13_build_reports/138_module_section.md
index 23e039b..d4aa365 100644
--- a/13_build_reports/138_module_section.md
+++ b/13_build_reports/138_module_section.md
@@ -51,6 +51,8 @@ file GUID, module size, module build time stamp and driver 
type.
 
 The following entries are options:
 
+* If using defaults or the `HASH` flag is specified:
+  - SHA1 HASH: %SHA1 HASH% and *%Module .efi file name%
 * UEFI Specification Version: %The UEFI specification
   version:'`UEFI_SPECIFICATION_VERSION`' in INF `[Defines]` section%
 * PI Specification Version: %The PI specification
@@ -75,6 +77,7 @@ Module Name:SmbiosDxe
 Module INF Path:MdeModule\Universal\SmbiosDxe\SmbiosDxe.inf
 File GUID:  

[edk2] [ edk2-BuildSpecification PATCH] Update build report to support -Y HASH option

2017-04-24 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=504

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 13_build_reports/131_build_report_generation_options.md   |  4 
 13_build_reports/132_sample_launch_steps_nt32_platform.md | 11 ++-
 13_build_reports/133_output.md|  2 +-
 13_build_reports/138_module_section.md|  4 
 README.md |  1 +
 appendix_d_buildexe_command/d4_usage.md   |  7 ---
 6 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/13_build_reports/131_build_report_generation_options.md 
b/13_build_reports/131_build_report_generation_options.md
index fc32590..05d7eb2 100644
--- a/13_build_reports/131_build_report_generation_options.md
+++ b/13_build_reports/131_build_report_generation_options.md
@@ -61,6 +61,10 @@ notification invoking sequence; Also the predicted addresses 
of module image
 loading, entry point and notification functions. Generating this report does
 take a significant amount of time, more than 2x the standard build time.
 
+**_Module Information_**
+
+Details of the module, may include the HASH of the `.efi` file.
+
 **
 **Note:** The execution order prediction report output is an html file,
 separate from the rest of the reports. All remaining reports are generated in a
diff --git a/13_build_reports/132_sample_launch_steps_nt32_platform.md 
b/13_build_reports/132_sample_launch_steps_nt32_platform.md
index 33ca1bf..099dc07 100644
--- a/13_build_reports/132_sample_launch_steps_nt32_platform.md
+++ b/13_build_reports/132_sample_launch_steps_nt32_platform.md
@@ -42,17 +42,18 @@ command. The following steps output the build report for 
NT32 platform:
 5. Run **build.exe -a IA32 -p Nt32Pkg\Nt32Pkg.dsc -y ReportFile.txt**
   * **-y**: This option specifies the output file name for build report.
   * **-Y**: This option specifies flags that control the type of build report.
-It must be from the set of **PCD**, **LIBRARY**, **DEPEX**, 
**BUILD_FLAGS**,
-**FLASH**, **FIXED_ADDRESS** and **EXECUTION_ORDER**. To specify more than
-one flag, repeat the option on the command line. Example of usage:
+It must be from the set of **PCD**, **LIBRARY**, **DEPEX**, **HASH**,
+**BUILD_FLAGS**, **FLASH**, **FIXED_ADDRESS** and **EXECUTION_ORDER**. To
+specify more than one flag, repeat the option on the command line. Example
+of usage:
 
 On the command line, append the following arguments:
 
 **-y report_filename.txt -Y PCD -Y FLASH -Y DEPEX**
 
 The default set of flags (if **-Y** is not specified) is: **PCD**,
-**LIBRARY**, **FLASH**, **DEPEX**, **BUILD_FLAGS** and **FIXED_ADDRESS**.
-
+**LIBRARY**, **FLASH**, **DEPEX**, **HASH**, **BUILD_FLAGS** and
+**FIXED_ADDRESS**.
 
 [^1] On Microsoft Windows 7, you must be an administrator to create a directory
 in the root of the C: drive. It recommended that you checkout edk2 into your
diff --git a/13_build_reports/133_output.md b/13_build_reports/133_output.md
index ce64efd..73afb0c 100644
--- a/13_build_reports/133_output.md
+++ b/13_build_reports/133_output.md
@@ -101,7 +101,7 @@ Target: DEBUG
 Output Path:s:\edk2\Build\NT32IA32
 Build Environment:  Windows-7-6.1.7601-SP1
 Build Duration: 00:01:53
-Report Contents:PCD, LIBRARY, BUILD_FLAGS, DEPEX, FLASH, FIXED_ADDRESS
+Report Contents:PCD, LIBRARY, BUILD_FLAGS, DEPEX, HASH, FLASH, 
FIXED_ADDRESS
 >==<
 Firmware Device (FD)
 FD Name:NT32
diff --git a/13_build_reports/138_module_section.md 
b/13_build_reports/138_module_section.md
index 23e039b..d4aa365 100644
--- a/13_build_reports/138_module_section.md
+++ b/13_build_reports/138_module_section.md
@@ -51,6 +51,8 @@ file GUID, module size, module build time stamp and driver 
type.
 
 The following entries are options:
 
+* If using defaults or the `HASH` flag is specified:
+  - SHA1 HASH: %SHA1 HASH% and *%Module .efi file name%
 * UEFI Specification Version: %The UEFI specification
   version:'`UEFI_SPECIFICATION_VERSION`' in INF `[Defines]` section%
 * PI Specification Version: %The PI specification
@@ -75,6 +77,7 @@ Module Name:SmbiosDxe
 Module INF Path:MdeModule\Universal\SmbiosDxe\SmbiosDxe.inf
 File GUID:  F9D88642-0737-49BC-81B5-6889CD57D9EA
 Size:   0x7000 (28.00K)
+SHA1 HASH:  d94c3f180f25d6b562f477bc4a16b286cb66a8b6 *SmbiosDxe.efi
 Build Time Stamp:   1969-12-31 16:00:00
 Driver Type:0x7 (DRIVER)
 
@@ -91,6 +94,7 @@ Module Name:EbcDxe
 Module INF Path:MdeModule\Universal\EbcDxe\EbcDxe.inf
 File GUID:  

[edk2] [ edk2-BuildSpecification PATCH] Update build report to support -Y HASH option

2017-04-24 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=504

GitHub branch for review:

* 
https://github.com/mdkinney/edk2-BuildSpecification/tree/Bugzilla_504_AddBuildReportHashFlag

GitHub word diff view of the patches in this series:

* 
https://github.com/mdkinney/edk2-BuildSpecification/commit/20ff478363aa89be7adcf64fd0ba08615354c42b?w=1

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Update build report to support -Y HASH option

 13_build_reports/131_build_report_generation_options.md   |  4 
 13_build_reports/132_sample_launch_steps_nt32_platform.md | 11 ++-
 13_build_reports/133_output.md|  2 +-
 13_build_reports/138_module_section.md|  4 
 README.md |  1 +
 appendix_d_buildexe_command/d4_usage.md   |  7 ---
 6 files changed, 20 insertions(+), 9 deletions(-)

-- 
2.6.3.windows.1

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


Re: [edk2] [PATCH] PeCoffGetEntryPointLib: Fix spelling issue

2017-04-24 Thread Gao, Liming
Reviewed-by: Liming Gao 

>-Original Message-
>From: Fan, Jeff
>Sent: Monday, April 24, 2017 10:29 AM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming ; Tian, Feng ;
>Kinney, Michael D 
>Subject: [PATCH] PeCoffGetEntryPointLib: Fix spelling issue
>
>*Serach* should be *Search*
>
>Cc: Liming Gao 
>Cc: Feng Tian 
>Cc: Michael Kinney 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Jeff Fan 
>---
> MdePkg/Include/Library/PeCoffGetEntryPointLib.h  | 2 +-
> MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c  | 2
>+-
>
>SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAge
>nt.c | 2 +-
> UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c   | 2
>+-
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/MdePkg/Include/Library/PeCoffGetEntryPointLib.h
>b/MdePkg/Include/Library/PeCoffGetEntryPointLib.h
>index 647503b..f211cf5 100644
>--- a/MdePkg/Include/Library/PeCoffGetEntryPointLib.h
>+++ b/MdePkg/Include/Library/PeCoffGetEntryPointLib.h
>@@ -115,7 +115,7 @@ PeCoffGetSizeOfHeaders (
> **/
> UINTN
> EFIAPI
>-PeCoffSerachImageBase (
>+PeCoffSearchImageBase (
>   IN UINTNAddress
>   );
>
>diff --git
>a/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c
>b/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c
>index 00f6d7d..e1ddc8b 100644
>--- a/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c
>+++ b/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c
>@@ -332,7 +332,7 @@ PeCoffGetSizeOfHeaders (
> **/
> UINTN
> EFIAPI
>-PeCoffSerachImageBase (
>+PeCoffSearchImageBase (
>   IN UINTNAddress
>   )
> {
>diff --git
>a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugA
>gent.c
>b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugA
>gent.c
>index 6f3c419..f156fe2 100644
>---
>a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugA
>gent.c
>+++
>b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugA
>gent.c
>@@ -206,7 +206,7 @@ FindAndReportModuleImageInfo (
>   //
>   // Find Image Base
>   //
>-  Pe32Data = PeCoffSerachImageBase ((UINTN) mErrorMsgVersionAlert);
>+  Pe32Data = PeCoffSearchImageBase ((UINTN) mErrorMsgVersionAlert);
>   if (Pe32Data != 0) {
> ImageContext.ImageAddress = Pe32Data;
> ImageContext.PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN)
>ImageContext.ImageAddress);
>diff --git
>a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
>b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
>index 78ee182..dbfaae1 100644
>--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
>+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
>@@ -120,7 +120,7 @@ DumpModuleImageInfo (
>   VOID *PdbPointer;
>   VOID *EntryPoint;
>
>-  Pe32Data = PeCoffSerachImageBase (CurrentEip);
>+  Pe32Data = PeCoffSearchImageBase (CurrentEip);
>   if (Pe32Data == 0) {
> InternalPrintMessage (" Can't find image information. \n");
>   } else {
>diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>index 2cb0bbc..2d6b572 100755
>--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
>@@ -178,7 +178,7 @@ DumpModuleInfoByIp (
>   //
>   // Find Image Base
>   //
>-  Pe32Data = PeCoffSerachImageBase (CallerIpAddress);
>+  Pe32Data = PeCoffSearchImageBase (CallerIpAddress);
>   if (Pe32Data != 0) {
> DEBUG ((DEBUG_ERROR, "It is invoked from the instruction before
>IP(0x%p)", (VOID *) CallerIpAddress));
> PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *) Pe32Data);
>--
>2.9.3.windows.2

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


Re: [edk2] [ edk2-BuildSpecification PATCH] Add support for Private declarations in a package

2017-04-24 Thread Zhu, Yonghong
Hi Mike,

This patch is good to me.  Reviewed-by: Yonghong Zhu  

while during review this patch, I found one update we wound made for " 5. 
Command line cannot be used to set the PCD value.". It is not related with this 
topic, but we can create another patch to update this sentence. Thanks.

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, April 25, 2017 9:12 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [ edk2-BuildSpecification PATCH] Add support for Private declarations 
in a package

https://bugzilla.tianocore.org/show_bug.cgi?id=465

Process new syntax in the DEC file that specifies information that can only be 
used by modules within the package. When modules outside the packages attempt 
to use this content, the EDK II build system must break with an error regarding 
content not found.

The four sections, Includes, Ppis, Guids and Protocols headers will be the 
keyword, Private, following the architecture modifier. If Private is not 
present, then the content is usable by modules outside the package.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 .../82_auto-generation_process.md  | 35 ++
 .../84_auto-generated_pcd_database_file.md |  6 
 README.md  |  3 +-
 3 files changed, 30 insertions(+), 14 deletions(-)

diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md 
b/8_pre-build_autogen_stage/82_auto-generation_process.md
index 6868d62..22a8b08 100644
--- a/8_pre-build_autogen_stage/82_auto-generation_process.md
+++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
@@ -1034,16 +1034,25 @@ II module:
   - DSC file's architecture specific modifier only `[LibraryClasses.arch]`
   - The DSC file's common `[LibraryClasses]` section
 
-**
-**Note:** For modules of type **USER_DEFINED**_, if a `NULL` library class -is 
required, the library instance should be listed in the INF scoping 
-`` section of the component.
-**
+  **
+  **Note:** For modules of type **USER_DEFINED**_, if a `NULL` library 
+ class  is required, the library instance should be listed in the INF 
+ scoping  `` section of the component.
+  **
 
 * Inherit GUIDs, Protocols and PPIs from all library instances obtained above,
   and determine values or type of them. The value of a GUID, Protocol or PPI is
   defined in DEC file.
 
+  **
+  **Note:** If GUID, Protocol or PPI is listed in a DEC file, where the  
+ `Private` modifier is used in the section tag 
+ (`[Guids.common.Private]` for  example), only modules within the 
+ package are permitted to use the GUID,  Protocol or PPI. If a module 
+ or library instance outside of the package  attempts to use the item, 
+ the build must fail with an appropriate error  message.
+  **
+
 * Inherit PCDs from all library instances obtained above and determine values
   and type. The value and type of a PCD are obtained from a DSC file, INF file
   or DEC file if it cannot be found in the DSC or INF file. For each EDK II @@ 
-1058,14 +1067,14 @@ is required, the library instance should be listed in the 
INF scoping
   - The INF file's PCD sections
   - The DEC file's PCD sections
 
-**
-**Note:** Values of PCDs using the FeatureFlag, PatchableInModule and 
-FixedAtBuild access methods set for this INF file are local to the INF file 
and -do not pertain to any other INF files. Dynamic and DynamicEx access method 
PCD -values are global to a platform and should not be overridden by specifying 
them -here. If, however, the dynamic PCDs are only valid for this INF, it is 
-permissible to set them here.
-**
+  **
+  **Note:** Values of PCDs using the FeatureFlag, PatchableInModule and  
+ FixedAtBuild access methods set for this INF file are local to the INF 
+ file and  do not pertain to any other INF files. Dynamic and DynamicEx 
+ access method PCD  values are global to a platform and should not be 
+ overridden by specifying them  here. If, however, the dynamic PCDs are 
+ only valid for this INF, it is  permissible to set them here.
+  **
 
 * Inherit library instance dependency (`[Depex]` sections) expressions if a
   module does not list a separate dependency file.
diff --git a/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md 
b/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md
index d309246..fc291c5 100644
--- a/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md
+++ b/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md
@@ -99,6 +99,12 @@ DSC, INF or DEC files.
 
 5. Command 

Re: [edk2] [PATCH V2 0/4] Add SmmIoLib

2017-04-24 Thread Gao, Liming
Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Jiewen Yao
>Sent: Monday, April 24, 2017 10:15 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [PATCH V2 0/4] Add SmmIoLib
>
> V2 
>Remove ASSERT(FALSE). (From Jeff Fan)
>
> V1 
>
>This patch series add SmmIoLib.
>It is the first part of bugzillar 491.
>https://bugzilla.tianocore.org/show_bug.cgi?id=491
>Move generic function - OpalIsValidMmioSpace from OPAL
>driver to library.
>
>This SmmIoLib is similar to SmmMemLib.
>
>The second part of bugzillar 491 is to update consumer
>SecurityPkg/Tcg/Opal/OpalPasswordSmm. It will be
>handled in future patch series.
>
>Jiewen Yao (4):
>  MdePkg/SmmIoLib: Add header file.
>  MdePkg/SmmIoLib: Add sample instance.
>  MdePkg/dec: Add SmmIoLib.
>  MdePkg/dsc: add SmmIoLib
>
> MdePkg/Include/Library/SmmIoLib.h|  42 +++
> MdePkg/Library/SmmIoLib/SmmIoLib.c   | 330 
> MdePkg/Library/SmmIoLib/SmmIoLib.inf |  53 
> MdePkg/Library/SmmIoLib/SmmIoLib.uni |  23 ++
> MdePkg/MdePkg.dec|   4 +
> MdePkg/MdePkg.dsc|   1 +
> 6 files changed, 453 insertions(+)
> create mode 100644 MdePkg/Include/Library/SmmIoLib.h
> create mode 100644 MdePkg/Library/SmmIoLib/SmmIoLib.c
> create mode 100644 MdePkg/Library/SmmIoLib/SmmIoLib.inf
> create mode 100644 MdePkg/Library/SmmIoLib/SmmIoLib.uni
>
>--
>2.7.4.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [ edk2-DecSpecification PATCH 0/4] Add support for Private declarations in a package

2017-04-24 Thread Zhu, Yonghong
Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, April 25, 2017 9:10 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [ edk2-DecSpecification PATCH 0/4] Add support for Private 
declarations in a package

https://bugzilla.tianocore.org/show_bug.cgi?id=465
https://bugzilla.tianocore.org/show_bug.cgi?id=482

GitHub word diff view of the patches in this series

* [1/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/24a07ae89ef0467c9009633d19d24bb1ba2e115a?w=1
* [2/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/65f49d1d86439b6144ff82217349a5145ec42ef0?w=1
* [3/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/a28fd82b07521fc7412be75b159a44a0dd3bf1b1?w=1
* [4/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/c04e668af9e1aa8c8e49d73fede6df7287b7d454?w=1

Remove trailing spaces from README.md 

Update DEC_SPECIFCATION to 0x0001001A / 1.26 

Add new syntax to the DEC file for specifying information that can only be used 
by modules within the package. When modules outside the packages attempt to use 
this content, the EDK II build system must break with an error regarding 
content not found.

The four sections, Includes, Ppis, Guids and Protocols headers will be modified 
with a keyword, Private following the architecture modifier. If Private is not 
present, then the content is usable by modules outside the package.

Clarify restriction that an element is not allowed to be declared with and 
without Private modifier.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 


Michael Kinney (4):
  Remove trailing spaces from README.MD
  Update version from 1.25 to 1.26
  Add support for Private declarations in a package
  Declarations not allowed to be both public and private

 2_dec_file_overview/24_[defines]_usage.md  |   2 +-
 2_dec_file_overview/25_[includes]_usage.md |  24 ++-
 2_dec_file_overview/26_[guids]_usage.md|  22 ++-
 2_dec_file_overview/27_[protocols]_usage.md|  24 ++-
 2_dec_file_overview/28_[ppis]_usage.md |  24 ++-
 3_edk_ii_dec_file_format/34_[defines]_section.md   |  28 ++-
 3_edk_ii_dec_file_format/35_[includes]_sections.md |  30 ++-
 3_edk_ii_dec_file_format/36_[guids]_sections.md|  29 ++-
 .../37_[protocols]_sections.md |  29 ++-
 3_edk_ii_dec_file_format/38_[ppis]_sections.md |  29 ++-
 README.md  | 211 +++--
 11 files changed, 329 insertions(+), 123 deletions(-)

--
2.6.3.windows.1

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


Re: [edk2] ARM virt machine boots fail with 14 ioh3420

2017-04-24 Thread Shannon Zhao


On 2017/4/24 18:16, Marcel Apfelbaum wrote:
> On 04/24/2017 01:02 PM, Laszlo Ersek wrote:
>> On 04/14/17 04:41, Shannon Zhao wrote:
>>> Hi Laszlo,
>>>
>>> Thanks a lot for your reply:)
>>>
>>> On 2017/4/14 1:09, Laszlo Ersek wrote:
 Adding Andrea, Ard, Drew and Marcel; and the main qemu list

 On 04/13/17 09:37, Shannon Zhao wrote:
> Hi,
>
> I'm testing the PCIe devices hotplug for ARM virt machine and using
> ioh3420 as root port. I found that below command line could work.
>
> qemu-system-aarch64 -machine virt,accel=kvm,usb=off -cpu host -bios
> QEMU_EFI.fd -m 12288 -smp 8,sockets=8,cores=1,threads=1  -device
> ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,addr=0x1 -device
> ioh3420,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x2 -device
> ioh3420,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x3 -device
> ioh3420,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x4 -device
> ioh3420,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x5 -device
> ioh3420,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x6 -device
> ioh3420,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x7 -device
> ioh3420,port=0xf,chassis=8,id=pci.8,bus=pcie.0,addr=0x8 -device
> ioh3420,port=0x10,chassis=9,id=pci.9,bus=pcie.0,addr=0x9 -device
> ioh3420,port=0x11,chassis=10,id=pci.10,bus=pcie.0,addr=0xa -device
> ioh3420,port=0x12,chassis=11,id=pci.11,bus=pcie.0,addr=0xb -device
> ioh3420,port=0x13,chassis=12,id=pci.12,bus=pcie.0,addr=0xc -device
> ioh3420,port=0x14,chassis=13,id=pci.13,bus=pcie.0,addr=0xd -device
> i82801b11-bridge,id=pci.17,bus=pcie.0,addr=0x11 -device
> pci-bridge,chassis_nr=18,id=pci.18,bus=pci.17,addr=0x0 -device
> usb-ehci,id=usb,bus=pci.18,addr=0x1 -device
> virtio-scsi-pci,id=scsi0,bus=pci.1,addr=0x0,disable-legacy=on,disable-modern=off
>
> -drive
> file=/mnt/sdb/guest.raw,format=raw,if=none,id=drive-scsi0-0-0-0,cache=none,aio=native
>
> -device
> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
>
> -netdev tap,id=hostnet1,vhost=on -device
> virtio-net-pci,netdev=hostnet1,id=net1,mac=00:16:3e:2b:cc:e1,bus=pci.2,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet2,vhost=on -device
> virtio-net-pci,netdev=hostnet2,id=net2,mac=00:16:3e:22:29:80,bus=pci.3,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet3,vhost=on -device
> virtio-net-pci,netdev=hostnet3,id=net3,mac=00:16:3e:28:07:9a,bus=pci.4,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet4,vhost=on -device
> virtio-net-pci,netdev=hostnet4,id=net4,mac=00:16:3e:3d:cd:b6,bus=pci.5,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet5,vhost=on -device
> virtio-net-pci,netdev=hostnet5,id=net5,mac=00:16:3e:64:9f:b0,bus=pci.6,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet6,vhost=on -device
> virtio-net-pci,netdev=hostnet6,id=net6,mac=00:16:3e:33:5b:d3,bus=pci.7,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet7,vhost=on -device
> virtio-net-pci,netdev=hostnet7,id=net7,mac=00:16:3e:39:7c:df,bus=pci.8,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet8,vhost=on -device
> virtio-net-pci,netdev=hostnet8,id=net8,mac=00:16:3e:0a:c1:4e,bus=pci.9,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet9,vhost=on -device
> virtio-net-pci,netdev=hostnet9,id=net9,mac=00:16:3e:0a:58:a6,bus=pci.10,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet10,vhost=on -device
> virtio-net-pci,netdev=hostnet10,id=net10,mac=00:16:3e:35:b5:80,bus=pci.11,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet11,vhost=on -device
> virtio-net-pci,netdev=hostnet11,id=net11,mac=00:16:3e:4d:b5:bb,bus=pci.12,addr=0x0,disable-legacy=on,disable-modern=off
>
> -netdev tap,id=hostnet12,vhost=on -device
> virtio-net-pci,netdev=hostnet12,id=net12,mac=00:16:3e:3b:69:e9,bus=pci.13,addr=0x0,disable-legacy=on,disable-modern=off
>
> -nographic
>
> But if I add one more ioh3420 device by appending above command with
> "-device ioh3420,port=0x15,chassis=14,id=pci.14,bus=pcie.0,addr=0xe",
> the guest can't boot. It seems that the firmware doesn't recognize the
> PCIe devices and print "Connect: PciRoot(0x0): Not Found".
>
> I'm using QEMU 2.8.1 and edk2 at commit 36a0d5c. Is there any
> limitation
> of the supported PCIe devices?

 In one sentence: you are running out of (emulated) IO space.

 Aarch64 does not have "IO space", but with QEMU, using the "virt"
 machine type, we emulate 64KB of IO space, mapped to a special MMIO
 range. This is available for PCI resource allocation, for such devices
 that have IO BARs (and for such PCI 

[edk2] [ edk2-BuildSpecification PATCH] Add support for Private declarations in a package

2017-04-24 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=465

GitHub word diff view of the patches in this series

* 
https://github.com/mdkinney/edk2-BuildSpecification/commit/97290a0b1e926c946959ed11f931fd2db26ad04b?w=1

Process new syntax in the DEC file that specifies
information that can only be used by modules within
the package. When modules outside the packages attempt
to use this content, the EDK II build system must
break with an error regarding content not found.

The four sections, Includes, Ppis, Guids and Protocols
headers will be the keyword, Private, following the
architecture modifier. If Private is not present, then
the content is usable by modules outside the package.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Add support for Private declarations in a package

 .../82_auto-generation_process.md  | 35 ++
 .../84_auto-generated_pcd_database_file.md |  6 
 README.md  |  3 +-
 3 files changed, 30 insertions(+), 14 deletions(-)

-- 
2.6.3.windows.1

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


[edk2] [ edk2-BuildSpecification PATCH] Add support for Private declarations in a package

2017-04-24 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=465

Process new syntax in the DEC file that specifies
information that can only be used by modules within
the package. When modules outside the packages attempt
to use this content, the EDK II build system must
break with an error regarding content not found.

The four sections, Includes, Ppis, Guids and Protocols
headers will be the keyword, Private, following the
architecture modifier. If Private is not present, then
the content is usable by modules outside the package.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 .../82_auto-generation_process.md  | 35 ++
 .../84_auto-generated_pcd_database_file.md |  6 
 README.md  |  3 +-
 3 files changed, 30 insertions(+), 14 deletions(-)

diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md 
b/8_pre-build_autogen_stage/82_auto-generation_process.md
index 6868d62..22a8b08 100644
--- a/8_pre-build_autogen_stage/82_auto-generation_process.md
+++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
@@ -1034,16 +1034,25 @@ II module:
   - DSC file's architecture specific modifier only `[LibraryClasses.arch]`
   - The DSC file's common `[LibraryClasses]` section
 
-**
-**Note:** For modules of type **USER_DEFINED**_, if a `NULL` library class
-is required, the library instance should be listed in the INF scoping
-`` section of the component.
-**
+  **
+  **Note:** For modules of type **USER_DEFINED**_, if a `NULL` library class
+  is required, the library instance should be listed in the INF scoping
+  `` section of the component.
+  **
 
 * Inherit GUIDs, Protocols and PPIs from all library instances obtained above,
   and determine values or type of them. The value of a GUID, Protocol or PPI is
   defined in DEC file.
 
+  **
+  **Note:** If GUID, Protocol or PPI is listed in a DEC file, where the
+  `Private` modifier is used in the section tag (`[Guids.common.Private]` for
+  example), only modules within the package are permitted to use the GUID,
+  Protocol or PPI. If a module or library instance outside of the package
+  attempts to use the item, the build must fail with an appropriate error
+  message.
+  **
+
 * Inherit PCDs from all library instances obtained above and determine values
   and type. The value and type of a PCD are obtained from a DSC file, INF file
   or DEC file if it cannot be found in the DSC or INF file. For each EDK II
@@ -1058,14 +1067,14 @@ is required, the library instance should be listed in 
the INF scoping
   - The INF file's PCD sections
   - The DEC file's PCD sections
 
-**
-**Note:** Values of PCDs using the FeatureFlag, PatchableInModule and
-FixedAtBuild access methods set for this INF file are local to the INF file and
-do not pertain to any other INF files. Dynamic and DynamicEx access method PCD
-values are global to a platform and should not be overridden by specifying them
-here. If, however, the dynamic PCDs are only valid for this INF, it is
-permissible to set them here.
-**
+  **
+  **Note:** Values of PCDs using the FeatureFlag, PatchableInModule and
+  FixedAtBuild access methods set for this INF file are local to the INF file 
and
+  do not pertain to any other INF files. Dynamic and DynamicEx access method 
PCD
+  values are global to a platform and should not be overridden by specifying 
them
+  here. If, however, the dynamic PCDs are only valid for this INF, it is
+  permissible to set them here.
+  **
 
 * Inherit library instance dependency (`[Depex]` sections) expressions if a
   module does not list a separate dependency file.
diff --git a/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md 
b/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md
index d309246..fc291c5 100644
--- a/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md
+++ b/8_pre-build_autogen_stage/84_auto-generated_pcd_database_file.md
@@ -99,6 +99,12 @@ DSC, INF or DEC files.
 
 5. Command line cannot be used to set the PCD value.
 
+6. If a PCD has a Token Space GUID specified in DEC file and the `[Guids]`
+   section tag contains the `Private` modifier (`[Guids.common.Private]` for
+   example), the PCD may only be used by modules in the package containing the
+   DEC file. If a module outside of that package attempts to use the PCD, the
+   build must break with an appropriate error message.
+
  8.4.1.2 Precedence Rules for PCDs not listed in the DSC or FDF Files:
 
 This subsection covers PCDs that are used by modules listed in the DSC file,
diff --git a/README.md b/README.md
index 89578d0..94b2062 100644
--- a/README.md
+++ b/README.md
@@ -188,7 +188,7 @@ Copyright (c) 

[edk2] [ edk2-DecSpecification PATCH 3/4] Add support for Private declarations in a package

2017-04-24 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=465

Add new syntax to the DEC file for specifying
information that can only be used by modules
within the package. When modules outside the
packages attempt to use this content, the EDK
II build system must break with an error
regarding content not found.

The four sections, Includes, Ppis, Guids and
Protocols headers will be modified with a keyword,
Private following the architecture modifier. If
Private is not present, then the content is usable
by modules outside the package.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dec_file_overview/25_[includes]_usage.md | 24 +-
 2_dec_file_overview/26_[guids]_usage.md| 22 ++--
 2_dec_file_overview/27_[protocols]_usage.md| 24 +-
 2_dec_file_overview/28_[ppis]_usage.md | 24 +-
 3_edk_ii_dec_file_format/35_[includes]_sections.md | 14 -
 3_edk_ii_dec_file_format/36_[guids]_sections.md| 14 -
 .../37_[protocols]_sections.md | 14 -
 3_edk_ii_dec_file_format/38_[ppis]_sections.md | 14 -
 README.md  |  1 +
 9 files changed, 142 insertions(+), 9 deletions(-)

diff --git a/2_dec_file_overview/25_[includes]_usage.md 
b/2_dec_file_overview/25_[includes]_usage.md
index b61eb98..17feb57 100644
--- a/2_dec_file_overview/25_[includes]_usage.md
+++ b/2_dec_file_overview/25_[includes]_usage.md
@@ -48,23 +48,45 @@ Also included in this section are the directories 
containing headers that may
 be required for individual EDK II module types. Refer to Appendix, "EDK II
 Module Types", for a list of the valid types.
 
+The section tag modifier, `Private`, is used to restrict the EDK II build
+system by preventing references to content in these sections from being used by
+modules outside of the package.
+
 Refer to the `[Includes]` definition later in this document for a complete
 description of this section and its contents.
 
 The `[Includes]` section uses one of the following section definitions:
 
 ```ini
+[Includes]
+
 [Includes.common]
 
+[Includes.common.Private]
+
 [Includes.IA32]
 
+[Includes.IA32.Private]
+
 [Includes.X64]
 
+[Includes.X64.Private]
+
 [Includes.IPF]
 
+[Includes.IPF.Private]
+
 [includes.EBC]
 
-[Includes]
+[includes.EBC.Private]
+```
+
+Architectural sections may also be combined, as in:
+
+```ini
+[Includes.IA32, Includes.X64]
+
+[Includes.IA32.Private, Includes.X64.Private]
 ```
 
 The format for entries in this section is one field, with an optional comment
diff --git a/2_dec_file_overview/26_[guids]_usage.md 
b/2_dec_file_overview/26_[guids]_usage.md
index 98459cf..f9addf5 100644
--- a/2_dec_file_overview/26_[guids]_usage.md
+++ b/2_dec_file_overview/26_[guids]_usage.md
@@ -35,24 +35,42 @@ This is an optional section.
 
 This section is used to define the GUID Value for Guid C Names.
 
+The section tag modifier, `Private`, is used to restrict the EDK II build
+system by preventing references to content in these sections from being used by
+modules outside of the package.
+
 This section uses one of the following section definitions:
 
 ```ini
 [Guids]
 
+[Guids.common]
+
+[Guids.common.Private]
+
 [Guids.IA32]
 
+[Guids.IA32.Private]
+
 [Guids.X64]
 
+[Guids.X64.Private]
+
 [Guids.IPF]
 
+[Guids.IPF.Private]
+
 [Guids.EBC]
 
-[Guids.common]
+[Guids.EBC.Private]
+```
 
+Architectural sections may also be combined, as in:
+
+```ini
 [Guids.IA32, Guids.X64]
 
-[Guids.X64, Guids.IPF]
+[Guids.IA32.Private, Guids.X64.Private]
 ```
 
 Format for the entries in this section is two fields with an equal "="
diff --git a/2_dec_file_overview/27_[protocols]_usage.md 
b/2_dec_file_overview/27_[protocols]_usage.md
index fb539b2..9f89524 100644
--- a/2_dec_file_overview/27_[protocols]_usage.md
+++ b/2_dec_file_overview/27_[protocols]_usage.md
@@ -35,20 +35,42 @@ This is an optional section.
 
 This section is used to define the GUID Value for Protocol C Names.
 
+The section tag modifier, `Private`, is used to restrict the EDK II build
+system by preventing references to content in these sections from being used by
+modules outside of the package.
+
 This section use ones of the following section definitions:
 
 ```ini
 [Protocols]
 
+[Protocols.common]
+
+[Protocols.common.Private]
+
 [Protocols.IA32]
 
+[Protocols.IA32.Private]
+
 [Protocols.X64]
 
+[Protocols.X64.Private]
+
 [Protocols.IPF]
 
+[Protocols.IPF.Private]
+
 [Protocols.EBC]
 
-[Protocols.common]
+[Protocols.EBC.Private]
+```
+
+Architectural sections may also be combined, as in:
+
+```ini
+[Protocols.IA32, Protocols.X64]
+
+[Protocols.IA32.Private, Protocols.X64.Private]
 ```
 
 Format for the entries in this section is two fields 

[edk2] [ edk2-DecSpecification PATCH 2/4] Update version from 1.25 to 1.26

2017-04-24 Thread Michael Kinney
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dec_file_overview/24_[defines]_usage.md|  2 +-
 3_edk_ii_dec_file_format/34_[defines]_section.md | 28 
 README.md|  3 ++-
 3 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/2_dec_file_overview/24_[defines]_usage.md 
b/2_dec_file_overview/24_[defines]_usage.md
index 3729902..fe97c25 100644
--- a/2_dec_file_overview/24_[defines]_usage.md
+++ b/2_dec_file_overview/24_[defines]_usage.md
@@ -66,7 +66,7 @@ The following is an example of this section.
 
 ```ini
 [Defines]
-  DEC_SPECIFICATION = 0x00010019
+  DEC_SPECIFICATION = 0x0001001A
   PACKAGE_NAME  = MdePkg
   PACKAGE_GUID  = 1E73767F-8F52-4603-AEB4-F29B510B6766
   PACKAGE_VERSION   = 1.02
diff --git a/3_edk_ii_dec_file_format/34_[defines]_section.md 
b/3_edk_ii_dec_file_format/34_[defines]_section.md
index f84db5f..d249ab7 100644
--- a/3_edk_ii_dec_file_format/34_[defines]_section.md
+++ b/3_edk_ii_dec_file_format/34_[defines]_section.md
@@ -40,9 +40,9 @@ This file is created during installation of a UEFI 
distribution package or by
 the developer and is an input to the EDK II build tool parsing utilities.
 Elements may appear in any order within this section.
 
-The code for this specification is `"00010019`" and new versions of this
-specification must increment the minor (0019) portion of the specification
-code. This value may also be specified as a decimal value, 1.25.
+The code for this specification is `"0001001A`" and new versions of this
+specification must increment the minor (001A) portion of the specification
+code. This value may also be specified as a decimal value, 1.26.
 
 Existing DEC files are not required to update the `DEC_SPECIFICATION` version
 value. This value may be used by tools to identify any new functionality
@@ -83,11 +83,11 @@ characters are not permitted.
 
 **_SpecVer_**
 
-For new DEC files, the version value must be set to 0x00010019 Tools that
+For new DEC files, the version value must be set to 0x0001001A Tools that
 process this version of the DEC file can successfully process earlier versions
 of the DEC file (this is a backward compatible update). There is no requirement
 to change the value in existing DEC files if no other content changes. This may
-also be specified as decimal value, 1.25.
+also be specified as decimal value, 1.26.
 
 **_Filename_**
 
@@ -97,13 +97,23 @@ permitted. Use of an absolute path is not permitted. The 
file name specified in
 the `PACKAGE_UNI_FILE` entry must be a Unicode file with an extension of .uni, 
.UNI
 or .Uni.
 
- Example
+ Example 1
 
 ```ini
 [DEFINES]
-  DEC_SPECIFICATION = 0x00010019
+  DEC_SPECIFICATION = 0x0001001A
   PACKAGE_NAME  = MdePkg
-  PACKAGE_GUID  = 5e0e9358-46b6-4ae2-8218-4ab8b9bbdcec
-  PACKAGE_VERSION   = 0.3
+  PACKAGE_GUID  = 1E73767F-8F52-4603-AEB4-F29B510B6766
+  PACKAGE_VERSION   = 1.06
   PACKAGE_UNI_FILE  = MdePkg.uni
 ```
+
+ Example 2
+
+```ini
+[DEFINES]
+  DEC_SPECIFICATION = 1.26
+  PACKAGE_NAME  = IntelFspPkg
+  PACKAGE_GUID  = 444C6CDF-55BD-4744-8F74-AE98B003B955
+  PACKAGE_VERSION   = 0.1
+```
diff --git a/README.md b/README.md
index 8f37a7e..b489cb1 100644
--- a/README.md
+++ b/README.md
@@ -164,4 +164,5 @@ Copyright (c) 2007-2017, Intel Corporation. All rights 
reserved.
 || packages located outside of the WORKSPACE directory tree (refer 
to| |
 || the TianoCore.org EDKII website for additional instructions on 
setting| |
 || up a development environment).  
  | |
-| 1.26   | Reformat for GitBook
  | March 2017  |
+| 1.26   | Reformat for GitBook
  | April 2017  |
+|| Updated `DEC_SPECIFICATION` to `0x0001001A` or `1.26`   
  | |
-- 
2.6.3.windows.1

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


[edk2] [ edk2-DecSpecification PATCH 1/4] Remove trailing spaces from README.MD

2017-04-24 Thread Michael Kinney
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 README.md | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/README.md b/README.md
index b69a091..8f37a7e 100644
--- a/README.md
+++ b/README.md
@@ -29,24 +29,24 @@
 
 -->
 
-
+
 
-### {{ book.title }}
+### {{ book.title }}
 
-{% if book.draft %}
-** DRAFT FOR REVIEW **
-{% else %}
-** {{ book.version }} **
-{% endif %}
+{% if book.draft %}
+** DRAFT FOR REVIEW **
+{% else %}
+** {{ book.version }} **
+{% endif %}
 
-** {{ gitbook.time|date('MM/DD/ hh:mm:ss') }} **
-
-{% if book.udkrelease %}
-** {{ book.udkrelease }} **
-{% endif %}
+** {{ gitbook.time|date('MM/DD/ hh:mm:ss') }} **
 
+{% if book.udkrelease %}
+** {{ book.udkrelease }} **
+{% endif %}
 
-### Acknowledgements
+
+### Acknowledgements
 
 Redistribution and use in source (original document form) and 'compiled'
 forms (converted to PDF, epub, HTML and other formats) with or without
@@ -74,7 +74,7 @@ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 Copyright (c) 2007-2017, Intel Corporation. All rights reserved.
 
-### Revision History
+### Revision History
 
 | Revision   | Revision History
  | Date|
 | -- | 
-
 | --- |
-- 
2.6.3.windows.1

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


[edk2] [ edk2-DecSpecification PATCH 4/4] Declarations not allowed to be both public and private

2017-04-24 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=482

Clarify that Includes, Protocols, PPIs, and GUIDs
declared in and a DEC file are now allowed to be
both public and private.  If this condition is
detected the build tools must terminate with an
error.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 3_edk_ii_dec_file_format/35_[includes]_sections.md |  16 ++
 3_edk_ii_dec_file_format/36_[guids]_sections.md|  15 ++
 .../37_[protocols]_sections.md |  15 ++
 3_edk_ii_dec_file_format/38_[ppis]_sections.md |  15 ++
 README.md  | 183 +++--
 5 files changed, 153 insertions(+), 91 deletions(-)

diff --git a/3_edk_ii_dec_file_format/35_[includes]_sections.md 
b/3_edk_ii_dec_file_format/35_[includes]_sections.md
index 6fa083c..ed5acea 100644
--- a/3_edk_ii_dec_file_format/35_[includes]_sections.md
+++ b/3_edk_ii_dec_file_format/35_[includes]_sections.md
@@ -94,6 +94,22 @@ build tools must terminate with an error message.
 
 For example, `[Includes.common, Includes.IA32.Private]` is prohibited.
 
+It is NOT permissible for the same include directory to be listed in section
+tags with and without the `Private` modifier. If this condition is detected,
+the build tools must terminate with an error message.
+
+For example, the following is prohibited because the same directory called
+`MyPrivateIncludePath` is listed in a tag with and without a `Private`
+modifier.
+
+```
+[Includes]
+  MyPrivateIncludePath
+
+[Includes.common.Private]
+  MyPrivateIncludePath
+```
+
  Example
 
 ```ini
diff --git a/3_edk_ii_dec_file_format/36_[guids]_sections.md 
b/3_edk_ii_dec_file_format/36_[guids]_sections.md
index 1d00c9a..6a398ea 100644
--- a/3_edk_ii_dec_file_format/36_[guids]_sections.md
+++ b/3_edk_ii_dec_file_format/36_[guids]_sections.md
@@ -91,6 +91,21 @@ build tools must terminate with an error message.
 
 For example, `[Guids.common, Guids.IA32.Private]` is prohibited.
 
+It is NOT permissible for the same GUID to be listed in section tags with and
+without the `Private` modifier. If this condition is detected, the build tools
+must terminate with an error message.
+
+For example, the following is prohibited because the GUID named `MyPrivateGuid`
+is listed in a tag with and without a `Private` modifier.
+
+```
+[Guids]
+  MyPrivateGuid = { 0x1e96808b, 0xfa93, 0x4230, { 0xb5, 0x6b, 0x96, 0xc5, 
0x95, 0x9b, 0xd1, 0xd2 }}
+
+[Guids.common.Private]
+  MyPrivateGuid = { 0x1e96808b, 0xfa93, 0x4230, { 0xb5, 0x6b, 0x96, 0xc5, 
0x95, 0x9b, 0xd1, 0xd2 }}
+```
+
  Example
 
 ```ini
diff --git a/3_edk_ii_dec_file_format/37_[protocols]_sections.md 
b/3_edk_ii_dec_file_format/37_[protocols]_sections.md
index a43260c..c1d7daf 100644
--- a/3_edk_ii_dec_file_format/37_[protocols]_sections.md
+++ b/3_edk_ii_dec_file_format/37_[protocols]_sections.md
@@ -90,6 +90,21 @@ build tools must terminate with an error message.
 
 For example, `[Protocols.common, Protocols.IA32.Private]` is prohibited.
 
+It is NOT permissible for the same protocol to be listed in section tags with
+and without the `Private` modifier. If this condition is detected, the build
+tools must terminate with an error message.
+
+For example, the following is prohibited because the protocol named
+`MyPrivateProtocol` is listed in a tag with and without a `Private` modifier.
+
+```
+[Protocols]
+  MyPrivateProtocol = { 0xc7c4a20f, 0xd1d1, 0x427a, { 0xb0, 0x82, 0xa8, 0xb6, 
0x24, 0xf7, 0x69, 0x4f }}
+
+[Protocols.common.Private]
+  MyPrivateProtocol = { 0xc7c4a20f, 0xd1d1, 0x427a, { 0xb0, 0x82, 0xa8, 0xb6, 
0x24, 0xf7, 0x69, 0x4f }}
+```
+
  Example
 
 ```ini
diff --git a/3_edk_ii_dec_file_format/38_[ppis]_sections.md 
b/3_edk_ii_dec_file_format/38_[ppis]_sections.md
index 87c5f0d..db83fc4 100644
--- a/3_edk_ii_dec_file_format/38_[ppis]_sections.md
+++ b/3_edk_ii_dec_file_format/38_[ppis]_sections.md
@@ -91,6 +91,21 @@ build tools must terminate with an error message.
 
 For example, `[Ppis.common, Ppis.IA32.Private]` is prohibited.
 
+It is NOT permissible for the same PPI to be listed in section tags with and
+without the `Private` modifier. If this condition is detected, the build tools
+must terminate with an error message.
+
+For example, the following is prohibited because the PPI named `MyPrivatePpi`
+is listed in a tag with and without a `Private` modifier.
+
+```
+[Ppis]
+  MyPrivatePpi = { 0x10ed6a18, 0xbbf7, 0x4051, { 0xba, 0xb8, 0xb4, 0x90, 0x1a, 
0x65, 0xa2, 0xc5 }}
+
+[Ppis.common.Private]
+  MyPrivatePpi = { 0x10ed6a18, 0xbbf7, 0x4051, { 0xba, 0xb8, 0xb4, 0x90, 0x1a, 
0x65, 0xa2, 0xc5 }}
+```
+
  Example
 
 ```ini
diff --git a/README.md b/README.md
index 372ef19..5eea1ad 100644
--- a/README.md
+++ b/README.md
@@ -76,94 +76,95 @@ Copyright (c) 2007-2017, Intel Corporation. 

[edk2] [ edk2-DecSpecification PATCH 0/4] Add support for Private declarations in a package

2017-04-24 Thread Michael Kinney
https://bugzilla.tianocore.org/show_bug.cgi?id=465
https://bugzilla.tianocore.org/show_bug.cgi?id=482

GitHub word diff view of the patches in this series

* [1/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/24a07ae89ef0467c9009633d19d24bb1ba2e115a?w=1
* [2/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/65f49d1d86439b6144ff82217349a5145ec42ef0?w=1
* [3/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/a28fd82b07521fc7412be75b159a44a0dd3bf1b1?w=1
* [4/4] 
https://github.com/mdkinney/edk2-DecSpecification/commit/c04e668af9e1aa8c8e49d73fede6df7287b7d454?w=1

Remove trailing spaces from README.md 

Update DEC_SPECIFCATION to 0x0001001A / 1.26 

Add new syntax to the DEC file for specifying
information that can only be used by modules
within the package. When modules outside the
packages attempt to use this content, the EDK
II build system must break with an error
regarding content not found.

The four sections, Includes, Ppis, Guids and
Protocols headers will be modified with a keyword,
Private following the architecture modifier. If
Private is not present, then the content is usable
by modules outside the package.

Clarify restriction that an element is not allowed
to be declared with and without Private modifier.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 


Michael Kinney (4):
  Remove trailing spaces from README.MD
  Update version from 1.25 to 1.26
  Add support for Private declarations in a package
  Declarations not allowed to be both public and private

 2_dec_file_overview/24_[defines]_usage.md  |   2 +-
 2_dec_file_overview/25_[includes]_usage.md |  24 ++-
 2_dec_file_overview/26_[guids]_usage.md|  22 ++-
 2_dec_file_overview/27_[protocols]_usage.md|  24 ++-
 2_dec_file_overview/28_[ppis]_usage.md |  24 ++-
 3_edk_ii_dec_file_format/34_[defines]_section.md   |  28 ++-
 3_edk_ii_dec_file_format/35_[includes]_sections.md |  30 ++-
 3_edk_ii_dec_file_format/36_[guids]_sections.md|  29 ++-
 .../37_[protocols]_sections.md |  29 ++-
 3_edk_ii_dec_file_format/38_[ppis]_sections.md |  29 ++-
 README.md  | 211 +++--
 11 files changed, 329 insertions(+), 123 deletions(-)

-- 
2.6.3.windows.1

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


Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Lock should be acquired

2017-04-24 Thread Fan, Jeff
Laszlo,

There is no any real issue we encountered.

Some static code check tool reported AcquireSpinLockOrFai() return value was 
not been checked.
Then I found we may ignore some issue if AcquireSpinLockOrFai() return FALSE 
(even it will not be happened).

Using AcquireSpinLock() is due to the following code are using 
AcquireSpinLock() to check AP's BUSY state also.

Thanks!
Jeff

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Monday, April 24, 2017 7:41 PM
To: Fan, Jeff; edk2-devel@lists.01.org
Cc: Wu, Hao A; Kinney, Michael D; Tian, Feng
Subject: Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Lock should be acquired

Hi Jeff,

On 04/18/17 04:16, Jeff Fan wrote:
> SMM BSP's *busy* state should be acquired. We could use 
> AcquireSpinLock() instead of AcquireSpinLockOrFail().
> 
> Cc: Hao Wu 
> Cc: Feng Tian 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index a1d16b4..e03f1e0 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -407,7 +407,7 @@ BSPHandler (
>//
>// The BUSY lock is initialized to Acquired state
>//
> -  AcquireSpinLockOrFail (mSmmMpSyncData->CpuData[CpuIndex].Busy);
> +  AcquireSpinLock (mSmmMpSyncData->CpuData[CpuIndex].Busy);
>  
>//
>// Perform the pre tasks
> 

what symptoms did you experience without the fix?

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


Re: [edk2] [PATCH] ShellPkg SmbiosView: Display Type 0 BIOS segment in hexadecimal

2017-04-24 Thread Zeng, Star
The patch has been pushed at fed709deb444084594c2e11a1886819fa54afc00.

Thanks,
Star
-Original Message-
From: Zeng, Star 
Sent: Saturday, April 22, 2017 9:03 PM
To: Jeff Westfahl ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Carsey, Jaben ; 
Zeng, Star 
Subject: RE: [edk2] [PATCH] ShellPkg SmbiosView: Display Type 0 BIOS segment in 
hexadecimal

It is ok to me.

Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff 
Westfahl
Sent: Saturday, April 22, 2017 5:25 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Carsey, Jaben 
Subject: [edk2] [PATCH] ShellPkg SmbiosView: Display Type 0 BIOS segment in 
hexadecimal

The SMBIOS Type 0 BIOS segment field is currently displayed in decimal.
Since this field is likely to have a value like 0xE800 or 0xF000, using 
hexadecimal seems like a better choice.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
index 50d15ef..038f111 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
@@ -316,7 +316,7 @@ SmbiosPrintStructure (
   case 0:
 PRINT_PENDING_STRING (Struct, Type0, Vendor);
 PRINT_PENDING_STRING (Struct, Type0, BiosVersion);
-PRINT_STRUCT_VALUE (Struct, Type0, BiosSegment);
+PRINT_STRUCT_VALUE_H (Struct, Type0, BiosSegment);
 PRINT_PENDING_STRING (Struct, Type0, BiosReleaseDate);
 ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN 
(STR_SMBIOSVIEW_PRINTINFO_BIOS_SIZE), gShellDebug1HiiHandle, 64 * 
(Struct->Type0->BiosSize + 1));
 
--
2.7.4

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


Re: [edk2] Unable to boot OVMF on qemu-x86_64

2017-04-24 Thread Jordan Justen
On 2017-04-24 13:41:50, Laszlo Ersek wrote:
> On 04/18/17 07:29, Prakhya, Sai Praneeth wrote:
> > Hi All,
> > 
> > I am facing an issue booting OVMF on qemu, could you please help me?
> > I have cloned EDKII, and built OVMF for X64 using GCC5. I have
> > followed the steps given at https://wiki.ubuntu.com/UEFI/EDK2.
> 
> "last edited 2012-11-16 20:22:59"
> 
> > Then I
> > have used qemu-system-x86_64 to boot OVMF, but it fails, I don't see
> > anything on tty0 of qemu.

Did you build with "-DDEBUG_ON_SERIAL_PORT=TRUE" to enable the debug
to go to the serial port?

Personally, I'd recommend *not* using DEBUG_ON_SERIAL_PORT, and
instead of looking at tty0, add this to the qemu command line:

-debugcon file:debug.log -global isa-debugcon.iobase=0x402

Then debug.log will contain the debug messages.

(BTW, thanks Laszlo for implementing this! :)

> > When I tried the same by changing to IA32
> > it seems working. So, could anyone please let me know what I am
> > missing or maybe someone give it a try and see it it's reproducible
> > or not...
> > I am using Ubuntu 15.04 as my build system.
> 
> Please try the instructions given under "Build Scripts" in
> "OvmfPkg/README". (CC Jordan)

Yeah. This is more up to date than the Ubuntu wiki. It also has the
debugcon info...

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


Re: [edk2] Unable to boot OVMF on qemu-x86_64

2017-04-24 Thread Laszlo Ersek
On 04/18/17 07:29, Prakhya, Sai Praneeth wrote:
> Hi All,
> 
> I am facing an issue booting OVMF on qemu, could you please help me?
> I have cloned EDKII, and built OVMF for X64 using GCC5. I have
> followed the steps given at https://wiki.ubuntu.com/UEFI/EDK2.

"last edited 2012-11-16 20:22:59"

> Then I
> have used qemu-system-x86_64 to boot OVMF, but it fails, I don't see
> anything on tty0 of qemu. When I tried the same by changing to IA32
> it seems working. So, could anyone please let me know what I am
> missing or maybe someone give it a try and see it it's reproducible
> or not...
> I am using Ubuntu 15.04 as my build system.

Please try the instructions given under "Build Scripts" in
"OvmfPkg/README". (CC Jordan)

Laszlo

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


Re: [edk2] [PATCH] CorebootModulePkg, EmulatorPkg, Vlv2TbltDevicePkg: .inf whitespace fixes

2017-04-24 Thread Jordan Justen
On 2017-04-24 02:43:08, Leif Lindholm wrote:
> Incorrect line endings, trailing spaces and missing line break at end
> of file.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm 
> ---
> 
> This addresses only issues found when hacking on some scripts for
> sanity checking .inf files.
> 
> Since trivial[1], would prefer not to split into one patch per
> package.
> 
> [1] git diff -w  --word-diff-regex=[^[:space:]] HEAD~1
> does not generate any output.

Also: git diff --ignore-space-at-eol HEAD~

Reviewed-by: Jordan Justen 

> 
>  CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf  
>|  96 
>  
> CorebootModulePkg/Library/CbPlatformSupportLibNull/CbPlatformSupportLibNull.inf
>  |  70 +-
>  CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf
>|  98 
>  
> EmulatorPkg/Library/DxeEmuPeCoffExtraActionLib/DxeEmuPeCoffExtraActionLib.inf 
>   |  96 
>  
> EmulatorPkg/Library/PeiEmuPeCoffExtraActionLib/PeiEmuPeCoffExtraActionLib.inf 
>   |  98 
>  EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf  
>|  94 
>  Vlv2TbltDevicePkg/PlatformInitPei/PlatformInitPei.inf
>|  18 ++---
>  Vlv2TbltDevicePkg/SmBiosMiscDxe/SmBiosMiscDxe.inf
>| 290 
> 
>  8 files changed, 430 insertions(+), 430 deletions(-)
> 
> diff --git 
> a/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf 
> b/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> index cd758ae4bf..77075ccc95 100644
> --- 
> a/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> +++ 
> b/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> @@ -1,48 +1,48 @@
> -## @file
> -#  SerialPortLib instance for 16550 UART.
> -#
> -#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> -#  This program and the accompanying materials
> -#  are licensed and made available under the terms and conditions of the BSD 
> License
> -#  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  = BaseSerialPortLib16550
> -  MODULE_UNI_FILE= BaseSerialPortLib16550.uni
> -  FILE_GUID  = 9E7C00CF-355A-4d4e-BF60-0428CFF95540
> -  MODULE_TYPE= BASE
> -  VERSION_STRING = 1.1
> -  LIBRARY_CLASS  = SerialPortLib
> -
> -[Packages]
> -  MdePkg/MdePkg.dec
> -  MdeModulePkg/MdeModulePkg.dec
> -
> -[LibraryClasses]
> -  PcdLib
> -  IoLib
> -  PlatformHookLib
> -  PciLib
> -
> -[Sources]
> -  BaseSerialPortLib16550.c
> -
> -[Pcd]
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio ## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl  ## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialDetectCable ## 
> SOMETIMES_CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialLineControl ## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialFifoControl ## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate   ## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialPciDeviceInfo   ## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialExtendedTxFifoSize  ## CONSUMES
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride  ## CONSUMES
> +## @file
> +#  SerialPortLib instance for 16550 UART.
> +#
> +#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD 
> License
> +#  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  = BaseSerialPortLib16550
> +  MODULE_UNI_FILE= BaseSerialPortLib16550.uni
> +  FILE_GUID   

Re: [edk2] [MAC HELP] Does Mac has a grubx64.efi ?

2017-04-24 Thread Marvin Häuser
Run '/System/Library/CoreServices/boot.efi' (without the quotes) on the macOS 
root partition, not the ESP.

Regards,
Marvin.

-Ursprüngliche Nachricht-
Von: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] Im Auftrag von Amit 
kumar
Gesendet: Montag, 24. April 2017 14:27
An: edk2-devel@lists.01.org
Betreff: [edk2] [MAC HELP] Does Mac has a grubx64.efi ?

Hi ,

I am trying to boot a mac OS X from the efi shell so i opened the EFI partition.
As usual there was EFI directory inside which there was APPLE director.
so i went to EFI/APPLE director and found out there where two more directories 
inside /EFI/APPLE 1. FIRMWARE and 2. EXTENSIONS but there was no grubx64.efi 
like linux system.
E.g
we can boot ubutu using :
EFI/ubuntu/grubx64.efi
and for windows we have
EFI/Boot/BOOTX64.efi 

i found out there is a ThorUtil.efi in /EFI/APPLE/FIRMWARE  but when i try to 
run it, it says ThorUtil.efi is not recognized as an internal or external 
command, operable program, or a batch file. 


Can some help me booting a mac OS from UEFI shell.
P.S :: I have a mac air 13, intel i5, OS X

Thanks And Regards
Amit Kumar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [MAC HELP] Does Mac has a grubx64.efi ? /

2017-04-24 Thread Andrew Fish

> On Apr 24, 2017, at 5:27 AM, Amit kumar  wrote:
> 
> Hi ,
> 
> I am trying to boot a mac OS X from the efi shell so i opened the EFI 
> partition.
> As usual there was EFI directory inside which there was APPLE director.
> so i went to EFI/APPLE director and found out there where two more 
> directories inside /EFI/APPLE
> 1. FIRMWARE and 2. EXTENSIONS but there was no grubx64.efi like linux system.
> E.g 
> we can boot ubutu using :
> EFI/ubuntu/grubx64.efi 
> and for windows we have
> EFI/Boot/BOOTX64.efi 
> 
> i found out there is a ThorUtil.efi in /EFI/APPLE/FIRMWARE  but when i try to 
> run it, it says ThorUtil.efi is not recognized as an internal or external 
> command, operable program, or a batch file. 
> 
> 
> Can some help me booting a mac OS from UEFI shell.
> P.S :: I have a mac air 13, intel i5, OS X
> 

>From macOS you can run `bless --info` and this will show you the current path 
>to the OS loader. 
The common location is System/Library/CoreServices/boot.efi on your OS boot 
volume. 

Thanks,

Andrew Fish

> Thanks And Regards
> Amit Kumar 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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


Re: [edk2] [PATCH V2 2/4] MdePkg/SmmIoLib: Add sample instance.

2017-04-24 Thread Carsey, Jaben
Slight cleanup suggestion.
Since you are already linking MemoryAllocationLib, you could just call FreePool 
in that library instead of using UefiBootServicesTableLib and using 
gBS->FreePool (since you have no other use of gBS that I see).

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiewen Yao
> Sent: Monday, April 24, 2017 7:15 AM
> To: edk2-devel@lists.01.org
> Cc: Fan, Jeff ; Gao, Liming 
> Subject: [edk2] [PATCH V2 2/4] MdePkg/SmmIoLib: Add sample instance.
> 
> The sample instance check if IO resource is valid
> one defined in GCD.
> A platform may choose add more check to exclude some
> other IO resource.
> 
> Cc: Jeff Fan 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdePkg/Library/SmmIoLib/SmmIoLib.c   | 330 
>  MdePkg/Library/SmmIoLib/SmmIoLib.inf |  53 
>  MdePkg/Library/SmmIoLib/SmmIoLib.uni |  23 ++
>  3 files changed, 406 insertions(+)
> 
> diff --git a/MdePkg/Library/SmmIoLib/SmmIoLib.c
> b/MdePkg/Library/SmmIoLib/SmmIoLib.c
> new file mode 100644
> index 000..181abb8
> --- /dev/null
> +++ b/MdePkg/Library/SmmIoLib/SmmIoLib.c
> @@ -0,0 +1,330 @@
> +/** @file
> +  Instance of SMM IO check library.
> +
> +  SMM IO check library library implementation. This library consumes GCD to
> collect all valid
> +  IO space defined by a platform.
> +  A platform may have its own SmmIoLib instance to exclude more IO space.
> +
> +  Copyright (c) 2017, Intel Corporation. All rights reserved.
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD
> License
> +  which accompanies this distribution.  The full text of the license may be
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_GCD_MEMORY_SPACE_DESCRIPTOR   *mSmmIoLibGcdMemSpace   =
> NULL;
> +UINTN mSmmIoLibGcdMemNumberOfDesc = 0;
> +
> +EFI_PHYSICAL_ADDRESS
> mSmmIoLibInternalMaximumSupportMemAddress = 0;
> +
> +VOID  *mSmmIoLibRegistrationEndOfDxe;
> +VOID  *mSmmIoLibRegistrationReadyToLock;
> +
> +BOOLEAN   mSmmIoLibReadyToLock = FALSE;
> +
> +/**
> +  Calculate and save the maximum support address.
> +
> +**/
> +VOID
> +SmmIoLibInternalCalculateMaximumSupportAddress (
> +  VOID
> +  )
> +{
> +  VOID *Hob;
> +  UINT32   RegEax;
> +  UINT8MemPhysicalAddressBits;
> +
> +  //
> +  // Get physical address bits supported.
> +  //
> +  Hob = GetFirstHob (EFI_HOB_TYPE_CPU);
> +  if (Hob != NULL) {
> +MemPhysicalAddressBits = ((EFI_HOB_CPU *) Hob)-
> >SizeOfMemorySpace;
> +  } else {
> +AsmCpuid (0x8000, , NULL, NULL, NULL);
> +if (RegEax >= 0x8008) {
> +  AsmCpuid (0x8008, , NULL, NULL, NULL);
> +  MemPhysicalAddressBits = (UINT8) RegEax;
> +} else {
> +  MemPhysicalAddressBits = 36;
> +}
> +  }
> +  //
> +  // IA-32e paging translates 48-bit linear addresses to 52-bit physical
> addresses.
> +  //
> +  ASSERT (MemPhysicalAddressBits <= 52);
> +  if (MemPhysicalAddressBits > 48) {
> +MemPhysicalAddressBits = 48;
> +  }
> +
> +  //
> +  // Save the maximum support address in one global variable
> +  //
> +  mSmmIoLibInternalMaximumSupportMemAddress =
> (EFI_PHYSICAL_ADDRESS)(UINTN)(LShiftU64 (1, MemPhysicalAddressBits) -
> 1);
> +  DEBUG ((DEBUG_INFO,
> "mSmmIoLibInternalMaximumSupportMemAddress = 0x%lx\n",
> mSmmIoLibInternalMaximumSupportMemAddress));
> +}
> +
> +/**
> +  This function check if the MMIO resource is valid per processor
> architecture and
> +  valid per platform design.
> +
> +  @param BaseAddress  The MMIO start address to be checked.
> +  @param Length   The MMIO length to be checked.
> +  @param OwnerA GUID representing the owner of the resource.
> +  This GUID may be used by producer to correlate the 
> device
> ownership of the resource.
> +  NULL means no specific owner.
> +
> +  @retval TRUE  This MMIO resource is valid per processor architecture and
> valid per platform design.
> +  @retval FALSE This MMIO resource is not valid per processor architecture
> or valid per platform design.
> +**/
> +BOOLEAN
> +EFIAPI
> +SmmIsMmioValid (
> +  IN EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN UINT64Length,
> +  IN EFI_GUID  *Owner  OPTIONAL
> +  )
> +{
> +  UINTN   Index;
> +  EFI_GCD_MEMORY_SPACE_DESCRIPTOR 

Re: [edk2] Python issue in UEFI shell

2017-04-24 Thread Carsey, Jaben
I am not sure here, but I think that you may have issues running multiple 
threads in the UEFI environment.  Have you tried not using multiple threadS?

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of KT
> Sent: Monday, April 24, 2017 5:32 AM
> To: edk2-devel@lists.01.org
> Cc: edk2-li...@mc2research.org
> Subject: Re: [edk2] Python issue in UEFI shell
> Importance: High
> 
> Hello,
> Can someone please shed some light on this issue?
> 
> Thanks
> 
> Thanks
> On Tue, Apr 18, 2017 at 2:56 PM, KT  wrote:
> 
> > Hi experts,
> >
> > I am experimenting python scripts in UEFI shell and as part of the first
> > step I tried compiling python as per the instructions in
> > edk2\AppPkg\Applications\Python\PythonReadMe.txt.  However when I
> run my
> > script, I noticed that it required third-party modules (requests, urllib3
> > etc). So I manually copied these under the \EFI\StdLib\lib\python.27\site-
> packages
> > folder (not sure if that is the correct way). That said currently my script
> > is failing as follows:
> >
> > Traceback (most recent call last):
> >   File "rest_json.py", line 11, in 
> > import requests
> >   File "\Efi\StdLib\lib\python.27\site-packages/requests/__init__.py",
> > line 60, in 
> > from .packages.urllib3.exceptions import DependencyWarning
> >   File "\Efi\StdLib\lib\python.27\site-
> packages/requests/packages/__init__.py",
> > line 29, in 
> > import urllib3
> >   File "\Efi\StdLib\lib\python.27\site-packages/urllib3/__init__.py",
> > line 8, in 
> > from .connectionpool import (
> >   File "\Efi\StdLib\lib\python.27\site-
> packages/urllib3/connectionpool.py",
> > line 28, in 
> > from .packages.six.moves import queue
> >   File 
> > "\Efi\StdLib\lib\python.27\site-packages/urllib3/packages/six.py",
> > line 203, in load_module
> > mod = mod._resolve()
> >   File 
> > "\Efi\StdLib\lib\python.27\site-packages/urllib3/packages/six.py",
> > line 115, in _resolve
> > return _import_module(self.mod)
> >   File 
> > "\Efi\StdLib\lib\python.27\site-packages/urllib3/packages/six.py",
> > line 82, in _import_module
> > __import__(name)
> >   File "\Efi\StdLib\lib\python.27/Queue.py", line 7, in 
> > import dummy_threading as _threading
> >   File "\Efi\StdLib\lib\python.27/dummy_threading.py", line 45, in
> > 
> > import threading
> > ImportError: No module named threading
> >
> >
> >
> > I understand that the script is now looking for the threading module and
> > after investigating further I realized I may have to turn on the threading
> > module as part of compiling python. So I modified the
> > \edk2\AppPkg\Applications\Python\X64\pyconfig.h file to change '#undef
> > WITH_THREAD' to '#define WITH_THREAD', but this is giving the following
> > compiling error. Any pointers please?
> >
> > "C:\Program Files (x86)\Microsoft Visual Studio
> > 11.0\Vc\bin\x86_amd64\cl.exe"
> /Foc:\users\user\documents\dev\uefi\edk2\edk
> > 2\Build\AppPkg\DEBUG_VS2012x86\X64\AppPkg\Applications\Pytho
> > n\PythonCore\OUTPUT\.\AutoGen.obj /nologo /c /WX /GS- /W4 /Gs32768
> /D
> > UNICODE /O1ib2s /GL /
> > Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Oi- /wd4018 /wd4054 /wd4055
> > /wd4101 /wd4131 /wd4152 /wd4204 /wd4210 /wd4244 /wd4267 /wd4305
> /wd4310
> > /wd4389 /
> > wd4701 /wd4702 /wd4706 /Ic:\users\user\documents\dev\
> > uefi\edk2\edk2\AppPkg\Applications\Python\X64
> /Ic:\users\user\documents\de
> > v\uefi\edk2\edk2\AppPkg\Applications\Python\Efi
> > /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Applications
> > \Python\Python-2.7.2\Include /DHAVE_MEMMOVE /DUSE_PYEXPAT_CAPI
> > /DXML_STATIC /X /Zc:wchar_t /D UEFI_C_SOURCE
> /Ic:\users\user\documents\dev\
> > uefi\edk2_
> > livecode_3_6_2016\edk2\AppPkg\Applications\Python\Python-
> 2.7.2\Modules\zlib
> > /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\A
> > pplications\Python\Python-2.7.2\Modules\expat
> > /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Applicat
> > ions\Python\PyMod-2.7.2
> > \Modules\expat  /Ic:\users\user\documents\dev\
> > uefi\edk2\edk2\AppPkg\Applications\Python\Python-
> 2.7.2\Modules\cjkcodecs
> > /Ic:\users
> >
> \user\documents\dev\uefi\edk2\edk2\AppPkg\Applications\Python\Pytho
> n-2.7.2\Modules\_io
> > /Ic:\users\user\documents\dev\uefi\edk2
> > _livecode_3_6_2016\edk2\AppPkg\Applications\Python\Python-
> 2.7.2\Modules
> > /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Appli
> > cations\Python\PyMod-2.7.2\Modules  /Ic:\users\user\documents\dev\
> > uefi\edk2\edk2\AppPkg\Applications\Python\Python-2.7.2\Objects
> > /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Applicat
> > ions\Python\PyMod-2.7.2\Objects  /Ic:\users\user\documents\dev\uefi
> > \edk2\edk2\AppPkg\Applications\Python\Python-2.7.2\Python
> > /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\A
> > pplications\Python\PyMod-2.7.2\Python 

Re: [edk2] Possible UEFI Shell DrvDiag Command Error

2017-04-24 Thread Carsey, Jaben
I would say the shell should not free the GUID.

> -Original Message-
> From: jim.dai...@dell.com [mailto:jim.dai...@dell.com]
> Sent: Monday, April 24, 2017 5:46 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Carsey, Jaben 
> Subject: [edk2] Possible UEFI Shell DrvDiag Command Error
> Importance: High
> 
> Although this question is about the shell's drvdiag command, the answer
> is related to the interpretation of the UEFI specification with respect
> to the diagnostics protocol's RunDiagnostics() function.
> 
> Ultimately, the question is, is the drvdiag command in error in trying
> to free the ErrorType pointer, or is a driver vendor in error when they
> return an ErrorType parameter that does not point to memory that was
> allocated using gBS->AllocatePool?
> 
> The diagnostics protocol's RunDiagnostics() function is partially
> described in the UEFI spec like this:
> 
>   typedef
>   EFI_STATUS
>   (EFIAPI *EFI_DRIVER_DIAGNOSTICS2_RUN_DIAGNOSTICS) (
> IN EFI_DRIVER_DIAGNOSTICS2_PROTOCOL *This,
> ...
> OUT EFI_GUID**ErrorType,
> OUT UINTN   *BufferSize,
> OUT CHAR16  **Buffer
> );
> 
>   ...
> 
>   ErrorType   A GUID that defines the format of the data returned in
>   Buffer.
>   BufferSize  The size, in bytes, of the data returned in Buffer.
>   Buffer  A buffer that contains a Null-terminated string plus
>   some additional data whose format is defined by
>   ErrorType. Buffer is allocated by this function with
>   EFI_BOOT_SERVICES.AllocatePool(), and it is the
>   caller's responsibility to free it with a call to
>   EFI_BOOT_SERVICES.FreePool().
> 
> After a call to RunDiagnostics, the drvdiag command attempts to free the
> ErrorType pointer if it is non-NULL, yet nothing in the UEFI spec says
> that this is proper.
> 
> 1234567890123456789012345678901234567890123456789012345678901234567
> 89012
> The UEFI spec goes to great length to point out that *Buffer* must be
> allocated by the callee using gBS->AllocatePool and that the caller must
> use gBS->FreePool to release the memory once it is no longer needed.
> However, there is no such language with respect to ErrorType.
> 
> So, repeating the question, is the drvdiag command in error in trying
> to free the ErrorType pointer, or is a driver vendor in error when they
> return an ErrorType parameter that does not point to memory that was
> allocated using gBS->AllocatePool?
> 
> Regards,
> Jim
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH V2 4/4] MdePkg/dsc: add SmmIoLib

2017-04-24 Thread Jiewen Yao
Cc: Jeff Fan 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdePkg/MdePkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index 8b69de3..d9c2c32 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -154,6 +154,7 @@
   MdePkg/Library/BaseS3SmbusLib/BaseS3SmbusLib.inf
   MdePkg/Library/BaseS3StallLib/BaseS3StallLib.inf
   MdePkg/Library/SmmMemLib/SmmMemLib.inf
+  MdePkg/Library/SmmIoLib/SmmIoLib.inf
   MdePkg/Library/BaseRngLib/BaseRngLib.inf
   MdePkg/Library/SmmPciExpressLib/SmmPciExpressLib.inf
   MdePkg/Library/SmiHandlerProfileLibNull/SmiHandlerProfileLibNull.inf
-- 
2.7.4.windows.1

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


[edk2] [PATCH V2 1/4] MdePkg/SmmIoLib: Add header file.

2017-04-24 Thread Jiewen Yao
This SmmIoLib is used to check if an IO resource
is valid in SMM.

Cc: Jeff Fan 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdePkg/Include/Library/SmmIoLib.h | 42 
 1 file changed, 42 insertions(+)

diff --git a/MdePkg/Include/Library/SmmIoLib.h 
b/MdePkg/Include/Library/SmmIoLib.h
new file mode 100644
index 000..7820f1e
--- /dev/null
+++ b/MdePkg/Include/Library/SmmIoLib.h
@@ -0,0 +1,42 @@
+/** @file
+  Provides services for SMM IO Operation.
+
+  The SMM IO Library provides function for checking if IO resource is 
accessible inside of SMM.
+
+  Copyright (c) 2017, 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 _SMM_IO_LIB_H_
+#define _SMM_IO_LIB_H_
+
+/**
+  This function check if the MMIO resource is valid per processor architecture 
and
+  valid per platform design.
+
+  @param BaseAddress  The MMIO start address to be checked.
+  @param Length   The MMIO length to be checked.
+  @param OwnerA GUID representing the owner of the resource.
+  This GUID may be used by producer to correlate the 
device ownership of the resource.
+  NULL means no specific owner.
+
+  @retval TRUE  This MMIO resource is valid per processor architecture and 
valid per platform design.
+  @retval FALSE This MMIO resource is not valid per processor architecture or 
valid per platform design.
+**/
+BOOLEAN
+EFIAPI
+SmmIsMmioValid (
+  IN EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN UINT64Length,
+  IN EFI_GUID  *Owner  OPTIONAL
+  );
+
+#endif
+
-- 
2.7.4.windows.1

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


[edk2] [PATCH V2 2/4] MdePkg/SmmIoLib: Add sample instance.

2017-04-24 Thread Jiewen Yao
The sample instance check if IO resource is valid
one defined in GCD.
A platform may choose add more check to exclude some
other IO resource.

Cc: Jeff Fan 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdePkg/Library/SmmIoLib/SmmIoLib.c   | 330 
 MdePkg/Library/SmmIoLib/SmmIoLib.inf |  53 
 MdePkg/Library/SmmIoLib/SmmIoLib.uni |  23 ++
 3 files changed, 406 insertions(+)

diff --git a/MdePkg/Library/SmmIoLib/SmmIoLib.c 
b/MdePkg/Library/SmmIoLib/SmmIoLib.c
new file mode 100644
index 000..181abb8
--- /dev/null
+++ b/MdePkg/Library/SmmIoLib/SmmIoLib.c
@@ -0,0 +1,330 @@
+/** @file
+  Instance of SMM IO check library.
+
+  SMM IO check library library implementation. This library consumes GCD to 
collect all valid
+  IO space defined by a platform.
+  A platform may have its own SmmIoLib instance to exclude more IO space.
+
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_GCD_MEMORY_SPACE_DESCRIPTOR   *mSmmIoLibGcdMemSpace   = NULL;
+UINTN mSmmIoLibGcdMemNumberOfDesc = 0;
+
+EFI_PHYSICAL_ADDRESS  mSmmIoLibInternalMaximumSupportMemAddress = 0;
+
+VOID  *mSmmIoLibRegistrationEndOfDxe;
+VOID  *mSmmIoLibRegistrationReadyToLock;
+
+BOOLEAN   mSmmIoLibReadyToLock = FALSE;
+
+/**
+  Calculate and save the maximum support address.
+
+**/
+VOID
+SmmIoLibInternalCalculateMaximumSupportAddress (
+  VOID
+  )
+{
+  VOID *Hob;
+  UINT32   RegEax;
+  UINT8MemPhysicalAddressBits;
+
+  //
+  // Get physical address bits supported.
+  //
+  Hob = GetFirstHob (EFI_HOB_TYPE_CPU);
+  if (Hob != NULL) {
+MemPhysicalAddressBits = ((EFI_HOB_CPU *) Hob)->SizeOfMemorySpace;
+  } else {
+AsmCpuid (0x8000, , NULL, NULL, NULL);
+if (RegEax >= 0x8008) {
+  AsmCpuid (0x8008, , NULL, NULL, NULL);
+  MemPhysicalAddressBits = (UINT8) RegEax;
+} else {
+  MemPhysicalAddressBits = 36;
+}
+  }
+  //
+  // IA-32e paging translates 48-bit linear addresses to 52-bit physical 
addresses.
+  //
+  ASSERT (MemPhysicalAddressBits <= 52);
+  if (MemPhysicalAddressBits > 48) {
+MemPhysicalAddressBits = 48;
+  }
+
+  //
+  // Save the maximum support address in one global variable
+  //
+  mSmmIoLibInternalMaximumSupportMemAddress = 
(EFI_PHYSICAL_ADDRESS)(UINTN)(LShiftU64 (1, MemPhysicalAddressBits) - 1);
+  DEBUG ((DEBUG_INFO, "mSmmIoLibInternalMaximumSupportMemAddress = 0x%lx\n", 
mSmmIoLibInternalMaximumSupportMemAddress));
+}
+
+/**
+  This function check if the MMIO resource is valid per processor architecture 
and
+  valid per platform design.
+
+  @param BaseAddress  The MMIO start address to be checked.
+  @param Length   The MMIO length to be checked.
+  @param OwnerA GUID representing the owner of the resource.
+  This GUID may be used by producer to correlate the 
device ownership of the resource.
+  NULL means no specific owner.
+
+  @retval TRUE  This MMIO resource is valid per processor architecture and 
valid per platform design.
+  @retval FALSE This MMIO resource is not valid per processor architecture or 
valid per platform design.
+**/
+BOOLEAN
+EFIAPI
+SmmIsMmioValid (
+  IN EFI_PHYSICAL_ADDRESS  BaseAddress,
+  IN UINT64Length,
+  IN EFI_GUID  *Owner  OPTIONAL
+  )
+{
+  UINTN   Index;
+  EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Desc;
+  BOOLEAN InValidRegion;
+
+  //
+  // Check override.
+  // NOTE: (B:0->L:4G) is invalid for IA32, but (B:1->L:4G-1)/(B:4G-1->L:1) is 
valid.
+  //
+  if ((Length > mSmmIoLibInternalMaximumSupportMemAddress) ||
+  (BaseAddress > mSmmIoLibInternalMaximumSupportMemAddress) ||
+  ((Length != 0) && (BaseAddress > 
(mSmmIoLibInternalMaximumSupportMemAddress - (Length - 1 ) {
+//
+// Overflow happen
+//
+DEBUG ((
+  DEBUG_ERROR,
+  "SmmIsMmioValid: Overflow: BaseAddress (0x%lx) - Length (0x%lx), 
MaximumSupportMemAddress (0x%lx)\n",
+  BaseAddress,
+  Length,
+  mSmmIoLibInternalMaximumSupportMemAddress
+  ));
+return FALSE;
+  }
+
+  //
+  // Check override for valid MMIO region
+  //
+  if (mSmmIoLibReadyToLock) {
+InValidRegion = FALSE;
+for (Index = 0; Index < 

[edk2] [PATCH V2 3/4] MdePkg/dec: Add SmmIoLib.

2017-04-24 Thread Jiewen Yao
Cc: Jeff Fan 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdePkg/MdePkg.dec | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 3310029..5774417 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -246,6 +246,10 @@
   #
   SmmMemLib|Include/Library/SmmMemLib.h
 
+  ##  @libraryclass  Provides services for Smm IO Operation.
+  #
+  SmmIoLib|Include/Library/SmmIoLib.h
+
   ##  @libraryclass  Provides services to enable/disable periodic SMI handlers.
   #
   SmmPeriodicSmiLib|Include/Library/SmmPeriodicSmiLib.h
-- 
2.7.4.windows.1

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



[edk2] [PATCH V2 0/4] Add SmmIoLib

2017-04-24 Thread Jiewen Yao
 V2 
Remove ASSERT(FALSE). (From Jeff Fan)

 V1 

This patch series add SmmIoLib.
It is the first part of bugzillar 491.
https://bugzilla.tianocore.org/show_bug.cgi?id=491
Move generic function - OpalIsValidMmioSpace from OPAL
driver to library.

This SmmIoLib is similar to SmmMemLib.

The second part of bugzillar 491 is to update consumer
SecurityPkg/Tcg/Opal/OpalPasswordSmm. It will be
handled in future patch series.

Jiewen Yao (4):
  MdePkg/SmmIoLib: Add header file.
  MdePkg/SmmIoLib: Add sample instance.
  MdePkg/dec: Add SmmIoLib.
  MdePkg/dsc: add SmmIoLib

 MdePkg/Include/Library/SmmIoLib.h|  42 +++
 MdePkg/Library/SmmIoLib/SmmIoLib.c   | 330 
 MdePkg/Library/SmmIoLib/SmmIoLib.inf |  53 
 MdePkg/Library/SmmIoLib/SmmIoLib.uni |  23 ++
 MdePkg/MdePkg.dec|   4 +
 MdePkg/MdePkg.dsc|   1 +
 6 files changed, 453 insertions(+)
 create mode 100644 MdePkg/Include/Library/SmmIoLib.h
 create mode 100644 MdePkg/Library/SmmIoLib/SmmIoLib.c
 create mode 100644 MdePkg/Library/SmmIoLib/SmmIoLib.inf
 create mode 100644 MdePkg/Library/SmmIoLib/SmmIoLib.uni

-- 
2.7.4.windows.1

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


[edk2] Possible UEFI Shell DrvDiag Command Error

2017-04-24 Thread Jim.Dailey
Although this question is about the shell's drvdiag command, the answer
is related to the interpretation of the UEFI specification with respect
to the diagnostics protocol's RunDiagnostics() function.

Ultimately, the question is, is the drvdiag command in error in trying
to free the ErrorType pointer, or is a driver vendor in error when they
return an ErrorType parameter that does not point to memory that was
allocated using gBS->AllocatePool?

The diagnostics protocol's RunDiagnostics() function is partially
described in the UEFI spec like this:

  typedef
  EFI_STATUS
  (EFIAPI *EFI_DRIVER_DIAGNOSTICS2_RUN_DIAGNOSTICS) (
IN EFI_DRIVER_DIAGNOSTICS2_PROTOCOL *This,
...
OUT EFI_GUID**ErrorType,
OUT UINTN   *BufferSize,
OUT CHAR16  **Buffer
);

  ...

  ErrorType   A GUID that defines the format of the data returned in
  Buffer.
  BufferSize  The size, in bytes, of the data returned in Buffer.
  Buffer  A buffer that contains a Null-terminated string plus
  some additional data whose format is defined by
  ErrorType. Buffer is allocated by this function with
  EFI_BOOT_SERVICES.AllocatePool(), and it is the
  caller's responsibility to free it with a call to
  EFI_BOOT_SERVICES.FreePool().

After a call to RunDiagnostics, the drvdiag command attempts to free the
ErrorType pointer if it is non-NULL, yet nothing in the UEFI spec says
that this is proper.

123456789012345678901234567890123456789012345678901234567890123456789012
The UEFI spec goes to great length to point out that *Buffer* must be
allocated by the callee using gBS->AllocatePool and that the caller must
use gBS->FreePool to release the memory once it is no longer needed.
However, there is no such language with respect to ErrorType.

So, repeating the question, is the drvdiag command in error in trying
to free the ErrorType pointer, or is a driver vendor in error when they
return an ErrorType parameter that does not point to memory that was
allocated using gBS->AllocatePool?

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


Re: [edk2] Python issue in UEFI shell

2017-04-24 Thread KT
Hello,
Can someone please shed some light on this issue?

Thanks

Thanks
On Tue, Apr 18, 2017 at 2:56 PM, KT  wrote:

> Hi experts,
>
> I am experimenting python scripts in UEFI shell and as part of the first
> step I tried compiling python as per the instructions in
> edk2\AppPkg\Applications\Python\PythonReadMe.txt.  However when I run my
> script, I noticed that it required third-party modules (requests, urllib3
> etc). So I manually copied these under the 
> \EFI\StdLib\lib\python.27\site-packages
> folder (not sure if that is the correct way). That said currently my script
> is failing as follows:
>
> Traceback (most recent call last):
>   File "rest_json.py", line 11, in 
> import requests
>   File "\Efi\StdLib\lib\python.27\site-packages/requests/__init__.py",
> line 60, in 
> from .packages.urllib3.exceptions import DependencyWarning
>   File 
> "\Efi\StdLib\lib\python.27\site-packages/requests/packages/__init__.py",
> line 29, in 
> import urllib3
>   File "\Efi\StdLib\lib\python.27\site-packages/urllib3/__init__.py",
> line 8, in 
> from .connectionpool import (
>   File 
> "\Efi\StdLib\lib\python.27\site-packages/urllib3/connectionpool.py",
> line 28, in 
> from .packages.six.moves import queue
>   File "\Efi\StdLib\lib\python.27\site-packages/urllib3/packages/six.py",
> line 203, in load_module
> mod = mod._resolve()
>   File "\Efi\StdLib\lib\python.27\site-packages/urllib3/packages/six.py",
> line 115, in _resolve
> return _import_module(self.mod)
>   File "\Efi\StdLib\lib\python.27\site-packages/urllib3/packages/six.py",
> line 82, in _import_module
> __import__(name)
>   File "\Efi\StdLib\lib\python.27/Queue.py", line 7, in 
> import dummy_threading as _threading
>   File "\Efi\StdLib\lib\python.27/dummy_threading.py", line 45, in
> 
> import threading
> ImportError: No module named threading
>
>
>
> I understand that the script is now looking for the threading module and
> after investigating further I realized I may have to turn on the threading
> module as part of compiling python. So I modified the
> \edk2\AppPkg\Applications\Python\X64\pyconfig.h file to change '#undef
> WITH_THREAD' to '#define WITH_THREAD', but this is giving the following
> compiling error. Any pointers please?
>
> "C:\Program Files (x86)\Microsoft Visual Studio
> 11.0\Vc\bin\x86_amd64\cl.exe" /Foc:\users\user\documents\dev\uefi\edk2\edk
> 2\Build\AppPkg\DEBUG_VS2012x86\X64\AppPkg\Applications\Pytho
> n\PythonCore\OUTPUT\.\AutoGen.obj /nologo /c /WX /GS- /W4 /Gs32768 /D
> UNICODE /O1ib2s /GL /
> Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Oi- /wd4018 /wd4054 /wd4055
> /wd4101 /wd4131 /wd4152 /wd4204 /wd4210 /wd4244 /wd4267 /wd4305 /wd4310
> /wd4389 /
> wd4701 /wd4702 /wd4706 /Ic:\users\user\documents\dev\
> uefi\edk2\edk2\AppPkg\Applications\Python\X64 /Ic:\users\user\documents\de
> v\uefi\edk2\edk2\AppPkg\Applications\Python\Efi
> /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Applications
> \Python\Python-2.7.2\Include /DHAVE_MEMMOVE /DUSE_PYEXPAT_CAPI
> /DXML_STATIC /X /Zc:wchar_t /D UEFI_C_SOURCE /Ic:\users\user\documents\dev\
> uefi\edk2_
> livecode_3_6_2016\edk2\AppPkg\Applications\Python\Python-2.7.2\Modules\zlib
> /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\A
> pplications\Python\Python-2.7.2\Modules\expat
> /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Applicat
> ions\Python\PyMod-2.7.2
> \Modules\expat  /Ic:\users\user\documents\dev\
> uefi\edk2\edk2\AppPkg\Applications\Python\Python-2.7.2\Modules\cjkcodecs
> /Ic:\users
> \user\documents\dev\uefi\edk2\edk2\AppPkg\Applications\Python\Python-2.7.2\Modules\_io
> /Ic:\users\user\documents\dev\uefi\edk2
> _livecode_3_6_2016\edk2\AppPkg\Applications\Python\Python-2.7.2\Modules
> /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Appli
> cations\Python\PyMod-2.7.2\Modules  /Ic:\users\user\documents\dev\
> uefi\edk2\edk2\AppPkg\Applications\Python\Python-2.7.2\Objects
> /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Applicat
> ions\Python\PyMod-2.7.2\Objects  /Ic:\users\user\documents\dev\uefi
> \edk2\edk2\AppPkg\Applications\Python\Python-2.7.2\Python
> /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\A
> pplications\Python\PyMod-2.7.2\Python  /Ic:\users\user\documents\dev\
> uefi\edk2\edk2\AppPkg\Applications\Python\Python-2.7.2\Parser
>   /Ic:\users\user\documents\dev\uefi\edk2\edk2\AppPkg\Applications\Python\Efi
> /Ic:\users\user\documents\dev\uefi\edk2_livecode
> _3_6_2016\edk2\AppPkg\Applications\Python  /Ic:\users\user\documents\dev\
> uefi\edk2\edk2\Build\AppPkg\DEBUG_VS2012x86\X64\AppPkg\Ap
> plications\Python\PythonCore\DEBUG  
> /Ic:\users\user\documents\dev\uefi\edk2\edk2\StdLib
> /Ic:\users\user\documents\dev\uefi\edk
> 2_livecode_3_6_2016\edk2\StdLib\Include  /Ic:\users\user\documents\dev\
> uefi\edk2\edk2\StdLib\Include\X64  /Ic:\users\user\docum
> 

[edk2] [MAC HELP] Does Mac has a grubx64.efi ?

2017-04-24 Thread Amit kumar
Hi ,

I am trying to boot a mac OS X from the efi shell so i opened the EFI partition.
As usual there was EFI directory inside which there was APPLE director.
so i went to EFI/APPLE director and found out there where two more directories 
inside /EFI/APPLE
1. FIRMWARE and 2. EXTENSIONS but there was no grubx64.efi like linux system.
E.g 
we can boot ubutu using :
EFI/ubuntu/grubx64.efi 
and for windows we have
EFI/Boot/BOOTX64.efi 

i found out there is a ThorUtil.efi in /EFI/APPLE/FIRMWARE  but when i try to 
run it, it says ThorUtil.efi is not recognized as an internal or external 
command, operable program, or a batch file. 


Can some help me booting a mac OS from UEFI shell.
P.S :: I have a mac air 13, intel i5, OS X

Thanks And Regards
Amit Kumar 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Lock should be acquired

2017-04-24 Thread Laszlo Ersek
Hi Jeff,

On 04/18/17 04:16, Jeff Fan wrote:
> SMM BSP's *busy* state should be acquired. We could use AcquireSpinLock()
> instead of AcquireSpinLockOrFail().
> 
> Cc: Hao Wu 
> Cc: Feng Tian 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index a1d16b4..e03f1e0 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -407,7 +407,7 @@ BSPHandler (
>//
>// The BUSY lock is initialized to Acquired state
>//
> -  AcquireSpinLockOrFail (mSmmMpSyncData->CpuData[CpuIndex].Busy);
> +  AcquireSpinLock (mSmmMpSyncData->CpuData[CpuIndex].Busy);
>  
>//
>// Perform the pre tasks
> 

what symptoms did you experience without the fix?

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


Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

2017-04-24 Thread Laszlo Ersek
On 04/21/17 15:27, gengdongjiu wrote:
> Hi all/Laszlo,
> 
>   sorry, I have a question to consult with you.
> 
> 
> On 2017/4/7 2:55, Laszlo Ersek wrote:
>> On 04/06/17 14:35, gengdongjiu wrote:
>>> Dear, Laszlo
>>>Thanks for your detailed explanation.
>>>
>>> On 2017/3/29 19:58, Laszlo Ersek wrote:
 (This ought to be one of the longest address lists I've ever seen :)
 Thanks for the CC. I'm glad Shannon is already on the CC list. For good
 measure, I'm adding MST and Igor.)

 On 03/29/17 12:36, Achin Gupta wrote:
> Hi gengdongjiu,
>
> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:
>>
>> Hi Laszlo/Biesheuvel/Qemu developer,
>>
>>Now I encounter a issue and want to consult with you in ARM64 
>> platform, as described below:
>>
>> when guest OS happen synchronous or asynchronous abort, kvm needs
>> to send the error address to Qemu or UEFI through sigbus to
>> dynamically generate APEI table. from my investigation, there are
>> two ways:
>>
>> (1) Qemu get the error address, and generate the APEI table, then
>> notify UEFI to know this generation, then inject abort error to
>> guest OS, guest OS read the APEI table.
>> (2) Qemu get the error address, and let UEFI to generate the APEI
>> table, then inject abort error to guest OS, guest OS read the APEI
>> table.
>
> Just being pedantic! I don't think we are talking about creating the APEI 
> table
> dynamically here. The issue is: Once KVM has received an error that is 
> destined
> for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject 
> the error
> into the guest OS, a CPER (Common Platform Error Record) has to be 
> generated
> corresponding to the error source (GHES corresponding to memory subsystem,
> processor etc) to allow the guest OS to do anything meaningful with the
> error. So who should create the CPER is the question.
>
> At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error 
> arrives
> at EL3 and secure firmware (at EL3 or a lower secure exception level) is
> responsible for creating the CPER. ARM is experimenting with using a 
> Standalone
> MM EDK2 image in the secure world to do the CPER creation. This will avoid
> adding the same code in ARM TF in EL3 (better for security). The error 
> will then
> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM 
> Trusted
> Firmware.
>
> Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1
> interface (as discussed with Christoffer below). So it should generate 
> the CPER
> before injecting the error.
>
> This is corresponds to (1) above apart from notifying UEFI (I am assuming 
> you
> mean guest UEFI). At this time, the guest OS already knows where to pick 
> up the
> CPER from through the HEST. Qemu has to create the CPER and populate its 
> address
> at the address exported in the HEST. Guest UEFI should not be involved in 
> this
> flow. Its job was to create the HEST at boot and that has been done by 
> this
> stage.
>
> Qemu folk will be able to add but it looks like support for CPER 
> generation will
> need to be added to Qemu. We need to resolve this.
>
> Do shout if I am missing anything above.

 After reading this email, the use case looks *very* similar to what
 we've just done with VMGENID for QEMU 2.9.

 We have a facility between QEMU and the guest firmware, called "ACPI
 linker/loader", with which QEMU instructs the firmware to

 - allocate and download blobs into guest RAM (AcpiNVS type memory) --
 ALLOCATE command,

 - relocate pointers in those blobs, to fields in other (or the same)
 blobs -- ADD_POINTER command,

 - set ACPI table checksums -- ADD_CHECKSUM command,

 - and send GPAs of fields within such blobs back to QEMU --
 WRITE_POINTER command.

 This is how I imagine we can map the facility to the current use case
 (note that this is the first time I read about HEST / GHES / CPER):
> 
> Laszlo lists a Qemu GHES table generation solution, Mainly use the
> four commands: "ALLOCATE/ADD_POINTER/ADD_CHECKSUM/WRITE_POINTER" to
> communicate with BIOS so whether the four commands needs to be
> supported by the guest firware/UEFI.  I found the  "WRITE_POINTER"
> always failed. so I suspect guest UEFI/firmware not support the
> "WRITE_POINTER" command. please help me confirm it, thanks so much.

That's incorrect, both OVMF and ArmVirtQemu support the WRITE_POINTER
command (see .) A
number of OvmfPkg/ modules are included in ArmVirtPkg binaries as well.

In QEMU, the WRITE_POINTER command is currently generated for the
VMGENID device only. If you try to test VMGENID with 

Re: [edk2] ARM virt machine boots fail with 14 ioh3420

2017-04-24 Thread Marcel Apfelbaum

On 04/24/2017 01:02 PM, Laszlo Ersek wrote:

On 04/14/17 04:41, Shannon Zhao wrote:

Hi Laszlo,

Thanks a lot for your reply:)

On 2017/4/14 1:09, Laszlo Ersek wrote:

Adding Andrea, Ard, Drew and Marcel; and the main qemu list

On 04/13/17 09:37, Shannon Zhao wrote:

Hi,

I'm testing the PCIe devices hotplug for ARM virt machine and using
ioh3420 as root port. I found that below command line could work.

qemu-system-aarch64 -machine virt,accel=kvm,usb=off -cpu host -bios
QEMU_EFI.fd -m 12288 -smp 8,sockets=8,cores=1,threads=1  -device
ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,addr=0x1 -device
ioh3420,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x2 -device
ioh3420,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x3 -device
ioh3420,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x4 -device
ioh3420,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x5 -device
ioh3420,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x6 -device
ioh3420,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x7 -device
ioh3420,port=0xf,chassis=8,id=pci.8,bus=pcie.0,addr=0x8 -device
ioh3420,port=0x10,chassis=9,id=pci.9,bus=pcie.0,addr=0x9 -device
ioh3420,port=0x11,chassis=10,id=pci.10,bus=pcie.0,addr=0xa -device
ioh3420,port=0x12,chassis=11,id=pci.11,bus=pcie.0,addr=0xb -device
ioh3420,port=0x13,chassis=12,id=pci.12,bus=pcie.0,addr=0xc -device
ioh3420,port=0x14,chassis=13,id=pci.13,bus=pcie.0,addr=0xd -device
i82801b11-bridge,id=pci.17,bus=pcie.0,addr=0x11 -device
pci-bridge,chassis_nr=18,id=pci.18,bus=pci.17,addr=0x0 -device
usb-ehci,id=usb,bus=pci.18,addr=0x1 -device
virtio-scsi-pci,id=scsi0,bus=pci.1,addr=0x0,disable-legacy=on,disable-modern=off
-drive
file=/mnt/sdb/guest.raw,format=raw,if=none,id=drive-scsi0-0-0-0,cache=none,aio=native
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
-netdev tap,id=hostnet1,vhost=on -device
virtio-net-pci,netdev=hostnet1,id=net1,mac=00:16:3e:2b:cc:e1,bus=pci.2,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet2,vhost=on -device
virtio-net-pci,netdev=hostnet2,id=net2,mac=00:16:3e:22:29:80,bus=pci.3,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet3,vhost=on -device
virtio-net-pci,netdev=hostnet3,id=net3,mac=00:16:3e:28:07:9a,bus=pci.4,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet4,vhost=on -device
virtio-net-pci,netdev=hostnet4,id=net4,mac=00:16:3e:3d:cd:b6,bus=pci.5,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet5,vhost=on -device
virtio-net-pci,netdev=hostnet5,id=net5,mac=00:16:3e:64:9f:b0,bus=pci.6,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet6,vhost=on -device
virtio-net-pci,netdev=hostnet6,id=net6,mac=00:16:3e:33:5b:d3,bus=pci.7,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet7,vhost=on -device
virtio-net-pci,netdev=hostnet7,id=net7,mac=00:16:3e:39:7c:df,bus=pci.8,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet8,vhost=on -device
virtio-net-pci,netdev=hostnet8,id=net8,mac=00:16:3e:0a:c1:4e,bus=pci.9,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet9,vhost=on -device
virtio-net-pci,netdev=hostnet9,id=net9,mac=00:16:3e:0a:58:a6,bus=pci.10,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet10,vhost=on -device
virtio-net-pci,netdev=hostnet10,id=net10,mac=00:16:3e:35:b5:80,bus=pci.11,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet11,vhost=on -device
virtio-net-pci,netdev=hostnet11,id=net11,mac=00:16:3e:4d:b5:bb,bus=pci.12,addr=0x0,disable-legacy=on,disable-modern=off
-netdev tap,id=hostnet12,vhost=on -device
virtio-net-pci,netdev=hostnet12,id=net12,mac=00:16:3e:3b:69:e9,bus=pci.13,addr=0x0,disable-legacy=on,disable-modern=off
-nographic

But if I add one more ioh3420 device by appending above command with
"-device ioh3420,port=0x15,chassis=14,id=pci.14,bus=pcie.0,addr=0xe",
the guest can't boot. It seems that the firmware doesn't recognize the
PCIe devices and print "Connect: PciRoot(0x0): Not Found".

I'm using QEMU 2.8.1 and edk2 at commit 36a0d5c. Is there any limitation
of the supported PCIe devices?


In one sentence: you are running out of (emulated) IO space.

Aarch64 does not have "IO space", but with QEMU, using the "virt"
machine type, we emulate 64KB of IO space, mapped to a special MMIO
range. This is available for PCI resource allocation, for such devices
that have IO BARs (and for such PCI bridges that reserve IO space for
hotplug purposes).

The ioh3420 PCI Express Root Port device represents such a bridge. Even
if you plug a PCI Express device into it that has only MMIO BARs, the
bridge still advertises IO support, and it causes the firmware (and/or
Linux) to reserve 4KB of IO space. With ~15-16 such ports, you run out
of the 64 KB IO aperture, and the resource assignment fails.


So currently if we want to support more than ~15 virtio-net-pci devices,
they can't connect to root port.


Right.


They should connect to pcie root bus
directly, 

Re: [edk2] ARM virt machine boots fail with 14 ioh3420

2017-04-24 Thread Laszlo Ersek
On 04/14/17 04:41, Shannon Zhao wrote:
> Hi Laszlo,
> 
> Thanks a lot for your reply:)
> 
> On 2017/4/14 1:09, Laszlo Ersek wrote:
>> Adding Andrea, Ard, Drew and Marcel; and the main qemu list
>>
>> On 04/13/17 09:37, Shannon Zhao wrote:
>>> Hi,
>>>
>>> I'm testing the PCIe devices hotplug for ARM virt machine and using
>>> ioh3420 as root port. I found that below command line could work.
>>>
>>> qemu-system-aarch64 -machine virt,accel=kvm,usb=off -cpu host -bios
>>> QEMU_EFI.fd -m 12288 -smp 8,sockets=8,cores=1,threads=1  -device
>>> ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,addr=0x1 -device
>>> ioh3420,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x2 -device
>>> ioh3420,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x3 -device
>>> ioh3420,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x4 -device
>>> ioh3420,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x5 -device
>>> ioh3420,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x6 -device
>>> ioh3420,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x7 -device
>>> ioh3420,port=0xf,chassis=8,id=pci.8,bus=pcie.0,addr=0x8 -device
>>> ioh3420,port=0x10,chassis=9,id=pci.9,bus=pcie.0,addr=0x9 -device
>>> ioh3420,port=0x11,chassis=10,id=pci.10,bus=pcie.0,addr=0xa -device
>>> ioh3420,port=0x12,chassis=11,id=pci.11,bus=pcie.0,addr=0xb -device
>>> ioh3420,port=0x13,chassis=12,id=pci.12,bus=pcie.0,addr=0xc -device
>>> ioh3420,port=0x14,chassis=13,id=pci.13,bus=pcie.0,addr=0xd -device
>>> i82801b11-bridge,id=pci.17,bus=pcie.0,addr=0x11 -device
>>> pci-bridge,chassis_nr=18,id=pci.18,bus=pci.17,addr=0x0 -device
>>> usb-ehci,id=usb,bus=pci.18,addr=0x1 -device
>>> virtio-scsi-pci,id=scsi0,bus=pci.1,addr=0x0,disable-legacy=on,disable-modern=off
>>> -drive
>>> file=/mnt/sdb/guest.raw,format=raw,if=none,id=drive-scsi0-0-0-0,cache=none,aio=native
>>> -device
>>> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
>>> -netdev tap,id=hostnet1,vhost=on -device
>>> virtio-net-pci,netdev=hostnet1,id=net1,mac=00:16:3e:2b:cc:e1,bus=pci.2,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet2,vhost=on -device
>>> virtio-net-pci,netdev=hostnet2,id=net2,mac=00:16:3e:22:29:80,bus=pci.3,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet3,vhost=on -device
>>> virtio-net-pci,netdev=hostnet3,id=net3,mac=00:16:3e:28:07:9a,bus=pci.4,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet4,vhost=on -device
>>> virtio-net-pci,netdev=hostnet4,id=net4,mac=00:16:3e:3d:cd:b6,bus=pci.5,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet5,vhost=on -device
>>> virtio-net-pci,netdev=hostnet5,id=net5,mac=00:16:3e:64:9f:b0,bus=pci.6,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet6,vhost=on -device
>>> virtio-net-pci,netdev=hostnet6,id=net6,mac=00:16:3e:33:5b:d3,bus=pci.7,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet7,vhost=on -device
>>> virtio-net-pci,netdev=hostnet7,id=net7,mac=00:16:3e:39:7c:df,bus=pci.8,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet8,vhost=on -device
>>> virtio-net-pci,netdev=hostnet8,id=net8,mac=00:16:3e:0a:c1:4e,bus=pci.9,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet9,vhost=on -device
>>> virtio-net-pci,netdev=hostnet9,id=net9,mac=00:16:3e:0a:58:a6,bus=pci.10,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet10,vhost=on -device
>>> virtio-net-pci,netdev=hostnet10,id=net10,mac=00:16:3e:35:b5:80,bus=pci.11,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet11,vhost=on -device
>>> virtio-net-pci,netdev=hostnet11,id=net11,mac=00:16:3e:4d:b5:bb,bus=pci.12,addr=0x0,disable-legacy=on,disable-modern=off
>>> -netdev tap,id=hostnet12,vhost=on -device
>>> virtio-net-pci,netdev=hostnet12,id=net12,mac=00:16:3e:3b:69:e9,bus=pci.13,addr=0x0,disable-legacy=on,disable-modern=off
>>> -nographic
>>>
>>> But if I add one more ioh3420 device by appending above command with
>>> "-device ioh3420,port=0x15,chassis=14,id=pci.14,bus=pcie.0,addr=0xe",
>>> the guest can't boot. It seems that the firmware doesn't recognize the
>>> PCIe devices and print "Connect: PciRoot(0x0): Not Found".
>>>
>>> I'm using QEMU 2.8.1 and edk2 at commit 36a0d5c. Is there any limitation
>>> of the supported PCIe devices?
>>
>> In one sentence: you are running out of (emulated) IO space.
>>
>> Aarch64 does not have "IO space", but with QEMU, using the "virt"
>> machine type, we emulate 64KB of IO space, mapped to a special MMIO
>> range. This is available for PCI resource allocation, for such devices
>> that have IO BARs (and for such PCI bridges that reserve IO space for
>> hotplug purposes).
>>
>> The ioh3420 PCI Express Root Port device represents such a bridge. Even
>> if you plug a PCI Express device into it that has only MMIO BARs, the
>> bridge still advertises IO support, and it causes the firmware (and/or
>> Linux) to reserve 4KB of IO space. With ~15-16 such 

[edk2] [PATCH] CorebootModulePkg, EmulatorPkg, Vlv2TbltDevicePkg: .inf whitespace fixes

2017-04-24 Thread Leif Lindholm
Incorrect line endings, trailing spaces and missing line break at end
of file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---

This addresses only issues found when hacking on some scripts for
sanity checking .inf files.

Since trivial[1], would prefer not to split into one patch per
package.

[1] git diff -w  --word-diff-regex=[^[:space:]] HEAD~1
does not generate any output.

 CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
 |  96 
 
CorebootModulePkg/Library/CbPlatformSupportLibNull/CbPlatformSupportLibNull.inf 
|  70 +-
 CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf  
 |  98 
 EmulatorPkg/Library/DxeEmuPeCoffExtraActionLib/DxeEmuPeCoffExtraActionLib.inf  
 |  96 
 EmulatorPkg/Library/PeiEmuPeCoffExtraActionLib/PeiEmuPeCoffExtraActionLib.inf  
 |  98 
 EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
 |  94 
 Vlv2TbltDevicePkg/PlatformInitPei/PlatformInitPei.inf  
 |  18 ++---
 Vlv2TbltDevicePkg/SmBiosMiscDxe/SmBiosMiscDxe.inf  
 | 290 
 8 files changed, 430 insertions(+), 430 deletions(-)

diff --git 
a/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf 
b/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
index cd758ae4bf..77075ccc95 100644
--- 
a/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
+++ 
b/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
@@ -1,48 +1,48 @@
-## @file
-#  SerialPortLib instance for 16550 UART.
-#
-#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  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  = BaseSerialPortLib16550
-  MODULE_UNI_FILE= BaseSerialPortLib16550.uni
-  FILE_GUID  = 9E7C00CF-355A-4d4e-BF60-0428CFF95540
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.1
-  LIBRARY_CLASS  = SerialPortLib
-
-[Packages]
-  MdePkg/MdePkg.dec
-  MdeModulePkg/MdeModulePkg.dec
-
-[LibraryClasses]
-  PcdLib
-  IoLib
-  PlatformHookLib
-  PciLib
-
-[Sources]
-  BaseSerialPortLib16550.c
-
-[Pcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl  ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialDetectCable ## 
SOMETIMES_CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialLineControl ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialFifoControl ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate   ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialPciDeviceInfo   ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialExtendedTxFifoSize  ## CONSUMES
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride  ## CONSUMES
+## @file
+#  SerialPortLib instance for 16550 UART.
+#
+#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  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  = BaseSerialPortLib16550
+  MODULE_UNI_FILE= BaseSerialPortLib16550.uni
+  FILE_GUID  = 9E7C00CF-355A-4d4e-BF60-0428CFF95540
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.1
+  LIBRARY_CLASS  = SerialPortLib
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  PcdLib
+  IoLib
+  PlatformHookLib
+  PciLib
+
+[Sources]
+  BaseSerialPortLib16550.c
+
+[Pcd]
+  

Re: [edk2] [Patch] MdeModulePkg: Update PiSmmCore to set correct ImageAddress into LoadedImage

2017-04-24 Thread Zeng, Star
Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: Gao, Liming 
Sent: Monday, April 24, 2017 4:57 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: [Patch] MdeModulePkg: Update PiSmmCore to set correct ImageAddress 
into LoadedImage

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Core/PiSmmCore/Dispatcher.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/Dispatcher.c 
b/MdeModulePkg/Core/PiSmmCore/Dispatcher.c
index b2a6822..f32bbbd 100644
--- a/MdeModulePkg/Core/PiSmmCore/Dispatcher.c
+++ b/MdeModulePkg/Core/PiSmmCore/Dispatcher.c
@@ -596,7 +596,7 @@ SmmLoadImage (
   }
   CopyMem (DriverEntry->LoadedImage->FilePath, FilePath, GetDevicePathSize 
(FilePath));
 
-  DriverEntry->LoadedImage->ImageBase = (VOID 
*)(UINTN)DriverEntry->ImageBuffer;
+  DriverEntry->LoadedImage->ImageBase = (VOID *)(UINTN) 
ImageContext.ImageAddress;
   DriverEntry->LoadedImage->ImageSize = ImageContext.ImageSize;
   DriverEntry->LoadedImage->ImageCodeType = EfiRuntimeServicesCode;
   DriverEntry->LoadedImage->ImageDataType = EfiRuntimeServicesData; @@ -615,7 
+615,7 @@ SmmLoadImage (
   }
   CopyMem (DriverEntry->SmmLoadedImage.FilePath, FilePath, 
GetDevicePathSize(FilePath));
 
-  DriverEntry->SmmLoadedImage.ImageBase = (VOID 
*)(UINTN)DriverEntry->ImageBuffer;
+  DriverEntry->SmmLoadedImage.ImageBase = (VOID *)(UINTN) 
+ ImageContext.ImageAddress;
   DriverEntry->SmmLoadedImage.ImageSize = ImageContext.ImageSize;
   DriverEntry->SmmLoadedImage.ImageCodeType = EfiRuntimeServicesCode;
   DriverEntry->SmmLoadedImage.ImageDataType = EfiRuntimeServicesData;
--
2.8.0.windows.1

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


Re: [edk2] [Patch] MdeModulePkg PiSmmIpl: Fix the issue in LMFA feature

2017-04-24 Thread Zeng, Star
Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Monday, April 24, 2017 4:58 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: [edk2] [Patch] MdeModulePkg PiSmmIpl: Fix the issue in LMFA feature

SmramBase should be got from mLMFAConfigurationTable.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index feb846e..2601275 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -263,6 +263,7 @@ EFI_PHYSICAL_ADDRESS   mSmramCacheBase;
 UINT64 mSmramCacheSize;
 
 EFI_SMM_COMMUNICATE_HEADER mCommunicateHeader;
+EFI_LOAD_FIXED_ADDRESS_CONFIGURATION_TABLE*mLMFAConfigurationTable = NULL;
 
 //
 // Table of Protocol notification and GUIDed Event notifications that the SMM 
IPL requires @@ -841,7 +842,7 @@ GetPeCoffImageFixLoadingAssignedAddress(
  
FixLoadingAddress = 0;
Status = EFI_NOT_FOUND;
-   SmramBase = mCurrentSmramRange->CpuStart;
+   SmramBase = mLMFAConfigurationTable->SmramBase;
//
// Get PeHeader pointer
//
@@ -1519,7 +1520,6 @@ SmmIplEntry (
   UINT64  MaxSize;
   VOID*Registration;
   UINT64  SmmCodeSize;
-  EFI_LOAD_FIXED_ADDRESS_CONFIGURATION_TABLE*LMFAConfigurationTable;
   EFI_CPU_ARCH_PROTOCOL   *CpuArch;
   EFI_STATUS  SetAttrStatus;
   EFI_SMRAM_DESCRIPTOR*SmramRangeSmmDriver;
@@ -1623,14 +1623,14 @@ SmmIplEntry (
   //
   Status = EfiGetSystemConfigurationTable (
 ,
-   (VOID **) 
+   (VOID **) 
);
-  if (!EFI_ERROR (Status) && LMFAConfigurationTable != NULL) {
-LMFAConfigurationTable->SmramBase = mCurrentSmramRange->CpuStart;
+  if (!EFI_ERROR (Status) && mLMFAConfigurationTable != NULL) {
+mLMFAConfigurationTable->SmramBase = 
+ mCurrentSmramRange->CpuStart;
 //
 // Print the SMRAM base
 //
-DEBUG ((EFI_D_INFO, "LOADING MODULE FIXED INFO: TSEG BASE is %x. \n", 
LMFAConfigurationTable->SmramBase));
+DEBUG ((EFI_D_INFO, "LOADING MODULE FIXED INFO: TSEG BASE is 
+ %x. \n", mLMFAConfigurationTable->SmramBase));
   }
 
   //
--
2.8.0.windows.1

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


[edk2] [Patch] MdeModulePkg: Update PiSmmCore to set correct ImageAddress into LoadedImage

2017-04-24 Thread Liming Gao
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Core/PiSmmCore/Dispatcher.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/Dispatcher.c 
b/MdeModulePkg/Core/PiSmmCore/Dispatcher.c
index b2a6822..f32bbbd 100644
--- a/MdeModulePkg/Core/PiSmmCore/Dispatcher.c
+++ b/MdeModulePkg/Core/PiSmmCore/Dispatcher.c
@@ -596,7 +596,7 @@ SmmLoadImage (
   }
   CopyMem (DriverEntry->LoadedImage->FilePath, FilePath, GetDevicePathSize 
(FilePath));
 
-  DriverEntry->LoadedImage->ImageBase = (VOID 
*)(UINTN)DriverEntry->ImageBuffer;
+  DriverEntry->LoadedImage->ImageBase = (VOID *)(UINTN) 
ImageContext.ImageAddress;
   DriverEntry->LoadedImage->ImageSize = ImageContext.ImageSize;
   DriverEntry->LoadedImage->ImageCodeType = EfiRuntimeServicesCode;
   DriverEntry->LoadedImage->ImageDataType = EfiRuntimeServicesData;
@@ -615,7 +615,7 @@ SmmLoadImage (
   }
   CopyMem (DriverEntry->SmmLoadedImage.FilePath, FilePath, 
GetDevicePathSize(FilePath));
 
-  DriverEntry->SmmLoadedImage.ImageBase = (VOID 
*)(UINTN)DriverEntry->ImageBuffer;
+  DriverEntry->SmmLoadedImage.ImageBase = (VOID *)(UINTN) 
ImageContext.ImageAddress;
   DriverEntry->SmmLoadedImage.ImageSize = ImageContext.ImageSize;
   DriverEntry->SmmLoadedImage.ImageCodeType = EfiRuntimeServicesCode;
   DriverEntry->SmmLoadedImage.ImageDataType = EfiRuntimeServicesData;
-- 
2.8.0.windows.1

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


[edk2] [Patch] MdeModulePkg PiSmmIpl: Fix the issue in LMFA feature

2017-04-24 Thread Liming Gao
SmramBase should be got from mLMFAConfigurationTable.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index feb846e..2601275 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -263,6 +263,7 @@ EFI_PHYSICAL_ADDRESS   mSmramCacheBase;
 UINT64 mSmramCacheSize;
 
 EFI_SMM_COMMUNICATE_HEADER mCommunicateHeader;
+EFI_LOAD_FIXED_ADDRESS_CONFIGURATION_TABLE*mLMFAConfigurationTable = NULL;
 
 //
 // Table of Protocol notification and GUIDed Event notifications that the SMM 
IPL requires
@@ -841,7 +842,7 @@ GetPeCoffImageFixLoadingAssignedAddress(
  
FixLoadingAddress = 0;
Status = EFI_NOT_FOUND;
-   SmramBase = mCurrentSmramRange->CpuStart;
+   SmramBase = mLMFAConfigurationTable->SmramBase;
//
// Get PeHeader pointer
//
@@ -1519,7 +1520,6 @@ SmmIplEntry (
   UINT64  MaxSize;
   VOID*Registration;
   UINT64  SmmCodeSize;
-  EFI_LOAD_FIXED_ADDRESS_CONFIGURATION_TABLE*LMFAConfigurationTable;
   EFI_CPU_ARCH_PROTOCOL   *CpuArch;
   EFI_STATUS  SetAttrStatus;
   EFI_SMRAM_DESCRIPTOR*SmramRangeSmmDriver;
@@ -1623,14 +1623,14 @@ SmmIplEntry (
   //
   Status = EfiGetSystemConfigurationTable (
 ,
-   (VOID **) 
+   (VOID **) 
);
-  if (!EFI_ERROR (Status) && LMFAConfigurationTable != NULL) {
-LMFAConfigurationTable->SmramBase = mCurrentSmramRange->CpuStart;
+  if (!EFI_ERROR (Status) && mLMFAConfigurationTable != NULL) {
+mLMFAConfigurationTable->SmramBase = mCurrentSmramRange->CpuStart;
 //
 // Print the SMRAM base
 //
-DEBUG ((EFI_D_INFO, "LOADING MODULE FIXED INFO: TSEG BASE is %x. \n", 
LMFAConfigurationTable->SmramBase));
+DEBUG ((EFI_D_INFO, "LOADING MODULE FIXED INFO: TSEG BASE is %x. \n", 
mLMFAConfigurationTable->SmramBase));
   }
 
   //
-- 
2.8.0.windows.1

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


[edk2] [patch] MdemodulePkg/DisplayEngine: clean the line before showing message

2017-04-24 Thread Dandan Bi
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../CustomizedDisplayLibInternal.c  | 21 -
 .../Universal/DisplayEngineDxe/FormDisplay.c| 15 +++
 2 files changed, 15 insertions(+), 21 deletions(-)

diff --git 
a/MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLibInternal.c 
b/MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLibInternal.c
index bc14a9d..3e24f35 100644
--- a/MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLibInternal.c
+++ b/MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLibInternal.c
@@ -857,12 +857,10 @@ PrintInternal (
   CHAR16  *BackupBuffer;
   UINTN   Index;
   UINTN   PreviousIndex;
   UINTN   Count;
   UINTN   TotalCount;
-  UINTN   PrintWidth;
-  UINTN   CharWidth;
 
   //
   // For now, allocate an arbitrarily long buffer
   //
   Buffer= AllocateZeroPool (0x1);
@@ -882,12 +880,18 @@ PrintInternal (
 
   Index = 0;
   PreviousIndex = 0;
   Count = 0;
   TotalCount= 0;
-  PrintWidth= 0;
-  CharWidth = 1;
+
+  //
+  // Clean the line and then reset the position of the cursor.
+  //
+  Out->OutputString (Out, [SPACE_BUFFER_SIZE - Width]);
+  if (Column != (UINTN) -1) {
+Out->SetCursorPosition (Out, Column, Row);
+  }
 
   do {
 for (; (Buffer[Index] != NARROW_CHAR) && (Buffer[Index] != WIDE_CHAR) && 
(Buffer[Index] != 0); Index++) {
   BackupBuffer[Index] = Buffer[Index];
 }
@@ -899,11 +903,10 @@ PrintInternal (
 //
 // Print this out, we are about to switch widths
 //
 Out->OutputString (Out, [PreviousIndex]);
 Count = StrLen ([PreviousIndex]);
-PrintWidth += Count * CharWidth;
 TotalCount += Count;
 
 //
 // Preserve the current index + 1, since this is where we will start 
printing from next
 //
@@ -916,18 +919,16 @@ PrintInternal (
   //
   // Preserve bits 0 - 6 and zero out the rest
   //
   Out->Mode->Attribute = Out->Mode->Attribute & 0x7f;
   Out->SetAttribute (Out, Out->Mode->Attribute);
-  CharWidth = 1;
 } else {
   //
   // Must be wide, set bit 7 ON
   //
   Out->Mode->Attribute = Out->Mode->Attribute | EFI_WIDE_ATTRIBUTE;
   Out->SetAttribute (Out, Out->Mode->Attribute);
-  CharWidth = 2;
 }
 
 Index++;
 
   } while (Buffer[Index] != 0);
@@ -935,17 +936,11 @@ PrintInternal (
   //
   // We hit the end of the string - print it
   //
   Out->OutputString (Out, [PreviousIndex]);
   Count = StrLen ([PreviousIndex]);
-  PrintWidth += Count * CharWidth;
   TotalCount += Count;
-  if (PrintWidth < Width) {
-Out->Mode->Attribute = Out->Mode->Attribute & 0x7f;
-Out->SetAttribute (Out, Out->Mode->Attribute);
-Out->OutputString (Out, [SPACE_BUFFER_SIZE - Width + 
PrintWidth]);
-  }
 
   FreePool (Buffer);
   FreePool (BackupBuffer);
   return TotalCount;
 }
diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c 
b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
index e1ac5a3..2938351 100644
--- a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
+++ b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
@@ -2056,32 +2056,31 @@ DisplayMenuString (
   IN CHAR16 *String,
   IN UINTN  Width,
   IN BOOLEANHighlight
   )
 {
-  UINTNLength;
-
   //
   // Print string with normal color.
   //
   if (!Highlight) {
 PrintStringAtWithWidth (Col, Row, String, Width);
 return;
   }
-  
   //
   // Print the highlight menu string.
-  // First print the highlight string.
+  // First, clean the line.
   // 
+  PrintStringAtWithWidth (Col, Row, L"", Width);
+  //
+  // Second, set the display attribute for highlight string and then print it.
+  //
   SetDisplayAttribute(MenuOption, TRUE);
-  Length = PrintStringAt (Col, Row, String);
-
+  PrintStringAt (Col, Row, String);
   //
-  // Second, clean the empty after the string.
+  // Last, reset the display attribute.
   //
   SetDisplayAttribute(MenuOption, FALSE);
-  PrintStringAtWithWidth (Col + Length, Row, L"", Width - Length);
 }
 
 /**
   Check whether this menu can has option string.
 
-- 
1.9.5.msysgit.1

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


Re: [edk2] [PATCH v2 2/2] MdeModulePkg/UfsPciHc: Avoid overriding return value in BindingStart

2017-04-24 Thread Zeng, Star
Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: Wu, Hao A 
Sent: Monday, April 24, 2017 1:59 PM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Zeng, Star 
Subject: [PATCH v2 2/2] MdeModulePkg/UfsPciHc: Avoid overriding return value in 
BindingStart

In function UfsHcDriverBindingStart(), the return value 'Status' may be 
overridden during the original PCI attributes restore process.

This commit refines the logic to avoid such override.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/UfsPciHcDxe/UfsPciHcDxe.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/UfsPciHcDxe/UfsPciHcDxe.c 
b/MdeModulePkg/Bus/Pci/UfsPciHcDxe/UfsPciHcDxe.c
index 373e55b4c2..96cf39adc1 100644
--- a/MdeModulePkg/Bus/Pci/UfsPciHcDxe/UfsPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/UfsPciHcDxe/UfsPciHcDxe.c
@@ -671,13 +671,12 @@ Done:
   //
   // Restore original PCI attributes
   //
-  Status = PciIo->Attributes (
-PciIo,
-EfiPciIoAttributeOperationSet,
-Private->PciAttributes,
-NULL
-);
-  ASSERT_EFI_ERROR (Status);
+  PciIo->Attributes (
+   PciIo,
+   EfiPciIoAttributeOperationSet,
+   Private->PciAttributes,
+   NULL
+   );
 }
 gBS->CloseProtocol (
   Controller,
--
2.12.0.windows.1

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