Hi Cinly,
Thank your for your observation.
After a quick look at the code in batch.c, it seems that the the additional
DMI NOP operation is really redundant, as you point out.
I haven't analyzed the code in detail, though.
The reason for the (perhaps redundant) NOP operation might have been be
at 4:29 PM Antonio Borneo
wrote:
> On Tue, Apr 27, 2021 at 11:18 AM Jan Matyáš wrote:
> >
> > Hello,
> >
> > I have noticed that when TCL commands are being issued from OpenOCD's
> startup scripts, their output (produced by command_print()) is not actually
>
Hello,
I have noticed that when TCL commands are being issued from OpenOCD's
startup scripts, their output (produced by command_print()) is not actually
visible on the output, apart from the last print. The preceding prints seem
to be dropped - not visible to the user.
This can be demonstrated
entation.
>
> Antonio
>
> On Thu, Feb 11, 2021 at 9:11 AM Jan Matyáš wrote:
> >
> > Hello all,
> >
> > This is a question to those well versed in GNU Autotools.
> >
> > I have noticed that since certain time (Q4/2020 ?), OpenOCD no longer
> bui
Hello all,
This is a question to those well versed in GNU Autotools.
I have noticed that since certain time (Q4/2020 ?), OpenOCD no longer
builds on my CentOS 7 via GNU Make from the package system - version 3.82:
[matyas@pcmatyas riscv-openocd]$ make
Makefile:5675: *** missing separator.
Hello Joe,
I have checked the OpenOCD code and this indeed appears to be an OpenOCD
bug, exactly as you describe. It affects not only this upstream OpenOCD but
the riscv-openocd fork where the RISC-V related development takes place.
I have submitted a fix at:
t;https://new.embeetle.com/downloads/openocd_riscv_patch.rar> )
> be helpful for your fork?
>
> Hopefully you can push your RISC-V support to the OpenOCD master branch.
> That would be awesome ^_^
>
> Kind regards,
> Kristof Mulier
>
> --
Dear Kristof,
I only had a moment to look at the Jenkins build result:
http://build.openocd.org/job/openocd-gerrit-build/TARGET=mingw64/lastFailedBuild/console
Based on the log, it appears that the build failed due to code style issues
(as checked by the checkpatch.pl script).
You may wish to
>
> As I am only familiar with RISC-V, I would recommend giving Spike ISS a
> try.
>
>
Also the instr. set simulator (ISS) need not necessarily run on the same
system as the OpenOCD instance being tested.
Regards,
Jan
___
OpenOCD-devel mailing list
> > On 3 Apr 2020, at 12:37, Tommy Murphy wrote:
> >
> > OpenOCD to debug against simulated targets including RISC-V simulated
> using Verilator and Spike
>
> Yes, this might be a solution, but I first have to make this simulator run
> on all my target platforms (Win 32/64, Linux Intel 32/64,
Hi,
as Tommy pointed out, one way to accomplish it is to use a RTL model of a
target processor. It can be simulated on a workstation (using an enterprise
RTL simulator or free Verilator tool). Then OpenOCD interfaced with this
running simulation - e.g. via jtag_vpi interface.
Another option is
Dear all,
some time ago I have submitted a series of two patches to fix issues in
jtag_vpi driver:
http://openocd.zylin.com/#/c/5152/ - jtag_vpi: ensured constant packet size
& endianness
This change has been reviewed and approved on Oct 21 but not merged since.
Please let me know if there is
Hello,
could you please help me finish the review & approval of:
http://openocd.zylin.com/#/c/5177/ (jtag_vpi: multiple improvements)
All the review findings so far have been addressed.
I would not want these important fixes in jtag_vpi to slip through the
cracks.
Thank you,
Jan
>
> I think BTW that we should switch to a submit strategy other than
> cherry-pick...
>
> /Andreas
>
Would "Rebase Always" be a fitting submit strategy? Any disadvantage in
doing that?
https://gerrit-review.googlesource.com/Documentation/config-project-config.html#submit-type
Thanks,
Jan
itial 0x0 frame
> - http://openocd.zylin.com/2887
> RTOS: Fix ThreadX for Cortex-R4 - Uses same scheme as ARM9 from change
> #2848
>
> => 1 patch can be cherry-pick but does not compile anymore. Owner in CC
> - http://openocd.zylin.com/2445
> jtag/
e
>
> Thanks and best regards,
> Marc
>
>
>
> ___
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
--
*Jan Matyáš* | *Software Engineer* | www.codasip.com | Technická 23, 616 00
Brno,
Hi all,
there has been a thread recently about building OpenOCD for Windows.
In relation to that topic, I am wondering if there would be an interest in
the community to have a CMake-based build system for OpenOCD.
In Codasip, we happily use CMake for native OpenOCD builds on both Windows
17 matches
Mail list logo
