This hooks dtc into Kbuild's dependency system.

Thus, for example, "make dtbs" will rebuild tegra-harmony.dtb if only
tegra20.dtsi has changed yet tegra-harmony.dts has not. The previous
lack of this feature recently caused me to have very confusing "git
bisect" results.

For ARM, it's obvious what to add to $(targets). I'm not familiar enough
with other architectures to know what to add there. Powerpc appears to
already add various .dtb files into $(targets), but the other archs may
need something added to $(targets) to work.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
[mmarek: Dropped arch/c6x part to avoid merging commits from the middle
of the merge window]
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Add a make rule to compile dt blobs for ARM.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NShawn Guo <shawn.guo@freescale.com>
Tested-by: NJason Liu <jason.hui@linaro.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

We have 'install' and 'zinstall' for installing Image and zImage
kernels, so add 'uinstall' to complete the set.

This allows developers to have a ~/bin/installkernel script which (eg)
copies the kernel to the tftp server automatically once the kernel
has built, resulting in a better workflow.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The code which makes up the zImage header intends to leave a
32-byte gap followed by a branch to the real entry point, a magic
number, and a word containing the absolute entry point address.

This gets messed up with with CONFIG_THUMB2_KERNEL, because the
size of the initial padding NOPs changes.

Instead, the header can be made fully compatible by restoring it to
ARM.

In the Thumb-2 case, we can replace the initial NOPs with a
sequence which switches to Thumb and jumps to the real entry point.

As a consequence, the zImage entry point is now always ARM, so no
special magic is needed any more for the uImage rules in the
Thumb-2 case.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Partially revert e69edc79, which introduced automatic zreladdr
support.  The change in the way the manual definition is defined
seems to be error and conflict prone.  Go back to the original way
we were handling this for the time being, while keeping the automatic
zreladdr facility.

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As long as the zImage is placed within the 128MB range from the start of
memory, ZRELADDR (Address where the decompressed kernel will be placed,
usually == PHYS_OFFSET + TEXT_OFFSET) can be determined at run-time by
masking PC with 0xf80000000.

Running through all the Makefile.boot, all those zreladdr-y
addresses == 0x[0-f][08]00_0000 + TEXT_OFFSET can be determined at
run-time.

Option CONFIG_AUTO_ZRELADDR and CONFIG_ZRELADDR are introduced,
CONFIG_ZRELADDR _must_ be explicitly specified if:

- ((zreladdr-y - TEXT_OFFSET) & ~0xf8000000) != 0, which means
  masking PC with 0xf8000000 will result in an incorrect address.
  Currently this is only a problem on u300.

- or the assumption of the zImage being loaded by the bootloader within
  the first 128MB of RAM is incorrect

- or when ZBOOT_ROM is used, where the above assumption is usually wrong.

[ukleinek: changed mask from 0xf0000000 to 0xf8000000 for mx1 and shark
+ some review fixes from the mailing list]
Original-Idea-and-Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NEric Miao <eric.miao@canonical.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

This allows U-Boot to branch to the kernel in Thumb-2 mode via
"mov pc, lr".
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

U-Boot puts an image at the load address specified in the uImage
header before jumping to the entry point.

In the CONFIG_ZBOOT_ROM case ZBOOT_ROM_TEXT is the right load
address.
Signed-off-by: NUwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The 'i' and 'zi' targets short-circuit the dependencies for
'install' and 'zinstall' targets; these are useful for
installing the kernel on platforms which have make but no
compiler installed.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The kbuild system takes advantage of an incorrect behavior in GNU make.
Once this behavior is fixed, all files in the kernel rebuild every time,
even if nothing has changed.  This patch ensures kbuild works with both
the incorrect and correct behaviors of GNU make.

For more details on the incorrect behavior, see:

http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html

Changes in this patch:
  - Keep all targets that are to be marked .PHONY in a variable, PHONY.
  - Add .PHONY: $(PHONY) to mark them properly.
  - Remove any $(PHONY) files from the $? list when determining whether
    targets are up-to-date or not.
Signed-off-by: NPaul Smith <psmith@gnu.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

We are coding the kernel link address into the makefiles, which is
invisibly dependent on PAGE_OFFSET.  If PAGE_OFFSET is changed, the
makefiles also need to be changed.

Make adjustments such that the makefiles encode just the offset from
PAGE_OFFSET for the kernel link address, and use PAGE_OFFSET in the
linker scripts directly.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!