Re: [Openocd-development] xsvf player does not work

2008-11-17 Thread Øyvind Harboe 
> I agree totally with this, I think this would be a *GREAT* idea.

So what would this mean technically?

What about the people. Is the culture compatible?




-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] parport.cfg question

2008-11-17 Thread Duane Ellis 
Uwe Hermann wrote:

 > [parallel port address: 0xc8b8]

That seems just wrong. The only time I've seen that type of address was 
a Long Time ago in some auto-configure port thing that went bad

I know these addresses

378 - make sense. - LPT1
278 - make sense. - LPT2

I've heard of this one.
3BC - is sometimes used

I think 3BC - was the Hercules monochrome video card.

This page seems to agree.

http://www.beyondlogic.org/spp/parallel.htm

I suspect it was a bad typo?
Or some weird configuration.

-Duane.

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

Re: [Openocd-development] xsvf player does not work

2008-11-17 Thread Duane Ellis 
Steve Franks wrote:
> The folks over at urjtag (http://www.urjtag.org/) are doing this for 
> svf (but not xsvf).  Might be a good learning tool.  Seems to program 
> all my xilinx stuff...
>
> Might be opportunities to merge or share code as well.  If you add 
> urjtag and openocd together, I think you have 98% of the working 
> open-source jtag tools in one spot.
I agree totally with this, I think this would be a *GREAT* idea.

The big difference between the two packages is this:

UrJTAG is mostly - boundary scan based flash programing, no real debug 
support.
UrJTAG - supports non-cpu gdb stuff (xilinx, etc)

OpenOCD - is CPU based flash programing.
OpenOCD - is lacking in non-CPU stuff.

I do know that ADI Blackfin uses UrJTAG + a GDB server package - they 
maintain this on a private fork.
Their "gdbproxy" is a wrapper uses UrJTAG...

http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2Fgdbproxy%2F

and

http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2Fjtag%2F

===

BTW - UrJTAG has something they call "Jim" - it is not the JimTCL.

http://urjtag.svn.sourceforge.net/viewvc/urjtag/trunk/jtag/src/jim/README.jim?revision=953&view=markup

-Duane.

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

Re: [Openocd-development] xsvf player does not work

2008-11-17 Thread Alan Carvalho de Assis 
Hi Steve

On Mon, Nov 17, 2008 at 9:26 PM, Steve Franks <[EMAIL PROTECTED]> wrote:
> http://www.urjtag.org/book/_licensing.html
>
> It's GPL with some BSD.  Project is hosted on sourceforge.
>

Great!

I think UrJTAG has a nice BSDL file parser, maybe it can be useful to OpenOCD.

These two projects needs to work more close (merging?) to sum forces.

> Steve
>

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

Re: [Openocd-development] xsvf player does not work

2008-11-17 Thread Steve Franks 
http://www.urjtag.org/book/_licensing.html

It's GPL with some BSD.  Project is hosted on sourceforge.

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

Re: [Openocd-development] xsvf player does not work

2008-11-17 Thread Øyvind Harboe 
What's the license?


I see no point in trying to solve solved problems if the code is GPL compatible.

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] xsvf player does not work

2008-11-17 Thread Steve Franks 
The folks over at urjtag (http://www.urjtag.org/) are doing this for svf
(but not xsvf).  Might be a good learning tool.  Seems to program all my
xilinx stuff...

Might be opportunities to merge or share code as well.  If you add urjtag
and openocd together, I think you have 98% of the working open-source jtag
tools in one spot.

Best,
Steve


On Sat, Nov 15, 2008 at 7:46 AM, Peter Hettkamp
<[EMAIL PROTECTED]>wrote:

> On Sat, Nov 15, 2008 at 11:00:13AM +0100, Peter Hettkamp wrote:
> > My previous patch does issue jtag_add_tlr() whenever
> xsvf_add_statemove(TAP_TLR)
> > is called. Now, due to the side effects of jtag_add_tlr() this might not
> be
> > an entirely good idea :-(. Because at the end of many xsvf operations,
> there
> > is a call to xsvf_add_statemove(xsvf_to_tap[xendir]) or [xenddr], and it
> > seems that xendir and xenddr are "Test-Logic-Reset" by default.
> >
> They are, by default. But the xsvf documentation says the default should be
> RTI. The attached patchlet will fix this.
>
> But after that, the xsvf player still does not program the xc9576 on my
> target board:
>
> > xsvf 0 xc.xsvf
> value captured during scan didn't pass the requested check: captured:
> 0x03fffe check_value: 0x01 check_mask: 0x03
> in_handler reported a failed check
> TDO mismatch, aborting
>
> I suppose that the xsvf instructions that lead to the failed check are
> : XREPEAT(7) 32
> 0002: XSTATE(18) Test-Logic-Reset
> 0004: XSTATE(18) Run-Test/Idle
> 0006: XRUNTEST(4) 0
> 000b: XSIR(2) 8 0xfe#IDCODE
> 000e: XSDRSIZE(8) 32
> 0013: XTDOMASK(1) 0x0fff
> 0018: XSDRTDO(9) 0x, 0xf9604093
> 0021: XSIR(2) 8 0xff#BYPASS
> 0024: XSIR(2) 8 0xe8#ISPEN
> 0027: XSDRSIZE(8) 6
> 002c: XTDOMASK(1) 0x00
> 002e: XSDRTDO(9) 05, 00
> 0031: XSIR(2) 8 0xed#FBULK
> 0034: XRUNTEST(4) 20
> 0039: XSDRSIZE(8) 18
> 003e: XTDOMASK(1) 0x00
> 0042: XSDRTDO(9) 0x03, 0x00
> 0049: XTDOMASK(1) 0x03
> 004d: XSDRTDO(9) 0x03fffd, 0x01
> 
>
> Could the error be due to the player disregarding the XREPEAT instruction?
>
> Regards,
>
> Peter
>
>
> --
> "Only wimps use tape backup: _real_ men just upload their important stuff
> on ftp, and let the rest of the world mirror it ;)"
> (Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi)
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [COMMIT]mips32 hardware breakpoint support

2008-11-17 Thread Spen 
Hi,

I have committed the attached patch.
It adds hardware breakpoint support to the mips target.

TODO: software breakpoints and watchpoints.

Cheers
Spen


mips.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Fix ep93xx compile on armel / arm

2008-11-17 Thread Uwe Hermann 
On Fri, Nov 07, 2008 at 01:59:36AM +0100, Uwe Hermann wrote:
> Hi,
> 
> I've updated the OpenOCD Debian package to r1130 yesterday, and the
> Debian autobuild daemons found a compile problem with ep93xx on the
> 'armel' architecture, see
> 
> http://buildd.debian.org/fetch.cgi?pkg=openocd;ver=0.0%2Br1130-1;arch=armel;stamp=1225973025
> 
> The problem is how nanosleep() is being called. I'm actually surprised
> that it ever worked and doesn't break on other architectures.
> 
> My Linux nanosleep(2) manpage says this:
> 
>#include 
>int nanosleep(const struct timespec *req, struct timespec *rem);
> 
> The /usr/include/time.h file says:
> 
>extern int nanosleep (__const struct timespec *__requested_time,
>  struct timespec *__remaining);
> 
> However, in src/jtag/ep93xx.c nanosleep() is always called as
> 
>struct timespec ep93xx_;
>nanosleep(ep93xx_);
> 
> which doesn't really work, as (a) the first argument should be a
> pointer (not a struct), and (b) there are two arguments, not only one.
> 
> The fix is probably:
> 
>nanosleep(&ep93xx_, NULL);
> 
> 
> See attached patch for a fix. I've tested it on an ARM box and confirmed
> that it really fixes the compile.

*ping*

Can somebody please review/commit this patch? Thanks!


> HTH, Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

> Index: src/jtag/ep93xx.c
> ===
> --- src/jtag/ep93xx.c (Revision 1142)
> +++ src/jtag/ep93xx.c (Arbeitskopie)
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static u8 output_value = 0x0;
>  static int dev_mem_fd;
> @@ -103,7 +104,7 @@
>   output_value &= TDI_BIT;
>  
>   *gpio_data_register = output_value;
> - nanosleep(ep93xx_);
> + nanosleep(&ep93xx_, NULL);
>  }
>  
>  /* (1) assert or (0) deassert reset lines */
> @@ -120,7 +121,7 @@
>   output_value &= SRST_BIT;
>   
>   *gpio_data_register = output_value;
> - nanosleep(ep93xx_);
> + nanosleep(&ep93xx_, NULL);
>  }
>  
>  int ep93xx_speed(int speed)
> @@ -218,7 +219,7 @@
>*/
>   output_value = TMS_BIT | TRST_BIT | SRST_BIT | VCC_BIT;
>   *gpio_data_register = output_value;
> - nanosleep(ep93xx_);
> + nanosleep(&ep93xx_, NULL);
>  
>   /*
>* Configure the direction register.  1 = output, 0 = input.
> @@ -226,7 +227,7 @@
>   *gpio_data_direction_register =
>   TDI_BIT | TCK_BIT | TMS_BIT | TRST_BIT | SRST_BIT | VCC_BIT;
>  
> - nanosleep(ep93xx_);
> + nanosleep(&ep93xx_, NULL);
>   return ERROR_OK;
>  }
>  

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


-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] parport.cfg question

2008-11-17 Thread Uwe Hermann 
On Fri, Nov 07, 2008 at 02:17:39AM +0100, Uwe Hermann wrote:
> Hi,
> 
> why does src/target/interface/parport.cfg use the
> 
>   parport_port 0xc8b8
> 
> config? Shouldn't that be either "0" or "0x3f8" rather?
> I've never seen that one used anywhere, and it definately doesn't
> work on my (standard PC) parallel port ("0" does work).

Comments anyone? Here's a patch to change the parallel port I/O port
to 0x378 to make it work with most PC parallel ports. Please let me
know if the 0xc8b8 is useful/correct on some platform I may not know...


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Index: src/target/interface/parport.cfg
===
--- src/target/interface/parport.cfg	(Revision 1172)
+++ src/target/interface/parport.cfg	(Arbeitskopie)
@@ -2,7 +2,9 @@
 gdb_port 2001
 
 interface parport
-parport_port 0xc8b8
+parport_port 0x378
+# Use the line below if you loaded the Linux 'ppdev' module, for instance.
+# parport_port 0
 parport_cable wiggler
 jtag_speed 0
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development