ARM: remove check for CONFIG_DEBUG_LL_SER3

A check for CONFIG_DEBUG_LL_SER3 was added in v2.5.43. But the related
symbol DEBUG_LL_SER3 was already removed in v2.5.8. This check has
always evaluated

ARM: remove check for CONFIG_DEBUG_LL_SER3

A check for CONFIG_DEBUG_LL_SER3 was added in v2.5.43. But the related
symbol DEBUG_LL_SER3 was already removed in v2.5.8. This check has
always evaluated to false. Remove it.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...

ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding

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 th

ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding

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: 81a0bc39ea19 ("ARM: add UEFI stub support")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Adam Lackorzynski <adam@l4re.org>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding

[ Upstream commit a92882a4d270fbcc021ee6848de5e48b7f0d27f3 ]

In the decompressor's head.S we need to start with an instruction that
is so

ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding

[ Upstream commit a92882a4d270fbcc021ee6848de5e48b7f0d27f3 ]

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: 81a0bc39ea19 ("ARM: add UEFI stub support")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Adam Lackorzynski <adam@l4re.org>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores

It was observed that decompressor running on hardware implementing ARM v8.2
Load/Store Multiple Atomicity and Ordering Control (

ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores

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: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9045/1: uncompress: Validate start of physical memory against passed DTB

Currently, the start address of physical memory is obtained by masking
the program counter with a fixed mask of 0xf80000

ARM: 9045/1: uncompress: Validate start of physical memory against passed DTB

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: Nicolas Pitre <nico@fluxnic.net>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9039/1: assembler: generalize byte swapping macro into rev_l

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. Wh

ARM: 9039/1: assembler: generalize byte swapping macro into rev_l

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: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9037/1: uncompress: Add OF_DT_MAGIC macro

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 endi

ARM: 9037/1: uncompress: Add OF_DT_MAGIC macro

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: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9036/1: uncompress: Fix dbgadtb size parameter name

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

Fixes: c03e41470e901123 ("ARM: 9010/1: uncompress: Print the

ARM: 9036/1: uncompress: Fix dbgadtb size parameter name

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

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

show more ...

ARM: 9035/1: uncompress: Add be32tocpu macro

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:

ARM: 9035/1: uncompress: Add be32tocpu macro

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: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: kvm: replace open coded VA->PA calculations with adr_l call

Replace the open coded calculations of the actual physical address
of the KVM stub vector table with a single adr_l invocation.

Revi

ARM: kvm: replace open coded VA->PA calculations with adr_l call

Replace the open coded calculations of the actual physical address
of the KVM stub vector table with a single adr_l invocation.

Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

show more ...

ARM: efistub: replace adrl pseudo-op with adr_l macro invocation

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

ARM: efistub: replace adrl pseudo-op with adr_l macro invocation

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: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

show more ...

ARM: efistub: replace adrl pseudo-op with adr_l macro invocation

commit 67e3f828bd4bf5e4eb4214dc4eb227d8f1c8a877 upstream.

The ARM 'adrl' pseudo instruction is a bit problematic, as it does not
exi

ARM: efistub: replace adrl pseudo-op with adr_l macro invocation

commit 67e3f828bd4bf5e4eb4214dc4eb227d8f1c8a877 upstream.

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: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores

[ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ]

It was observed that decompressor running on hardware implementing

ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores

[ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ]

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: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

ARM: 9036/1: uncompress: Fix dbgadtb size parameter name

[ Upstream commit 1ecec38547d415054fdb63a231234f44396b6d06 ]

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

ARM: 9036/1: uncompress: Fix dbgadtb size parameter name

[ Upstream commit 1ecec38547d415054fdb63a231234f44396b6d06 ]

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

Fixes: c03e41470e901123 ("ARM: 9010/1: uncompress: Print the location of appended DTB")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

efi/arm: set HSCTLR Thumb2 bit correctly for HVC calls from HYP

Commit

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

updated the EFI entry code to permit

efi/arm: set HSCTLR Thumb2 bit correctly for HVC calls from HYP

Commit

db227c19e68db353 ("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: db227c19e68db353 ("ARM: 8985/1: efi/decompressor: deal with HYP mode boot gracefully")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

show more ...

ARM: add malloc size to decompressor kexec size structure

Add the required malloc size to the decompressor kexec size structure.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

ARM: 9010/1: uncompress: Print the location of appended DTB

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

ARM: 9010/1: uncompress: Print the location of appended DTB

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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9008/1: uncompress: Drop excess whitespace print

This drops some whitespace from the debug message about
where we move the compressed kernel: r after the message
is completely surplus since the

ARM: 9008/1: uncompress: Drop excess whitespace print

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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9006/1: uncompress: Wait for ready and busy in debug prints

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

ARM: 9006/1: uncompress: Wait for ready and busy in debug prints

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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9003/1: uncompress: Delete unused debug macros

The debug macros debug_reloc_start and debug_reloc_end were
rendered unused in commit 6d7d0ae51574943bf571d269da3243257a2d15db
"ARM: 6750/1: impro

ARM: 9003/1: uncompress: Delete unused debug macros

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

Later on a different debug macro named dbgkc was introduced
in commit f3c899927e19d1be39818145efc39ea27b8efc69
"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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 8985/1: efi/decompressor: deal with HYP mode boot gracefully

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

ARM: 8985/1: efi/decompressor: deal with HYP mode boot gracefully

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: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: decompressor: run decompressor in place if loaded via UEFI

The decompressor can load from anywhere in memory, and the only reason
the EFI stub code relocates it is to ensure it appears within t

ARM: decompressor: run decompressor in place if loaded via UEFI

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: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>

show more ...

ARM: decompressor: defer loading of the contents of the LC0 structure

The remaining contents of LC0 are only used after the point in the
decompressor startup code where we enter via 'wont_overwrite'

ARM: decompressor: defer loading of the contents of the LC0 structure

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: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>

show more ...

ARM: decompressor: split off _edata and stack base into separate object

In preparation of moving the handling of the LC0 object to a later stage
in the decompressor startup code, move out _edata and

ARM: decompressor: split off _edata and stack base into separate object

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: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>

show more ...

ARM: decompressor: move headroom variable out of LC0

Before breaking up LC0 into different pieces, move out the variable
that is already place-relative (given that it subtracts 'restart' in
the expr

ARM: decompressor: move headroom variable out of LC0

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: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>

show more ...