An error occurred fetching the project authors.
- 17 Apr, 2019 1 commit
-
-
Thierry Reding authored
Move the Trusted Foundations support out of arch/arm/firmware and into drivers/firmware where most other firmware support implementations are located. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
- 01 Mar, 2019 1 commit
-
-
Sugaya Taichi authored
This adds the basic M10V SoC support under arch/arm. Since all cores are activated in the custom bootloader before booting linux, it is necessary to wait for the secondary-cores using cpu-enable- method and special sram. Signed-off-by: Sugaya Taichi <sugaya.taichi@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
- 01 Feb, 2019 1 commit
-
-
Nathan Chancellor authored
This option is not supported by lld: ld.lld: error: unknown argument: -p This has been a no-op in binutils since 2004 (see commit dea514f51da1 in that tree). Given that the lowest officially supported of binutils for the kernel is 2.20, which was released in 2009, nobody needs this flag around so just remove it. Commit 1a381d4a ("arm64: remove no-op -p linker flag") did the same for arm64. Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Nicolas Pitre <nico@linaro.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 31 Dec, 2018 1 commit
-
-
Andreas Färber authored
Introduce ARCH_RDA and mach-rda for RDA Micro SoCs. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
-
- 12 Dec, 2018 1 commit
-
-
Ard Biesheuvel authored
On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
-
- 04 Oct, 2018 1 commit
-
-
Jason A. Donenfeld authored
The purpose of CONFIG_CPU_32v3 is to avoid ldrh/strh on the RiscPC, which is pretty much an ARMv4 device, except its bus will choke on the half-words. The way to make the C compiler not output ldrh/strh is with -march=armv3, which doesn't support them in the ISA. However, this prevents certain cryptography code from working that uses instructions like umull. Fortunately there's also -march=armv3m that does support those, making it possible to continue assembling optimized cryptography routines for our beloved RiscPC. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 02 Oct, 2018 1 commit
-
-
Rob Herring authored
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Paul Burton <paul.burton@mips.com> Acked-by: Ley Foon Tan <ley.foon.tan@intel.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: linux-kbuild@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: uclinux-h8-devel@lists.sourceforge.jp Cc: linux-mips@linux-mips.org Cc: nios2-dev@lists.rocketboards.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Rob Herring <robh@kernel.org>
-
- 19 Sep, 2018 1 commit
-
-
Masahiro Yamada authored
You can always prefix machine/plat header search paths with $(srctree)/ because $(srctree) is '.' for in-tree building. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 23 Aug, 2018 1 commit
-
-
Masahiro Yamada authored
Commit a0f97e06 ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS. Commit 222d394d ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS. Commit 06c5040c ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS. For some reason, LDFLAGS was not renamed. Using a well-known variable like LDFLAGS may result in accidental override of the variable. Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention. I did not touch Makefiles under tools/ since the tools build system is a different world. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
-
- 01 Aug, 2018 1 commit
-
-
Masahiro Yamada authored
arch/arm/mach-uniphier/Makefile has been unused for a long time. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
- 18 Jul, 2018 1 commit
-
-
Masahiro Yamada authored
Since commit ce99d0bf ("kbuild: clear LDFLAGS in the top Makefile"), the top-level Makefile caters to this. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
-
- 11 Jul, 2018 1 commit
-
-
Masahiro Yamada authored
With the recent syntax extension, Kconfig is now able to evaluate the compiler / toolchain capability. However, accumulating flags to 'LD' is not compatible with the way it works; 'LD' must be passed to Kconfig to call $(ld-option,...) from Kconfig files. If you tweak 'LD' in arch Makefile depending on CONFIG_CPU_BIG_ENDIAN, this would end up with circular dependency between Makefile and Kconfig. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 01 Jun, 2018 1 commit
-
-
Luc Van Oostenryck authored
By default, sparse assumes a 64bit machine when compiled on x86-64 and 32bit when compiled on anything else. This can of course create all sort of problems for the other archs, like issuing false warnings ('shift too big (32) for type unsigned long'), or worse, failing to emit legitimate warnings. Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT, to CHECKFLAGS in the main Makefile (and so for all archs). Also, remove the now unneeded -m32/-m64 in arch specific Makefiles. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 19 May, 2018 1 commit
-
-
Stefan Agner authored
According to GCC documentation -m(no-)thumb-interwork is meaningless in AAPCS configurations. Also clang does not support the flag: clang-5.0: error: unknown argument: '-mno-thumb-interwork' Just drop -mno-thumb-interwork in AEABI configuration. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 23 Apr, 2018 1 commit
-
-
Geert Uytterhoeven authored
Since commit 9b5ba0df ("ARM: shmobile: Introduce ARCH_RENESAS") ARCH_RENESAS is a more appropriate platform dependency than the legacy ARCH_SHMOBILE, hence use the former. This will allow to drop ARCH_SHMOBILE on ARM in the near future. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
-
- 06 Mar, 2018 1 commit
-
-
Brendan Higgins authored
Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> Reviewed-by: Avi Fishman <avifishman70@gmail.com> Tested-by: Tomer Maimon <tmaimon77@gmail.com> Tested-by: Avi Fishman <avifishman70@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
- 17 Dec, 2017 1 commit
-
-
Nicolas Pitre authored
The GNU assembler has implemented the "unified syntax" parsing since 2005. This "unified" syntax is required when the kernel is built in Thumb2 mode. However the "unified" syntax is a mixed bag of features, including not requiring a `#' prefix with immediate operands. This leads to situations where some code builds just fine in Thumb2 mode and fails to build in ARM mode if that prefix is missing. This behavior discrepancy makes build tests less valuable, forcing both ARM and Thumb2 builds for proper coverage. Let's "fix" this issue by always using the "unified" syntax for both ARM and Thumb2 mode. Given that the documented minimum binutils version that properly builds the kernel is version 2.20 released in 2010, we can assume that any toolchain capable of building the latest kernel is also "unified syntax" capable. Whith this, a bunch of macros used to mask some differences between both syntaxes can be removed, with the side effect of making LTO easier. Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 01 Nov, 2017 1 commit
-
-
Luc Van Oostenryck authored
ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined or not to correctly select or define endian-specific macros, structures or pieces of code. These macros are predefined by the compiler but sparse knows nothing about them and thus may pre-process files differently from what gcc would. Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse, depending on the endianness of the kernel, like defined by GCC. Note: In most case it won't change anything since most ARMs use little-endian (but an allyesconfig would use big-endian!). To: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 30 Oct, 2017 1 commit
-
-
Cao jin authored
As kbuild document & commit 6588169d says: KBUILD_{C,LD}FLAGS_MODULE are used to add arch-specific options for $(CC) and $(LD). From commandline, {C,LD}FLAGS_MODULE shall be used. Doesn't have any functional change, but just follow kbuild rules. Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> CC: Russell King <linux@armlinux.org.uk> CC: linux-arm-kernel@lists.infradead.org Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 29 Oct, 2017 1 commit
-
-
Martin Blumenstingl authored
This adds the necessary SMP-operations and startup code to use the additional cores on the Amlogic Meson8/Meson8m2 (both are using the same sequence) and Meson8b (using a slightly difference sequence) SoCs. Signed-off-by: Carlo Caione <carlo@endlessm.com> [add Meson8/Meson8m2 support and allow taking CPU cores offline as well] Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
-
- 12 Oct, 2017 1 commit
-
-
Luc Van Oostenryck II authored
By default sparse uses the characteristics of the build machine to infer things like the wordsize. This is fine when doing native builds but for ARM it's, I suspect, very rarely the case and if the build are done on a 64bit machine we get a bunch of warnings like: 'cast truncates bits from constant value (... becomes ...)' Fix this by adding the -m32 flags for sparse. Reported-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- 21 Jun, 2017 1 commit
-
-
Andreas Färber authored
Add ARCH_ACTIONS and mach-actions/owl.c for "actions,s500". Signed-off-by: Andreas Färber <afaerber@suse.de>
-
- 20 Mar, 2017 1 commit
-
-
Michal Marek authored
The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which expect it to point to the image file in the build directory. The builddeb script has a workaround for architectures which only provide the basename, but let's provide a clean interface for packaging tools. Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 23 Nov, 2016 1 commit
-
-
Neil Armstrong authored
Refactor the oxnas Kconfig entries among the OX810SE and OX820 configs, and add the files to support the OX820 SMP feature. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
-
- 18 Oct, 2016 2 commits
-
-
Russell King authored
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>
-
Russell King authored
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>
-
- 12 Aug, 2016 1 commit
-
-
Mark Rutland authored
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>
-
- 10 Aug, 2016 1 commit
-
-
Arnd Bergmann authored
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>
-
- 06 Jul, 2016 1 commit
-
-
Alexander Shiyan authored
Switch CLPS711X to multiplatform. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
- 22 Jun, 2016 1 commit
-
-
Masahiro Yamada authored
Commit 3939f334 ("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>
-
- 26 Apr, 2016 1 commit
-
-
Vladimir Murzin authored
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>
-
- 24 Feb, 2016 1 commit
-
-
Lars Persson authored
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>
-
- 16 Feb, 2016 1 commit
-
-
Masahiro Yamada authored
These two targets were introduced by commit 13d5fadf ("[ARM] Make 'i' and 'zi' targets work") to short-circuit the dependencies for 'install' and 'zinstall'. After that, commit 19514fc6 ('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>
-
- 31 Dec, 2015 1 commit
-
-
Arnd Bergmann authored
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>
-
- 22 Dec, 2015 1 commit
-
-
Marc Gonzalez authored
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-tangoxSigned-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
-
- 07 Sep, 2015 1 commit
-
-
Ard Biesheuvel authored
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>
-
- 18 Aug, 2015 1 commit
-
-
Masahiro Yamada authored
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-gdd2384a7-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-gdd2384a7-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>
-
- 15 May, 2015 3 commits
-
-
Jun Nie authored
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>
-
Joachim Eastwood authored
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>
-
Maxime Coquelin authored
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>
-