David,
I have checked in the update at edk2 17130 and 17131. I look forward to
your 2nd part of update to support HiPermanentMemoryAddress/
HiPermanentMemorySize.
Regards
Elvin Li
-Original Message-
From: Li, Elvin [mailto:elvin...@intel.com]
Sent: Saturday, April 04, 2015 8:52
Yes. I have sent the patch to clean up OvmfPkg, Nt32Pkg and DuetPkg.
Thanks
Liming
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Tuesday, April 07, 2015 6:36 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Lzma GUID patch breaks OVMF build
The
Looks good.
Reviewed-by: Maurice Ma
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Tuesday, April 07, 2015 12:39 PM
To: Ma, Maurice; edk2-devel@lists.sourceforge.net; Agyeman, Prince
Subject: RE: [Patch 4/16] CorebootModulePkg: Change CbParseAcpiTable prototype
On 2015-04-07 12:42:29, Scott Duplichan wrote:
> CorebootModulePkg: Add 'ULL' suffix to avoid gcc 4.4 compile fail
>
> Add ULL siffix to 64-bit constants, otherwise gcc44 reports error:
> integer constant is too large for 'long' type
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> S
On 2015-04-07 12:49:12, Scott Duplichan wrote:
> CorebootModulePkg/CbSupportDxe: Add EFIAPI to CbDxeEntryPoint
>
> All image entry point functions must use EFIAPI.
>
> Some GCC toolchains will have a build error without this fix.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Sign
> On Apr 7, 2015, at 1:46 PM, Carsey, Jaben wrote:
>
> I think you’re right that there is no ideal event for your purpose.
>
> I don’t know what the guaranteed behavior is for BDS and DRIVER
> variables. What about using BOOT variables to launch your app? This
> would also mean you
I think you're right that there is no ideal event for your purpose.
I don't know what the guaranteed behavior is for BDS and DRIVER variables.
What about using BOOT variables to launch your app? This would also mean
you're running at TPL_APPLICATION.
From: Olivier Martin [mailto:olivi
17129
Reviewed-by: Jaben Carsey
From: Shah, Tapan [mailto:tapands...@hp.com]
Sent: Tuesday, April 07, 2015 12:10 PM
To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: fix mv and cp command related issues
Importance: High
Jaben,
Can you review the attached diff file with f
Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote:
]Sent: Monday, April 06, 2015 02:21 AM
]To: Scott Duplichan; edk2-devel@lists.sourceforge.net; 'Maurice Ma'; 'Prince
Agyeman'
]Subject: Re: [edk2] [Patch 16/16] CorebootModulePkg: Add EFIAPI to
CbDxeEntryPoint to fix gcc compile fail
]
]On
Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote:
]Sent: Tuesday, April 07, 2015 01:22 PM
]To: edk2-devel@lists.sourceforge.net; Scott Duplichan;
edk2-devel@lists.sourceforge.net; 'Maurice Ma'; ]'Prince Agyeman'
]Subject: Re: [edk2] [Patch 5/16] CorebootModulePkg: Add 'll' suffix to avoid
Ma, Maurice [mailto:maurice...@intel.com] wrote:
]Sent: Tuesday, April 07, 2015 12:40 PM
]To: Scott Duplichan; edk2-devel@lists.sourceforge.net; Agyeman, Prince
]Subject: RE: [Patch 4/16] CorebootModulePkg: Change CbParseAcpiTable prototype
to avoid gcc fail
]
]Hi, Scott,
]
]Can we change the "
Jaben,
Can you review the attached diff file with following changes?
Thanks,
Tapan
ShellPkg: fix mv and cp command related issues
1. mv deletes file/directory when trying to move it to non-existing file
system.
2. mv causes RSOD in system when tr
On 4/7/2015 12:34 PM, Jordan Justen wrote:
> On 2015-04-07 11:18:35, Bruce Cran wrote:
>> Have you tried SourceTree (http://www.sourcetreeapp.com/)
>
> Can it properly reproduce 'git format-patch' and 'git send-email'?
It doesn't seem to have those features -- at the moment it just creates
plain
On 2015-04-07 11:18:35, Bruce Cran wrote:
> On 4/6/2015 7:06 AM, Scott Duplichan wrote:
> > Well maybe so. I did use git during some recent coreboot work. But at this
> > point in time, SVN seems to still have a better Windows GUI than git.
>
> Have you tried SourceTree (http://www.sourcetreeapp.c
On 2015-04-05 21:19:56, Scott Duplichan wrote:
> Add ll siffix to 64-bit constants, otherwise gcc44 reports error:
> integer constant is too large for 'long' type
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Scott Duplichan
> ---
>
> Index: CorebootModulePkg/CbSup
The network stack is guarantee to be loaded (but not started) before my ideal
event (which is before the EFI OS Loader is started).
The EFI OS Loader is likely to be loaded from the EFI System partition that
might not have any link with the network stack.
And ideally I would like this ideal even
On 4/6/2015 7:06 AM, Scott Duplichan wrote:
> Well maybe so. I did use git during some recent coreboot work. But at this
> point in time, SVN seems to still have a better Windows GUI than git.
Have you tried SourceTree (http://www.sourcetreeapp.com/) or TortoiseGit
(https://code.google.com/p/tor
On 4/5/2015 10:19 PM, Scott Duplichan wrote:
> Add ll siffix to 64-bit constants, otherwise gcc44 reports error:
> integer constant is too large for 'long' type
> [...]
> -(EFI_PHYSICAL_ADDRESS)(0x1),
> +(EFI_PHYSICAL_ADDRESS)(0x1ll),
I wonder if upper-case 'L' would be bet
Is the network stack guaranteed to be installed before your ideal event or are
you doing the install of it?
-Jaben
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Tuesday, April 07, 2015 10:31 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Downloading a file from the network
The patch looks good to me.
Reviewed-by: Maurice Ma
Thanks
Maurice
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Sunday, April 05, 2015 9:20 PM
To: edk2-devel@lists.sourceforge.net; Ma, Maurice; Agyeman, Prince
Subject: [Patch 5/16] CorebootModulePkg: Add '
The patch looks good to me.
Reviewed-by: Maurice Ma
Thanks
Maurice
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Sunday, April 05, 2015 9:22 PM
To: edk2-devel@lists.sourceforge.net; Ma, Maurice; Agyeman, Prince
Subject: [Patch 7/16] CorebootPayloadPkg: Use
The patch looks good to me.
Reviewed-by: Maurice Ma
Thanks
Maurice
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Sunday, April 05, 2015 9:21 PM
To: edk2-devel@lists.sourceforge.net; Ma, Maurice; Agyeman, Prince
Subject: [Patch 6/16] CorebootModulePkg: Refor
Hi, Scott,
Can we change the " void **" to "VOID **" in this patch ?
Reviewed-by: Maurice Ma
Thanks
Maurice
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Sunday, April 05, 2015 9:19 PM
To: edk2-devel@lists.sourceforge.net; Ma, Maurice; Agyeman, Prince
Subj
The patch looks good to me.
Reviewed-by: Maurice Ma
Thanks
Maurice
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Sunday, April 05, 2015 9:17 PM
To: edk2-devel@lists.sourceforge.net; Ma, Maurice; Agyeman, Prince
Subject: [Patch 3/16] CorebootModulePkg: Remov
The patch looks good to me.
Reviewed-by: Maurice Ma
Thanks
Maurice
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Sunday, April 05, 2015 9:15 PM
To: edk2-devel@lists.sourceforge.net; Ma, Maurice; Agyeman, Prince
Subject: [Patch 2/16] CorebootModulePkg: Fix b
Hello,
I am trying to solve a TPL issue...
Use Case: Download ACPI tables (actually it is the Device Tree but the
principle is the same) from the network before BDS is started for enabling
developers to work on his ACPI/FDT tables on his host machine. The path of the
file is defined by a UEFI D
On Tue, 7 Apr 2015, Laszlo Ersek wrote:
> This is a known iPXE problem that has manifested in various forms.
Thanks, I've managed to find that too (replied to my own message with
that).
> In summary, please ask Gerd to rebuild the ipxe binaries that are
> bundled with upstream qemu such that the
On 04/07/15 16:16, Ard Biesheuvel wrote:
> On 7 April 2015 at 16:11, Laszlo Ersek wrote:
>> On 04/07/15 15:14, Ard Biesheuvel wrote:
>>
>>> If we start using the MemoryInitPeiLib under ArmVirtualizationPkg for
>>> QEMU (which was intended by this patch),
>>
>> Currently there is no executable modu
On 03/31/15 20:14, Jordan Justen wrote:
> In 1/2, it seems like the typo came from the Shell spec 2.0, but it
> was fixed in 2.1.
>
> My one minor comment is that in 2/2 it could have been
> IsStringOfHexBytes, and trivially verified an even number of
> characters without the extra StrLen call lat
On 7 April 2015 at 16:11, Laszlo Ersek wrote:
> On 04/07/15 15:14, Ard Biesheuvel wrote:
>
>> If we start using the MemoryInitPeiLib under ArmVirtualizationPkg for
>> QEMU (which was intended by this patch),
>
> Currently there is no executable module in the QEMU build that depends
> on this libra
On 04/07/15 15:14, Ard Biesheuvel wrote:
> If we start using the MemoryInitPeiLib under ArmVirtualizationPkg for
> QEMU (which was intended by this patch),
Currently there is no executable module in the QEMU build that depends
on this library class.
> then there is no need IMO to
> introduce a f
Adding back Michael (author of the syslinux list message that you
reference below). Also adding Gerd.
On 04/06/15 21:23, BALATON Zoltan wrote:
> Hello,
>
> I'm trying to find out why pxe boot with syslinux is failing on QEMU with
> OVMF.
> The problem is already described here in detail:
>
> h
Meanwhile I've found this thread:
http://sourceforge.net/p/edk2/mailman/message/33236100/
which shows this is probably not a bug but an iPXE "feature". The
efi-e1000.rom attached to the last message in that thread seems to work
better and allows syslinux to get further.
Regards,
BALATON Zoltan
On 04/06/15 09:06, Jordan Justen wrote:
> Wow. By the looks of this, you somehow managed to create and send all
> these patches with svn. I applaud your effort, but I hope you consider
> looking into git for future work to save yourself time. :)
>
> One request I have is to make patch 1 throgh 16
On 7 April 2015 at 14:59, Laszlo Ersek wrote:
> Hi Ard,
>
> first of all, sorry about the delayed review.
>
> So, this patch seems to be the only one in the series (according to both
> the blurb and the per-patch file lists) that modifies the QEMU build.
>
> However, I think this patch has no effe
On 04/01/15 16:46, Kinney, Michael D wrote:
> Oliver,
>
> What is the test case that fails? It is passing in a constant or a
> variable as the first parameter to the macro. If it is a variable, I am
> guessing that the type is smaller than UINT32?
>
> It makes sense that the left shift 31 bits
Hi Ard,
first of all, sorry about the delayed review.
So, this patch seems to be the only one in the series (according to both
the blurb and the per-patch file lists) that modifies the QEMU build.
However, I think this patch has no effect. (Or, more politely put, I
don't know how it is supposed
There were some recent patches about moving LZME from IntelFrameworkModulePkg
to MdeModulePkg.
I was expected them to break few platforms (including ARM platforms).
OvmfPkg (and ARM platforms) should be updated to pick LZMA from MdeModulePkg.
-Original Message-
From: Gabriel L. Somlo [ma
38 matches
Mail list logo
