Bringing in the MMC tree means that CONFIG_BOUNCE_BUFFER needed to be
added to include/configs/exynos5-dt.h now.

Conflicts:
	include/configs/exynos5250-dt.h

Signed-off-by: Tom Rini <trini@ti.com>

ARM64 uses the newer RELA-style relocations rather than the older REL.
RELA relocations have an addend in the relocation struct, rather than
expecting the loader to read a value from the location to be updated.

While this is beneficial for ordinary program loading, it's problematic
for U-Boot because the location to be updated starts out with zero,
rather than a pre-relocation value.  Since we need to be able to run C
code before relocation, we need a tool to apply the relocations at
build time.

In theory this tool is applicable to other newer architectures (mainly
64-bit), but currently the only relocations it supports are for arm64,
and it assumes a 64-bit little-endian target.  If the latter limitation
is ever to be changed, we'll need a way to tell the tool what format
the image is in.  Eventually this may be replaced by a tool that uses
libelf or similar and operates directly on the ELF file.  I've written
some code for such an approach but libelf does not make it easy to poke
addresses by memory address (rather than by section), and I was
hesitant to write code to manually parse the program headers and do the
update outside of libelf (or to iterate over sections) -- especially
since it wouldn't get test coverage on things like binaries with
multiple PT_LOAD segments.  This should be good enough for now to let
the manual relocation stuff be removed from the arm64 patches.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: David Feng <fenghua@phytium.com.cn>

Adding the base patch for Exynos based SMDK5420.
This shall enable compilation and basic boot support for
SMDK5420.

Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

Given a multi-file image created through the mkimage's -d option:

  $ mkimage -A x86 -O linux -T multi -n x86 -d vmlinuz:initrd.img:System.map \
  multi.img

  Image Name:   x86
  Created:      Thu Jul 25 10:29:13 2013
  Image Type:   Intel x86 Linux Multi-File Image (gzip compressed)
  Data Size:    13722956 Bytes = 13401.32 kB = 13.09 MB
  Load Address: 00000000
  Entry Point:  00000000
  Contents:
     Image 0: 4040128 Bytes = 3945.44 kB = 3.85 MB
     Image 1: 7991719 Bytes = 7804.41 kB = 7.62 MB
     Image 2: 1691092 Bytes = 1651.46 kB = 1.61 MB

It is possible to perform the innverse operation -- extracting any file from
the image -- by using the dumpimage's -i option:

  $ dumpimage -i multi.img -p 2 System.map

Although it's feasible to retrieve "data files" from image through scripting,
the requirement to embed tools such 'dd', 'awk' and 'sed' for this sole purpose
is cumbersome and unreliable -- once you must keep track of file sizes inside
the image. Furthermore, extracting data files using "dumpimage" tool is faster
than through scripting.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

In order to avoid duplicating code and keep only one point of modification,
the functions, structs and defines useful for "dumpimage" were moved from
"mkimage" to a common module called "imagetool".

This modification also weakens the coupling between image types (FIT, IMX, MXS,
and so on) and image tools (mkimage and dumpimage). Any tool may initialize the
"imagetool" through register_image_tool() function, while the image types
register themselves within an image tool using the register_image_type()
function:

                                                      +---------------+
                                               +------|   fit_image   |
 +--------------+          +-----------+       |      +---------------+
 |    mkimage   |--------> |           | <-----+
 +--------------+          |           |              +---------------+
                           | imagetool | <------------|    imximage   |
 +--------------+          |           |              +---------------+
 |  dumpimage   |--------> |           | <-----+
 +--------------+          +-----------+       |      +---------------+
                                               +------| default_image |
                                                      +---------------+

          register_image_tool()           register_image_type()

Also, the struct "mkimage_params" was renamed to "image_tool_params" to make
clear its general purpose.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

In-tree build:
  - Do not create a symbolic link
      from include/asm to arch/${ARCH}/include/asm
  - Add ${SRCTREE}/arch/arm/include into the header search path

Out-of-tree build:
  - Do not create a directory ${OBJTREE}/include2
  - Do not create a symbolic link
      from ${OBJTREE}/include2/asm to ${SRCTREE}/arch/${ARCH}/include/asm
  - Add ${SRCTREE}/arch/arm/include into the header search path

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Drop changes for PEP 4 following python tools]
Signed-off-by: Tom Rini <trini@ti.com>

Conflicts:
	tools/Makefile

Conflicts:
	drivers/serial/serial.c

The conflict above was a trivial case of adding one init
function in each branch, and manually resolved in merge.

Fix the lists of files so they are in order again.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Stefano Babic <sbabic@denx.de>