Promotion of kernel.lnx.4.4-160829.

			1 - 4K

			2 - 16K

			3 - 64K

  Bit 3:	Kernel physical placement

			0 - 2MB aligned base should be as close as possible

			    to the base of DRAM, since memory below it is not

			    accessible via the linear mapping

			1 - 2MB aligned base may be anywhere in physical

			    memory

  Bits 4-63:	Reserved.

  Bits 3-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

  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.

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.

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.

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.

Any memory described to the kernel (even that below the start of the

image) which is not marked as reserved from the kernel (e.g., with a

                Silicon Errata and Software Workarounds

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

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

Date  : 27 November 2015

It is an unfortunate fact of life that hardware is often produced with

so-called "errata", which can cause it to deviate from the architecture

under specific circumstances.  For hardware produced by ARM, these

errata are broadly classified into the following categories:

  Category A: A critical error without a viable workaround.

  Category B: A significant or critical error with an acceptable

              workaround.

  Category C: A minor error that is not expected to occur under normal

              operation.

For more information, consult one of the "Software Developers Errata

Notice" documents available on infocenter.arm.com (registration

required).

As far as Linux is concerned, Category B errata may require some special

treatment in the operating system. For example, avoiding a particular

sequence of code, or configuring the processor in a particular way. A

less common situation may require similar actions in order to declassify

a Category A erratum into a Category C erratum. These are collectively

known as "software workarounds" and are only required in the minority of

cases (e.g. those cases that both require a non-secure workaround *and*

can be triggered by Linux).

For software workarounds that may adversely impact systems unaffected by

the erratum in question, a Kconfig entry is added under "Kernel

Features" -> "ARM errata workarounds via the alternatives framework".

These are enabled by default and patched in at runtime when an affected

CPU is detected. For less-intrusive workarounds, a Kconfig option is not

available and the code is structured (preferably with a comment) in such

a way that the erratum will not be hit.

This approach can make it slightly onerous to determine exactly which

errata are worked around in an arbitrary kernel source tree, so this

file acts as a registry of software workarounds in the Linux Kernel and

will be updated when new workarounds are committed and backported to

stable kernels.

| Implementor    | Component       | Erratum ID      | Kconfig                 |

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

| ARM            | Cortex-A53      | #826319         | ARM64_ERRATUM_826319    |

| ARM            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319    |

| ARM            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069    |

| ARM            | Cortex-A53      | #819472         | ARM64_ERRATUM_819472    |

| ARM            | Cortex-A53      | #845719         | ARM64_ERRATUM_845719    |

| ARM            | Cortex-A53      | #843419         | ARM64_ERRATUM_843419    |

| ARM            | Cortex-A57      | #832075         | ARM64_ERRATUM_832075    |

| ARM            | Cortex-A57      | #852523         | N/A                     |

| ARM            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220    |

|                |                 |                 |                         |

| Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375    |

| Cavium         | ThunderX GICv3  | #23154          | CAVIUM_ERRATUM_23154    |

- #clock_cells:		Must be <1>. This will allow the common clock device

			tree framework to recognize _this_ device node as a

			clock provider.

Optional properties:

- #reset-cells:		Must be <1>. This will allow the common reset device

			tree framework to recognize _this_ device node as a

			reset controller provider.

Example:

	clock_rpm: qcom,rpmcc {

		compatible = "qcom,dummycc";

		#clock-cells = <1>;

		#reset-cells = <1>;

	};

- target-supply     : regulator for SATA target power

- phys              : reference to the SATA PHY node

- phy-names         : must be "sata-phy"

- ports-implemented : Mask that indicates which ports that the HBA supports

		      are available for software to use. Useful if PORTS_IMPL

		      is not programmed by the BIOS, which is true with

		      some embedded SOC's.

Required properties when using sub-nodes:

- #address-cells    : number of cells to encode an address

    |       alpha: |  ..  |

    |         arc: | TODO |

    |         arm: |  ok  |

    |       arm64: |  ok  |

    |       arm64: |  ..  |

    |       avr32: | TODO |

    |    blackfin: | TODO |

    |         c6x: | TODO |