Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

  u32 code0;			/* Executable code */

  u32 code1;			/* Executable code */

  u64 text_offset;		/* Image load offset */

  u64 res0	= 0;		/* reserved */

  u64 res1	= 0;		/* reserved */

  u64 text_offset;		/* Image load offset, little endian */

  u64 image_size;		/* Effective Image size, little endian */

  u64 flags;			/* kernel flags, little endian */

  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 */

  u32 res5;      		/* reserved (used for PE COFF offset) */

Header notes:

- As of v3.17, all fields are little endian unless stated otherwise.

- code0/code1 are responsible for branching to stext.

- when booting through EFI, code0/code1 are initially skipped.

  res5 is an offset to the PE header and the PE header has the EFI

  entry point (efi_stub_entry).  When the stub has done its work, it

  jumps to code0 to resume the normal boot process.

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

system RAM must be aligned to 2MB.

- 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:

  Bit 0: 	Kernel endianness.  1 if BE, 0 if LE.

  Bits 1-63:	Reserved.

- When image_size is zero, a bootloader should attempt to keep as much

  memory as possible free for use by the kernel immediately after the

  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 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.

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

memreserve region in the device tree) will be considered as available to

the kernel.

Before jumping into the kernel, the following conditions must be met:

		     ==============================

Author: Catalin Marinas <catalin.marinas@arm.com>

Date  : 20 February 2012

This document describes the virtual memory layout used by the AArch64

Linux kernel. The architecture allows up to 4 levels of translation

tables with a 4KB page size and up to 3 levels with a 64KB page size.

AArch64 Linux uses 3 levels of translation tables with the 4KB page

configuration, allowing 39-bit (512GB) virtual addresses for both user

and kernel. With 64KB pages, only 2 levels of translation tables are

used but the memory layout is the same.

AArch64 Linux uses either 3 levels or 4 levels of translation tables

with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit

(256TB) virtual addresses, respectively, for both user and kernel. With

64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)

virtual address, are used but the memory layout is the same.

User addresses have bits 63:39 set to 0 while the kernel addresses have

User addresses have bits 63:48 set to 0 while the kernel addresses have

the same bits set to 1. TTBRx selection is given by bit 63 of the

virtual address. The swapper_pg_dir contains only kernel (global)

mappings while the user pgd contains only user (non-global) mappings.

TTBR0.

AArch64 Linux memory layout with 4KB pages:

AArch64 Linux memory layout with 4KB pages + 3 levels:

Start			End			Size		Use

-----------------------------------------------------------------------

0000000000000000	0000007fffffffff	 512GB		user

ffffff8000000000	ffffffffffffffff	 512GB		kernel

ffffff8000000000	ffffffbbfffeffff	~240GB		vmalloc

ffffffbbffff0000	ffffffbbffffffff	  64KB		[guard page]

AArch64 Linux memory layout with 4KB pages + 4 levels:

ffffffbc00000000	ffffffbdffffffff	   8GB		vmemmap

ffffffbe00000000	ffffffbffbbfffff	  ~8GB		[guard, future vmmemap]

ffffffbffa000000	ffffffbffaffffff	  16MB		PCI I/O space

ffffffbffb000000	ffffffbffbbfffff	  12MB		[guard]

ffffffbffbc00000	ffffffbffbdfffff	   2MB		fixed mappings

ffffffbffbe00000	ffffffbffbffffff	   2MB		[guard]

ffffffbffc000000	ffffffbfffffffff	  64MB		modules

ffffffc000000000	ffffffffffffffff	 256GB		kernel logical memory map

Start			End			Size		Use

-----------------------------------------------------------------------

0000000000000000	0000ffffffffffff	 256TB		user

ffff000000000000	ffffffffffffffff	 256TB		kernel

AArch64 Linux memory layout with 64KB pages:

AArch64 Linux memory layout with 64KB pages + 2 levels:

Start			End			Size		Use

-----------------------------------------------------------------------

0000000000000000	000003ffffffffff	   4TB		user

fffffc0000000000	ffffffffffffffff	   4TB		kernel

fffffc0000000000	fffffdfbfffeffff	  ~2TB		vmalloc

fffffdfbffff0000	fffffdfbffffffff	  64KB		[guard page]

AArch64 Linux memory layout with 64KB pages + 3 levels:

fffffdfc00000000	fffffdfdffffffff	   8GB		vmemmap

fffffdfe00000000	fffffdfffbbfffff	  ~8GB		[guard, future vmmemap]

fffffdfffa000000	fffffdfffaffffff	  16MB		PCI I/O space

fffffdfffb000000	fffffdfffbbfffff	  12MB		[guard]

fffffdfffbc00000	fffffdfffbdfffff	   2MB		fixed mappings

fffffdfffbe00000	fffffdfffbffffff	   2MB		[guard]

Start			End			Size		Use

-----------------------------------------------------------------------

0000000000000000	0000ffffffffffff	 256TB		user

ffff000000000000	ffffffffffffffff	 256TB		kernel

fffffdfffc000000	fffffdffffffffff	  64MB		modules

fffffe0000000000	ffffffffffffffff	   2TB		kernel logical memory map

For details of the virtual kernel memory layout please see the kernel

booting log.

Translation table lookup with 4KB pages:

 |                 |         |         |         +-> [20:12] L3 index

 |                 |         |         +-----------> [29:21] L2 index

 |                 |         +---------------------> [38:30] L1 index

 |                 +-------------------------------> [47:39] L0 index (not used)

 |                 +-------------------------------> [47:39] L0 index

 +-------------------------------------------------> [63] TTBR0/1

 |                 |    |               |              v

 |                 |    |               |            [15:0]  in-page offset

 |                 |    |               +----------> [28:16] L3 index

 |                 |    +--------------------------> [41:29] L2 index (only 38:29 used)

 |                 +-------------------------------> [47:42] L1 index (not used)

 |                 |    +--------------------------> [41:29] L2 index

 |                 +-------------------------------> [47:42] L1 index

 +-------------------------------------------------> [63] TTBR0/1

When using KVM, the hypervisor maps kernel pages in EL2, at a fixed

offset from the kernel VA (top 24bits of the kernel VA set to zero):

config ARM64

	def_bool y

	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

	select ARCH_HAS_OPP

	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST

	select ARCH_USE_CMPXCHG_LOCKREF

	select ARCH_SUPPORTS_ATOMIC_RMW

	select ARM_AMBA

	select ARM_ARCH_TIMER

	select ARM_GIC

	select AUDIT_ARCH_COMPAT_GENERIC

	select ARM_GIC_V3

	select BUILDTIME_EXTABLE_SORT

	select CLONE_BACKWARDS

	select COMMON_CLK

	select GENERIC_STRNLEN_USER

	select GENERIC_TIME_VSYSCALL

	select HARDIRQS_SW_RESEND

	select HAVE_ARCH_AUDITSYSCALL

	select HAVE_ARCH_JUMP_LABEL

	select HAVE_ARCH_KGDB

	select HAVE_ARCH_TRACEHOOK

	select HAVE_C_RECORDMCOUNT

	select HAVE_CC_STACKPROTECTOR

	select HAVE_DEBUG_BUGVERBOSE

	select HAVE_DEBUG_KMEMLEAK

	select HAVE_DMA_API_DEBUG

	select RTC_LIB

	select SPARSE_IRQ

	select SYSCTL_EXCEPTION_TRACE

	select HAVE_CONTEXT_TRACKING

	help

	  ARM 64-bit (AArch64) Linux support.

menu "Kernel Features"

choice

	prompt "Page size"

	default ARM64_4K_PAGES

	help

	  Page size (translation granule) configuration.

config ARM64_4K_PAGES

	bool "4KB"

	help

	  This feature enables 4KB pages support.

config ARM64_64K_PAGES

	bool "Enable 64KB pages support"

	bool "64KB"

	help

	  This feature enables 64KB pages support (4KB by default)

	  allowing only two levels of page tables and faster TLB

	  look-up. AArch32 emulation is not available when this feature

	  is enabled.

endchoice

choice

	prompt "Virtual address space size"

	default ARM64_VA_BITS_39 if ARM64_4K_PAGES

	default ARM64_VA_BITS_42 if ARM64_64K_PAGES

	help

	  Allows choosing one of multiple possible virtual address

	  space sizes. The level of translation table is determined by

	  a combination of page size and virtual address space size.

config ARM64_VA_BITS_39

	bool "39-bit"

	depends on ARM64_4K_PAGES

config ARM64_VA_BITS_42

	bool "42-bit"

	depends on ARM64_64K_PAGES

config ARM64_VA_BITS_48

	bool "48-bit"

	depends on BROKEN

endchoice

config ARM64_VA_BITS

	int

	default 39 if ARM64_VA_BITS_39

	default 42 if ARM64_VA_BITS_42

	default 48 if ARM64_VA_BITS_48

config ARM64_PGTABLE_LEVELS

	int

	default 2 if ARM64_64K_PAGES && ARM64_VA_BITS_42

	default 3 if ARM64_64K_PAGES && ARM64_VA_BITS_48

	default 3 if ARM64_4K_PAGES && ARM64_VA_BITS_39

	default 4 if ARM64_4K_PAGES && ARM64_VA_BITS_48

config CPU_BIG_ENDIAN

       bool "Build big-endian kernel"

       help

	  instructions during context switch. Say Y here only if you are

	  planning to use hardware trace tools with this kernel.

config ARM64_RANDOMIZE_TEXT_OFFSET

	bool "Randomize TEXT_OFFSET at build time"

	help

	  Say Y here if you want the image load offset (AKA TEXT_OFFSET)

	  of the kernel to be randomized at build-time. When selected,

	  this option will cause TEXT_OFFSET to be randomized upon any

	  build of the kernel, and the offset will be reflected in the

	  text_offset field of the resulting Image. This can be used to

	  fuzz-test bootloaders which respect text_offset.

	  This option is intended for bootloader and/or kernel testing

	  only. Bootloaders must make no assumptions regarding the value

	  of TEXT_OFFSET and platforms must not require a specific

	  value.

endmenu

head-y		:= arch/arm64/kernel/head.o

# The byte offset of the kernel image in RAM from the start of RAM.

ifeq ($(CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET), y)

TEXT_OFFSET := $(shell awk 'BEGIN {srand(); printf "0x%04x0\n", int(65535 * rand())}')

else

TEXT_OFFSET := 0x00080000

endif

export	TEXT_OFFSET GZFLAGS