When enabling the MMU for ARMv7 CPUs, the decompressor does not touch
the ttbcr register, assuming that it will be zeroed (N == 0, EAE == 0).
Given that only EAE is defined as 0 for non-secure copies of the
register (and a bootloader such as kexec may leave it set to 1 anyway),
we should ensure that we reset the register ourselves before turning on
the MMU.

This patch zeroes TTBCR.EAE and TTBCR.N prior to enabling the MMU for
ARMv7 cores in the decompressor, configuring us exclusively for 32-bit
translation tables via TTBR0.

Cc: <stable@vger.kernel.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NMatthew Leach <matthew.leach@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We setup identity MMU mappings across the entire 4GB of space, which
are permissionless because the domain is set to manager.

This unfortunately allows ARMv6 and later CPUs to speculatively
prefetch from the entire address space, which can cause undesirable
side effects if those regions contain devices.

As we setup the mappings with read/write permission, we can switch
the domain to client mode, and then use the XN bit for ARMv6 and
above to control speculative prefetch to non-RAM areas.
Reported-by: NR Sricharan <r.sricharan@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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

atags_to_fdt() returns 1 when it fails to find a valid FDT signature.
The CONFIG_ARM_ATAG_DTB_COMPAT code is supposed to retry with another
location, but only does so when the initial call doesn't fail.

Fix this by using the correct condition in the assembly code.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch changes the ARCH name to "ARCH_S3C24XX" for Samsung
S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443,
and S3C2450 SoCs so that we can merge the mach-xxx directories
and plat-s3c24xx dir. to just one mach-s3c24xx for them.

I think this should be sent to upstream via samsung tree because
this touches many samsung stuff.

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Ball <cjb@laptop.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
[for the gadget part:]
Acked-by: NFelipe Balbi <balbi@ti.com>
[for the framebuffer (video) part:]
Acked-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
[For the watchdog-part:]
Acked-by: NWim Van Sebroeck <wim@iguana.be>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Before we enable the MMU, we must ensure that the TTBR registers contain
sane values. After the MMU has been enabled, we jump to the *virtual*
address of the following function, so we also need to ensure that the
SCTLR write has taken effect.

This patch adds ISB instructions around the SCTLR write to ensure the
visibility of the above.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

If TEXT_OFFSET is too large (e.g. like on MSM) the resulting immediate
argument gets wider than 8 bits.

Noticed by David Brown <davidb@codeaurora.org>
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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>

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 patch provides the ability to boot using a device tree that is appended
to the raw binary zImage (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
Signed-off-by: NJohn Bonesio <bones@secretlab.ca>
[nico: ported to latest zImage changes plus additional cleanups/improvements]
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
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>

Currently, the documented kernel entry requirements are not
explicit about whether the kernel should be entered in ARM or
Thumb, leading to an ambiguitity about how to enter Thumb-2
kernels.  As a result, the kernel is reliant on the zImage
decompressor to enter the kernel proper in the correct instruction
set state.

This patch changes the boot entry protocol for head.S and Image to
be the same as for zImage: in all cases, the kernel is now entered
in ARM.

Documentation/arm/Booting is updated to reflect this new policy.

A different rule will be needed for Cortex-M class CPUs as and when
support for those lands in mainline, since these CPUs don't support
the ARM instruction set at all: a note is added to the effect that
the kernel must be entered in Thumb on such systems.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It is easy to mis-maintain the proc_types table such that the
entries become wrongly-sized and misaligned when the kernel is
built in Thumb-2.

This patch adds an assembly-time check which will turn most common
size/alignment mistakes in this table into build failures, to avoid
having to debug the boot-time kernel hang which would happen if the
resulting kernel were actually booted.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit af3e4fd3 "ARM: 6859/1: Add writethrough dcache support for
ARM926EJS processor" broke Thumb2 compilation by omitting to maintain
the wide encoding for the added branch instructions which made the
ARM926EJ-S record smaller than expected, breaking the record walk code.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Cc: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The ARM kernel supports writethrough data cache via the
CONFIG_CPU_DCACHE_WRITETHROUGH option.  However, that
functionality wasn't implemented in the arch/arm/boot/compressed
code.  It is now necessary due to a new ARM926EJS processor
that has an issue with writeback data cache.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
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>

For correctness, the initial page table located right before the
decompressed kernel should be considered when determining if relocation
is required.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>

If the zImage load address is slightly below the relocation address,
there is a risk for the copied data to overwrite the copy loop or
cache flush code that the relocation process requires.  Always
bump the relocation address by the size of that code to avoid this
issue.

Noticed by Tony Lindgren <tony@atomide.com>.

While at it, let's start the copy from the restart symbol which makes
the above code size computation possible by the assembler directly
(same sections), given that we don't need to preserve the code before
that point anyway. And therefore we don't need to carry the _start
pointer in r5 anymore.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>

Otherwise cache_clean_flush can overwrite some of the relocated
area depending on where the kernel image gets loaded. This fixes
booting on n900 after commit 6d7d0ae5
(ARM: 6750/1: improvements to compressed/head.S).

Thanks to Aaro Koskinen <aaro.koskinen@nokia.com> for debugging
the address of the relocated area that gets corrupted, and to
Nicolas Pitre <nicolas.pitre@linaro.org> for the other uncompress
related fixes.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

The Marvell PJ4 is ARMv7 capable, so we don't support it in
ARMv6 mode anymore.
Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
Acked-by: NSaeed Bishara <saeed.bishara@gmail.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>

The inline assembly differences for v6 vs. v7 are purely
optimizations. On a v7 processor, an mrc with the pc sets the
condition codes to the 28-31 bits of the register being read. It
just so happens that the TX/RX full bits the DCC support code is
testing for are high enough in the register to be put into the
condition codes. On a v6 processor, this "feature" isn't
implemented and thus we have to do the usual read, mask, test
operations to check for TX/RX full. Thus, we can drop the v7
implementation and just use the v6 implementation for both.

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

In the case of a conflict between the memory used by the compressed
kernel with its decompressor code and the memory used for the
decompressed kernel, we currently store the later after the former and
relocate it afterwards.

This would be more efficient to do this the other way around i.e.
relocate the compressed data up front instead, resulting in a smaller
copy.  That also has the advantage of making the code smaller and more
straight forward.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some installers would binary patch the kernel zImage to replace the
first few nops with custom instructions.  This breaks the Thumb2 kernel
as the mode switch is right at the beginning.  Let's move it towards the
end of the nop sequence instead.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Introduce a CPU_V6K configuration option for platforms to select if they
have a V6K CPU core.  This allows us to identify whether we need to
support ARMv6 CPUs without the V6K SMP extensions at build time.

Currently CPU_V6K is just an alias for CPU_V6, and all places which
reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).

Select CPU_V6K from platforms which are known to be V6K-only.
Acked-by: NTony Lindgren <tony@atomide.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Tested-by: NWill Deacon <will.deacon@arm.com>
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>

Some instruction operand combinations are used here which are nor
permitted in Thumb-2.

In particular, most uses of pc as an operand are disallowed in
Thumb-2, and deprecated in ARM from ARMv7 onwards.

The modified code introduced by this patch should be compatible
with all architecture versions >= v3, with or without
CONFIG_THUMB2_KERNEL.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
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>

The .stack section doesn't contain any contents, and doesn't require
initialization either.  Rather than marking the output section with
'NOLOAD' but still having it exist in the object files, mark it with
%nobits which avoids the assembler marking the section with 'CONTENTS'.
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>

"ARM: Auto calculate ZRELADDR and provide option for exceptions" broke
the Thumb-2 decompressor because it removed an entry in the LC0 table
but didn't adjust the offset the Thumb-2 code uses to load the SP from
that table.

Fix it, and also change the ARM code to use the separate SP-load since
ARM instructions that include the SP in the LDM register list are
deprecated.
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NRabin Vincent <rabin@rab.in>
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>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

This adds missing registers to the list of corrupted registers and
removes a wrong comment about r9 on entry

While at it the formatting of the comment to cache_off is changed to
resemble the other two.
Acked-by: NEric Miao <eric.miao@canonical.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Probably the register content for cache operations is "don't care" in
practice, but as r1 is explicitly zeroed, use that one.
Acked-by: NEric Miao <eric.miao@canonical.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

__armv3_mpu_cache_on seems broken.  As there is noone around who knows
about these machines just keep the code as is but point out the strange
things.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Acked-by: NEric Miao <eric.miao@canonical.com>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Update CPUID pattern of PXA9xx in head.S and fix the duplicate
entries for pxa935.
Signed-off-by: NHaojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

98e12b5a ("ARM: Fix decompressor's kernel size estimation for
ROM=y") broke the Thumb-2 decompressor because it added an entry in the
LC0 table but didn't adjust the offset the Thumb-2 code uses to load the
SP from that table.  Fix it.

Cc: stable <stable@kernel.org>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This got broken with commit 0e056f20Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 2552fc27 changed the way the decompressor decides if it is safe
to decompress the kernel directly to its final location.  Unfortunately,
it took the top of the compressed data as being the stack pointer,
which it is for ROM=n cases.  However, for ROM=y, the stack pointer
is not relevant, and results in the wrong answer.

Fix this by explicitly storing the end of the biggybacked data in the
decompressor, and use that to calculate the compressed image size.

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