The zImage loader needs to turn on the MMU in order to take
advantage of caching while decompressing the zImage.  Running this
in hyp mode would require the LPAE pagetable format to be
supported; to avoid this complexity, this patch switches out of hyp
mode, and returns back to hyp mode just before booting the kernel.

This implementation assumes that the Hyp mode view of memory and the
PL1 view of memory are coherent, providing that the MMU and caches
are off in both, as required by the boot protocol.  The zImage
decompression code must drain the write buffer on completion anyway, and
entry into Hyp mode should flush any prefetch buffer, avoiding hazards
associated with local write buffers and the pipeline.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Wire up support for the XZ decompressor
Signed-off-by: NImre Kaloz <kaloz@openwrt.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Otherwise, cross compilation may fail with error messages like:

...
size: arch/arm/boot/compressed/../../../../vmlinux: File format is ambiguous
size: Matching formats: elf32-littlearm elf32-littlearm-symbian elf32-littlearm-vxworks
  LD      arch/arm/boot/compressed/vmlinux
  arm-angstrom-linux-uclibcgnueabi-ld:--defsym _kernel_bss_size=: syntax error
Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Get rid of this complaint from dash:

    AS      arch/arm/boot/compressed/lib1funcs.o
  /bin/sh: 1: [: y: unexpected operator
    LD      arch/arm/boot/compressed/vmlinux
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Without CONFIG_AUTO_ZRELADDR being set the kernel needs a single
zreladdr for building zImages. Bail out if we detect multiple
zreladdrs without CONFIG_AUTO_ZRELADDR.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The rule to copy this file doesn't have to be forced.  However
lib1funcs.[So] have to be listed amongst the targets.

This prevents zImage from being recreated needlessly.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Tested-by: NDave Martin <dave.martin@linaro.org>
Tested-by: NThomas Abraham <thomas.abraham@linaro.org>

Some old bootloaders can't be updated to a device tree capable one,
yet they provide ATAGs with memory configuration, the ramdisk address,
the kernel cmdline string, etc.  To allow a device tree enabled
kernel to be used with such bootloaders, it is necessary to convert those
ATAGs into FDT properties and fold them into the DTB appended to zImage.

Currently the following ATAGs are converted:

	ATAG_CMDLINE
	ATAG_MEM
	ATAG_INITRD2

If the corresponding information already exists in the appended DTB, it
is replaced, otherwise the required node is created to hold it.

The code looks for ATAGs at the location pointed by the value of r2 upon
entry into the zImage code.  If no ATAGs are found there, an attempt at
finding ATAGs at the typical 0x100 offset from start of RAM is made.
Otherwise the DTB is left unchanged.

Thisstarted from an older patch from John Bonesio <bones@secretlab.ca>,
with contributions from David Brown <davidb@codeaurora.org>.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Tested-by: NDave Martin <dave.martin@linaro.org>
Tested-by: NThomas Abraham <thomas.abraham@linaro.org>

This is a small subset of string functions needed by commits to come.
Except for memcpy() which is unchanged from its original location, their
implementation is meant to be small, and -Os is enforced to prevent gcc
from doing pointless loop unrolling.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Tested-by: NDave Martin <dave.martin@linaro.org>
Tested-by: NThomas Abraham <thomas.abraham@linaro.org>

The appended DTB gets relocated with the decompressor code to get out
of the way of the decompressed kernel.  However the kernel's .bss section
may be larger than the relocated code and data, and then the DTB gets
overwritten.  Let's make sure the relocation takes care of moving zImage
far enough so no such conflict with .bss occurs.

Thanks to Tony Lindgren <tony@atomide.com> for figuring out this issue.

While at it, let's clean up the code a bit so that the wont_overwrite
symbol is used while determining if a conflict exists, making the above
change more precise as well as eliminating some ARM/THUMB alternates.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Tested-by: NDave Martin <dave.martin@linaro.org>
Tested-by: NThomas Abraham <thomas.abraham@linaro.org>

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile
ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into
MERAM and then jumping to it.  This portion contains loader code which
copies the entire image to SDRAM and jumps to it. From there the zImage
boot code proceeds as normal, uncompressing the image into its final
location and then jumping to it.

Cc: Paul Mundt <lethal@linux-sh.org>
Acked-by: NMagnus Damm <magnus.damm@gmail.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

To be able to relocate the .bss section at run time independently from
the rest of the code, we must make sure that no GOTOFF relocations are
used with .bss symbols.  This usually means that no global variables can
be marked static unless they're also const.

To enforce this, suffice to fail the build whenever a private symbol
is allocated to .bss and list those symbols for convenience.

The user_stack and user_stack_end labels in head.S were converted into
non exported symbols to remove false positives.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>

In commit d239b1dc the hardcoded 4x estimate for the decompressed
kernel size was replaced by the exact Image file size and passed to
the linker as a symbol value.  Turns out that this is unneeded as the
size is already included at the end of the compressed piggy data.
For those compressed formats that don't include this data, the build
system already takes care of appending it using size_append in
scripts/Makefile.lib.  So let's use that instead.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>

With ARMv5+ and EABI, the compiler expects a 64-bit aligned stack so
instructions like STRD and LDRD can be used.  Without this, mysterious
boot failures were seen semi randomly with the LZMA decompressor.

While at it, let's align .bss as well.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
CC: stable@kernel.org

Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
Signed-off-by: Nmatt mooney <mfm@muteddisk.com>
Acked-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

The simply expanded variable may be evaluated before the target file for
the stat command is up to date or even exists.  Switching to a recursively
expanded variable move the execution of the stat command to the location
where LDFLAGS_vmlinux is actually used, fixing the dependency issue
introduced by patch #6746/1.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We currently presume a 4x expansion to guess the decompressed kernel size
in order to determine if the decompressed kernel is in conflict with
the location where zImage is loaded.  This guess may cause many issues
by overestimating the final kernel image size:

- This may force a needless relocation if the location of zImage was
  fine, wasting some precious microseconds of boot time.

- The relocation may be located way too far, possibly overwriting the
  initrd image in RAM.

- If the kernel image includes a large already-compressed initramfs image
  then the problem is even more exacerbated.

And if by some strange means the 4x guess is too low then we may overwrite
ourselves with the decompressed image.

So let's use the exact decompressed kernel image size instead.  For that
we need to rely on the stat command, but this is hardly a new build
dependency as the kernel already depends on many external commands
to be built provided by the coreutils package where stat is found.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This adds support for the family of Systems-on-Chip produced initially
by VIA and now its subsidiary WonderMedia that have recently become
widespread in lower-end Chinese ARM-based tablets and netbooks.

Support is included for both VT8500 and WM8505, selectable by a
configuration switch at kernel build time.

Included are basic machine initialization files, register and
interrupt definitions, support for the on-chip interrupt controller,
high-precision OS timer, GPIO lines, necessary macros for early debug,
pulse-width-modulated outputs control, as well as platform device
configurations for the specific drivers implemented elsewhere.
Signed-off-by: NAlexey Charkov <alchark@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This allows a ROM-able zImage to be written to MMC and
for SuperH Mobile ARM to boot directly from the MMCIF
hardware block.

This is achieved by the MaskROM loading the first portion
of the image into MERAM and then jumping to it. This portion
contains loader code which copies the entire image to SDRAM
and jumps to it. From there the zImage boot code proceeds
as normal, uncompressing the image into its final location
and then jumping to it.

Cc: Magnus Damm <magnus.damm@gmail.com>

Russell, please consider merging this for 2.6.38.

This patch depends on:
* "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h"
  which will be merged though Paul Mundt's rmobile sh-2.6.
  The absence of this patch will break the build if
  the (new) CONFIG_ZBOOT_ROM_MMCIF option is set.
  There are no subtle side-effects.

v2:
Addressed comments by Magnus Damm
* Fix copyright in vrl4.c
* Fix use of #define CONFIG_ZBOOT_ROM_MMCIF in mmcif-sh7372.c
* Initialise LED GPIO lines in head-ap4evb.txt instead of mmcif-sh7372.c
  as this is considered board-specific.

v3:
Addressed comments made in person by Magnus Damm
* Move mmcif_loader to be earlier in the image and
  reduce the number of blocks of boot program loaded by the MaskRom
  from 40 to 8 accordingly.
* Move LED GPIO initialisation into mmcif_progress_init
  - This leaves the partner jet script unbloated
Other
* inline mmcif_update_progress so it is a static inline in a header file

v4:
* Use htole16() and htole32() in v4rl.c to ensure
  that the output is little endian

v5:
Addressed comments by Russell King
* Simplify assembly code
* Jump to code rather than an address <- bug fix
* Use (void __iomem *) as appropriate
Roll in mackerel support
* This was previously a separate patch, only because of the order
  in which this code was developed
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When CONFIG_ZBOOT_ROM is selected, the resulting zImage file will be small
boot loader and may be burned to rom or flash.

This is the non-board-specific framework portion of this patch-set.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Jonathan Cameron reports that when using the environment
variable KCONFIG_CONFIG, he encounters this error:

make[2]: *** No rule to make target `.config', needed by `arch/arm/boot/compressed/vmlinux.lds'
Reported-by: NJonathan Cameron <jic23@cam.ac.uk>
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>

With kexec-based kernel boot loader on Zaurus, the machine ID is
actually correctly passed, and head-sharpsl.S is not necessary.
Introduce PXA_SHARPSL_DETECT_MACH_ID, and include head-sharpsl.S
only when that's explicitly enabled.
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Update the compressed boot Makefile for ARM to
remove files during clean.
Signed-off-by: NMagnus Damm <damm@opensource.se>
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>

The only reference in arch/arm/boot/compressed to PARAMS_PHYS is
params() in head.S, which can be directly converted to the exact
address as specified by arch/arm/mach-rpc/Makefile.boot.
Signed-off-by: NEric Miao <eric.miao@canonical.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

The only user of initrd_phys is arch/arm/boot/bootp/init.S which still
gets the value passed to.
Acked-by: NEric Miao <eric.miao@canonical.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

This hasn't been actively maintained for a long time, only receiving
the occasional build update when things break.  I doubt anyone has
one of these on their desks anymore.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch allows using a kernel image compressed with LZMA on ARM.
Extracting the image is fairly slow, but it might be useful on machines
with a very limited amount of storage, as the size benefit is quite
significant (about 25% smaller with LZMA compared to GZIP)
Tested-by: NMartin Michlmayr <tbm@cyrius.com>
Tested-by: NPaulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: NAlbin Tonnerre <albin.tonnerre@free-electrons.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We used to build decompressors with -Dstatic= to avoid any local data
being generated.  The problem is that local data generates GOTOFF
relocations, which means we can't relocate the data relative to the
text segment.

Global data, on the other hand, goes through the GOT, and can be
relocated anywhere.

Unfortunately, with the new decompressors, this presents a problem
since they declare static data within functions, and this leads to
stack overflow.

Fix this by separating out the decompressor code into a separate file,
and removing 'static' from BSS data in misc.c.

Also, discard the .data section - this means that should we end up
with read/write initialized data, the decompressor will fail to link
and the problem will be obvious.
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

- changes to ach/arch/boot/Makefile to make it easier to add new
   compression types
 - new piggy.lzo.S necessary for lzo compression
 - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
   gzip, depending on the config
 - Kconfig support
Signed-off-by: NAlbin Tonnerre <albin.tonnerre@free-electrons.com>
Tested-by: NWu Zhangjin <wuzhangjin@gmail.com>
Acked-by: N"H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Tested-by: NRussell King <rmk@arm.linux.org.uk>
Acked-by: NRussell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Starting with ARMv6, the CPUs support the BE-8 variant of big-endian
(byte-invariant). This patch adds the core support:

- setting of the BE-8 mode via the CPSR.E register for both kernel and
  user threads
- big-endian page table walking
- REV used to rotate instructions read from memory during fault
  processing as they are still little-endian format
- Kconfig and Makefile support for BE-8. The --be8 option must be passed
  to the final linking stage to convert the instructions to
  little-endian
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The CLPS7500 platform has not built since 2.6.22-git7 and there
seems to be no interest in fixing it.  So, remove the platform
support.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Due to confusion between the ftrace infrastructure and the gcc profiling
tracer "ftrace", this patch renames the config options from FTRACE to
FUNCTION_TRACER.  The other two names that are offspring from FTRACE
DYNAMIC_FTRACE and FTRACE_MCOUNT_RECORD will stay the same.

This patch was generated mostly by script, and partially by hand.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This allows assembly files to be crafted to cover all ARM CPU types
rather than erroring out on instructions only in later CPUs.  We
are careful in these files to only execute CPU specific code when
the CPU ID says we can.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Core ftrace support for the ARM architecture, which includes support
for dynamic function tracing.
Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

AT91RM9200 needlessly verifies machine-type numbers of
supported / known platforms and overwrites it for unknown
ones. Remove it.
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The variable CFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of CFLAGS with KBUILD_CFLAGS all over the
tree and enabling one to use:
make CFLAGS=...
to specify additional gcc commandline options.

One usecase is when trying to find gcc bugs but other
use cases has been requested too.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k

Test was simple to do a defconfig build, apply the patch and check
that nothing got rebuild.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This is to avoid a compiler warning for overriding the built-in "putc"
function.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

font_acorn_8x8.o was being built in drivers/video/console/ twice
during a build _in the same location_ - once for the kernel proper,
and once for the decompressor.  The result is when you came to run an
install target, the kernel was always rebuilt due to this file
apparantly having been built with different compiler arguments.

Solve this by making a local copy at build time in the decompressor's
directory.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>