Re: [edk2] [RFC PATCH v6 06/27] UefiCpuPkg/CpuDxe: introduce two PCD value

Chen, Got you. You could use ReallocatePool () to re-allocate the internal CPU data and the old one will be freed, after actual processor number gotten. mMpSystemData.CpuDatas = ReallocatePool ( sizeof (CPU_DATA_BLOCK) * gMaxLogicalP

[edk2] Device path for Nand Flash BlockIo

Hi I have a Nand Flash driver that installs BlockIo protocol. I want to use it to get the linux kernel image from NAND to system memory, in BDS phase. An ideal solution would be abstracting BlockIo with DiskIo, which in turn is abstracted with SimpleFileSystem. A device path concatenated with a

Re: [edk2] [RFC PATCH v6 06/27] UefiCpuPkg/CpuDxe: introduce two PCD value

Hi Jeff, as for the 2, we got this actual CPUs after start-up all APs, but I think it would be late to allocate the CPU data buffer. because I needed to fill the data at the time of startup CPUs. Thanks, Chen On Mon, 2014-11-03 at 08:36 +, Fan, Jeff wrote: > Chen, > > 1. Because you

Re: [edk2] [PATCH] BaseTools/GenFw: Fixed R_AARCH64_CALL26/R_AARCH64_JUMP26 when referring to a section

Patch is good to me. Reviewed-by: Yingke Liu Dennis -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Monday, November 03, 2014 7:04 PM To: Liu, Yingke D Cc: edk2-devel@lists.sourceforge.net; Olivier Martin Subject: [PATCH] BaseTools/GenFw: Fixed R_AARCH64_CA

Re: [edk2] [PATCH v4 4/6] OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances

On Mon, Nov 03, 2014 at 08:09:28PM +0100, Laszlo Ersek wrote: > comments below: > > On 11/01/14 23:20, Gabriel L. Somlo wrote: > > Remove local power management register access macros in favor of > > factored-out ones in OvmfPkg/Include/OvmfPlatforms.h > > > > Next, AcpiTimerLib is split out into

Re: [edk2] Enable optimization for gcc x64 builds

> On Nov 3, 2014, at 12:24 PM, Scott Duplichan wrote: > > Laszlo Ersek [mailto:ler...@redhat.com ] wrote: > > ]On 10/29/14 05:59, Scott Duplichan wrote: > ]> Optimization is not enabled for x64 builds using gcc 4.4-4.9. For IA32 > ]> builds, -Os (optimize for small cod

Re: [edk2] Enable optimization for gcc x64 builds

Bruce Cran [mailto:bruce.c...@gmail.com] wrote: ]On 11/3/2014 9:21 AM, Laszlo Ersek wrote: ] ]> So Scott's patch seems to be aligned with the ]> tradition. (Currently no gcc optimizations are enabled at all when ]> building for X64, neither for speed nor for size.) ] ]Doesn't the following cause

Re: [edk2] i'm outta here

On 10/24/14 22:47, cinap_len...@thefront.felloff.net wrote: > Attestation: > I have made the following decisition to support my sanity. > > Submission: > unsubscribing from this mailinglist. You asked for help on October 23rd ("EFI PXE booting with OVMF"). You got a quick ACK (but alas, no usable

Re: [edk2] Enable optimization for gcc x64 builds

Ah, thanks - I failed to trace it all the way through and just assumed it *was* used by one of the BUILDTYPE_TOOLCHAIN_ARCH_CC_FLAGS lines. -- Bruce On Mon, Nov 3, 2014 at 1:20 PM, Laszlo Ersek wrote: > No; GCC_X64_CC_FLAGS is an "internal use" define. Its name doesn't > follow the > > (DEBU

Re: [edk2] Enable optimization for gcc x64 builds

Laszlo Ersek [mailto:ler...@redhat.com] wrote: ]On 10/29/14 05:59, Scott Duplichan wrote: ]> Optimization is not enabled for x64 builds using gcc 4.4-4.9. For IA32 ]> builds, -Os (optimize for small code size) is used. Why is this? Apparently ]> it is because variable argument list handling fails

Re: [edk2] [PATCH] ArmVirtualizationQemu: fix the console when ConIn/ConOut/ErrOut are missing

On 10/28/14 17:23, Olivier Martin wrote: > > >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: 17 October 2014 00:04 >> To: edk2-devel@lists.sourceforge.net >> Subject: Re: [edk2] [PATCH] ArmVirtualizationQemu: fix the console when >> ConIn/ConOut/ErrOut are

Re: [edk2] Enable optimization for gcc x64 builds

On 11/03/14 20:54, Bruce Cran wrote: > On 11/3/2014 9:21 AM, Laszlo Ersek wrote: > >> So Scott's patch seems to be aligned with the >> tradition. (Currently no gcc optimizations are enabled at all when >> building for X64, neither for speed nor for size.) > > Doesn't the following cause X64 build

Re: [edk2] [PATCH v4 6/6] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

On 11/01/14 23:21, Gabriel L. Somlo wrote: > Merge PciInitialization() and AcpiInitialization() into a single > function, PciAcpiInitialization(), and use a PCD set during PEI to > detect the underlying platform type (PIIX4 or Q35/MCH) and therefore > the addresses of the registers to be initialize

Re: [edk2] Enable optimization for gcc x64 builds

On 11/3/2014 9:21 AM, Laszlo Ersek wrote: > So Scott's patch seems to be aligned with the > tradition. (Currently no gcc optimizations are enabled at all when > building for X64, neither for speed nor for size.) Doesn't the following cause X64 builds to use -Os (and IA32 to use -O2, if it wasn't

Re: [edk2] [PATCH v4 5/6] OvmfPkg: CsmSupportLib: Set/use platform specific legacy interrupt device

On 11/01/14 23:20, Gabriel L. Somlo wrote: > Use a PCD set from PEI to determine the legacy interrupt device > number appropriate for the underlying platform type during protocol > initialization. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Gabriel Somlo > Reviewe

Re: [edk2] [PATCH v4 4/6] OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances

comments below: On 11/01/14 23:20, Gabriel L. Somlo wrote: > Remove local power management register access macros in favor of > factored-out ones in OvmfPkg/Include/OvmfPlatforms.h > > Next, AcpiTimerLib is split out into three instances, for use during > various stages: > > - BaseRom: used du

Re: [edk2] [PATCH v4 3/6] OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)

On 11/01/14 23:20, Gabriel L. Somlo wrote: > Set from PEI, this PCD allows subsequent stages (specifically > DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform > type (e.g. PIIX4 or Q35/MCH) without the need to further query the > Host Bridge for its Device ID. > > Contributed-und

Re: [edk2] [PATCH v4 1/6] OvmfPkg: Factor out platform detection (q35 vs. piix4)

On 11/01/14 23:20, Gabriel L. Somlo wrote: > Introduce macros to detect the underlying platform and access its > ACPI power management registers, based on querying the host bridge > device ID. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Gabriel Somlo > Reviewed-by

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

On 11/01/14 23:20, Gabriel L. Somlo wrote: > Set up ACPI power management using registers determined based on > the underlying (PIIX4 or Q35/MCH) platform type. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Gabriel Somlo > Reviewed-by: Paolo Bonzini > Reviewed-by:

Re: [edk2] BaseLib/Ia32/InternalSwitchStack.S still needed? - Re: SF.net SVN: edk2:[12007] trunk/edk2/MdePkg/Library

> On Oct 31, 2014, at 2:36 PM, Jordan Justen wrote: > > On Fri, Oct 31, 2014 at 1:18 PM, Andrew Fish wrote: >> >>> On Oct 31, 2014, at 12:38 PM, Jordan Justen wrote: >>> >>> Andrew, >>> >>> Back in February 2011, you added this assembly file to (apparently) >>> work around a gdb bug. Do you

Re: [edk2] [PATCH v3 0/6] OVMF: Adding support for Qemu Q35 machine type

On 10/28/14 11:31, Paolo Bonzini wrote: > > > On 10/28/2014 05:09 AM, Gabriel L. Somlo wrote: >> New in version 3: >> >> - patches 6 and 7 from earlier v2 now merged into a single PCI/ACPI >> initialization patch; PIIX4 initialization of PCI_INTERRUPT_LINE >> register re-added (in clean

Re: [edk2] DuetPkg: correct print formatting problem for gcc X64 build

On 10/29/14 05:32, Scott Duplichan wrote: > Without patch: > LoadPe: new image base 7FE88000 > DxeCore PE image is successed loaded at 0, entry=13 > > EFI Memory Descriptors > Type = 0 Start = 0013 NumberOfPages = > Type = 0 Start = 0013 NumberOfPages = 000

Re: [edk2] Enable optimization for gcc x64 builds

On 10/29/14 17:18, Tim Lewis wrote: > Scott -- > > For historical perspective, the EDK2 build flags have focused on > space over speed because of the code size constraints placed on > flash-resident code. Not being as familiar with gcc as I am with > VS20xx, I don't know whether these can be set t

Re: [edk2] Enable optimization for gcc x64 builds

On 10/29/14 05:59, Scott Duplichan wrote: > Optimization is not enabled for x64 builds using gcc 4.4-4.9. For IA32 > builds, -Os (optimize for small code size) is used. Why is this? Apparently > it is because variable argument list handling fails when gcc X64 optimization > is enabled. The solution

Re: [edk2] Non-Volatile Variable Storage

On 11/03/2014 07:18 AM, Pant, Alok wrote: >>>which you can stop the h/w DMA, save OS context, do your task and then > restore OS context > > Hi Feng, > > Thanks. Yes this is one possibly but the implementation is always > messy. There is always some corner case where OS on other thread may be >

Re: [edk2] Non-Volatile Variable Storage

I agree w/ your points Alok. I will include these items in this week’s discussion. On your suggestion of a whitepaper to provide guidance, that is a great idea, too. We have been embracing that medium recently around clarifying some of the design intent around many edkII elements, including a t

Re: [edk2] Non-Volatile Variable Storage

>> which you can stop the h/w DMA, save OS context, do your task and then >> restore OS context Hi Feng, Thanks. Yes this is one possibly but the implementation is always messy. There is always some corner case where OS on other thread may be accessing the controller and BIOS(SMM) stepping on

Re: [edk2] GenFw build errors

Note: I have just sent a patch to properly fixed this relocation. See email “[PATCH] BaseTools/GenFw: Fixed R_AARCH64_CALL26/R_AARCH64_JUMP26 when referring to a section” (03/11/2014 11:04 GMT) From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: 31 October 2014 21:16 To: edk2-devel@li

[edk2] [PATCH] BaseTools/GenFw: Fixed R_AARCH64_CALL26/R_AARCH64_JUMP26 when referring to a section

When R_AARCH64_CALL26/R_AARCH64_JUMP26 relocations referred to static functions, they sometime refer to the start of the '.text' section + addend. It means the addend is different of '0'. The non-patched code (before applying the relocation) already contains the correct offset. SO, these relocation

[edk2] [PATCH] MdePkg: fix comments typo about EFIAPI for X64

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- MdePkg/Include/X64/ProcessorBind.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdePkg/Include/X64/ProcessorBind.h b/MdePkg/Include/X64/ProcessorBind.h index dae0683..842c9a6 100644 ---

Re: [edk2] PCD Database Forcing

I have the same question. It seems no way to do this except modify Python source code. My workaround is to create a dummy driver which is including all PCD that I need. -Harrison > Tim Lewis 於 2014年11月1日 上午6:29 寫道： > > How can I force a PCD that is not referenced in any INF to be the PCD

Re: [edk2] [RFC PATCH v6 08/27] UefiCpuPkg/CpuDxe: introduce EFI_MP_SERVICES_PROTOCOL

On Mon, 2014-11-03 at 08:38 +, Fan, Jeff wrote: > Chen, > > MP Service Protocol is not always installed. Please use ## SOMETIMES_PRODUCES > > + gEfiMpServiceProtocolGuid ## SOMETIMES_PRODUCES OK. Thanks, Chen > Thanks! > Jeff > > -Original Message- > From: Ch

Re: [edk2] [RFC PATCH v6 01/27] UefiCpuPkg/CpuDxe: Add no-op InitializeMpSupport

On Mon, 2014-11-03 at 08:38 +, Fan, Jeff wrote: > Chen, > > +/** > + Initialize Multi-processor support. > + > +**/ > +VOID InitializeMpSupport ( > + VOID > + ); > > Missing Enter between VOID and InitializeMpSupport() in CpuMp.h > Got it. Thanks, Chen > Thanks! > Jeff > > -Orig

Re: [edk2] [RFC PATCH v6 09/27] UefiCpuPkg/CpuDxe: introduce MP_SYSTEM_DATA for Mp Service Protocol

On Mon, 2014-11-03 at 08:37 +, Fan, Jeff wrote: > Chen, > > 1.FillInProcessorInformation() function head's parameters block does not > match the function declaration. > +/** > + This function is called by all processors (both BSP and AP) once and > +collects MP related data > + > + @param

Re: [edk2] [RFC PATCH v6 07/27] UefiCpuPkg/CpuDxe: Switch Ap Stack to NewStack

On Mon, 2014-11-03 at 08:37 +, Fan, Jeff wrote: > Chen, > > Missing parameter description block in function header of > ProcessorToIdleState(). Got it. Thanks, Chen > > Thanks! > Jeff > > -Original Message- > From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] > Sent: Monday,

Re: [edk2] [RFC PATCH v6 06/27] UefiCpuPkg/CpuDxe: introduce two PCD value

On Mon, 2014-11-03 at 08:36 +, Fan, Jeff wrote: > Chen, > > 1. Because you used the FreePages () to free the un-used memory space > allocated for stack per the actual processors number, please add ASSERT to > make sure PcdCpuApStackSize is multiple of 4K Bytes and add the comment in > DEC

Re: [edk2] [RFC PATCH v6 08/27] UefiCpuPkg/CpuDxe: introduce EFI_MP_SERVICES_PROTOCOL

Chen, MP Service Protocol is not always installed. Please use ## SOMETIMES_PRODUCES + gEfiMpServiceProtocolGuid ## SOMETIMES_PRODUCES Thanks! Jeff -Original Message- From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] Sent: Monday, October 27, 2014 5:30 PM To: edk

Re: [edk2] [RFC PATCH v6 01/27] UefiCpuPkg/CpuDxe: Add no-op InitializeMpSupport

Chen, +/** + Initialize Multi-processor support. + +**/ +VOID InitializeMpSupport ( + VOID + ); Missing Enter between VOID and InitializeMpSupport() in CpuMp.h Thanks! Jeff -Original Message- From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] Sent: Monday, October 27, 2014 5:30 PM

Re: [edk2] [RFC PATCH v6 07/27] UefiCpuPkg/CpuDxe: Switch Ap Stack to NewStack

Chen, Missing parameter description block in function header of ProcessorToIdleState(). Thanks! Jeff -Original Message- From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] Sent: Monday, October 27, 2014 5:30 PM To: edk2-devel@lists.sourceforge.net Cc: Fan, Jeff; Jordan Justen Subject:

Re: [edk2] [RFC PATCH v6 09/27] UefiCpuPkg/CpuDxe: introduce MP_SYSTEM_DATA for Mp Service Protocol

Chen, 1.FillInProcessorInformation() function head's parameters block does not match the function declaration. +/** + This function is called by all processors (both BSP and AP) once and +collects MP related data + + @param MPSystemDataPointer to the data structure containing MP related d

Re: [edk2] [RFC PATCH v6 06/27] UefiCpuPkg/CpuDxe: introduce two PCD value

Chen, 1. Because you used the FreePages () to free the un-used memory space allocated for stack per the actual processors number, please add ASSERT to make sure PcdCpuApStackSize is multiple of 4K Bytes and add the comment in DEC for this PCD. ASSERT (gApStackSize & (SIZE_4KB - 1) == 0);

[edk2] [PATCH v2 1/3] EmulatorPkg/Mpservice: fix wrong unsigned to signed variable transition

Because TimeoutInMicrosecsond is a unsigned value, converting it to signed value will cause the data region changed. so this patch fix that. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- EmulatorPkg/CpuRuntimeDxe/MpService.c | 10 +- 1 file changed,

[edk2] [PATCH v2 3/3] EmulatorPkg/Mpservice: add enabled processor check for startupThisAP

if processor number is the one of disabled processor, startupThisAP should return invalid prameter. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- EmulatorPkg/CpuRuntimeDxe/MpService.c | 4 1 file changed, 4 insertions(+) diff --git a/EmulatorPkg/CpuRun

[edk2] [PATCH v2 0/3] EmulatorPkg/MpService: fix bugs

there were some bugs we should fix. Chen Fan (3): EmulatorPkg/Mpservice: fix wrong unsigned to signed variable transition EmulatorPkg/MpService: StartupAllAPs should verify processor state before setting state EmulatorPkg/Mpservice: add enabled processor check for startupThisAP Emu

[edk2] [PATCH v2 2/3] EmulatorPkg/MpService: StartupAllAPs should verify processor state before setting state

if any enabled APs are not in idle state, StartupAllAPs() should return immediately, and must not change the other idled processor state. so we checked the state before changed them. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan --- EmulatorPkg/CpuRuntimeDxe/M