from:"Kinney, Michael D"

 with BSD+Patent License
6389a5b4d5 CryptoPkg: Replace BSD License with BSD+Patent License
0065fa2d9f CorebootPayloadPkg: Replace BSD License with BSD+Patent License
26d7dbf868 CorebootModulePkg: Replace BSD License with BSD+Patent License
b1ebd76234 BeagleBoardPkg: Replace BSD License with BSD+Patent License
f23540ea65 ArmVirtPkg: Replace BSD License with BSD+Patent License
054b667071 ArmPlatformPkg: Replace BSD License with BSD+Patent License
5128ec1897 ArmPkg: Replace BSD License with BSD+Patent License
3b7fd23df9 BaseTools: Replace BSD License with BSD+Patent License
aa5e7ad3ef edk2: Replace BSD License with BSD+Patent License
fdcf6f00c7 edk2: Change License.txt from 2-Clause BSD to BSD+Patent
831e2096e8 edk2: Add License-History.txt

Best regards,

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Friday, March 22, 2019 6:49 PM
> To: edk2-devel@lists.01.org; Kinney, Michael D
> 
> Subject: [RFC v3] Change EDK II to BSD+Patent License
> 
> Hello,
> 
> Based on review of the RFC V2, there are some updates
> required to
> Readme.md in the root of the edk2 repository.
> 
> Changes for V3
> ===
> * Move the portions of Contributions.txt in the root of
> edk2 to
>   Readme.md in the root of edk2 that describe how to
> contribute
>   along with the commit message format.
> 
> * Add to Readme.md in the root of edk2 that Signed-off-by
> means that
>   the contributor certifies compliance to the Developer's
> Certificate
>   of Origin 1.1.  https://developercertificate.org
> 
> Changes for V2
> ===
> * Replace 2-Clause BSD License in file headers with SPDX-
> License-Identifier
>   statement.  This reduces the size of the file headers
> and the size
>   of the patches for this change.  Based on the following
> post:
> 
>   https://01.org/blogs/jc415/2018/open-source-hacks-one-
> question-interviews-open-source-experts-how-use-spdx-
> headers
> 
> * Update License.txt in root of edk2 before changing file
> headers.
> * Fix minor typos
> ===
> 
> This RFC follows up on the proposal from Mark Doran to
> change the
> EDK II Project to a BSD+Patent License.
> 
>   https://lists.01.org/pipermail/edk2-devel/2019-
> February/036260.html
> 
> The review period for this license change is 30 days.  If
> there is no
> unresolved feedback on April 9, 2019, then commits of the
> license change
> patches will begin on April 9, 2019.
> 
>   ** Please provide feedback on the proposal by Monday
> April 8, 2019. **
> 
> Feedback can be sent to edk2-devel at lists.01.org, the
> EDK II community
> manager or any of the EDK II stewards.
> 
>   * Stephano Cetola 
> Community Manager
>   * Leif Lindholm   
> Steward
>   * Andrew Fish 
> Steward
>   * Laszlo Ersek
> Steward
>   * Michael Kinney  
> Steward
> 
> The goal is to convert all of the files in the edk2
> repository that are
> currently covered by the 2-Clause BSD License and the
> TianoCore
> Contribution Agreement to a BSD+Patent License.
> 
> I will be following up with pointers to public GitHub
> branches that
> contain the set of changes to the edk2 repository for
> review.
> 
> The proposal is to perform this change to edk2/master in
> the steps listed
> below. The license change will not be applied to any of
> the other existing
> branches in the edk2 repository.
> 
> 1) Add a License-History.txt file to the root of the edk2
> repository that
>contains the 2-Clause BSD License and the TianoCore
> Contribution
>Agreement along with the details on the change to the
> BSD+Patent License.
> 
> 2) Change License.txt in the root of the edk2 repository
> from a 2-Clause
>BSD License to the BSD+Patent License. The following
> is the link to the
>BSD+Patent License and the new License.txt file
> contents.
> 
>https://opensource.org/licenses/BSDplusPatent
> 
> 
> =
> =
>Redistribution and use in source and binary forms,
> with or without
>modification, are permitted provided that the
> following conditions are met:
> 
>1. Redistributions of source code must retain the
> above copyright notice,
>   this list of conditions and the following
> disclaimer.
> 
>2. Redistributions in binary form must reproduce the
> above copyright notice,
>   this list of conditions and the following
> disclaimer in the documentation
>   and/or other materials provided with the
> distribution.
> 
>Subject to the terms and conditions of this license,
> each copyright holder
>and contributor hereby grants to those recei

[edk2] [RFC v3] Change EDK II to BSD+Patent License

Hello,

Based on review of the RFC V2, there are some updates required to
Readme.md in the root of the edk2 repository.

Changes for V3
===
* Move the portions of Contributions.txt in the root of edk2 to
Readme.md in the root of edk2 that describe how to contribute
along with the commit message format.

* Add to Readme.md in the root of edk2 that Signed-off-by means that
the contributor certifies compliance to the Developer's Certificate
of Origin 1.1. https://developercertificate.org

Changes for V2
===
* Replace 2-Clause BSD License in file headers with SPDX-License-Identifier
statement. This reduces the size of the file headers and the size
of the patches for this change. Based on the following post:

https://01.org/blogs/jc415/2018/open-source-hacks-one-question-interviews-open-source-experts-how-use-spdx-headers

* Update License.txt in root of edk2 before changing file headers.
* Fix minor typos
===

This RFC follows up on the proposal from Mark Doran to change the
EDK II Project to a BSD+Patent License.

https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html

The review period for this license change is 30 days. If there is no
unresolved feedback on April 9, 2019, then commits of the license change
patches will begin on April 9, 2019.

** Please provide feedback on the proposal by Monday April 8, 2019. **

Feedback can be sent to edk2-devel at lists.01.org, the EDK II community
manager or any of the EDK II stewards.

* Stephano CetolaCommunity Manager
* Leif Lindholm Steward
* Andrew Fish Steward
* Laszlo Ersek Steward
* Michael KinneySteward

The goal is to convert all of the files in the edk2 repository that are
currently covered by the 2-Clause BSD License and the TianoCore
Contribution Agreement to a BSD+Patent License.

I will be following up with pointers to public GitHub branches that
contain the set of changes to the edk2 repository for review.

The proposal is to perform this change to edk2/master in the steps listed
below. The license change will not be applied to any of the other existing
branches in the edk2 repository.

1) Add a License-History.txt file to the root of the edk2 repository that
contains the 2-Clause BSD License and the TianoCore Contribution
Agreement along with the details on the change to the BSD+Patent License.

2) Change License.txt in the root of the edk2 repository from a 2-Clause
BSD License to the BSD+Patent License. The following is the link to the
BSD+Patent License and the new License.txt file contents.

https://opensource.org/licenses/BSDplusPatent

==
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.

Subject to the terms and conditions of this license, each copyright holder
and contributor hereby grants to those receiving rights under this license
a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except for failure to satisfy the conditions of this license) patent
license to make, have made, use, offer to sell, sell, import, and otherwise
transfer this software, where such license applies only to those patent
claims, already acquired or hereafter acquired, licensable by such copyright
holder or contributor that are necessarily infringed by:

(a) their Contribution(s) (the licensed copyrights of copyright holders and
non-copyrightable additions of contributors, in source or binary form)
alone; or

(b) combination of their Contribution(s) with the work of authorship to
which such Contribution(s) was added by such copyright holder or
contributor, if, at the time the Contribution is added, such addition
causes such combination to be necessarily infringed. The patent license
shall not apply to any other combinations which include the
Contribution.

Except as expressly stated above, no rights or licenses from any copyright
holder or contributor is granted under this license, whether expressly, by
implication, estoppel or otherwise.

DISCLAIMER

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

Hi Laszlo,

I have entered the following BZ for SPDX identifiers for 
MIT licensed content in OvmfPkg. 

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

Best regards,

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, March 20, 2019 5:10 AM
> To: Lars Kurth ; Julien Grall
> ; Kinney, Michael D
> 
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel
> ; Justen, Jordan L
> ; Anthony Perard
> ; Marc-André Lureau
> ; Stefan Berger
> 
> Subject: Re: [edk2] PATCH] Change EDK II to BSD+Patent
> License
> 
> On 03/15/19 18:48, Lars Kurth wrote:
> >
> >
> > On 15/03/2019, 10:18, "Julien Grall"
>  wrote:
> >
> > >
> > >  EDK2 is converting the full copyright in
> each file to SDPX identifier. While the
> > >  copyright looks like an MIT license, it has
> never been confirmed. Andrew Cooper
> > >  suggested you might be able to confirm.
> > >
> > > Is there a web-link to the files/repos such that
> I don’t have to clone the repo
> > > Lars
> >
> > Here an example of files from Xen public headers:
> >
> >
> https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/in
> clude/public;h=0618b0134d2b9babcba71a3f0f86be5a84468b50;h
> b=HEAD
> >
> > OK, this makes this easy then. Because in all
> likelihood, the files were copied from xen/include/public
> and then the COPYING file
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/in
> clude/public/COPYING applies, which states that
> everything in this directory is MIT, unless stated
> otherwise in the file.
> >
> > So as long as someone confirms that the files in
> OvmfPkg/Include came from xen/include/public, this is a
> clear case of a MIT license
> > If they are files from other directories in Xen, check
> the COPYING file in the original directory (or if there
> is none in the parent directory) and check the COPYING
> file
> >
> > I am not so clear about where the files in XenBusDxe
> came from, but the same principle applies.
> >
> > If someone groups these files by "original directory in
> Xen" to File ... I am happy to do a final sanity check
> and sign it off and/or deal with any unclear cases
> 
> Replacing MIT license blocks with SPDX identifiers is
> something we
> should do later -- I think it's out of scope for Mike's
> current patch
> series, it's just something I noticed and pointed out for
> the future,
> while I was verifying the "license block -> SPDX ID"
> replacements for
> 2-BSDL (i.e., *not* MIT).
> 
> Mike mentioned that he was going to file a number of
> TianoCore BZs as a
> result of the discussion in this thread. Mike, can you
> please file one
> for the MIT->SPDX "refactoring" (under OvmfPkg) as well?
> If not, I can
> file it myself later, I just wouldn't like us to end up
> with duplicates.
> 
> Once we have that separate BZ, we can discuss it in
> isolation.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v5] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM

Hi Narendra,

With this implementation, you have moved the save/restore
location to a module global variable.  The name should be
prefixed with 'm' to make that clear.  

mCr2

I do not think using a module global is MP safe.

The current implementation uses a local on the stack that
is MP safe because each CPU has its own stack.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of nkvangup
> Sent: Friday, March 22, 2019 11:50 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric
> ; Laszlo Ersek 
> Subject: [edk2] [PATCH v5] UefiCpuPkg\CpuSmm: Save &
> restore CR2 on-demand paging in SMM
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> 
> For every SMI occurrence, save and restore CR2 register
> only when SMM
> on-demand paging support is enabled in 64 bit operation
> mode.
> This is not a bug but to have better improvement of code.
> 
> Patch5 is updated with separate functions for Save and
> Restore of CR2
> based on review feedback.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Yao Jiewen 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 22
> ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  9 +---
> -
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 16
> 
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 28
> 
>  4 files changed, 71 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index b734a1ea8c..3750332ca8 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -316,3 +316,25 @@ SetPageTableAttributes (
> 
>return ;
>  }
> +
> +/**
> +  This function returns with no action for 32 bit.
> +**/
> +VOID
> +SaveCr2 (
> +  VOID
> +  )
> +{
> +// Do Nothing
> +}
> +
> +/**
> +  This function returns with no action for 32 bit.
> +**/
> +VOID
> +RestoreCr2 (
> +  VOID
> +  )
> +{
> +// Do Nothing
> +}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..6a5736a3eb 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1107,14 +1107,14 @@ SmiRendezvous (
>BOOLEANIsBsp;
>BOOLEANBspInProgress;
>UINTN  Index;
> -  UINTN  Cr2;
> 
>ASSERT(CpuIndex < mMaxNumberOfCpus);
> 
>//
> -  // Save Cr2 because Page Fault exception in SMM may
> override its value
> +  // Save Cr2 because Page Fault exception in SMM may
> override its value,
> +  // when using on-demand paging for above 4G memory.
>//
> -  Cr2 = AsmReadCr2 ();
> +  SaveCr2 ();
> 
>//
>// Perform CPU specific entry hooks
> @@ -1253,10 +1253,11 @@ SmiRendezvous (
> 
>  Exit:
>SmmCpuFeaturesRendezvousExit (CpuIndex);
> +
>//
>// Restore Cr2
>//
> -  AsmWriteCr2 (Cr2);
> +  RestoreCr2 ();
>  }
> 
>  /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 84efb22981..71a8c13960 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -1243,4 +1243,20 @@ EFIAPI
>  PiSmmCpuSmiEntryFixupAddress (
>   );
> 
> +/**
> +  This function saves CR2 register for 64 bit and no
> action for 32 bit.
> +**/
> +VOID
> +SaveCr2 (
> +  VOID
> +  );
> +
> +/**
> +  This function restores CR2 register for 64 bit and no
> action for 32 bit.
> +**/
> +VOID
> +RestoreCr2 (
> +  VOID
> +  );
> +
>  #endif
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 2c77cb47a4..76a30de171 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -22,6 +22,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS
> OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>  LIST_ENTRY  mPagePool =
> INITIALIZE_LIST_HEAD_VARIABLE (mPagePool);
>  BOOLEAN m1GPageTableSupport
> = FALSE;
>  BOOLEAN
> mCpuSmmStaticPageTable;
> +UINTN   Cr2 = 0;
> 
>  /**
>Disable CET.
> @@ -1053,3 +1054,30 @@ SetPageTableAttributes (
> 
>return ;
>  }
> +
> +/**
> +  This function saves CR2 register.
> +**/
> +VOID
> +SaveCr2 (
> +  VOID
> +  )
> +{
> +  if (!mCpuSmmStaticPageTable) {
> +Cr2 = AsmReadCr2 ();
> +  }
> +}
> +
> +/**
> +  This function restores CR2 register.
> +**/
> +VOID
> +RestoreCr2 (
> +  VOID
> +  )
> +{
> +  if ((!mCpuSmmStaticPageTable) && (Cr2 != 0)) {
> +AsmWriteCr2 (Cr2);
> +Cr2 = 0;
> +  }
> +}
> --
> 2.16.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mail

Re: [edk2] [PATCH] BaseTools: Add embedded driver support to GenerateCapsule.py

2019-03-20 Thread Kinney, Michael D

Hi Tomas,

Thanks for the contribution.  I agree we need this feature.
We have been working on updates to GenerateCapsule that
add support for one or more embedded drivers and multiple
payloads and the option to provide all the configuration
information in a JSON file.  It also extends decode
and dumpinfo to show the embedded drivers.  We will post
patch with all those features very soon.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Tomas Pilar (tpilar)
> Sent: Wednesday, March 20, 2019 10:18 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] BaseTools: Add embedded driver
> support to GenerateCapsule.py
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Tomas Pilar 
> ---
>  .../Source/Python/Capsule/GenerateCapsule.py  | 25
> ---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git
> a/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> index 7b08918857..4b275b092b 100644
> --- a/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> +++ b/BaseTools/Source/Python/Capsule/GenerateCapsule.py
> @@ -9,8 +9,7 @@
>  # system firmware or device firmware for integrated
> devices.  In order to
>  # keep the tool as simple as possible, it has the
> following limitations:
>  #   * Do not support multiple payloads in a capsule.
> -#   * Do not support optional drivers in a capsule.
> -#   * Do not support vendor code bytes in a capsule.
> +#   * Support at most one optional driver in a capsule.
>  #
>  # Copyright (c) 2018, Intel Corporation. All rights
> reserved.
>  # This program and the accompanying materials
> @@ -236,6 +235,12 @@ if __name__ == '__main__':
>  help = "Input binary payload
> filename.")
>  parser.add_argument("-o", "--output", dest =
> 'OutputFile', type = argparse.FileType('wb'),
>  help = "Output filename.")
> +
> +#
> +# Add optional embedded driver and vendor code
> arguments
> +#
> +parser.add_argument("--driver", dest = 'Driver',
> type = argparse.FileType('rb'),
> +help = "Input binary embedded
> driver to package alongside the image")
>  #
>  # Add group for -e and -d flags that are mutually
> exclusive and required
>  #
> @@ -355,7 +360,7 @@ if __name__ == '__main__':
>  parser.error ('the following option is not
> supported for dumpinfo operations: --output')
> 
>  #
> -# Read binary input file
> +# Read binary input files
>  #
>  try:
>  if args.Verbose:
> @@ -366,6 +371,17 @@ if __name__ == '__main__':
>  print ('GenerateCapsule: error: can not read
> binary input file {File}'.format (File =
> args.InputFile.name))
>  sys.exit (1)
> 
> +DriverBuffer = b''
> +if args.Driver:
> +try:
> +if args.Verbose:
> +print ('Read binary embedded driver
> {File}'.format (File = args.Driver.name))
> +DriverBuffer = args.Driver.read ()
> +args.Driver.close ()
> +except:
> +print ('GenerateCapsule: error: can not read
> supplied binary embedded driver file {File}'.format (File
> = args.Driver.name))
> +sys.exit (1)
> +
>  #
>  # Create objects
>  #
> @@ -423,6 +439,9 @@ if __name__ == '__main__':
> 
>  try:
>  FmpCapsuleHeader.AddPayload (args.Guid,
> Result, HardwareInstance = args.HardwareInstance)
> +if args.Driver:
> +
> FmpCapsuleHeader.AddEmbeddedDriver(DriverBuffer)
> +
>  Result = FmpCapsuleHeader.Encode ()
>  if args.Verbose:
>  FmpCapsuleHeader.DumpInfo ()
> --
> 2.17.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SerialDxe with BaseSerialPortLib16550 and standard PC com port

2019-03-20 Thread Kinney, Michael D

What are the PCDs settings you are using for the
SerialPortLib?

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Jacob Burkholder
> Sent: Tuesday, March 19, 2019 7:06 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] SerialDxe with BaseSerialPortLib16550 and
> standard PC com port
> 
> Greetings!
> 
> I had trouble using SerialDxe.efi with
> BaseSerialPortLib16550 on a standard
> PC com port (com1).  The PC is an asrock motherboard
> running whatever EFI
> bios it came with.  I changed MdeModulePkg.dsc so that
> BaseSerialPortLib16550 would be used instead of
> BaseSerialPortLibNull and
> then rebuilt SerialDxe.efi and loaded and started it
> using
> BootServices->{LoadImage,StartImage}.
> 
> Output works but input doesn't work, typed characters
> aren't received by
> the uart.  I looked at the code briefly and it seems like
> the uart isn't
> initialized properly.  I used this script to get input
> working (the
> commands should be self explanatory, they're not efi
> shell commands though):
> 
> image SerialDxe.efi
> outb 0x3fb 0x83
> outw 0x3f8 1
> outb 0x3fb 0x3
> outb 0x3fc 0x3
> 
> Any chance it can be fixed upstream?
> 
> Thanks,
> 
> Jake
> ___
> 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] Change EDK II to BSD+Patent License

2019-03-19 Thread Kinney, Michael D

Leif and Jordan,

Would you mind putting together a specific proposal
and perhaps some links to other projects that use
the same approach?

I am happy to update the RFC to V3 to address this 
topic if we can close on it quickly.

Thanks,

Mike


> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, March 19, 2019 10:59 AM
> To: Kinney, Michael D 
> Cc: Justen, Jordan L ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] PATCH] Change EDK II to BSD+Patent
> License
> 
> Hi Mike,
> 
> I see where Jordan is coming from here.
> 
> It isn't just about losing the comment in
> Contriutions.txt - there are
> bits in the actual TianoCore Contribution Agreement that
> cover the
> same things as https://developercertificate.org/ (that
> are not
> explicitly called out elsewhere in the existing
> Contributions.txt).
> 
> Like Jordan says, we wouldn't be the first project that
> use
> Signed-off-by without specifying exactly what it means,
> but I think
> we're one of the ones that actually care quite a bit.
> 
> I could live with us not resolving this at the same time
> as the
> license change, but I would prefer if we did...
> 
> Best Regards,
> 
> Leif
> 
> On Mon, Mar 18, 2019 at 06:25:54PM +, Kinney, Michael
> D wrote:
> > Hi Jordan,
> >
> > No proposed changes to the Signed-off-by tags.  If you
> have
> > a proposal, please provide an RFC or bring to the
> monthly
> > EDK II community meeting.
> >
> > This series is focused on the license change, the use
> of SPDX
> > identifiers, and removing the Contributed-under tag
> from
> > commit messages.
> >
> > I will update the V2 version of the patch series in to
> make
> > sure the content from Contributions.txt that is not
> part of
> > the TianoCore Contribution Agreement is added to
> Readme.md.
> >
> > The RFC mentioned the need to update documentation.  I
> will
> > send that out as a separate Wiki patch series for
> review.
> >
> > Best regards,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Justen, Jordan L
> > > Sent: Thursday, March 14, 2019 11:04 AM
> > > To: Kinney, Michael D ;
> > > edk2-devel@lists.01.org
> > > Subject: Re: [edk2] PATCH] Change EDK II to
> BSD+Patent
> > > License
> > >
> > > On 2019-03-13 10:54:22, Kinney, Michael D wrote:
> > > >
> > > > 84141eacac edk2: Remove Contributions.txt and
> update
> > > Readme.md
> > >
> > > I guess this removes the requirement for the
> > > 'Contributed-under' tag
> > > in commit messages?
> > >
> > > But, what about Signed-off-by? Is it desirable to
> > > remove that
> > > requirement?
> > >
> > > Relatedly, some open source projects have
> standardized
> > > on tying the
> > > Signed-off-by to this text:
> > >
> > > https://developercertificate.org/
> > >
> > > So, the contributor doesn't have to agree to give the
> > > project the
> > > contribution under the Contributed-under terms, but
> > > they still
> > > indicate that they believe that the project can use
> the
> > > code under the
> > > project's indicated license.
> > >
> > > There is also other information in Contributions.txt
> > > that appears to
> > > have been deleted, rather than moved. I guess it is
> > > mostly duplicated
> > > on the wiki. That doesn't mean it's not a good idea
> to
> > > duplicate it in
> > > the source tree, or at least provide a web-link. It
> > > seems like the
> > > first place devs might look for such information is
> > > either the readme,
> > > or Contributions.txt.
> > >
> > > Regarding the wiki, I guess it has to be updated
> after
> > > this change is
> > > made. It might be good to add that to the bug so it
> > > can't be closed
> > > until that is fixed.
> > >
> > > How about updating BaseTools/Scripts/PatchCheck.py?
> > >
> > > -Jordan
> > ___
> > 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] Change EDK II to BSD+Patent License

2019-03-18 Thread Kinney, Michael D

Hi Jordan,

No proposed changes to the Signed-off-by tags.  If you have 
a proposal, please provide an RFC or bring to the monthly
EDK II community meeting.

This series is focused on the license change, the use of SPDX
identifiers, and removing the Contributed-under tag from
commit messages.

I will update the V2 version of the patch series in to make
sure the content from Contributions.txt that is not part of
the TianoCore Contribution Agreement is added to Readme.md.

The RFC mentioned the need to update documentation.  I will
send that out as a separate Wiki patch series for review.

Best regards,

Mike

> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, March 14, 2019 11:04 AM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] PATCH] Change EDK II to BSD+Patent
> License
> 
> On 2019-03-13 10:54:22, Kinney, Michael D wrote:
> >
> > 84141eacac edk2: Remove Contributions.txt and update
> Readme.md
> 
> I guess this removes the requirement for the
> 'Contributed-under' tag
> in commit messages?
> 
> But, what about Signed-off-by? Is it desirable to
> remove that
> requirement?
> 
> Relatedly, some open source projects have standardized
> on tying the
> Signed-off-by to this text:
> 
> https://developercertificate.org/
> 
> So, the contributor doesn't have to agree to give the
> project the
> contribution under the Contributed-under terms, but
> they still
> indicate that they believe that the project can use the
> code under the
> project's indicated license.
> 
> There is also other information in Contributions.txt
> that appears to
> have been deleted, rather than moved. I guess it is
> mostly duplicated
> on the wiki. That doesn't mean it's not a good idea to
> duplicate it in
> the source tree, or at least provide a web-link. It
> seems like the
> first place devs might look for such information is
> either the readme,
> or Contributions.txt.
> 
> Regarding the wiki, I guess it has to be updated after
> this change is
> made. It might be good to add that to the bug so it
> can't be closed
> until that is fixed.
> 
> How about updating BaseTools/Scripts/PatchCheck.py?
> 
> -Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

2019-03-18 Thread Kinney, Michael D

Laszlo,

Thanks for the feedback.  I will entered a few BZs based on this
feedback and will provide a V2 version of the content.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Thursday, March 14, 2019 3:56 AM
> To: Kinney, Michael D 
> Cc: Justen, Jordan L ; edk2-
> de...@lists.01.org; Julien Grall
> ; Anthony Perard
> 
> Subject: Re: [edk2] PATCH] Change EDK II to BSD+Patent
> License
> 
> Hi Mike,
> 
> On 03/13/19 18:54, Kinney, Michael D wrote:
> > Hello,
> >
> > BZ:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1373
> >
> > This change is based on the following emails:
> >   https://lists.01.org/pipermail/edk2-devel/2019-
> February/036260.html
> >   https://lists.01.org/pipermail/edk2-devel/2018-
> October/030385.html
> >
> > RFCs with detailed process for the license change:
> >   https://lists.01.org/pipermail/edk2-devel/2019-
> March/037669.html
> >   https://lists.01.org/pipermail/edk2-devel/2019-
> March/037500.html
> >
> > I have posted the patch series for review on the
> following branch
> > using edk2-stable201903 as the base for the patch
> series.
> >
> >
> https://github.com/mdkinney/edk2/tree/Bug_1373_BsdPaten
> tLicense
> >
> > The commits in patch series can be viewed here:
> >
> >
> https://github.com/mdkinney/edk2/commits/Bug_1373_BsdPa
> tentLicense
> >
> > The patch series has one patch per package along with
> a few patches
> > to update the license information in the root of the
> edk2 repository
> > as described in the RFC V2.
> >
> > Due to the size of the patch series, I prefer to not
> send the
> > patch emails.  Instead, please perform code reviews
> using content
> > from the branch.
> >
> > All EDK II package maintainers and package reviewers
> should provide
> > review feedback for their packages.  The critical
> part of the review
> > is:
> > 1) Any changes that cause build breaks or logic
> changes.  These code
> >changes are intended to only modify license
> contents in comment
> >blocks.
> > 2) Any file that has been changed to BSD+Patent, but
> should remain
> >with the current license.
> > 3) Any file that that has not changed to BSD+Patent,
> but should be
> >changed to BSD+Patent.
> >
> > Feedback and Reviewed-by emails should identify the
> patch the feedback
> > applies using the patch summary listed below.  The
> goal is to complete
> > all reviews to support the commit of these patches on
> April 9, 2019.
> 
> [...]
> 
> 
> > 837a3425bf OvmfPkg: Replace BSD License with
> BSD+Patent License
> 
> (1) For the commit message, I have the following
> suggestions:
> 
> (1.1) please remove the "Cc:" tags, because you aren't
> actually posting
>   the patches to the mailing list, so the people
> listed in Cc have
>   no chance to receive the patch by email ("carbon-
> copied")
> 
> (1.2) please remove the "Branch for review" reference
> as well -- while I
>   certainly prefer such branch references ot remain
> valid forever,
>   in practice their longevity is quite dubious in
> comparison to e.g.
>   mailing list archive links.
> 
> (2) Regarding the patch body:
> 
> (2.1) I reviewed each of the 348 hunks in the patch
> file. They are
>   correct, with one exception:
> 
> (2.1.1) "create-release.py" doesn't only contain a
> copyright block
> (which is correctly patches), but it also
> *generates* a
> copyright block. (Search it manually for
> "http://opensource.org/licenses/bsd-
> license.php".) In my
> opinion, we should simply retire this python
> script, *before*
> the conversion is started -- I don't remember
> using it in recent
> years, plus now we have the stable tags, for
> open source
> community-oriented releases.
> 
> (2.2) 30 files under OvmfPkg remain without "SPDX-
> License-Identifier:
>   BSD-2-Clause-Patent" after the patch is applied.
> These can be
>   categorized as follows:
> 
> (2.2.1) Files without any copyright notices (very small
> files,
> README-like files, generated files):
> 
>   OvmfPkg/Csm/Csm16/ReadMe.txt
>   OvmfPkg/Include/IndustryStandard/Xen/README
>   OvmfPkg/README
> 
> 
> OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
> 
> OvmfPkg/Library/XenHypercallLib/X64/hypercall.

[edk2] PATCH] Change EDK II to BSD+Patent License

2019-03-13 Thread Kinney, Michael D


Best regards,

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, March 12, 2019 11:01 AM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC v2] Change EDK II to
> BSD+Patent License
> 
> On 03/10/19 01:15, Kinney, Michael D wrote:
> > Hello,
> >
> > Changes for V2
> > ===
> > * Replace 2-Clause BSD License in file headers with
> SPDX-License-Identifier
> >   statement.  This reduces the size of the file
> headers and the size
> >   of the patches for this change.  Based on the
> following post:
> >
> >   https://01.org/blogs/jc415/2018/open-source-hacks-
> one-question-interviews-open-source-experts-how-use-
> spdx-headers
> 
> This looks real nice.
> 
> Thanks
> Laszlo
> 
> >
> > * Update License.txt in root of edk2 before changing
> file headers.
> > * Fix minor typos
> > ===
> >
> > This RFC follows up on the proposal from Mark Doran
> to change the
> > EDK II Project to a BSD+Patent License.
> >
> > https://lists.01.org/pipermail/edk2-devel/2019-
> February/036260.html
> >
> > The review period for this license change is 30 days.
> If there is no
> > unresolved feedback on April 9, 2019, then commits of
> the license change
> > patches will begin on April 9, 2019.
> >
> >   ** Please provide feedback on the proposal by
> Monday April 8, 2019. **
> >
> > Feedback can be sent to edk2-devel@lists.01.org, the
> EDK II community
> > manager or any of the EDK II stewards.
> >
> >   * Stephano Cetola 
> Community Manager
> >   * Leif Lindholm   
> Steward
> >   * Andrew Fish 
> Steward
> >   * Laszlo Ersek
> Steward
> >   * Michael Kinney  
> Steward
> >
> > The goal is to convert all of the files in the edk2
> repository that are
> > currently covered by the 2-Clause BSD License and the
> TianoCore
> > Contribution Agreement to a BSD+Patent License.
> >
> > I will be following up with pointers to public GitHub
> branches that
> > contain the set of changes to the edk2 repository for
> review.
> >
> > The proposal is to perform this change to edk2/master
> in the steps listed
> > below. The license change will not be applied to any
> of the other existing
> > branches in the edk2 repository.
> >
> > 1) Add a License-History.txt file to the root of the
> edk2 repository that
> >contains the 2-Clause BSD License and the
> TianoCore Contribution
> >Agreement along with the details on the change to
> the BSD+Patent License.
> >
> > 2) Change License.txt in the root of the edk2
> repository from a 2-Clause
> >BSD License to the BSD+Patent License. The
> following is the link to the
> >BSD+Patent License and the new License.txt file
> contents.
> >
> >https://opensource.org/licenses/BSDplusPatent
> >
> >
> ===
> ===
> >Redistribution and use in source and binary forms,
> with or without
> >modification, are permitted provided that the
> following conditions are met:
> >
> >1. Redistributions of source code must retain the
> above copyright notice,
> >   this list of conditions and the following
> disclaimer.
> >
> >2. Redistributions in binary form must reproduce
> the above copyright notice,
> >   this list of conditions and the following
> disclaimer in the documentation
> >   and/or other materials provided with the
> distribution.
> >
> >Subject to the terms and conditions of this
> license, each copyright holder
> >and contributor hereby grants to those receiving
> rights under this license
> >a perpetual, worldwide, non-exclusive, no-charge,
> royalty-free, irrevocable
> >(except for failure to satisfy the conditions of
> this license) patent
> >license to make, have made, use, offer to sell,
> sell, import, and otherwise
> >transfer this software, where such license applies
> only to those patent
> >claims, already acquired or hereafter acquired,
> licensable by such copyright
> >holder or contributor that are necessarily
> infringed by:
> >
> >(a) their Contribution(s) (the licensed copyrights
> of copyright holders and
> >non-copyrightable additions of contributors,
> in source or binary form)
> >alone; or
> >
> >(b) combination of their Contribution(s) with the
>

Re: [edk2] [patch 1/2] SecurityPkg: Remove duplicated BSD license

2019-03-11 Thread Kinney, Michael D

Hi Dandan,

The copyright line should be preserved and put with the other
copyright line.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Dandan Bi
> Sent: Sunday, March 10, 2019 11:23 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao,
> Liming ; Zhang, Chao B
> 
> Subject: [edk2] [patch 1/2] SecurityPkg: Remove
> duplicated BSD license
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1612
> 
> Cc: Chao Zhang 
> Cc: Jian Wang 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  .../Ppi/FirmwareVolumeInfoPrehashedFV.h   | 26 -
> --
>  1 file changed, 26 deletions(-)
> 
> diff --git
> a/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
> b/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
> index 23a56715ca..9a02c429ac 100644
> ---
> a/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
> +++
> b/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
> @@ -8,36 +8,10 @@ which accompanies this distribution.
> The full text of the license may be found
>  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.
> 
> -**/
> -/**
> -PPI to describe all hash digests for a given FV
> -
> -Copyright (c) 2017, Microsoft Corporation
> -
> -All rights reserved.
> -Redistribution and use in source and binary forms, with
> or without
> -modification, are permitted provided that the following
> conditions are met:
> -1. Redistributions of source code must retain the above
> copyright notice,
> -this list of conditions and the following disclaimer.
> -2. Redistributions in binary form must reproduce the
> above copyright notice,
> -this list of conditions and the following disclaimer in
> the documentation
> - and/or other materials provided with the distribution.
> -
> -THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS" AND
> -ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED
> -WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE ARE DISCLAIMED.
> -IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE LIABLE FOR ANY DIRECT,
> -INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL DAMAGES (INCLUDING,
> -BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES; LOSS OF USE,
> -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> CAUSED AND ON ANY THEORY OF
> -LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT (INCLUDING NEGLIGENCE
> -OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> SOFTWARE, EVEN IF
> -ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> -
>  **/
> 
>  #ifndef __PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_H__
>  #define __PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_H__
> 
> --
> 2.18.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] [RFC v2] Change EDK II to BSD+Patent License

2019-03-09 Thread Kinney, Michael D

Hello,

https://01.org/blogs/jc415/2018/open-source-hacks-one-question-interviews-open-source-experts-how-use-spdx-headers

* Update License.txt in root of edk2 before changing file headers.
* Fix minor typos
===

This RFC follows up on the proposal from Mark Doran to change the
EDK II Project to a BSD+Patent License.

https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html

The review period for this license change is 30 days. If there is no
unresolved feedback on April 9, 2019, then commits of the license change
patches will begin on April 9, 2019.

** Please provide feedback on the proposal by Monday April 8, 2019. **

Feedback can be sent to edk2-devel@lists.01.org, the EDK II community
manager or any of the EDK II stewards.

* Stephano CetolaCommunity Manager
* Leif Lindholm Steward
* Andrew Fish Steward
* Laszlo Ersek Steward
* Michael KinneySteward

The goal is to convert all of the files in the edk2 repository that are
currently covered by the 2-Clause BSD License and the TianoCore
Contribution Agreement to a BSD+Patent License.

I will be following up with pointers to public GitHub branches that
contain the set of changes to the edk2 repository for review.

The proposal is to perform this change to edk2/master in the steps listed
below. The license change will not be applied to any of the other existing
branches in the edk2 repository.

https://opensource.org/licenses/BSDplusPatent

==
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.

(a) their Contribution(s) (the licensed copyrights of copyright holders and
non-copyrightable additions of contributors, in source or binary form)
alone; or

Except as expressly stated above, no rights or licenses from any copyright
holder or contributor is granted under this license, whether expressly, by
implication, estoppel or otherwise.

DISCLAIMER

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
==

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-08 Thread Kinney, Michael D

Jiewen,

There are not many of those functions and they can be on speed paths.

I do not recommend converting them to only NASM.

I do recommend we add comments to NASM files and C files with include assembly 
that state that updates to one require updates to the others.

Mike

From: Yao, Jiewen
Sent: Wednesday, March 6, 2019 11:25 PM
To: Gao, Liming ; af...@apple.com
Cc: Kinney, Michael D ; edk2-devel-01 

Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

Thanks.

I also recommend to take a look at MdePkg\Library\BaseSynchronizationLib.

That is also complicated and not so readable for me.

And we have 8 patches to *fix* the real problem in 2018.

Thank you
Yao Jiewen


From: Gao, Liming
Sent: Wednesday, March 6, 2019 11:15 PM
To: af...@apple.com<mailto:af...@apple.com>; Yao, Jiewen 
mailto:jiewen@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; edk2-devel-01 
mailto:edk2-devel@lists.01.org>>
Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

Thanks for your clarification. Now, we will focus on SetJump/LongJump() first.

Thanks
Liming
From: af...@apple.com<mailto:af...@apple.com> [mailto:af...@apple.com]
Sent: Wednesday, March 6, 2019 10:45 PM
To: Yao, Jiewen mailto:jiewen@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>; edk2-devel-01 
mailto:edk2-devel@lists.01.org>>
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code



On Mar 6, 2019, at 10:09 PM, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:

Thanks Andrew.
Now I 100% agree with you - I think it is fine to restrict new C inline 
assembler, or at least have a very high bar to add anything new. Any new inline 
assembler *should also be simple and just be a function abstracting a CPU 
op-code* that is not available to C. This is how we prevent the maintenance 
issues you are worrying about.

And I also agree with your case.

Let’s discuss another case. Below 2 functions SetJump/LongJump are updated 
recently, by me unfortunately.

It is unclear to me what is the size optimization we can get by inline 
SetJump/LongJump.
But obviously, it brings the maintenance issue to me.
And I don’t believe it meets the criteria you mentioned above.


Jiewen,

I agree it seems like given the rules we agree on this code should be written 
in NASM.

Thanks,

Andrew Fish

_declspec (naked)
RETURNS_TWICE
UINTN
EFIAPI
SetJump (
  OUT BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer
  )
{
  _asm {
push[esp + 4]
callInternalAssertJumpBuffer
pop ecx
pop ecx
mov edx, [esp]

xor eax, eax
mov [edx + 24], eax; save 0 to SSP

mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov eax, 1
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX to read original SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
mov [edx + 0x24], eax  ; save SSP

CetDone:

mov [edx], ebx
mov [edx + 4], esi
mov [edx + 8], edi
mov [edx + 12], ebp
mov [edx + 16], esp
mov [edx + 20], ecx
xor eax, eax
jmp ecx
  }
}

__declspec (naked)
VOID
EFIAPI
InternalLongJump (
  IN  BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer,
  IN  UINTN Value
  )
{
  _asm {
mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov edx, [esp + 4] ; edx = JumpBuffer
mov edx, [edx + 24]; edx = target SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
sub edx, eax   ; edx = delta
mov eax, edx   ; eax = delta

shr eax, 2 ; eax = delta/sizeof(UINT32)
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX

CetDone:

pop eax ; skip return address
pop edx ; edx <- JumpBuffer
pop eax ; eax <- Value
mov ebx, [edx]
mov esi, [edx + 4]
mov edi, [edx + 8]
mov ebp, [edx + 12]
mov esp, [edx + 16]
jmp dword ptr [edx + 20]
  }
}



From: af...@apple.com<mailto:af...@apple.co

Re: [edk2] [PATCH v2] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM

2019-03-07 Thread Kinney, Michael D

Laszlo,

The information I provided below is incorrect.  The PCD referenced
does support all PCD types as Jiewen noted.

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, March 7, 2019 10:10 AM
> To: Laszlo Ersek ; Vanguput,
> Narendra K ; edk2-
> de...@lists.01.org; Kinney, Michael D
> 
> Cc: Yao, Jiewen ; Dong, Eric
> 
> Subject: RE: [edk2] [PATCH v2] UefiCpuPkg\CpuSmm: Save
> & restore CR2 on-demand paging in SMM
> 
> Laszlo,
> 
> Good news is that the PCD being used is a Feature Flag.
> 
> [PcdsFeatureFlag]
>   ## Indicates if SMM Profile will be enabled.
>   #  If enabled, instruction executions in and data
> accesses to memory outside of SMRAM will be logged.
>   #  It could not be enabled at the same time with SMM
> static page table feature (PcdCpuSmmStaticPageTable).
>   #  This PCD is only for validation purpose. It should
> be set to false in production.
>   #   TRUE  - SMM Profile will be enabled.
>   #   FALSE - SMM Profile will be disabled.
>   # @Prompt Enable SMM Profile.
> 
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmProfileEnable|FALSE|
> BOOLEAN|0x32132109
> 
> That means a different PcdLib function should be used
> to look up
> the value so it is clear that it is safe at SMM
> runtime.
> 
> FeaturePcdGet(TokenName)
> 
> Best regards,
> 
> Mike
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of Laszlo Ersek
> > Sent: Thursday, March 7, 2019 9:58 AM
> > To: Vanguput, Narendra K
> > ; edk2-
> > de...@lists.01.org
> > Cc: Yao, Jiewen ; Dong, Eric
> > 
> > Subject: Re: [edk2] [PATCH v2] UefiCpuPkg\CpuSmm:
> Save
> > & restore CR2 on-demand paging in SMM
> >
> > On 03/07/19 12:14, nkvangup wrote:
> > > BZ:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> > >
> > > For every SMI occurrence, save and restore CR2
> > register only when SMM
> > > on-demand paging support is enabled in 64 bit
> > operation mode.
> > >
> > > Contributed-under: TianoCore Contribution Agreement
> > 1.1
> > > Signed-off-by: Vanguput Narendra K
> > 
> > > Cc: Eric Dong 
> > > Cc: Ray Ni 
> > > Cc: Laszlo Ersek 
> > > Cc: Yao Jiewen 
> > > ---
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 20
> > 
> > >  1 file changed, 12 insertions(+), 8 deletions(-)
> >
> > (1) There is an open question about the usefulness of
> > this patch in
> >
> <https://bugzilla.tianocore.org/show_bug.cgi?id=1593#c1
> > >. It should be
> > answered in the BZ, or the same description should be
> > included in the
> > commit message.
> >
> > (2) Also, the commit message should refer to the BZ.
> >
> >
> > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > > index 3b0b3b52ac..5be4a2b020 100644
> > > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > > @@ -,10 +,12 @@ SmiRendezvous (
> > >
> > >ASSERT(CpuIndex < mMaxNumberOfCpus);
> > >
> > > -  //
> > > -  // Save Cr2 because Page Fault exception in SMM
> > may override its value
> > > -  //
> > > -  Cr2 = AsmReadCr2 ();
> > > +  if ((sizeof (UINTN) == sizeof (UINT64)) &&
> > (!PcdGetBool (PcdCpuSmmStaticPageTable))) {
> >
> > (3) It doesn't look like a good idea to me to call
> > PcdGetBool() in the
> > SmiRendezvous() function.
> >
> > If the PCD is not fixed-at-build (but dynamic), then
> > we'll end up
> > calling a PI protocol member from a function that is
> by
> > definition
> > executed by multiple processors at the same time.
> >
> > "X64/PageTbl.c" already defines the global variable
> > "mCpuSmmStaticPageTable", setting it from the PCD on
> > the call stack of
> > the entry point function of the driver. That is safe
> --
> > we can call PI /
> > UEFI protocols in the entry point functions of a
> > DXE_SMM_DRIVER.
> >
> > Now, the fact that "mCpuSmmStaticPageTable" is only
> > defined in the X64
> > build (that is, in "X64/PageTbl.c"), is actually
> quite
> > informative. It
> > means that, instead of this conditional code in
> > "MpService.c", we should
> > introduce two new helper functions, "SaveCr2" and
> > "R

Re: [edk2] [PATCH v2] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM

2019-03-07 Thread Kinney, Michael D

Laszlo,

Good news is that the PCD being used is a Feature Flag.

[PcdsFeatureFlag]
  ## Indicates if SMM Profile will be enabled.
  #  If enabled, instruction executions in and data accesses to memory outside 
of SMRAM will be logged.
  #  It could not be enabled at the same time with SMM static page table 
feature (PcdCpuSmmStaticPageTable).
  #  This PCD is only for validation purpose. It should be set to false in 
production.
  #   TRUE  - SMM Profile will be enabled.
  #   FALSE - SMM Profile will be disabled.
  # @Prompt Enable SMM Profile.
  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmProfileEnable|FALSE|BOOLEAN|0x32132109

That means a different PcdLib function should be used to look up
the value so it is clear that it is safe at SMM runtime.

FeaturePcdGet(TokenName)

Best regards,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Thursday, March 7, 2019 9:58 AM
> To: Vanguput, Narendra K
> ; edk2-
> de...@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric
> 
> Subject: Re: [edk2] [PATCH v2] UefiCpuPkg\CpuSmm: Save
> & restore CR2 on-demand paging in SMM
> 
> On 03/07/19 12:14, nkvangup wrote:
> > BZ:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> >
> > For every SMI occurrence, save and restore CR2
> register only when SMM
> > on-demand paging support is enabled in 64 bit
> operation mode.
> >
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Vanguput Narendra K
> 
> > Cc: Eric Dong 
> > Cc: Ray Ni 
> > Cc: Laszlo Ersek 
> > Cc: Yao Jiewen 
> > ---
> >  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 20
> 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> (1) There is an open question about the usefulness of
> this patch in
>  >. It should be
> answered in the BZ, or the same description should be
> included in the
> commit message.
> 
> (2) Also, the commit message should refer to the BZ.
> 
> 
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > index 3b0b3b52ac..5be4a2b020 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > @@ -,10 +,12 @@ SmiRendezvous (
> >
> >ASSERT(CpuIndex < mMaxNumberOfCpus);
> >
> > -  //
> > -  // Save Cr2 because Page Fault exception in SMM
> may override its value
> > -  //
> > -  Cr2 = AsmReadCr2 ();
> > +  if ((sizeof (UINTN) == sizeof (UINT64)) &&
> (!PcdGetBool (PcdCpuSmmStaticPageTable))) {
> 
> (3) It doesn't look like a good idea to me to call
> PcdGetBool() in the
> SmiRendezvous() function.
> 
> If the PCD is not fixed-at-build (but dynamic), then
> we'll end up
> calling a PI protocol member from a function that is by
> definition
> executed by multiple processors at the same time.
> 
> "X64/PageTbl.c" already defines the global variable
> "mCpuSmmStaticPageTable", setting it from the PCD on
> the call stack of
> the entry point function of the driver. That is safe --
> we can call PI /
> UEFI protocols in the entry point functions of a
> DXE_SMM_DRIVER.
> 
> Now, the fact that "mCpuSmmStaticPageTable" is only
> defined in the X64
> build (that is, in "X64/PageTbl.c"), is actually quite
> informative. It
> means that, instead of this conditional code in
> "MpService.c", we should
> introduce two new helper functions, "SaveCr2" and
> "RestoreCr2". And we
> should provide separate implementations for IA32 and
> X64. For IA32, the
> function should do nothing. For X64, the function
> should depend on
> "mCpuSmmStaticPageTable", and massage CR2 as necessary.
> 
> However: that *still* depends on whether this change is
> useful. I
> realize the CR2 manipulation may not be overly useful
> on IA32 (we can't
> address >4GB memory, so demand paging for >4GB makes no
> sense), but its
> performance hit should be negligible. Again, back to
> point (1): what is
> the actual issue with the current code?
> 
> Thanks
> Laszlo
> 
> > +//
> > +// Save Cr2 because Page Fault exception in SMM
> may override its value
> > +//
> > +Cr2 = AsmReadCr2 ();
> > +  }
> >
> >//
> >// Perform CPU specific entry hooks
> > @@ -1253,10 +1255,12 @@ SmiRendezvous (
> >
> >  Exit:
> >SmmCpuFeaturesRendezvousExit (CpuIndex);
> > -  //
> > -  // Restore Cr2
> > -  //
> > -  AsmWriteCr2 (Cr2);
> > +  if ((sizeof (UINTN) == sizeof (UINT64)) &&
> (!PcdGetBool (PcdCpuSmmStaticPageTable))) {
> > +//
> > +// Restore Cr2
> > +//
> > +AsmWriteCr2 (Cr2);
> > +  }
> >  }
> >
> >  /**
> >
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Kinney, Michael D

Liming,

That does not work either because inline assembly uses compiler specific syntax.

Please update with the specific list of functions that you think the inline 
should be removed to improve maintenance with no impacts in size/perf.

The issue you pointed to was around SetJump()/LongJump().  Can we limit this BZ 
to only those 2 functions?

Mike

From: Gao, Liming
Sent: Wednesday, March 6, 2019 4:28 PM
To: af...@apple.com
Cc: Zhang, Shenglei ; edk2-devel-01 
; Kinney, Michael D 
Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

Andrew:
  I want to keep only one implementation. If inline assembly c source is 
preferred, I suggest to remove its nasm implementation.

Thanks
Liming
From: af...@apple.com<mailto:af...@apple.com> [mailto:af...@apple.com]
Sent: Tuesday, March 5, 2019 2:44 PM
To: Gao, Liming mailto:liming@intel.com>>
Cc: Zhang, Shenglei 
mailto:shenglei.zh...@intel.com>>; edk2-devel-01 
mailto:edk2-devel@lists.01.org>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code



On Mar 5, 2019, at 1:32 PM, Gao, Liming 
mailto:liming@intel.com>> wrote:

Andrew:
 BZ 1163 is to remove inline X86 assembly code in C source file. But, this 
patch is wrong. I have gave my comments to update this patch.

Why do we want to remove inline X86 assembly. As I mentioned it will lead to 
larger binaries, slower binaries, and less optimized code.

For example take this simple inline assembly function:

VOID
EFIAPI
CpuBreakpoint (
  VOID
  )
{
  __asm__ __volatile__ ("int $3");
}

Today with clang LTO turned on calling CpuBreakpoint() looks like this from the 
callers point of view.

a.out[0x1fa5] <+6>:  cc  int3

But if we move that to NASM:

a.out[0x1fa6] <+7>:  e8 07 00 00 00  calll  0x1fb2; 
CpuBreakpoint

plus:
a.out`CpuBreakpoint:
a.out[0x1fb2] <+0>: cc int3
a.out[0x1fb3] <+1>: c3 retl

And there is also an extra push and pop on the stack. The other issue is the 
call to the function that is unknown to the compiler will act like a 
_ReadWriteBarrier (Yikes I see _ReadWriteBarrier is deprecated in VC++ 2017). 
Is the depreciation of some of these intrinsics in VC++ driving the removal of 
inline assembly? For GCC inline assembly works great for local compile, and for 
clang LTO it works in entire program optimization.

The LTO bitcode includes inline assembly and constraints so that the optimizer 
knows what to do so it can get optimized just like the abstract bitcode during 
the Link Time Optimization.

This is CpuBreakpoint():
; Function Attrs: noinline nounwind optnone ssp uwtable
define void @CpuBreakpoint() #0 {
  call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2, 
!srcloc !3
  ret void
}

This is AsmReadMsr64():
; Function Attrs: noinline nounwind optnone ssp uwtable
define i64 @AsmReadMsr64(i32) #0 {
  %2 = alloca i32, align 4
  %3 = alloca i64, align 8
  store i32 %0, i32* %2, align 4
  %4 = load i32, i32* %2, align 4
  %5 = call i64 asm sideeffect "rdmsr", 
"=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4
  store i64 %5, i64* %3, align 8
  %6 = load i64, i64* %3, align 8
  ret i64 %6
}


I agree it make sense to remove .S and .asm files and only have .nasm files.

Thanks,

Andrew Fish

PS For the Xcode clang since it emits frame pointers by default we need to add 
the extra 4 bytes to save the assembly functions so the stack can get unwound.

a.out`CpuBreakpoint:
a.out[0x1f99] <+0>: 55 pushl  %ebp
a.out[0x1f9a] <+1>: 89 e5  movl   %esp, %ebp
a.out[0x1f9c] <+3>: cc int3
a.out[0x1f9d] <+4>: 5d popl   %ebp
a.out[0x1f9e] <+5>: c3 retl

So breakpoint goes from 1 byte to 11 bytes if we get rid of the intrinsics.

 The change is to reduce the duplicated implementation. It will be good on the 
code maintain. Recently, one patch has to update .c and .nasm both. Please see 
https://lists.01.org/pipermail/edk2-devel/2019-February/037165.html. Beside 
this change, I propose to remove all GAS assembly code for IA32 and X64 arch. 
After those change, the patch owner will collect the impact of the image size.

Thanks
Liming

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

[edk2] EDK II Specifications for edk2-stable201903 tag

2019-03-06 Thread Kinney, Michael D

Hi Liming and Bob,

I see several EDK II specification updates.

I do not see consistent updates to the Revision History
In the README.md with link to the BZ for the document
change.  Please make sure all revision histories are
up to date with BZ links, and as each BZ is closed put
the links to commits made in the BZ.  This allows anyone
reading the documents to follow the link to the BZ from
the Revision History, review the change request and follow
the links to the commits in GitHub and the easily view the
document changes.

Do you want released versions of these documents to 
align with the edk2-stable201903 tag?  The document
release process is documented here:

https://github.com/tianocore-docs/edk2-TemplateSpecification/wiki/TianoCore-Documents-Releasing

If so, please enter BZ for each document with the
requested release version number along with the 
SHA hash of on master the release branch is being
requested.

Thanks,

Mike

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

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-05 Thread Kinney, Michael D

Liming,

I agree .nasm files replacing .S/.asm files.  But the use of inline
assembly in C files for some primitives does produce much smaller/faster
code.

I would prefer that this BZ identify the specific functions that you
think would provide better maintainability with no impact to size
or performance.

Thanks,

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, March 5, 2019 1:33 PM
> To: af...@apple.com; Zhang, Shenglei
> 
> Cc: edk2-devel-01 ; Kinney,
> Michael D 
> Subject: RE: [edk2] [PATCH 3/3]
> MdePkg/BaseSynchronizationLib: Remove inline X86
> assembly code
> 
> Andrew:
>   BZ 1163 is to remove inline X86 assembly code in C
> source file. But, this patch is wrong. I have gave my
> comments to update this patch.
> 
>   The change is to reduce the duplicated
> implementation. It will be good on the code maintain.
> Recently, one patch has to update .c and .nasm both.
> Please see https://lists.01.org/pipermail/edk2-
> devel/2019-February/037165.html. Beside this change, I
> propose to remove all GAS assembly code for IA32 and
> X64 arch. After those change, the patch owner will
> collect the impact of the image size.
> 
> Thanks
> Liming
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Tuesday, March 5, 2019 12:58 PM
> > To: Zhang, Shenglei 
> > Cc: edk2-devel-01 ; Kinney,
> Michael D ; Gao, Liming
> 
> > Subject: Re: [edk2] [PATCH 3/3]
> MdePkg/BaseSynchronizationLib: Remove inline X86
> assembly code
> >
> > Shenglei,
> >
> > I was confused by the names of these patches. From a
> C point of view this is inline assembly:
> >
> > VOID
> > EFIAPI
> > CpuBreakpoint (
> > VOID
> > )
> > {
> > __asm__ __volatile__ ("int $3");
> > }
> >
> > These patches seem to be removing GAS and MASM
> assembly files, but not the inline assembly *.c files?
> >
> > We don't want to remove the inline assembly from the
> BaseLib as that could have size, performance, and
> compiler optimization impact.
> >
> > For example CpuBreakpoint() for clang with LTO would
> end up inlining a single byte. For i385 a call to
> assembler would be 5 bytes at each
> > call location plus the overhead of the function. So
> that is a size increase and a performance overhead. For
> a C complier calling an assembly
> > function is a serializing event an that can restrict
> optimizations. Thus having some limited inline assembly
> support is very useful.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > > On Mar 4, 2019, at 5:40 PM, Shenglei Zhang
>  wrote:
> > >
> > > MdePkg BaseSynchronizationLib still uses the inline
> X86 assembly code
> > > in C code files.It should be updated to consume
> nasm only.
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1163
> > >
> > > Cc: Michael D Kinney 
> > > Cc: Liming Gao 
> > > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > > Signed-off-by: Shenglei Zhang
> 
> > > ---
> > >
> .../Library/BaseSynchronizationLib/BaseSynchronizationL
> ib.inf   | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git
> a/MdePkg/Library/BaseSynchronizationLib/BaseSynchroniza
> tionLib.inf
> >
> b/MdePkg/Library/BaseSynchronizationLib/BaseSynchroniza
> tionLib.inf
> > > index 32414b29fa..719dc1938d 100755
> > > ---
> a/MdePkg/Library/BaseSynchronizationLib/BaseSynchroniza
> tionLib.inf
> > > +++
> b/MdePkg/Library/BaseSynchronizationLib/BaseSynchroniza
> tionLib.inf
> > > @@ -75,13 +75,11 @@
> > >
> > > [Sources.ARM]
> > > Synchronization.c
> > > -  Arm/Synchronization.asm   | RVCT
> > > Arm/Synchronization.S | GCC
> > >
> > > [Sources.AARCH64]
> > > Synchronization.c
> > > AArch64/Synchronization.S | GCC
> > > -  AArch64/Synchronization.asm   | MSFT
> > >
> > > [Packages]
> > > MdePkg/MdePkg.dec
> > > --
> > > 2.18.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] [RFC] Change EDK II to BSD+Patent License

2019-03-05 Thread Kinney, Michael D

Hello,

This RFC follows up on the proposal from Mark Doran to change the 
EDK II Project to a BSD+Patent License.

https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html

The review period for this license change is 30 days.  If there is no
unresolved feedback on April 9, 2019, then commits of the license change
patches will begin on April 9, 2019.  

  ** Please provide feedback on the proposal by Monday April 8, 2019. **

Feedback can be sent to edk2-devel@lists.01.org, the EDK II community
manager or any of the EDK II stewards.

  * Stephano CetolaCommunity Manager
  * Leif Lindholm   Steward
  * Andrew Fish  Steward
  * Laszlo Ersek   Steward
  * Michael KinneySteward

The goal is to convert all of the files in the edk2 repository that are
currently covered by the BSD 2-Clause License and the TianoCore
Contribution Agreement to a BSD+Patent License.  

I will be following up with pointers to public GitHub branches that
contain the set of changes to the edk2 repository for review.

The proposal is to perform this change to edk2/master in the steps listed
below. The license change will not be applied to any of the other existing
branches in the edk2 repository.

1) Add a License-History.txt file to the root of the edk2 repository that
   contains the BSD 2-Clause License and the TianoCore Contribution
   Agreement along with the details on the license change to BSD+Patent.

2) Change all files currently covered by a BSD 2-Clause license and the 
   TianoCore Contribution Agreement to a BSD+Patent license and add an 
   SPDX-License-Identifier statement.  The link to the BSD+Patent license
   and the text for file headers is listed below. 

   https://opensource.org/licenses/BSDplusPatent

   ==
   SPDX-License-Identifier: BSD-2-Clause-Patent

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions are met:

   1. Redistributions of source code must retain the above copyright notice,
  this list of conditions and the following disclaimer.

   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.

   Subject to the terms and conditions of this license, each copyright holder
   and contributor hereby grants to those receiving rights under this license
   a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable
   (except for failure to satisfy the conditions of this license) patent
   license to make, have made, use, offer to sell, sell, import, and otherwise
   transfer this software, where such license applies only to those patent
   claims, already acquired or hereafter acquired, licensable by such copyright
   holder or contributor that are necessarily infringed by:

   (a) their Contribution(s) (the licensed copyrights of copyright holders and
   non-copyrightable additions of contributors, in source or binary form)
   alone; or

   (b) combination of their Contribution(s) with the work of authorship to
   which such Contribution(s) was added by such copyright holder or
   contributor, if, at the time the Contribution is added, such addition
   causes such combination to be necessarily infringed. The patent license
   shall not apply to any other combinations which include the
   Contribution.

   Except as expressly stated above, no rights or licenses from any copyright
   holder or contributor is granted under this license, whether expressly, by
   implication, estoppel or otherwise.

   DISCLAIMER

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
   AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
   ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
   LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
   CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
   SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
   INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
   CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
   ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
   POSSIBILITY OF SUCH DAMAGE.
   ==

3) Update Readme.md and License.txt in the root of the edk2 repository to
   state that content is covered by a BSD+Patent license.  Also state that
   BSD+Patent is the preferred license for the EDK II project.

4) Remove the Contributions.txt file in the root of the edk2 repository
   That contiants the TianoCore Contribution Agreemen

Re: [edk2] Self-replicating image

2019-02-27 Thread Kinney, Michael D

Hi Tomas,

I have posted a branch in edk2-staging with the proposed
design changes to support multiple controller and a functional
example in OVMF using multiple E1000 adapters.

https://github.com/tianocore/edk2-staging/tree/Bug_1525_FmpDevicePkg_MultipleControllers

QEMU has a few limitations, so some aspects are simulated,
but you should be able to use the example as a template to
try your use case.

The E1000 UEFI PCI device driver that uses FmpDxe as a
Library is located at the following location.

OvmfPkg/E1000Fmp

It uses the E1000 specific FmpDeviceLib instance at:

OvmfPkg/Feature/Capsule/Library/FmpDeviceLibE1000

I have added device specific DSC files for each FMP driver
that are included from the OVMF DSC file.  The one for
E1000 is at:

OvmfPkg/Feature/Capsule/FmpE1000.dsc

QEMU does not support update of the PCI Option ROM 
mapped to a PCI device.  So I simulate the update of a
FW storage device using a 32-byte UEFI Variable that
is unique for each adapter.

Best regards,

Mike

> -Original Message-
> From: Tomas Pilar (tpilar)
> [mailto:tpi...@solarflare.com]
> Sent: Monday, February 11, 2019 2:37 AM
> To: Kinney, Michael D ;
> Andrew Fish ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Self-replicating image
> 
> Hi Mike,
> 
> Sorry to say I have not yet filed a BZ. Would you like
> me to, or are you happy doing it?
> 
> Cheers,
> Tom
> 
> On 08/02/2019 17:59, Kinney, Michael D wrote:
> > Hi Thomas,
> >
> > I have been looking into this topic of multiple
> controllers this
> > week.  I have some prototype code that I think
> resolves the issues
> > but needs a bit more work on some corner cases.
> >
> > I am using the PCI Option ROM use case to evaluate
> the changes.
> > PCI Option ROM can use Bus Specific Driver Override
> Protocol so
> > the driver from the option ROM manages the PCI
> controller the option
> > ROM is attached.  PCI Option ROMs can also use the
> Driver Family
> > Override Protocol so one of the PCI Option ROMs can
> manage a group
> > of PCI controllers.
> >
> > It is also possible for an FMP driver for integrated
> devices to
> > manage multiple integrated devices if there is more
> than one of
> > the same device with FW storage.  The multiple
> controller use case
> > is not limited to busses like PCI.
> >
> > The current version of the FmpDeviceLib is optimized
> for an FMP
> > instance that manages a single FW storage device.  If
> an FmpDeviceLib
> > is intended to manage multiple FW storage devices,
> then a few
> > extra services in the FmpDeviceLib are required.
> >
> > The concept is to extend the FmpDeviceLib with a
> couple extra
> > APIs that add support for Stop()/Unload() operations
> and to
> > to set the context for the current FmpDeviceLib
> actions.
> >
> > Have you entered a BZ for this issue yet?  I can
> start adding
> > details in the BZ and post some proposed changes
> soon.
> >
> > Best regards,
> >
> > Mike
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-
> >> boun...@lists.01.org] On Behalf Of Andrew Fish via
> >> edk2-devel
> >> Sent: Friday, February 8, 2019 9:16 AM
> >> To: Tomas Pilar (tpilar) 
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] Self-replicating image
> >>
> >>
> >>
> >>> On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar)
> >>  wrote:
> >>> Hi,
> >>>
> >>> I am currently pondering the most elegant way to
> >> implement capsule update for our devices that would
> >> work in the presence of multiple devices in the
> host.
> >>> Capsule allows embedding a driver that is executed
> >> prior to the update, which is very handy. Crypto
> >> library is quite large and would not fit into an
> >> OptionROM, so being able to supply FMP driver in the
> >> capsule is great.
> >>> However, if only one instance of the driver loads,
> >> the FMP upstream is currently written to support
> only
> >> one device per instance. So I wonder if there is a
> >> easy, neat way for my image to replicate on
> >> DriverBinding so that I end up with one instance per
> >> device.
> >>
> >> Tom,
> >>
> >> The usually model in EFI is to have one driver
> handle
> >> multiple things.
> >>
> >>> It looks like I should be able to do it with gBS-
> >>> LoadImage() and passing information about currently
> >> loaded image though

[edk2] [staging/Bug_1525_FmpDevicePkg_MultipleControllers] Create new branch

2019-02-27 Thread Kinney, Michael D

# FmpDevicePkg Multiple Controllers

This branch is used to evaluate methods to update the FmpDevicePkg to support
drivers that manage multiple controllers and also provide a firmware update
capability to each managed controller.  The primary use case is the update of
a PCI Option ROM when multiple adapters are present.  This branch addresses
the following TianoCore Bugzilla issues:

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

Branch owner(s):

Michael D Kinney 

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

Re: [edk2] Intel Platforms in Bugzilla

2019-02-20 Thread Kinney, Michael D

Hi Michael,

Done.  Some of these new components need more detailed descriptions.
Please follow up with how you want those filled in.

Thanks,

Mike

> -Original Message-
> From: Kubacki, Michael A
> Sent: Tuesday, February 19, 2019 5:31 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: Intel Platforms in Bugzilla
> 
> Hi Mike,
> 
> The devel-MinPlatform branch in the edk2-platforms repo
> is being used to develop Intel platform code. We plan
> to move this work to the master branch in edk2-
> platforms after a refactor in the MinPlatformPkg.
> 
> There's a need to submit feature requests and bugs
> against this code now. Do you think we could add the
> AdvancedFeaturePkg, ClevoOpenBoardPkg,
> KabylakeOpenBoardPkg, MinPlatformPkg, and
> PurleyOpenBoardPkg to the EDK2 Platforms product on
> Bugzilla?
> 
> Regards,
> Michael

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

Re: [edk2] [PATCH] MdePkg/UefiLib: Simplify protocol un/installation abstraction

2019-02-19 Thread Kinney, Michael D

Ashish,

Thanks for looking at simplifying this logic again.

I have not had a chance to run the size analysis yet.

I will get back to you in a couple of days.

Thanks,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Tuesday, February 19, 2019 8:19 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ;
> Gao, Liming 
> Subject: RE: [PATCH] MdePkg/UefiLib: Simplify protocol
> un/installation abstraction
> 
> Hello Mike/Lao,
> 
> Were you able to have a look at this?
> 
> Thanks
> Ashish
> 
> -Original Message-
> From: Ashish Singhal 
> Sent: Monday, February 4, 2019 1:16 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com;
> Ashish Singhal 
> Subject: [PATCH] MdePkg/UefiLib: Simplify protocol
> un/installation abstraction
> 
> Add helper functions to operate upon protocol
> installation and
> uninstallation instead of every function doing it by
> itself.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> ---
>  MdePkg/Library/UefiLib/UefiDriverModel.c | 2040 +-
> 
>  1 file changed, 342 insertions(+), 1698 deletions(-)
> 
> diff --git a/MdePkg/Library/UefiLib/UefiDriverModel.c
> b/MdePkg/Library/UefiLib/UefiDriverModel.c
> index 262d8bc..268edf7 100644
> --- a/MdePkg/Library/UefiLib/UefiDriverModel.c
> +++ b/MdePkg/Library/UefiLib/UefiDriverModel.c
> @@ -17,6 +17,290 @@
> 
>  #include "UefiLibInternal.h"
> 
> +
> +#define MAX_SUPPORTED_PROTOCOLS 7
> +typedef struct {
> +  EFI_GUID *Guid;
> +  VOID *Interface;
> +} EFI_PROCESS_PROTOCOL;
> +
> +
> +static
> +EFI_STATUS
> +EFIAPI
> +EfiLibProcessProtocols (
> +  IN CONST EFI_HANDLE
> ImageHandle,
> +  IN EFI_DRIVER_BINDING_PROTOCOL
> *DriverBinding,
> +  IN EFI_HANDLE
> DriverBindingHandle,
> +  IN BOOLEAN  Install,
> +  IN CONST EFI_PROCESS_PROTOCOL
> *ProtocolArray
> +  )
> +{
> +  ASSERT (DriverBinding != NULL);
> +  ASSERT (ProtocolArray != NULL);
> +
> +  if (Install) {
> +//
> +// Update the ImageHandle and DriverBindingHandle
> fields of the Driver Binding Protocol
> +//
> +DriverBinding->ImageHandle = ImageHandle;
> +DriverBinding->DriverBindingHandle =
> DriverBindingHandle;
> +
> +return gBS->InstallMultipleProtocolInterfaces (
> +  &DriverBinding->DriverBindingHandle,
> +  ProtocolArray[0].Guid,
> ProtocolArray[0].Interface,
> +  ProtocolArray[1].Guid,
> ProtocolArray[1].Interface,
> +  ProtocolArray[2].Guid,
> ProtocolArray[2].Interface,
> +  ProtocolArray[3].Guid,
> ProtocolArray[3].Interface,
> +  ProtocolArray[4].Guid,
> ProtocolArray[4].Interface,
> +  ProtocolArray[5].Guid,
> ProtocolArray[5].Interface,
> +  ProtocolArray[6].Guid,
> ProtocolArray[6].Interface,
> +  NULL
> +  );
> +  } else {
> +return gBS->UninstallMultipleProtocolInterfaces (
> +  DriverBinding->DriverBindingHandle,
> +  ProtocolArray[0].Guid,
> ProtocolArray[0].Interface,
> +  ProtocolArray[1].Guid,
> ProtocolArray[1].Interface,
> +  ProtocolArray[2].Guid,
> ProtocolArray[2].Interface,
> +  ProtocolArray[3].Guid,
> ProtocolArray[3].Interface,
> +  ProtocolArray[4].Guid,
> ProtocolArray[4].Interface,
> +  ProtocolArray[5].Guid,
> ProtocolArray[5].Interface,
> +  ProtocolArray[6].Guid,
> ProtocolArray[6].Interface,
> +  NULL
> +  );
> +  }
> +}
> +
> +
> +
> +static
> +EFI_STATUS
> +EFIAPI
> +EfiLibProcessAllDriverProtocols (
> +  IN CONST EFI_HANDLE
> ImageHandle,
> +  IN EFI_DRIVER_BINDING_PROTOCOL
> *DriverBinding,
> +  IN EFI_HANDLE
> DriverBindingHandle,
> +  IN BOOLEAN  Install,
> +  IN CONST EFI_COMPONENT_NAME_PROTOCOL
> *ComponentName,
> +  IN CONST EFI_DRIVER_CONFIGURATION_PROTOCOL
> *DriverConfiguration,
> +  IN CONST EFI_DRIVER_DIAGNOSTICS_PROTOCOL
> *DriverDiagnostics
> +  )
> +{
> +  EFI_STATUS   Status;
> +  EFI_PROCESS_PROTOCOL
> ProtocolArray[MAX_SUPPORTED_PROTOCOLS];
> +  UINT8ProtocolCount;
> +
> +  ASSERT (DriverBinding != NULL);
> +
> +  //
> +  // ZI the ProtocolArray structure. Both
> InstallMultipleProtocolInterfaces
> +  // and UninstallMultiple

Re: [edk2] [edk2-announce] Community Meeting Minutes

2019-02-14 Thread Kinney, Michael D

Rebecca,

You can review the groups.io features.  I think what you 
want is available.  Stephano has also setup an edk2 area
in groups.io for community member to try out.

https://groups.io/static/help#features

There are a number of CI services that are integrated with
GitHub.

https://github.com/marketplace/category/continuous-integration

There is work to be done to enable one of these CI services
for edk2.  Stephano has a community task to evaluate and
select a CI service.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Rebecca Cran via
> edk2-devel
> Sent: Thursday, February 14, 2019 12:28 PM
> To: Jeremiah Cox ; Ard
> Biesheuvel 
> Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org; Laszlo Ersek
> 
> Subject: Re: [edk2] [edk2-announce] Community Meeting
> Minutes
> 
> As a casual contributor, for me the biggest complaint I
> have is how busy
> the mailing list gets. I don't think a new 'announce'
> list is what's
> needed, perhaps a 'reviews' or 'discussion' list to
> split out
> discussions (from anyone) from day-to-day patches?
> Also, I'd be anxious
> about jumping to a new service like groups.io: most
> open source
> developers understand plain email, and personally I'd
> like that to stay.
> For example FreeBSD set up web forums, but most
> contributors continue to
> use the existing mailman based lists, and I suspect
> tend to forget the
> web interface exists.
> 
> 
> One thing I feel that's missing from the current
> Github-based
> infrastructure of the web site and wiki is that as far
> as I know there's
> no API documentation built regularly, or automated
> builds etc. I'm
> hosting the API documentation at e.g.
> https://code.bluestop.org/edk2/docs/master/ . Also, one
> thing a review
> system like Gerrit, Github, Phabricator, Review Board
> etc. would give us
> is the ability to run tests (lint, build/run OVMF etc.)
> against patches
> and have it comment on the review about its status to
> give committers
> more confidence in it.
> 
> 
> --
> 
> Rebecca Cran
> 
> 
> On 2/14/19 12:07 PM, Jeremiah Cox via edk2-devel wrote:
> > Hi Ard,
> > My apologies as no insult was intended.  The
> suggestion is that, similar to today, folks
> encountering difficulties with our systems could reach
> out to the TianoCore discussion venue (our mailing list
> or groups.io), and our friendly community members (we
> have many) will surely assist them.
> >
> > You are correct that my focus is not casual
> contributors, rather I want to encourage a large number
> of UEFI developers who are currently closed to stop
> their fork-modify-ship model, which is inefficient to
> service, go open to share their learnings, get current,
> stay current, upstream their changes (where it makes
> sense to the community), but not throw garbage over the
> wall.   I think there is some value in this endeavor.
> >
> > Kind Regards,
> > Jeremiah
> >
> > 
> > From: Ard Biesheuvel 
> > Sent: Friday, February 8, 2019 5:58 AM
> > To: Jeremiah Cox
> > Cc: stephano; edk2-devel@lists.01.org; Kinney,
> Michael D; Laszlo Ersek
> > Subject: Re: [edk2] [edk2-announce] Community Meeting
> Minutes
> >
> > On Thu, 7 Feb 2019 at 18:52, Jeremiah Cox via edk2-
> devel
> >  wrote:
> >> Apologies on the late reply, I was on vacation for
> several weeks and just got back to this.
> >>
> >> Regarding "Patch Review System Evaluation", on the
> call, I disagreed with your conclusion, but that note
> is not captured below.  My reading of the email and
> call discussions, I did not hear our community reject
> GitHub, rather observations that it was not "perfect",
> that it does not transparently interact with folks who
> prefer mailing list patch systems, but it would be
> acceptable to try.  On the call you mentioned a second
> justification for staying with the mailing list system,
> that GitHub (really all modern patch management
> systems) exclude folks who have limited internet
> connectivity.  I hypothesize that this theoretical
> group of Tianocore contributors would be a very small
> group of folks.  Should our community optimize our
> systems for a very small, theoretical group, penalizing
> the overwhelming majority?  I would propose that we try
> a modern patch management system, GitHub had the best
> reviews in my reading, and folks with limited internet
> connectivity find a friend to act as a go between
> translating their email diffs in

Re: [edk2] Hello Andrew query on BdsSetMemoryTypeInformationVariable

2019-02-08 Thread Kinney, Michael D

You can avoid the reboot on the first boot if the HOB
is initialized with sizes that match the usage on that
specific platform.

If you look at the boot logs, you will see messages that
show the memory type information table.  You can use that
information after a couple of boots to see the memory usage
and adjust the values used to produce the HOB in PEI.

Then rebuild with those new values and the extra reset on
first boot should go away.

The only time a reboot is required is if the memory usage
changes significantly.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Andrew Fish via
> edk2-devel
> Sent: Friday, February 8, 2019 9:36 AM
> To: galla rao ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] Hello Andrew query on
> BdsSetMemoryTypeInformationVariable
> 
> Forwarding to the edk2 list 
> 
> > On Feb 8, 2019, at 8:28 AM, galla rao
>  wrote:
> >
> > Hi Andrew,
> >
> > Am sorry for direct message!
> >
> > There is a function
> BdsSetMemoryTypeInformationVariable which causes a
> reset
> > when i enabled Secureboot related drivers
> >
> > Any clue why this function is added in EDK2?
> >
> 
> Yea it writes a variable that records how many pages of
> each memory type are used. This variable is read in PEI
> and used to pass a HOB into the DXE Core. The DXE Core
> uses these memory buckets to preallocate ranges for
> each memory type. This scheme prevents memory
> fragmentation and makes sure the runtime memory regions
> are in the same location when the system does an S4
> resume from disk.
> 
> 
> > is this a serious error, making the
> PcdResetOnMemoryTypeInformationChange to FALSE will
> resolve and boots to OS
> >
> 
> I think the idea behind that reboot, is the memory map
> could be different on the next boot and if that was an
> S4 the S4 could fail.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > shed some knowledge if you are aware of this feature
> >
> > Thanks & Regards
> > Galla
> 
> ___
> 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] Self-replicating image

2019-02-08 Thread Kinney, Michael D

Hi Thomas,

I have been looking into this topic of multiple controllers this
week.  I have some prototype code that I think resolves the issues
but needs a bit more work on some corner cases.

I am using the PCI Option ROM use case to evaluate the changes.
PCI Option ROM can use Bus Specific Driver Override Protocol so
the driver from the option ROM manages the PCI controller the option
ROM is attached.  PCI Option ROMs can also use the Driver Family
Override Protocol so one of the PCI Option ROMs can manage a group
of PCI controllers.

It is also possible for an FMP driver for integrated devices to
manage multiple integrated devices if there is more than one of
the same device with FW storage.  The multiple controller use case
is not limited to busses like PCI.

The current version of the FmpDeviceLib is optimized for an FMP
instance that manages a single FW storage device.  If an FmpDeviceLib
is intended to manage multiple FW storage devices, then a few
extra services in the FmpDeviceLib are required.

The concept is to extend the FmpDeviceLib with a couple extra
APIs that add support for Stop()/Unload() operations and to
to set the context for the current FmpDeviceLib actions.

Have you entered a BZ for this issue yet?  I can start adding
details in the BZ and post some proposed changes soon.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Andrew Fish via
> edk2-devel
> Sent: Friday, February 8, 2019 9:16 AM
> To: Tomas Pilar (tpilar) 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Self-replicating image
> 
> 
> 
> > On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar)
>  wrote:
> >
> > Hi,
> >
> > I am currently pondering the most elegant way to
> implement capsule update for our devices that would
> work in the presence of multiple devices in the host.
> >
> > Capsule allows embedding a driver that is executed
> prior to the update, which is very handy. Crypto
> library is quite large and would not fit into an
> OptionROM, so being able to supply FMP driver in the
> capsule is great.
> >
> > However, if only one instance of the driver loads,
> the FMP upstream is currently written to support only
> one device per instance. So I wonder if there is a
> easy, neat way for my image to replicate on
> DriverBinding so that I end up with one instance per
> device.
> >
> 
> 
> Tom,
> 
> The usually model in EFI is to have one driver handle
> multiple things.
> 
> > It looks like I should be able to do it with gBS-
> >LoadImage() and passing information about currently
> loaded image though I might have to CopyMem() the image
> itself to new location.
> >
> 
> gBS->LoadImage() will load and relocate the image to a
> malloced address of the correct memory type for the
> image. The inputs are just the source of the image, so
> no need to CopyMem() anything. gBS->StartImage() calls
> the entry point.
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thoughts?
> >
> > Cheers,
> > Tom
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v5 edk2-platforms 18/22] Platform/RaspberryPi/RPi3 NON-OSI: Add ATF binaries

2019-02-06 Thread Kinney, Michael D

Hi Pete,

When I saw it as a single patch series, I did assume all the
patches were for the edk2-platforms repo.  And it looked like
non-OSI binaries were going into the edk2-platforms repo.

Patch #0 did not make this clear either that multiple repos
were targeted.

I have not seen a patch series with content for multiple repos.
 
It would be clearer if there were 2 different series.  One for
edk2-platforms repo and one for the edk2-non-osi repo.

Thanks,

Mike

> -Original Message-
> From: Pete Batard [mailto:p...@akeo.ie]
> Sent: Wednesday, February 6, 2019 4:53 PM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v5 edk2-platforms 18/22]
> Platform/RaspberryPi/RPi3 *NON-OSI*: Add ATF binaries
> 
> Hi Michael,
> 
> On 2019.02.06 22:39, Kinney, Michael D wrote:
> > Hi Pete,
> >
> > We have the edk2-non-osi repository for binaries.
> 
> Not exactly sure what your point is since this patch is
> tagged *NON-OSI*
> in its subject line which means it is intended to go
> into edk2-non-osi,
> and we already went over what, in this patch series, we
> thought belonged
> or did not belong to non-osi. These ATF binaries were
> determined to
> belong to non-osi (with the intent to remove them
> altogether,
> eventually, once we have the next dot release of ATF).
> 
> Or is the issue that I am submitting non-osi patches as
> part of series
> that is prefixed [edk2-platform]?
> 
> > Do some of
> > the patches in this series really belong there?
> 
> The current consensus from previous patchsets
> submission is that the 3
> patches that are tagged as *NON-OSI* in this series are
> meant to be
> applied to edk2-non-osi whereas the other 19 are meant
> to be applied to
> edk2-platforms.
> 
> I have to say, if the issue is that you'd like to see
> an [edk2-non-osi]
> prefix for these patches, rather than a *NON-OSI*
> suffix appended, then
> doing so is a bit of a pain when you are re-submitting
> a large patchset
> series. So I do hope that simply submitting everything
> as edk2-platforms
> and tagging the non-osi ones in the subject line is
> okay.
> 
> Regards,
> 
> /Pete
> 
> > https://github.com/tianocore/edk2-non-osi
> >
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-
> >> boun...@lists.01.org] On Behalf Of Pete Batard
> >> Sent: Tuesday, February 5, 2019 8:26 AM
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] [PATCH v5 edk2-platforms 18/22]
> >> Platform/RaspberryPi/RPi3 *NON-OSI*: Add ATF
> binaries
> >>
> >> These ATF binaries were built from the ATF source
> >> (commit c3859557)
> >> with the custom RPi3 platform options detailed in
> the
> >> readme, and with
> >> no modification to the official source whatsoever.
> >>
> >> Contributed-under: TianoCore Contribution Agreement
> 1.1
> >> Signed-off-by: Pete Batard 
> >> ---
> >>
> Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> >> |  26 
> >>
> Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> >> |  42 
> >>   Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin
> >> | Bin 0 -> 18801 bytes
> >>   Platform/RaspberryPi/RPi3/TrustedFirmware/fip.bin
> >> | Bin 0 -> 41714 bytes
> >>   4 files changed, 68 insertions(+)
> >>
> >> diff --git
> >>
> a/Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> >>
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> >> new file mode 100644
> >> index ..b98dc643227e
> >> --- /dev/null
> >> +++
> >>
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> >> @@ -0,0 +1,26 @@
> >> +Copyright (c) 2013-2018, ARM Limited and
> Contributors.
> >> All rights reserved.
> >> +
> >> +Redistribution and use in source and binary forms,
> >> with or without modification,
> >> +are permitted provided that the following
> conditions
> >> are met:
> >> +
> >> +* Redistributions of source code must retain the
> above
> >> copyright notice, this
> >> +  list of conditions and the following disclaimer.
> >> +
> >> +* Redistributions in binary form must reproduce the
> >> above copyright notice, this
> >> +  list of conditions and the following disclaimer
> in
> >> the documentation and/or
> >> +  other materials provided

Re: [edk2] [PATCH v5 edk2-platforms 18/22] Platform/RaspberryPi/RPi3 NON-OSI: Add ATF binaries

2019-02-06 Thread Kinney, Michael D

Hi Pete,

We have the edk2-non-osi repository for binaries.  Do some of 
the patches in this series really belong there?

https://github.com/tianocore/edk2-non-osi

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Pete Batard
> Sent: Tuesday, February 5, 2019 8:26 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v5 edk2-platforms 18/22]
> Platform/RaspberryPi/RPi3 *NON-OSI*: Add ATF binaries
> 
> These ATF binaries were built from the ATF source
> (commit c3859557)
> with the custom RPi3 platform options detailed in the
> readme, and with
> no modification to the official source whatsoever.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard 
> ---
>  Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> |  26 
>  Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> |  42 
>  Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin
> | Bin 0 -> 18801 bytes
>  Platform/RaspberryPi/RPi3/TrustedFirmware/fip.bin
> | Bin 0 -> 41714 bytes
>  4 files changed, 68 insertions(+)
> 
> diff --git
> a/Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> new file mode 100644
> index ..b98dc643227e
> --- /dev/null
> +++
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/License.txt
> @@ -0,0 +1,26 @@
> +Copyright (c) 2013-2018, ARM Limited and Contributors.
> All rights reserved.
> +
> +Redistribution and use in source and binary forms,
> with or without modification,
> +are permitted provided that the following conditions
> are met:
> +
> +* Redistributions of source code must retain the above
> copyright notice, this
> +  list of conditions and the following disclaimer.
> +
> +* Redistributions in binary form must reproduce the
> above copyright notice, this
> +  list of conditions and the following disclaimer in
> the documentation and/or
> +  other materials provided with the distribution.
> +
> +* Neither the name of ARM nor the names of its
> contributors may be used to
> +  endorse or promote products derived from this
> software without specific prior
> +  written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS" AND
> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED
> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE ARE
> +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> CONTRIBUTORS BE LIABLE FOR
> +ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
> OR CONSEQUENTIAL DAMAGES
> +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> SUBSTITUTE GOODS OR SERVICES;
> +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> INTERRUPTION) HOWEVER CAUSED AND ON
> +ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> LIABILITY, OR TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> OUT OF THE USE OF THIS
> +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> diff --git
> a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> new file mode 100644
> index ..74bcec7d1f12
> --- /dev/null
> +++
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> @@ -0,0 +1,42 @@
> +ARM Trusted Firmware for Raspberry Pi 3
> +===
> +
> +The `bl1` and `fip` ATF binaries, found in this
> directory, were built from
> +the [official ATF source](https://github.com/ARM-
> software/arm-trusted-firmware)
> +(commit c3859557) using Linaro's GCC 5.5 compiler
> with:
> +
> +```
> +export CROSS_COMPILE=/usr/src/gcc-linaro-5.5.0-
> 2017.10-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
> +make PLAT=rpi3 PRELOADED_BL33_BASE=0x3
> RPI3_PRELOADED_DTB_BASE=0x1 SUPPORT_VFP=1
> RPI3_USE_UEFI_MAP=1 fip all
> +```
> +
> +This results in the following memory mapping:
> +
> +```
> +0x +-+
> +   |   ROM   | BL1
> +0x0001 +-+
> +   |   DTB   | (Loaded by the
> VideoCore)
> +0x0002 +-+
> +   |   FIP   |
> +0x0003 +-+
> +   | |
> +   |  UEFI PAYLOAD   |
> +   | |
> +0x0020 +-+
> +   |   Secure SRAM   | BL2, BL31
> +0x0030 +-+
> +   |   Secure DRAM   | BL32 (Secure
> payload)
> +0x0040 +-+
> +   | |
> +   | |
> +   | Non-secure DRAM | BL33
> +   | |
> +   | |
> +0x0100 +-+
> +   | |
> +   |   ...   |
> +   | |
> +0x3F00 +-+
> +   |   I/O   |

Re: [edk2] Peripheral FW capsule delivery?

2019-02-05 Thread Kinney, Michael D

Hi Brad,

In order to update a FW storage device in UEFI, a UEFI driver
that produces the Firmware Management Protocol is required.

There are some protocols to access I2C devices, so the 
implementation of the Firmware Management Protocol for
an I2C device can use the I2C protocols to perform the
I2C transactions to update the FW storage device on that
I2C device.

I am not aware of a standard for updating firmware devices
on I2C busses, so a new UEFI Driver would be required.

Please let me know if there is a public standard for 
this operation that I am not aware of.

Thanks,

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Brad Bozarth
> Sent: Tuesday, February 5, 2019 11:07 AM
> To: edk2-devel@lists.01.org
> Subject: Re: [edk2] Peripheral FW capsule delivery?
> 
> I would really appreciate a small pointer on this -
> yes/no on if is a
> standard peripheral fw delivery buit-in, and maybe a
> pointer to a doc or
> source code directory to take a look at?
> 
> Thank you,
> Brad
> 
> On Tue, Jan 29, 2019 at 4:54 PM Brad Bozarth
>  wrote:
> 
> > Hi!
> >
> > I am implementing firmware for a touchpad that will
> be going into a
> > laptop, connected via i2c. We would like to take
> advantage of the UEFI
> > firmware capsule delivery method for firmware updates
> if possible. I am
> > struggling to find out how to do this. In particular,
> I'd like to know
> > whether there is a "standard" delivery mechanism we
> can take advantage of
> > and communicate with from the firmware side over i2c,
> or if we need to
> > write UEFI driver code of some sort to pass the
> update down. We'd love to
> > leverage a standard pipe that dumps an update over
> i2c if possible and
> > implement what we need to on the firmware side. We
> are supplying our
> > touchpad to the laptop OEM and they are distant and
> have their own software
> > teams, so if we need to write UEFI code, it
> complicates matters!
> >
> > This is the page that I'd love to read, if it were
> filled out :)
> > https://github.com/mdkinney/edk2/wiki/Capsule-Based-
> Device-Firmware-Update
> >
> > Thank you!
> > Brad
> >
> ___
> 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-platforms/devel-MinPlatform][PATCH v3 1/1] ReadMe.md: Update Minimum Platform details

2019-02-05 Thread Kinney, Michael D

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Kubacki, Michael A
> Sent: Monday, February 4, 2019 5:57 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ;
> Desimone, Nathaniel L ;
> Sinha, Ankit ; Chiu, Chasel
> ; Oram, Isaac W
> ; Gao, Liming
> 
> Subject: [edk2-platforms/devel-MinPlatform][PATCH v3
> 1/1] ReadMe.md: Update Minimum Platform details
> 
> Adds details on the EDK II Minimum Platform design for
> Intel
> platforms.
> 
> * Overview of Minimum Platform
> * Board package purpose and conventions
> * Stage boot concept and control
> * Minimum Platform firmware solution stack overview
> * Updates build instructions for all OpenBoardPkgs
> * Adds information for the ClevoOpenBoardPkg
> * Adds planned activities and ideas for the future
> 
> Cc: Michael D Kinney 
> Cc: Nate DeSimone 
> Cc: Ankit Sinha 
> Cc: Chasel Chiu 
> Cc: Isaac W Oram 
> Cc: Liming Gao 
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kubacki
> 
> ---
>  ReadMe.md | 164
> ++-
> ---
>  1 file changed, 132 insertions(+), 32 deletions(-)
> 
> diff --git a/ReadMe.md b/ReadMe.md
> index 9b873da2e3..72e332a476 100644
> --- a/ReadMe.md
> +++ b/ReadMe.md
> @@ -1,8 +1,73 @@
> -# **EDK II Minimized firmware for Intel(R) platforms**
> +# **EDK II Minimum Platform Firmware for Intel(R)
> Platforms**
> 
> -## Features
> -* The Minimized Kabylake provides the minimal feature
> of the Kabylake BIOS.
> -* The Minimized Purley provides the minimal feature of
> the Purley BIOS.
> +The Minimum Platform is a software architecture that
> guides uniform delivery of Intel platforms enabling
> firmware
> +solutions for basic boot functionality with
> extensibility built-in.
> +
> +Package maintainers for the Minimum Platform projects
> are listed in Maintainers.txt.
> +
> +## Overview
> +The key elements of the architecture are organized
> into a staged boot approach where each stage has
> requirements and
> +functionality for specific use cases. The generic
> control flow through the boot process is implemented in
> the
> +[`MinPlatformPkg`](https://github.com/tianocore/edk2-
> platforms/tree/devel-
> MinPlatform/Platform/Intel/MinPlatformPkg).
> +The generic nature of the tasks performed in
> MinPlatformPkg lends to reuse across all Intel
> platforms with no
> +source modification. Details for any particular board
> are made accessible to the MinPlatformPkg through a
> well-defined
> +statically linked board API. A complete platform
> solution then consists of the MinPlatformPkg and a
> compatible board
> +package.
> +
> +## Board Naming Convention
> +The board packages supported by Intel follow the
> naming convention \OpenBoardPkg where xxx refers
> to the
> +encompassing platform name for a particular platform
> generation. For example, the
> [`KabylakeOpenBoardPkg`](https://github.com/tianocore/e
> dk2-platforms/tree/devel-
> MinPlatform/Platform/Intel/KabylakeOpenBoardPkg)
> contains the
> +board code for Intel Kaby Lake reference systems.
> Intel uses the moniker "OpenBoardPkg" to indicate that
> this package
> +is the open source board code. A closed source
> counterpart may exist which simply uses "BoardPkg".
> Both directly use
> +the MinPlatformPkg from edk2-platforms.
> +
> +## Stage Selection
> +Stage selection is controlled via the PCD
> `gMinPlatformPkgTokenSpaceGuid.PcdBootStage` in
> [`MinPlatformPkg.dec`](https://github.com/tianocore/edk
> 2-platforms/blob/devel-
> MinPlatform/Platform/Intel/MinPlatformPkg/MinPlatformPk
> g.dec).
> +The stage should be configured in the board package
> DSC file to the appropriate value. For example, a board
> may disable
> +all advanced features by setting this value to 4
> instead of 6. This may be used to improve boot time for
> a particular
> +use case. Decrementing the stage can also be used for
> debug since only the actions required for that stage
> objective
> +should be executed. As an example, ACPI initialization
> is not required for a Stage 3 boot.
> +
> +The stages are defined as follows:
> +
> +| Stage  | Functional Objective | Example
> Capabilities
> |
> +| ---|--|-
> ---
> |
> +| I  | Minimal Debug| Serial port
> output, source debug enabled, hardware debugger enabled
> |
> +| II | Memory Functional| Basic
> hardware initialization necessary to reach memory
> initia

Re: [edk2] [edk2-platforms/devel-MinPlatform][PATCH v2 1/1] ReadMe.md: Update Minimum Platform details

2019-02-04 Thread Kinney, Michael D

Hi Michael,

In order for a table to be rendered correctly in MD, a blank
line before the table is required.  See comment below where
an extra one is required.

With that change

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: Kubacki, Michael A
> Sent: Monday, February 4, 2019 5:16 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ;
> Desimone, Nathaniel L ;
> Sinha, Ankit ; Chiu, Chasel
> ; Oram, Isaac W
> ; Gao, Liming
> 
> Subject: [edk2-platforms/devel-MinPlatform][PATCH v2
> 1/1] ReadMe.md: Update Minimum Platform details
> 
> Adds details on the EDK II Minimum Platform design for
> Intel
> platforms.
> 
> * Overview of Minimum Platform
> * Board package purpose and conventions
> * Stage boot concept and control
> * Minimum Platform firmware solution stack overview
> * Updates build instructions for all OpenBoardPkgs
> * Adds information for the ClevoOpenBoardPkg
> * Adds planned activities and ideas for the future
> 
> Cc: Michael D Kinney 
> Cc: Nate DeSimone 
> Cc: Ankit Sinha 
> Cc: Chasel Chiu 
> Cc: Isaac W Oram 
> Cc: Liming Gao 
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kubacki
> 
> ---
>  ReadMe.md | 163
> ++-
> ---
>  1 file changed, 131 insertions(+), 32 deletions(-)
> 
> diff --git a/ReadMe.md b/ReadMe.md
> index 9b873da2e3..0a5e5593d2 100644
> --- a/ReadMe.md
> +++ b/ReadMe.md
> @@ -1,8 +1,72 @@
> -# **EDK II Minimized firmware for Intel(R) platforms**
> +# **EDK II Minimum Platform Firmware for Intel(R)
> Platforms**
> 
> -## Features
> -* The Minimized Kabylake provides the minimal feature
> of the Kabylake BIOS.
> -* The Minimized Purley provides the minimal feature of
> the Purley BIOS.
> +The Minimum Platform is a software architecture that
> guides uniform delivery of Intel platforms enabling
> firmware
> +solutions for basic boot functionality with
> extensibility built-in.
> +
> +Package maintainers for the Minimum Platform projects
> are listed in Maintainers.txt.
> +
> +## Overview
> +The key elements of the architecture are organized
> into a staged boot approach where each stage has
> requirements and
> +functionality for specific use cases. The generic
> control flow through the boot process is implemented in
> the
> +[`MinPlatformPkg`](https://github.com/tianocore/edk2-
> platforms/tree/devel-
> MinPlatform/Platform/Intel/MinPlatformPkg).
> +The generic nature of the tasks performed in
> MinPlatformPkg allows lends to reuse across all Intel
> platforms with no
> +source modification. Details for any particular board
> are made accessible to the MinPlatformPkg through well-
> defined
> +statically linked board API. A complete platform
> solution then consists of the MinPlatformPkg and a
> compatible board
> +package.
> +
> +## Board Naming Convention
> +The board packages supported by Intel follow the
> naming convention \OpenBoardPkg where xxx refers
> to the
> +encompassing platform name for a particular platform
> generation. For example, the
> [`KabylakeOpenBoardPkg`](https://github.com/tianocore/e
> dk2-platforms/tree/devel-
> MinPlatform/Platform/Intel/KabylakeOpenBoardPkg)
> contains the
> +board code for Intel Kaby Lake reference systems.
> Intel uses the moniker "OpenBoardPkg" to indicate that
> this package
> +is the open source board code. A closed source
> counterpart may exist which simply uses "BoardPkg".
> Both directly use
> +the MinPlatformPkg from edk2-platforms.
> +
> +## Stage Selection
> +Stage selection is controlled via the PCD
> `gMinPlatformPkgTokenSpaceGuid.PcdBootStage` in
> [`MinPlatformPkg.dec`](https://github.com/tianocore/edk
> 2-platforms/blob/devel-
> MinPlatform/Platform/Intel/MinPlatformPkg/MinPlatformPk
> g.dec).
> +The stage should be configured in the board package
> DSC file to the appropriate value. For example, a board
> may disable
> +all advanced features by setting this value to 4
> instead of 6. This may be used to improve boot time for
> a particular
> +use case. Decrementing the stage can also be used for
> debug since only the actions required for that stage
> objective
> +should be executed. As an example, ACPI initialization
> is not required for a Stage 3 boot.
> +
> +The stages are defined as follows:

Need an empty line here.

> +| Stage  | Functional Objective | Example
> Capabilities
> |
> +| ---|--|-
> ---
> |
> +| I  | Minimal Debug

Re: [edk2] [PATCH edk2-staging 10/20] IntelUndiPkg/XGigUndiDxe: drop StdLibC library class reference

2019-01-30 Thread Kinney, Michael D

Hi Richard,

It is possible to update C code to prevent the use of compiler
intrinsic functions.  This is what we have done for EDK II modules
that are built for both IA32 and X64.

The one exception is the use of OpenSSL.  We prefer to use that
project "as is" as a git submodule, so modifying the OpenSSL
sources to prevent use of intrinsic functions was not practical.
The CryptoPkg has the minimum set of intrinsic functions required
For OpenSSL to build.

We do recognize that this issue is difficult for developers to
resolve because the techniques require generation of mixed C/asm
output files to track down the C statements that are generating
the intrinsic functions.

Similar to the ARM support for an intrinsic lib, it may be 
reasonable to add a small intrinsic lib for IA32 and X64 that
supports the intrinsic functions that are seen the most often.
May  require an intrinsic lib for each supported tool chain.

This would be a new feature that would take some effort to 
implement and validate.  Can you enter an Bugzilla for this
feature and list the specific intrinsic functions needed for
this driver?

Thanks,

Mike

> -Original Message-
> From: Ryszard Knop
> [mailto:ryszard.k...@linux.intel.com]
> Sent: Wednesday, January 30, 2019 9:27 AM
> To: Ard Biesheuvel ; edk2-
> de...@lists.01.org; Carsey, Jaben
> 
> Cc: Kacperski, Kamil ; Jin,
> Eric ; Orlowski, Pawel
> ; Kinney, Michael D
> ; Hsiung, Harry L
> 
> Subject: Re: [edk2] [PATCH edk2-staging 10/20]
> IntelUndiPkg/XGigUndiDxe: drop StdLibC library class
> reference
> 
> That's actually not quite correct - we need this
> package to build on
> IA32. It's named rather unfortunately, since it's not
> the EDK2 StdLibC,
> but rather a package in this repository - see
> IntelUndiPkg/LibC. It
> contains the bare minimum of functionality required to
> fix missing 64-
> bit math/shifts on IA32 and missing memcpy/memset
> intrinsics. We can't
> prevent MSVC from yielding memcpy/memset either, so
> this was the nasty
> solution for build issues. You have included
> CompilerIntrinsicsLib for
> the same reason, too :)
> 
> I'm not aware of any X64/IA32 equivalent of your
> CompilerIntrinsicsLib,
> but I'd be happy to be proven wrong here. I'm off for
> the rest of the
> week - I'll continue with reviews and merging early
> next week.
> 
> Thanks, Richard.
> 
> On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela
> wrote:
> > StdLibc should not be used in drivers (it has
> dependencies on Shell
> > protocols), but in fact, we don't appear to rely on
> it in the first
> > place, so just drop the reference.
> >
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Ard Biesheuvel  linaro.org>
> > ---
> >  IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > index beee8aa8134e..b5747565fbea 100644
> > --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > @@ -132,7 +132,6 @@ GCC:*_*_*_CC_FLAGS = -DEFI32
> >PrintLib
> >UefiLib
> >HiiLib
> > -  StdLibC
> >
> >  [LibraryClasses.X64]
> >

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

Re: [edk2] Fmp Payload Header Usage

2019-01-29 Thread Kinney, Michael D

Hi Ashish,

You do need to use the standalone tool called GenerateCapsule to convert
a payload to a UEFI Capsule.

Here is an example:

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/Feature/Capsule/GenerateCapsule/GenCapsuleMinnowMax.bat

You can customize this script for your platform.  This script is for
dev/debug purposes only for use on a local dev system.  It supports
different keys and tools to generate a UEFI Capsule.  You can simplify
it for a specific tool/key option.

You can integrate this into the standard build process by adding a
script to the DSC file as a post build step.

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformCapsule.dsc

  POSTBUILD = 
Vlv2TbltDevicePkg/Feature/Capsule/GenerateCapsule/GenCapsuleAll.bat

This specific platform has some extra steps that need to be 
performed after the normal build of the FW image before the capsule
is generated, so a 2nd DSC/FDF file is used.  If you do not have 
any extra steps, then you can add the POSTBUILD statement to the
[Defines] section of your platform DSC file.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Ashish Singhal
> Sent: Tuesday, January 29, 2019 1:09 PM
> To: Gao, Liming ; Kinney, Michael
> D 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] Fmp Payload Header Usage
> 
> Hello Michael/Liming,
> 
> I am trying to use FmpDevicePkg for FMP based capsule
> update and am failing in FmpPayloadHeaderLib while
> verifying FMP payload header. I am building capsule and
> payload using FDF file itself and not calling Capsule
> tools explicitly from basetools. Is there a special
> build flag I need to provide to add FMP payload header
> to my payload?
> 
> Thanks
> Ashish
> 
> 
> ---
> This email message is for the sole use of the intended
> recipient(s) and may contain
> confidential information.  Any unauthorized review, use,
> disclosure or distribution
> is prohibited.  If you are not the intended recipient,
> please contact the sender by
> reply email and destroy all copies of the original
> message.
> 
> ---
> ___
> 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] History question about Base.h and its alternate parallel name space.... Should we change it?

2019-01-23 Thread Kinney, Michael D

Hi Andrew,

I think it makes sense for new code to use the
UEFI type names and for existing code to remain unchanged.

>From looking at UefiBaseTypes.h, I do not think we should
move all types from that file into Base.h.  If we really
wanted to do that, we could simple add #include of 
UefiBaseTypes.h to Base.h.

Moving a few lines from UefiBaseTypes.h to Base.h at the
bottom of Base.h with a comment block that explains why
the UEFI specific types/defines are available from Base.h
would be another way to add a subset of types/defines.  
That way, if we decide to move more in the future, there
is a place to move them that is easy to review.

Do you want to propose the specific types/defines that 
should be moved?

Best regards,

Mike

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, January 22, 2019 5:00 PM
> To: Kinney, Michael D 
> Cc: Felix Poludov ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] History question about Base.h and
> its alternate parallel name space Should we change
> it?
> 
> 
> 
> > On Jan 22, 2019, at 9:49 AM, Kinney, Michael D
>  wrote:
> >
> > Andrew,
> >
> > If we move all of those, then what are the code review
> rules for a lib of type BASE?
> >
> > Is there a preference to use the current BASE types?
> Under what conditions are EFI type names allowed?
> >
> > Is the a preference to stop using the current BASE
> types all together?
> >
> 
> Mike,
> 
> it seems messy to add types to Base.h to support Base
> Libs. So for example IPv4_ADDRESS and IPv6_ADDRESS got
> sucked into Base.h since an MdePkg Base Lib got added
> that used it. That does not really seem to scale to Base
> Libs in other packages. Thus I guess the preference
> would be to use the common EFI_* names. I'd not advocate
> removing the old names as that is going to break other
> folks Base LIbs. We could do the cleanup in TianoCore.
> If we want to deprecate the old names form, I guess that
> could be an ifdef to allow some depreciation in the
> future?
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: af...@apple.com [mailto:af...@apple.com]
> >> Sent: Friday, January 18, 2019 9:24 AM
> >> To: Felix Poludov 
> >> Cc: Kinney, Michael D ;
> >> edk2-devel@lists.01.org
> >> Subject: Re: [edk2] History question about Base.h and
> >> its alternate parallel name space Should we
> change
> >> it?
> >>
> >>
> >>
> >>> On Jan 18, 2019, at 9:08 AM, Felix Polyudov
> >>  wrote:
> >>>
> >>> Mike,
> >>>
> >>> I think EFI_GUID and EFI_STATUS should cover most of
> >> the use cases.
> >>>
> >>
> >> I think I missed a couple in my original mail
> >>
> >> But here are the typedef and #define names that get
> >> remapped (or redone) in
> >> MdePkg/Include/Uefi/UefiBaseType.h
> >>
> >> typedef struct {
> >>  UINT32  Data1;
> >>  UINT16  Data2;
> >>  UINT16  Data3;
> >>  UINT8   Data4[8];
> >> } GUID;
> >>
> >> typedef struct {
> >>  UINT8 Addr[4];
> >> } IPv4_ADDRESS;
> >>
> >> typedef struct {
> >>  UINT8 Addr[16];
> >> } IPv6_ADDRESS;
> >>
> >> typedef UINT64 PHYSICAL_ADDRESS;
> >> typedef UINTN RETURN_STATUS;
> >>
> >> #define ENCODE_ERROR(StatusCode)
> >> ((RETURN_STATUS)(MAX_BIT | (StatusCode)))
> >> #define ENCODE_WARNING(StatusCode)
> >> ((RETURN_STATUS)(StatusCode))
> >> #define RETURN_ERROR(StatusCode)
> >> (((INTN)(RETURN_STATUS)(StatusCode)) < 0)
> >> #define RETURN_SUCCESS           0
> >> #define RETURN_LOAD_ERRORENCODE_ERROR (1)
> >> #define RETURN_INVALID_PARAMETER ENCODE_ERROR (2)
> >> 
> >>
> >>
> >> I think the cleanup would be as simple as moving
> things
> >> from MdePkg/Include/Uefi/UefiBaseType.h to
> >> MdePkg/Include/Base.h.
> >>
> >> So:
> >>
> >> typedef struct {
> >>  UINT32  Data1;
> >>  UINT16  Data2;
> >>  UINT16  Data3;
> >>  UINT8   Data4[8];
> >> } GUID;
> >>
> >> Becomes:
> >>
> >> typedef struct {
> >>  UINT32  Data1;
> >>  UINT16  Data2;
> >>  UINT16  Data3;
> >>  UINT8   Data4[8];
> >> } GUID, EFI_GUID;
> >>
> >> Thanks,
> >>
&

Re: [edk2] [PATCH v1] ClevoOpenBoardPkg: Add initial implementation of ClevoOpenBoardPkg

2019-01-22 Thread Kinney, Michael D

Hi Michael,

1) Is this content intended for a new branch or an 
   existing branch in the edk2-platforms repo?  The
   subject line of the commit message can help clarify
   this.  The required format is:

[PATCH][platforms/branch]: Package/Module: Subject

2) The patch email size is large (2MB).  Can you break 
   it up into a patch series.  Perhaps one for the new
   package with its DEC/Includes, one or more for the
   package libraries, one or more for the package modules,
   and one for the package DSC/FDF/platform build files?
   Try to target < 500KB per patch.

   If a patch series is large, another recommendation
   is to also post the patch series to a personal GitHub
   account to support review/test by the community.

3) I see .bat files.  Are there any plans to support
   non windows build environments?

4) If you run BaseTools/Scripts/PatchCheck.py, there
   are 2 minor issues to resolve.

Best regards,

Mike

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

Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?

2019-01-22 Thread Kinney, Michael D

Andrew,

If we move all of those, then what are the code review rules for a lib of type 
BASE?

Is there a preference to use the current BASE types?  Under what conditions are 
EFI type names allowed?

Is the a preference to stop using the current BASE types all together?

Thanks,

Mike

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Friday, January 18, 2019 9:24 AM
> To: Felix Poludov 
> Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] History question about Base.h and
> its alternate parallel name space Should we change
> it?
> 
> 
> 
> > On Jan 18, 2019, at 9:08 AM, Felix Polyudov
>  wrote:
> >
> > Mike,
> >
> > I think EFI_GUID and EFI_STATUS should cover most of
> the use cases.
> >
> 
> I think I missed a couple in my original mail
> 
> But here are the typedef and #define names that get
> remapped (or redone) in
> MdePkg/Include/Uefi/UefiBaseType.h
> 
> typedef struct {
>   UINT32  Data1;
>   UINT16  Data2;
>   UINT16  Data3;
>   UINT8   Data4[8];
> } GUID;
> 
> typedef struct {
>   UINT8 Addr[4];
> } IPv4_ADDRESS;
> 
> typedef struct {
>   UINT8 Addr[16];
> } IPv6_ADDRESS;
> 
> typedef UINT64 PHYSICAL_ADDRESS;
> typedef UINTN RETURN_STATUS;
> 
> #define ENCODE_ERROR(StatusCode)
> ((RETURN_STATUS)(MAX_BIT | (StatusCode)))
> #define ENCODE_WARNING(StatusCode)
> ((RETURN_STATUS)(StatusCode))
> #define RETURN_ERROR(StatusCode)
> (((INTN)(RETURN_STATUS)(StatusCode)) < 0)
> #define RETURN_SUCCESS   0
> #define RETURN_LOAD_ERRORENCODE_ERROR (1)
> #define RETURN_INVALID_PARAMETER ENCODE_ERROR (2)
> 
> 
> 
> I think the cleanup would be as simple as moving things
> from MdePkg/Include/Uefi/UefiBaseType.h to
> MdePkg/Include/Base.h.
> 
> So:
> 
> typedef struct {
>   UINT32  Data1;
>   UINT16  Data2;
>   UINT16  Data3;
>   UINT8   Data4[8];
> } GUID;
> 
> Becomes:
> 
> typedef struct {
>   UINT32  Data1;
>   UINT16  Data2;
>   UINT16  Data3;
>   UINT8   Data4[8];
> } GUID, EFI_GUID;
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> [mailto:michael.d.kin...@intel.com]
> > Sent: Thursday, January 17, 2019 3:04 PM
> > To: Felix Polyudov; 'Andrew Fish'; Kinney, Michael D
> > Cc: edk2-devel@lists.01.org
> > Subject: RE: [edk2] History question about Base.h and
> its alternate parallel name space Should we change
> it?
> >
> > Felix,
> >
> > Is there a specific set that would have the most
> benefit?
> >
> > Is EFI_GUID sufficient?
> >
> > Mike
> >
> >> -Original Message-
> >> From: Felix Polyudov [mailto:fel...@ami.com]
> >> Sent: Wednesday, January 16, 2019 3:10 PM
> >> To: 'Andrew Fish' ; Kinney, Michael
> D
> >> 
> >> Cc: edk2-devel@lists.01.org
> >> Subject: RE: [edk2] History question about Base.h and
> >> its alternate parallel name space Should we
> change
> >> it?
> >>
> >> I agree with Andrew.
> >> In my opinion, moving alias types to Base.h will help
> to
> >> overcome certain practical inconveniences without
> >> a significant impact on the ability to detect poorly
> >> written Base libraries.
> >>
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-
> >> boun...@lists.01.org] On Behalf Of Andrew Fish via
> edk2-
> >> devel
> >> Sent: Wednesday, January 16, 2019 5:18 PM
> >> To: Mike Kinney
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] History question about Base.h and
> >> its alternate parallel name space Should we
> change
> >> it?
> >>
> >>
> >>
> >>> On Jan 16, 2019, at 1:19 PM, Kinney, Michael D
> >>  wrote:
> >>>
> >>> Hi Andrew,
> >>>
> >>> I though the reason was a bit more technical.  We
> have
> >> a
> >>> MODULE_TYPE of BASE.  Library instances that use the
> >> BASE
> >>> MODULE_TYPE are declaring that the library
> interfaces
> >> are
> >>> safe to be linked against a module of any other type
> >> (SEC,
> >>> PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP).
> >>>
> >>> We needed to make sure that a lib of type BASE that
> >>> includes Base.h as its top level include file only
> has
> >>> visibility to the types that are s

Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?

2019-01-17 Thread Kinney, Michael D

Felix,

Is there a specific set that would have the most benefit?

Is EFI_GUID sufficient?

Mike

> -Original Message-
> From: Felix Polyudov [mailto:fel...@ami.com]
> Sent: Wednesday, January 16, 2019 3:10 PM
> To: 'Andrew Fish' ; Kinney, Michael D
> 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] History question about Base.h and
> its alternate parallel name space Should we change
> it?
> 
> I agree with Andrew.
> In my opinion, moving alias types to Base.h will help to
> overcome certain practical inconveniences without
> a significant impact on the ability to detect poorly
> written Base libraries.
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Andrew Fish via edk2-
> devel
> Sent: Wednesday, January 16, 2019 5:18 PM
> To: Mike Kinney
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] History question about Base.h and
> its alternate parallel name space.... Should we change
> it?
> 
> 
> 
> > On Jan 16, 2019, at 1:19 PM, Kinney, Michael D
>  wrote:
> >
> > Hi Andrew,
> >
> > I though the reason was a bit more technical.  We have
> a
> > MODULE_TYPE of BASE.  Library instances that use the
> BASE
> > MODULE_TYPE are declaring that the library interfaces
> are
> > safe to be linked against a module of any other type
> (SEC,
> > PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP).
> >
> > We needed to make sure that a lib of type BASE that
> > includes Base.h as its top level include file only has
> > visibility to the types that are safe for all the
> other
> > module types.  It is up to the top level include files
> > for these other module types to provide the gasket to
> > the types in Base.h.
> >
> > If we add aliases in Base.h, then we may not get build
> > breaks when a lib of type BASE includes files that are
> > not compatible with BASE.
> >
> 
> Mike,
> 
> I don't think having aliases for return types really
> helps Base code quality  as RETURN_SUCCESS is almost
> always just a comment in a header file, and only exists
> in a .c file. Thus RETURN_* seem like a needless
> duplication, best case it is a comment that the code is
> Base.
> 
> I will agree that not having EFI_GUID defined does case
> all the PPI and Protocol files to blow up if you try to
> include them. The failure case I was helping explain was
> some one trying to include a PPI, that included a
> Protocol that contained a data structure that was
> needed. But I would posit that the definition of a
> (EFI_)GUID is state agnostic. Having access to a PPI or
> Protocol definition does not break Base code, what
> breaks Base code is trying to access some service that
> does not exist. To get more that EFI_GUID you are going
> to need to include Uefi.h, PiPei.h, PiDxe.h, etc. and
> that will block doing anything that is not Base.
> 
> So I'm asking if redefining the name for EFI_GUID to
> GUID for Base is really that helpful?
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-
> >> boun...@lists.01.org] On Behalf Of Andrew Fish via
> edk2-
> >> devel
> >> Sent: Wednesday, January 16, 2019 1:00 PM
> >> To: edk2-devel 
> >> Subject: [edk2] History question about Base.h and its
> >> alternate parallel name space Should we change
> it?
> >>
> >> I had some one ask me recently why EFI_GUID does not
> >> work with #include . I explained they needed
> to
> >> use GUID vs. EFI_GUID. That prompted the question of
> why
> >> we have 2 names for the same thing. Well the
> >> historical answer was kind of political as some team
> >> wanted to use edk2, but not implement EFI. Thus we
> have
> >> EFI types without the EFI_ prefix in Base.h.
> >>
> >> So all this got me thinking  Maybe it makes sense
> to
> >> move some of the renaming from
> >> MdePkg/Include/Uefi/UefiBaseType.h to Base.h?
> Removing
> >> the Base.h duplicate types would potentially hit lots
> of
> >> code [1] and break merges with other code bases
> (break
> >> other peoples Base libs etc.).
> >>
> >> These lines in MdePkg/Include/Uefi/UefiBaseType.h
> would
> >> get moved to MdePkg/Include/Base.h:
> >> typedef GUID  EFI_GUID;
> >> typedef RETURN_STATUS EFI_STATUS;
> >> #define EFIERR(_a)ENCODE_ERROR(_a)
>

Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?

Hi Andrew,

I though the reason was a bit more technical.  We have a
MODULE_TYPE of BASE.  Library instances that use the BASE
MODULE_TYPE are declaring that the library interfaces are
safe to be linked against a module of any other type (SEC,
PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP).

We needed to make sure that a lib of type BASE that
includes Base.h as its top level include file only has
visibility to the types that are safe for all the other
module types.  It is up to the top level include files
for these other module types to provide the gasket to
the types in Base.h.

If we add aliases in Base.h, then we may not get build
breaks when a lib of type BASE includes files that are
not compatible with BASE.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Andrew Fish via edk2-
> devel
> Sent: Wednesday, January 16, 2019 1:00 PM
> To: edk2-devel 
> Subject: [edk2] History question about Base.h and its
> alternate parallel name space Should we change it?
> 
> I had some one ask me recently why EFI_GUID does not
> work with #include . I explained they needed to
> use GUID vs. EFI_GUID. That prompted the question of why
> we have 2 names for the same thing. Well the
> historical answer was kind of political as some team
> wanted to use edk2, but not implement EFI. Thus we have
> EFI types without the EFI_ prefix in Base.h.
> 
> So all this got me thinking  Maybe it makes sense to
> move some of the renaming from
> MdePkg/Include/Uefi/UefiBaseType.h to Base.h? Removing
> the Base.h duplicate types would potentially hit lots of
> code [1] and break merges with other code bases (break
> other peoples Base libs etc.).
> 
> These lines in MdePkg/Include/Uefi/UefiBaseType.h would
> get moved to MdePkg/Include/Base.h:
> typedef GUID  EFI_GUID;
> typedef RETURN_STATUS EFI_STATUS;
> #define EFIERR(_a)ENCODE_ERROR(_a)
> #define EFI_ERROR(A)  RETURN_ERROR(A)
> 
> #define EFI_SUCCESS   RETURN_SUCCESS
> #define EFI_LOAD_ERRORRETURN_LOAD_ERROR
> #define EFI_INVALID_PARAMETER
> RETURN_INVALID_PARAMETER
> #define EFI_UNSUPPORTED   RETURN_UNSUPPORTED
> #define EFI_BAD_BUFFER_SIZE   RETURN_BAD_BUFFER_SIZE
> #define EFI_BUFFER_TOO_SMALL
> RETURN_BUFFER_TOO_SMALL
> #define EFI_NOT_READY RETURN_NOT_READY
> #define EFI_DEVICE_ERROR  RETURN_DEVICE_ERROR
> #define EFI_WRITE_PROTECTED   RETURN_WRITE_PROTECTED
> #define EFI_OUT_OF_RESOURCES
> RETURN_OUT_OF_RESOURCES
> #define EFI_VOLUME_CORRUPTED
> RETURN_VOLUME_CORRUPTED
> #define EFI_VOLUME_FULL   RETURN_VOLUME_FULL
> #define EFI_NO_MEDIA  RETURN_NO_MEDIA
> #define EFI_MEDIA_CHANGED RETURN_MEDIA_CHANGED
> #define EFI_NOT_FOUND RETURN_NOT_FOUND
> #define EFI_ACCESS_DENIED RETURN_ACCESS_DENIED
> #define EFI_NO_RESPONSE   RETURN_NO_RESPONSE
> #define EFI_NO_MAPPINGRETURN_NO_MAPPING
> #define EFI_TIMEOUT   RETURN_TIMEOUT
> #define EFI_NOT_STARTED   RETURN_NOT_STARTED
> #define EFI_ALREADY_STARTED   RETURN_ALREADY_STARTED
> #define EFI_ABORTED   RETURN_ABORTED
> #define EFI_ICMP_ERRORRETURN_ICMP_ERROR
> #define EFI_TFTP_ERRORRETURN_TFTP_ERROR
> #define EFI_PROTOCOL_ERRORRETURN_PROTOCOL_ERROR
> #define EFI_INCOMPATIBLE_VERSION
> RETURN_INCOMPATIBLE_VERSION
> #define EFI_SECURITY_VIOLATION
> RETURN_SECURITY_VIOLATION
> #define EFI_CRC_ERROR RETURN_CRC_ERROR
> #define EFI_END_OF_MEDIA  RETURN_END_OF_MEDIA
> #define EFI_END_OF_FILE   RETURN_END_OF_FILE
> #define EFI_INVALID_LANGUAGE
> RETURN_INVALID_LANGUAGE
> #define EFI_COMPROMISED_DATA
> RETURN_COMPROMISED_DATA
> #define EFI_HTTP_ERRORRETURN_HTTP_ERROR
> 
> #define EFI_WARN_UNKNOWN_GLYPH
> RETURN_WARN_UNKNOWN_GLYPH
> #define EFI_WARN_DELETE_FAILURE
> RETURN_WARN_DELETE_FAILURE
> #define EFI_WARN_WRITE_FAILURE
> RETURN_WARN_WRITE_FAILURE
> #define EFI_WARN_BUFFER_TOO_SMALL
> RETURN_WARN_BUFFER_TOO_SMALL
> #define EFI_WARN_STALE_DATA   RETURN_WARN_STALE_DATA
> #define EFI_WARN_FILE_SYSTEM
> RETURN_WARN_FILE_SYSTEM
> 
> I'm interested what folks think about a change like
> this? This change makes the alternate names optional.
> 
> I guess we could also leave the old Base.h definitions
> in Base.h and cleanup the code to only use the EFI form,
> but that is a much bigger change?
> 
> [1] RETURN_SUCCSS usage: git grep -w RETURN_SUCCESS
> 
> Thanks,
> 
> Andrew Fish
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 04/17] Vlv2TbltDevicePkg: add MmServicesTableLib resolution

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Ard Biesheuvel
> Sent: Wednesday, January 16, 2019 9:45 AM
> To: Gao, Liming ; Qian, Yi
> 
> Cc: Wu, Hao A ; edk2-
> de...@lists.01.org; Kinney, Michael D
> ; Laszlo Ersek
> ; Zeng, Star 
> Subject: Re: [edk2] [PATCH v2 04/17] Vlv2TbltDevicePkg:
> add MmServicesTableLib resolution
> 
> (add Yi as well)
> 
> On Wed, 16 Jan 2019 at 16:14, Gao, Liming
>  wrote:
> >
> > Zailiang:
> >   Could you help review this change?
> >
> > > -Original Message-
> > > From: Ard Biesheuvel
> [mailto:ard.biesheu...@linaro.org]
> > > Sent: Monday, January 14, 2019 9:28 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Ard Biesheuvel ;
> Laszlo Ersek ; Leif Lindholm
> ; Kinney,
> > > Michael D ; Gao, Liming
> ; Wang, Jian J
> ; Wu, Hao A
> > > ; Jagadeesh Ujja
> ; Achin Gupta
> ; Thomas Panakamattam
> > > Abraham ; Sami Mujawar
> ; Zeng, Star 
> > > Subject: [PATCH v2 04/17] Vlv2TbltDevicePkg: add
> MmServicesTableLib resolution
> > >
> > > The SMM based FTW and variable drivers are going to
> depend on
> > > MmServicesTableLib after a subsequent patch, so add
> a resolution
> > > for it to various Vlv2TbltDevicePkg .dsc files.
> > >
> > > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > > Signed-off-by: Ard Biesheuvel
> 
> > > ---
> > >  Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 +
> > >  Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 1 +
> > >  Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 1 +
> > >  3 files changed, 3 insertions(+)
> > >
> > > diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
> b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
> > > index d43611550285..eb7c205a10a6 100644
> > > --- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
> > > +++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
> > > @@ -406,6 +406,7 @@ [LibraryClasses.X64.DXE_CORE]
> > >  !endif
> > >
> > >  [LibraryClasses.X64.DXE_SMM_DRIVER]
> > > +
> MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmS
> ervicesTableLib.inf
> > >
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/S
> mmServicesTableLib.inf
> > >
> ReportStatusCodeLib|MdeModulePkg/Library/SmmReportStatus
> CodeLib/SmmReportStatusCodeLib.inf
> > >
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLi
> b/SmmMemoryAllocationLib.inf
> > > diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> > > index a33816c4d18b..b2f0d73f6d05 100644
> > > --- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> > > +++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> > > @@ -406,6 +406,7 @@ [LibraryClasses.IA32.DXE_CORE]
> > >  !endif
> > >
> > >  [LibraryClasses.IA32.DXE_SMM_DRIVER]
> > > +
> MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmS
> ervicesTableLib.inf
> > >
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/S
> mmServicesTableLib.inf
> > >
> ReportStatusCodeLib|MdeModulePkg/Library/SmmReportStatus
> CodeLib/SmmReportStatusCodeLib.inf
> > >
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLi
> b/SmmMemoryAllocationLib.inf
> > > diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> > > index 1da1442c64c6..aa62c07f177b 100644
> > > --- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> > > +++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> > > @@ -408,6 +408,7 @@ [LibraryClasses.X64.DXE_CORE]
> > >  !endif
> > >
> > >  [LibraryClasses.X64.DXE_SMM_DRIVER]
> > > +
> MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmS
> ervicesTableLib.inf
> > >
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/S
> mmServicesTableLib.inf
> > >
> ReportStatusCodeLib|MdeModulePkg/Library/SmmReportStatus
> CodeLib/SmmReportStatusCodeLib.inf
> > >
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLi
> b/SmmMemoryAllocationLib.inf
> > > --
> > > 2.20.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] [RFC v2] Proposal to add edk2-libc

Hello,

I shared an RFC in November to add an edk2-apps repository.

https://lists.01.org/pipermail/edk2-devel/2018-November/00.html

Feedback in this thread discussed that there are three types
of applications.  Apps that use libc, UEFI Shell apps,
and UEFI Applications.  I would like this RFC to focus on libc
applications, and changes related to UEFI Shell apps and
UEFI Applications can be handled separately.  The updated
RFC is shown below.  The repo name has been changed from
edk2-apps to edk2-libc based on feedback from Leif.



I would like to propose the creation of a new
repository called edk2-libc.  This repository
would initially be used to host the following
packages from the edk2 repository:

* AppPkg
* StdLib
* StdLibPrivateInternalFiles

These 3 packages provide support for the libc along
with applications that depend on libc.  None of the
other packages in the edk2 repository use these
packages, so these 3 package can be safely moved
without any impacts to platform firmware builds.
Build configurations that do use libc features can
clone the edk2-libc repository and add it to
PACKAGES_PATH.

The history of these 3 packages would be preserved
when importing the content into edk2-libc.  After
the import is verified, these 3 packages would be
deleted from the edk2 repository.

This proposal helps reduce the size of the edk2
repository and focuses edk2 repository on packages
used to provide UEFI/PI conformant firmware.

If there are no concerns with this proposal, I will
enter a Tianocore BZs for the two steps.

Best regards,

Mike

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

Re: [edk2] [PATCH V3 15/17] QuarkMin: Use merged variable driver for emulated NV mode

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Kinney, Michael D
> ; Steele, Kelly
> 
> Subject: [PATCH V3 15/17] QuarkMin: Use merged variable
> driver for emulated NV mode
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
> 
> The real variable driver has been updated to support
> emulated
> variable NV mode and the EmuVariableRuntimeDxe will be
> removed
> later, so use merged variable driver for emulated NV
> mode.
> 
> Cc: Michael D Kinney 
> Cc: Kelly Steele 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  QuarkPlatformPkg/QuarkMin.dsc | 8 ++--
>  QuarkPlatformPkg/QuarkMin.fdf | 4 ++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/QuarkPlatformPkg/QuarkMin.dsc
> b/QuarkPlatformPkg/QuarkMin.dsc
> index d7a25686a30b..bf3a9a8bfd0e 100644
> --- a/QuarkPlatformPkg/QuarkMin.dsc
> +++ b/QuarkPlatformPkg/QuarkMin.dsc
> @@ -2,7 +2,7 @@
>  # Clanton Peak CRB platform with 32-bit DXE for 4MB/8MB
> flash devices.
>  #
>  # This package provides Clanton Peak CRB platform
> specific modules.
> -# Copyright (c) 2013 - 2018 Intel Corporation.
> +# Copyright (c) 2013 - 2019 Intel Corporation.
>  #
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and
> conditions of the BSD License
> @@ -342,6 +342,10 @@ [PcdsFixedAtBuild]
>  !endif
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdHwErrStorageSize|0x000
> 02000
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariab
> leSize|0x1000
> +  #
> +  # Make VariableRuntimeDxe work at emulated non-
> volatile variable mode.
> +  #
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnabl
> e|TRUE
>## RTC Update Timeout Value, need to increase timeout
> since also
># waiting for RTC to be busy.
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdRealTimeClockUpdateTim
> eout|50
> @@ -553,7 +557,7 @@ [Components.IA32]
>MdeModulePkg/Universal/Metronome/Metronome.inf
> 
> MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.in
> f
>MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
> -
> MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariabl
> eRuntimeDxe.inf
> +
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRunti
> meDxe.inf
> 
> MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeD
> xe.inf
> 
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/Monoto
> nicCounterRuntimeDxe.inf
> 
> MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem
> RuntimeDxe.inf
> diff --git a/QuarkPlatformPkg/QuarkMin.fdf
> b/QuarkPlatformPkg/QuarkMin.fdf
> index b793fbd9a340..6e5545c16d3b 100644
> --- a/QuarkPlatformPkg/QuarkMin.fdf
> +++ b/QuarkPlatformPkg/QuarkMin.fdf
> @@ -2,7 +2,7 @@
>  # FDF file of Clanton Peak CRB platform with 32-bit DXE
>  #
>  # This package provides QuarkNcSocId platform specific
> modules.
> -# Copyright (c) 2013 - 2017 Intel Corporation.
> +# Copyright (c) 2013 - 2019 Intel Corporation.
>  #
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and
> conditions of the BSD License
> @@ -388,7 +388,7 @@ [FV.FVMAIN]
>  INF  MdeModulePkg/Universal/Metronome/Metronome.inf
>  INF
> MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.in
> f
>  INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
> -INF
> MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariabl
> eRuntimeDxe.inf
> +INF
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRunti
> meDxe.inf
>  INF
> MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeD
> xe.inf
>  INF
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/Monoto
> nicCounterRuntimeDxe.inf
>  INF
> MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem
> RuntimeDxe.inf
> --
> 2.7.0.windows.1

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

Re: [edk2] Conditional Compilation support in INF file

2019-01-11 Thread Kinney, Michael D

Karunakar,

Feature Flag Expressions is a concept that is defined in the
specs, but is a feature that is not fully implemented.  Liming
should be able to provide details on what has been implemented
and validated in BaseTools.  I think the reason that this feature
has not been implemented fully is that we have been able to find
alternate ways to get the equivalent results.  Here are a few
example techniques:

3a: One approach is to use multiple INF files and select the
Right INF for different types of platform builds in DSC file.
If multiple modules share source files but have different
elements produced/consumed/depex, then multiple INF
file is an approach that makes the produced/consumed/depex
clear and is compatible with UDP Spec.

3c: One approach is to use DEBUG_CODE(), DEBUG_CODE_BEGIN(),
and DEBUG_CODE_END() macros in a single version of the
source files and enable/disable the debug code using BIT2
in the following PCD:

  ## The mask is used to control DebugLib behavior.
  #  BIT0 - Enable Debug Assert.
  #  BIT1 - Enable Debug Print.
  #  BIT2 - Enable Debug Code.
  #  BIT3 - Enable Clear Memory.
  #  BIT4 - Enable BreakPoint as ASSERT.
  #  BIT5 - Enable DeadLoop as ASSERT.
  # @Prompt Debug Property.
  # @Expression  0x8002 | (gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask & 
0xC0) == 0
  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0|UINT8|0x0005

3c: Another approach is to use multiple INF files and select
the one needed for debug/release in DSC file.

If these techniques, or other techniques that other community
Member may be using do not work for your use cases, and 
Feature Flag Expressions are the best approach, then Bugzillas
Can be entered with supporting use cases to justify adding the
feature to BaseTools.

Thanks,
 
Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> karunakarpoosapa...@dell.com
> Sent: Thursday, January 10, 2019 10:34 PM
> To: Kinney, Michael D ; Gao,
> Liming ; ler...@redhat.com; edk2-
> de...@lists.01.org
> Cc: sumanth.vidyadh...@dell.com; shekar.bab...@dell.com;
> Gao, Liming ;
> sriramkumar.r...@dell.com
> Subject: Re: [edk2] Conditional Compilation support in
> INF file
> 
> Hi All,
> 
> Thank you very much for your valuable thoughts.
> Below are my concerns/thoughts, Could you please help on
> 
> 1. Is there any module or INF already using
> FeatureFlagExpression feature support in current edk2
> source?
> 2. If not, could you please help in providing more
> detailed spec/Doc to verify this support.
> 3. Below are the few of use cases we're looking for, Did
> really FeatureFlagExpression support all of this?
>   a.  If we've this support we can add different
> protocols in DEPEX section, like we can put condition
> check and add rotococol1 for Notebook and Protocol2 for
> Desktop.
>   b.   Help in simplifying build files. We
> could dispense with the prefix to inf files and more
> developer convenient.
>   c.  Sometimes we would like to add Conditional  .C
> and .H for file inclusion. Helps in our Debug / release
> builds as well..
>   Example; we do have release and debug
> build, although Source Section has - IA32,X64, Common,
> IPF, EBC exclusively.
> But for the same Source section, we
> can't have choices based on our build inputs...
> 
>   #if Condition1
> [Sources]
>   Main.c
>   #elif Condition2
>[Sources]
>   DebugMain.c
> 
> 4. I don't think INF file support MACRO support, How
> complex in modifying the BaseTools to support Condition
> checks and MACRO support?
> 
> Thanks & Regards,
> Karunakar
> 
> -Original Message-
> From: Kinney, Michael D
> [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, January 10, 2019 10:23 PM
> To: Gao, Liming; Laszlo Ersek; Poosapalli, Karunakar;
> edk2-devel@lists.01.org; Kinney, Michael D
> Cc: Vidyadhara, Sumanth; Gao, Liming; Raju, SriramKumar
> Subject: RE: [edk2] Conditional Compilation support in
> INF file
> 
> 
> [EXTERNAL EMAIL]
> 
> There is one additional constraint for adding
> conditionals to INF files.
> 
> The UEFI Distribution Packaging Specification defines a
> format to share package and module content in a standard
> format and uses an XML schema for the metadata.  We need
> to be ab

Re: [edk2] Conditional Compilation support in INF file

2019-01-10 Thread Kinney, Michael D

There is one additional constraint for adding conditionals
to INF files.

The UEFI Distribution Packaging Specification defines a 
format to share package and module content in a standard
format and uses an XML schema for the metadata.  We need to
be able to convert between INF <--> XML and DEC <--> XML.

http://www.uefi.org/sites/default/files/resources/Dist_Package_Spec_1_1.pdf

If we define extensions to INF or DEC files, we need to
make sure these transforms are still supported.  If an
extension prevents these transforms, then we either need
to change the extension to be compatible or work on an
update to the UDP spec to support the extension in the XML.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Gao, Liming
> Sent: Thursday, January 10, 2019 7:48 AM
> To: Laszlo Ersek ;
> karunakarpoosapa...@dell.com; edk2-devel@lists.01.org
> Cc: sumanth.vidyadh...@dell.com; Gao, Liming
> ; sriramkumar.r...@dell.com
> Subject: Re: [edk2] Conditional Compilation support in
> INF file
> 
> I have same question. What flexibility is expected in
> INF? I see one request in [Depex] section. So, PCD
> support in [Depex] is added.
> 
> Edk2 INF is used to describe the source code behavior.
> If the source uses Ppi/Protocol/Guid/Pcd, these
> information are always required to be described in INF
> file. The compiler can optimize the code and remove the
> unused Ppi/Protocol/Guid/Pcd. It doesn't need developer
> specify the conditional statement.
> 
> Thanks
> Liming
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Thursday, January 10, 2019 8:54 PM
> > To: karunakarpoosapa...@dell.com; Gao, Liming
> ; edk2-devel@lists.01.org
> > Cc: sumanth.vidyadh...@dell.com;
> sriramkumar.r...@dell.com
> > Subject: Re: [edk2] Conditional Compilation support in
> INF file
> >
> > On 01/10/19 07:03, karunakarpoosapa...@dell.com wrote:
> > > Hi All,
> > >
> > > I agree with providing the support like
> "FixedAtBuild PCD in INF". And we need to modify or
> provide support in BaseTools to support
> > this feature.
> > >
> > > There are more use cases or flexibility to developer
> if we support Conditional compilation support in INF.
> > > As we're providing support in BaseTools for
> FixedAtBuild PCD support in INF, Is there any challenges
> or drawbacks in  providing
> > conditional compilation support in INF?
> >
> > This is not for me to say authoritatively, but I'm
> unaware of any
> > specific use case that cannot be solved without this
> feature addition,
> > and any further complexity to BaseTools should be
> strongly justified.
> > "More convenient" is too vague for me, and the
> BaseTools code is already
> > hard to read and debug.
> >
> > That's just my opinion, again.
> >
> > Thanks
> > Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 0/2] Provide UEFILib functions for protocol uninstallation

2019-01-09 Thread Kinney, Michael D

Hi Ashish,

This V4 version of the patch produces the expected size 
results for platform and driver builds.

There are some very minor issues with some extra carriage
returns, but those can be handled by Liming when the patch
series is committed.

I may be good to have an additional BZ to use these new
APIs from all UEFI Driver Model drivers that have failure
paths in their entry point or support the unload feature.
Those updates can be done later.

Thanks,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Wednesday, January 9, 2019 12:59 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao,
> Liming ; Fu, Siyuan
> ; Wu, Jiaxin ;
> Ashish Singhal 
> Subject: [PATCH v4 0/2] Provide UEFILib functions for
> protocol uninstallation
> 
> An issue was seen in IScsiDxe in NetworkPkg where driver
> cleanup after
> initialization failure was not done right. Bug 1428 was
> filed in this regard.
> As per discussions with Mike, it was also discussed that
> having UEFILib
> provide protocol uninstallation abstraction would help
> to avoid these
> issues in the future. Bug 1429 was found to track this.
> These 2 patches
> take care of this.
> 
> 
> Ashish Singhal (2):
>   MdePkg/UefiLib: Abstract driver model protocol
> uninstallation
>   NetworkPkg/IScsiDxe: Use UEFILib APIs to uninstall
> protocols.
> 
>  MdePkg/Include/Library/UefiLib.h | 103 
>  MdePkg/Library/UefiLib/UefiDriverModel.c | 972
> ++-
>  NetworkPkg/IScsiDxe/IScsiDriver.c|  31 +-
>  3 files changed, 1085 insertions(+), 21 deletions(-)
> 
> --
> 2.7.4

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

Re: [edk2] [PATCH v3 0/2] Provide UEFILib functions for protocol uninstallation.

2019-01-08 Thread Kinney, Michael D

Ashish,

When I do full platform builds and individual driver
builds, the result is always a little bigger with the
V3 version of the patch.

 DEBUG  DEBUG+Patch  Delta  RELEASE 
RELEASE+Patch  Delta
 *  ***  *  *** 
*  *
Quark IA32 FVMAIN2337360  2339408   2048  1181168
1182992   1824
Quark IA32 FVMAIN_COMPACT 814664   815272608   516208 
516904696
DiskIoDxe.efi  1875218880128 5824   
5952128
DiskIoDxe.ROM  1024010240  0 3419   
3569150
OVMF X64 DXEFV   4447368  4456968   9600  2956808
2966312   9504
OVMF X64 FVMAIN_COMPACT  1164264  1164784520   912528 
913048520

I recommend the install APIs remain unchanged, and the
uninstall APIs use the same logic as the install APIs.

Best regards,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Tuesday, January 8, 2019 9:24 AM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org; Gao, Liming
> ; Fu, Siyuan
> ; Wu, Jiaxin 
> Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol uninstallation.
> 
> Thanks Mike. Please let me know if you have any more
> questions and/or comments.
> 
> Thanks
> Ashish
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, January 8, 2019 9:26 AM
> To: Ashish Singhal ; edk2-
> de...@lists.01.org; Gao, Liming ;
> Fu, Siyuan ; Wu, Jiaxin
> ; Kinney, Michael D
> 
> Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol uninstallation.
> 
> Ashish,
> 
> Good point.  I was looking at the code size of a single
> uncompressed UEFI Driver (DiskIoDxe).  I suspect that
> the patch provides a more consistent pattern across all
> drivers that use these UefiLib APIs, and then provides
> better compression on an FV that contains many UEFI
> Drivers.
> 
> I also suspect there may be a small size increase for
> the single compressed UEFI Driver use case for PCI
> Option ROMs.
> 
> I will run a few more experiments this morning.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Monday, January 7, 2019 2:51 PM
> > To: Kinney, Michael D ;
> > edk2-devel@lists.01.org; Gao, Liming
> ; Fu,
> > Siyuan ; Wu, Jiaxin
> 
> > Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol
> > uninstallation.
> >
> > Hi Mike,
> >
> > I build both DEBUG and RELEASE variant of the library
> and they both
> > built a few KB less in size compared to what is in
> tip right now. Can
> > you please help me with the optimization settings you
> have enabled so
> > that I can try the same at my end? Also, if you want,
> we can look at
> > the optimization part going forward and fix the issue
> first by pushing
> > in PATCH v2 1/4 and PATCH v2 2/4 which just adds
> uninstallation APIs
> > keeping the same code structure as for install.
> >
> > Thanks
> > Ashish
> >
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Monday, January 7, 2019 3:23 PM
> > To: Ashish Singhal ; edk2-
> > de...@lists.01.org; Gao, Liming
> ; Fu, Siyuan
> > ; Wu, Jiaxin
> ; Kinney,
> > Michael D 
> > Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol
> > uninstallation.
> >
> > Hi Ashish,
> >
> > My main concern with this patch is that the generated
> code for
> > optimized RELEASE builds is not as small.
> >
> > From a source maintenance perspective, the patch you
> have provided is
> > easier to maintain.  However, the implementation of
> the APIs that
> > install protocols was done to make sure the optimizer
> produces the
> > smallest number of instructions to install the
> protocols.
> >
> > I would prefer the APIs that install protocols remain
> unchanged, and
> > that only the new APIs to uninstall the protocols be
> added.  The same
> > approach could be taken in the implementation to
> produce the exact
> > right form of the uninstall action that is guaranteed
> to succeed if
> > the uninstall API matches the API that was used to
> install.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Ashish Singhal
> [mailto:ashishsin...@nvidia.com]
> > > Sent: Monday, January 7, 2019 6:02 AM
> > > To: edk2-devel@lists.01.org;

Re: [edk2] [PATCH v3 0/2] Provide UEFILib functions for protocol uninstallation.

2019-01-08 Thread Kinney, Michael D

Ashish,

Good point.  I was looking at the code size of a single
uncompressed UEFI Driver (DiskIoDxe).  I suspect that the
patch provides a more consistent pattern across all drivers
that use these UefiLib APIs, and then provides better
compression on an FV that contains many UEFI Drivers.

I also suspect there may be a small size increase for the
single compressed UEFI Driver use case for PCI Option ROMs.

I will run a few more experiments this morning.

Thanks,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Monday, January 7, 2019 2:51 PM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org; Gao, Liming
> ; Fu, Siyuan
> ; Wu, Jiaxin 
> Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol uninstallation.
> 
> Hi Mike,
> 
> I build both DEBUG and RELEASE variant of the library
> and they both built a few KB less in size compared to
> what is in tip right now. Can you please help me with
> the optimization settings you have enabled so that I
> can try the same at my end? Also, if you want, we can
> look at the optimization part going forward and fix the
> issue first by pushing in PATCH v2 1/4 and PATCH v2 2/4
> which just adds uninstallation APIs keeping the same
> code structure as for install.
> 
> Thanks
> Ashish
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Monday, January 7, 2019 3:23 PM
> To: Ashish Singhal ; edk2-
> de...@lists.01.org; Gao, Liming ;
> Fu, Siyuan ; Wu, Jiaxin
> ; Kinney, Michael D
> 
> Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol uninstallation.
> 
> Hi Ashish,
> 
> My main concern with this patch is that the generated
> code for optimized RELEASE builds is not as small.
> 
> From a source maintenance perspective, the patch you
> have provided is easier to maintain.  However, the
> implementation of the APIs that install protocols was
> done to make sure the optimizer produces the smallest
> number of instructions to install the protocols.
> 
> I would prefer the APIs that install protocols remain
> unchanged, and that only the new APIs to uninstall the
> protocols be added.  The same approach could be taken
> in the implementation to produce the exact right form
> of the uninstall action that is guaranteed to succeed
> if the uninstall API matches the API that was used to
> install.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Monday, January 7, 2019 6:02 AM
> > To: edk2-devel@lists.01.org; Kinney, Michael D
> > ; Gao, Liming
> ; Fu,
> > Siyuan ; Wu, Jiaxin
> 
> > Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol
> > uninstallation.
> >
> > + Maintainers
> >
> > -Original Message-
> > From: Ashish Singhal 
> > Sent: Sunday, January 6, 2019 9:38 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ashish Singhal 
> > Subject: [PATCH v3 0/2] Provide UEFILib functions for
> protocol
> > uninstallation.
> >
> > An issue was seen in IScsiDxe in NetworkPkg where
> driver cleanup after
> > initialization failure was not done right. Bug 1428
> was filed in this
> > regard.
> > As per discussions with Mike, it was also discussed
> that having
> > UEFILib provide protocol uninstallation abstraction
> would help to
> > avoid these issues in the future. Bug 1429 was found
> to track this.
> > The first 2 patches take care of this.
> >
> > Patch number 1 also simplifies the UEFILib protocol
> installation and
> > uninstallation abstraction by adding a helper
> function doing
> > operations instead of every public function.
> >
> > Ashish Singhal (2):
> >   MdePkg/UefiLib: Abstract driver model protocol
> uninstallation
> >   NetworkPkg/IScsiDxe: Use UEFILib APIs to uninstall
> protocols.
> >
> >  MdePkg/Include/Library/UefiLib.h |  103 +++
> >  MdePkg/Library/UefiLib/UefiDriverModel.c | 1186
> > --
> >  NetworkPkg/IScsiDxe/IScsiDriver.c|   31 +-
> >  3 files changed, 435 insertions(+), 885 deletions(-)
> >
> > --
> > 2.7.4
> >
> > -
> --
> > 
> > This email message is for the sole use of the
> intended
> > recipient(s) and may contain
> > confidential information.  Any unauthorized review,
> use, disclosure or
> > distribution is prohibited.  If you are not the
> intended recipient,
> > please contact the sender by reply email and destroy
> all copies of the
> > original message.
> > -
> --
> > 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/2] Provide UEFILib functions for protocol uninstallation.

2019-01-07 Thread Kinney, Michael D

Hi Ashish,

My main concern with this patch is that the 
generated code for optimized RELEASE builds is
not as small.

>From a source maintenance perspective, the patch
you have provided is easier to maintain.  However,
the implementation of the APIs that install protocols
was done to make sure the optimizer produces the 
smallest number of instructions to install the 
protocols.

I would prefer the APIs that install protocols
remain unchanged, and that only the new APIs to
uninstall the protocols be added.  The same
approach could be taken in the implementation
to produce the exact right form of the uninstall
action that is guaranteed to succeed if the uninstall
API matches the API that was used to install.

Thanks,

Mike

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Monday, January 7, 2019 6:02 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D
> ; Gao, Liming
> ; Fu, Siyuan
> ; Wu, Jiaxin 
> Subject: RE: [PATCH v3 0/2] Provide UEFILib functions
> for protocol uninstallation.
> 
> + Maintainers
> 
> -Original Message-
> From: Ashish Singhal 
> Sent: Sunday, January 6, 2019 9:38 PM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal 
> Subject: [PATCH v3 0/2] Provide UEFILib functions for
> protocol uninstallation.
> 
> An issue was seen in IScsiDxe in NetworkPkg where
> driver cleanup after initialization failure was not
> done right. Bug 1428 was filed in this regard.
> As per discussions with Mike, it was also discussed
> that having UEFILib provide protocol uninstallation
> abstraction would help to avoid these issues in the
> future. Bug 1429 was found to track this. The first 2
> patches take care of this.
> 
> Patch number 1 also simplifies the UEFILib protocol
> installation and uninstallation abstraction by adding a
> helper function doing operations instead of every
> public function.
> 
> Ashish Singhal (2):
>   MdePkg/UefiLib: Abstract driver model protocol
> uninstallation
>   NetworkPkg/IScsiDxe: Use UEFILib APIs to uninstall
> protocols.
> 
>  MdePkg/Include/Library/UefiLib.h |  103 +++
>  MdePkg/Library/UefiLib/UefiDriverModel.c | 1186
> --
>  NetworkPkg/IScsiDxe/IScsiDriver.c|   31 +-
>  3 files changed, 435 insertions(+), 885 deletions(-)
> 
> --
> 2.7.4
> 
> ---
> 
> This email message is for the sole use of the intended
> recipient(s) and may contain
> confidential information.  Any unauthorized review,
> use, disclosure or distribution
> is prohibited.  If you are not the intended recipient,
> please contact the sender by
> reply email and destroy all copies of the original
> message.
> ---
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Uninstalling Invalid Protocol Interfaces

2019-01-04 Thread Kinney, Michael D

Ashish,

Thanks for the pointer.  I agree there is an issue here.

Please enter a Bugzilla against the IScsiDxe module for this issue so we can 
fix this failure.

You are also welcome to enter a Bugzilla for a feature request to add UefiLib 
APIs that can be used to safely uninstall all the driver model related protocol 
that can be used in error paths in the entry point and in unload handlers.

Thanks,

Mike

From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
Sent: Thursday, January 3, 2019 4:16 PM
To: Kinney, Michael D ; edk2-devel@lists.01.org
Cc: Gao, Liming ; Fu, Siyuan ; Wu, 
Jiaxin 
Subject: RE: Uninstalling Invalid Protocol Interfaces

Hi Mike,

Call to UninstallMultipleProtocolInterfaces at 
https://github.com/tianocore/edk2/blob/master/NetworkPkg/IScsiDxe/IScsiDriver.c#L1864
 fails because the component name interface may not be installed depending on 
the state of PCD.

Thanks
Ashish

From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Thursday, January 3, 2019 5:09 PM
To: Ashish Singhal mailto:ashishsin...@nvidia.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Gao, Liming mailto:liming@intel.com>>; Fu, Siyuan 
mailto:siyuan...@intel.com>>; Wu, Jiaxin 
mailto:jiaxin...@intel.com>>
Subject: RE: Uninstalling Invalid Protocol Interfaces

Hi Ashish,

Can you provide a pointer to the UninstallMultipleProtocolInterfaces() call 
that is causing this failure?

I agree that the UefiLib could provide additional services to simplify the 
implementation of the unload handlers.  Matching the UefiLib APIs that install 
the Uefi Driver Model protocol would be useful, so the driver entry point and 
the driver unload functions can use matching APIs.

Mike

From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
Sent: Thursday, January 3, 2019 3:39 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>; Fu, Siyuan 
mailto:siyuan...@intel.com>>; Wu, Jiaxin 
mailto:jiaxin...@intel.com>>
Subject: Uninstalling Invalid Protocol Interfaces

Hello,

As part of moving from MdeModulePkg implementation of IScsiDxe to the 
implementation in NetworkPkg, I started hitting exception in the driver loaded 
after IScsiDxe if IScsiDxe's installation fails for some reason. Upon 
debugging, I found out that calls to UninstallMultipleProtocolInterfaces as 
part of Error 2 as well Error 1 fail while trying to uninstall component name 
protocol-interface pair and return error code EFI_INVALID_PARAMETER. As per 
UninstallMultipleProtocolInterfaces's documentation, if uninstallation of any 
of the input protocol-interface pair fails, it will reinstall any just 
uninstalled protocol and return EFI_INVALID_PARAMETER which causes the cleanup 
of this driver corrupt leading to failure in next driver getting loaded. The 
reason of failure in UninstallMultipleProtocolInterfaces is because the driver 
uses EfiLibInstallDriverBindingComponentName2 to install interfaces which may 
not install component name interfaces depending on the value of PCDs 
PcdComponentNameDi
 sable and PcdComponentName2Disable. I have the following proposals to get 
around this issue.


  1.  Instead of calling UninstallMultipleProtocolInterfaces once and list all 
protocol-interface pairs, do it sequentially for every pair so that the once 
which was installed correctly, gets uninstalled instead of getting reinstalled 
because of a failure uninstalling another pair. This would however make us not 
really use use UninstallMultipleProtocolInterfaces API to its full caliber.
  2.  In UEFILib, add a function EfiLibUninstallDriverBindingComponentName2 for 
uninstalling protocol interfaces taking into consideration the state of PCDs 
PcdComponentNameDisable and PcdComponentName2Disable.
  3.  In UEFILib, add uninstall functions for all corresponding install APIs to 
get coverage for all scenarios.

I would certainly prefer option 2 or 3 as they seem to be more correct and 
would provide a for all drivers which may hit the issue. I am happy to make the 
code changes as needed and suggested by the maintainers.

Thanks
Ashish

This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

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

Re: [edk2] Uninstalling Invalid Protocol Interfaces

2019-01-03 Thread Kinney, Michael D

Hi Ashish,

Can you provide a pointer to the UninstallMultipleProtocolInterfaces() call 
that is causing this failure?

I agree that the UefiLib could provide additional services to simplify the 
implementation of the unload handlers.  Matching the UefiLib APIs that install 
the Uefi Driver Model protocol would be useful, so the driver entry point and 
the driver unload functions can use matching APIs.

Mike

From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
Sent: Thursday, January 3, 2019 3:39 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 
; Fu, Siyuan ; Wu, Jiaxin 

Subject: Uninstalling Invalid Protocol Interfaces

Hello,

As part of moving from MdeModulePkg implementation of IScsiDxe to the 
implementation in NetworkPkg, I started hitting exception in the driver loaded 
after IScsiDxe if IScsiDxe's installation fails for some reason. Upon 
debugging, I found out that calls to UninstallMultipleProtocolInterfaces as 
part of Error 2 as well Error 1 fail while trying to uninstall component name 
protocol-interface pair and return error code EFI_INVALID_PARAMETER. As per 
UninstallMultipleProtocolInterfaces's documentation, if uninstallation of any 
of the input protocol-interface pair fails, it will reinstall any just 
uninstalled protocol and return EFI_INVALID_PARAMETER which causes the cleanup 
of this driver corrupt leading to failure in next driver getting loaded. The 
reason of failure in UninstallMultipleProtocolInterfaces is because the driver 
uses EfiLibInstallDriverBindingComponentName2 to install interfaces which may 
not install component name interfaces depending on the value of PCDs 
PcdComponentNameDi
 sable and PcdComponentName2Disable. I have the following proposals to get 
around this issue.


  1.  Instead of calling UninstallMultipleProtocolInterfaces once and list all 
protocol-interface pairs, do it sequentially for every pair so that the once 
which was installed correctly, gets uninstalled instead of getting reinstalled 
because of a failure uninstalling another pair. This would however make us not 
really use use UninstallMultipleProtocolInterfaces API to its full caliber.
  2.  In UEFILib, add a function EfiLibUninstallDriverBindingComponentName2 for 
uninstalling protocol interfaces taking into consideration the state of PCDs 
PcdComponentNameDisable and PcdComponentName2Disable.
  3.  In UEFILib, add uninstall functions for all corresponding install APIs to 
get coverage for all scenarios.

I would certainly prefer option 2 or 3 as they seem to be more correct and 
would provide a for all drivers which may hit the issue. I am happy to make the 
code changes as needed and suggested by the maintainers.

Thanks
Ashish

This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

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

Re: [edk2] SCT bugzilla topic?

2018-12-10 Thread Kinney, Michael D

Supreeth,

I have created the "EDK2 Test" product with the "UEFI-SCT" component.

Please review and let me know if there are any additional changes required.

Best regards,

Mike

> -Original Message-
> From: Supreeth Venkatesh
> [mailto:supreeth.venkat...@arm.com]
> Sent: Monday, December 10, 2018 8:40 AM
> To: Jin, Eric ; Leif Lindholm
> ; Kinney, Michael D
> 
> Cc: edk2-devel@lists.01.org; Dong Wei 
> Subject: RE: SCT bugzilla topic?
> 
> I guess we are in agreement that "EDK2-Test" product and
> "UEFI-SCT" component in Bugzilla  is required.
> 
> Mike,
> Can you please help create this and let us know?
> 
> Thanks,
> Supreeth
> 
> -Original Message-
> From: Jin, Eric 
> Sent: Monday, December 10, 2018 2:43 AM
> To: Leif Lindholm ; Kinney,
> Michael D 
> Cc: Supreeth Venkatesh ; edk2-
> de...@lists.01.org; Dong Wei 
> Subject: RE: SCT bugzilla topic?
> 
> Hi Leif,
> 
> We had better use "UEFI SCT" as the component.
> Other SCTs or test suites may be arranged in the EDK2-Test
> in future as the intention of EDK2-Test if my
> understanding is correct. Thanks.
> 
> Best Regards
> Eric
> 
> -Original Message-
> From: Leif Lindholm 
> Sent: Monday, December 10, 2018 4:14 PM
> To: Kinney, Michael D 
> Cc: Jin, Eric ; Supreeth Venkatesh
> ; edk2-devel@lists.01.org;
> Dong Wei 
> Subject: Re: SCT bugzilla topic?
> 
> Hi Mike,
> 
> I think we're agreed on an "EDK2 Test" product with an
> "SCT" component.
> (Although that should probably be "UEFI SCT" for clarity.)
> 
> Regards,
> 
> Leif
> 
> On Mon, Dec 10, 2018 at 03:02:57AM +, Kinney, Michael
> D wrote:
> > I can update BZ once there is a clear decision on what
> is required.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Jin, Eric
> > > Sent: Sunday, December 9, 2018 6:19 PM
> > > To: Supreeth Venkatesh ;
> Leif Lindholm
> > > ; edk2- de...@lists.01.org
> > > Cc: Kinney, Michael D ;
> Dong Wei
> > > ; Jin, Eric 
> > > Subject: RE: SCT bugzilla topic?
> > >
> > > Supreeth and Leif,
> > >
> > > UEFI-SCT is open source project now, the mantis is not
> proper
> > > option. We had better use the Bugzilla as edk2.
> > > Could the stewards help to create the Edk2 Test
> Product and SCT
> > > component if most members want to split test with
> edk2?
> > >
> > > Best Regards
> > > Eric
> > >
> > > -Original Message-
> > > From: Supreeth Venkatesh 
> > > Sent: Tuesday, December 4, 2018 3:37 AM
> > > To: Leif Lindholm ; edk2-
> > > de...@lists.01.org
> > > Cc: Jin, Eric ; Kinney, Michael D
> > > ; Dong Wei
> 
> > > Subject: RE: SCT bugzilla topic?
> > >
> > > Leif,
> > >
> > > Earlier, we used to use UTWG Mantis (for feature
> requests
> > > - https://mantis.uefi.org/mantis/view.php).
> > > After, UEFI-SCT became Open source, we did discuss to
> have the same
> > > infrastructure setup as edk2, which means using
> Bugzilla.
> > > However, I don't think we have created a SCT component
> or
> > > Edk2 Test Product yet.
> > >
> > > Your email reminds me one more task after the SCT
> component / Edk2
> > > Test product is created i.e., to migrate over
> remaining UTWG issues
> > > to Bugzilla.
> > >
> > > Once Eric chimes in/agrees, we will request Mike to
> create
> > > Edk2 Test Product within Bugzilla.
> > >
> > > Thanks,
> > > Supreeth
> > >
> > > -Original Message-
> > > From: Leif Lindholm 
> > > Sent: Monday, December 3, 2018 8:47 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Eric Jin ; Supreeth Venkatesh
> > > ; Michael D Kinney
> > > 
> > > Subject: SCT bugzilla topic?
> > >
> > > Hi Eric, Supreeth, Mike,
> > >
> > > I was looking to raise a feature request on UEFI SCT
> and didn't spot
> > > such a product. Should we create one?
> > >
> > > Or perhaps we should have an EDK2 Test product with an
> SCT
> > > component?
> > >
> > > Regards,
> > >
> > > Leif
> > > IMPORTANT NOTICE: The contents of this email and any
> attachments are
> > > confidential and may also be privileged.
> > > If you are not the intended recipient, please notify
> the sender
> > > immediately and do not disclose the contents to any
> other person,
> > > use it for any purpose, or store or copy the
> information in any
> > > medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any
> attachments are confidential and may also be privileged.
> If you are not the intended recipient, please notify the
> sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SCT bugzilla topic?

2018-12-09 Thread Kinney, Michael D

I can update BZ once there is a clear decision on what is required.

Mike

> -Original Message-
> From: Jin, Eric
> Sent: Sunday, December 9, 2018 6:19 PM
> To: Supreeth Venkatesh ; Leif
> Lindholm ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ; Dong
> Wei ; Jin, Eric 
> Subject: RE: SCT bugzilla topic?
> 
> Supreeth and Leif,
> 
> UEFI-SCT is open source project now, the mantis is not
> proper option. We had better use the Bugzilla as edk2.
> Could the stewards help to create the Edk2 Test Product
> and SCT component if most members want to split test with
> edk2?
> 
> Best Regards
> Eric
> 
> -Original Message-
> From: Supreeth Venkatesh 
> Sent: Tuesday, December 4, 2018 3:37 AM
> To: Leif Lindholm ; edk2-
> de...@lists.01.org
> Cc: Jin, Eric ; Kinney, Michael D
> ; Dong Wei 
> Subject: RE: SCT bugzilla topic?
> 
> Leif,
> 
> Earlier, we used to use UTWG Mantis (for feature requests
> - https://mantis.uefi.org/mantis/view.php).
> After, UEFI-SCT became Open source, we did discuss to have
> the same infrastructure setup as edk2, which means using
> Bugzilla.
> However, I don't think we have created a SCT component or
> Edk2 Test Product yet.
> 
> Your email reminds me one more task after the SCT
> component / Edk2 Test product is created i.e., to migrate
> over remaining UTWG issues to Bugzilla.
> 
> Once Eric chimes in/agrees, we will request Mike to create
> Edk2 Test Product within Bugzilla.
> 
> Thanks,
> Supreeth
> 
> -Original Message-
> From: Leif Lindholm 
> Sent: Monday, December 3, 2018 8:47 AM
> To: edk2-devel@lists.01.org
> Cc: Eric Jin ; Supreeth Venkatesh
> ; Michael D Kinney
> 
> Subject: SCT bugzilla topic?
> 
> Hi Eric, Supreeth, Mike,
> 
> I was looking to raise a feature request on UEFI SCT and
> didn't spot such a product. Should we create one?
> 
> Or perhaps we should have an EDK2 Test product with an SCT
> component?
> 
> Regards,
> 
> Leif
> IMPORTANT NOTICE: The contents of this email and any
> attachments are confidential and may also be privileged.
> If you are not the intended recipient, please notify the
> sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Change EDK II to an Apache 2.0 License

2018-12-07 Thread Kinney, Michael D

Matteo,

Since EDK II does use some content from a few other projects, we do
need content under other supported licenses to be allowed.  However,
we have discussed these dependencies and would prefer they are included
as git-submodules so the sources are not in the EDK II repositories.
There will be work items to go through each of those dependencies.

We would prefer all content in the EDK II repos going forward to 
use Apache 2.0 as both the inbound and outbound license without any
need for an EDK II developer to attest to the TianoCore Contribution
Agreement.  We will have to define an exception process for content
that can not follow this preference.

Thanks,

Mike

> -Original Message-
> From: Matteo Carlini [mailto:matteo.carl...@arm.com]
> Sent: Friday, December 7, 2018 12:07 PM
> To: Leif Lindholm ; Kinney,
> Michael D 
> Cc: edk2-devel@lists.01.org; Sami Mujawar
> ; Guillaume Letellier
> ; nd 
> Subject: RE: [edk2] [RFC] Change EDK II to an Apache 2.0
> License
> 
> Ok from Arm side, as long as contributions submitted under
> the existing TianoCore Contribution Agreement 1.1 (BSD 2-
> Clause) will still be accepted, as it's somehow implied by
> point 3).
> 
> Thanks
> Matteo
> 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: 29 November 2018 22:54
> > To: Kinney, Michael D 
> > Cc: edk2-devel@lists.01.org; Matteo Carlini
> ; Sami
> > Mujawar 
> > Subject: Re: [edk2] [RFC] Change EDK II to an Apache 2.0
> License
> >
> > On Thu, Nov 29, 2018 at 06:39:28PM +, Kinney,
> Michael D wrote:
> > > Hello,
> > >
> > > This RFC follows up on the proposal from Mark Doran to
> change the EDK
> > > II Project to an Apache 2.0 License.
> > >
> > > https://lists.01.org/pipermail/edk2-devel/2018-
> October/030385.html
> > >
> > >
> > >   ** Please provide feedback on the proposal by Friday
> 12/7/18. **
> >
> > 7 December 2018 to anyone outside the US :)
> >
> > > I will be following up with pointers to public GitHub
> branches that
> > > contain the initial set of changes in steps (1) and
> (2) below for
> > > review.
> > >
> > > The proposal is to perform this change to edk2/master
> in the steps
> > > listed below. The license change will not be applied
> to any of the
> > > other existing branches in the edk2 repository.
> > >
> > > 1) Change all files with a BSD 2-Clause license and
> only a single
> > >copyright statement by Intel Corporation to an
> Apache 2.0 license
> > >and add an SPDX-License-Identifier statement.
> > >
> > >
> >
> ==
> ==
> > ==
> > >SPDX-License-Identifier: Apache-2.0
> > >
> > >Licensed under the Apache License, Version 2.0 (the
> "License");
> > >you may not use this file except in compliance with
> the License.
> > >You may obtain a copy of the License at
> > >
> > >http://www.apache.org/licenses/LICENSE-2.0
> > >
> > >Unless required by applicable law or agreed to in
> writing, software
> > >distributed under the License is distributed on an
> "AS IS" BASIS,
> > >WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
> either express or
> > implied.
> > >See the License for the specific language governing
> permissions and
> > >limitations under the License.
> > >
> > >
> >
> ==
> ==
> > ==
> > >
> > > 2) Update Readme.md and License.txt in the root of the
> edk2 repository to
> > >state that content is covered by a mix of BSD 2-
> Clause and Apache 2.0
> > >licenses.
> > >
> > > 3) Update all documentation to state that content
> submitted under the
> > >Apache 2.0 license no longer requires the Tianocore
> Contribution
> > >Agreement which means the following line is not
> required in commit
> > >messages for changes to files that are covered by
> an Apache 2.0 License.
> >
> > Presumably this also applies to files _added_ with an
> Apache 2.0 License? (If so,
> > the above could benefit from minor rewording.)
> >
> > >Contributed-under: TianoCore Contribution
> Agreement 1.1
> > >
> > > 4) Create Wiki page(s) that provide the details of the
> Apache 2.0 License
> > >change and p

Re: [edk2] [RFC] Proposal to add edk2-apps repository

2018-11-30 Thread Kinney, Michael D

One of the goals with this proposal is to minimize
the amount of source code that needs to be setup in
a WORKSPACE to build firmware for a given platform.
If a platform does not require any applications that
require the libc, then it would be better if the libc
related packages and applications that use libc do not
have to be present in WORKSPACE.

Likewise, there are platforms that do not require the
UEFI Shell or any other UEFI Applications in order to
build the platform firmware image.

Perhaps we need one repo for libc related content and
another repo for UEFI Application related content.

Best regards,

Mike


> -Original Message-
> From: Carsey, Jaben
> Sent: Friday, November 30, 2018 7:50 AM
> To: Ni, Ruiyu ; krishnaLee
> ; Kinney, Michael D
> 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [RFC] Proposal to add edk2-apps
> repository
> 
> I do not think that expanding shellPkg would work since
> there is no requirement that any of these apps depend
> on it.  As was stated, MicroPythonPkg does not.
> 
> I also do not think that moving ShellPkg makes lots of
> sense since it is used by many platforms.
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Ni,
> > Ruiyu
> > Sent: Thursday, November 29, 2018 7:40 PM
> > To: krishnaLee ; Kinney, Michael D
> > 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
> repository
> > Importance: High
> >
> > Krishna,
> > The reason there are applications inside
> MdeModulePkg/Application is that
> > the shell protocol was in ShellPkg when the app was
> developed and
> > MdeModulePkg cannot depend on ShellPkg (rule).
> > Now since shell protocol is moved to MdePkg, any apps
> can depend on shell
> > protocol. (In fact they wanted to but just wasn't
> allowed due to reason
> > above.)
> >
> > I even prefer to move the ShellPkg to the edk2-app
> repo Mike proposed.
> > Instead of enlarge the ShellPkg:)
> >
> > I don't prefer edk2-libc unless we have a
> strategy/plan to make ordinary C
> > developer easy by promoting the std-c pkg.
> > The other reason I prefer edk2-app is then ShellPkg
> might be moved to that
> > new repo.
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> > > krishnaLee
> > > Sent: Friday, November 30, 2018 9:45 AM
> > > To: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
> repository
> > >
> > > Kinney,
> > > I always think there may be two kinds of apps:
> > > 1,some apps have dependency on uefi_shell(shell-
> > lib,efi_shell_protocol,...they
> > > usually execute under uefi_shell),I would call them
> > "uefi_shell_application";
> > > 2,some apps have no dependency on uefi_shell(such
> as apps in
> > > MdeModulePkg/Application),I would call them
> > "standard_uefi_application".
> > >
> > > The "AppPkg / StdLib / StdLibPrivateInternalFiles"
> packages are usually
> > used by
> > > uefi_shell_application,I think they can all move to
> ShellPkg,no need to
> > create
> > > new package ?
> > >
> > >
> > > Thanks,
> > > krishna.
> > >
> > > At 2018-11-30 08:46:58, "Kinney, Michael D"
> 
> > > wrote:
> > > >Leif,
> > > >
> > > >I did consider the edk2-libc name.  The port of
> Python 2.7 is in the
> > > >AppPkg as well and it uses libc.
> > > >
> > > >So the content of this new package is a
> combination of libc And apps
> > > >that use libc.
> > > >
> > > >I am definitely open to alternate names.  2
> options so far:
> > > >
> > > >* edk2-apps
> > > >* edk2-libc
> > > >
> > > >Thanks,
> > > >
> > > >Mike
> > > >
> > > >> -Original Message-
> > > >> From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > >> Sent: Thursday, November 29, 2018 2:41 PM
> > > >> To: Kinney, Michael D
> 
> > > >> Cc: edk2-devel@lists.01.org
> > > >> Subject: Re: [edk2] [RFC] Proposal to add edk2-
> apps repository
> > > >>
> > > >> On Thu, Nov 29, 2018 at 05:58:08PM +,
> Kinney, Michael D wrote:
> > > >> > Hello,
>

Re: [edk2] [RFC] Proposal to add edk2-apps repository

Ray,

Real HW platforms like Vlv2* and Quark* should be moved to
edk2-platforms.  Virtual platforms such as Ovmf and EmulatorPkg
should stay in edk2 repo to support validation.

We should enter Tianocore BZ to move the real HW platforms.

Thanks,

Mike

> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, November 29, 2018 7:32 PM
> To: edk2-devel@lists.01.org; Kinney, Michael D
> 
> Subject: RE: [RFC] Proposal to add edk2-apps repository
> 
> Mike,
> It's a great idea to have another edk2-apps repo.
> 
> I have a question not quite related to this new repo but
> related to edk2-platforms repo.
> There are many platforms in edk2 repo as well, like Ovmf,
> Emulator, Vlv2TbltDevicePkg.
> What's your opinion/plan about these platforms?
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> > Kinney, Michael D
> > Sent: Friday, November 30, 2018 1:58 AM
> > To: edk2-devel@lists.01.org; Kinney, Michael D
> 
> > Subject: [edk2] [RFC] Proposal to add edk2-apps
> repository
> >
> > Hello,
> >
> > I would like to propose the creation of a new repository
> called edk2-apps.  This
> > repository would initially be used to host the following
> packages from the edk2
> > repository:
> >
> > * AppPkg
> > * StdLib
> > * StdLibPrivateInternalFiles
> >
> > These 3 packages provide support for the libc along with
> applications that
> > depend on libc.  None of the other packages in the edk2
> repository use these
> > packages, so these 3 package can be safely moved without
> any impacts to
> > platform firmware builds.
> > Build configurations that do use libc features can clone
> the edk2-apps repository
> > and add it to PACKAGES_PATH.
> >
> > The history of these 3 packages would be preserved when
> importing the content
> > into edk2-apps.  After The import is verified, these 3
> packages would be deleted
> > from the edk2 repository.
> >
> > This proposal helps reduce the size of the edk2
> repository and focuses edk2
> > repository on packages used to provide UEFI/PI
> conformant firmware.
> >
> > If there are no concerns with this proposal, I will
> enter a Tianocore BZs for the
> > two steps.
> >
> > Best regards,
> >
> > Mike
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal to add edk2-apps repository

Leif,

I did consider the edk2-libc name.  The port of Python 2.7 
is in the AppPkg as well and it uses libc.

So the content of this new package is a combination of libc
And apps that use libc.

I am definitely open to alternate names.  2 options so far:

* edk2-apps
* edk2-libc

Thanks,

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, November 29, 2018 2:41 PM
> To: Kinney, Michael D 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
> repository
> 
> On Thu, Nov 29, 2018 at 05:58:08PM +, Kinney, Michael
> D wrote:
> > Hello,
> >
> > I would like to propose the creation of a new
> > repository called edk2-apps.  This repository
> > would initially be used to host the following
> > packages from the edk2 repository:
> >
> > * AppPkg
> > * StdLib
> > * StdLibPrivateInternalFiles
> 
> Let me start by saying I 100% back moving these out of the
> main edk2
> repository.
> 
> > These 3 packages provide support for the libc along
> > with applications that depend on libc.  None of the
> > other packages in the edk2 repository use these
> > packages, so these 3 package can be safely moved
> > without any impacts to platform firmware builds.
> > Build configurations that do use libc features can
> > clone the edk2-apps repository and add it to
> > PACKAGES_PATH.
> 
> I must confess to never having properly understood the
> scope of AppPkg
> to begin with.
> 
> AppPkg/Applications/Hello does not appear to have any
> further (real)
> dependency on libc than
> MdeModulePkg/Application/HelloWorld/, and .
> 
> And certainly MdeModulePkg/Applications contain plenty of
> ... applications.
> 
> So, if the purpose is simply to provide some examples of
> application
> written to libc rather than UEFI - should this be edk2-
> libc instead?
> 
> Best Regards,
> 
> Leif
> 
> > The history of these 3 packages would be preserved
> > when importing the content into edk2-apps.  After
> > The import is verified, these 3 packages would be
> > deleted from the edk2 repository.
> >
> > This proposal helps reduce the size of the edk2
> > repository and focuses edk2 repository on packages
> > used to provide UEFI/PI conformant firmware.
> >
> > If there are no concerns with this proposal, I will
> > enter a Tianocore BZs for the two steps.
> >
> > Best regards,
> >
> > Mike
> > ___
> > 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] [RFC] Change EDK II to an Apache 2.0 License

Hello,

This RFC follows up on the proposal from Mark Doran to change the 
EDK II Project to an Apache 2.0 License.

https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html


  ** Please provide feedback on the proposal by Friday 12/7/18. **

I will be following up with pointers to public GitHub branches that
contain the initial set of changes in steps (1) and (2) below for 
review. 

The proposal is to perform this change to edk2/master in the steps listed
below. The license change will not be applied to any of the other existing
branches in the edk2 repository.

1) Change all files with a BSD 2-Clause license and only a single 
   copyright statement by Intel Corporation to an Apache 2.0 license
   and add an SPDX-License-Identifier statement.

   ==
   SPDX-License-Identifier: Apache-2.0

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
   ==

2) Update Readme.md and License.txt in the root of the edk2 repository to
   state that content is covered by a mix of BSD 2-Clause and Apache 2.0
   licenses. 

3) Update all documentation to state that content submitted under the 
   Apache 2.0 license no longer requires the Tianocore Contribution
   Agreement which means the following line is not required in commit
   messages for changes to files that are covered by an Apache 2.0 License.

   Contributed-under: TianoCore Contribution Agreement 1.1

4) Create Wiki page(s) that provide the details of the Apache 2.0 License
   change and provide the status of the license change for each package
   in the edk2 repository.  Also provide a list of the additional copyright
   holders that need to be contacted to accept the change to an Apache 2.0
   License along with the status of that acceptance.

5) After all copyright holders have accepted the change to an Apache 2.0
   License, change the remaining files from BSD 2-Clause to Apache 2.0.

6) Update Readme.md and License.txt in the edk2 repository to state that
   Apache 2.0 is the preferred license for the EDK II project.

Best regards,

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

[edk2] [RFC] Proposal to add edk2-apps repository

Hello,

I would like to propose the creation of a new
repository called edk2-apps.  This repository
would initially be used to host the following
packages from the edk2 repository:

* AppPkg
* StdLib
* StdLibPrivateInternalFiles

These 3 packages provide support for the libc along
with applications that depend on libc.  None of the
other packages in the edk2 repository use these
packages, so these 3 package can be safely moved
without any impacts to platform firmware builds.
Build configurations that do use libc features can
clone the edk2-apps repository and add it to
PACKAGES_PATH.

The history of these 3 packages would be preserved
when importing the content into edk2-apps.  After
The import is verified, these 3 packages would be
deleted from the edk2 repository.

This proposal helps reduce the size of the edk2
repository and focuses edk2 repository on packages
used to provide UEFI/PI conformant firmware.

If there are no concerns with this proposal, I will
enter a Tianocore BZs for the two steps.

Best regards,

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

Re: [edk2] FmpDeviceLib

2018-11-27 Thread Kinney, Michael D

Tom,

Thanks for noticing this issue.  I need a little 
time to evaluate this use case and see what changes
are required to make this work for a UEFI driver
that manages many controllers.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Tomas Pilar (tpilar)
> Sent: Tuesday, November 27, 2018 7:29 AM
> To: Gao, Liming ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] FmpDeviceLib
> 
> Okay, so I just noticed that FmpDxe is full of module
> globals including the image descriptor, so it
> necessarily requires that the driver that includes it as
> a library can only ever control one controller.
> 
> Cheers,
> Tom
> 
> On 27/11/2018 15:23, Tomas Pilar (tpilar) wrote:
> >
> > On 27/11/2018 14:33, Gao, Liming wrote:
> >> Tom:
> >>   FmpDeviceLib can use UEFI driver model/driver
> binding protocol so it can install FMP on its device
> handle during the BDS/Device connection phase. It can
> implement RegisterFmpInstaller() to install FMP protocol
> in its device handle. In this way, FmpDeviceLib is like
> UEFI driver with UEFI driver binding protocol.
> >>
> >> Thanks
> >> Liming
> > Hi Liming,
> >
> > Sure, so now I can install FMP onto my
> ControllerHandle. Say that someone gets the FMP and
> calls GetImageSize. The FmpDxeLib does some checks and
> then it calls FmpDeviceLibGetImageSize() with no context
> parameter. This method is supposed to be implemented by
> me, the driver writer, but how is the code in this
> method meant to know which Controller are we getting the
> image size from?
> >
> > So maybe I can define some module globals, declare
> them in a cross include file, include that in my driver
> and and have the driver populate the module globals
> during probe. This immediately limits the usefulness by
> requiring that each driver only ever drives one
> controller.
> >
> > And then you consider how to do a SetImage without
> being even given the Handle of the Controller. Do you
> stuff the controller handle into a module global
> parameter that gets populated during the BDS phase?
> >
> > I guess you could enumerate all FMP instances, see
> which one of them advertises your ImageTypeId and get
> the handle that the FMP is installed on that way. But
> that seems rather insane and would cause issues if you
> have two of the same device in the platform, unless you
> check the HardwareInstance as well? This seems insane.
> >
> > Cheers,
> > Tom
> >
> >>> -Original Message-
> >>> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Tomas Pilar (tpilar)
> >>> Sent: Tuesday, November 27, 2018 9:26 PM
> >>> To: edk2-devel@lists.01.org
> >>> Subject: [edk2] FmpDeviceLib
> >>>
> >>> Hi all,
> >>>
> >>> I am looking at using FmpDxeLib so I need to
> implement the FmpDeviceLib. However, it seems like the
> library functions do not take any
> >>> private struct as a parameter, so I am struggling to
> figure out how to read information off the hardware.
> FmpDxe does not even pass its
> >>> created protocol instance when calling the library
> functions, leading me to believe that the only way to do
> this is to assign a pointer to
> >>> private struct during library construction, but that
> means that a driver that uses the code can only ever
> service a single controller.
> >>>
> >>> Can you offer any insights?
> >>>
> >>> Cheers,
> >>> Tom
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] Vlv2TbltDevicePkg: Add build instructions for Minnowboard Max.

2018-11-23 Thread Kinney, Michael D

Hi David,

These are not the correct instructions that take
advantage of the PACKAGES_PATH feature. The
directories with the binaries should not be
copied into the edk2 repo area.

Instead, WORKSPACE is set to the directory above
edk2, and the binaries are placed in a directory
that is a peer to edk2.

Please see Readme.me in the QuarkPlatformPkg for
an example of how to set up multiple paths with
packages.

https://github.com/tianocore/edk2/tree/master/QuarkPlatformPkg

It uses edk2 repo and edk2-non-osi repo with a binary
in the edk2-non-osi repo.

Please try the equivalent configuration for Vlv2 and
update the instructions to match.

Thanks,

Mike

> -Original Message-
> From: Wei, David
> Sent: Thursday, November 22, 2018 10:00 PM
> To: edk2-devel@lists.01.org
> Cc: Sun, Zailiang ; Qian, Yi
> ; Kinney, Michael D
> ; Wei, David
> 
> Subject: [Patch] Vlv2TbltDevicePkg: Add build
> instructions for Minnowboard Max.
> 
> Add build instructions for Minnowboard Max platform on
> edk2 master. Change stitching script to follow this new
> build instructions.
> 
> Test: Boot to Windows 10.
> 
> Cc: Zailiang Sun 
> Cc: Yi Qian 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: David Wei 
> ---
>  Vlv2TbltDevicePkg/Documents/BuildInstructions.txt | 128
> ++
>  Vlv2TbltDevicePkg/Stitch/IFWIStitch.bat   |   2
> +-
>  2 files changed, 129 insertions(+), 1 deletion(-)
>  create mode 100644
> Vlv2TbltDevicePkg/Documents/BuildInstructions.txt
> 
> diff --git
> a/Vlv2TbltDevicePkg/Documents/BuildInstructions.txt
> b/Vlv2TbltDevicePkg/Documents/BuildInstructions.txt
> new file mode 100644
> index 00..a03c6ce3c4
> --- /dev/null
> +++ b/Vlv2TbltDevicePkg/Documents/BuildInstructions.txt
> @@ -0,0 +1,128 @@
> +## @file
> +# Build Instructions for Minnowboard Max platform on
> edk2 master.
> +#
> +# Copyright (c) 2018, 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.
> +#
> +#
> +##
> +
> +
> 
> +  HOW TO CREATE A FULL SOURCE
> TREE
> +
> 
> +1) Create a new folder (directory) on the root of your
> local hard drive (development
> +   machine) for use as your work space (this example
> uses "C:\MyWorkspace").
> +   Some paths are very long and placing the working
> directory too deep in the directory
> +   structure may cause the path to be longer than
> Windows maximum path length.
> +
> +2) Checkout edk2 from GitHub with the following command.
> +i)  Run "git clone
> https://github.com/tianocore/edk2.git";
> +* This step will created a new folder
> C:\MyWorkspace\edk2, which holds edk2 source code
> downloaded.
> +
> +5) Download MinnowBoard MAX Binary Object Modules from :
> (To be updated)
> +
> https://firmware.intel.com/sites/default/files/MinnowBoar
> d_MAX-0.97-Binary.Objects.zip
> +
> +   The MinnowBoard MAX Binary Object Modules contain
> three additional
> +   folders required for the full source tree.
> +
> +IA32FamilyCpuPkg
> +Vlv2BinaryPkg
> +Vlv2MiscBinariesPkg
> +
> +   Copy above 3 packages into "C:\MyWorkspace\edk2".
> +
> +
> +6) Follow the instructions found in the file "OpenSSL-
> HOWTO.txt" located in your
> +   workspace (e.g.
> "C:\MyWorkspace\edk2\CryptoPkg\Library\OpensslLib\OpenSSL
> -HOWTO.txt")
> +   to install the Openssl source code.
> +
> +
> 
> +  HOW TO BUILD (WINDOWS
> ENVIRONMENT)
> +
> 
> +Windows System Configuration:
> +  Microsoft Windows 10 Enterprise 64-bit*
> +
> +   Note: Below steps could also apply to Microsoft
> Windows 8.1 and other version of Windows 10,
> + but Intel only verify these steps on Microsoft
> Windows 10 Enterprise 64-bit*.
> +
> +1. Setup Build Environment
> +   1) Install C compiler Microsoft Visual Studio 2015
> with Update 3 in

Re: [edk2] [RFC] Proposal to remove DuetPkg

2018-11-20 Thread Kinney, Michael D

Ray,

One additional note.  There are some tools in
BaseTools that are only used by Duet.  We should
remove those tools too.

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, November 20, 2018 3:21 PM
> To: Leif Lindholm ; Ni, Ruiyu
> ; Kinney, Michael D
> 
> Cc: edk2-devel@lists.01.org; Gao, Liming
> ; Richardson, Brian
> ; Cetola, Stephano
> ; Laszlo Ersek
> 
> Subject: RE: [edk2] [RFC] Proposal to remove DuetPkg
> 
> I agree with this proposal.
> 
> I also agree with Leif that large patch series
> must be shared on a branch for review.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org]
> > On Behalf Of Leif Lindholm
> > Sent: Tuesday, November 20, 2018 1:57 AM
> > To: Ni, Ruiyu 
> > Cc: edk2-devel@lists.01.org; Gao, Liming
> > ; Richardson, Brian
> > ; Cetola, Stephano
> > ; Kinney, Michael D
> > ; Laszlo Ersek
> > 
> > Subject: Re: [edk2] [RFC] Proposal to remove DuetPkg
> >
> > On Tue, Nov 20, 2018 at 05:27:13AM +, Ni, Ruiyu
> > wrote:
> > > All,
> > > DuetPkg depends on Legacy BIOS to provide a UEFI
> > environment. It was
> > > invented in the era when UEFI environment is hard to
> > find. Since now
> > > UEFI is very popular in PC area, we could stop the
> > official support
> > > of this package and remove it from the master.
> > > Anyone who wants to use it still can just grab it
> from
> > git
> > > history. This is the same as what we did for IPF
> > contents.
> > >
> > > If there is no concern by end of November, we will
> send
> > out a formal
> > > patch to remove DuetPkg. (Since DuetPkg is big, we
> will
> > not generate
> > > the huge patch using git command, instead we will
> just
> > send out the
> > > patch mail with correct title/commit message but
> empty
> > content.)
> >
> > Works for me. If you could include a link to the patch
> in
> > a branch
> > where it can be reviewed, that would be ideal.
> >
> > /
> > Leif
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal to remove DuetPkg

2018-11-20 Thread Kinney, Michael D

I agree with this proposal.

I also agree with Leif that large patch series
must be shared on a branch for review.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Leif Lindholm
> Sent: Tuesday, November 20, 2018 1:57 AM
> To: Ni, Ruiyu 
> Cc: edk2-devel@lists.01.org; Gao, Liming
> ; Richardson, Brian
> ; Cetola, Stephano
> ; Kinney, Michael D
> ; Laszlo Ersek
> 
> Subject: Re: [edk2] [RFC] Proposal to remove DuetPkg
> 
> On Tue, Nov 20, 2018 at 05:27:13AM +, Ni, Ruiyu
> wrote:
> > All,
> > DuetPkg depends on Legacy BIOS to provide a UEFI
> environment. It was
> > invented in the era when UEFI environment is hard to
> find. Since now
> > UEFI is very popular in PC area, we could stop the
> official support
> > of this package and remove it from the master.
> > Anyone who wants to use it still can just grab it from
> git
> > history. This is the same as what we did for IPF
> contents.
> >
> > If there is no concern by end of November, we will send
> out a formal
> > patch to remove DuetPkg. (Since DuetPkg is big, we will
> not generate
> > the huge patch using git command, instead we will just
> send out the
> > patch mail with correct title/commit message but empty
> content.)
> 
> Works for me. If you could include a link to the patch in
> a branch
> where it can be reviewed, that would be ideal.
> 
> /
> Leif
> 
> ___
> 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 6/8] IntelFrameworkPkg: Remove the redundant INFs

2018-11-19 Thread Kinney, Michael D

Liming,

We need to look at how to remove those dependencies
now so the entire package can be retired.  For example
the only consumer of 8259 is the 8254 driver.  The 8254
module can be replaced with the HPET driver that does not
use 8259 at all.

If we can convert all platforms that are currently using
8254 to use HPET instead, we can make a big step towards
removing the entire package.

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Sunday, November 18, 2018 9:16 PM
> To: Kinney, Michael D ;
> Zhang, Shenglei ; Ni, Ruiyu
> ; edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg: Remove
> the redundant INFs
> 
> Mike:
>   The long term goal is to remove IntelFrameworkPkg. I
> propose to remove its contents step by step. Now, some
> unused modules or header files are very clear. They can
> be removed now. But, others (such as Legacy definitions)
> are still consumed by LegacyBios and 8259/8254 drivers.
> We have no solution or clear plan to drop legacy support.
> They may still be kept for a while.
> 
> Thanks
> Liming
> >-Original Message-
> >From: Kinney, Michael D
> >Sent: Wednesday, November 14, 2018 1:18 PM
> >To: Zhang, Shenglei ; Ni,
> Ruiyu
> >; edk2-devel@lists.01.org; Kinney,
> Michael D
> >
> >Cc: Gao, Liming 
> >Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg:
> Remove the redundant
> >INFs
> >
> >Shenglei,
> >
> >I would prefer we work towards the goal of removing
> >the use of the Intel Framework Packages by all platforms
> >so the entire packages can be removed from edk2/master.
> >
> >This would be better than trying to remove a few items
> >at a time.
> >
> >Thanks,
> >
> >Mike
> >
> >> -Original Message-
> >> From: Zhang, Shenglei
> >> Sent: Tuesday, November 13, 2018 7:32 PM
> >> To: Ni, Ruiyu ; edk2-
> >> de...@lists.01.org
> >> Cc: Kinney, Michael D ;
> >> Gao, Liming 
> >> Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg:
> >> Remove the redundant INFs
> >>
> >> Ray
> >> Thanks for your constructive comments. I'll improve it
> >> in next version.
> >>
> >> Thanks,
> >> Shenglei
> >> > -Original Message-
> >> > From: Ni, Ruiyu
> >> > Sent: Wednesday, November 14, 2018 11:12 AM
> >> > To: Zhang, Shenglei ;
> edk2-
> >> de...@lists.01.org
> >> > Cc: Kinney, Michael D ;
> >> Gao, Liming
> >> > 
> >> > Subject: Re: [edk2] [PATCH 6/8] IntelFrameworkPkg:
> >> Remove the redundant
> >> > INFs
> >> >
> >> > On 11/13/2018 4:35 PM, Shenglei Zhang wrote:
> >> > > All INFs of unused Library instances in
> >> IntelFrameworkPkg
> >> > > are removed as they are not actually used.
> >> > >
> https://bugzilla.tianocore.org/show_bug.cgi?id=1190
> >> > >
> >> > > Cc: Liming Gao 
> >> > > Cc: Michael D Kinney 
> >> > > Contributed-under: TianoCore Contribution
> Agreement
> >> 1.1
> >> > > Signed-off-by: Shenglei Zhang
> >> 
> >> > > ---
> >> > >   IntelFrameworkPkg/IntelFrameworkPkg.dsc | 7 
> -
> >> --
> >> > >   1 file changed, 7 deletions(-)
> >> > >
> >> > > diff --git
> >> a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> >> > b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> >> > > index bd5df8c5d9..802a80e3eb 100644
> >> > > --- a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> >> > > +++ b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> >> > > @@ -63,13 +63,6 @@
> >> > >   #   generated for it, but the binary will
> not
> >> be put into any firmware
> >> > volume.
> >> > >   #
> >> > >
> >> >
> >>
> ###
> >> ###
> >> > #
> >> > > -[Components]
> >> > > -
> >>
> IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.i
> >> nf
> >> > > -
> >>
> IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUef
> >> iLib.inf
> >> > > -
> >> >
> >>
> IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmm
> >> DriverEntryP
> >> > oint.inf
> >> > > -
> >> >
> >>
> IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusL
> >> ibSmbusPpi.in
> >> > f
> >> > > -
> >> >
> >>
> IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLibF
> >> ramework.inf
> >> > > -
> >> > >   [BuildOptions]
> >> > > *_*_*_CC_FLAGS = -D
> >> DISABLE_NEW_DEPRECATED_INTERFACES
> >> > >
> >> > >
> >> > Shenglei,
> >> > You cannot remove the INF in the separate patch like
> >> this.
> >> > You should either put this patch in the first patch
> >> in your serial,
> >> > or combine the DSC change with your library removal.
> >> > The goal is the the build won't fail when committing
> >> the patches one by one.
> >> >
> >> > --
> >> > Thanks,
> >> > Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce][RFC] Collaboration Software

2018-11-16 Thread Kinney, Michael D

Hi Stephano,

GitHub supports discussions for teams.

If we added a new team to the GitHub TianoCore
organization for all developers that want to be
involved in community topics and design discussions
(which should closely match the current members of
edk2-devel) then that may be a simple option that
uses services that already there.

Another option is to use discussions for one of the
exiting teams (e.g. Tianocore Maintainers) and make
posts for these discussion topics public.

https://blog.github.com/2017-11-20-introducing-team-discussions/

https://help.github.com/articles/about-team-discussions/

Best regards,

Mike




> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of stephano
> Sent: Friday, November 16, 2018 11:14 AM
> To: Zimmer, Vincent ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] [edk2-announce][RFC] Collaboration
> Software
> 
> The only reason I didn't include Slack is that it will
> only log so much
> information before things start falling off into the
> ether.
> 
> Does anyone in the community currently use Slack and know
> of an easy way
> of archiving conversations publicly?
> 
> 
> On 11/16/2018 9:56 AM, Zimmer, Vincent wrote:
> > https://slack.com/
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Kevin D Davis
> > Sent: Friday, November 16, 2018 9:35 AM
> > To: stephano ; edk2-
> de...@lists.01.org
> > Subject: Re: [edk2] [edk2-announce][RFC] Collaboration
> Software
> >
> >
> >
> >
> >
> >
> > If we get to vote, I’d vote against Google
> Groups.  Their interface is very geared toward their
> internal work flow and seems to change on a whim.
> Thanks,Kevin
> >
> >
> >
> >
> >
> > On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano"
>  wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > We are looking to augment our current communication
> methods (mailing list / IRC) with a modern solution for
> group collaboration. The goal is to allow folks to
> communicate effectively without interrupting the current
> patch review system, as well as enabling any future
> systems with more robust options.
> >
> > Specific features we are looking for include
> attachments (currently blocked by the list), robust
> logging, modern chat, and integration with tools like bug
> trackers and source repositories (APIs, or better yet,
> pre-rolled plugins).
> >
> > Our current contenders are Google Groups and Groups.io.
> This RFC is in hopes of finding other options to
> evaluate.
> >
> > Cheers,
> > Stephano
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >
> >
> >
> >
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal on Python3 Migration

2018-11-16 Thread Kinney, Michael D

Liming,

Adding a new Python3 directory will increase the maintenance and testing of the 
python-based BaseTools.

It would be better if we could have one version of the python sources that work 
with both Python2 and Python3.

We should use the edk2-staging branch to work towards this goal.

Please explain why we can't support both in single set of sources.  Are there 
technical reasons or resource reasons?

Thanks,

Mike

From: Gao, Liming
Sent: Friday, November 16, 2018 7:02 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; leif.lindh...@linaro.org; 
Laszlo Ersek (ler...@redhat.com) ; af...@apple.com
Subject: [RFC] Proposal on Python3 Migration

Hi, all
  https://pythonclock.org/ say Python 2.7 will not be maintained past 2020. One 
BZ https://bugzilla.tianocore.org/show_bug.cgi?id=55 also requests this 
migration. And, Python37 does good performance optimization. In EDK2 build, 
Python37 can improve 20% performance than Python27 in Build AutoGen phase. So, 
we plan to add Python3 support in BaseTools. In previous discussion, the 
feedback is not to drop Python2 support in short term, and keep Python2 and 
Python3 coexist.

My proposal is to add two copy BaseTools Python code in BaseTools/Source 
directory. One is current BaseTools/Source/Python, another is new 
BaseTools/Source/Python3. edksetup.bat/edksetup.sh base on environment variable 
(PYTHON3_HOME) to know whether Python3 is used. If PYTHON3_HOME is not set, 
Python2 is still used as current way. If user wants to enable Python3, he needs 
to set PYTHON3_HOME. After 201811 release tag, BaseTools Python2 source code is 
kept as the stable release. Python3 is as the active trunk. By default, any 
change will be for Python3. If the submitter also request the change for 
Python2, he needs to list it in BZ description. If the submitter has the clear 
request, Python2 can add new feature or enhancement.

  If you have any comments or suggestion on Python3 migration, please join this 
discussion.

Thanks
Liming

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

Re: [edk2] [edk2-announce] EDK II Stable Tag edk2-stable201811 will be created based on commit 85588389222a3636baf0f9ed8227f2434af4c3f9

2018-11-14 Thread Kinney, Michael D

Liming,

Thanks.  This looks good to me.

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, November 14, 2018 7:39 AM
> To: Gao, Liming ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ;
> Cetola, Stephano ;
> leif.lindh...@linaro.org; af...@apple.com
> Subject: Re: [edk2] [edk2-announce] EDK II Stable Tag
> edk2-stable201811 will be created based on commit
> 85588389222a3636baf0f9ed8227f2434af4c3f9
> 
> On 11/14/18 15:20, Gao, Liming wrote:
> > Hi, all Today, I review all patches in edk2 mail list.
> There is no
> > patches for EDK II Stable Tag edk2-stable201811. Based
> on
> > edk2-stable201811 tag planning, it will be released at
> 2018-11-15.
> > So, I plan to create edk2-stable201811 based on current
> edk2 trunk
> > (the latest commit
> >
> https://github.com/tianocore/edk2/commit/85588389222a3636
> baf0f9ed8227f2434af4c3f9
> > UefiCpuPkg/CommonFeature: Always set
> FEATURE_CONTROL.Lock) on China
> > time (UTC + 8) 12:00PM of 2018-11-15. If you have any
> comments,
> > please reply the mail. If no concern or objection, I
> will create tag
> > and send another announce mail that edk2-stable201811
> is completed
> > and normal commit is resumed.
> 
> Sounds good to me, thank you.
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

2018-11-14 Thread Kinney, Michael D

Eugene,

Understood on the HW elements.  As long as you can provide 
evidence/documentation that the stack has been validated so we are all 
confident the stack can work on all conformant TPM devices, we should be good.  
We can also see if there are some publically available TPM devices that can be 
used to validate.

Quark did not have its own TPM.  The drivers added were for TPM devices 
connected to the I2C bus on the Arduino header.  So using platforms that have 
external I2C and SPI busses can potentially be used to validate new features 
like the ones you are proposing.

One note on the current process.  The process does require patch emails, but 
the patch emails can also point to a public GitHub branch to make it easy for 
others to review and test the changes without having to use the emails.  
Especially useful for larger patch sets.  I have use this method for a number 
of changes.  I do the same for document change in GitBook because GitHub 
provides a good way to view markdown document changes on a branch.

Thanks,

Mike

From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Wednesday, November 14, 2018 6:59 AM
To: Zhang, Chao B ; Kinney, Michael D 
; edk2-devel@lists.01.org; Yao, Jiewen 

Cc: Bin, Sung-Uk (빈성욱) 
Subject: RE: [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

Mike, Chao, Jiewen

Ø  [Chao] Infineon chip mentioned by Mike is an example but its register space 
doesn’t comply to PTP spec
Ø  [Mike] My experience is with DTPM and some I2C TPMs at 1.2 level.

We have experience with the TPM 1.2 Infineon I2C device and used a completely 
custom solution.  But I think that may be a 1.2 versus 2.0 difference.  I get 
the impression that TCG cleaned up their act a bit for the 2.0 spec – in fact 
we can see text to this effect in the PTP 1.03 
spec<https://trustedcomputinggroup.org/wp-content/uploads/TCG_PC_Client_Platform_TPM_Profile_PTP_2.0_r1.03_v22.pdf>
 Seciton 2.3:

The CRB Interface is intended to be physical-bus agnostic, so that it could
be implemented on an LPC or SPI interface, as specified in this specification 
or on
another physical interface not specified.

Reading a bit deeper in the PTP spec it looks like there are two register 
layouts but not driven by the physical bus (LPC, SPI, I2C) but rather the 
access method (FIFO or CRB access mode) – see section 5.3.2 called "Register 
Space Addresses" to see the FIFO and CRB register layouts juxtaposed.

Looking at I2C in the PTP spec I can now see the situation is totally different 
– I2C uses a variation of FIFO mode and has a significantly different layout of 
registers, comparing Table 10 to Table 48 in the PTP spec.  So now I see where 
you're coming from (and why we didn't initially understand the concern).


Given that HP's use case is SPI and SPI is aligned to LPC, we believe going 
forward with the TpmIoLib abstraction is still quite useful.  Whenever somebody 
needs to support I2C TPM2 devices then they will need to author another 
DeviceLib instance since the register layout is different.  (Will there ever be 
a Quark with an I2C TPM2?)

TPM experts, I'd appreciate if you could confirm that my analysis of 
LPC/I2C/SPI and CRB/FIFO is correct.


Ø  [Mike] I would recommend that a full implementation of TpmIoLib for a few 
non MMIO TPM devices be completed and pass validation before we consider adding 
new lib class to edk2.  Perhaps using an edk2-staging branch would be a better 
place to start and you can document in the Readme.md the criteria that must be 
met before the new lib class meets the requirements for edk2/master.

This plan is fine by me – our intent in the original Request for Comment emails 
was to understand if a TpmIoLib style abstraction would be acceptable to save 
us the work of going down a path that can't be upstreamed and having to fix it 
later.  I think the answer you are giving is "yes, as long as it really works". 
 We are developing and validating this support right now so as long as the TPM 
stack doesn't change out from under us on edk2/master while we are developing 
it should be straightforward to upstream the portions we can share and the 
results, so long as it is understood that we cannot upstream the full stack due 
to the proprietary HW elements – as such I'm not sure how useful the staging 
branch would be although I don't mind doing it.  (In fact I think branch-based 
pull requests are more reviewable than email patchsets but I think I may be in 
the minority on this mailing list).

Thanks,

Eugene


From: Zhang, Chao B mailto:chao.b.zh...@intel.com>>
Sent: Tuesday, November 13, 2018 6:53 PM
To: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Cohen, Eugene 
mailto:eug...@hp.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Yao, Jiewen 
mailto:jiewen@intel.com>>
Cc: Bin, Sung-Uk (빈성욱) mailto:sunguk-...@hp.com>>
Subject: RE: [PATCH 3/4] SecurityPkg: add Tpm

Re: [edk2] [PATCH 6/8] IntelFrameworkPkg: Remove the redundant INFs

Shenglei,

I would prefer we work towards the goal of removing
the use of the Intel Framework Packages by all platforms
so the entire packages can be removed from edk2/master.

This would be better than trying to remove a few items
at a time.

Thanks,

Mike

> -Original Message-
> From: Zhang, Shenglei
> Sent: Tuesday, November 13, 2018 7:32 PM
> To: Ni, Ruiyu ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ;
> Gao, Liming 
> Subject: RE: [edk2] [PATCH 6/8] IntelFrameworkPkg:
> Remove the redundant INFs
> 
> Ray
> Thanks for your constructive comments. I'll improve it
> in next version.
> 
> Thanks,
> Shenglei
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Wednesday, November 14, 2018 11:12 AM
> > To: Zhang, Shenglei ; edk2-
> de...@lists.01.org
> > Cc: Kinney, Michael D ;
> Gao, Liming
> > 
> > Subject: Re: [edk2] [PATCH 6/8] IntelFrameworkPkg:
> Remove the redundant
> > INFs
> >
> > On 11/13/2018 4:35 PM, Shenglei Zhang wrote:
> > > All INFs of unused Library instances in
> IntelFrameworkPkg
> > > are removed as they are not actually used.
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1190
> > >
> > > Cc: Liming Gao 
> > > Cc: Michael D Kinney 
> > > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > > Signed-off-by: Shenglei Zhang
> 
> > > ---
> > >   IntelFrameworkPkg/IntelFrameworkPkg.dsc | 7 -
> --
> > >   1 file changed, 7 deletions(-)
> > >
> > > diff --git
> a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > > index bd5df8c5d9..802a80e3eb 100644
> > > --- a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > > +++ b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> > > @@ -63,13 +63,6 @@
> > >   #   generated for it, but the binary will not
> be put into any firmware
> > volume.
> > >   #
> > >
> >
> ###
> ###
> > #
> > > -[Components]
> > > -
> IntelFrameworkPkg/Library/DxeIoLibCpuIo/DxeIoLibCpuIo.i
> nf
> > > -
> IntelFrameworkPkg/Library/FrameworkUefiLib/FrameworkUef
> iLib.inf
> > > -
> >
> IntelFrameworkPkg/Library/DxeSmmDriverEntryPoint/DxeSmm
> DriverEntryP
> > oint.inf
> > > -
> >
> IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusL
> ibSmbusPpi.in
> > f
> > > -
> >
> IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLibF
> ramework.inf
> > > -
> > >   [BuildOptions]
> > > *_*_*_CC_FLAGS = -D
> DISABLE_NEW_DEPRECATED_INTERFACES
> > >
> > >
> > Shenglei,
> > You cannot remove the INF in the separate patch like
> this.
> > You should either put this patch in the first patch
> in your serial,
> > or combine the DSC change with your library removal.
> > The goal is the the build won't fail when committing
> the patches one by one.
> >
> > --
> > Thanks,
> > Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

Hi Eugene,

My experience is with DTPM and some I2C TPMs at 1.2 level.

One of the I2C TPMs was significantly different, so the TpmIoLib concept does 
not apply.

QuarkPlatformPkg\Library\Tpm12DeviceLibAtmelI2c

The other could potentially use something like TpmIoLib, but may require some 
different delays and timeout values than DTPM.

QuarkPlatformPkg\Library\Tpm12DeviceLibInfineonI2c

So maybe we offer 2 methods to port a TPM.  Once is TpmIoLib if the register 
layout and required delays are the same as DTPM with potentially a different 
base, and the other is to just implement the DeviceLib.

I would recommend that a full implementation of TpmIoLib for a few non MMIO TPM 
devices be completed and pass validation before we consider adding new lib 
class to edk2.  Perhaps using an edk2-staging branch would be a better place to 
start and you can document in the Readme.md the criteria that must be met 
before the new lib class meets the requirements for edk2/master.

Mike

From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, November 13, 2018 3:24 PM
To: Kinney, Michael D ; edk2-devel@lists.01.org; 
Yao, Jiewen ; Zhang, Chao B 
Cc: Bin, Sung-Uk (빈성욱) 
Subject: RE: [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

Mike,

There is a prevalence of base address nomenclature in the DTPM library like:

return TisPcRequestUseTpm ((TIS_PC_REGISTERS_PTR) (UINTN) 
PcdGet64 (PcdTpmBaseAddress));

like from Tpm2Tis.c.


Ø  shouldn’t the Address be the relative address from a base?

I think it is, to the extent that the PcdTpmBaseAddress already exists.


Ø  Or are you using the full DTPM MMIO address on purpose and you expect non 
DTPM MMIO implementations to translate from the DTPM MMIO address to the 
equivalent register access in on an alternate bus type?

My thought is that the PcdTpmBaseAddress could be set to zero (or whatever 
non-MMIO offset makes sense).


Ø  Wouldn't it be better to have an abstraction for different TPM registers and 
the DTPM implementation would convert to a full MMIO address in the lib 
implementation?

I've been led to understand that the TPM registers are the same in both cases.  
I haven't verified this myself - but if you have data to the contrary please 
let us know so we stop going down this path.

My main reason for resisting creating a new library at the Tpm2DeviceLib layer 
because the DTPM library contains a lot of logic around how to talk to the TPM 
that extends well beyond the access mechanism that we would not want to 
duplicate to another library instance.  I'm looking inside Tpm2Tis.c and 
Tpm2Ptp.c to get this perspective.

Thanks,

Eugene

From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Tuesday, November 13, 2018 3:58 PM
To: Cohen, Eugene mailto:eug...@hp.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Yao, Jiewen 
mailto:jiewen@intel.com>>; Zhang, Chao B 
mailto:chao.b.zh...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Bin, Sung-Uk (빈성욱) mailto:sunguk-...@hp.com>>
Subject: RE: [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

Eugene,

It appears you are expecting the Address parameter
to be the full MMIO address for DTPM. If you are
wanting this lib class to abstract the access for
different bus types, shouldn’t the Address be the
relative address from a base?

Or are you using the full DTPM MMIO address on
purpose and you expect non DTPM MMIO implementations
to translate from the DTPM MMIO address to the
equivalent register access in on an alternate bus
type?

Wouldn't it be better to have an abstraction for
different TPM registers and the DTPM implementation
would convert to a full MMIO address in the lib
implementation?

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org<mailto:boun...@lists.01.org>] On Behalf Of Cohen, Eugene
> Sent: Tuesday, November 13, 2018 2:13 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Yao, Jiewen
> mailto:jiewen@intel.com>>; Zhang, Chao B
> mailto:chao.b.zh...@intel.com>>
> Cc: Bin, Sung-Uk (빈성욱) mailto:sunguk-...@hp.com>>
> Subject: [edk2] [PATCH 3/4] SecurityPkg: add
> TpmIoLibMmio instance
>
> SecurityPkg: add TpmIoLibMmio instance
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Chao Zhang mailto:chao.b.zh...@intel.com>>
> Cc: Jiewen Yao mailto:jiewen@intel.com>>
> Signed-off-by: Eugene Cohen mailto:eug...@hp.com>>
> ---
> SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c |
> 221 
> SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.inf |
> 41 
> 2 files changed, 262 insertions(+)
>
> diff --git
> a/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> b/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> new file mode 100644
>

Re: [edk2] [PATCH 1/4] SecurityPkg: enable TPM components to build for ARM and AARCH64

Jiewen,

There are I2C examples for TPM12 in the
QuarkPlatformPkg.  Would that we a good example
too?

Could this new lib class be used for both 
TPM12 and TPM20 devices?

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Yao, Jiewen
> Sent: Tuesday, November 13, 2018 2:22 PM
> To: Cohen, Eugene ; edk2-
> de...@lists.01.org; Zhang, Chao B
> 
> Cc: Bin, Sung-Uk (???) 
> Subject: Re: [edk2] [PATCH 1/4] SecurityPkg: enable TPM
> components to build for ARM and AARCH64
> 
> HI Eugene
> Thanks to enable SPI TPM chip.
> In general, I am OK on this patch series.
> 
> There are some additional work here.
> 1) Please split this patch to 2. The TpmIoLib is not
> present in at this point of time. We should add it
> after TpmIoLib instance is added.
> 
> 2) Since this patch series adds the dependency of
> TpmIoLib, please update *all* impacted platform in
> EDKII repo and EDKII platform repo.
> We need make sure this patch series does not break any
> existing platform build.
> 
> 3) I hope, (if possible) you can provide one *real
> example* on how to add SPI instance, to demonstrate the
> usage and value of this one more layer abstraction.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Cohen, Eugene [mailto:eug...@hp.com]
> > Sent: Wednesday, November 14, 2018 6:13 AM
> > To: edk2-devel@lists.01.org; Yao, Jiewen
> ; Zhang,
> > Chao B 
> > Cc: Bin, Sung-Uk (빈성욱) 
> > Subject: [PATCH 1/4] SecurityPkg: enable TPM
> components to build for ARM
> > and AARCH64
> >
> >  SecurityPkg: enable TPM components to build for ARM
> and AARCH64
> >
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Cc: Chao Zhang 
> > Cc: Jiewen Yao 
> > Signed-off-by: Eugene Cohen 
> > ---
> >  SecurityPkg/SecurityPkg.dsc | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/SecurityPkg/SecurityPkg.dsc
> b/SecurityPkg/SecurityPkg.dsc
> > index 68a2953..6fb9ad2 100644
> > --- a/SecurityPkg/SecurityPkg.dsc
> > +++ b/SecurityPkg/SecurityPkg.dsc
> > @@ -53,6 +53,7 @@
> >
> IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLi
> b.inf
> >
> OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> >
> IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrin
> sic.inf
> > +
> TpmIoLib|SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.
> inf
> >
> TpmCommLib|SecurityPkg/Library/TpmCommLib/TpmCommLib.in
> f
> >
> >
> PlatformSecureLib|SecurityPkg/Library/PlatformSecureLib
> Null/PlatformSecu
> > reLibNull.inf
> >
> >
> TcgPhysicalPresenceLib|SecurityPkg/Library/DxeTcgPhysic
> alPresenceLib/Dxe
> > TcgPhysicalPresenceLib.inf
> > @@ -199,7 +200,7 @@
> >  [Components.IA32, Components.X64, Components.ARM,
> > Components.AARCH64]
> >
> SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> >
> > -[Components.IA32, Components.X64]
> > +[Components.IA32, Components.X64 Components.ARM,
> > Components.AARCH64]
> >  #
> >
> SecurityPkg/UserIdentification/PwdCredentialProviderDxe
> /PwdCredentialPr
> > oviderDxe.inf
> >  #
> >
> SecurityPkg/UserIdentification/UsbCredentialProviderDxe
> /UsbCredentialPro
> > viderDxe.inf
> >
> >
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/S
> ecureBootConfi
> > gDxe.inf
> > --
> > 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] [PATCH 3/4] SecurityPkg: add TpmIoLibMmio instance

Eugene,

It appears you are expecting the Address parameter
to be the full MMIO address for DTPM.  If you are
wanting this lib class to abstract the access for
different bus types, shouldn’t the Address be the
relative address from a base?

Or are you using the full DTPM MMIO address on 
purpose and you expect non DTPM MMIO implementations
to translate from the DTPM MMIO address to the
equivalent register access in on an alternate bus
type?

Wouldn't it be better to have an abstraction for
different TPM registers and the DTPM implementation
would convert to a full MMIO address in the lib
implementation?

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Tuesday, November 13, 2018 2:13 PM
> To: edk2-devel@lists.01.org; Yao, Jiewen
> ; Zhang, Chao B
> 
> Cc: Bin, Sung-Uk (빈성욱) 
> Subject: [edk2] [PATCH 3/4] SecurityPkg: add
> TpmIoLibMmio instance
> 
> SecurityPkg: add TpmIoLibMmio instance
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Chao Zhang 
> Cc: Jiewen Yao 
> Signed-off-by: Eugene Cohen 
> ---
>  SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c   |
> 221 
>  SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.inf |
> 41 
>  2 files changed, 262 insertions(+)
> 
> diff --git
> a/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> b/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> new file mode 100644
> index 000..56f3187
> --- /dev/null
> +++ b/SecurityPkg/Library/TpmIoLibMmio/TpmIoLibMmio.c
> @@ -0,0 +1,221 @@
> +/** @file
> +  This library is to abstract TPM2 register accesses
> so that a common
> +  interface can be used for multiple underlying busses
> such as TPM,
> +  SPI, or I2C access.
> +
> +Copyright (c) 2018 HP Development Company, L.P.
> +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 
> +
> +
> +
> +/**
> +  Reads an 8-bit TPM register.
> +
> +  Reads the 8-bit TPM register specified by Address.
> The 8-bit read value is
> +  returned. This function must guarantee that all TPM
> read and write
> +  operations are serialized.
> +
> +  If 8-bit TPM register operations are not supported,
> then ASSERT().
> +
> +  @param  Address The TPM register to read.
> +
> +  @return The value read.
> +
> +**/
> +UINT8
> +EFIAPI
> +TpmRead8 (
> +  IN  UINTN Address
> +  )
> +{
> +  return MmioRead8 (Address);
> +}
> +
> +/**
> +  Writes an 8-bit TPM register.
> +
> +  Writes the 8-bit TPM register specified by Address
> with the value specified
> +  by Value and returns Value. This function must
> guarantee that all TPM read
> +  and write operations are serialized.
> +
> +  If 8-bit TPM register operations are not supported,
> then ASSERT().
> +
> +  @param  Address The TPM register to write.
> +  @param  Value   The value to write to the TPM
> register.
> +
> +  @return Value.
> +
> +**/
> +UINT8
> +EFIAPI
> +TpmWrite8 (
> +  IN  UINTN Address,
> +  IN  UINT8 Value
> +  )
> +{
> +  return MmioWrite8 (Address, Value);
> +}
> +
> +
> +/**
> +  Reads a 16-bit TPM register.
> +
> +  Reads the 16-bit TPM register specified by Address.
> The 16-bit read value is
> +  returned. This function must guarantee that all TPM
> read and write
> +  operations are serialized.
> +
> +  If 16-bit TPM register operations are not supported,
> then ASSERT().
> +  If Address is not aligned on a 16-bit boundary, then
> ASSERT().
> +
> +  @param  Address The TPM register to read.
> +
> +  @return The value read.
> +
> +**/
> +UINT16
> +EFIAPI
> +TpmRead16 (
> +  IN  UINTN Address
> +  )
> +{
> +  return MmioRead16 (Address);
> +}
> +
> +
> +/**
> +  Writes a 16-bit TPM register.
> +
> +  Writes the 16-bit TPM register specified by Address
> with the value specified
> +  by Value and returns Value. This function must
> guarantee that all TPM read
> +  and write operations are serialized.
> +
> +  If 16-bit TPM register operations are not supported,
> then ASSERT().
> +  If Address is not aligned on a 16-bit boundary, then
> ASSERT().
> +
> +  @param  Address The TPM register to write.
> +  @param  Value   The value to write to the TPM
> register.
> +
> +  @return Value.
> +
> +**/
> +UINT16
> +EFIAPI
> +TpmWrite16 (
> +  IN  UINTN Address,
> +  IN  UINT16Value
> +  )
> +{
> +  return MmioWrite16 (Address, Value);
> +}
> +
> +/**
> +  Reads a 32-bit TPM register.
> +
> +  Reads the 32-bit TPM register specified by Address.

Re: [edk2] [PATCH v1] Maintainers.txt: Change DynamicTablesPkg maintainer

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, November 13, 2018 2:08 PM
> To: Sami Mujawar 
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org;
> matteo.carl...@arm.com; stephanie.hughes-f...@arm.com;
> alexei.fedo...@arm.com; Andrew Fish ;
> Laszlo Ersek ; Kinney, Michael D
> 
> Subject: Re: [PATCH v1] Maintainers.txt: Change
> DynamicTablesPkg maintainer
> 
> +Andrew, Laszlo and Mike.
> 
> Hi Sami,
> 
> For my part, I can confirm that Evan is no longer
> evan.ll...@arm.com,
> so that account can't give an r-b on the change.
> 
> Reviewed-by: Leif Lindholm 
> 
> On Mon, Nov 12, 2018 at 04:27:46PM +, Sami Mujawar
> wrote:
> > Removing Evan and adding Alexei as the co-maintainer.
> >
> > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > Signed-off-by: Sami Mujawar 
> > ---
> >  Maintainers.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index
> cd2a310cbd8c17a8d893c5c747025d1cef1ac433..7b3cb9a0255bf
> 7c249c8202666332e3c4fd83e6c 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -106,8 +106,8 @@ M: Hao Wu 
> >
> >  DynamicTablesPkg
> >  W:
> https://github.com/tianocore/tianocore.github.io/wiki/D
> ynamicTablesPkg
> > -M: Evan Lloyd 
> >  M: Sami Mujawar 
> > +M: Alexei Fedorov 
> >
> >  EdkCompatibilityPkg
> >  W:
> https://github.com/tianocore/tianocore.github.io/wiki/E
> dkCompatibilityPkg
> > --
> > 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> >
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] TPM non-MMIO Access

2018-11-12 Thread Kinney, Michael D

Eugene,

I understand the intent.

Do we know for sure with a change like this that
MMIO and non-MMIO TPMs support the same registers
and require the exact same sequence of register
access to function correctly?  If not, then the
value of adding this new lib class is small.

Also, some of the non-MMIO bus types have much
different performance characteristics, which may
require slightly different interactions for best
performance.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Monday, November 12, 2018 5:59 AM
> To: Yao, Jiewen ; Bin, Sung-Uk
> (빈성욱) ; edk2-devel@lists.01.org;
> Zhang, Chao B 
> Cc: Chae, Matthew 
> Subject: Re: [edk2] [RFC] TPM non-MMIO Access
> 
> Jiewen,
> 
> We don't have a patch yet – we wanted to check with you
> first before going too far.
> 
> 
> Ø  Or just a simple replace-all for MmioRead/Write-
> >TpmMmioRead/Write.
> 
> Yes, basically – with a library class to support it.
> 
> We should not call it "TpmMmioRead8" since on some
> paths it is not MMIO at all.  We should call it
> TpmRead8 (or something like that) and then the MMIO
> instance of the library class would call Mmio
> functions.
> 
> Thanks,
> 
> Eugene
> 
> From: Yao, Jiewen 
> Sent: Sunday, November 11, 2018 9:33 PM
> To: Bin, Sung-Uk (빈성욱) ; Cohen,
> Eugene ; edk2-devel@lists.01.org; Zhang,
> Chao B 
> Cc: Chae, Matthew 
> Subject: RE: [RFC] TPM non-MMIO Access
> 
> OK. Thanks for the clarification.
> 
> If possible, would you please post your patch to
> somewhere?
> 
> Do you request to change any other logic in existing
> Tpm2DeviceLib ?
> Or just a simple replace-all for MmioRead/Write-
> >TpmMmioRead/Write.
> 
> Thank you
> Yao Jiewen
> 
> From: Bin, Sung-Uk (빈성욱) [mailto:sunguk-...@hp.com]
> Sent: Monday, November 12, 2018 12:17 PM
> To: Yao, Jiewen
> mailto:jiewen@intel.com>>;
> Cohen, Eugene mailto:eug...@hp.com>>;
> edk2-devel@lists.01.org de...@lists.01.org>; Zhang, Chao B
> mailto:chao.b.zh...@intel.com>>
> Cc: Chae, Matthew
> mailto:matthew.c...@hp.com>>
> Subject: RE: [RFC] TPM non-MMIO Access
> 
> Hi Jiewen
> 
> What Eugene proposes is not to make those another TPM
> device library instances.
> Instead, we propose new “TpmIoLib” which can handle
> both MMIO and non-MMIO device.
> 
> è Currently Tpm12Tis.c, Tpm2Tis.c and Tpm2Ptp.c uses
> IoLib (CPU IO), and what we propose is to replace it
> with TpmIoLib.
> 
> For example, TpmIoLib can provide TpmMmioRead() and
> Tpm12Tis.c, Tpm2Tis.c and Tpm2Ptp.c can use
> TpmMmioRead() instead of MmioRead().
> 
> -  TpmIoLib for PC (default in SecurityPkg)
> UINT8 TpmMmioRead8 (UINTN  Address )
> {
> return MmioRead8(Address);
> }
> 
> 
> -  TpmIoLib for SPI (vendor creates new
> instance)
> UINT8 TpmMmioRead8 (UINTN  Address )
> {
> UINT8 Data, SpiCs;
> SpiCs = (Address & 0xFF) >> 16;
> TpmAddress = Address & 0x;
> 
>/* Vendor specific SPI control for TPM
> */
> …
> SpiWrite(SpiCs, TpmAddress);
> …
> SpiRead(SpiCs, TpmAddress, &Data);
> return Data;
> }
> 
> This proposal came from code maintanance,
> when we need to update SecurityPkg, then in this case
> it’s more easy to update than making another
> Tpm2DeviceLibDTpm instance.
> 
> Thanks,
> Bin
> 
> From: Yao, Jiewen
> mailto:jiewen@intel.com>>
> Sent: Saturday, November 10, 2018 8:18 AM
> To: Cohen, Eugene
> mailto:eug...@hp.com>>; edk2-
> de...@lists.01.org;
> Zhang, Chao B
> mailto:chao.b.zh...@intel.com>>
> Cc: Bin, Sung-Uk (빈성욱)  b...@hp.com>; Chae, Matthew
> mailto:matthew.c...@hp.com>>
> Subject: RE: [RFC] TPM non-MMIO Access
> 
> Hi Eugene
> The TpmIoLib proposal is similar to the existing
> TpmDeviceLib.
> We have I2C TPM instance as example. You may create
> Tpm12DeviceLibXXXSpi.
> 
> Please let us know if there is any gap to support your
> non-MMIO device.
> 
> Thank you
> Yao Jiewen
> 
> 
> From: Yao, Jiewen
> Sent: Saturday, November 10, 2018 7:12 AM
> To: 'Cohen, Eugene'
> mailto:eug...@hp.com>>; edk2-
> de...@lists.01.org;
> Zhang, Chao B
> mailto:chao.b.zh...@intel.com>>
> Cc: Bin, Sung-Uk (빈성욱)  b...@hp.com>; Chae, Matthew
> mailto:matthew.c...@hp.com>>
> Subject: RE: [RFC] TPM non-MMIO Access
> 
> Hi Eugene
> Complete agree.
> 
> 
> 1)   please ignore TpmCommLib. It is deprecated. ☺
> 
> 
> 2)   we did notice there is non-MMIO TPM device
> before and abstract the device access via Tpm2DeviceLib
> and Tpm12DeviceLib library class. The Tpm2DeviceLibDTpm
> and Tpm12DeviceLibDTpm are the library instance for
> MMIO TIS access.
> 
> We do have other instance such as
> QuarkPlatformPkg\Library\Tpm12DeviceLibAtmelI2c or
> QuarkPlatformPkg\Library\Tpm12DeviceLibInfineonI2c.
> 
> 
> 3)   T

Re: [edk2] [patch] MdeModulePkg/DisplayEngine: Remove useless NULL ptr check for NewPos

Laszlo,

I added EDK2|Documentation|Wiki Pages

I also updated the sort order so Wiki Pages is
first, followed by maintained GitBook documents
sorted alphabetically, with "Other Document" last.

Thanks,

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, November 9, 2018 9:24 AM
> To: Kinney, Michael D ;
> Leif Lindholm ; Gao, Liming
> ; Cetola, Stephano
> 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [patch] MdeModulePkg/DisplayEngine:
> Remove useless NULL ptr check for NewPos
> 
> On 11/09/18 18:14, Kinney, Michael D wrote:
> > Hi Laszlo,
> >
> > There is already a "Documentation" component under
> > EDK2 in BZ.  Can we use that and identify the target
> > of the documentation change is in a Wiki page?
> 
> Absolutely.
> 
> > When you select "Documentation" there is a drop down
> > for "Tianocore documents" that lists the documents
> > published through GitBook along with a catch all
> called
> > "Other Document".  Is this the drop down you would
> like
> > to see "Wiki" added?
> 
> I was undecided. I recalled that earlier there used to
> be a "TianoCore
> Website" component somewhere, but now I couldn't find
> it. Also, I
> considered both options we're discussing now (i.e.,
> EDK2|Wiki, vs.
> EDK2|Documentation|Wiki). I couldn't really decide.
> "EDK2|Documentation|Xxx" seemed to suggest serious
> specifications that
> we publish "in print".
> 
> I think I'd be fine with either option (EDK2|Wiki vs.
> EDK2|Documentation|Wiki); whichever is easier to
> implement on the
> Bugzilla side. :)
> 
> Thank you!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] SecurityPkg: Fix TPM device compatibility issue

Laszlo,

Given that the compatibility issue has been present
for several months, I would prefer this change be
deferred until after the stable tag.

We can document this as a known issue in the release
page for the stable tag and point to the commit after
the stable tag that resolves the compatibility issue
so platforms that are impacted can choose to cherry-pick
the one additional change.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Friday, November 9, 2018 8:22 AM
> To: Zhang, Chao B ; Leif
> Lindholm 
> Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org; Yao, Jiewen
> 
> Subject: Re: [edk2] [Patch] SecurityPkg: Fix TPM device
> compatibility issue
> 
> On 11/09/18 15:46, Zhang, Chao B wrote:
> > Hi Leif:
> >The NTC1310 can work well with previous EDK2
> stable version (UDK2018).
> 
> That's not correct. The last EDK2 stable version is not
> UDK2018. The
> last stable EDK2 version is "edk2-stable201808", and
> the regression
> (commit f15cb995bb38, according to this patch) is
> already contained in
> "edk2-stable201808".
> 
> > Interface Cache is a new feature introduced after
> UDK2018.
> > So far as we see, it causes NTC1310 fail to work.
> 
> That may be the case, but it's not a feature (and
> resultant regression)
> introduced in this development cycle.
> 
> Personally I'm still undecided.
> 
> - From an end-user perspective, this is certainly a
> "bugfix"; given that
> the NTC1310 hardware (which is the real culprit) cannot
> be fixed at all.
> 
> - In a technical edk2 sense, this is a feature-let
> however (with code
> duplication at that) that works around a broken device
> that already
> doesn't work with "edk2-stable201808".
> 
> 
> I'm *slightly* leaning against this change. If the end-
> user regression
> had really been painful, this workaround would have
> been implemented
> very soon after "edk2-stable201808", not in a last
> minute rush before
> "edk2-stable201811".
> 
> I'd like to hear Mike's and Andrew's opinion too.
> 
> Thanks,
> Laszlo
> 
> >
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Leif Lindholm
> > Sent: Friday, November 9, 2018 7:13 PM
> > To: Laszlo Ersek 
> > Cc: Kinney, Michael D ;
> edk2-devel@lists.01.org; Yao, Jiewen
> ; Zhang, Chao B
> 
> > Subject: Re: [edk2] [Patch] SecurityPkg: Fix TPM
> device compatibility issue
> >
> > On Fri, Nov 09, 2018 at 09:04:46AM +0100, Laszlo
> Ersek wrote:
> >> On 11/09/18 07:02, Zhang, Chao B wrote:
> >>> Issue Statement:
> >>> TPM InterfaceId cache feature is introduced by
> f15cb995bb3880b77e15afe6facd3da05e599a17. It follows
> TCG PTP spec 1.3
> >>> to improve TPM transmission performance and also
> addresses defects in some TPM2.0 devices. But some
> other TPM devices like
> >>> NTC1310 SPI TPM is found function abnormally with
> this feature, causing extra device compatibility issue.
> >>>
> >>> Solution:
> >>> Add a policy indicator in PcdActiveTpmInterfaceType
> to disable TPM interface ID cache to support those
> existing TPM devices
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement
> 1.1
> >>> Signed-off-by: Zhang, Chao B
> mailto:chao.b.zh...@intel.com>>
> >>> Cc: Andrew Fish
> mailto:af...@apple.com>>
> >>> Cc: Laszlo Ersek
> mailto:ler...@redhat.com>>
> >>> Cc: Leif Lindholm
> mailto:leif.lindholm@linaro.o
> rg>>
> >>> Cc: Michael D Kinney
> mailto:michael.d.kinney@int
> el.com>>
> >>> Cc: Yao Jiewen
> mailto:jiewen@intel.com>>
> >>> ---
> >>>  SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c |
> 23 +++-
> >>>  SecurityPkg/SecurityPkg.dec |
> 3 +-
> >>>  SecurityPkg/SecurityPkg.uni |
> 3 +-
> >>>  SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c |
> 49 +
> >>>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c   |
> 42 +
> >>>  5 files changed, 117 insertions(+), 3 deletions(-)
> >>
> >> I'll let others review this patch for technical
> merit.
> >>
> >> However, I'm really undecided whether this patch
> qualifies for being
> >> pushed during the hard feature freeze. Comments
> welcome.

Re: [edk2] [patch] MdeModulePkg/DisplayEngine: Remove useless NULL ptr check for NewPos

Hi Laszlo,

There is already a "Documentation" component under
EDK2 in BZ.  Can we use that and identify the target
of the documentation change is in a Wiki page?

When you select "Documentation" there is a drop down
for "Tianocore documents" that lists the documents
published through GitBook along with a catch all called
"Other Document".  Is this the drop down you would like
to see "Wiki" added?

Thanks,

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, November 9, 2018 8:33 AM
> To: Leif Lindholm ; Gao,
> Liming ; Kinney, Michael D
> ; Cetola, Stephano
> 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [patch] MdeModulePkg/DisplayEngine:
> Remove useless NULL ptr check for NewPos
> 
> On 11/09/18 17:01, Leif Lindholm wrote:
> > On Fri, Nov 09, 2018 at 03:32:03PM +, Gao, Liming
> wrote:
> >> Laszlo and Leif:
> >>   I suggest to continue to update wiki page with
> more
> >>   information. If so, we can avoid such case again.
> >
> > Agreed, we need to be able to interpret what the
> process says
> > identically.
> 
> Making the wiki real precise on this question requires
> dedicated work. I
> was OK to simply send a patch about the announcements,
> but this topic
> requires more thinking, more discussion, and well, more
> tracking.
> 
> Mike: would it be proper to create a "Wiki" Component
> under the EDK2
> product in the bugzilla?
> 
> If so, I would suggest filing a BZ against that (new)
> component, and
> then we should discuss the freeze scopes in one of the
> next community
> meetings.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-wiki PATCH] release planning: announce the soft and hard feature freezes

Perhaps we should update Maintainers.txt with some lines
that identify the developers that are currently assigned
to the release/release planning role.  That way, the Wiki
can reference Maintainters.txt and we can update
Maintainers.txt as the assignments change over time.

Thanks,

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, November 9, 2018 8:27 AM
> To: Gao, Liming ; Leif Lindholm
> 
> Cc: edk2-devel@lists.01.org; Andrew Fish
> ; Richardson, Brian
> ; Kinney, Michael D
> ; Cetola, Stephano
> 
> Subject: Re: [edk2-wiki PATCH] release planning:
> announce the soft and hard feature freezes
> 
> On 11/09/18 16:09, Gao, Liming wrote:
> > Laszlo:
> >  Can ';' be removed from below sentence?
> >
> > an announcement email is sent to the edk2-devel
> mailing list; by default by Liming Gao.
> >
> > ==>
> >
> > an announcement email is sent to the edk2-devel
> mailing list by default by Liming Gao.
> 
> Hmm I don't really like that, to me it makes the
> sentence a lot harder
> to read. How about this simplified version instead
> (i.e., drop "by
> default", and the semicolon):
> 
> "an announcement email is sent to the edk2-devel
> mailing list by Liming Gao"
> 
> ?
> 
> Thanks!
> Laszlo
> 
> 
> 
> >
> > Thanks
> > Liming
> >> -Original Message-
> >> From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> >> Sent: Friday, November 9, 2018 6:05 PM
> >> To: Laszlo Ersek 
> >> Cc: edk2-devel@lists.01.org; Andrew Fish
> ; Richardson, Brian
> ; Gao, Liming
> >> ; Kinney, Michael D
> ; Cetola, Stephano
> 
> >> Subject: Re: [edk2-wiki PATCH] release planning:
> announce the soft and hard feature freezes
> >>
> >> On Thu, Nov 08, 2018 at 06:28:07PM +0100, Laszlo
> Ersek wrote:
> >>> Add a paragraph to each of the SoftFeatureFreeze
> and HardFeatureFreeze
> >>> articles about the respective announcements on
> edk2-devel.
> >>>
> >>> Cc: Andrew Fish 
> >>> Cc: Brian Richardson 
> >>> Cc: Leif Lindholm 
> >>> Cc: Liming Gao 
> >>> Cc: Michael Kinney 
> >>> Cc: Stephano Cetola 
> >>> Contributed-under: TianoCore Contribution Agreement
> 1.1
> >>> Signed-off-by: Laszlo Ersek 
> >>
> >> Reviewed-by: Leif Lindholm
> 
> >>
> >>> ---
> >>>
> >>> Notes:
> >>> Check out the rendered pages in my clone of the
> wiki:
> >>>
> >>>
> https://github.com/lersek/edk2/wiki/SoftFeatureFreeze
> >>>
> https://github.com/lersek/edk2/wiki/HardFeatureFreeze
> >>>
> >>>  HardFeatureFreeze.md | 8 
> >>>  SoftFeatureFreeze.md | 8 
> >>>  2 files changed, 16 insertions(+)
> >>>
> >>> diff --git a/HardFeatureFreeze.md
> b/HardFeatureFreeze.md
> >>> index 01288dd03f71..e08f4c047e8d 100644
> >>> --- a/HardFeatureFreeze.md
> >>> +++ b/HardFeatureFreeze.md
> >>> @@ -4,3 +4,11 @@ tag](EDK-II#stable-tags).
> >>>
> >>>  (This definition is modeled after QEMU's [hard
> feature
> >>>
> freeze](https://wiki.qemu.org/Planning/HardFeatureFreez
> e)).
> >>> +
> >>> +# Announcing the hard feature freeze
> >>> +
> >>> +The proposed schedule for the active development
> cycle is shown in the [EDK II
> >>> +Release Planning](EDK-II-Release-Planning)
> article. Shortly before the hard
> >>> +feature freeze, an announcement email is sent to
> the
> >>> +[edk2-
> devel](https://lists.01.org/mailman/listinfo/edk2-
> devel) mailing list; by
> >>> +default by [Liming
> Gao](https://github.com/lgao4/).
> >>> diff --git a/SoftFeatureFreeze.md
> b/SoftFeatureFreeze.md
> >>> index 9dc7d9c19369..e33dd80ccbee 100644
> >>> --- a/SoftFeatureFreeze.md
> >>> +++ b/SoftFeatureFreeze.md
> >>> @@ -40,3 +40,11 @@ communicate with the maintainer
> about their intentions. It also helps if you:
> >>>
> >>>  (This definition is modeled after QEMU's [soft
> feature
> >>>
> freeze](https://wiki.qemu.org/Planning/SoftFeatureFreez
> e).)
> >>> +
> >>> +# Announcing the soft feature freeze
> >>> +
> >>> +The proposed schedule for the active development
> cycle is shown in the [EDK II
> >>> +Release Planning](EDK-II-Release-Planning)
> article. Shortly before the soft
> >>> +feature freeze, an announcement email is sent to
> the
> >>> +[edk2-
> devel](https://lists.01.org/mailman/listinfo/edk2-
> devel) mailing list; by
> >>> +default by [Liming
> Gao](https://github.com/lgao4/).
> >>> --
> >>> 2.19.1.3.g30247aa5d201
> >>>

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

Re: [edk2] [Patch] BaseTools: Optimize string concatenation

Liming,

If we can support both Python2 and Python3 equally,
then I agree that these types of performance enhancements
can be added to edk2/master after the stable tag.

Let's make sure we enter a BZ for each performance
improvement and as Leif has asked, put evidence of the
performance improvement in the BZ.

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Friday, November 9, 2018 6:17 AM
> To: Kinney, Michael D ;
> Feng, Bob C ; edk2-
> de...@lists.01.org
> Cc: Carsey, Jaben 
> Subject: RE: [edk2] [Patch] BaseTools: Optimize string
> concatenation
> 
> Mike:
>   This patch bases on edk2 master with Python27.
> Seemly, most people are not aware that Python3
> migration
> (https://bugzilla.tianocore.org/show_bug.cgi?id=55) is
> added for next edk2-stable201903 tag planning. In BZ
> 55, I propose to keep Python2 and Python3 both, and new
> feature and patches are created based on Python3. I
> will send the mail to collect the feedback on this
> approach.
> 
> Thanks
> Liming
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Friday, November 9, 2018 12:41 AM
> > To: Feng, Bob C ; edk2-
> de...@lists.01.org; Kinney, Michael D
> 
> > Cc: Carsey, Jaben ; Gao,
> Liming 
> > Subject: RE: [edk2] [Patch] BaseTools: Optimize
> string concatenation
> >
> > Bob,
> >
> > Is this for edk2/master or for the Python 3
> conversion in the
> > edk2-staging branch?  If it is for the edk-staging
> branch, then
> > the Subject is not correct.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org] On Behalf Of BobCF
> > > Sent: Thursday, November 8, 2018 2:16 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben ; Gao,
> Liming
> > > 
> > > Subject: [edk2] [Patch] BaseTools: Optimize string
> > > concatenation
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1288
> > >
> > > This patch is one of build tool performance
> improvement
> > > series patches.
> > >
> > > This patch is going to use join function instead of
> > > string += string2 statement.
> > >
> > > Current code use string += string2 in a loop to
> combine
> > > a string. while creating a string list in a loop
> and
> > > using
> > > "".join(stringlist) after the loop will be much
> faster.
> > >
> > > Contributed-under: TianoCore Contribution Agreement
> 1.1
> > > Signed-off-by: BobCF 
> > > Cc: Liming Gao 
> > > Cc: Jaben Carsey 
> > > ---
> > >  BaseTools/Source/Python/AutoGen/StrGather.py  | 39
> > > +--
> > >  BaseTools/Source/Python/Common/Misc.py| 21
> > > +-
> > >  .../Source/Python/Workspace/InfBuildData.py   |  4
> +-
> > >  .../Python/Workspace/WorkspaceCommon.py   | 11
> ++-
> > > ---
> > >  4 files changed, 44 insertions(+), 31 deletions(-)
> > >
> > > diff --git
> > > a/BaseTools/Source/Python/AutoGen/StrGather.py
> > > b/BaseTools/Source/Python/AutoGen/StrGather.py
> > > index 361d499076..d34a9e9447 100644
> > > --- a/BaseTools/Source/Python/AutoGen/StrGather.py
> > > +++ b/BaseTools/Source/Python/AutoGen/StrGather.py
> > > @@ -135,11 +135,11 @@ def AscToHexList(Ascii):
> > >  # @param UniGenCFlag  UniString is generated
> into
> > > AutoGen C file when it is set to True
> > >  #
> > >  # @retval Str:   A string of .h file
> content
> > >  #
> > >  def CreateHFileContent(BaseName, UniObjectClass,
> > > IsCompatibleMode, UniGenCFlag):
> > > -Str = ''
> > > +Str = []
> > >  ValueStartPtr = 60
> > >  Line = COMMENT_DEFINE_STR + ' ' +
> > > LANGUAGE_NAME_STRING_NAME + ' ' * (ValueStartPtr -
> > > len(DEFINE_STR + LANGUAGE_NAME_STRING_NAME)) +
> > > DecToHexStr(0, 4) + COMMENT_NOT_REFERENCED
> > >  Str = WriteLine(Str, Line)
> > >  Line = COMMENT_DEFINE_STR + ' ' +
> > > PRINTABLE_LANGUAGE_NAME_STRING_NAME + ' ' *
> > > (ValueStartPtr - len(DEFINE_STR +
> > > PRINTABLE_LANGUAGE_NAME_STRING_NAME)) +
> DecToHexStr(1,
> > > 4) + COMMENT_NOT_REFERENCED
> > >  Str = WriteLine(Str, Line)
> > > @@ -164,16 +164,16 @@ def
> CreateHFileContent(BaseName,
> > > UniObject

Re: [edk2] Edk2 uni file encoding

2018-11-08 Thread Kinney, Michael D

Sean,

As a clarification.  The UNI specs does list 2 on-disk formats.
This was done so tools could support both in the transition
from UTF-16LE with BOM to UTF-8 without BOM.

The strong recommendation is for all EDK II open source packages to
use UTF-8 without a BOM.  Since platform packages not maintained
in EDK II could be pulling forward UNI files in UTF-16LE, we
have not changed the UNI spec or tools to consider UTF-16LE
as unsupported.

Doing patch email reviews of UNI files in UTF-16LE is a challenge
so requiring UTF-8 without a BOM make this much easier.

The EDK II open source package conversion to UTF-8 without a BO
was performed in late 2015.  Here is one example:

https://github.com/tianocore/edk2/commit/3f5287971ffdb5c42e3325a3a94c101f08d3a02a#diff-14d2171dacfcac1fd2e1b1f7b885e530

A helper python script was added to help perform these conversions:

https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/ConvertUni.py

At some point, it may make sense to *require* UTF-8 without a 
BOM for all UNI files and all tools and for tools to reject
UNI files that are not in UTF-8 without a BOM format.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Sean Brogan via
> edk2-devel
> Sent: Wednesday, November 7, 2018 11:11 PM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Edk2 uni file encoding
> 
> Liming,
> That was exactly what I was looking for.
> 
> Thanks
> Sean
> 
> 
> 
> 
> -Original Message-
> From: Gao, Liming 
> Sent: Wednesday, November 7, 2018 10:01 PM
> To: Sean Brogan 
> Cc: edk2-devel@lists.01.org
> Subject: RE: Edk2 uni file encoding
> 
> Sean:
>   EDKII UNI spec
> (https://na01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io
> %2Fwiki%2FEDK-II-
> Specifications&data=02%7C01%7Csean.brogan%40microso
> ft.com%7C5ffeb105737e4c00150208d6453fa46a%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C636772536983024335&
> sdata=veov60rbEtr3ub7RcreuFuqJvc4%2BdtAowph7kBGXW54%3D&
> amp;reserved=0) Chapter 2 defines UNI file format.
> EdkCompatibilityPkg is obsolete. BZ
> https://na01.safelinks.protection.outlook.com/?url=http
> s%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D
> 1103&data=02%7C01%7Csean.brogan%40microsoft.com%7C5
> ffeb105737e4c00150208d6453fa46a%7C72f988bf86f141af91ab2
> d7cd011db47%7C1%7C0%7C636772536983024335&sdata=LOLe
> zJzuK9kwu8QK78UM5nnCD%2FZEY5fxr1VQzk8sqY8%3D&reserv
> ed=0 is submitted to delete EdkCompatibilityPkg from
> edk2/master. We will work on it.
> 
> EDK II Unicode files are used for mapping token names
> to localized strings that are identified by an RFC4646
> language code. The format for storing EDK II Unicode
> files on disk is UTF-8 (without a BOM character) or
> UTF-16LE (with a BOM character). The character content
> must be UCS-2.
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> >Sean Brogan via edk2-devel
> >Sent: Thursday, November 08, 2018 7:00 AM
> >To: edk2-devel@lists.01.org
> >Subject: [edk2] Edk2 uni file encoding
> >
> >Is there a definitive answer for the file encoding for
> all UNI files in edk2?
> >If not I would like to propose one.  Incorrect
> encoding causes tool
> >issues and is something we can easily check for and
> fix.
> >
> >Proposal: All UNI files in edk2 should be
> >
> >
> >  1.  UTF-8
> >Or
> >
> >  1.  Use a BOM and be UTF-16
> >
> >https://na01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fen.wik
> >ipedia.org%2Fwiki%2FByte_order_mark&data=02%7C01%7
> Csean.brogan%40mi
> >crosoft.com%7C5ffeb105737e4c00150208d6453fa46a%7C72f98
> 8bf86f141af91ab2d
> >7cd011db47%7C1%7C0%7C636772536983024335&sdata=1IET
> 4LN5l9FfMscffzgk0
> >t7IqYGyYNU9IrZafvi9osU%3D&reserved=0
> >
> >Results from searching edk2:
> >1 - UTF-16 LE BOM file:
> >EdkCompatibilityPkg\Compatibility\FrameworkHiiOnUefiHi
> iThunk\Strings.un
> >i
> >919 - Without BOM and decoded as UTF-8
> >
> >Thoughts?
> >
> >Future question:  Can we make rule for all other
> standard file types
> >(c, h, dec, dsc, fdf, inf,)?
> >
> >Thanks
> >Sean
> >
> >
> >
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://na01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Flists.
> >01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel&data=02%7C01%7Csean.brogan
> >%40microsoft.com%7C5ffeb105737e4c00150208d6453fa46a%7C
> 72f988bf86f141af9
> >1ab2d7cd011db47%7C1%7C0%7C636772536983024335&sdata
> =HhfPaCyS0sKHu1fF
> >Gkfh%2FQ4pm34X68YKiaM6IN7%2Fzj0%3D&reserved=0
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Optimize string concatenation

2018-11-08 Thread Kinney, Michael D

Bob,

Is this for edk2/master or for the Python 3 conversion in the
edk2-staging branch?  If it is for the edk-staging branch, then
the Subject is not correct.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of BobCF
> Sent: Thursday, November 8, 2018 2:16 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Gao, Liming
> 
> Subject: [edk2] [Patch] BaseTools: Optimize string
> concatenation
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1288
> 
> This patch is one of build tool performance improvement
> series patches.
> 
> This patch is going to use join function instead of
> string += string2 statement.
> 
> Current code use string += string2 in a loop to combine
> a string. while creating a string list in a loop and
> using
> "".join(stringlist) after the loop will be much faster.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: BobCF 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  BaseTools/Source/Python/AutoGen/StrGather.py  | 39
> +--
>  BaseTools/Source/Python/Common/Misc.py| 21
> +-
>  .../Source/Python/Workspace/InfBuildData.py   |  4 +-
>  .../Python/Workspace/WorkspaceCommon.py   | 11 ++-
> ---
>  4 files changed, 44 insertions(+), 31 deletions(-)
> 
> diff --git
> a/BaseTools/Source/Python/AutoGen/StrGather.py
> b/BaseTools/Source/Python/AutoGen/StrGather.py
> index 361d499076..d34a9e9447 100644
> --- a/BaseTools/Source/Python/AutoGen/StrGather.py
> +++ b/BaseTools/Source/Python/AutoGen/StrGather.py
> @@ -135,11 +135,11 @@ def AscToHexList(Ascii):
>  # @param UniGenCFlag  UniString is generated into
> AutoGen C file when it is set to True
>  #
>  # @retval Str:   A string of .h file content
>  #
>  def CreateHFileContent(BaseName, UniObjectClass,
> IsCompatibleMode, UniGenCFlag):
> -Str = ''
> +Str = []
>  ValueStartPtr = 60
>  Line = COMMENT_DEFINE_STR + ' ' +
> LANGUAGE_NAME_STRING_NAME + ' ' * (ValueStartPtr -
> len(DEFINE_STR + LANGUAGE_NAME_STRING_NAME)) +
> DecToHexStr(0, 4) + COMMENT_NOT_REFERENCED
>  Str = WriteLine(Str, Line)
>  Line = COMMENT_DEFINE_STR + ' ' +
> PRINTABLE_LANGUAGE_NAME_STRING_NAME + ' ' *
> (ValueStartPtr - len(DEFINE_STR +
> PRINTABLE_LANGUAGE_NAME_STRING_NAME)) + DecToHexStr(1,
> 4) + COMMENT_NOT_REFERENCED
>  Str = WriteLine(Str, Line)
> @@ -164,16 +164,16 @@ def CreateHFileContent(BaseName,
> UniObjectClass, IsCompatibleMode, UniGenCFlag):
>  Line = COMMENT_DEFINE_STR + ' ' +
> Name + ' ' + DecToHexStr(Token, 4) +
> COMMENT_NOT_REFERENCED
>  else:
>  Line = COMMENT_DEFINE_STR + ' ' +
> Name + ' ' * (ValueStartPtr - len(DEFINE_STR + Name)) +
> DecToHexStr(Token, 4) + COMMENT_NOT_REFERENCED
>  UnusedStr = WriteLine(UnusedStr, Line)
> 
> -Str = ''.join([Str, UnusedStr])
> +Str.extend( UnusedStr)
> 
>  Str = WriteLine(Str, '')
>  if IsCompatibleMode or UniGenCFlag:
>  Str = WriteLine(Str, 'extern unsigned char ' +
> BaseName + 'Strings[];')
> -return Str
> +return "".join(Str)
> 
>  ## Create a complete .h file
>  #
>  # Create a complet .h file with file header and file
> content
>  #
> @@ -185,11 +185,11 @@ def CreateHFileContent(BaseName,
> UniObjectClass, IsCompatibleMode, UniGenCFlag):
>  # @retval Str:   A string of complete .h file
>  #
>  def CreateHFile(BaseName, UniObjectClass,
> IsCompatibleMode, UniGenCFlag):
>  HFile = WriteLine('', CreateHFileContent(BaseName,
> UniObjectClass, IsCompatibleMode, UniGenCFlag))
> 
> -return HFile
> +return "".join(HFile)
> 
>  ## Create a buffer to store all items in an array
>  #
>  # @param BinBuffer   Buffer to contain Binary data.
>  # @param Array:  The array need to be formatted
> @@ -209,11 +209,11 @@ def CreateBinBuffer(BinBuffer,
> Array):
>  #
>  def CreateArrayItem(Array, Width = 16):
>  MaxLength = Width
>  Index = 0
>  Line = '  '
> -ArrayItem = ''
> +ArrayItem = []
> 
>  for Item in Array:
>  if Index < MaxLength:
>  Line = Line + Item + ',  '
>  Index = Index + 1
> @@ -221,11 +221,11 @@ def CreateArrayItem(Array, Width
> = 16):
>  ArrayItem = WriteLine(ArrayItem, Line)
>  Line = '  ' + Item + ',  '
>  Index = 1
>  ArrayItem = Write(ArrayItem, Line.rstrip())
> 
> -return ArrayItem
> +return "".join(ArrayItem)
> 
>  ## CreateCFileStringValue
>  #
>  # Create a line with string value
>  #
> @@ -236,11 +236,11 @@ def CreateArrayItem(Array, Width
> = 16):
> 
>  def CreateCFileStringValue(Value):
>  Value = [StringBlockType] + Value
>  Str = WriteLine('', CreateArrayItem(Value))
> 
> -return Str
> +return "".join(Str)
> 
>  ## GetFilteredLanguage
>  #
>  # apply get best language rules to the UNI language
> code list
>  #
> @@ -438,11 +438,11 @@ def CreateCFileContent(BaseName,
> UniObjectCl

Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

2018-11-06 Thread Kinney, Michael D

Hi Ard,

Can you please add CC lines to the commit message
for the developers that have contributed to the
edk2-staging/Intel_UNDI branch?

This would include:

Cc: Maciej Rabeda 
Cc: Kamil Kacperski 
Cc: Pawel Orlowski 

Thanks,

Mike


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 6, 2018 9:58 AM
> To: edk2-devel@lists.01.org
> Cc: Rabeda, Maciej ; Kinney,
> Michael D ; Jin, Eric
> ; leif.lindh...@linaro.org; Ard
> Biesheuvel 
> Subject: [PATCH edk2-staging 00/19]
> IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC
> 
> This series fixes the GigUndiDxe in the edk2-
> staging/Intel_UNDI branch
> at github.com/tianocore so it can be built with GCC on
> Linux for ARM
> and AARCH64 (as well as X64)
> 
> Ard Biesheuvel (19):
>   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to
> supported
> architectures
>   IntelUndiPkg: remove EOF markers
>   IntelUndiPkg/GigUndiDxe: consistently use lowercase
> for e1000 in
> filenames
>   IntelUndiPkg/GigUndiDxe: consistently use forward
> slashes as path
> separators
>   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration
> after type
> definition
>   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts
> for pointers
>   IntelUndiPkg/GigUndiDxe: create GCC alternatives for
> MSFT build
> options
>   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
>   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
>   IntelUndiPkg/GigUndiDxe: add missing braces to GUID
> literals
>   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP
> token pasting
>   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to
> correct pointer
> type
>   IntelUndiPkg/GigUndiDxe: don't take address of cast
> expression
>   IntelUndiPkg/GigUndiDxe: redefine
> UNREFERENCED_nPARAMETER macros for
> GCC
>   IntelUndiPkg/GigUndiDxe: remove forward declaration of
> non-existent
> function
>   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
>   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides
> to INF file
>   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
>   IntelUndiPkg/GigUndiDxe: remove or reorganize unused
> variables
> 
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
>  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
>  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++--
> -
>  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++-
> --
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
>  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39
> +--
>  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Init.c| 11 +++-
> --
>  IntelUndiPkg/GigUndiDxe/Init.h|  1 -
>  IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
>  IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
>  IntelUndiPkg/GigUndiDxe/Version.h |  1 -
>  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37
> --
>  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 10
> -
>  IntelUndiPkg/GigUndiDxe/e1000_hw.h|  1 -
&g

Re: [edk2] [PATCH 1/1] MdePkg/Base.h: Implement BASE_CR() via OFFSET_OF().

2018-11-02 Thread Kinney, Michael D

Marvin,

Thanks.  This is a good improvement.

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, November 1, 2018 6:33 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: RE: [PATCH 1/1] MdePkg/Base.h: Implement
> BASE_CR() via OFFSET_OF().
> 
> The change is good. Reviewed-by: Liming Gao
> 
> 
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of
> >Marvin H?user
> >Sent: Thursday, November 01, 2018 4:09 AM
> >To: edk2-devel@lists.01.org
> >Cc: Kinney, Michael D ;
> Gao, Liming
> >
> >Subject: [edk2] [PATCH 1/1] MdePkg/Base.h: Implement
> BASE_CR() via
> >OFFSET_OF().
> >
> >Replace the current NULL pointer dereference to
> retrieve Field's
> >offset with a call to OFFSET_OF().  This is implemented
> via
> >__builtin_offsetof for GCC and Clang, which eliminates
> UB caught by
> >Clang UndefinedBehaviorSanitizer.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Marvin Haeuser
> 
> >---
> > MdePkg/Include/Base.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/MdePkg/Include/Base.h
> b/MdePkg/Include/Base.h
> >index 523192fd79fc..bc877d8125a5 100644
> >--- a/MdePkg/Include/Base.h
> >+++ b/MdePkg/Include/Base.h
> >@@ -869,7 +869,7 @@ typedef UINTN  *BASE_LIST;
> >   @return  A pointer to the structure from one of it's
> elements.
> >
> > **/
> >-#define BASE_CR(Record, TYPE, Field)  ((TYPE *)
> ((CHAR8 *) (Record) -
> >(CHAR8 *) &(((TYPE *) 0)->Field)))
> >+#define BASE_CR(Record, TYPE, Field)  ((TYPE *)
> ((CHAR8 *) (Record) -
> >OFFSET_OF (TYPE, Field)))
> >
> > /**
> >   Rounds a value up to the next boundary using a
> specified alignment.
> >--
> >2.19.1.windows.1
> >
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/6] IntelFrameworkPkg: fix build for AARCH64/ARM

2018-11-01 Thread Kinney, Michael D

Reviewed-by: Michael D Kinney 

Mike


> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, November 1, 2018 8:37 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ;
> Gao, Liming 
> Subject: [PATCH 3/6] IntelFrameworkPkg: fix build for
> AARCH64/ARM
> 
> Contrary to what the name suggests, some modules in
> this package are used
> on other architecture. ARM is already listed in
> SUPPORTED_ARCHITECTURES
> in the .dsc, but AARCH64 was never added - so do that.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
>  IntelFrameworkPkg/IntelFrameworkPkg.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> index bd5df8c5d9..f957af78fb 100644
> --- a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> +++ b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
> @@ -26,7 +26,7 @@ [Defines]
>PLATFORM_VERSION   = 0.96
>DSC_SPECIFICATION  = 0x00010005
>OUTPUT_DIRECTORY   =
> Build/IntelFramework
> -  SUPPORTED_ARCHITECTURES= IA32|X64|EBC|ARM
> +  SUPPORTED_ARCHITECTURES=
> IA32|X64|EBC|ARM|AARCH64
>BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
>SKUID_IDENTIFIER   = DEFAULT
> 
> --
> 2.11.0

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

Re: [edk2] [PATCH 1/6] AppPkg: fix webserver build for !Ia32/X64

2018-11-01 Thread Kinney, Michael D

Leif,

The MSR definitions are only used by Mtrr.c, and Mtrr.c is only
used for IA32 and X64 builds in the INF file.

It would be simpler to move the #include 
into Mtrr.c.  That would avoid the use of #if.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Leif Lindholm
> Sent: Thursday, November 1, 2018 8:37 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Daryl
> McDaniel 
> Subject: [edk2] [PATCH 1/6] AppPkg: fix webserver build
> for !Ia32/X64
> 
> The WebServer application is really quite Ia32/X64
> specific, but fundamentally
> it builds for other architectures as long as the
> architecture-specific
>   #include 
> header file is filtered out.
> So add an architecture-based filter on that to enable
> AppPkg.dsc to build for
> AARCH64/ARM (both listed in SUPPORTED_ARCHITECTURES).
> 
> Cc: Daryl McDaniel 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
> 
> Note: there is definitely a case here for just
> disabling this component
>   for !Ia32/X64, but the _interesting_ bits of this
> application are
>   completely architecture independent, so my
> preference would be to
>   do this for now, and worry about remaining issues
> (like MTRR dump)
>   at some point in the future.
> 
>  AppPkg/Applications/Sockets/WebServer/WebServer.h | 2
> ++
>  1 file changed, 2 insertions(+)
> 
> diff --git
> a/AppPkg/Applications/Sockets/WebServer/WebServer.h
> b/AppPkg/Applications/Sockets/WebServer/WebServer.h
> index 21b07b63df..610abdcf9e 100644
> --- a/AppPkg/Applications/Sockets/WebServer/WebServer.h
> +++ b/AppPkg/Applications/Sockets/WebServer/WebServer.h
> @@ -20,7 +20,9 @@
> 
>  #include 
> 
> +#if defined(__x86_64__) || defined(__i386__)
>  #include 
> +#endif
>  #include 
>  #include 
>  #include 
> --
> 2.11.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in MdeModulePkg.

2018-10-31 Thread Kinney, Michael D

Fu Siyuan,

Just edk2-platforms/master.

Maintainers for devel and stable branches need to device
when to move to a new version of edk2 repo and perform
integration tasks. 

The patch for edk2-platforms/master should include this
notification so maintainer of devel and stable branches
will know that the need to pay attention to this change.

Mike

> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, October 30, 2018 5:52 PM
> To: Kinney, Michael D ;
> Zeng, Star ; edk2-
> de...@lists.01.org
> Cc: Leif Lindholm ; Andrew
> Fish (af...@apple.com) ; Laszlo Ersek
> (ler...@redhat.com) ; Gao, Liming
> 
> Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in MdeModulePkg.
> 
> Mike,
> 
> Should I also update the devel branches in edk2-
> platform? Or the branch owner will take care of it?
> 
> BestRegards
> Fu Siyuan
> 
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Wednesday, October 31, 2018 5:15 AM
> > To: Fu, Siyuan ; Zeng, Star
> ;
> > edk2-devel@lists.01.org; Kinney, Michael D
> 
> > Cc: Leif Lindholm ; Andrew
> Fish (af...@apple.com)
> > ; Laszlo Ersek (ler...@redhat.com)
> ;
> > Gao, Liming 
> > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in
> > MdeModulePkg.
> >
> > Fu Siyuan,
> >
> > Please review edk2-platform/master and prepare a patch
> > for that branch if there are DSC/FDF files that refer
> > to the network drivers that are being removed.
> >
> > We should never break any platforms in edk2-
> platform/master.
> > The commits should be performed to the repos in the
> correct
> > order to guarantee no build breaks.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Fu, Siyuan
> > > Sent: Tuesday, October 30, 2018 1:23 AM
> > > To: Zeng, Star ; edk2-
> > > de...@lists.01.org
> > > Cc: Kinney, Michael D ;
> Leif
> > > Lindholm ; Andrew Fish
> > > (af...@apple.com) ; Laszlo Ersek
> > > (ler...@redhat.com) ; Gao, Liming
> > > 
> > > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> > > iSCSI driver in MdeModulePkg.
> > >
> > > Hi, Star
> > >
> > > This patch only covers the platforms in
> > > https://github.com/tianocore/edk2
> > >
> > > I will modify the edk2 network wiki page for an
> updated
> > > sample DSC/FDF section, if this patch could pass
> review
> > > w/o objection.
> > >
> https://github.com/tianocore/tianocore.github.io/wiki/Ne
> > > tworkPkg-Getting-Started-Guide
> > >
> > > Let's wait a few days to see if there is any
> objection
> > > on deleting these driver first, and I will be happy
> to
> > > generate another patch for edk2-platforms then.
> > >
> > > Thanks for your reminder.
> > >
> > >
> > > BestRegards
> > > Fu Siyuan
> > >
> > > > -Original Message-
> > > > From: Zeng, Star
> > > > Sent: Tuesday, October 30, 2018 3:43 PM
> > > > To: Fu, Siyuan ; edk2-
> > > de...@lists.01.org
> > > > Cc: Kinney, Michael D
> ;
> > > Leif Lindholm
> > > > ; Andrew Fish
> > > (af...@apple.com)
> > > > ; Laszlo Ersek
> (ler...@redhat.com)
> > > ;
> > > > Gao, Liming ; Zeng, Star
> > > 
> > > > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP,
> PXE,
> > > iSCSI driver in
> > > > MdeModulePkg.
> > > >
> > > > Hi Siyuan,
> > > >
> > > > Have you checked the platforms in
> > > https://github.com/tianocore/edk2-
> > > > platforms to see whether they need to be updated
> > > accordingly or not?
> > > >
> > > > Cc more people.
> > > >
> > > > Thanks,
> > > > Star
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> > > boun...@lists.01.org] On Behalf Of Fu
> > > > Siyuan
> > > > Sent: Tuesday, October 30, 2018 3:33 PM
> > > > To: edk2-devel@lists.01.org
> > > > Subject: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI
> > > driver in
> > > > MdeModulePkg.
> > > >
> > > > This patch series is to delete the Tcp4Dxe,
> > > UefiPxeBcDxe and IScsi4Dxe
> > > > drivers in MdeModulePkg. These drivers will not be
> > > maintained and can&

Re: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI driver in MdeModulePkg.

2018-10-30 Thread Kinney, Michael D

Fu Siyuan,

Please review edk2-platform/master and prepare a patch
for that branch if there are DSC/FDF files that refer
to the network drivers that are being removed. 

We should never break any platforms in edk2-platform/master.
The commits should be performed to the repos in the correct
order to guarantee no build breaks.

Thanks,

Mike

> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, October 30, 2018 1:23 AM
> To: Zeng, Star ; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D ; Leif
> Lindholm ; Andrew Fish
> (af...@apple.com) ; Laszlo Ersek
> (ler...@redhat.com) ; Gao, Liming
> 
> Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in MdeModulePkg.
> 
> Hi, Star
> 
> This patch only covers the platforms in
> https://github.com/tianocore/edk2
> 
> I will modify the edk2 network wiki page for an updated
> sample DSC/FDF section, if this patch could pass review
> w/o objection.
> https://github.com/tianocore/tianocore.github.io/wiki/Ne
> tworkPkg-Getting-Started-Guide
> 
> Let's wait a few days to see if there is any objection
> on deleting these driver first, and I will be happy to
> generate another patch for edk2-platforms then.
> 
> Thanks for your reminder.
> 
> 
> BestRegards
> Fu Siyuan
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Tuesday, October 30, 2018 3:43 PM
> > To: Fu, Siyuan ; edk2-
> de...@lists.01.org
> > Cc: Kinney, Michael D ;
> Leif Lindholm
> > ; Andrew Fish
> (af...@apple.com)
> > ; Laszlo Ersek (ler...@redhat.com)
> ;
> > Gao, Liming ; Zeng, Star
> 
> > Subject: RE: [edk2] [PATCH v1 0/7] Delete TCP, PXE,
> iSCSI driver in
> > MdeModulePkg.
> >
> > Hi Siyuan,
> >
> > Have you checked the platforms in
> https://github.com/tianocore/edk2-
> > platforms to see whether they need to be updated
> accordingly or not?
> >
> > Cc more people.
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Fu
> > Siyuan
> > Sent: Tuesday, October 30, 2018 3:33 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH v1 0/7] Delete TCP, PXE, iSCSI
> driver in
> > MdeModulePkg.
> >
> > This patch series is to delete the Tcp4Dxe,
> UefiPxeBcDxe and IScsi4Dxe
> > drivers in MdeModulePkg. These drivers will not be
> maintained and can't
> > co-work with the dual-stack drivers in NetworkPkg.
> >
> > People should use below NetworkPkg drivers instead:
> >   NetworkPkg/IScsiDxe/IScsiDxe.inf
> >   NetworkPkg/TcpDxe/TcpDxe.inf
> >   NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> > These drivers are actively maintained with more bug
> fixes and new feature
> > support.
> >
> > Patch 1~5 update edk2 platform DSC/FDF files to use
> NetworkPkg drivers.
> > Patch 6 deletes the TCP,PXE,iSCSI driver in
> MdeModulePkg.
> > Patch 7 removes some clarification in NetworkPkg
> drivers since the related
> > driver has been deleted in Patch 6.
> >
> > Fu Siyuan (7):
> >   Nt32Pkg: Replace obsoleted network drivers from NT32
> platform DSC/FDF.
> >   EmulatorPkg: Replace obsoleted network drivers from
> platform DSC/FDF.
> >   OvmfPkg: Replace obsoleted network drivers from
> platform DSC/FDF.
> >   Vlv2TbltDevicePkg: Replace obsoleted drivers from
> platform DSC/FDF.
> >   ArmVirtPkg: Replace obsoleted network drivers from
> platform DSC/FDF.
> >   MdeModulePkg: Delete the TCP/PXE/ISCSI drivers in
> MdeModulePkg.
> >   NetworkPkg: Remove some clarification from
> TCP/PXE/ISCSI driver INF.
> >
> >  .../Network/IScsiDxe/ComponentName.c  |  283
> --
> >  .../Universal/Network/IScsiDxe/IScsiCHAP.c|  430
> ---
> >  .../Universal/Network/IScsiDxe/IScsiConfig.c  | 1264
> ---
> >  .../Universal/Network/IScsiDxe/IScsiDhcp.c|  472
> ---
> >  .../Universal/Network/IScsiDxe/IScsiDriver.c  |  676
> 
> >  .../Network/IScsiDxe/IScsiExtScsiPassThru.c   |  412
> ---
> >  .../Universal/Network/IScsiDxe/IScsiIbft.c|  539
> ---
> >  .../Network/IScsiDxe/IScsiInitiatorName.c |  116
> -
> >  .../Universal/Network/IScsiDxe/IScsiMisc.c|  948
> --
> >  .../Universal/Network/IScsiDxe/IScsiProto.c   | 2799
> ---
> >  .../Universal/Network/IScsiDxe/IScsiTcp4Io.c  |  487
> ---
> > MdeModulePkg/Universal/Network/IScsiDxe/Md5.c |  350 -
> -
> >   .../Universal/Network/Tcp4Dxe/ComponentName.c |  433
> ---
> >  .../Universal/Network/Tcp4Dxe/SockImpl.c  | 1201

Re: [edk2] Another Test Message - please ignore

Chris,

Thanks!  That is working as expected now.

Mike

> -Original Message-
> From: Chris Co [mailto:christopher...@microsoft.com]
> Sent: Monday, October 29, 2018 3:50 PM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Subject: RE: Another Test Message - please ignore
> 
> Testing Reply-All
> 
> Chris
> 
> > -Original Message-
> > From: edk2-devel  On
> Behalf Of Kinney,
> > Michael D
> > Sent: Monday, October 29, 2018 3:44 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Another Test Message - please ignore
> >
> > Start new test message thread.
> >
> > Mike
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> >
> https://na01.safelinks.protection.outlook.com/?url=https
> %3A%2F%2Flists.01.o
> > rg%2Fmailman%2Flistinfo%2Fedk2-
> >
> devel&data=02%7C01%7Cchristopher.co%40microsoft.com%
> 7C3b7c858a6
> >
> e34427ebfd308d63df007f3%7C72f988bf86f141af91ab2d7cd011db
> 47%7C1%7C0
> >
> %7C636764498470253846&sdata=D96MYFbrcqLcaZr72ukFJ6XY
> enR4z50rD
> > hGNopmHgNc%3D&reserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Another Test Message - please ignore

Start new test message thread.

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

Re: [edk2] Test message. Please ignore.

Another test with reply_goes_to_list set to "Poster".

Mike

> -Original Message-
> From: Chris Co [mailto:christopher...@microsoft.com]
> Sent: Monday, October 29, 2018 1:12 PM
> To: Kinney, Michael D ; EDK
> II Development ; Gretzinger,
> Adam R ; Jeremiah Cox
> 
> Cc: Chad Mace ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: RE: Test message. Please ignore.
> 
> Hi Mike,
> 
> This is a Reply-All.
> 
> Chris
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Monday, October 29, 2018 1:11 PM
> > To: EDK II Development ;
> Gretzinger, Adam R
> > ; Jeremiah Cox
> ;
> > Kinney, Michael D 
> > Cc: Chris Co ; Chad Mace
> > ; Sean Brogan
> ;
> > Cetola, Stephano 
> > Subject: RE: Test message. Please ignore.
> >
> > Hi Chris,
> >
> > I am trying a different configuration setting to see
> if the posters reply-to
> > address can be preserved.
> >
> > Please try both a Reply and a Reply-All to this test
> message.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Monday, October 29, 2018 11:32 AM
> > > To: EDK II Development ;
> Gretzinger, Adam R
> > > ; Jeremiah Cox
> ;
> > > Kinney, Michael D 
> > > Cc: Chris Co ; Chad
> Mace
> > > ; Sean Brogan
> ;
> > > Cetola, Stephano 
> > > Subject: RE: Test message. Please ignore.
> > >
> > > Chris,
> > >
> > > Thanks.  That looks like what I expected.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf
> > > > Of Chris Co via edk2- devel
> > > > Sent: Monday, October 29, 2018 11:22 AM
> > > > To: Kinney, Michael D
> ; Gretzinger, Adam
> > > > R ;
> > > edk2-
> > > > de...@lists.01.org; Jeremiah Cox
> > > 
> > > > Cc: Chris Co ; Chad
> Mace
> > > > ; Sean Brogan
> ;
> > > > Cetola, Stephano 
> > > > Subject: Re: [edk2] Test message. Please ignore.
> > > >
> > > > Hi Mike,
> > > >
> > > > Here is a Reply All to the test message.
> > > >
> > > > Chris
> > > >
> > > > > -Original Message-
> > > > > From: Kinney, Michael D
> 
> > > > > Sent: Monday, October 29, 2018 10:31 AM
> > > > > To: Chris Co ;
> > > > Gretzinger, Adam R
> > > > > ; edk2-
> > > > de...@lists.01.org; Kinney, Michael D
> > > > > ; Jeremiah Cox
> > > > 
> > > > > Cc: Sean Brogan ;
> Cetola,
> > > > Stephano
> > > > > ; Chad Mace
> > > > 
> > > > > Subject: RE: Test message. Please ignore.
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > This is a response to this test message.  The
> Reply-
> > > To
> > > > setting has been
> > > > > updated to make sure edk2-devel is always
> present.
> > > > >
> > > > > Please do a Reply All to this test message.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike
> > > > >
> > > > > From: Chris Co
> [mailto:christopher...@microsoft.com]
> > > > > Sent: Friday, October 26, 2018 6:09 PM
> > > > > To: Kinney, Michael D
> ;
> > > > Gretzinger, Adam R
> > > > > ; edk2-
> > > de...@lists.01.org
> > > > > Cc: Sean Brogan ;
> > > Jeremiah
> > > > Cox
> > > > > ; Cetola, Stephano
> > > > ;
> > > > > Chad Mace 
> > > > > Subject: Test message. Please ignore.
> > > > >
> > > > > Test message. Checking for DMARC bounces...
> > > > >
> > > > > Chris
> > > > ___
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https
> %3A%2F%2Flis
> > > > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> > devel&data=02%7C01%7CChris
> > > >
> >
> topher.Co%40microsoft.com%7C868cbd744373450b6b3b08d63dda
> 97d8%7C72
> > f98
> > > >
> >
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636764406403589714
> &sda
> > ta=G
> > > >
> AoQ6V1QtnZJ1DDVKRFy2kvjtPJfWyEM6Pd4KGgzzf4%3D&reserv
> ed=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] NOTICE edk2-devel mailing list configuration changes

Hi Leif,

I can put the reply_goes_to_list option back to "Poster".

In that configuration, a user that has a DMARC policy of
reject will still have their from address munged.

But I noticed that the edk2-devel mailing list is not
present when anyone does a Reply-all to an email with
a munged from address.  That implied to me that everyone
would need to check if the edk2-devel mailing has been
removed from a Reply-all and add it back manually.  This
also seems like a non-ideal configuration option.

However, the behavior I am seeing could be due to some
of my client settings.

So I will put the reply_goes_to_list option back to
"Poster".

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 2:10 PM
> To: Kinney, Michael D 
> Cc: EDK II Development ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> I could hypothesise about which email client you may be
> using :)
> 
> But let me instead mention that the two email clients I
> have (mutt and
> gmail web interface) behave identically - neither adds
> the original
> sender to cc when the list server forces a reply-to
> header.
> 
> Regards,
> 
> Leif
> 
> On Mon, Oct 29, 2018 at 08:49:09PM +, Kinney,
> Michael D wrote:
> > Leif,
> >
> > Very strange.  When I do the same on that email, it
> > shows Paul on the To address line.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > Sent: Monday, October 29, 2018 1:40 PM
> > > To: Kinney, Michael D 
> > > Cc: EDK II Development ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> list
> > > configuration changes
> > >
> > > Hi Mike,
> > >
> > > When I try to "reply-to", the email from Paul A
> Lohr,
> > > sent 10 minutes
> > > after your one below, he does not show up in either
> "to"
> > > or "cc".
> > >
> > > OK, I missed the excitement during the plugfest.
> I'll go
> > > back and see
> > > what I can find there.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> > > Michael D wrote:
> > > > Leif,
> > > >
> > > > I have enabled a different configuration setting
> > > > that should be better.
> > > >
> > > > Please try some emails and let me know if there
> > > > are any impacts.
> > > >
> > > > The reason for these changes is the DMARC related
> > > > issue that occurred on 10-19-2018 that required a
> > > > number of users to be disabled.  The goal of these
> > > > changes is to enable those users to be re-
> activated.
> > > >
> > > > Thanks,
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Leif Lindholm
> > > [mailto:leif.lindh...@linaro.org]
> > > > > Sent: Monday, October 29, 2018 12:54 PM
> > > > > To: EDK II Development 
> > > > > Cc: Kinney, Michael D
> ;
> > > > > Cetola, Stephano 
> > > > > Subject: Re: [edk2] ** NOTICE ** edk2-devel
> mailing
> > > list
> > > > > configuration changes
> > > > >
> > > > > Hi Mike,
> > > > >
> > > > > On Mon, Oct 29, 2018 at 06:42:44PM +,
> Kinney,
> > > > > Michael D wrote:
> > > > > > Some configuration changes have been made to
> > > > > > the edk2-devel mailing list to handle posts
> from
> > > > > > a domain with a DMARC Reject/Quarantine policy
> > > > > > enabled. If this is detected then the from
> address
> > > > > > is now munged.
> > > > > >
> > > > > > One side effect of this setting is that the
> > > > > > behavior of Reply has changed.  Instead of
> being
> > > > > > a reply to the poster of the message, the
> Reply
> > > > > > address is the edk2-devel mailing list.
> > > > >
> > > > > The behaviour looks somewhat broken, since as
> far as
> > > I
> > > > > can tell,
> > > > > replies now longer include the person you're
> > > replying
> > > > > to.
> > > > > (This doesn't happen when replying specifically
> to
> > > > > _you_, because you
> > > > > cc yourself on everything).
> > > > >
> > > > > > If you wish to send a private reply to only
> the
> > > > > > poster of the message, you may have to perform
> > > > > > some manual steps.
> > > > > >
> > > > > > Please let me know if you have any concerns
> about
> > > > > > these changes or if these configuration
> changes
> > > > > > cause any other side effects.
> > > > >
> > > > > Can we make sure the person being replied to is
> at
> > > least
> > > > > on cc?
> > > > > Otherwise, we've just broken the workflow for
> anyone
> > > > > filtering on
> > > > > whether they are on "to" or "cc".
> > > > >
> > > > > Why was this change necessary?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] NOTICE edk2-devel mailing list configuration changes

Leif,

Very strange.  When I do the same on that email, it
shows Paul on the To address line.  

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 1:40 PM
> To: Kinney, Michael D 
> Cc: EDK II Development ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> When I try to "reply-to", the email from Paul A Lohr,
> sent 10 minutes
> after your one below, he does not show up in either "to"
> or "cc".
> 
> OK, I missed the excitement during the plugfest. I'll go
> back and see
> what I can find there.
> 
> Regards,
> 
> Leif
> 
> On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> Michael D wrote:
> > Leif,
> >
> > I have enabled a different configuration setting
> > that should be better.
> >
> > Please try some emails and let me know if there
> > are any impacts.
> >
> > The reason for these changes is the DMARC related
> > issue that occurred on 10-19-2018 that required a
> > number of users to be disabled.  The goal of these
> > changes is to enable those users to be re-activated.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > Sent: Monday, October 29, 2018 12:54 PM
> > > To: EDK II Development 
> > > Cc: Kinney, Michael D ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> list
> > > configuration changes
> > >
> > > Hi Mike,
> > >
> > > On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> > > Michael D wrote:
> > > > Some configuration changes have been made to
> > > > the edk2-devel mailing list to handle posts from
> > > > a domain with a DMARC Reject/Quarantine policy
> > > > enabled. If this is detected then the from address
> > > > is now munged.
> > > >
> > > > One side effect of this setting is that the
> > > > behavior of Reply has changed.  Instead of being
> > > > a reply to the poster of the message, the Reply
> > > > address is the edk2-devel mailing list.
> > >
> > > The behaviour looks somewhat broken, since as far as
> I
> > > can tell,
> > > replies now longer include the person you're
> replying
> > > to.
> > > (This doesn't happen when replying specifically to
> > > _you_, because you
> > > cc yourself on everything).
> > >
> > > > If you wish to send a private reply to only the
> > > > poster of the message, you may have to perform
> > > > some manual steps.
> > > >
> > > > Please let me know if you have any concerns about
> > > > these changes or if these configuration changes
> > > > cause any other side effects.
> > >
> > > Can we make sure the person being replied to is at
> least
> > > on cc?
> > > Otherwise, we've just broken the workflow for anyone
> > > filtering on
> > > whether they are on "to" or "cc".
> > >
> > > Why was this change necessary?
> > >
> > > Regards,
> > >
> > > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] NOTICE edk2-devel mailing list configuration changes

Leif,

I have enabled a different configuration setting 
that should be better.

Please try some emails and let me know if there
are any impacts.

The reason for these changes is the DMARC related
issue that occurred on 10-19-2018 that required a
number of users to be disabled.  The goal of these
changes is to enable those users to be re-activated.

Thanks,

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 12:54 PM
> To: EDK II Development 
> Cc: Kinney, Michael D ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> Michael D wrote:
> > Some configuration changes have been made to
> > the edk2-devel mailing list to handle posts from
> > a domain with a DMARC Reject/Quarantine policy
> > enabled. If this is detected then the from address
> > is now munged.
> >
> > One side effect of this setting is that the
> > behavior of Reply has changed.  Instead of being
> > a reply to the poster of the message, the Reply
> > address is the edk2-devel mailing list.
> 
> The behaviour looks somewhat broken, since as far as I
> can tell,
> replies now longer include the person you're replying
> to.
> (This doesn't happen when replying specifically to
> _you_, because you
> cc yourself on everything).
> 
> > If you wish to send a private reply to only the
> > poster of the message, you may have to perform
> > some manual steps.
> >
> > Please let me know if you have any concerns about
> > these changes or if these configuration changes
> > cause any other side effects.
> 
> Can we make sure the person being replied to is at least
> on cc?
> Otherwise, we've just broken the workflow for anyone
> filtering on
> whether they are on "to" or "cc".
> 
> Why was this change necessary?
> 
> Regards,
> 
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Test message. Please ignore.

Hi Chris,

I am trying a different configuration setting to see
if the posters reply-to address can be preserved.

Please try both a Reply and a Reply-All to
this test message.

Thanks,

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Monday, October 29, 2018 11:32 AM
> To: EDK II Development ;
> Gretzinger, Adam R ;
> Jeremiah Cox ; Kinney, Michael D
> 
> Cc: Chris Co ; Chad Mace
> ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: RE: Test message. Please ignore.
> 
> Chris,
> 
> Thanks.  That looks like what I expected.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of Chris Co via edk2-
> > devel
> > Sent: Monday, October 29, 2018 11:22 AM
> > To: Kinney, Michael D ;
> > Gretzinger, Adam R ;
> edk2-
> > de...@lists.01.org; Jeremiah Cox
> 
> > Cc: Chris Co ; Chad Mace
> > ; Sean Brogan
> > ; Cetola, Stephano
> > 
> > Subject: Re: [edk2] Test message. Please ignore.
> >
> > Hi Mike,
> >
> > Here is a Reply All to the test message.
> >
> > Chris
> >
> > > -----Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Monday, October 29, 2018 10:31 AM
> > > To: Chris Co ;
> > Gretzinger, Adam R
> > > ; edk2-
> > de...@lists.01.org; Kinney, Michael D
> > > ; Jeremiah Cox
> > 
> > > Cc: Sean Brogan ; Cetola,
> > Stephano
> > > ; Chad Mace
> > 
> > > Subject: RE: Test message. Please ignore.
> > >
> > > Hi Chris,
> > >
> > > This is a response to this test message.  The Reply-
> To
> > setting has been
> > > updated to make sure edk2-devel is always present.
> > >
> > > Please do a Reply All to this test message.
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > From: Chris Co [mailto:christopher...@microsoft.com]
> > > Sent: Friday, October 26, 2018 6:09 PM
> > > To: Kinney, Michael D ;
> > Gretzinger, Adam R
> > > ; edk2-
> de...@lists.01.org
> > > Cc: Sean Brogan ;
> Jeremiah
> > Cox
> > > ; Cetola, Stephano
> > ;
> > > Chad Mace 
> > > Subject: Test message. Please ignore.
> > >
> > > Test message. Checking for DMARC bounces...
> > >
> > > Chris
> > ___
> > 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] NOTICE edk2-devel mailing list configuration changes