linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 11/15] arm64: add EFI stub
Date: Wed, 19 Mar 2014 10:57:06 +0000	[thread overview]
Message-ID: <20140319105706.GE2214@arm.com> (raw)
In-Reply-To: <1395178831.2967.29.camel@deneb.redhat.com>

On Tue, Mar 18, 2014 at 09:40:31PM +0000, Mark Salter wrote:
> On Tue, 2014-03-18 at 18:28 +0000, Catalin Marinas wrote:
> > If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
> > flush by MVA. We don't need to flush the whole DRAM (and I would even
> > recommend it) but at least the relevant kernel code/data touched with
> > the MMU disabled.
> 
> So, it goes like this:
> 
>   1) UEFI calls stub with MMU/Caches on. Stub/kernel can be anywhere.
>   2) Stub runs and relocates kernel to the desired runtime location
>      but continues to execute from wherever UEFI loaded it until just
>      after ExitBootServices().
>   3) After ExitBootServices, efi_entry() returns relocated entry point
>      for kernel to efi_stub_entry() in efi-entry.S where the Dcache and
>      MMU are turned off, the __flush_dcache_all is called, then the
>      code jumps to the kernel proper entry point.
> 
> It isn't clear to me if UEFI does cache flushing at ExitBootServices
> time, but even so, at least stack use will get cached between then and
> the kernel entry point. The stub could conceivably get its hands on the
> EFI memmap and invalidate dcache using address ranges from UEFI memory
> descriptors so maybe that is the way we should do it.

I think the stub just needs to flush the relocated kernel image, ensure
it is sync with the memory. Additional flushing can be done by the
kernel for bits it writes (like page tables, code patching etc). We can
enter the kernel with the SCTLR.I bit set, so it can allocate in an
unified cache already and D-cache maintenance would be needed anyway.

Another aspect in the booting document is that we require any external
cache to be disabled. I think on ARMv8 with a more transparent external
cache we can relax this (Applied's SoC already does this). Otherwise,
since external cache enabling is usually a secure operation, we would
need some SoC specific code just for this early during boot and I'd like
to avoid it.

-- 
Catalin

  parent reply	other threads:[~2014-03-19 10:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-13 22:46 [PATCH v2 00/14] UEFI support for arm(64) Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 01/15] efi: delete stray ARM ifdef Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 02/15] efi: x86: Improve cmdline conversion Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 03/15] efi: create memory map iteration helper Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 04/15] lib: add fdt_empty_tree.c Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 05/15] efi: add helper function to get UEFI params from FDT Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 06/15] doc: efi-stub.txt updates for ARM Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 07/15] efi: Add shared printk wrapper for consistent prefixing Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 08/15] efi: Add get_dram_base() helper function Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 09/15] efi: Add shared FDT related functions for ARM/ARM64 Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 10/15] arm64: Add function to create identity mappings Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 11/15] arm64: add EFI stub Leif Lindholm
2014-03-18 12:09   ` Catalin Marinas
2014-03-18 14:40     ` Mark Salter
2014-03-18 18:28       ` Catalin Marinas
2014-03-18 21:40         ` Mark Salter
2014-03-18 21:48           ` Roy Franz
2014-03-18 22:21             ` Jason Gunthorpe
2014-03-19 10:35               ` Catalin Marinas
2014-03-19 10:57           ` Catalin Marinas [this message]
2014-03-19 15:13             ` Mark Salter
2014-03-19 16:01               ` Catalin Marinas
2014-03-19 16:46                 ` Mark Salter
2014-03-13 22:47 ` [PATCH v2 12/15] doc: arm64: add description of EFI stub support Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 13/15] arm64: add EFI runtime services Leif Lindholm
2014-03-18 12:34   ` Catalin Marinas
2014-03-18 14:16     ` Mark Salter
2014-03-18 17:36       ` Catalin Marinas
2014-03-13 22:47 ` [PATCH v2 14/15] doc: arm: add UEFI support documentation Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 15/15] efi/arm64: ignore dtb= when UEFI SecureBoot is enabled Leif Lindholm
2014-03-17 22:24 ` [PATCH v2 00/14] UEFI support for arm(64) Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140319105706.GE2214@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).