> > > > Attached, is a patch against the svn trunk that adds support > > for the Raisonance RLink JTAG adapter. That adapter is > > mostly used with their RIDE software, but there is a version > > of it embedded in the STM32 Primer (a development board), > > where it is wired in in lieu of a JTAG connector. > > > > Some reverse engineering was needed. USB traffic sniffing, > > analyzing publicly downloadable sample projects, and the > > like. Hopefully, that falls into the category of "not a > > problem". Neither I, nor the other person I've been working > > with, have entered into any sort of NDA which relates to > > this. I'm bringing this up now in case there is an issue. > > > > The basic architecture of the R-Link adapter is an ST7 > > microcontroller with a USB device interface and a Data > > Transfer Coprocessor in it. > > This driver communicates with the firmware on that > > microcontroller and uses it to load an image into the DTC and > > runs that to bit-bang each of several speeds. > > > > If it needs tweaking to make it suitable for inclusion, we'll do it. > > It seems to work fine in basic testing on our Linux systems. > > > > It would be good to include the rlink (i have a few lying around) but am > unsure we could without > permission from Raisonance. It is a closed interface so am unsure of the > legal implications - is there any? > > Segger released the api for the jlink - however it is not available on > their website anymore. > > Cheers > Spen
Sorry for breaking threading on this reply, I'm not going to be at my subscribed address for a while. I'm the "other person" mentioned in Lou's e-mail; I'd like to provide a bit of background on this driver, so that people with knowledge about these sorts of issues can maybe decide whether our code is OK for inclusion in OpenOCD. If this discussion isn't appropriate for this list, please accept my apologies. My impression, and IANAL, is that this work comes squarely under the description of "reverse engineering for interoperability" and there are no legal issues. I don't see that we've done anything much different to what the Samba project has, for example. What we've done is: 1) Log USB traffic between the RIDE software and the STM32-Primer board, which is described as an "embedded R-Link" on the stm32circle.com website. 2) Noted patterns in the USB traffic, particularly packets which were clearly "write-to-memory" and "read-from-memory" commands. Using this ability, I read out the R-Link firmware which is basically the USB library from ST plus a few command handlers. This provided details on some of the other commands that USB packets can contain. 3) Combed the data sheet for the ST72651 CPU in the R-Link. This has scant details of a peripheral called "Data Transfer Coprocessor" (DTC), which is used for handling data transfer between USB and various devices (memory cards etc). For some unfathomable reason, ST have decided not to document the DTC, but prefer to provide customers with firmware blobs. 4) By looking at (freely downloadable) resources on ST's site, such as sample code for ST7 development boards, we were able to piece together the DTC instruction set, and through a lot of experimentation we've gained a pretty good understanding of how the DTC actually works. As far as Spencer Oliver's comment about a "closed interface" goes, I don't think we're using anything that is (or could be) "closed". It's just undocumented :) 5) Wrote an OpenOCD driver using the information gathered in the previous steps. The driver is possibly not optimal, due to our incomplete knowledge about the components that we're dealing with. Some things that I think might be important: - No encryption, or any technology designed to control access, was bypassed in this work. There is no such technology in the R-Link. - There is no intention to bypass license control technology. The R-Link comes in "Basic" and "Pro" flavours, with the Basic model code-space limited when debugging with the RIDE software. We have no idea how that licensing works, we have no interest, and we aren't (knowingly) distributing any information that would enable anyone else to bypass that licensing. - The work we've done doesn't distribute any copyrighted work. Especially, the R-Link firmware and Raisonance DTC blobs are not included, in whole or in part, in the OpenOCD code we're offering. The way RIDE handles debugging seems quite different to OpenOCD, looking at USB logs. Once again, we don't know nor particularly care about how RIDE operates. As an aside, I'm planning to publish the information we've gathered about the DTC on my website in a few days, if you're interested get in touch. Cheers, Rob. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
