If you just want debug output and you have the proper hardware/drivers to
send/receive serial output through USB (like with Intel's Minnowboard), you
can use any terminal, like PuTTY, and connect via serial.
If you need breakpoints and stepping, then I don't know. Hopefully someone
else has some
Hi Andrew,
your patches are good. I tested CpuExceptionHandler.lib and Thunk16.nasm in
Ovmf+Qemu2.0 compiled by GCC49. Works fine!
But with XCLANG (Xcode 4.4.1) I got an error
--
qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a
RAX=
That's correct.
If the idea is to add the Intel copyright at the top of the file, you can still
add the space before 'CpuDeadLoop()'...
-Original Message-
From: Gao, Liming [mailto:liming@intel.com]
Sent: 28 August 2014 15:52
To: Dong, Eric; Olivier Martin
Cc:
Got it, we no need to add intel copyright, I will not check in this patch.
Thanks,
Eric
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Monday, September 01, 2014 5:24 PM
To: Gao, Liming; Dong, Eric
Cc: edk2-devel@lists.sourceforge.net
Subject: RE: [edk2]
Below is UEFI definition for EFI_IFR_TYPE_VALUE, for string type, it use
EFI_STRING_ID to specify it, so for catenate, it uses STRING_TOKEN.
typedef union {
UINT8 u8;
UINT16 u16;
UINT32 u32;
UINT64 u64;
BOOLEAN b;
EFI_HII_TIMEtime;
Il 31/08/2014 20:23, Sergey Isakov ha scritto:
Clang assembler doesn’t support 16 bit codes.
(please don't top-post)
Does Apple not ship gas anymore and replaces it with clang's integrated
assembler?
In either case, how the clang folks can say use the clang integrated
assembler and file bugs
On 01.09.2014, at 14:58, Paolo Bonzini wrote:
Il 31/08/2014 20:23, Sergey Isakov ha scritto:
Clang assembler doesn’t support 16 bit codes.
(please don't top-post)
Does Apple not ship gas anymore and replaces it with clang's integrated
assembler?
Yes, does not ship
-bash: gas: command
As we add now Ahci support, we probably should also add Ahci support to Csm
module (IntelFrameworkModulePkg/Csm/LegacyBiosDxe), otherwise Ahci devices
won't appear as Legacy entries.
On Thu, Aug 21, 2014 at 12:55 PM, reza.jel...@tuhh.de wrote:
From: Reza Jelveh reza.jel...@tuhh.de
The
Sorry, I mixed the machine configurations. It builds fine on my old
distribution, but not on our build server:
- gcc (GCC) 3.4.2
- RHEL 5.8 (20 February 2012)
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: 01 September 2014 12:28
To: Andrew Fish;
I have pushed your patxhes through our CI build to make sure there is no
regression.
The build system raised these errors:
# Line endings (CRLF):
- ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
# Trailing space:
- ArmPkg/Drivers/TimerDxe/TimerDxe.inf
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Committed to SVN rev16014
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 28 August 2014 15:14
To: ler...@redhat.com; Olivier Martin; edk2-
de...@lists.sourceforge.net; peter.mayd...@linaro.org;
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Committed to SVN rev16015
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 28 August 2014 15:14
To: ler...@redhat.com; Olivier Martin; edk2-
de...@lists.sourceforge.net; peter.mayd...@linaro.org;
Hmm, this PCD looks to be specific to your platform. Only platform specific
components use this PCD.
Why do you not declare it into the DEC of your platform (ie:
ArmVirtualizationPkg/ArmVirtualizationQemu.dec)?
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
On 1 September 2014 18:04, Olivier Martin olivier.mar...@arm.com wrote:
Hmm, this PCD looks to be specific to your platform. Only platform specific
components use this PCD.
Why do you not declare it into the DEC of your platform (ie:
ArmVirtualizationPkg/ArmVirtualizationQemu.dec)?
Good
Some trailing space issues:
-
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Vir
tMem.c
-
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Vir
t.c
And line endings:
-
ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/ARM
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: 28 August 2014 23:08
To: Ard Biesheuvel; Olivier Martin; edk2-devel@lists.sourceforge.net;
peter.mayd...@linaro.org; christoffer.d...@linaro.org;
drjo...@redhat.com; ilias.bi...@linaro.org;
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 28 August 2014 15:14
To: ler...@redhat.com; Olivier Martin; edk2-
de...@lists.sourceforge.net; peter.mayd...@linaro.org;
christoffer.d...@linaro.org; drjo...@redhat.com;
ilias.bi...@linaro.org;
On Fri, Aug 29, 2014 at 2:22 PM, Andrew Fish af...@apple.com wrote:
On Aug 29, 2014, at 2:10 PM, Carsey, Jaben jaben.car...@intel.com wrote:
I think it’s a result of cut and paste via Microsoft office. When I look in
the SVN repo via Tortoise SVN they look ok.
I thought these mails are
For now, Visual Studio, WINDDK and ICC don't have this new dependency.
NASM 2.07 or newer should most likely be available for your OS. (Check
your package manager.)
For OS X, it looks like binaries can be downloaded:
http://www.nasm.us/pub/nasm/releasebuilds/2.11.05/macosx/
If you want to use a
Hi,
QvmfPkg compiled by XCODE5 to RELEASE works with Qemu 2.1.0 !
Great!
Sergey
On 01 сент. 2014 г., at 11:09, Sergey Isakov isakov...@bk.ru wrote:
Hi Andrew,
your patches are good. I tested CpuExceptionHandler.lib and Thunk16.nasm in
Ovmf+Qemu2.0 compiled by GCC49. Works fine!
But with
On 1 September 2014 17:19, Olivier Martin olivier.mar...@arm.com wrote:
I have pushed your patxhes through our CI build to make sure there is no
regression.
The build system raised these errors:
# Line endings (CRLF):
- ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
That's actually what I also had in mind when I saw your Feature PCD and your
TimerDxe changes. I was waiting the v6 to get a better understanding of the
impact of this new library interface.
My suggestion would be to use this interface and libraries:
-
Jordan, will this work with NASM 2.07?
As I noticed on [patch 7/8]MdePkg/BaseLib NASM Thunk16: Use bits 16 for
16-bit code
NASM produces bad object file for construction
pushss
pushcs
o32 calldword .Base ; push eip
.Base:
pushdword 0
I've contacted
Eric -
Please try the example. When I tried it, it cannot compile.
The EFI_IFR_CATENATE operator expects two strings expressions, right? How to
specify two strings in an expression? As far as I can tell, STRING_TOKEN is not
a valid expression term. Only stringref() is a valid expression term
On Mon, Sep 1, 2014 at 1:36 PM, Mike Maslenkin miha...@parallels.com wrote:
Jordan, will this work with NASM 2.07?
As I noticed on [patch 7/8]MdePkg/BaseLib NASM Thunk16: Use bits 16 for
16-bit code
NASM produces bad object file for construction
pushss
pushcs
o32 call
Tim,
VFR spec has a mistake about the sample code for catenate, the correct format
is like below which is same as your expectation:
string varid = MyData.String,
prompt = STRING_TOKEN(STR_PROMPT),
help = STRING_TOKEN(STR_HELP),
minsize = 6,
maxsize = 40,
inconsistentif prompt =
Eric -
Thank you. That is what I suspected.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 9:01 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] VFR Specification catenate example issue
Tim,
VFR spec has a mistake about the sample code for
Tim,
I agree Value of the question is the entire buffer, not just one byte. But I
don't think the value in a ONE_OF_OPTION is the value for the entire value
storage, not just one byte of the value storage.
Take below code for example, the value for this question is 0002,0001,0003,0004
(8
Eric -
It is pretty clear from the spec that the value size for ordered list is 1 byte
per container. See 29.2.5.4.8,
Storage The set questions are stored as a Buffer with one byte for each
Container.
There is no indication, either in the IFR or VFR specification that option
values refer to
Tim,
I admit that one container should only has one byte, and I think one option is
corresponding to one container, do you agree this assumption?
For below sample code, current code use UINT16 for BootOrder array, so the
value for each option is UINT16. Now I think we should not use UINT16
Hi Samer,
Thank you for capturing this issue. We agree that trying to locate IPsec
protocol on every packet is not good for performance. Though we don't quite
agree with the fix, since it removes the capability to support the case that
IPsec is deployed after IP driver is started. As IPsec
Tim,
I agree the browser should not process BOOLEAN type as an integer, and it
should push a Undefined to the stack when process | opcode. Later when
process suppressif opcode, the stack popup an Undefined result which is not
TRUE, so I think the question nest it will not be suppressed, do you
Hi, experts:
Based on UEFI Spec:
This protocol is used to abstract the block accesses of the Block I/O
protocol to a more general offset-length protocol.
The firmware is responsible for adding this protocol to any Block I/O
interface that appears in the system that does not already have a Disk
Andrew Fish [mailto:af...@apple.com] wrote:
On Aug 28, 2014, at 9:11 PM, Scott Duplichan sc...@notabs.org
mailto:sc...@notabs.org wrote:
Hello Deric,
You are right about the possibility of redefining STATIC. The problem with
doing so is that STATIC is used in 3 unrelated ways:
Hello Deric,
Your idea sounds workable for code written to accommodate it. But what about
ported code where multiple files have static functions
with the same name? As soon as the macro is set for compatibility with the
problematic debug environment, the link would fail due to
multiply
Hi, Sava
From my side, I am ok with integrating these two cases into one.
Please help review and verify if the attached patch is ok for Qemu and Marvel’s
AHCI controller.
Thanks
Feng
From: A. Sava [mailto:asava@gmail.com]
Sent: Monday, September 01, 2014 06:50
To:
Sava,
What Reza proposed is to add UEFI AHCI support (by UEFI BLOCK_IO protocol)
rather than legacy AHCI support (by int 13 service). The latter is usually
provided by IHV’s legacy AHCI oprom.
For UEFI AHCI support, BDS boot manager creates boot option according to UEFI
block io interface
37 matches
Mail list logo
