Yawn, Nathan

Advanced Debug System

Rate limiting was removed as of bug 535, (Oct 01, 2009) as the OS blocks I/O calls until inb or outb completion.

However I have found that this causes my Xilinx PC3 clone to fail despite it working ok in Xilinx Impact 12.1 (where it is limited to a 200 kHz TCK).

With a simple test program I have recorded a maximum parallel port output rate of 667 kHz.

Xilinx document XTP029 (www.xilinx.com/support/documentation/user_guides/xtp029.pdf) explains that TCK rate is entirely defined by the host system's parallel port speed.  Hence the fault is with the JTAG programmer.

However, some option to limit the parallel port data rate would be useful to those of us using cheap programmers.

The overhead of usleep(1) seems to slow the clock to tens of kHz so I have worked around this by simply tripling each occurrence of outb/inb calls, bringing TCK to a manageable 222kHz (ugly, I know).

Thanks,


Andrew
0xADF

cable_parallel usleep/limiting

I needed to debug using a computer connected to a network having a server account management, thus I couldn't get superuser access. 

I solved that by changing the direct memory access to the port for operating system calls on a file descriptor. 

Your user account has to have read and write permissions to the "/dev/parport0". In my case "/dev/parport0" gives read and write permissions to the group lp and the user was registered to this group. 

In linux it has been tested and is working. Also compatibility issues with impact have been solved. 

How To? 
Includes:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/ppdev.h>
#include <linux/ioctl.h>
#include <linux/parport.h>

create a global variable called fd to carry the file descriptor pointing to the device. 

int fd;

Initialize the device:
  int mode = IEEE1284_MODE_COMPAT;
  fd = open("/dev/parport0", O_RDWR | O_NONBLOCK);
  if (fd == -1)
  {
    perror("Not able to acquire the device desriptor\n");
    return APP_ERR_INIT_FAILED;
  }
  if (ioctl(fd, PPCLAIM) == -1)
  {
    perror("Fail to claim the interface for itself.\n");
    return APP_ERR_INIT_FAILED;
  }
  if (ioctl(fd, PPSETMODE, &mode) == -1)
  {
    perror("Setting compatibility mode failed.\n");
    return APP_ERR_INIT_FAILED;
  }

Read from the device:
  ioctl(fd, PPRSTATUS, inval);
Write to the device:
  ioctl(fd, PPWDATA, &value);

inval and value as shown here work with cable_parallel.c. Actually both should be pointers to "unsigned char".

regular user parallel port access using adv_jtag_bridge

I'd like to inform that:

-xpc4 in compatibility mode to xpc3
-DLC9 (Xilinx USB Cable II)

worked for Spartan3A using the Xilinx JTAG TAP.

Project Status

Always get 0xFFFFFFF of IDCODE with EP3C25

We recently had an issue about the usleep call taking a lot longer than 1 us for one user. Probably related to the hardware if the usleep implementation is hardware dependent. 

Anyways I'd like to point out that we commented out the usleep function, actually removing every implementation of this function, and it did not influence our results. No problems at all. Only 16x speed-up, 5KB / sec right now. 

Actually the function is called between IO memory calls to ensure IO completion. This is not required, since the system blocks IO calls until completion.

Regards,
Raul

cable_parallel_phys_wait function and usleep

In xilinx_internal_jtag.v:

In the SPARTAN2 part there are two assignments to capture_dr_o:

line 154: 
assign capture_dr_o = 1'b0;
line 159 to 165:
always @ (negedge tck_o)
begin
    if(debug_select_o && !shift_dr_o)
        capture_dr_o <= 1'b1;
    else
        capture_dr_o <= 1'b0;
end

Since capture_dr_o is used by the dbg_if I just removed the assignment to 0 from line 154. I couldn't test it though.

xilinx_internal_jtag Spartan2

Hi Nathan! 

I have  detected some problems while working with adv_jtag bridge, legacy debug interfaces and GDB 6.8 and 5.3. I have been trying to detect what is going wrong and I think that it is about pthread mutex locking. I've tested with xilinx usb, xpc3 and ft2232 with no changes.

GDB returns the following:

    jose@menlopark:~/unison/proyectos/S3E/tools/or32_toolchain/mof-orsoc/or32-elf/bin$ sudo ./or32-elf-gdb
    Building automata... done, num uncovered: 0/216.
    Parsing operands data... done.
    GNU gdb 6.8
    Copyright (C) 2008 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=i686-pc-linux-gnu --target=or32-elf".
    (gdb) target remote :9999
    Remote debugging using :9999
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing... 
    ...
 
No matters how long you wait, it keeps returning packet errors
    ...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...



Tracing the behaviour of adv_jtag_bridge it shows the following:

    jose@menlopark:~/unison/proyectos/S3E/tools/or32_toolchain/jtag/legacy/adv_debug_sys/trunk/Software/adv_jtag_bridge$ sudo ./adv_jtag_bridge -g 9999 -x0 -l 0:4 -c 0x08 -t xpc3
    [sudo] password for jose:
    Connected to parallel port at 378
    Dropping root privileges.
    Enumerating JTAG chain...

    Devices on JTAG chain:
    Index    Name        ID Code        IR Length
    ----------------------------------------------------------------
    0:     (unknown)     0x149511C3     -1

    Target device 0, JTAG ID = 0x149511c3
    Prefix bits: 0
    Using command-line debug command 0x8
    *** Doing self-test ***
    Stall or1k - CPU(s) stalled.
    SRAM test:
    expected 11112222, read 11112222
    expected 33334444, read 33334444
    expected 55556666, read 55556666
    expected 77778888, read 77778888
    expected 9999aaaa, read 9999aaaa
    expected bbbbcccc, read bbbbcccc
    expected ddddeeee, read ddddeeee
    expected ffff0000, read ffff0000
    expected dedababa, read dedababa
    SRAM test passed
    Testing CPU0 (or1k) - writing instructions
    Setting up CPU0
    Starting CPU0!
    Read      npc = 00000010 ppc = 00000028 r1 = 00000005
    Expected  npc = 00000010 ppc = 00000028 r1 = 00000005
    Read      npc = 00000010 ppc = 00000028 r1 = 00000008
    Expected  npc = 00000010 ppc = 00000028 r1 = 00000008
    Read      npc = 00000028 ppc = 00000024 r1 = 0000000b
    Expected  npc = 00000028 ppc = 00000024 r1 = 0000000b
    Read      npc = 00000024 ppc = 00000020 r1 = 00000018
    Expected  npc = 00000024 ppc = 00000020 r1 = 00000018
    Read      npc = 00000020 ppc = 0000001c r1 = 00000031
    Expected  npc = 00000020 ppc = 0000001c r1 = 00000031
    Read      npc = 00000024 ppc = 00000020 r1 = 00000032
    Expected  npc = 00000024 ppc = 00000020 r1 = 00000032
    Read      npc = 00000014 ppc = 00000010 r1 = 00000063
    Expected  npc = 00000014 ppc = 00000010 r1 = 00000063
    Read      npc = 00000028 ppc = 00000024 r1 = 00000065
    Expected  npc = 00000028 ppc = 00000024 r1 = 00000065
    Read      npc = 00000010 ppc = 00000028 r1 = 000000c9
    Expected  npc = 00000010 ppc = 00000028 r1 = 000000c9
    result = deaddead
    *** Self-test PASSED ***
    JTAG bridge ready!
    Handling RSP
    Packet received qSupported: 10 chars
    Putting PacketSize=119
    Packet received ?: 1 chars
    Putting S00
    Packet received Hc-1: 4 chars
    Putting OK
    Packet received qC: 2 chars
    Putting
    Packet received Hg0: 3 chars
    Putting OK
    Packet received g: 1 chars


It hangs after receiving "g" and don't send any answer. I think it is a deadlock issue
When tracing locks and unlocks along the execution we can see:

1: rsp_read_all_regs () calls dbg_cpu0_read_block()
2: dbg_cpu0_read_block() locks dbg_access_mutex
3: dbg_cpu0_read_block() calls dbg_cpu0_read()
4: dbg_cpu0_read() tries to lock and hangs because dbg_cpu0_read_block() has already locked and is waiting for dbg_cpu0_read() to finish before it unlocks and dbg_cpu0_read() is waiting for dbg_cpu0_read_block() to unlock before it can continue.

Hope this info helps to solve the bug. It is strange that there aren't more people experiencing it...

Regards
José Ignacio Villar

gdb packet errors and deadlock with legacy debug interfaces

There are plenty of usb debug cables based on FT2232 chips from FTDI, including the new OpenRisc USB debug cable developed by OrSoc. I think it would be quite interesting if this wonderful debug interface could support this kind of cable.

I've been using urJtag to drive my FT2232 based home made cable and current support is fair good. Maybe urJtag is good starting point.

Browse

Advanced Debug System