+, Andy Potter wrote:
> Hi Marc,
> Ready, willing and able. I have a couple of 415 and 435 Goteks I can
> try it
> with.
> Regards
> Andy
> On Tue, 19 Nov 2024 at 08:48, Marc Schink d...@zapb.de wrote:
> > Hi Andy,
> > just to let you know, I have a working dri
Hi Ross,
> I’m working on an industrial production test device that needs to be
> able to interact with parts under test via JTAG/SWD to:
> * Write to RAM
> * Write to the flash
> * Start execution at specific addresses
> * Provide single step environment for the device under test (during
> de
Hi Andy,
just to let you know, I have a working driver for the ArteryTek AT32F4x
series. It just needs some code cleanup. I hope I can push it soon on
Gerrit. Would be nice if you can give it a try then.
Best regards,
Marc
On Mon, 2024-11-18 at 22:32 +, Andy Potter wrote:
> I am trying to do
Hi Jan,
there are pros and cons of having multiple libraries. The biggest
disadvantage is or would be if we do a lot of work more than once and
thereby consume valuable resources that could be well invested
elsewhere.
Anyway, nice to see that you also working on some test approaches for
OpenOCD.
2024-08-19 at 22:41 +0200, k...@aspodata.se wrote:
> Daniel:
> > On Mon, Aug 19, 2024 at 08:23:53AM -0400, Brandon Martin wrote:
> > > On 8/17/24 04:47, Marc Schink wrote:
> > > > > I would imagine many embedded developers have a PCI or PCIe
> > > > &g
Hi Brandon,
>
> I would imagine many embedded developers have a PCI or PCIe
> serial+parallel card laying around. You never know when it might be
> useful. I personally have like 3.
>
Can you provide me the names of your parallel port interface cards?
What mode (i.e SPP, ECP, EPP) must be
On Tue, 2024-06-25 at 10:33 +0200, Antonio Borneo wrote:
> On Mon, Jun 24, 2024 at 11:46 PM Marc Schink wrote:
> >
> > On Sun, 2024-06-23 at 10:27 +0200, Antonio Borneo wrote:
> > > ...
> > > - git2cl is only used for OpenOCD releases. We could keep it as a
>
On Sun, 2024-06-23 at 10:27 +0200, Antonio Borneo wrote:
>
> On Sat, Jun 22, 2024 at 9:20 AM Marc Schink wrote:
> > A more general question: what is the reason for integrating jimtcl
> > as a
> > submodule in the first place? According to repology it seems to be
> >
at 23:23 +0200, Daniel Glöckner wrote:
> On Thu, Jun 20, 2024 at 12:40:55AM +0200, Marc Schink wrote:
> > To be host I'm suprised that there are still parallel port users
> > out
> > there. Although the main reason is probably more nostalgia than
> > anything else
A more general question: what is the reason for integrating jimtcl as a
submodule in the first place? According to repology it seems to be
widespread. We deprecated the libjaylink submodule, what is the reason
to keep jimtcl?
Best regards,
Marc
On Fri, 2024-06-21 at 14:31 +0200, Antonio Borneo wr
gt; If the motivation to drop support is just "because it's old" then
> please don't drop support. It's not dead code as long as people are
> using it, and even if there were no users (which not true, there
> are), if it works, why kill it ?
>
> Bruno
>
>
rs/parports/operating-a-parallel-port
>
I'm not going to read Windows docs about how to develop paralllel port
drivers... in my opinion we should drop support for both ;D Okay, maybe
some Windows user will show up.
Best regards,
Marc
On Thu, 2024-06-20 at 04:42 +0200, k...@aspodata.se wrote:
&g
rc
On Wed, 2024-06-19 at 16:13 -0400, Brandon Martin wrote:
> > On 6/19/24 15:07, Marc Schink wrote:
> > > > thanks for your feedback! The patch is only a proposal for now
> > > > and > > not
> > > > a decision. Is there a special reason why you*need*
50
> >
> > -- gerrit
> >
> > commit 753c70601179f91f04dd86375f7bd559331c3e86
> > Author: Marc Schink
> > Date: Wed Jun 12 22:08:48 2024 +0200
> >
> > Drop parallel port adapters
> >
> > Parallel port adapters are deprected
On Sat, 2023-06-24 at 11:37 +0200, Michael Schwingen wrote:
> On 23.06.23 14:12, Antonio Borneo wrote:
> > Hi,
> > I would like to have your feedback on this topic.
> >
> > Today a binary package of OpenOCD should include:
> > - the binary openocd[.exe]
> > - the TCL scripts from tcl folder
> > -
Hi Tim,
I had the same issue. The problem is that the OpenSSH >= 8.3 deprecates
keys with SHA-1 [1]. The solution is to generate a new key pair without
SHA-1, for example, ssh-ed25519.
Best regards,
Marc
[1]
https://www.zdnet.com/article/openssh-to-deprecate-sha-1-logins-due-to-security-risk/
O
Hi all,
I just released the first version of a Python package to easily
interface OpenOCD via Tcl RPC. The code is based on the contrib Python
code (contrib/rpc_examples/ocd_rpc_example.py) but provides more
functions, documentation and follows the style guide for Python code ;)
I hope this makes
Hi all,
please consider the tpiu bug fixes [1,2] (needs review). What about the
patches for the new memory and register read/write Tcl functions
[3,4,5]?
Best regards,
Marc
[1] https://review.openocd.org/c/openocd/+/6329
[2] https://review.openocd.org/c/openocd/+/6328
[3] https://review.openocd.
On Sun, 2021-05-30 at 22:55 +0200, Matthias Welwarsky wrote:
> On Samstag, 29. Mai 2021 12:58:05 CEST Marc Schink wrote:
> > Hi Tim,
> >
> > I'm wondering why the registers for RISC-V targets are invalid
> > (register cache) after halting the core. When I try to
Hi Tim,
I'm wondering why the registers for RISC-V targets are invalid
(register cache) after halting the core. When I try to display the
values for all registers with "reg" I get the following output:
> reg
= RISC-V Registers
(0) zero (/32)
(1) ra (/32)
(2) sp (/32)
(3) gp (/32)
(4) tp (/32)
> Here is first level of transport API wich doesnot support large
> buffers:
> JAYLINK_API int jaylink_jtag_io(struct
> jaylink_device_handle *devh, const uint8_t *tms, const uint8_t *tdi,
> uint8_t *tdo,
>
> uint16_t length,
> Here is first level of transport API wich doesnot support large
> buffers:
> JAYLINK_API int jaylink_jtag_io(struct
> jaylink_device_handle *devh, const uint8_t *tms, const uint8_t *tdi,
> uint8_t *tdo,
>
> uint16_t length,
Hi Alexander,
thanks for your investigation.
> I'm using j-link debugger with arm11 target, and i have image loading
> speed about 125 KiB / s.
I have no experience with that target and barely use JTAG targets. What
is your desired speed? What speeds do you achieve with other tools like
the SEGG
Hi Alexander,
thanks for your investigation.
> I'm using j-link debugger with arm11 target, and i have image loading
> speed about 125 KiB / s.
I have no experience with that target and barely use JTAG targets. What
is your desired speed? What speeds do you achieve with other tools like
the SEGG
Hi Bohdan,
thank you for your report. I'm aware of this issue but I don't consider
this as bug in libjaylink. We ask libjaylink to discover TCP devices
but there are no ethernet devices available.
Maybe I will introduce a special check for "network not available" but
I'm not sure if and when. We
Tim, do you have any plans to push your changes directly to Gerrit? If
not, what's the reason?
Marc
On Mon, 2020-11-30 at 12:24 -0800, Tim Newsome wrote:
> Personally I'm waiting on 0.11 to be finalized (or on a separate
> branch) before pushing more changes from the RISC-V fork upstream, so
> th
Hi Antonio,
the command is not deprecated but the use of "USB addresses" is marked
as deprecated in the SEGGER software. The serial number should be used
instead, if possible. I pushed a patch [1] to fix the confusion.
Best regards,
Marc
[1] http://openocd.zylin.com/#/c/5918/
On Sun, 2020-11-01
Hi Kristof,
I would love to see a new website on openocd.org. The current one looks
quite ugly and old.
However, personally I would prefer to have a blog-like website as the
current one. It's easier to publish new content. To reduce maintenance
(security updates etc.) I would rather use a static
Hi,
I vote for A4, A6 and B4. On A6 I would remove the fading effect and
would rather use a solid color as in the header.
Thanks for your effort!
Best regards,
Marc
On Thu, 2020-10-08 at 19:19 +0200, kristof.mul...@telenet.be wrote:
> Hi,
> I've registered the votes today from:
> - Liviu Ionesc
Hi,
for your information, I just released libjaylink version 0.2.0.
Best regards
Marc
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Hi,
I cannot see any difference between "connect under reset" with and
without a call to jaylink_set_speed(). I'm using a STM32F1 development
board with a J-Link v10.1 (FW: May 27 2019).
Do have a cloned J-Link device? Can you provide me the traces in a
format that can be opened with the sigrok f
c
> AC_CHECK_HEADERS([sys/select.h])
> than automagically makes HAVE_SYS_SELECT_H
> Maybe the same works for you too!
>
> Antonio
>
> On Sun, May 31, 2020 at 8:02 PM Marc Schink wrote:
> >
> > Hi,
> >
> > can somebody check if this patch [1] is necessary
Hi,
can somebody check if this patch [1] is necessary to build libjaylink
on OSX?
I would like to integrate this fix (if necessary) in the upcoming 0.2.0
release which will probably take place within the next couple of days.
Best regards
Marc
[1]
https://github.com/syntacore/libjaylink/commit/
Hey,
there are some patches that should be merged in my opinion:
* http://openocd.zylin.com/#/c/5180/ has +2 since 4 months and is
essential for building OpenOCD on MSYS/MinGW
* http://openocd.zylin.com/#/c/5218/ Tested and won't break anything
* http://openocd.zylin.com/#/c/3903/ Pending f
Submit your patches on http://openocd.zylin.com/ please.
Best regards
Marc
Am 18.07.19 um 19:16 schrieb g...@novadsp.com:
Hello,
Every repo has new tool fun and mainline process fun :-) Please advise, I
could
not find the doku
http://openocd.org/doc/doxygen/html/patchguide.html#gerrit
HTH
I would need some argumentation, why "speed" and not "khz" or "rate" or
"freq".
Well, why not "khz"? It's the worst command name I can think of. It's an
unit and not an adapter action or property. (Un)fortunately, we don't
have a similar command to make fun of but what about "adapter ms"
inst
Hi all,
i started this discussion on the irc #openocd. As PaulFertser suggested,
lets move it to the mailing list.
To make at least some of the commands more consistent, i decided to
rework adapter related part. Initial patch is here:
http://openocd.zylin.com/4774
Awesome, thanks for the (radi
So it's a pretty odd use-case, and maybe not worth maintaining (I
would obviously vote for keeping it... if I have a vote that is). And
maybe there is a smarter / better way to do it. We did investigate
using the RPC interface and decided against it (I don't recall the
specifics). And maybe the
Hi,
are there good reasons why we need (ARM) disassembly integrated in
OpenOCD? As Paul already said, there are awesome external
tools/libraries like Capstone.
If there are no good reasons, I would vote to remove the disassembly
features in near future rather than extending it because it seems
Hi,
there is a branch with TCP/IP support for J-Link devices (e.g. J-Link
Pro, Flasher, EFR32 Wireless Starter Kit):
http://git.zapb.de/libjaylink.git/log/?h=tcpip_support
If you have one of these devices, please test it and give me some feedback.
Device discovery works with UDP broadcasts a
> Just curious, why not use the real serial number (supposed to be
> unique) for enumeration purpose
The first argument is that for the real serial number we have to open
the device, check for device capabilities and then read the real serial
number instead of just reading the serial number of t
> It works fine with both the V3 and V7 J-Link. Thanks.
>
> I also looked into the debug log and the only thing is that
> the V3 serial number is not read correctly.
>
> FYI, IAR tools (SEGGER J-Link Commander V4.43c, which is
> quite old version Compiled Feb 22 2012 20:13:08) works fine
> to read
Hi,
as libjaylink is integrated in OpenOCD I'm sending this announcement to
the OpenOCD-devel mailing list.
I'm currently preparing for release 0.1.0 of libjaylink and I would
invite you to review the code or give any other kind of feedback.
Especially, feedback from OS X users would be helpfu
Hi,
i also think that it is not related to the libjaylink patch. I'll rebase
the patch on the current HEAD and apply some minor changes these days.
Both logs should be the same then.
Best regards,
Marc
Am 24.05.2015 um 15:05 schrieb Xiaofan Chen:
> On Sun, May 24, 2015 at 6:15 PM, Mar
44 matches
Mail list logo
