Reviewed-by: Ye Ting
-Original Message-
From: Wu, Jiaxin
Sent: Tuesday, May 31, 2016 10:34 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan
Subject: [PATCH v2] MdeModulePkg: Fix SNP.Initialize() spec conformance issue
v2:
*Refine the coding style according edk2 community's fee
On 2016-05-30 20:19:42, Gary Lin wrote:
> When OVMF tried to load the file-based NvVars,
Tangent: Will Xen ever add a r/w flash emulation for variables like
QEMU/KVM?
> it checked all the PCI
> instances and connected the drivers to the mass storage device. However,
> Xen registered its PCI devic
Hi Andrew,
> The ELF should be linked at zero so that seems like the bug? It looks like
> your code is linking at 0x0040. Is that breaking the code that is
> converting to PE/COFF?
[Steven]: No in fact, the start address of ELF shared library does not matter.
The real running address will be
Reviewed-by: Jordan Justen
Pushed as 2f7b34b20842fcc485b39c0e1e91313c47b4d090.
On 2016-05-30 20:41:46, Gary Lin wrote:
> We reached the size limit again.
> Building OVMF with the following command
>
> $ ./OvmfPkg/build.sh -D SECURE_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
> HTTP_BOOT_ENABLE
>
> a
Hi,
VFR and UNI will be generated as the global byte array in AutoGen code, then
HiiDriver can call HiiAddPackages() with them to add them into HiiDataBase so
that they can be displayed. After the global byte array is built into image,
the below logic in GenFds will try to find them in the ma
On Tue, May 31, 2016 at 12:21:45AM -0700, Jordan Justen wrote:
> On 2016-05-30 20:19:42, Gary Lin wrote:
> > When OVMF tried to load the file-based NvVars,
>
> Tangent: Will Xen ever add a r/w flash emulation for variables like
> QEMU/KVM?
I don't know. It seems not going to happen in the short te
On 05/31/16 06:59, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add ACPI support for Virt Xen ARM and it gets the ACPI tables through
> Xen ARM multiboot protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao
> ---
> The corresponding Xen patches can
On 05/31/16 10:10, Jordan Justen wrote:
> Reviewed-by: Jordan Justen
>
> Pushed as 2f7b34b20842fcc485b39c0e1e91313c47b4d090.
Thanks! I tested it with SMM + S3, it seems to work fine. It also
matches earlier commit 08df58ec3043.
I compared the debug logs as well:
-DecompressMemFvs: OutputBuffer
Hello Mike,
our virt-QE team reported an interesting issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1308678#c14
We have a small UEFI_APPLICATION ((open source, of course) that enrolls
a set of fixed certificates into PK / KEK / DB.
In the course of the gRT->SetVariable() call, using the SMM
On 05/31/16 13:42, Laszlo Ersek wrote:
> Hello Mike,
>
> our virt-QE team reported an interesting issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1308678#c14
>
> We have a small UEFI_APPLICATION ((open source, of course) that enrolls
> a set of fixed certificates into PK / KEK / DB.
>
>
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> This cosmetic change only tidies things up in preparation for actual
> updates. (This reflects responses to a previously submitted patch,
> which has been split into several discrete changes.)
> There are no functional changes in this commit
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> The PCDs used in the PL011 UART Driver and Serial Port Library are
> inherently "fixed at build". This change updates the source to use
> Fixed PCDs for these values. This improves clarity and efficiency.
>
> Contributed-under: TianoCore C
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> The variable LineControl was initialised to zero, then updated in a
> condition. This change converts that to a write in each branch of the
> condition, removing the Write/Read/Modify/Write sequence.
>
> Contributed-under: TianoCore Contrib
Hi,
I want to readout the SMRAM of an existing UEFI-Bios.
Therefore I wrote a UEFI application inherited by the EDK2 sample
MemoryProfileInfo:
EFI_STATUS GetSmramProfileData(VOID)
{
EFI_STATUS Status;
UINTN CommSize;
UINT8* pCommBuffer;
EFI_SMM_COMMUNICATE_HEADER* pCommHeader
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> On some platforms the UART clock is not the same for all the serial
> ports. The PL011 driver must be capable of handling serial ports with
> different clock rates, so must not rely on a PCD for the clock rate.
>
> This patch allows the UART
Michael:
I think this change needs some discussion. It will impact current usage
model. Now, after tools_def.txt is copied to Conf directory, user could
directly modify it to match its tool configuration. After this change, all tool
chain definitions will always be kept into BaseTools\Conf. If
This patch is used to handle timeout case when downloading
the message. The Status in the token should also be checked
to handle any response error case including timeout case.
Cc: Fu Siyuan
Cc: Ye Ting
Cc: Zhang Lubo
Cc: Hegde Nagaraj P
Cc: Gary Lin
Contributed-under: TianoCore Contribution
Cc: Ye Ting
Cc: Fu Siyuan
Cc: Zhang Lubo
Cc: Hegde Nagaraj P
Cc: Gary Lin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu
Jiaxin Wu (3):
NetworkPkg: Support TCP Cancel function
NetworkPkg: HttpDxe response/cancel issue fix
NetworkPkg: Handling timeout c
yes I thought so.
It depends on the usage model.
if you just want to add a new/custom toolchain or change paths(these are
still in the main tools_def.txt!) the new way is definitely better because
u can just add a include for your configuration and edit paths.
But if you just want to change a few
> On May 31, 2016, at 1:01 AM, Shi, Steven wrote:
>
> Hi Andrew,
>> The ELF should be linked at zero so that seems like the bug? It looks like
>> your code is linking at 0x0040. Is that breaking the code that is
>> converting to PE/COFF?
> [Steven]: No in fact, the start address of ELF sha
Hi Nagaraj and Gary,
Please help to review and verify the series patches.
Thanks and Best regards!
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, May 31, 2016 10:17 PM
> To: edk2-devel@lists.01.org
> Cc: Y
> On May 31, 2016, at 7:26 AM, Andrew Fish wrote:
>
>>
>> On May 31, 2016, at 1:01 AM, Shi, Steven wrote:
>>
>> Hi Andrew,
>>> The ELF should be linked at zero so that seems like the bug? It looks like
>>> your code is linking at 0x0040. Is that breaking the code that is
>>> converting
Hi,
with the PACKAGES_PATH environment variables and the '--conf=CONFDIRECTORY'
build tool argument, BaseTools and Build are the only things that still put
binaries in the source tree.
Are there any intentions to change this?
If we allow the BaseTools' makefiles to be run from somewhere else(like
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> This change corrects 3 problems in the PL011 driver.
> 1. The TRM states "The UARTLCR_H, UARTIBRD, and UARTFBRD registers must
>not be changed:...when the UART is enabled"
> 2. The TRM (3.3.8) describes logic requiring the UART to be dis
Hi Andrew,
Thank you! Your comments really help me!
> If you turn off LTO what does the code look like? Does it work? This looks
> like a linker error, but it is hard to say if it is the compiler or linker at
> fault.
[Steven]: If I turn off LTO, everything worked very well, but maybe I was
> On May 31, 2016, at 6:51 AM, Juergen Rall wrote:
>
> Hi,
>
> I want to readout the SMRAM of an existing UEFI-Bios.
> Therefore I wrote a UEFI application inherited by the EDK2 sample
> MemoryProfileInfo:
>
> EFI_STATUS GetSmramProfileData(VOID)
> {
>EFI_STATUS Status;
>UINTN CommSize
On 05/31/16 15:51, Juergen Rall wrote:
> Hi,
>
> I want to readout the SMRAM of an existing UEFI-Bios.
> Therefore I wrote a UEFI application
If that worked, it would be a security vulnerability for your platform.
SMRAM is (supposed to be) locked down before third party (=
non-platform) code gets
All,
I am attempting to generate an compressed ROM image for our NIC driver.
I have the following defined in my .INF file -
PCI_VENDOR_ID = 0x177D
PCI_DEVICE_ID = 0x9700
PCI_CLASS_CODE = 0x0200
PCI_REVISION = 0x0003
PCI_COMPRESS = TRUE
However, when I issue the build command -
buil
Add missing "done" token needed to complete the for loop. Tested in
Ubuntu 14.04
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer
---
BaseTools/BinWrappers/PosixLike/LzmaF86Compress | 48 +
1 file changed, 25 insertions(+), 23 deletions
When ASSERTS are enabled, running the expression twice could have unintended
consequences, particularly if a variable is being incremented or modified in
some fashion.
Thomas
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin
Häuser
Sent: M
Sorry, I did not see the previous response until after I sent this email. I
love my email client ...
Thomas
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Palmer,
Thomas
Sent: Tuesday, May 31, 2016 12:35 PM
To: Marvin Häuser ; edk2-devel@lists
Adding defines from FSP EAS v2.0 section 11.2.2 Oem Status code.
Cc: Jiewen Yao
Cc: Maurice Ma
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru
---
IntelFsp2Pkg/Include/FspEas/FspApi.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Int
Reviewed-by: Maurice Ma
Regards,
-Maurice
-Original Message-
From: Mudusuru, Giri P
Sent: Tuesday, May 31, 2016 1:08 PM
To: edk2-devel@lists.01.org
Cc: Mudusuru, Giri P; Yao, Jiewen; Ma, Maurice
Subject: [edk2] [PATCH 1/1] IntelFsp2Pkg: Add missing OEM status code defines.
Adding defin
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Ma, Maurice
> Sent: Wednesday, June 1, 2016 4:54 AM
> To: Mudusuru, Giri P
> Cc: Yao, Jiewen ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 1/1] IntelFsp2Pkg: Add missing OEM status code
> defines.
>
> Reviewed-by: Ma
Hi,
Memory profile feature is not provided to read SMRAM area. It is provided to
collect the memory usage of different memory types for drivers.
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Juergen
Rall
Sent: Tuesday, May 31, 201
Palmer:
Your change is good. But, your patch also changes the file style from unix to
dos. Please keep it as unix file format, because this file is used in Linux
only.
Thanks
Liming
> -Original Message-
> From: Thomas Palmer [mailto:thomas.pal...@hpe.com]
> Sent: Wednesday, June 01, 2
Hi,
I wrote a USB CCID driver and it works on QEMU with OVMF. However, I found
it fail on real machines.
First I boot a laptop with UEFI support to UEFI shell. Then I load the
driver and insert the CCID device (I'm using a Yubikey 4), and I can see
the driver successfully run the DriverBindingSta
Is the bulk transfer running in your APP is the first call? Do you try the bulk
transfer at your CCID driver binding start()?
And which mode are you running at real platform and QEMU? EHCI or XHCI? Which
usb driver is managed the usb host controller at real platform? Is it AMI's or
Intel's? Ho
On Wed, Jun 1, 2016 at 10:20 AM, Tian, Feng wrote:
> Is the bulk transfer running in your APP is the first call? Do you try the
> bulk transfer at your CCID driver binding start()?
>
Yes, the first bulk transfer is in the application. In driver binding
supported() and start() I only get the desc
This series patch adds the initial version of IntelSiliconPkg
and an include file.
We will use IntelSiliconPkg for open source common Intel silicon
related modules.
Jiewen Yao (2):
IntelSiliconPkg: Add initial version.
IntelSiliconPkg/IgdOpRegion: Add definition for Intel IGD OpRegion.
Int
This package will include open source common Intel silicon related modules.
Cc: Giri P Mudusuru
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
IntelSiliconPkg/Contributions.txt | 218
IntelSiliconPkg/IntelSiliconPkg.dec | 24 +++
In
Add IGD OpRegion definition from Intel Integrated Graphics Device OpRegion
Specification.
at https://01.org/sites/default/files/documentation/acpi_igd_opregion_spec_0.pdf
Cc: Giri P Mudusuru
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
IntelSiliconPkg/In
Hi Juergen
1) If you are asking SMM profile feature, my comments below:
This SMRAM profile feature is only debug feature. Default is disable. See below:
## The mask is used to control memory profile behavior.
# BIT0 - Enable UEFI memory profile.
# BIT1 - Enable SMRAM profile.
# @P
Thanks Jiewen. Looks good to me.
Reviewed-by: Giri P Mudusuru
-Original Message-
From: Yao, Jiewen
Sent: Tuesday, May 31, 2016 8:02 PM
To: edk2-devel@lists.01.org
Cc: Mudusuru, Giri P
Subject: [PATCH 1/2] IntelSiliconPkg: Add initial version.
This package will include open source com
Thanks Jiewen. Few comments.
1) Size of RSV1 in OPREGION HEADER as per spec is 0x9F and in code it is 0x3C
(table2-2 section 2.2.1)
+ UINT8 RSV1[0xA0]; ///< Offset 96 Reserved
+} INTEL_IGD_OPREGION_HEADER;
2) Size of RSV3 in MBOX1 as per spec is 0x40 and in code it is 0x3C (table3-1
secti
Hi, Iru
I suggest you don't pass down the timeout value 0. The infinite waiting for 0
was added at an intermediate reversion. So the bios you are using may not
include this code.
Thanks
Feng
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Iru C
HI Giri
Thanks! I did check spec. Comments below:
1) I think it is a spec bug. The size should be 0xA0 if we want to make sure
the OPREGION_HEADER is 0x100 bytes. (0xA0 + 96 = 0x100). So I fixed it when I
write the code.
2) I think it is a spec bug The size should be 0x3C if we want to make sur
Thanks Jiewen for clarification. Can you please add comments in file to avoid
confusion during check-in?
Reviewed-by: Giri P Mudusuru
Thanks,
-Giri
-Original Message-
From: Yao, Jiewen
Sent: Tuesday, May 31, 2016 10:26 PM
To: Mudusuru, Giri P ; edk2-devel@lists.01.org
Subject: RE: [PAT
Yes. I agree.
It is a good idea to add comment to clarify the mismatch.
Again, thanks to catch that.
Thank you
Yao Jiewen
From: Mudusuru, Giri P
Sent: Wednesday, June 1, 2016 1:31 PM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Mudusuru, Giri P
Subject: RE: [PATCH 2/2] IntelSiliconPkg/IgdOpReg
Laszlo,
Have you any clue on bisect this issue?
SmiDefaultPFHandler() is used to dynamically setup page entry for those address
> 4GBytes.
If your platform is really accessing > 4GBytes address, Page Fault happened
does make sense.
Otherwise, please check PFAddress value to understand why PFAd
I think it is possible to run into PF in SMM. SMM only allocate 4G memory by
default, and use PF to handle >4G memory access.
On X64 version BIOS, if a platform has >4G memory, all those are reported as
usable, and no memory type info is reported, then the DXE core will treat >4G
memory as vali
Hi, Jeff
In patch #1, I didn't see you update the file comments to show it support PEI
phase.
In patch #8, suggest to move the HOB_GUID definition to ExceptionCommon.h file.
If you fix them, you can have my RB.
Reviewed-by: Feng Tian
Thanks
Feng
-Original Message-
From: edk2-devel [m
52 matches
Mail list logo
