at the moment and little time
to work on openocd. But maybe there's something there that could still be
helpful.
The patches are all tagged with "reset".
BR,
Matthias
On Freitag, 21. Januar 2022 15:48:10 CET Antonio Borneo wrote:
> Hi Oleh,
>
> Thanks for reporting the issue
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 display the
>
> values for all registers with "reg" I get the following output:
> > reg
>
> =
---
** [tickets:#260] write protection not supported - nrf52840 / laird ble654 / **
**Status:** new
**Milestone:** 0.9.0
**Created:** Wed Nov 27, 2019 06:37 AM UTC by Matthias Schuh
**Last Updated:** Wed Nov 27, 2019 06:37 AM UTC
**Owner:** nobody
Dear open-ocd community,
recently ran
y, one might be able to get a Nuvoton developer
to help with compiling or even with merging.
One way to proceed could be:
1. Get the Nuvoton fork to compile
2. Merge the latest version of OpenOCD into the Nuvoton fork
3. Merge the Nuvoton fork with upstream OpenOCD
Best,
Matthias
On 17.11.1
Perfect, thank you! Solution 3 worked for me, I added the separate
virtual Flash bank and hardware breakpoints were used automatically.
Matthias
On 06.11.19 14:01, Andreas Fritiofson wrote:
>
>
> On Wed, Nov 6, 2019 at 1:37 PM Matthias Stadler
> <mailto:matthias.stad...@medinee
0 0 0 $_TARGETNAME
But I don't have a clue how to fix it.
Thanks a lot!
Matthias
On 06.11.19 12:47, Antonio Borneo wrote:
> On Wed, Nov 6, 2019 at 12:16 PM Andreas Fritiofson
> wrote:
>>
>>
>> On Wed, Nov 6, 2019 at 11:56 AM Matthias Stadler
>> wrote
Thank you, i also tried it with the GIT head build... unfortunately same
behavior.
On November 5, 2019 18:02:45 Tommy Murphy wrote:
Seems a bit odd to me.
Sometimes it's using a hardware breakpoint
Debug: 3162 10991 cortex_m.c:1228 cortex_m_set_breakpoint(): BPID: 0, Type:
0, Address:
, I am happy to help.
Many thanks in advance!
Best regards,
Matthias
arm-none-eabi-gdb xmc-test -ex 'target remote localhost:'
GNU gdb (7.10-1ubuntu3+9) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.h
read in user space because
it's a
privileged register (don't want userspace to mess with the MMU of course).
If the target is stopped in 64bit userspace mode (EL0T), the debugger will
switch the
target to EL1T read the SCTLR register and switch back to EL0T.
However, in your case the target
oc4 and psoc6 converted to the new reset platform 11) 4727 tcl/target: ti_cc32xx.cfg converted to the new reset platform 12) 4752 target/startup.tcl: execute dap init twice in specific reset config [WIP]13) 4690 cortex_a: adapt reset assert/deassert to new reset framework codeThis is Matthias' ve
gt; stuff Tomas Vanek has done.
>
> Matthias,
>
> I'm afraid it is not wise to wait for any particular patch or series.
> As regards the reset framework, it needs more work: the emerging SWD
> multidrop support
> http://openocd.zylin.com/4935 will require per-target settin
llowed be "12" half a year later?
Automatic nightly builds for the supported platforms would be nice and will
make
openocd more accessible between releases.
BR,
Matthias
>
>
> regards,
>
> Liviu
>
>
>
> ___
nd then
we can merge the whole thing.
That, and a few kinks in the hwthread support to be ironed out. There are
patches already lined up which are more or less ready for inclusion, once I
get around to check them.
BR,
Matthias
>
>
e thread update from the vcont support will have side effects. I
specifically
put it there to circumvent a weird behaviour I was seeing with rtos threads
being not up
to date at this point. It should be resolved at a point but the fix for
current_threadid must
go into hwthread.c anyway.
BR,
Mat
017. You
need to be able to compile openocd from source and run the test for each bisect
step.
BR,
Matthias
> Ciao,
> RM
>
>
> On Fri, Apr 5, 2019 at 10:13 AM
>
> wrote:
> > Rocco Marco Guglielmi writes:
> > > Hello there,
> > > any hint?
>
t can be fixed. :-)
Yes, even if it's there since the original commit (which means it got past the
review like
that!) that introduced coreid, it's a bug and I'd appreciate a fix.
Thanks for spotting this!
BR,
Matthias
>
> Tim
--
Mit freundlichen Grüßen/Best regards,
Matthias Welwarsky
On Dienstag, 19. März 2019 04:58:42 CET Florian Fainelli wrote:
> Hi Matthias, Antonio,
>
> I am working through a set of changes to make OpenOCD's armv7a_mmu.c
> capable of dumping LPAE descriptors as well as super-section when
> using the short descriptors.
Thanks!
>
g
them (modified version of flush_journal()).
- maybe add some garbage collection to flush the pool after a while
BR,
Matthias
>
> Thanks,
> Bohdan Tymkiv
--
Mit freundlichen Grüßen/Best regards,
Matthias Welwarsky
Project Engineer
SYSGO AG
Office Mainz
Am Pfaffenstein 14 /
you look for e.g. corrupted RX/TX ethernet packets
etc. I didn't need to use TLB inspection yet.
TRACE32 has a good deal of integration in their debug view, e.g. you can see
in a source browser during debugging which variables are in the data
e core openocd, but as a TCL extension it
probably makes sense.
BR,
Matthias
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
t; target/riscv/riscv-01x.c. There is no such function pointer in their
> structure defined.
Risc-V is in the process of being merged into openocd mainline. Not all
functionality might be merged yet, but the development is ongoing.
BR,
Matthias
___
at the chip designers will have to tell you.
BR,
Matthias
>
>
>
>
> ___
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
On Mittwoch, 23. Januar 2019 13:18:31 CET Xen Mann wrote:
> >Von: "Matthias Welwarsky"
> >An: openocd-devel@lists.sourceforge.net
> >Cc: "Xen Mann"
> >Betreff: Re: [OpenOCD-devel] adding new interface(TAP): need to shift 36
> >bit to read 8 bi
th
> for the exact number of bytes. target_type.read_memory() / ...
Hm. If you're implementing a new TAP interface, why do you bother with
target_type?
Just curious ...
BR,
Matthias
--
Mit freundlichen Grüßen/Best regards,
Matthias Welwarsky
Project Engineer
SYSGO AG
Office Mainz
Am Pfaf
Hi,
I was about to write some Tcl configuration files,
but was a bit confused about the tcl/ folder structure.
Do you have criteria, by which you organize configuration files?
Because it looks a bit random to me...
Best,
Matthias
___
OpenOCD-devel
t; 4121 rtos: support gdb_get_register_packet
> 4660 esirisc: support eSi-RISC targets
> 4078 gdb_server: add support for architecture element
> 4112 ftdi: demote unhelpful debug messages
>
> Cheers,
> Steve
>
if there are no objections, I will merge the patchset in a few days.
.zylin.com/#/c/3999/ is a sufficient
replacement for the
rtos hack. I'm pretty sure it's practically the same and I prefer to merge this
instead of an
architecture-bound solution.
>
> Tim
--
Mit freundlichen Grüßen/Best regards,
Matthias Welwarsky
Project Engineer
SYSGO AG
Office Mainz
r on the target.
>
Please provide a -d3 log.
BR,
Matthias
> Thank you,
>
> Rick
>
> ---
>
> In src/jtag/drivers/ftdi.c, there is an adjustment made for time between
> AP instructions.
>
> ---
>
> /* Insert idle cycles after AP accesses to avoid WAI
M CPU without making
> any harm - it should be verified.
I'll merge Antonios change for apcsw command in init phase, then the csw setup
can go into a target configuration file. The less hardcoded policy in the
openocd binary the better.
BR,
Matthias
>
> As usually feel free to p
nt.
The policy is "make gdb happy", which has no idea about cache coherence and
cannot deal with it. Therefore, openocd must do everything required to present
a coherent memory view to gdb.
BR,
Matthias
--
On Donnerstag, 2. August 2018 15:31:56 CEST Antonio Borneo wrote:
> On Thu, Aug 2, 2018 at 8:24 AM, Michael Schwingen
wrote:
> > On Wed, 01 Aug 2018 22:25:18 +0200
> >
> > Matthias Welwarsky wrote:
> >> Hi,
> >>
> >> I'm very much wondering if
On Donnerstag, 2. August 2018 08:24:17 CEST Michael Schwingen wrote:
> On Wed, 01 Aug 2018 22:25:18 +0200
>
> Matthias Welwarsky wrote:
> > Hi,
> >
> > I'm very much wondering if this feature is worth maintaining. Is it
> > so useful that it's worth the c
. If there isn't a compelling
argument to keep it I'm much more in favor of removing it completely instead
of trying fixing it.
BR.
Matthias
On Mittwoch, 1. August 2018 15:01:31 CEST gerrit wrote:
> This is an automated email from Gerrit.
>
> Antonio Borneo (borneo.anto...@gmail.com) just uploa
On Montag, 16. Juli 2018 12:35:33 CEST Antonio Borneo via OpenOCD-devel wrote:
> For a first hack, you could replace the hardcoded addresses in OpenOCD, but
> you have two cortex-M and this hack will work for one only. The way to go
> should be to extend Cortex-M support and use -dbgbase,
accepting the code. Thanks for all the effort!
> Thank you,
> Tim
--
Mit freundlichen Grüßen/Best regards,
Matthias Welwarsky
Project Engineer
SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany
Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
VoIP: SIP:m...@s
3. Similarly, would there be interest in a generic socket implementation?
The TCLRPC stuff is not enough for your purposes?
BR,
Matthias
>
> Other comments?
>
> Thanks!
> Tom
--
Check out the vib
On Mittwoch, 28. März 2018 20:54:12 CEST Christian Haettich wrote:
> Hi Daniel,
>
> The patch of Eric Hoffmann sounds promising, but it doesn't work with my
> board (which has an on-board USB-Blaster2 solution).
Can you add your experiences as review comments to the patch in gerrit? This
patch
mand
'gdb_report_register_access_error' similar to 'gdb_report_data_abort' and
make sure it defaults to 'off'. Please also add documentation to openocd.texi.
Your RISC-V target configuration scripts can then enable this option, as can
everyone else who wants to experiment with it.
BR,
Matthias
On Montag, 26. März 2018 23:15:17 CEST Tim Newsome wrote:
> On Mon, Mar 26, 2018 at 1:30 AM, Matthias Welwarsky <
> matthias.welwar...@sysgo.com> wrote:
>
> You could start by explaining why it is necessary for RISC-V. Why would gdb
>
> > even ask for a register that
h still be needed?
Also, if this patch is genuinely useful, why do ARM targets break when it's
enabled?
BR,
Matthias
>
> Thank you,
> Tim
--
Mit freundlichen Grüßen/Best regards,
Matthias Welwarsky
Project Engineer
SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim
x.cfg
Looking forward to your contributions.
Best regards,
Matthias
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
not up in the ADI protocol.
BR,
Matthias
--
Mit freundlichen Grüßen/Best regards,
Matthias Welwarsky
Project Engineer
SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany
Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
VoIP: SIP:m...@sysgo.com
E-mail: matthias.welwar...@sys
the inputs to the hardware (VHDL) and what are the expected outputs from
> the hardware (VHDL) back to OpenOCD?
What are you actually trying to do? A JTAG probe? Then have a look at the HLA
adapter drivers like stlink, or the CMSIS-D
programming. I found this suspicious, but again,
> didn’t look into it too much as the direct approach was very fast.
TDO just get's tristated when the target is not driving it, i.e. if you're not
in SHIFT-IR/DR state. I have the same behaviour on the i.MX8MQ I'm currently
working
o reach close to 1MB/s, as long as you just push data
out and don't need to flush the queue to turn around and read back status
registers.
BR,
Matthias
--
Check out the vibrant tech community on one of the w
On Dienstag, 27. Februar 2018 23:23:47 CET Christopher Head wrote:
> On February 27, 2018 2:42:25 AM PST, Matthias Welwarsky
<matthias.welwar...@sysgo.com> wrote:
> >I'm guessing that the BUSY check was done to explicitly to avoid a JTAG
> >WAIT,
> >which was an e
ions, but I can’t see it making a whole lot of difference to
> the execution time in algorithm mode.
I'm guessing that the BUSY check was done to explicitly to avoid a JTAG WAIT,
which was an error condition not long ago. It might still break with SWD.
--
Mit freundlichen Grüßen/Best regards,
M
On Donnerstag, 22. Februar 2018 15:59:50 CET Tomas Vanek via OpenOCD-devel
wrote:
> A FAQ probably for you, Paul... Well, I'm interested too.
Personally, I would like to see the reset framework fixes integrated before
0.11 is released.
>
>
> Forwarded Message
> Subject:
ves using bare JTAG scan
commands, those will probably be the correct level of abstraction.
Best regards,
Matthias
>
> Regards,
> Antoine
>
>
> -- Check out the vibrant tech community on one of the wo
; Jim_SetAssocData(interp, "context", NULL, ctx_with_curent_target_set);
> Unfortunately we have to restore assoc data back when done - much more
> complicated...
>
> Tom
While looking that that issue, you may also want to have a look at this change
here, which fixes a r
hanges the signature of get_current_target() and therefore
requires fixing all its users, but it spells out nicely what has been changed
and where. I actually prefer this version, but "ymmv".
I'd like to have opinions on the patch and possibly a review to get this
annoying bug f
t due to that. You might be
able to fix that with adding "cortex_a dacrfixup on"
BR,
Matthias
smime.p7s
Description: S/MIME cryptographic signature
--
Check out the vibrant tech community on one of the world's m
(Motorola)), part: 0x891d, ver: 0x1) Error: target->coreid 0
> OSLock sticky, core not powered?
The OS running on the board has put the cpu core to sleep? Maybe disable the
CPU idle handling and try again?
BR,
Matthias
>
> Any help appreciated,
>
>
>
> Many Thanks
ie Chopin suggested. As long as the function can stay where it is
and I don't need to #ifdef it entirely.
BR,
Matthias
--
Check out the vibrant tech community on one of the world's most
en
On Friday 21 April 2017 09:59:30 Pierre wrote:> I've just noticed
http://openocd.zylin.com/#/c/3999/ that be a way to avoid
> these issues
Nice to hear, but the bugs of course exist nevertheless. See comments
below.
> [tickets:#150] Targets in "Examine Deferred" state create issues
> Status:
,
that should fix the problem for MacOS (the #defines are obviously
compatible).
The __unused will go away in a while, once I decide what to do with the
currently unused functions in armv8.c.
BR,
Matthias
On Monday 24 April 2017 12:14:07 Freddie Chopin wrote:
I just (mistakenly) a
changes the function signature, the first might have side
effects or maybe not feasible at all.
Hoping for advice.
BR,
Matthias
--
Check out the vibrant tech community on one of the world's most
engaging tech sites
On Thursday 17 November 2016 20:25:36 Uwe Bonnes wrote:
> Hallo,
>
> Zillions of Matthias patches hanging uncommented...
>
> Are they considered for 0.10.0 or for post 0.10.0? Or do they fall into
> the category: Nobody can review them as nobody has an appropriate setu
implements the change I requested myself.
3641: I know it's an ugly hack but it fixes a regression with reset and SWD.
It's not intended to stay, the whole reset procedure will be reworked in 3720,
which is too risky for the current merge window.
BR,
Matthias
>
> I know it's annoying many
On Thursday 08 September 2016 11:14:50 Matthias Welwarsky wrote:
> Let me fill you in on my current state:
So, the current current state can be found here:
http://openocd.zylin.com/3832 (checkout to get the full branch)
It's actually quite usable, but not yet fully functional.
What I k
On Thursday 08 September 2016 11:14:50 Matthias Welwarsky wrote:
> Let me fill you in on my current state:
So, the current current state can be found here:
http://openocd.zylin.com/3832 (checkout to get the full branch)
It's actually quite usable, but not yet fully functional.
What I k
has an idea about what's happening, that'd be awesome.
BR,
Matthias
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
For your general amusement, here's the current work-in-progress:
https://github.com/sysgo-maw/openocd-aarch64
On Wednesday 14 September 2016 21:09:31 Matthias Welwarsky wrote:
> On Wednesday 14 September 2016 08:12:01 Duane Ellis wrote:
> > >> What might (should?) work in my
many of the relevant system registers are
mapped between their respective counterparts (e.g. CLIDR, CSSELR, ...). I
don't yet see that a completely separate code module for aarch32 is required.
BR,
Matthias
--
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
On Tuesday 13 September 2016 22:23:11 Matthias Welwarsky wrote:
> On Tuesday 13 September 2016 20:08:46 David Ung wrote:
> > FWIW, on linux as long as CONFIG_COMPAT is enabled, you can run both
> > AArch64/32 userspace programs. But the mode switching is done at an
> > ex
L2, setting bit 4 = 1 and bits 3:0 to some valid aarch32 mode
(0x3 - svc mode)
- set ELR_EL2 to a memory location with valid ARM code
- "ERET"
BR,
Matthias
>
> David
>
>
> From: Andreas Färber <afaer...@suse.de>
> Sent: Tues
On Tuesday 13 September 2016 08:57:07 Matthias Welwarsky wrote:
> On Tuesday 13 September 2016 07:30:38 Matthias Welwarsky wrote:
> > That being said, can anyone share some code to switch a PE to Aarch32
> > mode?
> > I'm on Rpi3, using a custom little program that do
Rpi3, using a custom little program that does nothing but set up the
GPIOs and then execute an endless loop. The program runs at EL2 in Aarch64
state. This would certainly speed up work.
>
> David
>
> ____
> From: Matthias Welwarsky <matth...@
isty passages all alike” and the pirate (crash bug) will
> suddenly appear and take all of your gold and treasure.
Maybe, but anyway first we need to get it correct, then we can think of making
it neat. Right now it's not correct or complete.
BR,
Matthias
>
> -Duane.
--
On Sunday 11 September 2016 14:55:39 Andreas Färber wrote:
> Am 08.09.2016 um 23:08 schrieb David Ung:
> > Andreas Fritiofson mentions there was already a patch in Gerrit that
> > changes the target addresses throughout OpenOCD to a 64-bit type.
> > http://openocd.zylin.com/1200
> >
> > This
s in Aarch32 state, but the encoding
is different to -64 state. T32 and A64 don't seem to have a common, usable
subset.
Was your code working in Aarch32 state?
BR,
Matthias
>
> David
>
> ____
> From: Matthias Welwarsky <matth...@welwarsky.de>
&g
possibility to halt timer counting on entering debug state. This would prevent
the ticker timer from latching an interrupt while the core is halted, but
needs to be solved at board or chip level in a config file.
BR,
Matthias
Hi,
I don't have any possibility to test this on Windows. I'd appreciate if you
were able to try and provide feedback.
BR,
Matthias
On Tuesday 23 February 2016 21:55:08 Kent Brinkley wrote:
> I agree that Device manager is the way to go on Windows, how about an
> example cfg file that
abled? Also, the status bits decode
to "000110", which is a MMU translation fault, at level 2! Is there a
hypervisor active? I would not be surprised, knowing that it's a Qualcomm
device. If yes, you can assume that you tried to access a memory region that
has not been
On Thursday 10 December 2015 06:29:01 gerrit wrote:
> This is an automated email from Gerrit.
>
> Andreas Fritiofson (andreas.fritiof...@gmail.com) just uploaded a new patch
> set to Gerrit, which you can find at http://openocd.zylin.com/3165
I very much like where this is heading. Apart from
Hi,
does anyone know the rationale behind "cortex_a dbginit"? Is there a reason
for it to be a separate command? arp_examine executes the code anyway so that
should cover all the bases, shouldn't it?
BR
://openocd.zylin.com/3119
BR,
Matthias
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development
On Friday 20 November 2015 13:25:04 Andreas Fritiofson wrote:
> On Fri, Nov 20, 2015 at 11:20 AM, Matthias Welwarsky <matth...@welwarsky.de>
> > How would gdb utilize the ahb-ap for uploading binaries?
>
> First of all, should it? As (I think) we have established, th
lize the ahb-ap for uploading binaries? Or a tcl script?
BR,
Matthias
--
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
IW, I can offer to review and merge patches at least in the ARMv7/Cortex-A
area. I currently have access to a lot of different ARM hardware so that I can
even to some testing myself, though likely I would only do that to confirm
that a patch is not breaking one of my own targets.
BR,
Thread support does not work for recent FreeRTOS because varialbe
'uxTopUsedPriority' used in OPENOCD_SRC/src/rtos/FreeRTOS.c was
obmitted in FreeRTOS.
Appended patch based on OpenOCD 0.8.0 corrects this by calculating this
variables value based on pointers available.
Regards
Matthias
81 matches
Mail list logo
