Merge tag 'arm64-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64

			Booting AArch64 Linux

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

Author: Will Deacon <will.deacon@arm.com>

Date  : 07 September 2012

This document is based on the ARM booting document by Russell King and

is relevant to all public releases of the AArch64 Linux kernel.

The AArch64 exception model is made up of a number of exception levels

(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure

counterpart.  EL2 is the hypervisor level and exists only in non-secure

mode. EL3 is the highest priority level and exists only in secure mode.

For the purposes of this document, we will use the term `boot loader'

simply to define all software that executes on the CPU(s) before control

is passed to the Linux kernel.  This may include secure monitor and

hypervisor code, or it may just be a handful of instructions for

preparing a minimal boot environment.

Essentially, the boot loader should provide (as a minimum) the

following:

1. Setup and initialise the RAM

2. Setup the device tree

3. Decompress the kernel image

4. Call the kernel image

1. Setup and initialise RAM

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

Requirement: MANDATORY

The boot loader is expected to find and initialise all RAM that the

kernel will use for volatile data storage in the system.  It performs

this in a machine dependent manner.  (It may use internal algorithms

to automatically locate and size all RAM, or it may use knowledge of

the RAM in the machine, or any other method the boot loader designer

sees fit.)

2. Setup the device tree

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

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

blob using a single section mapping in the initial page tables.

3. Decompress the kernel image

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

Requirement: OPTIONAL

The AArch64 kernel does not currently provide a decompressor and

therefore requires decompression (gzip etc.) to be performed by the boot

loader if a compressed Image target (e.g. Image.gz) is used.  For

bootloaders that do not implement this requirement, the uncompressed

Image target is available instead.

4. Call the kernel image

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

Requirement: MANDATORY

The decompressed kernel image contains a 32-byte header as follows:

  u32 magic	= 0x14000008;	/* branch to stext, little-endian */

  u32 res0	= 0;		/* reserved */

  u64 text_offset;		/* Image load offset */

  u64 res1	= 0;		/* reserved */

  u64 res2	= 0;		/* reserved */

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.

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

- Quiesce all DMA capable devices so that memory does not get

  corrupted by bogus network packets or disk data.  This will save

  you many hours of debug.

- Primary CPU general-purpose register settings

  x0 = physical address of device tree blob (dtb) in system RAM.

  x1 = 0 (reserved for future use)

  x2 = 0 (reserved for future use)

  x3 = 0 (reserved for future use)

- CPU mode

  All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,

  IRQ and FIQ).

  The CPU must be in either EL2 (RECOMMENDED in order to have access to

  the virtualisation extensions) or non-secure EL1.

- Caches, MMUs

  The MMU must be off.

  Instruction cache may be on or off.

  Data cache must be off and invalidated.

  External caches (if present) must be configured and disabled.

- Architected timers

  CNTFRQ must be programmed with the timer frequency.

  If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)

  set where available.

- Coherency

  All CPUs to be booted by the kernel must be part of the same coherency

  domain on entry to the kernel.  This may require IMPLEMENTATION DEFINED

  initialisation to enable the receiving of maintenance operations on

  each CPU.

- System registers

  All writable architected system registers at the exception level where

  the kernel image will be entered must be initialised by software at a

  higher exception level to prevent execution in an UNKNOWN state.

The boot loader is expected to enter the kernel on each CPU in the

following manner:

- The primary CPU must jump directly to the first instruction of the

  kernel image.  The device tree blob passed by this CPU must contain

  for each CPU node:

    1. An 'enable-method' property. Currently, the only supported value

       for this field is the string "spin-table".

    2. A 'cpu-release-addr' property identifying a 64-bit,

       zero-initialised memory location.

  It is expected that the bootloader will generate these device tree

  properties and insert them into the blob prior to kernel entry.

- Any secondary CPUs must spin outside of the kernel in a reserved area

  of memory (communicated to the kernel by a /memreserve/ region in the

  device tree) polling their cpu-release-addr location, which must be

  contained in the reserved region.  A wfe instruction may be inserted

  to reduce the overhead of the busy-loop and a sev will be issued by

  the primary CPU.  When a read of the location pointed to by the

  cpu-release-addr returns a non-zero value, the CPU must jump directly

  to this value.

- Secondary CPU general-purpose register settings

  x0 = 0 (reserved for future use)

  x1 = 0 (reserved for future use)

  x2 = 0 (reserved for future use)

  x3 = 0 (reserved for future use)

		     Memory Layout on AArch64 Linux

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

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.

User addresses have bits 63:39 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.

The swapper_pgd_dir address is written to TTBR1 and never written to

TTBR0.

AArch64 Linux memory layout:

Start			End			Size		Use

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

0000000000000000	0000007fffffffff	 512GB		user

ffffff8000000000	ffffffbbfffcffff	~240GB		vmalloc

ffffffbbfffd0000	ffffffbcfffdffff	  64KB		[guard page]

ffffffbbfffe0000	ffffffbcfffeffff	  64KB		PCI I/O space

ffffffbbffff0000	ffffffbcffffffff	  64KB		[guard page]

ffffffbc00000000	ffffffbdffffffff	   8GB		vmemmap

ffffffbe00000000	ffffffbffbffffff	  ~8GB		[guard, future vmmemap]

ffffffbffc000000	ffffffbfffffffff	  64MB		modules

ffffffc000000000	ffffffffffffffff	 256GB		memory

Translation table lookup with 4KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+

|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|

+--------+--------+--------+--------+--------+--------+--------+--------+

 |                 |         |         |         |         |

 |                 |         |         |         |         v

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

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

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

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

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

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

Translation table lookup with 64KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+

|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|

+--------+--------+--------+--------+--------+--------+--------+--------+

 |                 |    |               |              |

 |                 |    |               |              v

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

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

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

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

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

F:	arch/arm/mach-pxa/z2.c

F:	arch/arm/mach-pxa/include/mach/z2.h

ARM64 PORT (AARCH64 ARCHITECTURE)

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

L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)

S:	Maintained

F:	arch/arm64/

ASC7621 HARDWARE MONITOR DRIVER

M:	George Joseph <george.joseph@fairview5.com>

L:	lm-sensors@lm-sensors.org

config ARM64

	def_bool y

	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

	select GENERIC_CLOCKEVENTS

	select GENERIC_HARDIRQS_NO_DEPRECATED

	select GENERIC_IOMAP

	select GENERIC_IRQ_PROBE

	select GENERIC_IRQ_SHOW

	select GENERIC_SMP_IDLE_THREAD

	select GENERIC_TIME_VSYSCALL

	select HARDIRQS_SW_RESEND

	select HAVE_ARCH_TRACEHOOK

	select HAVE_DMA_API_DEBUG

	select HAVE_DMA_ATTRS

	select HAVE_GENERIC_DMA_COHERENT

	select HAVE_GENERIC_HARDIRQS

	select HAVE_HW_BREAKPOINT if PERF_EVENTS

	select HAVE_IRQ_WORK

	select HAVE_MEMBLOCK

	select HAVE_PERF_EVENTS

	select HAVE_SPARSE_IRQ

	select IRQ_DOMAIN

	select NO_BOOTMEM

	select OF

	select OF_EARLY_FLATTREE

	select PERF_USE_VMALLOC

	select RTC_LIB

	select SPARSE_IRQ

	help

	  ARM 64-bit (AArch64) Linux support.

config 64BIT

	def_bool y

config ARCH_PHYS_ADDR_T_64BIT

	def_bool y

config MMU

	def_bool y

config NO_IOPORT

	def_bool y

config STACKTRACE_SUPPORT

	def_bool y

config LOCKDEP_SUPPORT

	def_bool y

config TRACE_IRQFLAGS_SUPPORT

	def_bool y

config GENERIC_LOCKBREAK

	def_bool y

	depends on SMP && PREEMPT

config RWSEM_GENERIC_SPINLOCK

	def_bool y

config GENERIC_HWEIGHT

	def_bool y

config GENERIC_CSUM

        def_bool y

config GENERIC_CALIBRATE_DELAY

	def_bool y

config ZONE_DMA32

	def_bool y

config ARCH_DMA_ADDR_T_64BIT

	def_bool y

config NEED_DMA_MAP_STATE

	def_bool y

config NEED_SG_DMA_LENGTH

	def_bool y

config SWIOTLB

	def_bool y

config IOMMU_HELPER

	def_bool SWIOTLB

source "init/Kconfig"

source "kernel/Kconfig.freezer"

menu "System Type"

endmenu

menu "Bus support"

config ARM_AMBA

	bool

endmenu

menu "Kernel Features"

source "kernel/time/Kconfig"

config ARM64_64K_PAGES

	bool "Enable 64KB pages support"

	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.

config SMP

	bool "Symmetric Multi-Processing"

	select USE_GENERIC_SMP_HELPERS

	help

	  This enables support for systems with more than one CPU.  If

	  you say N here, the kernel will run on single and

	  multiprocessor machines, but will use only one CPU of a

	  multiprocessor machine. If you say Y here, the kernel will run

	  on many, but not all, single processor machines. On a single

	  processor machine, the kernel will run faster if you say N

	  here.

	  If you don't know what to do here, say N.

config NR_CPUS

	int "Maximum number of CPUs (2-32)"

	range 2 32

	depends on SMP

	default "4"

source kernel/Kconfig.preempt

config HZ

	int

	default 100

config ARCH_HAS_HOLES_MEMORYMODEL

	def_bool y if SPARSEMEM

config ARCH_SPARSEMEM_ENABLE

	def_bool y

	select SPARSEMEM_VMEMMAP_ENABLE

config ARCH_SPARSEMEM_DEFAULT

	def_bool ARCH_SPARSEMEM_ENABLE

config ARCH_SELECT_MEMORY_MODEL

	def_bool ARCH_SPARSEMEM_ENABLE

config HAVE_ARCH_PFN_VALID

	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM

config HW_PERF_EVENTS

	bool "Enable hardware performance counter support for perf events"

	depends on PERF_EVENTS

	default y

	help

	  Enable hardware performance counter support for perf events. If

	  disabled, perf events will use software events only.

source "mm/Kconfig"

endmenu

menu "Boot options"

config CMDLINE

	string "Default kernel command string"

	default ""

	help

	  Provide a set of default command-line options at build time by

	  entering them here. As a minimum, you should specify the the

	  root device (e.g. root=/dev/nfs).

config CMDLINE_FORCE

	bool "Always use the default kernel command string"

	help

	  Always use the default kernel command string, even if the boot

	  loader passes other arguments to the kernel.

	  This is useful if you cannot or don't want to change the

	  command-line options your boot loader passes to the kernel.

endmenu

menu "Userspace binary formats"

source "fs/Kconfig.binfmt"

config COMPAT

	bool "Kernel support for 32-bit EL0"

	depends on !ARM64_64K_PAGES

	select COMPAT_BINFMT_ELF

	help

	  This option enables support for a 32-bit EL0 running under a 64-bit

	  kernel at EL1. AArch32-specific components such as system calls,

	  the user helper functions, VFP support and the ptrace interface are

	  handled appropriately by the kernel.

	  If you want to execute 32-bit userspace applications, say Y.

config SYSVIPC_COMPAT

	def_bool y

	depends on COMPAT && SYSVIPC

endmenu

source "net/Kconfig"

source "drivers/Kconfig"

source "fs/Kconfig"

source "arch/arm64/Kconfig.debug"

source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

menu "Kernel hacking"

source "lib/Kconfig.debug"

config FRAME_POINTER

	bool

	default y

config DEBUG_ERRORS

	bool "Verbose kernel error messages"

	depends on DEBUG_KERNEL

	help

	  This option controls verbose debugging information which can be

	  printed when the kernel detects an internal error. This debugging

	  information is useful to kernel hackers when tracking down problems,

	  but mostly meaningless to other people. It's safe to say Y unless

	  you are concerned with the code size or don't want to see these

	  messages.

config DEBUG_STACK_USAGE

	bool "Enable stack utilization instrumentation"

	depends on DEBUG_KERNEL

	help

	  Enables the display of the minimum amount of free stack which each

	  task has ever had available in the sysrq-T output.

endmenu