Re: [edk2] possible off-by-one in CoreAllocateSpace()?

On 03/02/15 08:21, Gao, Liming wrote: > Laszlo: > > So, this is like a clean up. I prefer to defer it until the real > issue or impact is clear. OK for you? It might be a bit (but not much) more than just cleanup. The consequence seems to be that the allocator wastes some address space (it alloca

Re: [edk2] [PATCH 1/4] ArmPkg: DebugPeCoffExtraActionLib: debugger commands are not errors

On 27 February 2015 at 19:55, Laszlo Ersek wrote: > PeCoffLoaderRelocateImageExtraAction() prints helpful debugger commands > for source level debugging. These messages should not be printed on the > EFI_D_ERROR level; they don't report errors. Change the debug level > (bitmask, actually) to EFI_D

Re: [edk2] [PATCH 2/4] ArmPlatformPkg: PEIM startup is not an error

On 27 February 2015 at 19:55, Laszlo Ersek wrote: > "MemoryInitPeim.c" and "PlatformPeim.c" log startup messages on the > EFI_D_ERROR level. This clutters a strictly EFI_D_ERROR level log > needlessly; change the log bitmask of these messages to EFI_D_LOAD | > EFI_D_INFO. > > Contributed-under: Ti

Re: [edk2] [PATCH 3/4] ArmVirtualizationPkg: PlatformIntelBdsLib: lack of QEMU kernel is no error

On 27 February 2015 at 19:55, Laszlo Ersek wrote: > When the user doesn't pass a kernel with QEMU's "-kernel" switch, the > firmware sees a zero-sized kernel blob via the QemuFwCfgItemKernelSize > key; there's no way to distinguish "no kernel" from "zero sized kernel". > In both cases TryRunningQe

Re: [edk2] [PATCH 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

On 27 February 2015 at 19:55, Laszlo Ersek wrote: > This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line > options. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- > ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc | 8

Re: [edk2] [PATCH 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

On 03/02/15 09:35, Ard Biesheuvel wrote: > On 27 February 2015 at 19:55, Laszlo Ersek wrote: >> This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line >> options. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Laszlo Ersek >> --- >> ArmPlatformPkg/

Re: [edk2] [PATCH 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

On 2 March 2015 at 09:23, Laszlo Ersek wrote: > On 03/02/15 09:35, Ard Biesheuvel wrote: >> On 27 February 2015 at 19:55, Laszlo Ersek wrote: >>> This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line >>> options. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>

[edk2] [PATCH v2 0/4] ArmVirtualizationPkg: unclutter EFI_D_ERROR log

Patch #4 now adds the default log mask to ArmVirtualization.dsc.inc, so that both Qemu.dsc and Xen.dsc can rely on it. Laszlo Ersek (4): ArmPkg: DebugPeCoffExtraActionLib: debugger commands are not errors ArmPlatformPkg: PEIM startup is not an error ArmVirtualizationPkg: PlatformIntelBdsLib:

[edk2] [PATCH v2 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line options. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- Notes: v2: - move DEBUG_PRINT_ERROR_LEVEL default to ArmVirtualization.dsc.inc so it affects both ArmVirtualization

[edk2] [PATCH v2 3/4] ArmVirtualizationPkg: PlatformIntelBdsLib: lack of QEMU kernel is no error

When the user doesn't pass a kernel with QEMU's "-kernel" switch, the firmware sees a zero-sized kernel blob via the QemuFwCfgItemKernelSize key; there's no way to distinguish "no kernel" from "zero sized kernel". In both cases TryRunningQemuKernel() proceeds as far as gBS->LoadImage(), which then

[edk2] [PATCH v2 2/4] ArmPlatformPkg: PEIM startup is not an error

"MemoryInitPeim.c" and "PlatformPeim.c" log startup messages on the EFI_D_ERROR level. This clutters a strictly EFI_D_ERROR level log needlessly; change the log bitmask of these messages to EFI_D_LOAD | EFI_D_INFO. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek

[edk2] [PATCH v2 1/4] ArmPkg: DebugPeCoffExtraActionLib: debugger commands are not errors

PeCoffLoaderRelocateImageExtraAction() prints helpful debugger commands for source level debugging. These messages should not be printed on the EFI_D_ERROR level; they don't report errors. Change the debug level (bitmask, actually) to EFI_D_LOAD | EFI_D_INFO, because the messages are printed in rel

Re: [edk2] [PATCH v2 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

On 2 March 2015 at 12:03, Laszlo Ersek wrote: > This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line > options. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel > --- > > Notes: > v2: > - move DEBUG_P

Re: [edk2] [PATCH v2 1/4] ArmPkg: DebugPeCoffExtraActionLib: debugger commands are not errors

On Mon, Mar 02, 2015 at 01:03:50PM +0100, Laszlo Ersek wrote: > PeCoffLoaderRelocateImageExtraAction() prints helpful debugger commands > for source level debugging. These messages should not be printed on the > EFI_D_ERROR level; they don't report errors. Change the debug level > (bitmask, actuall

Re: [edk2] [PATCH v2 2/4] ArmPlatformPkg: PEIM startup is not an error

On Mon, Mar 02, 2015 at 01:03:51PM +0100, Laszlo Ersek wrote: > "MemoryInitPeim.c" and "PlatformPeim.c" log startup messages on the > EFI_D_ERROR level. This clutters a strictly EFI_D_ERROR level log > needlessly; change the log bitmask of these messages to EFI_D_LOAD | > EFI_D_INFO. > > Contribut

Re: [edk2] [PATCH v2 3/4] ArmVirtualizationPkg: PlatformIntelBdsLib: lack of QEMU kernel is no error

On Mon, Mar 02, 2015 at 01:03:52PM +0100, Laszlo Ersek wrote: > When the user doesn't pass a kernel with QEMU's "-kernel" switch, the > firmware sees a zero-sized kernel blob via the QemuFwCfgItemKernelSize > key; there's no way to distinguish "no kernel" from "zero sized kernel". > In both cases T

Re: [edk2] [PATCH v2 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

On Mon, Mar 02, 2015 at 01:03:53PM +0100, Laszlo Ersek wrote: > This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line > options. Should also mention that it clarifies some comments. > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- >

Re: [edk2] [PATCH v2 3/4] ArmVirtualizationPkg: PlatformIntelBdsLib: lack of QEMU kernel is no error

On 03/02/15 14:14, Leif Lindholm wrote: > On Mon, Mar 02, 2015 at 01:03:52PM +0100, Laszlo Ersek wrote: >> When the user doesn't pass a kernel with QEMU's "-kernel" switch, the >> firmware sees a zero-sized kernel blob via the QemuFwCfgItemKernelSize >> key; there's no way to distinguish "no kernel

Re: [edk2] [PATCH v2 0/4] ArmVirtualizationPkg: unclutter EFI_D_ERROR log

On Mon, Mar 02, 2015 at 01:03:49PM +0100, Laszlo Ersek wrote: > Patch #4 now adds the default log mask to ArmVirtualization.dsc.inc, so > that both Qemu.dsc and Xen.dsc can rely on it. > > Laszlo Ersek (4): > ArmPkg: DebugPeCoffExtraActionLib: debugger commands are not errors > ArmPlatformPkg:

Re: [edk2] [PATCH v2 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

On 03/02/15 14:18, Leif Lindholm wrote: > On Mon, Mar 02, 2015 at 01:03:53PM +0100, Laszlo Ersek wrote: >> This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line >> options. > > Should also mention that it clarifies some comments. Will do. >> Contributed-under: TianoCore Contribut

Re: [edk2] [PATCH v2 0/4] ArmVirtualizationPkg: unclutter EFI_D_ERROR log

On 03/02/15 14:37, Leif Lindholm wrote: > On Mon, Mar 02, 2015 at 01:03:49PM +0100, Laszlo Ersek wrote: >> Patch #4 now adds the default log mask to ArmVirtualization.dsc.inc, so >> that both Qemu.dsc and Xen.dsc can rely on it. >> >> Laszlo Ersek (4): >> ArmPkg: DebugPeCoffExtraActionLib: debugg

[edk2] ovmf assert error on x86_64

Hi, Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which causes a booting qemu x86_64 vm to hang with a black screen. Getting OVMF to generate a debug log shows this: ... Loading driver FAB5D4F4-83C0-4AAF-8480-4

Re: [edk2] [PATCH v2 1/4] ArmPkg: DebugPeCoffExtraActionLib: debugger commands are not errors

> On Mar 2, 2015, at 5:06 AM, Leif Lindholm wrote: > > On Mon, Mar 02, 2015 at 01:03:50PM +0100, Laszlo Ersek wrote: >> PeCoffLoaderRelocateImageExtraAction() prints helpful debugger commands >> for source level debugging. These messages should not be printed on the >> EFI_D_ERROR level; they do

Re: [edk2] ovmf assert error on x86_64

On 2 March 2015 at 16:06, Laszlo Ersek wrote: > On 03/02/15 16:26, Gabriel L. Somlo wrote: >> Hi, >> >> Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and >> d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which >> causes a booting qemu x86_64 vm to hang with a bl

Re: [edk2] ovmf assert error on x86_64

On Mon, Mar 02, 2015 at 10:26:19AM -0500, Gabriel L. Somlo wrote: > Hi, > > Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and > d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which > causes a booting qemu x86_64 vm to hang with a black screen. Getting > OVMF to

Re: [edk2] [PATCH v2 4/4] ArmVirtualizationPkg: expose debug message bitmask on build command line

On 03/02/15 16:04, Leif Lindholm wrote: > On 02/03/15 13:54, Laszlo Ersek wrote: >> On 03/02/15 14:18, Leif Lindholm wrote: >>> On Mon, Mar 02, 2015 at 01:03:53PM +0100, Laszlo Ersek wrote: This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line options. >>> >>> Should also

Re: [edk2] ovmf assert error on x86_64

> On Mar 2, 2015, at 7:26 AM, Gabriel L. Somlo wrote: > > Hi, > > Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and > d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which > causes a booting qemu x86_64 vm to hang with a black screen. Getting > OVMF to generat

Re: [edk2] ovmf assert error on x86_64

On 03/02/15 16:26, Gabriel L. Somlo wrote: > Hi, > > Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and > d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which > causes a booting qemu x86_64 vm to hang with a black screen. Getting > OVMF to generate a debug log sh

Re: [edk2] ovmf assert error on x86_64

On 03/02/15 17:15, Ard Biesheuvel wrote: > On 2 March 2015 at 16:06, Laszlo Ersek wrote: >> On 03/02/15 16:26, Gabriel L. Somlo wrote: >>> Hi, >>> >>> Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and >>> d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which >>>

[edk2] [PATCH] Ovmf/Xen: avoid calling XenHypercallLib constructor on !Xen

This refactors the XenHypercallLib implementation for ARM and x86, and their callers, so that the init code for the XenHypercallLib is only called in places where we have already established that we are running as a Xen guest, or (in the XenConsoleSerialPortLib case) where ARM is the only user of t

Re: [edk2] [PATCH] Ovmf/Xen: avoid calling XenHypercallLib constructor on !Xen

On 03/02/15 18:35, Jordan Justen wrote: > On 2015-03-02 09:13:22, Ard Biesheuvel wrote: >> This refactors the XenHypercallLib implementation for ARM and x86, >> and their callers, so that the init code for the XenHypercallLib >> is only called in places where we have already established that we >>

Re: [edk2] [PATCH] Ovmf/Xen: avoid calling XenHypercallLib constructor on !Xen

On 2015-03-02 09:13:22, Ard Biesheuvel wrote: > This refactors the XenHypercallLib implementation for ARM and x86, > and their callers, so that the init code for the XenHypercallLib > is only called in places where we have already established that we > are running as a Xen guest, or (in the XenCons

Re: [edk2] SEC PPI HOBs

> On Mar 1, 2015, at 11:18 PM, Gao, Liming wrote: > > Andrew: > 1. This is a generic issue for PPI provided by SEC module only if this > PPI needs touch data in CAR. PeiCore can’t handle them all if this PPI is not > in PI spec. I think Tim’s point was EFI_SEC_PLATFORM_INFORMATION_PPI

Re: [edk2] SEC PPI HOBs

Andrew – It seems that this is tied to a missing data structure EFI_PEI_STARTUP_DESCRIPTOR, which is mentioned as mandatory, but not defined anywhere. Again, this looks like an earlier editorial issue. Tim From: Andrew Fish [mailto:af...@apple.com] Sent: Monday, March 02, 2015 10:05 AM To: edk

Re: [edk2] [PATCH] Ovmf/Xen: avoid calling XenHypercallLib constructor on !Xen

On 03/02/15 18:13, Ard Biesheuvel wrote: > This refactors the XenHypercallLib implementation for ARM and x86, > and their callers, so that the init code for the XenHypercallLib > is only called in places where we have already established that we > are running as a Xen guest, Hm, I think I disagree

Re: [edk2] [PATCH] Ovmf/Xen: avoid calling XenHypercallLib constructor on !Xen

On Mon, Mar 02, 2015 at 05:13:22PM +, Ard Biesheuvel wrote: > This refactors the XenHypercallLib implementation for ARM and x86, > and their callers, so that the init code for the XenHypercallLib > is only called in places where we have already established that we > are running as a Xen guest,

[edk2] [PATCH 2/4] OvmfPkg: ArmXenHypercallLib: add empty constructor

In the next patch we'll add a simple query function to the XenHypercallLib library class that is supposed to be called by initialization code in modules. Among those, in constructors of dependent libraries too. Library construction ordering is ensured only between libraries with constructors, plus

[edk2] [PATCH 3/4] OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()

Similarly to QemuFwCfgLib, we prefer mellow library construction code and an explicit "are you available" query function in the XenHypercallLib class. In this step we introduce that query function, but move no client code to it yet. Suggested-by: Jordan Justen Contributed-under: TianoCore Contrib

[edk2] [PATCH 0/4] relax XenHypercallLib construction

This series fixes the error reported by Gabriel, and tries *very hard* to comply with Jordan's suggestions. :) Public branch: . Laszlo Ersek (4): OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib names OvmfPkg: ArmXenHyperca

[edk2] [PATCH 1/4] OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib names

Perform the following renames in order to stick with edk2 tradition more closely: XenHypercallLibArm-> ArmXenHypercallLib XenHypercallIntel -> X86XenHypercall XenHypercallLibIntel -> X86XenHypercallLib This patch modifies ArmVirtualizationPkg and OvmfPkg at once, in order to kee

[edk2] [PATCH 4/4] OvmfPkg: replace strict XenHypercallLib construction with explicit query

XenHypercallLib has two clients at the moment: XenBusDxe and XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86 platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib instance built into it fails to initialize, which triggers an ASSERT() in auto-generated

[edk2] [PATCH v2 2/4] OvmfPkg: XenHypercallLib: add empty constructor for ARM & AARCH64

In the next patch we'll add a simple query function to the XenHypercallLib library class that is supposed to be called by initialization code in modules. Among those, in constructors of dependent libraries too. Library construction ordering is ensured only between libraries with constructors, plus

[edk2] [PATCH v2 1/4] OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib names

Perform the following renames in order to stick with edk2 tradition more closely: XenHypercallLibArm, XenHypercallLibIntel -> XenHypercallLib XenHypercallIntel -> X86XenHypercall In addition, we unify the INF files. This patch modifies ArmVirtualizationPkg and Ovmf

[edk2] [PATCH v2 3/4] OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()

Similarly to QemuFwCfgLib, we prefer mellow library construction code and an explicit "are you available" query function in the XenHypercallLib class. In this step we introduce that query function, but move no client code to it yet. Suggested-by: Jordan Justen Contributed-under: TianoCore Contrib

[edk2] [PATCH v2 0/4] relax XenHypercallLib construction

Patches #1 and #2 have been modified, unifying the INF file between ARM and X86. Public branch: . Laszlo Ersek (4): OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib names OvmfPkg: XenHypercallLib: add empty constructor f

[edk2] [PATCH v2 4/4] OvmfPkg: replace strict XenHypercallLib construction with explicit query

XenHypercallLib has two clients at the moment: XenBusDxe and XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86 platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib instance built into it fails to initialize, which triggers an ASSERT() in auto-generated

Re: [edk2] [PATCH v2 0/4] relax XenHypercallLib construction

Thanks Laszlo! Series Reviewed-by: Jordan Justen On 2015-03-02 13:01:29, Laszlo Ersek wrote: > Patches #1 and #2 have been modified, unifying the INF file between ARM > and X86. > > Public branch: > . > > Laszlo Ersek (4): > O

Re: [edk2] Macro expansion in DEC

Thanks but I got Table 1. from the DEC spec 1.22. I was saying that the table is no longer there in 1.24, but yet the other macros expand. I just solved this issue by setting another environment variable to the include directory and putting that variable in the build options in the DSC with /I s

Re: [edk2] SEC PPI HOBs

Andrew: I agree this is a spec issue. In our X64 platform, we have done it in CPU PEIM and Platform PEIM. After PI spec clarifies it, we can update PeiCore to build this HOB again. Thanks Liming From: Andrew Fish [mailto:af...@apple.com] Sent: Tuesday, March 3, 2015 2:05 AM To: edk2-devel@list

Re: [edk2] Macro expansion in DEC

DEC/INF belongs to Package. EDKII Package is the standalone unit. It can pass build without platform setting. DSC/FDF are platform scope that can refer to the packages. Thanks Liming From: apia...@aol.com [mailto:apia...@aol.com] Sent: Tuesday, March 3, 2015 5:49 AM To: edk2-devel@lists.sourcefo

[edk2] [v2 4/4] UefiCpuPkg/MpSerivce: remove volatile qualifier

because manipulating CpuState always with lock protection. so volatile qualifier is redundant. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- UefiCpuPkg/CpuDxe/CpuMp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UefiCpuPkg/CpuDxe/CpuMp

[edk2] [v2 2/4] UefiCpuPkg/MpService: put AP to busy state when execution

CpuState should follow the process： Idle -> Ready -> Busy -> Finished ^ | | | + - - - - - - - - - - - - + Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- UefiCpuPkg/CpuDxe/CpuMp.c | 9 +++-

[edk2] [v2 0/4] UefiCpuPkg/MpService: Put APs to sleep when not busy

nowadays, APs are busy running when installing MP protocol in multiple processors environment. so it whould consume much power resource unnecessary. this patchs put APs to sleep when not procedure to run, then via sending NMI IPI by BSP to wake up AP with hlt state. there is a proposal several mon

[edk2] [v2 3/4] UefiCpuPkg/MpService: Put APs to sleep when not busy

Add a new sleeping state for APs, when no procedure execution, put AP to sleep. when need to execute procedure, only need to wake up this AP by sent SIPI. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- UefiCpuPkg/CpuDxe/CpuMp.c | 61 ++

[edk2] [v2 1/4] UefiCpuPkg/MpService: fix trivial typo in cpu state

CpuStateBuzy => CpuStateBusy Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- UefiCpuPkg/CpuDxe/CpuMp.c | 2 +- UefiCpuPkg/CpuDxe/CpuMp.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.

Re: [edk2] [PATCH 2/4] UefiCpuPkg/MpService: register NMI handler for wake up AP with hlt state

On 02/03/2015 10:51 PM, Jordan Justen wrote: > On 2015-02-03 00:07:20, Fan, Jeff wrote: >> Jordan is right. NMI exception handler may be hooked by platform to capture >> real NMI interrupt. >> >> I suggest to send SIPI to Aps to wakeup AP if AP is in hlt state. >> But Aps needs startup from real

Re: [edk2] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.

Bruce Thanks for the help so far. I think I managed to solve all my VS (Community Edition) issues and I get pretty far now but build fails with this error: build... : error 000E: File/directory not found in workspace c:\...\myworkspace\Vlv2BinaryPkg\X64RELEASE\IA32\

Re: [edk2] [MinnowBoard] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.

On Monday, March 2, 2015, Gerard Bucas wrote: > > : error 000E: File/directory not found in workspace > > > c:\...\myworkspace\Vlv2BinaryPkg\X64RELEASE\IA32\PchSmbusArpDisabled.inf > > > > I do not have the “….\myworkspace\Vlv2BinaryPkg\” directory. > > This isn't really an edk2 issue - t

Re: [edk2] [MinnowBoard] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.

Thanks Bruce I did in fact read that & patched OpenSSL and THOUGHT I had correctly downloaded all the binaries. Guess somehow they landed up in the wrong place. Will check this out tomorrow - now I know where to look! Regards Gerard > On Mar 3, 2015, at 1:10 AM, B Cran wrote: > >> On Mond

Re: [edk2] [MinnowBoard] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.

Bruce, OK – somehow screwed up the folders in which those binariws wre supposed to go. Fixed it – THANKS! So far all my “issues” have been my own fault (or caused by the fact that I didn’t have VS2008 – which I debugged and fixed) so I hate asking you for even more help but you seem to h

Re: [edk2] [PATCH 0/6] update pool allocator to better support 64 KB runtime regions

Ard: I think current region is 128 (1 << 7) bytes. But, I agree use exponential bin sizes is better than linearly increasing with 128 bytes. Your patch defines mPoolSizeTable as below. Its max value is 24128. When Granularity is 64K, the request pool size that larger than 24128 will require

Re: [edk2] [PATCH 0/6] update pool allocator to better support 64 KB runtime regions

On 3 March 2015 at 06:55, Gao, Liming wrote: > Ard: > I think current region is 128 (1 << 7) bytes. But, I agree use exponential > bin sizes is better than linearly increasing with 128 bytes. > Ah yes, you are quite right. > Your patch defines mPoolSizeTable as below. Its max value is 24128

Re: [edk2] [Xen-devel] [PATCH v5 00/29] Xen/ARM guest support

On 3 March 2015 at 03:00, Wu, Feng wrote: > > >> -Original Message- >> From: xen-devel-boun...@lists.xen.org >> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Ard Biesheuvel >> Sent: Wednesday, February 25, 2015 2:03 AM >> To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com

Re: [edk2] [PATCH v2 0/4] relax XenHypercallLib construction

On 2 March 2015 at 21:46, Jordan Justen wrote: > Thanks Laszlo! > > Series Reviewed-by: Jordan Justen > For the series: Reviewed-by: Ard Biesheuvel Tested-by: Ard Biesheuvel # as a Xen/ARM domU > On 2015-03-02 13:01:29, Laszlo Ersek wrote: >> Patches #1 and #2 have been modified, unifying t

Re: [edk2] [MinnowBoard] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.

On Monday, March 2, 2015, Gerard Bucas wrote: > > Any idea on what is causing this error: > > > > build... > > …\myworkspace\EdkCompatibilityPkg\Compatibility\SmmBaseHelper\SmmBaseHelper > > .inf(66): error 4000: Value of Guid [gEdkiiMemoryProfileGuid] is not found > under > > No idea - this looks

Re: [edk2] [MinnowBoard] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.

> On Mar 2, 2015, at 11:32 PM, B Cran wrote: > > On Monday, March 2, 2015, Gerard Bucas > wrote: > Any idea on what is causing this error: > > > > build... > > …\myworkspace\EdkCompatibilityPkg\Compatibility\SmmBaseHelper\SmmBaseHelper > > .inf(66): error 400