> Broken
Nevertheless, in the telnet session, the command will proceed without error.
--
Regards,
Alexei Babich, circuit design engineer, Rezonans plc., Chelyabinsk, Russia
http://www.rez.ru
Jabber ID: imp...@jabber.ru
___
Openocd-development mailing l
On Tuesday 26 January 2010, Alexei Babich wrote:
> > THat MCR thing looks odd, but also:
> Hmm ... Why odd?
Broken
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
> THat MCR thing looks odd, but also:
Hmm ... Why odd?
> > Open On-Chip Debugger 0.4.0-rc1-dev-00118-gdab9297-dirty (2010-01-26-09:08)
>
> "git show dab9297" says more or less "what" ... looks like you have some
> nostandard patches in your git tree.
Nothing interesting. My local commit with
On Wed, 27 Jan 2010, Spencer Oliver wrote:
> > When do_semihosting() returns with an error, the caller should return right
> > away with 1 as the original code did and not 0 like the patch does.
> >
>
> I am confused as the code in git master is:
> if ((*retval = do_semihosting(target, &arm->sem
On Tue, 26 Jan 2010, David Brownell wrote:
> On Tuesday 26 January 2010, Nicolas Pitre wrote:
> > Finally the fix for FLEN could be split in a patch of its own too as
> > this is clearly an orthogonal issue.
>
> If you agree this is a bug, then it should get fixed
> before the 0.4 code freezes .
>
> When do_semihosting() returns with an error, the caller should return
> right away with 1 as the original code did and not 0 like the patch
> does.
>
I am confused as the code in git master is:
if ((*retval = do_semihosting(target, &arm->semi_hosting_info)) != ERROR_OK)
return 0;
On Tuesday 26 January 2010, Nicolas Pitre wrote:
> I don't like the fact that the introduced arm_semi_hosting
> structure (which could have been done in a patch of its own btw) is
> carrying fields that are valid only for one particular instance of a
> semihosting call and therefore should have
On Tuesday 26 January 2010, Nicolas Pitre wrote:
> Finally the fix for FLEN could be split in a patch of its own too as
> this is clearly an orthogonal issue.
If you agree this is a bug, then it should get fixed
before the 0.4 code freezes ...
I'm glad to see a bit more testing of the semihos
On Tue, 26 Jan 2010, David Brownell wrote:
> On Tuesday 26 January 2010, Nicolas Pitre wrote:
> >
> > > > For the record: I did get that working with an ARM9, no
> > > > changes, using the latest CodeSourcery EABI toolchain.
> > > >
> > >
> > > strange, i tested on arm9 aswell.
> > > fileio was
David Brownell wrote:
> On Tuesday 26 January 2010, Nicolas Pitre wrote:
For the record: I did get that working with an ARM9, no
changes, using the latest CodeSourcery EABI toolchain.
>>> strange, i tested on arm9 aswell.
>>> fileio was ok, just printf to stdout/stderr failed.
>> It
On Tue, 26 Jan 2010, Spencer Oliver wrote:
> David Brownell wrote:
> > On Tuesday 26 January 2010, Spencer Oliver wrote:
> >> I could not get the original implementation from Nicolas Pitr working
> >> when outputting to stdout.
> >
> > For the record: I did get that working with an ARM9, no
> >
On Tuesday 26 January 2010, Nicolas Pitre wrote:
>
> > > For the record: I did get that working with an ARM9, no
> > > changes, using the latest CodeSourcery EABI toolchain.
> > >
> >
> > strange, i tested on arm9 aswell.
> > fileio was ok, just printf to stdout/stderr failed.
>
> It is used in
On Tuesday 26 January 2010, David Brownell wrote:
> > No, I haven't checked the buffer. Do you suspect GDB to have a problem ?
> > This test is on my to do list for tomorrow.
>
> I suspect that somehow the (reported?) value for r0 got trashed.
>
> As if ... oh ... something were polling, and some
On Tuesday 26 January 2010, Ethan Eade wrote:
>
> >> This fixes the same problem on our iMX35 (Cogent CSB732).
> >> GDB breakpoints didn't work properly in the previous versions and do
> >> work now.
> >>
> >
> > Thanks for the confirmation!
> >
> > When you say "in the previous versions" .
On Tuesday 26 January 2010, Edgar Grimberg wrote:
> > Obviously. But did you check the buffer to see if it had the
> > right data?
>
> I'm a bit paranoid because of the deeply embedded programming
> background, where even the obvious might be false :)
Exactly why I checked ... and observed that
>
> Obviously. But did you check the buffer to see if it had the
> right data?
I'm a bit paranoid because of the deeply embedded programming
background, where even the obvious might be false :)
No, I haven't checked the buffer. Do you suspect GDB to have a problem ?
This test is on my to do list
>> This fixes the same problem on our iMX35 (Cogent CSB732).
>> GDB breakpoints didn't work properly in the previous versions and do
>> work now.
>>
>
> Thanks for the confirmation!
>
> When you say "in the previous versions" ... roughly which versions?
>
Breakpoints were working on the
On Tuesday 26 January 2010, Edgar Grimberg wrote:
> Hi David,
>
> > However: did you check the buffer to see if it had the right data?
> > What I saw was the right data in the buffer...
>
> The fail is in this code:
>
> /* MCR p14,0,R0,c0,c5,0 */
> retval = arm11_run
Hi David,
> However: did you check the buffer to see if it had the right data?
> What I saw was the right data in the buffer...
The fail is in this code:
/* MCR p14,0,R0,c0,c5,0 */
retval = arm11_run_instr_data_from_core(arm11, 0xEE000E15, &r0,
1);
David Brownell wrote:
> On Tuesday 26 January 2010, Spencer Oliver wrote:
>> patch attached.
>
> ... another preview for the 0.5 series. :)
>
>
got a few patches waiting :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
htt
David Brownell wrote:
> On Tuesday 26 January 2010, Spencer Oliver wrote:
>> I could not get the original implementation from Nicolas Pitr working
>> when outputting to stdout.
>
> For the record: I did get that working with an ARM9, no
> changes, using the latest CodeSourcery EABI toolchain.
>
On Tuesday 26 January 2010, Spencer Oliver wrote:
> patch attached.
... another preview for the 0.5 series. :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Tuesday 26 January 2010, Spencer Oliver wrote:
> I could not get the original implementation from Nicolas Pitr working
> when outputting to stdout.
For the record: I did get that working with an ARM9, no
changes, using the latest CodeSourcery EABI toolchain.
The only moderately surprising be
>From f350601abc80f61dbc37b64adbecb674278e2f86 Mon Sep 17 00:00:00 2001
From: Spencer Oliver
Date: Tue, 26 Jan 2010 15:08:38 +
Subject: [PATCH 2/2] ARM semihosting: document ARMv7M semihosting
Signed-off-by: Spencer Oliver
---
doc/openocd.texi | 11 +++
1 files changed, 11 insert
patch attached.
I could not get the original implementation from Nicolas Pitr working
when outputting to stdout.
The issue i had was with the SYS_FLEN call - it has now been change to
use fstat and printf works with codesourcery semihosting libs as expected.
Cheers
Spen
>From 7703ede2589941
THat MCR thing looks odd, but also:
On Monday 25 January 2010, Alexei Babich wrote:
> Open On-Chip Debugger 0.4.0-rc1-dev-00118-gdab9297-dirty (2010-01-26-09:08)
"git show dab9297" says more or less "what" ... looks like you have some
nostandard patches in your git tree. Plus the "-dirty" sa
On Tuesday 26 January 2010, Liu Hua wrote:
> Hi, I use git to download the newest OpenOCD, and compile with this
> configure" ./configure --enable-maintainer-mode ---enable-jlink"
>
> I write the openocd.cfg like the following:
>
> *gdb_port
> telnet_port
> tcl_port
>
> source [fi
Hi, I use git to download the newest OpenOCD, and compile with this
configure" ./configure --enable-maintainer-mode ---enable-jlink"
I write the openocd.cfg like the following:
*gdb_port
telnet_port
tcl_port
source [find interface/jlink.cfg]
jtag_khz 1500
source [find board/dm3
28 matches
Mail list logo
