[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[openrisc] Re: JTAG Proxy
On Tuesday 24 September 2002 10:07, Luis Santos wrote:
> Hi Marko,
>
>
>
> I'm studying the OR1K and its current implementation: or1200. I'm
> especially interested on the debugging support it offers. After reading the
> source code of the JTAG Proxy you wrote to GDB I've two questions:
>
>
>
> 1- For now or1200 doesn't have debugging support as described in OR1K. When
> this support exists how GDB, through the JTAG port (and JTAG proxy),
> becomes notified that the code reaches a given breakpoint and the processor
> becomes stalled, waiting for debugger activity? This doesn't seem feasible
> using the protocol currently implemented! As far as I can imagine, to
> achieve this we need to:
> a) Route the StallStat signal to the parallel port and continuously
> watching it
this is exactly what we are doing. Igor's debug interface has special bit in
MODER, if I am not mistaken, where you can stall/unstall RISC. E.g. you can
also reset RISC there.
> b) Change a little the protocol between GDB and the JTAG Proxy to inform
> the debugger when the OR is stalled.
>
> Comment this problem/solution scenario please.
>
>
>
> 2- Is the StallStat (from the RISC Debug Interface) signal already present
> at the parallel port in the Xess binaries that OpenCores is providing?
>
> - If not ... is it very hard to do? I'm not a Verilog programmer...
see above.
It is true however that not all debugging capabilities are currently
available, but basic capabilities are sufficient for almost everyone.
The only piece missing right now is matchpoint part of or1k architecture.
> 2- Why do you always read the registers twice (jtag_read_reg())?
The reson is debug I/F. First time you send request, then you read data.
If data is not available for next time either, one bit is intentionally
inverted to fail CRC; host should retry then.
It could not be done otherwise, due to scan chains. See debug I/F doc for more
info.
> 3- When you contact the scan chains through the parallel port you read the
> vector from TDO only after completely write the full input vector on TDI.
> As far as I know the output bits from TDO becomes available at the same
> time we shit data in through TDI. Does the response become buffered in the
> operating system, so you don't lose it? How this really happens? Could you
> also use the same strategy to shift-in/shift-out 1000 bits?
For details you should look at jp1.c source (search the cvs, don't know the
exact location, maybe or1k/jtag), but basically you just set what you want to
write to TDI, generate clock and read from TDI.
You are so suspicious -- you should know that these things actually work ;)
> Thanks for your time and care,
>
>
>
> Luís Santos
>
>
>
>
> Luís Eduardo Faria dos Santos-------------------------- lsantos@isec.pt
> Telf. (ext.): +351 239.790353----------------------- (Gabinete 22): 3036
> ___________________________________________
> Departamento de Engenharia Informática e de Sistemas
> Instituto Superior de Engenharia de Coimbra
> Quinta da Nora - Apartado 10057
> 3031-601 Coimbra
> Portugal
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml