On 23 May 2014 17:03, Leif Lindholm wrote:
> On Fri, May 23, 2014 at 02:47:20PM +0100, Catalin Marinas wrote:
>> That's a first (possibly temporary) step and I think it's fine:
>>
>> Acked-by: Catalin Marinas
>>
>> But we need some further tweaking to the way we call efi_init().
>> Currently it d
On 23 May 2014 17:45, Leif Lindholm 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_signatu
later, it should live under arch/arm anyway and not in
shared code.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/kernel/efi-stub.c | 2 --
drivers/firmware/efi/fdt.c | 10 --
2 files changed, 12 deletions(-)
diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
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 a pointer to unsigned long where a pointer to int is expected.
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c | 4
This moves definitions depended upon both by code under arch/arm64/boot and
under drivers/firmware/efi to . This is in preparation of turning
the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/efi.h | 13 +
arch
This moves definitions depended upon both by code under arch/x86/boot and
under drivers/firmware/efi to . This is in preparation of turning
the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 5 +
arch/x86
#includes to all .c files 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
---
arch/arm64/kernel/efi-s
On 16 June 2014 17:14, 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.
>
> The x86 code uses a stub built into the boot e
On 18 June 2014 11:02, Matt Fleming 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
&g
On 18 June 2014 10:50, Matt Fleming 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
>>
On 18 June 2014 11:28, Matt Fleming 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 c
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
---
arch/x86/platform/efi/efi.c| 144 +--
drivers/firmware/efi/Makefile | 2
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
---
arch/arm64/include/asm/efi.h | 21 +
arch/arm64/kernel/efi.c
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 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 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 cod
On 25 June 2014 23:53, kbuild test robot 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 wrappers to generic code
ly to UEFI Runtime Services called by the kernel, so make sure
the FP/SIMD register file is preserved in this case.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/efi.h | 21 +
arch/arm64/kernel/efi.c | 14 +-
3 fil
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
---
arch/x86/Kconfig| 1 +
arch/x86/platform/efi/efi.c | 144
ble 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/ar
On 26 June 2014 15:58, Mark Salter 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 u
This moves definitions depended upon both by code under arch/x86/boot and
under drivers/firmware/efi to . This is in preparation of turning
the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel
---
arch/x86/boot/compressed/eboot.c | 5 +
arch/x86
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
---
arch/arm64/kernel/efi-stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
This moves definitions depended upon both by code under arch/arm64/boot and
under drivers/firmware/efi to . This is in preparation of turning
the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/efi.h | 12
arch
#includes to all .c files 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
---
arch/arm64/kernel/efi-s
hould only 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/ar
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
---
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile| 1
On 1 July 2014 15:30, Matt Fleming 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.
>>
>> Si
On 1 July 2014 15:26, Matt Fleming 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
On 1 July 2014 17:11, Matt Fleming 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
On 1 July 2014 17:18, Ard Biesheuvel wrote:
> On 1 July 2014 17:11, Matt Fleming 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 ver
On 1 July 2014 20:39, Matt Fleming wrote:
> On Thu, 26 Jun, at 04:23:32PM, Ard Biesheuvel wrote:
>> This is v2 of the series to change the #include "../../../../xxx.c" pattern
>> into a static library linked into either the kernel (arm64) or a separate
>>
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
---
drivers/firmware/efi/runtime-wrappers.c | 109 +---
1 file changed, 99
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
---
arch/arm64/kernel/efi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel
> On 2 July 2014 12:10, 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
> ---
> arch/arm64/kernel/efi.c | 7 +--
> 1 file changed, 5 in
On 2 July 2014 13:15, Matt Fleming 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 librar
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 wrote:
> On 2 July 2014 13:15, Matt Fleming wrote:
>> On Thu, 26 Jun, at 04:23:37PM, Ard Biesheuvel wrote:
>>> This
This moves definitions depended upon both by code under arch/arm64/boot
and under drivers/firmware/efi to . This is in preparation of
turning the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel
Signed-off-by: Matt Fleming
---
arch/arm64/include/asm
#includes to all .c files 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
---
arch/arm64/kernel/efi-s
hould only 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: Avo
This moves definitions depended upon both by code under arch/x86/boot
and under drivers/firmware/efi to . This is in preparation of
turning the stub code under drivers/firmware/efi into a static library.
Signed-off-by: Ard Biesheuvel
Signed-off-by: Matt Fleming
---
arch/x86/boot/compressed
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
---
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
Signed-off-by: Matt Fleming
---
arch/arm64/kernel/efi-stub.c | 2 +-
1 file changed
On 2 July 2014 14:59, Mark Salter 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 . This is in preparation of turning
>> the stub code under driver
On 2 July 2014 16:29, Mark Salter wrote:
> On Wed, 2014-07-02 at 12:13 +0200, Ard Biesheuvel wrote:
>> > On 2 July 2014 12:10, Ard Biesheuvel wrote:
>> > We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL,
>> > but
>> > then go on an
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 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
(adding Catalin)
On 4 July 2014 16:42, Mark Salter 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 i
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 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 wrote:
> On Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote:
>> On 4 July 2014 17:45, Catalin Marinas wrote:
>> > On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
>> >> According to the UEFI spec secti
On 4 July 2014 19:01, Catalin Marinas 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
>>
ly to UEFI 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-o
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
---
arch/x86/Kconfig| 1 +
arch/x86/platform/efi/efi.c | 144
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 registe
On 7 July 2014 22:11, Matt Fleming 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.
>
> What release are we targetting with this patch? Is it a bug fix for
> something l
On 7 July 2014 22:29, Matt Fleming 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, and there are particular combinations of calls that need to be
>> serialized.
>
On 7 July 2014 22:43, Ard Biesheuvel wrote:
> On 7 July 2014 22:29, Matt Fleming 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, and there are particular combina
On 8 July 2014 11:29, Matt Fleming 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.
&g
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
---
So this is v2 of the UEFI Runtime Services serialization patch: this time, I use
a single spinlock
On 8 July 2014 13:21, Ard Biesheuvel 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
> ---
>
> So this is v2 of t
: Ard Biesheuvel
---
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 of mutexes, resulting in all
On 9 July 2014 08:40, joeyli 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
>> > > +++ b/arch/x86/platform/ef
On 11 July 2014 09:52, Matt Fleming 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 patc
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 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, but we ca
xactly 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/arm64/i
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
---
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
---
arch/arm64/kernel/Makefile | 2 --
arch/arm64/kernel/efi-stub.c | 29
On 14 July 2014 18:58, Mark Rutland 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 head
On 14 July 2014 18:54, Mark Rutland 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 h
On 14 July 2014 20:29, Mark Rutland wrote:
> On Mon, Jul 14, 2014 at 06:35:32PM +0100, Ard Biesheuvel wrote:
>> On 14 July 2014 18:54, Mark Rutland wrote:
>> > Hi Ard,
>> >
>> > On Mon, Jul 14, 2014 at 05:17:51PM +0100, Ard Biesheuvel wrote:
>> >>
ctually 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
---
arch/arm64/kernel/efi-entry.S | 2 +-
arch/arm64/kernel/head.S | 10 ++
2 files changed, 7 insertions(+),
On 15 July 2014 11:57, Mark Rutland wrote:
> 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 exp
tions of the same
value with a reference to 'stext_offset'
Signed-off-by: Ard Biesheuvel
---
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/arm
by the payload
will be zero initialised by the EFI loader.
Signed-off-by: Ard Biesheuvel
---
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..bbf2489939c2 100644
--- a/arch
On 15 July 2014 13:31, Mark Rutland 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 @@ ENTRY(efi_stub_entry
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
---
This was tested on a Foundation Model using the patch below, which forces the
Image to be loaded at
On 16 July 2014 11:20, Mark Rutland wrote:
> Hi Ard,
>
> On Tue, Jul 15, 2014 at 05:50:30PM +0100, 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
On 16 July 2014 21:45, Mark Salter 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 wrote:
>> > On Tue, 2014-07-15 at 12:58 +0200, Ard Biesheuvel wrote:
>> > > After the EFI stub has done i
On 16 July 2014 16:10, Mark Salter 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_ent
On 16 July 2014 23:03, Mark Salter wrote:
> On Wed, 2014-07-16 at 22:38 +0200, Ard Biesheuvel wrote:
>> On 16 July 2014 21:45, Mark Salter 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 wrote:
> On 7 July 2014 22:11, Matt Fleming 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.
>>
On 18 July 2014 21:31, Matt Fleming 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? An
by the payload
will be zero initialised by the EFI loader.
Signed-off-by: Ard Biesheuvel
---
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..c63f44f20ae3 100644
--- a/arch
: Ard Biesheuvel
---
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/kernel/image.h
@@ -37,8
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 to aid with this.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 18 ++
1 file changed
. 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 macr
tions of the same
value with a reference to 'stext_offset'
Signed-off-by: Ard Biesheuvel
---
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/arm
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
---
arch/arm64/include/asm/efi.h | 2 +
arch/arm64/kernel/efi-be-call.S| 55
arch/arm64/kernel/efi-be
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
---
arch/arm64/kernel/head.S | 48
This changes the Kconfig logic to allow EFI to be enabled on a BE kernel build.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/Kconfig | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e9d8af2fc389..9fa1383acbd3 100644
code 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
---
arch/arm64/kernel/Makefile | 7 +++-
arch/arm64/kernel/efi-en
If we are running a BE kernel, we need to byte reverse all data that UEFI keeps,
as UEFI is strictly little endian.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/kernel/efi.c| 53 +++---
drivers/firmware/efi/efi.c | 26
When we build the stub as a separate executable, we cannot refer to symbols
like _edata or _end to find out how large the kernel is. Use image->image_size
instead, this covers the entire static memory footprint including BSS.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/kernel/efi-stub.c |
On 17 July 2014 16:09, Mark Salter wrote:
> On Wed, 2014-07-16 at 23:13 +0200, Ard Biesheuvel wrote:
>> On 16 July 2014 23:03, Mark Salter wrote:
>> > On Wed, 2014-07-16 at 22:38 +0200, Ard Biesheuvel wrote:
>> >> On 16 July 2014 21:45, Mark Salter wrote:
>&
ices to simply
> boot a BE kernel.
>
Well, the significance of the variable store related 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
On 07/23/2014 12:59 PM, Ard Biesheuvel wrote:
> On 23 July 2014 11:34, Mark Rutland 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'
is not covered by the payload
will be zero initialised by the PE/COFF loader.
Signed-off-by: Ard Biesheuvel
---
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 69dafe9621fd..dafc4f2c1ade
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
1 - 100 of 1641 matches
Mail list logo
