litex
litex copied to clipboard
Increase JTAG UART upload speed
This patch increases the JTAG UART upload speed by switching to nonblocking read mode in the OpenOCD Tcl script, then reading and writing up to 512 byte blocks instead of 1 byte at a time.
On my setup, this increases the LiteX terminal upload speed from 74 bytes per second (assuming I patch out the BIOS's command timeout so uploads are even possible) to about 18.3KB/s. As a quick measure of download speed, the FPS of the donut demo has increased by ~50% as well.
It's not clear to me why blocking mode was used before. I would suggest testing other setups to make sure there aren't any regressions in other scenarios.
My setup:
- Ubuntu 18.04
- OpenOCD 0.11.0
- Altera USB Blaster (not the II)
- Cyclone V
- 75MHz VexRiscv SoC
I tested also with an LPC-Link2 running in CMSIS-DAP JTAG mode set to 6MHz. This patch boosts the upload speed of that adapter from 487 bytes per second to 107.1KB/s. Every other part of the setup is identical.
Thanks @tpwrules, I did a test on a Digilent Arty: It seems to work, but this affect the behavior of the BIOS console (we also receive blocks of data on the console). I'll have a a closer look at this.
Still interested in getting this in. What setups are there where it works nicely? The JTAG UART is still completely and utterly unusable for me without this patch.
Can you clarify what you mean about the BIOS console behavior? That works fine for me with this patch too.
Hi @tpwrules,
sorry for the delay, I'll try to spend more this on this. For now it was not possible to merge since was breaking my regular use cases.
I see, I did not realize the change actually broke something. If you can clarify what breaks and debug that would be extremely helpful.
@tpwrules: I just did a test on a Digilent Arty:
python3 python3 -m litex_boards.targets.digilent_arty --uart-name=jtag_uart --build --load
litex_term jtag
and the changes are making the terminal difficult to use, for example having to type enter multiple time to have the litex prompt update.
I was using an old version of OpenOCD and tested with a recent one, but the behavior is the same.
I could also do a test on an Altera device. Do you see a difference in behavior on your setup?
What OS and JTAG adatper are you using? IIRC with my setup the terminal works fine both with and without the patch, but the thing this patch is intended to fix is the broken download function. Can you use the download function (e.g. the --kernel flag) with your Arty?
I'm using Linux (Ubuntu 20.04) and JTAG HS2. I haven't tested the firmware upload yet since was first trying to understand the behavior. What we could eventually while trying to find the root cause would be to keep the current mode by default and enable yours optionally.
Sorry, what I was asking is if the firmware upload works for you before this patch on the Arty. Also curious if it works using an Altera JTAG adapter and/or target.
Hi, have you managed to get more information to answer the above?
Hi,
sorry, I hadn't time to look at it yet. I'm hiring a developer and together we should have more bandwidth to answer open-source related questions in the future with less delay. I'll still try to look at it when I have a moment.
Hi, I have tested your patch with a de0nano and observe a better xfer rate. But with an arty I'm unable to load a firmware. I suspect data loss. Tx size seems to high (and greater than ring buffer capacity). For a slow protocol than usbBlaster I or CMSIS-DAP CPU may be able to handle this size (frame are splited to fix protocol requirement) but MPSSE (FTDI) is directly able to handle 512B.
I have tried to reduce this size to 16 and now it's working with a highest xfer rate.
I have also reduces rx to 128
@tpwrules: We are going to merge and do the modification suggested by @trabucayre to have it working for the different use-cases. Thanks!