From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] arm64: update/clarify/relax Image and FDT placement rules
Date: Tue, 3 Mar 2015 12:03:45 +0100 [thread overview]
Message-ID: <1425380630-3684-1-git-send-email-ard.biesheuvel@linaro.org> (raw)
This series came about after Mark Rutland brought up the fact that the current
FDT placement logic used by the EFI stub is flawed. But actually, it turned out
that the documentation for both the Image and FDT placement was incorrect as
well, or confusing at the very least.
So this series does two things:
- It relaxes the FDT placement requirements, and updates the documentation and
EFI stub FDT placement logic accordingly.
- It clarifies the Image placement requirements in the documentation, and brings
the EFI stub Image placement logic in line with it
Ard Biesheuvel (5):
of/fdt: allow FDT virtual address outside of linear direct mapping
arm64: use fixmap region for permanent FDT mapping
arm64: Documentation: clarify Image placement in physical RAM
arm64/efi: ensure that Image does not cross a 512 MB boundary
arm64/efi: adapt to relaxed FDT placement requirements
Documentation/arm64/booting.txt | 12 +++----
arch/arm64/include/asm/efi.h | 9 +++--
arch/arm64/include/asm/fixmap.h | 9 +++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/efi-stub.c | 38 ++++++++++++++++----
arch/arm64/kernel/head.S | 38 +-------------------
arch/arm64/kernel/setup.c | 62 +++++++++++++++++++++++++++++----
drivers/firmware/efi/libstub/arm-stub.c | 2 +-
drivers/firmware/efi/libstub/fdt.c | 7 ++--
drivers/of/fdt.c | 14 +++++++-
10 files changed, 125 insertions(+), 67 deletions(-)
--
1.8.3.2
next reply other threads:[~2015-03-03 11:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 11:03 Ard Biesheuvel [this message]
2015-03-03 11:03 ` [PATCH 1/5] of/fdt: allow FDT virtual address outside of linear direct mapping Ard Biesheuvel
2015-03-10 21:47 ` Rob Herring
2015-03-11 8:34 ` Ard Biesheuvel
2015-03-11 11:48 ` Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 2/5] arm64: use fixmap region for permanent FDT mapping Ard Biesheuvel
2015-03-10 21:37 ` Rob Herring
2015-03-11 7:05 ` Ard Biesheuvel
2015-03-11 9:50 ` Mark Rutland
2015-03-11 10:20 ` Ard Biesheuvel
2015-03-11 10:46 ` Mark Rutland
2015-03-11 12:22 ` Rob Herring
2015-03-11 10:43 ` Mark Rutland
2015-03-11 10:54 ` Ard Biesheuvel
2015-03-11 11:56 ` Mark Rutland
2015-03-03 11:03 ` [PATCH 3/5] arm64: Documentation: clarify Image placement in physical RAM Ard Biesheuvel
2015-03-11 10:04 ` Mark Rutland
2015-03-03 11:03 ` [PATCH 4/5] arm64/efi: ensure that Image does not cross a 512 MB boundary Ard Biesheuvel
2015-03-11 11:50 ` Mark Rutland
2015-03-11 15:00 ` Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 5/5] arm64/efi: adapt to relaxed FDT placement requirements Ard Biesheuvel
2015-03-11 12:09 ` Mark Rutland
2015-03-11 14:42 ` Ard Biesheuvel
2015-03-10 10:51 ` [PATCH 0/5] arm64: update/clarify/relax Image and FDT placement rules Ard Biesheuvel
2015-03-10 11:21 ` Mark Rutland
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=1425380630-3684-1-git-send-email-ard.biesheuvel@linaro.org \
--to=ard.biesheuvel@linaro.org \
--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).