1. 06 Nov, 2009 1 commit
    • 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>
  2. 05 Nov, 2009 2 commits
  3. 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
    • 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
  4. 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
  5. 23 Jun, 2009 4 commits
  6. 18 Jun, 2009 1 commit
  7. 11 May, 2009 1 commit
  8. 29 Apr, 2009 1 commit
  9. 27 Apr, 2009 1 commit
  10. 20 Sep, 2008 1 commit
  11. 16 Jun, 2008 1 commit
  12. 27 May, 2008 1 commit
  13. 26 Apr, 2008 1 commit
  14. 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
  15. 11 Mar, 2008 1 commit
  16. 02 Mar, 2008 1 commit
  17. 29 Feb, 2008 1 commit
  18. 25 Feb, 2008 1 commit
  19. 22 Oct, 2007 1 commit
  20. 10 Sep, 2007 1 commit
  21. 24 Jun, 2007 1 commit
  22. 14 Jun, 2007 1 commit