From: Rasmus Villemoes <linux@rasmusvillemoes•dk>
To: linux-arm-kernel@lists•infradead.org
Cc: Ard Biesheuvel <ardb@kernel•org>, Will Deacon <will@kernel•org>,
Jonathan Corbet <corbet@lwn•net>,
linux-doc@vger•kernel.org, linux-kernel@vger•kernel.org,
Rasmus Villemoes <linux@rasmusvillemoes•dk>
Subject: [PATCH] docs: arm64: Document that text_offset is always 0
Date: Thu, 4 Jun 2026 16:08:39 +0200 [thread overview]
Message-ID: <20260604140839.1930847-1-linux@rasmusvillemoes.dk> (raw)
When trying to figure out where to place and call an arm64 Image in
memory, reading booting.rst should provide the answer. However, it
requires quite some digging to figure out that text_offset is set via
".quad 0" in head.S and is thus actually always 0 since v5.10.
Update the documentation and make that explicit. Reword the 2MB
requirement accordingly, and remove the paragraphs that only apply to
the ancient versions where text_offset could be non-zero, as they only
confuse a current reader.
Fixes: 120dc60d0bdb ("arm64: get rid of TEXT_OFFSET")
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes•dk>
---
I've included a Fixes tag since I spent way too much time tracking
down where that text_offset might be defined. The mentioned commit did
get rid of all references to TEXT_OFFSET-the-macro, but not
text_offset-the-concept.
Documentation/arch/arm64/booting.rst | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
index 13ef311dace8..f4cc25b1fd56 100644
--- a/Documentation/arch/arm64/booting.rst
+++ b/Documentation/arch/arm64/booting.rst
@@ -55,9 +55,6 @@ not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
using blocks of up to 2 megabytes in size, it must not be placed within
any 2M region which must be mapped with any specific attributes.
-NOTE: versions prior to v4.2 also require that the DTB be placed within
-the 512 MB region starting at text_offset bytes below the kernel Image.
-
3. Decompress the kernel image
------------------------------
@@ -93,6 +90,8 @@ Header notes:
- As of v3.17, all fields are little endian unless stated otherwise.
+- As of v5.10, text_offset is always 0.
+
- code0/code1 are responsible for branching to stext.
- when booting through EFI, code0/code1 are initially skipped.
@@ -100,12 +99,6 @@ Header notes:
entry point (efi_stub_entry). When the stub has done its work, it
jumps to code0 to resume the normal boot process.
-- Prior to v3.17, the endianness of text_offset was not specified. In
- these cases image_size is zero and text_offset is 0x80000 in the
- endianness of the kernel. Where image_size is non-zero image_size is
- little-endian and must be respected. Where image_size is zero,
- text_offset can be assumed to be 0x80000.
-
- The flags field (introduced in v3.17) is a little-endian 64-bit field
composed as follows:
@@ -135,12 +128,9 @@ Header notes:
end of the kernel image. The amount of space required will vary
depending on selected features, and is effectively unbound.
-The Image must be placed text_offset bytes from a 2MB aligned base
-address anywhere in usable system RAM and called there. The region
-between the 2 MB aligned base address and the start of the image has no
-special significance to the kernel, and may be used for other purposes.
-At least image_size bytes from the start of the image must be free for
-use by the kernel.
+The Image must be placed at a 2MB aligned base address anywhere in
+usable system RAM and called there. At least image_size bytes from
+the start of the image must be free for use by the kernel.
NOTE: versions prior to v4.6 cannot make use of memory below the
physical offset of the Image so it is recommended that the Image be
placed as close as possible to the start of system RAM.
--
2.54.0
reply other threads:[~2026-06-04 14:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260604140839.1930847-1-linux@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes$(echo .)dk \
--cc=ardb@kernel$(echo .)org \
--cc=corbet@lwn$(echo .)net \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-doc@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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