In the decompressor's head.S we need to start with an instruction that
is some kind of NOP, but also mimics as the PE/COFF header, when the
kernel is linked as an UEFI application. The clever solution here is
"tstne r0, #0x4d000", which in the worst case just clobbers the
condition flags, and bears the magic "MZ" signature in the lowest 16 bits.

However the encoding used (0x13105a4d) is actually not valid, since bits
[15:12] are supposed to be 0 (written as "(0)" in the ARM ARM).
Violating this is UNPREDICTABLE, and *can* trigger an UNDEFINED
exception. Common Cortex cores seem to ignore those bits, but QEMU
chooses to trap, so the code goes fishing because of a missing exception
handler at this point. We are just saved by the fact that commonly (with
-kernel or when running from U-Boot) the "Z" bit is set, so the
instruction is never executed. See [0] for more details.

To make things more robust and avoid UNPREDICTABLE behaviour in the
kernel code, lets replace this with a "two-instruction NOP":
The first instruction is an exclusive OR, the effect of which the second
instruction reverts. This does not leave any trace, neither in a
register nor in the condition flags. Also it's a perfectly valid
encoding. Kudos to Peter Maydell for coming up with this gem.

[0] https://lore.kernel.org/qemu-devel/YTPIdbUCmwagL5%2FD@os.inf.tu-dresden.de/T/

Link: https://lore.kernel.org/linux-arm-kernel/20210908162617.104962-1-andre.przywara@arm.com/T/

Fixes: 81a0bc39 ("ARM: add UEFI stub support")
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reported-by: NAdam Lackorzynski <adam@l4re.org>
Suggested-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>

It was observed that decompressor running on hardware implementing ARM v8.2
Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest,
would stuck just after:

Uncompressing Linux... done, booting the kernel.

The reason is that it clears nTLSMD bit when disabling caches:

  nTLSMD, bit [3]

  When ARMv8.2-LSMAOC is implemented:

    No Trap Load Multiple and Store Multiple to
    Device-nGRE/Device-nGnRE/Device-nGnRnE memory.

    0b0 All memory accesses by A32 and T32 Load Multiple and Store
        Multiple at EL1 or EL0 that are marked at stage 1 as
        Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and
        generate a stage 1 Alignment fault.

    0b1 All memory accesses by A32 and T32 Load Multiple and Store
        Multiple at EL1 or EL0 that are marked at stage 1 as
        Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped.

  This bit is permitted to be cached in a TLB.

  This field resets to 1.

  Otherwise:

  Reserved, RES1

So as effect we start getting traps we are not quite ready for.

Looking into history it seems that mask used for SCTLR clear came from
the similar code for ARMv4, where bit[3] is the enable/disable bit for
the write buffer. That not applicable to ARMv7 and onwards, so retire
that bit from the masks.

Fixes: 7d09e854 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format")
Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Currently, the start address of physical memory is obtained by masking
the program counter with a fixed mask of 0xf8000000.  This mask value
was chosen as a balance between the requirements of different platforms.
However, this does require that the start address of physical memory is
a multiple of 128 MiB, precluding booting Linux on platforms where this
requirement is not fulfilled.

Fix this limitation by validating the masked address against the memory
information in the passed DTB.  Only use the start address
from DTB when masking would yield an out-of-range address, prefer the
traditional method in all other cases.  Note that this applies only to the
explicitly passed DTB on modern systems, and not to a DTB appended to
the kernel, or to ATAGS.  The appended DTB may need to be augmented by
information from ATAGS, which may need to rely on knowledge of the start
address of physical memory itself.

This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
i.e. not at a multiple of 128 MiB.
Suggested-by: NNicolas Pitre <nico@fluxnic.net>
Suggested-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Take the 4 instruction byte swapping sequence from the decompressor's
head.S, and turn it into a rev_l GAS macro for general use. While
at it, make it use the 'rev' instruction when compiling for v6 or
later.
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The DTB magic marker is stored as a 32-bit big-endian value, and thus
depends on the CPU's endianness.  Add a macro to define this value in
native endianness, to reduce #ifdef clutter and (future) duplication.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The dbgadtb macro is passed the size of the appended DTB, not the end
address.

Fixes: c03e4147 ("ARM: 9010/1: uncompress: Print the location of appended DTB")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

DTB stores all values as 32-bit big-endian integers.
Add a macro to convert such values to native CPU endianness, to reduce
duplication.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Replace the open coded calculations of the actual physical address
of the KVM stub vector table with a single adr_l invocation.
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

The ARM 'adrl' pseudo instruction is a bit problematic, as it does not
exist in Thumb mode, and it is not implemented by Clang either. Since
the Thumb variant has a slightly bigger range, it is sometimes necessary
to emit the 'adrl' variant in ARM mode where Thumb mode can use adr just
fine. However, that still leaves the Clang issue, which does not appear
to be supporting this any time soon.

So let's switch to the adr_l macro, which works for both ARM and Thumb,
and has unlimited range.
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Commit

  db227c19 ("ARM: 8985/1: efi/decompressor: deal with HYP mode boot gracefully")

updated the EFI entry code to permit firmware to invoke the EFI stub
loader in HYP mode, with the MMU either enabled or disabled, neither
of which is permitted by the EFI spec, but which does happen in the
field.

In the MMU on case, we remain in HYP mode as configured by the firmware,
and rely on the fact that any HVC instruction issued in this mode will
be dispatched via the SVC slot in the HYP vector table. However, this
slot will point to a Thumb2 symbol if the kernel is built in Thumb2
mode, and so we have to configure HSCTLR to ensure that the exception
handlers are invoked in Thumb2 mode as well.

Fixes: db227c19 ("ARM: 8985/1: efi/decompressor: deal with HYP mode boot gracefully")
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Add the required malloc size to the decompressor kexec size structure.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

When using the kernel with an appended DTB it is useful to
know where this will end up in the physical memory at the
time the kernel boots.

We add a debug print macro that will help out with this.
Here is a sample debug print after passing -DDEBUG to head.S
during compilation:

DTB:0x40CEBA70 (0x000051B5)
C:0x402080C0-0x40CF0CE0->0x41801D00-0x422EA920
DTB:0x422E56B0 (0x00005262)

This means that the appended DTB is first found after the
compressed kernel at 0x40CEBA70 of size 0x51B5 and then
after the compressed kernel is moved to 0x41801D00
it is found again at 0x422E56B0 and is there size 0x5262.

The growth in size of the FDT is due to the call to
atags_to_fdt() that augments the DTB with ATAG information.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

This drops some whitespace from the debug message about
where we move the compressed kernel: r after the message
is completely surplus since the putc routine will anyway
add r after n, and the initial linefeed just assumes
that this will always be the first message on the console,
which is not certain to be true.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

For some platforms such as Qualcomm we need to wait for the
UART to be ready before writing characters to the UART
in the same manner as the macro in debug.S used with the
main "Uncompressing Linux ..." text. Pass an extra temporary
variable to writeb and make it call waituarttxrdy and
busyuart just like the other decomression messages.

Optionally it will also call waituartcts if and only if
CONFIG_DEBUG_UART_FLOW_CONTROL is selected.

After this the decompression debug messages work fine on
Qualcomm platforms if you compile head.S with -DDEBUG.

Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The debug macros debug_reloc_start and debug_reloc_end were
rendered unused in commit 6d7d0ae5
"ARM: 6750/1: improvements to compressed/head.S".

Later on a different debug macro named dbgkc was introduced
in commit f3c89992
"ARM: 8786/1: Debug kernel copy by printing".

Delete the dead debug code.

Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

EFI on ARM only supports short descriptors, and given that it mandates
that the MMU and caches are on, it is implied that booting in HYP mode
is not supported.

However, implementations of EFI exist (i.e., U-Boot) that ignore this
requirement, which is not entirely unreasonable, given that it makes
HYP mode inaccessible to the operating system.

So let's make sure that we can deal with this condition gracefully.
We already tolerate booting the EFI stub with the caches off (even
though this violates the EFI spec as well), and so we should deal
with HYP mode boot with MMU and caches either on or off.

- When the MMU and caches are on, we can ignore the HYP stub altogether,
  since we can carry on executing at HYP. We do need to ensure that we
  disable the MMU at HYP before entering the kernel proper.

- When the MMU and caches are off, we have to drop to SVC mode so that
  we can set up the page tables using short descriptors. In this case,
  we need to install the HYP stub as usual, so that we can return to HYP
  mode before handing over to the kernel proper.
Tested-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The decompressor can load from anywhere in memory, and the only reason
the EFI stub code relocates it is to ensure it appears within the first
128 MiB of memory, so that the uncompressed kernel ends up at the right
offset in memory.

We can short circuit this, and simply jump into the decompressor startup
code at the point where it knows where the base of memory lives. This
also means there is no need to disable the MMU and caches, create new
page tables and re-enable them.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>

The remaining contents of LC0 are only used after the point in the
decompressor startup code where we enter via 'wont_overwrite'. So
move the loading of the LC0 structure after it. This will allow us
to jump to wont_overwrite directly from the EFI stub, and execute
the decompressor in place at the offset it was loaded by the UEFI
firmware.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>

In preparation of moving the handling of the LC0 object to a later stage
in the decompressor startup code, move out _edata and the initial value
of the stack pointer, which are needed earlier than the remaining
contents of LC0.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>

Before breaking up LC0 into different pieces, move out the variable
that is already place-relative (given that it subtracts 'restart' in
the expression) and so its value does not need to be added to the
runtime address of the LC0 symbol itself.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NNicolas Pitre <nico@fluxnic.net>

Commit

  0698fac4 ("efi/arm: Clean EFI stub exit code from cache instead of avoiding it")

introduced a PC-relative reference to 'call_cache_fn' into
efi_enter_kernel(), which lives way at the end of head.S. In some cases,
the ARM version of the ADR instruction does not have sufficient range,
resulting in a build error:

  arch/arm/boot/compressed/head.S:1453: Error: invalid constant (fffffffffffffbe4) after fixup

ARM defines an alternative with a wider range, called ADRL, but this does
not exist for Thumb-2. At the same time, the ADR instruction in Thumb-2
has a wider range, and so it does not suffer from the same issue.

So let's switch to ADRL for ARM builds, and keep the ADR for Thumb-2 builds.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Tested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200409130434.6736-6-ardb@kernel.org

The following commit:

  c7225494 ("efi/arm: Work around missing cache maintenance in decompressor handover")

modified the EFI handover code written in assembler to work around the
missing cache maintenance of the piece of code that is executed after the
MMU and caches are turned off.

Due to the fact that this sequence incorporates a subroutine call, cleaning
that code from the cache is not a matter of simply passing the start and end of
the currently running subroutine into cache_clean_flush(), which is why
instead, the code jumps across into the cleaned copy of the image.

However, this assumes that this copy is executable, and this means we
expect EFI_LOADER_DATA regions to be executable as well, which is not
a reasonable assumption to make, even if this is true for most UEFI
implementations today.

So change this back, and add a cache_clean_flush() call to cover the
remaining code in the subroutine, and any code it may execute in the
context of cache_off().
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20200228121408.9075-5-ardb@kernel.org

Update the v7 cache_clean_flush routine to take into account the
memory range passed in r0/r1, and perform cache maintenance by
virtual address on this range instead of set/way maintenance, which
is inappropriate for the purpose of maintaining the cached state of
memory contents.

Since this removes any use of the stack in the implementation of
cache_clean_flush(), we can also drop some code that manages the
value of the stack pointer before calling it.
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

In preparation for turning the decompressor's cache clean/flush
operations into proper by-VA maintenance for v7 cores, pass the
start and end addresses of the regions that need cache maintenance
into cache_clean_flush in registers r0 and r1.

Currently, all implementations of cache_clean_flush ignore these
values, so no functional change is expected as a result of this
patch.
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Before adding another reference to the inflated image size, factor
out the slightly complicated way of loading the unaligned little-endian
constant from the end of the compressed data.
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Expose efi_entry() as the PE/COFF entrypoint directly, instead of
jumping into a wrapper that fiddles with stack buffers and other
stuff that the compiler is much better at. The only reason this
code exists is to obtain a pointer to the base of the image, but
we can get the same value from the loaded_image protocol, which
we already need for other reasons anyway.

Update the return type as well, to make it consistent with what
is required for a PE/COFF executable entrypoint.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

In preparation for turning the decompressor's cache clean/flush
operations into proper by-VA maintenance for v7 cores, pass the
start and end addresses of the regions that need cache maintenance
into cache_clean_flush in registers r0 and r1.

Currently, all implementations of cache_clean_flush ignore these
values, so no functional change is expected as a result of this
patch.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

The EFI stub executes within the context of the zImage as it was
loaded by the firmware, which means it is treated as an ordinary
PE/COFF executable, which is loaded into memory, and cleaned to
the PoU to ensure that it can be executed safely while the MMU
and caches are on.

When the EFI stub hands over to the decompressor, we clean the caches
by set/way and disable the MMU and D-cache, to comply with the Linux
boot protocol for ARM. However, cache maintenance by set/way is not
sufficient to ensure that subsequent instruction fetches and data
accesses done with the MMU off see the correct data. This means that
proceeding as we do currently is not safe, especially since we also
perform data accesses with the MMU off, from a literal pool as well as
the stack.

So let's kick this can down the road a bit, and jump into the relocated
zImage before disabling the caches. This removes the requirement to
perform any by-VA cache maintenance on the original PE/COFF executable,
but it does require that the relocated zImage is cleaned to the PoC,
which is currently not the case. This will be addressed in a subsequent
patch.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

This reverts commit e17b1af9, which is
no longer necessary now that the v7 specific routines take care not to
issue CP15 barrier instructions before they are enabled in SCTLR.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Commit e17b1af9

  "ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache"

added some explicit handling of the CP15BEN bit in the SCTLR system
register, to ensure that CP15 barrier instructions are enabled, even
if we enter the decompressor via the EFI stub.

However, as it turns out, there are other ways in which we may end up
using CP15 barrier instructions without them being enabled. I.e., when
the decompressor startup code skips the cache_on() initially, we end
up calling cache_clean_flush() with the caches and MMU off, in which
case the CP15BEN bit in SCTLR may not be programmed either. And in
fact, cache_on() itself issues CP15 barrier instructions before actually
enabling them by programming the new SCTLR value (and issuing an ISB)

Since these routines are shared between v7 CPUs and older ones that
implement the CPUID extension as well, using the ordinary v7 barrier
instructions in this code is not possible, and so we should enable the
CP15 ones explicitly before issuing them. Note that a v7 ISB is still
required between programming the SCTLR register and using the CP15 barrier
instructions, and we should take care to branch over it if the CP15BEN
bit is already set, given that in that case, the CPU may not support it.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

It looks like a section directive was using "Solaris style" to declare
the section flags. Replace this with the GNU style so that Clang's
integrated assembler can assemble this directive.

The modified instances were identified via:
$ ag \.section | grep #

Link: https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_7.html#SEC119
Link: https://github.com/ClangBuiltLinux/linux/issues/744
Link: https://bugs.llvm.org/show_bug.cgi?id=43759
Link: https://reviews.llvm.org/D69296Acked-by: NNicolas Pitre <nico@fluxnic.net>
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Suggested-by: NFangrui Song <maskray@google.com>
Suggested-by: NJian Cai <jiancai@google.com>
Suggested-by: NPeter Smith <peter.smith@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

LLVM's integrated assembler does not accept r15 as mrc operand.
  arch/arm/boot/compressed/head.S:1267:16: error: operand must be a register in range [r0, r14] or apsr_nzcv
  1: mrc p15, 0, r15, c7, c14, 3 @ test,clean,invalidate D cache
                 ^

Use APSR_nzcv instead of r15. The GNU assembler supports this
syntax since binutils 2.21 [0].

[0] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=db472d6ff0f438a21b357249a9b48e4b74498076Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

This open-coded nop as mov r0, r0 is a development history
artifact.

First commit b11fe388
("ARM: 6663/1: make Thumb2 kernel entry point more similar
to the ARM one") moved the code around so that the nops
would come before the conditional thumb instructions, as it
turned out that some boot loaders were patching the initial
nop instructions in the kernel. At this point it is clear
that all mov r0,r0 are open-coded nops.

Then commit 81a0bc39 ("ARM: add UEFI stub support")
moved things around and defined __nop for EFI support and
missed this open-coded nop.

commit 06a4b6d0
("ARM: 8677/1: boot/compressed: fix decompressor header
layout for v7-M") makes all invocations of __nop be wide,
but that is fine, because this is what we want: the
mov r0,r0 is inside ifndef CONFIG_THUMB2_KERNEL.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Acked-by: NRoy Franz <rfranz@marvell.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

This was unclear to me until Russell explained the obvious
that 8 nops are added to offset an a.out image. Reading
git history reveals that thumb kernels first removed the
nops and then kept 7 of them (the last instruction being
a switch to thumb mode) as it turns out that some boot
loaders were using this as a "patch area". Also the magic
numbers after the initial nops and the jump of course
need to stay in the same offset for kernel file
detection.

Make the code easier to understand with a comment.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Acked-by: NRoy Franz <rfranz@marvell.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NEnrico Weigelt <info@metux.net>
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The EFI stub is entered with the caches and MMU enabled by the
firmware, and once the stub is ready to hand over to the decompressor,
we clean and disable the caches.

The cache clean routines use CP15 barrier instructions, which can be
disabled via SCTLR. Normally, when using the provided cache handling
routines to enable the caches and MMU, this bit is enabled as well.
However, but since we entered the stub with the caches already enabled,
this routine is not executed before we call the cache clean routines,
resulting in undefined instruction exceptions if the firmware never
enabled this bit.

So set the bit explicitly in the EFI entry code, but do so in a way that
guarantees that the resulting code can still run on v6 cores as well
(which are guaranteed to have CP15 barriers enabled)

Cc: <stable@vger.kernel.org> # v4.9+
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

It may happen that when we relocate the kernel we corrupt other
sensible memory (e.g. the memory needed by U-Boot for dealing
with bootm command) while copying the kernel. If we overwrite
the content of the memory area used by U-Boot's command bootm
(described by U-Boot's parameters bootm_low and bootm_size),
the kernel won't be able to boot. Troubleshooting the problem
then is not straightforward.

This commit allows the user to easily print information on
where the kernel gets copied from/to in order to help with the
design of the system memory map (e.g. bootm_low and bootm_size)
at boot up.
Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: NChris Paterson <Chris.Paterson2@renesas.com>
Acked-by: NBiju Das <biju.das@bp.renesas.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The hypervisor setup before __enter_kernel destroys the value
sotred in r1. The value needs to be restored just before the jump.

Fixes: 6b52f7bd ("ARM: hyp-stub: Use r1 for the soft-restart address")
Signed-off-by: NŁukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

In commit 639da5ee ("ARM: add an extra temp register to the low
level debugging addruart macro") an additional temporary register was
added to the addruart macro, but the decompressor code wasn't updated.

Fixes: 639da5ee ("ARM: add an extra temp register to the low level debugging addruart macro")
Signed-off-by: NŁukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Add an additional extendable table to the compressed kernel so that we
can provide further information to boot loaders regarding the properties
of the image contained within.

This is necessary for correct behaviour of kexec.
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>