ler...@redhat.com; Tim Lewis tim.le...@insyde.com; Gao, Liming
liming@intel.com
Subject: Re: [edk2] BaseTools features: multiple workspaces
On Aug 5, 2015, at 12:16 PM, Jordan Justen jordan.l.jus...@intel.com wrote:
On 2015-08-05 07:06:46, Gao, Liming wrote:
Tim gave another idea
) and the root of the source code. I
don't think the current proposal disambiguates these.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan
Justen
Sent: Monday, August 03, 2015 11:55 AM
To: Tim Lewis tim.le...@insyde.com; Gao, Liming liming
Laszlo,
The PI specification describes DynamicEx PCDs. The PCD protocol is in PI:
volume 3, chapter 8.
All other PCDs are EDK2 artifacts, although some bits have drifted into the
packaging specification.
Tim
-Original Message-
From: edk2-devel
Which instance? There could be dozens: one from the PS/2, one from each USB
device, one from the I2C-attached touch panel, one from the serial port.
gST->ConIn uses a ConSplitter to aggregate all of this input to appear as one.
Tim
-Original Message-
From: edk2-devel
Also, I would point out: If this is a shell app, input redirection works
because the shell replaces these with instances that get the data from the
redirection source.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Miller,
Carl H
Sent:
That looks like it is setting up for a dependency expression. Check your .infs
to see if anyone uses it in their [depex] section.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hamel,
Lee M
Sent: Friday, August 28, 2015 6:24 AM
To:
Lee --
How will you prevent the OS from touching this device? It seems that preventing
the BIOS from touching it only delays your pain ;-)
Can you disable this PCI device entirely? I.e. make it disappear from config
space?
Tim
-Original Message-
From: edk2-devel
Eugene --
Personally, I don't see this as a positive change. The PEI flow from the
earliest days has said: at the end of PEI there is memory and there is a boot
mode (see 11.2.1). You can see this assumption in 2.5 and 9.1 of the PI
specification, where the result of the PEI Foundation (not
terminology muddle makes
it hard to be precise about this kind of thing.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Thursday, December 03, 2015 11:16 AM
To: Tim Lewis <tim.le...@insyde.com>; Laszlo Erse
Laurie --
Did I miss a review period for these? This would help those of us who depend on
the exact syntax of the files for a living :-)
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Jarlstrom, Laurie
Sent: Tuesday, January 05, 2016 3:36
Look at the OsIndications UEFI variable in the UEFI specification.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Stephen
Polkowski
Sent: Tuesday, January 05, 2016 2:23 PM
To: edk2-de...@ml01.01.org
Subject: [edk2] Reboot directly to UEFI
Jaben --
For the record, I think that continuing to add meta-build information to the
.inf files is counter-productive. As a company that has written tools that
conform to the grammar, these extensions to an .ini style file format are
becoming more and more arcane to parse and process. Some
d)
UINT8(0x4B), "S4BKn_ComDataRead00",UINT8(0x80) }
}
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, June 14, 2016 6:56 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>;
e
is that it is not distinguishable from subtraction
expressions.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, June 14, 2016 4:50 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>;
edk2-devel@lists.01
Mike --
We have traditionally used a preprocessor to convert the following into byte
arrays:
UINT8(xx), UINT16(xx), UINT32(xx), UINT64(xx), BOOLEAN(TRUE|FALSE),
GUID(struct-style {} or registry style "xx-yyy..."), "" (ASCII string
no-nullterminator), L"" (UCS16 string no null-terminator),
[mailto:michael.d.kin...@intel.com]
Sent: Tuesday, June 14, 2016 4:50 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>;
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: RE: [RFC] Add more flexible PCD value formats in
ael D
Sent: Tuesday, June 14, 2016 5:22 PM
To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong@intel.com>;
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files
Ti
to handle data structures where
offsets or sizes are required to be embedded. Doesn't work cross-PCDs, but does
in more complicated data structures.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, June 14, 2016 4:50 PM
To: Tim Lewis <tim
Of Kinney,
Michael D
Sent: Wednesday, February 10, 2016 9:41 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael
D <michael.d.kin...@intel.com>
Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE
Hi Tim,
Your description looks correct to me. The cu
We have run into an interesting problem with the PCD database when the PEI and
DXE databases were not built at the same time. This happens with boot-block
type arrangements. This is not a Dynamic vs. DynamicEx issue.
Short form:
1) The standard PCD database for Dynamic/DynamicEx PCDs is
might be to timestamp (rather than assume PEI before
DXE).
Tim
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Sunday, February 14, 2016 9:33 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Tim Lewis
<tim.le...@insyde.com>; edk2-devel@lists.01.org
value.
Tim
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Sunday, February 14, 2016 9:54 PM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>
Subj
y, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, February 17, 2016 9:00 AM
To: Gao, Liming <liming@intel.com>; Tim Lewis <tim.le...@insyde.com>; Zeng,
Star <star.z...@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D
<michael.d.kin...@intel.co
...@intel.com]
Sent: Wednesday, February 17, 2016 6:48 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Tim Lewis
<tim.le...@insyde.com>; edk2-devel@lists.01.org
Subject: RE: PCD Local Token Numbers in PEI/DXE
Could we let PEI PCD database includes all PCDs' information used
I thought I saw a thread talking about this. We are seeing an issue with a
UTF-8 BOM appears at the beginning of a .dec file, even if there are no other
non-ASCII characters. In our case, this causes the parser to bomb out with a
stack trace. This happens to our users in Asia.
I couldn't find
, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, March 01, 2016 3:33 PM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael
D <michael.d.kin...@intel.com>
Subject: RE: BOM in .dec, .dsc, .fdf
Tim,
Those files types are all required to be
]
Sent: Wednesday, March 02, 2016 11:27 PM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Subject: RE: BOM in .dec, .dsc, .fdf
Tim:
So, you suggest to let build tool report the meaning error message if .dec,
.dsc, .
Yes.
Tim
-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Monday, May 09, 2016 6:42 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Tim Lewis
<tim.le...@insyde.com>; Mudusuru, Giri P <giri.p.mudus...@intel.com>;
edk2-devel@lists.01.org
Is this really a good idea, dropping 1.1 support? We don't maintain two
separate trees for our products, just 1. There are several chipsets which have
long life that will need additional features, but are only 1.1
Tim
-Original Message-
From: edk2-devel
u can have both in a single tree.
Thanks,
-Giri
-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, May 3, 2016 4:48 AM
To: Yao, Jiewen <jiewen@intel.com>; edk2-devel@lists.01.org
Cc: Mudusuru, Giri P <giri.p.mudus...@intel.com>; Rangarajan, Ravi P
&l
That works well, thank you
Tim
Sent from my Windows 10 phone
From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Thursday, May 5, 2016 12:07 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao,
Jiewen<mailto:jiewen@intel.com>;
edk2-devel@lists.01.org<mailt
Thank you.
Tim
Sent from my Windows 10 phone
From: Mudusuru, Giri P<mailto:giri.p.mudus...@intel.com>
Sent: Tuesday, May 3, 2016 11:06 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Yao,
Jiewen<mailto:jiewen@intel.com>;
edk2-devel@lists.01.org<mailto:edk2-d
the final file resides. That leads to bad bug
reports, etc.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, May 05, 2016 6:14 PM
To: Tim Lewis <tim.le...@insyde.com>; Mudusuru, Giri P
<giri.p.mudus...@intel.com>; Yao, Ji
product launch. Because of features and
security concerns, we continually upgrade our chipsets to use newer kernel
code. This puts an extra variable.
Regards,
Tim Lewis
CTO, Insyde Software
www.insyde.com
From: Mudusuru, Giri P [mailto:giri.p.mudus...@intel.com]
Sent: Tuesday, May 03, 2016 4:07 PM
Giri --
Is MdePkg the right place for this? This appears to be an Intel-specific
definition, right? I understand that it was in IndustryStandard for
EdkCompatibilityPkg, but it might do better now in the IntelSiliconPkg.
Regards,
Tim
-Original Message-
From: edk2-devel
, 2016 9:29 AM
To: Tim Lewis <tim.le...@insyde.com>; Giri P Mudusuru
<giri.p.mudus...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
Cc: Michael Kinney <michael.d.kin...@intel.com>; Jiewen Yao
<jiewen@intel.com>; Liming Gao <liming@intel.com>
[mailto:jordan.l.jus...@intel.com]
Sent: Monday, August 01, 2016 12:03 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Leif Lindholm
<leif.lindh...@linaro.org>; Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@intel.com>
Cc: Laszlo Ersek <ler...@re
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, July 06, 2016 2:02 PM
To: Tim Lewis <tim.le...@insyde.com>; af...@apple.com
Cc: edk2-devel@lists.01.org; Michael Zimmermann <sigmaepsilo...@gmail.com>;
Daryl McDaniel (edk2-li...@mc2researc
Jaben --
I can certainly recall instances where drivers that publish HII setup pages
load things from the disk (such as when checking for specific file names).
I also seem to recall that the original EDK shell library was designed to that
volume names were simply ignored if the shell protocol
smaller and cleaner shell
applications.
Tim
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, July 06, 2016 2:12 PM
To: Tim Lewis <tim.le...@insyde.com>; af...@apple.com
Cc: edk2-devel@lists.01.org; Michael Zimmermann <sigmaepsilo...@
Jaben --
Are there no shell commands where the standard command-line parameters have
changed?
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey,
Jaben
Sent: Friday, August 05, 2016 10:26 AM
To: Meenakshi Aggarwal
riginal Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey,
Jaben
Sent: Friday, August 05, 2016 12:10 PM
To: Tim Lewis <tim.le...@insyde.com>; Meenakshi Aggarwal
<meenakshi.aggar...@nxp.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org
It appears that this file is not actually used. It is only referenced in the
[Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule in PlatformPkg.fdf. A little
further research shows that an alternate method was used for the actual GOP
binary (see below). A grep of the entire tree shows that no one uses
Also, on many systems, the output will be invisible, since boot screen output
is a platform policy. In general, using DEBUG() is better, since it can either
be redirected to StdErr() or through the serial port.
Tim
-Original Message-
From: edk2-devel
: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Monday, January 23, 2017 1:48 PM
To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; Zeng,
Star <star.z...@intel.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [PATCH
: Monday, January 23, 2017 1:59 PM
To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; Zeng,
Star <star.z...@intel.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [PATCH 3/3] ShellPkg SmbiosView: Add decoding of SMBIOS spe
onal shell in a much more restricted environment.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey,
Jaben
Sent: Monday, January 23, 2017 1:15 PM
To: Tim Lewis <tim.le...@insyde.com>; Ni, Ruiyu <ruiyu...@intel.com>; Zeng,
Sta
Also, in some cases, the text is taken directly from the specification.
Introducing HII strings in order to make these translatable when the source
material is normative doesn't help, IMO.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
I did a simple break apart of a path into map-name and directory.
fs0:\MdeModulePkg
So FileSystem was "fs0:" and Dir was "\MdeModulePkg" and the resulting working
directory was: "fs0:MdeModulePkg" (with escape characters)..
It seems the culprit is in EfiShellSetCurDir:
if
Jaben --
In which cases would you have the Shell protocol present and not have the
Unicode Collation protocol?
By my count, the Shell itself cannot function without it (see
ProcessCommandLine()).
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
Daniil --
Per your point about modules: Adding a dependency expression to a library
should NOT have any effect on an application, since applications do not have
dependency expressions.
So this would indicate that you are trying to link a driver against the
UefiShellLib. Is this correct?
Is it possible that Daniil has UnicodeCollation and not UnicodeCollation2? The
shell itself can handle this case, but the ShellLib cannot.
Tim
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, October 05, 2016 1:58 PM
To: Tim Lewis <tim.le...@insyde.
...@apple.com]
Sent: Wednesday, October 05, 2016 1:59 PM
To: Laszlo Ersek <ler...@redhat.com>
Cc: Tim Lewis <tim.le...@insyde.com>; Carsey, Jaben <jaben.car...@intel.com>;
Shah, Tapan <tapands...@hpe.com>; Daniil Egranov <daniil.egra...@arm.com>;
edk2-devel-01 <edk2-
ionMap.SetFileInfo(*FileHandle, FileInfo);
FreePool(FileInfo);
if (EFI_ERROR (Status2)) {
gEfiShellProtocol->CloseFile(*FileHandle);
}
Status = Status2;
}
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, October 05, 2016 2:17 P
Liming --
Could you change the protocol name, and then use a typedef with the old name
for compatibility?
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
Liming
Sent: Tuesday, September 20, 2016 8:57 PM
To: Boaz Kahana
Eugene --
Since SMM drivers today are actually DXE drivers during the initialization
phase, are you going to (a) have your library check InSmm? or (b) only work
with pure SMM stand-alone drivers?
Thanks,
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
Eugene --
Since the standalone file type isn't yet in the EDK2 code, the build system
will not be able to make this distinction in the library's INF file.
Tim
-Original Message-
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Friday, September 30, 2016 9:51 AM
To: Tim Lewis <tim
.org] On Behalf Of Tim Lewis
Sent: Thursday, October 27, 2016 2:11 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [shell] AliasLower never used in InternalSetAlias
In the function InternalSetAlias, it appears that AliasLower is duplicated
(fromAlias), converted to lower case and freed ,but never
In the function InternalSetAlias, it appears that AliasLower is duplicated
(fromAlias), converted to lower case and freed ,but never actually used. Am I
missing something?
// Convert to lowercase to make aliases case-insensitive
if (Alias != NULL) {
AliasLower = AllocateCopyPool
But the EDK2 registers them as a part of Level 2 supported command
initialization.
ShellCommandRegisterAlias(L"cd ..", L"cd..");
ShellCommandRegisterAlias(L"cd \\", L"cd\\");
According to the SetAlias() description:
An alias is a C-style identifier
The same language is repeated in 3.6.4.
ar...@intel.com]
Sent: Friday, October 28, 2016 8:20 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [shell] AliasLower never used in InternalSetAlias
Tim,
Given that all commands are case insensitive, I couldn't
Sure. I think we should adjust the specification in this case. My problem has
been when someone says "but the EDK2 version does X"
Tim
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Friday, October 28, 2016 9:59 AM
To: Tim Lewis <tim.le.
Did anyone have a chance to look at this EFI_SHELL_PROTOCOL bug in the EDK2
implementation?
Thanks,
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Thursday, October 13, 2016 11:16 AM
To: edk2-devel-01 <edk2-devel@lists
Reviewed-by: Tim Lewis <tim.le...@insyde.com>
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, October 18, 2016 4:07 AM
To: edk2-devel-01 <edk2-de...@ml01.01.org>
Cc: Jaben Carsey <jaben.car...@intel.com>; Ruiyu Ni <ruiyu...@intel.com
In EfiShellGetGuidFromName (ShellProtocol.c), we see:
EfiShellGetGuidFromName(
IN CONST CHAR16 *GuidName,
OUT EFI_GUID *Guid
)
{
EFI_GUID*NewGuid;
EFI_STATUS Status;
if (Guid == NULL || GuidName == NULL) {
return (EFI_INVALID_PARAMETER);
}
Status =
In using AsciiPrint (I'm presuming the behavior is also in Print, but I haven't
tested), I found an interesting behavior for linefeed characters embedded in
strings that are parameters. I post it here just so people who are mystified by
their output can understand it.
Consider this example:
Liming --
And I agree that this should be the behavior. I was surprised by the lack of
translation for the other string printed via %s.
Tim
-Original Message-
From: Gao, Liming [mailto:liming@intel.com]
Sent: Thursday, October 13, 2016 6:24 PM
To: Tim Lewis <tim.le...@insyde.
I prefer the renamed .h file, even though I have substantial investment in the
current infrastructure.
Why? Because engineers don't have time to remember "how does protocol X
translate to header file Y" It should be a consistent rule. How many times have
I needed to grep the header file name
Glad to see this is finally being done!
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Friday, October 14, 2016 2:44 AM
To: edk2-devel@lists.01.org
Cc: Jaben Carsey ; Michael D Kinney
Using the latest Shell build, try:
ls -sfo | parse FileInfo 2
This ends up with a breakpoint when FreePool is called on Shell.c, line 1756.
I'm still debugging, but I wondered if anyone else has seen this?
Also:
ls -sfo > tmp
parse FileInfo 2 < tmp
prints nothing, but
parse tmp FileInfo 2
I have a command like this:
X %_key% >v _key
and
X %_key% _key
These two commands should do, essentially the same thing, since the command 'X'
calls ShellSetEnvironmentVariable() if the 2nd parameter is present.
Any thoughts?
Tim
___
edk2-devel
if (StrStr (TempLine, L"ShellCommand,") == TempLine) {
LoopVariable++;
}
This line fails because, with redirected input, the file has the UCS-2 byte
order mark, so the string "ShellCommand," is not at the beginning of the line.
With the file, the byte order mark is not
Test by doing this, immediately after booting:
Notice that echo has created a new environment variable _key to the value 4,
But this variable does not show up when running "set"
Why? It is because the FileHandleWrappers does not use SetEnvironmentVariable.
Instead, it tries to read and write
Try this:
:start
@if %1 == "" then
@goto Done
@endif
@echo Parameter: %1
@shift
goto start
:Done
Per Chapter 4
Also, additional '@' before a command in a script file can prevent the current
command from being echoed.
In a script that looks like this:
:start
if not %1 == "" then
echo %1
shift
goto start
endif
'shift' will generate an error message. The spec doesn't describe any behavior
like this and it is annoying to write scripts that must avoid it.
Of course you can work around it...
Tim
Jaben --
I'm not sure. In the debugger, it clearly showed the memory as having already
been freed at the pointer. But I didn't track down who had done it.
Tim
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Friday, December 02, 2016 8:39 AM
To: Tim Lewis
There are "load options" that are passed to drivers (as a part of the
EFI_LOADED_IMAGE_PROTOCOL), but there is no guarantee as to their format
(binary data or ASCII string or UCS-2 string). It is possible for "load" to be
modified to create this data and populate it between the calls to
Mike --
Ok, I will enter it into Bugzilla later today.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney,
Michael D
Sent: Thursday, July 20, 2017 10:57 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, M
t;
Thanks,
Tim Lewis
CTO, Insyde Software
www.insyde.com<http://www.insyde.com>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
when one is not present won't help the vast quantities of existing UNI files
out there.
Tim
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, April 26, 2017 10:45 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@
...@intel.com]
Sent: Wednesday, April 26, 2017 11:05 AM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>;
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU s
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,
compatible for these files.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 11:11 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael
D <michael.d.kin...@intel.com>
Cc: C
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 <tim
, April 26, 2017 11:47 AM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W
<kevin.w.s...@intel.com>
Subject: RE: [edk2] [edk2-UniSpecification PATCH]
-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 12:04 PM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>;
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@i
e previous behavior.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 5:02 PM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben &
d.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 3:47 PM
To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael
D <michael.d.kin...@intel.com>
Cc: Carsey, Jaben <jaben.car...
...@intel.com]
Sent: Wednesday, April 26, 2017 3:57 PM
To: Tim Lewis <tim.le...@insyde.com>; Zeng, Star <star.z...@intel.com>;
edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Gao, Liming <liming@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support
Mike --
For the one-logo case, yes, that would work. But this is the simplest case.
Consider HII string packages.
Tim
-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Wednesday, April 26, 2017 5:28 PM
To: Tim Lewis <tim.le...@insyde.com>
-boun...@lists.01.org] On Behalf Of Tim Lewis
Sent: Wednesday, April 26, 2017 5:27 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Carsey, Jaben <jaben.car...@intel.com>; Shaw, Kevin W
<kevin.w.s...@intel.com>
Subject: Re: [edk2] [edk2-UniSpecific
.
Tim
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Thursday, April 27, 2017 6:00 PM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>;
, Star<mailto:star.z...@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.le...@insyde.com>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>;
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming@intel.com&
not found in array
}
Resource = NULL;
while (!GetResourceForSkuId(*SkuId, ) && *SkuId == 0) {
*SkuId++;
}
If (Resource == NULL) {
// error, no resource found for any of the SKU IDs
}
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Wednesday, May 03, 2017 7:03 AM
To:
Star --
Thanks for your work on this. I have reviewed this and it looks good,
addressing all of our concerns.
Tim
-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Monday, May 15, 2017 2:46 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<mich
I don't think it is good to change the behavior of the tool beyond what is in
the specification. Further, this tool has existed for quite a long time in the
EDK shell and now the UEFI shell without this behavior. So the de-facto
standard of this environment is "don't create". Leaving behind
01.org<mailto:edk2-devel@lists.01.org>
Cc: Star Zeng<mailto:star.z...@intel.com>; Michael
Kinney<mailto:michael.d.kin...@intel.com>; Liming
Gao<mailto:liming@intel.com>; Tim Lewis<mailto:tim.le...@insyde.com>;
Yonghong Zhu<mailto:yonghong@intel.com>
Subj
Mike --
Sorry for the delay. We have reviewed this RFC internally and we believe it is
a useful change.
Thanks,
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
Liming
Sent: Tuesday, April 11, 2017 8:17 AM
To: edk2-devel@lists.01.org
can decide not to use this, but we
actually like it.
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng,
Star
Sent: Friday, May 05, 2017 3:08 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@intel.com
...@intel.com]
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [RFC] PCD: Extended SKU supp
1 - 100 of 119 matches
Mail list logo