Yawn, Nathan

Advanced Debug System

Hi,

first of all, thanks for the Openrisc platform!

I just spent a while debugging a weird problem I had with my minsoc system, which uses an SDRAM (using the OC sdr_ctrl) at 25MHz.
I got sporadic errors like this:
[...]
Doing burst read, word size 1, word count 4, start address 0x54
Doing burst read, word size 1, word count 4, start address 0x58
ERROR!  WB bus error during burst read, address 0x5A (index 0x2), retrying!
[...]

for doing a memory dump (/x in GDB), a 'disas' command gives similar behavior. They always seemed to happen for a byte-wise read access.

It turns out that the the problem is that in my setup, the SDRAM takes too many cycles to complete an 8bit request, more time than it takes to trickle it out through JTAG, and the burst-read in the dbg state machine will not see the flag 'biu_ready' going high in time for the next byte to be sent out. Confusingly, it flags it as a Wishbone error, instead of noting it as a timeout on the bus.

I think it is a good idea if this would be documented somewhere, or if there would be a good way to avoid this.

Note somewhere: Wishbone needs to be faster than JTAG

The support for FT2232 based cables (OpenRISC USB-JTAG Debugger) seems to be broken. An older instance is working fine, but a recently checked out v3.0.0 does not work correct, as it gets wrong IDCODES from the (OC) JTAG TAP. A first quick look into the svn and diff's over the ft2232 code does not show an obvious difference or error.

FT2232 support broken

hi, my computer's arch is x86_64. So, a 'long int' in this machine is 64-bit width, but it is 32-bit width in i368 machine. I think it is the reason why I can't pass SRAM test in vpi mod. I think you should add an option '-m32' into CFLAGS. That's all.

Browse

Advanced Debug System