Re: problem with running "hello uart" in v2pro

On Sun, 2008-09-21 at 21:52 -0700, wuxian wrote:
Hi Wuxian,

These tutorials are very out of date, particularly the software one.

I don't have physical Virtex-II hardware here, so I can't check that
end. Are you using a Xilinx Parallel Cable 3?

On the software side, I strongly recommend you change to GDB 6.8, as
described on the OpenRISC software site.

At a first glance, I'm not sure that you are using GDB correctly to load
your program on the remote machine. Try instead:

or32-uclinux-gdb
file hello.or32                    <---- You need a local symbol table
target jtag jtag://localhost:9999  <---- Connect to the target
load hello.or32                    <---- This will load on the target
x/i 0x100                          <---- Has it loaded correctly
set $pc=0x100                      <---- Is this necessary?
run

GDB 6.8 should set $pc automatically to the entry point specified in the
binary, which I would hope is 0x100. I have heard of a problem with the
Igor Mohor debug unit, which will not allow the PC to be set via JTAG.

Which Verilog source are you using? ORPSoC? (this has a different debug
unit, not the Igor Mohor one). I would recommend that you recompile the
software example, using the current version of the tool chain, and
verify that it works using Or1ksim first.

If you can get the program to run with Or1ksim, then the problem is
somewhere in the interface between the hardware and the debugger. You
should check that the expected sequence of commands are being sent
across the OpenRISC Remote JTAG protocol.

This is a very simple protocol with commands to read & write single JTAG
registers, or blocks of JTAG registers and to change the JTAG scan chain
being addressed. The debug unit has 3 scan chains of relevance, 1 to
access the SPRs, one to access main memory, and one to control the CPU
by stalling or resetting the processor.

The functions which drive this in GDB (assuming GDB 6.8) are in the file
gdb/or1k-jtag.c. You can either modify these functions to print out
messages as each protocol command is sent, or you can run OpenRISC GDB
under GDB. For example, start up GDB as above, and note its process ID
(say 12345). Then debug it from a separate window using:

gdb or32-uclinux-gdb 12345
break or1k_jtag_init
break or1k_jtag_close
break or1k_jtag_read_spr
break or1k_jtag_write_spr
break or1k_jtag_read_mem
break or1k_jtag_write_mem
break or1k_jtag_stall
break or1k_jtag_unstall
break or1k_jtag_wait
cont

Then issue the commands to OpenRISC GDB in its window as above. The
local GDB will break as it encounters each of the JTAG protocol
functions, and you can examine what is being requested, step through the
code etc, to verify the JTAG commands being transmitted. You may find it
useful to build OpenRISC GDB with debugging info in for this. Follow the
usual instructions, but use

  make all CFLAGS+=-ggdb

instead of "make all"

You'll need to look at the code in gdb/or1k-jtag.c to understand what is
happening for each of these functions. It is well commented, and there
is a description in:

http://www.embecosm.com/download/ean3.html

If this is all working correctly, then the problem must be in the jp1
side. You'll need to debug this, and check that it is receiving the
OpenRISC JTAG protocol commands properly and generating the correct JP1
interface commands.

If this is not the source of the problem, then you have a problem in the
hardware of the debug unit. You'll need to run under simulation to work
out where that problem is.

Hope you can get the system working. You can ensure your everlasting
fame, by writing a new paper on how to use OpenRISC with a Virtex-II
FPGA, which we could post on the website.

HTH,


Jeremy

--
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com


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