Hello
I'm trying to run minsoc project on XUPV5-LX110T board (basically, it's ml-505 board with xc5vlx110t fpga). I have managed to synthesize the project and upload it to the fpga. Problem arises when i try to connect using adv_jtag_bridge. I run adv_jtag_bridge using the following command:

adv_jtag_bridge -b /root/ -t xpc_usb

I use DLC9G cable, I always reconnect USB plug after programming bitfile. adv_jtag_bridge resides on 32bit ubuntu under virtualbox (USB is passed to virtualbox).

adv_jtag_bridge returns an error after some time. Every run, it manages to go more or less far away. The most common error is:

Failed to send a write control message

The whole process lasts quite long, it takes around 5 minutes to get these errors. I have prepared a file with error outputs, ordered by how far the program went (separated by lines of '='). Please see the attachment.

Could somebody tell me what is the problem? Is it because i'm using dlc9 cable (according to doc's, support for that cable is experimental)? Maybe i'm missing some verilog files in the xilinx project? Or maybe it's the virtualbox?

This is an error I have not seen before. Support for the DLC9 is experimental in the sense that I don't have documentation for the cable, and the driver is very slow. However, usually if it will enumerate the JTAG chain, it will communicate reliably with the FPGA for the rest of the session, give or take the slow speed. Failures are usually deterministic, they always happen at the same place.

At this point I suspect virtualbox, because it's an unknown in the system - at least it's an unknown to me. If you can try a native Linux version, you might get better results. If that's not it, then we may be into the realm of really strange possibilities, like clocking/power/loose wire problems, things that just aren't all that likely. That or you have a new variant of the DLC9 that's fussier about how it's driven.

Try it without virtualbox if you can, and I'll let you know if anything else comes to mind...

Hello
I have changed the USB_TIMEOUT parameter to 10000 in cable_xpc_dlc9.c
That way, I have managed to reach the famous or1200v3 issue described in the minsoc faq.

It takes 20 minutes to get to this point. Is it normal for that cable? I'm new to openrisc so I can't tell.

Ah. Yes, drivers not waiting long enough is a common problem with the DLC9, though I don't remember having to adjust that particular number before. It's been about three years since I had a DLC9 to try, but from what I remember, 20 minutes for the self-test isn't unreasonable (though it may be slower than some, since you had to adjust a wait time that isn't normally a problem).

The DLC9 driver really only makes using a DLC9 *possible*, it doesn't make it convenient. If you have heavy debugging to do, I suggest you get one of the higher-speed cables...