Since the default EfiResetSystemLib for VExpress cannot be used at
runtime (due to the fact that its MMIO registers need to be owned
by the OS and so cannot be runtime remapped), instead use PSCI calls
into EL3 at runtime.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by:
Aaron,
Thanks for your comments. I check the code you provide, I found the input
maximum value(200) is bigger than the allowed maximum value(0x7F). So
vfrcompiler assume the maximum value is (INT (200) = -38) which is small than
minimum value(0), and the error raised.
Now I add code to do
Since ArmVExpressSysConfigLib cannot be supported at runtime, restrict
its use to the types of modules that are currently using it legally.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
The ArmVExpressSysConfigLib library does not (and cannot) runtime
remap its MMIO registers, so use a NULL implementation of the
ArmPlatformSysConfigLib library class for DXE_RUNTIME_DRIVER
type modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Since UEFI only support UTF-16LE strings internally, this simply
allows for another unicode the source file encoding.
The strings are still converted to UTF-16LE data for use in EDK II
source code.
Cc: Yingke D Liu yingke.d@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
In .utf8 files, there is the possibility that 32-bit unicode code
points might be used in comments.
While a 32-bit unicode code points should be dissallowed in string
data, it should be allowed in comments.
Cc: Yingke D Liu yingke.d@intel.com
Contributed-under: TianoCore Contribution
The UTF-16 .uni files are fairly annoying to work with:
* They must be checked in as 'binary' files
* It is difficult to produce a diff of changes
* UTF-8 is more likely to be supported by text editors
With some basic testing on Linux, it appears that UTF-8 works as
expected with UTF-8 files.
This allows the unit tests to run without the errors logging to the
screen.
Cc: Yingke D Liu yingke.d@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
BaseTools/Source/Python/Common/EdkLogger.py | 9 -
1 file
This allows unit tests to easily include BaseTools python
modules. This is very useful for writing unit tests.
Actually, previously, we would do this when RunTests.py was executed,
so unit tests could easily import BaseTools modules, so long as they
were executed via RunTests.
This change allows
With .uni UTF-16 files, it is impossible for unicode code points to be
larger than 0x.
To support .utf8 UTF-8 unicode files, we need to also deal with the
possibility that the UTF-8 file contains unicode code points larger
than 16-bits. Since UEFI only supports 16-bit string data, we make
This command was used to convert the file:
iconv -f UTF-16 -t UTF-8 OvmfPkg/PlatformDxe/Platform.uni \
OvmfPkg/PlatformDxe/Platform.utf8
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
OvmfPkg/PlatformDxe/Platform.inf |
This verifies that UTF-16 (with BOM) is considered bad data in a .utf8
file.
It also verified that UTF-8 data in a .utf8 file does not generate an
error.
Cc: Yingke D Liu yingke.d@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
This verifies that a .uni file should contain UTF-16 data (with BOM)
or an error should be generated by AutoGen.UniClassObject when the
string file in processed.
Cc: Yingke D Liu yingke.d@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
Since .utf8 UTF-8 unicode files might contain strings with unicode
code points larger than 16-bits, and UEFI only supports UTF-16
characters, we need to make sure that BaseTools rejects these strings.
Cc: Yingke D Liu yingke.d@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
On 04/30/15 14:45, Ard Biesheuvel wrote:
On 30 April 2015 at 14:31, Laszlo Ersek ler...@redhat.com wrote:
On 04/30/15 14:04, Ard Biesheuvel wrote:
InternalData may not be aligned to the size of the type
we are writing, so use WriteUnalignedXX() instead.
Contributed-under: TianoCore
On 05/04/15 08:14, Jordan Justen wrote:
With .uni UTF-16 files, it is impossible for unicode code points to be
larger than 0x.
To support .utf8 UTF-8 unicode files, we need to also deal with the
possibility that the UTF-8 file contains unicode code points larger
than 16-bits. Since UEFI
On 05/04/15 08:14, Jordan Justen wrote:
This command was used to convert the file:
iconv -f UTF-16 -t UTF-8 OvmfPkg/PlatformDxe/Platform.uni \
OvmfPkg/PlatformDxe/Platform.utf8
Reviewed-by: Laszlo Ersek ler...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
This series enables the ArmVirtualizationPkg QEMU/KVM platform to be built with
UEFI Secure Boot support.
Changes since v1:
- removed redundant '== FALSE' comparison in patch #2
- added R-b's
Patch #1 removes some unused variables that prevent the build from completing
with the default compiler
The NorFlashDxe uses an explicit 'BEFORE xxx' Depex declaration to
ensure that it is dispatched before VariableRuntimeDxe, and uses the
file GUID of the latter as 'xxx' explicitly to accomplish that.
However, when enabling UEFI Secure Boot, this breaks down since the
authenticated
This adds all the required modules and library dependencies so that
the ArmVirtualizationQemu platform can be built with support for
UEFI Secure Boot. This support consists of the OpenSSL crypto
library (whose source needs to be downloaded separately), the
authenticated variable store, and
This removes various unused variables from SecurityPkg whose presence
is causing failed builds.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Chao Zhang chao.b.zh...@intel.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Signed-off-by: Ard Biesheuvel
It looks good.
Reviewed-by: David Wei david@intel.commailto:david@intel.com
Thanks,
David | SSG BIOS
From: Lu, ShifeiX A
Sent: Monday, May 04, 2015 2:33 PM
To: edk2-devel@lists.sourceforge.net
Cc: Wei, David; He, Tim; Wu, Mike; Guo, Mang; Lu, ShifeiX A
Subject: [edk2][Patch]
On 4 May 2015 at 09:08, Laszlo Ersek ler...@redhat.com wrote:
On 04/30/15 14:45, Ard Biesheuvel wrote:
On 30 April 2015 at 14:31, Laszlo Ersek ler...@redhat.com wrote:
On 04/30/15 14:04, Ard Biesheuvel wrote:
InternalData may not be aligned to the size of the type
we are writing, so use
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian feng.t...@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
MdePkg/Include/Protocol/BlockIoCrypto.h | 526
MdePkg/MdePkg.dec | 8 +-
2 files changed,
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian feng.t...@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
MdePkg/Include/Protocol/SmartCardEdge.h | 726
MdePkg/MdePkg.dec | 3 +
2 files changed, 729
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian feng.t...@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
MdePkg/Include/Protocol/SmartCardReader.h | 326 ++
MdePkg/MdePkg.dec | 3 +
2 files changed,
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian feng.t...@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
MdePkg/Include/Protocol/UsbFunctionIo.h | 683
MdePkg/MdePkg.dec | 3 +
2 files changed, 686
I'm seeing this issue building edk2 with GCC on Windows - in this case Aarch64
but I think the issue may be common to all gcc-on-Windows situations.
tools_def has this stuff for bypassing the objcopy stage:
*_*_*_OBJCOPY_PATH = echo
*_*_*_OBJCOPY_FLAGS = objcopy not
Hi,
I've made some progress, but I've got some serious problems that I'll
need help with.
The current patchset (with 36 patches) is visible in my smm_wip1
branch on github:
https://github.com/lersek/edk2/compare/master...lersek:smm_wip1
I'm not posting the patchset to edk2-devel, for two
Cohen, Eugene [mailto:eug...@hp.com] wrote:
]Sent: Monday, May 04, 2015 07:45 AM
]To: edk2-devel@lists.sourceforge.net
]Subject: [edk2] Windows GCC build issues with echo
]
]I’m seeing this issue building edk2 with GCC on Windows – in this case Aarch64
but I think the issue may be ]common to all
On 04/05/2015 15:58, Laszlo Ersek wrote:
So here's the *specific* issues I'm facing (and need help with):
* Problem #1 for task (4):
Because Quark is 32-bit only, the (mostly assembly) code under
OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32 that (partly) constitutes the
SMM entry vector does not
Jordan,
Some source control systems provide support a file type of UTF-16LE, so the use
of 'binary' should be avoided. What source control systems require the use of
'binary'? What diff utilities are having issues with UTF-16LE files? Can you
provide some examples?
Also, what are the
On May 4, 2015, at 8:57 AM, Kinney, Michael D michael.d.kin...@intel.com
mailto:michael.d.kin...@intel.com wrote:
Jordan,
Some source control systems provide support a file type of UTF-16LE, so the
use of 'binary' should be avoided. What source control systems require the
use of
Scott, thanks for the suggestion.
As far as documentation of the GCC build or maintenance of the tools
definitions, I'd ask that some clarification is made. Ideally we could find a
way to eliminate this extra requirement.
Eugene
-Original Message-
From: Scott Duplichan
Hi Eric,
The patch is better, but it is not quite right. It is now allowing the
full range of values for each integer type. You can refer to the Two's
Compliment Wiki article for it additional information
http://en.wikipedia.org/wiki/Two%27s_complement.
The following code shows that the
On 2015-05-04 08:57:29, Kinney, Michael D wrote:
Jordan,
Some source control systems provide support a file type of UTF-16LE,
so the use of 'binary' should be avoided. What source control
systems require the use of 'binary'?
Svn seems to require it so the data doesn't get munged.
Git seems
On May 4, 2015, at 10:33 AM, Jordan Justen jordan.l.jus...@intel.com wrote:
On 2015-05-04 08:57:29, Kinney, Michael D wrote:
Jordan,
Some source control systems provide support a file type of UTF-16LE,
so the use of 'binary' should be avoided. What source control
systems require the use
On 2015-05-04 10:48:05, Andrew Fish wrote:
On May 4, 2015, at 10:33 AM, Jordan Justen jordan.l.jus...@intel.com
wrote:
On 2015-05-04 08:57:29, Kinney, Michael D wrote:
Jordan,
Some source control systems provide support a file type of UTF-16LE,
so the
On May 4, 2015, at 11:06 AM, Jordan Justen jordan.l.jus...@intel.com wrote:
Is there a concern with supporting UTF-8?
Not from an Mac. As long as VC++ and other Windows based editors are happy with
UTF-8 there should not be an issue.
It seems like in general UTF-8 is better supported,
(I couldn't find a better point to insert my two cents in the thread, so
I'll just follow up here.)
On 05/04/15 20:06, Jordan Justen wrote:
On 2015-05-04 10:48:05, Andrew Fish wrote:
On May 4, 2015, at 10:33 AM, Jordan Justen jordan.l.jus...@intel.com
wrote:
On 2015-05-04
On 04/05/2015 20:03, Laszlo Ersek wrote:
However, the point where it ultimately breaks, I think, is the
individual runtime drivers that communicate with their privileged SMM
counterparts. The communication happens via serializing a binary
message, and then raising an SMI.
Minimally in the
Hi
Here is patch to add comment for SafeString API in BaseLib for MdePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen jiewen@intel.commailto:jiewen@intel.com
Thank you
Yao Jiewen
SafeString.patch
Description: SafeString.patch
Thanks to feedback from Jaben.
I updated the comments.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen jiewen@intel.commailto:jiewen@intel.com
Reviewed-by: Carsey, Jaben
jaben.car...@intel.commailto:jaben.car...@intel.com
From: Yao, Jiewen
Sent:
BaseTools: Add support for gcc 5.1 tool chains.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan sc...@notabs.org
---
Build testing with gcc 5.1.0 tool chains from:
http://sourceforge.net/projects/edk2developertoolsforwindows/
passes for valid combinations
The patch is good.
Reviewed-by: Liming Gao liming@intel.com
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Tuesday, May 05, 2015 10:44 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [patch] MdePkg: add comment for SafeString API in BaseLib
Hi
Here is patch to add comment for
Rather than:
If error value would be returned, the function will ASSERT() also.
I think this sounds better:
If an error would be returned, then the function will also ASSERT().
Or, possibly:
If an error would be returned, then the function will also trigger an
ASSERT().
-Jordan
On 2015-05-04
On 05/04/2015 02:11 PM, Laszlo Ersek wrote:
(I couldn't find a better point to insert my two cents in the thread, so
I'll just follow up here.)
On 05/04/15 20:06, Jordan Justen wrote:
On 2015-05-04 10:48:05, Andrew Fish wrote:
On May 4, 2015, at 10:33 AM, Jordan Justen
On 2015-05-04 14:32:48, Brian J. Johnson wrote:
On 05/04/2015 02:11 PM, Laszlo Ersek wrote:
I do think such files should be distinguished with a separate filename
suffix.
Yes. Otherwise developers will get confused why some .uni files work
with their tools, and some do not.
Mike, what
On 05/04/15 21:21, Paolo Bonzini wrote:
On 04/05/2015 20:03, Laszlo Ersek wrote:
However, the point where it ultimately breaks, I think, is the
individual runtime drivers that communicate with their privileged SMM
counterparts. The communication happens via serializing a binary
message,
On 2015-05-04 11:03:08, Laszlo Ersek wrote:
On 05/04/15 17:55, Paolo Bonzini wrote:
On 04/05/2015 15:58, Laszlo Ersek wrote:
So here's the *specific* issues I'm facing (and need help with):
* Problem #1 for task (4):
Because Quark is 32-bit only, the (mostly assembly) code under
Hello all,
Due to community feedback, a new mailing list is being set up to replace this
one. The new list will be hosted on Lists.01.org and should be more stable and
consistent than this one.
The host has an opt-in policy and will not allow the current subscription list
to be imported so
Good suggestion!
I would choose:
-- If an error would be returned, then the function will also ASSERT().
Thank you
Yao Jiewen
-Original Message-
From: Justen, Jordan L
Sent: Tuesday, May 05, 2015 1:10 PM
To: edk2-devel@lists.sourceforge.net; Yao, Jiewen
Subject: Re: [edk2] [patch]
Jordan,
I did some investigations into this issue a while ago and even prototyped some
backwards compatible BaseTools changes.
Looks like a problem several of us have evaluated.
The .uni file extension is used for few purposes today. One is generation of
HII String Packages and another is
53 matches
Mail list logo
