Re: [Openocd-development] xscale_debug.S: Error: junk at end of line when using cygwin/mingw

2009-10-16 Thread Grant Edwards
On 2009-10-16, Redirect Slash NIL redirect.slash@gmail.com wrote:

 Any ideas how to fix that?

My guess is you've you've got DOS line endings instead of Unix
line endings.

-- 
Grant

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Moving to git

2009-10-06 Thread Grant Edwards
On 2009-10-06, Ra?l S?nchez Siles rsanch...@infoglobal.es wrote:

 !!! And if anyone objects to GIT, please speak up ASAP !!!

 I think mercurial [0] could be a good option. It's a well
 known distributed VCS, maybe not as spread or known as git,
 but it's fulfilling most if not all general users aspirations.
 I find it generally speaking easier to use than git and the
 move from those used to SVN should be less painful.

This exact same discuss is taking place in a different
open-source project in which I participate, and several people
there have also said that they thought mercurial would be an
easier transition than git.

I would give a few points to mercurial for being written in
Python.  I would expect it to be a lot more stable than
something written in C.  However, my opinion shouldn't be
weighted very heavily since I'm just a user when it comes to
openocd.

-- 
Grant Edwards   grante Yow! Are we on STRIKE yet?
  at   
   visi.com

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Switch to non-Berlios mailing list

2009-10-06 Thread Grant Edwards
On 2009-10-05, ??yvind Harboe oyvind.har...@zylin.com wrote:

 Migrate away from Berlios committe wants an alternative to
 Berlios mailing lists.

 Some alternatives so far:

[...]

Anything so long as it works with gmane.org.

-- 
Grant Edwards   grante Yow! Not SENSUOUS ... only
  at   FROLICSOME ... and in
   visi.comneed of DENTAL WORK ... in
   PAIN!!!

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] Has anybody gotten Atmel AT19SAM9G20 to work?

2009-08-11 Thread Grant Edwards
Has anybody gotten OpenOCD to work with an Atmel AT91SAM9G20?

I found a thread from about 6 months ago that indicated it was
partially working with an Amontek JTAG interface, but there
were problems and the thread contained no indication that the
problems had ever been resolved.

I'm trying to use an Olimex tiny with the 'G20 and I'm having
little luck.  The Olimex interface worked fine with an Atmel
ATRM9200, so I know the hardware is OK and openocd/libftdi both
work.

If I attempt to connect to a the board (an Atmel AT92SAM9G20-EK
Rev B eval board), OpenOCD _occasionally_ finds the CPU, but it
usually complains like this:

   Open On-Chip Debugger 0.1.0 (2009-06-29-11:11) Release
   $URL: 
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
 $
   jtag_speed: 5
   use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
   Error: couldn't read the requested number of bytes from FT2232 device (19  
81)
   Error: couldn't read from FT2232
   Error: number of discovered devices in JTAG chain (0) doesn't match 
(enabled) configuration (1), total taps: 1
   Error: check the config file and ensure proper JTAG communication 
(connections, speed, ...)
   Error: trying to validate configured JTAG chain anyway...
   Warn : no tcl port specified, using default port 

or like this:

   Open On-Chip Debugger 0.1.0 (2009-06-29-11:11) Release
   $URL: 
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
 $
   jtag_speed: 5
   use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
   Info : JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (Manufacturer: 
0x01f, Part: 0x7926, Version: 0x0)
   Info : JTAG Tap/device matched
   Warn : no tcl port specified, using default port 
   Warn : DBGACK set while target was in unknown state. Reset or initialize 
target.
   
If I cycle power on the board immediately before starting
openocd it will connect sometimes (maybe 20% of the time):

   Open On-Chip Debugger 0.1.0 (2009-06-29-11:11) Release
   $URL: 
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
 $
   jtag_speed: 5
   use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
   Info : JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (Manufacturer: 
0x01f, Part: 0x7926, Version: 0x0)
   Info : JTAG Tap/device matched
   Warn : no tcl port specified, using default port 

But then when I telnet in, it won't do anything useful.
Attempting to read memory fails with a device not halted
message, but the 'halt' command just hangs forever.

I'm now a bit stumped, and would appreciate the loan of a
clue...

The config I'm using was gleaned from various mailing list
postings:

   # REFERENCE:  http://www.olimex.com/dev/arm-usb-tiny.html
   interface ft2232
   ft2232_device_desc Olimex OpenOCD JTAG TINY
   ft2232_layout olimex-jtag
   ft2232_vid_pid 0x15ba 0x0004
   
   #daemon configuration
   telnet_port 
   gdb_port 
   
   set CHIPNAME at91sam9g20
   set ENDIAN little
   set CPUTAPID 0x0792603f
   # chip
   source [find target/at91sam9260.cfg]
   
   jtag_speed 5
   
   $_TARGETNAME configure -event reset-init {
   # at reset chip runs at 32khz
   jtag_khz 8
   mww 0xfd08 0xa5000501 # RSTC_MR : enable user reset
   mww 0xfd44 0x8000 # WDT_MR : disable watchdog
   mww 0xfc20 0x4001 # CKGR_MOR : enable the main 
oscillator
   sleep 20  # wait 20 ms
   mww 0xfc30 0x0001 # PMC_MCKR : switch to main 
oscillator
   sleep 10  # wait 10 ms
   mww 0xfc28 0x2060bf09 # CKGR_PLLAR: Set PLLA Register 
for 198,656MHz
   sleep 20  # wait 20 ms
   mww 0xfc30 0x0101 # PMC_MCKR : Select prescaler
   sleep 10  # wait 10 ms
   mww 0xfc30 0x0102 # PMC_MCKR : Clock from PLLA is 
selected
   sleep 10  # wait 10 ms
   # Now run at anything fast... ie: 10mhz!
   jtag_khz 1# Increase JTAG Speed to 6 MHz
   arm7_9 dcc_downloads enable   # Enable faster DCC downloads
   }
   #this chip has more sram
   # Internal sram2 memory
   $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x0020 
-work-area-size 0x1000 -work-area-backup 1
   
   #gdb
   gdb_memory_map enable
   arm7_9 dbgrq enable
   
Here's a debug log for the case that comes closest to working
(where the CPU is identified correctly).  I then telnet in and
issue an mdb command and then a halt command.  At that
point, openocd hangs and I kill it with Ctrl-C:

# openocd -d3
Open On-Chip Debugger 0.1.0 (2009-06-29-11:11) Release
$URL: 
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
 $
User : 5 1 

Re: [Openocd-development] Has anybody gotten Atmel AT19SAM9G20 to work?

2009-08-11 Thread Grant Edwards
On 2009-08-11, Gary Carlson gcarl...@carlson-minot.com wrote:

 I am using the same board you are using (except with a J-link
 debugger instead of the Olimex) without too many problems.

 You may want to consider moving up to the latest OpenOCD
 software since my recollection is that a number of problems
 were fixed between version 1.0 and 2.0 using that interface.

Doh!  I completely overlooked the fact that 0.2.0 was out.  I
had tried Gentoo's openocd- ebuild (which builds from the
svn trunk), and I couldn't get it to build for some reason:
emerge wouldn't even recognize the availabilty of the 
version.

So anyway, it turns out that the 0.1.0 ebuild works fine with
0.2.0 sources, and the resulting openocd recognizes the board
and is able halt the CPU and examine memory and CPU registers.
It still doesn't connect on every attempt, but other than that
it's bascially working now.

-- 
Grant Edwards   grante Yow! If elected, Zippy
  at   pledges to each and every
   visi.comAmerican a 55-year-old
   houseboy ...

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development