Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Eric -

For #1, this seems like a VFR compiler error, since the Form Browser does not 
place the container value in each element of the array (if the array is UINT16)

For #2, please refer to section 29.2.5.4.8, where it says:

"Storage The set questions are stored as a Buffer with one byte for each 
Container."

Then also see 29.2.5.4.1: "Question values are a data type listed in Section 
29.2.5.7.4." For an ordered list, the value is a Buffer (not one byte in a 
buffer) See also the Callback for CHANGING/CHANGED where the Ordered List value 
should be a buffer. The defaults 29.2.5.8 says "Defaults are pre-defined 
question values." Options say they "give ...description of a particular 
question value" (29.2.5.5)

This means that the Value of the question is the entire buffer, not just one 
byte.

Consider this case: I want to set the default boot order to 5,6,7,8,0,2,4. I 
understand that it is useful to see the value as one byte, and this might work 
best for one-of, but not for default. In any case, either the Form Browser 
needs to be changed or the specification needs to be changed for the 
ordered-list case.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, August 25, 2014 2:40 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

Add my comments below.

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 22, 2014 12:40 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] HII ORDERED_LIST support

In DriverSampleDxe, the boot order item is listed in storage as:

  UINT16  BootOrder[8];

And here is the ordered list which manipulates this item:

  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 
RESET_REQUIRED;
option text = STRING_TOKEN(0x006E), value = 1, flags = 
RESET_REQUIRED;
option text = STRING_TOKEN(0x0070), value = 3, flags = 
RESET_REQUIRED;
  suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
option text = STRING_TOKEN(0x0071), value = 4, flags = 
RESET_REQUIRED;
  endif
  endlist;

This leads to a number of questions:


1)  The BootOrder is defined as UINT16, but the UEFI specification clearly 
states that an orderedlist will work on a buffer with one byte per container.  
(See 29.2.5.4.8 where it says, "The set questions are stored as a Buffer with 
one byte for each Container."

[[[Eric]]] Truly spec has this description but vfrcompile and browser not do 
this check, also current code may already has samples which already violate 
this rule, so I need more discussion to provide a good proposal for this case.



[TIM] I am not worried about the actual struct members. BootOrder is 16 bytes 
(8 x sizeof(UINT16). So that means that MaxContainers will be 16, right? The 
VFR spec says: "NOTE: maxcontainers is optional, and the default value depends 
on the variable size defined by varid in vfrQuestionHeader" So it seems that, 
even though the code will work, using UINT8

BootOrder[16] would be easier to understand than UINT16 BootOrder[8]"

[[[Eric]]] Base on current implementation, the maxcontainer value is the array 
size. So for "UINT16 BootOrder[8]", the maxcontainer = 8 and for "UINT8 
BootOrder[16]", the maxcontainer = 16. I think we need to add check for the 
code first, only support one byte for each container.



2)  The option values are all integers. But the storage type of an ordered 
list is a BUFFER. To me this implies (I haven't looked this up) that the value 
an option is being used as the option for a single container. That makes sense, 
but it is not the behavior described in the UEFI specification. Also, there 
seems to be no way to create a value for a question of type buffer.

[[[Eric]]] no catch what's your mean is.

[TIM] For example, for "oneof" the value storage size is UINT8/UINT16/UINT32 or 
UINT64. The value storage size for "checkbox" is BOOLEAN. But what is the value 
storage size of "orderedlist" When I read the UEFI specification, the "value 
storage size" of orderedlist is maxcontainers x sizeof(UINT8). So, if 
maxcontainers is 16, then 16 bytes. BUT: the size of the value in an "option" 
inside the "orderedlist" in these examples is sizeof(UINT8), not maxcontainers 
x sizeof(UINT8).



According to the UEFI specification, as I read it today, the value in a 
ONE_OF_OPTION is the value for the entire value storage, not just one byte of 
the value storage.  So every container  in the ordered list value should be set 
to 2 when the first "ONE_OF_OPTION" (in the example above) is selected by the 
user.

[[[Eric]]] I can't find this information from the spec, which page in UEFI spec 
2.4b describe it?



But I do not believe this is what the EDK2 Form browser does today. I beli

[edk2] EFI_PEI_LOADED_IMAGE PPI question

[TigerLiu]

Hi, experts:

I found EFI_PEI_LOADED_IMAGE PPI was defined in PI_1.3  Spec.

But not find using it in PEI Phase code.

There is just ppi definition.

 

So:

Because it's optional ppi, not implement in current EDKII code base?

 

Best wishes

 

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Gao, Liming]

Hi, all

  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool. 
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help 
review them.

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

1)  Section Order in INF/DEC to match the ones generated from UPT

2)  Guid value in section will be align.

3)  Usage comments in section will be align.

4)  One PCD section includes one PCD type. If one PCD supports more PCD 
types, it will be listed in each PCD type section  in DEC file.

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

Thanks
Liming
From: Gao, Liming [mailto:liming@intel.com]
Sent: Thursday, August 14, 2014 10:18 AM
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 

[edk2] [Patch 2/2][FatPkg]INF/DEC files update to EDK II packages

[Gao, Liming]

Hi, all

  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool. 
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help 
review them.

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

1)  Section Order in INF/DEC to match the ones generated from UPT

2)  Guid value in section will be align.

3)  Usage comments in section will be align.

4)  One PCD section includes one PCD type. If one PCD supports more PCD 
types, it will be listed in each PCD type section  in DEC file.

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

Thanks
Liming
From: Qiu, Shumin
Sent: Monday, August 18, 2014 10:22 AM
To: edk2-devel@lists.sourceforge.net
Cc: Gao, Liming
Subject: [edk2][Patch 1/2][FatPkg]INF/DEC files update to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
FatPkg. 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: Qiu, Shumin mailto:shumin@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 sur

[edk2] build ovmf failure

[chen.fan.f...@cn.fujitsu.com]

Hi,

I always built OVMF successfully, but today I pull the newest edk2 code
to build OVMF then showing building failure:


Architecture(s)  = X64
Build target = DEBUG
Toolchain= GCC47

Active Platform
= /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.dsc
Flash Image Definition
= /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.fdf

Processing meta-data ...

build.py...
: error F000: Nothing to build
   [/home/chenfan/data/edk2/OvmfPkg/ResetVector/ResetVector.inf]


- Failed -
Build end time: 18:16:43, Aug.25 2014
Build total time: 00:00:03
---

and I use the code last git commit ID is:

commit f056e4c18047e9a0157a915175d07afbd8b8c581
Author: Jaben Carsey 
Date:   Fri Aug 22 17:02:11 2014 +

ShellPkg: Update 'pci' command for updated class codes


Did someone encounter this problem too?
how can I fix it?
any help will be appreciated.


Thanks,
Chen



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch 2/2][PcAtChipsetPkg]INF/DEC files update to EDK II packages

[Gao, Liming]

Hi, all

  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool. 
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help 
review them.

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

1)  Section Order in INF/DEC to match the ones generated from UPT

2)  Guid value in section will be align.

3)  Usage comments in section will be align.

4)  One PCD section includes one PCD type. If one PCD supports more PCD 
types, it will be listed in each PCD type section  in DEC file.

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

Thanks
Liming
From: Qiu, Shumin
Sent: Monday, August 18, 2014 10:28 AM
To: edk2-devel@lists.sourceforge.net
Cc: Gao, Liming
Subject: [edk2][Patch 1/2][PcAtChipsetPkg]INF/DEC files update to EDK II 
packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
PcAtChipsetPkg. 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: Qiu, Shumin mailto:shumin@intel.com>>

Thanks
Shumin


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_UN

[edk2] [Patch 2/2] [UefiCpuPkg] INF/DEC file updates to EDK II packages

[Gao, Liming]

Hi, all

  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool. 
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help 
review them.

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

1)  Section Order in INF/DEC to match the ones generated from UPT

2)  Guid value in section will be align.

3)  Usage comments in section will be align.

4)  One PCD section includes one PCD type. If one PCD supports more PCD 
types, it will be listed in each PCD type section  in DEC file.

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

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

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
UefiCpuPkg. 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: Fan, Jeff mailto:jeff@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 Descri

[edk2] [Patch 2/2] [SourceLevelDebugPkg] INF/DEC file updates to EDK II packages

[Gao, Liming]

Hi, all

  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool. 
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help 
review them.

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

1)  Section Order in INF/DEC to match the ones generated from UPT

2)  Guid value in section will be align.

3)  Usage comments in section will be align.

4)  One PCD section includes one PCD type. If one PCD supports more PCD 
types, it will be listed in each PCD type section  in DEC file.

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

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

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
SourceLevelDebugPkg. 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: Fan, Jeff mailto:jeff@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 
l

[edk2] [Patch 2/2] [NetworkPkg] INF/DEC file updates to EDK II packages

[Gao, Liming]

Hi, all

  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool. 
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help 
review them.

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

1)  Section Order in INF/DEC to match the ones generated from UPT

2)  Guid value in section will be align.

3)  Usage comments in section will be align.

4)  One PCD section includes one PCD type. If one PCD supports more PCD 
types, it will be listed in each PCD type section  in DEC file.

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

Thanks
Liming
From: Dong, Guo [mailto:guo.d...@intel.com]
Sent: Monday, August 18, 2014 3:11 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch 1/2] [NetworkPkg] INF/DEC file updates to EDK II packages


Hi, all
  Could you help review this patch?

It includes the following changes 1-6 for NetworkPkg and a few typo fix in UNI 
file.
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: Dong, Guo guo.d...@intel.com

Thanks,
Guo

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 al

[edk2] [Patch 2/2] [CryptoPkg] INF/DEC file updates to EDK II packages

[Gao, Liming]

Hi, all

  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool. 
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help 
review them.

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

1)  Section Order in INF/DEC to match the ones generated from UPT

2)  Guid value in section will be align.

3)  Usage comments in section will be align.

4)  One PCD section includes one PCD type. If one PCD supports more PCD 
types, it will be listed in each PCD type section  in DEC file.

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

Thanks
Liming

From: Dong, Guo [mailto:guo.d...@intel.com]
Sent: Monday, August 18, 2014 6:00 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch 1/2] [CryptoPkg] INF/DEC file updates to EDK II packages


Hi, all
  Could you help review this patch?

It includes the following changes 1-6 for CryptoPkg. For the 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: Dong, Guo guo.d...@intel.com

Thanks,
Guo

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 th

[edk2] Error Reported: Unsupported : windows server 2012 R2 boot issue

[ritul guru (riguru)]

Hi,
I am trying to install and boot from win2012 R2 UEFI OS.
I could install this OS in UEFI mode properly and but while booting I.e. 
executing the BOOTX64.efi from UEFI shell getting below error:

[cid:image001.png@01CFC083.F5F47080]


What could be the issue here?


Regards,
Ritul

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

[Gerd Hoffmann]

  Hi,

> The current calculation is correct for stdvga, because on stdvga the value
> returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is
> usable for drawing.

Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a qemu
bug.  We have releases with the bug in the wild though, so adding this
as (temporary?) workaround is sensible IMO.  The comment should be
updated saying so though.

cheers,
  Gerd



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] build ovmf failure

[Neeraj Ladkani]

I faced the same issue. For time being I commented line 506 in PCI.c and
build. It builds fine. Pls look at my last post on this forum regarding
same.

Neeraj
On Aug 25, 2014 4:01 PM, "chen.fan.f...@cn.fujitsu.com" <
chen.fan.f...@cn.fujitsu.com> wrote:

> Hi,
>
> I always built OVMF successfully, but today I pull the newest edk2 code
> to build OVMF then showing building failure:
>
> 
> Architecture(s)  = X64
> Build target = DEBUG
> Toolchain= GCC47
>
> Active Platform
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.dsc
> Flash Image Definition
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.fdf
>
> Processing meta-data ...
>
> build.py...
> : error F000: Nothing to build
>[/home/chenfan/data/edk2/OvmfPkg/ResetVector/ResetVector.inf]
>
>
> - Failed -
> Build end time: 18:16:43, Aug.25 2014
> Build total time: 00:00:03
> ---
>
> and I use the code last git commit ID is:
>
> commit f056e4c18047e9a0157a915175d07afbd8b8c581
> Author: Jaben Carsey 
> Date:   Fri Aug 22 17:02:11 2014 +
>
> ShellPkg: Update 'pci' command for updated class codes
>
>
> Did someone encounter this problem too?
> how can I fix it?
> any help will be appreciated.
>
>
> Thanks,
> Chen
>
>
>
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] build ovmf failure

[Sergey Isakov]

Did you update Conf/build_rules.txt to use nasm?

On 25.08.2014, at 14:29, chen.fan.f...@cn.fujitsu.com wrote:

> Hi,
> 
> I always built OVMF successfully, but today I pull the newest edk2 code
> to build OVMF then showing building failure:
> 
> 
> Architecture(s)  = X64
> Build target = DEBUG
> Toolchain= GCC47
> 
> Active Platform
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.dsc
> Flash Image Definition
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.fdf
> 
> Processing meta-data ...
> 
> build.py...
> : error F000: Nothing to build
>   [/home/chenfan/data/edk2/OvmfPkg/ResetVector/ResetVector.inf]
> 
> 
> - Failed -
> Build end time: 18:16:43, Aug.25 2014
> Build total time: 00:00:03
> ---
> 
> and I use the code last git commit ID is:
> 
> commit f056e4c18047e9a0157a915175d07afbd8b8c581
> Author: Jaben Carsey 
> Date:   Fri Aug 22 17:02:11 2014 +
> 
>ShellPkg: Update 'pci' command for updated class codes
> 
> 
> Did someone encounter this problem too?
> how can I fix it?
> any help will be appreciated.
> 
> 
> Thanks,
> Chen
> 
> 
> 
> --
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot issue

[Richardson, Brian]

Once the OS is installed, the primary loader is in the EFI\Microsoft directory.

Thanks ... br
---
Brian Richardson -- brian.richard...@intel.com -- Twitter: intel_brian

From: ritul guru (riguru) [mailto:rig...@cisco.com]
Sent: Monday, August 25, 2014 7:15 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot issue

Hi,
I am trying to install and boot from win2012 R2 UEFI OS.
I could install this OS in UEFI mode properly and but while booting I.e. 
executing the BOOTX64.efi from UEFI shell getting below error:

[cid:image001.png@01CFC046.D84C8190]


What could be the issue here?


Regards,
Ritul

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot issue

[ritul guru (riguru)]

Hi Brian,
Yes, I have tried booting from fs0:\EFI\Microsoft\Boot\BOOTMGFW.efi,
But it also gave the save Unsupported Error.

And I have just verified that OS is not calling ExitBootServices() means this 
error is coming before call to ExitBootServices().
Could there be issue while OS installation as the OS driver which detected the 
lun is development recently?

Regards,
Ritul

From: Richardson, Brian [mailto:brian.richard...@intel.com]
Sent: Monday, August 25, 2014 6:58 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot 
issue

Once the OS is installed, the primary loader is in the EFI\Microsoft directory.

Thanks ... br
---
Brian Richardson -- 
brian.richard...@intel.com -- Twitter: 
intel_brian

From: ritul guru (riguru) [mailto:rig...@cisco.com]
Sent: Monday, August 25, 2014 7:15 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot issue

Hi,
I am trying to install and boot from win2012 R2 UEFI OS.
I could install this OS in UEFI mode properly and but while booting I.e. 
executing the BOOTX64.efi from UEFI shell getting below error:

[cid:image001.png@01CFC097.B6DD60F0]


What could be the issue here?


Regards,
Ritul

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Add DDR4 SMBIOS enumeration

[El-Haj-Mahmoud, Samer]

Makes sense. Please disregard until the spec is published.

Thanks,
--Samer


From: Li, Elvin [mailto:elvin...@intel.com]
Sent: Sunday, August 24, 2014 7:57 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdePkg: Add DDR4 SMBIOS enumeration

Hi,
From 
http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf, 
the DDR4 fields in the patch have not been in this public spec. We may wait for 
a while.

Thanks
Elvin
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:11 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Add DDR4 SMBIOS enumeration

Dear MdePkg maintainers,

Please find the attached patch that adds DDR4 memory type enumeration from 
SMBIOS 2.8.0.



Add DDR4 memory type enumeration from SMBIOS 2.8.0.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
UEFI System Firmware Architect
HP - Industry Standard Servers (ISS)

el...@hp.com
T +1 281 514 5973
Hewlett-Packard Company
CCM07:M74-B228
Houston, TX 77070

[Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] build ovmf failure

[Gao, Liming]

After you update EDKII code base, please remove Conf/build_rules.txt first, 
then call edksetup script to copy new build_rules.txt

And, you also need to install nasm compiler.

-Original Message-
From: Sergey Isakov [mailto:isakov...@bk.ru] 
Sent: Monday, August 25, 2014 9:23 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] build ovmf failure

Did you update Conf/build_rules.txt to use nasm?

On 25.08.2014, at 14:29, chen.fan.f...@cn.fujitsu.com wrote:

> Hi,
> 
> I always built OVMF successfully, but today I pull the newest edk2 
> code to build OVMF then showing building failure:
> 
> 
> Architecture(s)  = X64
> Build target = DEBUG
> Toolchain= GCC47
> 
> Active Platform
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.dsc
> Flash Image Definition
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.fdf
> 
> Processing meta-data ...
> 
> build.py...
> : error F000: Nothing to build
>   [/home/chenfan/data/edk2/OvmfPkg/ResetVector/ResetVector.inf]
> 
> 
> - Failed -
> Build end time: 18:16:43, Aug.25 2014
> Build total time: 00:00:03
> ---
> 
> and I use the code last git commit ID is:
> 
> commit f056e4c18047e9a0157a915175d07afbd8b8c581
> Author: Jaben Carsey 
> Date:   Fri Aug 22 17:02:11 2014 +
> 
>ShellPkg: Update 'pci' command for updated class codes
> 
> 
> Did someone encounter this problem too?
> how can I fix it?
> any help will be appreciated.
> 
> 
> Thanks,
> Chen
> 
> 
> 
> --
> 
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from UEFI 2.4

[Gao, Liming]

The patch is good. I will help commit it.

Reviewed-by: Gao, Liming 

Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:16 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from 
UEFI 2.4

Dear MdePkg maintainers,

Please find the attached patch that adds IMAGE_ATTRIBUTE_UEFI_IMAGE definition 
from UEFI 2.4 specification.


Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from UEFI 2.4 specification.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] build ovmf failure

[Neeraj Ladkani]

Yes, I installed nasm.

Neeraj
Did you update Conf/build_rules.txt to use nasm?

On 25.08.2014, at 14:29, chen.fan.f...@cn.fujitsu.com wrote:

> Hi,
>
> I always built OVMF successfully, but today I pull the newest edk2 code
> to build OVMF then showing building failure:
>
> 
> Architecture(s)  = X64
> Build target = DEBUG
> Toolchain= GCC47
>
> Active Platform
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.dsc
> Flash Image Definition
> = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.fdf
>
> Processing meta-data ...
>
> build.py...
> : error F000: Nothing to build
>   [/home/chenfan/data/edk2/OvmfPkg/ResetVector/ResetVector.inf]
>
>
> - Failed -
> Build end time: 18:16:43, Aug.25 2014
> Build total time: 00:00:03
> ---
>
> and I use the code last git commit ID is:
>
> commit f056e4c18047e9a0157a915175d07afbd8b8c581
> Author: Jaben Carsey 
> Date:   Fri Aug 22 17:02:11 2014 +
>
>ShellPkg: Update 'pci' command for updated class codes
>
>
> Did someone encounter this problem too?
> how can I fix it?
> any help will be appreciated.
>
>
> Thanks,
> Chen
>
>
>
>
--
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from UEFI 2.4

[El-Haj-Mahmoud, Samer]

Thanks Liming

From: Gao, Liming [mailto:liming@intel.com]
Sent: Monday, August 25, 2014 10:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition 
from UEFI 2.4

The patch is good. I will help commit it.

Reviewed-by: Gao, Liming mailto:liming@intel.com>>

Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:16 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from 
UEFI 2.4

Dear MdePkg maintainers,

Please find the attached patch that adds IMAGE_ATTRIBUTE_UEFI_IMAGE definition 
from UEFI 2.4 specification.


Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from UEFI 2.4 specification.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for updated class codes

[Carsey, Jaben]

Do you know why it fails?

Is the < or > the incorrect ASCII character?

-Jaben

From: Neeraj Ladkani [mailto:neeraj.ladk...@gmail.com]
Sent: Saturday, August 23, 2014 1:24 PM
To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: Regarding commit: ShellPkg: Update 'pci' command for updated class 
codes
Importance: High

Hi Jaben,

The recent commit f056e4c18047e9a0157a915175d07afbd8b8c581(Fri Aug 22 17:02:11) 
is broken on GCC 4.7,

+  {
+0x20,
+L"Ethernet (802.11a <96> 5 GHz)",
+PCIBlankEntry
+  },
+  {
+0x21,
+L"Ethernet (802.11b <96> 2.4 GHz)",
+PCIBlankEntry
+  },

Reverting this push builds fine on GCC 4.7



Thanks
Neeraj

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch][ShellPkg]Fix invalid character in ShellPkg

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

From: Qiu, Shumin
Sent: Sunday, August 24, 2014 9:33 PM
To: Carsey, Jaben
Cc: 'edk2-devel@lists.sourceforge.net'
Subject: [edk2][Patch][ShellPkg]Fix invalid character in ShellPkg
Importance: High

Hi Jaben,
Can you help to review this patch?

For Invalid character '-' in Pci.c line 806 and line 8011, using ASCII encoding 
byte 0x2d to replace.

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

Thanks
Shumin

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] another build failure

[Gabriel L. Somlo]

Hi,

Apparently, commit f056e4c18047e9a0157a915175d07afbd8b8c581 causes
the build process to fail. I use Fedora 20 with the following command
line:

build -a X64 -t GCC48 -p OvmfPkg/OvmfPkgX64.dsc

The commit details are:

commit f056e4c18047e9a0157a915175d07afbd8b8c581
Author: Jaben Carsey 
Date:   Fri Aug 22 17:02:11 2014 +

ShellPkg: Update 'pci' command for updated class codes

This updated the strings to be compliant with PCI CODE AND
ID ASSIGNMENT SPECIFICATION 1.5.

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15885 
6f19259b-4bc3-4df7-8a09-765794883524

And the error I get is shown below:

"/usr/bin/gcc" -g -fshort-wchar -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h 
-DSTRING_ARRAY_NAME=UefiShellDebug1CommandsLibStrings -m64 -fno-stack-protector 
"-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone 
-Wno-address -mcmodel=large -Wno-address -Wno-unused-but-set-variable -mno-mmx 
-mno-sse -o 
/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib/OUTPUT/./Pci.obj
 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit
 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit
 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView
 -I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib/DEBUG
 -I/home/somlo/KVM-OSX/SCRATCH/edk2/MdePkg 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdePkg/Include 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdePkg/Include/X64 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Include 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdeModulePkg 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdeModulePkg/Include 
/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c:806:5:
 error: converting to execution character set: Invalid or incomplete multibyte 
or wide character
 L"Ethernet (802.11a ??? 5 GHz)",
 ^
/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c:811:5:
 error: converting to execution character set: Invalid or incomplete multibyte 
or wide character
 L"Ethernet (802.11b ??? 2.4 GHz)",
 ^
make: *** 
[/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib/OUTPUT/Pci.obj]
 Error 1


build.py...
 : error 7000: Failed to execute command
make tbuild 
[/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib]


build.py...
 : error F002: Failed to build module

/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
 [X64, GCC48, DEBUG]

- Failed -


Thanks much,
--Gabriel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

[El-Haj-Mahmoud, Samer]

Dear MdeModulePkg maintainers,

Please find the attached patch that adds a new function 
HiiCreateGuidLabelOpCode() to HiiLib


Add a new function HiiCreateGuidLabelOpCode() to HiiLib to help with creation 
of Label IFR op-codes dynamically


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



HiiCreateGuidLabelOpCode.patch
Description: HiiCreateGuidLabelOpCode.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call alignment

[El-Haj-Mahmoud, Samer]

Dear MdeModulePkg maintainers,

Please find the attached patch to fix a stack alignment in EBC DXE interpreter 
for X64 native calls:


Fix EBC X64 native call to be 16-byte aligned. From MSDN x64 Software 
Conventions:

"The stack will always be maintained 16-byte aligned,

except within the prolog (for example, after the return address is pushed),

and except where indicated in Function Types for a certain class of frame 
functions."


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



EbcLowLevel.asm_x64_stack_alignment.patch
Description: EbcLowLevel.asm_x64_stack_alignment.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot issue

[Richardson, Brian]

What is the platform hardware configuration?

Thanks ... br
---
Brian Richardson -- brian.richard...@intel.com -- Twitter: intel_brian

From: ritul guru (riguru) [mailto:rig...@cisco.com]
Sent: Monday, August 25, 2014 9:42 AM
To: edk2-devel@lists.sourceforge.net
Cc: Richardson, Brian
Subject: RE: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot 
issue

Hi Brian,
Yes, I have tried booting from fs0:\EFI\Microsoft\Boot\BOOTMGFW.efi,
But it also gave the save Unsupported Error.

And I have just verified that OS is not calling ExitBootServices() means this 
error is coming before call to ExitBootServices().
Could there be issue while OS installation as the OS driver which detected the 
lun is development recently?

Regards,
Ritul

From: Richardson, Brian [mailto:brian.richard...@intel.com]
Sent: Monday, August 25, 2014 6:58 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot 
issue

Once the OS is installed, the primary loader is in the EFI\Microsoft directory.

Thanks ... br
---
Brian Richardson -- 
brian.richard...@intel.com -- Twitter: 
intel_brian

From: ritul guru (riguru) [mailto:rig...@cisco.com]
Sent: Monday, August 25, 2014 7:15 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Error Reported: Unsupported : windows server 2012 R2 boot issue

Hi,
I am trying to install and boot from win2012 R2 UEFI OS.
I could install this OS in UEFI mode properly and but while booting I.e. 
executing the BOOTX64.efi from UEFI shell getting below error:

[cid:image001.png@01CFC060.338DACF0]


What could be the issue here?


Regards,
Ritul

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function allocation

[El-Haj-Mahmoud, Samer]

Dear MdeModulePkg maintainers,

Please find the attached patch to fix an issue in the EBC DXE interpreter for 
X64 native function prolog.


Fix X64 native function call prolog. Prepare space for at least 4 arguments,

even if the native function's arguments are less than 4.



>From MSDN x64 Software Conventions, Overview of x64 Calling Conventions:

"The caller is responsible for allocating space for parameters to the

callee, and must always allocate sufficient space for the 4 register

parameters, even if the callee doesn't have that many parameters.

This aids in the simplicity of supporting C unprototyped functions,

and vararg C/C++ functions."


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



EbcLowLevel.asm_x64_function_allocation.patch
Description: EbcLowLevel.asm_x64_function_allocation.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function allocation

[Yao, Jiewen]

Hi Samer
Thanks for the contribution for 2 EBC bug fixes. Below is my comments:


1)   It looks they are bug, so would you mind to share us the information: 
how you find the bug, and how you validate the fix?


2)   I found below line has NON-ASCII char, please help to correct it.
+  ;   parameters, even if the callee doesn�t have that many parameters.


3)   Please help to generate patch for GCC .S file, too.

Thank you
Yao, Jiewen

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Monday, August 25, 2014 9:30 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function 
allocation

Dear MdeModulePkg maintainers,

Please find the attached patch to fix an issue in the EBC DXE interpreter for 
X64 native function prolog.


Fix X64 native function call prolog. Prepare space for at least 4 arguments,

even if the native function's arguments are less than 4.



From MSDN x64 Software Conventions, Overview of x64 Calling Conventions:

“The caller is responsible for allocating space for parameters to the

callee, and must always allocate sufficient space for the 4 register

parameters, even if the callee doesn’t have that many parameters.

This aids in the simplicity of supporting C unprototyped functions,

and vararg C/C++ functions.”


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] another build failure

[Carsey, Jaben]

There is a patch already outstanding on the mailing list that fixes this 
invalid character.

Thanks!
-Jaben

-Original Message-
From: Gabriel L. Somlo [mailto:gso...@gmail.com] 
Sent: Monday, August 25, 2014 9:10 AM
To: edk2-devel@lists.sourceforge.net
Cc: Carsey, Jaben
Subject: another build failure

Hi,

Apparently, commit f056e4c18047e9a0157a915175d07afbd8b8c581 causes
the build process to fail. I use Fedora 20 with the following command
line:

build -a X64 -t GCC48 -p OvmfPkg/OvmfPkgX64.dsc

The commit details are:

commit f056e4c18047e9a0157a915175d07afbd8b8c581
Author: Jaben Carsey 
Date:   Fri Aug 22 17:02:11 2014 +

ShellPkg: Update 'pci' command for updated class codes

This updated the strings to be compliant with PCI CODE AND
ID ASSIGNMENT SPECIFICATION 1.5.

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15885 
6f19259b-4bc3-4df7-8a09-765794883524

And the error I get is shown below:

"/usr/bin/gcc" -g -fshort-wchar -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h 
-DSTRING_ARRAY_NAME=UefiShellDebug1CommandsLibStrings -m64 -fno-stack-protector 
"-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone 
-Wno-address -mcmodel=large -Wno-address -Wno-unused-but-set-variable -mno-mmx 
-mno-sse -o 
/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib/OUTPUT/./Pci.obj
 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit
 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit
 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView
 -I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib/DEBUG
 -I/home/somlo/KVM-OSX/SCRATCH/edk2/MdePkg 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdePkg/Include 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdePkg/Include/X64 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Include 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdeModulePkg 
-I/home/somlo/KVM-OSX/SCRATCH/edk2/MdeModulePkg/Include 
/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c:806:5:
 error: converting to execution character set: Invalid or incomplete multibyte 
or wide character
 L"Ethernet (802.11a � 5 GHz)",
 ^
/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c:811:5:
 error: converting to execution character set: Invalid or incomplete multibyte 
or wide character
 L"Ethernet (802.11b � 2.4 GHz)",
 ^
make: *** 
[/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib/OUTPUT/Pci.obj]
 Error 1


build.py...
 : error 7000: Failed to execute command
make tbuild 
[/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib]


build.py...
 : error F002: Failed to build module

/home/somlo/KVM-OSX/SCRATCH/edk2/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
 [X64, GCC48, DEBUG]

- Failed -


Thanks much,
--Gabriel
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for updated class codes

[Andrew Fish]

On Aug 25, 2014, at 8:41 AM, Carsey, Jaben  wrote:

> Do you know why it fails?
>  
> Is the < or > the incorrect ASCII character?
>  

As Lasszio mentioned <96> is not a valid UTF-8 encoding. U+0096 is C2 96 in 
UTF-8. Not to mention U+0096 is a  character. So the file contains 
some non portable encoding. 

Thanks,

Andrew Fish

> -Jaben
>  
> From: Neeraj Ladkani [mailto:neeraj.ladk...@gmail.com] 
> Sent: Saturday, August 23, 2014 1:24 PM
> To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
> Subject: Regarding commit: ShellPkg: Update 'pci' command for updated class 
> codes
> Importance: High
>  
> Hi Jaben, 
>  
> The recent commit f056e4c18047e9a0157a915175d07afbd8b8c581(Fri Aug 22 
> 17:02:11) is broken on GCC 4.7, 
>  
> +  {
> +0x20,
> +L"Ethernet (802.11a <96> 5 GHz)",
> +PCIBlankEntry
> +  },
> +  {
> +0x21,
> +L"Ethernet (802.11b <96> 2.4 GHz)",
> +PCIBlankEntry
> +  },
>  
> Reverting this push builds fine on GCC 4.7
>  
>  
>  
> Thanks 
> Neeraj
>  
> --
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for updated class codes

[Carsey, Jaben]

I realized that after I saw the other email.  There is an outstanding patch on 
the mailing list.  Should get committed tonight.

-Jaben

From: Andrew Fish [mailto:af...@apple.com]
Sent: Monday, August 25, 2014 9:52 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for 
updated class codes


On Aug 25, 2014, at 8:41 AM, Carsey, Jaben 
mailto:jaben.car...@intel.com>> wrote:


Do you know why it fails?

Is the < or > the incorrect ASCII character?


As Lasszio mentioned <96> is not a valid UTF-8 encoding. U+0096 is C2 96 in 
UTF-8. Not to mention U+0096 is a  character. So the file contains 
some non portable encoding.

Thanks,

Andrew Fish


-Jaben

From: Neeraj Ladkani [mailto:neeraj.ladk...@gmail.com]
Sent: Saturday, August 23, 2014 1:24 PM
To: edk2-devel@lists.sourceforge.net; 
Carsey, Jaben
Subject: Regarding commit: ShellPkg: Update 'pci' command for updated class 
codes
Importance: High

Hi Jaben,

The recent commit f056e4c18047e9a0157a915175d07afbd8b8c581(Fri Aug 22 17:02:11) 
is broken on GCC 4.7,

+  {
+0x20,
+L"Ethernet (802.11a <96> 5 GHz)",
+PCIBlankEntry
+  },
+  {
+0x21,
+L"Ethernet (802.11b <96> 2.4 GHz)",
+PCIBlankEntry
+  },

Reverting this push builds fine on GCC 4.7



Thanks
Neeraj

--
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for updated class codes

[Jordan Justen]

On Mon, Aug 25, 2014 at 10:01 AM, Carsey, Jaben  wrote:
> I realized that after I saw the other email.  There is an outstanding patch
> on the mailing list.  Should get committed tonight.

Jaben,

I tested Qiu's patch, and it seems pretty trivial (unlikely to break
anything). Can I commit it to ShellPkg?

I did modify the commit message slightly:
===
ShellPkg: Replace non-ASCII character in Pci.c to fix GCC build error

For Invalid character ‘-’ in Pci.c line 806 and line 811, using ASCII
encoding byte 0x2d to replace.

Example error from GCC 4.9:

ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c:806:5: error:
converting to execution character set: Invalid or incomplete multibyte
or wide character
 L"Ethernet (802.11a � 5 GHz)",
 ^

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
Reviewed-by: Jaben Carsey 
Tested-by: Jordan Justen 
===

-Jordan

> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Monday, August 25, 2014 9:52 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for
> updated class codes
>
>
>
>
>
> On Aug 25, 2014, at 8:41 AM, Carsey, Jaben  wrote:
>
>
>
> Do you know why it fails?
>
>
>
> Is the < or > the incorrect ASCII character?
>
>
>
>
>
> As Lasszio mentioned <96> is not a valid UTF-8 encoding. U+0096 is C2 96 in
> UTF-8. Not to mention U+0096 is a  character. So the file contains
> some non portable encoding.
>
>
>
> Thanks,
>
>
>
> Andrew Fish
>
>
>
> -Jaben
>
>
>
> From: Neeraj Ladkani [mailto:neeraj.ladk...@gmail.com]
> Sent: Saturday, August 23, 2014 1:24 PM
> To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
> Subject: Regarding commit: ShellPkg: Update 'pci' command for updated class
> codes
> Importance: High
>
>
>
> Hi Jaben,
>
>
>
> The recent commit f056e4c18047e9a0157a915175d07afbd8b8c581(Fri Aug 22
> 17:02:11) is broken on GCC 4.7,
>
>
>
> +  {
>
> +0x20,
>
> +L"Ethernet (802.11a <96> 5 GHz)",
>
> +PCIBlankEntry
>
> +  },
>
> +  {
>
> +0x21,
>
> +L"Ethernet (802.11b <96> 2.4 GHz)",
>
> +PCIBlankEntry
>
> +  },
>
>
>
> Reverting this push builds fine on GCC 4.7
>
>
>
>
>
>
>
> Thanks
>
> Neeraj
>
>
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for updated class codes

[Carsey, Jaben]

Go ahead.

-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Monday, August 25, 2014 10:20 AM
To: Carsey, Jaben; Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for 
updated class codes
Importance: High

On Mon, Aug 25, 2014 at 10:01 AM, Carsey, Jaben  wrote:
> I realized that after I saw the other email.  There is an outstanding patch
> on the mailing list.  Should get committed tonight.

Jaben,

I tested Qiu's patch, and it seems pretty trivial (unlikely to break
anything). Can I commit it to ShellPkg?

I did modify the commit message slightly:
===
ShellPkg: Replace non-ASCII character in Pci.c to fix GCC build error

For Invalid character ‘-’ in Pci.c line 806 and line 811, using ASCII
encoding byte 0x2d to replace.

Example error from GCC 4.9:

ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c:806:5: error:
converting to execution character set: Invalid or incomplete multibyte
or wide character
 L"Ethernet (802.11a � 5 GHz)",
 ^

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
Reviewed-by: Jaben Carsey 
Tested-by: Jordan Justen 
===

-Jordan

> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Monday, August 25, 2014 9:52 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for
> updated class codes
>
>
>
>
>
> On Aug 25, 2014, at 8:41 AM, Carsey, Jaben  wrote:
>
>
>
> Do you know why it fails?
>
>
>
> Is the < or > the incorrect ASCII character?
>
>
>
>
>
> As Lasszio mentioned <96> is not a valid UTF-8 encoding. U+0096 is C2 96 in
> UTF-8. Not to mention U+0096 is a  character. So the file contains
> some non portable encoding.
>
>
>
> Thanks,
>
>
>
> Andrew Fish
>
>
>
> -Jaben
>
>
>
> From: Neeraj Ladkani [mailto:neeraj.ladk...@gmail.com]
> Sent: Saturday, August 23, 2014 1:24 PM
> To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
> Subject: Regarding commit: ShellPkg: Update 'pci' command for updated class
> codes
> Importance: High
>
>
>
> Hi Jaben,
>
>
>
> The recent commit f056e4c18047e9a0157a915175d07afbd8b8c581(Fri Aug 22
> 17:02:11) is broken on GCC 4.7,
>
>
>
> +  {
>
> +0x20,
>
> +L"Ethernet (802.11a <96> 5 GHz)",
>
> +PCIBlankEntry
>
> +  },
>
> +  {
>
> +0x21,
>
> +L"Ethernet (802.11b <96> 2.4 GHz)",
>
> +PCIBlankEntry
>
> +  },
>
>
>
> Reverting this push builds fine on GCC 4.7
>
>
>
>
>
>
>
> Thanks
>
> Neeraj
>
>
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call alignment

[Kinney, Michael D]

Samer,

Can you please provide the details on how to reproduce an incorrect stack 
alignment.

It has been a long time since we have worked on this code, and I recall 
reviewing the stack alignment carefully at that time.

It is possible that the code that called an EBC function has misaligned the 
stack.  It is also possible that use of a newer/different compiler/assemble 
could be causing some issues.

Thanks,

Mike

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Monday, August 25, 2014 9:22 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call 
alignment

Dear MdeModulePkg maintainers,

Please find the attached patch to fix a stack alignment in EBC DXE interpreter 
for X64 native calls:


Fix EBC X64 native call to be 16-byte aligned. From MSDN x64 Software 
Conventions:

"The stack will always be maintained 16-byte aligned,

except within the prolog (for example, after the return address is pushed),

and except where indicated in Function Types for a certain class of frame 
functions."


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function allocation

[El-Haj-Mahmoud, Samer]

Jiewen,

We found the bugs during validation of an HP storage adapter that uses an EBC 
driver. When running the EBC driver on an X64 server with certain optimizations 
disabled in the UEFI system firmware (specifically, /GL and /LTCG removed), the 
driver hangs (sometimes with an exception). These two fixes allowed the EBC 
driver to run on system firmware with and without those optimizations.

The corrected patch (non-ASCII characters) is attached.

Note that I have not ported the change to EbcLowLevel.S since I have no way to 
verify if it builds correctly. Can you please help with that?

Thanks,
--Samer


From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Monday, August 25, 2014 11:47 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function 
allocation

Hi Samer
Thanks for the contribution for 2 EBC bug fixes. Below is my comments:


1)  It looks they are bug, so would you mind to share us the information: 
how you find the bug, and how you validate the fix?


2)  I found below line has NON-ASCII char, please help to correct it.
+  ;   parameters, even if the callee doesn�t have that many parameters.


3)  Please help to generate patch for GCC .S file, too.

Thank you
Yao, Jiewen

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Monday, August 25, 2014 9:30 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function 
allocation

Dear MdeModulePkg maintainers,

Please find the attached patch to fix an issue in the EBC DXE interpreter for 
X64 native function prolog.


Fix X64 native function call prolog. Prepare space for at least 4 arguments,

even if the native function's arguments are less than 4.



From MSDN x64 Software Conventions, Overview of x64 Calling Conventions:

“The caller is responsible for allocating space for parameters to the

callee, and must always allocate sufficient space for the 4 register

parameters, even if the callee doesn’t have that many parameters.

This aids in the simplicity of supporting C unprototyped functions,

and vararg C/C++ functions.”


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



EbcLowLevel.asm.patch
Description: EbcLowLevel.asm.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call alignment

[El-Haj-Mahmoud, Samer]

Mike,

I responded to Jiewen on another thread (for the other EBC DXE  issue):

We found the bugs during validation of an HP storage adapter that uses an EBC 
driver. When running the EBC driver on an X64 server with certain optimizations 
disabled in the UEFI system firmware (specifically, /GL and /LTCG removed), the 
driver hangs (sometimes with an exception). These two fixes allowed the EBC 
driver to run on system firmware with and without those compiler optimizations.



From: El-Haj-Mahmoud, Samer
Sent: Monday, August 25, 2014 11:22 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call 
alignment

Dear MdeModulePkg maintainers,

Please find the attached patch to fix a stack alignment in EBC DXE interpreter 
for X64 native calls:


Fix EBC X64 native call to be 16-byte aligned. From MSDN x64 Software 
Conventions:

"The stack will always be maintained 16-byte aligned,

except within the prolog (for example, after the return address is pushed),

and except where indicated in Function Types for a certain class of frame 
functions."


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Duplicate PCDs in DSC files

[El-Haj-Mahmoud, Samer]

It looks like the build tools will not warn you (or stop with an error) if 
there are multiple declarations of the same PCD in the DSC file. In fact, the 
same PCD could be initialized multiple times using different values and 
different types (Fixed vs. Dynamic for instance), and the build tools will 
silently pick the last instance of the PCD in the DSC File.

We just finished debugging a nasty issue caused by duplicate PCDs, and it would 
have been nice to prevent this to begin with! Looks to me like a bug in the 
tool.

Can we add the ability to break the build if there are duplicate PCD instances 
in the DSC file?




Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call alignment

[Kinney, Michael D]

Samer,

Can you please verify that the stack is aligned in native code before calling 
the EBC function where this fix was required?

If the native stack is always aligned correctly, can you please provide a small 
test case that reproduces the issue along with all the compiler/linker flags 
used.

Thanks,

Mike

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Monday, August 25, 2014 10:40 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function 
call alignment

Mike,

I responded to Jiewen on another thread (for the other EBC DXE  issue):

We found the bugs during validation of an HP storage adapter that uses an EBC 
driver. When running the EBC driver on an X64 server with certain optimizations 
disabled in the UEFI system firmware (specifically, /GL and /LTCG removed), the 
driver hangs (sometimes with an exception). These two fixes allowed the EBC 
driver to run on system firmware with and without those compiler optimizations.



From: El-Haj-Mahmoud, Samer
Sent: Monday, August 25, 2014 11:22 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call 
alignment

Dear MdeModulePkg maintainers,

Please find the attached patch to fix a stack alignment in EBC DXE interpreter 
for X64 native calls:


Fix EBC X64 native call to be 16-byte aligned. From MSDN x64 Software 
Conventions:

"The stack will always be maintained 16-byte aligned,

except within the prolog (for example, after the return address is pushed),

and except where indicated in Function Types for a certain class of frame 
functions."


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch][ShellPkg]Fix invalid character in ShellPkg

[Jordan Justen]

On Mon, Aug 25, 2014 at 8:40 AM, Carsey, Jaben  wrote:
> Reviewed-by: Jaben Carsey 

Tested-by: Jordan Justen 
committed in r15889

> From: Qiu, Shumin
> Sent: Sunday, August 24, 2014 9:33 PM
> To: Carsey, Jaben
> Cc: 'edk2-devel@lists.sourceforge.net'
> Subject: [edk2][Patch][ShellPkg]Fix invalid character in ShellPkg

Was this intended to be the first line of your commit message?

If so, I think
"[PATCH] ShellPkg: Fix invalid character"

Would have better followed the preferred format:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

(Usually, items in [] are not considered part of the commit message.)

-Jordan

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg: Fix bug in DisplayEngine - global width constants init order

[El-Haj-Mahmoud, Samer]

Dear MdeModulePkg maintainers,

Please bug in DisplayEngine that caused an issue with displaying long strings 
on the top level page (typically FrontPage) when the page is displayed the 
first time.


The original code does not initialize the global width constants before 
creating menu options. That caused an issue when long strings are used in the 
first HII form, but only when displayed for the first time.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



DisplayEngine.patch
Description: DisplayEngine.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 02/10] PeiCore: allow FVs residing at physical address 0x0

[Ard Biesheuvel]

In the ARM world, it is quite common to have NOR flash at 0x0 and DRAM
elsewhere. Don't treat pointers to FVs residing there as invalid NULL pointers
but as a valid 0x0 physical address.

Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Core/Pei/FwVol/FwVol.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c 
b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
index fe876ed393a9..8186a80276d3 100644
--- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
+++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
@@ -1422,10 +1422,6 @@ PeiFfsFvPpiProcessVolume (
   
   ASSERT (FvHandle != NULL);
   
-  if (Buffer == NULL) {
-return EFI_VOLUME_CORRUPTED;
-  }
-  
   //
   // The build-in EFI_PEI_FIRMWARE_VOLUME_PPI for FFS2/FFS3 support 
memory-mapped
   // FV image and the handle is pointed to Fv image's buffer.
@@ -1712,7 +1708,7 @@ PeiFfsFvPpiGetVolumeInfo (
   EFI_FIRMWARE_VOLUME_HEADER FwVolHeader;
   EFI_FIRMWARE_VOLUME_EXT_HEADER *FwVolExHeaderInfo;
 
-  if ((VolumeInfo == NULL) || (FvHandle == NULL)) {
+  if (VolumeInfo == NULL) {
 return EFI_INVALID_PARAMETER;
   }
   
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 05/10] ArmPkg: allow dynamic GIC base addresses

[Ard Biesheuvel]

Allow the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase to be redeclared
as PcdsDynamic by the platform, so virtual machines can set these
properties during boot. As the PcdGet32() calls now call into the
PCD database, cache the values that are required during the handling
of interrupts.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec   | 15 ---
 ArmPkg/Drivers/ArmGic/ArmGicDxe.c   | 34 --
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf |  4 +++-
 ArmPkg/Library/BdsLib/BdsLib.inf|  2 +-
 4 files changed, 32 insertions(+), 23 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 9229c07df53c..b654e7ca4552 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -68,6 +68,14 @@
   # Define if the Power State Coordination Interface (PSCI) is supported by 
the Platform Trusted Firmware
   gArmTokenSpaceGuid.PcdArmPsciSupport|FALSE|BOOLEAN|0x0033
 
+[PcdsDynamic.common,PcdsFixedAtBuild.common]
+  #
+  # ARM Generic Interrupt Controller
+  #
+  gArmTokenSpaceGuid.PcdGicDistributorBase|0|UINT32|0x000C
+  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0|UINT32|0x000D
+  gArmTokenSpaceGuid.PcdGicSgiIntId|0|UINT32|0x0025
+
 [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdTrustzoneSupport|FALSE|BOOLEAN|0x0006
 
@@ -81,13 +89,6 @@
   gArmTokenSpaceGuid.PcdCpuResetAddress|0x|UINT32|0x0005
 
   #
-  # ARM Generic Interrupt Controller
-  #
-  gArmTokenSpaceGuid.PcdGicDistributorBase|0|UINT32|0x000C
-  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0|UINT32|0x000D
-  gArmTokenSpaceGuid.PcdGicSgiIntId|0|UINT32|0x0025
-
-  #
   # ARM Secure Firmware PCDs
   #
   gArmTokenSpaceGuid.PcdSecureFdBaseAddress|0|UINT32|0x0015
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.c 
b/ArmPkg/Drivers/ArmGic/ArmGicDxe.c
index 111ce144385b..42079f9e1f3a 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.c
+++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.c
@@ -47,6 +47,9 @@ extern EFI_HARDWARE_INTERRUPT_PROTOCOL 
gHardwareInterruptProtocol;
 //
 EFI_EVENT EfiExitBootServicesEvent  = (EFI_EVENT)NULL;
 
+UINTN mGicInterruptInterfaceBase= 0;
+UINTN mGicDistributorBase   = 0;
+
 // Maximum Number of Interrupts
 UINTN mGicNumInterrupts = 0;
 
@@ -124,7 +127,7 @@ EnableInterruptSource (
   RegShift = Source % 32;
 
   // Write set-enable register
-  MmioWrite32 (PcdGet32(PcdGicDistributorBase) + ARM_GIC_ICDISER + 
(4*RegOffset), 1 << RegShift);
+  MmioWrite32 (mGicDistributorBase + ARM_GIC_ICDISER + (4*RegOffset), 1 << 
RegShift);
   
   return EFI_SUCCESS;
 }
@@ -159,7 +162,7 @@ DisableInterruptSource (
   RegShift = Source % 32;
 
   // Write set-enable register
-  MmioWrite32 (PcdGet32(PcdGicDistributorBase) + ARM_GIC_ICDICER + 
(4*RegOffset), 1 << RegShift);
+  MmioWrite32 (mGicDistributorBase + ARM_GIC_ICDICER + (4*RegOffset), 1 << 
RegShift);
   
   return EFI_SUCCESS;
 }
@@ -195,7 +198,7 @@ GetInterruptSourceState (
   RegOffset = Source / 32;
   RegShift = Source % 32;
 
-  if ((MmioRead32 (PcdGet32(PcdGicDistributorBase) + ARM_GIC_ICDISER + 
(4*RegOffset)) & (1<= mGicNumInterrupts) {
@@ -315,11 +318,11 @@ ExitBootServicesEvent (
   }
 
   // Disable Gic Interface
-  MmioWrite32 (PcdGet32(PcdGicInterruptInterfaceBase) + ARM_GIC_ICCICR, 0x0);
-  MmioWrite32 (PcdGet32(PcdGicInterruptInterfaceBase) + ARM_GIC_ICCPMR, 0x0);
+  MmioWrite32 (mGicInterruptInterfaceBase + ARM_GIC_ICCICR, 0x0);
+  MmioWrite32 (mGicInterruptInterfaceBase + ARM_GIC_ICCPMR, 0x0);
 
   // Disable Gic Distributor
-  MmioWrite32 (PcdGet32(PcdGicDistributorBase) + ARM_GIC_ICDDCR, 0x0);
+  MmioWrite32 (mGicDistributorBase + ARM_GIC_ICDDCR, 0x0);
 }
 
 /**
@@ -349,7 +352,10 @@ InterruptDxeInitialize (
   // Make sure the Interrupt Controller Protocol is not already installed in 
the system.
   ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, &gHardwareInterruptProtocolGuid);
 
-  mGicNumInterrupts = ArmGicGetMaxNumInterrupts 
(PcdGet32(PcdGicDistributorBase));
+  mGicInterruptInterfaceBase = PcdGet32(PcdGicInterruptInterfaceBase);
+  mGicDistributorBase = PcdGet32(PcdGicDistributorBase);
+  mGicNumInterrupts = ArmGicGetMaxNumInterrupts (mGicDistributorBase);
+  ASSERT(mGicNumInterrupts < 4096);
 
   for (Index = 0; Index < mGicNumInterrupts; Index++) {
 DisableInterruptSource (&gHardwareInterruptProtocol, Index);
@@ -358,7 +364,7 @@ InterruptDxeInitialize (
 RegOffset = Index / 4;
 RegShift = (Index % 4) * 8;
 MmioAndThenOr32 (
-  PcdGet32(PcdGicDistributorBase) + ARM_GIC_ICDIPR + (4*RegOffset),
+  mGicDistributorBase + ARM_GIC_ICDIPR + (4*RegOffset),
   ~(0xff << RegShift), 
   ARM_GIC_DEFAULT_PRIORITY << RegShift
   );
@@ -387,16 +393,16 @@ InterruptDxeInitialize (
   }
 
   // Set binary point reg to 0x7 (no preemption)
-  MmioWrite32 (PcdGet32(PcdGicInterruptInterfaceBase) + ARM_GIC_ICCBPR, 0x7);
+  MmioWrite32 (mGicInterruptInterfaceBase +

[edk2] [PATCH 04/10] ArmPkg: allow dynamically discovered virtual timer interrupt

[Ard Biesheuvel]

To support booting on virtual machines whose interrupt routing is
discovered from the device tree, allow the interrupt numbers to
be redeclared as PcdsDynamic by the platform .dsc
---
 ArmPkg/ArmPkg.dec|  2 ++
 ArmPkg/Drivers/TimerDxe/TimerDxe.c   |  6 +-
 ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c | 16 
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 1d896892dafc..9229c07df53c 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -136,6 +136,8 @@
   # Maximum file size for TFTP servers that do not support 'tsize' extension
   gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x
 
+
+[PcdsFixedAtBuild.common,PcdsDynamic.common]
   #
   # ARM Architectural Timer
   #
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c 
b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
index be346bf89c51..670c4431e5a1 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
@@ -36,6 +36,8 @@ EFI_EVENT EfiExitBootServicesEvent = 
(EFI_EVENT)NULL;
 // The current period of the timer interrupt
 UINT64 mTimerPeriod = 0;
 
+UINTN mArmArchTimerTimerFreq = 0;
+
 // Cached copy of the Hardware Interrupt protocol instance
 EFI_HARDWARE_INTERRUPT_PROTOCOL *gInterrupt = NULL;
 
@@ -144,7 +146,7 @@ TimerDriverSetTimerPeriod (
 // Convert TimerPeriod to micro sec units
 TimerTicks = DivU64x32 (TimerPeriod, 10);
 
-TimerTicks = MultU64x32 (TimerTicks, 
(PcdGet32(PcdArmArchTimerFreqInHz)/100));
+TimerTicks = MultU64x32 (TimerTicks, mArmArchTimerTimerFreq);
 
 ArmArchTimerSetTimerVal((UINTN)TimerTicks);
 
@@ -343,6 +345,8 @@ TimerInitialize (
   Status = TimerDriverSetTimerPeriod (&gTimer, 0);
   ASSERT_EFI_ERROR (Status);
 
+  mArmArchTimerTimerFreq = ArmArchTimerGetTimerFreq() / 100;
+
   // Install secure and Non-secure interrupt handlers
   // Note: Because it is not possible to determine the security state of the
   // CPU dynamically, we just install interrupt handler for both sec and 
non-sec
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
index 232d745b3d06..6487dcc441e4 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
@@ -175,7 +175,7 @@ ArmArchTimerEnableTimer (
 {
   UINTN TimerCtrlReg;
 
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerReadReg (CntvCtl, (VOID *)&TimerCtrlReg);
 /* FIXME: We need to clear IMASK when under KVM because KVM sets it. 
Unclear if this is a bug ... */
 TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
@@ -196,7 +196,7 @@ ArmArchTimerDisableTimer (
 {
   UINTN TimerCtrlReg;
 
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerReadReg (CntvCtl, (VOID *)&TimerCtrlReg);
 TimerCtrlReg &= ~ARM_ARCH_TIMER_ENABLE;
 ArmArchTimerWriteReg (CntvCtl, (VOID *)&TimerCtrlReg);
@@ -234,7 +234,7 @@ ArmArchTimerGetTimerVal (
 )
 {
   UINTN ArchTimerVal;
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerReadReg (CntvTval, (VOID *)&ArchTimerVal);
   } else {
 ArmArchTimerReadReg (CntpTval, (VOID *)&ArchTimerVal);
@@ -250,7 +250,7 @@ ArmArchTimerSetTimerVal (
 IN   UINTN   Val
 )
 {
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerWriteReg (CntvTval, (VOID *)&Val);
   } else {
 ArmArchTimerWriteReg (CntpTval, (VOID *)&Val);
@@ -264,7 +264,7 @@ ArmArchTimerGetSystemCount (
 )
 {
   UINT64 SystemCount;
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerReadReg (CntvCt, (VOID *)&SystemCount);
   } else {
 ArmArchTimerReadReg (CntPct, (VOID *)&SystemCount);
@@ -281,7 +281,7 @@ ArmArchTimerGetTimerCtrlReg (
 {
   UINTN  Val;
 
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerReadReg (CntvCtl, (VOID *)&Val);
   } else {
 ArmArchTimerReadReg (CntpCtl, (VOID *)&Val);
@@ -296,7 +296,7 @@ ArmArchTimerSetTimerCtrlReg (
 UINTN Val
 )
 {
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerWriteReg (CntvCtl, (VOID *)&Val);
   } else {
 ArmArchTimerWriteReg (CntpCtl, (VOID *)&Val);
@@ -309,7 +309,7 @@ ArmArchTimerSetCompareVal (
 IN   UINT64   Val
 )
 {
-  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+  if (FixedPcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
 ArmArchTimerWriteReg (CntvCval, (VOID *)&Val);
   } else {
 ArmArchTimerWriteReg (CntpCval, (VOID *)

[edk2] [PATCH 00/10] add support for AArch64 QEMU/KVM

[Ard Biesheuvel]

This series adds a platform config to support QEMU based virtual machines,
either in TCG or KVM mode. These virtual machines declare their platform 
configuration by passing a device tree which needs to be parsed by Tianocore
rather than relying on hardcoded peripherals.

Currently, the only assumptions made with respect to the platform config are:
- at least 1 MB of DRAM at 0x4000_
- NOR flash at 0x0
- PL011 UART at 0x900_

Peripherals detected at runtime:
- GIC interrupt controller
- timer interrupt line
- PL031 RTC
- system memory base and size, although changing the base is not currently
  supported
- virtio MMIO transports

There are some dependencies on QEMU and KVM changes that are not yet upstream:
- QEMU: add -bios param and wire it up to NOR flash banks at 0x0 and 0x400_
- QEMU: copy DTB to base of DRAM if no -kernel option is passed
- KVM: add support for CAP_READONLY_MEM
- KVM: advance PC when resuming guest after a WFI

Note that most of the patches are minor ones that make certain peripherals
configurable at runtime. The patch 'ArmPlatformPkg: add support for a
QEMU/mach-virt target' is the primary patch that implements most of the QEMU/KVM
interface logic, most notably parsing of the device tree to set PCDs containing
base addresses etc.

The code was tested in TCG mode on x64_64 and in TCG and KVM mode on a ARMv8
Foundation Model (software emulator)

Ard Biesheuvel (9):
  Add minimal support for passing a device tree image
  PeiCore: allow FVs residing at physical address 0x0
  ArmPkg: allow dynamically discovered virtual timer interrupt
  ArmPkg: allow dynamic GIC base addresses
  ArmPlatformPkg/PrePeiCore: remove GIC related PCDs from unicore
  ArmPlatformPkg: allow dynamically discovered PL031 RTC
  ArmPkg,ArmPlatformPkg: allow dynamic PCDs for memory base and size
  ArmPlatformPkg: add support for a QEMU/mach-virt target
  AArch64-KVM: add support for non-volatile variable store

Michael Casadevall (1):
  ArmPkg/TimerDxe: allow virtual timer to be selected

 ArmPkg/ArmPkg.dec  |  34 +-
 ArmPkg/Drivers/ArmGic/ArmGicDxe.c  |  34 +-
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf|   4 +-
 ArmPkg/Drivers/TimerDxe/TimerDxe.c |  12 +-
 ArmPkg/Drivers/TimerDxe/TimerDxe.inf   |   3 +
 ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c   |  66 +++-
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   |   2 +
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  |   1 +
 ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf|   1 +
 ArmPkg/Library/BdsLib/BdsLib.inf   |   5 +-
 .../AArch64Virtualization-KVM.dsc  | 236 ++
 .../AArch64Virtualization-KVM.fdf  | 301 ++
 .../AArch64Virtualization.dsc.inc  | 354 +
 .../AArch64VirtualizationPkg/Driver/VirtFdt.inf|  60 
 .../AArch64VirtualizationPkg/Driver/VirtFdtDxe.c   | 216 +
 .../Include/Platform/KVM/ArmPlatform.h |  38 +++
 .../AArch64VirtualizationLibKVM/AArch64KVMLib.inf  |  53 +++
 .../Library/AArch64VirtualizationLibKVM/KVM.c  | 127 
 .../AArch64VirtualizationLibKVM/KVMHelper.S|  70 
 .../Library/AArch64VirtualizationLibKVM/KVMMem.c   | 106 ++
 .../AArch64VirtualizationSysConfigLibKVM.c |  95 ++
 .../AArch64VirtualizationSysConfigLibKVM.inf   |  35 ++
 .../Library/NorFlashKVM/NorFlashKVM.c  |  63 
 .../Library/NorFlashKVM/NorFlashKVM.inf|  35 ++
 .../Library/ResetSystemLib/ResetSystemLib.c|  96 ++
 .../Library/ResetSystemLib/ResetSystemLib.inf  |  33 ++
 ArmPlatformPkg/ArmPlatformPkg.dec  |   9 +-
 .../PrePi/PrePiArmPlatformGlobalVariableLib.inf|   7 +-
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf  |   6 +-
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c  |  16 +-
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf|   6 +-
 ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf|   2 -
 ArmPlatformPkg/PrePi/PeiUniCore.inf|   6 +-
 MdeModulePkg/Core/Pei/FwVol/FwVol.c|   6 +-
 MdeModulePkg/MdeModulePkg.dec  |   2 +
 MdeModulePkg/MdeModulePkg.dsc  |   2 +
 .../Universal/Fdt/FdtTableDxe/FdtTableDxe.c|  33 ++
 .../Universal/Fdt/FdtTableDxe/FdtTableDxe.inf  |  48 +++
 MdePkg/Include/Guid/FdtTable.h |  26 ++
 MdePkg/MdePkg.dec  |   3 +
 40 files changed, 2181 insertions(+), 71 deletions(-)
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization.dsc.inc
 create mode 100644 ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdt.inf
 create mode 100644 ArmPlatformPkg/AArch64Virtual

[edk2] [PATCH 06/10] ArmPlatformPkg/PrePeiCore: remove GIC related PCDs from unicore

[Ard Biesheuvel]

Remove the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase from PrePeiCoreUniCore.inf,
as they are not in fact used by the module.

Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf | 2 --
 1 file changed, 2 deletions(-)

diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf 
b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
index f50d21fa6ef4..24f128cb6bd6 100644
--- a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
+++ b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
@@ -73,5 +73,3 @@
   
   gArmPlatformTokenSpaceGuid.PcdPeiGlobalVariableSize
   
-  gArmTokenSpaceGuid.PcdGicDistributorBase
-  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 01/10] Add minimal support for passing a device tree image

[Ard Biesheuvel]

This adds the possibility to include a DTB blob into the firmware image, and
have it installed as a configuration under the correct GUID at UEFI init time.

Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/MdeModulePkg.dec  |  2 +
 MdeModulePkg/MdeModulePkg.dsc  |  2 +
 .../Universal/Fdt/FdtTableDxe/FdtTableDxe.c| 33 +++
 .../Universal/Fdt/FdtTableDxe/FdtTableDxe.inf  | 48 ++
 MdePkg/Include/Guid/FdtTable.h | 26 
 MdePkg/MdePkg.dec  |  3 ++
 6 files changed, 114 insertions(+)
 create mode 100644 MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.c
 create mode 100644 MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.inf
 create mode 100644 MdePkg/Include/Guid/FdtTable.h

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index e04246a2f419..d4d2a423256c 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -692,6 +692,8 @@
   ## Default Creator Revision for ACPI table creation.
   
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision|0x0113|UINT32|0x30001038
 
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFdtImage|{ 
0x66,0x0f,0xe1,0x96,0xa5,0x0f,0x43,0x8c,0xa9,0x50,0xbe,0x6a,0x58,0xb9,0x12,0x1b 
}|VOID*|0x30001041
+
 [PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## This PCD defines the Console output column and the default value is 25 
according to UEFI spec.
   #  This PCD could be set to 0 then console output could be at max column and 
max row.
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index f4733253442b..616387a746c1 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -322,6 +322,8 @@
   
MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.inf
   
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
+  MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.inf
+
 [Components.IA32, Components.X64, Components.IPF]
   MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
   MdeModulePkg/Universal/DebugSupportDxe/DebugSupportDxe.inf
diff --git a/MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.c 
b/MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.c
new file mode 100644
index ..c9b8b4c42464
--- /dev/null
+++ b/MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.c
@@ -0,0 +1,33 @@
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+EFI_STATUS
+EFIAPI
+InitializeFdtTableDxe (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  EFI_STATUS Status;
+  VOID *FdtImageData;
+  UINTN FdtImageSize;
+
+  Status = GetSectionFromAnyFv(PcdGetPtr(PcdFdtImage), EFI_SECTION_RAW, 0,
+&FdtImageData, &FdtImageSize);
+  if (EFI_ERROR(Status))
+return Status;
+
+  DEBUG((EFI_D_ERROR, "InitializeFdtTableDxe: DTB @ 0x%08x\n", FdtImageData));
+
+  return gBS->InstallConfigurationTable(&gEfiFdtTableGuid, FdtImageData);
+}
diff --git a/MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.inf 
b/MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.inf
new file mode 100644
index ..993b778b8f66
--- /dev/null
+++ b/MdeModulePkg/Universal/Fdt/FdtTableDxe/FdtTableDxe.inf
@@ -0,0 +1,48 @@
+## @file
+#  FDT Table Protocol Driver
+#
+#  Copyright (c) 2014, Linaro Ltd. All rights reserved.
+#  This program and the accompanying materials are
+#  licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = FdtTableDxe
+  FILE_GUID  = 261F9737-CDF6-46CE-A9E2-5DD16B957413
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= InitializeFdtTableDxe
+
+[Sources]
+  FdtTableDxe.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  PcdLib
+  UefiDriverEntryPoint
+  DxeServicesLib
+
+[Guids]
+  gEfiFdtTableGuid
+
+[FeaturePcd]
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFdtImage
+
+[Protocols]
+
+[Depex]
+  TRUE
diff --git a/MdePkg/Include/Guid/FdtTable.h b/MdePkg/Include/Guid/FdtTable.h
new file mode 100644
index ..ab2e0bc43940
--- /dev/null
+++ b/MdePkg/Include/Guid/FdtTable.h
@@ -0,0 +1,26 @@
+/** @file
+  GUIDs used to locate the FDT image in the UEFI 2.x system table.
+
+  Copyright (c) 2014 Linaro Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available un

[edk2] [PATCH 08/10] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Ard Biesheuvel]

This changes the definition and a bunch of references to
gArmTokenSpaceGuid.PcdSystemMemoryBase and
gArmTokenSpaceGuid.PcdSystemMemorySize so they can be declared as dynamic PCDs
by the platform. Also, move the non-SEC call to
ArmPlatformInitializeSystemMemory() earlier, so a platform has a chance to set
these PCDs before they are first referenced.

The purpose is allowing dynamically instantiated virtual machines to declare
the system memory by passing a device tree.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec| 12 ++--
 ArmPkg/Library/BdsLib/BdsLib.inf |  3 ++-
 .../PrePi/PrePiArmPlatformGlobalVariableLib.inf  |  7 ---
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf|  6 --
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c| 16 
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf  |  6 --
 ArmPlatformPkg/PrePi/PeiUniCore.inf  |  6 --
 7 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index b654e7ca4552..a9eb856f76ee 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -112,12 +112,6 @@
   gArmTokenSpaceGuid.PcdHypFvBaseAddress|0|UINT32|0x003C
   gArmTokenSpaceGuid.PcdHypFvSize|0|UINT32|0x003D
 
-  # System Memory (DRAM): These PCDs define the region of in-built system 
memory
-  # Some platforms can get DRAM extensions, these additional regions will be 
declared
-  # to UEFI by ArmPlatformLib
-  gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
-  gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
-
   # Use ClusterId + CoreId to identify the PrimaryCore
   gArmTokenSpaceGuid.PcdArmPrimaryCoreMask|0xF03|UINT32|0x0031
   # The Primary Core is ClusterId[0] & CoreId[0]
@@ -139,6 +133,12 @@
 
 
 [PcdsFixedAtBuild.common,PcdsDynamic.common]
+  # System Memory (DRAM): These PCDs define the region of in-built system 
memory
+  # Some platforms can get DRAM extensions, these additional regions will be 
declared
+  # to UEFI by ArmPlatformLib
+  gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
+  gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
+
   #
   # ARM Architectural Timer
   #
diff --git a/ArmPkg/Library/BdsLib/BdsLib.inf b/ArmPkg/Library/BdsLib/BdsLib.inf
index ce9300d00efc..9ebfe20f222a 100644
--- a/ArmPkg/Library/BdsLib/BdsLib.inf
+++ b/ArmPkg/Library/BdsLib/BdsLib.inf
@@ -77,10 +77,11 @@
 [FeaturePcd]
   gArmTokenSpaceGuid.PcdArmPsciSupport
 
-[FixedPcd]
+[Pcd]
   gArmTokenSpaceGuid.PcdSystemMemoryBase
   gArmTokenSpaceGuid.PcdSystemMemorySize
 
+[FixedPcd]
   gArmTokenSpaceGuid.PcdArmMachineType
   gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset
   gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment
diff --git 
a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
 
b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
index 28ba9842856a..e803ca0d6270 100644
--- 
a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
+++ 
b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
@@ -37,9 +37,10 @@
   gArmTokenSpaceGuid.PcdFdBaseAddress
   gArmTokenSpaceGuid.PcdFdSize
 
-  gArmTokenSpaceGuid.PcdSystemMemoryBase
-  gArmTokenSpaceGuid.PcdSystemMemorySize
-
   gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize
   gArmPlatformTokenSpaceGuid.PcdPeiGlobalVariableSize
 
+[Pcd]
+  gArmTokenSpaceGuid.PcdSystemMemoryBase
+  gArmTokenSpaceGuid.PcdSystemMemorySize
+
diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf 
b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
index fb77e4db5d23..ed8e2095e2f9 100755
--- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
+++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
@@ -48,8 +48,6 @@
   gArmTokenSpaceGuid.PcdFdBaseAddress
   gArmTokenSpaceGuid.PcdFdSize
 
-  gArmTokenSpaceGuid.PcdSystemMemoryBase
-  gArmTokenSpaceGuid.PcdSystemMemorySize
   gArmPlatformTokenSpaceGuid.PcdSystemMemoryUefiRegionSize
   
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
@@ -61,6 +59,10 @@
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData
+
+[Pcd]
+  gArmTokenSpaceGuid.PcdSystemMemoryBase
+  gArmTokenSpaceGuid.PcdSystemMemorySize

 [depex]
   TRUE
diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c 
b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c
index c6a6fe64ba81..0a91869b0ed3 100755
--- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c
+++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c
@@ -103,14 +103,6 @@ InitializeMemory (
 
   DEBUG ((EFI_D_ERROR, "Memory Init PEIM Loaded\n"));
 
-  // Ensure PcdSystemMemorySize has been set
-  ASSERT (FixedPcdGet64 (PcdSystemMemorySize) != 0);
-
-  SystemMemoryBase = (UIN

[edk2] [PATCH 07/10] ArmPlatformPkg: allow dynamically discovered PL031 RTC

[Ard Biesheuvel]

Allow the PCDs gArmPlatformTokenSpaceGuid.PcdPL031RtcBase and
gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy PCDs to be
declared as PcdsDynamic by the platform so they can be overridden
during boot.

Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmPlatformPkg.dec | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 26f84180877b..c4f73de2b087 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -109,10 +109,6 @@
   gArmPlatformTokenSpaceGuid.PL011UartInteger|0|UINT32|0x0020
   gArmPlatformTokenSpaceGuid.PL011UartFractional|0|UINT32|0x002D
 
-  ## PL031 RealTimeClock
-  gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
-  gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy|3|UINT32|0x0022
-
   ## PL061 GPIO
   gArmPlatformTokenSpaceGuid.PcdPL061GpioBase|0x0|UINT32|0x0025
   
@@ -146,6 +142,11 @@
   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L""|VOID*|0x001B
   gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L""|VOID*|0x001C
 
+[PcdsFixedAtBuild.common,PcdsDynamic.common]
+  ## PL031 RealTimeClock
+  gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
+  gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy|3|UINT32|0x0022
+
 [PcdsFixedAtBuild.ARM]
   # Stack for CPU Cores in Secure Monitor Mode
   gArmPlatformTokenSpaceGuid.PcdCPUCoresSecMonStackBase|0|UINT32|0x0007
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 03/10] ArmPkg/TimerDxe: allow virtual timer to be selected

[Ard Biesheuvel]

From: Michael Casadevall 

For virtual machines, the physical architected timer may not be available,
so we need to allow the virtual timer to be used instead.

Signed-off-by: Michael Casadevall 
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec |  5 ++
 ArmPkg/Drivers/TimerDxe/TimerDxe.c|  6 +++
 ArmPkg/Drivers/TimerDxe/TimerDxe.inf  |  3 ++
 ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c  | 66 ++-
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf  |  2 +
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf |  1 +
 ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf   |  1 +
 7 files changed, 72 insertions(+), 12 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 14f16b85169a..1d896892dafc 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -143,6 +143,11 @@
   # ARM Architectural Timer Interrupt(GIC PPI) number
   gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum|29|UINT32|0x0035
   gArmTokenSpaceGuid.PcdArmArchTimerIntrNum|30|UINT32|0x0036
+  gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum|27|UINT32|0x0040
+  gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum|26|UINT32|0x0041
+
+  # MC: not really sure what the last value is except I think it needs to be 
unique
+  gArmTokenSpaceGuid.PcdArmArchTimerUseVirtual|FALSE|BOOLEAN|0x003F
 
 [PcdsFixedAtBuild.ARM]
   #
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c 
b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
index a43a10f48cee..be346bf89c51 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
@@ -347,6 +347,12 @@ TimerInitialize (
   // Note: Because it is not possible to determine the security state of the
   // CPU dynamically, we just install interrupt handler for both sec and 
non-sec
   // timer PPI
+  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerVirtIntrNum), TimerInterruptHandler);
+  ASSERT_EFI_ERROR (Status);
+
+  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
+  ASSERT_EFI_ERROR (Status);
+
   Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
   ASSERT_EFI_ERROR (Status);
 
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.inf 
b/ArmPkg/Drivers/TimerDxe/TimerDxe.inf
index 061fcbc688d9..fa48e569a17d 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.inf
@@ -52,6 +52,9 @@
   gEmbeddedTokenSpaceGuid.PcdTimerPeriod
   gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum  
   gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
+
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz  
 
 [Depex]
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
index fa4f7c741b15..232d745b3d06 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
@@ -175,9 +175,17 @@ ArmArchTimerEnableTimer (
 {
   UINTN TimerCtrlReg;
 
-  ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
-  TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
-  ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+ArmArchTimerReadReg (CntvCtl, (VOID *)&TimerCtrlReg);
+/* FIXME: We need to clear IMASK when under KVM because KVM sets it. 
Unclear if this is a bug ... */
+TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
+TimerCtrlReg &= ~ARM_ARCH_TIMER_IMASK;
+ArmArchTimerWriteReg (CntvCtl, (VOID *)&TimerCtrlReg);
+  } else {
+ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
+TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
+ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  }
 }
 
 VOID
@@ -188,9 +196,15 @@ ArmArchTimerDisableTimer (
 {
   UINTN TimerCtrlReg;
 
-  ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
-  TimerCtrlReg &= ~ARM_ARCH_TIMER_ENABLE;
-  ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+ArmArchTimerReadReg (CntvCtl, (VOID *)&TimerCtrlReg);
+TimerCtrlReg &= ~ARM_ARCH_TIMER_ENABLE;
+ArmArchTimerWriteReg (CntvCtl, (VOID *)&TimerCtrlReg);
+  } else {
+ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
+TimerCtrlReg &= ~ARM_ARCH_TIMER_ENABLE;
+ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  }
 }
 
 VOID
@@ -220,7 +234,12 @@ ArmArchTimerGetTimerVal (
 )
 {
   UINTN ArchTimerVal;
-  ArmArchTimerReadReg (CntpTval, (VOID *)&ArchTimerVal);
+  if (PcdGetBool(PcdArmArchTimerUseVirtual) == TRUE) {
+ArmArchTimerReadReg (CntvTval, (VOID *)&ArchTimerVal);
+  } else {
+ArmArchTimerReadReg (CntpTval, (VOID *)&ArchTimerVal);
+  }
+
   return ArchTimerVal;
 }
 
@@ -231,7 +250,11 @@ ArmArchTimerSetTimerVal (
 IN   UINTN   Val
 )
 {
-  ArmArchTimerWriteReg (CntpTval, (

[edk2] [PATCH 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Ard Biesheuvel]

This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
The following assumptions are made about the target:
- ARM architected timer
- PL011 UART at 0x900
- at least 1 MB of DRAM at 0x4000, containing the device tree blob

The following information is retrieved from the device tree:
- GIC base addresses
- virtual timer interrupt
- RTC base address
- system memory base and size
- virtio MMIO transports

The DTB image is relocated and installed as a configuration table so an
EFI stub enabled kernel can be booted directly without the need for a
bootloader.

Signed-off-by: Michael Casadevall 
Signed-off-by: Ard Biesheuvel 
---
 .../AArch64Virtualization-KVM.dsc  | 222 +
 .../AArch64Virtualization-KVM.fdf  | 299 +
 .../AArch64Virtualization.dsc.inc  | 354 +
 .../AArch64VirtualizationPkg/Driver/VirtFdt.inf|  60 
 .../AArch64VirtualizationPkg/Driver/VirtFdtDxe.c   | 216 +
 .../Include/Platform/KVM/ArmPlatform.h |  32 ++
 .../AArch64VirtualizationLibKVM/AArch64KVMLib.inf  |  53 +++
 .../Library/AArch64VirtualizationLibKVM/KVM.c  | 127 
 .../AArch64VirtualizationLibKVM/KVMHelper.S|  70 
 .../Library/AArch64VirtualizationLibKVM/KVMMem.c   | 106 ++
 .../AArch64VirtualizationSysConfigLibKVM.c |  95 ++
 .../AArch64VirtualizationSysConfigLibKVM.inf   |  35 ++
 .../Library/ResetSystemLib/ResetSystemLib.c|  96 ++
 .../Library/ResetSystemLib/ResetSystemLib.inf  |  33 ++
 14 files changed, 1798 insertions(+)
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization.dsc.inc
 create mode 100644 ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdt.inf
 create mode 100644 ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVM.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMHelper.S
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMMem.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.inf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.inf

diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc 
b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
new file mode 100644
index ..d8a5dcc87941
--- /dev/null
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
@@ -0,0 +1,222 @@
+#
+#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2014, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = AArch64Virtualization-KVM
+  PLATFORM_GUID  = 37d7e986-f7e9-45c2-8067-e371421a626c
+  PLATFORM_VERSION   = 0.1
+  DSC_SPECIFICATION  = 0x00010005
+  OUTPUT_DIRECTORY   = Build/AArch64Virtualization-KVM
+  SUPPORTED_ARCHITECTURES= AARCH64
+  BUILD_TARGETS  = DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+  FLASH_DEFINITION   = 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
+
+!include ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization.dsc.inc
+
+[LibraryClasses.common]
+  ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
+  ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexAEMv8Lib/ArmC

[edk2] [PATCH 10/10] AArch64-KVM: add support for non-volatile variable store

[Ard Biesheuvel]

This adds support for retaining UEFI environment variables in the second
emulated NOR flash which resided at phys address 0x0400 (64 MB).

Note that this requires booting QEMU with two -pflash arguments, each of which
points to a NOR image file of exactly 64 MB in size. The second one will be used
as the variable store.

Signed-off-by: Ard Biesheuvel 
---
 .../AArch64Virtualization-KVM.dsc  | 16 +-
 .../AArch64Virtualization-KVM.fdf  |  4 +-
 .../Include/Platform/KVM/ArmPlatform.h |  6 +++
 .../Library/NorFlashKVM/NorFlashKVM.c  | 63 ++
 .../Library/NorFlashKVM/NorFlashKVM.inf| 35 
 5 files changed, 122 insertions(+), 2 deletions(-)
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf

diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc 
b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
index d8a5dcc87941..b7c03b079577 100644
--- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
@@ -116,6 +116,16 @@
   gArmTokenSpaceGuid.PcdArmArchTimerUseVirtual|1
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
 
+  #
+  # NV Storage PCDs. Use base of 0x0400 for NOR1
+  #
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0400
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0404
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0408
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
+
 [PcdsDynamicDefault.common]
   # System Memory -- 1 MB initially, actual size will be fetched from DT
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x4000
@@ -178,7 +188,7 @@
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
@@ -196,6 +206,10 @@
 
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf {
+
+
NorFlashPlatformLib|ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf 
b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
index b40f915c88fe..9e3b1a625984 100644
--- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
@@ -99,8 +99,8 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
   INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
   INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
@@ -118,6 +118,7 @@ READ_LOCK_STATUS   = TRUE
 
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
@@ -177,6 +178,7 @@ READ_LOCK_STATUS   = TRUE
   INF ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf
   INF ArmPkg/Drivers/CpuPei/CpuPei.inf
   INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
+  INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
   INF IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
   INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h 
b/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
index f6f694f54390..8dddb1dccd63 100644
--- a/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/A

[edk2] ShellPkg: shell can't recognize 'ren' command

[Shah, Tapan]

Jaben / Erik,
   Can you please review this?

This patch fixes 'ren' alias for 'mv' command.


ShellPkg: Fix 'ren' alias for 'mv' command.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 





ren_alias.diff
Description: ren_alias.diff
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] BaseTools: Output build progress messages during pre-processing of build files

[El-Haj-Mahmoud, Samer]

Dear BaseTools maintainers,

Please see attached a minor change to build.py to display progress during 
processing meta-data (pre-processing and creating autogen files). Without this 
change, the build "pauses" for a long time giving the perception that some 
modules are taking a long time to build, when in fact it was pre-processing 
build files.

Minor change to build.py to display progress during processing meta-data 
(pre-processing and creating autogen files). Without this change, the build 
"pauses" for a long time giving the perception that some modules are taking a 
long time to build, when in fact it was pre-processing build files.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



build.py.progress.message.patch
Description: build.py.progress.message.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call alignment

[El-Haj-Mahmoud, Samer]

Mike,

I will try to collect the data and get back on this.

Thanks,
--Samer

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Monday, August 25, 2014 1:03 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function 
call alignment

Samer,

Can you please verify that the stack is aligned in native code before calling 
the EBC function where this fix was required?

If the native stack is always aligned correctly, can you please provide a small 
test case that reproduces the issue along with all the compiler/linker flags 
used.

Thanks,

Mike

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Monday, August 25, 2014 10:40 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function 
call alignment

Mike,

I responded to Jiewen on another thread (for the other EBC DXE  issue):

We found the bugs during validation of an HP storage adapter that uses an EBC 
driver. When running the EBC driver on an X64 server with certain optimizations 
disabled in the UEFI system firmware (specifically, /GL and /LTCG removed), the 
driver hangs (sometimes with an exception). These two fixes allowed the EBC 
driver to run on system firmware with and without those compiler optimizations.



From: El-Haj-Mahmoud, Samer
Sent: Monday, August 25, 2014 11:22 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function call 
alignment

Dear MdeModulePkg maintainers,

Please find the attached patch to fix a stack alignment in EBC DXE interpreter 
for X64 native calls:


Fix EBC X64 native call to be 16-byte aligned. From MSDN x64 Software 
Conventions:

"The stack will always be maintained 16-byte aligned,

except within the prolog (for example, after the return address is pushed),

and except where indicated in Function Types for a certain class of frame 
functions."


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 5/8] MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version

[Jordan Justen]

Liming,

I tested your changes with NASM 2.11, and they worked fine.

One question. I think the 'xor rax, rax' is not needed, so should we
skip that? (I tested with and without it.)

I then tested NASM 2.03, which we had copied from VTF0 as the required
minimum version. It built with your changes, but I found that the code
produced by 2.03 would not boot in OVMF.

I then tested NASM 2.07, and I found that it would boot fine.

All,

Should we require NASM 2.07 or newer rather than 2.03?

NASM 2.07 was released in July 2009. (NASM 2.03 was June 2008)

One other note, that is not particularly relevant, but NASM 2.07 was
when NASM changed to the BSD license.

-Jordan

On Wed, Aug 20, 2014 at 5:46 PM, Gao, Liming  wrote:
> Hi, I meet with the same issue. I verify it in my ubutu 12.04. GCC46, Nasm 
> 2.09. I meet with the build failure.
> 1) 0x10 is not power of two.
> 2) invalid combination of opcode and operands
>
>   I provide my patch that can pass build. Please help review it.
>
> diff --git a/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm 
> b/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> index 2e5a580..105238d 100644
> --- a/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> +++ b/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> @@ -174,7 +174,7 @@ BITS16
>
>  o32 retf; transfer control to user code
>
> -ALIGN   0x10
> +ALIGN   16
>  _NullSegDescDQ  0
>  _16CsDesc:
>  DW  -1
> diff --git a/MdePkg/Library/BaseLib/X64/Thunk16.nasm 
> b/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> index 8858e74..e11bb24 100644
> --- a/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> +++ b/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> @@ -190,7 +190,7 @@ o32 lidt[cs:bp + (_16Idtr - .Base)]
>
>  o32 retf; transfer control to user code
>
> -ALIGN   0x8
> +ALIGN   8
>
>  CODE16  equ _16Code - $
>  DATA16  equ _16Data - $
> @@ -237,11 +237,12 @@ BITS64
>  pushrsi
>  pushrdi
>
> -mov rbx, ds
> +xor rbx, rbx
> +mov ebx, ds
>  pushrbx  ; Save ds segment register on the stack
> -mov rbx, es
> +mov ebx, es
>  pushrbx  ; Save es segment register on the stack
> -mov rbx, ss
> +mov ebx, ss
>  pushrbx  ; Save ss segment register on the stack
>
>  pushfs
> @@ -307,11 +308,11 @@ BITS64
>  pop gs
>  pop fs
>  pop rbx
> -mov ss, rbx
> +mov ss, ebx
>  pop rbx
> -mov es, rbx
> +mov es, ebx
>  pop rbx
> -mov ds, rbx
> +mov ds, ebx
>
>  pop rdi
>  pop rsi
>
> -Original Message-
> From: Mike Maslenkin [mailto:miha...@parallels.com]
> Sent: Thursday, August 21, 2014 5:40 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH 5/8] MdePkg/BaseLib Thunk16: Replace X64 GAS 
> Thunk16 with NASM version
>
> Hello Jordan !
> build -p  build -p IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
> -a X64
> told me about next errors:
>
> Building ... 
> /home/mg/sources/jljusten/edk2/MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
>  [X64]
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:193:
>  error: segment alignment `0x8' is not power of two
> make: ***
> [/home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.obj]
>  Error 1
>
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:240:
>  error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:242:
>  error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:244:
>  error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:310:
>  error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:312:
>  error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:314:
>  error: invalid combination of opcode and operands
> make: ***
> [/home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.obj]
>  Error 1
>
> The last errors come from this
> +global ASM_PFX(InternalAsmThunk16)
> +ASM_PFX(InternalAsmThunk16):
> 
>
>
> ^^^
>> +pus

Re: [edk2] UEFI PXE Boot Question

[Andrew Fish]

On Aug 21, 2014, at 8:13 PM, Chris Cuthbert  wrote:

> Hi Siyuan,
> 
> I can get to Grub prompt but I don't see it trying to load any more files, 
> like the boot menu. Does GRUB V2.02 support PXE boot by default or does it 
> need some configuration option ?
> How does Grub know that it is in network boot mode and not booting from some 
> disk ?
> How does it know the IP address of TFTP server ?

The EFI Application (OS loader) can check the Loaded Image protocol, on the 
ImageHandle, to figure out where it was loaded from. 

Thanks,

Andrew Fish

> Thanx,
> Narinder Dhillon
> 
> 
> From: siyuan...@intel.com
> To: edk2-devel@lists.sourceforge.net; nd6...@hotmail.com
> Subject: RE: [edk2] UEFI PXE Boot Question
> Date: Fri, 22 Aug 2014 02:54:03 +
> 
> Hi, Chris
>  
> The UEFI network driver doesn’t need to be a runtime driver. The typical PXE 
> boot process is as below: first, GRUB will use UEFI stack to download the 
> required files to boot at least a minimum OS kernel, then load it. The OS 
> kernel continues to use UEFI stack to download until it get all the files to 
> start a network stack. After that, OS will call ExitBootServices() service to 
> terminate the UEFI stack, then start its own network.
>  
> Best Regards,
> Siyuan
>  
> From: Chris Cuthbert [mailto:nd6...@hotmail.com] 
> Sent: Friday, August 22, 2014 9:20 AM
> To: Edk2 Devel
> Subject: [edk2] UEFI PXE Boot Question
>  
> Hi All,
>  
> I am trying to PXE boot Linux kernel and I can get GRUB to load and run and 
> get to grub prompt. How is GRUB supposed to get the boot menu from the tftp 
> server ?
> If it is using UEFI network driver to talk to tftp server, does that mean the 
> UEFI network driver needs to be a UEFI runtime driver ?
>  
> Thanx,
>  
> --
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] BaseTools: Add support for ${s_*} and ${d_*} macros in FDF files

[El-Haj-Mahmoud, Samer]

Dear BaseTools maintainers,

Please see attached patch to:

Add support for ${s_*} and ${d_*} macros for in FDF file for the INF files, and 
for each statement in the build rules.
The following keywords are supported:
"src", "s_path", "s_dir", "s_name", "s_base", "s_ext", "dst", "d_path", 
"d_name", "d_base", "d_ext"


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



GenFds.patch
Description: GenFds.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Jordan Justen]

On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming  wrote:
> Hi, all
>
>   This patch is for below  ITEM 7. INF/DEC are generated from UPT tool.
> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help
> review them.
>
>MdePkg: Make sure order of DEC/INF content matches the order that UPT
> generates in the XML -> INF conversion

This patch subject line is much longer than the recommended 70 character limit:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

How about:
MdePkg DEC/INF: Match format required by UPT

These changes seem to arbitrarily match the 'order of some tool', but
why is that required?

What happens when someone edits these files, and doesn't get the order
'just right'?

Is the order that UPT uses strict, or will it potentially change in
the future, if for example, the version of some library being used by
the tool decides to change the way it orders things.

There seems to be other formatting happening, such as spaces removed
from the copyright notice.

All this rolled up into a single change seems to have produced
something that is not reviewable in a reasonable amount of time.

Another question I have is, were these changes the result of the
output of the tool? I guess it would be easier to have some confidence
in the output of a tool rather than all of these changes having been
manually applied.

Do you have the changes available in a branch to make it easy to test?
(No, I would not want an svn branch to be added for this.)

-Jordan

> 1)  Section Order in INF/DEC to match the ones generated from UPT
>
> 2)  Guid value in section will be align.
>
> 3)  Usage comments in section will be align.
>
> 4)  One PCD section includes one PCD type. If one PCD supports more PCD
> types, it will be listed in each PCD type section  in DEC file.
>
>
>
> Contributed-under: TianoCore Contribution Agreement 1.0
>
> Signed-off-by: Gao, Liming 
>
>
>
> Thanks
>
> Liming
>
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Thursday, August 14, 2014 10:13 AM
> 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 con

Re: [edk2] [PATCH 00/10] add support for AArch64 QEMU/KVM

[Laszlo Ersek]

On 08/25/14 21:19, Ard Biesheuvel wrote:
> This series adds a platform config to support QEMU based virtual machines,
> either in TCG or KVM mode. These virtual machines declare their platform 
> configuration by passing a device tree which needs to be parsed by Tianocore
> rather than relying on hardcoded peripherals.
> 
> Currently, the only assumptions made with respect to the platform config are:
> - at least 1 MB of DRAM at 0x4000_
> - NOR flash at 0x0

I'll strive to find the time to review this great series.

But, in advance, can we put the flash somewhere else, like at 0x8 or
0x10? Every time we treat NULL as a valid pointer to a firmware volume
*in C*, the fabric of the universe comes a bit more unstitched.

For one, if a standards-conformant compiler manages to deduce that your
FV pointer is a null pointer, and then you dereference that pointer, the
compiler will have carte blanche to do whatever it pleases (undefined
behavior). We should not base this patchset on undefined behavior.

Using a zero physical address might be fine in assembly, but it isn't
fine in C, for two reasons:

- On this specific implementation, the bit pattern for the zero
  address, and the bit pattern for null pointers, coincide.

- Per the C99 standard, 6.3.2.3 Pointers,

  3 An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
[...]

(As soon as the NOR flash's base address appears in the source code, in
the form of an integer constant, and it's 0, we have big trouble. Not
sure if this case ever occurs, but we shouldn't tempt it.)

Again -- this would be perfectly fine in assembly, but given the C
standard, it is not fine in C.

Thanks
Laszlo


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

[Laszlo Ersek]

On 08/25/14 14:43, Gerd Hoffmann wrote:
>   Hi,
> 
>> The current calculation is correct for stdvga, because on stdvga the value
>> returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is
>> usable for drawing.
> 
> Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a qemu
> bug.  We have releases with the bug in the wild though, so adding this
> as (temporary?) workaround is sensible IMO.  The comment should be
> updated saying so though.

Thanks for the review!

If the workaround is stable in your opinion (ie. it can be relied upon
even after the qemu problem with VBE_DISPI_INDEX_VIDEO_MEMORY_64K is
fixed), then I'd probably leave it in, even in the long term.

Jordan, is it enough if I only reword the commit message below, or do
you want me to resubmit the patch?

-
OvmfPkg: QemuVideoDxe: work around misreported QXL framebuffer size

When setting up the list of GOP modes offered on QEMU's stdvga ("VGA")
and QXL ("qxl-vga") video devices, QemuVideoBochsModeSetup() filters
those modes against the available framebuffer size. (Refer to SVN
r15288 / git commit ec88061e.)

The VBE_DISPI_INDEX_VIDEO_MEMORY_64K register of both stdvga and QXL is
supposed to report the size of the drawable, VGA-compatibility
framebuffer. Instead, up to and including qemu-2.1, this register
actually reports the full video RAM (PCI BAR 0) size.

In case of stdvga, this happens to be correct, because on that card the
full PCI BAR 0 is usable for drawing; there is no difference between
"drawable framebuffer size" and "video RAM (PCI BAR 0) size".

However, on the QXL card, only an initial portion of the video RAM is
suitable for drawing, as compatibility framebuffer; and the value
currently reported by VBE_DISPI_INDEX_VIDEO_MEMORY_64K overshoots the
valid size. Beyond the drawable range, the video RAM contains buffers
and structures for the QXL guest-host protocol.

Luckily, the size of the drawable QXL framebuffer can also be read from
a register in the QXL ROM BAR (PCI BAR 2), so let's retrieve it from
there.

Without this fix, OVMF offers too large resolutions on the QXL card (up
to the full size of the video RAM). If a GOP client selects such a
resolution and draws into the video RAM past the compatibility segment,
then the guest corrupts its communication structures (which is invalid
guest behavior).

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

Thanks,
Laszlo


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 5/8] MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version

[Laszlo Ersek]

On 08/25/14 22:26, Jordan Justen wrote:

> All,
> 
> Should we require NASM 2.07 or newer rather than 2.03?
> 
> NASM 2.07 was released in July 2009. (NASM 2.03 was June 2008)

RHEL-7.0 ships nasm-2.10+, so personally I'm fine with requiring 2.07+.

Thanks,
Laszlo


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 64-bit right shift

[Andrew Fish]

On Aug 20, 2014, at 4:59 PM, Kinney, Michael D  
wrote:

> Tim,
>  
> ARM was a different case.  Andrew Fish can provide many of the details.  
> Basic issue was that even 32-bit math ops were generating intrinsic calls and 
> to apply same technique we have use for 64-bit math ops would have required 
> conversion of most =-*/% operations on UINT32 or UINTN values to be converted 
> to function calls in all modules.  I believe Andrew also provided background 
> that the intrinsic calls to support 32-bit math ops were fully documented and 
> supported by all ARM compilers.
>  

Sorry I was on vacation last week….

The 10,000 foot view was we optimized the coding style of edk2 to not require 
intrinsics on IA32 code. So the edk2 math functions that exist solve this 
problem for integer math. Not doing assignment operations on structures seemed 
to get rid of most of the memset/memcpy issues. 



> I get the impression that the real issue here are the obscure linker error 
> messages and the extra steps/time required to identify he C source line that 
> is introducing the use of the intrinsic call.  Another option to consider is 
> to improve the tools to help identify the C source line that is generating 
> the intrinsic along with a recommended C source change to resolve the issue.
>  
> As Daryl said, if there is strong interest in making the intrinsic functions 
> in the AppPkg their own lib, he would consider that change.  I think that 
> would provide a partial solution.
>  

My understanding is the math libs are standard for GCC/clang and they follow a 
well known naming convention.  I’m not sure what VC++ does? 

The llvm project has a a set of these intrinsics in the compiler_rt project, 
mostly written in C, licensed under MIT and Illinois Open Source License (BDS 
compatible). 

Random internet search example: 
http://opensource.apple.com/source/clang/clang-137/src/projects/compiler-rt/lib/udivmoddi4.c

Thanks,

Andrew Fish

> Best regards,
>  
> Mike
>  
> From: Tim Lewis [mailto:tim.le...@insyde.com] 
> Sent: Wednesday, August 20, 2014 3:39 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 
> 64-bit right shift
>  
> Mike –
>  
> However, as compilers do require intrinsic functions in order to support 
> basic C/C++ operators, and as the ArmPkg has already implemented this sort of 
> function for support of ARM tool chains, and as it regularly causes compile 
> failures for reasons obscure even to engineers well versed in the art, I 
> think it is time to revisit that decision. Raise your hand if you have done a 
> search on u
>  
> Even a partial solution will be better than no solutions because the net 
> result is fewer hard-to-understand linker errors than before. If you miss one 
> function, the net result is no worse than today.
>  
> Tim
>  
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
> Sent: Wednesday, August 20, 2014 12:30 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 
> 64-bit right shift
>  
> Thomas,
>  
> A design decision was made early in the EDK II project to not depend on any 
> compiler intrinsic functions.  The reasons include:
> 1)  Linking against OS specific C libs has risks because it can 
> potentially introduce OS specific sys calls.
> 2)  Linking against OS specific C libs can potentially produce larger 
> firmware images.
> 3)  Different compilers and each compiler release can choose to 
> add/remove/modify intrinsic functions the compiler generates to meet that 
> specific compiler’s requirements. 
> 4)  Not all intrinsic functions generated by all compilers are fully 
> documented. 
>  
> When the AppPkg and support for C lib was added, there was a new requirement 
> to support building exiting C application sources “as is”.  This meant that 
> some intrinsic functions could not be avoided, so the minimum set of 
> intrinsic functions were added to the C lib support and the C lib maintainer 
> has to handle the issues listed above.  As a result, the compiler 
> compatibility of the AppPkg may not be the same as the rest of the EDK II 
> packages.
>  
> I may be a good idea to move the just the intrinsic functions into their own 
> lib instances in the AppPkg, so they are available for linking against 
> firmware modules to work around porting issues until the intrinsic functions 
> are replaced with MdePkg lib calls. 
>  
> Best regards,
>  
> Mike
>  
> From: Thomas Rognon [mailto:tcrog...@gmail.com] 
> Sent: Wednesday, August 20, 2014 11:34 AM
> To: edk2-devel
> Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 
> 64-bit right shift
>  
> UefiCpuPkg/Library/CompilerIntrinsicsLib would be awesome. I feel like I'm 
> always battling the compiler with math and memory intrinsics. I hope this 
> happens.
>  
> 
> On Wed, Aug 20, 2014 at 1:06 PM, Tim Lewis  wrote:
> Da

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

[Jordan Justen]

On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek  wrote:
> On 08/25/14 14:43, Gerd Hoffmann wrote:
>>   Hi,
>>
>>> The current calculation is correct for stdvga, because on stdvga the value
>>> returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is
>>> usable for drawing.
>>
>> Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a qemu
>> bug.  We have releases with the bug in the wild though, so adding this
>> as (temporary?) workaround is sensible IMO.  The comment should be
>> updated saying so though.
>
> Thanks for the review!
>
> If the workaround is stable in your opinion (ie. it can be relied upon
> even after the qemu problem with VBE_DISPI_INDEX_VIDEO_MEMORY_64K is
> fixed), then I'd probably leave it in, even in the long term.
>
> Jordan, is it enough if I only reword the commit message below, or do
> you want me to resubmit the patch?

Why not use Private->Variant, rather than 'IsQxl'?

-Jordan

> -
> OvmfPkg: QemuVideoDxe: work around misreported QXL framebuffer size
>
> When setting up the list of GOP modes offered on QEMU's stdvga ("VGA")
> and QXL ("qxl-vga") video devices, QemuVideoBochsModeSetup() filters
> those modes against the available framebuffer size. (Refer to SVN
> r15288 / git commit ec88061e.)
>
> The VBE_DISPI_INDEX_VIDEO_MEMORY_64K register of both stdvga and QXL is
> supposed to report the size of the drawable, VGA-compatibility
> framebuffer. Instead, up to and including qemu-2.1, this register
> actually reports the full video RAM (PCI BAR 0) size.
>
> In case of stdvga, this happens to be correct, because on that card the
> full PCI BAR 0 is usable for drawing; there is no difference between
> "drawable framebuffer size" and "video RAM (PCI BAR 0) size".
>
> However, on the QXL card, only an initial portion of the video RAM is
> suitable for drawing, as compatibility framebuffer; and the value
> currently reported by VBE_DISPI_INDEX_VIDEO_MEMORY_64K overshoots the
> valid size. Beyond the drawable range, the video RAM contains buffers
> and structures for the QXL guest-host protocol.
>
> Luckily, the size of the drawable QXL framebuffer can also be read from
> a register in the QXL ROM BAR (PCI BAR 2), so let's retrieve it from
> there.
>
> Without this fix, OVMF offers too large resolutions on the QXL card (up
> to the full size of the video RAM). If a GOP client selects such a
> resolution and draws into the video RAM past the compatibility segment,
> then the guest corrupts its communication structures (which is invalid
> guest behavior).
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> -
>
> Thanks,
> Laszlo
>
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ShellPkg: shell can't recognize 'ren' command

[Bjorge, Erik C]

Reviewed-by: Erik Bjorge 

From: Shah, Tapan [mailto:tapands...@hp.com]
Sent: Monday, August 25, 2014 12:54 PM
To: Carsey, Jaben; Bjorge, Erik C; edk2-devel@lists.sourceforge.net
Subject: ShellPkg: shell can't recognize 'ren' command

Jaben / Erik,
   Can you please review this?

This patch fixes 'ren' alias for 'mv' command.


ShellPkg: Fix 'ren' alias for 'mv' command.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

[Laszlo Ersek]

On 08/25/14 23:42, Jordan Justen wrote:
> On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek 
> wrote:
>> On 08/25/14 14:43, Gerd Hoffmann wrote:
>>>   Hi,
>>>
 The current calculation is correct for stdvga, because on stdvga
 the value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the
 full video RAM, is usable for drawing.
>>>
>>> Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a
>>> qemu bug.  We have releases with the bug in the wild though, so
>>> adding this as (temporary?) workaround is sensible IMO.  The comment
>>> should be updated saying so though.
>>
>> Thanks for the review!
>>
>> If the workaround is stable in your opinion (ie. it can be relied
>> upon even after the qemu problem with
>> VBE_DISPI_INDEX_VIDEO_MEMORY_64K is fixed), then I'd probably leave
>> it in, even in the long term.
>>
>> Jordan, is it enough if I only reword the commit message below, or do
>> you want me to resubmit the patch?
>
> Why not use Private->Variant, rather than 'IsQxl'?

I wondered if you would ask that question! :)

The reason is that at that point Private->Variant does not
*necessarily* distinguish QXL from stdvga. Originally, yes,
Private->Variant distinguishes QXL (QEMU_VIDEO_BOCHS) from stdvga
(QEMU_VIDEO_BOCHS_MMIO), but please see this in
QemuVideoControllerDriverStart():

  //
  // Check whenever the qemu stdvga mmio bar is present (qemu 1.3+).
  //
  if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO) {
EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *MmioDesc;

Status = Private->PciIo->GetBarAttributes (
Private->PciIo,
PCI_BAR_IDX2,
NULL,
(VOID**) &MmioDesc
);
if (EFI_ERROR (Status) ||
MmioDesc->ResType != ACPI_ADDRESS_SPACE_TYPE_MEM) {
  DEBUG ((EFI_D_INFO, "QemuVideo: No mmio bar, fallback to port io\n"));
  Private->Variant = QEMU_VIDEO_BOCHS;
} else {
  DEBUG ((EFI_D_INFO, "QemuVideo: Using mmio bar @ 0x%lx\n",
  MmioDesc->AddrRangeMin));
}

if (!EFI_ERROR (Status)) {
  FreePool (MmioDesc);
}
  }

There's a path here where Private->Variant changes from
QEMU_VIDEO_BOCHS_MMIO to QEMU_VIDEO_BOCHS, ie. an stdvga card would
appear as QXL.

For this reason, I added the IsQxl parameter, and I fill it in from:

  case QEMU_VIDEO_BOCHS:
Status = QemuVideoBochsModeSetup (Private,
   (BOOLEAN)(Card->Variant == QEMU_VIDEO_BOCHS));

The expression does not use Private->Variant, it uses Card->Variant.

I thought about introducing more fields to Private, but it seemed
overkill; the difference is only in QemuVideoBochsModeSetup(), and that
one can key off a local variable of the caller.

Thanks,
Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Duplicate PCDs in DSC files

[Tim Lewis]

Samer -

I would say that there are tool chains the depend on the last-instance winning. 
Consider the case of #included .dsc files where the included .dsc has the 
default value/storage type and the final resolution done later in the including 
file.

Tim

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 1:59 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Duplicate PCDs in DSC files

It looks like the build tools will not warn you (or stop with an error) if 
there are multiple declarations of the same PCD in the DSC file. In fact, the 
same PCD could be initialized multiple times using different values and 
different types (Fixed vs. Dynamic for instance), and the build tools will 
silently pick the last instance of the PCD in the DSC File.

We just finished debugging a nasty issue caused by duplicate PCDs, and it would 
have been nice to prevent this to begin with! Looks to me like a bug in the 
tool.

Can we add the ability to break the build if there are duplicate PCD instances 
in the DSC file?




Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Duplicate PCDs in DSC files

[El-Haj-Mahmoud, Samer]

In this case, there should at least be a build tool option to break the build 
if duplicates are found.


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 25, 2014 5:04 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Duplicate PCDs in DSC files

Samer -

I would say that there are tool chains the depend on the last-instance winning. 
Consider the case of #included .dsc files where the included .dsc has the 
default value/storage type and the final resolution done later in the including 
file.

Tim

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 1:59 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Duplicate PCDs in DSC files

It looks like the build tools will not warn you (or stop with an error) if 
there are multiple declarations of the same PCD in the DSC file. In fact, the 
same PCD could be initialized multiple times using different values and 
different types (Fixed vs. Dynamic for instance), and the build tools will 
silently pick the last instance of the PCD in the DSC File.

We just finished debugging a nasty issue caused by duplicate PCDs, and it would 
have been nice to prevent this to begin with! Looks to me like a bug in the 
tool.

Can we add the ability to break the build if there are duplicate PCD instances 
in the DSC file?




Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

[Jordan Justen]

On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek  wrote:
> Recent changes in the QEMU ACPI table generator have shown that our
> limited client for that interface is insufficient and/or brittle.
>
> Implement the full interface utilizing OrderedCollectionLib for addressing
> fw_cfg blobs by name.
>
> In addition, we stop using EFI_ACPI_TABLE_PROTOCOL in the QEMU loader
> client, because:
> - splitting the blobs for EFI_ACPI_TABLE_PROTOCOL is just untenable short
>   of a complete ACPI parser,
> - and it is fully sufficient to install the RSD PTR as an EFI
>   configuration table for the guest OS to see everything.
>
> In short, for this interface, EFI_ACPI_TABLE_PROTOCOL is an unwanted and
> restrictive convenience; let's stop using it.

Hmm. Been through a few rounds of this for Xen. It's QEMU's turn now? :)

Is this required?

What happens if another driver uses EFI_ACPI_TABLE_PROTOCOL? We now
have two drivers that want to install the pointer.

It seems the AcpiTableDxe driver has had to fix things on occasion to
cover some corner cases of table publishing. Did you capture all
these? What about future bugs?

How did Xen manage to end up using EFI_ACPI_TABLE_PROTOCOL if it is
not possible or practical for QEMU?

What is it about EFI_ACPI_TABLE_PROTOCOL that is such a bad fit for VMs?

-Jordan

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   3 +
>  OvmfPkg/AcpiPlatformDxe/Qemu.c  | 415 
> ++--
>  2 files changed, 398 insertions(+), 20 deletions(-)
>
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
> b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> index 90178e0..02eaf23 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> @@ -51,12 +51,15 @@
>MemoryAllocationLib
>BaseLib
>DxeServicesTableLib
> +  OrderedCollectionLib
>
>  [Protocols]
>gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
>
>  [Guids]
>gEfiXenInfoGuid
> +  gEfiAcpi10TableGuid
> +  gEfiAcpi20TableGuid
>
>  [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
> diff --git a/OvmfPkg/AcpiPlatformDxe/Qemu.c b/OvmfPkg/AcpiPlatformDxe/Qemu.c
> index 333766e..4663ecb 100644
> --- a/OvmfPkg/AcpiPlatformDxe/Qemu.c
> +++ b/OvmfPkg/AcpiPlatformDxe/Qemu.c
> @@ -17,12 +17,15 @@
>
>  #include "AcpiPlatform.h"
>  #include "QemuLoader.h"
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include // CopyMem()
> +#include   // AllocatePool()
> +#include  // QemuFwCfgFindFile()
> +#include   // gDS
> +#include// PcdGet16()
> +#include   // EfiGetSystemConfigurationTable()
> +#include  // OrderedCollectionInit()
> +#include // EFI_ACPI_DESCRIPTION_HEADER
> +#include // gEfiAcpi10TableGuid
>
>  BOOLEAN
>  QemuDetected (
> @@ -518,7 +521,8 @@ QemuInstallAcpiTable (
>
>
>  /**
> -  Check if an array of bytes starts with an RSD PTR structure.
> +  Check if an array of bytes starts with an RSD PTR structure, and if so,
> +  return the EFI ACPI table GUID that corresponds to its version.
>
>Checksum is ignored.
>
> @@ -526,8 +530,9 @@ QemuInstallAcpiTable (
>
>@param[in] Size   Number of bytes in Buffer.
>
> -  @param[out] RsdpSize  If the function returns EFI_SUCCESS, this parameter
> -contains the size of the detected RSD PTR structure.
> +  @param[out] AcpiTableGuid  On successful exit, pointer to the EFI ACPI 
> table
> + GUID in statically allocated storage that
> + corresponds to the detected RSD PTR version.
>
>@retval  EFI_SUCCESS RSD PTR structure detected at the beginning of
> Buffer, and its advertised size does not 
> exceed
> @@ -545,7 +550,7 @@ EFI_STATUS
>  CheckRsdp (
>IN  CONST VOID *Buffer,
>IN  UINTN  Size,
> -  OUT UINTN  *RsdpSize
> +  OUT EFI_GUID   **AcpiTableGuid
>)
>  {
>CONST UINT64   *Signature;
> @@ -574,7 +579,7 @@ CheckRsdp (
>  //
>  // ACPI 1.0 doesn't include the Length field
>  //
> -*RsdpSize = sizeof *Rsdp1;
> +*AcpiTableGuid = &gEfiAcpi10TableGuid;
>  return EFI_SUCCESS;
>}
>
> @@ -587,27 +592,99 @@ CheckRsdp (
>  return EFI_PROTOCOL_ERROR;
>}
>
> -  *RsdpSize = Rsdp2->Length;
> +  *AcpiTableGuid = &gEfiAcpi20TableGuid;
>return EFI_SUCCESS;
>  }
>
> +//
> +// The user structure for the ordered collection that will track the fw_cfg
> +// blobs under processing.
> +//
> +typedef struct {
> +  UINT8 File[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated name of the fw_cfg
> +  // blob. This is the ordering / search
> +  // key.
> +  UINTN Size; // The number of bytes

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

[Laszlo Ersek]

On 08/26/14 00:24, Jordan Justen wrote:
> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek  wrote:
>> Recent changes in the QEMU ACPI table generator have shown that our
>> limited client for that interface is insufficient and/or brittle.
>>
>> Implement the full interface utilizing OrderedCollectionLib for addressing
>> fw_cfg blobs by name.
>>
>> In addition, we stop using EFI_ACPI_TABLE_PROTOCOL in the QEMU loader
>> client, because:
>> - splitting the blobs for EFI_ACPI_TABLE_PROTOCOL is just untenable short
>>   of a complete ACPI parser,
>> - and it is fully sufficient to install the RSD PTR as an EFI
>>   configuration table for the guest OS to see everything.
>>
>> In short, for this interface, EFI_ACPI_TABLE_PROTOCOL is an unwanted and
>> restrictive convenience; let's stop using it.
> 
> Hmm. Been through a few rounds of this for Xen. It's QEMU's turn now? :)
> 
> Is this required?

Depends on how good (how accurate) ACPI tables you want to have in your
VMs. For a few qemu releases now, qemu has been the "master" of ACPI
payload generation. SeaBIOS too has kept its own builtin tables, yes,
but when the QEMU generated payload is available, it interprets this
linker/loader script just the same.

If you want PCI hotplug, pvpanic support; or, going forward, memory
hotplug, then yes, those things need ACPI support, and the ACPI stuff
for them is now developed in QEMU (and dynamically generated by it,
dependent on the actual hardware config).

> What happens if another driver uses EFI_ACPI_TABLE_PROTOCOL? We now
> have two drivers that want to install the pointer.

Yes, I checked that. The UEFI spec says that whenever you install a
configuration table that's already present (by GUID), the reference is
updated.

  InstallConfigurationTable()

  [...]
  * If Guid is present in the System Table, and Table is not NULL, then
the (Guid, Table) pair is updated with the new Table value.
  [...]

For this reason, the first thing InstallAllQemuLinkedTables() does is
check, with EfiGetSystemConfigurationTable(), for the presence of any of
the ACPI GUIDs in the config table.

There's no "absolute" cure against another driver in OVMF just grabbing
EFI_ACPI_TABLE_PROTOCOL and installing its own stuff (which would then
completely hide the tables installed by this patchset, because
"MdeModulePkg/Universal/Acpi/AcpiTableDxe" would simply replace QEMU's
RSD PTR's address in the UEFI config table with its own).

But ACPI tables are not randomly installed in OVMF, we keep it
centralized in AcpiTableDxe.

> It seems the AcpiTableDxe driver has had to fix things on occasion to
> cover some corner cases of table publishing. Did you capture all
> these? What about future bugs?

The point of this series, and more importantly, qemu's linker/loader
interface, is that the firmware can remain dumb. It doesn't need to know
about inter-table relationships, it doesn't need to know about tables.
It only needs to recognize the RSD PTR (which we can easily do now, in a
way that was suggested by Michael).

Bugs in ACPI payload, including inter-table relationships, will now be
caused by QEMU, and will have to be fixed in QEMU; they can remain
transparent to OVMF.

> How did Xen manage to end up using EFI_ACPI_TABLE_PROTOCOL if it is
> not possible or practical for QEMU?
> 
> What is it about EFI_ACPI_TABLE_PROTOCOL that is such a bad fit for VMs?

The difference is simply in how the different hypervisors provide the
ACPI stuff to the firmware. Xen elected for a per-table export, which
OVMF can super-easily pass to EFI_ACPI_TABLE_PROTOCOL, because the
latter expects individual tables as well.

QEMU chose a different path. The interface does not expose ACPI tables
as such, it exposes blobs that may contain binary data that, once
correctly cross-linked and checksummed, will be understood by a
full-blown ACPI interpreter (the ones you can find in OS kernels). This
is *very* convenient for SeaBIOS.

We tried to split the blobs into individual tables before, so that we
could pass each table to EFI_ACPI_TABLE_PROTOCOL individually.

This splitting logic turned out to be brittle. Although there wasn't
(and still isn't) any semi-official, written contract for the
linker/loader interface, our splitting logic did not meet the *intent*
of the qemu interface; it abused it.

And, in practice, please see this recent qemu-devel discussion -- an
example where our current, splitter approach would break down. It's
about TPM / TCPA.

  http://thread.gmane.org/gmane.comp.emulators.qemu/287985

This thread was what finally convinced me that I'd have to implement the
full thing.

BTW you don't have to look at Xen for a per-table approach. If you check
QEMU's new SMBIOS (as opposed to ACPI) generator (for which Gabriel has
contributed the OVMF client code too), that's table-based as well, and
uses EFI_SMBIOS_PROTOCOL.

Now, if you want to know why the QEMU ACPI interface was *designed* like
this, ie. with such a mismatch for EFI_ACPI_TABLE_PROTOCOL, I'm
partiall

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

[Jordan Justen]

On Mon, Aug 25, 2014 at 2:56 PM, Laszlo Ersek  wrote:
> On 08/25/14 23:42, Jordan Justen wrote:
>> On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek 
>> wrote:
>>> On 08/25/14 14:43, Gerd Hoffmann wrote:
   Hi,

> The current calculation is correct for stdvga, because on stdvga
> the value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the
> full video RAM, is usable for drawing.

 Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a
 qemu bug.  We have releases with the bug in the wild though, so
 adding this as (temporary?) workaround is sensible IMO.  The comment
 should be updated saying so though.
>>>
>>> Thanks for the review!
>>>
>>> If the workaround is stable in your opinion (ie. it can be relied
>>> upon even after the qemu problem with
>>> VBE_DISPI_INDEX_VIDEO_MEMORY_64K is fixed), then I'd probably leave
>>> it in, even in the long term.
>>>
>>> Jordan, is it enough if I only reword the commit message below, or do
>>> you want me to resubmit the patch?
>>
>> Why not use Private->Variant, rather than 'IsQxl'?
>
> I wondered if you would ask that question! :)
>
> The reason is that at that point Private->Variant does not
> *necessarily* distinguish QXL from stdvga. Originally, yes,
> Private->Variant distinguishes QXL (QEMU_VIDEO_BOCHS) from stdvga
> (QEMU_VIDEO_BOCHS_MMIO), but please see this in
> QemuVideoControllerDriverStart():
>
>   //
>   // Check whenever the qemu stdvga mmio bar is present (qemu 1.3+).
>   //
>   if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO) {
> EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *MmioDesc;
>
> Status = Private->PciIo->GetBarAttributes (
> Private->PciIo,
> PCI_BAR_IDX2,
> NULL,
> (VOID**) &MmioDesc
> );
> if (EFI_ERROR (Status) ||
> MmioDesc->ResType != ACPI_ADDRESS_SPACE_TYPE_MEM) {
>   DEBUG ((EFI_D_INFO, "QemuVideo: No mmio bar, fallback to port io\n"));
>   Private->Variant = QEMU_VIDEO_BOCHS;
> } else {
>   DEBUG ((EFI_D_INFO, "QemuVideo: Using mmio bar @ 0x%lx\n",
>   MmioDesc->AddrRangeMin));
> }
>
> if (!EFI_ERROR (Status)) {
>   FreePool (MmioDesc);
> }
>   }
>
> There's a path here where Private->Variant changes from
> QEMU_VIDEO_BOCHS_MMIO to QEMU_VIDEO_BOCHS, ie. an stdvga card would
> appear as QXL.
>
> For this reason, I added the IsQxl parameter, and I fill it in from:
>
>   case QEMU_VIDEO_BOCHS:
> Status = QemuVideoBochsModeSetup (Private,
>(BOOLEAN)(Card->Variant == QEMU_VIDEO_BOCHS));

Hmm, I see.

How about, for clarity, above, near where you first assign
Private->Variant, you also set a local IsQxl variable?

And a comment might not hurt:
//
// IsQxl is based on the detected Card->Variant, which at a
// later point might not match Private->Variant.
//

-Jordan

> The expression does not use Private->Variant, it uses Card->Variant.
>
> I thought about introducing more fields to Private, but it seemed
> overkill; the difference is only in QemuVideoBochsModeSetup(), and that
> one can key off a local variable of the caller.
>
> Thanks,
> Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

[Laszlo Ersek]

On 08/26/14 01:41, Jordan Justen wrote:
> On Mon, Aug 25, 2014 at 2:56 PM, Laszlo Ersek  wrote:
>> On 08/25/14 23:42, Jordan Justen wrote:
>>> On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek 
>>> wrote:
 On 08/25/14 14:43, Gerd Hoffmann wrote:
>   Hi,
>
>> The current calculation is correct for stdvga, because on stdvga
>> the value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the
>> full video RAM, is usable for drawing.
>
> Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a
> qemu bug.  We have releases with the bug in the wild though, so
> adding this as (temporary?) workaround is sensible IMO.  The comment
> should be updated saying so though.

 Thanks for the review!

 If the workaround is stable in your opinion (ie. it can be relied
 upon even after the qemu problem with
 VBE_DISPI_INDEX_VIDEO_MEMORY_64K is fixed), then I'd probably leave
 it in, even in the long term.

 Jordan, is it enough if I only reword the commit message below, or do
 you want me to resubmit the patch?
>>>
>>> Why not use Private->Variant, rather than 'IsQxl'?
>>
>> I wondered if you would ask that question! :)
>>
>> The reason is that at that point Private->Variant does not
>> *necessarily* distinguish QXL from stdvga. Originally, yes,
>> Private->Variant distinguishes QXL (QEMU_VIDEO_BOCHS) from stdvga
>> (QEMU_VIDEO_BOCHS_MMIO), but please see this in
>> QemuVideoControllerDriverStart():
>>
>>   //
>>   // Check whenever the qemu stdvga mmio bar is present (qemu 1.3+).
>>   //
>>   if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO) {
>> EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *MmioDesc;
>>
>> Status = Private->PciIo->GetBarAttributes (
>> Private->PciIo,
>> PCI_BAR_IDX2,
>> NULL,
>> (VOID**) &MmioDesc
>> );
>> if (EFI_ERROR (Status) ||
>> MmioDesc->ResType != ACPI_ADDRESS_SPACE_TYPE_MEM) {
>>   DEBUG ((EFI_D_INFO, "QemuVideo: No mmio bar, fallback to port io\n"));
>>   Private->Variant = QEMU_VIDEO_BOCHS;
>> } else {
>>   DEBUG ((EFI_D_INFO, "QemuVideo: Using mmio bar @ 0x%lx\n",
>>   MmioDesc->AddrRangeMin));
>> }
>>
>> if (!EFI_ERROR (Status)) {
>>   FreePool (MmioDesc);
>> }
>>   }
>>
>> There's a path here where Private->Variant changes from
>> QEMU_VIDEO_BOCHS_MMIO to QEMU_VIDEO_BOCHS, ie. an stdvga card would
>> appear as QXL.
>>
>> For this reason, I added the IsQxl parameter, and I fill it in from:
>>
>>   case QEMU_VIDEO_BOCHS:
>> Status = QemuVideoBochsModeSetup (Private,
>>(BOOLEAN)(Card->Variant == QEMU_VIDEO_BOCHS));
> 
> Hmm, I see.
> 
> How about, for clarity, above, near where you first assign
> Private->Variant, you also set a local IsQxl variable?
> 
> And a comment might not hurt:
> //
> // IsQxl is based on the detected Card->Variant, which at a
> // later point might not match Private->Variant.
> //

Will do, thanks!
Laszlo


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Circular Dependency Between DxePrintLibPrint2Protocol and BaseDebugLibSerialPort

[Cohen, Eugene]

Dear maintainers of DebugLib and PrintLib,

It looks like we have a circular dependency between the 
DxePrintLibPrint2Protocol library (which uses ASSERT) and 
BaseDebugLibSerialPort library (which uses AsciiSPrint):

1>.dsc(...) : error F002: Library 
[c:\edk2\MdeModulePkg\Library\DxePrintLibPrint2Protocol\DxePrintLibPrint2Protocol.inf]
 with constructors has a cycle
1>consumed by 
c:\edk2\MdePkg\Library\BaseDebugLibSerialPort\BaseDebugLibSerialPort.inf

so it seems that this library combination is incompatible.  Is there a 
preferred way to resolve this?

I see some platforms use the status code variant of DebugLib 
(PeiDxeDebugLibReportStatusCode) but I'd prefer a solution that allows us to 
keep using the simple BaseDebugLibSerialPort.

Thanks,

Eugene
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

[Jordan Justen]

On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek  wrote:
> On 08/26/14 00:24, Jordan Justen wrote:
>> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek  wrote:
>>> Recent changes in the QEMU ACPI table generator have shown that our
>>> limited client for that interface is insufficient and/or brittle.
>>>
>>> Implement the full interface utilizing OrderedCollectionLib for addressing
>>> fw_cfg blobs by name.
>>>
>>> In addition, we stop using EFI_ACPI_TABLE_PROTOCOL in the QEMU loader
>>> client, because:
>>> - splitting the blobs for EFI_ACPI_TABLE_PROTOCOL is just untenable short
>>>   of a complete ACPI parser,
>>> - and it is fully sufficient to install the RSD PTR as an EFI
>>>   configuration table for the guest OS to see everything.
>>>
>>> In short, for this interface, EFI_ACPI_TABLE_PROTOCOL is an unwanted and
>>> restrictive convenience; let's stop using it.
>>
>> Hmm. Been through a few rounds of this for Xen. It's QEMU's turn now? :)
>>
>> Is this required?
>
> Depends on how good (how accurate) ACPI tables you want to have in your
> VMs. For a few qemu releases now, qemu has been the "master" of ACPI
> payload generation. SeaBIOS too has kept its own builtin tables, yes,
> but when the QEMU generated payload is available, it interprets this
> linker/loader script just the same.
>
> If you want PCI hotplug, pvpanic support; or, going forward, memory
> hotplug, then yes, those things need ACPI support, and the ACPI stuff
> for them is now developed in QEMU (and dynamically generated by it,
> dependent on the actual hardware config).
>
>> What happens if another driver uses EFI_ACPI_TABLE_PROTOCOL? We now
>> have two drivers that want to install the pointer.
>
> Yes, I checked that. The UEFI spec says that whenever you install a
> configuration table that's already present (by GUID), the reference is
> updated.
>
>   InstallConfigurationTable()
>
>   [...]
>   * If Guid is present in the System Table, and Table is not NULL, then
> the (Guid, Table) pair is updated with the new Table value.
>   [...]
>
> For this reason, the first thing InstallAllQemuLinkedTables() does is
> check, with EfiGetSystemConfigurationTable(), for the presence of any of
> the ACPI GUIDs in the config table.
>
> There's no "absolute" cure against another driver in OVMF just grabbing
> EFI_ACPI_TABLE_PROTOCOL and installing its own stuff (which would then
> completely hide the tables installed by this patchset, because
> "MdeModulePkg/Universal/Acpi/AcpiTableDxe" would simply replace QEMU's
> RSD PTR's address in the UEFI config table with its own).
>
> But ACPI tables are not randomly installed in OVMF, we keep it
> centralized in AcpiTableDxe.

I don't agree with this statement. Rather, I would say that OVMF
follows the EDK II method of publishing tables, which means
EFI_ACPI_TABLE_PROTOCOL.

In the past we were a good little sample platform, and provided the
ACPI tables directly. Well, that is less and less the case. But, is it
a good idea to stop using EFI_ACPI_TABLE_PROTOCOL?

What about MdeModulePkg/Universal/Network/IScsiDxe/IScsiIbft.c, which
uses EFI_ACPI_TABLE_PROTOCOL?

Do we need to keep monitoring which EDK II drivers decide to use
EFI_ACPI_TABLE_PROTOCOL, or can we find a way to make these work
together? If the answer is no, then I wonder if this is something that
UEFI or EDK II needs to consider.

-Jordan

>> It seems the AcpiTableDxe driver has had to fix things on occasion to
>> cover some corner cases of table publishing. Did you capture all
>> these? What about future bugs?
>
> The point of this series, and more importantly, qemu's linker/loader
> interface, is that the firmware can remain dumb. It doesn't need to know
> about inter-table relationships, it doesn't need to know about tables.
> It only needs to recognize the RSD PTR (which we can easily do now, in a
> way that was suggested by Michael).
>
> Bugs in ACPI payload, including inter-table relationships, will now be
> caused by QEMU, and will have to be fixed in QEMU; they can remain
> transparent to OVMF.
>
>> How did Xen manage to end up using EFI_ACPI_TABLE_PROTOCOL if it is
>> not possible or practical for QEMU?
>>
>> What is it about EFI_ACPI_TABLE_PROTOCOL that is such a bad fit for VMs?
>
> The difference is simply in how the different hypervisors provide the
> ACPI stuff to the firmware. Xen elected for a per-table export, which
> OVMF can super-easily pass to EFI_ACPI_TABLE_PROTOCOL, because the
> latter expects individual tables as well.
>
> QEMU chose a different path. The interface does not expose ACPI tables
> as such, it exposes blobs that may contain binary data that, once
> correctly cross-linked and checksummed, will be understood by a
> full-blown ACPI interpreter (the ones you can find in OS kernels). This
> is *very* convenient for SeaBIOS.
>
> We tried to split the blobs into individual tables before, so that we
> could pass each table to EFI_ACPI_TABLE_PROTOCOL individually.
>
> This splitting logic turned out to be brittle. Alt

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

[Laszlo Ersek]

On 08/26/14 02:12, Jordan Justen wrote:
> On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek  wrote:
>> On 08/26/14 00:24, Jordan Justen wrote:
>>> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek  wrote:
 Recent changes in the QEMU ACPI table generator have shown that our
 limited client for that interface is insufficient and/or brittle.

 Implement the full interface utilizing OrderedCollectionLib for addressing
 fw_cfg blobs by name.

 In addition, we stop using EFI_ACPI_TABLE_PROTOCOL in the QEMU loader
 client, because:
 - splitting the blobs for EFI_ACPI_TABLE_PROTOCOL is just untenable short
   of a complete ACPI parser,
 - and it is fully sufficient to install the RSD PTR as an EFI
   configuration table for the guest OS to see everything.

 In short, for this interface, EFI_ACPI_TABLE_PROTOCOL is an unwanted and
 restrictive convenience; let's stop using it.
>>>
>>> Hmm. Been through a few rounds of this for Xen. It's QEMU's turn now? :)
>>>
>>> Is this required?
>>
>> Depends on how good (how accurate) ACPI tables you want to have in your
>> VMs. For a few qemu releases now, qemu has been the "master" of ACPI
>> payload generation. SeaBIOS too has kept its own builtin tables, yes,
>> but when the QEMU generated payload is available, it interprets this
>> linker/loader script just the same.
>>
>> If you want PCI hotplug, pvpanic support; or, going forward, memory
>> hotplug, then yes, those things need ACPI support, and the ACPI stuff
>> for them is now developed in QEMU (and dynamically generated by it,
>> dependent on the actual hardware config).
>>
>>> What happens if another driver uses EFI_ACPI_TABLE_PROTOCOL? We now
>>> have two drivers that want to install the pointer.
>>
>> Yes, I checked that. The UEFI spec says that whenever you install a
>> configuration table that's already present (by GUID), the reference is
>> updated.
>>
>>   InstallConfigurationTable()
>>
>>   [...]
>>   * If Guid is present in the System Table, and Table is not NULL, then
>> the (Guid, Table) pair is updated with the new Table value.
>>   [...]
>>
>> For this reason, the first thing InstallAllQemuLinkedTables() does is
>> check, with EfiGetSystemConfigurationTable(), for the presence of any of
>> the ACPI GUIDs in the config table.
>>
>> There's no "absolute" cure against another driver in OVMF just grabbing
>> EFI_ACPI_TABLE_PROTOCOL and installing its own stuff (which would then
>> completely hide the tables installed by this patchset, because
>> "MdeModulePkg/Universal/Acpi/AcpiTableDxe" would simply replace QEMU's
>> RSD PTR's address in the UEFI config table with its own).
>>
>> But ACPI tables are not randomly installed in OVMF, we keep it
>> centralized in AcpiTableDxe.
> 
> I don't agree with this statement. Rather, I would say that OVMF
> follows the EDK II method of publishing tables, which means
> EFI_ACPI_TABLE_PROTOCOL.
> 
> In the past we were a good little sample platform, and provided the
> ACPI tables directly. Well, that is less and less the case. But, is it
> a good idea to stop using EFI_ACPI_TABLE_PROTOCOL?

No. It's not a good idea.

But if we want to support the qemu interface, in the manner that
interface has been intended, then I can see no way around avoiding
EFI_ACPI_TABLE_PROTOCOL.

The only way you could reliably fish out tables, operation regions etc.
from the qemu payload would be to write a near-full ACPI interpreter.
The goal of the interface is the polar opposite, ie. to require the
firmware to know the least possible about ACPI table specifics.

> What about MdeModulePkg/Universal/Network/IScsiDxe/IScsiIbft.c, which
> uses EFI_ACPI_TABLE_PROTOCOL?

Good find.

> Do we need to keep monitoring which EDK II drivers decide to use
> EFI_ACPI_TABLE_PROTOCOL,

I guess so.

> or can we find a way to make these work
> together?

I doubt it.

The current in-tree solution is probably as good as it gets with
EFI_ACPI_TABLE_PROTOCOL. It would co-operate with IScsiIbft.c, but (if
you read the TPM thread I linked from qemu-devel) it would install a
broken TCPA table from QEMU, for example.

> If the answer is no, then I wonder if this is something that
> UEFI or EDK II needs to consider.

Maybe it is.

As far as the UEFI spec goes, EFI_ACPI_TABLE_PROTOCOL looks like the
canonical way.

RSD PTR being referenced in the config table is not even part of the
UEFI spec (if I searched it right); it's described in the ACPI spec. The
UEFI spec only names the relevant GUIDs, but doesn't explain how to use
them.

In any case, under the IBFT example you name, we have a conflict because
ACPI tables have two genuine, distinct sources. IBFT comes from the
firmware, while the rest would come from QEMU.

(I don't know if IBFT could be provided by QEMU. The ACPI 5.1 spec
doesn't describe the table. Googling led me to a license acceptance
window at Microsoft's site, which I closed.)

In practice, IBFT seems less important than the tables that QEMU does
offer 

Re: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from UEFI 2.4

[Gao, Liming]

Samer:
  I have one minor comment. Could you help add the description for new 
IMAGE_ATTRIBUTE_UEFI_IMAGE like other definition, such as 
IMAGE_ATTRIBUTE_IN_USE?

Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Monday, August 25, 2014 11:32 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition 
from UEFI 2.4

Thanks Liming

From: Gao, Liming [mailto:liming@intel.com]
Sent: Monday, August 25, 2014 10:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition 
from UEFI 2.4

The patch is good. I will help commit it.

Reviewed-by: Gao, Liming mailto:liming@intel.com>>

Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:16 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from 
UEFI 2.4

Dear MdePkg maintainers,

Please find the attached patch that adds IMAGE_ATTRIBUTE_UEFI_IMAGE definition 
from UEFI 2.4 specification.


Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition from UEFI 2.4 specification.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

[Andrew Fish]

On Aug 25, 2014, at 6:03 PM, Laszlo Ersek  wrote:

> On 08/26/14 02:12, Jordan Justen wrote:
>> On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek  wrote:
>>> On 08/26/14 00:24, Jordan Justen wrote:
 On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek  wrote:
> Recent changes in the QEMU ACPI table generator have shown that our
> limited client for that interface is insufficient and/or brittle.
> 
> Implement the full interface utilizing OrderedCollectionLib for addressing
> fw_cfg blobs by name.
> 
> In addition, we stop using EFI_ACPI_TABLE_PROTOCOL in the QEMU loader
> client, because:
> - splitting the blobs for EFI_ACPI_TABLE_PROTOCOL is just untenable short
>  of a complete ACPI parser,
> - and it is fully sufficient to install the RSD PTR as an EFI
>  configuration table for the guest OS to see everything.
> 
> In short, for this interface, EFI_ACPI_TABLE_PROTOCOL is an unwanted and
> restrictive convenience; let's stop using it.
 
 Hmm. Been through a few rounds of this for Xen. It's QEMU's turn now? :)
 
 Is this required?
>>> 
>>> Depends on how good (how accurate) ACPI tables you want to have in your
>>> VMs. For a few qemu releases now, qemu has been the "master" of ACPI
>>> payload generation. SeaBIOS too has kept its own builtin tables, yes,
>>> but when the QEMU generated payload is available, it interprets this
>>> linker/loader script just the same.
>>> 
>>> If you want PCI hotplug, pvpanic support; or, going forward, memory
>>> hotplug, then yes, those things need ACPI support, and the ACPI stuff
>>> for them is now developed in QEMU (and dynamically generated by it,
>>> dependent on the actual hardware config).
>>> 
 What happens if another driver uses EFI_ACPI_TABLE_PROTOCOL? We now
 have two drivers that want to install the pointer.
>>> 
>>> Yes, I checked that. The UEFI spec says that whenever you install a
>>> configuration table that's already present (by GUID), the reference is
>>> updated.
>>> 
>>>  InstallConfigurationTable()
>>> 
>>>  [...]
>>>  * If Guid is present in the System Table, and Table is not NULL, then
>>>the (Guid, Table) pair is updated with the new Table value.
>>>  [...]
>>> 
>>> For this reason, the first thing InstallAllQemuLinkedTables() does is
>>> check, with EfiGetSystemConfigurationTable(), for the presence of any of
>>> the ACPI GUIDs in the config table.
>>> 
>>> There's no "absolute" cure against another driver in OVMF just grabbing
>>> EFI_ACPI_TABLE_PROTOCOL and installing its own stuff (which would then
>>> completely hide the tables installed by this patchset, because
>>> "MdeModulePkg/Universal/Acpi/AcpiTableDxe" would simply replace QEMU's
>>> RSD PTR's address in the UEFI config table with its own).
>>> 
>>> But ACPI tables are not randomly installed in OVMF, we keep it
>>> centralized in AcpiTableDxe.
>> 
>> I don't agree with this statement. Rather, I would say that OVMF
>> follows the EDK II method of publishing tables, which means
>> EFI_ACPI_TABLE_PROTOCOL.
>> 
>> In the past we were a good little sample platform, and provided the
>> ACPI tables directly. Well, that is less and less the case. But, is it
>> a good idea to stop using EFI_ACPI_TABLE_PROTOCOL?
> 
> No. It's not a good idea.
> 
> But if we want to support the qemu interface, in the manner that
> interface has been intended, then I can see no way around avoiding
> EFI_ACPI_TABLE_PROTOCOL.
> 
> The only way you could reliably fish out tables, operation regions etc.
> from the qemu payload would be to write a near-full ACPI interpreter.
> The goal of the interface is the polar opposite, ie. to require the
> firmware to know the least possible about ACPI table specifics.
> 

I wonder if there are other cases when the platform “knows more” than the edk2 
driver producing the ACPI tables? Maybe having a PCD feature flag to turn off 
ACPI table production in the modules would make sense?

Thanks,

Andrew Fish


>> What about MdeModulePkg/Universal/Network/IScsiDxe/IScsiIbft.c, which
>> uses EFI_ACPI_TABLE_PROTOCOL?
> 
> Good find.
> 
>> Do we need to keep monitoring which EDK II drivers decide to use
>> EFI_ACPI_TABLE_PROTOCOL,
> 
> I guess so.
> 
>> or can we find a way to make these work
>> together?
> 
> I doubt it.
> 
> The current in-tree solution is probably as good as it gets with
> EFI_ACPI_TABLE_PROTOCOL. It would co-operate with IScsiIbft.c, but (if
> you read the TPM thread I linked from qemu-devel) it would install a
> broken TCPA table from QEMU, for example.
> 
>> If the answer is no, then I wonder if this is something that
>> UEFI or EDK II needs to consider.
> 
> Maybe it is.
> 
> As far as the UEFI spec goes, EFI_ACPI_TABLE_PROTOCOL looks like the
> canonical way.
> 
> RSD PTR being referenced in the config table is not even part of the
> UEFI spec (if I searched it right); it's described in the ACPI spec. The
> UEFI spec only names the relevant GUIDs, but doesn't explain how to use
> them.

Re: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

[Gao, Liming]

Samer:
  Label Opcode is EDKII extension GUIDED opcode, not standard UEFI HII opcode. 
And, HiiLib is generic HII Library for UEFI HII. So, I don't suggest to include 
this API in HiiLib.

Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 12:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

Dear MdeModulePkg maintainers,

Please find the attached patch that adds a new function 
HiiCreateGuidLabelOpCode() to HiiLib


Add a new function HiiCreateGuidLabelOpCode() to HiiLib to help with creation 
of Label IFR op-codes dynamically


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

[El-Haj-Mahmoud, Samer]

Fair enough. How about an HiiExLib library in IntelFrameworkModulePkg ?







-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Monday, 25 Aug 2014, 8:26PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: Re: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

Samer:
  Label Opcode is EDKII extension GUIDED opcode, not standard UEFI HII opcode. 
And, HiiLib is generic HII Library for UEFI HII. So, I don’t suggest to include 
this API in HiiLib.

Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 12:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

Dear MdeModulePkg maintainers,

Please find the attached patch that adds a new function 
HiiCreateGuidLabelOpCode() to HiiLib


Add a new function HiiCreateGuidLabelOpCode() to HiiLib to help with creation 
of Label IFR op-codes dynamically


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Gao, Liming]

Jordan:
  The real requirement is that some users use UPT to install core package into 
the different directories, such as Core\MdePkg.  After the installation, they 
want to easily compare the original package and installed package. 
  
  This change is required by EDKII project major release, but not required for 
daily development. 

  The section order will not be changed unless new section are introduced in 
INF/DEC.  

  Yes. Those changes are directly output from UPT tool. And, we have test to 
cover this tool. So, I have  confidence. 

  So far, I have no branch for those change. If you request, I could send zip 
the source INF/DEC (before UPT and after UPT) to you. 

Thanks
Liming
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Tuesday, August 26, 2014 5:03 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages

On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming  wrote:
> Hi, all
>
>   This patch is for below  ITEM 7. INF/DEC are generated from UPT tool.
> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. 
> Please help review them.
>
>MdePkg: Make sure order of DEC/INF content matches the order that 
> UPT generates in the XML -> INF conversion

This patch subject line is much longer than the recommended 70 character limit:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

How about:
MdePkg DEC/INF: Match format required by UPT

These changes seem to arbitrarily match the 'order of some tool', but why is 
that required?

What happens when someone edits these files, and doesn't get the order 'just 
right'?

Is the order that UPT uses strict, or will it potentially change in the future, 
if for example, the version of some library being used by the tool decides to 
change the way it orders things.

There seems to be other formatting happening, such as spaces removed from the 
copyright notice.

All this rolled up into a single change seems to have produced something that 
is not reviewable in a reasonable amount of time.

Another question I have is, were these changes the result of the output of the 
tool? I guess it would be easier to have some confidence in the output of a 
tool rather than all of these changes having been manually applied.

Do you have the changes available in a branch to make it easy to test?
(No, I would not want an svn branch to be added for this.)

-Jordan

> 1)  Section Order in INF/DEC to match the ones generated from UPT
>
> 2)  Guid value in section will be align.
>
> 3)  Usage comments in section will be align.
>
> 4)  One PCD section includes one PCD type. If one PCD supports more PCD
> types, it will be listed in each PCD type section  in DEC file.
>
>
>
> Contributed-under: TianoCore Contribution Agreement 1.0
>
> Signed-off-by: Gao, Liming 
>
>
>
> Thanks
>
> Liming
>
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Thursday, August 14, 2014 10:13 AM
> 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 IN

Re: [edk2] [PATCH 5/8] MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version

[Gao, Liming]

Jordan:
  I am ok to skip 'xor rax, rax'.
  I think NASM 2.07 better.   

Thanks
Liming
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Tuesday, August 26, 2014 4:26 AM
To: edk2-devel@lists.sourceforge.net; Gao, Liming
Subject: Re: [edk2] [PATCH 5/8] MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 
with NASM version

Liming,

I tested your changes with NASM 2.11, and they worked fine.

One question. I think the 'xor rax, rax' is not needed, so should we skip that? 
(I tested with and without it.)

I then tested NASM 2.03, which we had copied from VTF0 as the required minimum 
version. It built with your changes, but I found that the code produced by 2.03 
would not boot in OVMF.

I then tested NASM 2.07, and I found that it would boot fine.

All,

Should we require NASM 2.07 or newer rather than 2.03?

NASM 2.07 was released in July 2009. (NASM 2.03 was June 2008)

One other note, that is not particularly relevant, but NASM 2.07 was when NASM 
changed to the BSD license.

-Jordan

On Wed, Aug 20, 2014 at 5:46 PM, Gao, Liming  wrote:
> Hi, I meet with the same issue. I verify it in my ubutu 12.04. GCC46, Nasm 
> 2.09. I meet with the build failure.
> 1) 0x10 is not power of two.
> 2) invalid combination of opcode and operands
>
>   I provide my patch that can pass build. Please help review it.
>
> diff --git a/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm 
> b/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> index 2e5a580..105238d 100644
> --- a/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> +++ b/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
> @@ -174,7 +174,7 @@ BITS16
>
>  o32 retf; transfer control to user code
>
> -ALIGN   0x10
> +ALIGN   16
>  _NullSegDescDQ  0
>  _16CsDesc:
>  DW  -1
> diff --git a/MdePkg/Library/BaseLib/X64/Thunk16.nasm 
> b/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> index 8858e74..e11bb24 100644
> --- a/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> +++ b/MdePkg/Library/BaseLib/X64/Thunk16.nasm
> @@ -190,7 +190,7 @@ o32 lidt[cs:bp + (_16Idtr - .Base)]
>
>  o32 retf; transfer control to user code
>
> -ALIGN   0x8
> +ALIGN   8
>
>  CODE16  equ _16Code - $
>  DATA16  equ _16Data - $
> @@ -237,11 +237,12 @@ BITS64
>  pushrsi
>  pushrdi
>
> -mov rbx, ds
> +xor rbx, rbx
> +mov ebx, ds
>  pushrbx  ; Save ds segment register on the stack
> -mov rbx, es
> +mov ebx, es
>  pushrbx  ; Save es segment register on the stack
> -mov rbx, ss
> +mov ebx, ss
>  pushrbx  ; Save ss segment register on the stack
>
>  pushfs
> @@ -307,11 +308,11 @@ BITS64
>  pop gs
>  pop fs
>  pop rbx
> -mov ss, rbx
> +mov ss, ebx
>  pop rbx
> -mov es, rbx
> +mov es, ebx
>  pop rbx
> -mov ds, rbx
> +mov ds, ebx
>
>  pop rdi
>  pop rsi
>
> -Original Message-
> From: Mike Maslenkin [mailto:miha...@parallels.com]
> Sent: Thursday, August 21, 2014 5:40 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH 5/8] MdePkg/BaseLib Thunk16: Replace X64 
> GAS Thunk16 with NASM version
>
> Hello Jordan !
> build -p  build -p IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
> -a X64
> told me about next errors:
>
> Building ... 
> /home/mg/sources/jljusten/edk2/MdePkg/Library/BaseReportStatusCodeLibN
> ull/BaseReportStatusCodeLibNull.inf [X64]
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC
> 47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:193: 
> error: segment alignment `0x8' is not power of two
> make: ***
> [/home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GC
> C47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.obj] Error 1
>
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC
> 47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:240: 
> error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC
> 47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:242: 
> error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC
> 47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:244: 
> error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC
> 47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:310: 
> error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC
> 47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/Thunk16.iii:312: 
> error: invalid combination of opcode and operands
> /home/mg/sources/jljusten/edk2/Build/IntelFrameworkModuleAll/DEBUG_GCC
> 47/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64

Re: [edk2] [BaseTools]Support a force binary build mode

[Liu, Yingke D]

Reviewed-by: Yingke Liu 

Dennis

From: Chen, Hesheng [mailto:hesheng.c...@intel.com]
Sent: Monday, August 25, 2014 10:53 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [BaseTools]Support a force binary build mode

Hello all,
Could you help review this patch?

This patch is going to:

1.   Support a force binary build mode by adding "--ignore-source" to 
command line options.



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

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Tim Lewis]

Liming --

I think Jordan's question is: is the grammar of the INF/DEC file changing?

I think the answer is: "No. Since UPT generates these files, it would be nice 
that the order matches."

Tim

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Tuesday, August 26, 2014 10:01 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages

Jordan:
  The real requirement is that some users use UPT to install core package into 
the different directories, such as Core\MdePkg.  After the installation, they 
want to easily compare the original package and installed package. 
  
  This change is required by EDKII project major release, but not required for 
daily development. 

  The section order will not be changed unless new section are introduced in 
INF/DEC.  

  Yes. Those changes are directly output from UPT tool. And, we have test to 
cover this tool. So, I have  confidence. 

  So far, I have no branch for those change. If you request, I could send zip 
the source INF/DEC (before UPT and after UPT) to you. 

Thanks
Liming
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com]
Sent: Tuesday, August 26, 2014 5:03 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages

On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming  wrote:
> Hi, all
>
>   This patch is for below  ITEM 7. INF/DEC are generated from UPT tool.
> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. 
> Please help review them.
>
>MdePkg: Make sure order of DEC/INF content matches the order that 
> UPT generates in the XML -> INF conversion

This patch subject line is much longer than the recommended 70 character limit:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

How about:
MdePkg DEC/INF: Match format required by UPT

These changes seem to arbitrarily match the 'order of some tool', but why is 
that required?

What happens when someone edits these files, and doesn't get the order 'just 
right'?

Is the order that UPT uses strict, or will it potentially change in the future, 
if for example, the version of some library being used by the tool decides to 
change the way it orders things.

There seems to be other formatting happening, such as spaces removed from the 
copyright notice.

All this rolled up into a single change seems to have produced something that 
is not reviewable in a reasonable amount of time.

Another question I have is, were these changes the result of the output of the 
tool? I guess it would be easier to have some confidence in the output of a 
tool rather than all of these changes having been manually applied.

Do you have the changes available in a branch to make it easy to test?
(No, I would not want an svn branch to be added for this.)

-Jordan

> 1)  Section Order in INF/DEC to match the ones generated from UPT
>
> 2)  Guid value in section will be align.
>
> 3)  Usage comments in section will be align.
>
> 4)  One PCD section includes one PCD type. If one PCD supports more PCD
> types, it will be listed in each PCD type section  in DEC file.
>
>
>
> Contributed-under: TianoCore Contribution Agreement 1.0
>
> Signed-off-by: Gao, Liming 
>
>
>
> Thanks
>
> Liming
>
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Thursday, August 14, 2014 10:13 AM
> 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.  Th

Re: [edk2] [BaseTools]Implement the external PCD database generation rule to support the case that all binary driver are only listed in FDF file.

[Liu, Yingke D]

Patch looks good to me.
Reviewed-by: Yingke Liu 

Dennis

From: Feng, Bob C
Sent: Monday, August 25, 2014 1:49 PM
To: Liu, Yingke D; 'edk2-devel@lists.sourceforge.net'
Subject: RE: [edk2] [BaseTools]Implement the external PCD database generation 
rule to support the case that all binary driver are only listed in FDF file.

Hi Dennis,

I update the patch with a minor change. Please help to review.

Thanks a lot.

-Bob

From: Feng, Bob C
Sent: Monday, August 25, 2014 9:30 AM
To: Liu, Yingke D; 
edk2-devel@lists.sourceforge.net
Subject: [edk2] [BaseTools]Implement the external PCD database generation rule 
to support the case that all binary driver are only listed in FDF file.

Hi Dennis,
Could you help review this patch?

[Description]
This patch is going to correct the external PCD database generation rule to 
support the case that all binary driver are only listed in FDF file.



Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Feng, Bob C bob.c.f...@intel.com



Best Regards,
Bob Feng

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] EFI_TCP4_PROTOCOL->Cancel() not implemented

[Thomas Rognon]

Is there any plan to implement EFI_TCP4_PROTOCOL->Cancel()? Right now it's
just a stub that returns EFI_UNSUPPORTED.

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Main.c

I'll have to use timers again to hack my way around this.

Also, TcpIoLib's TcpIoReceive() relies on Cancel() and thus breaks after an
EFI_TIMEOUT since Cancel() doesn't do anything.

Thomas Rognon
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Andrew Fish]

On Aug 25, 2014, at 7:01 PM, Gao, Liming  wrote:

> Jordan:
>  The real requirement is that some users use UPT to install core package into 
> the different directories, such as Core\MdePkg.  After the installation, they 
> want to easily compare the original package and installed package. 
> 

How is this compare done? How is it going to be easy if I get the weakly 
development version from some one who has a different location for the MdePkg 
than in my tree? So I will get a diff hit on 100% of the INF files, when I 
really just looking for the incremental changes. Not the relative changes 
caused by the path differences. 

How does the build deal with MdePkg and MdeModulePkg containing 
MdePkg/MdePkg.dec and the “Other code” containing Core/MdePkg/MdePkg.dec. How 
do I combine edk2 + vendor a + vendor b code together in a working tree and 
still grep against their original drops? As the edk2, vendor a, and vendor b 
should all not get the final say in the tree structure we end up with. Do I 
need to put all the edk2 packages in / (edk2) Core/ (vendor a) and edk2/ 
(vendor b) so each version matches?

Currently we work around this by adding search paths to $WORKSPACE as a local 
hack to the BaseTools. 

Also when is this stuff going to be real? It looks like UDK 2014 is svn tags 
and a Zip file of code. Does that mean the UDK 2017 (2014 +  (2014 - 2011)) we 
will use UPT to install the packages as the only option? The folks doing 
Core\MdePkg also like to release zip files with code. So all this UPT cleanup 
is making getting real work done harder…

Seems like you guys should add some features to the build system so that daily 
development is not made worse by these UPT changes. 
1) Allow search paths in the $WORKSPACE. So if some one moves the edk2 packages 
to Core/ you can add $(WORKSPACE)/Core as a search path and not need to change 
every INF in the system. 
2) Given the current UPT cleanup we should add $WORKSPACE aliases so you don’t 
need to have MdePkg in /, Core/, and edk2/. 

Thanks,

Andrew Fish


>  This change is required by EDKII project major release, but not required for 
> daily development. 
> 
>  The section order will not be changed unless new section are introduced in 
> INF/DEC.  
> 
>  Yes. Those changes are directly output from UPT tool. And, we have test to 
> cover this tool. So, I have  confidence. 
> 
>  So far, I have no branch for those change. If you request, I could send zip 
> the source INF/DEC (before UPT and after UPT) to you. 
> 
> Thanks
> Liming
> -Original Message-
> From: Jordan Justen [mailto:jljus...@gmail.com] 
> Sent: Tuesday, August 26, 2014 5:03 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II 
> packages
> 
> On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming  wrote:
>> Hi, all
>> 
>>  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool.
>> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. 
>> Please help review them.
>> 
>>   MdePkg: Make sure order of DEC/INF content matches the order that 
>> UPT generates in the XML -> INF conversion
> 
> This patch subject line is much longer than the recommended 70 character 
> limit:
> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
> 
> How about:
> MdePkg DEC/INF: Match format required by UPT
> 
> These changes seem to arbitrarily match the 'order of some tool', but why is 
> that required?
> 
> What happens when someone edits these files, and doesn't get the order 'just 
> right'?
> 
> Is the order that UPT uses strict, or will it potentially change in the 
> future, if for example, the version of some library being used by the tool 
> decides to change the way it orders things.
> 
> There seems to be other formatting happening, such as spaces removed from the 
> copyright notice.
> 
> All this rolled up into a single change seems to have produced something that 
> is not reviewable in a reasonable amount of time.
> 
> Another question I have is, were these changes the result of the output of 
> the tool? I guess it would be easier to have some confidence in the output of 
> a tool rather than all of these changes having been manually applied.
> 
> Do you have the changes available in a branch to make it easy to test?
> (No, I would not want an svn branch to be added for this.)
> 
> -Jordan
> 
>> 1)  Section Order in INF/DEC to match the ones generated from UPT
>> 
>> 2)  Guid value in section will be align.
>> 
>> 3)  Usage comments in section will be align.
>> 
>> 4)  One PCD section includes one PCD type. If one PCD supports more PCD
>> types, it will be listed in each PCD type section  in DEC file.
>> 
>> 
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> 
>> Signed-off-by: Gao, Liming 
>> 
>> 
>> 
>> Thanks
>> 
>> Liming
>> 
>> From: Gao, Liming [mailto:liming@intel.com]
>> Sent: Thursday, August 14, 2014 10:13 AM
>> To: edk2-devel@lists.sourcef

Re: [edk2] Circular Dependency Between DxePrintLibPrint2Protocol and BaseDebugLibSerialPort

[Tim Lewis]

Eugene -

We found this also when because there are DEBUG macros in the serial port 
library. Is this the root cause of what you found? We finally had to hack the 
library constructors, but it was messy.

Tim

From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, August 26, 2014 7:49 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Circular Dependency Between DxePrintLibPrint2Protocol and 
BaseDebugLibSerialPort

Dear maintainers of DebugLib and PrintLib,

It looks like we have a circular dependency between the 
DxePrintLibPrint2Protocol library (which uses ASSERT) and 
BaseDebugLibSerialPort library (which uses AsciiSPrint):

1>.dsc(...) : error F002: Library 
[c:\edk2\MdeModulePkg\Library\DxePrintLibPrint2Protocol\DxePrintLibPrint2Protocol.inf]
 with constructors has a cycle
1>consumed by 
c:\edk2\MdePkg\Library\BaseDebugLibSerialPort\BaseDebugLibSerialPort.inf

so it seems that this library combination is incompatible.  Is there a 
preferred way to resolve this?

I see some platforms use the status code variant of DebugLib 
(PeiDxeDebugLibReportStatusCode) but I'd prefer a solution that allows us to 
keep using the simple BaseDebugLibSerialPort.

Thanks,

Eugene
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] r15893 "going to correct the external PCD database generation rule to support the case that all binary driver are only listed in FDF file."

[Tim Lewis]

I saw this revision was just checked in. Can someone explain how you do this?

Currently, the PCD database is built as a firmware file section and integrated 
directly into the PcdPei and PcdDxe drivers. In the binary only case, how is 
the firmware file section integrated into these binary-only drivers?

Thanks,

Tim
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [BaseTools] [UPT] Add some new feature support on UPT

[Gao, Liming]

Hess:
  The change is good to me.
  Reviewed-by: Gao, Liming 

Thanks
Liming
From: Chen, Hesheng
Sent: Monday, August 25, 2014 4:30 PM
To: Gao, Liming; edk2-devel@lists.sourceforge.net
Subject: [edk2] [BaseTools] [UPT] Add some new feature support on UPT

Hello Liming,
Could you help review this patch? Thank you

This patch is going to:

1.   Add a recovery mode for UPT failure

2.   Add UNI file support

3.   Add binary file header support

4.   Add support for PCD error message

5.   Add support for replace

6.   Format generated INF/DEC files

7.   Update dependency check

8.   Other minor fixes





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

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] r15893 "going to correct the external PCD database generation rule to support the case that all binary driver are only listed in FDF file."

[Gao, Liming]

Tim:
  PCD database is built as a firmware file section and integrated into PcdPei 
and PcdDxe driver FFS file. This happens on GenFds phase. When build the 
platform that have the binary drivers with DynamicEx PCD, PCD database will be 
generated to include those DynamicEx PCD information, then GenFds phase will 
add  PCD database section into PCD driver FFS file.

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, August 26, 2014 12:10 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] r15893 "going to correct the external PCD database generation 
rule to support the case that all binary driver are only listed in FDF file."

I saw this revision was just checked in. Can someone explain how you do this?

Currently, the PCD database is built as a firmware file section and integrated 
directly into the PcdPei and PcdDxe drivers. In the binary only case, how is 
the firmware file section integrated into these binary-only drivers?

Thanks,

Tim
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Circular Dependency Between DxePrintLibPrint2Protocol and BaseDebugLibSerialPort

[Gao, Liming]

Hi,
  You can use MdePkg\Library\BasePrintLib\BasePrintLib.inf when you use 
BaseDebugLibSerialPort library.

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, August 26, 2014 12:09 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Circular Dependency Between DxePrintLibPrint2Protocol and 
BaseDebugLibSerialPort

Eugene -

We found this also when because there are DEBUG macros in the serial port 
library. Is this the root cause of what you found? We finally had to hack the 
library constructors, but it was messy.

Tim

From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, August 26, 2014 7:49 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Circular Dependency Between DxePrintLibPrint2Protocol and 
BaseDebugLibSerialPort

Dear maintainers of DebugLib and PrintLib,

It looks like we have a circular dependency between the 
DxePrintLibPrint2Protocol library (which uses ASSERT) and 
BaseDebugLibSerialPort library (which uses AsciiSPrint):

1>.dsc(...) : error F002: Library 
[c:\edk2\MdeModulePkg\Library\DxePrintLibPrint2Protocol\DxePrintLibPrint2Protocol.inf]
 with constructors has a cycle
1>consumed by 
c:\edk2\MdePkg\Library\BaseDebugLibSerialPort\BaseDebugLibSerialPort.inf

so it seems that this library combination is incompatible.  Is there a 
preferred way to resolve this?

I see some platforms use the status code variant of DebugLib 
(PeiDxeDebugLibReportStatusCode) but I'd prefer a solution that allows us to 
keep using the simple BaseDebugLibSerialPort.

Thanks,

Eugene
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] build ovmf failure

[chen.fan.f...@cn.fujitsu.com]

On Mon, 2014-08-25 at 15:04 +, Gao, Liming wrote: 
> After you update EDKII code base, please remove Conf/build_rules.txt first, 
> then call edksetup script to copy new build_rules.txt
> 
> And, you also need to install nasm compiler.
> 

thanks, after remove build_rule.txt, I built it successfully.
Chen


> -Original Message-
> From: Sergey Isakov [mailto:isakov...@bk.ru] 
> Sent: Monday, August 25, 2014 9:23 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] build ovmf failure
> 
> Did you update Conf/build_rules.txt to use nasm?
> 
> On 25.08.2014, at 14:29, chen.fan.f...@cn.fujitsu.com wrote:
> 
> > Hi,
> > 
> > I always built OVMF successfully, but today I pull the newest edk2 
> > code to build OVMF then showing building failure:
> > 
> > 
> > Architecture(s)  = X64
> > Build target = DEBUG
> > Toolchain= GCC47
> > 
> > Active Platform
> > = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.dsc
> > Flash Image Definition
> > = /home/chenfan/data/edk2/OvmfPkg/OvmfPkgX64.fdf
> > 
> > Processing meta-data ...
> > 
> > build.py...
> > : error F000: Nothing to build
> >   [/home/chenfan/data/edk2/OvmfPkg/ResetVector/ResetVector.inf]
> > 
> > 
> > - Failed -
> > Build end time: 18:16:43, Aug.25 2014
> > Build total time: 00:00:03
> > ---
> > 
> > and I use the code last git commit ID is:
> > 
> > commit f056e4c18047e9a0157a915175d07afbd8b8c581
> > Author: Jaben Carsey 
> > Date:   Fri Aug 22 17:02:11 2014 +
> > 
> >ShellPkg: Update 'pci' command for updated class codes
> > 
> > 
> > Did someone encounter this problem too?
> > how can I fix it?
> > any help will be appreciated.
> > 
> > 
> > Thanks,
> > Chen
> > 
> > 
> > 
> > --
> > 
> > Slashdot TV.  
> > Video for Nerds.  Stuff that matters.
> > http://tv.slashdot.org/
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 
> 
> --
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 
> --
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools: Add support for ${s_*} and ${d_*} macros in FDF files

[Liu, Yingke D]

Hi Samer,

Thanks for this patch, it's really a good new feature, we will evaluate this 
feature and let you know the feedback later.

Thanks,
Dennis

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 4:59 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] BaseTools: Add support for ${s_*} and ${d_*} macros in 
FDF files

Dear BaseTools maintainers,

Please see attached patch to:

Add support for ${s_*} and ${d_*} macros for in FDF file for the INF files, and 
for each statement in the build rules.
The following keywords are supported:
"src", "s_path", "s_dir", "s_name", "s_base", "s_ext", "dst", "d_path", 
"d_name", "d_base", "d_ext"


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Update EFI_DRIVER_HEALTH_HII_MESSAGE definition from UEFI 2.4

[Ni, Ruiyu]

Check in @15894.

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:13 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Update EFI_DRIVER_HEALTH_HII_MESSAGE definition 
from UEFI 2.4

Dear MdePkg maintainers,

Please find the attached patch that updates EFI_DRIVER_HEALTH_HII_MESSAGE 
definition from UEFI 2.4 specification.



Update EFI_DRIVER_HEALTH_HII_MESSAGE definition from UEFI 2.4 specification to 
replace Reserved with MessageCode.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
UEFI System Firmware Architect
HP - Industry Standard Servers (ISS)

el...@hp.com
T +1 281 514 5973
Hewlett-Packard Company
CCM07:M74-B228
Houston, TX 77070

[Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Gao, Liming]

Andrew:
  Yes. 100% change in INF file should be the path difference if they are from 
the same package.dist file. But, if original one is not UPT clean, the 
difference will be hard to be seen.  

  The main UPT change is [Section] order and some alignment. Why do you think 
it will bring hard to the real work? 

Thanks
Liming
-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Tuesday, August 26, 2014 11:38 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages


On Aug 25, 2014, at 7:01 PM, Gao, Liming  wrote:

> Jordan:
>  The real requirement is that some users use UPT to install core package into 
> the different directories, such as Core\MdePkg.  After the installation, they 
> want to easily compare the original package and installed package. 
> 

How is this compare done? How is it going to be easy if I get the weakly 
development version from some one who has a different location for the MdePkg 
than in my tree? So I will get a diff hit on 100% of the INF files, when I 
really just looking for the incremental changes. Not the relative changes 
caused by the path differences. 

How does the build deal with MdePkg and MdeModulePkg containing 
MdePkg/MdePkg.dec and the "Other code" containing Core/MdePkg/MdePkg.dec. How 
do I combine edk2 + vendor a + vendor b code together in a working tree and 
still grep against their original drops? As the edk2, vendor a, and vendor b 
should all not get the final say in the tree structure we end up with. Do I 
need to put all the edk2 packages in / (edk2) Core/ (vendor a) and edk2/ 
(vendor b) so each version matches?

Currently we work around this by adding search paths to $WORKSPACE as a local 
hack to the BaseTools. 

Also when is this stuff going to be real? It looks like UDK 2014 is svn tags 
and a Zip file of code. Does that mean the UDK 2017 (2014 +  (2014 - 2011)) we 
will use UPT to install the packages as the only option? The folks doing 
Core\MdePkg also like to release zip files with code. So all this UPT cleanup 
is making getting real work done harder...

Seems like you guys should add some features to the build system so that daily 
development is not made worse by these UPT changes. 
1) Allow search paths in the $WORKSPACE. So if some one moves the edk2 packages 
to Core/ you can add $(WORKSPACE)/Core as a search path and not need to change 
every INF in the system. 
2) Given the current UPT cleanup we should add $WORKSPACE aliases so you don't 
need to have MdePkg in /, Core/, and edk2/. 

Thanks,

Andrew Fish


>  This change is required by EDKII project major release, but not required for 
> daily development. 
> 
>  The section order will not be changed unless new section are introduced in 
> INF/DEC.  
> 
>  Yes. Those changes are directly output from UPT tool. And, we have test to 
> cover this tool. So, I have  confidence. 
> 
>  So far, I have no branch for those change. If you request, I could send zip 
> the source INF/DEC (before UPT and after UPT) to you. 
> 
> Thanks
> Liming
> -Original Message-
> From: Jordan Justen [mailto:jljus...@gmail.com]
> Sent: Tuesday, August 26, 2014 5:03 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK 
> II packages
> 
> On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming  wrote:
>> Hi, all
>> 
>>  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool.
>> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. 
>> Please help review them.
>> 
>>   MdePkg: Make sure order of DEC/INF content matches the order that 
>> UPT generates in the XML -> INF conversion
> 
> This patch subject line is much longer than the recommended 70 character 
> limit:
> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-F
> ormat
> 
> How about:
> MdePkg DEC/INF: Match format required by UPT
> 
> These changes seem to arbitrarily match the 'order of some tool', but why is 
> that required?
> 
> What happens when someone edits these files, and doesn't get the order 'just 
> right'?
> 
> Is the order that UPT uses strict, or will it potentially change in the 
> future, if for example, the version of some library being used by the tool 
> decides to change the way it orders things.
> 
> There seems to be other formatting happening, such as spaces removed from the 
> copyright notice.
> 
> All this rolled up into a single change seems to have produced something that 
> is not reviewable in a reasonable amount of time.
> 
> Another question I have is, were these changes the result of the output of 
> the tool? I guess it would be easier to have some confidence in the output of 
> a tool rather than all of these changes having been manually applied.
> 
> Do you have the changes available in a branch to make it easy to test?
> (No, I would not want an svn branch to be added for this.)
> 
> -Jordan
> 
>> 1)  Section Order in INF/DEC to 

Re: [edk2] [PATCH] BaseTools: Output build progress messages during pre-processing of build files

[Liu, Yingke D]

Hi Samer,

It's really a good enhancement. Since it's a change to build output, we have to 
evaluate if the new outputs impact current users or not.

Thanks,

Dennis

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 4:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] BaseTools: Output build progress messages during 
pre-processing of build files

Dear BaseTools maintainers,

Please see attached a minor change to build.py to display progress during 
processing meta-data (pre-processing and creating autogen files). Without this 
change, the build "pauses" for a long time giving the perception that some 
modules are taking a long time to build, when in fact it was pre-processing 
build files.

Minor change to build.py to display progress during processing meta-data 
(pre-processing and creating autogen files). Without this change, the build 
"pauses" for a long time giving the perception that some modules are taking a 
long time to build, when in fact it was pre-processing build files.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Tim Lewis]

Liming --

I think the real problem is: I don't like having tools change *any* files in 
other packages. This has been a long-standing issue with EDK2 and the packaging 
spec. Source code control can detect a 1 byte difference and show it as a 
change to me. Then I must do a file compare to determine if the change is real 
or not.

Every other item in the EDK2 build system can be controlled through the .dsc or 
the .fdf file *except* the location of package .dec files. So, why not add a 
section to the .dsc file to specify the location of the package files.  If the 
[Packages] section in an INF has no path, then look it up in the .dsc file. 
Otherwise use the path specified in the .inf file.  

Something like this:
.dsc

[Packages]
  MdePkg.dec|MdePkg\MdePkg.dec (match MdePkg.dec from INF and use 
$(WORKSPACE)-relative 2nd half)

Tim


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

Andrew:
  Yes. 100% change in INF file should be the path difference if they are from 
the same package.dist file. But, if original one is not UPT clean, the 
difference will be hard to be seen.  

  The main UPT change is [Section] order and some alignment. Why do you think 
it will bring hard to the real work? 

Thanks
Liming
-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Tuesday, August 26, 2014 11:38 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages


On Aug 25, 2014, at 7:01 PM, Gao, Liming  wrote:

> Jordan:
>  The real requirement is that some users use UPT to install core package into 
> the different directories, such as Core\MdePkg.  After the installation, they 
> want to easily compare the original package and installed package. 
> 

How is this compare done? How is it going to be easy if I get the weakly 
development version from some one who has a different location for the MdePkg 
than in my tree? So I will get a diff hit on 100% of the INF files, when I 
really just looking for the incremental changes. Not the relative changes 
caused by the path differences. 

How does the build deal with MdePkg and MdeModulePkg containing 
MdePkg/MdePkg.dec and the "Other code" containing Core/MdePkg/MdePkg.dec. How 
do I combine edk2 + vendor a + vendor b code together in a working tree and 
still grep against their original drops? As the edk2, vendor a, and vendor b 
should all not get the final say in the tree structure we end up with. Do I 
need to put all the edk2 packages in / (edk2) Core/ (vendor a) and edk2/ 
(vendor b) so each version matches?

Currently we work around this by adding search paths to $WORKSPACE as a local 
hack to the BaseTools. 

Also when is this stuff going to be real? It looks like UDK 2014 is svn tags 
and a Zip file of code. Does that mean the UDK 2017 (2014 +  (2014 - 2011)) we 
will use UPT to install the packages as the only option? The folks doing 
Core\MdePkg also like to release zip files with code. So all this UPT cleanup 
is making getting real work done harder...

Seems like you guys should add some features to the build system so that daily 
development is not made worse by these UPT changes. 
1) Allow search paths in the $WORKSPACE. So if some one moves the edk2 packages 
to Core/ you can add $(WORKSPACE)/Core as a search path and not need to change 
every INF in the system. 
2) Given the current UPT cleanup we should add $WORKSPACE aliases so you don't 
need to have MdePkg in /, Core/, and edk2/. 

Thanks,

Andrew Fish


>  This change is required by EDKII project major release, but not required for 
> daily development. 
> 
>  The section order will not be changed unless new section are introduced in 
> INF/DEC.  
> 
>  Yes. Those changes are directly output from UPT tool. And, we have test to 
> cover this tool. So, I have  confidence. 
> 
>  So far, I have no branch for those change. If you request, I could send zip 
> the source INF/DEC (before UPT and after UPT) to you. 
> 
> Thanks
> Liming
> -Original Message-
> From: Jordan Justen [mailto:jljus...@gmail.com]
> Sent: Tuesday, August 26, 2014 5:03 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK 
> II packages
> 
> On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming  wrote:
>> Hi, all
>> 
>>  This patch is for below  ITEM 7. INF/DEC are generated from UPT tool.
>> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. 
>> Please help review them.
>> 
>>   MdePkg: Make sure order of DEC/INF content matches the order that 
>> UPT generates in the XML -> INF conversion
> 
> This patch subject line is much longer than the recommended 70 character 
> limit:
> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-F
> ormat
> 
> How about:
> MdePkg DEC/INF: Match fo

Re: [edk2] [PATCH] MdePkg: Add PMC/PMCSR definitions

[Ni, Ruiyu]

Checked in @15895


From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:09 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Add PMC/PMCSR definitions

Dear MdePkg maintainers,

Please find the attached patch that adds some PCI Power Management registers 
definitions to Pci22.h.



Add PCI PMC and PMCSR register definitions from PCI Power Management Interface 
Specification

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
UEFI System Firmware Architect
HP - Industry Standard Servers (ISS)

el...@hp.com
T +1 281 514 5973
Hewlett-Packard Company
CCM07:M74-B228
Houston, TX 77070

[Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Andrew Fish]

On Aug 25, 2014, at 10:05 PM, Gao, Liming  wrote:

> Andrew:
>  Yes. 100% change in INF file should be the path difference if they are from 
> the same package.dist file. But, if original one is not UPT clean, the 
> difference will be hard to be seen.  
> 

So when the Core/MdePkg vendor drops me a code base with 300+ INF files that 
have the edk2 location shifted if  I shift to my code base location I get 300 
files that show up in a git diff + what ever changed between the versions. This 
is a lot of overhead to find the changes. If I get a lot of incremental drops I 
get bogged down by all these changes. 

>  The main UPT change is [Section] order and some alignment. Why do you think 
> it will bring hard to the real work? 
> 

Adding new content that remains consistent between code bases is not an issue. 

Thanks,

Andrew Fish

> Thanks
> Liming
> -Original Message-
> From: Andrew Fish [mailto:af...@apple.com] 
> Sent: Tuesday, August 26, 2014 11:38 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II 
> packages
> 
> 
> On Aug 25, 2014, at 7:01 PM, Gao, Liming  wrote:
> 
>> Jordan:
>> The real requirement is that some users use UPT to install core package into 
>> the different directories, such as Core\MdePkg.  After the installation, 
>> they want to easily compare the original package and installed package. 
>> 
> 
> How is this compare done? How is it going to be easy if I get the weakly 
> development version from some one who has a different location for the MdePkg 
> than in my tree? So I will get a diff hit on 100% of the INF files, when I 
> really just looking for the incremental changes. Not the relative changes 
> caused by the path differences. 
> 
> How does the build deal with MdePkg and MdeModulePkg containing 
> MdePkg/MdePkg.dec and the "Other code" containing Core/MdePkg/MdePkg.dec. How 
> do I combine edk2 + vendor a + vendor b code together in a working tree and 
> still grep against their original drops? As the edk2, vendor a, and vendor b 
> should all not get the final say in the tree structure we end up with. Do I 
> need to put all the edk2 packages in / (edk2) Core/ (vendor a) and edk2/ 
> (vendor b) so each version matches?
> 
> Currently we work around this by adding search paths to $WORKSPACE as a local 
> hack to the BaseTools. 
> 
> Also when is this stuff going to be real? It looks like UDK 2014 is svn tags 
> and a Zip file of code. Does that mean the UDK 2017 (2014 +  (2014 - 2011)) 
> we will use UPT to install the packages as the only option? The folks doing 
> Core\MdePkg also like to release zip files with code. So all this UPT cleanup 
> is making getting real work done harder...
> 
> Seems like you guys should add some features to the build system so that 
> daily development is not made worse by these UPT changes. 
> 1) Allow search paths in the $WORKSPACE. So if some one moves the edk2 
> packages to Core/ you can add $(WORKSPACE)/Core as a search path and not need 
> to change every INF in the system. 
> 2) Given the current UPT cleanup we should add $WORKSPACE aliases so you 
> don't need to have MdePkg in /, Core/, and edk2/. 
> 
> Thanks,
> 
> Andrew Fish
> 
> 
>> This change is required by EDKII project major release, but not required for 
>> daily development. 
>> 
>> The section order will not be changed unless new section are introduced in 
>> INF/DEC.  
>> 
>> Yes. Those changes are directly output from UPT tool. And, we have test to 
>> cover this tool. So, I have  confidence. 
>> 
>> So far, I have no branch for those change. If you request, I could send zip 
>> the source INF/DEC (before UPT and after UPT) to you. 
>> 
>> Thanks
>> Liming
>> -Original Message-
>> From: Jordan Justen [mailto:jljus...@gmail.com]
>> Sent: Tuesday, August 26, 2014 5:03 AM
>> To: edk2-devel@lists.sourceforge.net
>> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK 
>> II packages
>> 
>> On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming  wrote:
>>> Hi, all
>>> 
>>> This patch is for below  ITEM 7. INF/DEC are generated from UPT tool.
>>> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. 
>>> Please help review them.
>>> 
>>>  MdePkg: Make sure order of DEC/INF content matches the order that 
>>> UPT generates in the XML -> INF conversion
>> 
>> This patch subject line is much longer than the recommended 70 character 
>> limit:
>> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-F
>> ormat
>> 
>> How about:
>> MdePkg DEC/INF: Match format required by UPT
>> 
>> These changes seem to arbitrarily match the 'order of some tool', but why is 
>> that required?
>> 
>> What happens when someone edits these files, and doesn't get the order 'just 
>> right'?
>> 
>> Is the order that UPT uses strict, or will it potentially change in the 
>> future, if for example, the version of some library being used by the tool 
>> decides to change the way it orders

Re: [edk2] [PATCH 00/10] add support for AArch64 QEMU/KVM

[Ard Biesheuvel]

On 25 August 2014 23:03, Laszlo Ersek  wrote:
> On 08/25/14 21:19, Ard Biesheuvel wrote:
>> This series adds a platform config to support QEMU based virtual machines,
>> either in TCG or KVM mode. These virtual machines declare their platform
>> configuration by passing a device tree which needs to be parsed by Tianocore
>> rather than relying on hardcoded peripherals.
>>
>> Currently, the only assumptions made with respect to the platform config are:
>> - at least 1 MB of DRAM at 0x4000_
>> - NOR flash at 0x0
>
> I'll strive to find the time to review this great series.
>

Thanks.

> But, in advance, can we put the flash somewhere else, like at 0x8 or
> 0x10? Every time we treat NULL as a valid pointer to a firmware volume
> *in C*, the fabric of the universe comes a bit more unstitched.
>

Fair enough. With the following added to the .fdf, I am able to drop
the patch to allow FVs at 0x0.

-0x|0x0020
+0x|0x1000
+DATA = {
+  0x0, 0x4, 0x0, 0x14   # b 0x1000
+}
+
+0x1000|0x001ff000

-- 
Ard.


> For one, if a standards-conformant compiler manages to deduce that your
> FV pointer is a null pointer, and then you dereference that pointer, the
> compiler will have carte blanche to do whatever it pleases (undefined
> behavior). We should not base this patchset on undefined behavior.
>
> Using a zero physical address might be fine in assembly, but it isn't
> fine in C, for two reasons:
>
> - On this specific implementation, the bit pattern for the zero
>   address, and the bit pattern for null pointers, coincide.
>
> - Per the C99 standard, 6.3.2.3 Pointers,
>
>   3 An integer constant expression with the value 0, or such an
> expression cast to type void *, is called a null pointer constant.
> [...]
>
> (As soon as the NOR flash's base address appears in the source code, in
> the form of an integer constant, and it's 0, we have big trouble. Not
> sure if this case ever occurs, but we shouldn't tempt it.)
>
> Again -- this would be perfectly fine in assembly, but given the C
> standard, it is not fine in C.
>
> Thanks
> Laszlo
>

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel