1. 05 Dec, 2018 1 commit
  2. 12 Aug, 2016 1 commit
  3. 10 Aug, 2016 1 commit
    • Arnd Bergmann's avatar
      ARM: hide mach-*/ include for ARM_SINGLE_ARMV7M · de8a06f6
      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: 's avatarArnd Bergmann <arnd@arndb.de>
      de8a06f6
  4. 06 Jul, 2016 1 commit
  5. 22 Jun, 2016 1 commit
    • Masahiro Yamada's avatar
      ARM: 8576/1: avoid duplicating "Kernel: arch/arm/boot/*Image is ready" · c6bbfbb7
      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's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c6bbfbb7
  6. 26 Apr, 2016 1 commit
  7. 24 Feb, 2016 1 commit
  8. 16 Feb, 2016 1 commit
  9. 31 Dec, 2015 1 commit
  10. 22 Dec, 2015 1 commit
  11. 07 Sep, 2015 1 commit
    • Ard Biesheuvel's avatar
      ARM: 8429/1: disable GCC SRA optimization · a077224f
      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: 's avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a077224f
  12. 18 Aug, 2015 1 commit
    • Masahiro Yamada's avatar
      ARM: 8418/1: add boot image dependencies to not generate invalid images · 3939f334
      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's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      3939f334
  13. 15 May, 2015 3 commits
  14. 12 May, 2015 1 commit
  15. 08 May, 2015 1 commit
    • Ard Biesheuvel's avatar
      ARM: 8220/1: allow modules outside of bl range · 7d485f64
      Ard Biesheuvel authored
      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: 's avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7d485f64
  16. 29 Mar, 2015 1 commit
    • Ard Biesheuvel's avatar
      ARM: 8323/1: force linker to use PIC veneers · 02e541db
      Ard Biesheuvel authored
      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: 's avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      02e541db
  17. 27 Mar, 2015 2 commits
  18. 16 Mar, 2015 1 commit
  19. 11 Mar, 2015 1 commit
  20. 09 Jan, 2015 1 commit
    • Wang Nan's avatar
      ARM: probes: move all probe code to dedicate directory · fca08f32
      Wang Nan authored
      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: 's avatarWang Nan <wangnan0@huawei.com>
      Acked-by: 's avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: 's avatarJon Medhurst <tixy@linaro.org>
      fca08f32
  21. 21 Oct, 2014 3 commits
  22. 02 Oct, 2014 1 commit
  23. 26 Sep, 2014 1 commit
  24. 25 Sep, 2014 1 commit
  25. 31 Jul, 2014 1 commit
  26. 22 Jul, 2014 1 commit
  27. 18 Jul, 2014 2 commits
  28. 13 Jul, 2014 1 commit
  29. 12 Jul, 2014 1 commit
  30. 07 Jul, 2014 1 commit
  31. 23 May, 2014 1 commit
  32. 25 Feb, 2014 1 commit
  33. 20 Feb, 2014 1 commit
    • Jason Cooper's avatar
      kbuild: dtbs_install: new make target · f4d4ffc0
      Jason Cooper authored
      Unlike other build products in the Linux kernel, there is no 'make
      *install' mechanism to put devicetree blobs in a standard place.
      
      This commit adds a new 'dtbs_install' make target which copies all of
      the dtbs into the INSTALL_DTBS_PATH directory. INSTALL_DTBS_PATH can be
      set before calling make to change the default install directory. If not
      set then it defaults to:
      
      	$INSTALL_PATH/dtbs/$KERNELRELEASE.
      
      This is done to keep dtbs from different kernel versions separate until
      things have settled down.  Once the dtbs are stable, and not so strongly
      linked to the kernel version, the devicetree files will most likely move
      to their own repo.  Users will need to upgrade install scripts at that
      time.
      
      v7: (reworked by Grant Likely)
      - Moved rules from arch/arm/Makefile to arch/arm/boot/dts/Makefile so
        that each dtb install could have a separate target and be reported as
        part of the make output.
      - Fixed dependency problem to ensure $KERNELRELEASE is calculated before
        attempting to install
      - Removed option to call external script. Copying the files should be
        sufficient and a build system can post-process the install directory.
        Despite the fact an external script is used for installing the kernel,
        I don't think that is a pattern that should be encouraged. I would
        rather see buildroot type tools post process the install directory to
        rename or move dtb files after installing to a staging directory.
        - Plus it is easy to add a hook after the fact without blocking the
          rest of this feature.
      - Move the helper targets into scripts/Makefile.lib with the rest of the
        common dtb rules
      Signed-off-by: 's avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: 's avatarGrant Likely <grant.likely@linaro.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rob Herring <robh+dt@kernel.org>
      f4d4ffc0
  34. 19 Feb, 2014 1 commit