Looks like more fun with the code below in jim.c...
#if !defined(HAVE_UNISTD_H) || !defined(__GNU_LIBRARY__)
extern char **environ;
#endif
../../../openocd/src/helper/jim.c: In function `Jim_EnvCoreCommand':
../../../openocd/src/helper/jim.c:11988: warning: redundant
redeclaration of
On Wed, 2009-05-06 at 08:17 +0200, Øyvind Harboe wrote:
Looks like more fun with the code below in jim.c...
#if !defined(HAVE_UNISTD_H) || !defined(__GNU_LIBRARY__)
extern char **environ;
#endif
../../../openocd/src/helper/jim.c: In function `Jim_EnvCoreCommand':
On Tue, 2009-05-05 at 23:27 -0700, Zach Welch wrote:
On Wed, 2009-05-06 at 08:17 +0200, Øyvind Harboe wrote:
Looks like more fun with the code below in jim.c...
#if !defined(HAVE_UNISTD_H) || !defined(__GNU_LIBRARY__)
extern char **environ;
#endif
Committed.
in_handler is deprecated. Removing the remaining uses will take
some time, but the most significant benefit of not having to setting
all those deprecated fields to NULL can be had immediately.
--
Øyvind Harboe
Embedded software and hardware consulting services
Do not submit this patch.
Do not modify / retire any parameter from JTAG API scan functions.
Yes, field.out_mask is not used for ARM Debug, but could be very important for
pure boundary scan test !
Please do not touch the JTAG API at all !
Regards,
Laurent Gauch
http://www.amontec.com
Please remove it.
In_handler could be very useful when we will add pure JTAG Boundary
Scan support in OpenOCD.
Please do not touch the JTAG API at all !
Regards,
Laurent Gauch
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Committed.
in_handler is deprecated. Removing
Yes, field.out_mask is not used for ARM Debug, but could
be very important for pure boundary scan test !
This can be done from the calling code and it will be much clearer
what's going on.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
I would like to remove in_check_mask.
There are a *few* places in the code where it is used,
but those are trivially modified.
This will result in lots of code deleted and more easily
understandable code
in_check_mask is nice feature since we could check only one (or some)
bit in a scan
Yes it could. But giving this out_mask info to the low layer JTAG API
can really help to accelerate the JTAG interface itself and accelerating
the OpenOCD by the way.
Same for in_check_mask and other _mask parameters.
The best you can do is to write new smaller functions calling the actual
On Wed, May 6, 2009 at 11:10 AM, Laurent Gauch
laurent.ga...@amontec.com wrote:
Yes it could. But giving this out_mask info to the low layer JTAG API can
really help to accelerate the JTAG interface itself and accelerating the
OpenOCD by the way.
This is an extraordinary claim that I do not
On Wed, May 6, 2009 at 11:50 AM, Laurent Gauch
laurent.ga...@amontec.com wrote:
Ųyvind Harboe wrote:
On Wed, May 6, 2009 at 11:10 AM, Laurent Gauch
laurent.ga...@amontec.com wrote:
Yes it could. But giving this out_mask info to the low layer JTAG API can
really help to accelerate the JTAG
It think we should keep them (for now). They do not cause any problems,
a helper to fill in defaults is very simple to write.
But it would be interesting to see some example of how they should be
used to accelerate the JTAG Layer Interface.
Please lets us work on more important stuff, 7 step
On Wed, May 6, 2009 at 12:06 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
It think we should keep them (for now). They do not cause any problems,
a helper to fill in defaults is very simple to write.
The helper function is there already. We can introduce
any number of new fields to that
On Wednesday 29 April 2009 14:35:24 Vytautas Lukenskas wrote:
I have problems connecting with Amontec JTAGKey to LuminaryMicro boards
(IDM-L35, LM3S8962) from linux. I get about 1 successfull connection from
~10 attempts. When connection succeeded, I can flash target, restart, debug
it without
Øyvind Harboe wrote:
These fields are not gone as such. We can have any number of
them that we want by modifying the helper functions.
Lets start with profiling and analysis of OpenOCD and we'll add
those features to the driver API that we need without complicating
the calling code.
I
Hi,
On Mon, May 04, 2009 at 11:56:00AM -0700, Zach Welch wrote:
The attached patch should fix the cast alignment warnings caused by
jim.c on platforms with stricter alignment rules.
If you get more problems, please run the builds with --disable-werror so
I can try to fix all of them in one
Well,
I noticed that you do have some context handling functions and that they
just use a context[16] to save the values of r0 ~r15. We still have cspr and
spsr...
Isn't there any ARM reg struct in the whole OpenOCD code to save this reg
context?
thanks,
jesus
2009/5/4 Jesus
Does anyone have any arm11 testing hardware they could donate?
If so, email me. We're setting up a target farm for testing OpenOCD
developer access.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Do you mean monitor go or monitor continue ?
I mean, at this point I'm not sure if I really need to do everything with
the monitor commands...
I did what said monitor reset halt monitor bp monitor resume...
nothing. I can never reach a breakpoint. What's going on ?!
thanks,
Jesus
2009/5/5
Magnus Lundin wrote:
tangray wrote:
Hi all,
I could not enter debug state when I set DRCR[0] to b1, And I get the
DSCR[1:0] value is b10
any idea?
DRCR:Debug Run Control Register
DSCR:Debug Status and Control Register
these registers is on page 12.4.12 of Cortex-A8 TRM
The
Added code for new jtag sequence in JLink driver
Tested on LPC2148 and STM32 with both old and new table.
Small changes that might improve stabilitybut it is still unclear why it
sometimes works and sometimes not.
Regards
Magnus
___
Added (BUILD_JLINK==1) condition to us new tables with JLink
Regards
Magnus
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Dirk Behme wrote:
Magnus Lundin wrote:
tangray wrote:
Hi all,
I could not enter debug state when I set DRCR[0] to b1, And I get
the DSCR[1:0] value is b10
any idea?
DRCR:Debug Run Control Register
DSCR:Debug Status and Control Register
these registers is on page 12.4.12 of
Magnus Lundin wrote:
Added (BUILD_JLINK==1) condition to us new tables with JLink
I usually build with both FT2232 and parport enabled (and use both) -
how is that supposed to work with the patch?
If I understood the patch correct, this can only work if both drivers
are converted and
Oyvind [removed some non-used api features of the JTAG field structures]
Laurent [please put them back, they are important]
Laurent,
You are the only one who wants this to remain.
Your request to keep these items sound like a idea that somebody
_thought_ was important, but it turned out
On Wed, 2009-05-06 at 15:50 +0200, Uwe Hermann wrote:
Hi,
On Mon, May 04, 2009 at 11:56:00AM -0700, Zach Welch wrote:
The attached patch should fix the cast alignment warnings caused by
jim.c on platforms with stricter alignment rules.
If you get more problems, please run the builds
On Wed, 2009-05-06 at 16:24 -0700, Zach Welch wrote:
On Wed, 2009-05-06 at 15:50 +0200, Uwe Hermann wrote:
Hi,
On Mon, May 04, 2009 at 11:56:00AM -0700, Zach Welch wrote:
The attached patch should fix the cast alignment warnings caused by
jim.c on platforms with stricter alignment
27 matches
Mail list logo
