From 4370eec05a887b0cd4392cd5dc5b2713174745c0 Mon Sep 17 00:00:00 2001 From: Roy Franz Date: Thu, 15 Aug 2013 00:10:00 +0100 Subject: arm64: Expand arm64 image header Expand the arm64 image header to allow for co-existance with PE/COFF header required by the EFI stub. The PE/COFF format requires the "MZ" header to be at offset 0, and the offset to the PE/COFF header to be at offset 0x3c. The image header is expanded to allow 2 instructions at the beginning to accommodate a benign intruction at offset 0 that includes the "MZ" header, a magic number, and the offset to the PE/COFF header. Signed-off-by: Roy Franz Signed-off-by: Catalin Marinas --- Documentation/arm64/booting.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 9c4d388dadd..5273c4d60e6 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -68,13 +68,23 @@ Image target is available instead. Requirement: MANDATORY -The decompressed kernel image contains a 32-byte header as follows: +The decompressed kernel image contains a 64-byte header as follows: - u32 magic = 0x14000008; /* branch to stext, little-endian */ - u32 res0 = 0; /* reserved */ + u32 code0; /* Executable code */ + u32 code1; /* Executable code */ u64 text_offset; /* Image load offset */ + u64 res0 = 0; /* reserved */ u64 res1 = 0; /* reserved */ u64 res2 = 0; /* reserved */ + u64 res3 = 0; /* reserved */ + u64 res4 = 0; /* reserved */ + u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ + u32 res5 = 0; /* reserved */ + + +Header notes: + +- code0/code1 are responsible for branching to stext. The image must be placed at the specified offset (currently 0x80000) from the start of the system RAM and called there. The start of the -- cgit v1.2.3-18-g5258 From d50240a5f6ceaf690a77b0fccb17be51cfa151c2 Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Wed, 12 Jun 2013 16:28:04 +0100 Subject: arm64: mm: permit use of tagged pointers at EL0 TCR.TBI0 can be used to cause hardware address translation to ignore the top byte of userspace virtual addresses. Whilst not especially useful in standard C programs, this can be used by JITs to `tag' pointers with various pieces of metadata. This patch enables this bit for AArch64 Linux, and adds a new file to Documentation/arm64/ which describes some potential caveats when using tagged virtual addresses. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas --- Documentation/arm64/tagged-pointers.txt | 34 +++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/arm64/tagged-pointers.txt (limited to 'Documentation') diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt new file mode 100644 index 00000000000..264e9841563 --- /dev/null +++ b/Documentation/arm64/tagged-pointers.txt @@ -0,0 +1,34 @@ + Tagged virtual addresses in AArch64 Linux + ========================================= + +Author: Will Deacon +Date : 12 June 2013 + +This document briefly describes the provision of tagged virtual +addresses in the AArch64 translation system and their potential uses +in AArch64 Linux. + +The kernel configures the translation tables so that translations made +via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of +the virtual address ignored by the translation hardware. This frees up +this byte for application use, with the following caveats: + + (1) The kernel requires that all user addresses passed to EL1 + are tagged with tag 0x00. This means that any syscall + parameters containing user virtual addresses *must* have + their top byte cleared before trapping to the kernel. + + (2) Tags are not guaranteed to be preserved when delivering + signals. This means that signal handlers in applications + making use of tags cannot rely on the tag information for + user virtual addresses being maintained for fields inside + siginfo_t. One exception to this rule is for signals raised + in response to debug exceptions, where the tag information + will be preserved. + + (3) Special care should be taken when using tagged pointers, + since it is likely that C compilers will not hazard two + addresses differing only in the upper bits. + +The architecture prevents the use of a tagged PC, so the upper byte will +be set to a sign-extension of bit 55 on exception return. -- cgit v1.2.3-18-g5258 From 4d5e0b1527dd330940e8b7180b8d7016fc900352 Mon Sep 17 00:00:00 2001 From: Mark Salter Date: Wed, 4 Sep 2013 15:10:02 +0100 Subject: Documentation/arm64: clarify requirements for DTB placement The current description of DTB placement requirements does not quite match the kernel code in head.S: __vet_fdt and __create_page_tables. This patch tweaks the text to match the actual requirements placed on it by the code. Signed-off-by: Mark Salter Acked-by: Will Deacon Signed-off-by: Catalin Marinas --- Documentation/arm64/booting.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 5273c4d60e6..98df4a03807 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -45,9 +45,9 @@ sees fit.) Requirement: MANDATORY -The device tree blob (dtb) must be no bigger than 2 megabytes in size -and placed at a 2-megabyte boundary within the first 512 megabytes from -the start of the kernel image. This is to allow the kernel to map the +The device tree blob (dtb) must be placed on an 8-byte boundary within +the first 512 megabytes from the start of the kernel image and must not +cross a 2-megabyte boundary. This is to allow the kernel to map the blob using a single section mapping in the initial page tables. -- cgit v1.2.3-18-g5258