Searched +hist:6 +hist:e8699f7 (Results 1 - 3 of 3) sorted by relevance

/linux-master/arch/arm/boot/compressed/
H A Ddecompress.cdiff 7b96ddd0 Thu Feb 02 05:29:36 MST 2017 Arnd Bergmann <arnd@arndb.de> ARM: 8654/1: decompressor: add strlen prototype

The decompress.c file contains a declaration for strstr() so we can
include some compression library code.

With the updated LZ4 implementation, we run into the same problem again
for strlen():

In file included from ../include/linux/rcupdate.h:40:0,
from ../include/linux/srcu.h:33,
from ../include/linux/notifier.h:15,
from ../include/linux/memory_hotplug.h:6,
from ../include/linux/mmzone.h:749,
from ../include/linux/gfp.h:5,
from ../include/linux/kmod.h:22,
from ../include/linux/module.h:13,
from ../arch/arm/boot/compressed/../../../../lib/lz4/lz4_decompress.c:39,
from ../arch/arm/boot/compressed/../../../../lib/decompress_unlz4.c:13,
from ../arch/arm/boot/compressed/decompress.c:55:
include/linux/cpumask.h: In function 'cpumask_parse':
include/linux/cpumask.h:592:53: error: implicit declaration of function 'strlen';did you mean 'strstr'? [-Werror=implicit-function-declaration]

This adds another declaration to work around the new problem.

Fixes: ce83d9ab80d6 ("lib: update LZ4 compressor module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
diff 6e8699f7 Sat Apr 03 04:40:28 MDT 2010 Albin Tonnerre <albin.tonnerre@free-electrons.com> ARM: 6026/1: ARM: Add support for LZMA-compressed kernel images

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: Martin Michlmayr <tbm@cyrius.com>
Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
diff 6e8699f7 Sat Apr 03 04:40:28 MDT 2010 Albin Tonnerre <albin.tonnerre@free-electrons.com> ARM: 6026/1: ARM: Add support for LZMA-compressed kernel images

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: Martin Michlmayr <tbm@cyrius.com>
Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
H A DMakefilediff c4e792d1 Fri Feb 05 11:23:00 MST 2021 Ard Biesheuvel <ardb@kernel.org> ARM: 9056/1: decompressor: fix BSS size calculation for LLVM ld.lld

The LLVM ld.lld linker uses a different symbol type for __bss_start,
resulting in the calculation of KBSS_SZ to be thrown off. Up until now,
this has gone unnoticed as it only affects the appended DTB case, but
pending changes for ARM in the way the decompressed kernel is cleaned
from the caches has uncovered this problem.

On a ld.lld build:

$ nm vmlinux |grep bss_
c1c22034 D __bss_start
c1c86e98 B __bss_stop

resulting in

$ readelf -s arch/arm/boot/compressed/vmlinux | grep bss_size
433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size

which is obviously incorrect, and may cause the cache clean to access
unmapped memory, or cause the size calculation to wrap, resulting in no
cache clean to be performed at all.

Fix this by updating the sed regex to take D type symbols into account.

Link: https://lore.kernel.org/linux-arm-kernel/6c65bcef-d4e7-25fa-43cf-2c435bb61bb9@collabora.com/
Link: https://lore.kernel.org/linux-arm-kernel/20210205085220.31232-1-ardb@kernel.org/

Cc: <stable@vger.kernel.org> # v4.19+
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
diff 6cea14f5 Mon Apr 16 06:21:54 MDT 2018 Russell King <rmk+kernel@armlinux.org.uk> ARM: replace unnecessary perl with sed and the shell $(( )) operator

You can build a kernel in a cross compiling environment that doesn't
have perl in the $PATH. Commit 429f7a062e3b broke that for 32 bit
ARM. Fix it.

As reported by Stephen Rothwell, it appears that the symbols can be
either part of the BSS section or absolute symbols depending on the
binutils version. When they're an absolute symbol, the $(( ))
operator errors out and the build fails. Fix this as well.

Fixes: 429f7a062e3b ("ARM: decompressor: fix BSS size calculation")
Reported-by: Rob Landley <rob@landley.net>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Rob Landley <rob@landley.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
diff 429f7a06 Thu Sep 21 10:15:23 MDT 2017 Russell King <rmk+kernel@armlinux.org.uk> ARM: decompressor: fix BSS size calculation

Assuming size(1) gives the size of the BSS is a mistake - it reports
the size of the .bss section in the ELF image, which may not be the
same as the region we mark with the __bss_start..__bss_stop symbols.

We use the size of the BSS in the decompressor to know whether the
kernel will overwrite the appended dtb, by adding the BSS size to the
size of the Image (stored at the end of the compressed data) and adding
the desired address of the decompressed image.

If the BSS size is smaller than it really is, the decompressor can
incorrectly assume that the BSS clearance will not overwrite the DTB.

Here is an illustration:

$ arm-linux-size vmlinux
text data bss dec hex filename
8136972 3098076 10240348 21475396 147b044 vmlinux
$ arm-linux-nm vmlinux | grep __bss_
c0ac0e34 B __bss_start
c1484f9c B __bss_stop
$ stat -c %s arch/arm/boot/Image
11243060

In the above case, we are 12 bytes short. This is caused by the BSS
section being aligned by one of its input sections:

Idx Name Size VMA LMA File off Algn
23 __bug_table 00005d3c c0abb0f8 c0abb0f8 00acb0f8 2**2
CONTENTS, ALLOC, LOAD, DATA
24 .bss 009c415c c0ac0e40 c0ac0e40 00ad0e34 2**6
ALLOC

Note that there's an additional 12 bytes difference between the file
offset and LMA compared with the bug table - this occurs because one
of the input sections for the .bss section requires a 64 byte
alignment.

Fix this by using 'nm' and perl to obtain the address of the __bss_start
and __bss_stop symbols, using their difference for the size of the BSS.

Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
diff 6e8699f7 Sat Apr 03 04:40:28 MDT 2010 Albin Tonnerre <albin.tonnerre@free-electrons.com> ARM: 6026/1: ARM: Add support for LZMA-compressed kernel images

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: Martin Michlmayr <tbm@cyrius.com>
Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
diff 6e8699f7 Sat Apr 03 04:40:28 MDT 2010 Albin Tonnerre <albin.tonnerre@free-electrons.com> ARM: 6026/1: ARM: Add support for LZMA-compressed kernel images

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: Martin Michlmayr <tbm@cyrius.com>
Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/linux-master/arch/arm/
H A DKconfigdiff 6a1d798f Thu Dec 06 09:29:51 MST 2018 Rob Herring <robh@kernel.org> kbuild: Support flat DTBs install

In preparation to move Arm .dts files into sub-directories grouped
by vendor/family, the current flat tree of DTBs generated by
dtbs_install needs to be maintained. Moving the installed DTBs to
sub-directories would break various consumers using 'make dtbs_install'.

This is a NOP until sub-directories are introduced.

Signed-off-by: Rob Herring <robh@kernel.org>
diff 5eb6e280 Sun Jan 29 07:49:07 MST 2023 Nathan Chancellor <nathan@kernel.org> ARM: 9289/1: Allow pre-ARMv5 builds with ld.lld 16.0.0 and newer

Commit 6a7ee50f8f56 ("ARM: disallow pre-ARMv5 builds with ld.lld")
prevented v4 or v4t kernels when ld.lld will link the kernel due to
inserting unsupported blx instructions.

ld.lld has been fixed in current main (16.0.0) to avoid inserting these
instructions by inserting position independent thunks instead. Allow
these configurations to be enabled when ld.lld 16.0.0 is used to link
the kernel.

Additionally, add a link to the upstream LLVM issue so that the reason
for this dependency is clearly documented.

Link: https://github.com/ClangBuiltLinux/linux/issues/964
Link: https://github.com/llvm/llvm-project/commit/6f9ff1beee9d12aca0c9caa9ae0051dc6d0a718c

Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
diff 5eb6e280 Sun Jan 29 07:49:07 MST 2023 Nathan Chancellor <nathan@kernel.org> ARM: 9289/1: Allow pre-ARMv5 builds with ld.lld 16.0.0 and newer

Commit 6a7ee50f8f56 ("ARM: disallow pre-ARMv5 builds with ld.lld")
prevented v4 or v4t kernels when ld.lld will link the kernel due to
inserting unsupported blx instructions.

ld.lld has been fixed in current main (16.0.0) to avoid inserting these
instructions by inserting position independent thunks instead. Allow
these configurations to be enabled when ld.lld 16.0.0 is used to link
the kernel.

Additionally, add a link to the upstream LLVM issue so that the reason
for this dependency is clearly documented.

Link: https://github.com/ClangBuiltLinux/linux/issues/964
Link: https://github.com/llvm/llvm-project/commit/6f9ff1beee9d12aca0c9caa9ae0051dc6d0a718c

Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
diff 61b7f892 Thu Sep 29 07:33:15 MDT 2022 Arnd Bergmann <arnd@arndb.de> ARM: s3c: remove all s3c24xx support

The platform was deprecated in commit 6a5e69c7ddea ("ARM: s3c: mark
as deprecated and schedule removal") and can be removed. This includes
all files that are exclusively for s3c24xx and not shared with s3c64xx,
as well as the glue logic in Kconfig and the maintainer file entries.

Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Christer Weinigel <christer@weinigel.se>
Cc: Guillaume GOURAT <guillaume.gourat@nexvision.tv>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Simtec Linux Team <linux@simtec.co.uk>
Cc: openmoko-kernel@lists.openmoko.org
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff 6a7ee50f Thu Dec 15 09:26:20 MST 2022 Arnd Bergmann <arnd@arndb.de> ARM: disallow pre-ARMv5 builds with ld.lld

lld cannot build for ARMv4/v4T targets because it inserts 'blx' instructions
that are unsupported there:

ld.lld: warning: lld uses blx instruction, no object with architecture supporting feature detected

Add a Kconfig time dependency to prevent those targets from being
selected in randconfig builds.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://github.com/llvm/llvm-project/issues/50764
Link: https://github.com/ClangBuiltLinux/linux/issues/964
Link: https://lore.kernel.org/r/20221215162635.3750763-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff 47723de8 Fri Sep 16 13:53:09 MDT 2022 Arnd Bergmann <arnd@arndb.de> ARM: disallow PCI with MMU=n again

My cleanup patch allowed enabling PCI on MMU-less builds,
which breaks for at least one driver and is never required:

In file included from include/linux/irqchip/arm-gic-v3.h:604,
from drivers/pci/controller/pcie-iproc.c:17:
arch/arm/include/asm/arch_gicv3.h: In function 'write_ICC_EOIR1_EL1':
arch/arm/include/asm/arch_gicv3.h:44:9: error: implicit declaration of function 'write_sysreg' [-Werror=implicit-function-declaration]

Fixes: 6fd09c9afa49 ("ARM: Kconfig: clean up platform selection")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff 6fd09c9a Tue Jul 26 06:16:37 MDT 2022 Arnd Bergmann <arnd@arndb.de> ARM: Kconfig: clean up platform selection

The top-level platform selection is mostly meaningless these days after
almost everything is sorted below the CONFIG_ARCH_MULTIPLATFORM, with
the only exception being the 20+ year old StrongARM based machines.

Make this more consistent by removing the entire choice statement and
moving the StrongARM specific options into regular platform specific
Kconfig files.

The three platforms (footbridge, rpc and sa1100) are still mutually
exclusive and cannot coexist with other ARMv4/v5 machines, but since
there are only three of them and we will not add more, this can be
expressed using Kconfig 'depends on' statements.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff 6f5d248d Tue Nov 30 03:21:49 MST 2021 Arnd Bergmann <arnd@arndb.de> ARM: iop32x: use GENERIC_IRQ_MULTI_HANDLER

iop32x uses the entry-macro.S file for both the IRQ entry and for
hooking into the arch_ret_to_user code path. This is done because the
cp6 registers have to be enabled before accessing any of the interrupt
controller registers but have to be disabled when running in user space.

There is also a lazy-enable logic in cp6.c, but during a hardirq, we
know it has to be enabled.

Both the cp6-enable code and the code to read the IRQ status can be
lifted into the normal generic_handle_arch_irq() path, but the
cp6-disable code has to remain in the user return code. As nothing
other than iop32x uses this hook, just open-code it there with an
ifdef for the platform that can eventually be removed when iop32x
has reached the end of its life.

The cp6-enable path in the IRQ entry has an extra cp_wait barrier that
the trap version does not have, but it is harmless to do it in both
cases to simplify the logic here at the cost of a few extra cycles
for the trap.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
diff 2abd6e34 Mon Oct 18 08:30:02 MDT 2021 Arnd Bergmann <arnd@arndb.de> ARM: 9146/1: RiscPC needs older gcc version

Attempting to build mach-rpc with gcc-9 or higher, or with any version
of clang results in a build failure, like:

arm-linux-gnueabi-gcc-11.1.0: error: unrecognized -march target: armv3m
arm-linux-gnueabi-gcc-11.1.0: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main iwmmxt iwmmxt2; did you mean 'armv4'?

Building with gcc-5 also fails in at least one of these ways:

/tmp/cczZoCcv.s:68: Error: selected processor does not support `bx lr' in ARM mode
drivers/tty/vt/vt_ioctl.c:958:1: internal compiler error: Segmentation fault

Handle this in Kconfig so we don't run into this with randconfig
builds, allowing only gcc-6 through gcc-8.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
diff 2abd6e34 Mon Oct 18 08:30:02 MDT 2021 Arnd Bergmann <arnd@arndb.de> ARM: 9146/1: RiscPC needs older gcc version

Attempting to build mach-rpc with gcc-9 or higher, or with any version
of clang results in a build failure, like:

arm-linux-gnueabi-gcc-11.1.0: error: unrecognized -march target: armv3m
arm-linux-gnueabi-gcc-11.1.0: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main iwmmxt iwmmxt2; did you mean 'armv4'?

Building with gcc-5 also fails in at least one of these ways:

/tmp/cczZoCcv.s:68: Error: selected processor does not support `bx lr' in ARM mode
drivers/tty/vt/vt_ioctl.c:958:1: internal compiler error: Segmentation fault

Handle this in Kconfig so we don't run into this with randconfig
builds, allowing only gcc-6 through gcc-8.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Completed in 1631 milliseconds