Mike:
Your issue is that X64 version doesn't work on machine with UG feature. You
find it can work when "call dword .Base" is used instead of "o32 calldword
.Base". So, your question is why o32 prefix used. Right?
Thanks
Liming
-Original Message-
From: Mike Maslenkin [mailto:miha
Sergey:
So, X64 Thunk16.nasm could pass XCLANG build and ld. What about IA32
Thunk16.nasm code?
Thanks
Liming
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Friday, August 29, 2014 2:15 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Requ
On 08/29/14 04:20, Laszlo Ersek wrote:
> IOW, please squash the 2nd patch too.
Attaching a 3rd one for squashing as well -- it adds the scsi bus & disk
drivers, so that you can actually use the virtio-scsi HBA for something.
(The protocol chain is [VirtioScsiDxe] -->
gEfiExtScsiPassThruProtocolGu
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:
1) static functions
2) static variables declared inside of a function
3) static variables declared outside of functions
If STATIC is defined as
Eric --
The UEFI specification says that "Data conversion is not implicit. Explicit
data conversion can be performed using the EFI_IFR_TO_STRING, EFI_IFR_TO_UINT,
and EFI_IFR_TO_BOOLEAN operators." (29.2.5.7.4) The VFR compiler in this case
is generating code that would not work on a conformant
Hi Chris,
I noticed you changed the copyright information from "Copyright (c) ..." to
"(C) Copyright ..." . Is this a new copyright style for HP? In order to keep
consistent with other files, do you want to change it back?
-Shumin
From: Phillips, Chris J (Plano, TX) [mailto:chr...@hp.com]
S
I check the current implementation of browser and vfrcompile, detail shows
below:
Below IFR data generated from the vfr file:
suppressif 8|8 == 0x8;
>01AA: 0A 82
>01AC: 45 8A 08 00 00 00 00 00 00 00
>01B6: 45 0A 08 00 00 00 00 00 00 00
>01C0: 45 0A 08 00 00 00 00 00 00 00
>
On 08/28/14 22:37, Laszlo Ersek wrote:
> If you had been in #edk2 on OFTC I'd have told you "I've added this to
> my queue, but don't hold your breath".
With "don't hold your breath", I only meant that my patch review queue
is not exactly short. It's nothing to do with the merits of this patch.
I
Apologies, I have some updates here:
On 08/29/14 01:17, Laszlo Ersek wrote:
> On 08/28/14 17:40, Ard Biesheuvel wrote:
>
>> + APRIORI DXE {
>> +INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>> + }
>> + INF MdeModulePkg/Core/Dxe/DxeMain.inf
>> + INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>>
Larry:
This patch will add new section "SVN Log Since Last Build".
is
its section end line?
Thanks
Liming
From: Hauch, Larry
Sent: Wednesday, August 27, 2014 5:45 AM
To: edk2-devel@lists.sourceforge.net; Gao, Liming
Subj
On 08/29/14 00:41, Gabriel L. Somlo wrote:
> On Thu, Aug 28, 2014 at 10:37:17PM +0200, Laszlo Ersek wrote:
>>>
>>> OvmfPkg/Library/AcpiTimerLib: Access power mgmt regs based on host bridge
>>> type
>>>
>>> Pick the appropriate bus:dev.fn for accessing ACPI power management
>>> registers (00:01.3 o
comments below
On 08/28/14 17:40, Ard Biesheuvel wrote:
> This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
> The following assumptions are made about the target:
> - DRAM base at 0x4000_, containing the device tree blob
> - DRAM size at least 1 MB
> - PL011 UART
So this leads to the follow on question (now that I've got the precedence
straight): suppressif 8|8 == 0x8 is an illegal statement.
in IFR (8 8 EFI_IFR_EQUAL 8 EFI_IFR_BITWISE_OR) since EFI_IFR_EQUAL results in
a BOOLEAN, but EFI_IFR_BITWISE_OR requires an integer, and IFR is strongly
typed.
On Thu, Aug 28, 2014 at 10:37:17PM +0200, Laszlo Ersek wrote:
> >
> > OvmfPkg/Library/AcpiTimerLib: Access power mgmt regs based on host bridge
> > type
> >
> > Pick the appropriate bus:dev.fn for accessing ACPI power management
> > registers (00:01.3 on PIIX4 vs. 00:1f.0 on Q35) based on the DI
On 08/28/14 16:14, Ard Biesheuvel wrote:
> This adds an implementation of EfiResetSystemLib that uses PSCI
> hypervisor calls to reboot and/or shutdown the system.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Casadevall
> Acked-by: Laszlo Ersek
> Signed-of
On 08/28/14 16:14, Ard Biesheuvel wrote:
> This is a fork of the ARM PlatformPeiLib for virtual machines. The main
> purpose of having this specific implementation is that it allows us to
> preserve the device tree blob if it was passed to us in system DRAM.
>
> Contributed-under: TianoCore Contri
Mike --
I think in most production cases, that is an acceptable limitation. But, if we
require further qualification, you could add a further field to qualify this by
INF
[Packages]
MdePkg/MdePkg.dec | Core/MdePkg/MdePkg.dec |
MdeModulePkg/Universal/Core/Dxe/DxeMain.inf
-Original Mess
On 08/28/14 16:14, Ard Biesheuvel wrote:
> This introduces an implementation of ArmPlatformSysConfigLib for virtual
> machines. This is currently a stub, but some peripheral drivers (such as
> the PL031 RTC driver) rely on one to be available.
>
> Contributed-under: TianoCore Contribution Agreemen
On 08/28/14 16:13, Ard Biesheuvel wrote:
> This is an implementation of ArmPlatformLib that discovers the size of system
> DRAM from a device tree blob located at the address passed in
> gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, which should equal the value in
> gArmTokenSpaceGuid.PcdSystemMemor
splendid updates, and I'm *almost* giving my R-b :) , but:
On 08/28/14 16:13, Ard Biesheuvel wrote:
> This driver enumerates the device nodes in the device tree located at the
> base address passed in gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, and
> installs drivers for devices it cares about (G
On 28 August 2014 20:57, Laszlo Ersek wrote:
> The FDF under review follows exactly scheme 2. The FD starts with a DATA
> region that starts with a manually encoded branch instruction to 0x1000.
> The DATA region encodes this branch instruction in 4 bytes, and the rest
> (4092 byes) come from the
Is this the whole point of defining "STATIC" rather than using the keyword
"static", that it can be redefined (locally) if it causes problems like this?
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Thursday, August 28, 2014 1:11 PM
To: Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.ne
On 08/28/14 16:13, Ard Biesheuvel wrote:
> This include file contains platform specific defines, and is shared by
> various modules.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Acked-by: Laszlo Ersek
> Signed-off-by: Ard Biesheuvel
> ---
> .../ArmVirtualizationPkg/Include/ArmP
On 08/28/14 16:13, Ard Biesheuvel wrote:
> 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.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Casa
On 08/28/14 16:14, Ard Biesheuvel wrote:
> This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
> The following assumptions are made about the target:
> - DRAM base at 0x4000_, containing the device tree blob
> - DRAM size at least 1 MB
> - PL011 UART at 0x900_
> -
On 08/28/14 22:29, Gabriel L. Somlo wrote:
>
> NOTE: I screwed up the mailing list address in the previous attempt,
> so please use this one to reply with feedback. Sorry about that !
>
>
> OvmfPkg/Library/AcpiTimerLib: Access power mgmt regs based on host bridge type
>
> Pick the appropriate b
NOTE: I screwed up the mailing list address in the previous attempt,
so please use this one to reply with feedback. Sorry about that !
OvmfPkg/Library/AcpiTimerLib: Access power mgmt regs based on host bridge type
Pick the appropriate bus:dev.fn for accessing ACPI power management
registers (00
On 08/28/14 17:26, Ard Biesheuvel wrote:
> On 28 August 2014 16:30, Laszlo Ersek wrote:
>> comments below
>>
>> On 08/27/14 17:12, Ard Biesheuvel wrote:
>>> + # Use the serial console (ConIn & ConOut) and the Graphic driver
>>> (ConOut)
>>> +
>>> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPa
Reviewed-by: Jaben Carsey
From: Qiu, Shumin
Sent: Wednesday, August 27, 2014 7:40 PM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2][Patch]ShellPkg: Remove 'STATIC' from function declarations to
avoid source level debugging problem
Importance: High
Hi Jaben,
Can you help
On 08/28/14 19:35, Andrew Fish wrote:
>
> On Aug 28, 2014, at 8:46 AM, Laszlo Ersek wrote:
>
>> On 08/28/14 17:17, Peter Maydell wrote:
>>> On 28 August 2014 16:16, Laszlo Ersek wrote:
On 08/28/14 16:59, Ard Biesheuvel wrote:
> However, putting a vector table in that particular place i
Sent from my iPhone
> On Aug 28, 2014, at 10:56 AM, "Kinney, Michael D"
> wrote:
>
> Andrew,
>
> A [Packages] section in the DSC file would be global and would not support
> multiple versions of the same package installed in a WORKSPACE with different
> modules requiring different versions
That works!
Now I have next same problem (offtop?)
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.S
The same using of absolute addresses of CommonInterruptEntry
———
#
Exception0Handle:
.byte 0x6a# push #VectorNum
.byte 0
pushq %rax
.byte 0x48, 0xB8
Andrew,
A [Packages] section in the DSC file would be global and would not support
multiple versions of the same package installed in a WORKSPACE with different
modules requiring different versions of the same package to build.
If and only if you had a single version of each package in WORKSPAC
On Aug 28, 2014, at 8:46 AM, Laszlo Ersek wrote:
> On 08/28/14 17:17, Peter Maydell wrote:
>> On 28 August 2014 16:16, Laszlo Ersek wrote:
>>> On 08/28/14 16:59, Ard Biesheuvel wrote:
However, putting a vector table in that particular place is
troublesome, as the whole point of having
>
> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov wrote:
> > Hi sirs,
> > I tested Thunk16.nasm too. For x86_64 there is no issue.
> > For ia32 compilation disasm shows not good codes
> > -
> > :
> >0: 00 00 add%al,(%eax)
> >2: 00 00
I understand. The value of 16GdtrBase is patched by C-codes in procedure
AsmPrepareThunk16()
So we may set
———
>> _16GdtrBase:
>> DQ 0
>
-
On 28 авг. 2014 г., at 15:48, Andrew Fish wrote:
>
> On Aug 28, 2014, at 4:30 AM, Sergey Isakov wrote:
>
>> But what can you do with
The DMTF published version 3.0.0d of the SMBIOS spec (DSP0134) as a
work-in-progress here: http://dmtf.org/standards/wip
The spec is not final, but it seems highly unlikely that this particular value
would change.
Kimon
From: El-Haj-Mahmoud, Samer
Sent: Monday, August 25, 2014 8:10 AM
To: edk2
Hm, looks like the value remains zero forever. And this works.
On 28 авг. 2014 г., at 15:48, Andrew Fish wrote:
>
> On Aug 28, 2014, at 4:30 AM, Sergey Isakov wrote:
>
>> But what can you do with absolute addressing to _NullSeg?
>> ---
>> _EntryPoint:
>> DD _ToUserCode - ASM_
Thanks for your report. Fixed at 15973.
Original code describes gEfiUartDevicePathGuid in GenericBdsLib, but this LIB
doesn't refer it. New patch cleans up LIB usage. Then, it reports BdsDxe driver
issue. BdsDxe uses this GUID, but not describe it in INF.
Thanks
Liming
-Original Message---
On 08/28/14 17:17, Peter Maydell wrote:
> On 28 August 2014 16:16, Laszlo Ersek wrote:
>> On 08/28/14 16:59, Ard Biesheuvel wrote:
>>> However, putting a vector table in that particular place is
>>> troublesome, as the whole point of having the region is to avoid
>>> putting a Firmware Volume (FV)
This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
The following assumptions are made about the target:
- DRAM base at 0x4000_, containing the device tree blob
- DRAM size at least 1 MB
- PL011 UART at 0x900_
- ARM architected timer
- Cortex-A15 CPU (if built for
On 28 August 2014 16:30, Laszlo Ersek wrote:
> comments below
>
> On 08/27/14 17:12, Ard Biesheuvel wrote:
>
>> diff --git
>> a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>> b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>> new file mode 100644
On 28 August 2014 16:22, Laszlo Ersek wrote:
> You're saying "put the vector table somewhere else than the base of RAM".
Sorry, that was a thinko on my part. I meant "base of
physical address space".
-- PMM
--
Slashdot
On 08/28/14 17:17, Peter Maydell wrote:
> On 28 August 2014 16:08, Laszlo Ersek wrote:
>> - Even if someone wants to implement such, where should (where *can*,
>> actually) the exception handler table exist at all? The addresses
>> that I listed above are backed by the (read-only) flash chip.
On Aug 28, 2014, at 8:08 AM, Laszlo Ersek wrote:
> On 08/28/14 16:52, Peter Maydell wrote:
>> On 28 August 2014 15:30, Laszlo Ersek wrote:
>>> So we got, in the NOR-mapped FD file:
>>>
>>> address 0: jump instruction to 4K, otherwise a bunch of emptiness
>>>(according to erase pol
On 28 August 2014 16:08, Laszlo Ersek wrote:
> - Even if someone wants to implement such, where should (where *can*,
> actually) the exception handler table exist at all? The addresses
> that I listed above are backed by the (read-only) flash chip. The
> exception handler table should be bui
On 28 August 2014 16:16, Laszlo Ersek wrote:
> On 08/28/14 16:59, Ard Biesheuvel wrote:
>> However, putting a vector table in that particular place is
>> troublesome, as the whole point of having the region is to avoid
>> putting a Firmware Volume (FV) there. And having to code the whole
>> vector
On 08/28/14 16:59, Ard Biesheuvel wrote:
> On 28 August 2014 16:52, Peter Maydell wrote:
>> On 28 August 2014 15:30, Laszlo Ersek wrote:
>>> So we got, in the NOR-mapped FD file:
>>>
>>> address 0: jump instruction to 4K, otherwise a bunch of emptiness
>>> (according to erase polarit
I am seeing NT32 build failure due to this check-in. When I reverted 15966,
build completed successfully.
Creating library
c:\dev\sourceforge08262014\edk2\Build\NT32IA32\DEBUG_VS2008x86\IA32\IntelFrameworkModulePkg\Universal\BdsDxe\BdsDxe\DEBUG\BdsDxe.lib
and object
c:\dev\sourceforge08262
On 08/28/14 16:52, Peter Maydell wrote:
> On 28 August 2014 15:30, Laszlo Ersek wrote:
>> So we got, in the NOR-mapped FD file:
>>
>> address 0: jump instruction to 4K, otherwise a bunch of emptiness
>> (according to erase polarity!)
>
> Ideally this should be a proper complete vecto
On 28 August 2014 16:52, Peter Maydell wrote:
> On 28 August 2014 15:30, Laszlo Ersek wrote:
>> So we got, in the NOR-mapped FD file:
>>
>> address 0: jump instruction to 4K, otherwise a bunch of emptiness
>> (according to erase polarity!)
>
> Ideally this should be a proper complete
On 28 August 2014 15:30, Laszlo Ersek wrote:
> So we got, in the NOR-mapped FD file:
>
> address 0: jump instruction to 4K, otherwise a bunch of emptiness
> (according to erase polarity!)
Ideally this should be a proper complete vector table with
handlers for all the exception vector
Eric:
I think this function is compiler Intrinsic functions. Its name can't be
changed.
Thanks
Liming
-Original Message-
From: Dong, Eric
Sent: Thursday, August 28, 2014 9:02 PM
To: Gao, Liming; Olivier Martin (olivier.mar...@arm.com)
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk
comments below
On 08/27/14 17:12, Ard Biesheuvel wrote:
> diff --git
> a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> new file mode 100644
> index ..89c5ff134b41
> --- /dev/null
> ++
Hi Samer,
I would like more information from you about your proposal.
The rules in the EDK II FDF/DSC and Build Specs say that Macros must be defined
in either the DSC or FDF files before they can be used.
Are you requesting a change to this behavior or are you requesting the ability
to set the
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
This introduces an implementation of ArmPlatformSysConfigLib for virtual
machines. This is currently a stub, but some peripheral drivers (such as
the PL031 RTC driver) rely on one to be available.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Casadevall
Acked-by:
This driver enumerates the device nodes in the device tree located at the
base address passed in gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, and
installs drivers for devices it cares about (GIC interrupt controller, RTC,
architected timer interrupt)
Contributed-under: TianoCore Contribution Agree
This is an implementation of ArmPlatformLib that discovers the size of system
DRAM from a device tree blob located at the address passed in
gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, which should equal the value in
gArmTokenSpaceGuid.PcdSystemMemoryBase.
As the device tree blob is passed in syst
This include file contains platform specific defines, and is shared by
various modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
.../ArmVirtualizationPkg/Include/ArmPlatform.h | 33 ++
1 file changed
This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
The following assumptions are made about the target:
- DRAM base at 0x4000_, containing the device tree blob
- DRAM size at least 1 MB
- PL011 UART at 0x900_
- ARM architected timer
- Cortex-A15 CPU (if built for
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
This adds an implementation of NorFlashPlatformLib that exposes the
two 64 MB NOR flash banks that are provided by QEMU's mach-virt
emulation both in 32-bit and 64-bit mode.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
.../L
Introduce gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, which will be used by
virtual machine ports that discover the system configuration from a flattened
device tree DTB image.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
A
This adds an implementation of EfiResetSystemLib that uses PSCI
hypervisor calls to reboot and/or shutdown the system.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Casadevall
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
.../ResetSystemLib/AARCH64/R
This is a fork of the ARM PlatformPeiLib for virtual machines. The main
purpose of having this specific implementation is that it allows us to
preserve the device tree blob if it was passed to us in system DRAM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
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
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
ArmPkg/ArmPkg.dec
This is v4 of the series that 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
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Casadevall
Acked-by: Laszlo Ersek
Signed-off-by: Ard Bies
Allow the PCDs gArmPlatformTokenSpaceGuid.PcdPL031RtcBase and
gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy PCDs to be
declared as PcdsDynamic by the platform so they can be overridden
during boot.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: A
Remove the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase from PrePeiCoreUniCore.inf,
as they are not in fact used by the module.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
A
This separates PlatformPei and PlatformPeiLib so the latter can be
overridden by a specific platform.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/PlatformPei/PlatformPeim.inf | 2 +-
1 file changed, 1 inserti
On 08/28/14 15:11, Ard Biesheuvel wrote:
> On 28 August 2014 14:50, Ard Biesheuvel wrote:
>> I don't think it is necessary for this module to be that rigid.
>> In particular, now that we have PcdDeviceTreeBaseAddress, we can
>> define it in the DSC, and in QEMU's case, its default value will be
>
On 08/28/14 14:50, Ard Biesheuvel wrote:
> On 28 August 2014 14:03, Laszlo Ersek wrote:
>> comments below
>>
>> On 08/27/14 17:12, Ard Biesheuvel wrote:
>>
>>> + ASSERT (DeviceTreeBase != NULL);
>>
>> In the hope that I'm not suggesting something insane, you might also
>> want to assert at this
On 28 August 2014 14:50, Ard Biesheuvel wrote:
> On 28 August 2014 14:03, Laszlo Ersek wrote:
>> comments below
>>
>> On 08/27/14 17:12, Ard Biesheuvel wrote:
>>
>>> diff --git
>>> a/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
>>>
>>> b/ArmPlat
Hi Olivier & Liming,
Please help to review this patch, thanks.
Refine MdePkg: U BaseStackCheckLib library code to follow edkii coding style.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong
Thanks,
Eric
-Original Message-
From: Olivier Martin [mailto:o
On 28 August 2014 14:03, Laszlo Ersek wrote:
> comments below
>
> On 08/27/14 17:12, Ard Biesheuvel wrote:
>
>> diff --git
>> a/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
>>
>> b/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64Virtualiza
comments below
On 08/27/14 17:12, Ard Biesheuvel wrote:
> diff --git
> a/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
>
> b/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
> new file mode 100644
> in
On Aug 28, 2014, at 4:30 AM, Sergey Isakov wrote:
> But what can you do with absolute addressing to _NullSeg?
> ---
> _EntryPoint:
> DD _ToUserCode - ASM_PFX(m16Start)
> DW CODE16
> _16Gdtr:
> DW GDT_SIZE - 1
> _16GdtrBase:
> DQ _NullSeg
>
But what can you do with absolute addressing to _NullSeg?
---
_EntryPoint:
DD _ToUserCode - ASM_PFX(m16Start)
DW CODE16
_16Gdtr:
DW GDT_SIZE - 1
_16GdtrBase:
DQ _NullSeg
---
On 28.08.2014, at 15:16, Andrew Fish wrote:
>
> On Aug 28, 20
On Aug 28, 2014, at 12:15 AM, Sergey Isakov wrote:
>>
>>
>> Actually I just noticed you are getting an illegal text-relocation error.
>> This is usually caused by an absolute relocation, and clang wants it to be
>> IP relative. Basically Xcode/clang only supports a subset of the relocations
On 08/27/14 17:12, Ard Biesheuvel wrote:
> diff --git
> a/ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.c
>
> b/ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.c
> new file mode 100644
> index ..a420591a8e9c
> --- /dev/nu
On 28 August 2014 12:46, Laszlo Ersek wrote:
> On 08/27/14 17:12, Ard Biesheuvel wrote:
>
>> diff --git
>> a/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.c
>>
>> b/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch6
On 08/27/14 17:12, Ard Biesheuvel wrote:
> diff --git
> a/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.c
>
> b/ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationS
On 08/27/14 17:12, Ard Biesheuvel wrote:
> diff --git
> a/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
> b/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
> new file mode 100644
> index ..5a74456d123e
> --- /dev/null
> +++
> b
This patch is for IA32, tested on GCC49 toolset
--- Thunk16.nasm2014-08-28 10:44:15.0 +0400
+++ New/Thunk16.nasm2014-08-28 13:55:12.0 +0400
@@ -58,11 +58,11 @@ SECTION .data
;
; These are global constant to convey information to C code.
;
-ASM_PFX(m16Size)
Laszlo --
You are correct. I have verified the VFR grammar which has similar priority.
It is actually the behavior for integer conversion in suppressif that is
confusing me, not the order of evaluation like I thought.
Tim
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
I checked only for X64 but I think ia32 will be the same.
OK, will test now.
On 28.08.2014, at 12:53, Gao, Liming wrote:
> Sergey:
>Your change adds ASM_PFX() for the external variable to let it pass XLCANG
> tool chain. Is it for IA32 Thunk16.nasm or X64 Thunk16.nasm or both?
>
> Thanks
On 08/28/14 11:31, Laszlo Ersek wrote:
> In the C language, both operator & and operator | bind
> *less* strongly than operator ==.
(Sorry for following up on my own email.) I found some references:
http://en.wikipedia.org/wiki/Operator_precedence_in_C#Criticism_of_bitwise_and_equality_operators
On 08/28/14 07:18, Tim Lewis wrote:
> It appears that this should prevent the display of the text statement.
> However, to my surprise, it works on NT32. Per operator precedence, it
> should be 8|8 is 8, and 8 == 8 is TRUE.
>
>
>
> suppressif 8|8 == 0x8;
>
> text
>
> h
On 08/28/14 08:39, Gabor Puha wrote:
> All,
>
> I am developing an efi loader and having problem to write an allocated
> mem or text to a file on efi partition. I can create and del but I am
> not able to write a file. I have checked all doc but example with
> declaration was not found. Please, he
Sergey:
Your change adds ASM_PFX() for the external variable to let it pass XLCANG
tool chain. Is it for IA32 Thunk16.nasm or X64 Thunk16.nasm or both?
Thanks
Liming
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Thursday, August 28, 2014 3:16 PM
To: edk2-devel@lists.sourceforge.net
Subjec
Hi,
HiiLib has provided HiiCreateGuidOpCode() API to create GUID extension
opcode. How about use this API?
Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Thursday, August 28, 2014 4:37 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] Mde
Comments below
On 28.08.2014, at 7:54, Andrew Fish wrote:
>
> On Aug 27, 2014, at 8:43 PM, Sergey Isakov wrote:
>
>> Jordan,
>> There was no issue with gcc49 toolchain in x86_64.
>> I made an attempt to use nasm with XCLANG toolset but failed on ld:
>> I seems have to wait while Andrew make XC
94 matches
Mail list logo
