On Thu, Jul 16, 2015 at 12:41:17AM +0200, Laszlo Ersek wrote:
> This function is only called from Xen.c, so it should be defined in Xen.c
> and have internal linkage (ie. STATIC).
>
> Cc: Jordan Justen
> Cc: Wei Liu
> Cc: Gabriel Somlo
> Contributed-under: TianoCore Contribution Agreement 1.0
>
On 07/16/15 17:34, Wei Liu wrote:
> CC Ian, Stefano and Julien who are familiar with ARM side of things.
Right -- I Cc'd Ard too on this patch because he implemented the ARM
hypercalls.
For now, this patch series explicitly doesn't try to implement
SMBIOS-on-ARM-Xen. That could be a future featur
On Thu, Jul 16, 2015 at 12:41:18AM +0200, Laszlo Ersek wrote:
> The Xen code in SmbiosPlatformDxe is centered on the informational HOB
> with GUID gEfiXenInfoGuid. This Xen hand-off mechanism is specific to the
> IA32 and X64 architectures. Therefore, sequester it from the rest of the
> source with
On Thu, Jul 16, 2015 at 12:41:17AM +0200, Laszlo Ersek wrote:
> This function is only called from Xen.c, so it should be defined in Xen.c
> and have internal linkage (ie. STATIC).
>
> Cc: Jordan Justen
> Cc: Wei Liu
> Cc: Gabriel Somlo
> Contributed-under: TianoCore Contribution Agreement 1.0
>
CC Ian, Stefano and Julien who are familiar with ARM side of things.
On Thu, Jul 16, 2015 at 12:41:18AM +0200, Laszlo Ersek wrote:
> The Xen code in SmbiosPlatformDxe is centered on the informational HOB
> with GUID gEfiXenInfoGuid. This Xen hand-off mechanism is specific to the
> IA32 and X64 arc
After changing the USB stack to make it synchronous at initialization,
we were checking if there was a pending interrupt when the USB interrupt
was initialized for a specific device.
At the first enumeration, all the connected USB devices are initialized.
USB device drivers initialize their USB int
The USB stack uses BS.SignalEvent and Timer event to initialize the USB stack.
It means a USB device initialization might not be completed when returning
from BS.ConnectController().
This behaviour is not compliant with the UEFI spec.
This change is only a _temporary hack_ as it forces the enumera
After changing the USB stack to make it synchronous at initialization,
we were checking if there was a pending interrupt when the USB interrupt
was initialized for a specific device.
At the first enumeration, all the connected USB devices are initialized.
USB device drivers initialize their USB int
The current USB stack is broken when you call BS.ConnectController()
with a USB device Device Path for instance like
PciRoot(0)/PCI(31,2)/USB(1,0)/USB(3,0)
The issue is not new and has probably always existed.
What the UEFI specification says about EFI_DRIVER_BINDING_PROTOCOL.Start():
If the dr
The USB stack uses BS.SignalEvent and Timer event to initialize the USB stack.
It means a USB device initialization might not be completed when returning
from BS.ConnectController().
This behaviour is not compliant with the UEFI spec.
This change is only a _temporary hack_ as it forces the enumera
Hi Siyuan,
I sent a patch on the 5th July with the title "[PATCH] Fix bug in
IpSecImpl.c causes by missing parentheses" that didn't get any reviews and
hasn't been committed. Would it be possible to have it reviewed please?
I wrote it against the UDK2014.SP1 branch, but I guess it could be commit
On 7/16/2015 12:01 AM, He, Tim wrote:
> I am using the "TortoiseGit" tool, which version is 1.8.14.0. the parameters
> I am using is "git.exe am --3way --ignore-space-change --keep-cr ".
Thanks. I've tried using the same tool and I'm seeing errors like:
0 [main] mv 5252 open_stackdumpfile
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
Reviewed-by: Ronald Cron
---
StdLib/StdLib.inc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/StdLib/StdLib.inc b/StdLib/StdLib.inc
index 1b7fcf0..391c7c9 100644
--- a/StdLib/StdLib.inc
+++ b/StdLib/
This patchset adds support for ARM SoftFloat. ARM Hardware floating
point is disabled when building UEFI Firmware.
Software Floating point is required to get full StdLib support.
This support also adds AArch64 support.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier M
On Fri, 10 Jul, at 04:23:58PM, Ard Biesheuvel wrote:
>
> Is there a reason to set strict permissions at all on the 1:1 mapping?
> Does it stick around after having called SVAM () ?
>
> My (naive) suggestion would be to apply the strict permissions only to
> the virtual remapping of the runtime se
From: Brendan Jackman
- Use some files from ARM version.
- Use NetBSD software floating point library to provide floating point
operations not handled directly by hardware floating point enabled
GCC compiler.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Harry Liebel
From: Harry Liebel
Provide missing functionality by using files from LLVM.
Changes made:
- Formatting changes (tabs to spaces, DOS line endings etc).
- Simplified 'int_endianness.h' to work for our case.
- Added LLVM licence to the individual files.
Contributed-under: TianoCore Contribution Agr
On 07/16/2015 05:56 PM, Laszlo Ersek wrote:
> On 07/16/15 04:09, Heyi Guo wrote:
>> This is bug fix for TerminalDxe: NullRemaining should be set to FALSE
>> by fault and then be set to TRUE conditionally.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Heyi Guo
>>
On 07/16/15 10:51, Ard Biesheuvel wrote:
> On 16 July 2015 at 10:21, Heyi Guo wrote:
>> There were some issues when I ran SCT test against Serial IO Protocol
>> on qemu aarch64, and below patches were made after I went through the
>> code of TerminalDxe driver and the flow of console devices being
Hi Olivier,
On 07/16/15 01:41, Olivier Martin wrote:
> For people who does not know me I have been the EDK2 maintainer of
> the ARM Packages for the last 4 years. I took over the excellent work
> Andrew Fish and Eugene Cohen started few years before.
>
> This week was my last week at ARM - my las
On 07/16/15 04:09, Heyi Guo wrote:
> This is bug fix for TerminalDxe: NullRemaining should be set to FALSE
> by fault and then be set to TRUE conditionally.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Heyi Guo
> ---
> MdeModulePkg/Universal/Console/TerminalDxe/Te
On 07/16/15 04:09, Heyi Guo wrote:
> Change default terminal type to be consistent with default
> ConIn/ConOut device path, which is now determined by TTY_TERMINAL
> flag, TTYTERM or VT100.
>
> I can't say this is a bug, as we can pass the whole console device
> path to ConnectController, and Term
On 07/16/15 04:09, Heyi Guo wrote:
> There were some issues when I ran SCT test against Serial IO Protocol
> on qemu aarch64, and below patches were made after I went through the
> code of TerminalDxe driver and the flow of console devices being
> connected.
>
> V2 is based on TTY terminal patches
On 07/16/15 06:45, Jordan Justen wrote:
> Can you just split this into two patches?
>
> I think we should keep patches confined to updating a single module
> unless there is a technical reason to touch separate packages in a
> single patch.
>
> Or, I suppose if you are making the *exact* same cha
Reviewed-By: Olivier Martin
> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: 16 July 2015 09:35
> To: edk2-devel@lists.sourceforge.net
> Cc: Heyi Guo; Olivier Martin; Leif Lindholm
> Subject: [edk2] [PATCH] ArmPlatformPkg/Bds: Use HandleProtocol to get
> SNP inst
On 16 July 2015 at 10:21, Heyi Guo wrote:
> There were some issues when I ran SCT test against Serial IO Protocol
> on qemu aarch64, and below patches were made after I went through the
> code of TerminalDxe driver and the flow of console devices being
> connected.
>
> V2 is based on TTY terminal
LocateProtocol only gets the 1st SNP instance and this will be wrong
in a system with multiple SNP instances installed. Use HandleProtocol
instead.
Cc: Olivier Martin
Cc: Leif Lindholm
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
---
ArmPlatformPkg/Bds/BootOp
There were some issues when I ran SCT test against Serial IO Protocol
on qemu aarch64, and below patches were made after I went through the
code of TerminalDxe driver and the flow of console devices being
connected.
V2 is based on TTY terminal patches.
V3 updates comment for PcdDefaultTerminalType
1. Get default terminal type from PCD rather than using PCANSI
directly in BuildTeminalDevpath;
2. Only terminal type is needed to create an TerminalDev instance, so
remove the useless code of creating and freeing DefaultNode.
3. Some white space refining.
Cc: Feng Tian
Contributed-under: TianoCo
This is bug fix for TerminalDxe: NullRemaining should be set to FALSE
by fault and then be set to TRUE conditionally.
Cc: Feng Tian
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Reviewed-by: Ruiyu Ni
Reviewed-by: Feng Tian
---
MdeModulePkg/Universal/Console/T
Change default terminal type to be consistent with default
ConIn/ConOut device path, which is now determined by TTY_TERMINAL
flag, TTYTERM or VT100.
I can't say this is a bug, as we can pass the whole console device
path to ConnectController, and TerminalDxe driver will pick up the
terminal in the
Update comment for PcdDefaultTerminalType, as a new terminal type
TTYTERM has been added with type value of 4.
The new type is NOT defined in UEFI SPEC v2.5.
Cc: Michael D Kinney
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Reviewed-by: Liming
Update comment for PcdDefaultTerminalType, as a new terminal type
TTYTERM has been added with type value of 4.
The new type is NOT defined in UEFI SPEC v2.5.
Cc: Jordan Justen
Cc: Andrew Fish
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Reviewed-by: Jordan Ju
Reviewed-by: Liming Gao
-Original Message-
From: Heyi Guo [mailto:heyi@linaro.org]
Sent: Thursday, July 16, 2015 10:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH V3 1/4] MdePkg|EmulatorPkg: Update comment for
PcdDefaultTerminalType
Update comment for PcdDefaultT
Thanks for your helpful info.
On 07/16/2015 02:56 PM, Ard Biesheuvel wrote:
> On 16 July 2015 at 04:09, Heyi Guo wrote:
>> There were some issues when I ran SCT test against Serial IO Protocol
>> on qemu aarch64, and below patches were made after I went through the
>> code of TerminalDxe driver a
35 matches
Mail list logo
