2012-11-02 19:27:55 +01:00
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
#
|
2013-01-16 07:50:08 +01:00
|
|
|
# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
|
2012-11-02 19:27:55 +01:00
|
|
|
#
|
|
|
|
# This program and the accompanying materials
|
|
|
|
# are licensed and made available under the terms and conditions of the BSD License
|
|
|
|
# which accompanies this distribution. The full text of the license may be found at
|
|
|
|
# http://opensource.org/licenses/bsd-license.php.
|
|
|
|
#
|
|
|
|
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
|
|
|
|
#
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
ASM_GLOBAL ASM_PFX(JumpToKernel)
|
2013-02-14 20:21:39 +01:00
|
|
|
ASM_GLOBAL ASM_PFX(JumpToUefiKernel)
|
2012-11-02 19:27:55 +01:00
|
|
|
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# VOID
|
|
|
|
# EFIAPI
|
|
|
|
# JumpToKernel (
|
|
|
|
# VOID *KernelStart, // %rcx
|
|
|
|
# VOID *KernelBootParams // %rdx
|
|
|
|
# );
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
ASM_PFX(JumpToKernel):
|
OvmfPkg: LoadLinuxLib: Fix kernel entry for 64-bit OVMF
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-14 04:10:57 +01:00
|
|
|
|
|
|
|
// Set up for executing kernel. BP in %esi, entry point on the stack
|
|
|
|
// (64-bit when the 'ret' will use it as 32-bit, but we're little-endian)
|
2012-11-02 19:27:55 +01:00
|
|
|
movq %rdx, %rsi
|
OvmfPkg: LoadLinuxLib: Fix kernel entry for 64-bit OVMF
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-14 04:10:57 +01:00
|
|
|
pushq %rcx
|
|
|
|
|
|
|
|
// Jump into the compatibility mode CS
|
|
|
|
pushq $0x10
|
2013-01-16 07:50:35 +01:00
|
|
|
leaq 1f(%rip), %rax
|
OvmfPkg: LoadLinuxLib: Fix kernel entry for 64-bit OVMF
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-14 04:10:57 +01:00
|
|
|
pushq %rax
|
2013-01-23 01:21:57 +01:00
|
|
|
.byte 0x48, 0xcb // retfq
|
OvmfPkg: LoadLinuxLib: Fix kernel entry for 64-bit OVMF
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-14 04:10:57 +01:00
|
|
|
|
|
|
|
1: // Now in compatibility mode
|
|
|
|
.code32
|
|
|
|
movl $0x18, %eax
|
|
|
|
movl %eax, %ds
|
|
|
|
movl %eax, %es
|
|
|
|
movl %eax, %fs
|
|
|
|
movl %eax, %gs
|
|
|
|
movl %eax, %ss
|
|
|
|
|
|
|
|
// Disable paging
|
|
|
|
movl %cr0, %eax
|
|
|
|
btcl $31, %eax
|
|
|
|
movl %eax, %cr0
|
|
|
|
|
|
|
|
// Disable long mode in EFER
|
|
|
|
movl $0x0c0000080, %ecx
|
|
|
|
rdmsr
|
|
|
|
btcl $8, %eax
|
|
|
|
wrmsr
|
|
|
|
|
|
|
|
// Disable PAE
|
|
|
|
movl %cr4, %eax
|
|
|
|
btcl $5, %eax
|
|
|
|
movl %eax, %cr4
|
|
|
|
|
|
|
|
// Zero registers and 'return' to kernel
|
|
|
|
xorl %ebp, %ebp
|
|
|
|
xorl %edi, %edi
|
|
|
|
xorl %ebx, %ebx
|
2012-11-02 19:27:55 +01:00
|
|
|
ret
|
OvmfPkg: LoadLinuxLib: Fix kernel entry for 64-bit OVMF
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-14 04:10:57 +01:00
|
|
|
.code64
|
2012-11-02 19:27:55 +01:00
|
|
|
|
2013-02-14 20:21:39 +01:00
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# VOID
|
|
|
|
# EFIAPI
|
|
|
|
# JumpToUefiKernel (
|
|
|
|
# EFI_HANDLE ImageHandle, // rcx
|
|
|
|
# EFI_SYSTEM_TABLE *SystemTable, // rdx
|
|
|
|
# VOID *KernelBootParams, // r8
|
|
|
|
# VOID *KernelStart // r9
|
|
|
|
# );
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
ASM_PFX(JumpToUefiKernel):
|
|
|
|
movq %rcx, %rdi
|
|
|
|
movq %rdx, %rsi
|
|
|
|
movq %r8, %rdx
|
|
|
|
xor %rax, %rax
|
|
|
|
movl 0x264(%r8), %eax
|
|
|
|
addq %rax, %r9
|
|
|
|
addq $0x200, %r9
|
|
|
|
callq %r9
|
|
|
|
ret
|
|
|
|
|