from:"Andreas Fritiofson"

On Mon, Jun 6, 2011 at 10:11 AM, Yegor Yefremov
yegorsli...@googlemail.comwrote:

 The only question is, what description has jtagkey-tiny Amontec
 JTAGkey or Amontec JTAGkey-tiny?


My JTAGkey Tiny uses the string Amontec JTAGkey and indeed it works with
the jtagkey.cfg. Please also note that the means to match devices seems to
differ between linux-libftdi and win32-ftd2xx. At work (the latter
configuration) we have set our different ft2232 dongles back to the standard
FTDI vid/pid to avoid having lots of different drivers installed. It works
with the stock openocd config files because openocd-ftd2xx apparently
ignores the vid/pid and uses only the description to select the device. At
home, on linux-libftdi, both the vid/pid and the description must match.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Configuration file for stm32f2xxx

On Mon, Jun 6, 2011 at 11:10 AM, Laurent Charpentier laurent_p...@yahoo.com
 wrote:

 Hi,
 We would like to add the configuration file for the stm32f2xxx to the GIT
 repository.
 Here is the file (should be named openocd/tcl/target/stm32f2xxx.cfg )
 Thanks for adding this file.
 Laurent


A patch is generally preferred.




# Work-area is a space in RAM used for flash programming
 # By default use 128kB
 if { [info exists WORKAREASIZE] } {
   set  _WORKAREASIZE $WORKAREASIZE
 } else {
   set  _WORKAREASIZE 0x2
 }


There are at least one STM32F2xx with 64 kB RAM, so the default work area
size shouldn't exceed that.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Configuration file for stm32f2xxx

On Mon, Jun 6, 2011 at 11:23 AM, Øyvind Harboe oyvind.har...@zylin.comwrote:

 To create a patch:

 git add tcl/tcl/target/stm32f2xxx.cfg


Another minor thing I noticed now, why three x in the file name? And in the
flash driver too it seems? Shouldn't it be stm32f2xx?

(also, to avoid confusion, I'll just point out that the above git snippet
has tcl/ duplicated in the path)

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred

On Mon, Jun 6, 2011 at 3:35 PM, Øyvind Harboe oyvind.har...@zylin.comwrote:

 Is this patch ready to be committed?

 Any objections?


It doesn't build. Leftover variable no longer used.

Apart from that it seems OK from my limited review. I could agree with the
others that it looks like a needlessly complex fix for a simple missing
free. Maybe there's a bigger picture here but I don't get the open/init
deinit/close separation or why it's needed (Why would you want to open
without initializing?). Haven't given it much thought though. Is the
mentioned followup patch already posted?

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] mips target

2011-05-30 Thread Andreas Fritiofson

On Mon, May 30, 2011 at 7:10 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
 On Mon, May 30, 2011 at 5:47 PM, Mahr, Stefan stefan.m...@sphairon.com 
 wrote:

 lead to the NULL pointer dereference in the time of jtag data scan
 execution (r is a automatic variable, local to the
 mips_ejtag_fastdata_scan() function) ?
 Correction, not NULL pointer, but some trash value pointer from the
 no longer valid stack.

 No, buf_get_u32 fills r[4]. The initial value does not matter.

 No, I meant about r array. this array is a local variable allocated on
 a stack. Where is it referenced again ? Outside of this function ? I
 do not know very well the OpenOCD architecture, I am afraid that this
 reference might be used during jtag data scan execute function and
 that at this moment it will not be valid anymore (although I am
 obviously wrong, since you confirm that it works and you saw no
 sigfaults).


Drasko is probably right here. This will crash and burn. At least
sometimes/somewhere. Getting a segfault or even a consistent failure
is not guaranteed.

However, a more fundamental problem with this code is that it uses the
in_field before the jtag queue is likely to have been executed. Most
of the times it would just set *data to whatever garbage that was on
the stack where r[] got allocated.

The correct way to handle host/target endianness swapping without
forcing a queue execution is to add a callback to the queue. See for
example adi_jtag_dp_scan_u32() in adi_v5_jtag.c.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] segfault in cortex_m3_assert_reset

2011-01-25 Thread Andreas Fritiofson

Mathias:
I built in a fresh out-of-tree directory, and reran bootstrap every
time. See test.sh script. Anyway I found the bug, the patch I posted
solves it for me. Since the stack was corrupted, technically, anything
could have happened. It was just magically consistent during my
bisection.

All:
Finding the bug got me thinking. All this error propagation code that
is all over the place:
retval = jtag_queue_foo(bar); if (retval != ERROR_OK) return retval;

What happens if a queue operation fails and the function returns
without having executed any previously queued reads? Those reads are
often to stack allocated variables that goes out of scope if we
return. Is the queue discarded if there's an error? Otherwise the will
be massive stack corruption when a subsequent operation executes the
queue.

Also, what are the possible failure modes for the queue operations? Is
there any way they can fail other than out-of-memory? Maybe it's not
the best solution to error check every individual queue operation.
Maybe the queue operations should be transactional, so that either all
or none of a set of related operations are added to the queue. Only
the transaction as a whole would need to be error checked.

Regards,
Andreas

On Tue, Jan 25, 2011 at 9:11 AM, Mathias K. kes...@freenet.de wrote:
 Hello,


 i had the same error a while ago. Try to clean your repository (make 
 distclean) and recompile the
 source.


 Regards,

 Mathias

 Am 24.01.2011 23:08, schrieb Andreas Fritiofson:
 Hi all,

 Has anyone else problem with segfaults on current git? As soon as I
 issue a reset, openocd dies. This is with a STM32 target. Same result
 with both rlink and a jtagkey interface. Bisection was successful and
 pointed to commit '8f93c0a3... target: do not expose error numbers to
 users' by Øyvind. Unfortunately, that patch seems very much unrelated.

 I suspect it's a 64-bit issue, because I've traced it to rbx
 (containing a pointer) getting trashed (some of the high 32 bits set)
 during the call to mem_ap_read_atomic_u32 in cortex_m3_assert_reset
 (cortex_m3.c:932), which causes the segfault later when it
 dereferences the pointer.

 My setup is as follows:
 $ uname -srvm
 Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64
 $ gcc -v
 gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

 I attach the git bisect test script that gave the following log:

 git bisect start
 # good: [c24087d33ec75144ec5f579142152d8eb5ce50c9] config: fix
 luminary jtag config
 git bisect good c24087d33ec75144ec5f579142152d8eb5ce50c9
 # bad: [a72741818431d693e48b0f016258be0fec1f79da] stellaris:
 automatically generate and update device IDs
 git bisect bad a72741818431d693e48b0f016258be0fec1f79da
 # good: [56d9ee779d5d744822e5957c98c0d61ce3fc44a9] flash: print flash
 bank name on flash info cmd
 git bisect good 56d9ee779d5d744822e5957c98c0d61ce3fc44a9
 # bad: [d356034f03eb60fd4e8b3537bd979d9e7e5e25f8] svf: implement sleep
 for RUNTEST min_time
 git bisect bad d356034f03eb60fd4e8b3537bd979d9e7e5e25f8
 # bad: [21a1c6ec33f87b6285e47ad6597cd49ad89a9485] NAND/TCL: fix
 segfault on syntax error
 git bisect bad 21a1c6ec33f87b6285e47ad6597cd49ad89a9485
 # bad: [eea91f71f918caa5e4ef571c76f60c579533b0f6] warning: fix warning
 where GCC didn't catch a doubly declared global structure
 git bisect bad eea91f71f918caa5e4ef571c76f60c579533b0f6
 # good: [7cd2617384f4ac620c468343c1f2009fbfa2fc79] initial SWD
 transport (SWD infrastructure #2)
 git bisect good 7cd2617384f4ac620c468343c1f2009fbfa2fc79
 # bad: [4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7] warnings: use more
 'const' for char *
 git bisect bad 4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7
 # bad: [8f93c0a3fe29313945a63b3f2154baef70acd796] target: do not
 expose error numbers to users
 git bisect bad 8f93c0a3fe29313945a63b3f2154baef70acd796



 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development

 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] segfault in cortex_m3_assert_reset

2011-01-24 Thread Andreas Fritiofson

Hi all,

Has anyone else problem with segfaults on current git? As soon as I
issue a reset, openocd dies. This is with a STM32 target. Same result
with both rlink and a jtagkey interface. Bisection was successful and
pointed to commit '8f93c0a3... target: do not expose error numbers to
users' by Øyvind. Unfortunately, that patch seems very much unrelated.

I suspect it's a 64-bit issue, because I've traced it to rbx
(containing a pointer) getting trashed (some of the high 32 bits set)
during the call to mem_ap_read_atomic_u32 in cortex_m3_assert_reset
(cortex_m3.c:932), which causes the segfault later when it
dereferences the pointer.

My setup is as follows:
$ uname -srvm
Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64
$ gcc -v
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

I attach the git bisect test script that gave the following log:

git bisect start
# good: [c24087d33ec75144ec5f579142152d8eb5ce50c9] config: fix
luminary jtag config
git bisect good c24087d33ec75144ec5f579142152d8eb5ce50c9
# bad: [a72741818431d693e48b0f016258be0fec1f79da] stellaris:
automatically generate and update device IDs
git bisect bad a72741818431d693e48b0f016258be0fec1f79da
# good: [56d9ee779d5d744822e5957c98c0d61ce3fc44a9] flash: print flash
bank name on flash info cmd
git bisect good 56d9ee779d5d744822e5957c98c0d61ce3fc44a9
# bad: [d356034f03eb60fd4e8b3537bd979d9e7e5e25f8] svf: implement sleep
for RUNTEST min_time
git bisect bad d356034f03eb60fd4e8b3537bd979d9e7e5e25f8
# bad: [21a1c6ec33f87b6285e47ad6597cd49ad89a9485] NAND/TCL: fix
segfault on syntax error
git bisect bad 21a1c6ec33f87b6285e47ad6597cd49ad89a9485
# bad: [eea91f71f918caa5e4ef571c76f60c579533b0f6] warning: fix warning
where GCC didn't catch a doubly declared global structure
git bisect bad eea91f71f918caa5e4ef571c76f60c579533b0f6
# good: [7cd2617384f4ac620c468343c1f2009fbfa2fc79] initial SWD
transport (SWD infrastructure #2)
git bisect good 7cd2617384f4ac620c468343c1f2009fbfa2fc79
# bad: [4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7] warnings: use more
'const' for char *
git bisect bad 4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7
# bad: [8f93c0a3fe29313945a63b3f2154baef70acd796] target: do not
expose error numbers to users
git bisect bad 8f93c0a3fe29313945a63b3f2154baef70acd796


test.sh
Description: Bourne shell script
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] fix segfault from stack corruption in ahbap_debugport_init

2011-01-24 Thread Andreas Fritiofson

ahbap_debugport_init was queueing reads to a local stack variable but
didn't execute the queue before returning. Since the result of the reads
are not used anyway, it's better to pass NULL as the destination instead of
a dummy variable. I changed this throughout the function, even for the
reads that were actually executed.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/target/arm_adi_v5.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 7df0d4f..7b801b9 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -906,7 +906,6 @@ extern const struct dap_ops jtag_dp_ops;
  */
 int ahbap_debugport_init(struct adiv5_dap *dap)
 {
-   uint32_t dummy;
uint32_t ctrlstat;
int cnt = 0;
int retval;
@@ -931,7 +930,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap)
 
/* DP initialization */
 
-   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy);
+   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL);
if (retval != ERROR_OK)
return retval;
 
@@ -939,7 +938,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap)
if (retval != ERROR_OK)
return retval;
 
-   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy);
+   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL);
if (retval != ERROR_OK)
return retval;
 
@@ -977,7 +976,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap)
alive_sleep(10);
}
 
-   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy);
+   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL);
if (retval != ERROR_OK)
return retval;
/* With debug power on we can activate OVERRUN checking */
@@ -985,7 +984,7 @@ int ahbap_debugport_init(struct adiv5_dap *dap)
retval = dap_queue_dp_write(dap, DP_CTRL_STAT, dap-dp_ctrl_stat);
if (retval != ERROR_OK)
return retval;
-   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, dummy);
+   retval = dap_queue_dp_read(dap, DP_CTRL_STAT, NULL);
if (retval != ERROR_OK)
return retval;
 
-- 
1.7.0.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem loading to CFI flash

2010-12-18 Thread Andreas Fritiofson

On Fri, Dec 17, 2010 at 4:36 PM, Jonathan dumaresq
jdumar...@cimeq.qc.ca wrote:
 Hi all,

 Here my first patches to be able to use the CFI driver on cortex M3 with the
 helper code on target. This is probably not the better way of doing it, but
 at least it's work. This have been tested on real hardware. The default cfg
 that enable the fsmc can be used. Right now only the 16 bit interface has
 been tested. I can add the 8 and 32 bit if the patch is correct.

 From my testing, I got 17KB/sec

 I'll apreciate a feedback for thoses patches. Since this is nearly my first
 git pacthes...

 Regards

 Jonathan Dumaresq

Just drop patch #3 and replace 'b done' with 'bkpt #0' in patch #1
(and the corresponding opcode in patch #2). No need to add a
breakpoint programmatically. Look at the other armv7-m algorithms.

Otherwise it looks good to me, but I'm no expert on the cfi-code.
Maybe the armv4_5_info naming is a bit odd if it now contains
armv7-related stuff, though.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Help needed for SAM3S4C

2010-12-18 Thread Andreas Fritiofson

On Fri, Dec 17, 2010 at 6:27 PM, Kenan Özdemir gla...@hotmail.de wrote:
 Hi,

 i start working with the SAM3S4C, but having trouble with openOCD. When I
 start debugging, the very first instructions are working fine, but after the
 3rd instruction, its jumping acrross the code.

 This is my main.cpp


 int
 main(void) {
    int a, i = 0;
    a = 5;

    for(i = 0; i 10; i++)
   a = a+5;

 }

 the first instructions (int a, i = 0; and a = 5;) are working. At the
 begining when the curser is at int a... the PC is pointing to 400107 (the
 next instruction a = 5).

 When I press step into, the curser goes to a = 5 and the PC is pointing to
 the next instruction (for(i...)), but when i press step into again, it jumps
 into the adress 400d50.


I suspect that you're wrongly assuming that the execution flow follows
line-by-line in source code order. That's not the case for any but
possibly the lowest compiler optimization settings. The compiler will
reorder and remove your statements at will, as long as semantics,
according to the C standard, are unchanged. In your case the entire
loop will be removed since it doesn't DO anything. The jump to 400d50
is probably where your main() returns to. In fact, your main() is
semantically equivalent to
int
main(void)
{
}

It's sometimes very hard to debug strongly optimized code, so you
might want to turn optimization off if you need to step around a lot.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem loading to CFI flash

2010-12-14 Thread Andreas Fritiofson

On Tue, Dec 14, 2010 at 7:26 PM, Jonathan dumaresq
jdumar...@cimeq.qc.ca wrote:
  Hi,

 I have pull the head branch of openocd and now I can write to the cfi at a
 slow speed. I want to modify openocd to use the asm code for the cortex. I
 have used the sample contrib file as starting point for the cortex. I have
 been able to translate (a little effort there) the code. Now the question:

 1- I have modifer the cfi.c to use my new opcodes in the word_16_code array.
 2- I have change armv4_5_info.common_magic for ARMV7M_COMMON_MAGIC

 Up to now, I get to the point that my new code is loaded to ram and
 executed. The problem, is that I always exit of the armv7m_run_algorithm
 with an timeout. The target is never halt. BUT, when I look at the PC I'm at
 the exit point of the code, and the value of R5 is 0x80. So From what I see,
 The flash have been writed correctly. When I double check with mdw
 0x6400 all the data is well written.

 I have no idea why or How the target will be halted. Does any one here can
 point me to the righ direction ?

 I attach the asm file for the spansion 16 bin interface with the cortex m3

 Regards

 Jonathan Dumaresq


IIRC, all armv7-m algorithms must end with a BKPT instruction. That
should probably be documented somewhere. Which sample contrib file are
you talking about?

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32, openocd and eCos

2010-12-13 Thread Andreas Fritiofson

On Mon, Dec 13, 2010 at 10:16 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
 On 13/12/2010 08:47, Manuel Borchers wrote:

 Hi Andreas, hi list,

 On Sun, 2010-12-12 at 21:12 +0100, Andreas Fritiofson wrote:

 It may be that the scheduler or the idle thread puts the core in low
 power mode if no thread is ready to run. That will break the debugger
 connection. See if anything executes a WFI or WFE instruction, and
 disable it. There's likely a configuration setting for it.

 Yes, thanks for hint, I already got a hint on the eCos list about the
 idle thread executing 'wfi'. I suspected something like that but didn't
 find it myself in the sources.
 I also got a hint how to keep the clock for JTAG active when the CPU
 goes to wfi. I'll try that tonight and report back if it didn't solve my
 problem.

 Thanks again!
 Cheers,
 Manuel

 Look for the define HAL_IDLE_THREAD_ACTION in
 packages/hal/cortexm/arch/current/include/hal_arch.h - i comment that out
 while debugging.

 However it does work ok if slow the jtag clock to about 1kHz aswell.

Are you sure? I can't see why that would work. Unless you have a high
frequency interrupt running that happens to match with the jtag
transitions.

Removing WFI/WFE in debug builds, or setting DBGMCU_CR to keep clocks
running solves most cases, anyway.

//Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32, openocd and eCos

2010-12-12 Thread Andreas Fritiofson

On Sun, Dec 12, 2010 at 5:22 PM, Manuel Borchers man...@matronix.de wrote:
Hi all,

I'm a bit lost with a problem concerning OpenOCD, eCos and my STM32
board.

I'm running with a ftdi2232-based usb2jtag adapter. I'm already using
this adapter for quite a long time for my ARM9-based projects, so the
hardware should be fine.

I'm currently porting eCos to a STM32 MINI board, which John announced a
while ago. The port is based on the STM3210E board port.

A simple demo program which prints out some lines on the serial channel
is being flashed into the chip's on-chip flash. When I let the processor
run it directly without debugger, it works fine.

But when I'm stepping through the code and want to step over a
thread-delay routine OpenOCD or the CPU gets somewhat confused and I'm
unable to continue debugging.

That's what I'm doing in gdb (arm-eabi-gdbtui actually):

target remote :
mon reset init
load
b simple_prog
c
b serial.c:99 [the line before the thread delay function]
c
n

And that's what I'm getting in GDB then:
-- snip --
JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 100ms

Program received signal 0, Signal 0.
cyg_thread_delay (delay=0)

at
/home/manuel/Arbeit/netX-ACCOS/netx_accos/trunk/src/ecos/ecos-cvs/packages/kernel/current/src/common/kapi.cxx:292
Current language: auto; currently c++
-- snip --

OpenOCD seems to lose the connection to the target as I get the
following lines repeatedly on the shell:

-- snip --
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 6300ms
-- snip --

The CPU seems to continue running, as I get the output from the program
correctly.

The parameter delay = 0 seems to be bogus, because the function is
called with delay=1000 (which is 10s delay with the default config) from
the application thread.

My openocd config is attached.
I'm running the git version pulled an hour ago, but had no luck with
stable 0.4.0 either before.

I'm quite new to the STM32 / Cortex-M3 familiy, but already did a lot
work on ARM9 before.

I also tried lowering the JTAG speed to 100kHz which did not help. The
thread delay is doing a 10 sec delay, but signal 0 is hit immediately
after stepping.

I tried with a cyg_thread_delay(1) et voila: stepping suddenly works! So
what's goind on here? Has anyone worked with openocd on an STM32?

I'm not sure if the problem lies in openocd or the STM32 eCos port...

I came to the problem because I'm writing and debugging a SPI-Flash
driver (based on the M25Pxx driver) for the on-board flash (SST25VFxxxB)
which uses the cyg_thread_delay function when kernel support is
available. But I reduced it to a simple serial example, which is
delaying between outputting lines...

Any help appreciated.
Regards,
Manuel

It may be that the scheduler or the idle thread puts the core in low
power mode if no thread is ready to run. That will break the debugger
connection. See if anything executes a WFI or WFE instruction, and
disable it. There's likely a configuration setting for it.

//Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Fix for segmentation fault from freed memory access in jtag_unregister_event_callback()

2010-12-10 Thread Andreas Fritiofson

On Fri, Dec 10, 2010 at 4:16 PM, Paul Richards paulr...@gmail.com wrote:
 On 2010/12/10 18:46, Spencer Oliver wrote:

 Not looked into it but why do we not just duplicate the existing
 unregister event/timer functions - or are they broken aswell?


 They (the target versions) don't appear to have the same problem.  The only
 difference I can see is that the jtag_unregister_event_callback() continues
 to look for further events to unregister.  I'm not familiar enough with the
 code to know why that might be possible.  Easy enough to continue iterating
 if it is required.

 Now there's 3 versions to choose from :-)  I would have copied these had I
 known they were there.


It's not too late. The target versions seems nice and readable. And
correct, as far as I can see this late hour. I think the jtag version
should follow the behavior of these and only remove the first matching
handler. That would be the correct thing to do, if there was a point
in having the same handler registered more than once.

The only issue I have with copying the target version is that having
the same code duplicated in three places probably warrants refactoring
it into a helper function instead.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Fix for segmentation fault from freed memory access in jtag_unregister_event_callback()

2010-12-10 Thread Andreas Fritiofson

On Fri, Dec 10, 2010 at 11:39 PM, Peter Stuge pe...@stuge.se wrote:
 Andreas Fritiofson wrote:
  Now there's 3 versions to choose from :-)

 It's not too late. The target versions seems nice and readable. And
 correct, as far as I can see this late hour. I think the jtag version
 should follow the behavior of these and only remove the first matching
 handler. That would be the correct thing to do, if there was a point
 in having the same handler registered more than once.

 Really? How are the callbacks being used?

I don't know. But, generally, if I _can_ register the same handler
twice, I'd expect each registration to require a separate unregister
call. The actual call sites would have to be inspected before changing
this behavior, of course. There shouldn't be many of them, since the
bug has gone unnoticed for so long.

 The only issue I have with copying the target version is that having
 the same code duplicated in three places probably warrants refactoring
 it into a helper function instead.

 Which is difficult for something simple as a linked list, unless the
 list entries are identical, and of the same type. Are they?

Two of them differ only in the callback signature, the third is very different.

There are several imaginable solutions. You could have the list
functions operate on a generic next pointer, included as the first
element of all specialized list types. Or the actual data could be
stored outside the list structure, with just a void pointer in it.
Both require some nasty casts. Neither is likely to be more clear and
concise than the duplicated code. Maybe if it was used in _ten_
places...

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 reset_config

2010-11-11 Thread Andreas Fritiofson

On Wed, Nov 10, 2010 at 11:10 PM, David Brownell davi...@pacbell.net wrote:

  Today I've noticed that resetting the chip
 with OpenOCD does NOT reset
  peripheals (the chip is STM32F103RBT8), which
 IMO is not very good...

 Not all SoCs reset peripherals like that; don't
 assume they do.  Likewise, not all boards.

  - Dave


It's not an assumption, it's in the manual. Do you have an example of
a microcontroller which doesn't reset the bulk of the peripherals on a
NRST or equivalent?

This is somewhat of a regression, since in 0.4.0, the STM32 (and
likely other cortex-m3) peripherals were being reset when a (soft or
hard) reset was issued from OpenOCD. Now they're suddenly not when the
default configs are used.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 reset_config

On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote:
 Hi!

 I've doubts about this commit
 http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5
 Today I've noticed that resetting the chip with OpenOCD does NOT reset
 peripheals (the chip is STM32F103RBT8), which IMO is not very good...

 Do you think this patch should be reverted? Are there any important reasons
 to not have reset_config in stm32.cfg as in many other target cfg files?


I don't think this specific patch is the problem. I've run with
'reset_config none' for a long time without any trouble. Before this
patch there were a bunch of reset issues. Please don't revert it.
Besides, having reset signals wired is optional and a board/adapter
level decision, and should not be specified in the target file.

If the peripherals are not getting reset I suspect some other patch
has sneaked in that changed the soft reset behavior from a real
reset to a core only reset. Perhaps to fix issues with other Cortex-M3
implementations. I haven't run HEAD for a while, but if I find some
time I'll try to confirm and locate the problem.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 reset_config

On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote:
Hi!

I've doubts about this commit
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5
Today I've noticed that resetting the chip with OpenOCD does NOT reset
peripheals (the chip is STM32F103RBT8), which IMO is not very good...

Do you think this patch should be reverted? Are there any important reasons
to not have reset_config in stm32.cfg as in many other target cfg files?

I don't think this specific patch is the problem. I've run with
'reset_config none' for a long time without any trouble. Before this
patch there were a bunch of reset issues. Please don't revert it.
Besides, having reset signals wired is optional and a board/adapter
level decision, and should not be specified in the target file.

If the peripherals are not getting reset I suspect some other patch
has sneaked in that changed the soft reset behavior from a real
reset to a core only reset. Perhaps to fix issues with other Cortex-M3
implementations. I haven't run HEAD for a while, but if I find some
time I'll try to confirm and locate the problem.

Without having tested it, commit 3c69eee9 seems to be the problem.
While it's good that the reset type is now configurable, changing the
default behavior wasn't perhaps the best idea. It would have been
better to keep SYSRESETREQ as the default and change it in the configs
for cores that haven't wired it up to the master reset.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 reset_config

On Wed, Nov 10, 2010 at 10:15 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Spencer Oliver s...@spen-soft.co.uk wrote:
 The default behaviour was changed to make it compatible with all cortex-m3
 cores - will have to check but some stm32 and nxp parts had issues using
 SYSTEMRESET.

I believe STM32 does what it is supposed to, I've never had issues
with it. Code comments mentions some Stellaris parts only. Regardless,
I feel that having a working SYSRESETREQ should be norm, and broken
silicon worked around in the respective config file.

 I think it would be good for openocd to have knowledge of what core can
 handle certain reset modes.

 We have already gone down this path with success on Cortex A8 where
 there is a hack for an iMX51 part for the debug offset.

 This target specific code could either be in OpenOCD or perhaps
 better in the config files?

In this case, one line of tcl overrides the default setting, so it's
perfectly suited for the config files.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] httpd: fix build error with new Jim

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/server/httpd.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/server/httpd.c b/src/server/httpd.c
index af8c3c8..42bba5b 100644
--- a/src/server/httpd.c
+++ b/src/server/httpd.c
@@ -84,7 +84,7 @@ static const char *httpd_exec_cgi_tcl_error(Jim_Interp 
*interp)
t = appendf(t, Runtime error, file \%s\, line %d:br,
interp-errorFileName, interp-errorLine);
t = appendf(t, %s  br, Jim_GetString(interp-result, NULL));
-   Jim_ListLength(interp, interp-stackTrace, len);
+   len = Jim_ListLength(interp, interp-stackTrace);
for (i = 0; i  len; i += 3)
{
Jim_Obj *objPtr;
-- 
1.7.0.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] httpd: fix build error with new Jim

On Wed, Nov 10, 2010 at 11:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 I was actually pondering removing the httpd stuff from OpenOCD
 as we have the tcl server which is a good enough interface. I don't
 think the httpd server was ever used and OpenOCD's role seems
 to be more low level.

 Any thoughts on that?


Fine with me, I'm not really using it. I just have it configured in to
build-test it. Maybe we should just deprecate it in 0.5.0 and remove
it after that, though.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 core debug reset problem

2010-11-04 Thread Andreas Fritiofson

2010/10/31 Michel Catudal michelcatu...@gmail.com:
 Le 2010-10-29 19:15, Andreas Fritiofson a écrit :

 One can also ponder why you need debug access to something molded in
 plastic... Wouldn't it be better to debug your application on a more
 lab-friendly setup?



 A production unit that is to be protected from the environment must be
 molded into something.
 We would never use plastic in most application but the end result would be
 the same.
 I do agree that molded in plastic is strange but what difference would it
 make as for software is concerned?

It's not the plastic mold that's strange, it's the desire to _debug_
software on a production unit, permanently sealed or not. Debugging is
software development, which is more comfortably done on a lab unit
which can be probed and measured (and, in the best of worlds,
preferably _before_ production even starts).

 Most designs nowadays require reflashing at one time or another. Most of us
 in the industry no long use mask rom.
 Why do you think that we would want simulated mask rom?

I didn't say that. You're talking about in-system programming, not
debugging. ISP (or reflashing) is often possible over the debug
access port, but it's not always the only option and seldom the most
practical one. A better alternative, especially for a sealed product,
is to use a preprogrammed boot loader operating over some other
communication channel present in the product. I'm guessing that would
have been Chris' first choice, had this particular boot loader of his
not been broken.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 core debug reset problem

2010-11-04 Thread Andreas Fritiofson

On Wed, Nov 3, 2010 at 10:01 AM, Chris Jones ch...@martin-jones.com wrote:

 I tried the IAR software but don't have a JTAG dongle directly compatible
 with it. I tried to get it to talk to OpenOCD via GDB but attempting to
 download the code to the STM32 that way just resulted in streams of errors.
 I didn't spend any more time on this because I don't think it would help to
 isolate the issue into or out of OpenOCD.

 There seem to be some circumstances in which attempting to start OpenOCD
 connected to an STM32 in stop mode, or switching rapidly into and out of
 stop mode, breaks the STM32's debug unit. It's consistently repeatable. For
 now we can work around it by being extremely careful when we try to connect
 OpenOCD, but I'd like to try and help prevent the problem.

I agree with Michel that the first step towards that is probably to
determine whether the problem has a reasonable chance of being fixable
in OpenOCD. Otherwise it's a waste of time trying to. We could try
completely different tools to see if they have the same problem. We
can also ask ST (having tried different tools would help here, too).
Maybe someone on the list has the tools and the time required.
Unfortunately, I have neither right now.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Stm32 load elf file with gdb

2010-11-04 Thread Andreas Fritiofson

On Thu, Nov 4, 2010 at 2:46 PM, Jonathan dumaresq jdumar...@cimeq.qc.ca wrote:
 Hi all,

 I try to get my stm32 environnement working with gdb. I'm unable to get my
 elf file loaded with gdb. Here my setup:

 Openocd.cfg
 /
 source [find interface/olimex-arm-usb-ocd.cfg]
 source [find target/stm32.cfg]

 stm32.cpu configure -event gdb-flash-write-end {
        reset init
 }

 stm32.cpu configure -event gdb-flash-erase-start {
        reset init
 }
 ///

 All include file are default.

 Here how i lunch gdb

 Arm-none-eabi-gdb rtosdemo.elf


 (gdb)target remote | openocd --pipe
 (gdb)load rtosdemo.elf
 (gdb) load
 Loading section .text, size 0xa7d8 lma 0x0
 Debug: 408 139609 gdb_server.c:2145 gdb_input_inner(): received packet:
 'X0,3fb0
 :binary-data'
 Debug: 409 139609 gdb_server.c:1388 gdb_write_memory_binary_packet(): addr:
 0x00
 00, len: 0x3fb0
 Debug: 410 139609 target.c:1251 target_write_buffer(): writing buffer of
 16304 b
 yte at 0x

0x is most certainly the wrong place to be writing stuff...

 Warn : 419 139828 arm_adi_v5.c:720 mem_ap_write_buf_u32(): Block write error
 add
 ress 0x0, wcount 0xfec
 Error: 420 139828 gdb_server.c:1211 gdb_error(): unexpected error -107
 Load failed
 (gdb)

 I have to admit that i'm a little bit lost there. Do i have something else
 to do to get this work ?

Yes, you need to fix your broken linker script (in case of GNU ld) to
place your code in flash, which is located at 0x0800, not 0x0.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 core debug reset problem

2010-10-29 Thread Andreas Fritiofson

On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones ch...@martin-jones.com wrote:
 Hi all,

 I'm using OpenOCD (version 0.4.0, downloaded from SourceForge and built
 about half an hour ago) on Debian Lenny (5.0, stable) running under VMWare
 Fusion on an x86 Mac Pro. The microcontroller I'm using is an STM32F103C6T6,
 and the JTAG dongle is an Amontec JTAGKey. By and large it works: I can
 program the flash, halt, use gdb, all the things I'd expect from OpenOCD.

 But there's a way of breaking it semi-permanently. The application on the
 STM32 is one which spends most of its time with the CPU in Stop mode, waking
 up periodically (about every 12ms) via an RTC interrupt to do some
 processing. If I attempt to start OpenOCD while the microcontroller is
 stopping and running like this, I get messages which say,

 Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction

 and OpenOCD just won't work, though it finds the TAPs correctly so the JTAG
 hardware is clearly working to some extent.

 The whole JTAG system appears to be then stuck in this state. Restarting
 OpenOCD, doing a hardware system reset on the microcontroller, unplugging
 everything including the JTAG dongle and its USB interface, all make no
 difference. I've even tried exercising the JTAG port using another
 application (XJTAG) though this only does boundary scan testing and doesn't
 play with the ARM debug TAP. Though boundary scan works fine.

 The only thing which fixes the problem is power-cycling the STM32 chip
 itself. I note from its documentation and the ARM Cortex-M3 TRM that some
 parts of the core debug unit are only reset at power up, not in response to
 a system reset. The device has no TRST pin.

 However, this board is going to be permanently moulded into a plastic lump
 with a battery, so power cycling it is *not* an option.

 Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is
 wedged, if that's the case, and tickling it back to life?

The debug unit is clocked by the core clock. So, naturally, when you
stop the core clock you'll lose all debug access. There's nothing
OpenOCD can do about it. As Kyle said, you can flip some bits in
DBGMCU_CR to keep the debug unit clocked even in sleep modes. That
will enable you to debug but of course it will also drain your
battery.

One can also ponder why you need debug access to something molded in
plastic... Wouldn't it be better to debug your application on a more
lab-friendly setup?

//Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)

2010-10-28 Thread Andreas Fritiofson

On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin freddie_cho...@op.pl wrote:
 Hi!

 Someone has asked me for help with using OpenOCD + STM32F100 (8kB of RAM).
 After some time I've come to conclusion that the problem was caused by
 incorrect workareasize value, which in stm32.cfg is defined to be 16kB. With
 std cfg files flashing the device resulted in:

 Error: JTAG-DP STICKY ERROR
 Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004
 Error: JTAG-DP STICKY ERROR
 Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004
 Warn : Block write error address 0x20002000, wcount 0xc

 The flashing actually works, but is extremely slow (rate  200B/s). Changing
 the workareasize to 2kB helps - everything works normally then.

We should probably change it to the least common denominator within
the family, which is 8kB (maybe even 6?). Definitely, if you don't see
any significant reduction in flashing speed after reducing the
workareasize (8kB vs 2kB). That's likely dependent on the adapter in
use, of course.

 However, I've always thought that OpenOCD somehow finds the amount of RAM
 that is available on the chip and will not allocate more than is possible?
 Am I wrong?

Yes. Early silicon had a SRAM size register in factory programmed ROM
but it was later removed for some reason. I don't think OpenOCD used
it even when it existed. We could probably determine the size
indirectly, maybe from a chip id database, but I think it's just as
good to simply provide a minimum safe workareasize and let the user
override it if he wishes.

//Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Eclipse Helios GDB settings (was: STM32 flashwrite speed)

2010-10-19 Thread Andreas Fritiofson

On Mon, Oct 18, 2010 at 9:30 PM, Bernard Mentink
bernard.ment...@trimble.co.nz wrote:



 On 2010-10-18 20:54, Bernard Mentink wrote:
 Well I have tried that, but I get this error from the GDB
 (DSF)Hardware debugger plugin for Eclipse:

 You need to select Standard GDB Hardware Debugging Launcher and
 instead of load command - use the available options below Load Image
 and Symbols - for flashing select both checkboxes, for debugging of
 previously flashed image select Symbols only.

 
 Hmm, I have tried that and can indeed use the load command with the
 Standard GDB debugger, but I don't like that debugger as mach as the DSF
 version.
 I also have to use custom commands to get the init sequence I want, the
 tick box options don't give me what I need.

I have got decent results in Helios using the GDB (DSF) Hardware
Debugging Launcher with the following, pretty straight-forward,
configuration.

Main tab:
Select project and binary as usual

Debugger tab:
GDB Command: arm-none-eabi-gdb
Check Use remote target
JTAG Device: OpenOCD (via pipe)
(GDB Connection String: | openocd --pipe)

Startup tab:
Uncheck Reset and delay... and Halt
Check Load image, use project binary
Check Load symbols, use project binary
Check Set breakpoint at: main
Check Resume
No run or init commands specified

In the project root, create a file openocd.cfg:
---
source interface.cfg
source [find target/stm32.cfg]
source [find chip/st/stm32/stm32.tcl]

stm32.cpu configure -event gdb-flash-write-end {
reset init
}

stm32.cpu configure -event gdb-flash-erase-start {
reset init
}
---
interface.cfg is an unversioned file sourcing my adapter config file
(interface/jtagkey.cfg in my case).

Does this work for you as well? Of course you need to change the
stm32-specifics if you have the LPC part. Oh, by the way, this is on
Linux. Also I'd like to work out how to attach to a running target
nicely without specifying init commands manually. Unchecking Load and
setting the init commands to mon gdb_sync and stepi probably does
it but I'd rather not need to have to have any commands in the launch
file.

 All, in all, I get the same speed with the GDB load command or the
 target flash command .. I guess it maybe a limitation of the FT2232D
 based JTAG
 module I am using ... It would be good if someone else can confirm that
 with the same hardware.

Both speeds should be more or less identical.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Eclipse Helios GDB settings (was: STM32flashwrite speed)

2010-10-19 Thread Andreas Fritiofson

On Tue, Oct 19, 2010 at 11:28 PM, Bernard Mentink
bernard.ment...@trimble.co.nz wrote:

 Hi again Andreas,

 An update to this: The error below was because I had several instances
 of gdb running, they were not closed off correctly in eclipse.

Hm, yeah I've seen that too sometimes. Perhaps more often or with
different error messages when running with the --pipe option.

 Now when I run it, the program downloades and I get to main correctly

 However, when I hit continue, I end up in the g_pfnVectors() at 0x00,
 and I can not continue ..

 Also, in the Console window, I get this error:
 lpc1766.cpu -- clearing lockup after double fault

 I am way out of my depth here .. I don't have this issue when I run my
 init script as described earlier ... Instead of this method.

This is indicative of an actual bug in your code. I can't explain why
it only shows with my method. If you can get to main you should be
able to step instead of continue. Does that work? Can you step forward
until you hit the place where it crashes?

The clearing lockup after double fault says that the core was in a
lockup state which means a fault occurred (bad memory access, invalid
instruction and such, probably due to a software bug) and, in
addition, there was an error while fetching or executing the exception
vector (no fault handler installed?). Common bugs that can cause this
is invalid pointer dereferencing, buffer overflows or enabled
interrupts for which no handler is installed.

//Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 flash write speed

2010-10-18 Thread Andreas Fritiofson

On Mon, Oct 18, 2010 at 7:15 PM, Freddie Chopin freddie_cho...@op.pl wrote:
 Hi!

 When I flash some big image (~128kB) on STM32 without any tricks:
 reset halt
 stm32x mass_erase
 flash write_image c:\\stm32.hex
 I achieve speeds of 12kB. JTAG frequency is 1MHz.

 When I use my reset init script which sets the flash latency to 2 cycles,
 starts the PLL with internal RC oscillator (final chip frequency 64MHz) and
 sets JTAG frequency to 6MHz I achieve speeds of... 13.5kB/s...

 I've verified that this script works fine (the values in registers are
 fine), so why there is almost none increase in the loading speed?

 This test was caused by curiosity which started after reading one forum post
 in which someone describes that in CrossWorks when using the same JTAG he
 achieved almost 150kB/s, over 14x faster than OpenOCD.

Well, that's BS. The STM32 flash has a nominal programming time of
52.5µs per 16 bits. So the theoretical max speed anyone can achieve is
roughly 37.2 KiBytes/s. If you see claims of speeds way above that
they're either lies, load-to-ram figures or a mixup in units.

That said, I think it should be possible to crank up the STM32 flash
programming speed in OpenOCD by at least a factor of two. I don't know
what the bottleneck is, but like you I have concluded that JTAG
frequency is not the major issue here. My guess is that the
programming algorithm we use might be quite inefficient. USB latency
might play a role but with double buffering and other tricks in the
algorithm the latency shouldn't be a limiting factor.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Is this STM32F100x errata sheet discovery the cause of my problems?

2010-10-04 Thread Andreas Fritiofson

On Mon, Oct 4, 2010 at 6:36 PM,  n...@bike-nomad.com wrote:
 I've been trying to use OpenOCD with the STM32F100C4T6B, one of the new low 
 density value line processors from STMicroelectronics.

 I haven't had too much success using it (not stopping at breakpoints, not 
 noticing when it has stopped at breakpoints, not working well with gdb, not 
 stepping once at a breakpoint, etc.) and I was thinking that this information 
 from the errata sheet might have something to do with my problems.

 Could anyone tell me whether this silicon bug will affect OpenOCD, and, if 
 so, how?

 2.5     Boundary scan TAP: wrong pattern sent out after the “capture IR” state

The errata mentions the boundary scan TAP only. It's not likely that
the core debug TAP is affected. But I have not read the whole errata
sheet.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Message script openocd 0.4.0 windows for In Board flash programming.

2010-09-16 Thread Andreas Fritiofson

 flash write_binary 0 BootLoader_108.bin 0x0 0: command requires more
 arguments

There is no command with the name 'flash write_binary'. Perhaps you
mean 'flash write_bank'? In that case, the extra zero on the end
shouldn't be there. The error message is nonsense.

 help flash write_bank
  flash write_bank bank_id filename offset
Write binary data from file to flash bank, starting at specified
byte offset from the beginning of the bank.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000

2010-09-04 Thread Andreas Fritiofson

On Sat, Sep 4, 2010 at 2:57 PM, Peter Stuge pe...@stuge.se wrote:
 Øyvind Harboe wrote:
 Perhaps this is a thing that *should* be a bit hard?

 Perhaps embedded users *should* learn about the load offset for
 GDB?

 Do you know if gdb always sends an offset in the (binary?) command to
 OpenOCD? If yes, I think gdb should be changed to make 'load' easier
 to use.

This is not a problem with gdb. When gdb is asked to load an image it
simply writes all relevant sections in that image to their respective
memory locations. If it has knowledge that the location to be written
resides in flash, it uses the vFlash* commands, otherwise it uses
regular memory writes. If the section addresses does not match the
actual memory layout of the target, there's nothing gdb can do about
it. Yes, you can fix the error by telling gdb to load the image with
an offset. That won't change the fact that the image is not linked
correctly and gdb can hardly be blamed for providing the possibility
of a workaround.

Nor is it an OpenOCD problem. We just provide the knowledge to gdb
about the memory layout of the target and then receive the memory
writes. We can't guess the user's intentions and try to remap the
writes behind gdb's (and the user's) back.

 Can OpenOCD return a (textual?) error message? If yes, then OpenOCD
 could return a very informative error in case someone tries to load
 to an address not backed by flash.

We can't really tell the (non-flash) loads from other memory writes
and we don't want to see errors on every write to peripheral or sram
addresses. Even if we could we wouldn't want to print an error,
because there is no error. And what would the message look like?

It seems you're trying to load an image to a memory location not
commonly used for loading to. Maybe you're using a broken linker
script. Do you want me to try to fix the script for you?

That would be neat. Why not take it a step further?

I notice you try to load an image that has been compiled for another
architecture than the one you're working on. Do you want me to install
the correct cross compiler and recompile it for you?

Based on your recent usage pattern I've come to the conclusion that
you're getting desperate to find that nasty bug you introduced two
weeks ago, before your deadline tomorrow morning. It's really late, so
why don't you go home and get some sleep and I'll fix the bug for
you.

It looks like you're writing a letter. Would you like help? Aaargh!
Ok maybe not such a great idea.

Ok I got a little carried away there, sorry :). But my point is: We
shouldn't remove the incentive for users to fix their tools or read up
on the docs by reducing the impact of their errors or making it easier
to work around them.

 But ideally this knowledge should be up in gdb too, so that gdb, or
 whatever tool is controlling it, can provide more information and
 faster response to the user.

OpenOCD already gives gdb full knowledge of the target's memory layout
(at least what is and isn't flash).

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000

2010-09-04 Thread Andreas Fritiofson

On Sat, Sep 4, 2010 at 7:31 PM, Peter Stuge pe...@stuge.se wrote:
 Andreas Fritiofson wrote:
 When gdb is asked to load an image it simply writes all relevant
 sections in that image to their respective memory locations. If it
 has knowledge that the location to be written resides in flash, it
 uses the vFlash* commands, otherwise it uses regular memory writes.

 Thanks! Sorry I'm a bit of a gdb noob. I've never used it in-depth in
 spite of using it a little, over lots of years.


 If the section addresses does not match the actual memory layout of
 the target, there's nothing gdb can do about it.

 I disagree; gdb can certainly discover this and do something more
 useful (error message, whatever) than trying to send stuff to OpenOCD
 *even though* it can not work.

GDB cannot know that it cannot work. The user has, and must have, the
power here. If the user tells gdb to load some data to address 0, gdb
must try its best to do so, using the information provided (directly
or indirectly) by the user to determine _how_ to do it. I know I would
hate if gdb tried to outsmart me by disallowing a load of a
not-quite-standard configuration just because it doesn't work in other
cases.

 Yes, you can fix the error by telling gdb to load the image with
 an offset.

 What happens then, exactly? Does gdb relocate all sections or does it
 just send a single offset parameter to OpenOCD?

I really don't know since I've never used the offset. It's probably
mainly useful when you load a binary file without location information
encoded in the file. When you load an elf-file, all information gdb
needs is already available from the file. Under normal circumstances,
load is a fire-and-forget command, it just does the right thing. Very
usable.

 That won't change the fact that the image is not linked correctly

 Agreed.


 and gdb can hardly be blamed for providing the possibility of a
 workaround.

 If anything I'm blaming gdb for not being smarter about when to
 automatically add the workaround - or at the *very least* providing
 relevant and useful error messages.

THE workaround you're talking about is not some universal fix for
problems related to linking. It may help in some very specific
situation with some link script that's broken in a very specific way.
It can never be made automatic. Consider if my target actually HAS
some memory at address zero that I want to load and gdb has been
patched as a result of this discussion to automatically add 0x800
to the load address if it equals zero. It would break my system. Can
you find another method of altering gdb that would resolve this issue
while not breaking any conceivable valid configuration and not
producing nonsense error messages?

 Nor is it an OpenOCD problem.
 ..
 We can't guess the user's intentions

 And we shouldn't.


 We can't really tell the (non-flash) loads from other memory writes
 and we don't want to see errors on every write to peripheral or sram
 addresses. Even if we could we wouldn't want to print an error,
 because there is no error.

 There is not enough information for OpenOCD to accurately determine
 if it is an error or not. Remember that is very different from there
 is no error. Even in gdb there may not be enough information, since
 the load command is so generic.


 It seems you're trying to load an image to a memory location not
 commonly used for loading to. Maybe you're using a broken linker
 script.

 A message similar to this would be a significant and real improvement
 if it could be generated with zero false positives.

It cannot.

 Do you want me to try to fix the script for you?

 Silly. At most, whoever is generating the error (gdb IMO) could at
 this point list known memory areas.


 That would be neat. Why not take it a step further?
 ..
 We shouldn't remove the incentive for users to fix their tools or
 read up on the docs by reducing the impact of their errors or
 making it easier to work around them.

 Let me make another point, which I think is partially parallell
 partially orthogonal:

 There should be adequate error messages for all error cases. All
 error cases must be detected without heuristics and without
 ambiguity.

A bit too ambitious goal, don't you think, especially when you
consider errors that are not errors in the realm of gdb, but outside
of it. It's like a blender that would refuse to mix ingredients that
are not normally used together.

  But ideally this knowledge should be up in gdb too,

 OpenOCD already gives gdb full knowledge of the target's memory
 layout (at least what is and isn't flash).

 Good stuff. The problem is all in gdb then.

No, the problem is still in the faulty linker script/build system
shipped by Olimex(?). Use a Blinky LED example from another source and
the issue is gone.

 Freddie Chopin wrote:
 Both OpenOCD and GDB work perfectly well with correct files
 (standard OpenOCD .cfgs, correctly linked .elf file) so I really
 don't see any problem you're trying to fix...

 Usability

Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000

2010-09-03 Thread Andreas Fritiofson

On Fri, Sep 3, 2010 at 9:29 PM, John Hartman (NoICE)
j...@noicedebugger.com wrote:
 The STM32 parts have Flash beginning at 0x800, and OpenOCD's stm32x.c
 places the Flash there regardless of the address used in the flash command
 in the cfg file.

 The chips have two pins that can be jumpered to specify what appears at
 address 0: Flash, RAM, or the boot loader.  For embedded work, I think
 Flash will be the most common case.

 But if I link my program at zero, it is a pain to burn my program, because
 OpenOCD tells gdb there is only RAM at 0, with Flash at 800.

 One solution is to re-link my program to 800, and rely on aliasing of
 the vector table to 0.  This works, but is a little annoying.

Annoying how? The flash IS at 0x0800. Why would you want to link
your program to 0? That if anything would be relying on the aliasing.
Of course it works, otherwise the chip couldn't start, but does it
alias the entire flash and not just enough to cover the vectors? Two
years ago, the ST folks I asked didn't know the answer to that.
Perhaps it's clarified in the docs today.

 I would like to propose the following changes to allow Flash at zero:


 1) In the file flash/stm32x.c, function stm32x_probe, remove or comment out
 the explicit setting of bank-base:
        // Don't fill in the base: get it from the cfg file
 //      bank-base = 0x0800;
        bank-size = (num_pages * page_size);
        (etc.)

 2) In the stm32.cfg, change
        flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
 to
        flash bank $_FLASHNAME.1 stm32x 0x 0 0 0 $_TARGETNAME
        flash bank $_FLASHNAME.2 stm32x 0x0800 0 0 0 $_TARGETNAME

 This claims that there are TWO Flash banks, one at 0 and one at 800.  By
 having two banks, users can locate their code at either location, as they
 prefer, without needing to modify the cfg file.

 Note that this would break existing cfg files, moving the Flash from 800
 to 0.  This could be remedied by using a non-zero value for one of the other
 parameters (bus width etc) to mean new style, and only using the specified
 base address in that case.  (Or more formally, one might add a new
 algorithm instead of stm32x that does this)

 What do people think?

Breaking existing config files and/or adding confusing nonexistent
banks for no apparent benefit? I don't like it.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Error while debugging PXA271

2010-09-01 Thread Andreas Fritiofson

On Wed, Sep 1, 2010 at 10:17 AM, Nived nive...@gmail.com wrote:
 Hi,
 We have been trying to debug a .Net Microframework Port onto an IntelMote2
 device running a PXA271 processor using openocd-ftd2xx.exe( Version: Open
 On-Chip Debugger 1.0 (2008-10-04-10:00)).
 I am able to step through the code well, but a strange error keeps popping
 at the most undesirable of times.
 Failed to receiving data from debug handler after 1000 attempts
 time out writing RX register
 time out writing RX register
 Remote connection closed
 Any idea why this may be happening ?

No, but I'm guessing that using an ancient OpenOCD version doesn't
help. I have no idea how much attention the PXA271 target has gotten
recently but quite a lot could have happened over the last two years.
Try with a recent build and see if it works better.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] debug: debug entry error propagation

2010-07-19 Thread Andreas Fritiofson

Considering the huge number of identical if (retval != ERROR_OK)
return retval; added in this and your other patches, maybe we should
reuse the CHECK_RETVAL macro from arm11.h as a general mechanism to
reduce the clutter? It may not be the best of practices to return from
a macro, but rules are made to be broken, right?

--
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] arm-jtag-ew: -Wshadow fix

2010-06-19 Thread Andreas Fritiofson

declaration of ‘index’ shadows a global declaration
in /usr/include/string.h

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
I'm not convinced of the benefit of the warning in this case. A whole bunch
of other warnings or error would catch the bug if the local variable index
had been used in place of the system header declared _function_ index. I had
expected the warning to be emitted only for shadowing of compatible types.
---
 src/jtag/drivers/arm-jtag-ew.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/jtag/drivers/arm-jtag-ew.c b/src/jtag/drivers/arm-jtag-ew.c
index 7a6c178..72c756e 100644
--- a/src/jtag/drivers/arm-jtag-ew.c
+++ b/src/jtag/drivers/arm-jtag-ew.c
@@ -568,29 +568,29 @@ static void armjtagew_tap_ensure_space(int scans, int 
bits)
 static void armjtagew_tap_append_step(int tms, int tdi)
 {
last_tms = tms;
-   int index = tap_length / 8;
+   int index_local = tap_length / 8;
 
-   if (index  ARMJTAGEW_TAP_BUFFER_SIZE)
+   if (index_local  ARMJTAGEW_TAP_BUFFER_SIZE)
{
int bit_index = tap_length % 8;
uint8_t bit = 1  bit_index;
 
if (tms)
{
-   tms_buffer[index] |= bit;
+   tms_buffer[index_local] |= bit;
}
else
{
-   tms_buffer[index] = ~bit;
+   tms_buffer[index_local] = ~bit;
}
 
if (tdi)
{
-   tdi_buffer[index] |= bit;
+   tdi_buffer[index_local] |= bit;
}
else
{
-   tdi_buffer[index] = ~bit;
+   tdi_buffer[index_local] = ~bit;
}
 
tap_length++;
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] don't print Jim stacktrace

2010-06-17 Thread Andreas Fritiofson

On Thu, Jun 17, 2010 at 7:24 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 On Thu, Jun 17, 2010 at 2:05 AM, Andreas Fritiofson
 andreas.fritiof...@gmail.com wrote:
 On Thu, Jun 17, 2010 at 12:30 AM, Øyvind Harboe oyvind.har...@zylin.com 
 wrote:
 On Wed, Jun 16, 2010 at 11:40 PM, Andreas Fritiofson
 andreas.fritiof...@gmail.com wrote:

 The stack trace provides no valuable information to the user for
 interactive commands.

 What about nested proc's?


 You mean when calling user defined tcl procedures calling other tcl
 procedures that fails?

 My guess is the *user* doesn't particularly care about the chain of
 events leading up to the fault. It's probably due to either misuse of
 the first procedure, in which case the user is fully aware of what the
 called procedure was, or a bug in one of the following. If it's a bug
 it calls for debugging, a job for a *developer* (might of course be
 the same person with another hat). The developer could flip the debug
 level switch and see the stack trace as previously.

 Then on the other hand I don't get a stack trace when a shell script
 in multiple nesting levels fails, and I'm not very bothered about
 that.

 I think the current error messages do more harm than good in the
 majority of cases. If there's a better solution I'm open to
 suggestions.

 I agree that the current error messages are ugly, but I don't
 agree that we should not print file and line # of e.g. syntax
 error.

The problem is that the file and line# printed is the same for all
syntax errors and failed builtins and has no relevance to the actual
error. A useful trace is only produced when a nested tcl procedure
fails on a lower level. I haven't actually noticed that feature before
but now when I've played around with it a bit I agree that we want to
keep it.

 However, we may be able to address this in a more fine
 grained fashion than simply turning the stack traces on
 and off.

 Perhaps you could post some examples and show what
 parts of the stack trace that is useful and what's just (debug)
 noise?

For example, misspelling a subcommand:

 flash prob 0
flash prob 0: command requires more arguments -- 1)
in procedure 'flash' called at file command.c, line 654 -- 2)
called at file command.c, line 365 -- 3)

1) This is nonsense, but not really related to the stack trace.
2) I didn't call the flash command from command.c, i called it from an
interactive telnet session. Nothing flash related can be found at line
654.
3) Same as 2, but worse. What was called at line 365??

In short, there's no useful part of this stack trace.

A more interesting example, a nested command that fails:

$ openocd -f bitsbytes.tcl -c normalize_bitfield 1 2 q
...
Runtime error, file bitsbytes.tcl, line 31: -- 4)
Syntax error in expression
in procedure 'normalize_bitfield' called at file command.c, line 654 -- 5)
in procedure 'extract_bitfield' called at file bitsbytes.tcl, line 50 -- 6)
in procedure 'create_mask' called at file bitsbytes.tcl, line 39

This is where I start to see the point of the stack trace. However,
it's not correct.

4) there's no normalize_bitfield at line 31 as it's suggested.
5) same problem as 2, I called it from the command line.
6) extract_bitfield is really called at line 50, but NOT in procedure
create_mask. Line 50 is in normalize_bitfield.

It struck me that the stack trace would make much more sense if it was
written in the reverse order! Let's see:

Runtime error, file bitsbytes.tcl, line 31:
Syntax error in expression
in procedure 'create_mask' called at file bitsbytes.tcl, line 39
in procedure 'extract_bitfield' called at file bitsbytes.tcl, line 50
in procedure 'normalize_bitfield' called at file command.c, line 654

Apart from the command.c reference this looks quite alright!

I attach two patches. One to remove the command.c references and one
to rearrange the stack trace output. Any takers?

/Andreas
From 9ebd0e62a8112ec227d11f0633fc7a897217b8b8 Mon Sep 17 00:00:00 2001
From: Andreas Fritiofson andreas.fritiof...@gmail.com
Date: Fri, 18 Jun 2010 00:48:47 +0200
Subject: [PATCH 1/2] don't add confusing source info to Jim

When an interactive command fails, the Jim stack trace prints references to
the line in command.c where the interpreter was invoked. Since that
location has no relation to the actual command that failed, the information
serves only to add confusion.

By not adding the useless source info to Jim the noise can be reduced,
while still printing a useful trace for nested commands.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/command.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/helper/command.c b/src/helper/command.c
index be262f2..ea768b2 100644
--- a/src/helper/command.c
+++ b/src/helper/command.c
@@ -362,7 +362,7 @@ static int register_command_handler(struct command_context *cmd_ctx,
 	if (NULL == override_name)
 		return JIM_ERR;
 
-	retval = Jim_Eval_Named(interp, override_name

Re: [Openocd-development] [PATCH] don't print Jim stacktrace

2010-06-16 Thread Andreas Fritiofson

On Thu, Jun 17, 2010 at 12:30 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 On Wed, Jun 16, 2010 at 11:40 PM, Andreas Fritiofson
 andreas.fritiof...@gmail.com wrote:

 The stack trace provides no valuable information to the user for
 interactive commands.

 What about nested proc's?


You mean when calling user defined tcl procedures calling other tcl
procedures that fails?

My guess is the *user* doesn't particularly care about the chain of
events leading up to the fault. It's probably due to either misuse of
the first procedure, in which case the user is fully aware of what the
called procedure was, or a bug in one of the following. If it's a bug
it calls for debugging, a job for a *developer* (might of course be
the same person with another hat). The developer could flip the debug
level switch and see the stack trace as previously.

Then on the other hand I don't get a stack trace when a shell script
in multiple nesting levels fails, and I'm not very bothered about
that.

I think the current error messages do more harm than good in the
majority of cases. If there's a better solution I'm open to
suggestions.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] -Wshadow fixes

2010-06-15 Thread Andreas Fritiofson

On Tue, Jun 15, 2010 at 11:13 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 As you have noticed I'm pushing a number of -Wshadow
 warning fixes.

 Most of these should be trivial, but there is of course a
 chance that I screw this up as I have only done compile
 tests for most.

 This is a bit roughshod way of cleaning up the -Wshadow
 fixes, but I've also fixed *real* bugs along the way here
 and I need -Wshadow to be enabled by default and get
 testing done by the community on this one.

 Obviously not the way to do things when release is close.


A backup file sneaked in: src/helper/#jim.c#
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR

2010-06-07 Thread Andreas Fritiofson

On Mon, Jun 7, 2010 at 5:21 PM, Kenan Özdemir gla...@hotmail.de wrote:

 I figured out, that the SIGINT signal was caused by an string function.

 There is a memset in the tskTCB *prvAllocateTCBAndStack(...) function in
 task.c and if I comment it the problem is solved..
 till the next SIGINT is caused by strncpy in void
 prvInitialiseTCBVariables(...) also in task.c

 It looks like that there is something missing in my configurations.. :) but
 what?!


User : 823 58626 armv7m.c:489 armv7m_arch_state(): target halted due
to debug-request, current mode: Thread

xPSR:  pc: 0x2040 msp: 0x08002e90

This looks really wrong just after a reset. Executing from RAM with
stack pointer in flash... Check your vector table. It should have the
stack pointer in the first slot (0x0800) and the reset vector in
the second (0x0804).

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR

2010-06-01 Thread Andreas Fritiofson

On Tue, Jun 1, 2010 at 5:01 PM, Kenan Özdemir gla...@hotmail.de wrote:
 This is only a part of the logfile.. I got more error messages like that,
 and each time I got also a SIGINT signal while debugging..
 So how would you recommend me to solve that problem? Is it maybe the linker
 script where I have to do some changes?
 Thx for your help


Start by fixing your gdbinit oddities. Then post the complete log
file, from a minimal debug session to reduce the noise, together
with a more detailed description of actual behavior.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] stm32 : improve unlock procedure for mass_erase

2010-06-01 Thread Andreas Fritiofson

On Tue, Jun 1, 2010 at 1:56 PM, gcembed gcem...@gmail.com wrote:
 Hello,
 I have added a new command for stm32x : mass_erase_unlock
 This function combine stm32x unlock 0 + reset to apply unlock + stm32x
 mass_erase 0
 In this way, it is more easier to handle the unlock sequence and makes the
 (annoying) reset procedure transparent.
 After calling mass_erase_unlock, flash write_image can immediately  called.
 Here is an example of my flashing procedure :

 init
 jtag_khz 1000
 reset_config trst_and_srst
 halt
 flash probe 0
 flash protect 0 0 last off
 stm32x mass_erase_unlock 0
 flash write_bank 0 file.bin 0
 flash protect 0 0 last on
 verify_image file.bin 0

 Thanks
 Gaëtan

I like the idea, it would be very convenient to have a single command
to always put the chip in a well defined, cleared state. Perfect for
programming scripts, which today need to assume that the flash is
locked. However...

If the flash is locked, the unlock procedure will perform a mass
erase, so the second mass erase will just waste time and flash erase
cycles. Plus, the SP and PC could have different values after the
procedure depending on whether the protection was active or not (see
the test I posted yesterday). I would prefer something like the
following pseudo code to get a consistent state with minimum number of
operations.

read option byte;
if (readout protection active)
   unlock;
else
   mass_erase;
reset;

Then one starts to think why we need this new command in addition to
the separate unlock and mass_erase commands. Unlock already implies
mass_erase. And is there ever a reason to (try to) do a mass_erase on
a locked flash without wanting to unlock it? Or to mass_erase or
unlock without resetting the core afterwards (how about when running
from ram?). The operations seem to go hand in hand. Maybe we only need
one command to do it all.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR

2010-05-31 Thread Andreas Fritiofson

On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir gla...@hotmail.de wrote:
 Hi Guys,

 I have the following problem..

 Each time I try to Debug I got this Error Message it is out of my logfile..

 Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
 CTRL/STAT error, 0xf021
 Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
 STICKY ERROR
 Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
 CTRL/STAT 0xf001
 Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
 0x2352, MEM_AP_TAR 0xfffc
 Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
 CTRL/STAT error, 0xf021
 Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
 STICKY ERROR
 Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
 CTRL/STAT 0xf001
 Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
 0x2352, MEM_AP_TAR 0xfffc
 Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error
 address 0xfff8, count 0x1

At a first glance, it seems fairly normal. The failed accesses to
0xfffX are because GDB tries to backtrace through the stack frames
as far as it goes. Sooner or later it will reach one with the special
exception return value and stop because it can't read memory there.

I assume debugging isn't working for you (and not just the phony error
message nagging you)? What are the symptoms? Any other error messages?

 I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse,
 OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd
 0.4.0

You should be aware of a bug in 0.4.0 causing the first debug session,
after OpenOCD has been started, to fail if the target is running when
GDB connects. It is fixed in recent git and can be worked around in
0.4.0 by either doing 'reset init' in a gdb-attach event handler, or
adding -c init -c 'reset init' to the command line when starting
OpenOCD.


 here are my GDB commands:

 target remote localhost:
 monitor reset halt
 monitor stm32x mass_erase 0
 monitor stm32x options_read 0
 monitor stm32x unlock 0
 monitor reset
 monitor flash write_image  main.bin 0x800 bin
 file main.out
 load main.out
 break main

This looks a bit strange. Nowadays, 'reset init' seems to be preferred
over 'reset halt'. I don't really know the difference but feel it
works better. The 'flash write_image' is superfluous since you later
tell GDB to do a 'load'. Skip the 'flash write_image' and let GDB
handle the flash programming. Also, I believe a second 'reset init' is
needed right after the load in order to update the initial SP and PC
from the newly loaded image. The 'mass_erase' is not needed, unless
you want to clear unused areas of flash, since the GDB load will erase
flash on a page by page basis. The 'unlock' is of course only
necessary if you have previously activated the readout protection. You
could make a separate script to unlock protected chips instead of
doing it each debug session.

My GDB initialization looks something like this (out of my head):

target remote localhost:
monitor reset init
load (if GDB has been told on the command line which executable to
debug, there's no need to specify a file here)
monitor reset init
tbreak main
continue

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR

2010-05-31 Thread Andreas Fritiofson

On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin freddie_cho...@op.pl wrote:
 On 2010-05-31 21:59, Andreas Fritiofson wrote:

 Also, I believe a second 'reset init' is
 needed right after the load in order to update the initial SP and PC
 from the newly loaded image.

 It's not.


Then what sets it?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR

2010-05-31 Thread Andreas Fritiofson

On Mon, May 31, 2010 at 10:43 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
 On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin freddie_cho...@op.pl wrote:
 On 2010-05-31 21:59, Andreas Fritiofson wrote:

 Also, I believe a second 'reset init' is
 needed right after the load in order to update the initial SP and PC
 from the newly loaded image.

 It's not.


 Then what sets it?


Just tried it:

oocd:
 stm32x mass_erase 0
 reset init

gdb:
(gbd) tar rem :
(gbd) load
(gbd) mon gdb_sync
(gbd) stepi
(gbd) info reg
...
sp 0xfffc   0xfffc
lr 0x   4294967295
pc 0x80002dd0x80002dd Reset_Handler

So the PC is set up by GDB (assuming the entry point has been set
correctly in the elf-file) but nothing touches the stack pointer. And
sure enough:

(gdb) stepi
- target is off to infinity and beyond (first instruction pushes some
registers)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Bugfix for flash write_image

2010-05-04 Thread Andreas Fritiofson

On Thu, Apr 29, 2010 at 3:59 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Why hasn't anybody complained yet that flash write_image erase will
 fail for elf images that are not aligned to sectors???

 Unlocking is automatically aligned to sectors in this case...

 I'll be committing this soonish if I don't hear any protests or insights...

ISTR quite some discussion over this a few months ago resulting in the
change TO the current behaviour. The rationale being that it's
unexpected/rude/dangerous to silently alter memory outside the range
being loaded. I seem to agree with that. The REVISIT comment suggests
a better solution: let the user force padding to erase sectors with an
additional 'pad' argument, or fail with a helpful error message
otherwise.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg

2010-04-20 Thread Andreas Fritiofson

On Tue, Apr 20, 2010 at 2:22 AM, JY Koh ko...@uni-inc.co.kr wrote:
 Hi All,



 I have a STM32F103ZE custom board.

 I have been using OpenOCD with Amontec JTAGkey2 for debugging.

 It works fine when I use internal SRAM (64K) as workspace.

 In order to run a little big program I add external SRAM (1M bytes) on FSMC
 (CS1)

 So I’d like to use this external SRAM as workspace.

 What should I change in target configuration ?

 I change workspace from 0x200 to 0x600. It doesn’t work.

 Please let me know if there are something to change.



 Regards,

 JY Koh


OpenOCD won't set up the FSMC for you so you have to do that
somewhere, preferrably in the reset init handler. But I'm not
convinced that there are any benefits over having it in internal SRAM.
What is the problem?

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target

2010-04-20 Thread Andreas Fritiofson

On Tue, Apr 20, 2010 at 9:08 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 I've updated the documentation on the gdb-attach event to
 provide an alternate way to solve this issue.


Great! And there's the target event list that I was briefly searching
for. Good to know there is one.

Freddie, have you checked if the patch resolves your problem?

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg

2010-04-20 Thread Andreas Fritiofson

On Tue, Apr 20, 2010 at 1:10 PM, JY Koh ko...@uni-inc.co.kr wrote:
 Hi Andreas

 Thanks a lot.

 My board has Ethernet and LCD interface so that my program is too big to be
 accommodated into internal SRAM.
 For this reason, I added external SRAM (1M Bytes) and I'd like to run my
 program here.


The working area (which I suspect you are talking about when you say
workspace) has nothing to do with where your program runs from. It is
an area for OpenOCD's internal use, for example for downloading flash
algorithms for execution on the target and as buffer space for data
during flashing. Best leave it at its default location.

If you want to load and debug your program running from external SRAM,
simply tell the linker to place your code there. You still have to set
up the FSMC in the reset init handler for GDB to be able to load the
executable into external memory.

Another solution is to run (and debug) your program from internal
flash. The hardware breakpoints are often sufficient, and the STM32 is
notoriously slow at executing code from external memory. Besides, you
still have to make the code fit in flash if you want it to run without
the debugger.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target

2010-04-17 Thread Andreas Fritiofson

On Sat, Apr 17, 2010 at 9:40 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 You have found an interesting case here indeed.

 As a principle it should be possible to connect via GDB regardless
 of the target state.

 Since that state, in general, can include a case where the target's
 flash is not probable and we need the flash layout upon connection,
 I think we need a more general solution than the one you have below.
 Also, I think it is good, in general, to require the target to be halted
 before the flash is probed GDB aside.

Well, many targets DO need to be halted to be able to probe the flash
and I agree that it would be nice with a solution to the GDB connect
problem in the general case. However, I don't see how it helps to
impose artificial restrictions to targets/flash drivers that are free
from such limitations. I believe such restrictions should be removed,
regardless of any general solution.

Besides, if we for some reason would want the target to always be
halted before a flash probe, shouldn't that be enforced in the generic
flash layer instead of in each individual driver?

 I would like a robust and simple solution. This is not a common problem,
 it is the first time that it has been spotted. A solution that made the 
 general
 case harder would not be desirable.

I don't know, I somehow recall previous reports of this kind of
problem, earlier than Freddie's. And I suspect there's a vast number
of problems like this that never get reported, since people are
historically used to having random glitches and occasional
malfunction. Restarting GDB/OpenOCD is easier than reporting the bug.
For sure it's been a long-standing major annoyance at work with those
once-in-a-while failed loads. I just haven't found a cause until now
(there may be other as well).

 Did you consider adding target config script code to a pre connect
 GDB event?

 Such an event could reset init the target if the flash is not probe-able.

I did consider, but refrained for three reasons:
1. I couldn't find a reference to the available hooks in the
documentation, and I don't know them by heart. I'm sure I just didn't
look hard enough.
2. That would be somewhat of a workaround and I'd much rather see a
fix for the underlying problem.
3. It would probably make it impossible to connect to a running target
without stopping it, for the cases where it is desired.

This may be a good solution for targets which are impossible to probe
in the running state. Other targets shouldn't need it.

--
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] stm32x: allow flash probe on a running target

2010-04-16 Thread Andreas Fritiofson

If the flash has not yet been probed and GDB connects while the target is
running, the flash probe triggered by GDB's memory map read will fail. In
that case the returned memory map will be empty, causing a subsequent load
from within GDB to fail. There's not much you can do from GDB to recover,
other than a restart; a 'mon reset init' and manual 'mon flash probe' won't
help since GDB has already made up its mind about the memory map.

It seems there's no reason to require the target to be halted when probing
the flash. Remove the check to let a valid memory map be provided to GDB
even when connecting to a running target.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/flash/nor/stm32x.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c
index 845d589..818c474 100644
--- a/src/flash/nor/stm32x.c
+++ b/src/flash/nor/stm32x.c
@@ -676,12 +676,6 @@ static int stm32x_probe(struct flash_bank *bank)
uint32_t device_id;
int page_size;
 
-   if (bank-target-state != TARGET_HALTED)
-   {
-   LOG_ERROR(Target not halted);
-   return ERROR_TARGET_NOT_HALTED;
-   }
-
stm32x_info-probed = 0;
 
/* read stm32 device id register */
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Other compilers

2010-01-29 Thread Andreas Fritiofson

This would help to avoid picking a magic value for true.
#define false 0
#define true (!false) // this will actually evaluate to 1

On the other hand, code that relies on specific values for true is
IMHO buggy or at least error prone (especially if true == -1!!),
which implies that the define shouldn't be used at all in comparisons.
That includes pointless constructs like if ((a == b) == true) ...
except with real boolean types (and if there's a bool type there's
certainly a built-in true as well). It could perhaps be useful in
assignments, though.

- Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Other compilers

2010-01-29 Thread Andreas Fritiofson

On Fri, Jan 29, 2010 at 7:11 PM, Michael Schwingen
rincew...@discworld.dascon.de wrote:
 Andreas Fritiofson wrote:
 This would help to avoid picking a magic value for true.
 #define false 0
 #define true (!false) // this will actually evaluate to 1

 IMHO, this is unnecessary obfuscation.
 The C standard guarantees that this will evaluate to 1, so why not write
 1 directly?


To signal to less knowledgeable people, who might be reading/altering
the code, that it is *not* an arbitrary value. You are probably less
likely to change the definition of true from not false than from
1 to another non-zero value which might seem just as valid but which
isn't, such as -1.

Just my 0.14772 SEK...

A bit more on-topic:
Doesn't clang have stdbool.h? It should provide these constants
already. For systems lacking stdbool.h, OpenOCD already contains the
necessary compatibility defines in types.h, isn't that getting
included?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] post 0.4 memory map features

2010-01-20 Thread Andreas Fritiofson

On Wed, Jan 20, 2010 at 8:40 AM, David Brownell davi...@pacbell.net wrote:
 On Tuesday 19 January 2010, Øyvind Harboe wrote:
 New thread on new features to gdb memory maps.

  Not sure what you mean by caching ... if the CPU is running, we
  can't assume it's not going to touch such areas.

 We can tell GDB to read data from an area(e.g. disassembly) from
 the elf file rather than the target memory, I think.

 That'd be reasonable for flash and ROM type regions.  Not for RAM,
 which as a rule can be trivially overwritten.  When that happens,
 people driving a debugger will want the current status.


  Though:  I looked at the GDB protocol spec and it says that undefined
  areas are presumed to be RAM.  So I'm a bit puzzled about just what
  that current code is there for...

 If you have *any* memory map, then, as I recall, it would be defined as
 invalid memory if it wasn't ram.

 If you have *no* memory map, then it's all assumed to be RAM.

 I'm going by:

  http://sourceware.org/gdb/current/onlinedocs/gdb/Memory-Map-Format.html

 which says (among other things):  GDB assumes that areas of memory
 not covered by the memory map are RAM.  I don't know if older versions
 assumed otherwise, though.

When I played with it some time ago, it behaved as Øyvind described.
There is an option, i think it's called 'mem inaccessible-by-default',
that selects the other behavior. The default value may have changed
recently.

Regards,
Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/3] update win32 script search path

2010-01-19 Thread Andreas Fritiofson

It seems this never reached the list...

So in conclusion, the (soon to be official?) windows packages from
Freddie Chopin installs config files so they are found by the first
default search path (in $installroot). In a unix-like environment,
including cygwin/msys, the build system by default installs them in
$installroot/share/openocd/scripts, not yet covered by any default
search path when building for Windows. I take the silence to mean that
nobody wants the files under $installroot/lib/openocd so that search
path could go (or possibly kept as a third option).

Any objections to merge this?

Regards,
Andreas

2010/1/16 Andreas Fritiofson andreas.fritiof...@gmail.com:
 2010/1/15  freddie_cho...@op.pl:
 Użytkownik  oyvind.har...@zylin.com napisał:
I find it odd that none has.

 Personally I don't know what is the point of that patch. I don't use OpenOCD 
 via tree of MinGW/MSYS and I don't think anyone does, so what's the point of 
 that patch? I use MinGW/MSYS to compile OpenOCD, and it compiles fine, 
 because that process does not require cfg files. In windows there is only 
 one place for installing software - C:\Program Files\. Personally I package 
 OpenOCD the same way as Michael Fisher has done that in the past: /bin/ (exe 
 + dll), /interface/ (cfg), /target/ (cfg), /board/ (cfg) and that works as a 
 charm.

 Well, I do. Otherwise I wouldn't need it patched. So does everybody
 else that uses a MSYS environment and wants to build/install openocd
 with a customary configure  make  make install. This is the
 environment we use at work, hence my wish to get it fixed. For my
 personal use I don't really care since I don't use Windows.

 The reason I want packagers to comment is to avoid breakage if they
 install scripts in ../lib relative to the openocd binary.

 Regards,
 Andreas

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/3] update win32 script search path

2010-01-14 Thread Andreas Fritiofson

Any comments on this? I had hoped to get this functional in 0.4 so I
could drop the -s from the command line at work.

Windows builders/packagers, does this look OK from your point of view
or do you still install scripts in ../lib?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote:
 On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
 On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote:
  On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote:
   Hm - I'm with David here: I am not very fond of re-inventing parts of
   gdb to include it in OpenOCD.
  
   Fully implementing this would make OpenOCD depend on libbfd just for
   crash reports - this is ridiculous.
 
  If something like this was added, it should not create any
  dependencies or do anything remotely exotic.
 
  How about adding an option to statically link with GDB or create
  a script that launched OpenOCD via GDB as default?
 
  No one was talking about linking with GDB.  That's just insane. ;)
  libbfd is part of binutils.  But again it should be_optional.

 OK. Explain the benefit of complicating OpenOCD vs. adding a script
 to launch OpenOCD via GDB then...

 Seriously... you've never had a Heisenbug either?  Am I the only one
 that gets segfaults and doesn't _want_ to have to debug them?  Really?

Isn't running with core dumps enabled a far simpler method to catch
those one-off crashes than keeping (and maintaining!) a bunch of code
in-tree to do essentially the same, but less? It's less awkward than
launching openocd within gdb, for sure.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote:
 On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
 On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote:
  On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
  On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net 
  wrote:
   On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote:
Hm - I'm with David here: I am not very fond of re-inventing parts of
gdb to include it in OpenOCD.
   
Fully implementing this would make OpenOCD depend on libbfd just for
crash reports - this is ridiculous.
  
   If something like this was added, it should not create any
   dependencies or do anything remotely exotic.
  
   How about adding an option to statically link with GDB or create
   a script that launched OpenOCD via GDB as default?
  
   No one was talking about linking with GDB.  That's just insane. ;)
   libbfd is part of binutils.  But again it should be_optional.
 
  OK. Explain the benefit of complicating OpenOCD vs. adding a script
  to launch OpenOCD via GDB then...
 
  Seriously... you've never had a Heisenbug either?  Am I the only one
  that gets segfaults and doesn't _want_ to have to debug them?  Really?

 Isn't running with core dumps enabled a far simpler method to catch
 those one-off crashes than keeping (and maintaining!) a bunch of code
 in-tree to do essentially the same, but less? It's less awkward than
 launching openocd within gdb, for sure.

 Again, core dumps are great -- when you have the presence of mind to set
 yourself up to produce them.  It has been my impression (for some time)
 that most folks run in environments where that is disabled by default,
 so we are again talking about performing precognitive steps if you want
 to capture unpredictable bugs (while not producing unwanted core files).

Something like this simple patch would fix that in most (linux) users'
environments. At least on my ubuntu the hard limit is unlimited,
probably on most other dists as well.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
 On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote:
 On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
 On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote:
  On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
  On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net 
  wrote:
   On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote:
Hm - I'm with David here: I am not very fond of re-inventing parts 
of
gdb to include it in OpenOCD.
   
Fully implementing this would make OpenOCD depend on libbfd just for
crash reports - this is ridiculous.
  
   If something like this was added, it should not create any
   dependencies or do anything remotely exotic.
  
   How about adding an option to statically link with GDB or create
   a script that launched OpenOCD via GDB as default?
  
   No one was talking about linking with GDB.  That's just insane. ;)
   libbfd is part of binutils.  But again it should be_optional.
 
  OK. Explain the benefit of complicating OpenOCD vs. adding a script
  to launch OpenOCD via GDB then...
 
  Seriously... you've never had a Heisenbug either?  Am I the only one
  that gets segfaults and doesn't _want_ to have to debug them?  Really?

 Isn't running with core dumps enabled a far simpler method to catch
 those one-off crashes than keeping (and maintaining!) a bunch of code
 in-tree to do essentially the same, but less? It's less awkward than
 launching openocd within gdb, for sure.

 Again, core dumps are great -- when you have the presence of mind to set
 yourself up to produce them.  It has been my impression (for some time)
 that most folks run in environments where that is disabled by default,
 so we are again talking about performing precognitive steps if you want
 to capture unpredictable bugs (while not producing unwanted core files).

 Something like this simple patch would fix that in most (linux) users'
 environments. At least on my ubuntu the hard limit is unlimited,
 probably on most other dists as well.

 /Andreas

D'oh...
diff --git a/src/main.c b/src/main.c
index a71977d..b580c8b 100644
--- a/src/main.c
+++ b/src/main.c
@@ -23,6 +23,7 @@
 #include config.h
 #endif
 #include openocd.h
+#include sys/resource.h
 
 /* This is the main entry for developer PC hosted OpenOCD.
  *
@@ -35,5 +36,12 @@
 
 int main(int argc, char *argv[])
 {
+	struct rlimit rlim;
+
+	if (getrlimit(RLIMIT_CORE, rlim) == 0) {
+		rlim.rlim_cur = rlim.rlim_max;
+		setrlimit(RLIMIT_CORE, rlim);
+	}
+
 	return openocd_main(argc, argv);
 }
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch z...@superlucidity.net wrote:
 On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote:
 On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson
 andreas.fritiof...@gmail.com wrote:
  On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote:
  On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
  On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net 
  wrote:
   On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
   On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net 
   wrote:
On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote:
 Hm - I'm with David here: I am not very fond of re-inventing 
 parts of
 gdb to include it in OpenOCD.

 Fully implementing this would make OpenOCD depend on libbfd just 
 for
 crash reports - this is ridiculous.
   
If something like this was added, it should not create any
dependencies or do anything remotely exotic.
   
How about adding an option to statically link with GDB or create
a script that launched OpenOCD via GDB as default?
   
No one was talking about linking with GDB.  That's just insane. ;)
libbfd is part of binutils.  But again it should be_optional.
  
   OK. Explain the benefit of complicating OpenOCD vs. adding a script
   to launch OpenOCD via GDB then...
  
   Seriously... you've never had a Heisenbug either?  Am I the only one
   that gets segfaults and doesn't _want_ to have to debug them?  Really?
 
  Isn't running with core dumps enabled a far simpler method to catch
  those one-off crashes than keeping (and maintaining!) a bunch of code
  in-tree to do essentially the same, but less? It's less awkward than
  launching openocd within gdb, for sure.
 
  Again, core dumps are great -- when you have the presence of mind to set
  yourself up to produce them.  It has been my impression (for some time)
  that most folks run in environments where that is disabled by default,
  so we are again talking about performing precognitive steps if you want
  to capture unpredictable bugs (while not producing unwanted core files).
 
  Something like this simple patch would fix that in most (linux) users'
  environments. At least on my ubuntu the hard limit is unlimited,
  probably on most other dists as well.
 

 I like it, except I think it needs to be disabled in the default case.
 We will get complaints if OpenOCD produces core dumps without asking, so
 this precludes the possibility of turning it on by default.  Our program
 needs to respect the fact that the user could have configured their
 environment to let the program dump its core, so it seems like bad
 policy to override that default without the user's explicit authority.

I don't follow. If a user has no clue what a core file is but wants to
report a crash, he'll be pleased to find that the file we request is
already there, ready to submit in a bug report. If a user knows about
core files and _wants_ them, he surely has them enabled anyway (ulimit
-c unlimited). If that user _doesn't_ want any core files from
openocd, he'll have set the hard limit to 0 (ulimit -c 0), in which
case openocd cannot change that. Tough luck. The default policy, which
the user may override, is don't dump core unless the process wants
to.

 We could allow it to be turned on with OPENOCD_DUMPS_CORES set in the
 environment or via a script command (e.g. 'core dumps (on|off)').  This
 modified suggestion sounds like a reasonable feature to add, once more
 work has been done to manage portability.  Right now, it's a rat's nest.
 Finally, I am not sure your suggestion would improve the assert() macro,
 as the last patch that I posted demonstrates.  Does that macro produce
 core files with the stack trace at the point of assertion?

Yes. Unless, of course, your mentioned patch is applied... :)
It also dumps on some other signals (SIGILL, SIGFPE and SIGQUIT).

The fact is that the most recent crash I had with OpenOCD
(log_print_lf adding a newline beyond the end of the cheaply allocated
string) wouldn't have been caught with your stack trace, since it did
not SIGSEGV, it was aborted by a later free(). It would have dumped
core though. Of course, your solution could have been trivially
improved to catch SIGABRT as well.

 I still want my stack tracing, because I cannot tell the future.  It's
 also the least invasive to the user experience, when compared to GDB or
 core dumps.  I am not kidding when I say that I do not want to do _any_
 extra post-processing steps.  I fail to see how core files meet this
 added requirement any better than GDB, when my code nearly does  To
 be fair, I added a small perl script to my series that runs addr2line to
 translate the existing traces that the code produces, but this still has
 the clear advantage of not needing to predict your crashes.

What kind of post-processing steps do you mean and why don't you want
them? Given an executable and its

[Openocd-development] [PATCH] improve alloc_vprintf

2009-11-24 Thread Andreas Fritiofson

The previous implementation was unnecessarily complex. Get rid of the loops,
let vsnprintf() tell us directly how much storage we need and allocate that. A
second pass writes the actual string. Also add a va_end() that was missing.
This should be much faster for large strings and less wasteful for small ones.

A quirk that has been retained is that some callers patch in a newline at the
end of the returned string and depend on alloc_vprintf to allocate at least
one byte extra.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
This time without the copy/paste error. Thanks Zach for spotting it.
---
 src/helper/log.c |   43 ---
 1 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/src/helper/log.c b/src/helper/log.c
index caaed42..2dcf7bb 100644
--- a/src/helper/log.c
+++ b/src/helper/log.c
@@ -395,37 +395,26 @@ int log_remove_callback(log_callback_fn fn, void *priv)
 /* return allocated string w/printf() result */
 char *alloc_vprintf(const char *fmt, va_list ap)
 {
-   /* no buffer at the beginning, force realloc to do the job */
-   char *string = NULL;
-
-   /* start with buffer size suitable for typical messages */
-   int size = 128;
-
-   for (;;)
-   {
-   char *t = string;
-   va_list ap_copy;
-   int ret;
-   string = realloc(string, size);
-   if (string == NULL)
-   {
-   if (t != NULL)
-   free(t);
-   return NULL;
-   }
+   va_list ap_copy;
+   int len;
+   char *string;
 
-   va_copy(ap_copy, ap);
+   /* determine the length of the buffer needed */
+   va_copy(ap_copy, ap);
+   len = vsnprintf(NULL, 0, fmt, ap_copy);
+   va_end(ap_copy);
 
-   ret = vsnprintf(string, size, fmt, ap_copy);
-   /* NB! The result of the vsnprintf() might be an *EMPTY* 
string! */
-   if ((ret = 0)  ((ret + 1)  size))
-   break;
+   /* allocate and make room for terminating zero. */
+   /* FIXME: The old version always allocated at least one byte extra and
+* other code depend on that. They should be probably be fixed, but for
+* now reserve the extra byte. */
+   string = malloc(len + 2);
+   if (string == NULL)
+   return NULL;
 
-   /* there was just enough or not enough space, allocate more in 
the next round */
-   size *= 2; /* double the buffer size */
-   }
+   /* do the real work */
+   vsnprintf(string, len + 1, fmt, ap);
 
-   /* the returned buffer is by principle guaranteed to be at least one 
character longer */
return string;
 }
 
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-23 Thread Andreas Fritiofson

On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson
 andreas.fritiof...@gmail.com wrote:
 On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com 
 wrote:
 Do not use variable length arrays. Use malloc().

 If you use variable length arrays on the stack that messes with embedded
 / uCLinux hosts.


 Only if the embedded host uses a home directory path longer than what
 will fit on the stack. Is this really a problem?

 Yes. Other programmers will copy and paste your code.

 We've got the code clean of dynamic arrays on the stack and we
 should keep it that way.


Since C99 has been accepted as the project's language standard, I
think it is reasonable to expect that valid language constructs that
are still *not* acceptable by the project be clearly stated in the
Style Guide. Likewise if being optimized for embedded hosts is a
priority for the project as a whole. Rejecting even trivial patches on
the grounds of previously unspoken goals does not encourage developers
to contribute.

With that said, I'll happily resign in this case. Actually, my first
draft was using asprintf() but I rejected it for not being standard.
Seeing there's an equivalent already in the code, I'll update the
patch using that.

However, alloc_vprintf() seems to have a rather cumbersome
implementation. Is there a reason why it is looping, trying with
increasingly larger allocations?

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 2/3] support for scripts in $HOME/.openocd

2009-11-23 Thread Andreas Fritiofson

Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.

Update the user guide with information on where OpenOCD expects to find
configuration files and scripts. Also fixed some minor formatting issues.

Add entry to NEWS as well.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 NEWS |1 +
 doc/openocd.texi |   22 ++
 src/helper/options.c |   15 ++-
 3 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/NEWS b/NEWS
index 1a024e4..0dcc4bc 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,7 @@ Flash Layer:
 Board, Target, and Interface Configuration Scripts:
ARM9
- ETM and ETB hookup for iMX2* targets
+   Add $HOME/.openocd to the search path.
 
 Documentation:
 Build and Release:
diff --git a/doc/openocd.texi b/doc/openocd.texi
index cff7fc5..e94c9d0 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -483,14 +483,24 @@ bash$ openocd --help
 --pipe   | -p   use pipes when talking to gdb
 @end verbatim
 
-By default OpenOCD reads the file configuration file @file{openocd.cfg}
-in the current directory.  To specify a different (or multiple)
-configuration file, you can use the ``-f'' option. For example:
+By default OpenOCD reads the configuration file @file{openocd.cfg}.
+To specify a different (or multiple)
+configuration file, you can use the @option{-f} option. For example:
 
 @example
 openocd -f config1.cfg -f config2.cfg -f config3.cfg
 @end example
 
+Configuration files and scripts are searched for in
+...@enumerate
+...@item the current directory,
+...@item any search dir specified on the command line using the @option{-s} 
option,
+...@item @file{$HOME/.openocd} (not on Windows),
+...@item the site wide script library @file{$pkgdatadir/site} and
+...@item the OpenOCD-supplied script library @file{$pkgdatadir/scripts}.
+...@end enumerate
+The first found file with a matching file name will be used.
+
 OpenOCD starts by processing the configuration commands provided
 on the command line or in @file{openocd.cfg}.
 @xref{Configuration Stage}.
@@ -507,7 +517,7 @@ clients (Telnet, GDB, Other) and processes the commands 
issued through
 those channels.
 
 If you are having problems, you can enable internal debug messages via
-the ``-d'' option.
+the @option{-d} option.
 
 Also it is possible to interleave JIM-Tcl commands w/config scripts using the
 @option{-c} command line switch.
@@ -523,10 +533,6 @@ setting from within a telnet or gdb session using 
@command{debug_level
 You can redirect all output from the daemon to a file using the
 @option{-l logfile} switch.
 
-Search paths for config/script files can be added to OpenOCD by using
-the @option{-s search} switch. The current directory and the OpenOCD
-target library is in the search path by default.
-
 For details on the @option{-p} option. @xref{Connecting to GDB}.
 
 Note! OpenOCD will launch the GDB  telnet server even if it can not
diff --git a/src/helper/options.c b/src/helper/options.c
index 5792e11..e036d61 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -101,7 +101,20 @@ static void add_default_dirs(void)
 * listed last in the built-in search order, so the user can
 * override these scripts with site-specific customizations.
 */
-   /// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
+
+   const char *home = getenv(HOME);
+
+   if (home) {
+   char *path;
+
+   path = alloc_printf(%s/.openocd, home);
+
+   if (path) {
+   add_script_search_dir(path);
+   free(path);
+   }
+   }
+
add_script_search_dir(PKGDATADIR /site);
add_script_search_dir(PKGDATADIR /scripts);
 #endif
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] improve alloc_vprintf

2009-11-23 Thread Andreas Fritiofson

The previous implementation was unnecessarily complex. Get rid of the loops,
let vsnprintf() tell us directly how much storage we need and allocate that. A
second pass writes the actual string. Also add a va_end() that was missing.
This should be much faster for large strings and less wasteful for small ones.

A quirk that has been retained is that some callers patch in a newline at the
end of the returned string and depend on alloc_vprintf to allocate at least
one byte extra.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/log.c |   43 ---
 1 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/src/helper/log.c b/src/helper/log.c
index caaed42..6869d2e 100644
--- a/src/helper/log.c
+++ b/src/helper/log.c
@@ -395,37 +395,26 @@ int log_remove_callback(log_callback_fn fn, void *priv)
 /* return allocated string w/printf() result */
 char *alloc_vprintf(const char *fmt, va_list ap)
 {
-   /* no buffer at the beginning, force realloc to do the job */
-   char *string = NULL;
-
-   /* start with buffer size suitable for typical messages */
-   int size = 128;
-
-   for (;;)
-   {
-   char *t = string;
-   va_list ap_copy;
-   int ret;
-   string = realloc(string, size);
-   if (string == NULL)
-   {
-   if (t != NULL)
-   free(t);
-   return NULL;
-   }
+   va_list ap_copy;
+   int len;
+   char *string;
 
-   va_copy(ap_copy, ap);
+   /* determine the length of the buffer needed */
+   va_copy(ap_copy, ap);
+   len = vsnprintf(NULL, 0, fmt, ap_copy);
+   va_end(ap_copy);
 
-   ret = vsnprintf(string, size, fmt, ap_copy);
-   /* NB! The result of the vsnprintf() might be an *EMPTY* 
string! */
-   if ((ret = 0)  ((ret + 1)  size))
-   break;
+   /* allocate and make room for terminating zero. */
+   /* FIXME: The old version always allocated at least one byte extra and
+* other code depend on that. They should be probably be fixed, but for
+* now reserve the extra byte. */
+   string = malloc(len + 2);
+   if (string == NULL)
+   return NULL;
 
-   /* there was just enough or not enough space, allocate more in 
the next round */
-   size *= 2; /* double the buffer size */
-   }
+   /* do the real work */
+   vsnprintf(string, len + 1, fmt, ap_copy);
 
-   /* the returned buffer is by principle guaranteed to be at least one 
character longer */
return string;
 }
 
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-22 Thread Andreas Fritiofson

On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Do not use variable length arrays. Use malloc().

 If you use variable length arrays on the stack that messes with embedded
 / uCLinux hosts.


Only if the embedded host uses a home directory path longer than what
will fit on the stack. Is this really a problem?

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Document build broken when src != build

2009-11-22 Thread Andreas Fritiofson

On Sun, Nov 22, 2009 at 10:17 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 I can no longer build docs when src != build. I believe this is trivially
 reproducible and that the breakage is relatively recent(a month
 or so).

 Or... perhaps I'm missing some tool on my laptop?

 make docs
 make doxygen

 = both fail

 make doxygen/latex/refman.pdf
 make[1]: Entering directory `/home/oyvind/workspace/build'
 make[1]: *** No rule to make target `doxygen/latex/refman.pdf'.  Stop.

 I saw this error warning fly by

 doxygen Doxyfile 21 | perl ../zy1000/openocd/tools/logger.pl  doxygen.log
 Warning: tag INPUT: input source `../zy1000/openocd/config.h' does not exist
 Warning: source ../zy1000/openocd/config.h is not a readable file or
 directory... skipping.
 


Same problem here, automatic git bisect revealed
0091e59d2a18c293fd952a9d707e609afdd6b17f to be the culprit.
The warning message is unrelated.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 0/3] improve default script search path

This series improves the default script search path to include $HOME/.openocd.
It also updates the search path on Windows to match what appears to be the
result of a standard 'configure  make  make install' in one particular
MSYS environment. Other environments have not been tested, but the current
path seems wrong regardless.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 2/3] update win32 script search path

The default script search path on Windows seems to be out of date with the
current layout, causing the standard scripts not to be found after a
conventional './configure  make  make install' under msys/MinGW. The same
should hold true for cygwin native builds although not verified.

Update the search path to ../share/openocd/scripts instead of ../lib/openocd,
relative the openocd executable.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/options.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/helper/options.c b/src/helper/options.c
index 874196e..5792e11 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -74,21 +74,21 @@ static void add_default_dirs(void)
add_script_search_dir(strExePath);
}
/*
-* Add support for the default (as of 20080121) layout when
-* using autotools and cygwin to build native MinGW binary.
+* Add support for the default (as of 20091118) layout when
+* using autotools and cygwin/MinGW to build native binary.
 * Path separator is converted to UNIX style so that MinGW is
 * pleased.
 *
 * bin/openocd.exe
-* lib/openocd/event/at91eb40a_reset.cfg
-* lib/openocd/target/at91eb40a.cfg
+* share/openocd/scripts/interface/dummy.cfg
+* share/openocd/scripts/target/at91eb40a.cfg
 */
{
char strExePath [MAX_PATH];
char *p;
GetModuleFileName (NULL, strExePath, MAX_PATH);
*strrchr(strExePath, '\\') = 0;
-   strcat(strExePath, /../lib/PACKAGE);
+   strcat(strExePath, /../share/PACKAGE/scripts);
for (p = strExePath; *p; p++) {
if (*p == '\\')
*p = '/';
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/options.c |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/src/helper/options.c b/src/helper/options.c
index 5792e11..2187ff7 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -29,6 +29,7 @@
 #include server.h
 
 #include getopt.h
+#include stdlib.h
 
 static int help_flag, version_flag;
 
@@ -54,6 +55,10 @@ int configuration_output_handler(struct command_context 
*context, const char* li
 
 static void add_default_dirs(void)
 {
+#ifndef MAX_PATH
+#define MAX_PATH 1024
+#endif
+
 #ifdef _WIN32
/* Add the parent of the directory where openocd.exe resides to the
 * config script search path.
@@ -101,7 +106,16 @@ static void add_default_dirs(void)
 * listed last in the built-in search order, so the user can
 * override these scripts with site-specific customizations.
 */
-   /// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
+
+   char *home = getenv(HOME);
+
+   if (home) {
+   char path[MAX_PATH];
+
+   if (snprintf(path, MAX_PATH, %s/.openocd, home)  MAX_PATH)
+   add_script_search_dir(path);
+   }
+
add_script_search_dir(PKGDATADIR /site);
add_script_search_dir(PKGDATADIR /scripts);
 #endif
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 1/3] show script search dirs in debug log

Add this to ease debugging why the standard scripts aren't found on the
default script search path in some build/install enviroments. Especially on
Windows it's not straight forward where openocd actually looks for the
scripts.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/configuration.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/helper/configuration.c b/src/helper/configuration.c
index 74bcc9b..2ea5da4 100644
--- a/src/helper/configuration.c
+++ b/src/helper/configuration.c
@@ -41,6 +41,8 @@ void add_script_search_dir (const char *dir)
 
script_search_dirs[num_script_dirs-1] = strdup(dir);
script_search_dirs[num_script_dirs] = NULL;
+
+   LOG_DEBUG(adding %s, dir);
 }
 
 void add_config_command (const char *cfg)
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote:
 On Sat, 2009-11-21 at 16:53 +0100, Andreas Fritiofson wrote:
 Add $HOME/.openocd as the first default script search directory, allowing
 the user to override the standard scripts.

 Comments are in-line and at the end.

 Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
 ---
  src/helper/options.c |   16 +++-
  1 files changed, 15 insertions(+), 1 deletions(-)

 diff --git a/src/helper/options.c b/src/helper/options.c
 index 5792e11..2187ff7 100644
 --- a/src/helper/options.c
 +++ b/src/helper/options.c
 @@ -29,6 +29,7 @@
  #include server.h

  #include getopt.h
 +#include stdlib.h

  static int help_flag, version_flag;

 @@ -54,6 +55,10 @@ int configuration_output_handler(struct command_context 
 *context, const char* li

  static void add_default_dirs(void)
  {
 +#ifndef MAX_PATH
 +#define MAX_PATH 1024
 +#endif
 +

 PATH_MAX should be defined and available (in limits.h).  Use it.

I did some research on the matter, and it seems that PATH_MAX is only
defined if there actually is a limit, which apparently is not always
the case. Even if defined, the value is often arbitrary or unsuitably
large. So the #ifndef would have to stay, albeit with another name.
Since MAX_PATH was already used in the WIN32 specific section, I
decided to reuse that to avoid confusion with two different names.

Of course, should PATH_MAX be equally valid on WIN32 even though it's
an extension, that section could be changed to use it too if
available. I can verify if that's the case earliest on Monday, since I
have no Windows machine at home, and submit a clean-up patch after
that. In the meantime, this should work perfectly, even if users with
a 1K long home directory might be disappointed. :)


  #ifdef _WIN32
       /* Add the parent of the directory where openocd.exe resides to the
        * config script search path.
 @@ -101,7 +106,16 @@ static void add_default_dirs(void)
        * listed last in the built-in search order, so the user can
        * override these scripts with site-specific customizations.
        */
 -     /// @todo Implement @c add_script_search_dir(${HOME}/.openocd).

 As the one who added that @todo item, thanks for doing this! :)

 +
 +     char *home = getenv(HOME);
 +
 +     if (home) {
 +             char path[MAX_PATH];
 +
 +             if (snprintf(path, MAX_PATH, %s/.openocd, home)  MAX_PATH)
 +                     add_script_search_dir(path);
 +     }
 +
       add_script_search_dir(PKGDATADIR /site);
       add_script_search_dir(PKGDATADIR /scripts);
  #endif

 As others note, this deserves mention in doc/openocd.texi and NEWS.


I'll look into a patch for those soon-ish.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

On Sat, Nov 21, 2009 at 9:31 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote:

 PATH_MAX should be defined and available (in limits.h).  Use it.

 Why not just allocate dynamically and avoid the problem at the root?


That sounds like the best solution, I'll prepare an updated patch.

Ehm... The question is... how do i do it?? This was more or less my
first git experience and I found it rather easy to develop and commit
this on a separate branch, prepare the patch series with
git-format-patch and even send it with git-send-email. But when
there's feedback on one of the patches, like in this case, how do I
revise that patch and send an updated version? I find myself in the
dark here... I've read some tutorials, but most speak in rather
general terms. This ought to be a very common scenario. Step-by-step
guide, anyone?

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch z...@superlucidity.net wrote:
 Checkout your branch and run 'git rebase master'.  That will update your
 branch against the current master.  Then, do the same thing with '-i'.
 Select the patches to change and mark them with 'e', change the files,
 add them and --amend the comment, then --continue the rebase. Rinse and
 repeat for all marked files.

Great, that was easy, thanks! Here's an updated patch, this time using
C99 variable length arrays. I'm using the unbounded string functions
here, guessing we can trust getenv() to return a piece of memory that
won't change on the fly.

Btw, is it suitable to attach an updated patch as an attachment like
this? I thought git-send-email was fancy, but I hardly think it can
figure out to send the new patch as a reply in the old thread?

/Andreas
From 4fb41a4855e58448070f5d4e3434878aa1c8c72f Mon Sep 17 00:00:00 2001
From: Andreas Fritiofson andreas.fritiof...@gmail.com
Date: Thu, 19 Nov 2009 23:58:15 +0100
Subject: [PATCH 2/2] support for scripts in $HOME/.openocd

Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/options.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/src/helper/options.c b/src/helper/options.c
index 5792e11..84e391b 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -101,7 +101,18 @@ static void add_default_dirs(void)
 	 * listed last in the built-in search order, so the user can
 	 * override these scripts with site-specific customizations.
 	 */
-	/// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
+
+	const char *home = getenv(HOME);
+	const char *suffix = /.openocd;
+
+	if (home) {
+		char path[strlen(home) + strlen(suffix) + 1];
+
+		strcpy(path, home);
+		strcat(path, suffix);
+		add_script_search_dir(path);
+	}
+
 	add_script_search_dir(PKGDATADIR /site);
 	add_script_search_dir(PKGDATADIR /scripts);
 #endif
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 2/2] support for scripts in $HOME/.openocd