On Mon, May 19, 2014 at 7:00 PM, Fan, Jeff wrote:
> X64 Exception Type - 000E means Page Fault exception
> RIP - 06BA58DE means in
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.
> (ImageBase=06B9F000)
> CR2 - F
X64 Exception Type - 000E means Page Fault exception
RIP - 06BA58DE means in
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.
(ImageBase=06B9F000)
CR2 - FFF0 means Page F
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
BaseTools/Conf/build_rule.template | 19 ++-
BaseTools/Conf/tools_def.template | 8 +++-
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Conf/build_rule.templat
The first patch obviously needs to be made to edk2-buildtools/BaseTools
first, and then sync'd to EDK II.
The first 6 patches change OVMF to build VTF0 during the EDK II
build process by running NASM.
The UefiCpuPkg VTF0 patches are not ready yet, since the X64 page
tables are not being built. (T
This implements the old VTF ResetVector code often used on EDK II
IA32 & X64 platforms.
The BaseTools GenFv tool has code that patches the jump target of
the reset vector code to match the entry point of the SEC image in
the PEI Firmware Volume.
Contributed-under: TianoCore Contribution Agreement
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
.../Vtf0/Bin/ResetVector.ia32.port80.raw | Bin 516 -> 0 bytes
.../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 0 bytes
.../Vtf0/Bin/ResetVector.ia32.serial.raw | Bin 884 -
Using NASM we build VTF0 as part of the EDK II build process.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
UefiCpuPkg/ResetVector/Vtf0/Vtf0.inf | 36 ++
UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmbin | 53 +
Using NASM we build OVMF's ResetVector as part of the EDK II build
process.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
OvmfPkg/ResetVector/ResetVector.inf | 37 +++
OvmfPkg/ResetVector/ResetVector.nasmbin | 53
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
OvmfPkg/ResetVector/Bin/ResetVector.inf | 29
OvmfPkg/ResetVector/Bin/ResetVector.x64.raw | Bin 628 -> 0 bytes
OvmfPkg/ResetVector/Build.py| 58
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
OvmfPkg/OvmfPkgIa32.dsc| 2 ++
OvmfPkg/OvmfPkgIa32.fdf| 6 +++---
OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
OvmfPkg/OvmfPkgIa32X64.fdf | 6 +++---
OvmfPkg/OvmfPkgX64.dsc | 2 ++
OvmfPkg/OvmfPkgX64.fdf
Thank you so much Andrew.
Regards,
On Fri, May 16, 2014 at 12:03 PM, Andrew Fish wrote:
>
> On May 16, 2014, at 6:56 AM, André Dantas
> wrote:
>
> Anybody can help me?
>
>
> On Tue, May 13, 2014 at 5:05 PM, André Dantas wrote:
>
>> Hi guys,
>>
>> I'm working with the mkramdisk.efi application
Hello all,
I have a UEFI Application (that I built using GNU-EFI) that does not produce
any entry in the handle database, it only consumes protocols and services.
Right now I am loading this UEFI Application through the UEFI Shell but I want
this application to run on every boot.
Is there any
On Fri, May 16, 2014 at 03:21:26PM -0700, Jordan Justen wrote:
> On Thu, May 15, 2014 at 4:30 AM, Wei Liu wrote:
> > On Wed, May 14, 2014 at 12:34:14PM -0400, Gabriel L. Somlo wrote:
> >> On Wed, May 14, 2014 at 02:55:15PM +0100, Wei Liu wrote:
> >> > On Wed, May 14, 2014 at 03:31:48PM +0200, Lasz
On 05/19/14 10:33, Ludovic Rousseau wrote:
> My debug1.c code is now:
> #include
> #include
>
> EFI_STATUS
> efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
> {
> InitializeLib(ImageHandle, SystemTable);
>
> Print(L"a\n");
> DEBUG(( D_INFO, (CHAR8 *)"D_INFO\r\n"));
2014-05-16 20:37 GMT+02:00 Laszlo Ersek :
> 2. The error is in Ludovic's program; I can reproduce it and also fix
> it. Quote:
>
> EFI_STATUS
> EFIAPI
> efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
> {
> ...
>
> The problem is "EFIAPI". You *must not* add EFIAPI to efi_main() *i
15 matches
Mail list logo
