Merge branch 'master' of git://git.denx.de/u-boot

6 files changed, 101 insertions, 121 deletions

diff --git a/doc/README.fsl-trustzone-components b/doc/README.fsl-trustzone-components
new file mode 100644
index 0000000000..a3afd1f5f4
--- /dev/null
+++ b/doc/README.fsl-trustzone-components
@@ -0,0 +1,25 @@
+Freescale ARM64 SoCs like LS2085A have ARM TrustZone components like
+TZPC-BP147 (TrustZone Protection Controller) and TZASC-400 (TrustZone
+Address Space Controller).
+
+While most of the configuration related programming of these peripherals
+is left to a root-of-trust security software layer (running in EL3
+privilege mode), but still some configurations of these peripherals
+might be required while the bootloader is executing in EL3 privilege
+mode. The following sections define how to turn on these features for
+LS2085A like SoCs.
+
+TZPC-BP147 (TrustZone Protection Controller)
+============================================
+- Depends on CONFIG_FSL_TZPC_BP147 configuration flag.
+- Separates Secure World and Normal World on-chip RAM (OCRAM) spaces.
+- Provides a programming model to set access control policy via the TZPC
+  TZDECPROT Registers.
+
+TZASC-400 (TrustZone Address Space Controller)
+==============================================
+- Depends on CONFIG_FSL_TZASC_400 configuration flag.
+- Separates Secure World and Normal World external memory spaces for bus masters
+  such as processors and DMA-equipped peripherals.
+- Supports 8 fully programmable address regions, initially inactive at reset,
+  and one base region, always active, that covers the remaining address space.
diff --git a/doc/README.kconfig b/doc/README.kconfig
index 69dc45970b..288d17d232 100644
--- a/doc/README.kconfig
+++ b/doc/README.kconfig
@@ -17,109 +17,45 @@ source directory for a basic specification of Kconfig.
 Difference from Linux's Kconfig
 -------------------------------
 
-The biggest difference between Linux Kernel and U-Boot in terms of the
-configuration is that U-Boot has to configure multiple boot images per board:
-Normal, SPL, TPL.
-Kconfig functions need to be expanded for U-Boot to handle multiple images.
-The files scripts/kconfig/* were imported from Linux Kernel and adjusted
-for that purpose.
+Here are some worth-mentioning configuration targets.
 
-See below for how each configuration target works in U-Boot:
+- silentoldconfig
 
-- config, nconfig, menuconfig, xconfig, gconfig
+  This target updates .config, include/generated/autoconf.h and
+  include/configs/* as in Linux.  In U-Boot, it also does the followings
+  for the compatibility with the old configuration system:
 
-  These targets are used to configure Normal and create (or modify) the
-  .config file.  For SPL configuration, the configutation targets are prefixed
-  with "spl/", for example "make spl/config", "make spl/menuconfig", etc.
-  Those targets create or modify the spl/.config file.  Likewise, run
-  "make tpl/config", "make tpl/menuconfig", etc. for TPL.
+   * create a symbolic link "arch/${ARCH}/include/asm/arch" pointing to
+     the SoC/CPU specific header directory
+   * create include/config.h
+   * create include/autoconf.mk
+   * create spl/include/autoconf.mk (SPL and TPL only)
+   * create tpl/include/autoconf.mk (TPL only)
 
-- silentoldconfig
+   If we could completely switch to Kconfig in a long run
+   (i.e. remove all the include/configs/*.h), those additional processings
+   above would be removed.
 
-  This target updates .config, include/generated/autoconf.h and
-  include/configs/*.  In U-Boot, the same thing is done for SPL, TPL,
-  if supported by the target board.  Depending on whether CONFIG_SPL and
-  CONFIG_TPL are defined, "make silentoldconfig" iterates three times at most
-  changing the work directory.
-
-  To sum up, "make silentoldconfig" possibly updates:
-  - .config, include/generated/autoconf.h, include/config/*
-  - spl/.config, spl/include/generated/autoconf.h, spl/include/config/*
-    (in case CONFIG_SPL=y)
-  - tpl/.config, tpl/include/generated/autoconf.h, tpl/include/config/*
-    (in case CONFIG_TPL=y)
-
-- defconfig, <board>_defconfig
-
-  The target "<board>_defconfig" is used to create the .config based on the
-  file configs/<board>_defconfig.  The "defconfig" target is the same
-  except it checks for a file specified with KBUILD_DEFCONFIG environment.
-
-  Note:
-  The defconfig files are placed under the "configs" directory,
-  not "arch/$(ARCH)/configs".  This is because "ARCH" is not necessarily
-  given from the command line for the U-Boot configuration and build.
-
-  The defconfig file format in U-Boot has the special syntax; each line has
-  "<condition>:" prefix to show which image(s) the line is valid for.
-  For example,
-
-  CONFIG_FOO=100
-  S:CONFIG_FOO=200
-  T:CONFIG_FOO=300
-  ST:CONFIG_BAR=y
-  +S:CONFIG_BAZ=y
-  +T:CONFIG_QUX=y
-  +ST:CONFIG_QUUX=y
-
-  Here, the "<condition>:" prefix is one of:
-  None  - the line is valid only for Normal image
-  S:    - the line is valid only for SPL image
-  T:    - the line is valid only for TPL image
-  ST:   - the line is valid for SPL and TPL images
-  +S:   - the line is valid for Normal and SPL images
-  +T:   - the line is valid for Normal and TPL images
-  +ST:  - the line is valid for Normal, SPL and TPL images
-
-  So, if neither CONFIG_SPL nor CONFIG_TPL is defined, the defconfig file
-  has no "<condition>:" part and therefore has the same form as in Linux.
-  From the example defconfig shown above, three separete configuration sets
-  are generated and used for creating .config, spl/.config and tpl/.config.
-
-  - Input for the default configuration of Normal
-     CONFIG_FOO=100
-     CONFIG_BAZ=y
-     CONFIG_QUX=y
-     CONFIG_QUUX=y
-
-  - Input for the default configuration of SPL
-     CONFIG_FOO=200
-     CONFIG_BAR=y
-     CONFIG_BAZ=y
-     CONFIG_QUUX=y
-
-  - Input for the default configuration of TPL
-     CONFIG_FOO=300
-     CONFIG_BAR=y
-     CONFIG_QUX=y
-     CONFIG_QUUX=y
-
-- savedefconfig
-
-  This is the reverse operation of "make defconfig".  If neither CONFIG_SPL
-  nor CONFIG_TPL is defined in the .config file, it works like "savedefconfig"
-  in Linux Kernel: creates the minimal set of config based on the .config
-  and saves it into the "defconfig" file.  If CONFIG_SPL (and CONFIG_TPL) is
-  defined, the common lines among .config, spl/.config (and tpl/.config) are
-  coalesced together with "<condition:>" prefix for each line as shown above.
-  This file can be used as an input of "defconfig" target.
+- defconfig
+
+  In U-Boot, "make defconfig" is a shorthand of "make sandbox_defconfig"
+
+- <board>_defconfig
+
+  Now it works as in Linux.
+  The prefixes such as "+S:" in *_defconfig are deprecated.
+  You can simply remove the prefixes.  Do not add them for new boards.
 
 - <board>_config
 
   This does not exist in Linux's Kconfig.
+  "make <board>_config" works the same as "make <board>_defconfig".
   Prior to Kconfig, in U-Boot, "make <board>_config" was used for the
-  configuration.  It is still supported for backward compatibility and
-  its behavior is the same as "make <board>_defconfig".
+  configuration.  It is still supported for backward compatibility, so
+  we do not need to update the distro recipes.
+
+
+The other configuration targets work as in Linux Kernel.
 
 
 Migration steps to Kconfig
@@ -137,14 +73,10 @@ based configuration as follows:
 
 Configuration files for use in C sources
   - include/generated/autoconf.h     (generated by Kconfig for Normal)
-  - spl/include/generated/autoconf.h (generated by Kconfig for SPL)
-  - tpl/include/generated/autoconf.h (generated by Kconfig for TPL)
   - include/configs/<board>.h        (exists for all boards)
 
 Configuration file for use in makefiles
-  - include/config/auto.conf         (generated by Kconfig for Normal)
-  - spl/include/config/auto.conf     (generated by Kconfig for SPL)
-  - tpl/include/config/auto.conf     (generated by Kconfig for TPL)
+  - include/config/auto.conf         (generated by Kconfig)
   - include/autoconf.mk              (generated by the old config for Normal)
   - spl/include/autoconfig.mk        (generated by the old config for SPL)
   - tpl/include/autoconfig.mk        (generated by the old config for TPL)
@@ -215,8 +147,8 @@ TODO
   CONFIG_SYS_EXTRA_OPTIONS should not be used for new boards.
 
 - In the pre-Kconfig, a single board had multiple entries in the boards.cfg
-  file with differences in the option fields.  The correspoing defconfig files
-  were auto-generated when switching to Kconfig.  Now we have too many
+  file with differences in the option fields.  The corresponding defconfig
+  files were auto-generated when switching to Kconfig.  Now we have too many
   defconfig files compared with the number of the supported boards.  It is
   recommended to have only one defconfig per board and allow users to select
   the config options.
diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index 952ab871c2..cd8f4aeaf3 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -12,23 +12,30 @@ The list should be sorted in reverse chronological order.
 
 Board            Arch        CPU            Commit      Removed     Last known maintainer/contact
 =================================================================================================
-icecube_5200     powerpc     mpc5xxx        -           -           Wolfgang Denk <wd@denx.de>
-Lite5200         powerpc     mpc5xxx        -           -
-cpci5200         powerpc     mpc5xxx        -           -           Reinhard Arlt <reinhard.arlt@esd-electronics.com>
-mecp5200         powerpc     mpc5xxx        -           -           Reinhard Arlt <reinhard.arlt@esd-electronics.com>
-pf5200           powerpc     mpc5xxx        -           -           Reinhard Arlt <reinhard.arlt@esd-electronics.com>
-PM520            powerpc     mpc5xxx        -           -           Josef Wagner <Wagner@Microsys.de>
-Total5200        powerpc     mpc5xxx        -           -
-CATcenter        powerpc     ppc4xx         -           -
-PPChameleonEVB   powerpc     ppc4xx         -           -           Andrea "llandre" Marson <andrea.marson@dave-tech.it>
-P2020DS          powerpc     mpc85xx        -           -
-P2020COME        powerpc     mpc85xx        -           -           Ira W. Snyder <iws@ovro.caltech.edu>
-P2020RDB         powerpc     mpc85xx        -           -           Poonam Aggrwal <poonam.aggrwal@freescale.com>
-P2010RDB         powerpc     mpc85xx        -           -
-P1020RDB         powerpc     mpc85xx        -           -
-P1011RDB         powerpc     mpc85xx        -           -
-MPC8360EMDS      powerpc     mpc83xx        -           -           Dave Liu <daveliu@freescale.com>
-MPC8360ERDK      powerpc     mpc83xx        -           -           Anton Vorontsov <avorontsov@ru.mvista.com>
+hawkboard        arm         arm926ejs      -           -           Syed Mohammed Khasim <sm.khasim@gmail.com>:Sughosh Ganu <urwithsughosh@gmail.com>
+tnetv107x        arm         arm1176        -           -           Chan-Taek Park <c-park@ti.com>
+a320evb          arm         arm920t        -           -           Po-Yu Chuang <ratbert@faraday-tech.com>
+cm4008           arm         arm920t        -           -           Greg Ungerer <greg.ungerer@opengear.com>
+cm41xx           arm         arm920t        -           -
+dkb              arm         arm926ejs      -           -           Lei Wen <leiwen@marvell.com>
+jadecpu          arm         arm926ejs      -           -           Matthias Weisser <weisserm@arcor.de>
+icecube_5200     powerpc     mpc5xxx        37b608a5    2015-01-23  Wolfgang Denk <wd@denx.de>
+Lite5200         powerpc     mpc5xxx        37b608a5    2015-01-23
+cpci5200         powerpc     mpc5xxx        37b608a5    2015-01-23  Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+mecp5200         powerpc     mpc5xxx        37b608a5    2015-01-23  Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+pf5200           powerpc     mpc5xxx        37b608a5    2015-01-23  Reinhard Arlt <reinhard.arlt@esd-electronics.com>
+PM520            powerpc     mpc5xxx        a258e732    2015-01-23  Josef Wagner <Wagner@Microsys.de>
+Total5200        powerpc     mpc5xxx        ad734f7d    2015-01-23
+CATcenter        powerpc     ppc4xx         5344cc1a    2015-01-23
+PPChameleonEVB   powerpc     ppc4xx         5344cc1a    2015-01-23  Andrea "llandre" Marson <andrea.marson@dave-tech.it>
+P2020DS          powerpc     mpc85xx        168dcc6c    2015-01-23
+P2020COME        powerpc     mpc85xx        89123536    2015-01-23  Ira W. Snyder <iws@ovro.caltech.edu>
+P2020RDB         powerpc     mpc85xx        743d4815    2015-01-23  Poonam Aggrwal <poonam.aggrwal@freescale.com>
+P2010RDB         powerpc     mpc85xx        743d4815    2015-01-23
+P1020RDB         powerpc     mpc85xx        743d4815    2015-01-23
+P1011RDB         powerpc     mpc85xx        743d4815    2015-01-23
+MPC8360EMDS      powerpc     mpc83xx        8d1e3cb1    2015-01-23  Dave Liu <daveliu@freescale.com>
+MPC8360ERDK      powerpc     mpc83xx        8d1e3cb1    2015-01-23  Anton Vorontsov <avorontsov@ru.mvista.com>
 P3G4             powerpc     74xx_7xx       d928664f    2015-01-16  Wolfgang Denk <wd@denx.de>
 ZUMA             powerpc     74xx_7xx       d928664f    2015-01-16  Nye Liu <nyet@zumanetworks.com>
 ppmc7xx          powerpc     74xx_7xx       d928664f    2015-01-16
diff --git a/doc/device-tree-bindings/exynos/emmc-reset.txt b/doc/device-tree-bindings/exynos/emmc-reset.txt
new file mode 100644
index 0000000000..5e7ba26c27
--- /dev/null
+++ b/doc/device-tree-bindings/exynos/emmc-reset.txt
@@ -0,0 +1,15 @@
+* Samsung eMMC reset
+
+Some exynos boards require special handling of nRESET_OUT line for eMMC memory
+to perform complete reboot.
+
+Required properties:
+- compatible: should be "samsung,emmc-reset"
+- reset-gpio: gpio chip for eMMC reset.
+
+Example:
+
+emmc-reset {
+        compatible = "samsung,emmc-reset";
+        reset-gpio = <&gpk1 2 0>;
+};
diff --git a/doc/device-tree-bindings/gpio/gpio.txt b/doc/device-tree-bindings/gpio/gpio.txt
index b9bd1d64cf..f7a158d858 100644
--- a/doc/device-tree-bindings/gpio/gpio.txt
+++ b/doc/device-tree-bindings/gpio/gpio.txt
@@ -69,7 +69,8 @@ GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
 ----------------------------------
 
 A gpio-specifier should contain a flag indicating the GPIO polarity; active-
-high or active-low. If it does, the follow best practices should be followed:
+high or active-low. If it does, the following best practices should be
+followed:
 
 The gpio-specifier's polarity flag should represent the physical level at the
 GPIO controller that achieves (or represents, for inputs) a logically asserted
@@ -147,7 +148,7 @@ contains information structures as follows:
 	numeric-gpio-range ::=
 			<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
 	named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
-	gpio-phandle : phandle to pin controller node.
+	pinctrl-phandle : phandle to pin controller node
 	gpio-base : Base GPIO ID in the GPIO controller
 	pinctrl-base : Base pinctrl pin ID in the pin controller
 	count : The number of GPIOs/pins in this range
diff --git a/doc/driver-model/spi-howto.txt b/doc/driver-model/spi-howto.txt
index 5bc29ad65c..ee4abf4a8b 100644
--- a/doc/driver-model/spi-howto.txt
+++ b/doc/driver-model/spi-howto.txt
@@ -40,8 +40,8 @@ with only minor changes:
 
 Add these to your board config:
 
-#define CONFIG_DM_SPI
-#define CONFIG_DM_SPI_FLASH
+CONFIG_DM_SPI
+CONFIG_DM_SPI_FLASH
 
 
 2. Add the skeleton