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
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,
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
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
> 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
> 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
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
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
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 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
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
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
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
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/
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,
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
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 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 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 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
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 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
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
> 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 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)
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 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.
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 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
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
> > -
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
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*
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
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
>
>
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
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
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
> >
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
>
40 matches
Mail list logo
