Re: [edk2] PCDs in PEI phase

Tiger: 1. No limitation. PCD Database is built into GUID HOB. But, if PCD basebase is too big to be placed in CAR, PEI PCD can't work. 2. Yes. PEI Core will migrate HOB data. Then, GUID HOB can still be found in post memory. Thanks Liming From: tiger...@via-alliance.com [mailto:tig

Re: [edk2] [PATCH 1/2] ArmGicLib: cache GIC arch revision in global variable

On 12 November 2014 20:43, Olivier Martin wrote: > I forgot to say your line endings are not correct. You have to use CRLF - > sorry that's the coding convention. > I know, I know ... I just failed to pay attention to it. Anyway, we can drop this patch entirely, I did not realize that ArmGicLib

Re: [edk2] BUILDRULEFAMILY in tools_def - RE: [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

Jordan: The default one can be. ASM and S is not conflicted. *_*_*_*_BUILDRULEORDER = nasm asm S XCODE tool chain has its one. *_XCODE5_*_*_ BUILDRULEORDER = S nasm Thanks Liming -Original Message- From: Jordan Justen [mailto:jordan.l.jus...@intel.com] Sent: Thursday, November 13,

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

> On Nov 12, 2014, at 7:00 PM, Jordan Justen wrote: > > On 2014-11-12 18:16:59, Andrew Fish wrote: >>> On Nov 12, 2014, at 5:49 PM, Jordan Justen >> > wrote: >>> On 2014-11-12 16:22:59, Andrew Fish wrote: I assumed there would be a Python script to convert

Re: [edk2] BUILDRULEFAMILY in tools_def - RE: [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

> On Nov 12, 2014, at 7:40 PM, Jordan Justen wrote: > > I tried this change to tools_def: > -*_GCC49_X64_NASM_FLAGS = -f elf64 > +GCC:*_*_X64_NASM_FLAGS = -f elf32 > Is the syntax defined in the design documentation for the tools_def? I’ve only ever seen it in the DSC, INF

[edk2] BUILDRULEFAMILY in tools_def - RE: [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

I tried this change to tools_def: -*_GCC49_X64_NASM_FLAGS = -f elf64 +GCC:*_*_X64_NASM_FLAGS = -f elf32 But, it didn't work. Does anyone know why we can't use the BUILDRULEFAMILY like this? I thought it could be helpful with: GCC:*_*_*_*_BUILDRULEORDER = nasm S -Jordan On 20

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

On 2014-11-12 17:59:24, Andrew Fish wrote: > > On Nov 12, 2014, at 5:47 PM, Gao, Liming wrote: > > > > Jordan and Andrew: > > Now, we have BUILDRULEFAMILY, how about add BUILDRULEORDER key? It means > > the priority order of the build rule for the same output with the different > > postfix sour

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On 2014-11-12 18:16:59, Andrew Fish wrote: > > On Nov 12, 2014, at 5:49 PM, Jordan Justen > > wrote: > > On 2014-11-12 16:22:59, Andrew Fish wrote: > >> I assumed there would be a Python script to convert to WinDBG to > >> gdb-remote. > > > > Hmm. That sounds horrible. Luckily, *I think* it actu

Re: [edk2] patch review feedback about FvSimpleFileSystem module

On 2014-11-12 18:10:11, Tian, Feng wrote: > Jordan, > > As Contributed-under and Signed-off-by message are mandatory infos, > I didn't mention it. Yes, it is mandatory that every contribution have this. Therefore, it should be mentioned with every contribution of code. I usually don't even look a

[edk2] PCDs in PEI phase

Hi, experts: I found PCD_PPI / EFI_PEI_PCD_PPI provided Set functions. So I have 2 questions: 1. Before permanent memory had been initialized, PCD database was created at CAR region. Is there any limitations about Dynamic PCD used in this stage?(has only cache, not permanent memory) 2.

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

> On Nov 12, 2014, at 5:49 PM, Jordan Justen wrote: > > On 2014-11-12 16:22:59, Andrew Fish wrote: >> >>On Nov 12, 2014, at 4:08 PM, Jordan Justen >>wrote: >> >>On 2014-11-12 15:22:18, Andrew Fish wrote: >>On Nov 12, 2014, at 2:26 PM, Jordan Justen < >>jord

Re: [edk2] patch review feedback about FvSimpleFileSystem module

Jordan, As Contributed-under and Signed-off-by message are mandatory infos, I didn't mention it. Ok, let's mend the commit message: MdeModulePkg/FvSimpleFileSystem: Add a new module to provide access to executable files in FVs. This module implements Simple FileSystem protocol over Firmware V

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

> On Nov 12, 2014, at 5:47 PM, Gao, Liming wrote: > > Jordan and Andrew: > Now, we have BUILDRULEFAMILY, how about add BUILDRULEORDER key? It means the > priority order of the build rule for the same output with the different > postfix source files. > > *_GCC49_*_*_BUILDRULEORDER = nasm S > *

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

Jordan and Andrew: Now, we have BUILDRULEFAMILY, how about add BUILDRULEORDER key? It means the priority order of the build rule for the same output with the different postfix source files. *_GCC49_*_*_BUILDRULEORDER = nasm S *_VS2013_*_*_ BUILDRULEORDER = nasm asm *_XCODE5_*_*_ BUILDRULEORDER

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On 2014-11-12 16:22:59, Andrew Fish wrote: > > On Nov 12, 2014, at 4:08 PM, Jordan Justen > wrote: > > On 2014-11-12 15:22:18, Andrew Fish wrote: > On Nov 12, 2014, at 2:26 PM, Jordan Justen < > jordan.l.jus...@intel.com> wrote: > Too bad the Debug

Re: [edk2] patch review feedback about FvSimpleFileSystem module

On 2014-11-11 23:16:21, Tian, Feng wrote: > Hi, Martin > > Here is my review comments on your FvSimpleFileSystem uefi driver. Sorry for > late response. > > 1. Fixed system hang due to wrong assertions in > FvSimpleFileSystemDriverStart() and FvSimpleFileSystemOpenVolume(). > a. change

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

Yes. FixedAtBuild type PCD could be used for all phases including SEC. So, the current OvmfPkg\Library\AcpiTimerLib works when enabling SOURCE_DEBUG_ENABLE. For OVMF source debugging , we could use WinDBG + Qemu on Windows and GDB + Qemu on Ubuntu. Jeff -Original Message- From: Jorda

Re: [edk2] patch review feedback about FvSimpleFileSystem module

Hi, Martin My intention is initializing the FsInfoOut with the destination size and the VolumeLable field of FsInfoOut got updated at next statement (StrCpy operation). CopyMem (FsInfoOut, &mFsInfoTemplate, Size); StrCpy (FsInfoOut->VolumeLabel, Instance->VolumeLabel); But anyway it's n

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

> On Nov 12, 2014, at 4:08 PM, Jordan Justen wrote: > > On 2014-11-12 15:22:18, Andrew Fish wrote: >>> On Nov 12, 2014, at 2:26 PM, Jordan Justen >> > wrote: >>> Too bad the DebugAgent isn't actually useful for all the trouble it >>> causes. :) >> >> 1st questi

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On 2014-11-12 15:22:18, Andrew Fish wrote: > > On Nov 12, 2014, at 2:26 PM, Jordan Justen > > wrote: > > Too bad the DebugAgent isn't actually useful for all the trouble it > > causes. :) > > 1st question what is wrong with the DebugAgent? Why is int not > useful? Last time I looked at it you h

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On 2014-11-12 15:12:25, Gabriel Somlo wrote: > On Wednesday, November 12, 2014 5:26 PM, Jordan Justen wrote: > >On 2014-11-12 03:23:04, Laszlo Ersek wrote: > >> SEC always runs, but whether or not SEC depends on TimerLib is > >> conditional on -D SOURCE_DEBUG_ENABLE. If it is absent, then the debug

Re: [edk2] patch review feedback about FvSimpleFileSystem module

I do not disagree but can we assume Instance->VolumeLabel will always be an empty string? My point is 'Instance->VolumeLabel' can contain a valid non empty string. It means: Size = sizeof (EFI_FILE_SYSTEM_INFO) + StrSize (Instance->VolumeLabel) - sizeof (CHAR16) > sizeof (EFI_FILE_SYSTEM_INFO)

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

> On Nov 12, 2014, at 2:26 PM, Jordan Justen wrote: > Too bad the DebugAgent isn't actually useful for all the trouble it > causes. :) 1st question what is wrong with the DebugAgent? Why is int not useful? 2nd question why are you using the DebugAgent, when you could just use the QEMU built in

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

> On Nov 12, 2014, at 3:12 PM, Gabriel Somlo wrote: > > On Wednesday, November 12, 2014 5:26 PM, Jordan Justen wrote: >> On 2014-11-12 03:23:04, Laszlo Ersek wrote: >>> SEC always runs, but whether or not SEC depends on TimerLib is >>> conditional on -D SOURCE_DEBUG_ENABLE. If it is absent, then

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On Wednesday, November 12, 2014 5:26 PM, Jordan Justen wrote: >On 2014-11-12 03:23:04, Laszlo Ersek wrote: >> SEC always runs, but whether or not SEC depends on TimerLib is >> conditional on -D SOURCE_DEBUG_ENABLE. If it is absent, then the debug >> agent is not pulled in (*), and then SEC doesn't

[edk2] MdeModulePkg: PEI Core

Why does the initial call to the ProcessLibraryConstructorList() pass in the PEI Services Table pointer pointer, when the PEI Services will crash? Would it be better to pass in NULL? Also why does it get called 3 times on boot? I was trying to make a call to a PPI database call, and it crashed

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On 2014-11-12 03:23:04, Laszlo Ersek wrote: > On 11/11/14 22:34, Gabriel Somlo wrote: > > On Sun, Nov 09, 2014 at 10:13:54AM -0800, Jordan Justen wrote: > >> On 2014-11-08 14:02:00, Gabriel L. Somlo wrote: > >>> Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may > >>> utilize global va

Re: [edk2] [PATHC] ShellPkg: control code flow with a PCD

Reviewed-by: Erik Bjorge From: Carsey, Jaben Sent: Wednesday, November 12, 2014 11:01 AM To: Bjorge, Erik C Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben Subject: [PATHC] ShellPkg: control code flow with a PCD Erik, Can you verify? Currently the shell has a comment to control iScsi decod

Re: [edk2] [PATCH 0/7] build fixes for gcc and VS2010

On 11/12/14 20:31, Scott Duplichan wrote: > Laszlo Ersek [mailto:ler...@redhat.com] wrote: > > ]This patchset includes > ]- three OVMF build fixes from Scott for VS2010 / NOOPT / Ia32, > ]- two patches suggested by Scott, but reimplemented by yours truly, for > ] the same, > ]- two CryptoPkg patc

Re: [edk2] [PATCH 0/7] build fixes for gcc and VS2010

Andrew Fish [mailto:af...@apple.com] wrote: Sent: Wednesday, November 12, 2014 01:47 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH 0/7] build fixes for gcc and VS2010 On Nov 12, 2014, at 11:31 AM, Scott Duplichan mailto:sc...@notabs.org> > wrote: Laszlo Ersek [

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

On 2014-11-12 05:38:28, Gabriel Somlo wrote: > On Tue, Nov 11, 2014 at 07:54:30PM -0800, Jordan Justen wrote: > > > > When I build IA32 (OvmfPkg/build.sh -a IA32) I get warnings about > > > > possibly uninitialized variables. > > > > > > > > It seems to happen basically everwhere that you switch o

Re: [edk2] [PATCH 0/7] build fixes for gcc and VS2010

> On Nov 12, 2014, at 11:31 AM, Scott Duplichan wrote: > > Laszlo Ersek [mailto:ler...@redhat.com ] wrote: > > ]This patchset includes > ]- three OVMF build fixes from Scott for VS2010 / NOOPT / Ia32, > ]- two patches suggested by Scott, but reimplemented by yours trul

Re: [edk2] [PATCH 1/2] ArmGicLib: cache GIC arch revision in global variable

I forgot to say your line endings are not correct. You have to use CRLF - sorry that's the coding convention. > -Original Message- > From: Olivier Martin [mailto:olivier.mar...@arm.com] > Sent: 12 November 2014 19:43 > To: 'Ard Biesheuvel'; edk2-devel@lists.sourceforge.net > Cc: Marc Zyngi

Re: [edk2] [PATCH 1/2] ArmGicLib: cache GIC arch revision in global variable

I also thought using a global variable in my initial implementation. But it does not work when the library is called from XIP phases. In this case the global variables live in Read-Only memory and it would crash as soon as you try to write to it. This change is only safe when this library is called

Re: [edk2] [PATCH 0/7] build fixes for gcc and VS2010

Laszlo Ersek [mailto:ler...@redhat.com] wrote: ]This patchset includes ]- three OVMF build fixes from Scott for VS2010 / NOOPT / Ia32, ]- two patches suggested by Scott, but reimplemented by yours truly, for ] the same, ]- two CryptoPkg patches from myself, for recently introduced gcc build ] fa

[edk2] [PATHC] ShellPkg: control code flow with a PCD

Erik, Can you verify? Currently the shell has a comment to control iScsi decoding by adding or removing the code via a comment and that this should be replaced with a PCD. This is that replacement with a PCD. [PATHC] ShellPkg: control code flow with a PCD Contributed-under: TianoCore Contrib

[edk2] [PATCH] OvmfPkg/build.sh: Support XCODE5 by default on Mac

Update OS Major number checking to future proof it, and default to XCODE5 (clang + lldb). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fish git diff OvmfPkg/build.sh diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh index b549ab5..b1f6fde 100755 --- a/OvmfPkg/bui

[edk2] [PATCH] DuetPkg: fix unresolved external symbol __allshl with MSFT IA32 NOOPT build

DuetPkg: fix unresolved external symbol __allshl with MSFT IA32 NOOPT build Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan --- Index: DuetPkg/DxeIpl/HobGeneration.c === --- DuetPkg/DxeIpl/HobG

Re: [edk2] patch review feedback about FvSimpleFileSystem module

With an empty string isn't StrSize going to return 2, and then sizeof(CHAR16) also returning 2, so the math will result in the same copy as the original? -Jaben > -Original Message- > From: Olivier Martin [mailto:olivier.mar...@arm.com] > Sent: Wednesday, November 12, 2014 3:35 AM > To:

[edk2] [PATCH] OvmfPkg/XenBusDxe: Avoid typedef XENBUS_DEVICE twice.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/XenBusDxe/XenHypercall.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/XenBusDxe/XenHypercall.h b/OvmfPkg/XenBusDxe/XenHypercall.h index 3627b18..088037b 100644 --- a/Ov

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global

On 11/12/14 14:30, Gabriel Somlo wrote: > On Wed, 12 Nov 2014 12:23:04 +0100, Laszlo Ersek wrote: >> On 11/11/14 22:34, Gabriel Somlo wrote: >>> On Sun, Nov 09, 2014 at 10:13:54AM -0800, Jordan Justen wrote: On 2014-11-08 14:02:00, Gabriel L. Somlo wrote: > + // > + // Check to see

Re: [edk2] Xcode build failure on OVMF

On Tue, Nov 11, 2014 at 08:30:18PM -0800, Andrew Fish wrote: > This this redefinition a bug? > > Thanks, > > Andrew Fish > > Building ... /Users/andrewfish/work/src/edk2/OvmfPkg/XenBusDxe/XenBusDxe.inf > [X64] > "clang" -target x86_64-pc-win32-macho -c -g -Os -Wall -Werror -Wextra > -include A

[edk2] [PATCH 3/7] OvmfPkg: flash driver: drop needlessly wide multiplication (VS2010)

From: Scott Duplichan The current types of subexpressions used in QemuFlashPtr() are as follows. (We also show the types of "larger" subexpressions, according to operator binding.) mFlashBase + (Lba * mFdBlockSize) + Offset ^ ^ ^^ | | |

[edk2] [PATCH 2/7] OvmfPg: flash driver: drop gratuitous 64-by-32 bit division (VS2010)

In the InitializeVariableFvHeader() function, both "Start" and "BlockSize" have type UINTN. Therefore the (Start / BlockSize) division can be compiled on all platforms without intrinsics. In he current expression (EFI_LBA) Start / BlockSize "Start" is cast to UINT64 (== EFI_LBA), which leads t

[edk2] [PATCH 6/7] CryptoPkg: TimestampTokenVerify(): fix gcc-4.8 / Ia32 build failure

SVN r16339 ("CryptoPkg Updates to support RFC3161 timestamp signature verification.") introduced the following build failure: > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c: In function > 'TimestampTokenVerify': > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c:538:3: error: passing > argument 2 of 'd2

[edk2] [PATCH 7/7] CryptoPkg: OpenSslSupport.h: edk2-ize offsetof() macro for gcc-4.8 / X64

Code added in SVN r16339 ("CryptoPkg Updates to support RFC3161 timestamp signature verification.") introduced many new uses of the offsetof() macro. Since the offsetof() macro in "OpenSslSupport.h" casts a pointer to an "int", it triggers a large number of error: cast from pointer to integer of

[edk2] [PATCH 0/7] build fixes for gcc and VS2010

This patchset includes - three OVMF build fixes from Scott for VS2010 / NOOPT / Ia32, - two patches suggested by Scott, but reimplemented by yours truly, for the same, - two CryptoPkg patches from myself, for recently introduced gcc build failures. Scott, can you please test your build with th

[edk2] [PATCH 1/7] OvmfPg: flash driver: fix type of EFI_SIZE_TO_PAGES argument (VS2010)

The MarkMemoryRangeForRuntimeAccess() function passes the Length parameter (of type UINT64) to the macro EFI_SIZE_TO_PAGES(). When building for the Ia32 platform, this violates the interface contract of the macro: [...] Passing in a parameter that is larger than UINTN may produce unexpecte

[edk2] [PATCH 4/7] OvmfPkg: QemuVideoDxe: the VBE shim needs no 64-bit shifts (VS2010)

From: Scott Duplichan The SegmentC local variable has type EFI_PHYSICAL_ADDRESS for (justified) style reasons. However, the 64-bit bit-shifts that it undergoes result in intrinsic calls when built with VS2010 for Ia32 / NOOPT. The concrete value of SegmentC, 0xC, and the results of the bito

[edk2] [PATCH 5/7] OvmfPkg: VirtioScsiDxe: drop 64-bit shift in PopulateRequest() (VS2010)

From: Scott Duplichan "Lun" has type UINT64 in this function. The result of the expression (UINT8) ((Lun >> 8) | 0x40) depends only on bits [15:8] of "Lun", therefore we can cast "Lun" to UINT32 before shifting it. This eliminates an intrinsic when building with VS2010 for Ia32 / NOOPT. Con

Re: [edk2] [PATCH] OvmfPkg: fix VS2010 build failures

On 11/11/14 21:11, Scott Duplichan wrote: > Laszlo Ersek [mailto:ler...@redhat.com] wrote: > > ]Apparently I wasn't quick enough to answer (which is not a surprise > ]these days), but I do have some points to raise... > ] > ]On 11/11/14 00:41, Jordan Justen wrote: > ]> On 2014-11-10 15:05:07, Scot

Re: [edk2] [PATCH v2] OvmfPkg/XenPvBlkDxe: Don't include system inttypes.h

On Tue, Nov 11, 2014 at 04:12:24PM -0800, Jordan Justen wrote: > EDK II code should not include system include files. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jordan Justen > Cc: Anthony PERARD > Cc: Scott Duplichan > --- > OvmfPkg/XenPvBlkDxe/BlockFront.c |

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

On Tue, Nov 11, 2014 at 07:54:30PM -0800, Jordan Justen wrote: > > > When I build IA32 (OvmfPkg/build.sh -a IA32) I get warnings about > > > possibly uninitialized variables. > > > > > > It seems to happen basically everwhere that you switch on > > > HostBridgeDevId. > > > > I wonder why it's onl

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global

On Wed, 12 Nov 2014 12:23:04 +0100, Laszlo Ersek wrote: > On 11/11/14 22:34, Gabriel Somlo wrote: > > On Sun, Nov 09, 2014 at 10:13:54AM -0800, Jordan Justen wrote: > >> On 2014-11-08 14:02:00, Gabriel L. Somlo wrote: > >>> + // > >>> + // Check to see if the Power Management Base Address is alr

[edk2] [PATCH 2/2] ArmGicLib: select GICv2 mode if SRE is present but unavailable

Even if the CPU id registers indicate hardware support for the System Register interface to the GIC, higher exception levels may disable that interface and only allow access through MMIO. So move the enabling of the SRE bit to the GIC version detection routine: if we trigger an exception, we would

[edk2] [PATCH 1/2] ArmGicLib: cache GIC arch revision in global variable

Before extending the GIC arch revision check to support an emulated GICv2 on GICv3 capable hardware in the next patch, add a constructor to ArmGicLib that caches the result of the check so we don't have to go through it on every call into ArmGicLib. Contributed-under: TianoCore Contribution Agreem

Re: [edk2] patch review feedback about FvSimpleFileSystem module

Thanks a lot for submitted a revised version. There is nothing controversial in your changes. Except maybe these lines in FvSimpleFileSystemGetInfo(): Size = sizeof (EFI_FILE_SYSTEM_INFO) + StrSize (Instance->VolumeLabel) - sizeof (CHAR16); CopyMem (FsInfoOut, &mFsInfoTemplate, Size); Whi

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On 11/11/14 22:34, Gabriel Somlo wrote: > On Sun, Nov 09, 2014 at 10:13:54AM -0800, Jordan Justen wrote: >> On 2014-11-08 14:02:00, Gabriel L. Somlo wrote: >>> Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may >>> utilize global variables, use the "Base" AcpiTimerLib instance >>> (ins

Re: [edk2] Xcode build failure on OVMF

Anthony, On 11/12/14 05:30, Andrew Fish wrote: > This this redefinition a bug? > > Thanks, > > Andrew Fish > > Building ... > /Users/andrewfish/work/src/edk2/OvmfPkg/XenBusDxe/XenBusDxe.inf [X64] > "clang" -target x86_64-pc-win32-macho -c -g -Os -Wall -Werror -Wextra > -include AutoGen.h -funsi

Re: [edk2] [Linaro-uefi] AARCH64 GIC updates for 64 bit

Hi, Yes you can send you GIC patch and I will be pleased to review and merge it if it is appropriate. I am not sure to understand your second question. I do not know if it is related to the mess of some platform ports in Linaro repository (what I was told). But there should only be one DEC fi

Re: [edk2] [PATCH] ArmPlatformPkg: fix undefined reference to memcpy

Thanks Scott your change has been committed into SVN rev 16340. > -Original Message- > From: Scott Duplichan [mailto:sc...@notabs.org] > Sent: 12 November 2014 05:33 > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] [PATCH] ArmPlatformPkg: fix undefined reference to > memcpy >

Re: [edk2] Thunk16 or NASM changed?

Sorry, it is YASM. On 12.11.2014, at 11:30, Sergey Isakov wrote: > Hi sirs, > Is there anybody knows what is changed in Thunk16.nasm or in NASM ? > -- > /X64/Thunk16.iii:137: error: unexpected STRICT after instruction > /X64/Thunk16.iii:244: warning: `ds' segment register ignored in 64-bi

[edk2] Thunk16 or NASM changed?

Hi sirs, Is there anybody knows what is changed in Thunk16.nasm or in NASM ? -- /X64/Thunk16.iii:137: error: unexpected STRICT after instruction /X64/Thunk16.iii:244: warning: `ds' segment register ignored in 64-bit mode /X64/Thunk16.iii:246: warning: `es' segment register ignored in 64-bit