o
match up, unless the hardware explicitly tells you the reason.
Tim
On Sat, Jul 22, 2023 at 12:07 AM Liviu Ionescu wrote:
> Given the findings discussed in a previous thread, it seems that the
> existing Cortex-M7 cores from STM have a bug which triggers an unexpected
> breakpoint when
verything and do the resume again. If we fail instead, then there is no
good way for the user to only set the PC on the halted harts and resume
them.
Tim
> Example (core0.cpu and core1.cpu are in SMP group):
> reset halt
> targets core0.cpu
> bp
> resume
> //core0.cpu hit
On Fri, Apr 7, 2023 at 9:00 AM Tim Newsome wrote:
>
>
>> Can you use Checkpatch-ignore in the fork?
>>
>
> Possibly. Part of the problem is that I haven't figured out in the github
> action how to find which changes are part of the pull request. Erhan
> su
478245399,
but they don't work when the action is running.
I guess we'll have to figure that out, and then we can add
checkpatch-ignore, or simply override the check when merging.
Tim
>
> Well,
> https://github.com/riscv/riscv-openocd/pull/816#issuecomment-1474425966
>
But I'm curious how others think of this.
Tim
On Tue, Mar 28, 2023 at 9:09 AM Evgeniy Naydanov <
[email protected]> wrote:
> Hello! I'm struggling to understand how `resume ` command should
> behave for an SMP configuration like this:
> ```
> target
efile there would go a long way towards getting this kind of thing
tested.
Tim
On Fri, Dec 2, 2022 at 4:25 AM Kirill Radkin
wrote:
> Could someone explain the difference between the following 2
> configurations?
>
> I'm using RISCV targets, but it may be the case that problem ex
ts share memory, so if you set a software
breakpoint on one target, then all of them will automatically see it as
well.
Tim
You can set the value you need for your hardware using `irscv
set_bscan_tunner_ir `. The code you pointed at is the default value.
Tim
On Wed, Oct 12, 2022 at 3:15 AM peng cheng wrote:
> Registered in the mail list and repost this bug report again.
>
> peng cheng 于2022年10月12日周
This should be addressed between https://review.openocd.org/c/openocd/+/7087
and https://review.openocd.org/c/openocd/+/7084.
Tim
On Thu, Jun 30, 2022 at 9:22 AM Tim Newsome wrote:
> On Wed, Jun 29, 2022 at 1:46 PM Antonio Borneo
> wrote:
>
>> On Wed, Jun 29, 2022 at 9:48
Thank you both. Generating a new ssh key let me push a change.
Tim
On Fri, Jul 8, 2022 at 1:49 PM Paul Fertser wrote:
> Hi Tim,
>
> On Fri, Jul 08, 2022 at 01:13:21PM -0700, Tim Newsome wrote:
> > I used to be able to `git push review` to open a new pull request, but
> th
riscv-openocd$
```
I checked and https://review.openocd.org/settings/#SSHKeys shows that my
SSH keys match. Did something change that means I need to take some extra
steps?
Tim
On Wed, Jun 29, 2022 at 1:46 PM Antonio Borneo
wrote:
> On Wed, Jun 29, 2022 at 9:48 PM Tim Newsome wrote:
> >
> > On Tue, Jun 28, 2022 at 3:09 PM Antonio Borneo
> wrote:
> >>
> >> Definitively odd! The top part matches the initial part of
> >> http
ifornia presumably only they can
change the license, which sounds like a big bureaucracy at best. Seems
easier just to include the license in the OpenOCD source and binary. I've
opened a PR at https://github.com/riscv/riscv-opcodes/pull/131 to help with
that.
Tim
is file can be used.
>
That license doesn't seem to be exactly a BSD-3-Clause. I'm not a lawyer so
I don't want to say the two licenses are equivalent, which I think means we
have to distribute the license verbatim.
Tim
ITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE SOFTWARE AND ACCOMPANYING DOCUMENTATION, IF ANY, PROVIDED
HEREUNDER IS PROVIDED "AS IS". REGENTS HAS NO OBLIGATION TO PROVIDE
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
Tim
>
://github.com/riscv/riscv-opcodes. The LICENSE
<https://github.com/riscv/riscv-opcodes/blob/master/LICENSE> in question
looks a bit painful as well. I'll see about including the license directly
in that header file as a string, so it's present in the source and could be
display
ld be even better.)
Thank you,
Tim
e the root problem is that people just don't have the time to spend.
Given that restriction, what could be done to improve things?
Tim
Change https://review.openocd.org/c/openocd/+/6362 has been sitting idle
since December 2nd. There are no outstanding review issues. Can it be
merged? If not, can we discuss what the problems are so I can address them?
Thank you,
Tim
responded to my comments there since September. Can somebody
take a look?
Thank you,
Tim
Can somebody look at this?
Thank you,
Tim
On Mon, Aug 9, 2021 at 12:54 PM Tim Newsome wrote:
> Can I get a review of change http://openocd.zylin.com/#/c/6362/:
>
> Combine register lists of smp targets.
>
> This is helpful when you want to pretend to gdb that your heterogene
fine if e.g. one of the cores
has an FPU while the other does not. (Specifically, HiFive Unleashed has 1
core with no FPU, plus 4 cores with an FPU.)
Thank you,
Tim
f e.g. one of the cores
has an FPU while the other does not. (Specifically, HiFive Unleashed has 1
core with no FPU, plus 4 cores with an FPU.)
Tim
un() there will
be one DMI scan for each batch->used_scans. In riscv_batch_add_dmi_write()
batch->used_scans is incremented once, as expected.
There are probably some ways to optimize memory writing, but the inner loop
of write_memory_progbuf() scans no more bits than necessary.
Tim
>
On Thu, Jun 3, 2021 at 9:04 AM Marc Schink wrote:
> 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
Linux kernel. Maybe there is a
> need to refresh/update it. It misses the doxigen headers.
> Kernel doc for list.h is here
> https://www.kernel.org/doc/html/v4.15/core-api/kernel-api.html
Can we add that link to list.h also? It's probably obvious to people who
are familiar with how the kernel is organized, but I did not think to go
looking there.
Tim
>
On Mon, May 24, 2021 at 4:31 PM Andreas Fritiofson <
[email protected]> wrote:
>
>
> On Wed, Feb 17, 2021 at 9:21 PM Tim Newsome wrote:
>
>> On Tue, Feb 16, 2021 at 4:17 PM Steven Stallion via OpenOCD-devel <
>> [email protected]>
On Thu, May 20, 2021 at 12:56 PM Antonio Borneo
wrote:
> On Thu, May 20, 2021 at 9:15 PM Tim Newsome wrote:
> >
> > So, can at least one person say uthash will be fine to use in OpenOCD
> code?
> >
> > After the lack of response on this thread last time I went ahe
So, can at least one person say uthash will be fine to use in OpenOCD code?
After the lack of response on this thread last time I went ahead and did an
implementation using gnulib which I now have to rewrite using something
else. I'd like to only do that once.
Tim
On Tue, May 18, 2021 at
led on the PC.
> Copying uthash inside OpenOCD code is not my preferred choice because
> it will add extra work to track the upstream version and keep OpenOCD
> in sync.
That all sounds good to me.
Tim
On Wed, Feb 17, 2021 at 12:20 PM Tim Newsome wrote:
> On Tue, Feb 16, 2021 at
pport as follows:
@code
LDFLAGS="-fprofile-arcs -ftest-coverage"
CFLAGS="-fprofile-arcs -ftest-coverage" ./configure
@endcode
Now every time OpenOCD is run, coverage info in your build directory is
updated. Running `gcov src/path/file.c` will generate a rep
ess
on the same machine, so there may be some implicit flushing going on in the
kernel for that kind of scenario.
Tim
>
on Windows. Is that right? Is anybody motivated to take that on?
Tim
Congrats on getting this out, Paul! I appreciate you taking on the most
thankless task of all: making a release.
Tim
On Sun, Mar 7, 2021 at 10:46 AM Paul Fertser wrote:
> Finally! Final.
>
> I'm happy to announce the availability of OpenOCD version 0.11.0.
>
> So four
list instead if rtos_get_gdb_reg_list() returns an error
My problem was that step 1 wasn't happening correctly.
(Is there any chance of all this working when a target has multiple cores,
configured as SMP?)
Tim
On Tue, Feb 23, 2021 at 11:45 AM Tim Newsome wrote:
> When using `-rt
don't see ARM FreeRTOS users complaining about this behavior. What am
I missing? How is this supposed to work?
Thank you,
Tim
___
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
fficient even with lots of data, because it'll save somebody someday, and
is no extra work for me.
Tim
___
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
On Tue, Feb 16, 2021 at 12:59 PM Antonio Borneo
wrote:
> On Tue, Feb 16, 2021 at 9:25 PM Tim Newsome wrote:
> >
> > I'm working on sprucing up FreeRTOS.c, and I want to keep a map of TCB
> address to thread id. (Currently they're the same, but that doesn't work
r should I write something less
efficient myself?
(Really my preferred option would be to switch OpenOCD to use C++, then I
can use STL and a number of other convenient features.)
Tim
___
OpenOCD-devel mailing list
[email protected]
htt
ructure in
memory at that point.
Tim
On Wed, Feb 10, 2021 at 11:02 AM Steven Stallion
wrote:
> I think my only worry is impact to other RTOSes. I had to hack around this
> too when I wrote the uC/OS-III support. There's definitely a special case
> when the RTOS is not running, but fortun
Thanks. I'll hold off upstreaming anything until that's done.
Tim
On Wed, Feb 10, 2021 at 10:24 AM Paul Fertser wrote:
> Hey Tim,
>
> On Wed, Feb 10, 2021 at 10:18:02AM -0800, Tim Newsome wrote:
> > What's the status of this release? I've put on hold upstrea
te_threads(), first the configured rtos is called, so that that
code will take over once code has advanced to the point where there are
rtos threads. Does that make sense?
Tim
On Fri, Feb 5, 2021 at 1:48 PM Tim Newsome wrote:
> I'm looking into adding RISC-V FreeRTOS support to OpenOCD,
What's the status of this release? I've put on hold upstreaming some more
changes from the RISC-V fork because it didn't seem worth potentially
destabilizing a release for. But it's been a long time now, and I don't
want my fork to drift too far off mainline if I can help
ad, which simply reflects the current execution
thread. It seems like this code should just read the regular registers for
this case. I don't see where that might be happening, though. How is this
supposed to work?
Thank you,
Tim
___
OpenOCD-de
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 the sooner
that happens the better.
Tim
On Fri, Nov 27, 2020 at 9:51 AM Antonio Borneo
wrote:
> Hello,
>
> the initial idea was to tag v0.11.0-
, but I'm quite opinionated
when it comes to how votes should be held. :-)
Tim
On Thu, Oct 8, 2020 at 12:26 PM Liviu Ionescu wrote:
>
>
> > On 8 Oct 2020, at 20:19, [email protected] wrote:
> >
> > Once this first round has finished and we have a "
Main OpenOCD is quite a long way behind the riscv-openocd fork. Please try that
version, and if the problem exists there, then file a bug on github.
riscv-openocd lives at https://github.com/riscv/riscv-openocd
Tim
---
** [tickets:#276] riscv reg command problem**
**Status:** new
On Thu, Apr 30, 2020 at 3:51 AM Antonio Borneo
wrote:
> Yes,riscv target does not define the function get_gdb_arch(), so
> cannot send the arch value to gdb.
> This should be easy to fix, but there are so many variants of riscv
> that I don't know how to correctly implement i
rebased before submitting, which means
that a maintainer can't select more than one patch at a time to merge.
Given that maintainers already seem to have very little time to
review/merge patches, I prefer the status quo. Breakage has been rare, and
at least it makes it possible for sometimes a
Thanks, Antonio. I didn't realize -defer-examine existed. It looks like it
might do what I want.
Tim
On Mon, Jan 6, 2020 at 1:08 PM Antonio Borneo
wrote:
> On Mon, Jan 6, 2020 at 9:06 PM Tim Newsome wrote:
> >
> > I have a RISC-V target with 2 TAP controllers chained t
Happy New Year, devs!
I'd still love to get a review on http://openocd.zylin.com/#/c/5324/.
Thank you,
Tim
On Mon, Dec 2, 2019 at 12:41 PM Tim Newsome wrote:
> Months ago I submitted http://openocd.zylin.com/#/c/5324/, and I would
> like to get a review of it.
> These are simple
Thanks, Tommy. I'd thought of doing it all in TCL before `init` but I feel
it gets rather unwieldy, and I'd end up rewriting a bunch of the RISC-V
target code in TCL just to make it happen.
Tim
On Mon, Jan 6, 2020 at 2:18 PM Tommy Murphy
wrote:
> Hi Tim
>
> FWIW we (Microchi
If I just configure both of those and connect then OpenOCD errors out
because examine() fails on the core behind the second controller because
it's not powered up yet. How can I change the code to make this case work?
Is there an example for some oth
cally only expose
the general purpose and FPU registers.
Anyway, I'd love a review on this, so I can resume the process of pushing
the RISC-V changes upstream. I'm not trying to make target-independent
changes, but sometimes that is just clearly the best choice.
Hi,
These two changes are relatively minor, but they've both been approved. Can
they be merged?
http://openocd.zylin.com/#/c/4451/: Add complete JTAG debug logging.
http://openocd.zylin.com/#/c/4767/: Add wall clock timeout warning to
mpsse_flush()
Thank you
Duplicate of https://github.com/riscv/riscv-openocd/issues/414
Tim
On Thu, Oct 10, 2019 at 1:08 AM Sathya Narayanan N
wrote:
> Dear experts,
>
> I am trying to write to flash directly using openocd. I went through
> riscv-openocd
> <https://github.com/riscv/riscv-openocd/bl
target->head. Does that seem reasonable? Is there a better way to solve
this?
I'd love to simply say that gdb should be aware of heterogeneous multicore,
but AFAIK that doesn't really exist.
Tim
___
OpenOCD-devel mailing list
I've been asking for http://openocd.zylin.com/#/c/5114/ to be merged for
months now. It's been approved. What can I do to move this process forward?
What is the process?
Thank you,
Tim
On Wed, Jul 10, 2019 at 9:51 AM Tim Newsome wrote:
> Change http://openocd.zylin.com/#/c/5114/ i
Change http://openocd.zylin.com/#/c/5114/ is approved by Matthias. What can
I do to get it actually merged?
Tim
On Thu, May 23, 2019 at 12:04 PM Tim Newsome wrote:
> What do I need to do to move this change forward?
>
> Tim
>
> On Mon, May 6, 2019 at 1:25 PM Tim Newsome
---
** [tickets:#239] Using OpenOCD a dynamic link library?**
**Status:** new
**Milestone:** 0.9.0
**Created:** Thu May 30, 2019 04:39 PM UTC by Tim Smith
**Last Updated:** Thu May 30, 2019 04:39 PM UTC
**Owner:** nobody
We wanted to utilize OpenOCD as a DLL in-process in our application
What do I need to do to move this change forward?
Tim
On Mon, May 6, 2019 at 1:25 PM Tim Newsome wrote:
> Can somebody continue the review on http://openocd.zylin.com/#/c/5114/?
> I've gotten some feedback which I addressed, over 2 weeks ago. I'd like to
> get this cha
Yes, it is GPL v2+ compatible. Any ideas
On Tue, May 21, 2019 at 10:53 AM Paul Fertser
wrote:
> Hi Tim,
>
> On Tue, May 21, 2019 at 04:53:03PM -, Tim Smith wrote:
>
> Hi Paul, We wanted to run OpenOCD with in our process preferably by
> linking it
> as a DLL. Is th
Yes, it is GPLv2+ compatible. Any ideas?
---
** [tickets:#235] Communicating with OpenOCD's north bound API's?**
**Status:** new
**Milestone:** 0.9.0
**Created:** Wed May 01, 2019 09:12 PM UTC by Tim Smith
**Last Updated:** Tue May 21, 2019 04:53 PM UTC
**Owner:** nobody
Hi,
Hi Paul, We wanted to run OpenOCD with in our process preferably by linking it
as a DLL. Is this something possible?
---
** [tickets:#235] Communicating with OpenOCD's north bound API's?**
**Status:** new
**Milestone:** 0.9.0
**Created:** Wed May 01, 2019 09:12 PM UTC by Tim Sm
Can somebody continue the review on http://openocd.zylin.com/#/c/5114/?
I've gotten some feedback which I addressed, over 2 weeks ago. I'd like to
get this change in because some improvements to `-rtos hwthread` depend on
it.
Thank you,
Tim
_
---
** [tickets:#235] Communicating with OpenOCD's north bound API's?**
**Status:** new
**Milestone:** 0.9.0
**Created:** Wed May 01, 2019 09:12 PM UTC by Tim Smith
**Last Updated:** Wed May 01, 2019 09:12 PM UTC
**Owner:** nobody
Hi,
We have a debugger that supports halt() , ste
I just submitted my fix for this (along with a raft of other hwthread
tweaks) at http://openocd.zylin.com/#/c/5101/
Tim
On Wed, Apr 10, 2019 at 4:02 AM Matthias Welwarsky <
[email protected]> wrote:
> On Dienstag, 9. April 2019 01:36:43 CEST Tim Newsome wrote:
>
> &
s */
rtos->thread_details = malloc(sizeof(struct thread_detail) *
thread_list_size);
Tim
On Mon, Apr 8, 2019 at 9:36 AM Daniel Goehring OS via OpenOCD-devel <
[email protected]> wrote:
> Hello,
>
> For the OpenOCD project, I’d like to commit a change
m not
comfortable making the change or even declaring it a real bug. But now at
least it's been passed up the chain. If this means something to somebody,
it can be fixed. :-)
Tim
___
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
On Fri, Mar 8, 2019 at 8:59 AM Tim Newsome wrote:
> I include files from src/target/riscv (debug_defines.h, riscv.h). Will
>> those headers be incompatible in future because they will have changed? Or
>> will changes at those files only add information but no
ture. If I change it after your code merges I will attempt
to keep your code working. Part of that will be on you to keep an eye on
RISC-V changes as they are suggested to OpenOCD to make sure they won't
break your code.
Tim
___
OpenOCD-devel mail
de directly into the main
OpenOCD project. I periodically merge everything from the main OpenOCD
project into riscv-openocd, and am working on merging all changes from
riscv-openocd into the main OpenOCD project (see e.g.
http://openocd.zylin.com/#/c/4922/).
Tim
Hi all,
I've got an (unfortunately giant) change of RISC-V improvements up for
review at http://openocd.zylin.com/#/c/4922/. Could somebody take a look at
this? I'm happy to answer questions, etc.
Tim
___
OpenOCD-devel mailing list
Ope
The code you're looking for is riscv_get_gdb_reg_list() in
src/target/riscv.c. If you are thinking of making RISC-V-specific changes,
then https://github.com/riscv/riscv-openocd is the place you want. It has
many changes that haven't made it to the OpenOCD mainline yet.
Tim
On Wed, F
---
** [tickets:#220] Generic OpenOCD driver for logical IR/DR scans to use our
custom pod**
**Status:** new
**Milestone:** 0.9.0
**Created:** Thu Jan 17, 2019 12:35 AM UTC by Tim Smith
**Last Updated:** Thu Jan 17, 2019 12:35 AM UTC
**Owner:** OpenOCD-Gerrit
Hi,
We have a simple JTAG
On Mon, Oct 29, 2018 at 1:18 PM The EMARD wrote:
>
> HI Tim!
>
> I didn't know about linux-sio-gpio. It seems to support CBUS-only
> what is suitable for your hardware :). Please try and let me know
> does it work
Davor,
linux-sio-gpio also supports FT232R via
https:/
On Mon, Oct 29, 2018 at 12:53 PM The EMARD wrote:
>
> HI Tim
>
> maybe easiest way is to get my (1-2 month old) openocd fork at github
> where the patch is integrated and start modifying it to
> support CBUS pins on the similar way as RS232 pins are supported
> without brea
On Mon, Oct 29, 2018 at 11:28 AM Tim Harvey wrote:
>
> Greetings,
>
> I've got a BLE module which has an nRF52840 connected with its SWDIO
> and SWDCLK connected to an FTDI FT231XQ single UART CBUS1/CBUS2 pins.
> I'm hoping to program the nRF52840's flash via Ope
On Mon, Oct 29, 2018 at 12:29 PM The EMARD wrote:
>
> HI Tim
>
> any FT231X RS232 pinout is is supported by my ft232r driver patch but
> not the CBUS pins. This is also written in the patched readme doc too.
>
> driver currently supports any pinout wired to RS232 signaling
2 BLE_SCLK
# CBUS0 N/C
interface ftdi
ftdi_device_desc "USB-JTAG"
ftdi_vid_pid 0x0403 0x6015
ftdi_layout_init 0x0006 0x0006
ftdi_layout_signal SWD_EN -data 0
transport select swd
Any help would be greatly appreciated!
Best Regards,
Tim
___
AFAIK RISC-V debug only works with JTAG.
Tim
On Thu, Oct 4, 2018 at 12:10 PM Jay wrote:
>
> Greetings,
>
> Do we have SWD interface support for RISC-V core on OpenOCD?
>
> At this point, I'm using below risc-v fork as baseline, which is known to
> be working with JTA
any target that implements 0.13 of the spec. If you can narrow
down what OpenOCD is doing wrong, I can take a look at fixing the
problem. (openocd
-d should get you lots of detail on exactly what OpenOCD is doing, but you
do have to be familiar with the debug interface to really understand it.)
Tim
On Fri, Sep 14, 2018 at 12:03 AM, Matthias Welwarsky <
[email protected]> wrote:
Tim, please check if http://openocd.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 inst
On Wed, Sep 12, 2018 at 1:44 PM, Liviu Ionescu wrote:
>
>
> > On 12 Sep 2018, at 23:11, Tim Newsome wrote:
> >
> > I would like a review on these changes:
> > http://openocd.zylin.com/#/c/4655/ : Clarify what exactly the RISC-V
> code supports.
> > http://
I would like a review on these changes:
http://openocd.zylin.com/#/c/4655/ : Clarify what exactly the RISC-V code
supports.
http://openocd.zylin.com/#/c/4656/ : Add flash support for SiFive's Freedom
E platforms
Please let me know if there's anything else I need to do.
Than
A few weeks ago I pushed http://openocd.zylin.com/#/c/4578/, which adds
RISC-V support to OpenOCD. What else do I need to do to get this reviewed,
and eventually accepted?
Thank you,
Tim
--
Check out the vibrant tech
On Wed, Apr 4, 2018 at 10:23 PM, Paul Fertser wrote:
> Hello,
>
> On Wed, Apr 04, 2018 at 02:18:13PM -0700, Tim Newsome wrote:
> > Let's say I get my target in a state where examine() fails, but a reset
> would
> > revive it. It appears that OpenOCD can't d
Let's say I get my target in a state where examine() fails, but a reset
would revive it. It appears that OpenOCD can't do that, because until
`init` has completed, there is no `reset` command. Am I missing something?
How should this kind of situation be dealt with?
Than
Thanks, Tomas.
I'll probably wait for your changes to merge, and then hopefully I'll find
some time to change the types.
Tim
On Wed, Apr 4, 2018 at 12:38 PM, Tomas Vanek
wrote:
> On 04.04.2018 1:28, Tim Newsome wrote:
>
> src/flash/nor/core.h defines:
&g
changing uint32_t types to
target_addr_t, and fix whatever errors the compiler points out.)
Tim
--
Check out the vibrant tech community on one of the world's most
engaging tech sites
On Fri, Mar 30, 2018 at 8:19 AM, Matthias Welwarsky <
[email protected]> wrote:
> On Dienstag, 27. März 2018 23:41:54 CEST Tim Newsome wrote:
> > On Tue, Mar 27, 2018 at 11:26 AM, Tim Newsome wrote:
> > > However, reporting an error to gdb doesn'
On Tue, Mar 27, 2018 at 11:26 AM, Tim Newsome wrote:
>
> However, reporting an error to gdb doesn't seem to be all that useful. I've
>> been trying with a Cortex-M target (STM32F303) and effectively the error
>> prevents gdb from fetching all registers from the tar
y're
accessing a register that doesn't exist. I don't really see how to make
that happen without reporting the error, which feels like the right thing
to do in any case.
Tim
--
Check out the vibrant tech
gdb behaves
that way for ARM targets, it seems best not to report errors to it unless
we know it can handle them with grace.
I hope this clarifies things. If it doesn’t, please ask me more.
Tim
--
Check out the vibrant tec
x27;t just always be enabled.) On RISC-V we want
this behavior. I'm slowly working towards upstreaming that port, and this
is part of that effort.
Thank you,
Tim
--
Check out the vibrant tech community on one of t
On Wed, Mar 7, 2018 at 4:33 AM, Paul Fertser wrote:
On Tue, Mar 06, 2018 at 02:34:06PM -0800, Tim Newsome wrote:
> > I made a patch which fails one of the Jenkins
> > builds: [1]http://build.openocd.org/job/openocd-
> gerrit-build/TARGET=zy1000/9213/console
> > How can I
ns of --enable-zy1000-master and --enable-zy1000 but haven't
managed to reproduce the failure.
Thank you,
Tim
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
Thanks for the explanation!
Tim
On Tue, Feb 27, 2018 at 12:03 AM, Paul Fertser wrote:
> On Mon, Feb 26, 2018 at 12:22:58PM -0800, Tim Newsome wrote:
> > > set challenge [riscv authdata_read]
> >
> > Please try ocd_riscv there.
> >
> > That works. Thank y
On Fri, Feb 23, 2018 at 2:08 PM, Paul Fertser wrote:
> Hello,
>
> On Fri, Feb 23, 2018 at 01:53:02PM -0800, Tim Newsome wrote:
> > set challenge [riscv authdata_read]
>
> Please try ocd_riscv there.
>
That works. Thank you.
How does it work? The command prints out a va
value, can I set a tcl variable somehow in my handler?
Thank you,
Tim
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm
1 - 100 of 133 matches
Mail list logo
