#
96a8fae0 |
| 18-Oct-2016 |
Russell King <rmk+kernel@armlinux.org.uk> |
ARM: convert to generated system call tables
Convert ARM to use a similar mechanism to x86 to generate the unistd.h system call numbers and the various kernel system call tables. This means that ra
ARM: convert to generated system call tables
Convert ARM to use a similar mechanism to x86 to generate the unistd.h system call numbers and the various kernel system call tables. This means that rather than having to edit three places (asm/unistd.h for the total number of system calls, uapi/asm/unistd.h for the system call numbers, and arch/arm/kernel/calls.S for the call table) we have only one place to edit, making the process much more simple.
The scripts have knowledge of the table padding requirements, so there's no need to worry about __NR_syscalls not fitting within the immediate constant field of ALU instructions anymore.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
show more ...
|
#
4e2648db |
| 18-Oct-2016 |
Russell King <rmk+kernel@armlinux.org.uk> |
ARM: remove indirection of asm/mach-types.h
Arrange for mach-types.h to be directly generated in the relevant path, so we don't need a one-liner file in arch/arm/include/asm/.
Signed-off-by: Russel
ARM: remove indirection of asm/mach-types.h
Arrange for mach-types.h to be directly generated in the relevant path, so we don't need a one-liner file in arch/arm/include/asm/.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
show more ...
|
Revision tags: v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1 |
|
#
3cb59581 |
| 19-Jul-2016 |
Mark Rutland <mark.rutland@arm.com> |
ARM: 8588/1: localise objcopy flags
We currently define OBJCOPYFLAGS in the top-level arm Makefile, and thus these flags will be passed to all uses of objcopy, kernel-wide, for which they are not ex
ARM: 8588/1: localise objcopy flags
We currently define OBJCOPYFLAGS in the top-level arm Makefile, and thus these flags will be passed to all uses of objcopy, kernel-wide, for which they are not explicitly overridden. The flags we set are intended for converting a few ELF files into raw binaries, and thus the flags chosen are problematic for some other uses which do not expect a raw binary result, e.g. the upcoming lkdtm rodata test:
http://www.openwall.com/lists/kernel-hardening/2016/06/08/2
This patch localises the objcopy flags such that they are only used for the cases we require them for today.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Kees Cook <keescook@chromium.org> Tested-by: Laura Abbott <labbott@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
Revision tags: openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14 |
|
#
de8a06f6 |
| 09-Jun-2016 |
Arnd Bergmann <arnd@arndb.de> |
ARM: hide mach-*/ include for ARM_SINGLE_ARMV7M
The machine specific header files are exported for traditional platforms, but not for the ones that use ARCH_MULTIPLATFORM, as they could conflict wit
ARM: hide mach-*/ include for ARM_SINGLE_ARMV7M
The machine specific header files are exported for traditional platforms, but not for the ones that use ARCH_MULTIPLATFORM, as they could conflict with one another.
In case of ARM_SINGLE_ARMV7M, we end up also exporting them, but that appears to be a mistake, and we should treat it the same way as ARCH_MULTIPLATFORM here.
'make W=1' warns about this because it passes -Wmissing-includes to gcc and the directories are not actually present.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v4.6.2, v4.4.13, openbmc-20160606-1 |
|
#
c86f5173 |
| 04-Jun-2016 |
Alexander Shiyan <shc_work@mail.ru> |
ARM: clps711x: Switch to MULTIPLATFORM
Switch CLPS711X to multiplatform.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
Revision tags: v4.6.1, v4.4.12 |
|
#
c6bbfbb7 |
| 29-May-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
ARM: 8576/1: avoid duplicating "Kernel: arch/arm/boot/*Image is ready"
Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not generate invalid images") fixed bad image generation for
ARM: 8576/1: avoid duplicating "Kernel: arch/arm/boot/*Image is ready"
Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not generate invalid images") fixed bad image generation for the parallel building, but as its side effect, Kbuild now descends into arch/arm/boot/ again and again, duplicating the log messages. It looks clumsy, so let's display the same message only once.
This commit moves the log rules from arch/arm/boot/Makefile to arch/arm/Makefile. I did not delete them completely because *Image are the final targets that users are interested in.
Without this commit, the log of incremental build is like follows:
$ make ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Image arch/arm/boot/uImage is ready
With this commit, it will look like follows:
$ make ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Kernel: arch/arm/boot/uImage is ready
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
Revision tags: openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9 |
|
#
1847119d |
| 25-Apr-2016 |
Vladimir Murzin <vladimir.murzin@arm.com> |
ARM: vexpress/mps2: introduce MPS2 platform
The Cortex-M Prototyping System (or V2M-MPS2) is designed for prototyping and evaluation Cortex-M family of processors including the latest Cortex-M7
It
ARM: vexpress/mps2: introduce MPS2 platform
The Cortex-M Prototyping System (or V2M-MPS2) is designed for prototyping and evaluation Cortex-M family of processors including the latest Cortex-M7
It comes with a range of useful peripherals including 8MB single cycle SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA connector, Audio, SPI and GPIO.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
Revision tags: v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1 |
|
#
590b460c |
| 11-Feb-2016 |
Lars Persson <lars.persson@axis.com> |
arm: initial machine port for artpec-6 SoC
Basic machine port for the Artpec-6 SoC from Axis Communications.
Signed-off-by: Lars Persson <larper@axis.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
arm: initial machine port for artpec-6 SoC
Basic machine port for the Artpec-6 SoC from Axis Communications.
Signed-off-by: Lars Persson <larper@axis.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
show more ...
|
#
a34c6635 |
| 15-Feb-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
ARM: 8529/1: remove 'i' and 'zi' targets
These two targets were introduced by commit 13d5fadf45d1 ("[ARM] Make 'i' and 'zi' targets work") to short-circuit the dependencies for 'install' and 'zinsta
ARM: 8529/1: remove 'i' and 'zi' targets
These two targets were introduced by commit 13d5fadf45d1 ("[ARM] Make 'i' and 'zi' targets work") to short-circuit the dependencies for 'install' and 'zinstall'.
After that, commit 19514fc665ff ('arm, kbuild: make "make install" not depend on vmlinux') eventually made "(z)install" equivalent to "(z)i".
It is true that 'i' and 'zi' might be still useful as shorthands but the original intention had been already lost.
They do not even show up in "make ARCH=arm help", so I hope this deletion does not have much impact.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
Revision tags: openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4 |
|
#
32872c04 |
| 18-Dec-2015 |
Arnd Bergmann <arnd@arndb.de> |
ARM: default to multi_v7_defconfig
versatile_defconfig has not been a reasonable default for a very long time, there is very little work happening on this platform and it's based on an old ARM926 CP
ARM: default to multi_v7_defconfig
versatile_defconfig has not been a reasonable default for a very long time, there is very little work happening on this platform and it's based on an old ARM926 CPU core.
This changes the default to multi_v7_defconfig, which is much more relevant to anyone doing a build test on ARM, as it covers a wide range of platforms.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
show more ...
|
Revision tags: openbmc-20151217-1 |
|
#
d6de5b02 |
| 15-Dec-2015 |
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> |
ARM: tango4: Initial platform support
Support Sigma Designs ARM-based (specifically, Cortex-A9 MPCore r3p0) Tango4 "Secure Media Processor" platforms: smp8756, smp8758, smp8759 (8756 is single-core,
ARM: tango4: Initial platform support
Support Sigma Designs ARM-based (specifically, Cortex-A9 MPCore r3p0) Tango4 "Secure Media Processor" platforms: smp8756, smp8758, smp8759 (8756 is single-core, the latter are dual-core).
Note: 8758 vs 8759: same chip, different package.
Support for older MIPS-based platforms can be found elsewhere: https://github.com/mansr/linux-tangox
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
show more ...
|
Revision tags: openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1 |
|
#
a077224f |
| 03-Sep-2015 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
ARM: 8429/1: disable GCC SRA optimization
While working on the 32-bit ARM port of UEFI, I noticed a strange corruption in the kernel log. The following snprintf() statement (in drivers/firmware/efi/
ARM: 8429/1: disable GCC SRA optimization
While working on the 32-bit ARM port of UEFI, I noticed a strange corruption in the kernel log. The following snprintf() statement (in drivers/firmware/efi/efi.c:efi_md_typeattr_format())
snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
was producing the following output in the log:
| | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | | | | |UC] |RUN| | | | | | | |UC]
As it turns out, this is caused by incorrect code being emitted for the string() function in lib/vsprintf.c. The following code
if (!(spec.flags & LEFT)) { while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } } for (i = 0; i < len; ++i) { if (buf < end) *buf = *s; ++buf; ++s; } while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; }
when called with len == 0, triggers an issue in the GCC SRA optimization pass (Scalar Replacement of Aggregates), which handles promotion of signed struct members incorrectly. This is a known but as yet unresolved issue. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular case, it is causing the second while loop to be executed erroneously a single time, causing the additional space characters to be printed.
So disable the optimization by passing -fno-ipa-sra.
Cc: <stable@vger.kernel.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
Revision tags: v4.2, v4.2-rc8 |
|
#
3939f334 |
| 16-Aug-2015 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
ARM: 8418/1: add boot image dependencies to not generate invalid images
U-Boot is often used to boot the kernel on ARM boards, but uImage is not built by "make all", so we are often inclined to do "
ARM: 8418/1: add boot image dependencies to not generate invalid images
U-Boot is often used to boot the kernel on ARM boards, but uImage is not built by "make all", so we are often inclined to do "make all uImage" to generate DTBs, modules and uImage in a single command, but we should notice a pitfall behind it. In fact, "make all uImage" could generate an invalid uImage if it is run with the parallel option (-j).
You can reproduce this problem with the following procedure:
[1] First, build "all" and "uImage" separately. You will get a valid uImage
$ git clean -f -x -d $ export CROSS_COMPILE=<your-tools-prefix> $ make -s -j8 ARCH=arm multi_v7_defconfig $ make -s -j8 ARCH=arm all $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:21:35 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6138648 Bytes = 5994.77 kB = 5.85 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:20 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 6138712 Aug 8 23:21 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:20 arch/arm/boot/zImage
[2] Update some source file(s)
$ touch init/main.c
[3] Then, re-build "all" and "uImage" simultaneously. You will get an invalid uImage at random.
$ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CC init/main.o CHK include/generated/compile.h LD init/built-in.o LINK vmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map OBJCOPY arch/arm/boot/Image Building modules, stage 2. Kernel: arch/arm/boot/Image is ready GZIP arch/arm/boot/compressed/piggy.gzip AS arch/arm/boot/compressed/piggy.gzip.o Kernel: arch/arm/boot/Image is ready LD arch/arm/boot/compressed/vmlinux GZIP arch/arm/boot/compressed/piggy.gzip OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:23:14 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 26472 Bytes = 25.85 kB = 0.03 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready MODPOST 192 modules AS arch/arm/boot/compressed/piggy.gzip.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:23 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 26536 Aug 8 23:23 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:23 arch/arm/boot/zImage
Please notice the uImage is extremely small when this issue is encountered. Besides, "Kernel: arch/arm/boot/zImage is ready" is displayed twice, before and after the uImage log.
The root cause of this is the race condition between zImage and uImage. Actually, uImage depends on zImage, but the dependency between the two is only described in arch/arm/boot/Makefile. Because arch/arm/boot/Makefile is not included from the top-level Makefile, it cannot know the dependency between zImage and uImage.
Consequently, when we run make with the parallel option, Kbuild updates vmlinux first, and then two different threads descends into the arch/arm/boot/Makefile almost at the same time, one for updating zImage and the other for uImage. While one thread is re-generating zImage, the other also tries to update zImage before creating uImage on top of that. zImage is overwritten by the slower thread and then uImage is created based on the half-written zImage.
This is the reason why "Kernel: arch/arm/boot/zImage is ready" is displayed twice, and a broken uImage is created.
The same problem could happen on bootpImage.
This commit adds dependencies among Image, zImage, uImage, and bootpImage to arch/arm/Makefile, which is included from the top-level Makefile.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
Revision tags: v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2 |
|
#
acede515 |
| 28-Apr-2015 |
Jun Nie <jun.nie@linaro.org> |
ARM: zx: add basic support for ZTE ZX296702
Add basic code for ZTE ZX296702 platform.
[arnd: removed unused zx296702_init_machine function, and changed l2c aux val to default]
Signed-off-by
ARM: zx: add basic support for ZTE ZX296702
Add basic code for ZTE ZX296702 platform.
[arnd: removed unused zx296702_init_machine function, and changed l2c aux val to default]
Signed-off-by: Jun Nie <jun.nie@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
e8d235d4 |
| 11-May-2015 |
Joachim Eastwood <manabian@gmail.com> |
ARM: lpc18xx: add basic support for NXP LPC18xx/43xx SoCs
Add support for NXP's LPC18xx (Cortex-M3) and LPC43xx (Cortex-M4) SoCs. These SoCs are NXP's high preformance MCU line and can run at clock
ARM: lpc18xx: add basic support for NXP LPC18xx/43xx SoCs
Add support for NXP's LPC18xx (Cortex-M3) and LPC43xx (Cortex-M4) SoCs. These SoCs are NXP's high preformance MCU line and can run at clock speeds up to 180 MHz for LPC18xx and 204 MHz for LPC43xx.
LPC43xx is more or less a LPC18xx with a Cortex-M4F core and a few extra peripherals. The LPC43xx series also features one or two Cortex-M0 cores that can be used to offload the main M4 core.
Signed-off-by: Joachim Eastwood <manabian@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
9b799b78 |
| 09-May-2015 |
Maxime Coquelin <mcoquelin.stm32@gmail.com> |
ARM: Add STM32 family machine
STMicrolectronics's STM32 series is a family of Cortex-M microcontrollers. It is used in various applications, and proposes a wide range of peripherals.
Tested-by: Cha
ARM: Add STM32 family machine
STMicrolectronics's STM32 series is a family of Cortex-M microcontrollers. It is used in various applications, and proposes a wide range of peripherals.
Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
ba56a987 |
| 07-May-2015 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
ARM: UniPhier: add basic support for UniPhier architecture
Initial commit for a new SoC family, UniPhier, developed by Socionext Inc. (formerly, System LSI Business Division of Panasonic Corporation
ARM: UniPhier: add basic support for UniPhier architecture
Initial commit for a new SoC family, UniPhier, developed by Socionext Inc. (formerly, System LSI Business Division of Panasonic Corporation).
This commit includes a minimal set of components for booting the kernel, including SMP support.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7 |
|
#
7d485f64 |
| 24-Nov-2014 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
ARM: 8220/1: allow modules outside of bl range
Loading modules far away from the kernel in memory is problematic because the 'bl' instruction only has limited reach, and modules are not built with P
ARM: 8220/1: allow modules outside of bl range
Loading modules far away from the kernel in memory is problematic because the 'bl' instruction only has limited reach, and modules are not built with PLTs. Instead of using the -mlong-calls option (which affects all compiler emitted bl instructions, but not the ones in assembler), this patch allocates some additional space at module load time, and populates it with PLT like veneers when encountering relocations that are out of range.
This should work with all relocations against symbols exported by the kernel, including those resulting from GCC generated implicit function calls for ftrace etc.
The module memory size increases by about 5% on average, regardless of whether any PLT entries were actually needed. However, due to the page based rounding that occurs when allocating module memory, the average memory footprint increase is negligible.
Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
#
02e541db |
| 25-Mar-2015 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
ARM: 8323/1: force linker to use PIC veneers
When building a very large kernel, it is up to the linker to decide when and where to insert stubs to allow calls to functions that are out of range for
ARM: 8323/1: force linker to use PIC veneers
When building a very large kernel, it is up to the linker to decide when and where to insert stubs to allow calls to functions that are out of range for the ordinary b/bl instructions.
However, since the kernel is built as a position dependent binary, these stubs (aka veneers) may contain absolute addresses, which will break far calls performed with the MMU off.
For instance, the call from __enable_mmu() in the .head.text section to __turn_mmu_on() in the .idmap.text section may be turned into something like this:
c0008168 <__enable_mmu>: c0008168: f020 0002 bic.w r0, r0, #2 c000816c: f420 5080 bic.w r0, r0, #4096 c0008170: f000 b846 b.w c0008200 <____turn_mmu_on_veneer> [...] c0008200 <____turn_mmu_on_veneer>: c0008200: 4778 bx pc c0008202: 46c0 nop c0008204: e59fc000 ldr ip, [pc] c0008208: e12fff1c bx ip c000820c: c13dfae1 teqgt sp, r1, ror #21 [...] c13dfae0 <__turn_mmu_on>: c13dfae0: 4600 mov r0, r0 [...]
After adding --pic-veneer to the LDFLAGS, the veneer is emitted like this instead:
c0008200 <____turn_mmu_on_veneer>: c0008200: 4778 bx pc c0008202: 46c0 nop c0008204: e59fc004 ldr ip, [pc, #4] c0008208: e08fc00c add ip, pc, ip c000820c: e12fff1c bx ip c0008210: 013d7d31 teqeq sp, r1, lsr sp c0008214: 00000000 andeq r0, r0, r0
Note that this particular example is best addressed by moving .head.text and .idmap.text closer together, but this issue could potentially affect any code that needs to execute with the MMU off.
Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
#
e5b61deb |
| 25-Mar-2015 |
Nathan Lynch <nathan_lynch@mentor.com> |
ARM: 8332/1: add CONFIG_VDSO Kconfig and Makefile bits
Allow users to enable the vdso in Kconfig; include the vdso in the build if CONFIG_VDSO is enabled. Add 'vdso_install' target.
Signed-off-by:
ARM: 8332/1: add CONFIG_VDSO Kconfig and Makefile bits
Allow users to enable the vdso in Kconfig; include the vdso in the build if CONFIG_VDSO is enabled. Add 'vdso_install' target.
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
#
c0c89faf |
| 13-Mar-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
ARM: Remove mach-msm and associated ARM architecture code
The maintainers for mach-msm no longer have any plans to support or test the platforms supported by this architecture[1]. Most likely there
ARM: Remove mach-msm and associated ARM architecture code
The maintainers for mach-msm no longer have any plans to support or test the platforms supported by this architecture[1]. Most likely there aren't any active users of this code anyway, so let's delete it.
[1] http://lkml.kernel.org/r/20150307031212.GA8434@fifo99.com Cc: David Brown <davidb@codeaurora.org> Cc: Bryan Huntsman <bryanh@codeaurora.org> Cc: Daniel Walker <dwalker@fifo99.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
show more ...
|
#
445d9b30 |
| 12-Mar-2015 |
Tsahee Zidenberg <tsahee@annapurnalabs.com> |
ARM: Alpine: Initial support for Alpine platform
This patch introduces initial architecture and device-tree support.
Signed-off-by: Saeed Bishara <saeed@annapurnalabs.com> Signed-off-by: Tsahee Zid
ARM: Alpine: Initial support for Alpine platform
This patch introduces initial architecture and device-tree support.
Signed-off-by: Saeed Bishara <saeed@annapurnalabs.com> Signed-off-by: Tsahee Zidenberg <tsahee@annapurnalabs.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
16083d45 |
| 09-Mar-2015 |
Baruch Siach <baruch@tkos.co.il> |
ARM: digicolor: add the machine directory to Makefile
Make the digicolor specific DT_MACHINE_START entry visible.
Fixes: df8d742e929 (ARM: initial support for Conexant Digicolor CX92755 SoC) Signed
ARM: digicolor: add the machine directory to Makefile
Make the digicolor specific DT_MACHINE_START entry visible.
Fixes: df8d742e929 (ARM: initial support for Conexant Digicolor CX92755 SoC) Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
fca08f32 |
| 08-Jan-2015 |
Wang Nan <wangnan0@huawei.com> |
ARM: probes: move all probe code to dedicate directory
In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell King suggests to move all probe related code to arch/arm/probes. This pat
ARM: probes: move all probe code to dedicate directory
In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell King suggests to move all probe related code to arch/arm/probes. This patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this patch also moves patch.h to 'arch/arm/include/asm/patch.h', and related '#include' directives are also midified to '#include <asm/patch.h>'.
Following is an overview of this patch:
./arch/arm/kernel/ ./arch/arm/probes/ |-- Makefile |-- Makefile |-- probes-arm.c ==> |-- decode-arm.c |-- probes-arm.h ==> |-- decode-arm.h |-- probes-thumb.c ==> |-- decode-thumb.c |-- probes-thumb.h ==> |-- decode-thumb.h |-- probes.c ==> |-- decode.c |-- probes.h ==> |-- decode.h | |-- kprobes | | |-- Makefile |-- kprobes-arm.c ==> | |-- actions-arm.c |-- kprobes-common.c ==> | |-- actions-common.c |-- kprobes-thumb.c ==> | |-- actions-thumb.c |-- kprobes.c ==> | |-- core.c |-- kprobes.h ==> | |-- core.h |-- kprobes-test-arm.c ==> | |-- test-arm.c |-- kprobes-test.c ==> | |-- test-core.c |-- kprobes-test.h ==> | |-- test-core.h |-- kprobes-test-thumb.c ==> | `-- test-thumb.c | `-- uprobes | |-- Makefile |-- uprobes-arm.c ==> |-- actions-arm.c |-- uprobes.c ==> |-- core.c |-- uprobes.h ==> `-- core.h | `-- patch.h ==> arch/arm/include/asm/patch.h
Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Jon Medhurst <tixy@linaro.org>
show more ...
|
Revision tags: v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4 |
|
#
6f889d8b |
| 03-Sep-2014 |
Robert Richter <rrichter@cavium.com> |
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
The machine description is not needed to build dtb files.
Signed-off-by: Robert Richter <rrichter@cavium.com>
|