Re: [edk2] Build Tool Changes

[Tim Lewis]

Liming -

We also edit the binary images, and we don't use a separate binary. We simply 
emitted a signature ahead of the generated C array.

The main point is: continuing to add build tool changes without having public 
review before the commit causes other users of EDK2 (who may also have their 
own tools) to crash because formats and sizes change unexpectedly (PCD 
database!), and the community cannot improve or comment on the ideas. This is 
especially true in those areas related to non-UEFI and non-PI extensions 
because they create de-facto standards that others begin to depend upon.

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Tuesday, June 16, 2015 3:05 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Build Tool Changes

Tim:
  I agree that HII resource section for the same purpose. But now, most HII 
drivers still uses EDKII implement way to access VFR and UNI in source code. To 
support this usage model in the binary image, BaseTools will generate a binary 
file to record each offset for VFR and UNI packages in EFI image. Then, it can 
be integrated into FFS file in BIOS image. If so, the tool can parse BIOS image 
to get HII package data and analyze them.

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, June 12, 2015 9:45 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] Build Tool Changes

Would someone care to document the recent changes surrounding the VFR and UNI 
offsets encoded as a binary? I don't think I've seen this discussed anywhere. 
It seems to me that a better course of action would have been to solve the 
problem with linking the resources in the method defined in the UEFI 
specification.

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

Re: [edk2] FV FvName in FV Ext Entry

[Tim Lewis]

Liming -

Your e-mail answers part of my concern. The other part is: normally, changes to 
critical components are reviewed by the entire open-source community before 
they are checked in, not after. This is a new feature, with wide-ranging 
implications.

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Sunday, June 14, 2015 11:01 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] FV FvName in FV Ext Entry

Tim:
  Yes. We will update EDKII FDF and Build spec to describe this change. When 
the FvNameGuid entry is present in an [FV] section, the tools will generate an 
FvNameString entry in FV EXT header using the UiFvName. That means FvNameGuid 
and FvNameString will both be generated or not.

Thanks
Liming

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, June 12, 2015 9:56 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] FV FvName in FV Ext Entry

Would someone care to document the changes that were made to add the FV Name to 
the FV volume header? It would be helpful for other folks to know what Intel is 
planning here, and how it fits in with the overall scheme. Also, how to turn 
off this feature so that it is not generated.

Thanks,

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

Re: [edk2] FV FvName in FV Ext Entry

[Tim Lewis]

Liming -

I think you should allow a flag to indicate whether it should be generated or 
not. We would prefer that it not be generated and that optional features in FVs 
be turned off by default.

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Sunday, June 14, 2015 11:01 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] FV FvName in FV Ext Entry

Tim:
  Yes. We will update EDKII FDF and Build spec to describe this change. When 
the FvNameGuid entry is present in an [FV] section, the tools will generate an 
FvNameString entry in FV EXT header using the UiFvName. That means FvNameGuid 
and FvNameString will both be generated or not.

Thanks
Liming

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, June 12, 2015 9:56 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] FV FvName in FV Ext Entry

Would someone care to document the changes that were made to add the FV Name to 
the FV volume header? It would be helpful for other folks to know what Intel is 
planning here, and how it fits in with the overall scheme. Also, how to turn 
off this feature so that it is not generated.

Thanks,

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

[edk2] FV FvName in FV Ext Entry

[Tim Lewis]

Would someone care to document the changes that were made to add the FV Name to 
the FV volume header? It would be helpful for other folks to know what Intel is 
planning here, and how it fits in with the overall scheme. Also, how to turn 
off this feature so that it is not generated.

Thanks,

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

[edk2] Build Tool Changes

[Tim Lewis]

Would someone care to document the recent changes surrounding the VFR and UNI 
offsets encoded as a binary? I don't think I've seen this discussed anywhere. 
It seems to me that a better course of action would have been to solve the 
problem with linking the resources in the method defined in the UEFI 
specification.

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

Re: [edk2] "cond" vs. ?

[Tim Lewis]

There is already an example in the VFR specification. But there is no comment 
to indicate which is "TRUE" and which is "FALSE"

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, June 10, 2015 6:04 PM
To: edk2-devel@lists.sourceforge.net
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

Tim:
  How about add one example in VFR spec to explain it?

Thanks
Liming

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, June 10, 2015 5:11 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

Yes. But this is confusing because the VFR specification is not clear. As a 
result, many programmers assume that the cond() operator will work like the C ? 
operator.

How do we get the VFR specification updated?

Thanks,

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, June 10, 2015 5:01 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

Lewis:
  Second way. If (expr1) then x = expr3 else expr2

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, June 10, 2015 10:48 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc: Lawrence Chiu
Subject: [edk2] "cond" vs. ?

Folks -

It appears that the VFR spec is not clear about how the 2nd and 3rd parameters 
of the "cond" operator are handled.

cond(expr1, expr2, expr3)

Is it: if (expr1) then x = expr2 else expr3

Or

If (expr1) then x = expr3 else expr2

We have seen alternate implementations in the wild.

Thanks,

Tim

The VFR spec says:


conditionalExp ::=

"cond"

"("

vfrStatementExpression

"?"

vfrStatementExpression

":"

vfrStatementExpression

")"

BEHAVIORS AND RESTRICTIONS:

Generates EFI_IFR_CONDITIONAL op-codes.VFR Description in BNF 52

Example:

numeric varid = MyData.Data,

prompt = STRING_TOKEN(STR_PROMPT),

help = STRING_TOKEN(STR_HELP),

minimum = 0,

maximum = 255,

default value = cond(2 == 1 ? 5 : 10),
endnumeric;



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

Re: [edk2] "cond" vs. ?

[Tim Lewis]

Yes. But this is confusing because the VFR specification is not clear. As a 
result, many programmers assume that the cond() operator will work like the C ? 
operator.

How do we get the VFR specification updated?

Thanks,

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, June 10, 2015 5:01 PM
To: edk2-devel@lists.sourceforge.net
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

Lewis:
  Second way. If (expr1) then x = expr3 else expr2

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, June 10, 2015 10:48 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Cc: Lawrence Chiu
Subject: [edk2] "cond" vs. ?

Folks -

It appears that the VFR spec is not clear about how the 2nd and 3rd parameters 
of the "cond" operator are handled.

cond(expr1, expr2, expr3)

Is it: if (expr1) then x = expr2 else expr3

Or

If (expr1) then x = expr3 else expr2

We have seen alternate implementations in the wild.

Thanks,

Tim

The VFR spec says:


conditionalExp ::=

"cond"

"("

vfrStatementExpression

"?"

vfrStatementExpression

":"

vfrStatementExpression

")"

BEHAVIORS AND RESTRICTIONS:

Generates EFI_IFR_CONDITIONAL op-codes.VFR Description in BNF 52

Example:

numeric varid = MyData.Data,

prompt = STRING_TOKEN(STR_PROMPT),

help = STRING_TOKEN(STR_HELP),

minimum = 0,

maximum = 255,

default value = cond(2 == 1 ? 5 : 10),
endnumeric;



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

[edk2] "cond" vs. ?

[Tim Lewis]

Folks -

It appears that the VFR spec is not clear about how the 2nd and 3rd parameters 
of the "cond" operator are handled.

cond(expr1, expr2, expr3)

Is it: if (expr1) then x = expr2 else expr3

Or

If (expr1) then x = expr3 else expr2

We have seen alternate implementations in the wild.

Thanks,

Tim

The VFR spec says:


conditionalExp ::=

"cond"

"("

vfrStatementExpression

"?"

vfrStatementExpression

":"

vfrStatementExpression

")"

BEHAVIORS AND RESTRICTIONS:

Generates EFI_IFR_CONDITIONAL op-codes.VFR Description in BNF 52

Example:

numeric varid = MyData.Data,

prompt = STRING_TOKEN(STR_PROMPT),

help = STRING_TOKEN(STR_HELP),

minimum = 0,

maximum = 255,

default value = cond(2 == 1 ? 5 : 10),
endnumeric;



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

Re: [edk2] Question about SetPcd

[Tim Lewis]

Leo - PatchableInModule is not what you want, you need DynamicEx. Although 
Dynamic would also work, I wouldn't recommend it.

PatchableInModule builds the value into the .exe data section. In this case, 
SetPcd only changes that module 's data, not the other modules data.

Tim

Sent from my Windows Phone

From: Duran, Leo
Sent: ‎5/‎5/‎2015 11:06 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Question about SetPcd

I’m declaring a Pcd with some default value as [PcdsPatchableInModule.common], 
and here are my observations:

1)  In PEIM module1 after  SetPcdXX() with a new value and can read back 
the new value with GetPcdXX()

2)  However, from PEIM module2 (which runs later) GetPcdXX() returns the 
default declared value

Question: Is there a way to invoke SetPcdXX() so that the new value is 
persistent across modules?

Thanks,
Leo.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] EFI_SHELL_PROTOCOL installed on every App's imagehandle?

[Tim Lewis]

There is a single global instance of the EFI_SHELL_PROTOCOL. Use HandleProtocol.

Tim

From: tiger...@zhaoxin.com [mailto:tiger...@zhaoxin.com]
Sent: Wednesday, April 08, 2015 11:42 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] EFI_SHELL_PROTOCOL installed on every App's imagehandle?

Hi, experts:
I have a question about UEFI Shell App:

1.  UEFI App’s EntryPoint usually is as below:

UefiMain (

  IN EFI_HANDLEImageHandle,

  IN EFI_SYSTEM_TABLE  *SystemTable

  )



When launches App at Shell command prompt:

EFI_LOADED_IMAGE_PROTOCOL / EFI_SHELL_PARAMETERS_PROTOCOL will be installed on 
ImageHandle!



So:

How about EFI_SHELL_PROTOCOL?

Would it be also installed on ImageHandle?



I tried to :

  Status = gBS->OpenProtocol(

ImageHandle,

&gEfiShellProtocolGuid,

(VOID **)&pTstEfiShellProtocol,

ImageHandle,

NULL,

EFI_OPEN_PROTOCOL_GET_PROTOCOL

   );



But failed, and Status = EFI_UNSUPPORTED !

My Shell version is: (ver cmd in shell prompt)
UEFI Interactive Shell v2.1


Best wishes,


本邮件仅针对指定的收件人发送并可能含有保密或专有内容。任何非指定收件人所为之查阅、转发或使用本信息是不被允许的。
如果您误收到本邮件，请立即告知发件人并删除本邮件及所有附件。谢谢！
The information transmitted in this e-mail is intended only for the addressee 
and may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
e-mail in error, please notify the sender immediately, and delete this e-mail 
and any attachments. Thank you.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] libc for non-shell apps

[Tim Lewis]

Daryl -

Is there any progress on providing some or all of StdLib for non-shell apps in 
edk2? Which portions can be used independently now?

Tim
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] SEC PPI HOBs

[Tim Lewis]

Andrew –

It seems that this is tied to a missing data structure 
EFI_PEI_STARTUP_DESCRIPTOR, which is mentioned as mandatory, but not defined 
anywhere. Again, this looks like an earlier editorial issue.

Tim

From: Andrew Fish [mailto:af...@apple.com]
Sent: Monday, March 02, 2015 10:05 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] SEC PPI HOBs


On Mar 1, 2015, at 11:18 PM, Gao, Liming 
mailto:liming@intel.com>> wrote:

Andrew:
1.   This is a generic issue for PPI provided by SEC module only if this 
PPI needs touch data in CAR. PeiCore can’t handle them all if this PPI is not 
in PI spec.

I think Tim’s point was EFI_SEC_PLATFORM_INFORMATION_PPI is defined as 
(optional) in the PI spec. But it is the defined as “the way” to pass up BIST 
information on x86 systems.

The PI Spec also clearly states:
This same information will be placed in a GUIDed HOB with the PPI GUID as the 
HOB GUID. This allows agents, such as the DXE multiprocessor (MP) driver, to 
get health information for the boot-strap processor (BSP).

But it does not define who does the work. Which is the real bug


2.   SecCore is a platform module. The platform developer implements this 
PPI. So, I think the platform developer can do it.


Well the passing of information from SEC to PEI is “well defined” and the PEI 
core is required to register the PPI. So you could interpret that the PEI Core 
could do it? I think it also fair to assume the CPU PEIM would do this job, but 
that does not seem to exist in any of the X64 platforms. Since it is not clear 
in the spec who does the work, it seems all groups assumed a different module 
was responsible for the work.

At this point it looks like no platforms implement this feature, so the easiest 
way to fix it would have the PEI Core do it, and fix the PI spec to be clear on 
who should do it.

Thanks,

Andrew Fish

PS It looks like the PI spec wording needs to get cleaned up. I’l take this up 
with PIWG.


Thanks
Liming
From: Andrew Fish [mailto:af...@apple.com]
Sent: Sunday, March 01, 2015 2:47 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] SEC PPI HOBs


On Feb 27, 2015, at 11:18 PM, Gao, Liming 
mailto:liming@intel.com>> wrote:

PI spec doesn’t define the clear rule. So, this is not PeiCore compliant issue.
Like Jiewen say, Early PEIM that run before CAR down can consume data from PPI 
and publish HOB. It should be platform PEIM, because we can’t assure the 
generic PEIM is dispatched before CAR down.


I agree the issue with the spec is it is unclear who publishes the HOB. Which 
is why it is not being published today.

Since it is required on every platform it probably makes sense to do it in the 
PEI Core, vs. requiring every CPU PEIM to do it.

Thanks,

Andrew Fish




Thanks
Liming
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Saturday, February 28, 2015 2:34 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] SEC PPI HOBs

I think CPU PEIM need consume data from PPI and publish HOB.

CPU PEIM might also reinstall EFI_SEC_PLATFORM_INFORMATION_PPI to let PPI 
consume data from HOB. The Old EFI_SEC_PLATFORM_INFORMATION_PPI might refer 
data on CAR, which is not available after CAR teardown.

Thank you
Yao Jiewen

From: Andrew Fish [mailto:af...@apple.com]
Sent: Saturday, February 28, 2015 7:32 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] SEC PPI HOBs


On Feb 27, 2015, at 3:02 PM, Tim Lewis 
mailto:tim.le...@insyde.com>> wrote:

Section 8.3.1 of the PI Specification, volume 1, says (of the 
EFI_SEC_PLATFORM_INFORMATION_PPI)

This same information will be placed in a GUIDed HOB with the PPI GUID as the 
HOB GUID.
This allows agents, such as the DXE multiprocessor (MP) driver, to get health 
information for the
boot-strap processor (BSP).

But it isn’t clear who does this. The SEC code? Certainly the PEI Core doesn’t 
do it From PeiMain.c (~375) And no sample I’ve looked at tries to do the GUIDed 
HOB thing.

Thoughts?


The edk2 PEI Core does not conform to the specification?

I’m guessing some private GUID’ed HOBs existed prior to this PI defined one. 
The CPU PEIM pass up data to the CPU DXE driver.

Thanks,

Andrew Fish

Tim
//
// If SEC provided any PPI services to PEI, install them.
//
if (PpiList != NULL) {
  Status = PeiServicesInstallPpi (PpiList);
  ASSERT_EFI_ERROR (Status);
}



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now

[edk2] SEC PPI HOBs

[Tim Lewis]

Section 8.3.1 of the PI Specification, volume 1, says (of the 
EFI_SEC_PLATFORM_INFORMATION_PPI)

This same information will be placed in a GUIDed HOB with the PPI GUID as the 
HOB GUID.
This allows agents, such as the DXE multiprocessor (MP) driver, to get health 
information for the
boot-strap processor (BSP).

But it isn't clear who does this. The SEC code? Certainly the PEI Core doesn't 
do it From PeiMain.c (~375) And no sample I've looked at tries to do the GUIDed 
HOB thing.

Thoughts?

Tim
//
// If SEC provided any PPI services to PEI, install them.
//
if (PpiList != NULL) {
  Status = PeiServicesInstallPpi (PpiList);
  ASSERT_EFI_ERROR (Status);
}



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Remove IntelFramweorkModulePkg as Shell library dependency

[Tim Lewis]

Reviewed-by: Tim Lewis tim.le...@insyde.com<mailto:tim.le...@insyde.com>


From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Thursday, December 11, 2014 8:43 AM
To: Tim Lewis; El-Haj-Mahmoud, Samer (samer.el-haj-mahm...@hp.com)
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: [PATCH] Remove IntelFramweorkModulePkg as Shell library dependency

Tim and Samer,

Can you review this please?


[PATCH] Remove IntelFramweorkModulePkg as Shell library dependency

Replace Protocol GUIDs from that package with local copies.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: jaben carsey 
mailto:jaben.car...@intel.com>>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Remove IntelFramweorkModulePkg as Shell library dependency

[Tim Lewis]

Jaben -

Looks good to me.

Tim

From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Thursday, December 11, 2014 8:43 AM
To: Tim Lewis; El-Haj-Mahmoud, Samer (samer.el-haj-mahm...@hp.com)
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: [PATCH] Remove IntelFramweorkModulePkg as Shell library dependency

Tim and Samer,

Can you review this please?


[PATCH] Remove IntelFramweorkModulePkg as Shell library dependency

Replace Protocol GUIDs from that package with local copies.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: jaben carsey 
mailto:jaben.car...@intel.com>>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

[Tim Lewis]

Jaben -

Consider an ARM source delivery. Do we really a package full of Intel-isms 
delivered? They never use those protocols and likely never will.

We can rebuild the shell entirely by itself, like a UEFI app, and it currently 
depends only on MdePkg and MdeModulePkg.

My first choice would be just to leave them out. My next choice would be to 
duplicate any extraneous values in the ShellPkg.dec

Tim

From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Tuesday, November 25, 2014 4:18 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

I think that knowing the name of a produced protocol is pretty useful.  The 
only alternative I thought about is putting copies of the GUIDs in the shell.  
What would you propose?

-Jaben

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, November 25, 2014 4:14 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

Jaben, Samer -

Do we really want to make the shell dependent on the IntelFrameworkModulePkg?

Tim

From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Tuesday, November 25, 2014 2:42 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

Reviewed-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>

Commit 16445

p.s.  I had to rework the commit message a little to get it past the "guard" or 
whatever controls commit messages.


From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, November 25, 2014 2:08 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

Jaben,

Can you please review this and submit it?


Update Shell DH command to display gEfiAdapterInformationProtocolGuid and decode

information blocks defined in the UEFI 2.4 specification.

Also added GUIDs for gEfiIsaIoProtocolGuid and gEfiIsaAcpiProtocolGuid 
protocols.


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


Thanks,

Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com<mailto:el...@hp.com>
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi<http://hp.com/go/proliant/uefi>

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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

[Tim Lewis]

Jaben, Samer -

Do we really want to make the shell dependent on the IntelFrameworkModulePkg?

Tim

From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Tuesday, November 25, 2014 2:42 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

Reviewed-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>

Commit 16445

p.s.  I had to rework the commit message a little to get it past the "guard" or 
whatever controls commit messages.


From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, November 25, 2014 2:08 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol

Jaben,

Can you please review this and submit it?


Update Shell DH command to display gEfiAdapterInformationProtocolGuid and decode

information blocks defined in the UEFI 2.4 specification.

Also added GUIDs for gEfiIsaIoProtocolGuid and gEfiIsaAcpiProtocolGuid 
protocols.


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


Thanks,

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]

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] FindImageBase and FVs with 0xff padding.

[Tim Lewis]

There are several instances of a function like FindImageBase() 
(IntelFspWrapperPkg, OvmfPkg/Sec). These functions all share common flaws:


1)  If the FV does not begin with a file, then the code does not correctly 
skip the empty space at the beginning of the FV that is filled with 0xFF. This 
happens when the gap at the beginning of the FV is less than 24 bytes. This 
happens because a FILETYPE_PAD file requires at least 24 bytes for the header 
and header alignment only needs to be 8 bytes. Per the PI specification, it is 
filled with the ERASE_POLARITY value (0x00 or 0xff)

2)  If the FV does not end with a file, a similar result happens because 
the empty space is assumed to be a file header and the new "size" of the file 
is either 0x or 0x, both of which lead to problems.

3)  If the FV is less than 24 bytes in length the code will fail. This is a 
rare case, but it is possible to have valid FVs like this, per the spec.

Consider this piece from IntelFspWrapperPkg

for (EndOfFile = CurrentAddress + BootFirmwareVolumePtr->HeaderLength; ; ) {

CurrentAddress = (EndOfFile + 7) & 0xfff8ULL;
if (CurrentAddress > EndOfFirmwareVolume) {
  return EFI_NOT_FOUND;
}

   /* CONSIDER THE CASE WHERE THERE IS EMPTY SPACE AT THE BEGINNING OF THE FV */
File = (EFI_FFS_FILE_HEADER*)(UINTN) CurrentAddress;
if (IS_FFS_FILE2 (File)) {
  Size = FFS_FILE2_SIZE (File);
  if (Size <= 0x00FF) {
return EFI_NOT_FOUND;
  }
} else {
  Size = FFS_FILE_SIZE (File);
  if (Size < sizeof (EFI_FFS_FILE_HEADER)) {
return EFI_NOT_FOUND;
  }
}

EndOfFile = CurrentAddress + Size;
  /* AT THIS POINT, WE MIGHT BE POINTING TO EndOfFirmwareVolume - 16, pointing 
to 0x */

if (EndOfFile > EndOfFirmwareVolume) {
  return EFI_NOT_FOUND;
}

//
// Look for SEC Core / PEI Core files
//
if (File->Type != EFI_FV_FILETYPE_SECURITY_CORE &&
File->Type != EFI_FV_FILETYPE_PEI_CORE) {
  continue;
}
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Enable optimization for gcc x64 builds

[Tim Lewis]

Another note (from the archives): vendors used mixed builds for VS2003/VS2005 
on 32-bit in order to use __fastcall for internal function calls and then 
EFIABI for all the various UEFI calls. 

Tim

-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Tuesday, November 04, 2014 2:33 PM
To: Andrew J. Fish
Cc: Paolo Bonzini; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Enable optimization for gcc x64 builds

On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish  wrote:
> So my 1st question is why do you need to mix calling conventions, and 
> depend on EFIAPI for interoperability. Why not just change the ABI on 
> all functions?

GCC 4.4 doesn't support the command line option to change everything over. So, 
EFIAPI was the only option then.

> Problems with the mixed calling convention:
> 1) All assembly routines must be marked as EFIAPI, or the C code will 
> generate the wrong calling convention. Not an issue in the MdePkg, but 
> potentially an issue in other packages.

I don't see this as a problem. I think this is the rules that we have set up 
for EDK II. It just so happens that the GCC4X toolchains are the only ones that 
use EFIAPI, and thus are the only ones that allow us to keep our codebase clean 
with regards to EFIAPI.

For GCC >= 4.5, I actually think we should convert *RELEASE* builds over to 
using the ms-abi all the time to generate smaller code. I think we should leave 
DEBUG builds as mixed to help clean up EFIAPI issues.

-Jordan

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

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

[edk2] PCD Database Forcing

[Tim Lewis]

How can I force a PCD that is not referenced in any INF to be the PCD database?

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

Re: [edk2] Enable optimization for gcc x64 builds

[Tim Lewis]

Scott --

For historical perspective, the EDK2 build flags have focused on space over 
speed because of the code size constraints placed on flash-resident code. Not 
being as familiar with gcc as I am with VS20xx, I don't know whether these can 
be set together.

Tim

-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org] 
Sent: Tuesday, October 28, 2014 9:59 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Enable optimization for gcc x64 builds

Optimization is not enabled for x64 builds using gcc 4.4-4.9. For IA32 builds, 
-Os (optimize for small code size) is used. Why is this? Apparently it is 
because variable argument list handling fails when gcc X64 optimization is 
enabled. The solution is an improvement to the patch of SVN rev 10440:
http://sourceforge.net/p/edk2/mailman/message/2512/

The patch in this email only adds gcc X64 optimization for gcc versions 4.8 and 
newer. This is because testing with older versions of gcc is a lot of work. On 
the other hand, the patch could be a lot simpler if it were to ignore gcc 
version. The patch is boot tested using Duet with gcc 4.8.2 and gcc 4.9.1. For 
these two cases, the print formatting problem is resolved by the patch.

Should we:
1) Restrict the change to recent gcc versions where testing is easy
   (approach of included patch)
2) Apply the change to all gcc versions, and let older versions go
   untested?
3) Try to find/build the needed older gcc versions so that the patch
   can apply to all versions and be tested too

Thanks,
Scott

-- 

Enable optimization for gcc x64 builds.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan 

--

Index: BaseTools/Conf/tools_def.template 
===
--- BaseTools/Conf/tools_def.template   (revision 16254)
+++ BaseTools/Conf/tools_def.template   (working copy)
@@ -3843,7 +3843,7 @@
 
 DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include 
AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
-malign-double -fno-stack-protector -D EFI32
-DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS 
-mno-red-zone -Wno-address -mcmodel=large
+DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone 
-Wno-address -mcmodel=large
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections 
--script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry ReferenceAcpiTable -u ReferenceAcpiTable
 DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
@@ -4420,7 +4420,7 @@
 *_GCC48_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC48_X64_ASLDLINK_FLAGS   = DEF(GCC48_IA32_X64_ASLDLINK_FLAGS) -m 
elf_x86_64
 *_GCC48_X64_ASM_FLAGS= DEF(GCC48_ASM_FLAGS) -m64
-*_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS)
+*_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -Os
 *_GCC48_X64_DLINK_FLAGS  = DEF(GCC48_X64_DLINK_FLAGS)
 *_GCC48_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
 *_GCC48_X64_OBJCOPY_FLAGS= 
@@ -4542,7 +4542,7 @@
 *_GCC49_X64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS) -m64
 *_GCC49_X64_ASLDLINK_FLAGS   = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS) -m 
elf_x86_64
 *_GCC49_X64_ASM_FLAGS= DEF(GCC49_ASM_FLAGS) -m64
-*_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
+*_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -Os
 *_GCC49_X64_DLINK_FLAGS  = DEF(GCC49_X64_DLINK_FLAGS)
 *_GCC49_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
 *_GCC49_X64_OBJCOPY_FLAGS= 
Index: EdkCompatibilityPkg/Foundation/Include/EfiStdArg.h
===
--- EdkCompatibilityPkg/Foundation/Include/EfiStdArg.h  (revision 16254)
+++ EdkCompatibilityPkg/Foundation/Include/EfiStdArg.h  (working copy)
@@ -66,6 +66,7 @@
   @return The aligned size.
 **/
 #define _INT_SIZE_OF(n) ((sizeof (n) + sizeof (UINTN) - 1) &~(sizeof (UINTN) - 
1))
+#define GCC_VERSION (__GNUC__ * 10 + __GNUC_MINOR__)
 
 #if defined(__CC_ARM)
 //
@@ -92,25 +93,37 @@
 
 #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
 
-#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
+#elif defined(__GNUC__) && !defined(__x86_64__)
 //
 // Use GCC built-in macros for variable argument lists.
 //
 
 ///
-/// Variable used to traverse the list of arguments. This type can vary by 
-/// implementation and could be an array or structure. 
+/// Variable used to traverse the list of argum

Re: [edk2] Get BlockIo protocol from Ata Device based on Port and Multiplier Port

[Tim Lewis]

Rafael –

Create a device path using the port/multiplier port information (see 
BuildDevicePath), then use LocateDevicePath.

From: Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
Sent: Wednesday, October 29, 2014 3:32 AM
To: edk2-devel
Subject: Re: [edk2] Get BlockIo protocol from Ata Device based on Port and 
Multiplier Port

Hi Feng

Thanks for the answer.
Just to explain better my scenario.

What I need to do is execute some ata commands, like read verify sector, this 
is done sending ata commands to some Port / Multiplier port, but in case this 
device has a Block Io protocol, I need to use this protocol instead of sending 
a specific ata command (so my application will be more generic)

This is why I need to know if a specific ata device has an associated block io 
protocol, based on its position (Port/Multiplier port location)

If my explanation is not that clear I can try to explain in another way.

Thanks a lot for the answer.
Rafael R. Machado


2014-10-28 22:55 GMT-02:00 Tian, Feng 
mailto:feng.t...@intel.com>>:
Rafael,

Why don’t you directly locate all handles at which BlockIo protocols are 
installed? After you get these handles, you can get device path from these 
handles to know which one is you want to access.

Thanks
Feng

From: Rafael Machado 
[mailto:rafaelrodrigues.mach...@gmail.com]
Sent: Monday, October 27, 2014 18:40
To: edk2-devel
Subject: [edk2] Get BlockIo protocol from Ata Device based on Port and 
Multiplier Port

Hi everyone.

I have a system, that has a Storage device.
This device can be detected at Port 0, Multiplier 0 by the 
EFI_ATA_PASS_THRU_PROTOCOL.GetNextDevice()

typedef EFI_STATUS
(EFIAPI *EFI_ATA_PASS_THRU_GET_NEXT_DEVICE) (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN OUT UINT16 *PortMultiplierPort
);

Now I need to know the EFI_BLOCK_IO_PROTOCOL "instance" that I need to use to 
access this device.
Is there a way to do this ?

Thanks and Regards
Rafael R. Machado

--

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

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

Re: [edk2] DynamicEx and FeatureFlag

[Tim Lewis]

Liming -

I don't understand. DynamicEx supports BOOLEAN also. Why is it incompatible? It 
seems like a backward-compatible extension to the existing design. And, as 
mentioned, the restriction that is not useful.

Having two PCDs that have the exact same meaning just adds a DynamicEx PCD 
that, most of the time, will never be used, but will still be in the PCD 
database. 90% of the time, this PCD would be FeatureFlag. That means that 90% 
of the time I would have an unused DynamicEx PCD in the PCD database.

Tim

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, October 08, 2014 2:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DynamicEx and FeatureFlag

Tim:
  In current design, PcdsFeatureFlag is BOOLEAN FixedAtBuild PCD. It can't be 
extended to other PCD type. To use it as PcdDynamicEx, its type has to be 
changed. But, this change is incompatible. To avoid its impact, could you 
introduce new PCD for PcdDynamicEx usage?

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, October 01, 2014 2:23 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] DynamicEx and FeatureFlag

Currently the flag PcdDxeIplSwitchToLongMode is declared as storage type 
PcdFeatureFlag.

But we tried to change it to DynamicEx. Ok, that works great. We changed the 
.dec file to say [PcdDynamicEx]. No problem.

But then we tried to make it selectable by .dsc by making it [PcdFeatureFlag, 
PcdDynamicEx] in the .dec file.

Then we get this error:

"PcdsFeatureFlag must not be in the same section of other types of PCD"
While I understand that there are cases where feature-flag PCDs must be 
resolved during the build process, this is not always the case and I would 
rather I get the error when I try to use the non-feature-flag PCD in the wrong 
place. Do I really have to change this to PcdFixedAtBuild?

Tim
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] DynamicEx and FeatureFlag

[Tim Lewis]

Currently the flag PcdDxeIplSwitchToLongMode is declared as storage type 
PcdFeatureFlag.

But we tried to change it to DynamicEx. Ok, that works great. We changed the 
.dec file to say [PcdDynamicEx]. No problem.

But then we tried to make it selectable by .dsc by making it [PcdFeatureFlag, 
PcdDynamicEx] in the .dec file.

Then we get this error:

"PcdsFeatureFlag must not be in the same section of other types of PCD"


While I understand that there are cases where feature-flag PCDs must be 
resolved during the build process, this is not always the case and I would 
rather I get the error when I try to use the non-feature-flag PCD in the wrong 
place. Do I really have to change this to PcdFixedAtBuild?

Tim
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Or, you could have two pick lists: one near the title of the Orderded List



Boot Order v
  Container 1 v
  Container 2 v
  Container 3 v

That is, "Boot Order" is also a pick list, showing the options that are buffers.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 24, 2014 12:31 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

I think this sample code is always return UINT8 type, the difference between 
your proposal and my proposal is the "," or " ", just like below
Your proposal:
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
My proposal:
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;

I think our proposal both has the same problem which is raised by you.


Also I think if enable option opcode for buffer type, we can't describe it when 
it used in the ordered list op-code. Sample code shows below. do you think so?
If  we support buffer type for option, take below code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
  endlist;
the result shows like below, how can user to change the order for this case?
 [cid:image004.png@01CFD72D.0304CC60]

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 24, 2014 3:51 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

The new grammar is ambiguous because it is impossible to tell whether the 
following statement is a UINT8 or a Buffer of size 1.

option text = STRING_TOKEN(0x006F), value = 2, flags = 0;

Since, in my proposal, the behavior of these two value types have different 
behaviors for ORDERED_LIST, it is important to distinguish between them.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Thursday, September 04, 2014 8:02 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

For option, current it only has one value and one prompt string " EFI_STRING_ID 
Option; ". For below example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
  endlist;
the result shows like below, and user can change the option order.
[cid:image002.png@01CFD7D4.ED8D1B00]

If  we support buffer type for option, take below code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
  endlist;
the result shows like below, how can user to change the order for this case?
 [cid:image001.png@01CFD7D4.ED8D1B00]


For the buffer grammar in VFR, because we already has an opcode "ideqvallist" 
which has the similar format, so I follow this style to define the buffer 
grammar.
  numeric varid   = MyIfrNVData.HowOldAreYouInYearsManual,
prompt  = STRING_TOKEN(STR_NUMERIC_MANUAL_PROMPT),
help= STRING_TOKEN(STR_NUMERIC_HELP0),
minimum = 0,
maximum = 0xf0,
step= 0,
default value = questionrefval(devicepath = STRING_TOKEN 
(STR_DEVICE_PATH), guid = DRIVER_SAMPLE_FORMSET_GUID, 0x),

inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
  ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
  OR
  ideqid  MyIfrNVData.HowOldAreYouInYearsManual == MyEfiVar.Field8
  OR
  ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
endif
endnumeric;


  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
  endlist;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, September 05, 2014 8:09 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is the basic idea:

typedef struct _EFI_IFR_ONE_OF_OPTION {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID Option;
  UINT8 Flags;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EF

Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Eric -

Here was my original proposal (see the bottom of the thread)

BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}"  and 
byte-list :=  | integer

So the example would be:

option text = STRING_TOKEN(0x006F), value = {2, 1, 3}, flags = 
0;

For a buffer case, I'm not sure how the UI would display it. One way is to 
create something like this:

Xxx // UINT8 option
Yyy // UINT8 option
---
USB First // Buffer option

That is, they would all appear in the list, with a separator to show the buffer 
options.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 24, 2014 12:31 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

I think this sample code is always return UINT8 type, the difference between 
your proposal and my proposal is the "," or " ", just like below
Your proposal:
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
My proposal:
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;

I think our proposal both has the same problem which is raised by you.


Also I think if enable option opcode for buffer type, we can't describe it when 
it used in the ordered list op-code. Sample code shows below. do you think so?
If  we support buffer type for option, take below code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
  endlist;
the result shows like below, how can user to change the order for this case?
 [cid:image004.png@01CFD72D.0304CC60]

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 24, 2014 3:51 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

The new grammar is ambiguous because it is impossible to tell whether the 
following statement is a UINT8 or a Buffer of size 1.

option text = STRING_TOKEN(0x006F), value = 2, flags = 0;

Since, in my proposal, the behavior of these two value types have different 
behaviors for ORDERED_LIST, it is important to distinguish between them.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Thursday, September 04, 2014 8:02 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

For option, current it only has one value and one prompt string " EFI_STRING_ID 
Option; ". For below example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
  endlist;
the result shows like below, and user can change the option order.
[cid:image002.png@01CFD7D4.96067D40]

If  we support buffer type for option, take below code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
  endlist;
the result shows like below, how can user to change the order for this case?
 [cid:image001.png@01CFD7D4.96067D40]


For the buffer grammar in VFR, because we already has an opcode "ideqvallist" 
which has the similar format, so I follow this style to define the buffer 
grammar.
  numeric varid   = MyIfrNVData.HowOldAreYouInYearsManual,
prompt  = STRING_TOKEN(STR_NUMERIC_MANUAL_PROMPT),
help= STRING_TOKEN(STR_NUMERIC_HELP0),
minimum = 0,
maximum = 0xf0,
step= 0,
default value = questionrefval(devicepath = STRING_TOKEN 
(STR_DEVICE_PATH), guid = DRIVER_SAMPLE_FORMSET_GUID, 0x),

inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
  ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
  OR
  ideqid  MyIfrNVData.HowOldAreYouInYearsManual == MyEfiVar.Field8
  OR
  ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
endif
endnumeric;


  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
  endlist;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, September 05, 2014 8:09 AM
To: edk

Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Eric -

The new grammar is ambiguous because it is impossible to tell whether the 
following statement is a UINT8 or a Buffer of size 1.

option text = STRING_TOKEN(0x006F), value = 2, flags = 0;

Since, in my proposal, the behavior of these two value types have different 
behaviors for ORDERED_LIST, it is important to distinguish between them.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Thursday, September 04, 2014 8:02 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

For option, current it only has one value and one prompt string " EFI_STRING_ID 
Option; ". For below example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
  endlist;
the result shows like below, and user can change the option order.
[cid:image003.png@01CFD72D.0304CC60]

If  we support buffer type for option, take below code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
  endlist;
the result shows like below, how can user to change the order for this case?
 [cid:image004.png@01CFD72D.0304CC60]


For the buffer grammar in VFR, because we already has an opcode "ideqvallist" 
which has the similar format, so I follow this style to define the buffer 
grammar.
  numeric varid   = MyIfrNVData.HowOldAreYouInYearsManual,
prompt  = STRING_TOKEN(STR_NUMERIC_MANUAL_PROMPT),
help= STRING_TOKEN(STR_NUMERIC_HELP0),
minimum = 0,
maximum = 0xf0,
step= 0,
default value = questionrefval(devicepath = STRING_TOKEN 
(STR_DEVICE_PATH), guid = DRIVER_SAMPLE_FORMSET_GUID, 0x),

inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
  ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
  OR
  ideqid  MyIfrNVData.HowOldAreYouInYearsManual == MyEfiVar.Field8
  OR
  ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
endif
endnumeric;


  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
  endlist;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, September 05, 2014 8:09 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is the basic idea:

typedef struct _EFI_IFR_ONE_OF_OPTION {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID Option;
  UINT8 Flags;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_ONE_OF_OPTION;

typedef struct _EFI_IFR_DEFAULT {
  EFI_IFR_OP_HEADER Header;
  UINT16 DefaultId;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_DEFAULT;

For EFI_IFR_ORDERED_LIST only, the nested EFI_IFR_ONE_OF_OPTION can be either 
EFI_IFR_TYPE_NUM_SIZE_8 or EFI_IFR_TYPE_BUFFER. If it is 
EFI_IFR_TYPE_NUM_SIZE_8, then the option value is only for a single container. 
But if it is EFI_IFR_TYPE_BUFFER, then it is for all containers. If 
EFI_IFR_TYPE_BUFFER and the number of bytes is smaller than the number of 
containers, then remaining containers are set to 0 (empty)

Same with EFI_IFR_DEFAULT.

BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}"  and 
byte-list :=  | integer

Tim



From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 03, 2014 6:31 PM
To: edk2-devel@lists.sourceforge.net<mailto: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: Thursday, September 04, 2014 12:04 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is what I am thinking: we can extend the UEFI specification (which I will 
do in a separate ECR), to allow either the UINT8 or the BUFFER value for 
"option" and "default" If UINT8, then it will work on a single container. If 
BUFFER then it works on all containers. It may take me a week (after IDF) to 
get the ECR written for UEFI.
[[[E

Re: [edk2] ShellExecute crashing in NT emulator

[Tim Lewis]

It appears you are using the EDK Shell (not the UEFI shell) since you are using 
ShellEnvironment2. Is that your intention?

In the UEFI shell, this would be ShellPkg/Include/Protocol/EfiShell.h and the 
corresponding function is:

typedef
EFI_STATUS
(EFIAPI *EFI_SHELL_EXECUTE) (
  IN EFI_HANDLE *ParentImageHandle,
  IN CHAR16 *CommandLine OPTIONAL,
  IN CHAR16 **Environment OPTIONAL,
  OUT EFI_STATUS*StatusCode OPTIONAL
  );

Tim

From: J. E. [mailto:nszero...@hotmail.com]
Sent: Thursday, September 18, 2014 10:22 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] ShellExecute crashing in NT emulator

Yep thats the first thing I did, search all of UDK for SHELLENV_GET_ENV using 
Agent Ransack which searches binary and unicode as well.
I found nothing except for the EfiShellEnvironment2.h and UefiShellLib.lib 
files.
No idea where SHELLENV_GET_ENV is defined, it doesnt make sense.

If I boot and run the app in the proper EFI Shell, ShellExecute doesn't hang, 
but execution fails. Status is always EFI_SUCCESS
The echo commands in the NSH file do not output text onscreen, and the efi file 
in the NSH doesn't launch.

Status = ShellExecute(ImageHandle, L"fs1:", TRUE, NULL, NULL);
Status = ShellExecute(ImageHandle, L"cd fs1:\\TEST", TRUE, NULL, NULL);
Status = ShellExecute(ImageHandle, L"run.nsh", TRUE, NULL, NULL);

The above commands work fine if I type them in manually in the EFI shell.
ShellExecute just seems broken, I can find the code so I cant debug it. 
Everything compiles ok.
Maybe I should download the latest source instead of using the UDK2014 release, 
or change the compiler to GCC or Intel.

From: af...@apple.com
Date: Thu, 18 Sep 2014 18:48:25 -0700
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] ShellExecute crashing in NT emulator


Sent from my iPhone

On Sep 18, 2014, at 6:01 PM, J. E. 
mailto:nszero...@hotmail.com>> wrote:
It is crashing in SHELLENV_EXECUTE but I cant seem to find the c source for 
this function in
UDK\ShellPkg\Include\Protocol\EfiShellEnvironment2.h

typedef
EFI_STATUS
(EFIAPI *SHELLENV_EXECUTE) (
  IN EFI_HANDLE   *ParentImageHandle,
  IN CHAR16   *CommandLine,
  IN BOOLEAN  DebugOutput
  );

Which c file has the actual source code?

For protocols look at the global, EFI_GUID. Grep for that global. The producer 
will pass it as an argument to install protocol boot service.

Thanks,

Andrew Fish




From: af...@apple.com
Date: Thu, 18 Sep 2014 16:38:51 -0700
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] ShellExecute crashing in NT emulator

On Sep 18, 2014, at 4:24 PM, J. E. 
mailto:nszero...@hotmail.com>> wrote:

I am compiling and running secmain from the command line with no debugger, 
compiler is VS2005.
Perhaps there is a way to dump the exception to file?

Not sure as I don't use VC++.

It happens in Windows 7 64 as well.

I'll see if I can debug the ShellExecute function directly to find out which 
line is crashing out

Look at: http://tianocore.sourceforge.net/wiki/NT32

Thanks,

Andrew Fish


From: af...@apple.com
Date: Thu, 18 Sep 2014 10:25:30 -0700
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] ShellExecute crashing in NT emulator

On Sep 18, 2014, at 6:22 AM, J. E. 
mailto:nszero...@hotmail.com>> wrote:

The below code is crashing the emulator, any ideas?

Do you get a stack trace and error messages from the crash?

Thanks,

Andrew Fish

Is it a Windows 8 thing? (can't test a Win7 system or via proper EFI shell 
right now)


EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLEImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
EFI_STATUS Status;
Status = ShellExecute(ImageHandle, L"startup.nsh", FALSE, NULL, NULL);   // 
Crash dxecore.dll
Status = ShellExecute(ImageHandle, NULL, FALSE, NULL, NULL); // Crash 
dxecore.dll

}


UDK2014
Win8.1 64bit
UEFI Mode



--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___
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://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___ edk2-devel mailing list 

Re: [edk2] UEFI and ACPI

[Tim Lewis]

The _STA ASL method can often be used to check for run-time conditions. Can't 
remember off-hand how that works for processor objects. There are typically 
three ways this is handled:

1) The _STA method can read some register directly that determines this.
2) The firmware creates a memory Operation Region which is essentially a buffer 
full of configuration settings and the _STA references that.
3) The firmware patches the AML during boot with the actual number of cores, or 
the return status values.

Tim

-Original Message-
From: Brian J. Johnson [mailto:bjohn...@sgi.com] 
Sent: Friday, September 19, 2014 7:08 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] UEFI and ACPI

BIOSes often have boot-time code which tweaks the static ACPI tables generated 
by iasl to reflect the current hardware.  For instance, it may mark missing 
CPUs as "disabled."  It's also possible (although a lot of
work) to generate the binary ACPI data (AML) on the fly.  I'm not aware of any 
standardized UEFI functions to do this, however.  It's a very platform-specific 
thing.

Brian

On 09/19/2014 12:56 AM, Neeraj Ladkani wrote:
> You mean changing tables during subsequent boot or runtime?  IMHO, 
> During reboot, boot fw can choose which table to populate .
>
> Neeraj
>
> On Sep 19, 2014 11:10 AM, "Narinder Dhillon"  > wrote:
>
> Hi All,
>
> In order to add ACPI tables to UEFI, iasl compiler has to be
> downloaded from acpica.org .
> UEFI build compiles the tables, which makes the configuration static.
> Is there any way to change this configuration from UEFI prompt or by
> calling UEFI functions ?
> For example, I have a 8 core ARMv8 ACPI table but I want to boot
> only 4 cores. Is it possible to change this on the fly without
> editing and recompiling the ACPI tables ?
>
> Thanx.
>
> 
> --
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
> clktrk
>
>
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>


-- 

"It's OK to be stuck.  99% of the time in your own [research] work,
 you're stuck."
-- Mark Lawrence

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
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://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Is there a way ...

[Tim Lewis]

Deric -

Sounds like a good idea. You should propose this to your USWG representative to 
change the specification.

Tim

From: Deric Cole [mailto:deric_c...@phoenix.com]
Sent: Friday, September 12, 2014 9:57 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Is there a way ...

Why not update the shell to automatically create this ARCH variable?

Deric Cole
Sr. Customer Engineer
Phoenix Technologies Ltd.

From: allen_w...@dell.com<mailto:allen_w...@dell.com> 
[mailto:allen_w...@dell.com]
Sent: Friday, September 12, 2014 9:14 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] Is there a way ...

Another option would be to write a small EFI driver, built for one bit-ness, 
load it, and check %lasterror%.  If you are only interested in Ia32 vs X64, you 
could follow this example:

 load MyTest32BitDriver.efi
 if %lasterror% == 0 then
  
 else
  if %lasterror% == 7 then
   
  else
   
  endif
 endif

This assumes, of course, that the shell will return 7 (SHELL_DEVICE_ERROR) when 
it is unable a driver because of incorrect bit-ness.  And using one driver like 
this isn't extensible to other architectures.  If that is a concern, then you 
could build test drivers for IA32, X64, IPF, EBC, etc., attempt to load all of 
them until on returns success, and us that as an indication of the system 
architecture.

Allen Wynn


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, September 11, 2014 11:42 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] Is there a way ...

Lowell -

You might use the redirect-to-environment variable that the UEFI shell supports.

I believe you can do:

ver -terse -_pa >v ARCH

Is that what you want?

By the way, I would point out that since _pa is not architectural per the spec, 
it may not be supported on all shell implementations.

Tim

From: lowell_den...@dell.com<mailto:lowell_den...@dell.com> 
[mailto:lowell_den...@dell.com]
Sent: Thursday, September 11, 2014 8:33 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] Is there a way ...


Dell - Internal Use - Confidential
Ok,

So in case anyone is interested, I found a way to extract this using nsh 
scripts.  It is kind of goofy but ...

startup.nsh:
ver -terse -_pa > ver.nsh
ver.nsh

UEFI.nsh:
@echo -off
exit /b 0

64.nsh:
@echo -off
set -v ARCH X64
exit /b 0

32.nsh:
@echo -off
set -v ARCH IA32
exit /b 0

The first line of startup.nsh generates ver.nsh.
The second line of startup.nsh then executes ver.nsh.

On a 64-bit system ver.nsh will contain

UEFI Interactive Shell V2.0
64

On a 32-bit system ver.nsh will contain

UEFI Interactive Shell V2.0
32

When ver.nsh is executed, it first runs UEFI.nsh (which does nothing).
It then runs either 64.nsh or 32.nsh which will sets ARCH appropriately.



From: Dennis, Lowell
Sent: Wednesday, September 10, 2014 11:07 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] Is there a way ...


Dell - Internal Use - Confidential
Tested it on a 32-bit system and it worked (after updating my USB key with a 
shell 2.0 version of BOOTIA32.efi that is).

Ok, now the question is how to take the output of the ver command and use it in 
an nsh file to read the 64 or 32.

Any ideas? ... I find the shell command very limiting in this respect.



From: Dennis, Lowell
Sent: Wednesday, September 10, 2014 9:07 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] Is there a way ...

Thanks Allen,

FS0:\> ver -s -_pa
2.0
64

Seems to work.  I do not have any IA32 H/W at the moment.  Could someone who 
does have IA32 H/W please try it out and verify that it indicates 32-bit.


-  Lowell

-Original Message-
From: Wynn, Allen
Sent: Wednesday, September 10, 2014 8:47 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] Is there a way ...

Have you tried following?
ver -_pa

See ShellPkg\Library\UefiShellLevel3CommandsLib\Ver.c (snippet below)
//
// implementation specific support for displaying processor architecture
//
if (ShellCommandLineGetFlag(Package, L"-_pa")) {
ShellPrintEx(-1, -1, L"%d\r\n", sizeof(UINTN)==sizeof(UINT64)?64:32);
}


Best Regards,
Allen

-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, September 9, 2014 3:53 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] Is there a way ...


On Sep 9, 2014, at 1:44 PM, Laszlo Ersek wrote:

> 

Re: [edk2] Is there a way ...

[Tim Lewis]

Lowell -

You might use the redirect-to-environment variable that the UEFI shell supports.

I believe you can do:

ver -terse -_pa >v ARCH

Is that what you want?

By the way, I would point out that since _pa is not architectural per the spec, 
it may not be supported on all shell implementations.

Tim

From: lowell_den...@dell.com [mailto:lowell_den...@dell.com]
Sent: Thursday, September 11, 2014 8:33 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Is there a way ...


Dell - Internal Use - Confidential
Ok,

So in case anyone is interested, I found a way to extract this using nsh 
scripts.  It is kind of goofy but ...

startup.nsh:
ver -terse -_pa > ver.nsh
ver.nsh

UEFI.nsh:
@echo -off
exit /b 0

64.nsh:
@echo -off
set -v ARCH X64
exit /b 0

32.nsh:
@echo -off
set -v ARCH IA32
exit /b 0

The first line of startup.nsh generates ver.nsh.
The second line of startup.nsh then executes ver.nsh.

On a 64-bit system ver.nsh will contain

UEFI Interactive Shell V2.0
64

On a 32-bit system ver.nsh will contain

UEFI Interactive Shell V2.0
32

When ver.nsh is executed, it first runs UEFI.nsh (which does nothing).
It then runs either 64.nsh or 32.nsh which will sets ARCH appropriately.



From: Dennis, Lowell
Sent: Wednesday, September 10, 2014 11:07 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Is there a way ...


Dell - Internal Use - Confidential
Tested it on a 32-bit system and it worked (after updating my USB key with a 
shell 2.0 version of BOOTIA32.efi that is).

Ok, now the question is how to take the output of the ver command and use it in 
an nsh file to read the 64 or 32.

Any ideas? ... I find the shell command very limiting in this respect.



From: Dennis, Lowell
Sent: Wednesday, September 10, 2014 9:07 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Is there a way ...

Thanks Allen,

FS0:\> ver -s -_pa
2.0
64

Seems to work.  I do not have any IA32 H/W at the moment.  Could someone who 
does have IA32 H/W please try it out and verify that it indicates 32-bit.


-  Lowell

-Original Message-
From: Wynn, Allen
Sent: Wednesday, September 10, 2014 8:47 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Is there a way ...

Have you tried following?
ver -_pa

See ShellPkg\Library\UefiShellLevel3CommandsLib\Ver.c (snippet below)
//
// implementation specific support for displaying processor architecture
//
if (ShellCommandLineGetFlag(Package, L"-_pa")) {
ShellPrintEx(-1, -1, L"%d\r\n", sizeof(UINTN)==sizeof(UINT64)?64:32);
}


Best Regards,
Allen

-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, September 9, 2014 3:53 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Is there a way ...


On Sep 9, 2014, at 1:44 PM, Laszlo Ersek wrote:

> On 09/09/14 21:52, lowell_den...@dell.com 
> wrote:
>> *Dell - Internal Use - Confidential *
>
> (not very confidential...)

But some lawyer is happy.

>

>> I would like to know if there is a way from the EFI shell to
>> determine if this is a 32-bit or 64-bit environment.
>>
>> For the most part, I am using BOOTX64.efi.
>>
>> However, it would be nice to be able to gracefully handle the
>> situation where BOOTIA32.efi was used.
>>
>> For example, let's say I have a home grown utility that has a 32-bit
>> and a 64-bit efi file. How do I determine which one to use from an nsh 
>> script?
>
> When in doubt, use brute force, I guess. Start the 64-bit variant, and
> if it fails, start the 32-bit one. LoadImage() won't let you load a
> binary with incorrect bitness (or another architecture mismatch). IIRC
> the return value in this case is EFI_UNSUPPORTED.
>

>From C code, you can use #ifdef to figure out your image type.

#ifdef MDE_CPU_X64
#ifdef MDE_CPU_IA32

The DXE Core uses the EFI_IMAGE_MACHINE_TYPE_SUPPORTED() macro. It tells you if 
the PE/COFF image type is supported.

The image types from the PE/COFF header are:
///
/// PE32+ Machine type for IA32 UEFI images.
///
#define EFI_IMAGE_MACHINE_IA32 0x014C

///
/// PE32+ Machine type for IA64 UEFI images.
///
#define EFI_IMAGE_MACHINE_IA64 0x0200

///
/// PE32+ Machine type for EBC UEFI images.
///
#define EFI_IMAGE_MACHINE_EBC 0x0EBC

///
/// PE32+ Machine type for X64 UEFI images.
///
#define EFI_IMAGE_MACHINE_X64 0x8664

///
/// PE32+ Machine type for ARM mixed ARM and Thumb/Thumb2 images.
///
#define EFI_IMAGE_MACHINE_ARMTHUMB_MIXED 0x01C2

///
/// PE32+ Machine type for AARCH64 A64 images.
///
#define EFI_IMAGE_MACHINE_AARCH64 0xAA64


Thanks,

Andrew Fish



> Granted, this might not allow you to tell apart genuine error exits of

Re: [edk2] VS2013 build failures: unresolved external symbol __dtoui3

[Tim Lewis]

Daryl --

I would note that for 64-bit x86 (2.3.4.2) it explicitly describes the usage of 
XMM registers. These are non-int usages but the preservation rules are listed.

The registers Rax, Rcx Rdx R8, R9, R10, R11, and XMM0-XMM5 are volatile and 
are, therefore, destroyed on function calls.
The registers RBX, RBP, RDI, RSI, R12, R13, R14, R15, and XMM6-XMM15 are 
considered nonvolatile and must be saved and restored by a function that uses 
them.
Function pointers are pointers to the label of the respective function and 
don't require special treatment.

And

For MMX, XMM and floating-point values, return values that can fit into 64-bits 
are returned through RAX (including MMX types). However, XMM 128-bit types, 
floats, and doubles are returned in XMM0. The floating point status register is 
not saved by the target function. Floating-point and double-precision arguments 
are passed in XMM0 - XMM3 (up to 4) with the integer slot (RCX, RDX, R8, and 
R9) that would normally be used for that cardinal slot being ignored (see 
example) and vice versa. XMM types are never passed by immediate value but 
rather a pointer will be passed to memory allocated by the caller. MMX types 
will be passed as if they were integers of the same size. Callees must not 
unmask exceptions without providing correct exception handlers.

For 32-bit (2.3.2.2) x86

In addition, unless otherwise specified by the function definition, all other 
registers (including MMX and XMM) are preserved.
The floating point status register is not preserved by the target function. The 
floating point control register and MMX control register are saved by the 
target function.
If the return value is a float or a double, the value is returned in ST(0).

-Original Message-
From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com] 
Sent: Friday, September 05, 2014 11:41 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] VS2013 build failures: unresolved external symbol __dtoui3

Scott,

Thank you for reporting this.  I have added it to the list of issues to be 
resolved for StdLib.

Regrettably, I haven't done any testing with VS2013.

While one is free to use the SSEx and MMX registers and instructions in their 
own code, it isn't a supported feature of EDK II.  A compilation unit using 
these extensions must confine all artifacts of such use within the compilation 
unit.  No assumptions may be made about external code's use, preservation, or 
destruction of these registers.  

Within a compilation unit, one is free to use any calling convention supported 
by the target compilers, as long as all public APIs use the EFIAPI calling 
convention, which does not address these registers.

Regarding your questions:
1) I don't know about combining modules compiled with /arch:SSE2 and /arch:SSE. 
 My assumption has been that both of these have been "turned off" since we 
didn't want the compiler generating these instructions.  It looks like I need 
to do some more research in this area.

2) The ftol2.obj binary is compatible with VS2003 through VS2012.  I don't yet 
know about VS2013.

Daryl McDaniel

"It is the mark of an educated mind to be able to entertain a thought without 
accepting it."
- Aristotle

-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org] 
Sent: Thursday, September 04, 2014 9:41 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] VS2013 build failures: unresolved external symbol __dtoui3

Building AppPkg for IA32 using VS2013 fails with unresolved external symbol 
__dtoui3.
__dtoui3 is a helper function called by the generated code. It is analogous to 
the
__ftol2 helper function call generated by older Microsoft compilers. VS2013 
calls
__dtoui3 instead of __ftol2. Apparently the new function converts double to 
integer with reduced use of the x87 fpu.

The call to __ftol2 generated by older Microsoft compilers is resolved by 
binary file StdLib\LibC\Main\Ia32\ftol2.obj, an object extracted from Microsoft 
libs. The same approach could be used for VS2013's __dtoui3 by extracting 
ftol3.obj and adding it to EDK2. But doing so causes unresolved external symbol 
__except1. This can be fixed by extracting fpexcept.obj from VS2013 libs and 
adding it to EDK2. But once that is done, 12 more unresolved externals are 
created.

Another approach is to use /arch:SSE when building LibGdtoa for IA32 with 
VS2013 (default is /arch:SSE2). This causes VS2013 to generate a call to 
__ftol2 instead of __dtoui3 and resolves the build failure. I suppose this is 
the route to take.
Concerns are:
1) Is it OK to combine modules compiled with /arch:SSE2 and /arch:SSE?
2) Is the current EDK2 ftol2.obj binary compatible with all supported Microsoft
   compilers, including VS2013?
I will do some testing and submit a patch if it looks OK.
Thanks,
Scott




--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/

Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Eric -

Here is the basic idea:

typedef struct _EFI_IFR_ONE_OF_OPTION {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID Option;
  UINT8 Flags;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_ONE_OF_OPTION;

typedef struct _EFI_IFR_DEFAULT {
  EFI_IFR_OP_HEADER Header;
  UINT16 DefaultId;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_DEFAULT;

For EFI_IFR_ORDERED_LIST only, the nested EFI_IFR_ONE_OF_OPTION can be either 
EFI_IFR_TYPE_NUM_SIZE_8 or EFI_IFR_TYPE_BUFFER. If it is 
EFI_IFR_TYPE_NUM_SIZE_8, then the option value is only for a single container. 
But if it is EFI_IFR_TYPE_BUFFER, then it is for all containers. If 
EFI_IFR_TYPE_BUFFER and the number of bytes is smaller than the number of 
containers, then remaining containers are set to 0 (empty)

Same with EFI_IFR_DEFAULT.

BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}"  and 
byte-list :=  | integer

Tim



From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 03, 2014 6:31 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: Thursday, September 04, 2014 12:04 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is what I am thinking: we can extend the UEFI specification (which I will 
do in a separate ECR), to allow either the UINT8 or the BUFFER value for 
"option" and "default" If UINT8, then it will work on a single container. If 
BUFFER then it works on all containers. It may take me a week (after IDF) to 
get the ECR written for UEFI.
[[[Eric]]] If in BUFFER type, we can create a sample like below. In this case, 
only one "text" for this option, how to show the different value for this 
orderedlist? Maybe we need to update the "text" field also? I agree it has 
value to support BUFFER type for default opcode, because in this case we can 
set default value for "orderedlist" opcode. But I don't know the value to 
support BUFFER for "option"? It will make the "option" more complicate to 
handle. Also the "option" can be used for "Oneof" opcode, we also need consider 
this opcode when we clarify the "option" opcode.
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
  endlist;

I think that if we document this behavior, it will be useful.

Are there any other question types where there are multiple value types 
possible? Obviously UINTx. How about CHECKBOX with integer? Or NUMERIC with 
BOOLEAN? Just thinking ahead.
[[[Eric]]] I think we don't have that question.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 10:45 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

After internal discussion, we agree default opcode can support ordered list 
opcode, I will follow up to enable it.

For your proposal, item 2 I think it's not an acceptable proposal, take below 
code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
  endlist;
normally, we can see option 2/option 1/option 3 for this ordered list. But base 
on your proposal, the default for this ordered list opcode is option 1/option 
1/option 1, do you think  this is an valid ordered list result? I think if 
DEFAULT flag is set, we can just skip this flag. We can use default opcode to 
set default for ordered list opcode.

For your proposal, I think you can submit an ECR for it.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 10:24 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Again, these are EDK2 decisions. They are not limitations of the specification. 
The UEFI specification does not indicate that the EFI_IFR_ONE_OF_OPTION default 
flag cannot work for ordered list. The UEFI specification does not say that 
there is any limitation to the default opcode. It does not say that 
EFI_IFR_TYPE_BUFFER cannot be used.   These are EDK2 and VFR limitations, not 
specification limit

Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Eric -

Here is what I am thinking: we can extend the UEFI specification (which I will 
do in a separate ECR), to allow either the UINT8 or the BUFFER value for 
"option" and "default" If UINT8, then it will work on a single container. If 
BUFFER then it works on all containers. It may take me a week (after IDF) to 
get the ECR written for UEFI.

I think that if we document this behavior, it will be useful.

Are there any other question types where there are multiple value types 
possible? Obviously UINTx. How about CHECKBOX with integer? Or NUMERIC with 
BOOLEAN? Just thinking ahead.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 10:45 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

After internal discussion, we agree default opcode can support ordered list 
opcode, I will follow up to enable it.

For your proposal, item 2 I think it's not an acceptable proposal, take below 
code for example:
  orderedlist
varid   = MyIfrNVData.BootOrder,
prompt  = STRING_TOKEN(0x006D),
help= STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
  endlist;
normally, we can see option 2/option 1/option 3 for this ordered list. But base 
on your proposal, the default for this ordered list opcode is option 1/option 
1/option 1, do you think  this is an valid ordered list result? I think if 
DEFAULT flag is set, we can just skip this flag. We can use default opcode to 
set default for ordered list opcode.

For your proposal, I think you can submit an ECR for it.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 10:24 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Again, these are EDK2 decisions. They are not limitations of the specification. 
The UEFI specification does not indicate that the EFI_IFR_ONE_OF_OPTION default 
flag cannot work for ordered list. The UEFI specification does not say that 
there is any limitation to the default opcode. It does not say that 
EFI_IFR_TYPE_BUFFER cannot be used.   These are EDK2 and VFR limitations, not 
specification limits.

So, that is why I made the proposal below: to try and clarify the behavior if 
these exist based on the UEFI specification language.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 7:10 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

For ordered list opcode, we not support set default flags in the option field. 
It is useful for oneof opcode not for ordered list opcode. Also I think your 
proposal of item 2) also not acceptable. We not support set default value 
through option for ordered list opcode.

The value for ordered list opcode is buffer type, but the default opcode not 
support save buffer type value(The EFI_IFR_TYPE_VALUE not support buffer type), 
so the default opcode can't be used by ordered list opcode.
[cid:image001.jpg@01CFC756.016ED7B0]

[cid:image002.jpg@01CFC756.016ED7B0]

Current for ordered list opcode, browser based on the current option order nest 
in this question to set the default value for it.
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

I believe that what you say is useful. But I don't think the specification 
describes that behavior.

The next question, which was asked by someone else on the EDK2 list, is what to 
do with "default" Both the flag for the "option" and the separate "default" 
opcode. The "just the value for the one container" does not seem like a good 
usage for default, since normally the engineer would like to saw the default 
values for all containers. But if "option" is for 1 container, then how does 
that work for default?

So here is a proposal for a clarification I would like to see in the UEFI 
specification:


1)  That, for ordered list, the "option values" should refer to a single 
container.

2)  When setting the default value using "option" then all containers will 
be filled with that value.

3)  When setting the default value using "default" then the "value" will be 
a Buffer type, with one byte of the Buffer per container. If the default value 
is smaller than the Buffer size, then the remaining containers will be filled 
with 0.

Tim


From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, Septem

Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Again, these are EDK2 decisions. They are not limitations of the specification. 
The UEFI specification does not indicate that the EFI_IFR_ONE_OF_OPTION default 
flag cannot work for ordered list. The UEFI specification does not say that 
there is any limitation to the default opcode. It does not say that 
EFI_IFR_TYPE_BUFFER cannot be used.   These are EDK2 and VFR limitations, not 
specification limits.

So, that is why I made the proposal below: to try and clarify the behavior if 
these exist based on the UEFI specification language.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 7:10 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

For ordered list opcode, we not support set default flags in the option field. 
It is useful for oneof opcode not for ordered list opcode. Also I think your 
proposal of item 2) also not acceptable. We not support set default value 
through option for ordered list opcode.

The value for ordered list opcode is buffer type, but the default opcode not 
support save buffer type value(The EFI_IFR_TYPE_VALUE not support buffer type), 
so the default opcode can't be used by ordered list opcode.
[cid:image001.jpg@01CFC6E2.FED0A970]

[cid:image002.jpg@01CFC6E2.FED0A970]

Current for ordered list opcode, browser based on the current option order nest 
in this question to set the default value for it.
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

I believe that what you say is useful. But I don't think the specification 
describes that behavior.

The next question, which was asked by someone else on the EDK2 list, is what to 
do with "default" Both the flag for the "option" and the separate "default" 
opcode. The "just the value for the one container" does not seem like a good 
usage for default, since normally the engineer would like to saw the default 
values for all containers. But if "option" is for 1 container, then how does 
that work for default?

So here is a proposal for a clarification I would like to see in the UEFI 
specification:


1)  That, for ordered list, the "option values" should refer to a single 
container.

2)  When setting the default value using "option" then all containers will 
be filled with that value.

3)  When setting the default value using "default" then the "value" will be 
a Buffer type, with one byte of the Buffer per container. If the default value 
is smaller than the Buffer size, then the remaining containers will be filled 
with 0.

Tim


From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:40 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

I admit that one container should only has one byte, and I think one option is 
corresponding to one container, do you agree this assumption?

For below sample code, current code use UINT16 for BootOrder array, so the 
value for each option is UINT16. Now I think we should not use UINT16 array for 
ordered list,  we should only user BYTE type(UINT8) array for the ordered list 
opcode. Right?
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;

typedef struct {
  ...
  UINT16  BootOrder[8];
  ...
} DRIVER_SAMPLE_CONFIGURATION;


Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, September 02, 2014 9:25 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

It is pretty clear from the spec that the value size for ordered list is 1 byte 
per container. See 29.2.5.4.8,

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

There is no indication, either in the IFR or VFR specification that "option" 
values refer to  a single container value. There is also no indication in these 
specifications that an option is a 16-bit value.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:18 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [e

[edk2] PCD Binary SkuIdTable and SystemSkuId Documentaton

[Tim Lewis]

The PCD Inf files contain this section in the header, describing the format of 
the FFS file that is integrated with the PcdPei and PcdDxe modules. But two 
fields are left undocumented: SkuIdTable and SystemSkuId.

Is there any further documentation elsewhere about the format of these sections/

Thanks,

Tim

#3.3 PCD Database binary file
#  PCD Database binary file will be created at build time as the standalone 
binary image.
#  To understand the binary image layout, PCD Database C structure is still 
generated
#  as comments by build tools in PCD driver's autogen.h/
#  autogen.c file. In generated C structure, following information is 
stored:
#  - ExMapTable: This table is used translate a binary dynamicex type PCD's
#"tokenguid + token" to local token number.
#  - LocalTokenNumberTable:
#This table stores all local token number in array, use 
"Internal
#token number" as array index to get PCD entry's offset 
fastly.
#  - SizeTable:  This table stores the size information for all PCD entry.
#  - GuidTable:  This table stores guid value for DynamicEx's token space,
#HII type PCD's variable GUID.
#  - SkuIdTable: TBD
#  - SystemSkuId: TBD
#  - PCD value structure:
#Every PCD has a value record in PCD database. For different
#datum type PCD has different record structure which will be
#introduced in 3.3.1
--
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] HII ORDERED_LIST support

[Tim Lewis]

Eric -

I believe that what you say is useful. But I don't think the specification 
describes that behavior.

The next question, which was asked by someone else on the EDK2 list, is what to 
do with "default" Both the flag for the "option" and the separate "default" 
opcode. The "just the value for the one container" does not seem like a good 
usage for default, since normally the engineer would like to saw the default 
values for all containers. But if "option" is for 1 container, then how does 
that work for default?

So here is a proposal for a clarification I would like to see in the UEFI 
specification:


1)  That, for ordered list, the "option values" should refer to a single 
container.

2)  When setting the default value using "option" then all containers will 
be filled with that value.

3)  When setting the default value using "default" then the "value" will be 
a Buffer type, with one byte of the Buffer per container. If the default value 
is smaller than the Buffer size, then the remaining containers will be filled 
with 0.

Tim


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

Tim,

I admit that one container should only has one byte, and I think one option is 
corresponding to one container, do you agree this assumption?

For below sample code, current code use UINT16 for BootOrder array, so the 
value for each option is UINT16. Now I think we should not use UINT16 array for 
ordered list,  we should only user BYTE type(UINT8) array for the ordered list 
opcode. Right?
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;

typedef struct {
  ...
  UINT16  BootOrder[8];
  ...
} DRIVER_SAMPLE_CONFIGURATION;


Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, September 02, 2014 9:25 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

It is pretty clear from the spec that the value size for ordered list is 1 byte 
per container. See 29.2.5.4.8,

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

There is no indication, either in the IFR or VFR specification that "option" 
values refer to  a single container value. There is also no indication in these 
specifications that an option is a 16-bit value.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:18 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

I agree "Value of the question is the entire buffer, not just one byte." But I 
don't think "the value in a ONE_OF_OPTION is the value for the entire value 
storage, not just one byte of the value storage. "
Take below code for example, the value for this question is 0002,0001,0003,0004 
(8 byte), and the value type if buffer type. but for each option, the value is 
different(0002/0001/0003/004), and type is UINT16 (2 byte), not 8 byte.
  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;

so I think current issue for vfrcompile is it not restrict the data type for 
each container is 1 byte.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 25, 2014 3:11 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

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:

"

Re: [edk2] HII ORDERED_LIST support

[Tim Lewis]

Eric -

It is pretty clear from the spec that the value size for ordered list is 1 byte 
per container. See 29.2.5.4.8,

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

There is no indication, either in the IFR or VFR specification that "option" 
values refer to  a single container value. There is also no indication in these 
specifications that an option is a 16-bit value.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:18 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

I agree "Value of the question is the entire buffer, not just one byte." But I 
don't think "the value in a ONE_OF_OPTION is the value for the entire value 
storage, not just one byte of the value storage. "
Take below code for example, the value for this question is 0002,0001,0003,0004 
(8 byte), and the value type if buffer type. but for each option, the value is 
different(0002/0001/0003/004), and type is UINT16 (2 byte), not 8 byte.
  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;

so I think current issue for vfrcompile is it not restrict the data type for 
each container is 1 byte.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 25, 2014 3:11 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

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<mailto: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<mailto: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 fo

Re: [edk2] VFR Specification "catenate" example issue

[Tim Lewis]

Eric -

Thank you. That is what I suspected.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 9:01 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] VFR Specification "catenate" example issue

Tim,

VFR spec has  a mistake about the sample code for catenate, the correct format 
is like below which is same as your expectation:

string varid = MyData.String,

  prompt = STRING_TOKEN(STR_PROMPT),

  help = STRING_TOKEN(STR_HELP),

  minsize = 6,

  maxsize = 40,

  inconsistentif prompt = STRING_TOKEN(STR_CHECK),

pushthis != catenate (stringref (STRING_TOKEN(STR_STRING_RIGHT)), stringref 
(STRING_TOKEN(STR_STRING_LEFT))),

  endif
endstring;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, September 02, 2014 5:46 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] VFR Specification "catenate" example issue

Eric -

Please try the example. When I tried it, it cannot compile.

The EFI_IFR_CATENATE operator expects two strings expressions, right? How to 
specify two strings in an expression? As far as I can tell, STRING_TOKEN is not 
a valid expression term. Only stringref() is a valid expression term that 
returns a string. Is it your intention that STRING_TOKEN can generate a 
EFI_IFR_STRING_REF1 opcode?

Here is EFI_IFR_CATENATE (29.3.8.3.8)

typedef struct _EFI_IFR_CATENATE {
  EFI_IFR_OP_HEADER Header;
} EFI_IFR_CATENATE;

Here is EFI_IFR_STRING_REF1 (29.3.8.3.71):

typedef struct _EFI_IFR_STRING_REF1 {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID StringId;
} EFI_IFR_STRING_REF1;

So I would expect to see

0x4e 0x04 0xyy 0xyy 0x4e 0x04 0xzz 0xzz 0x5e 0x02

Where  and  are the string ids in question.

Am I missing something?

Thanks,

Tim



From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:07 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] VFR Specification "catenate" example issue

Below is UEFI definition for EFI_IFR_TYPE_VALUE, for string type, it use 
EFI_STRING_ID to specify it, so for catenate, it uses STRING_TOKEN.
typedef union {
  UINT8   u8;
  UINT16  u16;
  UINT32  u32;
  UINT64  u64;
  BOOLEAN b;
  EFI_HII_TIMEtime;
  EFI_HII_DATEdate;
  EFI_STRING_ID   string; ///< EFI_IFR_TYPE_STRING, EFI_IFR_TYPE_ACTION
  EFI_HII_REF ref;///< EFI_IFR_TYPE_REF
  // UINT8 buffer[];  ///< EFI_IFR_TYPE_BUFFER
} EFI_IFR_TYPE_VALUE;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 27, 2014 8:57 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] VFR Specification "catenate" example issue


The example for catenate (in 2.12.11.1) appears to be incorrect. I believe that 
the parameters for catenate should be stringref(STRING_TOKEN), not just 
STRING_TOKEN. Or at least the grammar doesn't seem to support a STRING_TOKEN in 
vfrExpressionConstant and the current VfrCompiler.exe complains.





string varid = MyData.String,

  prompt = STRING_TOKEN(STR_PROMPT),

  help = STRING_TOKEN(STR_HELP),

  minsize = 6,

  maxsize = 40,

  inconsistentif prompt = STRING_TOKEN(STR_CHECK),

pushthis != catenate (STRING_TOKEN(STR_STRING_RIGHT),

  STRING_TOKEN(STR_STRING_LEFT)),

  endif
endstring;
--
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] VFR Specification "catenate" example issue

[Tim Lewis]

Eric -

Please try the example. When I tried it, it cannot compile.

The EFI_IFR_CATENATE operator expects two strings expressions, right? How to 
specify two strings in an expression? As far as I can tell, STRING_TOKEN is not 
a valid expression term. Only stringref() is a valid expression term that 
returns a string. Is it your intention that STRING_TOKEN can generate a 
EFI_IFR_STRING_REF1 opcode?

Here is EFI_IFR_CATENATE (29.3.8.3.8)

typedef struct _EFI_IFR_CATENATE {
  EFI_IFR_OP_HEADER Header;
} EFI_IFR_CATENATE;

Here is EFI_IFR_STRING_REF1 (29.3.8.3.71):

typedef struct _EFI_IFR_STRING_REF1 {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID StringId;
} EFI_IFR_STRING_REF1;

So I would expect to see

0x4e 0x04 0xyy 0xyy 0x4e 0x04 0xzz 0xzz 0x5e 0x02

Where  and  are the string ids in question.

Am I missing something?

Thanks,

Tim


From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:07 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] VFR Specification "catenate" example issue

Below is UEFI definition for EFI_IFR_TYPE_VALUE, for string type, it use 
EFI_STRING_ID to specify it, so for catenate, it uses STRING_TOKEN.
typedef union {
  UINT8   u8;
  UINT16  u16;
  UINT32  u32;
  UINT64  u64;
  BOOLEAN b;
  EFI_HII_TIMEtime;
  EFI_HII_DATEdate;
  EFI_STRING_ID   string; ///< EFI_IFR_TYPE_STRING, EFI_IFR_TYPE_ACTION
  EFI_HII_REF ref;///< EFI_IFR_TYPE_REF
  // UINT8 buffer[];  ///< EFI_IFR_TYPE_BUFFER
} EFI_IFR_TYPE_VALUE;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 27, 2014 8:57 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] VFR Specification "catenate" example issue


The example for catenate (in 2.12.11.1) appears to be incorrect. I believe that 
the parameters for catenate should be stringref(STRING_TOKEN), not just 
STRING_TOKEN. Or at least the grammar doesn't seem to support a STRING_TOKEN in 
vfrExpressionConstant and the current VfrCompiler.exe complains.





string varid = MyData.String,

  prompt = STRING_TOKEN(STR_PROMPT),

  help = STRING_TOKEN(STR_HELP),

  minsize = 6,

  maxsize = 40,

  inconsistentif prompt = STRING_TOKEN(STR_CHECK),

pushthis != catenate (STRING_TOKEN(STR_STRING_RIGHT),

  STRING_TOKEN(STR_STRING_LEFT)),

  endif
endstring;
--
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] Bitwise OR operator problems

[Tim Lewis]

Eric --

The UEFI specification says that "Data conversion is not implicit. Explicit 
data conversion can be performed using the EFI_IFR_TO_STRING, EFI_IFR_TO_UINT, 
and EFI_IFR_TO_BOOLEAN operators." (29.2.5.7.4) The VFR compiler in this case 
is generating code that would not work on a conformant Form Browser, because 
the result of == is BOOLEAN TRUE (not 1), and | does not take type BOOLEAN for 
either operand. The spec says that if either type does not evaluate as an 
Integer, the result should be "Undefined"

Suppressif takes a result of BOOLEAN TRUE (not integer 0 or non-zero). The 
result of suppressif with a result of Undefined is not mentioned in the 
specification.

Tim

-Original Message-
From: Dong, Eric [mailto:eric.d...@intel.com] 
Sent: Friday, August 29, 2014 11:16 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bitwise OR operator problems

I check the current implementation of browser and vfrcompile, detail shows 
below:
Below IFR data generated from the vfr file:
suppressif 8|8 == 0x8;
>01AA: 0A 82 
>01AC: 45 8A 08 00 00 00 00 00 00 00 
>01B6: 45 0A 08 00 00 00 00 00 00 00 
>01C0: 45 0A 08 00 00 00 00 00 00 00 
>01CA: 2F 02 
>01CC: 36 02 
>01CE: 29 02 

checkbox varid   = MyIfrNVData.ChooseToActivateNuclearWeaponry,
>01D0: 06 8E 29 00 2A 00 03 00 34 12 D4 00 00 03 
 prompt   = STRING_TOKEN(0x0029),
 help = STRING_TOKEN(0x002A),
 flags= CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG,
 default  = TRUE,
>01DE: 5B 06 00 00 00 01 
endcheckbox;
>01E4: 29 02 

endif;
>01E6: 29 02

In browser, when do the "|" operate, it save the result as an UINT64 type and 
the result is 0x9. When check the suppressif opcode, it found the data type is 
UINT64 and value is 0x9,not 0, so the checkbox is suppressed.


Thanks,
Eric

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com] 
Sent: Friday, August 29, 2014 7:18 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bitwise OR operator problems

So this leads to the follow on question (now that I've got the precedence 
straight): suppressif 8|8 == 0x8 is an illegal statement.

 in IFR (8 8 EFI_IFR_EQUAL 8 EFI_IFR_BITWISE_OR) since EFI_IFR_EQUAL results in 
a BOOLEAN, but EFI_IFR_BITWISE_OR requires an integer, and IFR is strongly 
typed.

In Laszlo's original analysis:   8|(8 == 0x8) means   8|1

The specification says:

This opcode performs the following actions:
1. Pop two expressions from the expression stack.
2. If the two expressions cannot be evaluated as unsigned integers, push 
Undefined.
3. Otherwise, zero-extend the unsigned integers to 64-bits.
4. Perform a bitwise-OR of the two values.
5. Push the result.

There is no implicit type conversion in IFR, so in order for VfrCompile.exe to 
handle this expression, I would expect a EFI_IFR_TO_BOOLEAN to be generated 
implicitly. But in my analysis of the IFR being generated, it is not.

In fact, an optimizer tool we have written catches these as errors, along with 
the fact that the suppressif expression is not evaluating to a bool.

Tim

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com] 
Sent: Thursday, August 28, 2014 5:53 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bitwise OR operator problems

Laszlo --

You are correct. I have verified the VFR grammar which has similar priority.

It is actually the behavior for integer conversion in suppressif that is 
confusing me, not the order of evaluation like I thought.

Tim

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, August 28, 2014 5:43 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bitwise OR operator problems

On 08/28/14 11:31, Laszlo Ersek wrote:

> In the C language, both operator & and operator | bind
> *less* strongly than operator ==.

(Sorry for following up on my own email.) I found some references:

http://en.wikipedia.org/wiki/Operator_precedence_in_C#Criticism_of_bitwise_and_equality_operators_precedence

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

See under "Neonatal 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

--
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] Bitwise OR operator problems

[Tim Lewis]

So this leads to the follow on question (now that I've got the precedence 
straight): suppressif 8|8 == 0x8 is an illegal statement.

 in IFR (8 8 EFI_IFR_EQUAL 8 EFI_IFR_BITWISE_OR) since EFI_IFR_EQUAL results in 
a BOOLEAN, but EFI_IFR_BITWISE_OR requires an integer, and IFR is strongly 
typed.

In Laszlo's original analysis:   8|(8 == 0x8) means   8|1

The specification says:

This opcode performs the following actions:
1. Pop two expressions from the expression stack.
2. If the two expressions cannot be evaluated as unsigned integers, push 
Undefined.
3. Otherwise, zero-extend the unsigned integers to 64-bits.
4. Perform a bitwise-OR of the two values.
5. Push the result.

There is no implicit type conversion in IFR, so in order for VfrCompile.exe to 
handle this expression, I would expect a EFI_IFR_TO_BOOLEAN to be generated 
implicitly. But in my analysis of the IFR being generated, it is not.

In fact, an optimizer tool we have written catches these as errors, along with 
the fact that the suppressif expression is not evaluating to a bool.

Tim

-Original Message-----
From: Tim Lewis [mailto:tim.le...@insyde.com] 
Sent: Thursday, August 28, 2014 5:53 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bitwise OR operator problems

Laszlo --

You are correct. I have verified the VFR grammar which has similar priority.

It is actually the behavior for integer conversion in suppressif that is 
confusing me, not the order of evaluation like I thought.

Tim

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, August 28, 2014 5:43 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bitwise OR operator problems

On 08/28/14 11:31, Laszlo Ersek wrote:

> In the C language, both operator & and operator | bind
> *less* strongly than operator ==.

(Sorry for following up on my own email.) I found some references:

http://en.wikipedia.org/wiki/Operator_precedence_in_C#Criticism_of_bitwise_and_equality_operators_precedence

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

See under "Neonatal 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

--
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 2/2] [MdePkg] INF/DEC file updates to EDK II packages

[Tim Lewis]

Mike --

I think in most production cases, that is an acceptable limitation. But, if we 
require further qualification, you could add a further field to qualify this by 
INF 

[Packages]
  MdePkg/MdePkg.dec | Core/MdePkg/MdePkg.dec | 
MdeModulePkg/Universal/Core/Dxe/DxeMain.inf


-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Friday, August 29, 2014 1:57 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages

Andrew,

A [Packages] section in the DSC file would be global and would not support 
multiple versions of the same package installed in a WORKSPACE with different 
modules requiring different versions of the same package to build.

If and only if you had a single version of each package in WORKSPACE would this 
be unambiguous.

Mike

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com] 
Sent: Monday, August 25, 2014 11:07 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages

Andrew --

Your 1st example works for me also.

Tim

-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Tuesday, August 26, 2014 2:01 PM
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 10:12 PM, Tim Lewis  wrote:

> 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,

I think this would be easier to implement, and understand:
[Packages]
  MdePkg/MdePkg.dec | Core/MdePkg/MdePkg.dec

So basically original package location vs. shifted location in this build tree. 
It also does not require any changes to support non adjusted .dec paths.

An alternate form could be the path to pre-pend:
[Packages]
  MdePkg/MdePkg.dec | Core


I made a cheap hack to add an environment variable called ALT_WORKSPACE to add 
alternate places to search for .dec files. 
export ALT_WORKSPACE="$WORKSPACE/edk2/;$WORKSPACE/Vendor/Xyz/XyzProjectK/"

So in this example the search path for a *.dec would be $WORKSPACE, then 
"$WORKSPACE/edk2, and $WORKSPACE/Vendor/Xyz/XyzProjectK/. Basically the edk2 is 
a subdirectory in the tree, and the vendor code is not all in the root of the 
tree. Putting  the info in the .dsc file would be a better solution, but the 
ALT_WORKSPACE environment variable is only requires a few lines of new Python 
code. 

Thanks,

Andrew Fish

> 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 
> caus

Re: [edk2] Bitwise OR operator problems

[Tim Lewis]

Laszlo --

You are correct. I have verified the VFR grammar which has similar priority.

It is actually the behavior for integer conversion in suppressif that is 
confusing me, not the order of evaluation like I thought.

Tim

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, August 28, 2014 5:43 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bitwise OR operator problems

On 08/28/14 11:31, Laszlo Ersek wrote:

> In the C language, both operator & and operator | bind
> *less* strongly than operator ==.

(Sorry for following up on my own email.) I found some references:

http://en.wikipedia.org/wiki/Operator_precedence_in_C#Criticism_of_bitwise_and_equality_operators_precedence

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

See under "Neonatal 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

--
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] Bitwise OR operator problems

[Tim Lewis]

It appears that this should prevent the display of the text statement. However, 
to my surprise, it works on NT32. Per operator precedence, it should be 8|8 is 
8, and 8 == 8 is TRUE.

suppressif 8|8 == 0x8;
text
help = STRING_TOKEN(STR_BITWISE_OR_HELP),
text  = STRING_TOKEN(STR_BITWISE_OR_PROMPT);
endif;

The equivalent 8&8 == 0x8 has no problem.
--
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] Endless Loop when DEBUG_POOL used with ReportStatusCode version of DebugLib

[Tim Lewis]

Mike -
Using a non-RSC version of debug lib isn't an option for these customers.
Is it possible to handle the allocation outside of the RSC call itself? And get 
notification if a new handler is installed to update
Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 28, 2014 12:22 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode 
version of DebugLib

Tim,
Yes.  This issue has been around a while.  The workaround when you want to 
monitor every single pool operation in the DXE Core is to use a DebugLib 
instance that sends debug messages directly to a debug device such as 
MdePkg/Library/BaseDebugLibSerialPort.
The issue with using a DebugLib instance that sends debug messages through 
report status code is that the report status code services allocate from pool, 
which causes the recursion.
Thanks,
Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 27, 2014 9:00 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode version 
of DebugLib

Symptom:
If "DEBUG_POOL" bit is set in PcdDebugPrintErrorLevel, BIOS will enter 
recursive loop. (A call B, B call C, C call A, )
Description:
This happens when the PeiDxeDebugLibReportStatusCode.inf version of DebugLib is 
used. We found it can be duplicated with revision 15913, although it appears 
the problem has been there for a while.
Procedure: Step by Step

1.DxeMain.c - Line 237, DxeMain()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

2.   DxeMain.c - Line 419, CoreInstallMultipleProtocolInterfaces()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

3.   Handle.c - Line 582, CoreInstallProtocolInterface()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

4.Handle.c - Line 311, CoreInstallProtocolInterfaceNotify()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

5.   Handle.c - Line 384, CoreAcquireProtocolLock()   <-First Lock

~\MdeModulePkg\Core\Dxe\Hand\Handle.c

6.   Handle.c - Line 389, CoreFindProtocolEntry (Protocol, TRUE)
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

7.   Handle.c - Line 136, AllocatePool()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

8.   MemoryAllocationLib.c - Line 405, InternalAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

9.   MemoryAllocationLib.c - Line 380, CoreAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

10.   Pool.c - Line 216, CoreAllocatePoolI()
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

11.   Pool.c - Line 343, DEBUG()  <- It will run when efidebug BIOS + 
(PcdDebugPrintErrorLevel  | DEBUG_POOL)
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

12.   DebugLib.c - Line 50, DebugPrint()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

13.   DebugLib.c - Line 219, REPORT_STATUS_CODE_EX()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

14.   ReportStatusCodeLib.c - Line 481, ReportStatusCodeEx()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

15.   ReportStatusCodeLib.c - Line 555, InternalReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

16.   ReportStatusCodeLib.c - Line 102, InternalGetReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

17.   ReportStatusCodeLib.c - Line 57, gBS->LocateProtocol()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

18.   Locate.c - Line 552, CoreLocateProtocol()
~\MdeModulePkg\Core\Dxe\Hand\Locate.c

19.   Locate.c - Line 583, CoreAcquireProtocolLock() <-Second Lock (enter 
ASSERT())

~\MdeModulePkg\Core\Dxe\Hand\Locate.c

20.   DebugLib.c - Line 253, DebugAssert()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

21.   DebugLib.c - Line 317, REPORT_STATUS_CODE_EX()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

22.Enter recursive loop, step 
21->14->15->...->21->14->15->..

--
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] Endless Loop when DEBUG_POOL used with ReportStatusCode version of DebugLib

[Tim Lewis]

Symptom:
If "DEBUG_POOL" bit is set in PcdDebugPrintErrorLevel, BIOS will enter 
recursive loop. (A call B, B call C, C call A, )
Description:
This happens when the PeiDxeDebugLibReportStatusCode.inf version of DebugLib is 
used. We found it can be duplicated with revision 15913, although it appears 
the problem has been there for a while.
Procedure: Step by Step

1.DxeMain.c - Line 237, DxeMain()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

2.   DxeMain.c - Line 419, CoreInstallMultipleProtocolInterfaces()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

3.   Handle.c - Line 582, CoreInstallProtocolInterface()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

4.Handle.c - Line 311, CoreInstallProtocolInterfaceNotify()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

5.   Handle.c - Line 384, CoreAcquireProtocolLock()   <-First Lock

~\MdeModulePkg\Core\Dxe\Hand\Handle.c

6.   Handle.c - Line 389, CoreFindProtocolEntry (Protocol, TRUE)
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

7.   Handle.c - Line 136, AllocatePool()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

8.   MemoryAllocationLib.c - Line 405, InternalAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

9.   MemoryAllocationLib.c - Line 380, CoreAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

10.   Pool.c - Line 216, CoreAllocatePoolI()
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

11.   Pool.c - Line 343, DEBUG()  <- It will run when efidebug BIOS + 
(PcdDebugPrintErrorLevel  | DEBUG_POOL)
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

12.   DebugLib.c - Line 50, DebugPrint()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

13.   DebugLib.c - Line 219, REPORT_STATUS_CODE_EX()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

14.   ReportStatusCodeLib.c - Line 481, ReportStatusCodeEx()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

15.   ReportStatusCodeLib.c - Line 555, InternalReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

16.   ReportStatusCodeLib.c - Line 102, InternalGetReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

17.   ReportStatusCodeLib.c - Line 57, gBS->LocateProtocol()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

18.   Locate.c - Line 552, CoreLocateProtocol()
~\MdeModulePkg\Core\Dxe\Hand\Locate.c

19.   Locate.c - Line 583, CoreAcquireProtocolLock() <-Second Lock (enter 
ASSERT())

~\MdeModulePkg\Core\Dxe\Hand\Locate.c

20.   DebugLib.c - Line 253, DebugAssert()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

21.   DebugLib.c - Line 317, REPORT_STATUS_CODE_EX()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

22.Enter recursive loop, step 
21->14->15->...->21->14->15->..

--
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] "goto" vfrConstantValue

[Tim Lewis]

It appears that the VFR specification has not been updated with the HII_REF 
default format, although it is used in the DriverSampleDxe. Can I verify the 
actual format?

Here is a sample:

  default = 0;0;ZERO_GUID;STRING_TOKEN(STR_NULL_STRING),

It appears that this is: question = 0, formid = 0, formsetguid = ZERO_GUID and 
devicepath = STRING_TOKEN(STR_NULL_STRING). Is this correct?

Then the grammar would be something like:

integer ";" integer ";" guid ";" string-token

which differentiates it from the other constant values (like time with ':' and 
date with '/'). Correct?

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

[edk2] VFR Specification "catenate" example issue

[Tim Lewis]

The example for catenate (in 2.12.11.1) appears to be incorrect. I believe that 
the parameters for catenate should be stringref(STRING_TOKEN), not just 
STRING_TOKEN. Or at least the grammar doesn't seem to support a STRING_TOKEN in 
vfrExpressionConstant and the current VfrCompiler.exe complains.





string varid = MyData.String,

  prompt = STRING_TOKEN(STR_PROMPT),

  help = STRING_TOKEN(STR_HELP),

  minsize = 6,

  maxsize = 40,

  inconsistentif prompt = STRING_TOKEN(STR_CHECK),

pushthis != catenate (STRING_TOKEN(STR_STRING_RIGHT),

  STRING_TOKEN(STR_STRING_LEFT)),

  endif
endstring;
--
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]

Andrew --

Your 1st example works for me also.

Tim

-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Tuesday, August 26, 2014 2:01 PM
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 10:12 PM, Tim Lewis  wrote:

> 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,

I think this would be easier to implement, and understand:
[Packages]
  MdePkg/MdePkg.dec | Core/MdePkg/MdePkg.dec

So basically original package location vs. shifted location in this build tree. 
It also does not require any changes to support non adjusted .dec paths.

An alternate form could be the path to pre-pend:
[Packages]
  MdePkg/MdePkg.dec | Core


I made a cheap hack to add an environment variable called ALT_WORKSPACE to add 
alternate places to search for .dec files. 
export ALT_WORKSPACE="$WORKSPACE/edk2/;$WORKSPACE/Vendor/Xyz/XyzProjectK/"

So in this example the search path for a *.dec would be $WORKSPACE, then 
"$WORKSPACE/edk2, and $WORKSPACE/Vendor/Xyz/XyzProjectK/. Basically the edk2 is 
a subdirectory in the tree, and the vendor code is not all in the root of the 
tree. Putting  the info in the .dsc file would be a better solution, but the 
ALT_WORKSPACE environment variable is only requires a few lines of new Python 
code. 

Thanks,

Andrew Fish

> 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 yo

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

[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] 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

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] 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] 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<mailto: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.

[edk2] "suppressif" "endif" grammar different between Form, FormSet and Question usage.

[Tim Lewis]

Compare the following. Notice that the question does not require it to be 
present, but the statement and formset do. I suggest that these be made 
consistent by making the ";" optional in all cases, and the examples in 
DriverSampleDxe be updated to always include it.


vfrStatementSuppressIfQuest ::=

"suppressif" vfrStatementExpression ";"

vfrStatementQuestionOptionList
"endif"


vfrStatementSuppressIfStat ::=

"suppressif" vfrStatementExpression ";"

( vfrStatementStatList )*
"endif" ";"


vfrStatementSuppressIfFormSet ::=

"suppressif" vfrStatementExpression ";"

vfrFormSetList
"endif" ";"

--
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] HII ORDERED_LIST support

[Tim Lewis]

Eric -

See below:

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 22, 2014 12:40 AM
To: edk2-devel@lists.sourceforge.net<mailto: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]"

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.



But I do not believe this is what the EDK2 Form browser does today. I believe 
that it only changes a single container to the value 2 (not the whole buffer).



3)  Likewise, there seems to be no way to provide a default for an ordered 
list.

[[[Eric]]] yes, ordered list opcode just base on the current option order to 
set the default value. For your above example, the default value is 2,1,3,4.



[TIM] If I put a "default = 2" in the example above, will it set one container 
to "2" or all containers to "2" Again, this is a problem with the way the 
specification describes values for ordered list opcodes. It is fairly clear 
that the EDK2 form browser takes a different approach than the current 
specification.



Here is an example display:



Boot Order: [boot order 1] [boot order 2][boot order 3][boot order 4][boot 
order 5][boot order 6][boot order 7][boot order 8]



Each [boot order x] is a container. If the user goes to [boot order 2] and uses 
one of the ONE_OF_OPTION pre-defined values, does it change only [boot order 2] 
or all [boot order x]?  Now, what does the UEFI specification say should happen?

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] [PATCH RFC 0/4] UDF filesystem driver

[Tim Lewis]

Jordan --

Yes, we want to disable anything non-spec (and in some cases, even those). Size 
sensitive applications are always trying to take out the pieces that they don't 
absolutely need. Adding a simple PCD allows us to make that choice without 
having to branch the code.

Tim

-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Thursday, August 21, 2014 2:43 PM
To: Andrew J. Fish; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH RFC 0/4] UDF filesystem driver

On Thu, Aug 21, 2014 at 1:37 PM, Paulo Alcantara  wrote:
> On Thu, August 21, 2014 4:49 pm, Andrew Fish wrote:
>> The spec is defining what is required to be implement. It does not 
>> limit what could be implemented. Thus you would probably want to add 
>> a PCD feature flag to turn on/off UDF support in the partition 
>> driver, and just default it to off.
>
> OK - figured it out. Thanks.
>
> Given that, I think I could start working on PartitionDxe to support 
> UDF and possibly use the "PCD feature flag" Andrew mentioned -- I 
> still need to take a look at how that works but sounds good to me the 
> ability to turn on/off it.
>
> How about that guys?

I don't see a reason to want to disable it. It will just cause an extra DiskIo 
to be produced for the UDF "partition".

Do you think a PCD is really needed Andrew?

-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

--
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] HII CHECKBOX

[Tim Lewis]

The following statement appears in DriverSampleDxe for a checkbox:

checkbox varid   = MyIfrNVData.ChooseToActivateNuclearWeaponry,
 prompt   = STRING_TOKEN(0x0029),
 help = STRING_TOKEN(0x002A),




 flags= CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG,
 key  = 0,
 default  = 1,
endcheckbox;

Since a checkbox has a type of Boolean, I would have expected the value after 
default to be a Boolean also. vfrConstantValueField is the terminal used to 
process these values and this supports "TRUE" and "FALSE" There is no explicit 
statement in the VFR spec which says that this will be converted to a type 
Boolean. I suggest that these be changed in the sample to use the correct 
Boolean values and that the VfrCompiler generate a warning in this case 
(something like "forced conversion of integer to Boolean"

I would suggest the same for handling of items such as suppressif 1, or at 
least clarify that the compiler will automatically promote integers to Booleans 
(because the UEFI spec is pretty clear that this is not a Boolean)

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

[edk2] HII ORDERED_LIST support

[Tim Lewis]

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."

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.

3)  Likewise, there seems to be no way to provide a default for an ordered 
list.

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

[edk2] HII ONE_OF_OPTIONS flags

[Tim Lewis]

The current DriverSampleDxe has the following item for the orderedlist:

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;

The VFR specification lists both RESET_REQUIRED and INTERACTIVE for the 
"option" flags field.

But the UEFI specification says:

FlagsSpecifies the flags associated with the current option. See 
EFI_IFR_OPTION_x.


#define EFI_IFR_OPTION_DEFAULT 0x10
#define EFI_IFR_OPTION_DEFAULT_MFG 0x20

The VFR specification then goes on to say:

Therefore, the options' flags are treated as question flags and can accept all 
values of question flags.

What is not clear is: do these flags enable some extension to the UEFI 
specification? (since theses flags are not in the specification) or are these 
flags, in effect, promoted so that the question's Flags field bit will be set 
IF any option has the field bit set?

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] [StdLib] Patch for review: Add VC++ helper function for 64-bit right shift

[Tim Lewis]

Mike,

It is obvious that someone has discovered the interfaces for some, since Daryl 
is able to create one for the StdLib. That is one error that we can remove from 
everyone’s collective experience going forward. So why not start with 
documenting what we know?

Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, August 20, 2014 5:31 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 
64-bit right shift

Tim,

For background, can you please provide a links to the public specification of 
all intrinsic function calls that may be generated for all the compilers 
supported by the EDK II open source project.

Thanks,

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 20, 2014 5:09 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 
64-bit right shift

Mike –

The linker errors are the side effect of not putting full support for the 
compilers in the tree. I don’t want a better error message. I don’t want an 
error message at all. And there is no real reason why EDK2 cannot provide that. 
It is not an app thing. It is an EDK2 thing.

What is the rationale for maintaining the status quo?  Does that really 
outweigh fully support the C language on Visual Studio compilers? Or do we 
really want to leave Visual Studio for x86 at a disadvantage?

Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, August 20, 2014 4:59 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 
64-bit right shift

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.

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.

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<mailto: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<mailto: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 

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

[Tim Lewis]

Mike –

The linker errors are the side effect of not putting full support for the 
compilers in the tree. I don’t want a better error message. I don’t want an 
error message at all. And there is no real reason why EDK2 cannot provide that. 
It is not an app thing. It is an EDK2 thing.

What is the rationale for maintaining the status quo?  Does that really 
outweigh fully support the C language on Visual Studio compilers? Or do we 
really want to leave Visual Studio for x86 at a disadvantage?

Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, August 20, 2014 4:59 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for 
64-bit right shift

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.

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.

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<mailto: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<mailto: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 
mailto:tim.le...@insyde.com>> wrote:
Daryl –

Do we want to create the equivalent of the ArmPkg/Library/CompilerIntrinsicsLib 
for x86 so that these sorts of math-helpers can be used across the whole build? 
Per

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

[Tim Lewis]

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 
mailto:tim.le...@insyde.com>> wrote:
Daryl –

Do we want to create the equivalent of the ArmPkg/Library/CompilerIntrinsicsLib 
for x86 so that these sorts of math-helpers can be used across the whole build? 
Perhaps UefiCpuPkg/Library/CompilerIntrinsicsLib?

Tim



From: Mcdaniel, Daryl 
[mailto:daryl.mcdan...@intel.com<mailto:daryl.mcdan...@intel.com>]
Sent: Wednesday, August 20, 2014 10:56 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] [StdLib] Patch for review: Add VC++ helper function for 64-bit 
right shift

Jaben, Erik, or Lee (or anyone else ☺),
Please review the attached patch.  llshr.c is a new file, LibC.inf was modified.

StdLib: Add a runtime helper function for VC++ 64-bit right shift on Ia32 
target architectures.

Add new file StdLib/LibC/CRT/Ia32/llshr.c
Add references to the new file to StdLib/LibC/LibC.inf


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Daryl McDaniel


--
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto: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] [StdLib] Patch for review: Add VC++ helper function for 64-bit right shift

[Tim Lewis]

Daryl -

Do we want to create the equivalent of the ArmPkg/Library/CompilerIntrinsicsLib 
for x86 so that these sorts of math-helpers can be used across the whole build? 
Perhaps UefiCpuPkg/Library/CompilerIntrinsicsLib?

Tim



From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com]
Sent: Wednesday, August 20, 2014 10:56 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [StdLib] Patch for review: Add VC++ helper function for 64-bit 
right shift

Jaben, Erik, or Lee (or anyone else :)),
Please review the attached patch.  llshr.c is a new file, LibC.inf was modified.

StdLib: Add a runtime helper function for VC++ 64-bit right shift on Ia32 
target architectures.

Add new file StdLib/LibC/CRT/Ia32/llshr.c
Add references to the new file to StdLib/LibC/LibC.inf


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Daryl McDaniel

--
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] [RFC] EDK II UNI Unicode File Specification

[Tim Lewis]

Larry -

Thanks for the cleanup.

Let me see whether our current extensions would be appropriate for a proposal. 
If not, I'll find something that is appropriate.

Tim

From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Tuesday, August 19, 2014 2:54 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [RFC] EDK II UNI Unicode File Specification

Hi Tim,

I agree with your proposal for #1. - See highlighting in the original RFC text 
(add and delete).

For #2 & 3, After looking through the UEFI specifications, the escape character 
sequences are not defined for the code, so I have removed the majority of them.
The only ones that are now listed in the EBNF are the ones that are currently 
processed by the EDK II build system (see 
Source\Python\AutoGen\UniClassObject.py).

Actually, I would like to see a proposal that would update both this spec and 
our tools for alternate methods for specifying the control codes listed in UEFI 
Spec v2.4B (section 29.2.6.2.4). Using something like "\" (a-zA-Z)+ ";" that 
uses the semi-colon as the terminator for the control code, or use hypertext 
markings like: "<" ["\"] (a-zA-Z)+ ">" as an additional method that must be 
supported by the EDI II Build tools. Since the tools have to convert these into 
the Double-Byte encodings specified in the UEFI Spec, they do need to be 
defined in a table.

I would also suggest that we do not add any unterminated control code sequences 
for any new content that must be supported. (Only \wide, \narrow and \nbr along 
with the standard \n, \r and \t escapes sequences would ever be non-terminated).

Cheers,
Larry


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 18, 2014 4:17 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] [RFC] EDK II UNI Unicode File Specification

Larry -

The description of the extensions for modules/package abstracts/description are 
much better.

Here are a few comments which are not specific to your update (although they 
are contained in the text below)


1.   It is readable. I do think that adding <> terminals for single 
characters makes it harder to read, but otherwise the text is clear. Why not 
"/" instead of  and "(" instead of ?

2.   I don't think there is any UEFI spec requirement that a \endbold be 
preceded by a \bold. Since the font for any string may include the bold 
attribute, it may be that the \endbold might be desirable. This is further 
complicated by the fact the the .UNI specification doesn't not provide 
font-select capabilities.

3.   The current escape character mechanism prevents future expansion, 
because the escape sequences are neither fixed length nor well-delimited. 
Consider what would happen if someone wanted to add \bolder to the grammar. 
This would make older strings suspect, since it could be interpreted as "\bold" 
 and "er" or "\bolder" I mentioned this long ago.

Tim

From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Monday, August 18, 2014 3:54 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] [RFC] EDK II UNI Unicode File Specification

Hi Folks,

Here are the proposed changes to the EDK II UNI Unicode File Specification. 
Hopefully, HTML format for the chapters will be easier to review and respond 
with feedback.
Please provide feedback by the end of this week (22 Aug. 2014).


Updates:

*  Updated EBNF to follow syntax specified in EBNF by the ANTLR project

*  Added content related to EDK II Meta-Data Unicode files

*  Restructured document

*  Removed security and C format GUID definitions, not required for HII 
or other UNI files.

Cheers,
Larry
2
Unicode Strings File Format
EDK II Unicode files are used for mapping token names to localized strings that 
are identified by an RFC4646 language code. The format for storing EDK II 
Unicode files is UTF-16LE. The character content must be UCS-2.
Strings ends are determined by the first of the following items found:

* a control character

* a comment

* the end of the file

* a blank line
Comments may appear anywhere within the string file.
All the files must begin with a Unicode BOM character.

Note:Please make sure you select an editor that supports UCS-2 characters 
that can be stored in a UTF-16LE file.

2.1   2. 1 Common EBNF
The following EBNF uses quoted (double quotes) encapsulated characters to 
represent UCS-2 string literals. In the following definitions, the semi-colon 
is used to denote a comment.


::=  \u0020" "   ; Space Character

::=  \u0027   ; Forward Slash, /


::=  \u0028   ; Left Parenthesis, (

   

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

[Tim Lewis]

Larry -

The description of the extensions for modules/package abstracts/description are 
much better.

Here are a few comments which are not specific to your update (although they 
are contained in the text below)

1.   It is readable. I do think that adding <> terminals for single 
characters makes it harder to read, but otherwise the text is clear. Why not 
"/" instead of  and "(" instead of ?

2.   I don't think there is any UEFI spec requirement that a \endbold be 
preceded by a \bold. Since the font for any string may include the bold 
attribute, it may be that the \endbold might be desirable. This is further 
complicated by the fact the the .UNI specification doesn't not provide 
font-select capabilities.

3.   The current escape character mechanism prevents future expansion, 
because the escape sequences are neither fixed length nor well-delimited. 
Consider what would happen if someone wanted to add \bolder to the grammar. 
This would make older strings suspect, since it could be interpreted as "\bold" 
 and "er" or "\bolder" I mentioned this long ago.

Tim

From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Monday, August 18, 2014 3:54 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [RFC] EDK II UNI Unicode File Specification

Hi Folks,

Here are the proposed changes to the EDK II UNI Unicode File Specification. 
Hopefully, HTML format for the chapters will be easier to review and respond 
with feedback.
Please provide feedback by the end of this week (22 Aug. 2014).


Updates:

·  Updated EBNF to follow syntax specified in EBNF by the ANTLR project

·  Added content related to EDK II Meta-Data Unicode files

·  Restructured document

·  Removed security and C format GUID definitions, not required for HII 
or other UNI files.

Cheers,
Larry
2
Unicode Strings File Format
EDK II Unicode files are used for mapping token names to localized strings that 
are identified by an RFC4646 language code. The format for storing EDK II 
Unicode files is UTF-16LE. The character content must be UCS-2.
Strings ends are determined by the first of the following items found:

· a control character

· a comment

· the end of the file

· a blank line
Comments may appear anywhere within the string file.
All the files must begin with a Unicode BOM character.

Note:Please make sure you select an editor that supports UCS-2 characters 
that can be stored in a UTF-16LE file.

2.1   2. 1 Common EBNF
The following EBNF uses quoted (double quotes) encapsulated characters to 
represent UCS-2 string literals. In the following definitions, the semi-colon 
is used to denote a comment.


::=  \u0020   ; Space Character

::=  \u0027   ; Forward Slash, /


::=  \u0028   ; Left Parenthesis, (

::=  \u0029   ; Right Parenthesis, )

::=  {(\u0041-\u005A)} ; Characters A - Z
 {(\u0061-\u007A)} ; Characters a - z

 ::=  (\u0030-\u0039)   ; Characters 0 - 9

::=  \u005F; Underscore Character, _

::=  +

::=  {} {}

   ::=*  

 ::=  

 ::=  (\u0001-\uF6FF)



::=  (\u0020-\uF6FF)



::=  (\u0021-\uF6FF)



  ::=   

 [ [ ]+]+



  ::=   "language"   



 ::=  {}

 {(\u0041-\u0046)} ; Characters A - F

 {(\u0061-\u0066)} ; Characters a - f



  ::=  \u0023   ; Hash Character, #



 ::=   "string"  



::=   [{} {} {}]*



  ::=  



::=  (\u002D) ; Dash Character, -



   ::=  {2,8} [ *]



  ::=   [{} {}]{1,8}



   ::=   [{} {}]{1,}



 ::=  \u0022   ; Double Quote Character, "



::=   * 



  ::=  {} {} {}



::=   *

[]



::=   



  ::=  \u005C   ; Backslash Character, \



 ::=   "end" 



  ::=  {} {}



   ::=  {"narrow">} {"wide"}



 ::=  {"normal"} {"bold"} {"italic"}

 {"emboss"}

 {"shadow"} {"underline"} {"dblunder"}



  ::=   {"n"} {"f"} {"r"} {"p"}

 {"ospace"} {"enquad"} {"emquad"}

 {"ensp"} {"emsp"} {"em3sp"} {"em4sp"}

 {"em6sp"} {"usp"} {"tsp"} {"hsp"}

 {"msp"} {"!bsp"} {"!nbsp"}

 {"zsp"} {"ah"} { "hy"} { "df"} {"den"}

 {"dem"} {"!bh"} {"g"} {"osp"} {"k"}



   ::=  \u005D   ; Backslash Character, \





2.1.1  Definitions
LanguageCodes
The language code must be a valid RFC4646 language code.
EscChar
In 

[edk2] "key" usage with VFR

[Tim Lewis]

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


vfrStatementCheckBox ::=

  "checkbox"

  vfrQuestionHeader ","

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

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

  vfrStatementQuestionOptionList
"endcheckbox" ";"

And then a little further down it has this note:

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

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

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

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

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


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

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

[Tim Lewis]

Jaben -

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


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

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

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

a.   first, replace  with X (italics)

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

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

Tim


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

Tim,

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

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

-Jaben

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

Larry -

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

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

Tim



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

Hi Tim,

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

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

Cheers,
Larry

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

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

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

On the other topic, we would be willing to contribute change

[edk2] PEI_DEPEX and DXE_DEPEX in .INF files

[Tim Lewis]

In trying to build a PEI from binaries, we tried the following:

[Defines]
  INF_VERSION= 0x00010016
  BASE_NAME  = CommonPolicyPei
  FILE_GUID  = 4CD976FF-A41B-43d4-A3A7-D67872066F76
  MODULE_TYPE= PEIM
  VERSION_STRING = 1.0

[Packages]

[Binaries.IA32]
  PE32|Vlv2DeviceRefCodeBinPkg/Ia32/CommonPolicyPei.efi
  PEI_DEPEX|Vlv2DeviceRefCodeBinPkg/Ia32/CommonPolicyPei.depex

Notice that the PEI DEPEX is specified via binary, not the [Depex] section. In 
fact, if you can't do this, it seems like that supporting the PEI_DEPEX binary 
type is not useful.  Here is the section of the .INF spec that is causing 
issues:

[cid:image001.png@01CFB6E1.6DE0CE60]

I would suggest that this wording be changed to "Module types PEIM, DXE_DRIVER, 
DXE_RUNTIME_DRIVER, DXE_SAL_DRIVER and DXE_SMM_DRIVER require a [Depex] section 
unless the dependencies are specified by a PEI_DEPEX or DXE_DEPEX in the 
[Binaries] section."

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

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

[Tim Lewis]

Larry -

Yes, this looks a much better separation.  A couple of comments:


1)  I still think that the separation of two separate .uni files for one 
INF seems awkward.

2)  It uses some grammar terms, but the font isn't changed. Using the font 
would help clarify that you are referring to a grammar term.

3)  I think that reference to UPT as the consumer seems a bit exclusive. 
Rather, I'd simply say that this is a means of extending the abstract and 
description information normally found in the module header. It 
extends/replaces the information found in the Abstract, Description, Copyright 
and Licenses part of the @file header in the .INF specification (see. After 
this, you can describe how the UPT uses this information (see how 3.3 in the 
.INF spec words this).

4)  We still need the to add some Build spec descriptions of these "objects 
(Packages, Module) and "attributes" (Abstract, Description, Copyright, Licenses)

Tim

From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Wednesday, August 13, 2014 9:57 AM
To: Tim Lewis
Cc: edk2-devel@lists.sourceforge.net
Subject: RE: EDK II UNI Unicode File Specification Update

Hi Tim,
So if we try simplifying this with the UNI Unicode File spec, then is the 
following acceptable?
Cheers,
Larry

Update Definition of  in section 2.1 Extended Backus-Naur Form (EBNF)

::= (\ua-\uf\uA-\uF\u0-\u9)



::=   L"string" 

   (\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*



   ::= (\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*



::= 


Add the following chapter.
3
Meta-Data UNI Files
In order to support distributions conforming to the UEFI PI Distribution 
Package Specification, Unicode files may be used to contain localization 
content passed along in the XML file for content that cannot be passed using 
ASCII characters.
The format of the Unicode files that contain the optional Module and Package 
localization content for distribution is as follows:

 ::= *

   +



 ::= {} {} {}


Additional Definitions used for Package Meta-Data Token Identifiers

 ::= (\u0-\u9\ua-\uf\uA-\uF)



 ::=  L"_" 



   ::= (\uA-\uZ\ua-\uz)(\uA-\uZ\ua-\uz\u0-\u9)*


Refer to Chapter 2.1, Unicode Strings File Format, Extended Backus-Naur Form 
(EBNF) for the definitions of CommentLine, BlankLine and UnicodeLines.
It is also recommended that the comment section at the start of the file use 
content consistent with content described for meta-data headers, including a 
start tag line, L"// @file", and include an abstract, description, copyright 
and license information.
3.1 Module Meta-Data
If a Module's INF file contains a MODULE_UNI_FILE entry in its [Defines] 
section, then that Unicode file may contain localization of the Module's 
Abstract and Description lines.
The Intel UEFI Packaging Tool, UPT, provided as part of the EDK II BaseTools 
will use following identifiers in the UnicodeLines' Token element to pass along 
localization of the Module's Abstract and Description. This file is created 
from the UEFI PI Distribution Package XML content by the Intel UEFI Packaging 
Tool during installation, and will be read from the file into the UEFI PI 
Distribution Package XML when creating a distribution.

L"STR_MODULE_ABSTRACT"

L"STR_MODULE_DESCRIPTION"

If a Module's INF file contains a Unicode file entry in its 
[UserExtensions.TianoCore."ExtraFiles"] section, then that Unicode file may 
contain a localized version of a User Interface name for the module as well as 
other content. This file is used to hold content that is not required by UEFI 
PI Distribution Package, but may be useful for User Interface tools. The 
following identifier may be used in the UnicodeLines' Token element to pass 
along the User Interface name of the module.

L"STR_PRORPERTIES_MODULE_NAME"
Other content may be provided in this file as the file itself will be carried 
along with the Module in a UEFI PI Distribution Package.
3.1 Package Meta-Data
If a Package's DEC file contains a PACKAGE_UNI_FILE entry in its [Defines] 
section, then that Unicode file may contain localization of the Package's 
Abstract and Description line as well as information used for PCD declarations. 
This file is created from the UEFI PI Distribution Package XML content by the 
Intel UEFI Packaging Tool during installation, and will be read from the file 
into the UEFI PI Distribution Package XML when creating a distribution.
The following identifiers are used in the UnicodeLines' Token element to pass 
along localization of the Package's Abstract and Description.

L"STR_PACKAGE_ABSTRACT"

L"STR_PACKAGE_DESCRIPTION"


The following describes the format for an identifier used in the UnicodeLines' 
Token element to pass along localization of a TokenSpaceGuid's Error messages 
that are refere

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

[Tim Lewis]

Larry -

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

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

Tim



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

Hi Tim,

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

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

Cheers,
Larry

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

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

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

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

Tim

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

Hi Tim,

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

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

Thanks,

Mike

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

Larry -

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

Tim

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

Hi Folks,
The following is content we would like to add to the EDK II UNI Unicode File 
Specification to support the changes  we have proposed for supporting 
localization in EDK II that can be consumed by the packaging to when creating a 
UEFI PI Distribution Package (and when installing a UEFI PI Distribution 
Package using the EDK II upt tool).
Please respond with feedback the end of this week.
Thanks,
Larry

3
UNI File Common Content
This section defines the common tag syntax for content in a Unicode file 
specified in the following Module and Package UNI sections.

Prototype

  ::= L" "



  ::

Re: [edk2] Removal of DEBUG_CODE in RELEASE Builds

[Tim Lewis]

Alexei -

I'm not sure about GCC, but in Visual Studio 2013 with LTCG turned on, the 
binary code will not appear in the output file because link-time code 
generation detects the cross-module optimization and removes the code correctly.

Tim

From: Alexei Fedorov [mailto:alexei.fedo...@arm.com]
Sent: Tuesday, August 12, 2014 7:59 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Removal of DEBUG_CODE in RELEASE Builds

Hi All,

The description of DEBUG_CODE_BEGIN() and DEBUG_CODE_END() macros in 
edk2\MdePkg\Include\Library\DebugLib.h reads:

/**
  Macro that marks the beginning of debug source code.
  If the DEBUG_PROPERTY_DEBUG_CODE_ENABLED bit of PcdDebugProperyMask is set,
  then this macro marks the beginning of source code that is included in a 
module.
  Otherwise, the source lines between DEBUG_CODE_BEGIN() and DEBUG_CODE_END()
  are not included in a module.
**/
#define DEBUG_CODE_BEGIN()  do { if (DebugCodeEnabled ()) { UINT8  
__DebugCodeLocal

Actually this is not correct because code between DEBUG_CODE_BEGIN() / 
DEBUG_CODE_END() is still being compiled & present in the output binary code 
for RELEASE builds with DEBUG_PROPERTY_DEBUG_CODE_ENABLED bit not set in 
PcdDebugProperyMask.
This is because in BaseDebugLibNull library DebugCodeEnabled () is still a 
run-time function call, see
edk2_new\edk2\MdePkg\Library\BaseDebugLibNull\DebugLib.c:

BOOLEAN
EFIAPI
DebugCodeEnabled (
  VOID
  )
{
  return FALSE;
}

As a workaround DebugCodeEnabled() function can be replaced with a similar 
macro definition as in
edk2\EdkCompatibilityPkg\Foundation\Library\EdkIIGlueLib\Include\Library\EdkIIGlueDebugLib.h:
//
// Use the following 4 macros to save size
//
#define DebugCodeEnabled()
((BOOLEAN)((__EDKII_GLUE_PCD_PcdDebugPropertyMask__ & 
DEBUG_PROPERTY_DEBUG_CODE_ENABLED) != 0))

like:

#define DebugCodeEnabled()   ((_PCD_VALUE_PcdDebugPropertyMask__ & 
DEBUG_PROPERTY_DEBUG_CODE_ENABLED) != 0)

& removal of DebugCodeEnabled () declaration from 
\BaseDebugLibSerialPort\DebugLib.c & BaseDebugLibNull\DebugLib.c.

gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask should added in [FixedPcd] 
section of modules' .INF files which use DEBUG_CODE_BEGIN() / DEBUG_CODE_END() 
in their sources.

Can anyone comment on that?

Thanks.
Alexei.




-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Tim Lewis]

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

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

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

Tim

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

Hi Tim,

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

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

Thanks,

Mike

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

Larry -

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

Tim

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

Hi Folks,
The following is content we would like to add to the EDK II UNI Unicode File 
Specification to support the changes  we have proposed for supporting 
localization in EDK II that can be consumed by the packaging to when creating a 
UEFI PI Distribution Package (and when installing a UEFI PI Distribution 
Package using the EDK II upt tool).
Please respond with feedback the end of this week.
Thanks,
Larry

3
UNI File Common Content
This section defines the common tag syntax for content in a Unicode file 
specified in the following Module and Package UNI sections.

Prototype

  ::= L" "



  ::= +



  ::= {} {}



  ::= 0x000D



  ::= 0x000A



 ::= 



   ::= 



  ::= (0x0020-0xF6FF)


::= 

 ::= (\ua-\uz\uA-\uZ){2,8}
  [L"-" (\ua-\uz\uA-\uZ\u0-\u9){2,8}]

   ::= 0x0022

  ::=  * 



  ::= L"// /** @file" 

  [ ]?

  [L"//" ]+

  [ ]*

  [L"//" ]

  [ ]+

  [L"//" ]*

  [ ]+

  [L"//" ]*

  L"// **/" +



::= L"//"  +



 ::= L"//"  +



   ::= L"//"  "Copyright (c)"  



::= {} {} {} L","  



::= (\u2-\u9) (\u0-\u9){3}



   ::=   L"-"  



::=  [","  ]+



::= * L"."  L"All rights reserved."



 ::= L"//"  *


   ::= L"#language"   
  [ ]+






4
MODULE_UNI_FILE Content
This section defines the tag syntax for content in a Unicode file specified in 
the MODULE_UNI_FILE entry of an INF file's [Defines] section.

Prototype

 ::= 

 *

 ?

 *

 ?

 *





::= L"#string"  L"STR_MODULE_ABSTRACT" 

 +



 ::= L"#string"  L"STR_MODULE_DESCRIPTION" 

 +




Example

// /** @file

// TerminalDxe Module Localized Abstract and Description Content

//

// Copyright (c) 2012 - 2014, Intel Corporation. All rights reserved.

//

// This program and the accompanying materials

// are licensed and made available under the terms and conditions of the BSD

// License which accompanies this distribution.

// The full text of the license may be found at

// http://opensource.org/licenses/bsd-license.php

// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,

// WITHOUT WARRANTIES OR REPRESENTATIO

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

[Tim Lewis]

Larry -

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

Tim

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

Hi Folks,
The following is content we would like to add to the EDK II UNI Unicode File 
Specification to support the changes  we have proposed for supporting 
localization in EDK II that can be consumed by the packaging to when creating a 
UEFI PI Distribution Package (and when installing a UEFI PI Distribution 
Package using the EDK II upt tool).
Please respond with feedback the end of this week.
Thanks,
Larry

3
UNI File Common Content
This section defines the common tag syntax for content in a Unicode file 
specified in the following Module and Package UNI sections.

Prototype

  ::= L" "



  ::= +



  ::= {} {}



  ::= 0x000D



  ::= 0x000A



 ::= 



   ::= 



  ::= (0x0020-0xF6FF)


::= 

 ::= (\ua-\uz\uA-\uZ){2,8}
  [L"-" (\ua-\uz\uA-\uZ\u0-\u9){2,8}]

   ::= 0x0022

  ::=  * 



  ::= L"// /** @file" 

  [ ]?

  [L"//" ]+

  [ ]*

  [L"//" ]

  [ ]+

  [L"//" ]*

  [ ]+

  [L"//" ]*

  L"// **/" +



::= L"//"  +



 ::= L"//"  +



   ::= L"//"  "Copyright (c)"  



::= {} {} {} L","  



::= (\u2-\u9) (\u0-\u9){3}



   ::=   L"-"  



::=  [","  ]+



::= * L"."  L"All rights reserved."



 ::= L"//"  *


   ::= L"#language"   
  [ ]+






4
MODULE_UNI_FILE Content
This section defines the tag syntax for content in a Unicode file specified in 
the MODULE_UNI_FILE entry of an INF file's [Defines] section.

Prototype

 ::= 

 *

 ?

 *

 ?

 *





::= L"#string"  L"STR_MODULE_ABSTRACT" 

 +



 ::= L"#string"  L"STR_MODULE_DESCRIPTION" 

 +




Example

// /** @file

// TerminalDxe Module Localized Abstract and Description Content

//

// Copyright (c) 2012 - 2014, Intel Corporation. All rights reserved.

//

// This program and the accompanying materials

// are licensed and made available under the terms and conditions of the BSD

// License which accompanies this distribution.

// The full text of the license may be found at

// http://opensource.org/licenses/bsd-license.php

// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,

// WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.

//

// **/





#string STR_MODULE_ABSTRACT

#language en-US

"Terminal module installs Simple Text Input(ex)/Out protocols for serial "

"devices."



#string STR_MODULE_DESCRIPTION #language en-US

"This module will install Simple Text Input (Ex) protocol and Simple Test "

"Output protocols based on Serial I/O protocol for serial devices including "

"hotplug serial devices."


5
Module Extra File Content
This section defines the tag syntax for content in a Unicode file specified in 
an extra file specified in a [UserExtensions.TianoCore."ExtraFiles"] section of 
an INF file.

Prototype

  ::= 

  *

  ?

  *



::= L"#string" 

  L"STR_PROPERTIES_MODULE_NAME" 

  +




Example

// /** @file

// TerminalDxe Localized Strings and Content

//

// Copyright (c) 2013, Intel Corporation. All rights reserved.

//

// This program and the accompanying materials

// are licensed and made available under the terms and conditions of

// the BSD License which accompanies this distribution. The full text

// of the license may be found at

// http://opensource.org/licenses/bsd-license.php

// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"

// BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER

// EXPRESS OR IMPLIED.

//

// **/



#string STR_PROPERTIES_MODULE_NAME

#language en-US

"Terminal DXE Driver"

6
PACKAGE_UNI_FILE Content
This section defines the tag syntax for content in a Unicode file specified in 
the PACKAGE_UNI_FILE entry of a DEC file's [Defines] section.

Prototype

  ::= 

  *

  ?

  *

  ?

  *

  *

  *

  *

  *

  *

  *



 ::= L"#string" 

  L"STR_PACKAGE_ABSTRACT" 

  +



  ::= L"#str

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

[Tim Lewis]

DEC have an RFC 
1766 language code of en-US.  If the same string is also declared in a UNI file 
with the same language code of en-US, then there is a potential conflict.  We 
prefer that content that a developer chose to put into the INF/DEC/UNI files 
are preserved across the XML translations.  Our proposal is to store both 
versions of the en-US strings in XML.  This is accomplished by introducing an 
extended language code following the format defined by RFC 1766  of 
en-x-tianocore.  This language code is used to store the INF/DEC strings that 
potentially conflict with UNI file string so the XML carries both of them.  
When converting from XML back to INF/DEC, the INF/DEC file will get the strings 
contents from the en-x-tianocor strings if they are present, and en-US strings 
if en-x-tianocore strings are not present.  When converting from XML to UNI, 
the strings with the extended language code of en-x-tianocore are ignored, so 
the original UNI file contents are preserved.

Best regards,

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 08, 2014 1:44 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Mike -

Can you show how the module abstract could be encoded purely in the .inf? I can 
see how PCDs work.  Are you saying these .uni strings would replace that which 
appears in the .inf header?

Tim



From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Friday, August 08, 2014 1:34 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Tim,

I think we are in agreement here.  Detailed responses embedded below in [Mike]. 
 I have provided more details on proposed syntax below along with some sample 
UNI file content.  The EDK II specifications require updates to define the 
string token naming conventions for the UNI files associated with Packages and 
Modules.

Thanks,

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 08, 2014 11:58 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Mike -

Let me propose an alternative which simplifies the 99% of module development: 
put the strings that you want in the .dec/.inf file directly with an option to 
extend it through .uni files.

[Mike] I agree with your proposal.  Strings can be put in ASCII formatted DEC 
files using @Prompt.  The UNI files being proposed here are always optional.  
The EDK II Package Declaration (DEC) File Format Specification 1.22 Errata C 
Section 3.10 posted under the EDK II project on tianocore.org defines syntax 
for tags associated with PCDs for @Prompt, @ValidRange, @ValidList, 
@Expression.  We want to maximize the use of these tags.  The UNI files provide 
a method to carry strings that cannot be encoded in ASCII.  We are providing 
the UNI file too for these patches, so the strings can be translated to other 
languages as needed.

You already mentioned @Prompt (which, by the way, might have been better than 
UserDefined and made it more consistent) There are hundreds of files that 
follow the existing meta-data format as defined in the .dec spec. I can already 
provide non-localized content there and any use of these .uni files will have 
to find some way to attach to the related PCD through naming convention. In 
order to support existing files, your tools will already need to process this 
information. So you will always have a mix of meta-data descriptive text IN the 
.inf/.dec and out of the .inf/.dec because of this. You can give the .uni file 
priority where there is an overlap in order to allow vendors with 
multi-language meta-data display tools support it.

[Mike] I agree.  If a string for same language is present in both INF/DEC and 
UNI file, the UNI file should have higher priority.

Separating the .uni files defeats some of your re-use arguments below. Make it 
easier on the developer. Make the tools do the heavy lifting. Solve the problem 
rather than passing it on.

[Mike] Each developer for a package/module can decide what content they 
provide.  If they only want to do ASCII English strings, then those can be 
provided in INF/DEC with no UNI file.  If they want to provide more than just 
English, then a UNI file can be provided.   It is also possible for tools to 
extract strings from INF/DEC and generate a UNI file with English strings for 
translations services.  Many options here and developers can opt-in to levels 
of support.

Speaking of naming and content conventions:


1)   There is no mention of what will be done with font-related 
information. Will bold escape characters work? While EDK2 has never really 
supported these, you might consider explicitly limiting to no font-information 
or ???

[Mike] You are correct that the EDK II ASCII/UNI meta-da

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

[Tim Lewis]

Mike -

Can you show how the module abstract could be encoded purely in the .inf? I can 
see how PCDs work.  Are you saying these .uni strings would replace that which 
appears in the .inf header?

Tim



From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Friday, August 08, 2014 1:34 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Tim,

I think we are in agreement here.  Detailed responses embedded below in [Mike]. 
 I have provided more details on proposed syntax below along with some sample 
UNI file content.  The EDK II specifications require updates to define the 
string token naming conventions for the UNI files associated with Packages and 
Modules.

Thanks,

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 08, 2014 11:58 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Mike -

Let me propose an alternative which simplifies the 99% of module development: 
put the strings that you want in the .dec/.inf file directly with an option to 
extend it through .uni files.

[Mike] I agree with your proposal.  Strings can be put in ASCII formatted DEC 
files using @Prompt.  The UNI files being proposed here are always optional.  
The EDK II Package Declaration (DEC) File Format Specification 1.22 Errata C 
Section 3.10 posted under the EDK II project on tianocore.org defines syntax 
for tags associated with PCDs for @Prompt, @ValidRange, @ValidList, 
@Expression.  We want to maximize the use of these tags.  The UNI files provide 
a method to carry strings that cannot be encoded in ASCII.  We are providing 
the UNI file too for these patches, so the strings can be translated to other 
languages as needed.

You already mentioned @Prompt (which, by the way, might have been better than 
UserDefined and made it more consistent) There are hundreds of files that 
follow the existing meta-data format as defined in the .dec spec. I can already 
provide non-localized content there and any use of these .uni files will have 
to find some way to attach to the related PCD through naming convention. In 
order to support existing files, your tools will already need to process this 
information. So you will always have a mix of meta-data descriptive text IN the 
.inf/.dec and out of the .inf/.dec because of this. You can give the .uni file 
priority where there is an overlap in order to allow vendors with 
multi-language meta-data display tools support it.

[Mike] I agree.  If a string for same language is present in both INF/DEC and 
UNI file, the UNI file should have higher priority.

Separating the .uni files defeats some of your re-use arguments below. Make it 
easier on the developer. Make the tools do the heavy lifting. Solve the problem 
rather than passing it on.

[Mike] Each developer for a package/module can decide what content they 
provide.  If they only want to do ASCII English strings, then those can be 
provided in INF/DEC with no UNI file.  If they want to provide more than just 
English, then a UNI file can be provided.   It is also possible for tools to 
extract strings from INF/DEC and generate a UNI file with English strings for 
translations services.  Many options here and developers can opt-in to levels 
of support.

Speaking of naming and content conventions:


1)   There is no mention of what will be done with font-related 
information. Will bold escape characters work? While EDK2 has never really 
supported these, you might consider explicitly limiting to no font-information 
or ???

[Mike] You are correct that the EDK II ASCII/UNI meta-data formats for strings 
do not provide font information today.  If you think this is a gap or a 
valuable addition to the EDK II, then please provide some proposals.


2)  You mention @Prompt related .uni, but Larry's update does not give the 
contents of these files. Let's be explicit about this up-front and say that 
strings in these files must have the name X_Y_Z in order to be correctly 
associated with some specific meaning.

[Mike] Here is some sample content for MdePkg.dec and its optionally associated 
MdePkg.uni file.  A UNI file can be optionally declared in PACKAGE_UNI_FILE 
listed in [Defines] section of DEC file.  In the UNI file, the string token 
names of STR_PACKAGE_ABSTACT and STR_PACKAGE_DESCRIPTION are used to store 
additional localized strings in the UDP XML package header.  In the DEC file 
for a PCD, the comment block contents without @ tags are the detailed help text 
that can be converted to additional UDP PCD HelpText XML.  The DEC file 
contents with @ tags in the PCD comment block are also converted to associated 
XML sections.  In the UNI file, the string token name formats of 
STR___PROMPT and 
STR___HELP are used to store additional 
localized strings in the UDP XML for PCDs.  The string token name format of 
STR__ERR_ is used to 

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

[Tim Lewis]

Mike -

Let me propose an alternative which simplifies the 99% of module development: 
put the strings that you want in the .dec/.inf file directly with an option to 
extend it through .uni files.

You already mentioned @Prompt (which, by the way, might have been better than 
UserDefined and made it more consistent) There are hundreds of files that 
follow the existing meta-data format as defined in the .dec spec. I can already 
provide non-localized content there and any use of these .uni files will have 
to find some way to attach to the related PCD through naming convention. In 
order to support existing files, your tools will already need to process this 
information. So you will always have a mix of meta-data descriptive text IN the 
.inf/.dec and out of the .inf/.dec because of this. You can give the .uni file 
priority where there is an overlap in order to allow vendors with 
multi-language meta-data display tools support it.

Separating the .uni files defeats some of your re-use arguments below. Make it 
easier on the developer. Make the tools do the heavy lifting. Solve the problem 
rather than passing it on.

Speaking of naming and content conventions:


1)  There is no mention of what will be done with font-related information. 
Will bold escape characters work? While EDK2 has never really supported these, 
you might consider explicitly limiting to no font-information or ???

2)  You mention @Prompt related .uni, but Larry's update does not give the 
contents of these files. Let's be explicit about this up-front and say that 
strings in these files must have the name X_Y_Z in order to be correctly 
associated with some specific meaning.

Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Friday, August 08, 2014 11:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Tim,

I agree that UTF-8 formatted files can support localized string, but INF/DEC 
files are current defined to be ASCII.

We are attempting to find a balance that works for both developers and tools.

We are re-using the .UNI file format on purpose so developers who are already 
using .UNI files will not have to learn a new method to implement localizes 
strings.  This reduces the number of file formats for the same type of content. 
 Also, the PCD related information such as PROMPT, HELP, and ERROR messages can 
be captured in a .UNI file associated with a DEC file, and that content can be 
reused in HII content "as is" for PCDs that may be mapped to HII string packs 
associated with HII setup questions.  This reduces translations between 
different file formats.

Also, translation services for localized strings may already support .UNI files 
associated with HII, and those services will not have to be updated to support 
more file formats if we simple reuse .UNI file format.

Thanks,

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 08, 2014 10:47 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Mike -

Perhaps developer complexity should be the metric used for these choices, not 
tool complexity. Tool complexity is dealt with once, developer complexity is an 
on-going effort.

It is not clear why .uni files are used at all. These are not consumed by 
drivers, are they? Nor are they installed in the HII database. This overrides 
the .uni purpose and definition without giving the convenience of even 
combining them together. Why not just add it to the [UserDefined] section of 
the .dec directly? UTF-8 can handle the  language text necessary, and is not 
difficult to add to current processing tools. This essentially requires 
packages to go from 1 to 2 files and modules to go from 1 to 2 (I know they are 
 optional, but we are talking about "well-constructed")

Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Friday, August 08, 2014 10:33 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Felix,

This is a very good question.

The UEFI Distribution Packaging Specification 1.0 (Errata B) available from 
uefi.org and its associated XML schema has support to store localized Abstract 
and localized Description.  However, there is no XML schema support to store 
the localized Module Name.  We think it may be a good idea to separate the 
content that is formally supported by the XML schema from the content that is 
not formally supported by the XML schema, so the UPT tool that converts EDK II 
Meta-Data files to XML and from XML back to EDK II Meta-Data files will be 
straight forward.  We were very concerned about the complexity of the UPT tool 
if there was a single EDK II UNI file that contains some strings that would be 
translated into XML and other strings that needed to be packaged

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

[Tim Lewis]

Mike -

Perhaps developer complexity should be the metric used for these choices, not 
tool complexity. Tool complexity is dealt with once, developer complexity is an 
on-going effort.

It is not clear why .uni files are used at all. These are not consumed by 
drivers, are they? Nor are they installed in the HII database. This overrides 
the .uni purpose and definition without giving the convenience of even 
combining them together. Why not just add it to the [UserDefined] section of 
the .dec directly? UTF-8 can handle the  language text necessary, and is not 
difficult to add to current processing tools. This essentially requires 
packages to go from 1 to 2 files and modules to go from 1 to 2 (I know they are 
 optional, but we are talking about "well-constructed")

Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Friday, August 08, 2014 10:33 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Felix,

This is a very good question.

The UEFI Distribution Packaging Specification 1.0 (Errata B) available from 
uefi.org and its associated XML schema has support to store localized Abstract 
and localized Description.  However, there is no XML schema support to store 
the localized Module Name.  We think it may be a good idea to separate the 
content that is formally supported by the XML schema from the content that is 
not formally supported by the XML schema, so the UPT tool that converts EDK II 
Meta-Data files to XML and from XML back to EDK II Meta-Data files will be 
straight forward.  We were very concerned about the complexity of the UPT tool 
if there was a single EDK II UNI file that contains some strings that would be 
translated into XML and other strings that needed to be packaged up as pass 
through.  Then during package installation UTP would have to generate some UNI 
strings from XML and mix those back together with the pass through content.

Thanks,

Mike


From: Felix Poludov [mailto:fel...@ami.com]
Sent: Thursday, August 07, 2014 8:57 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Mike,

Why localized module name and localized module abstract/description  are in two 
separate UNI files?

Thanks
Felix

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, August 06, 2014 9:22 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Tim,

I should have put it in the original email.  The spec changes will be shared 
too.  We welcome review comments on all spec changes and patches.

Thanks,

Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 06, 2014 2:58 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] INF/DEC file updates to EDK II packages

Mike --

Since there are dozens of tools in the industry that consume these files, don't 
you think it's better to put the specification changes out where the consumers 
can read, evaluate and comment on them? I realize that "UserDefined" sections 
should be skipped by tools (agreed) but that doesn't mean that other module 
creators might have made similar or related extensions or want to understand 
how these changes play into their tools.

Regards,

Tim

From: Kinney, Michael D [michael.d.kin...@intel.com]
Sent: Wednesday, August 06, 2014 2:31 PM
To: edk2-devel@lists.sourceforge.net<mailto: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 -> I

[edk2] VfrCompiler error

[Tim Lewis]

Never mind. Noticed that this was fixed in r2667 in the Build Tools repository. 
The comment did not mention the symptoms.

Tim
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] VfrCompiler.exe uninitialized variable causes random failures

[Tim Lewis]

Folks, the function VfrCompiler::VfrCompiler() has a bug related to 
uninitialized variables. This shows up (in my experience) mostly under Linux 
systems.

Below is the constructor for the compiler class. Please note that the 
IS_RUN_STATUS member function is called before SET_RUN_STATUS member function.

mRunStatus is a member variable of the CVfrCompiler class but is not 
initialized before this point.

This typically shows up as the following error message (much later)

"VfrCompile" -l -n --output-directory dir FrontPageVfr.ii
VfrCompile: ERROR 0003: Error parsing
  compile error in file (null)

Since you may not want to set mRunStatus to STATUS_INITIALIZED so early in the 
constructor, it would require another status value to be created and used prior 
to calling OptionInitialization()

Thanks,

Tim


CVfrCompiler::CVfrCompiler (
  IN INT32  Argc,
  IN CHAR8  **Argv
  )
{
  mPreProcessCmd = (CHAR8 *) PREPROCESSOR_COMMAND;
  mPreProcessOpt = (CHAR8 *) PREPROCESSOR_OPTIONS;

  OptionInitialization(Argc, Argv);

  if ((IS_RUN_STATUS(STATUS_FAILED)) || (IS_RUN_STATUS(STATUS_DEAD))) {
return;
  }

  SET_RUN_STATUS(STATUS_INITIALIZED);
}
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Tim Lewis]

Mike --

Since there are dozens of tools in the industry that consume these files, don't 
you think its better to put the specification changes out where the consumers 
can read, evaluate and comment on them? I realize that "UserDefined" sections 
should be skipped by tools (agreed) but that doesn't mean that other module 
creators might have made similar or related extensions or want to understand 
how these changes play into their tools.

Regards,

Tim

From: Kinney, Michael D [michael.d.kin...@intel.com]
Sent: Wednesday, August 06, 2014 2:31 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Patches for the following EDK II packages are being prepared

1)  MdePkg

2)  MdeModulePkg

3)  IntelFrameworkPkg

4)  IntelFrameworkModulePkg

5)  FatPkg

6)  ShellPkg

7)  PcAtChipsetPkg

8)  UefiCpuPkg

9)  SourceLevelDebugPkg

10)   CryptoPkg

11)   SecurityPkg

12)   NetworkPkg

Best regards,

Mike

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy

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

[Tim Lewis]

Mike --

I am also curious why this EDK2 behavior is being put into a "UserDefined" 
section at all, since the file format is owned by the specifications on this 
web site.  why not just create a new [PackageInfo] section and update the 
revision level?

Are the contents of the new .UNI files and their tags also in a specification 
somewhere? Is there a description as to where this corresponds with items in 
the packaging specification?

Thanks,

Tim

From: Kinney, Michael D [michael.d.kin...@intel.com]
Sent: Wednesday, August 06, 2014 2:31 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Patches for the following EDK II packages are being prepared

1)  MdePkg

2)  MdeModulePkg

3)  IntelFrameworkPkg

4)  IntelFrameworkModulePkg

5)  FatPkg

6)  ShellPkg

7)  PcAtChipsetPkg

8)  UefiCpuPkg

9)  SourceLevelDebugPkg

10)   CryptoPkg

11)   SecurityPkg

12)   NetworkPkg

Best regards,

Mike

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy app

[edk2] VFR Expression Grammar Issues

[Tim Lewis]

The current VFR Grammar, as expressed in section 2.12 of the VFR specification, 
does not seem to be viable. Take the following piece: 2.12.1:

[cid:image001.png@01CFA5C4.78ADC1A0]

But imagine the following grammar:

5 OR 3 OR 2

This will go andTerm (returning 5) then "OR" but then it will have andTerm 
again, so the 2nd "OR" will not ever be processed.

I believe that this should be:

andTerm ( "OR" vfrStatementExpression)

Likewise, each of the following sections (2.12.2 and following), seems to 
suffer from the same issue.

Tim
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] "orderedlist" grammar inconsistency

[Tim Lewis]

The "flags" "=" portion of the VFR grammar currently does not allow a "," after 
it, which is different from all of the other questions. It should, at least, 
allow it to make it consistent with the other questions.

Tim
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] "option" statement

[Tim Lewis]

Thank you, Eric. Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, July 14, 2014 7:55 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] "option" statement

Tim,

Add my comments below.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, July 14, 2014 10:49 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] "option" statement

The option statement has the following flags:


oneofoptionFlagsField ::=

Number

| "OPTION_DEFAULT"

| "OPTION_DEFAULT_MFG"

| "INTERACTIVE"

| "RESET_REQUIRED"
| "DEFAULT"

But it is not clear what the "INTERACTIVE" and "RESET_REQUIRED" flags should 
do. Are they OR'd together and put in the parent question?
[[[Eric]]] yes, these two flags will be put in the parent question.

There are many other flags in the grammar that are undocumented. For example: 
LATE_CHECK or NV_ACCESS. These flags values are also not defined in the UEFI 
specification. Is there any further definition or are these from the older 
Framework spec? If they are from the Framework spec, is there some way to add 
error checking so that they can be excluded?
[[[Eric]]] Yes. LATE_CHECK or NV_ACCESS are for old framework HII. They are 
kept here for compatible with old VFR file, I will add check for these flags 
used for old framework HII and report warning info for it.

oneofoptionFlagsField [UINT8 & HFlags, UINT8 & LFlags] :
N:Number   << $LFlags |= 
_STOU8(N->getText(), N->getLine()); >>
  | "OPTION_DEFAULT"   << $LFlags |= 0x10; >>
  | "OPTION_DEFAULT_MFG"   << $LFlags |= 0x20; >>
  | InteractiveFlag<< $HFlags |= 0x04; >>
  | NVAccessFlag   << $HFlags |= 0x08; >>
  | ResetRequiredFlag  << $HFlags |= 0x10; >>
  | LateCheckFlag  << $HFlags |= 0x20; >>
  | ManufacturingFlag  << $LFlags |= 0x20; >>
  | DefaultFlag<< $LFlags |= 0x10; >>
  ;

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] "option" statement

[Tim Lewis]

The option statement has the following flags:


oneofoptionFlagsField ::=

Number

| "OPTION_DEFAULT"

| "OPTION_DEFAULT_MFG"

| "INTERACTIVE"

| "RESET_REQUIRED"
| "DEFAULT"

But it is not clear what the "INTERACTIVE" and "RESET_REQUIRED" flags should 
do. Are they OR'd together and put in the parent question?

There are many other flags in the grammar that are undocumented. For example: 
LATE_CHECK or NV_ACCESS. These flags values are also not defined in the UEFI 
specification. Is there any further definition or are these from the older 
Framework spec? If they are from the Framework spec, is there some way to add 
error checking so that they can be excluded?

oneofoptionFlagsField [UINT8 & HFlags, UINT8 & LFlags] :
N:Number   << $LFlags |= 
_STOU8(N->getText(), N->getLine()); >>
  | "OPTION_DEFAULT"   << $LFlags |= 0x10; >>
  | "OPTION_DEFAULT_MFG"   << $LFlags |= 0x20; >>
  | InteractiveFlag<< $HFlags |= 0x04; >>
  | NVAccessFlag   << $HFlags |= 0x08; >>
  | ResetRequiredFlag  << $HFlags |= 0x10; >>
  | LateCheckFlag  << $HFlags |= 0x20; >>
  | ManufacturingFlag  << $LFlags |= 0x20; >>
  | DefaultFlag<< $LFlags |= 0x10; >>
  ;

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Vfr.vfr Question with Regard to "text"

[Tim Lewis]

In DriverSampleDxe's vfr.vfr, there is the following text statement:

text
  help   = STRING_TOKEN(0x0053),
  text   = STRING_TOKEN(0x0053),
text   = STRING_TOKEN(0x0053),
  flags  = INTERACTIVE,
  key= 0x1237;

Notice that (a) this has the INTERACTIVE flag set (making it an ACTION opcode) 
but (b) it also has a 2nd "text" statement.

As far as I can tell, this should be illegal. Here is the corresponding 
statement in VfrSyntax.g:

CIfrAction AObj;

mCVfrQuestionDB.RegisterQuestion (NULL, NULL, QId);
AObj.SetLineNo 
(F->getLine());
AObj.SetQuestionId 
(QId);
AObj.SetPrompt 
(_STOSID(S2->getText()));
AObj.SetHelp 
(_STOSID(S1->getText()));

_PCATCH(AObj.SetFlags (Flags), F->getLine());
AssignQuestionKey 
(AObj, KN);
CRT_END_OP (KN);

You can see the basic question header being created but there is no reference 
to the 2nd text. Here, on the other hand, is the code for the EFI_IFR_TEXT, 
which does use the 2nd text item.

CIfrText TObj;
TObj.SetLineNo 
(T->getLine());
TObj.SetHelp 
(_STOSID(S1->getText()));
TObj.SetPrompt 
(_STOSID(S2->getText()));
TObj.SetTextTwo 
(TxtTwo);

In my opinion, the 2nd text item should generate an error with VfrCompile, 
because it will not and cannot ever be used for a "text" statement that has the 
INTERACTIVE flag set.

Tim

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Is it just me or is tianocore.org completely missing the useful front page?

[Tim Lewis]

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] NON_FFS_FILE Not Supported

[Tim Lewis]

Just as a follow on to my previous question about binary-only module 
deliverables for EDK2.


1.   The current FDF specification (1.22d) incorrectly states that there is 
an option NON_FFS_FILE (see  which is, in fact, not supported and, even 
if it were supported, would be pretty useless since it uses Options2 which 
makes it basically the same as RAW or FREEFORM, as far as I can tell. I think 
this was originally intended for use with OEM-defined file types but does not 
give the option for either an OEM file type (or GUID, if it will construct the 
extended header entry for the OEM file type).

2.   If you could add a FFS file (product of the build tools) directly to 
the FV, an unintended side effect is that Dynamic/DynamicEx PCDs will not get 
placed into the PCD database, because the PCD database is constructed based on 
INF content references (in the [Pcd] sections) and FDF files don't give such 
references. Of course, I can add these manually in an INF file, but I haven't 
found a good automated way to use a FDF-centric build solution for this.

Tim
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] How to include a .FFS file directly into an .FV

[Tim Lewis]

You can't do it from .fdf? Tim

From: Lin, Jie [mailto:jie@intel.com]
Sent: Wednesday, June 11, 2014 10:23 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] How to include a .FFS file directly into an .FV

Tim,
You need a tool to add FFS into FV. Intel Tiano team has 
developed a tool called FMMT that could meet your need.

Cheers!
Auber

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, June 12, 2014 5:50 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] How to include a .FFS file directly into an .FV

Andrew. Yes. I'm trying to put an already-formed FFS file, complete with 
header, file type, etc. I could use SECTION or I could create an INF, but I'd 
rather do neither and just use the FFS. Hmmm...

Tim

From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, June 11, 2014 2:44 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] How to include a .FFS file directly into an .FV


On Jun 11, 2014, at 2:16 PM, Tim Lewis 
mailto:tim.le...@insyde.com>> wrote:

I have the .FFS, complete with dependency expression sections and UI sections, 
etc. And now I want to include that into my FV in my FDF

FILE RAW doesn't do it (the filetype is always RAW). How do I do it? There is a 
NON_FFS_FILE in the spec, but I can't see it in the grammar.


I've used `FILE FREEFORM` but I think that may just push your problem to the 
SECTION.

Thanks,

Andrew Fish

Tim
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] How to include a .FFS file directly into an .FV

[Tim Lewis]

Andrew. Yes. I'm trying to put an already-formed FFS file, complete with 
header, file type, etc. I could use SECTION or I could create an INF, but I'd 
rather do neither and just use the FFS. Hmmm...

Tim

From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, June 11, 2014 2:44 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] How to include a .FFS file directly into an .FV


On Jun 11, 2014, at 2:16 PM, Tim Lewis 
mailto:tim.le...@insyde.com>> wrote:


I have the .FFS, complete with dependency expression sections and UI sections, 
etc. And now I want to include that into my FV in my FDF

FILE RAW doesn't do it (the filetype is always RAW). How do I do it? There is a 
NON_FFS_FILE in the spec, but I can't see it in the grammar.


I've used `FILE FREEFORM` but I think that may just push your problem to the 
SECTION.

Thanks,

Andrew Fish


Tim
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] How to include a .FFS file directly into an .FV

[Tim Lewis]

I have the .FFS, complete with dependency expression sections and UI sections, 
etc. And now I want to include that into my FV in my FDF

FILE RAW doesn't do it (the filetype is always RAW). How do I do it? There is a 
NON_FFS_FILE in the spec, but I can't see it in the grammar.

Tim
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Signalling an event group

[Tim Lewis]

Andrew--

It accounts for the strange usage I've seen. When the code wants to signal the 
event group, it also has to create an event in the event group. With the 
current codebase, you can see it creating dummy notify functions for this 
event, even though the intention is just to signal the other events in the 
group. For example, see IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c, 
line 144 where it has the usefully-titles reference to 
"BdsEmptyCallbackFunction" or ConSpliter.c (line 590) with 
"ConSplitterEmptyCallbackFunction". Even DXE Core's CoreEmptyCallbackFunction 
in Event.c (line 142)

I could not find anything in CreateEventEx that tries to enforce this, which is 
good.

Tim

-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Friday, May 30, 2014 1:15 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Signalling an event group


On May 30, 2014, at 12:41 PM, justin_johns...@dell.com wrote:

> Andrew,
> Your suggested code makes sense to me, I will give it a try. Besides that 
> sample code snippet, I don't think the spec isn't really explicit; but does 
> imply that the entire group is signaled, regardless of whether the event 
> itself is of type EVT_NOTIFY_SIGNAL.
>  

The reason CreateEventEx() got created was to allow the signaling of a group of 
functions so they could run their notify function. But the example clearly 
shows it is legal to create and Ex event of any type. The spec does say the 
event is signaled and their notification functions are schedule. 

Good point, if all the events got signaled I think CoreNotifySignalList() would 
look more like:

VOID
CoreNotifySignalList (
 IN EFI_GUID *EventGroup
 )
{
 LIST_ENTRY  *Link;
 LIST_ENTRY  *Head;
 IEVENT  *Event;

 CoreAcquireEventLock ();

 Head = &gEventSignalQueue;
 for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
   Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
   if (CompareGuid (&Event->EventGroup, EventGroup)) {
  if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
   CoreNotifyEvent (Event);
 } else if (Event->SignalCount == 0x) {
  //
  // The check for 0 prevents double counting the signaled event. 
  //
  Event->SignalCount++;
 }
   }
 }

 CoreReleaseEventLock ();
}

Probably a good idea to change the name to CoreSignalEventGroup(). 

Thanks,

Andrew Fish

> -- Justin
>  
>  
> -Original Message-
> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Friday, May 30, 2014 2:19 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Signalling an event group
> 
> 
> On May 30, 2014, at 11:51 AM, Andrew Fish wrote:
> 
> > 
> > On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:
> > 
> >> Hello all,
> >> I'm working with the DXE core event services and am not sure that the code 
> >> in MdeModulePkg agrees with the UEFI spec.
> >> The situation is this: in several modules I have created an event using 
> >> the CreateEventEx() method, with an EventGroup GUID. Later, I want to 
> >> signal the event group, but the module which does the signaling does not 
> >> have any work to do in response to the event. It would seem that I can 
> >> signal the event by doing as indicated in the UEFI spec:
> >> gBS->CreateEventEx (
> >> 0,
> >> 0,
> >> NULL,
> >> NULL,
> >> &gMyEventGroupGuid,
> >> &Event);
> >> gBS->SignalEvent(Event);
> >> 
> >> However, this does not work with EDKII. I see in Event.c :
> >> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) { if (Event->ExFlag) { 
> >> // // The CreateEventEx() style requires all members of the Event 
> >> Group // to be signaled.
> >> //
> >> CoreReleaseEventLock ();
> >> CoreNotifySignalList (&Event->EventGroup); CoreAcquireEventLock ();
> >> 
> >> Which seems to indicate that the event group is only signaled if the event 
> >> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event 
> >> group signaled, I must create an event with a dummy callback and give it 
> >> type EVT_NOTIFY_SIGNAL, even though I do not have any work to do in 
> >> response to the event.
> >> 
> >> Is this an error in MdeModulePkg's implementation? Or is the spec 
> >> incomplete?
> >> 
> 
> Justin,
> 
> I think the logic in the DXE Core should look like this:
> 
> if (Event->SignalCount == 0x) {
> Event->SignalCount++;
> 
> if (Event->ExFlag) {
> //
> // The CreateEventEx() style requires all members of the Event Group 
> // to be signaled.
> //
> CoreReleaseEventLock ();
> CoreNotifySignalList (&Event->EventGroup); CoreAcquireEventLock (); } 
> else if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) { // // If signalling 
> type is a notify function, queue it // CoreNotifyEvent (Event); } }
> 
> So always walk the List for an Ex event, but only notify the event if 
> it is the right type. And the check should be in 
> CoreNotifySignalList()
> 
> VOID
> CoreNotifySignalList (
> IN EFI_GUID *EventGroup
> )
> {
> LIST_ENTRY *Link;

Re: [edk2] Signalling an event group

[Tim Lewis]

Is this why we see a lot of created events with dummy notify functions?

-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Friday, May 30, 2014 12:19 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Signalling an event group


On May 30, 2014, at 11:51 AM, Andrew Fish  wrote:

> 
> On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:
> 
>> Hello all,
>> I'm working with the DXE core event services and am not sure that the code 
>> in MdeModulePkg agrees with the UEFI spec.
>> The situation is this: in several modules I have created an event using the 
>> CreateEventEx() method, with an EventGroup GUID. Later, I want to signal the 
>> event group, but the module which does the signaling does not have any work 
>> to do in response to the event. It would seem that I can signal the event by 
>> doing as indicated in the UEFI spec:
>> gBS->CreateEventEx (
>>   0,
>>   0,
>>   NULL,
>>   NULL,
>>   &gMyEventGroupGuid,
>>   &Event);
>> gBS->SignalEvent(Event);
>>  
>> However, this does not work with EDKII. I see in Event.c :
>> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
>>   if (Event->ExFlag) {
>> //
>> // The CreateEventEx() style requires all members of the Event Group
>> //  to be signaled.
>> //
>> CoreReleaseEventLock ();
>> CoreNotifySignalList (&Event->EventGroup);
>> CoreAcquireEventLock ();
>>  
>> Which seems to indicate that the event group is only signaled if the event 
>> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event group 
>> signaled, I must create an event with a dummy callback and give it type 
>> EVT_NOTIFY_SIGNAL, even though I do not have any work to do in response to 
>> the event.
>>  
>> Is this an error in MdeModulePkg's implementation? Or is the spec incomplete?
>>  

Justin,

I think the logic in the DXE Core should look like this:

  if (Event->SignalCount == 0x) {
Event->SignalCount++;

if  (Event->ExFlag) {
//
// The CreateEventEx() style requires all members of the Event Group
//  to be signaled.
//
CoreReleaseEventLock ();
CoreNotifySignalList (&Event->EventGroup);
CoreAcquireEventLock ();
} else if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
//
// If signalling type is a notify function, queue it
//
CoreNotifyEvent (Event);
}
  }

So always walk the List for an Ex event, but only notify the event if it is the 
right type. And the check should be in CoreNotifySignalList()

VOID
CoreNotifySignalList (
  IN EFI_GUID *EventGroup
  )
{
  LIST_ENTRY  *Link;
  LIST_ENTRY  *Head;
  IEVENT  *Event;

  CoreAcquireEventLock ();

  Head = &gEventSignalQueue;
  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
if (CompareGuid (&Event->EventGroup, EventGroup)) {
   if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
CoreNotifyEvent (Event);
  }
}
  }

  CoreReleaseEventLock ();
}


Man, this code has been busted for a long time This bug predates the edk2!

The edk2 UefiLib even has a Dummy event and tries to hide the need for it from 
the caller

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/UefiLib/UefiNotTiano.c
/**
  An empty function to pass error checking of CreateEventEx ().

  This empty function ensures that EVT_NOTIFY_SIGNAL_ALL is error
  checked correctly since it is now mapped into CreateEventEx() in UEFI 2.0.
 
  @param  Event Event whose notification function is being 
invoked.
  @param  Context   The pointer to the notification function's 
context,
which is implementation-dependent.

**/
VOID
EFIAPI
InternalEmptyFunction (
  IN EFI_EVENTEvent,
  IN VOID *Context
  )
{
  return;
}

EFI_STATUS
EFIAPI
EfiCreateEventReadyToBootEx (
  IN  EFI_TPL   NotifyTpl,
  IN  EFI_EVENT_NOTIFY  NotifyFunction,  OPTIONAL
  IN  VOID  *NotifyContext,  OPTIONAL
  OUT EFI_EVENT *ReadyToBootEvent
  )
{
  EFI_STATUSStatus;
  EFI_EVENT_NOTIFY  WorkerNotifyFunction;

  ASSERT (ReadyToBootEvent != NULL);

  if (gST->Hdr.Revision < EFI_2_00_SYSTEM_TABLE_REVISION) {
DEBUG ((EFI_D_ERROR, "EFI1.1 can't support ReadyToBootEvent!"));
ASSERT (FALSE);

return EFI_UNSUPPORTED;
  } else {
//
// For UEFI 2.0 and the future use an Event Group
//
if (NotifyFunction == NULL) {
  //
  // CreateEventEx will check NotifyFunction is NULL or not and return 
error.
  // Use dummy routine for the case NotifyFunction is NULL.
  //
  WorkerNotifyFunction = InternalEmptyFunction;
} else {
  WorkerNotifyFunction = NotifyFunction;
}
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
NotifyTpl,

[edk2] HotkeyBoot() only called after normal boot fails?

[Tim Lewis]

In examining how the current tianocore BDS works, it seems that the 
UEFI-defined hot keys are ignored except after a boot failure for normal boot 
options. It appears there is a missing call to HotkeyBoot() in BdsEntry.c 
inside the loop. Currently, the only calls to this function are in FrontPage.c, 
which is only processed either after all boot options have failed or a 
successful boot returns to the BDS.

Per the UEFI-spec, this seems wrong because, although the spec doesn't talk 
about prioritization (BootNext, OsIndications aren't prioritized either) but 
the likely usage case would be that a user presses a key and wants to launch 
that boot option instead of the ones in the BootOrder.

Tim
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] edk2-devel Digest, Vol 53, Issue 25 [OvmfPkg/SMBIOS: Add QEMU-2.1 support]

[Tim Lewis]

Gabriel --

I think that Yi's point is that this structure method of finding the tables is 
optional and is deprecated. On UEFI system, the tables are found using the EFI 
System Configuration table, searching it for the GUID he mentioned. Many X86 
systems still support both means of finding the tables, but ARM systems only 
support the UEFI method.

Tim

-Original Message-
From: Gabriel L. Somlo [mailto:gso...@gmail.com] 
Sent: Wednesday, May 14, 2014 9:48 AM
To: Yi Li
Cc: edk2-devel@lists.sourceforge.net; pbonz...@redhat.com; liyi 00215672
Subject: Re: [edk2] edk2-devel Digest, Vol 53, Issue 25 [OvmfPkg/SMBIOS: Add 
QEMU-2.1 support]

On Wed, May 14, 2014 at 08:17:30AM +0800, Yi Li wrote:
> Hi Gabrie,
> 
>  Why do you use legacy method to find SMBIOS entry(like "_SM_")
> only in GetQemuSmbiosTables()?
> 
>  there is no "_SM_" support on ARM platform, but
> SMBIOS_TABLE_GUID is usable, could you consider to add
> SMBIOS_TABLE_GUID
> 
> support in that function?

Hello Yi,

I'm using this as reference:

http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf

Check out Section 5.2.1 on page 21 (Entry Point).

It's not so much a method to find the entry that I'm using -- it's
more that I'm doing additional checks to make extra sure QEMU provided
a valid set of (entry point + tables blob). Then (similarly to how
Xen does it) I ignore the entry point completely and clone each
structure in the tables blob using InstallAllStructures().

Per the spec, the entry point is expected to contain the strings
"_SM_" and "_DMI_" in the appropriate fields. So if they're not
where they're expected to be, then we're in trouble :)

Hope this clears it up...

Thanks,
--Gabriel

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] EndOfDxe?

[Tim Lewis]

Vincent --

I understand the business problems all too well. But the EDK2 reference 
implementation should be able to comply as it exists today, even if we were to 
put the signal at the last possible point before the connect console and 
Driver processing. We perpetuate this problem on both the x86 side and ARM 
by leaving it out but having EDK2 drivers depend on it.

Tim 

-Original Message-
From: Zimmer, Vincent [mailto:vincent.zim...@intel.com] 
Sent: Wednesday, April 30, 2014 6:36 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?

Tim:

I agree.  First order business problem is evolving implementations to adhere to 
strictures of PI spec about 3rd party code in volume 2 of the PI Spec from 
uefi.org, viz,

5.1.2.1 End of DXE Event
Prior to invoking any UEFI drivers, applications, or connecting consoles, the 
platform should signal the event EFI_END_OF_DXE_EVENT_GUID.
#define EFI_END_OF_DXE_EVENT_GROUP_GUID \ { 0x2ce967a, 0xdd7e, 0x4ffc, { 0x9e, 
0xe7, 0x81, 0xc, \ 0xf0, 0x47, 0x8, 0x80 } }
>From SEC through the signaling of this event, all of the components 
>should
be under the authority of
the platform manufacturer and not have to worry about interaction or corruption 
by 3rd party extensible modules. As such, PI modules that need to lock or 
protect their resources in anticipation of the invocation of 3rd party 
extensible modules, such as UEFI drivers, should register for notification on 
this event and effect the appropriate protections in their notification handler



Vincent 

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, April 30, 2014 6:19 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?

Vincent --

Less worried about the exact location, but want it to meet the PI-imposed 
requirements of before console connection or processing DriverOrder or 
BootOrder.

Tim

-Original Message-
From: Zimmer, Vincent [mailto:vincent.zim...@intel.com]
Sent: Wednesday, April 30, 2014 6:06 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?

Tim:

I wanted to follow-up a bit on the complexity of doing this.  Maybe relax the ' 
immediately upon calling the BdsEntry() function in BdsDxe.' language in your 
initial message to 'somewhere within BdsEntry() of BdsDxe' if that wasn't 
already your intent.

Why?

Signaling of the EndOfDxe event is a bit tricky since it may need to be done in 
some intermediate portion of the platform Bds logic, not necessarily at the 
top, for a given platform.

Specifically, if you were to simplify logic in 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/IntelFrameworkModulePkg/Unive
rsal/BdsDxe/BdsEntry.c 

You might not signal the event at 

VOID
EFIAPI
BdsEntry (
  IN EFI_BDS_ARCH_PROTOCOL  *This
  )
{
  LIST_ENTRY  DriverOptionList;
  LIST_ENTRY  BootOptionList;
  UINTN   BootNextSize;
  CHAR16  *FirmwareVendor;
  EFI_STATUS  Status;
  UINT16  BootTimeOut;
  UINTN   Index;
  EDKII_VARIABLE_LOCK_PROTOCOL*VariableLock;

 SignalEndOfDxe here

But instead perhaps later in the code, prior to the code block:

  //
  // Set up the device list based on EFI 1.1 variables
  // process Driver and Load the driver's in the
  // driver option list
  //
  BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
  if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
  }
  //
  // Check if we have the boot next option
  //
  mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
&gEfiGlobalVariableGuid,
&BootNextSize
);

  //
  // Setup some platform policy here
  //
  PlatformBdsPolicyBehavior (&DriverOptionList, &BootOptionList, 
BdsProcessCapsules, BdsMemoryTest);
  PERF_END (NULL, "PlatformBds", "BDS", 0);

  //
  // BDS select the boot device to load OS
  //
  BdsBootDeviceSelect ();


Why?

Prior to loading drivers and doing connects, you may want the platform to be 
open (assuming an EndOfDxe handler locks flash, for example).

Other examples in platform Bds's not in our open source one includes capsule 
processing.

Perhaps the Bds logic there



BdsEntry()
{
Process capsule

If there exists a valid capsule, connect just my integrated gfx driver so that 
I can provide output while processing capsules

Signal end of Dxe to lock flash

Load and run 3rd party drivers

Connect rest of consoles

etc
}

So I agree w/ need, but maybe each package owner needs to do the analysis on 
where in their Bds to put this logic.  

So this isn't so much a question of 'if' we should do it, which we all agree is 
good, but perhaps 'where' in the respective Bds driver?

Thanks,

Vincent

-Original

Re: [edk2] EndOfDxe?

[Tim Lewis]

Vincent --

Less worried about the exact location, but want it to meet the PI-imposed 
requirements of before console connection or processing DriverOrder or 
BootOrder.

Tim

-Original Message-
From: Zimmer, Vincent [mailto:vincent.zim...@intel.com] 
Sent: Wednesday, April 30, 2014 6:06 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?

Tim:

I wanted to follow-up a bit on the complexity of doing this.  Maybe relax the ' 
immediately upon calling the BdsEntry() function in BdsDxe.' language in your 
initial message to 'somewhere within BdsEntry() of BdsDxe' if that wasn't 
already your intent.

Why?

Signaling of the EndOfDxe event is a bit tricky since it may need to be done in 
some intermediate portion of the platform Bds logic, not necessarily at the 
top, for a given platform.

Specifically, if you were to simplify logic in 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/IntelFrameworkModulePkg/Unive
rsal/BdsDxe/BdsEntry.c 

You might not signal the event at 

VOID
EFIAPI
BdsEntry (
  IN EFI_BDS_ARCH_PROTOCOL  *This
  )
{
  LIST_ENTRY  DriverOptionList;
  LIST_ENTRY  BootOptionList;
  UINTN   BootNextSize;
  CHAR16  *FirmwareVendor;
  EFI_STATUS  Status;
  UINT16  BootTimeOut;
  UINTN   Index;
  EDKII_VARIABLE_LOCK_PROTOCOL*VariableLock;

 SignalEndOfDxe here

But instead perhaps later in the code, prior to the code block:

  //
  // Set up the device list based on EFI 1.1 variables
  // process Driver and Load the driver's in the
  // driver option list
  //
  BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
  if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
  }
  //
  // Check if we have the boot next option
  //
  mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
&gEfiGlobalVariableGuid,
&BootNextSize
);

  //
  // Setup some platform policy here
  //
  PlatformBdsPolicyBehavior (&DriverOptionList, &BootOptionList, 
BdsProcessCapsules, BdsMemoryTest);
  PERF_END (NULL, "PlatformBds", "BDS", 0);

  //
  // BDS select the boot device to load OS
  //
  BdsBootDeviceSelect ();


Why?

Prior to loading drivers and doing connects, you may want the platform to be 
open (assuming an EndOfDxe handler locks flash, for example).

Other examples in platform Bds's not in our open source one includes capsule 
processing.

Perhaps the Bds logic there



BdsEntry()
{
Process capsule

If there exists a valid capsule, connect just my integrated gfx driver so that 
I can provide output while processing capsules

Signal end of Dxe to lock flash

Load and run 3rd party drivers

Connect rest of consoles

etc
}

So I agree w/ need, but maybe each package owner needs to do the analysis on 
where in their Bds to put this logic.  

So this isn't so much a question of 'if' we should do it, which we all agree is 
good, but perhaps 'where' in the respective Bds driver?

Thanks,

Vincent

-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, April 30, 2014 10:39 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?


On Apr 30, 2014, at 7:29 AM, Zimmer, Vincent 
wrote:

> I agree w/ your concern and the proposed placement.
> This omission has caused a lot of confusion.

I've also seen issues porting EDK code..

Thanks,

Andrew Fish

> Vincent
> 
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 30, 2014 10:10 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] EndOfDxe?
> 
> I see that more and more drivers are adding callbacks for the 
> PI-defined EndOfDxe event group. However, none of the EDK2 
> implementations signal this event group. As a result, we are seeing 
> widely varying implementations as to its placement, and a lot of 
> assumptions about what is completed at that point. For example, is PCI 
> enumeration complete? IMO, you can't assume that because no UEFI 
> devices have been connected. As  the PI spec says: " Prior to invoking 
> any UEFI drivers, applications, or connecting consoles, the platform
should signal the event EFI_END_OF_DXE_EVENT_GUID."
> 
> So it seems appropriate that the signaling of this event should be 
> immediately upon calling the BdsEntry() function in BdsDxe.
> 
> Thoughts?
> 
> Tim
> 
> --
> --
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE 
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
> unparallele