Re: [edk2] Build Tool Changes
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.netmailto: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
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.netmailto: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
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.netmailto: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
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] cond vs. ?
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.netmailto: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.netmailto: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.netmailto: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. ?
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.netmailto: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. ?
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
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, Leomailto:leo.du...@amd.com Sent: 5/5/2015 11:06 AM To: edk2-devel@lists.sourceforge.netmailto: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?
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_15utm_medium=emailutm_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
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
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
liming@intel.commailto: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.netmailto:edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] SEC PPI HOBs
On Feb 27, 2015, at 11:18 PM, Gao, Liming
liming@intel.commailto: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.netmailto: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.netmailto:edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] SEC PPI HOBs
On Feb 27, 2015, at 3:02 PM, Tim Lewis
tim.le...@insyde.commailto: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.
http
Re: [edk2] [PATCH] Remove IntelFramweorkModulePkg as Shell library dependency
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 jaben.car...@intel.commailto: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=164703151iu=/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
Reviewed-by: Tim Lewis tim.le...@insyde.commailto: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 jaben.car...@intel.commailto: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=164703151iu=/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
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 jaben.car...@intel.commailto: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.netmailto: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.commailto:el...@hp.com Thanks, Samer El-Haj-Mahmoud System Firmware Architect HP Servers el...@hp.commailto:el...@hp.com T +1.281.514.5973 C +1.512.659.1523 Hewlett-Packard Company hp.com/go/proliant/uefihttp://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=157005751iu=/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
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.netmailto: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.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH] ShellPkg: Update DH for AdapterInfoProtocol Reviewed-by: Jaben Carsey jaben.car...@intel.commailto: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.netmailto: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.commailto:el...@hp.com Thanks, Samer El-Haj-Mahmoud System Firmware Architect HP Servers el...@hp.commailto:el...@hp.com T +1.281.514.5973 C +1.512.659.1523 Hewlett-Packard Company hp.com/go/proliant/uefihttp://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=157005751iu=/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.
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
[edk2] PCD Database Forcing
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] Get BlockIo protocol from Ata Device based on Port and Multiplier Port
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 feng.t...@intel.commailto: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.commailto: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.netmailto: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] Enable optimization for gcc x64 builds
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 sc...@notabs.org -- 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
Re: [edk2] DynamicEx and FeatureFlag
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.netmailto: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=154622311iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[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=154622311iu=/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
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 := byte-list , integer | 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.netmailto: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.netmailto: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: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: Re
Re: [edk2] HII ORDERED_LIST support
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.netmailto: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.netmailto: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.netmailto: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
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
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.netmailto: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 := byte-list , integer | integer
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 03, 2014 6:31 PM
To: edk2-devel@lists.sourceforge.netmailto: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.netmailto: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
Re: [edk2] VS2013 build failures: unresolved external symbol __dtoui3
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
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 := byte-list , integer | 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.netmailto: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.netmailto: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
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. 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.netmailto: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.netmailto: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.netmailto: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.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] HII ORDERED_LIST support Tim, I admit that one
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
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.netmailto: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.netmailto: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.netmailto: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
[edk2] PCD Binary SkuIdTable and SystemSkuId Documentaton
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
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.netmailto: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.netmailto: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.netmailto: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.netmailto: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
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
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.netmailto: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
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.netmailto: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.netmailto: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.netmailto: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] 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 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.netmailto: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.netmailto: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.netmailto: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
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] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages
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 tim.le...@insyde.com 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 liming@intel.com 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
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 -- 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
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
Re: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode version of DebugLib
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.netmailto: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] Bitwise OR operator problems
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 88 == 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
[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
[edk2] goto vfrConstantValue
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
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 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.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] HII ORDERED_LIST support In DriverSampleDxe, the boot order item is listed in storage as: UINT16 BootOrder[8]; And here is the ordered list which manipulates this item: orderedlist varid = MyIfrNVData.BootOrder, prompt = STRING_TOKEN(0x006D), help= STRING_TOKEN(0x0059), option text = STRING_TOKEN(0x006F), value = 2, flags = RESET_REQUIRED; option text = STRING_TOKEN(0x006E), value = 1, flags = RESET_REQUIRED; option text = STRING_TOKEN(0x0070), value = 3, flags = RESET_REQUIRED; suppressif ideqval MyIfrNVData.BootOrderLarge == 0; option text = STRING_TOKEN(0x0071), value = 4, flags = RESET_REQUIRED; endif endlist; This leads to a number of questions: 1) The BootOrder is defined as UINT16, but the UEFI specification clearly states that an orderedlist will work on a buffer with one byte per container. (See 29.2.5.4.8 where it says, The set questions are stored as a Buffer with one byte for each Container. [[[Eric]]] Truly spec has this description but vfrcompile and browser not do this check, also current code may already has samples which already violate this rule, so I need more discussion to provide a good proposal for this case. [TIM] I am not worried about the actual struct members. BootOrder is 16 bytes (8 x sizeof(UINT16). So that means that MaxContainers will be 16, right? The VFR spec says: NOTE: maxcontainers is optional, and the default value depends on the variable size defined by varid in vfrQuestionHeader So it seems that, even though the code will work, using UINT8 BootOrder[16] would be easier to understand than UINT16 BootOrder[8] [[[Eric]]] Base on current implementation, the maxcontainer value is the array size. So for UINT16 BootOrder[8], the maxcontainer = 8 and for UINT8 BootOrder[16], the maxcontainer = 16. I think we need to add check for the code first, only support one byte for each container. 2) The option values are all integers. But the storage type of an ordered list is a BUFFER. To me this implies (I haven't looked this up) that the value an option is being used as the option for a single container. That makes sense, but it is not the behavior described in the UEFI specification. Also, there seems to be no way to create a value for a question of type buffer. [[[Eric]]] no catch what's your mean is. [TIM] For example, for oneof the value storage size is UINT8/UINT16/UINT32 or UINT64. The value storage size for checkbox is BOOLEAN. But what is the value storage size of orderedlist When I read the UEFI specification, the value storage size of orderedlist is maxcontainers x sizeof(UINT8). So, if maxcontainers is 16, then 16 bytes. BUT: the size of the value in an option inside the orderedlist in these examples is sizeof(UINT8), not maxcontainers x sizeof(UINT8). According to the UEFI specification, as I read it today, the value in a ONE_OF_OPTION is the value for the entire value storage, not just one byte of the value storage. So every container in the ordered list value should be set to 2 when the first ONE_OF_OPTION (in the example above) is selected by the user. [[[Eric]]] I can't find this information from the spec, which page in UEFI spec 2.4b describe it? But I do not believe this is what the EDK2 Form browser does today. I believe that it only changes
Re: [edk2] Duplicate PCDs in DSC files
Samer - I would say that there are tool chains the depend on the last-instance winning. Consider the case of #included .dsc files where the included .dsc has the default value/storage type and the final resolution done later in the including file. Tim From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] Sent: Tuesday, August 26, 2014 1:59 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] Duplicate PCDs in DSC files It looks like the build tools will not warn you (or stop with an error) if there are multiple declarations of the same PCD in the DSC file. In fact, the same PCD could be initialized multiple times using different values and different types (Fixed vs. Dynamic for instance), and the build tools will silently pick the last instance of the PCD in the DSC File. We just finished debugging a nasty issue caused by duplicate PCDs, and it would have been nice to prevent this to begin with! Looks to me like a bug in the tool. Can we add the ability to break the build if there are duplicate PCD instances in the DSC file? Samer El-Haj-Mahmoud System Firmware Architect HP Servers el...@hp.commailto:el...@hp.com T +1.281.514.5973 C +1.512.659.1523 Hewlett-Packard Company hp.com/go/proliant/uefihttp://hp.com/go/proliant/uefi [Description: Description: C:\Users\elhajmah\HpLogo.png] -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] suppressif endif grammar different between Form, FormSet and Question usage.
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
[edk2] HII ONE_OF_OPTIONS flags
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] [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 FS and ( instead of LP?
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.
US::= \u0020 ; Space Character
FW::= \u0027 ; Forward Slash, /
LP::= \u0028 ; Left Parenthesis, (
RP::= \u0029 ; Right Parenthesis, )
Letter::= {(\u0041-\u005A)} ; Characters A - Z
{(\u0061-\u007A)} ; Characters a - z
Digit ::= (\u0030-\u0039) ; Characters 0 - 9
UN::= \u005F; Underscore Character, _
MS::= US+
ME::= {MS} {EOL}
CommentLine ::= FW FW US* PCHars EOL
BlankLine ::= EOL
Chars ::= (\u0001-\uF6FF)
PChars::= (\u0020-\uF6FF)
VChars::= (\u0021-\uF6FF)
UnicodeLines ::= Token ME
[Ldef [String ME]+]+
Ldef ::= CtrlChar language MS LangCode ME
HexDigitU ::= {Digit}
{(\u0041-\u0046)} ; Characters A - F
{(\u0061-\u0066)} ; Characters a - f
CtrlChar ::= \u0023 ; Hash Character, #
Token ::= CtrlChar string MS Identifier
Identifier::= Letter [{Letter} {Digit} {UN}]*
LangCode ::= RFC4646
DH::= (\u002D) ; Dash Character, -
RFC4646 ::= Letter{2,8} [ShortExt LongExt*]
ShortExt ::= DH [{Letter} {Digit}]{1,8}
LongExt ::= DH [{Letter} {Digit}]{1,}
UDblQuote ::= \u0022 ; Double Quote Character,
String::= UDblQuote SContent* UDblQuote
SContent ::= {PChars} {Attributes} {CtrlCode}
Attributes::= StartAttribute SContent*
[StopAttribute]
StartAttribute::= AttrCtrlChar FontAttr
AttrCtrlChar ::= \u005C ; Backslash Character, \
StopAttribute ::= AttrCtrlChar end FontAttr
FontAttr ::= {SimpleAttrs} {StandardAttrs}
SimpleAttrs ::= {narrow} {wide}
StandardAttrs ::= {normal} {bold} {italic}
{emboss}
{shadow} {underline} {dblunder}
CtrlCode ::= EscChar {n} {f} {r} {p}
Re: [edk2] EDK II UNI Unicode File Specification Update
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 X with X (italics) b. second, removal of the TS terminal. Moved the whitespace rules into the introductory information where comments are described. This allowed some other rules to be simplified, since X Eq Y could become = c. Replace simple terminals with their literals. EX: Why FieldSeparator when you can use |? I replaced CRLF with EOL 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.netmailto: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.netmailto: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.netmailto: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 TS Identifier TS = TS 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
[edk2] key usage with VFR
The current grammar for VFR shows the following for checkbox:
vfrStatementCheckBox ::=
checkbox
vfrQuestionHeader ,
{ flags = vfrCheckBoxFlags , }
{ key = Number , }
vfrStatementQuestionOptionList
endcheckbox ;
And then a little further down it has this note:
BEHAVIORS AND RESTRICTIONS:
The value of key is used as question ID.
Now, observe this example from DriverSampleDxe (Vfr.vfr, line 177):
checkbox varid = MyIfrNVData.ChooseToActivateNuclearWeaponry,
prompt = STRING_TOKEN(STR_CHECK_BOX_PROMPT),
help = STRING_TOKEN(STR_CHECK_BOX_HELP),
//
// CHECKBOX_DEFAULT indicate this checkbox is marked with
EFI_IFR_CHECKBOX_DEFAULT
// CHECKBOX_DEFAULT_MFG indicate EFI_IFR_CHECKBOX_DEFAULT_MFG.
//
flags= CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG,
key = 0,
default = 1,
endcheckbox;
Notice that (a) there is no questionid (from the vfrQuestionHeader terminal)
and (b) key is set to 0. Since 0 is not a valid question identifier value
(although the UEFI 2.4 spec is not so clear on this, you can see that it is
true from how it is referenced in the EFI_IFR_REF structure 29.3.8.3.59 and the
callback). So it is not clear whether the intention was to force the assignment
of a non-conflicting value or it really intended that the question identifier
be 0.
There is a similar issue on line 590 (another checkbox). Am I missing something
here? Is there a specific reason why key (an anachronism from the Framework
days) is used instead of questionid?
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] EDK II UNI Unicode File Specification Update
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 Token in section 2.1 Extended Backus-Naur Form (EBNF)
HexDigitU::= (\ua-\uf\uA-\uF\u0-\u9)
Token::= CtrlChar MS Lstring MS
Identifier(\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*
Identifier ::= (\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*
LangCode::= RFC4646
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:
MetaInfoFile ::= CommentLine*
MetaData+
MetaData ::= {CommentLine} {BlankLine} {UnicodeLines}
Additional Definitions used for Package Meta-Data Token Identifiers
ErrorNumber ::= (\u0-\u9\ua-\uf\uA-\uF)
PcdName ::= CName L_ CName
CName ::= (\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.
LSTR_MODULE_ABSTRACT
LSTR_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.
LSTR_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.
LSTR_PACKAGE_ABSTRACT
LSTR_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 referenced by an error number. The CName
[edk2] PEI_DEPEX and DXE_DEPEX in .INF files
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] Removal of DEBUG_CODE in RELEASE Builds
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
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
US ::= L
MS ::= US+
ME ::= {MS} {EOL}
CR ::= 0x000D
LF ::= 0x000A
EOL ::= CRLF
BlankLine ::= EOL
PChars ::= (0x0020-0xF6FF)
LangCode::= RFC4646
RFC4646 ::= (\ua-\uz\uA-\uZ){2,8}
[L- (\ua-\uz\uA-\uZ\u0-\u9){2,8}]
UDblQuote ::= 0x0022
String ::= UDblQuote PChars* UDblQuote
Header ::= L// /** @file EOL
[Abstract EOL]?
[L// EOL]+
[Description EOL]*
[L// EOL]
[Copyright EOL]+
[L// EOL]*
[License EOL]+
[L// EOL]*
L// **/ EOL+
Abstract::= L// MS PChars+
Description ::= L// MS PChars+
Copyright ::= L// MS Copyright (c) MS Date
Date::= {Year} {YearRange} {YearList} L, US Comp
Year::= (\u2-\u9) (\u0-\u9){3}
YearRange ::= Year US L- US Year
YearList::= Year [, US Year]+
Comp::= PChars* L. MS LAll rights reserved.BR
License ::= L// MS PChars*
LangEntry ::= L#language MS LangCode ME
[String ME]+
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
InfUnicodeFile ::= Header
BlankLine*
AbstractTag?
BlankLine*
DescriptionTag?
BlankLine*
AbstractTag::= L#string MS LSTR_MODULE_ABSTRACT ME
LangEntry+
DescriptionTag ::= L#string MS LSTR_MODULE_DESCRIPTION ME
LangEntry+
Example
// /** @file
// TerminalDxe Module Localized Abstract and Description Content
//
// Copyright (c) 2012 - 2014, Intel Corporation. All rights reserved.BR
//
// 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
InfUnicodeFile ::= Header
BlankLine*
PropertyName?
BlankLine*
PropertyName::= L#string MS
LSTR_PROPERTIES_MODULE_NAME ME
LangEntry+
Example
// /** @file
// TerminalDxe Localized Strings and Content
//
// Copyright (c) 2013, Intel Corporation. All rights reserved.BR
//
// 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
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 TS
Identifier TS = TS 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.netmailto: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.netmailto: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
US ::= L
MS ::= US+
ME ::= {MS} {EOL}
CR ::= 0x000D
LF ::= 0x000A
EOL ::= CRLF
BlankLine ::= EOL
PChars ::= (0x0020-0xF6FF)
LangCode::= RFC4646
RFC4646 ::= (\ua-\uz\uA-\uZ){2,8}
[L- (\ua-\uz\uA-\uZ\u0-\u9){2,8}]
UDblQuote ::= 0x0022
String ::= UDblQuote PChars* UDblQuote
Header ::= L// /** @file EOL
[Abstract EOL]?
[L// EOL]+
[Description EOL]*
[L// EOL]
[Copyright EOL]+
[L// EOL]*
[License EOL]+
[L// EOL]*
L// **/ EOL+
Abstract::= L// MS PChars+
Description ::= L// MS PChars+
Copyright ::= L// MS Copyright (c) MS Date
Date::= {Year} {YearRange} {YearList} L, US Comp
Year::= (\u2-\u9) (\u0-\u9){3}
YearRange ::= Year US L- US Year
YearList::= Year [, US Year]+
Comp::= PChars* L. MS LAll rights reserved.BR
License ::= L// MS PChars*
LangEntry ::= L#language MS LangCode ME
[String ME]+
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
InfUnicodeFile ::= Header
BlankLine*
AbstractTag?
BlankLine*
DescriptionTag?
BlankLine*
AbstractTag::= L#string MS LSTR_MODULE_ABSTRACT ME
LangEntry+
DescriptionTag ::= L#string MS LSTR_MODULE_DESCRIPTION ME
LangEntry+
Example
// /** @file
// TerminalDxe Module Localized Abstract and Description Content
//
// Copyright (c) 2012 - 2014, Intel Corporation. All rights reserved.BR
//
// 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
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 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.netmailto: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.netmailto: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.netmailto: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.netmailto: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
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. 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.netmailto: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.netmailto: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
Re: [edk2] INF/DEC file updates to EDK II packages
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.netmailto: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.netmailto: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.netmailto: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
[edk2] VfrCompiler.exe uninitialized variable causes random failures
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=153845071iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] VfrCompiler error
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=153845071iu=/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
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.TokenSpaceGuid] 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
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 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.TokenSpaceGuid] 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
[edk2] VFR Expression Grammar Issues
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
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
[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? 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#174; Code Sight#153; - 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
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?eom
-- 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
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 type4 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
[edk2] How to include a .FFS file directly into an .FV
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] How to include a .FFS file directly into an .FV
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.netmailto: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.netmailto: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 tim.le...@insyde.commailto: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.netmailto: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] Signalling an event group
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 af...@apple.com 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,
WorkerNotifyFunction,
NotifyContext,
Re: [edk2] Signalling an event group
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;
LIST_ENTRY *Head;
IEVENT *Event;
CoreAcquireEventLock ();
Head = gEventSignalQueue;
for (Link = Head-ForwardLink; Link != Head; Link = Link-ForwardLink)
{ Event = CR
[edk2] HotkeyBoot() only called after normal boot fails?
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]
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?
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, LDriverOrder);
if (!IsListEmpty (DriverOptionList)) {
BdsLibLoadDrivers (DriverOptionList);
}
//
// Check if we have the boot next option
//
mBootNext = BdsLibGetVariableAndSize (
LBootNext,
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?
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 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] A compile fail problem when I include stdio.h into the cpp file
It has been my observation that this occurs because the current build rules include the .cpp extension with the .c extension. This forces C++ files to be compiled with the C rules. In the x86 tool chains, this almost works because the tool chain auto-detects the type of compilation to perform based on the extension (in ARM RVTOOLS it doesn’t, if my memory serves me right). However, when you get the StdLib you run into one of the issues: wchar_t. In C++ this flag is turned on by default. In C it is not. EfiCDefs.h is trying to make sense of this, but does not consider the C++ case. If _NATIVE_WCHAR_T_DEFINED is set, it means that /Zc:wchar_t was used (or C++ was compiled) Tim From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com] Sent: Tuesday, April 29, 2014 10:36 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] A compile fail problem when I include stdio.h into the cpp file You mention a cpp file. Are you trying to build this with C++? Have you included StdLib\StdLib.inc in your project’s .dsc file? The error you are seeing was added to EfiCdefs.h to detect configuration errors. When it occurs, you can be sure that your project’s build files are not configured correctly. Look at StdLib\StdLib.dsc and AppPkg\AppPkg.dsc for examples of .dsc files for using StdLib. Also, look at some of the application .inf files in AppPkg for examples of properly formed .inf files. These files have comments describing the constructs that are specific to StdLib. Note that C++ is not currently supported, nor is it tested. Make sure that you have read, and understand, the StdLib\ReadMe.txt file. If you don’t follow the instructions in that file, builds with StdLib will either fail or will not work as expected. Sincerely, Daryl McDaniel Mistakes are the portals of discovery -- James Joyce From: w.j.wang (王為之) [mailto:w.j.w...@gigabyte.com] Sent: Thursday, April 24, 2014 8:52 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] A compile fail problem when I include stdio.h into the cpp file Hello everyone, I have met a compile problem when I include stdio.h into the cpp file. The error message is: c:\myworkspace\StdLib\Include\sys/EfiCdefs.h(330) : fatal error C1189: #error : You must specify /Zc:wchar_t- to the compiler to turn off intrinsic wchar_t. Hence, I followed the tip to add the /Zc:wchar_t- into the BuildOptions of my inf file. However, this compile error still occurs, unless I direct delete the 330 line of the EfiCdef.h. It seems an issue. Thanks, -- 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] A compile fail problem when I include stdio.h into the cpp file
Daryl - Could we simply remove the .cpp rules from the build_rules? It makes people unnecessarily confused, since C++ is not officially supported. It prevents getting an “file type not supported” from the INF processing and instead gives esoteric C compiler issues. Tim From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com] Sent: Tuesday, April 29, 2014 5:19 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] A compile fail problem when I include stdio.h into the cpp file Since C++ isn’t supported, I won’t comment on that. If the directions for StdLib are followed, /Zc:wchar_t- will be set for the Microsoft compiler. (Note the trailing minus (-). This turns off intrinsic support for wchar_t) The equivalent is done, where necessary, for other compilers and other intrinsics. wchar_t is particularly problematic since VC++ treats wchar_t as a specific, distinct, type. Any attempt to redefine it, even to an equivalent type, will fail. Sometimes the failure shows up during compilation. Most often it fails during the link and code generation phase; a result of LTCG. Daryl McDaniel It is the mark of an educated mind to be able to entertain a thought without accepting it. - Aristotle From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Tuesday, April 29, 2014 11:06 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] A compile fail problem when I include stdio.h into the cpp file It has been my observation that this occurs because the current build rules include the .cpp extension with the .c extension. This forces C++ files to be compiled with the C rules. In the x86 tool chains, this almost works because the tool chain auto-detects the type of compilation to perform based on the extension (in ARM RVTOOLS it doesn’t, if my memory serves me right). However, when you get the StdLib you run into one of the issues: wchar_t. In C++ this flag is turned on by default. In C it is not. EfiCDefs.h is trying to make sense of this, but does not consider the C++ case. If _NATIVE_WCHAR_T_DEFINED is set, it means that /Zc:wchar_t was used (or C++ was compiled) Tim From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com] Sent: Tuesday, April 29, 2014 10:36 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] A compile fail problem when I include stdio.h into the cpp file You mention a cpp file. Are you trying to build this with C++? Have you included StdLib\StdLib.inc in your project’s .dsc file? The error you are seeing was added to EfiCdefs.h to detect configuration errors. When it occurs, you can be sure that your project’s build files are not configured correctly. Look at StdLib\StdLib.dsc and AppPkg\AppPkg.dsc for examples of .dsc files for using StdLib. Also, look at some of the application .inf files in AppPkg for examples of properly formed .inf files. These files have comments describing the constructs that are specific to StdLib. Note that C++ is not currently supported, nor is it tested. Make sure that you have read, and understand, the StdLib\ReadMe.txt file. If you don’t follow the instructions in that file, builds with StdLib will either fail or will not work as expected. Sincerely, Daryl McDaniel Mistakes are the portals of discovery -- James Joyce From: w.j.wang (王為之) [mailto:w.j.w...@gigabyte.com] Sent: Thursday, April 24, 2014 8:52 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] A compile fail problem when I include stdio.h into the cpp file Hello everyone, I have met a compile problem when I include stdio.h into the cpp file. The error message is: c:\myworkspace\StdLib\Include\sys/EfiCdefs.h(330) : fatal error C1189: #error : You must specify /Zc:wchar_t- to the compiler to turn off intrinsic wchar_t. Hence, I followed the tip to add the /Zc:wchar_t- into the BuildOptions of my inf file. However, this compile error still occurs, unless I direct delete the 330 line of the EfiCdef.h. It seems an issue. Thanks, -- 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
[edk2] Why would I ever use the header file information in the .DEC file?
It doesn't seem to really be used for anything specific. If I declare a header file and it doesn't exist, I don't get an error. Tim -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] EmulatorPkg
Andrew - Do you have any docs to start me on trying a X64 version of EmulatorPkg? 1) Starting points? 2) Where would I put the native IA32/X64 EXE INFs, etc? Thanks, Tim -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] FeatureFlagExpress
Liming - So all of the current uses in MdeModulePkg and IntelFrameworkModulePkg have no effect, correct? Tim From: Gao, Liming [mailto:liming@intel.com] Sent: Wednesday, March 19, 2014 12:47 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] FeatureFlagExpress Lewis: No. It is not supported. EDKII INF lists them as the description for PCD relationship. Thanks Liming From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Wednesday, March 19, 2014 2:23 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] FeatureFlagExpress I note that FeatureFlagExpress is defined in the .INF grammar for [Source] and [Pcd] and [Protocol] sections. I also recall (from Mike Kinney) that these aren't currently supported. The spec says they are currently ignored. However, I see that they are now used in multiple places in MdeModulePkg. What I want to know is: to what extent are they actually supported. And, if so, do we expect an update to the INF grammar to explicitly define the behavior? As a producer of tools that consume and produce INFs, I'd like to be able to handle EDK2 source without unexpected errors. For example, in CapsuleRuntimeDxe.inf [Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule || gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleReset ## Populate Image requires reset support. Or StatusCodeRuntimeDxe.inf: [Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize |128| gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory I presume means that this PCD is only used if gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleReset is TRUE. Or, in UnicodeCollation: [Protocols] gEfiUnicodeCollationProtocolGuid | gEfiMdeModulePkgTokenSpaceGuid.PcdUnicodeCollationSupport ## PRODUCES gEfiUnicodeCollation2ProtocolGuid | gEfiMdeModulePkgTokenSpaceGuid.PcdUnicodeCollation2Support ## PRODUCES Which only creates a reference to the GUID if the PCD is defined. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] FeatureFlagExpress
I note that FeatureFlagExpress is defined in the .INF grammar for [Source] and [Pcd] and [Protocol] sections. I also recall (from Mike Kinney) that these aren't currently supported. The spec says they are currently ignored. However, I see that they are now used in multiple places in MdeModulePkg. What I want to know is: to what extent are they actually supported. And, if so, do we expect an update to the INF grammar to explicitly define the behavior? As a producer of tools that consume and produce INFs, I'd like to be able to handle EDK2 source without unexpected errors. For example, in CapsuleRuntimeDxe.inf [Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule || gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleReset ## Populate Image requires reset support. Or StatusCodeRuntimeDxe.inf: [Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize |128| gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory I presume means that this PCD is only used if gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleReset is TRUE. Or, in UnicodeCollation: [Protocols] gEfiUnicodeCollationProtocolGuid | gEfiMdeModulePkgTokenSpaceGuid.PcdUnicodeCollationSupport ## PRODUCES gEfiUnicodeCollation2ProtocolGuid | gEfiMdeModulePkgTokenSpaceGuid.PcdUnicodeCollation2Support ## PRODUCES Which only creates a reference to the GUID if the PCD is defined. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] MdeModulePkg: (at least) 4 writes to Flash to update a NV variable in UpdateVariable()
Olivier - Actually, the current NOR technology assumes that we can do a byte level write only when changing bits from 1 to 0. In order to change from 0 to 1, you need to do an erase. I understood (correct me if I'm wrong) that NAND works the opposite way (can change from 0 to 1, but 1 to 0 requires and erase) That is why there is a polarity bit in the FV header, to tell the FV code which way to do it. Tim From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Tuesday, March 11, 2014 7:47 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] MdeModulePkg: (at least) 4 writes to Flash to update a NV variable in UpdateVariable() As Andrew says you have assumed a hardware specific technology (you assume you have SPI Flash which allows to write a single byte in NV memory) to manage your atomicity. For most block devices, it is not possible to update a single byte without reading/writing the full block. It means the current logic of UpdateVariable() is not correct. If we keep the assumption that we can only do block access then it would be more efficient/faster to use a checksum to ensure the consistency of our variables (actually there is a spare field into VARIABLE_HEADER). Most Flash memory needs their block to be erased before to be written. It means with the current flow, we have (example of 256 Byte page): Step 1: Write the header: Erase 256B. Write 256B Step 2: Update the state: Erase 256B. Write 256B Step 3: Write the Data: Erase 256B. Write 256B Step 4: Update the state: Erase 256B. Write 256B From: Andrew Fish [mailto:af...@apple.com] Sent: 11 March 2014 02:29 To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] MdeModulePkg: (at least) 4 writes to Flash to update a NV variable in UpdateVariable() On Mar 10, 2014, at 7:04 PM, Zeng, Star star.z...@intel.commailto:star.z...@intel.com wrote: Hi Olivier, As we know, the BlockSize is the unit of FVB, FVB needs to depend on lower protocol(SPI protocol) to do real write operation, SPI Protocol does not seem to be part of the Open source or industry standard. FirmwareVolumeBlock is the last standardized/open source hop. Thanks, Andrew Fish but the unit of write operation may be one byteimage001.png, or other bytes. Anyway, we should not assume the operation unit of real flash chip. To keep the atomicity, we need to be very careful. Thanks, Star From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Tuesday, March 11, 2014 5:42 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] MdeModulePkg: (at least) 4 writes to Flash to update a NV variable in UpdateVariable() Olivier - I don't have the whole code section memorized, but if I remember right there is the problem when there is a power failure as the variable header is being written. If VAR_HEADER_VALID_ONLY was set in this case, but the entire variable header was not written, wouldn't this be another inconsistent state? Tim From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Monday, March 10, 2014 12:52 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] MdeModulePkg: (at least) 4 writes to Flash to update a NV variable in UpdateVariable() Dear MdeModulePkg maintainers, We have seen on some platforms that flash writing/erasing counts for most of the boot time. We have also noticed UpdateVariable() (in MdeModulePkg/Universal/RuntimeDxe/Variable.c) might make 4 accesses to the same region of Flash to update a non-volatile variable: // 1. Write variable header UpdateVariableStore (..., mVariableModuleGlobal-NonVolatileLastVariableOffset, sizeof (VARIABLE_HEADER), (UINT8 *) NextVariable ); // 2. Set variable state to header valid NextVariable-State = VAR_HEADER_VALID_ONLY; UpdateVariableStore (..., mVariableModuleGlobal-NonVolatileLastVariableOffset + OFFSET_OF (VARIABLE_HEADER, State), sizeof (UINT8), NextVariable-State ); // 3. Write variable data UpdateVariableStore (..., mVariableModuleGlobal-NonVolatileLastVariableOffset + sizeof (VARIABLE_HEADER), (UINT32) VarSize - sizeof (VARIABLE_HEADER), (UINT8 *) NextVariable + sizeof (VARIABLE_HEADER) ); // 4. Set variable state to valid NextVariable-State = VAR_ADDED; UpdateVariableStore (..., mVariableModuleGlobal-NonVolatileLastVariableOffset + OFFSET_OF (VARIABLE_HEADER, State), sizeof (UINT8), NextVariable-State ); I understand the 4 steps are to prevent the flash to be inconsistent in case of accidental reset. Actually the steps 1 and 2 could easily be merged (ie: do 'NextVariable-State = VAR_HEADER_VALID_ONLY' in step 1). For most variables, it is likely these 4 accesses would be into the same block of flash. It means this block of flash would be written 4 times. Could we potentially check if we do a write to the same block of flash and do a single
Re: [edk2] MdeModulePkg: (at least) 4 writes to Flash to update a NV variable in UpdateVariable()
Olivier -
I don't have the whole code section memorized, but if I remember right there is
the problem when there is a power failure as the variable header is being
written. If VAR_HEADER_VALID_ONLY was set in this case, but the entire variable
header was not written, wouldn't this be another inconsistent state?
Tim
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Monday, March 10, 2014 12:52 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] MdeModulePkg: (at least) 4 writes to Flash to update a NV
variable in UpdateVariable()
Dear MdeModulePkg maintainers,
We have seen on some platforms that flash writing/erasing counts for most of
the boot time.
We have also noticed UpdateVariable() (in
MdeModulePkg/Universal/RuntimeDxe/Variable.c) might make 4 accesses to the same
region of Flash to update a non-volatile variable:
// 1. Write variable header
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset,
sizeof (VARIABLE_HEADER),
(UINT8 *) NextVariable
);
// 2. Set variable state to header valid
NextVariable-State = VAR_HEADER_VALID_ONLY;
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset + OFFSET_OF
(VARIABLE_HEADER, State),
sizeof (UINT8),
NextVariable-State
);
// 3. Write variable data
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset + sizeof
(VARIABLE_HEADER),
(UINT32) VarSize - sizeof (VARIABLE_HEADER),
(UINT8 *) NextVariable + sizeof (VARIABLE_HEADER)
);
// 4. Set variable state to valid
NextVariable-State = VAR_ADDED;
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset + OFFSET_OF
(VARIABLE_HEADER, State),
sizeof (UINT8),
NextVariable-State
);
I understand the 4 steps are to prevent the flash to be inconsistent in case of
accidental reset.
Actually the steps 1 and 2 could easily be merged (ie: do 'NextVariable-State
= VAR_HEADER_VALID_ONLY' in step 1).
For most variables, it is likely these 4 accesses would be into the same block
of flash. It means this block of flash would be written 4 times.
Could we potentially check if we do a write to the same block of flash and do a
single write?
For instance (untested code):
BlockSize = Fvb-GetBlockSize ();
BlockStart = mVariableModuleGlobal-NonVolatileLastVariableOffset ~(BlockSize
- 1);
BlockEnd = (mVariableModuleGlobal-NonVolatileLastVariableOffset + VarSize)
~(BlockSize - 1);
if (BlockStart == BlockEnd) {
NextVariable-State = VAR_ADDED;
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset,
VarSize,
(UINT8 *) NextVariable
);
} else {
// 1. Write variable header
NextVariable-State = VAR_HEADER_VALID_ONLY;
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset,
sizeof (VARIABLE_HEADER),
(UINT8 *) NextVariable
);
// 2. Write variable data
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset + sizeof
(VARIABLE_HEADER),
(UINT32) VarSize - sizeof (VARIABLE_HEADER),
(UINT8 *) NextVariable + sizeof (VARIABLE_HEADER)
);
// 3. Set variable state to valid
NextVariable-State = VAR_ADDED;
UpdateVariableStore (...,
mVariableModuleGlobal-NonVolatileLastVariableOffset + OFFSET_OF
(VARIABLE_HEADER, State),
sizeof (UINT8),
NextVariable-State
);
}
Regards,
Olivier
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/1] MdeModulePkg: TerminalDxe: add other text resolutions
It could be a PCD. I would recommend against using EFI_GLYPH_HEIGHT and
EFI_GLYPH_WIDTH, since that is not necessarily the height of the system font.
The correct way is to call the GetFontInfo() function of the HII Font protocol,
with a NULL input for StringFontIn set to NULL. This will return the width and
height of the character cell.
Tim
From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, February 25, 2014 5:45 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH 1/1] MdeModulePkg: TerminalDxe: add other text
resolutions
On Feb 25, 2014, at 5:23 PM, Li, Elvin
elvin...@intel.commailto:elvin...@intel.com wrote:
Laszlo,
Where do you get the video resolution list? I prefer to be more
popular to cover most common resolutions we see.
I wonder if you could add a mode that used the PCD defaults and EFI_GYPH_HIGHT
and EFI_GLYPH_WIDTH to calculate the mode and not need as large a list?
f
## This PCD defines the video horizontal resolution.
# This PCD could be set to 0 then video resolution could be at highest
resolution.
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800|UINT32|0x4009
## This PCD defines the video vertical resolution.
# This PCD could be set to 0 then video resolution could be at highest
resolution.
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600|UINT32|0x400a
Thanks,
Andrew Fish
Thanks
Elvin
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, February 26, 2014 3:00 AM
To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH 1/1] MdeModulePkg: TerminalDxe: add other text
resolutions
When the console output is multiplexed to several devices by ConSplitterDxe,
then ConSplitterDxe builds an intersection of text modes supported by all
console output devices.
Two notable output devices are provided by:
(1) MdeModulePkg/Universal/Console/GraphicsConsoleDxe,
(2) MdeModulePkg/Universal/Console/TerminalDxe.
GraphicsConsoleDxe supports four modes at most -- see
InitializeGraphicsConsoleTextMode():
(1a) 80x25 (required by the UEFI spec as mode 0),
(1b) 80x50 (not necessarily supported, but if it is, then the UEFI spec
requires the driver to provide it as mode 1),
(1c) 100x31 (corresponding to graphics resolution 800x600, which the UEFI
spec requires from all plug-in graphics devices),
(1d) full screen resolution, derived form the underlying GOP's
horizontal and vertical resolutions with division by EFI_GLYPH_WIDTH
(8) and EFI_GLYPH_HEIGHT (19), respectively.
The automatic full screen resolution makes GraphicsConsoleDxe's character
console very flexible. However, TerminalDxe (which runs on serial ports) only
provides the following fixed resolutions -- see
InitializeTerminalConsoleTextMode():
(2a) 80x25 (required by the UEFI spec as mode 0),
(2b) 80x50 (since the character resolution of a serial device cannot be
interrogated easily, this is added unconditionally as mode 1)
(2c) modes 2 and above come from mTerminalConsoleModeData. This table
currently only contains one mode, 100x31.
When ConSplitterDxe combines (1) and (2), multiplexing console output to both
video output and serial terminal, the list of commonly supported text modes
(ie. the intersection) comprises:
(3a) 80x25, unconditionally, from (1a) and (2a),
(3b) 80x50, if the graphics console provides at least 640x950 pixel
resolution, from (1b) and (2b)
(3c) 100x31, if the graphics device is a plug-in one (because in that case
800x600 is a mandated pixel resolution), from (1c) and (2c).
Unfortunately, the full screen resolution (1d) of the GOP-based text console
is not available in general.
Mitigate this problem by extending mTerminalConsoleModeData with a handful of
text resolutions that are derived from widespread maximal pixel resolutions.
This way TerminalDxe won't cause ConSplitterDxe to filter out the most frequent
(1d) values from the intersection, and eg. the MODE command in the UEFI shell
will offer the best (ie. full screen) resolution too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.commailto:ler...@redhat.com
---
.../Universal/Console/TerminalDxe/Terminal.c | 37 +-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
index 14f49ee..67dc369 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
@@ -96,7 +96,42 @@ TERMINAL_DEV mTerminalDevTemplate = { };
TERMINAL_CONSOLE_MODE_DATA mTerminalConsoleModeData[] = {
- {100, 31},
+ { 100, 25 }, // from graphics resolution 800 x 480 { 100, 31
+ }, // from graphics resolution 800 x 600 { 104, 32 }, // from
+ graphics resolution 832 x 624 { 120, 33 }, // from graphics
+
Re: [edk2] UEFI writing protection variable
Miguel - There is no provision for such protection in UEFI. UEFI does not provide the type of secure environment that would enforce such protections. For example, another driver executing could look in your driver, since they share a single memory space. All keys used by the UEFI firmware are public keys, as you noted. Tim From: miguelro...@ua.pt [mailto:miguelro...@ua.pt] Sent: Friday, February 21, 2014 2:42 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] UEFI writing protection variable Hello all, I'm a master's student and for my final thesis I am writing a UEFI Application/Driver. In my UEFI Application/Driver I need to have access to a non volatile variable that must be visible (write permission) only to my UEFI Application/Driver and invisible (no read permission) for other drivers, applications or operating systems. Does UEFI provide any mechanism to create a non volatile variable (or some kind of data storage) that is only accessible to my driver? Can I have some hints on how to do this? I have been reading about the Secure Boot secure variables and Key Managment Service but, the first does not seem to provide reading protection and the second does not specify read/write protections for the saved keys. Regards Miguel Rocha -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] UEFI writing protection variable
Good points, Brian. The typical solution to this sort of problem requires hardware support, where a key is hidden in a piece of hardware that is readable after reset but then can be locked. In this way, once your driver reads the key from the lockable storage, it then locks it, uses it and then scrubs all references from memory. This does not protect you against agents that run before you, or hardware snooping devices, but it does protect you from anyone running after you. Tim -Original Message- From: Brian J. Johnson [mailto:bjohn...@sgi.com] Sent: Friday, February 21, 2014 9:40 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] UEFI writing protection variable On 02/21/2014 04:41 AM, miguelro...@ua.pt wrote: Hello all, I'm a master's student and for my final thesis I am writing a UEFI Application/Driver. In my UEFI Application/Driver I need to have access to a non volatile variable that must be visible (write permission) only to my UEFI Application/Driver and invisible (no read permission) for other drivers, applications or operating systems. Does UEFI provide any mechanism to create a non volatile variable (or some kind of data storage) that is only accessible to my driver? Can I have some hints on how to do this? I have been reading about the Secure Boot secure variables and Key Managment Service but, the first does not seem to provide reading protection and the second does not specify read/write protections for the saved keys. You could encrypt the variable's contents with a key known only to your driver. That's the scheme used for updating the secure Machine Owner Key (MOK) database from a running OS: encrypt the data into a non-secure transit variable, then reboot, decrypt, and validate it from a signed driver in a secure environment. As Tim Lewis pointed out, this wouldn't protect you from all threats, but at least it could ensure that only signed/trusted software is running at the point you decrypt your data. See the IDF presentations and other info linked from http://uefidk.intel.com/blog/using-mok-and-uefi-secure-boot-suse-linux (I'm not a security researcher, so take all the above with a grain of salt. I just thought the scheme presented at IDF was interesting, and it seemed applicable.) -- Brian J. Johnson I use not only the brains I have, but all I can borrow. -- Woodrow Wilson -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] ShellPkg: Fix changing to file system with 2 colons like fs0::
It looks like this tries to use UnicodeCollation instead of UnicodeCollation2. Did I read this wrong? Tim From: Carsey, Jaben [mailto:jaben.car...@intel.com] Sent: Tuesday, February 11, 2014 3:38 PM To: Bjorge, Erik C Cc: edk2-devel@lists.sourceforge.net Subject: [edk2] ShellPkg: Fix changing to file system with 2 colons like fs0:: Erik, Can you review this patch? ShellPkg: Fix changing to file system with 2 colons like fs0:: Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey jaben.car...@intel.commailto:jaben.car...@intel.com -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] ShellPkg: Fix changing to file system with 2 colons like fs0::
Sorry, I think it is 15220. It also looks like gUnicodeCollation is already initialized at this point (from UefiShellCommandLib) Tim From: Carsey, Jaben [mailto:jaben.car...@intel.com] Sent: Tuesday, February 11, 2014 3:59 PM To: edk2-devel@lists.sourceforge.net; Bjorge, Erik C Subject: Re: [edk2] ShellPkg: Fix changing to file system with 2 colons like fs0:: Tim, I don't see anything like that. It changes the if block to require that the last character in the string be a colon, and that the first colon in the string must be the last character in the string. No Unicode collation at all... -Jaben From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Tuesday, February 11, 2014 3:55 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; Bjorge, Erik C Subject: Re: [edk2] ShellPkg: Fix changing to file system with 2 colons like fs0:: It looks like this tries to use UnicodeCollation instead of UnicodeCollation2. Did I read this wrong? Tim From: Carsey, Jaben [mailto:jaben.car...@intel.com] Sent: Tuesday, February 11, 2014 3:38 PM To: Bjorge, Erik C Cc: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] ShellPkg: Fix changing to file system with 2 colons like fs0:: Erik, Can you review this patch? ShellPkg: Fix changing to file system with 2 colons like fs0:: Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey jaben.car...@intel.commailto:jaben.car...@intel.com -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] BaseTools maintainer
Is there any plan to update the FDF and VFR specifications to match the recent changes to the BaseTools repository? I noticed that there have been changed to the capsule creation (to support adding a binary) and the VFR (to support warning_if). Thanks, Tim -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Monday, December 30, 2013 6:29 AM To: Liu, Yingke D; 'Jordan Justen' Cc: edk2-devel@lists.sourceforge.net; edk2-buildtools-de...@lists.sourceforge.net Subject: Re: [edk2] BaseTools maintainer Would it be possible to sync the BaseTools in Tianocore. The version used by EDK2 is 2610 (17/12/2013) while the latest version is 2630 (29/12/2013). The change log is: - Fixed and Update PCD support - Removing unrecognized 'ULL' from assembly files - Add GCC48 - Add ACPI support to ARM toolchains - Fix a bug about large file support. Thanks, Olivier From: Liu, Yingke D [yingke.d@intel.com] Sent: 17 June 2013 06:21 To: 'Jordan Justen' Cc: edk2-devel@lists.sourceforge.net; edk2-buildtools-de...@lists.sourceforge.net Subject: Re: [edk2-buildtools] BaseTools maintainer Hi Jordan, The patch from Garrett Kirkendall looks good to me. Reviewed-by: Liu Yingke yingke.d@intel.com Best Regards, Dennis -Original Message- From: Jordan Justen [mailto:jljus...@gmail.com] Sent: Sunday, June 16, 2013 12:38 AM To: Liu, Yingke D Cc: edk2-buildtools-de...@lists.sourceforge.net; edk2-devel@lists.sourceforge.net Subject: Re: BaseTools maintainer On Fri, Jun 14, 2013 at 1:13 PM, Jordan Justen jljus...@gmail.com wrote: On http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDKII_ Packages we have yingke (Yingke Liu) listed as the maintainer. Is this up to date? (yingke last committed in 2011.) Hmm. I don't know what I was looking at before. I'm seeing a commit as recently as April. Sorry! I'm wondering, as we have a recent contribution from Garrett Kirkendall which probably should get a Reviewed-by or Acked-by from the BaseTools maintainer. Does this contribution look okay to you? -Jordan -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ edk2-buildtools-devel mailing list edk2-buildtools-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel -- 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 -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] How to debug application running in secmain with WinDbg/VS2010
Another note on this: VS2010 debugs by loading the DLL version of your module, if it can find it, instead of the one in the FV. It finds the DLL by examining the debug record in the EXE in the FV. The DLL file must be in the same directory as the PDB file specified. So, if you try to load a random .efi and don't have the build DLL and PDB in the location, it won't do source level debug. Tim -Original Message- From: Carsey, Jaben [mailto:jaben.car...@intel.com] Sent: Friday, December 13, 2013 1:47 PM To: Jordan Justen Cc: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] How to debug application running in secmain with WinDbg/VS2010 In visual studio, you can press F9 and get a breakpoint on the line of code you cursor is on... that way there is no special code to add/remove... -Original Message- From: Jordan Justen [mailto:jljus...@gmail.com] Sent: Friday, December 13, 2013 1:01 PM To: Carsey, Jaben Cc: Amit Kulkarni; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] How to debug application running in secmain with WinDbg/VS2010 Importance: High On Fri, Dec 13, 2013 at 12:40 PM, Carsey, Jaben jaben.car...@intel.com wrote: I have always found the following works for me. 1) Set the breakpoint How did you set a breakpoint initially? I seem to recall for NT32 I would add a call to CpuBreakpoint and then rebuild NT32. Then when 'build run' was executed an exception would happen. This would allow VS to open to debug the code, and it would have symbols available. VS debug could then set additional breakpoints in the code as usual. I would imagine WinDbg could also be used to debug the application as well and it should be able to load the symbols like VS. -Jordan 2) Do the build run 3) I attach the debugger as soon as I can to secmain.exe Then when the module with the breakpoint loads visual studio changes the color of the breakpoint to indicate that it's possible to hit... -Jaben From: Andrew Fish [mailto:af...@apple.com] Sent: Friday, December 13, 2013 11:51 AM To: Amit Kulkarni; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] How to debug application running in secmain with WinDbg/VS2010 On Dec 13, 2013, at 2:53 AM, Amit Kulkarni amit_balasaheb2...@yahoo.com wrote: Hi All, I am trying to debug hello sample from EADK running in NT32(secmain) using WinDbg VS2010 but my breakpoint does not hit. I observed that lm command does not show hello in loaded module list. An Application loads, executes, and then unloads. So if the Application is not running you will not see it in the list. So is it possible to debug in NT32(secmain) using WinDbg/VS2010? Is there any way to do source level debugging while running in secmain? So it's been a lot of years since I used Visual Studio, but NT32 is just an application so you should be able to debug it directly with VS2010. I'm guessing the default build of NT32 does not support WinDbg as you need to do special magic(tm) to load symbols of EFI modules in VS2010 (Thus the standard WinDbg serial stuff is probably not hooked in). The LoadLibraryEx() call in SecNt32PeCoffRelocateImage in https://svn.code.sf.net/p/edk2/code/trunk/edk2/Nt32Pkg/Sec/SecMain.c is what makes symbols visible to VS2010. SecMain is a Windows Application so you should not have any issues debugging that directly with VS2010. To use WinDbg I think you need to use OVFM and establish a serial connection with the VM. Thanks, Andrew Fish Thanks Regards, Amit Kulkarni. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.c lktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.c lktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Rapidly troubleshoot problems before they affect your business.
Re: [edk2] GUID for Flattened Device Tree in configuration table.
Leif --
The reason that Liming mentions this is that we've had some bad experiences
with namespace collision for the #defines associated with GUIDs. For example,
Intel's Framework specifications used this, so when the PI specification tried
to use a name for similar functionality, it could not (which is why you see 2
appended to protocol names when there was never a 1). Some other groups
(including, for example, TCG) have decided that they would like to use EFI_ as
a namespace for their specific context. And Intel has made some slips in this
area within the UEFI universe, esp. in the EDK2 implementation.
Consider the case where the UEFI specification might want to implement some
UEFI device tree protocol or GUID. The name EFI_DEVICE_TREE_GUID defined
implies that it is an EFI device tree, when, in fact, it is merely produced by
an EFI component. I would suggest (at least) further qualifying the name to
make it clear which agent in the ecosystem owns the definition of the device
tree.
Tim
-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: Monday, December 09, 2013 9:41 AM
To: Gao, Liming
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] GUID for Flattened Device Tree in configuration table.
Thank you.
The code below is taken from the GRUB or Linux efi.h header, and as
such prepends EFI_ for namespace reasons.
/
Leif
On Mon, Dec 09, 2013 at 02:18:20PM +, Gao, Liming wrote:
Yes. GUID format is correct. For GUID macro, it doesn't belong to UEFI spec.
So, I suggest to remove prefix EFI_.
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Monday, December 9, 2013 8:45 PM
To: Leif Lindholm; edk2-devel@lists.sourceforge.net; Roy Franz
Subject: [edk2] GUID for Flattened Device Tree in configuration table.
Hi all,
We (Linaro) are working on support for passing a flattened device tree
(FDT) via the UEFI configuration table. Before we publish patches, I want to
make sure that we've generated a valid UUID for the FDT entry.
We used the Linux tool uuidgen and it produced this:
#define EFI_DEVICE_TREE_GUID \
{ \
0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa,
0xe0 } \
}
I'm asking here to make sure we haven't made a fundamental error that gets
implemented by some firmware. Have we done the right thing?
g.
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] ARM UEFI BIOS Trusted firmware
Eugene - One of the issues for the SMM specification and TZ is the single-threaded nature. While most of ARM's TrustZone infrastructure can be mapped easily to SMM, the possibility of having cores in TZ and out of TZ simultaneously, or more than one core in TZ at the same time raises some interesting issues (resource contention, etc.) Tim From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Thursday, December 05, 2013 9:29 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer * It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? * Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard way for all of us to adopt here. Before creating yet another method I was hoping to hear from experts on any common ground for such feature implementation Thanks again for all your help and comments -Alok -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Wednesday, December 04, 2013 7:40 AM To: tiger...@viatech.com.cnmailto:tiger...@viatech.com.cn; edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] SEC code support big.LITTLE tech? Hi Tiger, The ARM recommendation to manage secondary CPUs (the primary CPU is the CPU that runs UEFI and starts your OS kernel) is to use PSCI (Power State Coordination Interface - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022b/index.h tml). PSCI uses SMCs (Secure Memory Calls) to bring up secondary CPUs (CPU_UP / CPU_DOWN). This code runs in Secure World while UEFI runs in Non-Secure World. For the story... I started to implement PSCI support in Tianocore source code (in ArmPlatformPkg/Sec). But the EDK2 framework (PCD/Library/INF/FDF etc) had made the code quite hard to maintain. So, I wrote a new secure firmware framework project to handle this support. This firmware is not Open Source (available in binary format for TC2 only). A new project has been started by ARM Ltd last month. It is an Open Source implementation of the Trusted/Secure Firmware: https://github.com/ARM-software/arm-trusted-firmware Unfortunately at this stage, 32bit is not supported (only AArch64 is supported). And as far as I know there is no plan to add 32bit support by ARM Ltd in the short term. The current ArmPlatformPkg/Sec has support to hold the secondary cores in WFI. But it does not support PSCI. The current support might be sufficient
Re: [edk2] ARM UEFI BIOS Trusted firmware
Vincent - But the multiple in-TZ cores is problematic currently. There is no concept of multiple stacks, or multiple copies of SMST (consider the CurrentCpu field). Also, there is no concept of mutexes, or yielding for these cores, a problem in high reliability systems. Many ARM configurations also allow a separate, lower-privileged, 3rd party OS to be running on the secure side The in and out of TZ problem occurs if there are hardware resources which must be shared between TZ and non-TZ. This is a common case on PC (CMOS, EC or SMBus). In the ARM world it happens when a TZ OS is performing some sort of secure task. An analogous case would be a S3 bug fix workarounds. What happens when the secure OS is performing a secure task, but the other OS asks for a shutdown? Back to ACPI Global Lock? Tim From: Zimmer, Vincent [mailto:vincent.zim...@intel.com] Sent: Thursday, December 05, 2013 10:01 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Tim- Not sure if this helps, but recall that in PI1.2.1 we introduced concept of # of CPU's in SMM can be # of CPU's in platform w/ M731 NumberOfCpus clarification, so PI1.2.1+ can support models of some inside/some outside of this alternate CPU mode. So I think your point on 'in TZ and out of TZ simultaneously' can be supported by the PI DXE SMM software model (replace TZ w SMM in that quote). Vincent From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, December 05, 2013 9:39 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Eugene - One of the issues for the SMM specification and TZ is the single-threaded nature. While most of ARM's TrustZone infrastructure can be mapped easily to SMM, the possibility of having cores in TZ and out of TZ simultaneously, or more than one core in TZ at the same time raises some interesting issues (resource contention, etc.) Tim From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Thursday, December 05, 2013 9:29 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer * It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? * Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard
Re: [edk2] Getting PCD values for tools that post process the build.
Andrew -- That's how we do it :-) Tim -Original Message- From: Andrew Fish [mailto:af...@apple.com] Sent: Tuesday, December 03, 2013 11:19 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] Getting PCD values for tools that post process the build. Is there a recommended solution to get PCD values for consumption in a post build step? The only thing I could think of is to post process the build log? Thanks, Andrew Fish -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Hii and EFI Variables
Ben -
When you say I do not use a Var Store what do you mean? Why not use a
NAME_VALUE var store, instead of the traditional buffer var store? The Name
Value does not even assume that it is a bucket of bytes (thus, no offsets).
Actually, the Form Browser does not (for the most part) save anything to UEFI
variables, that is the responsibility of the driver. So you can decide when, if
and how much of the data comes from a UEFI variable.
Tim
From: Ben Schroeder [mailto:ben...@mellanox.com]
Sent: Wednesday, November 13, 2013 7:44 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables
Eric,
In ExtractConfig function of HII config access protocol, I am required to
return a ConfigResp
This header includes the following 3 fields:
GuidHdr ::= 'GUID='Guid
NameHdr ::= 'NAME='String
PathHdr ::= 'PATH='UEFI binary Device Path represented as hex
number
Assuming I do not use a Var Store, but decide to save data locally -
How should I fill the GUID and Name fields?
Thanks,
Ben.
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Friday, November 08, 2013 4:11 AM
To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables
Ben,
Add my comments below.
Thanks,
Eric
From: Ben Schroeder [mailto:ben...@mellanox.com]
Sent: Thursday, November 07, 2013 11:53 PM
To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables
Let me clarify my third question:
The example shows code that when receiving a NULL ConfigRequest request
string in ExtractConfig, will build a ConfigHdr.
This ConfigHdr will be used to construct a ConfigResp response string that
holds the fields and data of this VFR Form, needed by ExtractConfig().
I would like to continue to support this option of NULL request strings, but
stop using EFI Variables.
Because the function HiiConstructConfigHdr accepts a GUID as a parameter, I am
not sure if it would still be possible.
If so, what GUID and Name would I pass to HiiConstructConfigHdr function so
that I may continue support this feature?
Thanks,
Ben
From: Ben Schroeder [mailto:ben...@mellanox.com]
Sent: Thursday, November 07, 2013 5:39 PM
To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: [edk2] Hii and EFI Variables
Hi,
First Question:
The examples I have seen for HII Config Access Protocol have used an EFI
Variable to store the data and retrieve it.
Is it possible to just use a defined structure and set/get the values from it.
It doesn't seem that GetVariable/SetVariable are necessary if I can just save
the values in a struct for my driver use.
Then I can pass these values to BlockToConfig as needed.
Is this possible? Is there anything that requires me to use EFI variables in
junction with HII config access protocol.
[[[Eric]]] It's ok, ExtractConfig/RouteConfig is used by browser to save/get
data for Hii driver, hii driver can decide where to save the data. It just need
to make sure the data can save and retrieve.
Second Question (about HiiConstructConfigHdr):
EFIAPI
HiiConstructConfigHdr (
IN CONST EFI_GUID *Guid, OPTIONAL
IN CONST CHAR16*Name, OPTIONAL
IN EFI_HANDLE DriverHandle
)
It takes a Guid and a Name. I assume this is the GUID of an EFI var store,
otherwise why would you need a name?
Or is it the GUID of the VFR Form?
[[[Eric]]] When you define a varstore, you need to input the guid and name,
there are the tags for this varstore. Here your input are the guid and name for
this varstore.
Last Question: (concerning ExtractConfig() from ConfigAccessProtocol)
The following code is taken from DriverSampleDxe.
Assuming I don't use EFI Variables. I also assume I would still need take care
of the even of a NULL request string, and populate the entire configuration
header.
How what I go about this if I don't use EFI VarStore? (assuming it's not
necessary to work with HII)
if (Request == NULL) {
//
// Request is set to NULL, construct full request string.
// Allocate and fill a buffer large enough to hold the ConfigHdr template
// followed by OFFSET=0WIDTH= followed by a
Null-terminator
//
ConfigRequestHdr = HiiConstructConfigHdr (gDriverSampleFormSetGuid,
VariableName, PrivateData-DriverHandle[0]);
Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
ConfigRequest = AllocateZeroPool (Size);
ASSERT (ConfigRequest != NULL);
AllocatedRequest = TRUE;
UnicodeSPrint (ConfigRequest, Size, L%sOFFSET=0WIDTH=%016LX,
ConfigRequestHdr, (UINT64)BufferSize);
FreePool (ConfigRequestHdr);
ConfigRequestHdr = NULL;
}
[[[Eric]]] The guid and name is the varstore tags.
Thanks,
Ben.
--
DreamFactory - Open Source REST JSON Services for HTML5 Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app
Re: [edk2] Problems in Image Decoding in HII Database code
Eric - For example, it is possible to encode SKIP1 as EXT4 with BlockType2 set to IIBT_SKIP1. This is consistent with the pattern found in all other HII database block types. The purpose of EXT1, EXT2 and EXT4 is to provide an alternate encoding of IIBT blocks where the size is explicit. The other blocks have an implicit type. UCST recognized this weakness, since in limits extensibility, and provided the alternate forms. Please see, for example, Figure 104 for SIBT blocks The point is: ImageId should not be incremented for EXT1, EXT2 or EXT4. Tim From: Dong, Eric [mailto:eric.d...@intel.com] Sent: Monday, November 04, 2013 1:32 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Problems in Image Decoding in HII Database code Hi Tim, Add my comments below. Thanks, Eric From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Friday, November 01, 2013 1:16 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] Problems in Image Decoding in HII Database code We noticed that the current HII Database code that processes the image packages incorrectly increments the ImageId for EXT1, EXT2 and EXT4 blocks. The specification allows these forms of the IIBT block types to be used for any other blocks, including DUP and SKIP1 and SKIP2. But currently, EXT1 does this: case EFI_HII_IIBT_EXT1: Length8 = *(ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8)); ImageBlock += Length8; ImageIdCurrent++; break; case EFI_HII_IIBT_EXT2: CopyMem ( Length16, ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8), sizeof (UINT16) ); ImageBlock += Length16; ImageIdCurrent++; break; case EFI_HII_IIBT_EXT4: CopyMem ( Length32, ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8), sizeof (UINT32) ); ImageBlock += Length32; ImageIdCurrent++; break; Notice the inconsistent behavior here between EXT1, EXT2 and EXT4. EXT1 does not copy the block, but EXT2 and EXT4 do. [[[Eric]]] I think CopyMem function is used to fix the potential alignment issue raised in IPF platform. Also, notice that ImageIdCurrent is incremented. This leads to inconsistent behavior when SKIP1 and SKIP2 or DUP are encoded using any of these forms. [[[Eric]]] Still not catch your means, what's the relationship between Ext1, EXT2, EXT4 with SKIP1, SKIP2 and DUP? You may ask: why would anyone do this? Well, one of the ways we are considering to extend the image package format is adding new image types (such as IIBIT_32BIT). One of the problems with this is that older tools may correctly skip the unknown block, but they the ImageId assignment would be incorrect (since the older tools don't know it should be incremented). So the solution we were thinking is that new image types should be followed by a IIBT_SKIP1 (1) so that even older tools would correctly handle the increment of the ImageId. But of course, that will not work if the current EDK2 implementation makes all EXT4 and EXT2 increment the ImageId! Tim -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] Problems in Image Decoding in HII Database code
We noticed that the current HII Database code that processes the image packages incorrectly increments the ImageId for EXT1, EXT2 and EXT4 blocks. The specification allows these forms of the IIBT block types to be used for any other blocks, including DUP and SKIP1 and SKIP2. But currently, EXT1 does this: case EFI_HII_IIBT_EXT1: Length8 = *(ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8)); ImageBlock += Length8; ImageIdCurrent++; break; case EFI_HII_IIBT_EXT2: CopyMem ( Length16, ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8), sizeof (UINT16) ); ImageBlock += Length16; ImageIdCurrent++; break; case EFI_HII_IIBT_EXT4: CopyMem ( Length32, ImageBlock + sizeof (EFI_HII_IMAGE_BLOCK) + sizeof (UINT8), sizeof (UINT32) ); ImageBlock += Length32; ImageIdCurrent++; break; Notice the inconsistent behavior here between EXT1, EXT2 and EXT4. EXT1 does not copy the block, but EXT2 and EXT4 do. Also, notice that ImageIdCurrent is incremented. This leads to inconsistent behavior when SKIP1 and SKIP2 or DUP are encoded using any of these forms. You may ask: why would anyone do this? Well, one of the ways we are considering to extend the image package format is adding new image types (such as IIBIT_32BIT). One of the problems with this is that older tools may correctly skip the unknown block, but they the ImageId assignment would be incorrect (since the older tools don't know it should be incremented). So the solution we were thinking is that new image types should be followed by a IIBT_SKIP1 (1) so that even older tools would correctly handle the increment of the ImageId. But of course, that will not work if the current EDK2 implementation makes all EXT4 and EXT2 increment the ImageId! Tim -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Trying to understand the BOXDRAW_ naming logic?
Actually, it says: if you are at a corner, where do the legs go. Legs going down and right is in the upper-left corner. Legs going up-right is in the lower-left. From: Carsey, Jaben [mailto:jaben.car...@intel.com] Sent: Thursday, September 19, 2013 3:13 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Trying to understand the BOXDRAW_ naming logic? I think this is defined about where you go and hence start. I.e. Draw a box going to bottom right, you start in the upper left... At the same time, it's not overly logical... From: David F. [mailto:df7...@gmail.com] Sent: Thursday, September 19, 2013 2:56 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] Trying to understand the BOXDRAW_ naming logic? Hi, I don't understand why: BOXDRAW_DOWN_RIGHT = upper left corner of a box, BOXDRAW_DOWN_LEFT = upper right corner, BOXDRAW_UP_RIGHT = lower left BOXDRAW_UP_LEFT = lower right What's the logic there (or is this a firmware implementation problem that got it all mixed up) ?? TIA!! -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Multiple Protocols on same driver...
David - Yes, you work your way back from the device path node that has the Block I/O installed on it. Tim From: David F. [mailto:df7...@gmail.com] Sent: Wednesday, September 04, 2013 4:47 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Multiple Protocols on same driver... Using ATA passthru, say you get a device using protocol block_io ... now you use LocalDevicePath to look for the ATA PassThru, it gives you the device handle with one of the ATA PassThru protocols available on that handle. But where is the other one / how would I find it? Or is it simply if you're going to use protocol_block_io as your starting point, it will always work back to the logical form of the ATA pass thru (I'm sure that's the one it would use for raid support) .. if you wanted the other one, you'd have had to work forward, starting by looking or all the ATA PassThru protocols available? On Wed, Sep 4, 2013 at 4:12 PM, Andrew Fish af...@apple.commailto:af...@apple.com wrote: On Sep 4, 2013, at 3:11 PM, David F. df7...@gmail.commailto:df7...@gmail.com wrote: Hi, So when a driver produces two protocol interfaces to access the device using the same protocol GUID. How do you open each instance? They are produced on different handles, as only a single protocol GUID can exist per handle. Say you look for all BlkIo protocol devices via HandleBuffer, then want to look if an ATA or SCSI passthru is attached as well, so use same handle, but ATA pass-through could have multiple interfaces logical/physical ... how do you parse through those? You can read about SCSI Pass Thru in UEFI 2.4 sections 14.1 and 14.2. The Pass Through driver sits on the handle the represents the device, and it is a bus driver that produces child handles with EFI_SCSI_IO_PROTOCOL on them that represent SCSI targets. So the child handles will have the device path of the parent, with a SCSI device path appended to identify the targets. Thanks, Andrew Fish TIA!! -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Understanding the OpenProtocol()/CloseProtocol()/DisconnectController() for Open by Handle.
David - To answer your specific questions: no EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL does not participate in DisconnectController() and no, it cannot reject it somehow. They are simply closed. Why? As the paragraph indicates, this was a part of EFI 1.10 (ancient history) and was worried about EFI 1.02 compatibility. In EFI 1.02 there was only HandleProtocol. None of the Open/Close stuff existed. When the driver model was added in EFI 1.10, there was a problem of backward compatibility: how to handle callers to HandleProtocol (i.e. agents) since they did not register their own handles when they called HandleProtocol. This causes a problem for CloseProtocol, since it wants to cleanly disconnect things, but for people who called HandleProtocol(), there was no record of who should be disconnected. In those cases, the bold text simply indicates that for those people who didn't register themselves (either by using HandleProtocol() or by using the HANDLE_PROTOCOL/GET_PROTOCOL/TEST_PROTOCOL versions of OpenProtocol()), they are just closed without warning. After this point, if the kernel (after DisconnectController() and clearing the HANDLE/GET/TEST folks) still detects that there are outstanding folks (drivers or apps) hanging on to handles, it will return EFI_ACCESS_DENIED From: David F. [mailto:df7...@gmail.com] Sent: Tuesday, September 03, 2013 5:25 PM To: edk2-devel@lists.sourceforge.net Subject: [edk2] Understanding the OpenProtocol()/CloseProtocol()/DisconnectController() for Open by Handle. In the *** BOLD *** sentence below. What exactly are they trying to say? What are the agents? Does this mean EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL also participates in the DisconnectController() call and can reject it some how? Or is the agent the application/process/whatever and it shuts it down or they are closed down cleanly? EFI 1.10 Extension The extension to this service directly addresses the limitations described in the section above. There may be some drivers that are currently consuming the protocol interface that needs to be uninstalled, so it may be dangerous to just blindly remove a protocol interface from the system. Since the usage of protocol interfaces is now being tracked for components that use the OpenProtocol() and CloseProtocol() boot services, a safe version of this function can be implemented. Before the protocol interface is removed, an attempt is made to force all the drivers that are consuming the protocol interface to stop consuming that protocol interface. This is done by calling the boot service DisconnectController() for the driver that currently have the protocol interface open with an attribute of EFI_OPEN_PROTOCOL_BY_DRIVER or EFI_OPEN_PROTOCOL_BY_DRIVER | EFI_OPEN_PROTOCOL_EXCLUSIVE. If the disconnect succeeds, then those agents will have called the boot service CloseProtocol() to release the protocol interface. *** Lastly, all of the agents that have the protocol interface open with an attribute of EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL, EFI_OPEN_PROTOCOL_GET_PROTOCOL, or EFI_OPEN_PROTOCOL_TEST_PROTOCOL are closed. *** If there are any agents remaining that still have the protocol interface open, the protocol interface is not removed from the handle and EFI_ACCESS_DENIED is returned. In addition, all of the drivers that were disconnected with the boot service DisconnectController() earlier, are reconnected with the boot service ConnectController(). If there are no agents remaining that are consuming the protocol interface, then the protocol interface is removed from the handle as described above. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Mixed Section Types for PCD
Chip - It is legal. The types that are listed in the .dec file limit the types that a .dsc file can use. If none is specified in the .dsc file, then the first one will be used by default. So, for example, you may want to allow a .dsc file to support either Dynamic, DynamicEx or FixedAtBuild. So the .dec file lists all three. But if the .dsc file tries to use Patchable, it will fail. So Set will not work on FixedAtBuild, right, because it is defined as CONST. So you need to change the type in the .dsc file to Dynamic or DynamicEx or Patchable (actually, I'm not sure if Patchable generates a CONST or not) Tim From: Chip Ueltschey [mailto:chipj...@gmail.com] Sent: Wednesday, August 28, 2013 5:26 PM To: edk2-devel@lists.sourceforge.net Subject: [edk2] Mixed Section Types for PCD Is it legal to do this in a DEC file? [PcdsFixedAtBuild,PcdsPatchableInModule,PcdsDynamic] That seems suspect since a PcdsFixedAtBuild type will not allow set, but a PcdsDynamic will allow set. What is AutoGen supposed to do? Currently, I have an error where the C code wants to set a PCD in this section. Thanks, -chip -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
