We don’t have plan to support Cancel() interface. According to UEFI spec,
EFI_UNSUPPORTED is a permitted returned status of TCP->Cancel().
Best Regards,
Ye Ting
From: Thomas Rognon [mailto:tcrog...@gmail.com]
Sent: Tuesday, August 26, 2014 10:45 AM
To: edk2-devel
Subject: [edk2] EFI_TCP4_PROTOCO
On Mon, Aug 25, 2014 at 7:01 PM, Gao, Liming 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.
Can
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,
On Aug 25, 2014, at 10:12 PM, Tim Lewis 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
>
Hi,
> If the workaround is stable in your opinion (ie. it can be relied upon
> even after the qemu problem with VBE_DISPI_INDEX_VIDEO_MEMORY_64K is
> fixed), then I'd probably leave it in, even in the long term.
Yes, ROM (bar 2) struct layout is stable.
> Jordan, is it enough if I only reword
On 25 August 2014 23:03, Laszlo Ersek wrote:
> On 08/25/14 21:19, Ard Biesheuvel wrote:
>> This series adds a platform config to support QEMU based virtual machines,
>> either in TCG or KVM mode. These virtual machines declare their platform
>> configuration by passing a device tree which needs to
On Aug 25, 2014, at 10:05 PM, Gao, Liming wrote:
> 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.
>
So when the Core/MdePkg vendor drops me
Checked in @15895
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:09 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Add PMC/PMCSR definitions
Dear MdePkg maintainers,
Please find the attached patch that adds some PCI Po
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 determi
Hi Samer,
It's really a good enhancement. Since it's a change to build output, we have to
evaluate if the new outputs impact current users or not.
Thanks,
Dennis
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 4:21 AM
To: edk2-devel@lists.sourcef
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
Check in @15894.
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:13 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Update EFI_DRIVER_HEALTH_HII_MESSAGE definition
from UEFI 2.4
Dear MdePkg maintainers,
Please find the a
Hi Samer,
Thanks for this patch, it's really a good new feature, we will evaluate this
feature and let you know the feedback later.
Thanks,
Dennis
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 4:59 AM
To: edk2-devel@lists.sourceforge.net
Subject
On Mon, 2014-08-25 at 15:04 +, Gao, Liming wrote:
> After you update EDKII code base, please remove Conf/build_rules.txt first,
> then call edksetup script to copy new build_rules.txt
>
> And, you also need to install nasm compiler.
>
thanks, after remove build_rule.txt, I built it success
Hi,
You can use MdePkg\Library\BasePrintLib\BasePrintLib.inf when you use
BaseDebugLibSerialPort library.
Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, August 26, 2014 12:09 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Circular Dependency Between DxeP
Tim:
PCD database is built as a firmware file section and integrated into PcdPei
and PcdDxe driver FFS file. This happens on GenFds phase. When build the
platform that have the binary drivers with DynamicEx PCD, PCD database will be
generated to include those DynamicEx PCD information, then Ge
Hess:
The change is good to me.
Reviewed-by: Gao, Liming
Thanks
Liming
From: Chen, Hesheng
Sent: Monday, August 25, 2014 4:30 PM
To: Gao, Liming; edk2-devel@lists.sourceforge.net
Subject: [edk2] [BaseTools] [UPT] Add some new feature support on UPT
Hello Liming,
Could you help review this pa
I saw this revision was just checked in. Can someone explain how you do this?
Currently, the PCD database is built as a firmware file section and integrated
directly into the PcdPei and PcdDxe drivers. In the binary only case, how is
the firmware file section integrated into these binary-only dr
Eugene -
We found this also when because there are DEBUG macros in the serial port
library. Is this the root cause of what you found? We finally had to hack the
library constructors, but it was messy.
Tim
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, August 26, 2014 7:49 AM
To: edk
On Aug 25, 2014, at 7:01 PM, Gao, Liming 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.
>
Ho
Is there any plan to implement EFI_TCP4_PROTOCOL->Cancel()? Right now it's
just a stub that returns EFI_UNSUPPORTED.
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Main.c
I'll have to use timers again to hack my way around this.
Also, TcpIoLib's TcpIoRec
Patch looks good to me.
Reviewed-by: Yingke Liu
Dennis
From: Feng, Bob C
Sent: Monday, August 25, 2014 1:49 PM
To: Liu, Yingke D; 'edk2-devel@lists.sourceforge.net'
Subject: RE: [edk2] [BaseTools]Implement the external PCD database generation
rule to support the case that all binary driver are
Liming --
I think Jordan's question is: is the grammar of the INF/DEC file changing?
I think the answer is: "No. Since UPT generates these files, it would be nice
that the order matches."
Tim
-Original Message-
From: Gao, Liming [mailto:liming@intel.com]
Sent: Tuesday, August 26,
Reviewed-by: Yingke Liu
Dennis
From: Chen, Hesheng [mailto:hesheng.c...@intel.com]
Sent: Monday, August 25, 2014 10:53 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [BaseTools]Support a force binary build mode
Hello all,
Could you help review this patch?
This patch is going to:
1.
Jordan:
I am ok to skip 'xor rax, rax'.
I think NASM 2.07 better.
Thanks
Liming
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com]
Sent: Tuesday, August 26, 2014 4:26 AM
To: edk2-devel@lists.sourceforge.net; Gao, Liming
Subject: Re: [edk2] [PATCH 5/8] MdePkg/BaseLib
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.
This change is required by EDKII project major release, but
Fair enough. How about an HiiExLib library in IntelFrameworkModulePkg ?
-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Monday, 25 Aug 2014, 8:26PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: Re: [edk2] [PATCH] MdeModulePkg:
Samer:
Label Opcode is EDKII extension GUIDED opcode, not standard UEFI HII opcode.
And, HiiLib is generic HII Library for UEFI HII. So, I don't suggest to include
this API in HiiLib.
Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014
On Aug 25, 2014, at 6:03 PM, Laszlo Ersek wrote:
> On 08/26/14 02:12, Jordan Justen wrote:
>> On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek wrote:
>>> On 08/26/14 00:24, Jordan Justen wrote:
On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek wrote:
> Recent changes in the QEMU ACPI table ge
Samer:
I have one minor comment. Could you help add the description for new
IMAGE_ATTRIBUTE_UEFI_IMAGE like other definition, such as
IMAGE_ATTRIBUTE_IN_USE?
Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Monday, August 25, 2014 11:32 PM
To: edk2-devel@lis
On 08/26/14 02:12, Jordan Justen wrote:
> On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek wrote:
>> On 08/26/14 00:24, Jordan Justen wrote:
>>> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek wrote:
Recent changes in the QEMU ACPI table generator have shown that our
limited client for that i
On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek wrote:
> On 08/26/14 00:24, Jordan Justen wrote:
>> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek wrote:
>>> Recent changes in the QEMU ACPI table generator have shown that our
>>> limited client for that interface is insufficient and/or brittle.
>>>
>
Dear maintainers of DebugLib and PrintLib,
It looks like we have a circular dependency between the
DxePrintLibPrint2Protocol library (which uses ASSERT) and
BaseDebugLibSerialPort library (which uses AsciiSPrint):
1>.dsc(...) : error F002: Library
[c:\edk2\MdeModulePkg\Library\DxePrintLibPrint
On 08/26/14 01:41, Jordan Justen wrote:
> On Mon, Aug 25, 2014 at 2:56 PM, Laszlo Ersek wrote:
>> On 08/25/14 23:42, Jordan Justen wrote:
>>> On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek
>>> wrote:
On 08/25/14 14:43, Gerd Hoffmann wrote:
> Hi,
>
>> The current calculation is c
On Mon, Aug 25, 2014 at 2:56 PM, Laszlo Ersek wrote:
> On 08/25/14 23:42, Jordan Justen wrote:
>> On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek
>> wrote:
>>> On 08/25/14 14:43, Gerd Hoffmann wrote:
Hi,
> The current calculation is correct for stdvga, because on stdvga
> the va
On 08/26/14 00:24, Jordan Justen wrote:
> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek wrote:
>> Recent changes in the QEMU ACPI table generator have shown that our
>> limited client for that interface is insufficient and/or brittle.
>>
>> Implement the full interface utilizing OrderedCollectionLi
On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek wrote:
> Recent changes in the QEMU ACPI table generator have shown that our
> limited client for that interface is insufficient and/or brittle.
>
> Implement the full interface utilizing OrderedCollectionLib for addressing
> fw_cfg blobs by name.
>
> I
In this case, there should at least be a build tool option to break the build
if duplicates are found.
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 25, 2014 5:04 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Duplicate PCDs in DSC files
Samer -
I would say th
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
On 08/25/14 23:42, Jordan Justen wrote:
> On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek
> wrote:
>> On 08/25/14 14:43, Gerd Hoffmann wrote:
>>> Hi,
>>>
The current calculation is correct for stdvga, because on stdvga
the value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the
Reviewed-by: Erik Bjorge
From: Shah, Tapan [mailto:tapands...@hp.com]
Sent: Monday, August 25, 2014 12:54 PM
To: Carsey, Jaben; Bjorge, Erik C; edk2-devel@lists.sourceforge.net
Subject: ShellPkg: shell can't recognize 'ren' command
Jaben / Erik,
Can you please review this?
This patch fixes '
On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek wrote:
> On 08/25/14 14:43, Gerd Hoffmann wrote:
>> Hi,
>>
>>> The current calculation is correct for stdvga, because on stdvga the value
>>> returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is
>>> usable for drawing.
>>
>> Value
On Aug 20, 2014, at 4:59 PM, Kinney, Michael D
wrote:
> Tim,
>
> ARM was a different case. Andrew Fish can provide many of the details.
> Basic issue was that even 32-bit math ops were generating intrinsic calls and
> to apply same technique we have use for 64-bit math ops would have requ
On 08/25/14 22:26, Jordan Justen wrote:
> All,
>
> Should we require NASM 2.07 or newer rather than 2.03?
>
> NASM 2.07 was released in July 2009. (NASM 2.03 was June 2008)
RHEL-7.0 ships nasm-2.10+, so personally I'm fine with requiring 2.07+.
Thanks,
Laszlo
On 08/25/14 14:43, Gerd Hoffmann wrote:
> Hi,
>
>> The current calculation is correct for stdvga, because on stdvga the value
>> returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is
>> usable for drawing.
>
> Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is
On 08/25/14 21:19, Ard Biesheuvel wrote:
> This series adds a platform config to support QEMU based virtual machines,
> either in TCG or KVM mode. These virtual machines declare their platform
> configuration by passing a device tree which needs to be parsed by Tianocore
> rather than relying on h
On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming wrote:
> Hi, all
>
> This patch is for below ITEM 7. INF/DEC are generated from UPT tool.
> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help
> review them.
>
>MdePkg: Make sure order of DEC/INF content matches the orde
Dear BaseTools maintainers,
Please see attached patch to:
Add support for ${s_*} and ${d_*} macros for in FDF file for the INF files, and
for each statement in the build rules.
The following keywords are supported:
"src", "s_path", "s_dir", "s_name", "s_base", "s_ext", "dst", "d_path",
"d_name"
On Aug 21, 2014, at 8:13 PM, Chris Cuthbert wrote:
> Hi Siyuan,
>
> I can get to Grub prompt but I don't see it trying to load any more files,
> like the boot menu. Does GRUB V2.02 support PXE boot by default or does it
> need some configuration option ?
> How does Grub know that it is in net
Liming,
I tested your changes with NASM 2.11, and they worked fine.
One question. I think the 'xor rax, rax' is not needed, so should we
skip that? (I tested with and without it.)
I then tested NASM 2.03, which we had copied from VTF0 as the required
minimum version. It built with your changes,
Mike,
I will try to collect the data and get back on this.
Thanks,
--Samer
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Monday, August 25, 2014 1:03 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdeModulePkg: Fix EBC DXE issue with x64 function
call al
Dear BaseTools maintainers,
Please see attached a minor change to build.py to display progress during
processing meta-data (pre-processing and creating autogen files). Without this
change, the build "pauses" for a long time giving the perception that some
modules are taking a long time to build
Jaben / Erik,
Can you please review this?
This patch fixes 'ren' alias for 'mv' command.
ShellPkg: Fix 'ren' alias for 'mv' command.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah
ren_alias.diff
Description: ren_alias.d
This adds support for retaining UEFI environment variables in the second
emulated NOR flash which resided at phys address 0x0400 (64 MB).
Note that this requires booting QEMU with two -pflash arguments, each of which
points to a NOR image file of exactly 64 MB in size. The second one will be u
From: Michael Casadevall
For virtual machines, the physical architected timer may not be available,
so we need to allow the virtual timer to be used instead.
Signed-off-by: Michael Casadevall
Signed-off-by: Ard Biesheuvel
---
ArmPkg/ArmPkg.dec | 5 ++
ArmPkg/D
This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
The following assumptions are made about the target:
- ARM architected timer
- PL011 UART at 0x900
- at least 1 MB of DRAM at 0x4000, containing the device tree blob
The following information is retrieved from t
This changes the definition and a bunch of references to
gArmTokenSpaceGuid.PcdSystemMemoryBase and
gArmTokenSpaceGuid.PcdSystemMemorySize so they can be declared as dynamic PCDs
by the platform. Also, move the non-SEC call to
ArmPlatformInitializeSystemMemory() earlier, so a platform has a chance
Allow the PCDs gArmPlatformTokenSpaceGuid.PcdPL031RtcBase and
gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy PCDs to be
declared as PcdsDynamic by the platform so they can be overridden
during boot.
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmPlatformPkg.dec | 9 +
1 file chan
Remove the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase from PrePeiCoreUniCore.inf,
as they are not in fact used by the module.
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf | 2 --
1 file changed, 2 deletio
This adds the possibility to include a DTB blob into the firmware image, and
have it installed as a configuration under the correct GUID at UEFI init time.
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/MdeModulePkg.dec | 2 +
MdeModulePkg/MdeModulePkg.dsc
To support booting on virtual machines whose interrupt routing is
discovered from the device tree, allow the interrupt numbers to
be redeclared as PcdsDynamic by the platform .dsc
---
ArmPkg/ArmPkg.dec| 2 ++
ArmPkg/Drivers/TimerDxe/TimerDxe.c | 6 ++
This series adds a platform config to support QEMU based virtual machines,
either in TCG or KVM mode. These virtual machines declare their platform
configuration by passing a device tree which needs to be parsed by Tianocore
rather than relying on hardcoded peripherals.
Currently, the only assump
Allow the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase to be redeclared
as PcdsDynamic by the platform, so virtual machines can set these
properties during boot. As the PcdGet32() calls now call into the
PCD database, cache the values that are re
In the ARM world, it is quite common to have NOR flash at 0x0 and DRAM
elsewhere. Don't treat pointers to FVs residing there as invalid NULL pointers
but as a valid 0x0 physical address.
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Core/Pei/FwVol/FwVol.c | 6 +-
1 file changed, 1 insertion
Dear MdeModulePkg maintainers,
Please bug in DisplayEngine that caused an issue with displaying long strings
on the top level page (typically FrontPage) when the page is displayed the
first time.
The original code does not initialize the global width constants before
creating menu options. Th
On Mon, Aug 25, 2014 at 8:40 AM, Carsey, Jaben wrote:
> Reviewed-by: Jaben Carsey
Tested-by: Jordan Justen
committed in r15889
> From: Qiu, Shumin
> Sent: Sunday, August 24, 2014 9:33 PM
> To: Carsey, Jaben
> Cc: 'edk2-devel@lists.sourceforge.net'
> Subject: [edk2][Patch][ShellPkg]Fix invalid
Samer,
Can you please verify that the stack is aligned in native code before calling
the EBC function where this fix was required?
If the native stack is always aligned correctly, can you please provide a small
test case that reproduces the issue along with all the compiler/linker flags
used.
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 w
Mike,
I responded to Jiewen on another thread (for the other EBC DXE issue):
We found the bugs during validation of an HP storage adapter that uses an EBC
driver. When running the EBC driver on an X64 server with certain optimizations
disabled in the UEFI system firmware (specifically, /GL and
Jiewen,
We found the bugs during validation of an HP storage adapter that uses an EBC
driver. When running the EBC driver on an X64 server with certain optimizations
disabled in the UEFI system firmware (specifically, /GL and /LTCG removed), the
driver hangs (sometimes with an exception). These
Samer,
Can you please provide the details on how to reproduce an incorrect stack
alignment.
It has been a long time since we have worked on this code, and I recall
reviewing the stack alignment carefully at that time.
It is possible that the code that called an EBC function has misaligned the
Go ahead.
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com]
Sent: Monday, August 25, 2014 10:20 AM
To: Carsey, Jaben; Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Regarding commit: ShellPkg: Update 'pci' command for
updated class codes
Importance:
On Mon, Aug 25, 2014 at 10:01 AM, Carsey, Jaben wrote:
> I realized that after I saw the other email. There is an outstanding patch
> on the mailing list. Should get committed tonight.
Jaben,
I tested Qiu's patch, and it seems pretty trivial (unlikely to break
anything). Can I commit it to She
I realized that after I saw the other email. There is an outstanding patch on
the mailing list. Should get committed tonight.
-Jaben
From: Andrew Fish [mailto:af...@apple.com]
Sent: Monday, August 25, 2014 9:52 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Regarding commit: Shell
On Aug 25, 2014, at 8:41 AM, Carsey, Jaben wrote:
> Do you know why it fails?
>
> Is the < or > the incorrect ASCII character?
>
As Lasszio mentioned <96> is not a valid UTF-8 encoding. U+0096 is C2 96 in
UTF-8. Not to mention U+0096 is a character. So the file contains
some non portable
There is a patch already outstanding on the mailing list that fixes this
invalid character.
Thanks!
-Jaben
-Original Message-
From: Gabriel L. Somlo [mailto:gso...@gmail.com]
Sent: Monday, August 25, 2014 9:10 AM
To: edk2-devel@lists.sourceforge.net
Cc: Carsey, Jaben
Subject: another bu
Hi Samer
Thanks for the contribution for 2 EBC bug fixes. Below is my comments:
1) It looks they are bug, so would you mind to share us the information:
how you find the bug, and how you validate the fix?
2) I found below line has NON-ASCII char, please help to correct it.
+ ;
Dear MdeModulePkg maintainers,
Please find the attached patch to fix an issue in the EBC DXE interpreter for
X64 native function prolog.
Fix X64 native function call prolog. Prepare space for at least 4 arguments,
even if the native function's arguments are less than 4.
>From MSDN x64 Softw
What is the platform hardware configuration?
Thanks ... br
---
Brian Richardson -- brian.richard...@intel.com -- Twitter: intel_brian
From: ritul guru (riguru) [mailto:rig...@cisco.com]
Sent: Monday, August 25, 2014 9:42 AM
To: edk2-devel@lists.sourceforge.net
Cc: Richardson, Brian
Subject: RE: [
Dear MdeModulePkg maintainers,
Please find the attached patch to fix a stack alignment in EBC DXE interpreter
for X64 native calls:
Fix EBC X64 native call to be 16-byte aligned. From MSDN x64 Software
Conventions:
"The stack will always be maintained 16-byte aligned,
except within the prolo
Dear MdeModulePkg maintainers,
Please find the attached patch that adds a new function
HiiCreateGuidLabelOpCode() to HiiLib
Add a new function HiiCreateGuidLabelOpCode() to HiiLib to help with creation
of Label IFR op-codes dynamically
Contributed-under: TianoCore Contribution Agreement 1.0
Hi,
Apparently, commit f056e4c18047e9a0157a915175d07afbd8b8c581 causes
the build process to fail. I use Fedora 20 with the following command
line:
build -a X64 -t GCC48 -p OvmfPkg/OvmfPkgX64.dsc
The commit details are:
commit f056e4c18047e9a0157a915175d07afbd8b8c581
Author: Jaben Carsey
Reviewed-by: Jaben Carsey
From: Qiu, Shumin
Sent: Sunday, August 24, 2014 9:33 PM
To: Carsey, Jaben
Cc: 'edk2-devel@lists.sourceforge.net'
Subject: [edk2][Patch][ShellPkg]Fix invalid character in ShellPkg
Importance: High
Hi Jaben,
Can you help to review this patch?
For Invalid character '-' in
Do you know why it fails?
Is the < or > the incorrect ASCII character?
-Jaben
From: Neeraj Ladkani [mailto:neeraj.ladk...@gmail.com]
Sent: Saturday, August 23, 2014 1:24 PM
To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: Regarding commit: ShellPkg: Update 'pci' command for updated c
Thanks Liming
From: Gao, Liming [mailto:liming@intel.com]
Sent: Monday, August 25, 2014 10:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition
from UEFI 2.4
The patch is good. I will help commit it.
Reviewed-by: Gao, Limin
Yes, I installed nasm.
Neeraj
Did you update Conf/build_rules.txt to use nasm?
On 25.08.2014, at 14:29, chen.fan.f...@cn.fujitsu.com wrote:
> Hi,
>
> I always built OVMF successfully, but today I pull the newest edk2 code
> to build OVMF then showing building failure:
>
> ---
The patch is good. I will help commit it.
Reviewed-by: Gao, Liming
Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Saturday, August 23, 2014 7:16 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg: Add IMAGE_ATTRIBUTE_UEFI_IMAGE definition
After you update EDKII code base, please remove Conf/build_rules.txt first,
then call edksetup script to copy new build_rules.txt
And, you also need to install nasm compiler.
-Original Message-
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Monday, August 25, 2014 9:23 PM
To: edk2-d
Makes sense. Please disregard until the spec is published.
Thanks,
--Samer
From: Li, Elvin [mailto:elvin...@intel.com]
Sent: Sunday, August 24, 2014 7:57 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdePkg: Add DDR4 SMBIOS enumeration
Hi,
From
http://www.
Hi Brian,
Yes, I have tried booting from fs0:\EFI\Microsoft\Boot\BOOTMGFW.efi,
But it also gave the save Unsupported Error.
And I have just verified that OS is not calling ExitBootServices() means this
error is coming before call to ExitBootServices().
Could there be issue while OS installation a
Once the OS is installed, the primary loader is in the EFI\Microsoft directory.
Thanks ... br
---
Brian Richardson -- brian.richard...@intel.com -- Twitter: intel_brian
From: ritul guru (riguru) [mailto:rig...@cisco.com]
Sent: Monday, August 25, 2014 7:15 AM
To: edk2-devel@lists.sourceforge.net
S
Did you update Conf/build_rules.txt to use nasm?
On 25.08.2014, at 14:29, chen.fan.f...@cn.fujitsu.com wrote:
> Hi,
>
> I always built OVMF successfully, but today I pull the newest edk2 code
> to build OVMF then showing building failure:
>
>
I faced the same issue. For time being I commented line 506 in PCI.c and
build. It builds fine. Pls look at my last post on this forum regarding
same.
Neeraj
On Aug 25, 2014 4:01 PM, "chen.fan.f...@cn.fujitsu.com" <
chen.fan.f...@cn.fujitsu.com> wrote:
> Hi,
>
> I always built OVMF successfully,
Hi,
> The current calculation is correct for stdvga, because on stdvga the value
> returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is
> usable for drawing.
Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a qemu
bug. We have releases with the bug in the w
Hi,
I am trying to install and boot from win2012 R2 UEFI OS.
I could install this OS in UEFI mode properly and but while booting I.e.
executing the BOOTX64.efi from UEFI shell getting below error:
[cid:image001.png@01CFC083.F5F47080]
What could be the issue here?
Regards,
Ritul
-
Hi, all
This patch is for below ITEM 7. INF/DEC are generated from UPT tool.
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help
review them.
CryptoPkg: Make sure order of DEC/INF content matches the order that UPT
generates in the XML -> INF conversion
1)
Hi, all
This patch is for below ITEM 7. INF/DEC are generated from UPT tool.
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help
review them.
NetworkPkg: Make sure order of DEC/INF content matches the order that UPT
generates in the XML -> INF conversion
1)
Hi, all
This patch is for below ITEM 7. INF/DEC are generated from UPT tool.
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help
review them.
SourceLevelDebugPkg: Make sure order of DEC/INF content matches the order
that UPT generates in the XML -> INF conversion
Hi, all
This patch is for below ITEM 7. INF/DEC are generated from UPT tool.
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help
review them.
UefiCpuPkg: Make sure order of DEC/INF content matches the order that UPT
generates in the XML -> INF conversion
1)
Hi, all
This patch is for below ITEM 7. INF/DEC are generated from UPT tool.
DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. Please help
review them.
PcAtChipsetPkg: Make sure order of DEC/INF content matches the order that
UPT generates in the XML -> INF conversion
1)
1 - 100 of 105 matches
Mail list logo
