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. Oct 20, 2009
  3. Oct 15, 2009
  5. Oct 14, 2009
  7. Oct 13, 2009
  9. Oct 10, 2009
  11. Sep 23, 2009
  13. Sep 22, 2009
  15. Sep 21, 2009
  17. Sep 20, 2009
  19. 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
  21. Sep 16, 2009
  23. Sep 14, 2009
  25. Sep 11, 2009
  27. Sep 10, 2009
  29. 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
  31. 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
  33. Sep 01, 2009
  35. Aug 30, 2009
  37. Aug 26, 2009
    • oharboe's avatar
      David Brownell <david-b@pacbell.net> Clock updates/fixes for the Stellaris flash driver: · a5354ff5
      oharboe authored 
       - Bugfixes:
   * internal osc: it's *12* MHz (not 15 MHz) on _current_ chips
      + except new Tempest parts where it's 16 MHz (and calibrated!)
      + or some old Sandstorm ones, where 15 MHz was valid
   * crystal config:
      + read and use the crystal config, don't assume 6 MHz
      + know when that field is 4 bits vs 5
   * an RCC2 register may be overriding the original RCC
      + more clock source options
      + bigger dividers
      + fractional dividers on Tempest (NYET handled)
   * there's a 30 KHz osc on newer chips (for deep sleep)
   * there's a 32768 Hz osc on newer chips (for hibernation)

 - Cosmetic
   * say "rev A0" not "vA.0", to match vendor docs
   * don't always report master clock as an "estimate":
      + give the error bound if it's approximate, like "±30%"
      + else don't say anything
   * fix whitespace and caps in some messages
   * these are not AT91SAM chips!!

Those clock issues might explain problems sometimes reported when
writing to Stellaris flash banks; they affect write timings.

That 12-vs-15 MHz issue is problematic; there's no consolidated doc
showing which chips (and revs!) have which internal oscillator speed.
It's clear that only older silicon had the faster-and-less-accurate
flavor.  What's less clear is which chips are "old" like that.

Lightly tested, on a DustDevil part.

git-svn-id: svn://svn.berlios.de/openocd/trunk@2626 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      a5354ff5
  39. Aug 25, 2009
  41. Aug 18, 2009
  43. Aug 13, 2009
  45. Jul 20, 2009
  47. Jul 17, 2009
  49. Jul 08, 2009
  51. Jul 02, 2009
  53. Jul 01, 2009
  55. Jun 30, 2009