1. 07 Apr, 2019 1 commit
  2. 14 Mar, 2019 1 commit
  3. 08 Jan, 2019 1 commit
    • Antonio Borneo's avatar
      target/arm: add support for multi-architecture gdb · 5c941edc
      Antonio Borneo authored
      GDB can be built for multi-architecture through the command
      	./configure --enable-targets=all && make
      Such multi-architecture GDB requires the target's architecture to
      be selected either manually by the user through the GDB command
      "set architecture" or automatically by the target description sent
      by the remote target (i.e. OpenOCD).
      
      Commit e65acd88
      
       ("gdb_server: add
      support for architecture element") already provides the required
      infrastructure to support multi-architecture gdb.
      
      arm-none-eabi-gdb 8.2 uses "arm" as default architecture, but also
      supports the following values: "arm_any", "armv2", "armv2a",
      "armv3", "armv3m", "armv4", "armv4t", "armv5", "armv5t", "armv5te",
      "armv5tej", "armv6", "armv6k", "armv6kz", "armv6-m", "armv6s-m",
      "armv6t2", "armv7", "armv7e-m", "armv8-a", "armv8-m.base",
      "armv8-m.main", "armv8-r", "ep9312", "iwmmxt", "iwmmxt2", "xscale".
      These values can be displayed on arm gdb prompt by typing
      "set architecture " followed by a TAB for autocompletion.
      
      Set the gdb architecture value for all arm targets to "arm".
      
      Change-Id: I176cb89878606e1febd546ce26543b3e7849500a
      Signed-off-by: default avatarAntonio Borneo <borneo.antonio@gmail.com>
      Reviewed-on: http://openocd.zylin.com/4754
      
      
      Tested-by: jenkins
      Reviewed-by: default avatarSpencer Oliver <spen@spen-soft.co.uk>
      5c941edc
  4. 25 Jan, 2018 1 commit
  5. 10 Feb, 2017 1 commit
    • Dongxue Zhang's avatar
      target: Add 64-bit target address support · 47b8cf84
      Dongxue Zhang authored
      
      
      Define a target_addr_t type to support 32-bit and 64-bit addresses at
      the same time. Also define matching TARGET_PRI*ADDR format macros as
      well as a convenient TARGET_ADDR_FMT.
      
      In targets that are 32-bit (avr32, nds32, arm7/9/11, fm4, xmc1000)
      be least invasive by leaving the formatting unchanged apart from the
      type;
      for generic code adopt TARGET_ADDR_FMT as unified address format.
      
      Don't silently change gdb formatting here, leave that to later.
      
      Add COMMAND_PARSE_ADDRESS() macro to abstract the address type.
      Implement it using its own parse_target_addr() function, in the hopes
      of catching pointer type mismatches better.
      
      Add '--disable-target64' configure option to revert to previous 32-bit
      target address behavior.
      
      Change-Id: I2e91d205862ceb14f94b3e72a7e99ee0373a85d5
      Signed-off-by: default avatarDongxue Zhang <elta.era@gmail.com>
      Signed-off-by: default avatarDavid Ung <david.ung.42@gmail.com>
      [AF: Default to enabling (Paul Fertser), rename macros, simplify]
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Signed-off-by: default avatarMatthias Welwarsky <matthias.welwarsky@sysgo.com>
      47b8cf84
  6. 08 Dec, 2016 1 commit
  7. 04 Nov, 2016 1 commit
  8. 24 May, 2016 1 commit
  9. 05 May, 2016 1 commit
    • Tomas Vanek's avatar
      target: improve robustness of reset command · 88258042
      Tomas Vanek authored
      
      
      Before this change jim_target_reset() checked examined state of a target
      and failed without calling .assert_reset in particular target layer
      (and without comprehensible warning to user).
      Cortex-M target (which refuses access to DP under active SRST):
      If connection is lost then reset process fails before asserting SRST
      and connection with MCU is not restored.
      This resulted in:
      1) A lot of Cortex-M MCUs required use of reset button or cycling power
      after firmware blocked SWD access somehow (sleep, misconfigured clock etc).
      If firmware blocks SWD access early during initialization, a MCU could
      become completely inaccessible by SWD.
      2) If OpenOCD is (re)started and a MCU is in a broken state unresponsive
      to SWD, reset command does not work even if it could help to restore communication.
      Hopefully this scenario is not possible under full JTAG.
      
      jim_target_reset() in target.c now does not check examined state
      and delegates this task to a particular target. All targets have been checked
      and xx_assert_reset() (or xx_deassert_reset()) procedures were changed
      to check examined state if needed. Targets except arm11, cortex_a and cortex_m
      just fail if target is not examined although it may be possible to use
      at least hw reset. Left as TODO for developers familiar with these targets.
      
      cortex_m_assert_reset(): memory access errors are stored
      instead of immediate returning them to a higher level.
      Errors from less important reads/writes are ignored.
      Requested reset always leads to a configured action.
      
      arm11_assert_reset() just asserts hw reset in case of not examined target.
      cortex_a_assert_reset() works as usual in case of not examined target.
      
      Change-Id: I84fa869f4f58e2fa83b6ea75de84440d9dc3d929
      Signed-off-by: default avatarTomas Vanek <vanekt@fbl.cz>
      Reviewed-on: http://openocd.zylin.com/2606
      
      
      Tested-by: jenkins
      Reviewed-by: default avatarMatthias Welwarsky <matthias@welwarsky.de>
      Reviewed-by: default avatarPaul Fertser <fercerpav@gmail.com>
      88258042
  10. 29 Feb, 2016 2 commits
  11. 09 Mar, 2015 1 commit
    • Paul Fertser's avatar
      armv7m: add FPU registers support · dccbf7d8
      Paul Fertser authored
      
      
      This patch adds the fpv4-sp-d16 registers to the armv7m register set.
      
      The work is inspired by Mathias K but takes a different approach:
      instead of having both double and single presicion registers in the
      cache this patch works only with the doubles and counts on GDB to
      split the data in halves whenever needed.
      
      Tested with HLA only (on an STM32F334 disco board).
      
      Currently this patch makes all ARMv7-M targets report an FPU-enabled
      target description to GDB. It shouldn't harm if the user is not trying
      to access non-existing FPU. However, the plan is to make this depend
      on actual FPU presence later.
      
      Change-Id: Ifcc72c80ef745230c42e4dc3995f792753fc4e7a
      Signed-off-by: default avatarMathias K <kesmtp@freenet.de>
      [fercerpav@gmail.com: rework to fit target description framework]
      Signed-off-by: default avatarPaul Fertser <fercerpav@gmail.com>
      Reviewed-on: http://openocd.zylin.com/514
      
      
      Tested-by: jenkins
      Reviewed-by: default avatarPeter Stuge <peter@stuge.se>
      Reviewed-by: default avatarSpencer Oliver <spen@spen-soft.co.uk>
      dccbf7d8
  12. 11 Feb, 2015 1 commit
  13. 06 Oct, 2014 1 commit
  14. 22 Sep, 2014 1 commit
  15. 02 Aug, 2014 1 commit
  16. 29 Mar, 2014 1 commit
  17. 20 Jan, 2014 1 commit
  18. 31 Oct, 2013 1 commit
  19. 08 Sep, 2013 2 commits
  20. 01 Jul, 2013 2 commits
  21. 05 Jun, 2013 1 commit
  22. 28 Apr, 2013 1 commit
  23. 15 Mar, 2013 1 commit
  24. 06 Feb, 2012 1 commit
  25. 23 Jan, 2012 1 commit
  26. 18 Jan, 2012 1 commit
  27. 04 Jan, 2012 2 commits
  28. 20 Dec, 2011 1 commit
  29. 07 Nov, 2011 1 commit
  30. 18 Oct, 2011 1 commit
  31. 01 Apr, 2011 1 commit
  32. 31 Mar, 2011 1 commit
  33. 03 Jan, 2011 1 commit
  34. 04 Dec, 2010 1 commit
    • Mike Dunn's avatar
      xscale: trace buffer remains enabled until explicitly disabled · 2e7d51c9
      Mike Dunn authored
      
      
      Hi everyone,
      
      Since a call went out for patches... been sitting on this for months.  For some
      reason, the xscale trace buffer is automatically disabled as soon as a break
      occurs and the trace data is collected.  This patch was a result of the
      frustration of always re-enabling it, or else hitting a breakpoint and checking
      the trace data, only to discover that I forgot to re-enable it before resuming.
      Don't see why it should work this way.  There is no run-time penalty, AFAIK.
      
      Along the way, I also cleaned up a little by removing the ugly practice of
      recording wrap mode by setting the fill count variable to "-1", replacing it
      with an enum that records the trace mode.
      
      I've been using this for months.  Comments, criticisms gratefully received.
      
      Mike
      Signed-off-by: default avatarMike Dunn <mikedunn@newsguy.com>
      2e7d51c9
  35. 20 Sep, 2010 2 commits
    • Øyvind Harboe's avatar
      warnings: fix alignment warnings · f6a3fc81
      Øyvind Harboe authored
      
      
      These warnings are for architectures that do not
      support non-aligned word access.
      Signed-off-by: default avatarØyvind Harboe <oyvind.harboe@zylin.com>
      f6a3fc81
    • Mike Dunn's avatar
      xscale: check that wp length does not exceed address · ebfb2f4f
      Mike Dunn authored
      
      
      Hi everyone,
      
      A while back I sent in a patch that adds support for watchpoint lengths greater
      than four on xscale.  It's been working well, until the other day, when it
      caused an unexpected debug exception.  Looking into this I realized there is a
      case where it breaks: when the length arg is greater than the base address.
      This is a consequence of the way the hardware works.  Don't see a work-around,
      so I added code to xscale_add_watchpoint() to check for and disallow this
      combination.
      
      Some more detail... xscale watchpoint hardware does not support a length
      directly.  Instead, a mask value can be specified (not to be confused with the
      optional mask arg to the wp command, which xscale does not support).  Any bits
      set in the mask are ignored when the watchpoint hardware compares the access
      address to the watchpoint address.  So as long as the length is a power of two,
      setting the mask to length-1 effectively specifies the length.  Or so I thought,
      until I realized that if the length exceeds the base address, *all* bits of the
      base address are ignored by the comaparator, and the watchpoint range
      effectively becomes 0 .. length.
      
      Questions, comments, criticisms gratefully received.
      
      Thanks,
      Mike
      Signed-off-by: default avatarMike Dunn <mikedunn@newsguy.com>
      ebfb2f4f