PI spec doesn’t define the clear rule. So, this is not PeiCore compliant issue.
Like Jiewen say, Early PEIM that run before CAR down can consume data from PPI
and publish HOB. It should be platform PEIM, because we can’t assure the
generic PEIM is dispatched before CAR down.
Thanks
Liming
From:
I think CPU PEIM need consume data from PPI and publish HOB.
CPU PEIM might also reinstall EFI_SEC_PLATFORM_INFORMATION_PPI to let PPI
consume data from HOB. The Old EFI_SEC_PLATFORM_INFORMATION_PPI might refer
data on CAR, which is not available after CAR teardown.
Thank you
Yao Jiewen
From:
Reviewed-by: Ruiyu Ni
From: Qiu, Shumin [mailto:shumin@intel.com]
Sent: Monday, February 9, 2015 9:47 AM
To: Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch]NT32Pkg: Bind NT32 process to a single core to avoid
NT32 crash issue in some multi-core processors.
Hi Eri
> On Feb 27, 2015, at 3:02 PM, Tim Lewis wrote:
>
> Section 8.3.1 of the PI Specification, volume 1, says (of the
> EFI_SEC_PLATFORM_INFORMATION_PPI)
>
> This same information will be placed in a GUIDed HOB with the PPI GUID as the
> HOB GUID.
> This allows agents, such as the DXE multiproce
Section 8.3.1 of the PI Specification, volume 1, says (of the
EFI_SEC_PLATFORM_INFORMATION_PPI)
This same information will be placed in a GUIDed HOB with the PPI GUID as the
HOB GUID.
This allows agents, such as the DXE multiprocessor (MP) driver, to get health
information for the
boot-strap pr
Laszlo,
You are welcome to apply the patch set. Thanks for helping.
Mike
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, February 27, 2015 1:02 PM
To: edk2-devel@lists.sourceforge.net; Olivier Martin; Laszlo Ersek; Justen,
Jordan L; Kinney, Mic
Ard,
The updated patch looks good.
Reviewed-by: Michael Kinney
Thanks,
Mike
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, February 26, 2015 12:50 AM
To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com;
ler...@redhat.com; Justen,
On 26 February 2015 at 08:50, Ard Biesheuvel wrote:
> Hello all,
>
> This is the latest version of the InterlockedCompareExchange16() patch.
> Michael has kindly confirmed (thanks Michael) that it does the right
> thing for IPF, but also spotted some issues with the Intel asm versions.
>
> The pat
"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
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
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
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 +---
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization
Surprisingly, some people would like to get fewer debug messages from
edk2, rather than more. While I can certainly not identify with such
preferences, the yes-man employee that I am agreed to writing this
series. At the end of it, an ArmVirtualizationQemu binary built with
-D DEBUG_PRINT_ERROR_
OK – figured it out – sorry to waste your time!
(required an “export” instead of an “import” in TortoiseSVN – counter-intuitive
to me!)
From: Gerard Bucas [mailto:gerar...@tekmagic.net]
Sent: Friday, February 27, 2015 11:50 AM
To: 'Wei, David'; edk2-devel@lists.sourceforge.net
Cc: 'Minnow
> On Feb 27, 2015, at 12:27 AM, tiger...@zhaoxin.com wrote:
>
> Hi, experts:
> UEFI BIOS will do pci enumeration, and allocated IO ranges(not MMIO range,
> just pure IO range) for some PCI devices.
> So:
> How to declare these allocated IO ranges as reserved when booting OS.
> So OS won’t occupy
Thanks David,
Stupid question:
Which Windows “tool” can import from that “svn” webpage?
I tried TortoiseSVN but it asks for username/pwd and my sourceforge credentials
don’t work on it. So can’t seem to be able to import anything from that link
(that’s why I eventually landed up using
Hi Leif,
Thanks for your reply. Some comments in-line
> Hi Sakar,
>
> On Thu, Feb 26, 2015 at 10:36:18AM +, sakar.ar...@freescale.com
> wrote:
> > I see that by and large, the contents of SoC and Board Packages (ARM
> based) in EDK2, are like this:
> >
> >
> > - Most drivers like mm
On Fri, Feb 27, 2015 at 12:08:32PM +, bhupesh.sha...@freescale.com wrote:
> Sure. We understand the same. However, it seems that as we add support for
> new ARM based platforms to this tree, the source code would un-necessarily
> bloat
> and we might end up in the same situation as we had in u
Hi Sakar,
On Thu, Feb 26, 2015 at 10:36:18AM +, sakar.ar...@freescale.com wrote:
> I see that by and large, the contents of SoC and Board Packages (ARM based)
> in EDK2, are like this:
>
>
> - Most drivers like mmc, sd, flash, timer, etc and certain Libraries
> like Serial port,
Please follow following two steps of the release note to get
Vlv2DeviceRefCodePkg and Vlv2TbltDevicePkg from
https://svn.code.sf.net/p/edk2/code/branches/UDK2014.SP1.
2. Create the following folders (sub-directories) from your workspace (e.g.
"C:\MyWorkspace"):
BaseTools
Conf
Hi, experts:
UEFI BIOS will do pci enumeration, and allocated IO ranges(not MMIO range, just
pure IO range) for some PCI devices.
So:
How to declare these allocated IO ranges as reserved when booting OS.
So OS won’t occupy these pre-allocated IO ranges when a PnP device is plugged
during OS runti
21 matches
Mail list logo
