From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/5] arm64: Documentation: clarify Image placement in physical RAM
Date: Wed, 18 Mar 2015 18:05:06 +0100 [thread overview]
Message-ID: <1426698308-726-4-git-send-email-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <1426698308-726-1-git-send-email-ard.biesheuvel@linaro.org>
The early init code maps the kernel image using statically
allocated page tables. This means that we can only allow
Image to be placed such that we can map its entire static
footprint using a single table entry at all but the lowest
level. So update the documentation to reflect that the Image
should not cross a 512 MB boundary, which ensures the above
on both 4k and 64k pages kernels.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Documentation/arm64/booting.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index ab5a90adece3..5949bdbe7aac 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -115,8 +115,9 @@ The Image must be placed text_offset bytes from a 2MB aligned base
address near the start of usable system RAM and called there. Memory
below that base address is currently unusable by Linux, and therefore it
is strongly recommended that this location is the start of system RAM.
-At least image_size bytes from the start of the image must be free for
-use by the kernel.
+The physical memory region consisting of image_size bytes counting from
+the start of the image must be free for use by the kernel, and must not
+cross a 512 MB physical alignment boundary.
Any memory described to the kernel (even that below the 2MB aligned base
address) which is not marked as reserved from the kernel e.g. with a
--
1.8.3.2
next prev parent reply other threads:[~2015-03-18 17:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 17:05 [PATCH v3 0/5] arm64: update/clarify/relax Image and FDT placement rules Ard Biesheuvel
2015-03-18 17:05 ` [PATCH v3 1/5] of/fdt: split off FDT self reservation from memreserve processing Ard Biesheuvel
2015-04-09 11:50 ` Mark Rutland
2015-03-18 17:05 ` [PATCH v3 2/5] arm64: use fixmap region for permanent FDT mapping Ard Biesheuvel
2015-04-09 11:49 ` Mark Rutland
2015-04-09 12:12 ` Ard Biesheuvel
2015-04-09 13:12 ` Mark Rutland
2015-04-09 13:16 ` Ard Biesheuvel
2015-04-09 13:29 ` Mark Rutland
2015-03-18 17:05 ` Ard Biesheuvel [this message]
2015-04-09 11:54 ` [PATCH v3 3/5] arm64: Documentation: clarify Image placement in physical RAM Mark Rutland
2015-04-09 12:14 ` Ard Biesheuvel
2015-03-18 17:05 ` [PATCH v3 4/5] arm64/efi: ensure that Image does not cross a 512 MB boundary Ard Biesheuvel
2015-03-18 17:05 ` [PATCH v3 5/5] arm64/efi: adapt to relaxed FDT placement requirements Ard Biesheuvel
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=1426698308-726-4-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.