ARM: 9441/1: rust: Enable Rust support for ARMv7

This commit allows building ARMv7 kernels with Rust support.

The rust core library expects some __eabi_... functions
that are not implemented in the

ARM: 9441/1: rust: Enable Rust support for ARMv7

This commit allows building ARMv7 kernels with Rust support.

The rust core library expects some __eabi_... functions
that are not implemented in the kernel.
Those functions are some float operations and __aeabi_uldivmod.
For now those are implemented with define_panicking_intrinsics!.

This is based on the code by Sven Van Asbroeck from the original
rust branch and inspired by the AArch version by Jamie Cunliffe.

I have tested the rust samples and a custom simple MMIO module
on hardware (De1SoC FPGA + Arm A9 CPU).

Tested-by: Rudraksha Gupta <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Tested-by: Miguel Ojeda <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Christian Schrefl <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

kbuild: add $(objtree)/ prefix to some in-kernel build artifacts

$(objtree) refers to the top of the output directory of kernel builds.

This commit adds the explicit $(objtree)/ prefix to build art

kbuild: add $(objtree)/ prefix to some in-kernel build artifacts

$(objtree) refers to the top of the output directory of kernel builds.

This commit adds the explicit $(objtree)/ prefix to build artifacts
needed for building external modules.

This change has no immediate impact, as the top-level Makefile
currently defines:

objtree := .

This commit prepares for supporting the building of external modules
in a different directory.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

ARM: ep93xx: DT for the Cirrus ep93xx SoC platforms

Add compulsory device tree support to the Cirrus ep93xx ARMv4 platform.

- select PINCTRL_EP93xx
- select COMMON_CLK_EP93XX, as clock driver moved

ARM: ep93xx: DT for the Cirrus ep93xx SoC platforms

Add compulsory device tree support to the Cirrus ep93xx ARMv4 platform.

- select PINCTRL_EP93xx
- select COMMON_CLK_EP93XX, as clock driver moved out of platform code
- select ARCH_HAS_RESET_CONTROLLER

Select ARM_ATAG_DTB_COMPAT to update device tree with information
about memory passed from bootloader.

We have to leave all MACH options as they are used for board checking
before decomp, to turn off watchdog and ethernet DMA.

Tested-by: Alexander Sverdlin <[email protected]>
Signed-off-by: Nikita Shubin <[email protected]>
Tested-by: Michael Peters <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Kris Bahnsen <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Reviewed-by: Sergey Shtylyov <[email protected]>
Acked-by: Miquel Raynal <[email protected]>
Acked-by: Alexander Sverdlin <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Acked-by: Damien Le Moal <[email protected]>
Acked-by: Sebastian Reichel <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: implement ARCH_HAS_KERNEL_FPU_SUPPORT

ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and expo

ARM: implement ARCH_HAS_KERNEL_FPU_SUPPORT

ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.

[[email protected]: ARM: do not select ARCH_HAS_KERNEL_FPU_SUPPORT]
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Samuel Holland <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Acked-by: Christian König <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Borislav Petkov (AMD) <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Huacai Chen <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicolas Schier <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Russell King <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: WANG Xuerui <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Thiago Jung Bauermann <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

ARM: qcom: merge remaining subplatforms into sensible Kconfig entry

Three remaining Qualcomm platforms have special handling of the
TEXT_OFFSET to reserve the memory at the beginnig of the system RA

ARM: qcom: merge remaining subplatforms into sensible Kconfig entry

Three remaining Qualcomm platforms have special handling of the
TEXT_OFFSET to reserve the memory at the beginnig of the system RAM, see
the commit 9e775ad19f52 ("ARM: 7012/1: Set proper TEXT_OFFSET for newer
MSMs"). This is required for older platforms like IPQ40xx, MSM8x60,
MSM8960 and APQ8064 and is compatible with other 32-bit Qualcomm
platforms.

Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

ARM: mach-nspire: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 supp

ARM: mach-nspire: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 support
does not allow mach-* directories at all. While we may not get to that
given all the non-standard architectures we support, we should still try
to get as close as we can and reduce the number of mach directories.

The mach-nspire/ directory and files, provides just one "feature":
having the kernel print the machine name if the DTB does not also contain
a "model" string (which they always do). To reduce the number of mach-*
directories let's do without that feature and remove this directory.

NOTE: The default l2c_aux_mask is now ~0 but these devices never have
this type of cache controller so this is safe.

Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: mach-sunplus: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 sup

ARM: mach-sunplus: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 support
does not allow mach-* directories at all. While we may not get to that
given all the non-standard architectures we support, we should still try
to get as close as we can and reduce the number of mach directories.

The mach-sunplus/ directory and files, provides just one "feature":
having the kernel print the machine name if the DTB does not also contain
a "model" string (which they always do). To reduce the number of mach-*
directories let's do without that feature and remove this directory.

NOTE: The default l2c_aux_mask is now ~0 but these devices never have
this type of cache controller so this is safe.

Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: mach-airoha: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 supp

ARM: mach-airoha: Rework support and directory structure

Having a platform need a mach-* directory should be seen as a negative,
it means the platform needs special non-standard handling. ARM64 support
does not allow mach-* directories at all. While we may not get to that
given all the non-standard architectures we support, we should still try
to get as close as we can and reduce the number of mach directories.

The mach-airoha/ directory, and files within, provide just one "feature":
having the kernel print the machine name if the DTB does not also contain
a "model" string (which they always do). To reduce the number of mach-*
directories let's do without that feature and remove this directory.

It also seems there was a copy/paste error and the "MEDIATEK_DT"
name was re-used in the DT_MACHINE_START macro. This may have caused
conflicts if this was built in a multi-arch configuration.

NOTE: The default l2c_aux_mask is now ~0 but these devices never have
this type of cache controller so this is safe.

Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: mach-moxart: Move MOXA ART support into Kconfig.platforms

This removes the need for a dedicated Kconfig and empty mach directory.

Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Arnd B

ARM: mach-moxart: Move MOXA ART support into Kconfig.platforms

This removes the need for a dedicated Kconfig and empty mach directory.

Signed-off-by: Andrew Davis <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

kbuild: unify vdso_install rules

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just

kbuild: unify vdso_install rules

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just for copying files
to the install destination.

Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.

2. Unintended updates of in-tree build artifacts

The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").

3. Broken code in some architectures

Makefile code is often copied from one architecture to another
without proper adaptation.

'make vdso_install' for parisc does not work.

'make vdso_install' for s390 installs vdso64, but not vdso32.

To address these problems, this commit introduces a generic vdso_install
rule.

Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.

For example, arch/x86/Makefile looks like this:

vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg

These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.

vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.

The following is a snippet from arch/arm64/Makefile.

vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so

This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Sven Schnelle <[email protected]> # s390
Reviewed-by: Nicolas Schier <[email protected]>
Reviewed-by: Guo Ren <[email protected]>
Acked-by: Helge Deller <[email protected]> # parisc
Acked-by: Catalin Marinas <[email protected]>
Acked-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: oxnas: remove OXNAS support

Due to lack of maintainance and stall of development for a few years now,
and since no new features will ever be added upstream, remove support
for OX810 and OX820 A

ARM: oxnas: remove OXNAS support

Due to lack of maintainance and stall of development for a few years now,
and since no new features will ever be added upstream, remove support
for OX810 and OX820 ARM support.

Acked-by: Linus Walleij <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Daniel Golle <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: add multi_v7_lpae_defconfig

The only missing configuration option preventing us from using
multi_v7_defconfig with the Raspberry Pi 4 is ARM_LPAE. It's needed as
the PCIe controller found on th

ARM: add multi_v7_lpae_defconfig

The only missing configuration option preventing us from using
multi_v7_defconfig with the Raspberry Pi 4 is ARM_LPAE. It's needed as
the PCIe controller found on the SoC depends on 64bit addressing, yet
can't be included as not all v7 boards support LPAE.

Introduce multi_v7_lpae_defconfig, built off multi_v7_defconfig, which will
avoid us having to duplicate and maintain multiple similar configurations.

Needless to say the Raspberry Pi 4 is not the only platform that can
benefit from this new configuration.

Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Signed-off-by: Alexander Stein <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: 9287/1: Reduce __thumb2__ definition to crypto files that require it

Commit 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") added
a __thumb2__ define to ASFLAGS to avoid build error

ARM: 9287/1: Reduce __thumb2__ definition to crypto files that require it

Commit 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") added
a __thumb2__ define to ASFLAGS to avoid build errors in the crypto code,
which relies on __thumb2__ for preprocessing. Commit 59e2cf8d21e0 ("ARM:
9275/1: Drop '-mthumb' from AFLAGS_ISA") followed up on this by removing
-mthumb from AFLAGS so that __thumb2__ would not be defined when the
default target was ARMv7 or newer.

Unfortunately, the second commit's fix assumes that the toolchain
defaults to -mno-thumb / -marm, which is not the case for Debian's
arm-linux-gnueabihf target, which defaults to -mthumb:

$ echo | arm-linux-gnueabihf-gcc -dM -E - | grep __thumb
#define __thumb2__ 1
#define __thumb__ 1

This target is used by several CI systems, which will still see
redefined macro warnings, despite '-mthumb' not being present in the
flags:

<command-line>: warning: "__thumb2__" redefined
<built-in>: note: this is the location of the previous definition

Remove the global AFLAGS __thumb2__ define and move it to the crypto
folder where it is required by the imported OpenSSL algorithms; the rest
of the kernel should use the internal CONFIG_THUMB2_KERNEL symbol to
know whether or not Thumb2 is being used or not. Be sure that __thumb2__
is undefined first so that there are no macro redefinition warnings.

Link: https://github.com/ClangBuiltLinux/linux/issues/1772

Reported-by: "kernelci.org bot" <[email protected]>
Suggested-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Fixes: 59e2cf8d21e0 ("ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA")
Fixes: 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler")
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

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 exc

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 <[email protected]>
Cc: Ben Dooks <[email protected]>
Cc: Christer Weinigel <[email protected]>
Cc: Guillaume GOURAT <[email protected]>
Cc: Heiko Stuebner <[email protected]>
Cc: Simtec Linux Team <[email protected]>
Cc: [email protected]
Acked-by: Heiko Stuebner <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: 9285/1: remove meaningless arch/arm/mach-rda/Makefile

You do not need to put Makefile if there is nothing to compile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Russe

ARM: 9285/1: remove meaningless arch/arm/mach-rda/Makefile

You do not need to put Makefile if there is nothing to compile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: iop32x: remove the platform

This was marked as unused in 5.19 and can now be removed

Cc: Lennert Buytenhek <[email protected]>
Cc: Martin Michlmayr <[email protected]>
Acked-by: Dan Williams

ARM: iop32x: remove the platform

This was marked as unused in 5.19 and can now be removed

Cc: Lennert Buytenhek <[email protected]>
Cc: Martin Michlmayr <[email protected]>
Acked-by: Dan Williams <[email protected]>
Acked-by: Wolfram Sang <[email protected]> # for I2C
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: cns3xxx: remove entire platform

cns3xxx was marked as unused a while ago, and gets removed
entirely now.

Acked-by: Krzysztof Hałasa <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]

ARM: cns3xxx: remove entire platform

cns3xxx was marked as unused a while ago, and gets removed
entirely now.

Acked-by: Krzysztof Hałasa <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA

When building with CONFIG_THUMB2_KERNEL=y + a version of clang from
Debian using CROSS_COMPILE=arm-linux-gnueabihf-, the following warning
occurs frequent

ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA

When building with CONFIG_THUMB2_KERNEL=y + a version of clang from
Debian using CROSS_COMPILE=arm-linux-gnueabihf-, the following warning
occurs frequently:

<built-in>:383:9: warning: '__thumb2__' macro redefined [-Wmacro-redefined]
#define __thumb2__ 2
^
<built-in>:353:9: note: previous definition is here
#define __thumb2__ 1
^
1 warning generated.

Debian carries a downstream patch that changes the default CPU of the
arm-linux-gnueabihf target from 'arm1176jzf-s' (v6) to 'cortex-a7' (v7).
As a result, '-mthumb' defines both '__thumb__' and '__thumb2__'. The
define of '__thumb2__' via the command line was purposefully added to
catch a situation like this.

In a similar vein as commit 26b12e084bce ("ARM: 9264/1: only use
-mtp=cp15 for the compiler"), do not add '-mthumb' to AFLAGS_ISA, as it
is already passed to the assembler via '-Wa,-mthumb' and '__thumb2__' is
already defined for preprocessing.

Link: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/622dbcbd40b316ed3905a2d25d9623544a06e6b1/debian/patches/930008-arm.diff

Fixes: 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler")
Reported-by: "kernelci.org bot" <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9265/1: pass -march= only to compiler

When both -march= and -Wa,-march= are specified for assembler or
assembler-with-cpp sources, GCC and Clang will prefer the -Wa,-march=
value but Clang will

ARM: 9265/1: pass -march= only to compiler

When both -march= and -Wa,-march= are specified for assembler or
assembler-with-cpp sources, GCC and Clang will prefer the -Wa,-march=
value but Clang will warn that -march= is unused.

warning: argument unused during compilation: '-march=armv6k'
[-Wunused-command-line-argument]

This is the top group of warnings we observe when using clang to
assemble the kernel via `ARCH=arm make LLVM=1`.

Split the arch-y make variable into two, so that -march= flags only get
passed to the compiler, not the assembler. -D flags are added to
KBUILD_CPPFLAGS which is used for both C and assembler-with-cpp sources.

Clang is trying to warn that it doesn't support different values for
-march= and -Wa,-march= (like GCC does, but the kernel doesn't need this)
though the value of the preprocessor define __thumb2__ is based on
-march=. Make sure to re-set __thumb2__ via -D flag for assembler
sources now that we're no longer passing -march= to the assembler. Set
it to a different value than the preprocessor would for -march= in case
-march= gets accidentally re-added to KBUILD_AFLAGS in the future.
Thanks to Ard and Nathan for this suggestion.

Link: https://github.com/ClangBuiltLinux/linux/issues/1315
Link: https://github.com/ClangBuiltLinux/linux/issues/1587
Link: https://github.com/llvm/llvm-project/issues/55656

Suggested-by: Ard Biesheuvel <[email protected]>
Suggested-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9264/1: only use -mtp=cp15 for the compiler

Avoids an error from the assembler for CONFIG_THUMB2 kernels:

clang-15: error: hardware TLS register is not supported for the thumbv4t
sub-architect

ARM: 9264/1: only use -mtp=cp15 for the compiler

Avoids an error from the assembler for CONFIG_THUMB2 kernels:

clang-15: error: hardware TLS register is not supported for the thumbv4t
sub-architecture

This flag only makes sense to pass to the compiler, not the assembler.

Perhaps CFLAGS_ABI can be renamed to CPPFLAGS_ABI to reflect that they
will be passed to both the compiler and assembler for sources that
require pre-processing.

Reviewed-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9262/1: remove lazy evaluation in Makefile

arch-y and tune-y used lazy evaluation since they used to contain

cc-option checks. They don't any longer, so just eagerly evaluate these
command lin

ARM: 9262/1: remove lazy evaluation in Makefile

arch-y and tune-y used lazy evaluation since they used to contain

cc-option checks. They don't any longer, so just eagerly evaluate these
command line flags.

Reviewed-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

kbuild: remove head-y syntax

Kbuild puts the objects listed in head-y at the head of vmlinux.
Conventionally, we do this for head*.S, which contains the kernel entry
point.

A counter approach is to

kbuild: remove head-y syntax

Kbuild puts the objects listed in head-y at the head of vmlinux.
Conventionally, we do this for head*.S, which contains the kernel entry
point.

A counter approach is to control the section order by the linker script.
Actually, the code marked as __HEAD goes into the ".head.text" section,
which is placed before the normal ".text" section.

I do not know if both of them are needed. From the build system
perspective, head-y is not mandatory. If you can achieve the proper code
placement by the linker script only, it would be cleaner.

I collected the current head-y objects into head-object-list.txt. It is
a whitelist. My hope is it will be reduced in the long run.

Signed-off-by: Masahiro Yamada <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

ARM: 9226/1: disable FDPIC ABI

When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is
enabled by default but should not be used to build the kernel.
Therefore, pass -mno-fdpic if s

ARM: 9226/1: disable FDPIC ABI

When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is
enabled by default but should not be used to build the kernel.
Therefore, pass -mno-fdpic if supported by the compiler.

Signed-off-by: Ben Wolsieffer <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: simplify machdirs/platdirs handling

There is only one plat-* directory left, and the MACHINE variable is
only used for the mach/*.h header path.

Simplify this by removing the checks for ARCH_M

ARM: simplify machdirs/platdirs handling

There is only one plat-* directory left, and the MACHINE variable is
only used for the mach/*.h header path.

Simplify this by removing the checks for ARCH_MULTIPLATFORM and
ARM_SINGLE_ARMV7M, and just adding the include directories for the
remaining three platforms manually.

Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

ARM: remove obsolete Makefile.boot infrastructure

There are a number of old Makefile.boot files that remain from the
multiplatform conversion, and three that are still in use.

These provide the "ZR

ARM: remove obsolete Makefile.boot infrastructure

There are a number of old Makefile.boot files that remain from the
multiplatform conversion, and three that are still in use.

These provide the "ZRELADDR", "PARAMS_PHYS" and "INITRD_PHYS" values
that are platform specific. It turns out that we can generally just
derive this from information that is available elsewhere:

- ZRELADDR is normally detected at runtime with the
CONFIG_AUTO_ZRELADDR flag, but also needed to be passed to
for 'make uImage'. In a multiplatform kernel, one always has
to pass this as the $(LOADADDR) variable, but in the StrongARM
kernels we can derive it from the sum of $(CONFIG_PHYS_OFFSET)
and $(TEXT_OFFSET) that are already known.

- PARAMS_PHYS and INITRD_PHYS are only used for bootpImage, which
in turn is only used for the pre-ATAGS 'param_struct' based boot
interface on StrongARM based machines with old boot loaders.
They can both be derived from CONFIG_PHYS_OFFSET and a machine
specific offset for the initrd, so all of the logic for these
can be part of arch/arm/boot/bootp/Makefile.

Signed-off-by: Arnd Bergmann <[email protected]>

show more ...