Hi, Simon
I found my first proposed patch has issue on using DisconnectController() as
the current dxe core implementation would return EFI_NOT_FOUND if the image
handle is not managing controller handle.
So I enhanced my patch to avoid such case. I have tested it at h/w and unload()
could be
Dear All,
I am developing application by using DuetPkgX64.dsc.
I want to know current directory of my program so I`m try to get
EfiShellprotocol.
It return Error(3 : EFO_UNSUPPORT);
Is there other way to get current directory?
EFI_SHELL_PRTOCOL *tEfiShellProtocol = NULL;
Status = gBS->OpenProt
Hi Andrew,
The GenPcdDb.py(BaseTools\Source\Python\AutoGen) will to generate the RAW
file(PEIPcdDataBase.raw and DXEPcdDataBase.raw) for PEI and DXE PCD driver.
Could you help check if they are present in
...\IA32(X64)\MdeModulePkg\Universal\PCD\Pei(Dxe)\Pcd\OUTPUT?
Could you help check if the
Hi, all
I have finished this sync at r15089. The final sync BaseTools version is
2640. If you meet with any build issue, please let me know.
Thanks
Liming
From: Gao, Liming [mailto:liming@intel.com]
Sent: Thursday, January 02, 2014 11:12 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk
Hi, Oliver:
I have a question abourt ARMv8 CPU's bootloader.
ARMv8 supports: AARCH32 / AARCH64
Take an example:
An ARMv8 SOC, when power up / reset, its default state is : AARCH32
Then, could i still run an old arm uefi bootloader which written by
ARMv7 instruction set?
I will switch ARMv8 SOC to A
I’m pulling in new BaseTools and edk2 versions and I ran into issue where I
ASSERT in the DXE PCD driver. I’m hitting the ASSERT() in LocateExPcdBinary().
It looks there is an assumption that there is a RAW file section in with the
driver? It seems that is not happening. What code makes this ha
The patch looks good to me.
Reviewed-by: Ruiyu Ni mailto:ruiyu...@intel.com>>
From: Carsey, Jaben
Sent: Friday, January 10, 2014 6:16 AM
To: edk2-devel@lists.sourceforge.net; Ni, Ruiyu
Cc: Carsey, Jaben
Subject: ShellPkg: remove potential memory leak with new apps on old shell
Ray,
Can you re
The patch looks good to me.
Reviewed-by: Ruiyu Ni
From: Carsey, Jaben
Sent: Friday, January 10, 2014 6:15 AM
To: edk2-devel@lists.sourceforge.net; Ni, Ruiyu
Cc: Carsey, Jaben
Subject: ShellPkg: remove double free operation
Ray,
Can you review this?
ShellPkg: remove double free operation
Hi, Oliver:
I have a question abourt ARMv8 CPU's bootloader.
ARMv8 supports: AARCH32 / AARCH64
Take an example:
An ARMv8 SOC, when power up / reset, its default state is : AARCH32
Then, could i still run an old arm uefi bootloader which written by
ARMv7 instruction set?
I will switch ARMv8 SOC to A
On Jan 9, 2014, at 1:19 PM, Kirkendall, Garrett
wrote:
> Should we force Little Endian as well since EFI has taken the Little Endian
> stance?
>
Good point. We should make sure all the places are consistent. In the C code
and the Python BaseTools.
> I know there are a few places in the bu
On Thu, Jan 9, 2014 at 2:00 PM, Laszlo Ersek wrote:
> On 01/09/14 22:47, Jordan Justen wrote:
>> On Thu, Jan 9, 2014 at 12:41 PM, Laszlo Ersek wrote:
>>> On 01/09/14 01:45, Jordan Justen wrote:
From: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-
Ray,
Can you review this?
ShellPkg: remove potential memory leak with new apps on old shell
This pointer never gets free when running new apps on the old shell.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey
mailto:jaben.car...@intel.com>>
UefiShellLib.
Ray,
Can you review this?
ShellPkg: remove double free operation
This pointer gets free twice and this does not work.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey
mailto:jaben.car...@intel.com>>
Ls.c.patch
Description: Ls.c.patch
-
On 01/09/14 22:47, Jordan Justen wrote:
> On Thu, Jan 9, 2014 at 12:41 PM, Laszlo Ersek wrote:
>> On 01/09/14 01:45, Jordan Justen wrote:
>>> From: Laszlo Ersek
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Laszlo Ersek
>>> [jordan.l.jus...@intel.com: move to
Please note that I made my commits in the incorrect order today. This commit
is required for the shell commit I made this morning to build/function.
-Jaben
-Original Message-
From: jcar...@users.sourceforge.net [mailto:jcar...@users.sourceforge.net]
Sent: Thursday, January 09, 2014 1:5
On Thu, Jan 9, 2014 at 12:41 PM, Laszlo Ersek wrote:
> On 01/09/14 01:45, Jordan Justen wrote:
>> From: Laszlo Ersek
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek
>> [jordan.l.jus...@intel.com: move to MemDetect.c; use PCDs]
>
> PCDs are fine of cou
Should we force Little Endian as well since EFI has taken the Little Endian
stance?
I know there are a few places in the build tools that pack and unpack data, and
I assume we should try to force consistency wherever possible. Just in case
the dream comes true and UEFI takes over the firmware
On Thu, Jan 9, 2014 at 11:15 AM, Laszlo Ersek wrote:
> On 01/09/14 01:44, Jordan Justen wrote:
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jordan Justen
>> ---
>> OvmfPkg/PlatformPei/Platform.c | 10 +--
>> OvmfPkg/PlatformPei/Platform.h | 188
>> ++
On 01/09/14 01:45, Jordan Justen wrote:
> From: Laszlo Ersek
>
> On X64, the reset vector code in
> "OvmfPkg/ResetVector/Ia32/PageTables64.asm" identity maps the first 4GB of
> RAM for PEI, consuming six frames starting at 8MB.
>
> This range is declared by the PcdOvmfSecPageTablesBase/Size PCDs
On 01/09/14 01:45, Jordan Justen wrote:
> From: Laszlo Ersek
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> [jordan.l.jus...@intel.com: move to MemDetect.c; use PCDs]
PCDs are fine of course, but MemDetect() is not called on Xen
(unless that's the in
On 01/09/14 01:45, Jordan Justen wrote:
> Since we marked the FV at PcdOvmfPeiMemFvBase as ACPI NVS memory,
> we can use it on S3 resume.
>
> The FV at PcdOvmfDxeMemFvBase may have been overwritten by the OS,
> but we do not use it's contents on S3 resume.
>
> Contributed-under: TianoCore Contrib
comments at bottom
On 01/09/14 01:44, Jordan Justen wrote:
> We will not be running DXE on S3 resume, so we don't
> need to do these initialization items:
> * Reserve EMU Variable memory range
> * Declare Firmware volumes
> * Add memory HOBs
> * MiscInitialization:
>- Disable A20 Mask
>
comments below
On 01/09/14 01:44, Jordan Justen wrote:
> This 32k section of RAM will be declared to the PEI Core on
> S3 resume to allow memory allocations during S3 resume PEI.
>
> If the boot mode is BOOT_ON_S3_RESUME, then we publish
> the pre-reserved PcdS3AcpiReservedMemory range to PEI.
>
Hi Rafael & Eugene,
Normally the EmbeddedPkg/Universal/MmcDxe should support MMC / SD(HC) (and I
have just pushed eMMC support - svn 15074). It has been tested with
different MMC/SD/eMMC controllers (ARM PL180 controller / BeagleBoard /
PandaBoard / Exynos / a eMMC controller) and it seems to w
On 01/09/14 01:44, Jordan Justen wrote:
> The Xen and QEMU/KVM paths were calling this at nearly
> the same time in the boot flow anyhow, so just make
> the call in one spot.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen
> ---
> OvmfPkg/PlatformPei/Me
On 01/09/14 01:44, Jordan Justen wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen
> ---
> OvmfPkg/PlatformPei/Platform.c | 10 +--
> OvmfPkg/PlatformPei/Platform.h | 188
> +
> 2 files changed, 100 insertions
On 01/09/14 01:44, Jordan Justen wrote:
> From: Laszlo Ersek
>
> Data is transferred between S3 Suspend and S3 Resume as follows:
>
> [...]
>
> [jordan.l.jus...@intel.com: move code into BootModeInitialization]
Reviewed-by: Laszlo Ersek
--
On 01/09/14 01:44, Jordan Justen wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen
> ---
> OvmfPkg/PlatformPei/Platform.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/Platform
comments below
On 01/09/14 01:44, Jordan Justen wrote:
> By splitting the PEI and DXE phases into separate FVs,
> we can only reserve the PEI FV for ACPI S3 support.
> This should save about 7MB.
>
> Unfortunately, this all has to happen in a single commit.
>
> DEC:
> * Remove PcdOvmfMemFv(Base|
On 01/09/14 01:44, Jordan Justen wrote:
> This allow you to search for an 'instance' of a section
> within a series of FFS sections.
>
> For example, we will split the MAINFV into a PEI and DXE
> FV, and then compress those two FV's together within a
> FFS FV file. The DXE FV will appear as the se
Dear everyone,
I will post for the first time.
I want to make an UEFI Application to set a wakeup time and boot the Mac.
To set a wakeup time, I wrote the following code.
But the error does not occur when application is running, but did not wakeup.
Will I have the use of the API that wrong?
Hi, Oliver:
I have a question abourt ARMv8 CPU's bootloader.
ARMv8 supports: AARCH32 / AARCH64
Take an example:
An ARMv8 SOC, when power up / reset, its default state is : AARCH32
Then, could i still run an old arm uefi bootloader which written by
ARMv7 instruction set?
I will switch ARMv8 SOC to A
Andrew:
I provide my patch based on option 2. Could you help review them?
Thanks
Liming
From: Gao, Liming [mailto:liming@intel.com]
Sent: Thursday, January 09, 2014 4:48 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Adding TempRam support to PeiServicesTablePointerLibIdt
cause
Andrew:
Thanks for your comments. I agree that the Library Class definition does not
define this behavior. I think your option 2 is a clean way. It requires to
update all PeiServicesTablePointerLib instances although most implementation is
an empty function. Now, I know four library PeiService
34 matches
Mail list logo
