date:20140814

Re: [edk2] AARCH64 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c question. TCR adjusted but not written.

2014-08-14 Thread Kirkendall, Garrett

Line 615 stores TCR initially.  Lines 663-672 modify the TCR variable, but then 
there is no ArmSetTCR (TCR) call after lines 663-672.

Garrett Kirkendall   [Description: Description: Description: purple]
SMTS Firmware Engineer | AMD Technology & Engineering
7171 Southwest Parkway, Austin, TX 78735 USA
[Description: Description: Description: image004]   
facebook  |  amd.com

From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Wednesday, August 13, 2014 5:17 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] AARCH64 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c 
question. TCR adjusted but not written.

Am I missing something or the line 615 is doing what you were expected to see: 
https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c#L615

Thanks,
Olivier

From: Kirkendall, Garrett [mailto:garrett.kirkend...@amd.com]
Sent: 12 August 2014 21:54
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] AARCH64 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c question. 
TCR adjusted but not written.

In ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c:ArmConfigureMmu()  there is a 
section of code that puzzles me.



  // Translate the Memory Attributes into Translation Table Register Attributes
  if ((TranslationTableAttribute == 
ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED) ||
  (TranslationTableAttribute == 
ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_UNCACHED_UNBUFFERED)) {
TCR |= TCR_SH_NON_SHAREABLE | TCR_RGN_OUTER_NON_CACHEABLE | 
TCR_RGN_INNER_NON_CACHEABLE;
  } else if ((TranslationTableAttribute == 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK) ||
  (TranslationTableAttribute == 
ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_BACK)) {
TCR |= TCR_SH_INNER_SHAREABLE | TCR_RGN_OUTER_WRITE_BACK_ALLOC | 
TCR_RGN_INNER_WRITE_BACK_ALLOC;
  } else if ((TranslationTableAttribute == 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_THROUGH) ||
  (TranslationTableAttribute == 
ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_THROUGH)) {
TCR |= TCR_SH_NON_SHAREABLE | TCR_RGN_OUTER_WRITE_THROUGH | 
TCR_RGN_INNER_WRITE_THROUGH;
  } else {
// If we failed to find a mapping that contains the root translation table 
then it probably means the translation table
// is not mapped in the given memory map.
ASSERT (0);
Status = RETURN_UNSUPPORTED;
goto FREE_TRANSLATION_TABLE;
  }



The code will either adjust the TCR variable with the shareability bits [13:8] 
or assert.  The problem is that I don't see where the code following this does 
anything with that adjusted value.  Maybe I'm missing it, but I just don't see 
it.  Is it actually supposed to be written back into the TCR register, or is 
just intended to get to the return of the unsupported?

Garrett Kirkendall   [Description: Description: Description: purple]
SMTS Firmware Engineer | AMD Technology & Engineering
7171 Southwest Parkway, Austin, TX 78735 USA
[Description: Description: Description: image004]   
facebook  |  amd.com

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

2014-08-14 Thread El-Haj-Mahmoud, Samer

It is not a problem for this patch (since the new UNI files are in the ZIP).

I agree that with UTF16 file types, the patch file itself is not very readable. 
But at least I can take a patch file (from this email list for instance), and 
apply it using SVN to my tree, and it will automatically apply the string 
changes to UNI files. 

I can also generate patch files from my tree that include UNI file changes and 
send them to this list to review

This is definitely better than binary files that cannot be dealt with AT ALL 
using SVN diff

In order to achieve this, we need to change ALL UNI files in EDK2 from:

svn:mime-type = application/octect-stream

To:

svn:mime-type = text/plain;encoding=UTF-16LE

Can someone please help with this change?




-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Wednesday, August 13, 2014 9:36 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Yes. This is a possible solution. But, svn generated patch for UTF16 file is 
not good readability. 

This patch adds new UNI files. You can see them from ZIP files. 

Thanks
Liming
-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 10:26 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Can we change the file encoding type svn property for uni files to make them 
utf16 instead of binary stream? This way we can actually include uni files in 
patches and see what changed.









-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Wednesday, 13 Aug 2014, 9:17PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
MdePkg. The patch is a little big. For new added UNI file, I zip them together.

  The second patch for below item 7 will be sent later

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:


1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a module to go along with the 
localized Abstract and Description from the MODULE_UNI_FILE.

4)  PCD information in DEC file comment blocks are either incomplete or 
incorrect.  This includes detailed description, @Prompt, @ValidRange, 
@ValidList, @Expression, and [Error.] validation error messages

5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file that 
contains the localized Abstract and Description of a package and localized 
strings associated with PCDs.

a.   Addresses an information gap between DEC files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
PACKAGE_UNI_FILE and associated UNI file during UDP creation that performs the 
DEC -> XML conversion.

c.   There

Re: [edk2] EDK II UNI Unicode File Specification Update

2014-08-14 Thread Carsey, Jaben

Tim,

Can you elaborate on your rewrite?  What needed to be done...

What do you think of having a shared "EBNF Document" that stores all the shared 
EBNF items?

-Jaben

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, August 12, 2014 3:46 PM
To: Hauch, Larry
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EDK II UNI Unicode File Specification Update

Larry -

As a tools developer and a QA team, we (Insyde) can tell you that the existing 
EBNF is hard to manage. We have rewritten it to be readable by tools and by 
humans. When you start having conditions in the grammar (see the INF spec, 
section 3.2), you know you've definitely crossed the line.

I think the core items, like Expressions and PCDs can be defined in the EDK2 
Build Specification. I think that the Expression syntax could be there also, in 
an appendix. The PCD syntax is not shared, so we'd parcel that out to the 
relevant .fdf/.inf/.dsc/.dec specifications but refer back to the Build spec 
for definition for common terms.

Tim



From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Tuesday, August 12, 2014 3:22 PM
To: Tim Lewis
Cc: edk2-devel@lists.sourceforge.net
Subject: RE: EDK II UNI Unicode File Specification Update

Hi Tim,

I agree that the EBNF is getting cumbersome and we should really look at 
reducing this.
I need to work with my internal development and validation teams (who keep 
asking for more EBNF) to figure out a better method.
Our validation team has expressed the desire to have everything in one place so 
that they can only look at the EBNF and not have to look at anything else.

I agree that we would be better served if we could centralize some of the 
documentation so that we update the PCD document to contain all of the relevant 
information to a PCD document and then have the other specs refer to 
appropriate chapters in the other documents. (I was attempting to do that with 
the EDK II Meta-Data Expression Spec document which I hope to publish shortly - 
newer versions of the EDK II INF/DEC/DSC/FDF specs will have the expression 
EBNF removed and a reference to the Expression Spec.).

Cheers,
Larry

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 11, 2014 3:03 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EDK II UNI Unicode File Specification Update

It is about using EBNF for specific string-token name patterns. In cases where 
the basic pattern is X = Y (as described in the overview portions of the same 
spec) the grammar is much simpler and easier to ready if it says  
Identifier  "="  Value. The question: "which X is valid" and "which Y 
is valid for which X" is easily taken care of in the sections.

Again, this is speaking as another company has worked valiantly to create tools 
compatible with the EDK2 toolset, and to teach the grammar to new engineers.

On the other topic, we would be willing to contribute changes on specific 
documents, such as the Build Specification. Do you think it is better to 
describe such topics as PCDs where they are defined (.DEC spec) or as a general 
build concept (Build spec)?

Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Monday, August 11, 2014 12:27 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EDK II UNI Unicode File Specification Update

Hi Tim,

Thanks for the feedback on this topic.  We have had similar discussions over 
the last couple of days for where this content should be listed.

These updates do reserve specific string token name patterns.  Whenever we have 
used specific keywords in syntax in the other EDK II related documents, the 
keywords have been added as part of the grammar using an EBNF description.  
This provides clear direction for tool development and tool validation.  Is 
your feedback about the location of this content, or the use of EBNF to for the 
string token name patterns?

Thanks,

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 11, 2014 11:23 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EDK II UNI Unicode File Specification Update

Larry -

I would recommend that these sort of changes not be added to the grammar, but 
rather in the specification text related to the [UserDefined] or DEFINES 
section of the .inf or .dec specification.

Tim

From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Monday, August 11, 2014 10:56 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] EDK II UNI Unicode File Specification Update

Hi Folks,
The following is content we would like to add to the EDK II UNI Unicode File 
Specification to support the changes  we have proposed for supporting 
localization in EDK II that can be consumed by the packaging to when creating a 
UEFI PI Distribution Package (and when installing a UEF

Re: [edk2] [PATCH]ShellPkg: Fix code style and build failure

2014-08-14 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

From: Qiu, Shumin
Sent: Tuesday, August 12, 2014 6:29 PM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH]ShellPkg: Fix code style and build failure
Importance: High

Hi Jaben,
Can you help to review this patch.

ShellPkg: Fix code style and build failure
1. File has invalid Non-ACSII char.
2. No initialization of a variable as part of its declaration.
3. Close braces for function body must be in the first column.
4. Inconsistent parameter in  function comments.
5. The first line of text in a comment block should be a brief description of 
the element being documented and the brief description must end with a period.
6. For function 'ShellCommandDynamicCommandExists' in UefiShellCommandLib.c 
return type is conversed from 'int' to 'boolean'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin mailto:shumin@intel.com>>

Thanks
Shumin

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] EDK II UNI Unicode File Specification Update

2014-08-14 Thread Tim Lewis

Jaben -

There were three pieces of this (which were all geared towards making the 
grammar easier to read by humans without losing specified behavior)


1)  Removed some items out of the grammar. This included all conditionals. 
In many case the generic "identifier" was substituted and the valid values were 
listed (with a description!) in a table along with specific values in the 
individual grammar sections.  There are other items, like file names with 
specific file extensions in the grammar. This greatly reduced the number of 
terminals.

2)  Broke down some sections further. This allowed the grammar to be 
digested more easily.  (see the FV section in the FDF spec (3.6) where each of 
the statements became a sub-section). This is similar to what the VFR 
specification tried to do. Since in #1 we'd moved many keywords out, this is 
where we'd put the tables to list valid  identifier values and a description, 
showing what it means or which opcode/specification data structure it is tied 
to.

3)  Made the formatting easier to read. I know that the current format is 
related to the one fed into the tools, but with a little work it in formatting 
helps. There were three major pieces of this:

a.   first, replace  with X (italics)

b.  second, removal of the  terminal.  Moved the whitespace rules into 
the introductory information where comments are described. This allowed some 
other rules to be simplified, since "X"  "Y" could become "="

c.   Replace simple terminals with their literals. EX: Why  
when you can use "|"? I replaced CRLF with 
Hope this helps,

Tim


From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Thursday, August 14, 2014 8:39 AM
To: edk2-devel@lists.sourceforge.net; Hauch, Larry
Subject: Re: [edk2] EDK II UNI Unicode File Specification Update

Tim,

Can you elaborate on your rewrite?  What needed to be done...

What do you think of having a shared "EBNF Document" that stores all the shared 
EBNF items?

-Jaben

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, August 12, 2014 3:46 PM
To: Hauch, Larry
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EDK II UNI Unicode File Specification Update

Larry -

As a tools developer and a QA team, we (Insyde) can tell you that the existing 
EBNF is hard to manage. We have rewritten it to be readable by tools and by 
humans. When you start having conditions in the grammar (see the INF spec, 
section 3.2), you know you've definitely crossed the line.

I think the core items, like Expressions and PCDs can be defined in the EDK2 
Build Specification. I think that the Expression syntax could be there also, in 
an appendix. The PCD syntax is not shared, so we'd parcel that out to the 
relevant .fdf/.inf/.dsc/.dec specifications but refer back to the Build spec 
for definition for common terms.

Tim



From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Tuesday, August 12, 2014 3:22 PM
To: Tim Lewis
Cc: edk2-devel@lists.sourceforge.net
Subject: RE: EDK II UNI Unicode File Specification Update

Hi Tim,

I agree that the EBNF is getting cumbersome and we should really look at 
reducing this.
I need to work with my internal development and validation teams (who keep 
asking for more EBNF) to figure out a better method.
Our validation team has expressed the desire to have everything in one place so 
that they can only look at the EBNF and not have to look at anything else.

I agree that we would be better served if we could centralize some of the 
documentation so that we update the PCD document to contain all of the relevant 
information to a PCD document and then have the other specs refer to 
appropriate chapters in the other documents. (I was attempting to do that with 
the EDK II Meta-Data Expression Spec document which I hope to publish shortly - 
newer versions of the EDK II INF/DEC/DSC/FDF specs will have the expression 
EBNF removed and a reference to the Expression Spec.).

Cheers,
Larry

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 11, 2014 3:03 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EDK II UNI Unicode File Specification Update

It is about using EBNF for specific string-token name patterns. In cases where 
the basic pattern is X = Y (as described in the overview portions of the same 
spec) the grammar is much simpler and easier to ready if it says  
Identifier  "="  Value. The question: "which X is valid" and "which Y 
is valid for which X" is easily taken care of in the sections.

Again, this is speaking as another company has worked valiantly to create tools 
compatible with the EDK2 toolset, and to teach the grammar to new engineers.

On the other topic, we would be willing to contribute changes on specific 
documents, such as the Build Specification. Do you think it is better to 
describe such topics as PCDs where they are

Re: [edk2] [PATCH] AppPkg: Enable ARM and AArch64 support

2014-08-14 Thread Olivier Martin

Any feedback on this one?

 

From: Olivier Martin [mailto:olivier.mar...@arm.com] 
Sent: 01 August 2014 20:03
To: 'Daryl McDaniel'
Cc: edk2-devel@lists.sourceforge.net; Harry Liebel
Subject: [PATCH] AppPkg: Enable ARM and AArch64 support

 

Dear AppPkg maintainer,

Please find the attached patch that enables ARM and AARCH64 architecture for
the AppPkg package.

 

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Harry Liebel 

Reviewed-By: Olivier Martin 

 

Regards,

Olivier
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] StdLib/LibC: Fix ARM symbol problems

2014-08-14 Thread Olivier Martin

Any feedback on this one?

 

From: Olivier Martin [mailto:olivier.mar...@arm.com] 
Sent: 01 August 2014 20:01
To: 'Carsey, Jaben'
Cc: edk2-devel@lists.sourceforge.net; Harry Liebel
Subject: [PATCH] StdLib/LibC: Fix ARM symbol problems

 

Dear StdLib maintainer,

 

Please find the attached patch that:

- Disable 'memcpy' symbol for ARM in LibC. It is already provided by the
ARM compiler intrinsics library.

- Add missing 'strtold' symbol. Use the same fallback as IPF for now.

 

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Harry Liebel 

Reviewed-By: Olivier Martin 

 

Regards,

Olivier
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] StdLibPrivateInternalFiles: Add AArch64 support

2014-08-14 Thread Olivier Martin

Any feedback on this one?

 

From: Olivier Martin [mailto:olivier.mar...@arm.com] 
Sent: 01 August 2014 20:06
To: 'Carsey, Jaben'
Cc: edk2-devel@lists.sourceforge.net; Harry Liebel
Subject: [PATCH] StdLibPrivateInternalFiles: Add AArch64 support

 

Dear StdLibPrivateInternalFiles maintainer,

Please find the attached path that adds AArch64 support. ARM headers are
re-used for AArch64.

 

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Harry Liebel 

Reviewed-By: Olivier Martin 

 

Regards,

Olivier
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch 1] Change svn:mime-type property on Unicode files

2014-08-14 Thread Hauch, Larry

Hi Folks,
I agree that we should modify the svn property although it still does not fix 
the issue with code reviews for the files.
I have attached the proposed patch; please review and let me know if there are 
any issues.

Change svn:mime-type property on all Unicode files (extension .uni) in edk2

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lhauch 

Cheers,
Larry


-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 8:06 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

It is not a problem for this patch (since the new UNI files are in the ZIP).

I agree that with UTF16 file types, the patch file itself is not very readable. 
But at least I can take a patch file (from this email list for instance), and 
apply it using SVN to my tree, and it will automatically apply the string 
changes to UNI files. 

I can also generate patch files from my tree that include UNI file changes and 
send them to this list to review

This is definitely better than binary files that cannot be dealt with AT ALL 
using SVN diff

In order to achieve this, we need to change ALL UNI files in EDK2 from:

svn:mime-type = application/octect-stream

To:

svn:mime-type = text/plain;encoding=UTF-16LE

Can someone please help with this change?




-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Wednesday, August 13, 2014 9:36 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Yes. This is a possible solution. But, svn generated patch for UTF16 file is 
not good readability. 

This patch adds new UNI files. You can see them from ZIP files. 

Thanks
Liming
-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 10:26 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Can we change the file encoding type svn property for uni files to make them 
utf16 instead of binary stream? This way we can actually include uni files in 
patches and see what changed.









-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Wednesday, 13 Aug 2014, 9:17PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
MdePkg. The patch is a little big. For new added UNI file, I zip them together.

  The second patch for below item 7 will be sent later

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:


1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a module to go along with the 
localized Abstract and Description from the MODULE_UNI_FILE.

4)  PCD information in DEC file comment blocks are either

[edk2] [Patch][BaseTools] Fix --version in Rsa2048Sha256 tools

2014-08-14 Thread Kinney, Michael D

Larry,

Can you please review this patch that fixes the behavior of the -version flag 
in the Rsa2048Sha256 tools and updates logic for showing program name, version, 
usage, and copyright information to match other BaseTools.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

Thanks,

Mike


Rsa2048Sha256SignAddVersion.patch
Description: Rsa2048Sha256SignAddVersion.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

2014-08-14 Thread Olivier Martin

Any feedback on this one?

Thanks,
Olivier

> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: 24 March 2014 20:23
> To: feng.t...@intel.com
> Cc: Brendan Jackman; edk2-devel@lists.sourceforge.net
> Subject: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to
> MdeModulePkg
> 
> From: Brendan Jackman 
> 
> This library is useful to other modules than the shell - for example
> filesystem drivers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brendan Jackman 
> Reviewed-by: Olivier Martin 
> ---
>  AppPkg/AppPkg.dsc|   2 +-
>  EmulatorPkg/EmulatorPkg.dsc  |   2 +-
>  MdeModulePkg/Include/Library/PathLib.h   |  56 +++
>  MdeModulePkg/Library/BasePathLib/BasePathLib.c   | 123
> +++
>  MdeModulePkg/Library/BasePathLib/BasePathLib.inf |  38 +++
>  OvmfPkg/OvmfPkgIa32.dsc  |   2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   2 +-
>  OvmfPkg/OvmfPkgX64.dsc   |   2 +-
>  ShellPkg/Include/Library/PathLib.h   |  56 ---
>  ShellPkg/Library/BasePathLib/BasePathLib.c   | 123 ---
> 
>  ShellPkg/Library/BasePathLib/BasePathLib.inf |  38 ---
>  ShellPkg/ShellPkg.dsc|   2 +-
>  StdLib/StdLib.dsc|   2 +-
>  StdLib/StdLib.inc|   2 +-
>  14 files changed, 225 insertions(+), 225 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Library/PathLib.h
>  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.c
>  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.inf
>  delete mode 100644 ShellPkg/Include/Library/PathLib.h
>  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.c
>  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.inf
> 
> diff --git a/AppPkg/AppPkg.dsc b/AppPkg/AppPkg.dsc
> index d0aac2c..491332a 100644
> --- a/AppPkg/AppPkg.dsc
> +++ b/AppPkg/AppPkg.dsc
> @@ -82,7 +82,7 @@
>ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> 
> FileHandleLib|ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
> -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> 
> 
> CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMai
> ntenanceLib.inf
> 
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> index f1cb780..fb580d6 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -391,7 +391,7 @@
>ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
>  #
> MemoryAllocationLib|EmulatorPkg/Library/GuardUefiMemoryAllocationLib/Gu
> ardUefiMemoryAllocationLib.inf
>  #
> SafeBlockIoLib|ShellPkg/Library/SafeBlockIoLib/SafeBlockIoLib.inf
>  #
> SafeOpenProtocolLib|ShellPkg/Library/SafeOpenProtocolLib/SafeOpenProtoc
> olLib.inf
> diff --git a/MdeModulePkg/Include/Library/PathLib.h
> b/MdeModulePkg/Include/Library/PathLib.h
> new file mode 100644
> index 000..ee47352
> --- /dev/null
> +++ b/MdeModulePkg/Include/Library/PathLib.h
> @@ -0,0 +1,56 @@
> +/** @file
> +  Provides interface to path manipulation functions.
> +
> +  Copyright (c) 2011, Intel Corporation. All rights reserved.
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of
> the BSD License
> +  which accompanies this distribution.  The full text of the license
> may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +**/
> +
> +#ifndef _PATH_LIB_
> +#define _PATH_LIB_
> +
> +#include 
> +#include 
> +
> +/**
> +  Removes the last directory or file entry in a path by changing the
> last
> +  L'\' to a CHAR_NULL.
> +
> +  @param[in, out] PathThe pointer to the path to modify.
> +
> +  @retval FALSE Nothing was found to remove.
> +  @retval TRUE  A directory or file was removed.
> +**/
> +BOOLEAN
> +EFIAPI
> +PathRemoveLastItem(
> +  IN OUT CHAR16 *Path
> +  );
> +
> +/**
> +  Function to clean up paths.
> +
> +  - Single periods in the path are removed.
> +  - Double periods in the path are removed along with a single parent
> directory.
> +  - Forward slashes L'/' are converted to backward slashes L'\'.
> +
> +  This will be done inline and the existing buffer may be larger than
> required
> +  upon completion.
> +
> +  @param[in] Path   The pointer to

Re: [edk2] [Patch][BaseTools] Fix --version in Rsa2048Sha256 tools

2014-08-14 Thread Hauch, Larry

Hi Mike,
Looks Good.

Reviewed-by: lhauch 

Cheers,
Larry

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 14, 2014 11:59 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch][BaseTools] Fix --version in Rsa2048Sha256 tools

Larry,

Can you please review this patch that fixes the behavior of the -version flag 
in the Rsa2048Sha256 tools and updates logic for showing program name, version, 
usage, and copyright information to match other BaseTools.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

Thanks,

Mike
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch 1] Change svn:mime-type property on Unicode files

2014-08-14 Thread El-Haj-Mahmoud, Samer

Ship it!

Thanks,
--Samer

-Original Message-
From: Hauch, Larry [mailto:larry.ha...@intel.com] 
Sent: Thursday, August 14, 2014 1:57 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch 1] Change svn:mime-type property on Unicode files

Hi Folks,
I agree that we should modify the svn property although it still does not fix 
the issue with code reviews for the files.
I have attached the proposed patch; please review and let me know if there are 
any issues.

Change svn:mime-type property on all Unicode files (extension .uni) in edk2

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lhauch 

Cheers,
Larry

-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 8:06 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

It is not a problem for this patch (since the new UNI files are in the ZIP).

I agree that with UTF16 file types, the patch file itself is not very readable. 
But at least I can take a patch file (from this email list for instance), and 
apply it using SVN to my tree, and it will automatically apply the string 
changes to UNI files. 

I can also generate patch files from my tree that include UNI file changes and 
send them to this list to review

This is definitely better than binary files that cannot be dealt with AT ALL 
using SVN diff

In order to achieve this, we need to change ALL UNI files in EDK2 from:

svn:mime-type = application/octect-stream

To:

svn:mime-type = text/plain;encoding=UTF-16LE

Can someone please help with this change?

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Wednesday, August 13, 2014 9:36 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Yes. This is a possible solution. But, svn generated patch for UTF16 file is 
not good readability. 

This patch adds new UNI files. You can see them from ZIP files. 

Thanks
Liming
-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 10:26 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Can we change the file encoding type svn property for uni files to make them 
utf16 instead of binary stream? This way we can actually include uni files in 
patches and see what changed.

-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Wednesday, 13 Aug 2014, 9:17PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
MdePkg. The patch is a little big. For new added UNI file, I zip them together.

  The second patch for below item 7 will be sent later

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:

1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [User

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

2014-08-14 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

I didn't notice this email originally. I think that this looks like a good 
change.  What other feedback are you hoping for?

-Jaben


> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: Thursday, August 14, 2014 12:06 PM
> To: edk2-devel@lists.sourceforge.net; Tian, Feng
> Cc: Brendan Jackman
> Subject: Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to
> MdeModulePkg
> 
> Any feedback on this one?
> 
> Thanks,
> Olivier
> 
> > -Original Message-
> > From: Olivier Martin [mailto:olivier.mar...@arm.com]
> > Sent: 24 March 2014 20:23
> > To: feng.t...@intel.com
> > Cc: Brendan Jackman; edk2-devel@lists.sourceforge.net
> > Subject: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to
> > MdeModulePkg
> >
> > From: Brendan Jackman 
> >
> > This library is useful to other modules than the shell - for example
> > filesystem drivers.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Brendan Jackman 
> > Reviewed-by: Olivier Martin 
> > ---
> >  AppPkg/AppPkg.dsc|   2 +-
> >  EmulatorPkg/EmulatorPkg.dsc  |   2 +-
> >  MdeModulePkg/Include/Library/PathLib.h   |  56 +++
> >  MdeModulePkg/Library/BasePathLib/BasePathLib.c   | 123
> > +++
> >  MdeModulePkg/Library/BasePathLib/BasePathLib.inf |  38 +++
> >  OvmfPkg/OvmfPkgIa32.dsc  |   2 +-
> >  OvmfPkg/OvmfPkgIa32X64.dsc   |   2 +-
> >  OvmfPkg/OvmfPkgX64.dsc   |   2 +-
> >  ShellPkg/Include/Library/PathLib.h   |  56 ---
> >  ShellPkg/Library/BasePathLib/BasePathLib.c   | 123 ---
> > 
> >  ShellPkg/Library/BasePathLib/BasePathLib.inf |  38 ---
> >  ShellPkg/ShellPkg.dsc|   2 +-
> >  StdLib/StdLib.dsc|   2 +-
> >  StdLib/StdLib.inc|   2 +-
> >  14 files changed, 225 insertions(+), 225 deletions(-)  create mode
> > 100644 MdeModulePkg/Include/Library/PathLib.h
> >  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.c
> >  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> >  delete mode 100644 ShellPkg/Include/Library/PathLib.h
> >  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.c
> >  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.inf
> >
> > diff --git a/AppPkg/AppPkg.dsc b/AppPkg/AppPkg.dsc index
> > d0aac2c..491332a 100644
> > --- a/AppPkg/AppPkg.dsc
> > +++ b/AppPkg/AppPkg.dsc
> > @@ -82,7 +82,7 @@
> >ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >
> > FileHandleLib|ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> >SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
> > -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> > +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> >
> >
> >
> CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCac
> heMa
> > CacheMaintenanceLib|i
> > ntenanceLib.inf
> >
> > diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> > index f1cb780..fb580d6 100644
> > --- a/EmulatorPkg/EmulatorPkg.dsc
> > +++ b/EmulatorPkg/EmulatorPkg.dsc
> > @@ -391,7 +391,7 @@
> >ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
> >PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> > -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> > +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> >  #
> >
> MemoryAllocationLib|EmulatorPkg/Library/GuardUefiMemoryAllocationLib/
> G
> > MemoryAllocationLib|u
> > ardUefiMemoryAllocationLib.inf
> >  #
> > SafeBlockIoLib|ShellPkg/Library/SafeBlockIoLib/SafeBlockIoLib.inf
> >  #
> >
> SafeOpenProtocolLib|ShellPkg/Library/SafeOpenProtocolLib/SafeOpenProto
> > SafeOpenProtocolLib|c
> > olLib.inf
> > diff --git a/MdeModulePkg/Include/Library/PathLib.h
> > b/MdeModulePkg/Include/Library/PathLib.h
> > new file mode 100644
> > index 000..ee47352
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Library/PathLib.h
> > @@ -0,0 +1,56 @@
> > +/** @file
> > +  Provides interface to path manipulation functions.
> > +
> > +  Copyright (c) 2011, Intel Corporation. All rights reserved.
> > + This program and the accompanying materials  are licensed and made
> > + available under the terms and conditions of
> > the BSD License
> > +  which accompanies this distribution.  The full text of the license
> > may be found at
> > +  http://opensource.org/licenses/bsd-license.php.
> > +
> > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS
> > + OR
> > IMPLIED.
> > +**/
> > +
> > +#ifndef _PATH_LIB_
> > +#define _PATH_LIB_
> > +
> > +#include 
> > +#include 
> > +
> > +/**
> > +  Removes t

Re: [edk2] ShellPkg: Fix EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL_GUID to match UEFI Shell 2.1 spec

2014-08-14 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

From: Phillips, Chris J (Plano, TX) [mailto:chr...@hp.com]
Sent: Thursday, August 14, 2014 1:35 PM
To: Carsey, Jaben; edk2-devel@lists.sourceforge.net
Subject: ShellPkg: Fix EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL_GUID to match UEFI 
Shell 2.1 spec
Importance: High


Please review the attached patch.



This fixes the recently added dynamic command protocol to use the GUID defined 
in the UEFI Shell 2.1 spec.



Thanks,

Chris







ShellPkg: Fix EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL_GUID to match UEFI Shell 2.1 
spec



Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Chris Phillips mailto:chr...@hp.com>>
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] ShellPkg: Fix EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL_GUID to match UEFI Shell 2.1 spec

2014-08-14 Thread Phillips, Chris J (Plano, TX)

Please review the attached patch.



This fixes the recently added dynamic command protocol to use the GUID defined 
in the UEFI Shell 2.1 spec.



Thanks,

Chris







ShellPkg: Fix EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL_GUID to match UEFI Shell 2.1 
spec



Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Chris Phillips 


DynamicCommandGuidFix.patch
Description: DynamicCommandGuidFix.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 3/6] OvmfPkg: enable SATA controller

2014-08-14 Thread reza . jelveh

From: Reza Jelveh 

Removed:
- IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
(provides gEfiDiskInfoProtocolGuid, gEfiBlockIoProtocolGuid)
- PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
(provides gEfiIdeControllerInitProtocolGuid)

Added:
- MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
(provides gEfiDiskInfoProtocolGuid, gEfiBlockIoProtocolGuid,

\--> MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
(provides gEfiAtaPassThruProtocolGuid,
 gEfiExtScsiPassThruProtocolGuid)
 gEfiBlockIo2ProtocolGuid, gEfiStorageSecurityCommandProtocolGuid)

\--> PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
(provides gEfiIdeControllerInitProtocolGuid)

AtaBusDxe enumerates all ports. AtaAtapiPassthru then enumerates the ATA
devices in IDE and AHCI mode seperately on those ports. It then notifies
the SataController.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 OvmfPkg/OvmfPkgIa32.dsc| 5 +++--
 OvmfPkg/OvmfPkgIa32.fdf| 5 +++--
 OvmfPkg/OvmfPkgIa32X64.dsc | 5 +++--
 OvmfPkg/OvmfPkgIa32X64.fdf | 5 +++--
 OvmfPkg/OvmfPkgX64.dsc | 5 +++--
 OvmfPkg/OvmfPkgX64.fdf | 5 +++--
 6 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f7064b7..9049455 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -452,8 +452,9 @@
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
-  PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
+  PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 243cff3..ce9e642 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -250,8 +250,9 @@ INF  
MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
-INF  PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
+INF  PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
 INF  MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
 INF  MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 26d1132..67c520a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -459,8 +459,9 @@
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
-  PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
+  PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 67c5f9c..e2198e1 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -250,8 +250,9 @@ INF  
MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
-INF  PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
+INF  PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
+INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
 INF  MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
 INF  MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 66459c2..161f783 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -457,8 +457,9 @@
   MdeModulePkg/Universal/Disk/U

[edk2] [PATCH 0/6] enable SataController in OVMF

2014-08-14 Thread reza . jelveh

From: Reza Jelveh 

The SataController is moved to PcAtChipsetPkg where the IdeController
resides. The SataController is also enabled for OVMF.

Certain controllers such as Marvel 9230 controller use a D2H FIS instead
of PIO Setup FIS to denote the end of a PIO data-in command.

Some dependency on SataController is removed from IdeMode and SataController
channel detection is moved to later after protocol installation

Reza Jelveh (6):
  MdeModulePkg: Check D2H register status in AhciPioTransfer
  DuetPkg: Move SataControllerDxe to PcAtChipsetPkg
  OvmfPkg: enable SATA controller
  MdeModulePkg: IdeMode should not depend on SataController
  PcAtChipsetPkg: read host capabilities on ChannelInfo
  MdeModulePkg: AhciMode calls GetChannelInfo when enumerating

 DuetPkg/DuetPkg.fdf|2 +-
 DuetPkg/DuetPkgIa32.dsc|2 +-
 DuetPkg/DuetPkgX64.dsc |2 +-
 DuetPkg/SataControllerDxe/ComponentName.c  |  176 
 DuetPkg/SataControllerDxe/SataController.c | 1007 ---
 DuetPkg/SataControllerDxe/SataController.h |  542 ---
 DuetPkg/SataControllerDxe/SataControllerDxe.inf|   49 -
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c   |   30 +-
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h   |3 +
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c|5 +-
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h|5 +
 OvmfPkg/OvmfPkgIa32.dsc|5 +-
 OvmfPkg/OvmfPkgIa32.fdf|5 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |5 +-
 OvmfPkg/OvmfPkgIa32X64.fdf |5 +-
 OvmfPkg/OvmfPkgX64.dsc |5 +-
 OvmfPkg/OvmfPkgX64.fdf |5 +-
 .../Bus/Pci/SataControllerDxe/ComponentName.c  |  176 
 .../Bus/Pci/SataControllerDxe/SataController.c | 1008 
 .../Bus/Pci/SataControllerDxe/SataController.h |  542 +++
 .../Pci/SataControllerDxe/SataControllerDxe.inf|   49 +
 21 files changed, 1834 insertions(+), 1794 deletions(-)
 delete mode 100644 DuetPkg/SataControllerDxe/ComponentName.c
 delete mode 100644 DuetPkg/SataControllerDxe/SataController.c
 delete mode 100644 DuetPkg/SataControllerDxe/SataController.h
 delete mode 100644 DuetPkg/SataControllerDxe/SataControllerDxe.inf
 create mode 100644 PcAtChipsetPkg/Bus/Pci/SataControllerDxe/ComponentName.c
 create mode 100644 PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.c
 create mode 100644 PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.h
 create mode 100644 
PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf

-- 
1.9.2


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 4/6] MdeModulePkg: IdeMode should not depend on SataController

2014-08-14 Thread reza . jelveh

From: Reza Jelveh 

Currently IdeMode depends on SataController to set ChannelCount to
enumerate IDE devices. SataController sets ChannelCount to
ICH_IDE_MAX_CHANNEL, which is 2.

IdeMode should not be dependent on SataController and just use this
constant directly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c | 5 ++---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h | 5 +
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
index e5beea6..2c554e0 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
@@ -2797,14 +2797,12 @@ IdeModeInitialization (
   EFI_STATUSStatus;
   EFI_IDE_CONTROLLER_INIT_PROTOCOL  *IdeInit;
   EFI_PCI_IO_PROTOCOL   *PciIo;
-  UINT8 Channel;
   UINT8 IdeChannel;
   BOOLEAN   ChannelEnabled;
   UINT8 MaxDevices;
 
   IdeInit = Instance->IdeControllerInit;
   PciIo   = Instance->PciIo;
-  Channel = IdeInit->ChannelCount;
 
   //
   // Obtain IDE IO port registers' base addresses
@@ -2814,7 +2812,8 @@ IdeModeInitialization (
 goto ErrorExit;
   }
 
-  for (IdeChannel = 0; IdeChannel < Channel; IdeChannel++) {
+
+  for (IdeChannel = 0; IdeChannel < ICH_IDE_MAX_CHANNEL; IdeChannel++) {
 IdeInit->NotifyPhase (IdeInit, EfiIdeBeforeChannelEnumeration, IdeChannel);
 
 //
diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h
index 67fff64..d2590d9 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h
@@ -77,6 +77,11 @@ typedef enum {
 #define EFI_ATA_MODE_MDMA0x04
 #define EFI_ATA_MODE_UDMA0x08
 
+//
+// Supports 2 channel max
+//
+#define ICH_IDE_MAX_CHANNEL 0x02
+
 typedef struct {
   UINT32  RegionBaseAddr;
   UINT16  ByteCount;
-- 
1.9.2


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 5/6] PcAtChipsetPkg: read host capabilities on ChannelInfo

2014-08-14 Thread reza . jelveh

From: Reza Jelveh 

SataController reads host capabalities when the module is first loaded.

The Initialize method should only install the protocol. All host
specific information is read when ChannelInfo is accessed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 .../Bus/Pci/SataControllerDxe/SataController.c | 115 +++--
 1 file changed, 58 insertions(+), 57 deletions(-)

diff --git a/PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.c 
b/PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.c
index 1807c88..944aba2 100644
--- a/PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.c
+++ b/PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.c
@@ -390,10 +390,7 @@ SataControllerStart (
 {
   EFI_STATUSStatus;
   EFI_PCI_IO_PROTOCOL   *PciIo;
-  PCI_TYPE00PciData;
   EFI_SATA_CONTROLLER_PRIVATE_DATA  *SataPrivateData;
-  UINT32Data32;
-  UINTN ChannelDeviceCount;
 
   DEBUG ((EFI_D_INFO, "SataControllerStart START\n"));
 
@@ -437,50 +434,6 @@ SataControllerStart (
   SataPrivateData->IdeInit.SetTiming = IdeInitSetTiming;
   SataPrivateData->IdeInit.EnumAll = SATA_ENUMER_ALL;
 
-  Status = PciIo->Pci.Read (
-PciIo,
-EfiPciIoWidthUint8,
-PCI_CLASSCODE_OFFSET,
-sizeof (PciData.Hdr.ClassCode),
-PciData.Hdr.ClassCode
-);
-  ASSERT_EFI_ERROR (Status);
-
-  if (IS_PCI_IDE (&PciData)) {
-SataPrivateData->IdeInit.ChannelCount = IDE_MAX_CHANNEL;
-SataPrivateData->DeviceCount = IDE_MAX_DEVICES;
-  } else if (IS_PCI_SATADPA (&PciData)) {
-//
-// Read Host Capability Register(CAP) to get Number of Ports(NPS) and 
Supports Port Multiplier(SPM)
-//   NPS is 0's based value indicating the maximum number of ports 
supported by the HBA silicon.
-//   A maximum of 32 ports can be supported. A value of '0h', indicating 
one port, is the minimum requirement.
-//
-Data32 = AhciReadReg (PciIo, R_AHCI_CAP);
-SataPrivateData->IdeInit.ChannelCount = (UINT8) ((Data32 & B_AHCI_CAP_NPS) 
+ 1);
-SataPrivateData->DeviceCount = AHCI_MAX_DEVICES;
-if ((Data32 & B_AHCI_CAP_SPM) == B_AHCI_CAP_SPM) {
-  SataPrivateData->DeviceCount = AHCI_MULTI_MAX_DEVICES;
-}
-  }
-
-  ChannelDeviceCount = (UINTN) (SataPrivateData->IdeInit.ChannelCount) * 
(UINTN) (SataPrivateData->DeviceCount);
-  SataPrivateData->DisqulifiedModes = AllocateZeroPool ((sizeof 
(EFI_ATA_COLLECTIVE_MODE)) * ChannelDeviceCount);
-  if (SataPrivateData->DisqulifiedModes == NULL) {
-Status = EFI_OUT_OF_RESOURCES;
-goto Done;
-  }
-
-  SataPrivateData->IdentifyData = AllocateZeroPool ((sizeof 
(EFI_IDENTIFY_DATA)) * ChannelDeviceCount);
-  if (SataPrivateData->IdentifyData == NULL) {
-Status = EFI_OUT_OF_RESOURCES;
-goto Done;
-  }
-
-  SataPrivateData->IdentifyValid = AllocateZeroPool ((sizeof (BOOLEAN)) * 
ChannelDeviceCount);
-  if (SataPrivateData->IdentifyValid == NULL) {
-Status = EFI_OUT_OF_RESOURCES;
-goto Done;
-  }
 
   //
   // Install IDE Controller Init Protocol to this instance
@@ -502,15 +455,6 @@ Done:
   Controller
   );
 if (SataPrivateData != NULL) {
-  if (SataPrivateData->DisqulifiedModes != NULL) {
-FreePool (SataPrivateData->DisqulifiedModes);
-  }
-  if (SataPrivateData->IdentifyData != NULL) {
-FreePool (SataPrivateData->IdentifyData);
-  }
-  if (SataPrivateData->IdentifyValid != NULL) {
-FreePool (SataPrivateData->IdentifyValid);
-  }
   FreePool (SataPrivateData);
 }
   }
@@ -648,18 +592,75 @@ IdeInitGetChannelInfo (
   OUT UINT8 *MaxDevices
   )
 {
+  EFI_STATUSStatus;
+  PCI_TYPE00PciData;
   EFI_SATA_CONTROLLER_PRIVATE_DATA  *SataPrivateData;
+  UINT32Data32;
+  UINTN ChannelDeviceCount;
+
   SataPrivateData = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (This);
   ASSERT (SataPrivateData != NULL);
 
+  Status = SataPrivateData->PciIo->Pci.Read (
+SataPrivateData->PciIo,
+EfiPciIoWidthUint8,
+PCI_CLASSCODE_OFFSET,
+sizeof (PciData.Hdr.ClassCode),
+PciData.Hdr.ClassCode
+);
+  ASSERT_EFI_ERROR (Status);
+
+  if (IS_PCI_IDE (&PciData)) {
+SataPrivateData->IdeInit.ChannelCount = IDE_MAX_CHANNEL;
+SataPrivateData->DeviceCount = IDE_MAX_DEVICES;
+  } else if (IS_PCI_SATADPA (&PciData)) {
+//
+// Read Host Capability Register(CAP) to get Number of Ports(NPS) and 
Supports Port Multiplier(SPM)
+//   NPS is 0's based value indicating the maximum number of ports 
supported by the HBA silicon.
+

[edk2] [PATCH 2/6] DuetPkg: Move SataControllerDxe to PcAtChipsetPkg

2014-08-14 Thread reza . jelveh

From: Reza Jelveh 

SataController is moved to PcAtChipsetPkg for use in other packages such
as OVMF.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 DuetPkg/DuetPkg.fdf|2 +-
 DuetPkg/DuetPkgIa32.dsc|2 +-
 DuetPkg/DuetPkgX64.dsc |2 +-
 DuetPkg/SataControllerDxe/ComponentName.c  |  176 
 DuetPkg/SataControllerDxe/SataController.c | 1007 
 DuetPkg/SataControllerDxe/SataController.h |  542 ---
 DuetPkg/SataControllerDxe/SataControllerDxe.inf|   49 -
 .../Bus/Pci/SataControllerDxe/ComponentName.c  |  176 
 .../Bus/Pci/SataControllerDxe/SataController.c | 1007 
 .../Bus/Pci/SataControllerDxe/SataController.h |  542 +++
 .../Pci/SataControllerDxe/SataControllerDxe.inf|   49 +
 11 files changed, 1777 insertions(+), 1777 deletions(-)
 delete mode 100644 DuetPkg/SataControllerDxe/ComponentName.c
 delete mode 100644 DuetPkg/SataControllerDxe/SataController.c
 delete mode 100644 DuetPkg/SataControllerDxe/SataController.h
 delete mode 100644 DuetPkg/SataControllerDxe/SataControllerDxe.inf
 create mode 100644 PcAtChipsetPkg/Bus/Pci/SataControllerDxe/ComponentName.c
 create mode 100644 PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.c
 create mode 100644 PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataController.h
 create mode 100644 
PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf

diff --git a/DuetPkg/DuetPkg.fdf b/DuetPkg/DuetPkg.fdf
index 66f8b68..644c9e3 100644
--- a/DuetPkg/DuetPkg.fdf
+++ b/DuetPkg/DuetPkg.fdf
@@ -83,7 +83,7 @@ INF  
IntelFrameworkModulePkg/Bus/Pci/VgaMiniPortDxe/VgaMiniPortDxe.inf
 INF  IntelFrameworkModulePkg/Universal/Console/VgaClassDxe/VgaClassDxe.inf
 
   # IDE/AHCI Support
-INF  DuetPkg/SataControllerDxe/SataControllerDxe.inf
+INF  PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
diff --git a/DuetPkg/DuetPkgIa32.dsc b/DuetPkg/DuetPkgIa32.dsc
index db1f7b6..550922c 100644
--- a/DuetPkg/DuetPkgIa32.dsc
+++ b/DuetPkg/DuetPkgIa32.dsc
@@ -226,7 +226,7 @@
   IntelFrameworkModulePkg/Universal/Console/VgaClassDxe/VgaClassDxe.inf
 
   # IDE/AHCI Support
-  DuetPkg/SataControllerDxe/SataControllerDxe.inf
+  PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
diff --git a/DuetPkg/DuetPkgX64.dsc b/DuetPkg/DuetPkgX64.dsc
index eeae767..0d42687 100644
--- a/DuetPkg/DuetPkgX64.dsc
+++ b/DuetPkg/DuetPkgX64.dsc
@@ -227,7 +227,7 @@
   IntelFrameworkModulePkg/Universal/Console/VgaClassDxe/VgaClassDxe.inf
 
   # IDE/AHCI Support
-  DuetPkg/SataControllerDxe/SataControllerDxe.inf
+  PcAtChipsetPkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
diff --git a/DuetPkg/SataControllerDxe/ComponentName.c 
b/DuetPkg/SataControllerDxe/ComponentName.c
deleted file mode 100644
index 57cd3c8..000
--- a/DuetPkg/SataControllerDxe/ComponentName.c
+++ /dev/null
@@ -1,176 +0,0 @@
-/** @file
-  UEFI Component Name(2) protocol implementation for Sata Controller driver.
-
-  Copyright (c) 2011, Intel Corporation. All rights reserved.
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "SataController.h"
-
-//
-/// EFI Component Name Protocol
-///
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  
gSataControllerComponentName = {
-  SataControllerComponentNameGetDriverName,
-  SataControllerComponentNameGetControllerName,
-  "eng"
-};
-
-//
-/// EFI Component Name 2 Protocol
-///
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL 
gSataControllerComponentName2 = {
-  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME) 
SataControllerComponentNameGetDriverName,
-  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME) 
SataControllerComponentNameGetControllerName,
-  "en"
-};
-
-//
-/// Driver Name Strings
-///
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
mSataControllerDriverNameTable[] = {
-  {
-"eng;en",
-(CHAR16 *)L"Sata Controller Init Driver"
-  },
-  {
-NULL,
-NULL
-  }
-};
-
-///
-/// Controller Name Strings
-///
-GLOBAL_REMOVE_IF_UNREFERENC

[edk2] [PATCH 6/6] MdeModulePkg: AhciMode calls GetChannelInfo when enumerating

2014-08-14 Thread reza . jelveh

From: Reza Jelveh 

GetChannelInfo is called to initialize the SataController when
enumerating ports.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
index 487f516..92af9e4 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
@@ -2211,6 +2211,7 @@ AhciModeInitialization (
   EFI_PCI_IO_PROTOCOL  *PciIo;
   EFI_IDE_CONTROLLER_INIT_PROTOCOL *IdeInit;
   UINT32   Capability;
+  BOOLEAN  ChannelEnabled;
   UINT8MaxPortNumber;
   UINT32   PortImplementBitMap;
 
@@ -2282,6 +2283,21 @@ AhciModeInitialization (
 
   IdeInit->NotifyPhase (IdeInit, EfiIdeBeforeChannelEnumeration, Port);
 
+  Status = IdeInit->GetChannelInfo (
+  IdeInit,
+  Port,
+  &ChannelEnabled,
+  &MaxPortNumber
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "[GetChannel, Status=%x]", Status));
+continue;
+  }
+
+  if (!ChannelEnabled) {
+continue;
+  }
+
   //
   // Initialize FIS Base Address Register and Command List Base Address 
Register for use.
   //
-- 
1.9.2


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 1/6] MdeModulePkg: Check D2H register status in AhciPioTransfer

2014-08-14 Thread reza . jelveh

From: Reza Jelveh 

Some AHCI controllers such as the Marvel 9230 controllers do not send
PIO Setup FIS when the PIO data-in command is completed. Instead they
just send a D2H FIS.

To accomodate for this possibility the status code of the D2H FIS is
checked.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 14 --
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h |  3 +++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
index 7fc7a28..487f516 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
@@ -703,6 +703,7 @@ AhciPioTransfer (
   EFI_AHCI_COMMAND_LIST CmdList;
   UINT32PortTfd;
   UINT32PrdCount;
+  UINT8 D2HStatus;
   BOOLEAN   InfiniteWait;
 
   if (Timeout == 0) {
@@ -804,8 +805,17 @@ AhciPioTransfer (
   Offset = FisBaseAddr + EFI_AHCI_D2H_FIS_OFFSET;
   Status = AhciCheckMemSet (Offset, EFI_AHCI_FIS_TYPE_MASK, 
EFI_AHCI_FIS_REGISTER_D2H, NULL);
   if (!EFI_ERROR (Status)) {
-Status = EFI_DEVICE_ERROR;
-break;
+D2HStatus = *(volatile UINT8 *) (Offset + 
EFI_AHCI_D2H_FIS_STATUS_OFFSET);
+
+if ((D2HStatus & EFI_AHCI_D2H_FIS_ERR) != 0) {
+  Status = EFI_DEVICE_ERROR;
+  break;
+}
+
+PrdCount = *(volatile UINT32 *) 
(&(AhciRegisters->AhciCmdList[0].AhciCmdPrdbc));
+if (PrdCount == DataCount) {
+  break;
+}
   }
 
   //
diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h
index 485b647..9fe1fb3 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h
@@ -78,12 +78,15 @@ typedef union {
 #define   EFI_AHCI_FIS_SET_DEVICE_LENGTH   8
 
 #define EFI_AHCI_D2H_FIS_OFFSET0x40
+#define   EFI_AHCI_D2H_FIS_STATUS_OFFSET   0x02
+#define   EFI_AHCI_D2H_FIS_ERR BIT0
 #define EFI_AHCI_DMA_FIS_OFFSET0x00
 #define EFI_AHCI_PIO_FIS_OFFSET0x20
 #define EFI_AHCI_SDB_FIS_OFFSET0x58
 #define EFI_AHCI_FIS_TYPE_MASK 0xFF
 #define EFI_AHCI_U_FIS_OFFSET  0x60
 
+
 //
 // Port register
 //
-- 
1.9.2


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] "key" usage with VFR

2014-08-14 Thread Tim Lewis

The current grammar for VFR shows the following for "checkbox":


vfrStatementCheckBox ::=

  "checkbox"

  vfrQuestionHeader ","

  { "flags" "=" vfrCheckBoxFlags "," }

  { "key" "=" Number "," }

  vfrStatementQuestionOptionList
"endcheckbox" ";"

And then a little further down it has this note:

BEHAVIORS AND RESTRICTIONS:
The value of key is used as question ID.

Now, observe this example from DriverSampleDxe (Vfr.vfr, line 177):

checkbox varid   = MyIfrNVData.ChooseToActivateNuclearWeaponry,
 prompt   = STRING_TOKEN(STR_CHECK_BOX_PROMPT),
 help = STRING_TOKEN(STR_CHECK_BOX_HELP),
 //
 // CHECKBOX_DEFAULT indicate this checkbox is marked with 
EFI_IFR_CHECKBOX_DEFAULT
 // CHECKBOX_DEFAULT_MFG indicate EFI_IFR_CHECKBOX_DEFAULT_MFG.
 //
 flags= CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG,
 key  = 0,
 default  = 1,
endcheckbox;

Notice that (a) there is no "questionid" (from the vfrQuestionHeader terminal) 
and (b) key is set to 0. Since 0 is not a valid question identifier value 
(although the UEFI 2.4 spec is not so clear on this, you can see that it is 
true from how it is referenced in the EFI_IFR_REF structure 29.3.8.3.59 and the 
callback). So it is not clear whether the intention was to force the assignment 
of a non-conflicting value or it really intended that the question identifier 
be 0.

There is a similar issue on line 590 (another checkbox). Am I missing something 
here? Is there a specific reason why "key" (an anachronism from the Framework 
days) is used instead of "questionid"?


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch][Basetools]Enable long file path support on BaseTools

2014-08-14 Thread Liu, Yingke D

Hess,

The patch is good.
Reviewed-by: Yingke Liu 

Dennis

From: Chen, Hesheng [mailto:hesheng.c...@intel.com]
Sent: Thursday, August 14, 2014 3:16 PM
To: 'edk2-devel@lists.sourceforge.net'
Subject: [edk2] [Patch][Basetools]Enable long file path support on BaseTools

Hello all,
Could you help review this patch?

There is a limitation on WINDOWS OS for the length of entire file path can't be 
larger than 255. There is an OS API provided by Microsoft to add "\\?\" before 
the path header to support the long file path. Enable this feature on basetools.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen mailto:hesheng.c...@intel.com>>

Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
Email: hesheng.c...@intel.com

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] "key" usage with VFR

2014-08-14 Thread Dong, Eric

Hi Tim,

The "key" is used to compatible with framework code.  I check the vfrcompile 
code, found the "key" is worked only when "flags" field has "INTERACTIVE" 
attribute. So the "key = 0" is not works for this sample code.  I will follow 
up to clean up this make user confused code.

Attach the ifr data for this sample code, it actually use 0x03 as the question 
id.
checkbox varid   = MyIfrNVData.ChooseToActivateNuclearWeaponry,
>01C6: 06 8E 29 00 2A 00 03 00 34 12 D4 00 00 03
 prompt   = STRING_TOKEN(0x0029),
 help = STRING_TOKEN(0x002A),
 flags= CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG,
 key  = 0,
 default  = 1,
>01D4: 5B 06 00 00 00 01
endcheckbox;
>01DA: 29 02
  endif;
>01DC: 29 02
endif;
>01DE: 29 02

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 15, 2014 8:48 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] "key" usage with VFR

The current grammar for VFR shows the following for "checkbox":


vfrStatementCheckBox ::=

  "checkbox"

  vfrQuestionHeader ","

  { "flags" "=" vfrCheckBoxFlags "," }

  { "key" "=" Number "," }

  vfrStatementQuestionOptionList
"endcheckbox" ";"

And then a little further down it has this note:

BEHAVIORS AND RESTRICTIONS:
The value of key is used as question ID.

Now, observe this example from DriverSampleDxe (Vfr.vfr, line 177):

checkbox varid   = MyIfrNVData.ChooseToActivateNuclearWeaponry,
 prompt   = STRING_TOKEN(STR_CHECK_BOX_PROMPT),
 help = STRING_TOKEN(STR_CHECK_BOX_HELP),
 //
 // CHECKBOX_DEFAULT indicate this checkbox is marked with 
EFI_IFR_CHECKBOX_DEFAULT
 // CHECKBOX_DEFAULT_MFG indicate EFI_IFR_CHECKBOX_DEFAULT_MFG.
 //
 flags= CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG,
 key  = 0,
 default  = 1,
endcheckbox;

Notice that (a) there is no "questionid" (from the vfrQuestionHeader terminal) 
and (b) key is set to 0. Since 0 is not a valid question identifier value 
(although the UEFI 2.4 spec is not so clear on this, you can see that it is 
true from how it is referenced in the EFI_IFR_REF structure 29.3.8.3.59 and the 
callback). So it is not clear whether the intention was to force the assignment 
of a non-conflicting value or it really intended that the question identifier 
be 0.

There is a similar issue on line 590 (another checkbox). Am I missing something 
here? Is there a specific reason why "key" (an anachronism from the Framework 
days) is used instead of "questionid"?


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

2014-08-14 Thread Tian, Feng

Hi, Olivier

Sorry for the late response. I will get back to you if I have progress.

Thanks
Feng

-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com] 
Sent: Friday, August 15, 2014 03:06
To: edk2-devel@lists.sourceforge.net; Tian, Feng
Cc: Brendan Jackman
Subject: RE: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

Any feedback on this one?

Thanks,
Olivier

> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: 24 March 2014 20:23
> To: feng.t...@intel.com
> Cc: Brendan Jackman; edk2-devel@lists.sourceforge.net
> Subject: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to 
> MdeModulePkg
> 
> From: Brendan Jackman 
> 
> This library is useful to other modules than the shell - for example 
> filesystem drivers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brendan Jackman 
> Reviewed-by: Olivier Martin 
> ---
>  AppPkg/AppPkg.dsc|   2 +-
>  EmulatorPkg/EmulatorPkg.dsc  |   2 +-
>  MdeModulePkg/Include/Library/PathLib.h   |  56 +++
>  MdeModulePkg/Library/BasePathLib/BasePathLib.c   | 123
> +++
>  MdeModulePkg/Library/BasePathLib/BasePathLib.inf |  38 +++
>  OvmfPkg/OvmfPkgIa32.dsc  |   2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   2 +-
>  OvmfPkg/OvmfPkgX64.dsc   |   2 +-
>  ShellPkg/Include/Library/PathLib.h   |  56 ---
>  ShellPkg/Library/BasePathLib/BasePathLib.c   | 123 ---
> 
>  ShellPkg/Library/BasePathLib/BasePathLib.inf |  38 ---
>  ShellPkg/ShellPkg.dsc|   2 +-
>  StdLib/StdLib.dsc|   2 +-
>  StdLib/StdLib.inc|   2 +-
>  14 files changed, 225 insertions(+), 225 deletions(-)  create mode 
> 100644 MdeModulePkg/Include/Library/PathLib.h
>  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.c
>  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.inf
>  delete mode 100644 ShellPkg/Include/Library/PathLib.h
>  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.c
>  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.inf
> 
> diff --git a/AppPkg/AppPkg.dsc b/AppPkg/AppPkg.dsc index 
> d0aac2c..491332a 100644
> --- a/AppPkg/AppPkg.dsc
> +++ b/AppPkg/AppPkg.dsc
> @@ -82,7 +82,7 @@
>ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> 
> FileHandleLib|ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
> -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> 
> 
> CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMa
> CacheMaintenanceLib|i
> ntenanceLib.inf
> 
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc 
> index f1cb780..fb580d6 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -391,7 +391,7 @@
>ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
>  #
> MemoryAllocationLib|EmulatorPkg/Library/GuardUefiMemoryAllocationLib/G
> MemoryAllocationLib|u
> ardUefiMemoryAllocationLib.inf
>  #
> SafeBlockIoLib|ShellPkg/Library/SafeBlockIoLib/SafeBlockIoLib.inf
>  #
> SafeOpenProtocolLib|ShellPkg/Library/SafeOpenProtocolLib/SafeOpenProto
> SafeOpenProtocolLib|c
> olLib.inf
> diff --git a/MdeModulePkg/Include/Library/PathLib.h
> b/MdeModulePkg/Include/Library/PathLib.h
> new file mode 100644
> index 000..ee47352
> --- /dev/null
> +++ b/MdeModulePkg/Include/Library/PathLib.h
> @@ -0,0 +1,56 @@
> +/** @file
> +  Provides interface to path manipulation functions.
> +
> +  Copyright (c) 2011, Intel Corporation. All rights reserved.  
> + This program and the accompanying materials  are licensed and made 
> + available under the terms and conditions of
> the BSD License
> +  which accompanies this distribution.  The full text of the license
> may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS 
> + OR
> IMPLIED.
> +**/
> +
> +#ifndef _PATH_LIB_
> +#define _PATH_LIB_
> +
> +#include 
> +#include 
> +
> +/**
> +  Removes the last directory or file entry in a path by changing the
> last
> +  L'\' to a CHAR_NULL.
> +
> +  @param[in, out] PathThe pointer to the path to modify.
> +
> +  @retval FALSE Nothing was found to remove.
> +  @retval TRUE  A directory or file was removed.
> +**/
> +BOOLEAN
> +EFIAPI
> +PathRemoveL

Re: [edk2] [Patch 1] Change svn:mime-type property on Unicode files

2014-08-14 Thread Gao, Liming

Larry:

  The patch is good.  Reviewed-by: Gao, Liming 

-Original Message-
From: Hauch, Larry [mailto:larry.ha...@intel.com] 
Sent: Friday, August 15, 2014 2:57 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch 1] Change svn:mime-type property on Unicode files

Hi Folks,
I agree that we should modify the svn property although it still does not fix 
the issue with code reviews for the files.
I have attached the proposed patch; please review and let me know if there are 
any issues.

Change svn:mime-type property on all Unicode files (extension .uni) in edk2

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lhauch 

Cheers,
Larry

-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 8:06 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

It is not a problem for this patch (since the new UNI files are in the ZIP).

I agree that with UTF16 file types, the patch file itself is not very readable. 
But at least I can take a patch file (from this email list for instance), and 
apply it using SVN to my tree, and it will automatically apply the string 
changes to UNI files. 

I can also generate patch files from my tree that include UNI file changes and 
send them to this list to review

This is definitely better than binary files that cannot be dealt with AT ALL 
using SVN diff

In order to achieve this, we need to change ALL UNI files in EDK2 from:

svn:mime-type = application/octect-stream

To:

svn:mime-type = text/plain;encoding=UTF-16LE

Can someone please help with this change?

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Wednesday, August 13, 2014 9:36 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Yes. This is a possible solution. But, svn generated patch for UTF16 file is 
not good readability. 

This patch adds new UNI files. You can see them from ZIP files. 

Thanks
Liming
-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 10:26 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Can we change the file encoding type svn property for uni files to make them 
utf16 instead of binary stream? This way we can actually include uni files in 
patches and see what changed.

-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Wednesday, 13 Aug 2014, 9:17PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
MdePkg. The patch is a little big. For new added UNI file, I zip them together.

  The second patch for below item 7 will be sent later

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:

1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to packag

Re: [edk2] [PATCH 4/6] MdeModulePkg: IdeMode should not depend on SataController

2014-08-14 Thread Tian, Feng

Hi, Reza

This is a reason to use IdeInit.ChannelCount rather than the constant value. 
Some platforms may only expose one ide channel to external. By this way, we can 
skip unnecessary enumeration time according to platform policy.

Do you see any real impact with original code?

Thanks
Feng

-Original Message-
From: reza.jel...@tuhh.de [mailto:reza.jel...@tuhh.de] 
Sent: Friday, August 15, 2014 08:20
To: edk2-devel@lists.sourceforge.net
Cc: ag...@suse.de
Subject: [edk2] [PATCH 4/6] MdeModulePkg: IdeMode should not depend on 
SataController

From: Reza Jelveh 

Currently IdeMode depends on SataController to set ChannelCount to enumerate 
IDE devices. SataController sets ChannelCount to ICH_IDE_MAX_CHANNEL, which is 
2.

IdeMode should not be dependent on SataController and just use this constant 
directly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c | 5 ++---  
MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h | 5 +
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
index e5beea6..2c554e0 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
@@ -2797,14 +2797,12 @@ IdeModeInitialization (
   EFI_STATUSStatus;
   EFI_IDE_CONTROLLER_INIT_PROTOCOL  *IdeInit;
   EFI_PCI_IO_PROTOCOL   *PciIo;
-  UINT8 Channel;
   UINT8 IdeChannel;
   BOOLEAN   ChannelEnabled;
   UINT8 MaxDevices;
 
   IdeInit = Instance->IdeControllerInit;
   PciIo   = Instance->PciIo;
-  Channel = IdeInit->ChannelCount;
 
   //
   // Obtain IDE IO port registers' base addresses @@ -2814,7 +2812,8 @@ 
IdeModeInitialization (
 goto ErrorExit;
   }
 
-  for (IdeChannel = 0; IdeChannel < Channel; IdeChannel++) {
+
+  for (IdeChannel = 0; IdeChannel < ICH_IDE_MAX_CHANNEL; IdeChannel++) 
+ {
 IdeInit->NotifyPhase (IdeInit, EfiIdeBeforeChannelEnumeration, IdeChannel);
 
 //
diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h
index 67fff64..d2590d9 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.h
@@ -77,6 +77,11 @@ typedef enum {
 #define EFI_ATA_MODE_MDMA0x04
 #define EFI_ATA_MODE_UDMA0x08
 
+//
+// Supports 2 channel max
+//
+#define ICH_IDE_MAX_CHANNEL 0x02
+
 typedef struct {
   UINT32  RegionBaseAddr;
   UINT16  ByteCount;
--
1.9.2


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 6/6] MdeModulePkg: AhciMode calls GetChannelInfo when enumerating

2014-08-14 Thread Tian, Feng

Hi, Reza

Do you see any impact with original code? Why we don't use 
IdeInit.GetChannelInfo() is because we can get the info by AHCI PI register.

Thanks
Feng

-Original Message-
From: reza.jel...@tuhh.de [mailto:reza.jel...@tuhh.de] 
Sent: Friday, August 15, 2014 08:20
To: edk2-devel@lists.sourceforge.net
Cc: ag...@suse.de
Subject: [edk2] [PATCH 6/6] MdeModulePkg: AhciMode calls GetChannelInfo when 
enumerating

From: Reza Jelveh 

GetChannelInfo is called to initialize the SataController when enumerating 
ports.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
index 487f516..92af9e4 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
@@ -2211,6 +2211,7 @@ AhciModeInitialization (
   EFI_PCI_IO_PROTOCOL  *PciIo;
   EFI_IDE_CONTROLLER_INIT_PROTOCOL *IdeInit;
   UINT32   Capability;
+  BOOLEAN  ChannelEnabled;
   UINT8MaxPortNumber;
   UINT32   PortImplementBitMap;
 
@@ -2282,6 +2283,21 @@ AhciModeInitialization (
 
   IdeInit->NotifyPhase (IdeInit, EfiIdeBeforeChannelEnumeration, Port);
 
+  Status = IdeInit->GetChannelInfo (
+  IdeInit,
+  Port,
+  &ChannelEnabled,
+  &MaxPortNumber
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "[GetChannel, Status=%x]", Status));
+continue;
+  }
+
+  if (!ChannelEnabled) {
+continue;
+  }
+
   //
   // Initialize FIS Base Address Register and Command List Base Address 
Register for use.
   //
--
1.9.2


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

2014-08-14 Thread Kinney, Michael D

Liming,

Why was AARHCH64 was removed from VALID_ARCHITECTURES in BaseLib.inf and 
BaseCpuLib.inf?
Thanks,

Mike

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, August 13, 2014 7:13 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
MdePkg. The patch is a little big. For new added UNI file, I zip them together.

  The second patch for below item 7 will be sent later

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:


1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a module to go along with the 
localized Abstract and Description from the MODULE_UNI_FILE.

4)  PCD information in DEC file comment blocks are either incomplete or 
incorrect.  This includes detailed description, @Prompt, @ValidRange, 
@ValidList, @Expression, and [Error.] validation error messages

5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file that 
contains the localized Abstract and Description of a package and localized 
strings associated with PCDs.

a.   Addresses an information gap between DEC files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
PACKAGE_UNI_FILE and associated UNI file during UDP creation that performs the 
DEC -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
PACKAGE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> DEC conversion.

6)  Add [UserExtensions.TianoCore."ExtraFiles"] section to DEC files along 
with associated UNI file that provides the localized Name of a package.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
package to specify extra files to be added to a UDP without having to list the 
files in the UPT package information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a package to go along with the 
localized Abstract and Description from the PACKAGE_UNI_FILE.

7)  Make sure order of DEC/INF content matches the order that UPT generates 
in the XML -> INF conversion

a.   This allows UDP packages installed by UPT to be compared against EDK 
II trunk/branches using standard diff utilities.

Patches for the following EDK II packages are being prepared

1)  MdePkg

2)  MdeModulePkg

3)  IntelFrameworkPkg

4)  IntelFrameworkModulePkg

5)  FatPkg

6)  ShellPkg

7)  PcAtChipsetPkg

8)  UefiCpuPkg

9)  SourceLevelDebugPkg

10)   CryptoPkg

11)   SecurityPkg

12)   NetworkPkg

Best regards,

Mike

--

Re: [edk2] [Patch 1/2] [IntelFrameworkPkg] INF/DEC file updates to EDK II packages

2014-08-14 Thread Kinney, Michael D

Liming,

The patch looks good to me.

Reviewed-by: Michael Kinney 
mailto:michael.d.kin...@intel.com>>

Mike

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, August 13, 2014 7:18 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch 1/2] [IntelFrameworkPkg] INF/DEC file updates to EDK II 
packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
IntelFrameworkPkg. The patch is a little big. For new added UNI file, I zip 
them together.

  The second patch for below item 7 will be sent later

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming mailto:liming@intel.com>>

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:


1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a module to go along with the 
localized Abstract and Description from the MODULE_UNI_FILE.

4)  PCD information in DEC file comment blocks are either incomplete or 
incorrect.  This includes detailed description, @Prompt, @ValidRange, 
@ValidList, @Expression, and [Error.] validation error messages

5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file that 
contains the localized Abstract and Description of a package and localized 
strings associated with PCDs.

a.   Addresses an information gap between DEC files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
PACKAGE_UNI_FILE and associated UNI file during UDP creation that performs the 
DEC -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
PACKAGE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> DEC conversion.

6)  Add [UserExtensions.TianoCore."ExtraFiles"] section to DEC files along 
with associated UNI file that provides the localized Name of a package.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
package to specify extra files to be added to a UDP without having to list the 
files in the UPT package information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a package to go along with the 
localized Abstract and Description from the PACKAGE_UNI_FILE.

7)  Make sure order of DEC/INF content matches the order that UPT generates 
in the XML -> INF conversion

a.   This allows UDP packages installed by UPT to be compared against EDK 
II trunk/branches using standard diff utilities.

Patches for the following EDK II packages are being prepared

1)  MdePkg

2)  MdeModulePkg

3)  IntelFrameworkPkg

4)  IntelFrameworkModulePkg

5)  FatPkg

6)  ShellPkg

7)  PcAtChipsetPkg

8)  UefiCpuPkg

9)  SourceLevelDebugPkg

10)   CryptoPkg

11)   SecurityPkg

12)   NetworkPkg

Be

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

2014-08-14 Thread Ni, Ruiyu

I think maybe PathCleanUpDirectories is not a good name to describe this API's 
behavior. It's a API to normalize the file path but do nothing to the directory 
content. Would "PathNormalize" be better?

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Friday, August 15, 2014 4:41 AM
To: edk2-devel@lists.sourceforge.net; Tian, Feng; Olivier Martin 
(olivier.mar...@arm.com)
Cc: Brendan Jackman
Subject: Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

Reviewed-by: Jaben Carsey 

I didn't notice this email originally. I think that this looks like a good 
change.  What other feedback are you hoping for?

-Jaben


> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: Thursday, August 14, 2014 12:06 PM
> To: edk2-devel@lists.sourceforge.net; Tian, Feng
> Cc: Brendan Jackman
> Subject: Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to
> MdeModulePkg
> 
> Any feedback on this one?
> 
> Thanks,
> Olivier
> 
> > -Original Message-
> > From: Olivier Martin [mailto:olivier.mar...@arm.com]
> > Sent: 24 March 2014 20:23
> > To: feng.t...@intel.com
> > Cc: Brendan Jackman; edk2-devel@lists.sourceforge.net
> > Subject: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to
> > MdeModulePkg
> >
> > From: Brendan Jackman 
> >
> > This library is useful to other modules than the shell - for example
> > filesystem drivers.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Brendan Jackman 
> > Reviewed-by: Olivier Martin 
> > ---
> >  AppPkg/AppPkg.dsc|   2 +-
> >  EmulatorPkg/EmulatorPkg.dsc  |   2 +-
> >  MdeModulePkg/Include/Library/PathLib.h   |  56 +++
> >  MdeModulePkg/Library/BasePathLib/BasePathLib.c   | 123
> > +++
> >  MdeModulePkg/Library/BasePathLib/BasePathLib.inf |  38 +++
> >  OvmfPkg/OvmfPkgIa32.dsc  |   2 +-
> >  OvmfPkg/OvmfPkgIa32X64.dsc   |   2 +-
> >  OvmfPkg/OvmfPkgX64.dsc   |   2 +-
> >  ShellPkg/Include/Library/PathLib.h   |  56 ---
> >  ShellPkg/Library/BasePathLib/BasePathLib.c   | 123 ---
> > 
> >  ShellPkg/Library/BasePathLib/BasePathLib.inf |  38 ---
> >  ShellPkg/ShellPkg.dsc|   2 +-
> >  StdLib/StdLib.dsc|   2 +-
> >  StdLib/StdLib.inc|   2 +-
> >  14 files changed, 225 insertions(+), 225 deletions(-)  create mode
> > 100644 MdeModulePkg/Include/Library/PathLib.h
> >  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.c
> >  create mode 100644 MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> >  delete mode 100644 ShellPkg/Include/Library/PathLib.h
> >  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.c
> >  delete mode 100644 ShellPkg/Library/BasePathLib/BasePathLib.inf
> >
> > diff --git a/AppPkg/AppPkg.dsc b/AppPkg/AppPkg.dsc index
> > d0aac2c..491332a 100644
> > --- a/AppPkg/AppPkg.dsc
> > +++ b/AppPkg/AppPkg.dsc
> > @@ -82,7 +82,7 @@
> >ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >
> > FileHandleLib|ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> >SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
> > -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> > +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> >
> >
> >
> CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCac
> heMa
> > CacheMaintenanceLib|i
> > ntenanceLib.inf
> >
> > diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> > index f1cb780..fb580d6 100644
> > --- a/EmulatorPkg/EmulatorPkg.dsc
> > +++ b/EmulatorPkg/EmulatorPkg.dsc
> > @@ -391,7 +391,7 @@
> >ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf
> >PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> > -  PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
> > +  PathLib|MdeModulePkg/Library/BasePathLib/BasePathLib.inf
> >  #
> >
> MemoryAllocationLib|EmulatorPkg/Library/GuardUefiMemoryAllocationLib/
> G
> > MemoryAllocationLib|u
> > ardUefiMemoryAllocationLib.inf
> >  #
> > SafeBlockIoLib|ShellPkg/Library/SafeBlockIoLib/SafeBlockIoLib.inf
> >  #
> >
> SafeOpenProtocolLib|ShellPkg/Library/SafeOpenProtocolLib/SafeOpenProto
> > SafeOpenProtocolLib|c
> > olLib.inf
> > diff --git a/MdeModulePkg/Include/Library/PathLib.h
> > b/MdeModulePkg/Include/Library/PathLib.h
> > new file mode 100644
> > index 000..ee47352
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Library/PathLib.h
> > @@ -0,0 +1,56 @@
> > +/** @file
> > +  Provides interface to path manipulation functions.
> > +
> > +  Copyright (c) 2011, Intel Corporation. All rights reserved.
> > + This program and the accompanying materials  are licensed and made
> > + available unde

Re: [edk2] [PATCH v3 2/3] MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance

2014-08-14 Thread Gao, Liming

Hi, 
  I just find one minor issue. PcdValidateOrderedCollection is PcdsFeatureFlag. 
It should be listed in [FeaturePcd] instead of [Pcd] section in INF file.

+[Pcd]
+  gEfiMdePkgTokenSpaceGuid.PcdValidateOrderedCollection ## CONSUMES

Thanks
Liming
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, August 07, 2014 4:24 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH v3 2/3] MdePkg: introduce 
BaseOrderedCollectionRedBlackTreeLib library instance

edk2 should have a fast and easy-to-use associative array (a dictionary)
type.

Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.

Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.

The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).

While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.

I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)

During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.

The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.

A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.

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

Notes:
v3:
- move Validate() from OrderedCollection namespace to RedBlackTree, make
  it static, and call it automatically (when requested by PCD) at the
  exit points of Init(), Insert(), Delete(). [Mike]

v2:
- replace BaseRbTreeLib with BaseOrderedCollectionRedBlackTreeLib in
  files and in file names [Mike]

- adapt to changes in previous patch [Mike+Laszlo]

- move O(log(n)) language to library instance [Laszlo]

- preserve red-black specific nomenclature for the internals, but
  replace RbTree* with RedBlackTree*, and RB_TREE* with RED_BLACK_TREE*
  [Mike]

 .../BaseOrderedCollectionRedBlackTreeLib.inf   |   49 +
 .../BaseOrderedCollectionRedBlackTreeLib.c | 1439 
 MdePkg/MdePkg.dsc  |1 +
 3 files changed, 1489 insertions(+)
 create mode 100644 
MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
 create mode 100644 
MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c

diff --git 
a/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
 
b/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
new file mode 100644
index 000..4546725
--- /dev/null
+++ 
b/MdePkg

Re: [edk2] [PATCH v3 2/3] MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance

2014-08-14 Thread Laszlo Ersek

On 08/15/14 08:22, Gao, Liming wrote:
> Hi, 
>   I just find one minor issue. PcdValidateOrderedCollection is 
> PcdsFeatureFlag. It should be listed in [FeaturePcd] instead of [Pcd] section 
> in INF file.
> 
> +[Pcd]
> +  gEfiMdePkgTokenSpaceGuid.PcdValidateOrderedCollection ## CONSUMES

Thank you for the feedback!

Is this a strict requirement though? I modeled
"PcdValidateOrderedCollection" after "PcdVerifyNodeInList", which is
also declared under [PcdsFeatureFlag] in "MdePkg/MdePkg.dec". And, if
you search for INF files referencing "PcdVerifyNodeInList", you can find:

MdePkg/Library/BaseLib/BaseLib.inf:

[Pcd]
  gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength
  gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength
  gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength
  gEfiMdePkgTokenSpaceGuid.PcdVerifyNodeInList  <-- here

That is, the model for "PcdValidateOrderedCollection",
"PcdVerifyNodeInList", is also used by INF file(s) in their plain [Pcd]
section(s). (See SVN r9016.)

Thanks,
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] AARCH64 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c question. TCR adjusted but not written.

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Re: [edk2] EDK II UNI Unicode File Specification Update

Re: [edk2] [PATCH]ShellPkg: Fix code style and build failure

Re: [edk2] EDK II UNI Unicode File Specification Update

Re: [edk2] [PATCH] AppPkg: Enable ARM and AArch64 support

Re: [edk2] [PATCH] StdLib/LibC: Fix ARM symbol problems

Re: [edk2] [PATCH] StdLibPrivateInternalFiles: Add AArch64 support

[edk2] [Patch 1] Change svn:mime-type property on Unicode files

[edk2] [Patch][BaseTools] Fix --version in Rsa2048Sha256 tools

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

Re: [edk2] [Patch][BaseTools] Fix --version in Rsa2048Sha256 tools

Re: [edk2] [Patch 1] Change svn:mime-type property on Unicode files

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

Re: [edk2] ShellPkg: Fix EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL_GUID to match UEFI Shell 2.1 spec

[edk2] ShellPkg: Fix EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL_GUID to match UEFI Shell 2.1 spec

[edk2] [PATCH 3/6] OvmfPkg: enable SATA controller

[edk2] [PATCH 0/6] enable SataController in OVMF

[edk2] [PATCH 4/6] MdeModulePkg: IdeMode should not depend on SataController

[edk2] [PATCH 5/6] PcAtChipsetPkg: read host capabilities on ChannelInfo

[edk2] [PATCH 2/6] DuetPkg: Move SataControllerDxe to PcAtChipsetPkg

[edk2] [PATCH 6/6] MdeModulePkg: AhciMode calls GetChannelInfo when enumerating

[edk2] [PATCH 1/6] MdeModulePkg: Check D2H register status in AhciPioTransfer

[edk2] "key" usage with VFR

Re: [edk2] [Patch][Basetools]Enable long file path support on BaseTools

Re: [edk2] "key" usage with VFR

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

Re: [edk2] [Patch 1] Change svn:mime-type property on Unicode files

Re: [edk2] [PATCH 4/6] MdeModulePkg: IdeMode should not depend on SataController

Re: [edk2] [PATCH 6/6] MdeModulePkg: AhciMode calls GetChannelInfo when enumerating

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Re: [edk2] [Patch 1/2] [IntelFrameworkPkg] INF/DEC file updates to EDK II packages

Re: [edk2] [PATCH 1/3] Move BasePathLib from ShellPkg to MdeModulePkg

Re: [edk2] [PATCH v3 2/3] MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance

Re: [edk2] [PATCH v3 2/3] MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance

35 matches

Site Navigation

Mail list logo

Footer information