Skip to content
Snippets Groups Projects
Select Git revision
  • dw-cmsisdap-path
  • max32xxx default protected
2 results
Search by author
  • Any Author
  • 9R 9R
  • Administrator root
  • Andreas Schildbach pink
  • Daniel Hoffend griffon
  • Definitely Not A Robot Doloo1ai
  • Dirk Jäckel Dirk Jäckel biafra
  • G G
  • Hauke Mehrtens hauke
  • Jan Morawek RFguy
  • Julian hdsjulian
  • Lila Fisch lilafisch
  • Martin Ling martinling
  • Mateusz Zalega msgctl
  • Michael Huebler mh
  • Ole Dreessen ole
  • Phileas Phileas pl
  • Philip Brechler Philip Brechler plaetzchen
  • Renze renze
  • Sabine Wolf Bine
  • Sec 42 sec
20 authors
  1. Nov 06, 2009
  3. Oct 20, 2009
  5. Oct 15, 2009
  7. Oct 14, 2009
  9. Oct 13, 2009
  11. Oct 10, 2009
  13. Sep 23, 2009
  15. Sep 22, 2009
  17. Sep 21, 2009
  19. Sep 20, 2009
  21. Sep 17, 2009
    • dbrownell's avatar
      Minor fixes to NAND code and docs · 9536577c
      dbrownell authored 
      Erase logic:
 - command invocation
    + treat "nand erase N" (no offset/length) as "erase whole chip N"
    + catch a few more bogus parameter cases, like length == 0 (sigh)
 - nand_erase() should be static
 - on error
    + say which block failed, and if it was a bad block
    + don't give up after the first error; try to erase the rest
 - on success, say which nand device was erased (name isn't unique)

Device list ("nand list"):
 - say how many blocks there are
 - split summary into two lines
 - give example in the docs

Doc tweaks:
 - Use @option{...} for DaVinci's supported hardware ECC options

For the record, I've observed that _sometimes_ erasing bad blocks causes
failure reports, and that manufacturer bad block markers aren't always
erasable (even when erasing their blocks doesn't trigger an error report).


git-svn-id: svn://svn.berlios.de/openocd/trunk@2724 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      9536577c
  23. Sep 16, 2009
  25. Sep 14, 2009
  27. Sep 11, 2009
  29. Sep 10, 2009
  31. Sep 09, 2009
    • oharboe's avatar
      Rolf Meeser <rolfm_9dq@yahoo.de> · 7b5ddb4a
      oharboe authored 
      This patch adds target algorithm support for those flash devices that do not support DQ5 polling. So far they could only be programmed with host algorithm, but this was way too slow.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2682 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      7b5ddb4a
    • oharboe's avatar
      David Brownell <david-b@pacbell.net> · aa46b153
      oharboe authored 
      Optionally shave time off the armv4_5 run_algorithm() code:  let
them terminate using software breakpoints, avoiding roundtrips
to manage hardware ones.

Enable this by using BKPT to terminate execution instead of "branch
to here" loops.  Then pass zero as the exit address, except when
running on an ARMv4 core.  ARM7TDMI, ARM9TDMI, and derived cores
now set a flag saying they're ARMv4.

Use that mechanism in arm_nandwrite(), for about 3% speedup on a
DaVinci ARM926 core; not huge, but it helps.  Some other algorithms
could use this too (mostly flavors of flash operation).

git-svn-id: svn://svn.berlios.de/openocd/trunk@2680 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      aa46b153
  33. Sep 03, 2009
    • oharboe's avatar
      David Brownell · a89dd2ca
      oharboe authored 
      Abstract the orion_nand_fast_block_write() routine into a separate
routine -- arm_nandwrite() -- so that other ARM cores can reuse it.

Have davinci_nand do so.  This faster than byte-at-a-time ops by a
factor of three (!), even given the slowish interactions to support
hardware ECC (1-bit flavor in that test) each 512 bytes; those could
be read more efficiently by on-chip code.

NOTE that until there's a generic "ARM algorithm" structure, this
can't work on newer ARMv6 (like ARM1136) or ARMv7A (like Cortex-A8)
cores, though the downloaded code itself would work just fine there.

git-svn-id: svn://svn.berlios.de/openocd/trunk@2663 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      a89dd2ca
  35. Sep 01, 2009