On Sat, 12 Jul, at 02:34:26PM, Michael Brown wrote:
On 12/07/14 01:31, H. Peter Anvin wrote:
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -154,7 +154,7 @@ extra_header_fields:
#else
.quad 0 # ImageBase
#endif
- .long 0x20
On Mon, 14 Jul, at 01:08:32PM, Matt Fleming wrote:
On Sat, 12 Jul, at 02:34:26PM, Michael Brown wrote:
On 12/07/14 01:31, H. Peter Anvin wrote:
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -154,7 +154,7 @@ extra_header_fields:
#else
.quad 0
On Fri, 11 Jul, at 04:16:30PM, Michael Brown wrote:
Since the patch itself is so trivial, I'm happy for you to commit it
as your own, with whatever commit message you think makes most
sense.
I was thinking something along these lines,
---
From 997cea56672faf5521cd5718281b99d4e6afdb2d Mon
On 14/07/14 14:10, Matt Fleming wrote:
On Fri, 11 Jul, at 04:16:30PM, Michael Brown wrote:
The EFI boot stub goes to great pains to relocate the kernel image to
an appropriately aligned address, as indicated by the -kernel_alignment
field in the bzImage header. However, for the PE stub entry
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 aborting. We may lose a bit of memory at the low end, but we can
still proceed normally otherwise.
Signed-off-by: Ard Biesheuvel
On 14 July 2014 17:25, Ard Biesheuvel ard.biesheu...@linaro.org 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 aborting. We may lose a bit of memory at the low end,
This is a followup on the RFC series I sent a week ago that changes the EFI
stub Image loader to stop using linker arithmetic and build time defines and
use data obtained at runtime instead.
This series is now rebased on top of Catalin's arm64 for-next/core branch, which
contains a relevant set
In order to be able to interpret the Image header from C code, we need a
struct definition that reflects the specification for Image headers as laid
out in Documentation/arm64/booting.txt.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/image_hdr.h | 75
The EFI stub for arm64 needs to behave like an ordinary bootloader in the sense
that it needs to use the EFI environment and the Image header at runtime and
not rely on the linker or preprocessor to produce values for text offset,
image size and kernel size. This patch also fixes the corner case
Hi Ard,
On Mon, Jul 14, 2014 at 05:17:51PM +0100, Ard Biesheuvel wrote:
The EFI stub for arm64 needs to behave like an ordinary bootloader in the
sense
that it needs to use the EFI environment and the Image header at runtime and
not rely on the linker or preprocessor to produce values for
Hi Ard,
On Mon, Jul 14, 2014 at 05:17:50PM +0100, Ard Biesheuvel wrote:
In order to be able to interpret the Image header from C code, we need a
struct definition that reflects the specification for Image headers as laid
out in Documentation/arm64/booting.txt.
Signed-off-by: Ard Biesheuvel
On 14 July 2014 18:58, Mark Rutland mark.rutl...@arm.com wrote:
Hi Ard,
On Mon, Jul 14, 2014 at 05:17:50PM +0100, Ard Biesheuvel wrote:
In order to be able to interpret the Image header from C code, we need a
struct definition that reflects the specification for Image headers as laid
out in
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 needs to behave like an ordinary bootloader in the
sense
that it needs to use the EFI environment and the Image header at runtime
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 needs to behave like an ordinary bootloader in the
sense
that
14 matches
Mail list logo
