1. 25 Nov, 2009 1 commit
    • Zachary T Welch's avatar
      remove target_type register_command callback · 66ee3034
      Zachary T Welch authored
      Uses chaining of command_registration structures to eliminate all
      target_type register_callback routines.  Exports the command_handler
      registration arrays for those target types that are used by others.
      66ee3034
  2. 18 Nov, 2009 1 commit
    • David Brownell's avatar
      ARM: only use one set of dummy FPA registers · d6c89456
      David Brownell authored
      
      
      All ARM cores need to provide obsolete FPA registers in their
      GDB register dumps.  (Even though cores with floating point
      support now generally use some version of VFP...)
      
      Clean up that support a bit by sharing the same dummy registers,
      and removing the duplicate copies.  Eventually we shouldn't need
      to export those dummies.
      
      (This makes the ARMv7-M support include the armv4_5 header, and
      cleans up related #includes, but doesn't yet use anything from
      there except those dummies.)
      
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      d6c89456
  3. 16 Nov, 2009 1 commit
    • Zachary T Welch's avatar
      armv7m: make core reg read/write use unsigned · 10cce4a5
      Zachary T Welch authored
      Eliminate redundant check that gets covered by using unsigned type.
      Created to eliminate noise from subsequent patches, but this kind of
      conversion will be beneficial in similar ways throughout the tree.
      10cce4a5
  4. 13 Nov, 2009 10 commits
  5. 09 Nov, 2009 1 commit
  6. 06 Nov, 2009 2 commits
    • David Brownell's avatar
      Cortex-M3: use the new inheritance/nesting scheme · da739aa2
      David Brownell authored
      
      
      Use new target_to_cm3() and target_to_armv7m() inlines,
      instead of a series of x->arch_info conversions.  Remove
      arch_info, since nothing uses it.
      
      Also fix an omission:  the Cortex-M3 commands didn't verify
      that they were operating on that kind of target.  Add comment
      about the ARMv7M version of that omission.
      
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      da739aa2
    • David Brownell's avatar
      target: provide container_of() · db116b1e
      David Brownell authored
      
      
      Provide a cleaner way to handle single inheritance of targets
      in C, using the same model Linux does:  structs containing other
      structs, un-nested via calls to a "container_of()" macro that
      are packaged in typesafe inline functions.
      
      Targets already use this containment idiom, but make it much
      more complicated because they un-nest using embedded "void *"
      pointers ... in chains of up to five per target, which is all
      pure needless complication.  (Example: arm92x core, arm9tdmi,
      arm7_9, armv4_5 ... on top of the base "target" class.)
      
      Applying this scheme consistently simplifies things, and gets
      rid of many error-prone untyped pointers.  It won't change any
      part of the type model though -- it just simplifies things.
      (And facilitates more cleanup later on.)
      
      Rule of thumb:  where there's an X->arch_info void* pointer,
      access to that pointer can and should be removed.  It may be
      convenient to set up pointers to some of the embedded structs;
      and shrink their current "*_common" names (annoyingly long).
      
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      db116b1e
  7. 05 Nov, 2009 2 commits
  8. 21 Jul, 2009 2 commits
    • ntfreak's avatar
      David Brownell <david-b@pacbell.net>: · 4da019ed
      ntfreak authored
      Clean up treatment of registers in ARMv7-M and Cortex-M3. 
      
       - At the arch level:
          * Just list registers and names; don't impose core-specific
            policy about how they are accessed.
          * Each register has a symbol.
          * Remove the register mode field (irrelevant to debugger)
      
       - At the core/implementation level:
          * Just map the registers to their relevant access methods;
            don't require the arch level to say how that should work
            (cores other than Cortex-M3 could do it differently).
          * Don't use undefined bits from register 20.
          * Use register IDs that are part of the ARMv7-M interface.
      
      In short, there's now a real distinction between the arch
      and core layers.
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2554 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      4da019ed
    • ntfreak's avatar
      David Brownell <david-b@pacbell.net>: · cd0ca916
      ntfreak authored
      Revert parts of the previous ARMv7-M register patch.
      It turns out that part of the issue is a documentation
      problem for the Cortex-M3 r1 parts. So for the rest,
      simpler fixes are possible (in followup patch).
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2552 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      cd0ca916
  9. 16 Jul, 2009 1 commit
    • zwelch's avatar
      Magnus Lundin <lundin@mlu.mine.nu>, Oyvind Harboe <oyvind.harboe@zylin.com>,... · 16e17ab1
      zwelch authored
      Magnus Lundin <lundin@mlu.mine.nu>, Oyvind Harboe <oyvind.harboe@zylin.com>, David Brownell <david-b@pacbell.net>:
      
      Some cleanup of the ARMv7-M support:
      
       - Reference the relevant ARMv7-M ARM doc (DDI 0405C to non-Vendors), and
         update the Cortex-M3 doc refs (DDI 0337C is no longer available).
      
       - Those registers aren't actually general, and some are incorrect (per all
         public docs anyway).  Update comments and code accordingly.
      
           * What the Core Debug facility exposes is *implementation-specific*
             not architectural.  These values aren't fully portable.  They match
             Cortex-M3 ... so no current implementation will make trouble, but
             the next v7m implementation might.
      
           * Four of the registers are actually not exposed that way.  Before
             Cortex-M3 r2p0 they are read/written through MRS/MSR instructions.
             In that newest silicon, they are four bytes in one register, not
             four separate registers.
      
       - Update the CM3 code to report when that one register is available,
         and not try to access it when it isn't.  Also declare the register
         numbers that an eventual MRS/MSR solution will need to be using.
      
       - Stop line wrapping the exception labels.
      
      So for parts before r2p0 OpenOCD behavior is effectively unchanged, and
      still buggy; but for those newer parts a few things might now be correct.
      
      Most current Cortex-M3 parts use r1p1 (or earlier); this seems to include
      most LM3S parts and all STM32 parts.  Parts using r2p0 are available, and
      include fourth generation LM3S parts ("Tempest") plus AT91SAM3 and LPC17xx
      parts which are now sampling.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2543 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      16e17ab1
  10. 23 Jun, 2009 4 commits
  11. 18 Jun, 2009 1 commit
  12. 11 May, 2009 1 commit
  13. 29 Apr, 2009 1 commit
  14. 27 Apr, 2009 1 commit
  15. 20 Sep, 2008 1 commit
  16. 16 Jun, 2008 1 commit
  17. 27 May, 2008 1 commit
  18. 26 Apr, 2008 1 commit
  19. 10 Apr, 2008 1 commit
    • ntfreak's avatar
      - single core context used, removed debug context as thought unnecessary. · 9c3dec37
      ntfreak authored
      - DCRDR now used to access special core registers - info is currently omitted from the cortex_m3 TRM ARM have told me this is the preferred access method and the docs will be updated soon.
      - now checks for User Thread Mode and Thread mode when halted.
      - removed repeated function declarations from command.c
      - cortex_m3_prepare_reset_halt removed, updated cortex_m3_assert_reset to suit
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@558 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      9c3dec37
  20. 11 Mar, 2008 1 commit
  21. 02 Mar, 2008 1 commit
  22. 29 Feb, 2008 1 commit
  23. 25 Feb, 2008 1 commit
  24. 22 Oct, 2007 1 commit
  25. 10 Sep, 2007 1 commit