kernel/linux.git/arch/arm/boot/compressed/head.S, branch linux-4.4.y

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

2021-03-03T15:44:19+00:00

[ 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 Signed-off-by: Russell King Signed-off-by: Sasha Levin

ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7

2016-10-07T13:23:42+00:00

commit 117e5e9c4cfcb7628f08de074fbfefec1bb678b7 upstream. If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece45894d3a ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece45894d3 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by: Robin Murphy Signed-off-by: Srinivas Ramana Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: replace BSYM() with badr assembly macro

2015-05-08T16:33:50+00:00

BSYM() was invented to allow us to work around a problem with the assembler, where local symbols resolved by the assembler for the 'adr' instruction did not take account of their ISA. Since we don't want BSYM() used elsewhere, replace BSYM() with a new macro 'badr', which is like the 'adr' pseudo-op, but with the BSYM() mechanics integrated into it. This ensures that the BSYM()-ification is only used in conjunction with 'adr'. Acked-by: Dave Martin Acked-by: Nicolas Pitre Signed-off-by: Russell King

ARM: 8327/1: zImage: add support for ARMv7-M

2015-03-28T16:54:53+00:00

This patch makes it possible to enter zImage in Thumb mode for ARMv7-M (Cortex-M) CPUs that do not support ARM mode. The kernel entry is also made in Thumb mode. [ukl: fix spelling in commit log, return early in call_cache_fn] Signed-off-by: Joachim Eastwood Tested-by: Stefan Agner Tested-by: Ezequiel Garcia Tested-by: Chanwoo Choi Signed-off-by: Uwe Kleine-König Signed-off-by: Russell King

ARM: add documentation for finding start of physical memory

2015-03-27T22:21:14+00:00

Occasionally, there's a question about the method we use to find the start of physical memory. Add some documentation so we don't have to keep repeating outselves on the mailing list. Signed-off-by: Russell King

Merge branches 'debug', 'fixes', 'l2c' (early part), 'misc' and 'sa1100' into for-next

2015-02-10T10:26:27+00:00

ARM: 8294/1: ATAG_DTB_COMPAT: remove the DT workspace's hardcoded 64KB size

2015-01-29T15:23:01+00:00

There is currently a hardcoded limit of 64KB for the DTB to live in and be extended with ATAG info. Some DTBs have outgrown that limit: $ du -b arch/arm/boot/dts/omap3-n900.dtb 70212 arch/arm/boot/dts/omap3-n900.dtb Furthermore, the actual size passed to atags_to_fdt() included the stack size which is obviously wrong. The initial DTB size is known, so use it to size the allocated workspace with a 50% growth assumption and relocate the temporary stack above that. This is also clamped to 32KB min / 1MB max for robustness against bad DTB data. Reported-by: Pali Rohár Tested-by: Pavel Machek Signed-off-by: Nicolas Pitre Signed-off-by: Russell King

ARM: 8290/1: decompressor: fix a wrong comment

2015-01-21T15:59:34+00:00

This comment does not correspond to the actual code. When zImage is loaded at a lower *OR* higher address of the destination of Image, it won't overwrite itself. Signed-off-by: Masahiro Yamada Acked-by: Nicolas Pitre Signed-off-by: Russell King

ARM: 8191/1: decompressor: ensure I-side picks up relocated code

2014-11-13T23:45:20+00:00

To speed up decompression, the decompressor sets up a flat, cacheable mapping of memory. However, when there is insufficient space to hold the page tables for this mapping, we don't bother to enable the caches and subsequently skip all the cache maintenance hooks. Skipping the cache maintenance before jumping to the relocated code allows the processor to predict the branch and populate the I-cache with stale data before the relocation loop has completed (since a bootloader may have SCTLR.I set, which permits normal, cacheable instruction fetches regardless of SCTLR.M). This patch moves the cache maintenance check into the maintenance routines themselves, allowing the v6/v7 versions to invalidate the I-cache regardless of the MMU state. Cc: Reported-by: Marc Carino Tested-by: Julien Grall Signed-off-by: Will Deacon Signed-off-by: Russell King

ARM: 8079/1: zImage: identify kernel endianness

2014-07-18T11:29:08+00:00

With patch #8067/1 ("zImage: ensure header in LE format for BE8 kernels") applied, it is no longer possible to determine the endianness of a compiled kernel image. This normally shouldn't matter to the boot environment, except for those cases where the selection of a ramdisk or root filesystem with a matching endianness has to be automated. Let's add a flag to the zImage header indicating the actual endianness. Four bytes from offset 0x30 can be interpreted as follows: 04 03 02 01 big endian kernel 01 02 03 04 little endian kernel Anything else should be interpreted as "unknown", in which case it is most likely that patch #8067/1 was not applied either and the zImage magic number at offset 0x24 could be used instead to determine endianness. No zImage before this patch ever produced 0x01020304 nor 0x04030201 at offset 0x30 so there is no confusion possible. Signed-off-by: Nicolas Pitre Acked-by: Kevin Hilman Signed-off-by: Russell King