Reviewed-by: Yao, Jiewen jiewen@intel.com
At same time, I suggest we move PcdTpm2HashMask to Dynamic section too, because
now Tcg2Pei will set this PCD according to TPM2 device capability.
If you agree, I will check in both.
Thank you
Yao Jiewen
-Original Message-
From:
Star,
The NT32Pkg changes are good.
Reviewed-by: Ruiyu Ni ruiyu...@intel.com
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, August 17, 2015 4:24 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 00/15] Separate
On 16 August 2015 at 23:48, Scott Duplichan sc...@notabs.org wrote:
]Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote:
. . .
] Thanks for this much needed tool chain definition consolidation. I ran
] a build test with and without the patch. The build test uses GCC44-49
] and
The patch for Vlv2TbltDevicePkg is good. Thanks.
Thanks,
David | SSG BIOS
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, August 17, 2015 4:24 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 00/15] Separate
On 13 August 2015 at 16:37, Heyi Guo heyi@linaro.org wrote:
NewNode is the node we found, while Node is the last node in the
list. Also update mFreedBufferSize.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo heyi@linaro.org
Cc: Leif Lindholm
Jordan,
Sorry I missed your previous questions. Let me try to answer all your questions
in this email.
Q1: Why merging Ex and non-Ex APIs? Providing Non-Ex APIs was to make simpler
functions available for blt operations.
Merging the Ex and non-EX APIs is to avoid the library APIs provide
Jiewen:
The updated message is useful. I suggest to change error level from
EFI_D_ERROR to EFI_D_INFO.
Thanks
Liming
-Original Message-
From: Yao, Jiewen
Sent: Tuesday, August 18, 2015 10:46 AM
To: Gao, Liming; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section
Ard:
I think this patch needs to update VS tool chain link flag to enable 4K for
DXE_RUNTIME modules, because Ovmf platform also supports VS tool chain.
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
Biesheuvel
Sent:
Hi,
This is a warning message that describes the runtime driver alignment is not
4K.
UEFI PropertiesTable table feature expects all runtime driver alignment is
4K. When DxeCore loads Runtime driver, it will check its alignment and report
such warning message if it doesn't meet with the
OK
-Original Message-
From: Gao, Liming
Sent: Tuesday, August 18, 2015 10:48 AM
To: Yao, Jiewen; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Jiewen:
The updated message is useful. I suggest to change error
The MS ABI uses leading underscores to decorate symbol names only
when generating 32-bit code. Due to a bug in GCC prior to version 4.3,
it used the same decoration for 64-bit code but this has been fixed
since. So uses the leading underscore for IA32 only, and remove it
for X64.
Disentangle the arguments passed to the various flavors of GCC we
support, by refactoring the [AS]DLINK flags so that we distinguish
more clearly between toolchains that generate PE/COFF directly (for
IA32 and X86 only) and toolchains that generate ELF only.
Contributed-under: TianoCore
The warning flags -Wno-address -Wno-unused-but-set-variable are added
for version 4.6 and up, but since they are happily accepted by version
4.4 and 4.5, add them there as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Use the same GCC options for assembling regardless of the exact
GCC version.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/tools_def.template | 67
1 file changed, 27 insertions(+), 40
This aligns the remaining configuration options for ELFGCC with
the other ELF based toolchains.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/tools_def.template | 18 +-
1 file changed, 9
This enables 4 KB section alignment for DXE_RUNTIME modules, for
ELF based toolchains and for the UNIXGCC PE/COFF toolchain.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/OvmfPkgX64.dsc | 7 +++
1 file changed, 7
The driver consumes the GraphicsInfo HOB and produces GOP protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Feng Tian feng.t...@intel.com
---
MdeModulePkg/MdeModulePkg.dsc | 4 +
The patch serials refined the BltLib and moved it to MdeModulePkg.
Based on the BltLib, the patch created the GraphicsOutputDxe driver which
consumes
the GraphicsInfo HOB.
Ruiyu Ni (8):
OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*
OptionRomPkg: Add video move test
Since the library consumes the GOP mode structure which is provided by
library caller, library caller doesn't need to ask the library about
the screen resolution, instead, it can directly get from the GOP mode
structure.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu
GCC4x and ELFGCC are both ELF based GCC toolchains, so there is no
justification for allowing the command line options to deviate.
So align them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/tools_def.template
If any version of GCC emits any object whose actual alignment
requirement exceeds 32 bytes, this actual alignment value will
automatically become the PE/COFF section alignment value after
PE/COFF conversion, now that GenFw propagates the alignment of
the ELF input sections. So there is no longer a
As a first step towards disentangling the arguments passed to the
various flavors of GCC we support, refactor the CC flags so that
we distinguish more clearly between toolchains that generate PE/COFF
directly (for IA32 and X86 only) and toolchains that generate ELF
only.
Note that this does not
When a section's start address is set explicitly and is not aligned to
the alignment of its contents, the linker will rearrange them so that
everything lines up provided that the misalignment is preserved.
Since we cannot do the same in PE/COFF, don't set the .data start
address directly, but
Use the same GCC options for linking regardless of the exact
GCC version.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/tools_def.template | 63 +++-
1 file changed, 23 insertions(+), 40
This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
toolchains that needed some tlc as well.
Anyway, this series aims to refactor the toolchains definitions for
UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
CYGGCC and CYGGCCxASL so that they share as much of
The code was also checked in to below URL:
https://github.com/niruiyu/edk2/tree/GOP
-Original Message-
From: Ni, Ruiyu
Sent: Monday, August 17, 2015 9:45 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ruiyu...@intel.com
Subject: [Patch 0/8] Move BltLib to MdeModulePkg and create
API removal:
BltLibVideoToBltBuffer
BltLibBufferToVideo
BltLibGopBlt
API rename:
BltLibVideoToBltBufferEx - BltVideoToBuffer
BltLibBufferToVideoEx - BltBufferToVideo
BltLibVideoToVideo - BltVideoToVideo
BltLibVideoFill - BltVideoFill
BltLibConfigure - BltConfigure
The 3 APIs in
The BltConfigure() API caches the video frame buffer meta data which
forbids the library to be implemented to support re-entry.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: Jordan Justen
The definition of GCC_WINDRES_FLAGS is never referenced again
so remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/tools_def.template | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi Feng,
Now I understand the concept. I was expecting that PEIM would already be
available for the Minnowboard Max. Is Usb in the PEI phase not supported in
Minnowboard?
From my digging in the code today, it seems to enable the xhci controller,
it's PCI BAR needs to be set and enabled for
Please see attached patch file. Can you help review it and check it in please?
Thanks,
--Samer
-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Saturday, August 15, 2015 1:10 AM
To: El-Haj-Mahmoud, Samer samer.el-haj-mahm...@hp.com; edk2-devel@lists.01.org
Cc:
Yes that makes sense. I missed it since I have not tried to build the new Tcg2
drivers yet.
Thanks,
--Samer
-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Tuesday, August 18, 2015 12:15 AM
To: El-Haj-Mahmoud, Samer samer.el-haj-mahm...@hp.com;
On 18 August 2015 at 04:35, Gao, Liming liming@intel.com wrote:
Ard:
I think this patch needs to update VS tool chain link flag to enable 4K for
DXE_RUNTIME modules, because Ovmf platform also supports VS tool chain.
Good point, thanks.
-Original Message-
From: edk2-devel
The UEFI Shell 2.1 has been available for a long time. Any UDK release after
Aug last year should have it. I am not an expert on the UDK releases...
-Jaben
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Daniel Samuelraj
Sent: Monday,
On 17 August 2015 at 19:53, Jordan Justen jordan.l.jus...@intel.com wrote:
On 2015-08-17 07:24:57, Ard Biesheuvel wrote:
This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
toolchains that needed some tlc as well.
Anyway, this series aims to refactor the toolchains definitions
Thank you, Jaben.
I have added my comments inline
*From:* Carsey, Jaben [mailto:jaben.car...@intel.com]
*Sent:* Monday, August 17, 2015 11:12 AM
*To:* Daniel Samuelraj; uswg
*Cc:* edk2-devel@lists.01.org; Carsey, Jaben
*Subject:* RE: [uswg] Shell 2.0 and 2.1
(note: I changed the edk2
On 2015-08-17 06:45:27, Ruiyu Ni wrote:
The BltConfigure() API caches the video frame buffer meta data which
forbids the library to be implemented to support re-entry.
How does this help? GraphicsOutputDxe will set a mode, and then use
BltLib with that mode.
I already asked this, and I had
On 2015-08-17 07:24:57, Ard Biesheuvel wrote:
This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
toolchains that needed some tlc as well.
Anyway, this series aims to refactor the toolchains definitions for
UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
UNIXGCC and CYGGCC are GCC 4.3 mingw based. Did this get tested?
I think ELFGCC is unused at this point. (And has been since UnixPkg
was deprecated.)
I think we should deprecate all three of these toolchains. I would
like to see
Of all the gin joints in all the towns in all the world, David Woodhouse had
to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
UNIXGCC and CYGGCC are GCC 4.3 mingw based. Did this get tested?
I think ELFGCC is unused
(note: I changed the edk2 mailing list)
Daniel,
A UEFI Shell 2.0 application will work fine in UEFI Shell 2.1 with no changes.
To create/build a UEFI Shell 2.1 application would need to have a version of
the UDK that has the updated protocol to get easy access to the new API’s that
were added
On 2015-08-17 11:10:57, Bill Paul wrote:
Of all the gin joints in all the towns in all the world, David Woodhouse had
to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
UNIXGCC and CYGGCC are GCC 4.3 mingw based. Did
Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote:
]Sent: Monday, August 17, 2015 09:25 AM
]To: edk2-de...@ml01.01.org; yingke.d@intel.com
]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel
ard.biesheu...@linaro.org; jordan.l.jus...@intel.com; ]liming@intel.com;
On 17 August 2015 at 20:37, Scott Duplichan sc...@notabs.org wrote:
Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote:
]Sent: Monday, August 17, 2015 09:25 AM
]To: edk2-de...@ml01.01.org; yingke.d@intel.com
]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel
Of all the gin joints in all the towns in all the world, Jordan Justen had to
walk into mine at 11:22:15 on Monday 17 August 2015 and say:
On 2015-08-17 11:10:57, Bill Paul wrote:
Of all the gin joints in all the towns in all the world, David Woodhouse
had
to walk into mine at 11:00:23
On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
based on GCC 4.9 rather than
On 2015-08-17 11:25:41, David Woodhouse wrote:
On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
Not for testing LLP64, no.
How/who is this helping?
I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to
On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
On 2015-08-17 11:10:57, Bill Paul wrote:
Of all the gin joints in all the towns in all the world, David Woodhouse had
to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
On Mon, 2015-08-17 at 10:53 -0700,
On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
Not for testing LLP64, no.
I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
of
Hi, I have an application that runs in DXE phase. It executes some code and
then call
ResetSystem() from RunTimeServices
to shut down the system (consider that the OS has put the system in
S4 state previously, and this app is being called right
after system resumes from S4). The system goes down,
No platforms use the ARMv6 (ARM11) support code anymore. In fact, the
only reference to it in ArmPkg.dsc was commented out by Andrew in SVN
r11298 (2011-02-03) so it may well be broken. So remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
This updates mingw-gcc-build.py to the newest version of GCC currently
supported by the EDK2 build system, which is 4.9.3. At the same time,
binutils is updated to version 2.24.51.0.2.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
See http://www.infradead.org/rpr.html
X-SRS-Rewrite: SMTP reverse-path rewritten from dw...@infradead.org by
twosheds.infradead.org
See http://www.infradead.org/rpr.html
On 2015-08-17 11:25:41, David Woodhouse wrote:
On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
Can't you use an
Reviewed-by: Ye Ting ting...@intel.com
-Original Message-
From: Wu, Jiaxin
Sent: Monday, August 17, 2015 11:25 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Zhang, Lubo
Subject: [PATCH v2] MdeModulePkg: IP4 should re-initiate a DHCP while network
reconnection
v2:
* Update the
Hi all,
About a week or two ago I was able to start the emulator + shell (Fedora
22 64-bit host) using:
$ sh EmulatorPkg/build.sh run
However, after re-cloning the git repository today and trying the same
process, a breakpoint is instead triggered somewhere in PeiCore (I
believe). If I
Hi All,
I have some problems and inconsistencies on i2c bus on my minnowBoard MAX.
Two problems:
1. When I run i2cdetect -l on the same board with my yocto project build
and then again with running Ubuntu 14.04.3 LTS I get different listing for
i2c buses.
2. Even though I have no lures
This commit introdues a new build option to OvmfPkg: HTTP_BOOT_ENABLE.
When HttpBoot is enabled, a new Network boot option will show in the
boot manager menu with the device path like this:
PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)/Uri()
It works like the PXE one but fetches
What to do: Implement VarCheckUefiLib NULL class library instance.
The code logic are separated from Variable driver, and it will consume
VarCheckLib
to register var check handler and variable property set for UEFI defined
variables.
Why to do: Share code.
Separate variable check UEFI code from
Cc: Laszlo Ersek ler...@redhat.com
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
ArmVirtPkg/ArmVirtQemu.dsc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
OvmfPkg/OvmfPkgIa32.dsc| 5 -
OvmfPkg/OvmfPkgIa32X64.dsc | 5 -
OvmfPkg/OvmfPkgX64.dsc | 5 -
Since Variable driver has been updated to consume the separated VarCheckLib.
Cc: Ruiyu Ni ruiyu...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
Nt32Pkg/Nt32Pkg.dsc | 1 +
1 file changed, 1 insertion(+)
diff --git
Cc: David Wei david@intel.com
Cc: Tim He tim...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 +
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 1 +
Vlv2TbltDevicePkg/PlatformPkgX64.dsc
Since Variable driver has been updated to consume the separated VarCheckLib.
Cc: Laszlo Ersek ler...@redhat.com
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
ArmVirtPkg/ArmVirt.dsc.inc | 1 +
Reviewed-by: Qiu Shumin shumin@intel.com
This patch for ShellPkg depends on the ' EFIFORMAT ' change in MdePkg. So block
the check in after the MdePkg has been updated.
-Shumin
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Saturday, August 08, 2015 2:04
64 matches
Mail list logo
