On 14 July 2014 20:29, Mark Rutland mark.rutl...@arm.com wrote:
On Mon, Jul 14, 2014 at 06:35:32PM +0100, Ard Biesheuvel wrote:
On 14 July 2014 18:54, Mark Rutland mark.rutl...@arm.com wrote:
Hi Ard,
On Mon, Jul 14, 2014 at 05:17:51PM +0100, Ard Biesheuvel wrote:
The EFI stub for arm64
After the EFI stub has done its business, it jumps into the kernel by branching
to offset #0 of the loaded Image, which is where it expects to find the header
containing a 'branch to stext' instruction.
However, the header is not covered by any PE/COFF section, so the header may
not actually be
Hi Ard,
On Tue, Jul 15, 2014 at 10:10:02AM +0100, Ard Biesheuvel wrote:
After the EFI stub has done its business, it jumps into the kernel by
branching
to offset #0 of the loaded Image, which is where it expects to find the header
containing a 'branch to stext' instruction.
However, the
On Mon, Jul 14, 2014 at 02:40:48PM -0400, Mark Salter wrote:
On Mon, 2014-07-14 at 17:25 +0200, Ard Biesheuvel wrote:
If we fail to relocate the kernel Image to its preferred offset of
TEXT_OFFSET
bytes above the base of DRAM, accept the lowest alternative mapping
available
instead of
After the EFI stub has done its business, it jumps into the kernel by branching
to offset #0 of the loaded Image, which is where it expects to find the header
containing a 'branch to stext' instruction.
However, the header is not covered by any PE/COFF section, so the header may
not actually be
The static memory footprint of a kernel Image at boot is larger than the
Image file itself. Things like .bss data and initial page tables are allocated
statically but populated dynamically so their content is not contained in the
Image file.
However, if EFI has loaded the Image at precisely the
On Mon, Jul 14, 2014 at 07:40:48PM +0100, Mark Salter wrote:
On Mon, 2014-07-14 at 17:25 +0200, Ard Biesheuvel wrote:
If we fail to relocate the kernel Image to its preferred offset of
TEXT_OFFSET
bytes above the base of DRAM, accept the lowest alternative mapping
available
instead of
On Tue, Jul 15, 2014 at 11:02:22AM +0100, Leif Lindholm wrote:
On Mon, Jul 14, 2014 at 02:40:48PM -0400, Mark Salter wrote:
On Mon, 2014-07-14 at 17:25 +0200, Ard Biesheuvel wrote:
If we fail to relocate the kernel Image to its preferred offset of
TEXT_OFFSET
bytes above the base of
On 15 July 2014 13:31, Mark Rutland mark.rutl...@arm.com wrote:
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 619b1dd7bcde..6ef541731d9e 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -61,7 +61,7 @@
On Tue, Jul 15, 2014 at 12:49:07PM +0100, Ard Biesheuvel wrote:
On 15 July 2014 13:31, Mark Rutland mark.rutl...@arm.com wrote:
diff --git a/arch/arm64/kernel/efi-entry.S
b/arch/arm64/kernel/efi-entry.S
index 619b1dd7bcde..6ef541731d9e 100644
--- a/arch/arm64/kernel/efi-entry.S
On Tue, 2014-07-15 at 11:02 +0100, Leif Lindholm wrote:
@@ -273,6 +282,10 @@ static void __init free_boot_services(void)
continue;
}
+ /* Don't free anything below kernel */
+ if (md-phys_addr PHYS_OFFSET)
+
On Tue, Jul 15, 2014 at 09:11:00AM -0400, Mark Salter wrote:
On Tue, 2014-07-15 at 11:02 +0100, Leif Lindholm wrote:
@@ -273,6 +282,10 @@ static void __init free_boot_services(void)
continue;
}
+ /* Don't free anything below kernel
On Tue, 2014-07-15 at 14:54 +0100, Leif Lindholm wrote:
On Tue, Jul 15, 2014 at 09:11:00AM -0400, Mark Salter wrote:
On Tue, 2014-07-15 at 11:02 +0100, Leif Lindholm wrote:
@@ -273,6 +282,10 @@ static void __init free_boot_services(void)
continue;
On Tue, Jul 15, 2014 at 03:23:26PM +0100, Mark Salter wrote:
On Tue, 2014-07-15 at 14:54 +0100, Leif Lindholm wrote:
On Tue, Jul 15, 2014 at 09:11:00AM -0400, Mark Salter wrote:
On Tue, 2014-07-15 at 11:02 +0100, Leif Lindholm wrote:
@@ -273,6 +282,10 @@ static void __init
On 07/15/2014 08:10 AM, Matt Fleming wrote:
Going forward, I suspect any attempts to use the EFI File Protocol are
going to result in this kind of breakage, and that the only thing that
can be relied upon is the Disk I/O Protocol.
Do we know what the Windows bootloader does? I thought it
The EFI loader may load Image at any available offset. This means Image may
reside very close to or at the base of DRAM, in which case the relocation
done by efi_entry() results in Image being moved up in memory, which is
undesirable (memory below the kernel is currently not usable).
To work
16 matches
Mail list logo
