Reviewed-by: Ye Ting
-Original Message-
From: Long, Qin
Sent: Wednesday, April 26, 2017 12:06 AM
To: Ye, Ting ; edk2-devel@lists.01.org
Subject: [Patch] CryptoPkg/SmmCryptLib: Enable HMAC-SHA256 support for SMM.
Enable HMAC-SHA256 cipher support in SmmCryptLib instance.
Cc: Ting Ye
C
Laszlo,
There is no platform policy in the UEFI spec by design. The spec is policy
agnostic, as an ATM policy would be different from a server, etc. It's all
implementation choice.
Sent from my iPad
> On Apr 26, 2017, at 10:40 PM, Ni, Ruiyu wrote:
>
> Laszlo,
> I believe the "Unable to boot"
Laszlo,
I believe the "Unable to boot" message was added by intention.
I just checked the UEFI Spec Boot Manager chapter again, still I didn't
find any wording to say what to do, when boot and recovery failure
happens.
Putting "Unable to boot" message there is to tell platform developer
that syst
In case of the DHCP and PXE services on different servers,PXEv6 boot will
failure when DhcpBinl offer received. The issue is caused by the following
reasons:
* PXE Client doesn't append VENDOR_CLASS request parameter, so the
offer replied from DHCP service will not contain VENDOR_CLASS option
(16).
Tim,
Could you use a PCD (for example a GUID value of an FFS file) for the
Logo, and you could use PcdGet() after SetSku() and the GUID value
of the FFS file with the logo would be returned for the lookup.
That way, the need for the relationship information at runtime is
removed and you would get
Mike --
No, the meta-data (in this case, file extension .uni) was used by tools to
determine the format of the file contents, as described in section 2.6.
Little-endian, UCS-2 was assumed.
"When a higher-level protocol supplies mechanisms for handling the endianness
of integral data types, it
Hi Tim,
For UTF-16 files on disk with no BOM, do you follow the
big-endian assumption as documented in the Unicode
Specification Section 3.10, D98?
http://www.unicode.org/versions/Unicode9.0.0/ch03.pdf
Mike
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wed
Mike --
I would prefer to update the docs to match actual industry practice. EDK2 is
not the universe.
Insyde has been using UNI files well before my time here (> 5 years). The fact
that recent specifications or EDK2 tools (2 years) added BOM support it does
not remove the backward compatibil
Mike --
We select logos for SKU C (which is listed as having SKU A and DEFAULT) as its
antecedents. If SKU C does not have a logo, then the SKU from SKU A is used.
And if not from SKU A, then from DEFAULT.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.co
Hi Tim,
How would this relationship information be used in a module?
Do you have an example use case where this relationship
information could be used from the selected SKU? Maybe
there is a different method to solve the same problem?
Please also review the 2nd SKU related RFC titled:
[
Hi Tim,
The recommendation for UTF-8 usage is to not use a BOM, which is why
no BOM for UTF-8 was selected for EDK II.
The current task is to update docs to match the current tool behavior.
The EDK II repos on GitHub have .uni files in UTF-8 format without
a BOM to support easier patch review.
Resolve mainly 'misleading indentation', but also one 'defined but not used'
warning when building with GCC 6 (using GCC5 profile).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm
---
Encountered when attmpting to build AppPkg/Applications/Lua.
StdLib/LibC/
That makes sense. When I wrote that I was unsure where to draw the line between
which characters to print and which to replace.
Reviewed-by: Jaben Carsey
> -Original Message-
> From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> Sent: Wednesday, April 26, 2017 12:59 PM
> To: edk2-devel@
ASCII characters {|}~ should be printed by DumpHex. The problem is that
if you have a string like
{xizzy}~{foo|bar}~{quux}
in the dumped data, it will not appear as such in the *-delimited ASCII
column to the right, but as
.xizzy...foo.bar...quux.
which is less than ideal.
Most of the
Mike --
So your use case for SetSku() is also what we've used.
Generating a simple table that describes the default relationships between SKUs
is helpful:
DEFAULT
A DEFAULT
B A DEFAULT
This could be a #define in the form of a C UINT32 structure initializer:
#define SKUID_DEFAULT_ORDER 0,1,0,
On 04/26/17 21:46, Laszlo Ersek wrote:
> On 04/26/17 21:37, Jeff Westfahl wrote:
>> Hi Laszlo,
>>
>> I liked your description so much that I copied it basically word for
>> word in my PATCH v2 commit description. Is there some way I can
>> attribute this to you in the commit description?
>
> Sure!
On 04/26/17 21:37, Jeff Westfahl wrote:
> Hi Laszlo,
>
> I liked your description so much that I copied it basically word for
> word in my PATCH v2 commit description. Is there some way I can
> attribute this to you in the commit description?
Sure! For example, add:
(parts of) the commit messa
Hi Laszlo,
I liked your description so much that I copied it basically word for word
in my PATCH v2 commit description. Is there some way I can attribute this
to you in the commit description?
Regards,
Jeff
On Wed, 26 Apr 2017, Laszlo Ersek wrote:
On 04/26/17 20:00, Carsey, Jaben wrote:
I
ASCII characters {|}~ should be printed by DumpHex. The problem is that
if you have a string like
{xizzy}~{foo|bar}~{quux}
in the dumped data, it will not appear as such in the *-delimited ASCII
column to the right, but as
.xizzy...foo.bar...quux.
which is less than ideal.
Cc: Ruiyu Ni
On Tue, 2017-04-25 at 12:13 -0700, Richardson, Brian wrote:
> The Ubuntu wiki info isn't quite up to date. We're maintaining updated build
> instructions on the TianoCore Wiki:
> https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-Native-GCC#Ubuntu_1604_LTS__Ubuntu_1610
>
> h
On Mon, 2017-04-24 at 15:56 -0700, Jordan Justen wrote:
> On 2017-04-24 13:41:50, Laszlo Ersek wrote:
> > On 04/18/17 07:29, Prakhya, Sai Praneeth wrote:
> > > Hi All,
> > >
> > > I am facing an issue booting OVMF on qemu, could you please help me?
> > > I have cloned EDKII, and built OVMF for X64
Hi Tim,
If multiple SKUs are present in a FW image, in most cases
A platform specific PEIM detects what SKU is present and
calls SetSku() for the detected SKU. The detection
mechanism is typically very HW specific and may involve
checking straps, GPIOs, or reading ID values from registers.
Bef
Mike --
This is not about files in the EDK II repository. This is about files created
based on the spec, and created with other sets of tools. Go back to early 2015,
to the Build spec (1.22, etc.), Appendix G, which is where the UNI stuff used
to live.
The point is: files which worked before,
Laszlo is correct.
On Wed, 26 Apr 2017, Laszlo Ersek wrote:
On 04/26/17 20:00, Carsey, Jaben wrote:
I think that this is a correct change, but I do not understand the problem this
solves.
The problem is presumably that, if you have a string like
{xizzy}~{foo|bar}~{quux}
in the dumped dat
Tim,
If you look at the entire file history of the EDK II, you will see
that the BOM has always been present in the UTF-16LE formatted files.
The build tools were updated in 2015 to *add* support for UTF-8 file.
The .uni files in the EDK II project were then converted from UTF-16LE
with a BOM to
Mike --
I am saying that creating a relationship between SKUs that cannot be determined
at runtime is a confusing thing to add to the DSC.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 11:40 AM
To: Tim Lewis ; Zeng, S
Tim,
This RFC does not change the DEFAULT behavior. If a PCD value override
is not provided in a SKU, then the DEFAULT value is used. If this is not
how you interpret the RFC, then please provide some clarifications for
the next revision of this RFC.
This RFC is about reducing the number of PCD
Mike --
I understand that EDK2 has decided to add BOM markers two years ago. Adding a
BOM didn't change the default. The problem is (a) there are still hundreds of
files extant in our codebase which were created prior to the 2015 changes and
still in use, and (b) this change is not backward com
Tim,
The document change request under review here is against this 1.3 spec.
Here is the document history on this topic I have been able to find.
The Multi-String .UNI File Format Specification Version 1.3, March 2016
https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specificatio
I understand the purpose. Today there is an assumption that IF not SKU x, then
use SKU DEFAULT. This assumption is used (by us) for many purposes other than
the PCD database.
I'm confused by your statement that "This RFC has no impact to the PCD database
or behavior of PCD services." Currently,
On 04/26/17 20:00, Carsey, Jaben wrote:
> I think that this is a correct change, but I do not understand the problem
> this solves.
The problem is presumably that, if you have a string like
{xizzy}~{foo|bar}~{quux}
in the dumped data, it will not appear as such in the *-delimited ASCII
colu
Hi Tim,
This is not a request for a new change. Instead, the intent of this document
change is to update the document to reflect the implemented behavior of the
EDK II tools. The EDK II tool updates to add UTF-8 file support were completed
with the patches listed below. Notice that the main one
Tim,
Can you please provide more details on your specific concerns along with some
use cases?
This RFC does not change the SKU feature in EDK II. This RFC simply provides a
more
efficient way for a developer to provide PCD values for different SKUs with
fewer PCD
statements in a DSC file.
T
I think that this is a correct change, but I do not understand the problem this
solves.
-Jaben
> -Original Message-
> From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
> Sent: Wednesday, April 26, 2017 10:41 AM
> To: edk2-devel@lists.01.org
> Cc: Jeff Westfahl ; Ni, Ruiyu ;
> Carsey, J
The original UNI specifications (for example, the Multi-String .UNI File Format
Specification, February 2014, Revision 1.0) did not require it, and the fact is
that tools accept files without the BOM happily today.
I believe that requiring the BOM is a good step forward, but assuming UTF-8
when
Tim,
Doesn't that assumption/behavior violate the current spec?
"All the files must begin with a Unicode BOM character."
-Jaben
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 26, 2017 9:15 AM
> To: Kinney, Michael D ; edk2-
> de...@lists.01
ASCII characters {|}~ should be printed by DumpHex.
Cc: Ruiyu Ni
Cc: Jaben Carsey
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl
---
ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
Star --
This assumes that the SKU ID is only used for PCDs, which is not the case. The
SKU ID may be used by other components, and other components may use the
0|DEFAULT rule as well.
1) There is no way to read this defaulting rule at runtime. The information is
buried in the PCD database, bu
Mike --
This breaks our existing build tools, which assume that a file without a BOM is
UTF-16.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Kinney
Sent: Tuesday, April 25, 2017 6:07 PM
To: edk2-devel@lists.01.org
Cc: Jaben Cars
Hi Ray,
the UiApp application is added to the UEFI boot order automatically, but
it is not invoked automatically, even if BDS gives up and hangs with
[Bds] Unable to boot!
For example, consider the following:
- no UEFI bootable application available anywhere in the system,
- ... not even for t
When the PCD value is set to TRUE or FALSE, while it is not exchanged to
its int value, it cause error in the function int(Pcd.DefaultValue, 0).
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 7
On 04/25/17 17:28, Carsey, Jaben wrote:
> I am good with the series. Good research and description!
>
> Reviewed-by: Jaben Carsey
Thank you Jaben and Marvin for the prompt reviews!
Series pushed as 6bbd4a8f5f2a..227fe49d5d4f.
Cheers,
Laszlo
>
>> -Original Message-
>> From: Laszlo Ers
Which directory includes nasm? If it is in L:\edk2-win\nasm, please set
NASM_PREFIX=L:\edk2-win\nasm\
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Jannis ?tjengerdes
>Sent: Wednesday, April 26, 2017 5:37 PM
>To: edk2-devel@lists.01.org
>Subj
Hello,
I want to build an "OVMF"-Image with Windows. I followed your guide
https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems which
works perfectly fine with the MdeModulePkg.
However, if I change that to OvmfPkg/OvmfPkgX64.dsc the build fails. I did
not found any guide providi
Reviewed-by: Liming Gao
>-Original Message-
>From: Zhu, Yonghong
>Sent: Wednesday, April 26, 2017 4:57 PM
>To: edk2-devel@lists.01.org
>Cc: Nikolai SAOUKH ; Gao, Liming
>Subject: [Patch] BaseTools: fix the typo in function name LanuchPostbuild
>
>From: Nikolai SAOUKH
>
>The patch fix fu
From: Nikolai SAOUKH
The patch fix function name typo LanuchPostbuild ==> LaunchPostbuild.
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Nikolai SAOUKH
---
BaseTools/Source/Python/build/build.py | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: Kinney, Michael D
Sent: Wednesday, April 26, 2017 2:33 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ;
Shaw, Kevin W
Subject: [edk2-BuildSpecification PATCH] Add conditional and unused PC
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: Kinney, Michael D
Sent: Wednesday, April 26, 2017 2:57 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ;
Shaw, Kevin W
Subject: [edk2-BuildSpecification PATCH V2 0/2] Add --pcd flag to overr
48 matches
Mail list logo
