There have been numerous cases described in this forum where people had to re-flash their LimeSDR (USB/mini) using JTAG. The “documented” method is to use some proprietary/non-free tools available only for proprietary/non-free operating systems, which excludes the freedom-loving portion of the user base from performing such programming/flashing.
The Altera/Intel MAX10 series is supported by OpenOCD since early 2017. There are other projects out there which are documenting how to program MAX10 using OpenOCD, see for example https://numato.com/kb/programming-telesto-using-openocd/
It appears that this requires SVF files to be generated, while Lime appears to only publish RBF files at this point. I would therefore kindly request to
Condsider to provide SVF files as part of the standard build procedure of the gateware (important)
Maybe even spend a bit of time to document the programming procedure using FOSS tools such as OpenOCD (less important)
If the SVF files were provided, the community could test it and try to put together some documentation.
If @Zack or somebody else at Lime could generate a SVF file of the most recent gateware (or, actually, any known-working gateware) for me to test, I’d be happy to test it with a LimeSDR-mini as soon as possible and report back.
Thanks a lot, @Zack! I’m on business travel this week (without JTAG / cables / LimeSDR-mini) but will try over the weekend or early next week for sure.
If it turns out they can be used I would suggest we place them on the downloads server instead of GitHub, alongside the other programming files, so then they are all in one place. E.g.:
Reading through the SVF file comments, it seems that all the “programming” steps (UFM1, UFM0, CFM2, CFM1, CFM0) are completed but then the verification phase starts, and UFM1 cannot be verified. I don’t know enough about the MAX10 to know what those different acronyms mean.
Referring to the “Intel MAX 10 UFM Design Considerations” it states that the flash must be erased before programming. In the SVF file comments, it lists only “Program” and “Verify” but I don’t see any mention of erase at the beginning. Maybe that’s a hint, not sure.
These are User Flash Memory and Configuration Flash Memory. All MAX10 Flash space is divided to these sections.
This is SVF file generation window in Quartus:
As you can see there is no option to erase the device. Do not think that “Blank-check” option would help. But probably TCK frequency of 25MHz is an issue. Here is SVF file for Mini board with 100kHz TCK frequency.
I’ve been using OpenOCD to program the LimeSDR-Mini for some time. I forked the gateware repository and added an OpenOCD folder under the bitstreams with a bash script to automatically program the gateware. I tested it with my adapters (FT2232H and FT232H) and worked without problems. I added a experimental support to @LaF0rge’s Olimex adapter with information based on this thread.
I’m a big fan of open source software. But as FPGA designer/user I can’t see the benefit of programming my LimeSDR using SVF. I will still have to use proprietary software, i.e. Quartus, to run P&R and to generate the SVF. If I want to do something useful like running signaltap I still need Quartus. If I was Lime Micro I could see some benefit if I could use SVF files and free software during the production and testing of the cards. But I can’t see the point other than it’s cool. You could save a few dollars on the programming cable, but I can program my LimeSDR using the onboard FX3 anyways. Am I missing something?
BTW I typically just put this in my build script to generate SVF:
I finally got around to test your OpenOCD configs + repository + SVF file, and I could successfully flash two LimeSDR-mini v1.2 and one v1.1 using your repository.
The interesting part is that I now could successfully program even using the SVF file provided by @Zack, which failed reproducibly before, see my earlier posts.
I’ve been using the exact same Laptop and openocd version “Open On-Chip Debugger 0.10.0+dev-00524-g149b9c56 (2018-09-21-00:25)”. The only difference was that I’m now using a jtag-lock-pick tiny 2.0.0 as programmer (also FT232H based).
So while it’s unclear why it wasn’t working I tried last time, we can conclude that indeed using SVF files and OpenOCD it is possible to flash LimeSDR-mini.
@Zack: I think I agree with @andrewback that LimeMicro should start adding SVF files next to their standard build to LimeSuite. Thanks!
