Re: [Openocd-development] Patch submission for new interface support

[Rick Altherr]

On Dec 16, 2008, at 2:18 PM, Rob wrote:

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.

unsure we could without

legal implications - is there any?


their website anymore.

Cheers
Spen

It would be good to include the rlink (i have a few lying around) but am permission from Raisonance. It is a closed interface so am unsure of the Segger released the api for the jlink - however it is not available on

Sorry for breaking threading on this reply, I'm not going to be at my
subscribed address for a while.


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

please accept my apologies.

My impression, and IANAL, is that this work comes squarely under the

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:


  which is described as an "embedded R-Link" on the stm32circle.com
  website.

2) Noted patterns in the USB traffic, particularly packets which were

  ability, I read out the R-Link firmware which is basically the USB

  some of the other commands that USB packets can contain.


  is used for handling data transfer between USB and various devices

  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

  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

undocumented :)


  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.

 comes in "Basic" and "Pro" flavours, with the Basic model code-space

 licensing works, we have no interest, and we aren't (knowingly)
 distributing any information that would enable anyone else to bypass
 that licensing.

 or in part, in the OpenOCD code we're offering.


at USB logs. Once again, we don't know nor particularly care about how
RIDE operates.



Cheers,
Rob.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

I'm the "other person" mentioned in Lou's e-mail; I'd like to provide a inclusion in OpenOCD. If this discussion isn't appropriate for this list, description of "reverse engineering for interoperability" and there are 1) Log USB traffic between the RIDE software and the STM32-Primer board, clearly "write-to-memory" and "read-from-memory" commands. Using this library from ST plus a few command handlers. This provided details on 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 (memory cards etc). For some unfathomable reason, ST have decided not sample code for ST7 development boards, we were able to piece together don't think we're using anything that is (or could be) "closed". It's just 5) Wrote an OpenOCD driver using the information gathered in the previous - There is no intention to bypass license control technology. The R- Link limited when debugging with the RIDE software. We have no idea how that - 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 The way RIDE handles debugging seems quite different to OpenOCD, looking 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.

--
Rick Altherr
kc8...@kc8apf.net


 -- Unsigned

IANAL either, but this seems to be clean-room reverse engineering for interoperability. That is generally considered OK in the US. I don't foresee the rlink support being a problem, but if one wanted to ask the manufacturer we would have a clear answer. We do lose plausible deniability (I really hate that term) in that case though. "He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development