This is a second example of how to remove in_handler usage handling
it on the caller side.
This example focuses on a more or less mechanical fix with changing
as little code as possible. From here the code can be cleaned up
significantly, but I'm splitting that into a separate patch for illustrati
Committed.
This is an example of how to rewrite code to not use in_handler.
Getting rid of the in_handler code will greatly simplify the jtag.c code and
increase legibility of the user code. Especially for those that are reading
and not writing that code.
--
Øyvind Harboe
Embedded software an
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
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 th
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 th
Michael Schwingen wrote:
> 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
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 agr
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
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
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
___
Openocd-develo
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
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
200
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
___
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 Sanchez-Palencia
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
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 problem i
Ø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.
>
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
Best Regards,
Ray
___
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 guess the next thing I'm looki
Øyvind Harboe wrote:
> On Wed, May 6, 2009 at 11:50 AM, Laurent Gauch
> wrote:
>
>> Ųyvind Harboe wrote:
>>
>>> On Wed, May 6, 2009 at 11:10 AM, Laurent Gauch
>>> wrote:
>>>
>>>
Yes it could. But giving this out_mask info to the low layer JTAG API can
really help to accel
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 with
On Wed, May 6, 2009 at 12:06 PM, Magnus Lundin 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 structure as we need them
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 s
On Wed, May 6, 2009 at 11:50 AM, Laurent Gauch
wrote:
>
> Ųyvind Harboe wrote:
>>
>> On Wed, May 6, 2009 at 11:10 AM, Laurent Gauch
>> 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 accelerati
Øyvind Harboe wrote:
> On Wed, May 6, 2009 at 11:10 AM, Laurent Gauch
> 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
On Wed, May 6, 2009 at 11:10 AM, Laurent Gauch
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 accept at face value.
I
I'm trying to figure out why bitbang fails and ft2232 reportedly
works with arm11.
The attached patch makes a direct transition from shift
to the end state rather than going via pause, which should
line the bitbang driver up more closely with ft2232.
To me this seems like a sensible change and is
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
JTA
Hi all,
The attached patch adds a autoconf check to use libtool and rewrites the
Makefile.am automake inputs to create libtool libraries. These are
linked into a new libopenocd library that is installed and used by the
openocd application.
Future patches can install those header files that conta
> 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
To clarify a bit:
this functionality can be synthesized by a helper function, but it unecessarily
complicates the lower levels and the normal use case of this API.
Nothing is "removed" in that regard.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.c
> In_handler could be very useful when we will add pure JTAG Boundary
> Scan support in OpenOCD.
Anything that in_handler can do can be done from the calling code.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
__
> 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
__
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. Removin
On May 6, 2009, at 10:20, Zach Welch wrote:
> 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 ch
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
http
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
http://consulting.zy
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
> >
> >
> > ../../
38 matches
Mail list logo
