1. 19 Feb, 2009 1 commit
  2. 01 Oct, 2008 1 commit
  3. 23 Jul, 2008 1 commit
    • Jason Wessel's avatar
      kgdb: support for ARCH=arm · 5cbad0eb
      Jason Wessel authored
      This patch adds the ARCH=arm specific a kgdb backend, originally
      written by Deepak Saxena <dsaxena@plexity.net> and George Davis
      <gdavis@mvista.com>.  Geoff Levand <geoffrey.levand@am.sony.com>,
      Nicolas Pitre, Manish Lachwani, and Jason Wessel have contributed
      various fixups here as well.
      The KGDB patch makes one change to the core ARM architecture such that
      the traps are initialized early for use with the debugger or other
      [ mingo@elte.hu: small cleanups. ]
      [ ben-linux@fluff.org: fixed early_trap_init ]
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Acked-by: default avatarDeepak Saxena <dsaxena@plexity.net>
  4. 02 Jun, 2008 1 commit
  5. 18 Apr, 2008 1 commit
  6. 17 Apr, 2008 1 commit
  7. 04 Feb, 2008 1 commit
    • Richard Purdie's avatar
      [ARM] 4736/1: Export atags to userspace and allow kexec to use customised atags · 4cd9d6f7
      Richard Purdie authored
      Currently, the atags used by kexec are fixed to the ones originally used
      to boot the kernel. This is less than ideal as changing the commandline,
      initrd and other options would be a useful feature.
      This patch exports the atags used for the current kernel to userspace
      through an "atags" file in procfs. The presence of the file is
      controlled by its own Kconfig option and cleans up several ifdef blocks
      into a separate file. The tags for the new kernel are assumed to be at
      a fixed location before the kernel image itself. The location of the
      tags used to boot the original kernel is unimportant and no longer
      Based on a patch from Uli Luckas <u.luckas@road.de>
      Signed-off-by: default avatarRichard Purdie <rpurdie@rpsys.net>
      Acked-by: default avatarUli Luckas <u.luckas@road.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  8. 26 Jan, 2008 2 commits
    • Abhishek Sagar's avatar
      ARM kprobes: core code · 24ba613c
      Abhishek Sagar authored
      This is a full implementation of Kprobes including Jprobes and
      Kretprobes support.
      This ARM implementation does not follow the usual kprobes double-
      exception model. The traditional model is where the initial kprobes
      breakpoint calls kprobe_handler(), which returns from exception to
      execute the instruction in its original context, then immediately
      re-enters after a second breakpoint (or single-stepping exception)
      into post_kprobe_handler(), each time the probe is hit..  The ARM
      implementation only executes one kprobes exception per hit, so no
      post_kprobe_handler() phase. All side-effects from the kprobe'd
      instruction are resolved before returning from the initial exception.
      As a result, all instructions are _always_ effectively boosted
      regardless of the type of instruction, and even regardless of whether
      or not there is a post-handler for the probe.
      Signed-off-by: default avatarAbhishek Sagar <sagar.abhishek@gmail.com>
      Signed-off-by: default avatarQuentin Barnes <qbarnes@gmail.com>
      Signed-off-by: default avatarNicolas Pitre <nico@marvell.com>
    • Quentin Barnes's avatar
      ARM kprobes: instruction single-stepping support · 35aa1df4
      Quentin Barnes authored
      This is the code implementing instruction single-stepping for kprobes
      on ARM.
      To get around the limitation of no Next-PC and no hardware single-
      stepping, all kprobe'd instructions are split into three camps:
      simulation, emulation, and rejected. "Simulated" instructions are
      those instructions which behavior is reproduced by straight C code.
      "Emulated" instructions are ones that are copied, slightly altered
      and executed directly in the instruction slot to reproduce their
      behavior.  "Rejected" instructions are ones that could be simulated,
      but work hasn't been put into simulating them. These instructions
      should be very rare, if not unencountered, in the kernel. If ever
      needed, code could be added to simulate them.
      One might wonder why this and the ptrace singlestep facility are not
      sharing some code.  Both approaches are fundamentally different because
      the ptrace code regains control after the stepped instruction by installing
      a breakpoint after the instruction itself, and possibly at the location
      where the instruction might be branching to, instead of simulating or
      emulating the target instruction.
      The ptrace approach isn't suitable for kprobes because the breakpoints
      would have to be moved back, and the icache flushed, everytime the
      probe is hit to let normal code execution resume, which would have a
      significant performance impact. It is also racy on SMP since another
      CPU could, with the right timing, sail through the probe point without
      being caught.  Because ptrace single-stepping always result in a
      different process to be scheduled, the concern for performance is much
      less significant.
      On the other hand, the kprobes approach isn't (currently) suitable for
      ptrace because it has no provision for proper user space memory
      protection and translation, and even if that was implemented, the gain
      wouldn't be worth the added complexity in the ptrace path compared to
      the current approach.
      So, until kprobes does support user space, both kprobes and ptrace are
      best kept independent and separate.
      Signed-off-by: default avatarQuentin Barnes <qbarnes@gmail.com>
      Signed-off-by: default avatarAbhishek Sagar <sagar.abhishek@gmail.com>
      Signed-off-by: default avatarNicolas Pitre <nico@marvell.com>
  9. 28 Apr, 2007 1 commit
  10. 16 Feb, 2007 1 commit
    • Richard Purdie's avatar
      [ARM] 4137/1: Add kexec support · c587e4a6
      Richard Purdie authored
      Add kexec support to ARM.
      Improvements like commandline handling could be made but this patch gives
      basic functional support. It uses the next available syscall number, 347.
      Once the syscall number is known, userspace support will be
      finalised/submitted to kexec-tools, various patches already exist.
      Originally based on a patch by Maxim Syrchin but updated and forward
      ported by various people.
      Signed-off-by: default avatarRichard Purdie <rpurdie@rpsys.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  11. 09 Feb, 2007 1 commit
  12. 03 Dec, 2006 1 commit
    • Lennert Buytenhek's avatar
      [ARM] 3881/4: xscale: clean up cp0/cp1 handling · afe4b25e
      Lennert Buytenhek authored
      XScale cores either have a DSP coprocessor (which contains a single
      40 bit accumulator register), or an iWMMXt coprocessor (which contains
      eight 64 bit registers.)
      Because of the small amount of state in the DSP coprocessor, access to
      the DSP coprocessor (CP0) is always enabled, and DSP context switching
      is done unconditionally on every task switch.  Access to the iWMMXt
      coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
      first issued, and iWMMXt context switching is done lazily.
      CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
      have iWMMXt support', but boards are supposed to select this config
      symbol by hand, and at least one pxa27x board doesn't get this right,
      so on that board, proc-xscale.S will incorrectly assume that we have a
      DSP coprocessor, enable CP0 on boot, and we will then only save the
      first iWMMXt register (wR0) on context switches, which is Bad.
      This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
      might have iWMMXt support, and we will enable iWMMXt context switching
      if it does.'  This means that with this patch, running a CONFIG_IWMMXT=n
      kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
      state over context switches, and running a CONFIG_IWMMXT=y kernel on a
      non-iWMMXt capable CPU will still do DSP context save/restore.
      These changes should make iWMMXt work on PXA3xx, and as a side effect,
      enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
      as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
      as well as setting and using HWCAP_IWMMXT properly.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  13. 28 Aug, 2006 1 commit
  14. 01 Jul, 2006 1 commit
  15. 28 Jun, 2006 1 commit
  16. 24 Apr, 2006 1 commit
  17. 14 Jan, 2006 1 commit
  18. 04 Jan, 2006 1 commit
  19. 03 Jan, 2006 1 commit
  20. 29 Oct, 2005 1 commit
    • Nicolas Pitre's avatar
      [ARM] 3061/1: cleanup the XIP link address mess · 37d07b72
      Nicolas Pitre authored
      Patch from Nicolas Pitre
      Since vmlinux.lds.S is preprocessed, we can use the defines already
      present in asm/memory.h (allowed by patch #3060) for the XIP kernel link
      address instead of relying on a duplicated Makefile hardcoded value, and
      also get rid of its dependency on awk to handle it at the same time.
      While at it let's clean XIP stuff even further and make things clearer
      in head.S with a nice code reduction.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  21. 20 Jun, 2005 1 commit
  22. 26 Apr, 2005 1 commit
  23. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!