On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote:
This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
operates similarly to the x86 stub: it is a shim between the EFI firmware
and the normal zImage entry point, and sets up the environment that the
zImage is
On 15 January 2014 03:16, Roy Franz roy.fr...@linaro.org wrote:
On Tue, Jan 14, 2014 at 5:47 PM, Roy Franz roy.fr...@linaro.org wrote:
On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote:
This patch
On 5 February 2014 18:04, Leif Lindholm leif.lindh...@linaro.org wrote:
From: Ard Biesheuvel ard.biesheu...@linaro.org
Loading unauthenticated FDT blobs directly from storage is a security hazard,
so this should only be allowed when running with UEFI Secure Boot disabled.
Signed-off-by: Ard
On 23 May 2014 17:45, Leif Lindholm leif.lindh...@linaro.org wrote:
On Fri, May 23, 2014 at 05:17:39PM +0200, Ard Biesheuvel wrote:
Can we add another of detecting whether it's an EFI application and
avoid calling efi_init()? I can see x86 sets some efi_loader_signature
string
This moves definitions depended upon both by code under arch/x86/boot and
under drivers/firmware/efi to asm/efi.h. This is in preparation of turning
the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/boot
which were formerly relying on the #includor to
include the correct header files
- remove all static modifiers from functions which will need to be externally
visible once we move to a static library
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi-stub.c
On 16 June 2014 17:14, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
This patch changes both x86 and arm64 efistub implementations from #including
shared .c files under drivers/firmware/efi to building the shared code as a
static library.
The x86 code uses a stub built into the boot
On 18 June 2014 11:02, Matt Fleming m...@console-pimps.org wrote:
On Fri, 13 Jun, at 04:54:59PM, Ard Biesheuvel wrote:
Fix two instances of pointer type errors, a harmless one where a const void*
value is assigned to a non-const void* variable, and a not-so-harmless one
where
we pass
On 18 June 2014 10:50, Matt Fleming m...@console-pimps.org wrote:
On Fri, 13 Jun, at 01:11:51PM, Ard Biesheuvel wrote:
The shared efistub code for ARM and arm64 contains a local copy of
linux_banner,
allowing it to be referenced from separate executables such as the ARM
decompressor. However
On 18 June 2014 11:28, Matt Fleming m...@console-pimps.org wrote:
On Wed, 18 Jun, at 11:06:09AM, Ard Biesheuvel wrote:
You say potato, I say po-tah-to?
But seriously, whichever you prefer ...
$ git grep const void | wc -l
4441
$ git grep void const | wc -l
50
I say potato, you say
In order for other archs (such as arm64) to be able to reuse the virtual mode
function call wrappers, move them to drivers/firmware/efi/runtime.c.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/platform/efi/efi.c| 144 +--
drivers
UEFI Runtime Services function calls may clobber the contents of the NEON
register file, so we need to make sure that we preserve/restore them when
performing such a function call.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/efi.h | 21
, and
adding kernel_neon_begin()/kernel_neon_end() pairs to the wrappers.
The first patch moves the existing x86 versions of those wrappers to generic
code, so that the second patch can easily enable them by supplying a definition
for efi_call_virt and adding a call to efi_native_runtime_setup().
Ard
On 23 June 2014 16:18, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
The current UEFI implementation for arm64 fails to preserve/restore the
contents
of the NEON register file, which may result in data corruption, especially now
that those contents are lazily restored for user processes
Hey Matt,
On 25 jun. 2014, at 22:34, Matt Fleming m...@console-pimps.org wrote:
On Mon, 16 Jun, at 05:14:48PM, Ard Biesheuvel wrote:
This patch changes both x86 and arm64 efistub implementations from #including
shared .c files under drivers/firmware/efi to building the shared code
On 25 June 2014 23:53, kbuild test robot fengguang...@intel.com wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git next
head: 8922cc07b558b167bc8f9e176c1a0b49acc5694f
commit: 012e96bf2f05b3652ef02cf3df80b7a63cced0af [6/7] efi/x86: move UEFI
Runtime Services
Runtime Services called by the kernel, so make sure
the FP/SIMD register file is preserved in this case.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/efi.h | 21 +
arch/arm64/kernel/efi.c | 14
In order for other archs (such as arm64) to be able to reuse the virtual mode
function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/Kconfig| 1 +
arch/x86/platform/efi/efi.c
UEFI/AAPCS spec sections
Ard Biesheuvel (2):
efi/x86: move UEFI Runtime Services wrappers to generic code
efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/efi.h| 21 +
arch/arm64/kernel
On 26 June 2014 15:58, Mark Salter msal...@redhat.com wrote:
On Thu, 2014-06-26 at 12:09 +0200, Ard Biesheuvel wrote:
The current UEFI implementation for arm64 fails to preserve/restore the
contents
of the NEON register file,
Does the current implementation actually use NEON registers?
I
This moves definitions depended upon both by code under arch/x86/boot and
under drivers/firmware/efi to asm/efi.h. This is in preparation of turning
the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/boot
As EFI_ERROR is not a UEFI result code but a local invention only intended to
allow get_dram_base() to signal failure, we should not use it elsewhere.
Replace with EFI_LOAD_ERROR.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi-stub.c | 2 +-
1 file changed, 1
This moves definitions depended upon both by code under arch/arm64/boot and
under drivers/firmware/efi to asm/efi.h. This is in preparation of turning
the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include
which were formerly relying on the #includor to
include the correct header files
- remove all static modifiers from functions which will need to be externally
visible once we move to a static library
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi-stub.c
be returned by get_dram_base() and efi_entry()
- added a section to libstub Makefile to clean CFLAGS of stack protecter and
other options that are inappropriate for the stub
- rebased onto the UEFI Runtime Services NEON patches (re)posted earlier today
Ard Biesheuvel (5):
efi/arm64: avoid
is linked into the decompressor.
In the arm64 case, the stub is part of the kernel proper so the library is
linked into the kernel proper as well.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile
On 1 July 2014 15:30, Matt Fleming m...@console-pimps.org wrote:
On Thu, 26 Jun, at 12:09:05PM, Ard Biesheuvel wrote:
In order for other archs (such as arm64) to be able to reuse the virtual mode
function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c.
Signed-off-by: Ard
On 1 July 2014 15:26, Matt Fleming m...@console-pimps.org wrote:
On Thu, 26 Jun, at 12:09:04PM, Ard Biesheuvel wrote:
The current UEFI implementation for arm64 fails to preserve/restore the
contents
of the NEON register file, which may result in data corruption, especially
now
that those
On 1 July 2014 17:11, Matt Fleming m...@console-pimps.org wrote:
On Thu, 26 Jun, at 04:23:36PM, Ard Biesheuvel wrote:
In order to move from the #include ../../../x.c anti-pattern used by
both the x86 and arm64 versions of the stub to a static library linked into
either the kernel proper
According to section 7.1 of the UEFI spec, Runtime Services are not fully
reentrant, and there are particular combinations of calls that need to be
serialized.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
drivers/firmware/efi/runtime-wrappers.c | 109
We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but
then go on an dereference it anyway.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/efi.c
On 2 July 2014 13:15, Matt Fleming m...@console-pimps.org wrote:
On Thu, 26 Jun, at 04:23:37PM, Ard Biesheuvel wrote:
This patch changes both x86 and arm64 efistub implementations from #including
shared .c files under drivers/firmware/efi to building the shared code as a
static library
Would something like this
ifneq ($(CONFIG_EFI_STUB)$(CONFIG_EFI_ARMSTUB),nn)
obj-y += libstub/
endif
be too hideous?
On 2 July 2014 13:23, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 2 July 2014 13:15, Matt Fleming m...@console-pimps.org wrote:
On Thu, 26 Jun, at 04:23:37PM, Ard
which were formerly relying on the #includor to
include the correct header files
- remove all static modifiers from functions which will need to be externally
visible once we move to a static library
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi-stub.c
by get_dram_base() and efi_entry()
- added a section to libstub Makefile to clean CFLAGS of stack protecter and
other options that are inappropriate for the stub
- rebased onto the UEFI Runtime Services NEON patches (re)posted earlier today
Ard Biesheuvel (5):
efi/arm64: Avoid EFI_ERROR as a generic
This moves definitions depended upon both by code under arch/x86/boot
and under drivers/firmware/efi to asm/efi.h. This is in preparation of
turning the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Signed-off-by: Matt Fleming
is linked into the decompressor.
In the arm64 case, the stub is part of the kernel proper so the library is
linked into the kernel proper as well.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig | 5 +
arch/arm64/Makefile
As EFI_ERROR is not a UEFI result code but a local invention only
intended to allow get_dram_base() to signal failure, we should not use
it elsewhere.
Replace with EFI_LOAD_ERROR.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Signed-off-by: Matt Fleming matt.flem...@intel.com
---
arch
On 2 July 2014 14:59, Mark Salter msal...@redhat.com wrote:
On Thu, 2014-06-26 at 16:23 +0200, Ard Biesheuvel wrote:
This moves definitions depended upon both by code under arch/x86/boot and
under drivers/firmware/efi to asm/efi.h. This is in preparation of turning
the stub code under drivers
On 2 July 2014 16:29, Mark Salter msal...@redhat.com wrote:
On Wed, 2014-07-02 at 12:13 +0200, Ard Biesheuvel wrote:
On 2 July 2014 12:10, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL,
but
then go
If we cannot resolve the virtual address of the UEFI System Table, its physical
offset must be missing from the virtual memory map, and there is really no point
in proceeding with installing the virtual memory map and the runtime services
dispatch table. So back out gracefully.
Signed-off-by: Ard
On 4 July 2014 15:38, Catalin Marinas catalin.mari...@arm.com wrote:
On Wed, Jul 02, 2014 at 11:10:01AM +0100, Ard Biesheuvel wrote:
We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but
then go on an dereference it anyway.
Signed-off-by: Ard Biesheuvel ard.biesheu
(adding Catalin)
On 4 July 2014 16:42, Mark Salter msal...@redhat.com wrote:
On Fri, 2014-07-04 at 12:16 +0200, Ard Biesheuvel wrote:
If we cannot resolve the virtual address of the UEFI System Table, its
physical
offset must be missing from the virtual memory map, and there is really
If we cannot resolve the virtual address of the UEFI System Table, its physical
offset must be missing from the virtual memory map, and there is really no point
in proceeding with installing the virtual memory map and the runtime services
dispatch table. So back out gracefully.
Signed-off-by: Ard
On 4 July 2014 17:45, Catalin Marinas catalin.mari...@arm.com wrote:
On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
According to the UEFI spec section 2.3.6.4, the use of FP/SIMD instructions
is
allowed, and should adhere to the AAPCS64 calling convention, which states
On 4 July 2014 18:59, Catalin Marinas catalin.mari...@arm.com wrote:
On Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote:
On 4 July 2014 17:45, Catalin Marinas catalin.mari...@arm.com wrote:
On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
According to the UEFI spec
On 4 July 2014 19:01, Catalin Marinas catalin.mari...@arm.com wrote:
On Fri, Jul 04, 2014 at 05:52:36PM +0100, Mark Salter wrote:
On Fri, 2014-07-04 at 17:25 +0200, Ard Biesheuvel wrote:
If we cannot resolve the virtual address of the UEFI System Table, its
physical
offset must be missing
Runtime Services called by the kernel, so make sure
the FP/SIMD register file is preserved in this case. We do this by enabling the
wrappers for UEFI Runtime Services (CONFIG_EFI_RUNTIME_WRAPPERS) and inserting
calls to kernel_neon_begin() and kernel_neon_end() into these wrappers.
Signed-off-by: Ard
In order for other archs (such as arm64) to be able to reuse the virtual mode
function call wrappers, move them to drivers/firmware/efi/runtime.c.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/Kconfig| 1 +
arch/x86/platform/efi/efi.c
v3:
- improve commit message for patch #2 and add Catalin's ack
v2:
- add Kconfig symbol EFI_RUNTIME_WRAPPERS so we don't break ia64 by enabling it
unconditionally
Ard Biesheuvel (2):
efi/x86: move UEFI Runtime Services wrappers to generic code
efi/arm64: preserve FP/SIMD registers on UEFI
On 7 July 2014 22:43, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 7 July 2014 22:29, Matt Fleming m...@console-pimps.org wrote:
On Wed, 02 Jul, at 12:10:02PM, Ard Biesheuvel wrote:
According to section 7.1 of the UEFI spec, Runtime Services are not fully
reentrant
On 8 July 2014 11:29, Matt Fleming m...@console-pimps.org wrote:
On Tue, 08 Jul, at 10:54:13AM, Ard Biesheuvel wrote:
After doing a bit more research, I still think there is work needed if
we aim to adhere to the UEFI spec, or at least be safe from the
hazards it points out.
Note that I
According to section 7.1 of the UEFI spec, Runtime Services are not fully
reentrant, and there are particular combinations of calls that need to be
serialized.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
So this is v2 of the UEFI Runtime Services serialization patch: this time, I
On 8 July 2014 13:21, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
According to section 7.1 of the UEFI spec, Runtime Services are not fully
reentrant, and there are particular combinations of calls that need to be
serialized.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
v3:
Keep value of in_nmi() cached in local scope to help the compiler understand
that it cannot change while the function is active
v2:
So this is v2 of the UEFI Runtime Services serialization patch: this time, I use
a single spinlock rather than a set
On 9 July 2014 08:40, joeyli j...@suse.com wrote:
On Tue, Jul 08, 2014 at 01:19:42PM +0100, Ben Hutchings wrote:
On Tue, 2014-07-08 at 11:14 +0100, Matt Fleming wrote:
On Tue, 08 Jul, at 11:00:58AM, Lee, Chun-Yi wrote:
[...]
--- a/arch/x86/platform/efi/efi.c
+++
On 11 July 2014 09:52, Matt Fleming m...@console-pimps.org wrote:
On Fri, 11 Jul, at 09:47:23AM, Ard Biesheuvel wrote:
Hi all,
I tested the version that is in Matt's -next now and it works fine on arm64.
Great, thanks Ard. May I add your Tested-by to the patch?
Sure,
Tested-by: Ard
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
at exactly the right offset,
but the allocation is actually too small to satisfy the requirement imposed by
image_size as set in the header.
Ard Biesheuvel (2):
arm64: add C struct definition for Image header
arm64/efi: efistub: get text offset and image size from the Image
header
arch
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
where Image
happens to be loaded at exactly the right offset, but the allocation is
actually too small to satisfy the requirement imposed by image_size as set in
the header.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/Makefile | 2 --
arch/arm64/kernel/efi
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
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 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
be loaded at the expected offset. So instead, jump to 'stext'
directly, which is at the base of the PE/COFF .text section.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi-entry.S | 2 +-
arch/arm64/kernel/head.S | 10 ++
2 files changed, 7 insertions
with a reference to 'stext_offset'
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi-entry.S | 3 ++-
arch/arm64/kernel/head.S | 10 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
by the payload
will be zero initialised by the EFI loader.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/head.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 78ddae28b090
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 @@
mapping has sufficient size, we add 2 megs + TEXT_OFFSET
of padding to the PE/COFF .text section, this should be sufficient to cover
rounding and adding TEXT_OFFSET.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
This was tested on a Foundation Model using the patch below, which forces
On 16 July 2014 16:10, Mark Salter msal...@redhat.com wrote:
On Tue, 2014-07-15 at 18:50 +0200, Ard Biesheuvel wrote:
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
On 16 July 2014 23:03, Mark Salter msal...@redhat.com wrote:
On Wed, 2014-07-16 at 22:38 +0200, Ard Biesheuvel wrote:
On 16 July 2014 21:45, Mark Salter msal...@redhat.com wrote:
On Wed, 2014-07-16 at 16:53 +0100, Mark Rutland wrote:
On Wed, Jul 16, 2014 at 03:51:37PM +0100, Mark Salter
On 7 July 2014 22:38, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 7 July 2014 22:11, Matt Fleming m...@console-pimps.org wrote:
On Sat, 05 Jul, at 08:25:35AM, Catalin Marinas wrote:
OK, I’ll leave it to Matt then together with the other EFI patches
he’s already queuing.
Thanks guys
On 18 July 2014 21:31, Matt Fleming m...@console-pimps.org wrote:
On Fri, 18 Jul, at 08:42:27PM, Ard Biesheuvel wrote:
Hey Matt,
I was wondering if you're on track to queue up your -next branch for 3.17?
If so, could you please include $subject? And if you don't mind, could
you squash
by the payload
will be zero initialised by the EFI loader.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/head.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 5cd1f3491df5
-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/image.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index 8fae0756e175..f5a2f298810d 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64
The Image header contains many constants that should be emitted in little
endian regardless of the endianness of the kernel. Add helper macros le16,
le32 and le64 to asm/assembler.h to aid with this.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/assembler.h
this. There is some trickery
regarding en-/disabling caches and MMU and surely I have gotten something
wrong there.
Ard Biesheuvel (10):
arm64/efi: efistub: jump to 'stext' directly, not through the header
arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text
arm64: add macros to emit
with a reference to 'stext_offset'
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/efi-entry.S | 3 ++-
arch/arm64/kernel/head.S | 10 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
This enables the UEFI Runtime Services needed to manipulate the
non-volatile variable store when running under a BE kernel.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/include/asm/efi.h | 2 +
arch/arm64/kernel/efi-be-call.S| 55
arch
Update the PE/COFF header to use explicit little endian constants and use
explicit little endian linker symbols so that the PE/COFF header is always
emitted in little endian regardless of the endiannes of the kernel.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel
This changes the Kconfig logic to allow EFI to be enabled on a BE kernel build.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Kconfig | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e9d8af2fc389
and string functions. This is accomplished by
building little endian versions of those support files and link them into
a static library which is used by the inner stub build.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/Makefile | 7 +++-
arch
On 17 July 2014 16:09, Mark Salter msal...@redhat.com wrote:
On Wed, 2014-07-16 at 23:13 +0200, Ard Biesheuvel wrote:
On 16 July 2014 23:03, Mark Salter msal...@redhat.com wrote:
On Wed, 2014-07-16 at 22:38 +0200, Ard Biesheuvel wrote:
On 16 July 2014 21:45, Mark Salter msal...@redhat.com
Runtime Services
is that they are used by an installer (through efibootmgr) to program
the kernel command line. Hence the choice for just these services in
the minimal implementation.
--
Ard.
On Mon, Jul 21, 2014 at 04:16:24PM +0100, Ard Biesheuvel wrote:
This enables the UEFI Runtime Services
On 07/23/2014 12:59 PM, Ard Biesheuvel wrote:
On 23 July 2014 11:34, Mark Rutland mark.rutl...@arm.com wrote:
Hi Ard,
This is certainly a neat feature, and I definitely want to be able to
boot BE kernels via UEFI.
Good!
However, I'm wary of calling EFI in a physical (i.e. idmap
On 29 July 2014 17:29, Mark Salter msal...@redhat.com wrote:
On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
If we cannot relocate the kernel Image to its preferred offset of base of
DRAM
plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary
plus
TEXT_OFFSET
On 29 July 2014 20:27, Mark Salter msal...@redhat.com wrote:
On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
On 29 July 2014 17:29, Mark Salter msal...@redhat.com wrote:
On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
If we cannot relocate the kernel Image to its preferred
On 29 July 2014 21:20, Mark Salter msal...@redhat.com wrote:
On Tue, 2014-07-29 at 20:46 +0200, Ard Biesheuvel wrote:
On 29 July 2014 20:27, Mark Salter msal...@redhat.com wrote:
On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
On 29 July 2014 17:29, Mark Salter msal...@redhat.com
that is not covered by the payload
will be zero initialised by the PE/COFF loader.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Acked-by: Mark Salter msal...@redhat.com
---
arch/arm64/kernel/head.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel
If we cannot relocate the kernel Image to its preferred offset of base of DRAM
plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus
TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
proceed normally otherwise.
Signed-off-by: Ard Biesheuvel
mark.rutl...@arm.com
Tested-by: Mark Salter msal...@redhat.com
[ardb: added (__force void *) cast]
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/kernel/smp_spin_table.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm64
.
Changes in v2:
- add (__force void *) cast to patch #1, as suggested in LAKML discussion
- add tested-by/acked-by lines
- rebased patch #3 onto efi-next
Mark Rutland (1):
arm64: spin-table: handle unmapped cpu-release-addrs
Ard Biesheuvel (2):
arm64/efi: efistub: cover entire static mem
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
From: Mark Rutland mark.rutl...@arm.com
In certain cases the cpu-release-addr of a CPU may not fall in the
linear mapping (e.g. when the kernel is loaded above
On 30 July 2014 14:00, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
From: Mark Rutland mark.rutl...@arm.com
In certain cases the cpu-release-addr of a CPU may
On 30 July 2014 14:49, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Jul 30, 2014 at 01:42:58PM +0100, Will Deacon wrote:
On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote:
On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
On 30 July 2014 13:30, Will Deacon
On 30 July 2014 15:10, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 30 July 2014 14:49, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Jul 30, 2014 at 01:42:58PM +0100, Will Deacon wrote:
On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote:
On Wed, Jul 30, 2014 at 01:00:40PM
On 30 July 2014 16:18, Matt Fleming m...@console-pimps.org wrote:
On Mon, 21 Jul, at 05:16:19PM, Ard Biesheuvel wrote:
Similar to how text offset and kernel size are mangled to produce little
endian constants for the Image header regardless of the endianness of the
kernel, this adds a number
On 31 July 2014 12:04, Will Deacon will.dea...@arm.com wrote:
On Thu, Jul 31, 2014 at 10:58:54AM +0100, Mark Rutland wrote:
On Thu, Jul 31, 2014 at 10:45:15AM +0100, Will Deacon wrote:
On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote:
]On 30 July 2014 13:30, Will Deacon
mappings anyway (point (a) above)
It should also be noted that, as the kernel side of the address space (TTBR1) is
retained, the stack and pointer function arguments remain accessible to the
runtime service while the id mapping is active.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
1 - 100 of 1439 matches
Mail list logo
