Need explanation for bin download (JTAG+GDB)

[kobegpfan]

With JTAG and GDB, our bin file can be downloaded into a board. I am
just curious about how these command work? Would you please explain
the meaning of each step I listed below?

1. type "“./jp1-xilinx 9999" or "“./jp1-xess 9999"
Q: What does this command do? From the screen information I guess
this command starts a JTAG proxy server in my host, and the server use
TCP port 9999 to communicate with other applications, e.g. GDB. Is this
guess correct?

2. in screen, "Connected to parallel port at 378"
Q: It seems the JTAG proxy server connected to the parallel port. But
what does "378" means? It is time or port number?

3. In screen info, there are several key words: "read / expected / npc /
ppc / rl"
Q: first what does npc/ppc/rl mean? and what is read & expected. Why
they are different? I remember they should be same then it works
properly.

4. "or32-uclinux-gdb hello.or32"
No question.

5. "target jtag jtag://localhost:9999"
Q: Does it connect 9999 port?

6. "load"
Q: Does it load the bin?

7. "set $pc=0x100" "c"
No question.

8. Are there any way to do the same thing in Windows OS? I have not
installed Linux in my test PC.

Best regards
Kobe
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

Hi Kobe,

I believe you are using the tutorial from the De Nayer Instituut, which
is very out of date (you may notice it uses GDB 5.0, which is nearly 10
years old). I hope this email will explain things. Make sure you read
the BIG WARNINGS at the end of this message.

EXPLANATION
===========

GDB 5.3 for OpenRISC implements a proprietary protocol to talk to
targets via JTAG.

This is then used within GDB by running

  target jtag <target address>

If the target address is a local parallel port, then GDB will drive a
physical OpenRISC processor connected via a JP1 header to the parallel
port of the computer. For this would you type something like:

  target jtag /dev/lp1

(Assuming you are on Linux and your parallel port is on /dev/lp1).

However there is an alternative, where the same protocol can communicate
over TCP/IP to a remote machine. This is a proprietary OpenRISC protocol
running over TCP/IP sockets, which packages up the JTAG commands to set
scan chains and read/write registers. The far end must then run a client
protocol, which decodes these instructions and applies them to the
target. You can run this as

  target jtag jtag://<remote machine>:<port number>

The most useful client is the architectural simulator, Or1ksim. If you
enable its GDB and JTAG debugging feature and set a port number for JTAG
to use (in the sim.cfg file), then you can talk to it via GDB. This is
usually run in a separate window on the same machine, so the remote
machine name can just be "localhost". For example I have set up Or1ksim
to run the JTAG client on port 50000

or32-uclinux-sim -f ~/svntrunk/GNU/gdb-6.8/debug.cfg
Reading script file from
'/home/jeremy/svntrunk/GNU/gdb-6.8/debug.cfg'...
Building automata... done, num uncovered: 0/213.
Parsing operands data... done.
JTAG Proxy server started on port 50000
Resetting PIC.

I can now (in a separate window) run GDB and issue the command:

  target jtag jtag://localhost:50000

and GDB will connect to the Or1ksim. Any GDB commands will now drive the
remote simulator.

For example if I issue the commands:

file /home/jeremy/svntrunk/GNU/gdb-6.8/progs_or32/hello
load /home/jeremy/svntrunk/GNU/gdb-6.8/progs_or32/hello
run

The program "hello" will be loaded on the remote machine and run. On the
terminal running Or1ksim, I will see output:

Hello World!
exit(0)
@reset : cycles 0, insn #0
@exit  : cycles 164034216, insn #164033604
 diff  : cycles 164034216, insn #164033604

And on the GDB terminal I will see:

(gdb) load /home/jeremy/svntrunk/GNU/gdb-6.8/progs_or32/hello
Loading section .text, size 0x1290 lma 0x0
Loading section .rodata, size 0xe lma 0x1290
Start address 0x100, load size 4766
Transfer rate: 38128 bits in <1 sec, 2383 bytes/write.
(gdb) run
Starting program: /home/jeremy/svntrunk/GNU/gdb-6.8/progs_or32/hello

Program received signal SIG43, Real-time event 43.
[Switching to process -1]
0x00001014 in simexit (rc=0) at utils.c:46
46        __asm__ __volatile__ ( "\tl.nop\t%0" : : "K"( NOP_EXIT ));
(gdb)

Note that in addition to the usual GDB commands there is also the "info
spr" command to tell you the value of special purpose registers and the
"spr" command to set the value of special purpose registers.

This technique works with any component that implements the OpenRISC
JTAG remote client protocol. The De Nayer Instituut example was based on
such a client, and I understand ORSoC (the owners of OpenRISC) have a
USB JTAG connector, which also talks this protocol, so could be hooked
to GDB in this way.

BIG WARNING
===========

This how it *should* all work. However the port of GDB 5.3 was done 7
years ago, when the OpenRISC architecture was not finalized.
Consequently the protocol does not actually match real OpenRISC designs.
It's OK with the architectural simulator, since it dates from the same
time, so the version of OpenRISC it models and the JTAG are quite close
and a lot of the things work.

In my experience I can get GDB 5.3 to load programs on the architectural
simulator, and I can inspect them to some extent, but that's about it.

SECOND BIG WARNING
==================

No one has used the local connection to a JP1 header for a long time (if
ever). So if you do try this method to talk to real hardware, you may
need to do some debugging. You are probably better using a USB connector
as I mentioned above.

THIRD BIG WARNING
=================

The only way this might run on Windows is under Cygwin. However I don't
know if anyone has tried building the toolchain under Cygwin, and there
could considerable work to complete this port.

THE GOOD NEWS
=============

I've been working on a port of the latest version of GDB 6.8 for a
couple of weeks. This will fix all the problems, and should work to the
current OpenRISC spec. The example above was using this version. It
still needs some more work - frame backtrace does not work properly and
the breakpoint code is untested. I hope to have a first version with
documentation by the end of this month.

Hope this explains things.

ATB,


Jeremy

-  
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com



-----Original Message-----
From: kobegpfan@...
Reply-To: List about OpenRISC project <openrisc@...>
To: openrisc@...
Subject: [openrisc] Need explanation for bin download (JTAG+GDB)
Date: Thu, 24 Jul 2008 10:39:46 +0200 (CEST)

With JTAG and GDB, our bin file can be downloaded into a board. I am
just curious about how these command work? Would you please explain
the meaning of each step I listed below?

1. type "./jp1-xilinx 9999" or "./jp1-xess 9999"
Q: What does this command do? From the screen information I guess
this command starts a JTAG proxy server in my host, and the server use
TCP port 9999 to communicate with other applications, e.g. GDB. Is this
guess correct?

2. in screen, "Connected to parallel port at 378"
Q: It seems the JTAG proxy server connected to the parallel port. But
what does "378" means? It is time or port number?

3. In screen info, there are several key words: "read / expected / npc /
ppc / rl"
Q: first what does npc/ppc/rl mean? and what is read & expected. Why
they are different? I remember they should be same then it works
properly.

4. "or32-uclinux-gdb hello.or32"
No question.

5. "target jtag jtag://localhost:9999"
Q: Does it connect 9999 port?

6. "load"
Q: Does it load the bin?

7. "set $pc=0x100" "c"
No question.

8. Are there any way to do the same thing in Windows OS? I have not
installed Linux in my test PC.

Best regards
Kobe
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc