On Wed, Oct 19, 2011 at 4:49 PM, Peter Stuge wrote:
> Michael Ashton wrote:
> > On Wed, Oct 19, 2011 at 8:56 AM, Laurent Gauch wrote:
> > > certainly olime waits on Segger JLINK SWD implementation in
> > > openocd to let say their arm jtag ew has swd
> > &
On Wed, Oct 19, 2011 at 4:53 PM, Tomek CEDRO wrote:
> On Thu, Oct 20, 2011 at 1:52 AM, Tomek CEDRO
> wrote:
> > On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge wrote:
> >> It might be really easy to make the device speak SWD.
>
> JLink specification is open, from what Ive seen it should be
> relat
On Wed, Oct 19, 2011 at 8:56 AM, Laurent Gauch wrote:
> **
>
> certainly olime waits on Segger JLINK SWD implementation in openocd to let
> say their arm jtag ew has swd
> certainly olime waits on Amontec JTAGkey-3 SWD implementation in openocd to
> let say their 2232 has swd ...
>
> Ha .. I see
You're right -- my mistake. The web page says: "ARM-JTAG-EW emulates on low
level the IAR Systems' J-LINK API so it works like normal J-LINK debugger,
..." I took this to mean that they were emulating the USB protocol.
But a footnote in the manual says --
"DLL compatible means that we supply our
at 2:47 AM, Michael Ashton wrote:
> > Hi,
> > I'm wondering if anyone can say whether it's possible, or might ever be
> > possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD?
> > I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure
Hi,
I'm wondering if anyone can say whether it's possible, or might ever be
possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD?
I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure whether
that really means anything
can be called from the board
config file?
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
fallback inpout32 is loaded.
What do you think about this?
I would prefer this - otherwise, it would be impossible to distribute a
binary with full functionality.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlio
nt and the C-Mode in emacs can do automatic re-formatting
according to a configurable style.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
initialization code, so
there needs to be some way to disable the RTOS support.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
?
If there is such a command, that is OK with me.
I got the impression it had yet to be implemented.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
image containing startup code, RTOS and
applicationn, it will be.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
JTAG
clock is not completely unthinkable (think about a device running on a
32.768kHz clock).
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hi,
there are two "TMPA" targets: TMPA900 and TMPA910.
In the TMPA900 target, however, TMPA900 is mispelled as TMPA910.
Probably this was a copy & paste error.
The attached patch fixes this. It was tested with a TopasA900
development board which uses the TMPA900.
CU
M
ote: don't put vias *in* SMD pads - they will wick away the solder when
doing automated production.
> Still, no solution/idea on how to make pads metalization at home
> safely... there is a clear field for a patent, hey inventors wake up!
> :-)
I have not found a solution that wor
hich was about a year when I used the stuff, while the
pre-coated material can be stored a lot longer.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
.
Especially if this is used in 10 places, this looks like there *is* a
need for a function that returns swapped 32-bit values, only the
function uses the wrong data types.
cu
Michael
___
Openocd-development mailing list
Openocd-development@l
Am 07/07/2011 07:27 PM, schrieb Drasko DRASKOVIC:
> Hi all,
> I am happy to present you several exciting enhancements to the MIPS32 target.
This is great!
I do not (yet) use MIPS, but from the descriptions of what you did, this
should bring OpenOCD a good step forward.
cu
M
ease don't troll.
Looking at the patch, the LED handling seems to be integrated with the
lowlevel code just fine - there is no bypassing of lower layers to
access the LED, rather, the LED bit is handled at the same place as the
other JTAG
xes the root cause of the problem.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
e spots problems, I would say we give it a try and
merge it.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
being simulated.
Hi,
I can see use cases for this, however, without a sample implementation
for the "other end", it is difficult to use and even test.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlio
is), this should be a useful addition to OpenOCD.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
the macros
should be submitted - this is not a task for a maintainer, but for the
patch submitter.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
D, production of such ELF is not possible with GNU ld, because it
> will keep p_paddr_valid flag at FALSE and equalize p_paddr to p_vaddr
> at some point...
Address 0 is a valid starting address - I know systems with RAM or FLASH
at 0, so code with p_paddr==0 for one section is a valid case.
ld categorically
exclude such extensions on the simple basis that "this should not be done".
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
should not give to higher layer the possibility
> to have an direct access to the dongle port.
I can agree that the driver should filter the access and only allow
access to those pins that are deemed safe for the specific dongle.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
ike 2-4 releases
/ year should be sufficient, IMHO.
Apart from that, I like the proposal.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
so many people interested...
> >
>
> I am all for a 0.50 release.
>
mee to.
I think the long time (with lots of minro improvements) since the last
release warrants a 0.5 version, even if ist does not have a "big" new
feature. Version numbers are cheap - SWD can be 0.
gs pop up during the next 2 weeks or so. I don't think this
really requires fancy "release management" - if noone steps up as
release manager, any release is better than none at all for >1 year.
cu
Michael
___
Openocd-developmen
.
Since it was argued that this is the only "correct" way to exit OpenOCD,
I need to object.
I try to first design stuff in a way that is correct, and only back off
and implement shortcuts when there is some benefit of doing so.
cu
Michael
_
ould have to exit
OpenOCD to achieve that - if I quit OpenOCD, I lose all command history.
Some kind of detach/attach command would be a better solution IMHO.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
imply drive them to that state (or keep them
driven and not turn them off).
>> The goal of OpenOCD is to interfere with target to obtain expected
>> results, after the job is done no interaction is necessary, or we
>> simply not quit the program to enforce some specific behavior..
Am 06/10/2011 09:51 PM, schrieb Tomek CEDRO:
> On Fri, Jun 10, 2011 at 7:17 PM, Michael Schwingen
> wrote:
>> If we agree that we do not want to touch the target, that means the
>> lowlevel interface driver must not change any signal state upon exit,
>> because it does
openocd inter-session more robust.
> I have mentioned this trouble from a long time (4-5months ago). The
> sebastien patch 1..5/5 resolve all of this.
In what way?
If OpenOCD had trouble on startup if the dongle state is unknown, then
that needs to be fixed - you never know which ot
Am 06/10/2011 04:35 PM, schrieb Laurent Gauch:
>>
>> If I quit OpenOCD, I expect the target to stay in the same state as
>> before.
>> If it was in reset, I expect it to stay in reset and not start some code
>> uncontrolled.
>>
>
> Yes you're
you please take this off openocd-devel?
The whole thread has long lost all relevance regarding OpenOCD development.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
of the external circuit).
Any code that assumes the dongle is already in a specific state on init
is broken and needs to be fixed. Working around that by enforcing a
certain state on deinit is plain broken.
cu
Michael
___
Openocd-development ma
to a custom
> debug procedure.
Why *do* we have to do that?
If I quit OpenOCD, I expect the target to stay in the same state as before.
If it was in reset, I expect it to stay in reset and not start some code
uncontrolled.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
it function but
> this is trivial to add :-
Then let's do it right in the first place - that means doing a
layout-specific deinit. There is nothing strange with positive logic -
let's not limit the types of dongles we can support.
cu
Michael
__
Am 06/07/2011 11:23 AM, schrieb Laurent Gauch:
> Hi Michael,
>> Am 06/06/2011 02:10 PM, schrieb Laurent Gauch:
>> >/ Yes, this is to decouple the open and init (open the handle, init
>> />/ the associated specific layout).
>> /
>> Is there case where ope
;
> open
> init
> deinit
> close
>
> and not as the actual
> init
> quit
open/close instead of init/quit is OK with me, but what is the advantage
of the 4-function API instead of the old 2-function API?
cu
Michael
___
Openocd-d
d,
> will be to see our patches merged in the minute, instead to wait 1 to
> 2 months ... also the ft2232.c will still be usable for the JTAGkey.
That is, if such a patch were accepted by the maintainers.
I would expect a NAK on a patch that introduces lots of duplica
xCFF8
> -
> +# The JTAGkey2P uses exactly the same config as the JTAGkey.
> +source [find interface/jtagkey.cfg]
Hi,
this patch seems to remove the two different ft2232_device_desc strings.
Are these unused?
If not, I don't understand how this is supposed to work
tool!
>
That's fine. Every bit helps - if you supply a patch that improves one
ore more of the supplied sample scripts, or even the documentation, that
will help improve OpenOCD without digging into the code.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
d
which target you are using, so I can only guess.
If you use your own config file, you have to expect some breakage both
on development versions and new major releases. Backward compatibility
is a nice goal, but it can hamper progress and produce layers of cruft
in the code, so t
and boundary scan
> - set _JRC_TAPID 0x0b89102f
> + set _JRC_TAPID "-expected-id 0x0b89102f -expected-id 0x0b89102f"
Is there a typo? These two IDs look identical.
cu
Michael
___
Openocd-development mailing list
Openocd-
djust scripts to
special needs.
I agree that the default scripts should have everything ready for the
casual user.
Regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On 02.05.2011 22:44, Jie Zhang wrote:
> On Mon, May 2, 2011 at 3:52 PM, Michael Trensch
> wrote:
>> I often use openOCD and GDB/Insight to attach to a running target that I
>> don't want to halt, or even cannot halt it during my debugging session.
>> I just want to t
read request is
received while the target is running
might be a better idea, but I don't know if the GDB protocol allows this.
Regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
do whatever you want, like resetting the CPU,
blink LED's in this script.
Regards,
Michael
On 02.05.2011 21:14, Jie Zhang wrote:
> When GDB connects to OpenOCD, OpenOCD does not halt the target by
> default. To halt the target, users have to add "halt" to gdb-attach
> eve
the user to specify a value
might be the way to go.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
h, so having support for flash patch units would be
quite handy.
Otherwise, HW breakpoints are the only alternative that really works.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/lis
an
trace the individual accesses and see what goes wrong.
And if nothing goes wrong, you have a (slow) recovery method, and you
know that your memory / working area setup is wrong.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
D/Spansion parts, since these parts
never had any protection mechanism when they started.
In Contrast, many Intel flashes come up protected out of reset and
*need* the unprotect operation.
Are you sure your flash *does* have protection and *needs* unprotect?
Otherwise, you can simple remove the &quo
On 04/15/2011 06:53 AM, Øyvind Harboe wrote:
Any objections to merging?
No.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On 04/15/2011 06:53 AM, Øyvind Harboe wrote:
Any objections?
No.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
this looks like it would break
all existing config files that rely on the default behaviour.
Is there really a *need* to change the default?
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
his looks wrong to me.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
the host.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
an law, I don't know about other countries.
The Samba project would be one precedent where this has been done
successfully.
However, if the ULINK is basically an EZ-USB chip which downloads its
code via USB, using the ULINK protocol would also mean we would have to
use Keil's firm
roducing additional code.
>
> Now I've got another question: where would be the best place to install
> the ULINK's firmware image when 'make install' is executed?
Look at the IXP42x target: the debug handler binary file is installed on
"make install" and i
0-dev
commandline:
-d3 -f "C:\Program Files (x86)\openocd-x64-0.5.0-dev\interface\olimex-arm-usb-ocd.cfg" -f
"C:\Program Files (x86)\openocd-x64-0.5.0-dev\target\stm32.cfg" -f stm32_program.cfg
Regards
Michael
___
Openocd-development mailing
hink
that would be a good approach, because it has zero chance of breaking
non-affected devices.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Mathias K. wrote:
Hello,
Am 25.02.2011 14:38, schrieb Michael Schwingen:
Mathias K. wrote:
I think you can't simple abstract this with 8/16/24/32bit access, because in my
case the data bus
has always a 24bit width and the address bus increment is always one (one
address and 3
Mathias K. wrote:
Hello,
Am 24.02.2011 22:27, schrieb Michael Schwingen:
Am 02/24/2011 09:36 AM, schrieb Mathias K.:
this patch add the risc (default) and harvard architecture to the target
structure. Currently
this patch only affect the memory read/write functions.
I am not
terms.
IIRC, "Harvard" only means separate address busses / spaces for data and
instruction, but does not tell anything about the behaviour on unaligned
or non-machineword accesses.
I would prefer some wording that clearly defines the relevant behaviour.
cu
Michael
__
>> Everything I've tried works well... Individual sector erase,
>> multiple sector erase up to the full device, image writes, image
>> writes with auto-erase, gdb debugging through Eclipse.
>What version of OpenOCD do you use ?
I was working with Øyvind Harboe's WIP git here:
http://repo.or.cz/w
> FYI, I'm working on stm32f2xxx flash support. I've got
> basic erase + programming up and running, including
> block programming so performance will should be tolerable.
>
> Does anyone have hardware to test on out there?
Hi,
I have done some testing on a custom STM32F217ZGT (Rev Z) board usin
e now globally visible).
This might be OK if there really is a noticeable speed gain.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
hat it is faster.
(that does not mean I object against the original patch: speeding up the
implementation by optimizing the code is fine, as long as it does not
hamper maintainability).
cu
Michael
___
Openocd-development mailing list
Openocd-devel
ome snapshort release as a starting point -
use the GIT repository.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
ms to be on all of the newer boards.
Thanks and regards
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
configurable, but provide commands/flags that override the
configured default so that everything works by using the manual versions
when nothing special is configured?
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https
positions, so
taping the single pins together does not work well).
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
specific part -
> setup_lpc2103. This proc takes only two changeable parameters (for
> "regular" user) in this "equation": core clock and adapter clock. This
> way when someone wishes to use lpc2103.cfg inside a board cfg file,
> he/she does not have to copy/pa
Am 01/07/2011 05:44 PM, schrieb Øyvind Harboe:
> On Fri, Jan 7, 2011 at 5:38 PM, Michael Schwingen
> wrote:
>> Am 01/07/2011 05:18 PM, schrieb Øyvind Harboe:
>>> The construct below has a comment to explain
>>> what the following statement means => duplicati
Tcl, but offhand I don't know the syntax
> or construct.
Like this?
proc flash_boot { {FILE "/tftpboot/actux3/u-boot.bin"} } {
echo "writing bootloader: $FILE"
flash write_image erase $FILE 0x5000 bin
}
(from actux3.cfg - works fine).
cu
Michael
___
n be done later and should not stop this from getting
merged, IMHO.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
ript. Or maybe I can force my board
scripts to contain a proc "init_board" which is called from targets like
a callback (if it exists).
Or do you mean I should move the "init_targets" to my board script then?
This would make it easier for sure, as every option is availa
Signed-off-by: Michael Schwingen
---
src/flash/nor/cfi.c | 187 +++
src/flash/nor/non_cfi.c | 10 ++-
2 files changed, 98 insertions(+), 99 deletions(-)
diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c
index 74362c4..5a35aae 100644
--- a
Signed-off-by: Michael Schwingen
---
src/flash/nor/cfi.c | 44 ++--
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c
index f25f46d..10a8f62 100644
--- a/src/flash/nor/cfi.c
+++ b/src/flash/nor
have protection
flags in hardware), so I changed the behaviour from "error" to "warning".
That makes it possible to use "flash write_image erase unlock" in board
scripts, regardless of the flash type on the board.
cu
Michael
_
Signed-off-by: Michael Schwingen
---
tcl/board/actux3.cfg | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/tcl/board/actux3.cfg b/tcl/board/actux3.cfg
index 922d4fc..5435ff8 100644
--- a/tcl/board/actux3.cfg
+++ b/tcl/board/actux3.cfg
@@ -45,3
Signed-off-by: Michael Schwingen
---
src/flash/nor/cfi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c
index 5a35aae..f25f46d 100644
--- a/src/flash/nor/cfi.c
+++ b/src/flash/nor/cfi.c
@@ -1163,8 +1163,8 @@ static int
I will leave the scripts as they are (for now) as these new changes are
combatible with "old" style scripts, until I am clear what is the best
solution. I am in no hurry with that anyway.
Cheers and a happy new year (as this will be my last mail in this year ;) )
Michael
___
behaviour from "error" to "warning".
That makes it possible to use "flash write_image erase unlock" in board
scripts, regardless of the flash type on the board.
cu
Michael
--
Some people have no respect of age unless it is bottled.
_
This can be easily be done with openOCD's telnet interface by dumping
the code area "mdw " and verify it with your binary image
/ .lst file . Alternatively you can create a binary image with "objcopy"
and let openOCD verify the binary image.
Hope that helps a little.
Regard
and assembler code.
If you want line-accurate debugging, it may be necessary to turn off
compiler opzimization (-O0) completely.
BTW: "bx lr" looks like the code is returning from main() - which it
should never do in an embedded environment.
cu
Michael
___
Am 12/18/2010 09:09 PM, schrieb Øyvind Harboe:
> Hi Michael,
>
> you'll have to rebase your patch on top of the master branch and
> update the comments to use ;# at the end of lines as the master
> branch now follows tcl rules for comments.
No problem - I also fixed the worki
quot;s, I get errors whenever
the variable is accessed. I would have expected to be in global context,
but as I said, my TCL knowledge is not much.
Thanks for your comments!
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
in case we have multiple devices in one scan chain?
does the last included "setup_target" replace the previous one, or do we
need unique names?
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://list
, and re-enter main from the beginning - what happens
exactly is usually undefined.
You need to make sure main never exits.
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
first
> git pacthes...
I only did a short look, but this looks fine to me.
I think it is time to re-factor that target-algorithm code and pull the
target dependencies out of the CFI code, but that would be a separate step.
cu
Michael
___
Openoc
three more for rev. A0
silicon, which I do not have and which is probably quite rare except on some
eval boards.
Since my TCL knowledge is basically zero, I am looking for suggestions how
to improve this - for example, are those repeated "global" statements really
necessary?
cu
Michae
On 16.12.2010 16:58, Peter Stuge wrote:
> Michael Trensch wrote:
>> Probably it was an error to keep two branches and merge them by hand.
>>
>> I've made the changes in a temporary test environment and tried to merge
>> the stuff.
>> 1. cloned openocd's G
target/hilscher_netx500.cfg
5. git commit
Probably i shouldn't have added the file again after modification, or
don't copy it?
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
cfg
(similarity 52%)" and added "hilscher_netx500.cfg". Probably renaming
and modifying does not work here (msysgit problem), or I still need to
learn how to use git correctly
So I either need to redo my local patch series to make sure the rename
gets correctly to repo, or
ning how to correctly develop using git
and how to create/post patches. ;)
Regards,
Michael
>From 58d613ea138f1dbcb70c8f438557769e49516e81 Mon Sep 17 00:00:00 2001
From: Michael Trensch
Date: Thu, 16 Dec 2010 15:33:16 +0100
Subject: [PATCH] Add support for Hilscher netX controllers
-
1 - 100 of 578 matches
Mail list logo
