4
>
> Some (all?) V6 firmware on the J-Link adapter fails to step
> the TAP unless the first EMU_CMD_HW_JTAG3 command has 8 bits
> rather than 7, immediately after adapter power-up. Add a hack
> to pad out to 8 bits, the first time only.
>
I am hoping todo some usb traces today using seggar's
thank you!
I want to make the OpenOCD more easier to use, for us, who are not so
professional. (students,newbie). so my idea,just a idea, is to bind the
OpenOCD with Eclipse.
And my aim is to make a easy-use tool (maybe there are already some good
free tools,but,sorry I don't know) for debugging
On Mon, 2009-06-01 at 06:12 +0200, Michael Bruck wrote:
> On Mon, Jun 1, 2009 at 6:00 AM, David Brownell wrote:
> > On Sunday 31 May 2009, Michael Bruck wrote:
> >> and I imagined how much worse that that would get once we mix in
> >> struct and enum.
> >
> > Heck, I imagined how much *better* it
On Sun, 2009-05-31 at 21:00 -0700, David Brownell wrote:
> On Sunday 31 May 2009, Michael Bruck wrote:
> > and I imagined how much worse that that would get once we mix in
> > struct and enum.
>
> Heck, I imagined how much *better* it would be, especially
> if the whitespace/layout bugs got fixed.
On Mon, Jun 1, 2009 at 6:00 AM, David Brownell wrote:
> On Sunday 31 May 2009, Michael Bruck wrote:
>> and I imagined how much worse that that would get once we mix in
>> struct and enum.
>
> Heck, I imagined how much *better* it would be, especially
> if the whitespace/layout bugs got fixed. ;)
On Sunday 31 May 2009, Michael Bruck wrote:
> and I imagined how much worse that that would get once we mix in
> struct and enum.
Heck, I imagined how much *better* it would be, especially
if the whitespace/layout bugs got fixed. ;)
___
Openocd-deve
On Sunday 31 May 2009, Michael Bruck wrote:
> > If I see "foo_t" I have no idea what kind of thing it is.
> > If I see a "struct foo" there's no such confusion.
> >
> > Ergo, "foo_t" has obscured.
>
> Yes, I read that argument on this list before. By this logic most C++
> code in existence is doom
On Sunday 31 May 2009, Zach Welch wrote:
> This series has been committed as r1972-1977, using the new version for
> patch #4 containing the update suggested by Nicolas Pitre.
>
> Cheers,
Thanks. Next up: the "JTAG Commands" chapter.
There will be some questions forthcoming from me, there...
On Mon, Jun 1, 2009 at 5:31 AM, Zach Welch wrote:
> On Mon, 2009-06-01 at 05:16 +0200, Michael Bruck wrote:
>> On Mon, Jun 1, 2009 at 4:41 AM, David Brownell wrote:
>> > On Sunday 31 May 2009, Michael Bruck wrote:
>> >> The 'struct foo_s' syntax is code bloat that obscures the actual
>> >> algori
On Mon, 2009-06-01 at 05:16 +0200, Michael Bruck wrote:
> On Mon, Jun 1, 2009 at 4:41 AM, David Brownell wrote:
> > On Sunday 31 May 2009, Michael Bruck wrote:
> >> The 'struct foo_s' syntax is code bloat that obscures the actual
> >> algorithms. 'foo_t' is shorter.
> >
> > Disagree about obscurin
On Mon, 2009-06-01 at 05:14 +0200, Michael Bruck wrote:
> On Mon, Jun 1, 2009 at 4:35 AM, Zach Welch wrote:
> > On Mon, 2009-06-01 at 04:15 +0200, Michael Bruck wrote:
[snip]
> > I think 'struct foo' is much more clear when reading and writing code.
> >
> >> Doxygen seems to recognize the foo_s an
On Mon, 1 Jun 2009, Michael Bruck wrote:
> On Mon, Jun 1, 2009 at 4:41 AM, David Brownell wrote:
> > On Sunday 31 May 2009, Michael Bruck wrote:
> >> The 'struct foo_s' syntax is code bloat that obscures the actual
> >> algorithms. 'foo_t' is shorter.
> >
> > Disagree about obscuring. And "short
On Sun, 2009-05-31 at 23:02 -0400, Duane Ellis wrote:
> duane> Either (A) - is done via a cascade of #include files -
> effectively what
> duane> we have today, #include , and is shown below via
> "arm11.c"
>
> zach> That simply is not true. I spent a lot of time cleaning up things,
> and
> zac
On Mon, Jun 1, 2009 at 4:41 AM, David Brownell wrote:
> On Sunday 31 May 2009, Michael Bruck wrote:
>> The 'struct foo_s' syntax is code bloat that obscures the actual
>> algorithms. 'foo_t' is shorter.
>
> Disagree about obscuring. And "shorter" doesn't matter here.
>
> If I see "foo_t" I have n
On Sun, 2009-05-31 at 15:03 -0700, David Brownell wrote:
> Remove broken whitespace ... mostly at end of line, but
> also in some cases blocks of inappropriate empty lines.
>
> And spell "comamnd" right. :)
> ---
> src/flash/avrf.c | 108 ++--
> src/flash/lpc288x.c | 94 +---
On Mon, Jun 1, 2009 at 4:35 AM, Zach Welch wrote:
> On Mon, 2009-06-01 at 04:15 +0200, Michael Bruck wrote:
>> The 'struct foo_s' syntax is code bloat that obscures the actual
>> algorithms. 'foo_t' is shorter.
>
> I assume you prefer u32 over uint32_t, then? ;) Nevermind
Yes I do.
> I thin
2009/6/1 chenee543216 :
> I always have a question, that, how to debug the Kernel run on my board with
> OpenOCD in SOURCE LEVEL??
> you know, I only could get the disassemble, For me it's hard to follow the
> system call and debug the detail of Kernel
>
> could I bind OpenOCD with some IDE (eclips
hi all:
I always have a question, that, how to debug the Kernel run on my board with
OpenOCD in SOURCE LEVEL??
you know, I only could get the disassemble, For me it's hard to follow the
system call and debug the detail of Kernel
could I bind OpenOCD with some IDE (eclipse?)
ps
I know,
duane> Either (A) - is done via a cascade of #include files -
effectively what
duane> we have today, #include , and is shown below via
"arm11.c"
zach> That simply is not true. I spent a lot of time cleaning up things,
and
zach> the tree of headers that you show below is a _gross_ improvement
z
On Sun, 2009-05-31 at 16:37 -0700, Zach Welch wrote:
> Hi all,
>
> The following things nagged at me when I did the target_type clean-up:
>
> 1) Remove redundant structure typedefs:
> a) Entails the following steps (for each named struct "type"):
> i) s/^typedef struct type_s/struct typ
On Sunday 31 May 2009, Michael Bruck wrote:
> The 'struct foo_s' syntax is code bloat that obscures the actual
> algorithms. 'foo_t' is shorter.
Disagree about obscuring. And "shorter" doesn't matter here.
If I see "foo_t" I have no idea what kind of thing it is.
If I see a "struct foo" there's
On Mon, 2009-06-01 at 04:15 +0200, Michael Bruck wrote:
> The 'struct foo_s' syntax is code bloat that obscures the actual
> algorithms. 'foo_t' is shorter.
I assume you prefer u32 over uint32_t, then? ;) Nevermind
I think 'struct foo' is much more clear when reading and writing code.
> Dox
The 'struct foo_s' syntax is code bloat that obscures the actual
algorithms. 'foo_t' is shorter.
Doxygen seems to recognize the foo_s and foo_t version as one an the
same, I don't see what problem you have there. However it will just as
happily accept foo_t only, like in
typedef struct {} foo_t;
On Sun, 2009-05-31 at 16:37 -0700, Zach Welch wrote:
> Hi all,
>
> The following things nagged at me when I did the target_type clean-up:
>
> 1) Remove redundant structure typedefs:
> a) Entails the following steps (for each named struct "type"):
> i) s/^typedef struct type_s/struct typ
On Sun, 2009-05-31 at 21:31 -0400, Duane Ellis wrote:
> duane> [about target_types.h]and "openocd/types.h"
>
> I do like what you have done with "target_types.h" - Yes, absolutely -
> good idea, I think I said it wrong, I'm sure I'll make that mistake again.
>
> zach> You want to expose ever
On Mon, Jun 1, 2009 at 7:36 AM, Zach Welch wrote:
> After my patch series today, I discovered that I am finally able to
> flash my custom target reliably from the latest trunk.
>
> This is the _first_ time that I have seen success with a recent build.
> Personally, I consider this a major breakthr
On Sunday 31 May 2009, Nicolas Pitre wrote:
> I'd suggest this instead:
>
> git svn clone -s svn://svn.berlios.de/openocd
>
> The -s tells git-svn to assume svn standard layout for trunk, branches
> and tags, and then converts them into proper git branches and tags
> automatically.
Goo
On Sun, 31 May 2009, David Brownell wrote:
> On Sunday 31 May 2009, Zach Welch wrote:
> > While I think this would help the code and documentation a
> > lot, I would even go further to suggest "s/_s//" from all struct names.
>
> Most certainly. I realize there are coding conventions that
> p
duane> [about target_types.h]and "openocd/types.h"
I do like what you have done with "target_types.h" - Yes, absolutely -
good idea, I think I said it wrong, I'm sure I'll make that mistake again.
zach> You want to expose every struct name to every module? No thanks.
We do that now - in a m
On Sun, 31 May 2009, David Brownell wrote:
> Various updates, mostly small/formatting changes:
>
> * Small content tweaks:
> - Re-title: "OpenOCD User's Guide".
> - For users, URLs for latest doc and SparkFun forum
> - Mention GIT-SVN
You suggest:
git svn clone svn://svn.
On Sunday 31 May 2009, Zach Welch wrote:
>
> 1) Remove redundant structure typedefs:
> a) Entails the following steps (for each named struct "type"):
> i) s/^typedef struct type_s/struct type_s/
>ii) s/^} type_t;/};/
> iii) s/type_t/struct type_s/
>iv) Fix any messe
On Sunday 31 May 2009, Zach Welch wrote:
> I apologize if any problems crop
> up, but I will report my own status in a new thread following this one.
> Suffice it to say that I believe it unlikely there will be problems.
Nothing broke on my x86_64/Linux sanity check, prior
to posting those patches
Hi all,
The following things nagged at me when I did the target_type clean-up:
1) Remove redundant structure typedefs:
a) Entails the following steps (for each named struct "type"):
i) s/^typedef struct type_s/struct type_s/
ii) s/^} type_t;/};/
iii) s/type_t/struct type_s/
Hi all,
After my patch series today, I discovered that I am finally able to
flash my custom target reliably from the latest trunk.
This is the _first_ time that I have seen success with a recent build.
Personally, I consider this a major breakthrough in terms of stability.
After over a month of
Hi all,
Last night, I committed patches to hide the definition of the
target_type_s structure from out-of-module users. This was done over
the course of a few series of patches. I apologize if any problems crop
up, but I will report my own status in a new thread following this one.
Suffice it to
On Sun, 2009-05-31 at 12:15 -0400, Duane Ellis wrote:
> zach> Move definition of 'struct target_type_s' into new 'target_type.h'
> file.
>
> Hmm,
>
> why would this not be in:
>
> #include
Why put it in its own file? Encapsulation, that's why.
> Or something like that, I specificall
On Sun, 2009-05-31 at 15:17 -0700, David Brownell wrote:
> On Sunday 31 May 2009, Zach Welch wrote:
> >
> > > What I would like to see is that we push funky rules into board/target
> > > config
> > > files and keep the reset_config implementation as simple as possible.
>
> One reason I dislike t
Some (all?) V6 firmware on the J-Link adapter fails to step the TAP unless
the first EMU_CMD_HW_JTAG3 command has 8 bits rather than 7, immediately
after adapter power-up. Add a hack to pad out to 8 bits, the first time
only.
Index: src/jtag/jlink.c
==
On Sunday 31 May 2009, Zach Welch wrote:
>
> > What I would like to see is that we push funky rules into board/target
> > config
> > files and keep the reset_config implementation as simple as possible.
One reason I dislike that model is the knowledge that
configuration/installation errors are o
Uplevel the arch commands to be a chapter; they really
don't fit in the "general commands" category.
---
doc/openocd.texi | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
Uplevel the arch commands to be a chapter; they really
don't fit in the "gene
Fix minor goofage in previous doc updates:
* The ETM dummy driver name is "dummy" not "etm_dummy";
re-alphabetize.
* DCC trace message mode "charmsg" is a format type
(and what Linux needs)
---
doc/openocd.texi | 27 +++
1 file changed, 15 insertions(+
Various updates, mostly small/formatting changes:
* Small content tweaks:
- Re-title: "OpenOCD User's Guide".
- For users, URLs for latest doc and SparkFun forum
- Mention GIT-SVN
* Fix some front-matter goofage, matching texinfo docs:
- "paragraphindent" location matters
-
Whitespace fixes.
---
src/target/cortex_m3.c | 358 +-
src/target/target_request.c | 48 ++---
2 files changed, 203 insertions(+), 203 deletions(-)
Whitespace fixes.
---
src/target/cortex_m3.c | 358 +-
Split out OSK5912 board support from the omap5912 target config, and make
it pass sanity checks on my (Rev C/original) hardware:
- Fix syntax error ("-irlen" not "irlen")
- Provide real TAP ids for the ARM926ejs and the C55x dsp
- Label both CPUs appropriately (DSP, ARM)
- List both flash chip
Hi,
Xiaofan Chen pisze:
> You commented out all of the following for your script. Should I
> uncomment them for flashing?
>
> #$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x0020
> -work-area-size 0x4000 -work-area-backup 0
>
> #flash bank tms470 0x0 0x2 0 0 0
> #flash ba
zach> Move definition of 'struct target_type_s' into new 'target_type.h'
file.
Hmm,
why would this not be in:
#include
Or something like that, I specifically mean a file with a bunch of forward
structure definitions, really simple - the file would not have 'structure
contents' - o
Hi list,
I've got a new problem. When I use the command `flash probe 0' after
telnet to the server. It cannot probe the flash.
My core is arm926ejs and flash used CFI interface, so go into the code
and I found something is not normal.
# my flash config
flash bank cfi 0x1000 0x0080 2 2 0
On Sat, 30 May 2009, Peter Denison wrote:
> On Sat, 30 May 2009, Magnus Lundin wrote:
>
>> It looks like you are using jtag_khz 0, this means adaptive clocking with
>> the RTCK signal. This work for LPC3148 that has a RTCK signal, but as far as
>> I can find there is no RTCK singal on the TMS4
On Sun, 2009-05-31 at 10:50 +0200, Øyvind Harboe wrote:
> > It sounds like the problem relates to the fact that reset_config will
> > not work for all combinations of interfaces and targets. All of this
> > discussion makes me think that OpenOCD needs two reset_config commands:
> > one for the int
> It sounds like the problem relates to the fact that reset_config will
> not work for all combinations of interfaces and targets. All of this
> discussion makes me think that OpenOCD needs two reset_config commands:
> one for the interface and one for the target. With knowledge of both,
> OpenOC
On Sun, May 31, 2009 at 4:32 PM, Krzysztof Dziuba
wrote:
>> I have not tried flashing (I do not want to brick the board) and real
>> debugging yet (as such, not using the patch). Did you try
>> flashing the TMS470 with OpenOCD?
>>
> Flashing works, watch out on security keys!
Yeah that is the thi
On Sat, 2009-05-30 at 17:18 -0400, Duane Ellis wrote:
> All,
> (especially david & zach, you seem to do this very well).
>
> Yes, this is some what "off-topic" for this list, but it is on topic
> because the list wants "small more reviewable patches". To that end, I'm
> looking for a better way
On Sun, 2009-05-31 at 10:13 +0200, Øyvind Harboe wrote:
> > Been there, done that. Reread what I wrote: the issue
> > is the *board* not wiring it.
> >
> > The current code to check "is RTCK supported" only
> > addresses the JTAG adapter. There's no way for it
> > to discern the case which I lis
Xiaofan Chen pisze:
> On Wed, May 27, 2009 at 2:33 AM, Krzysztof Dziuba
> wrote:
>> I attached my cfg file, I think it needs to be polished before including it
>> to the official configurations, however it works for me.
>> There is also patch which fix big endian issue. It was created by some othe
> Been there, done that. Reread what I wrote: the issue
> is the *board* not wiring it.
>
> The current code to check "is RTCK supported" only
> addresses the JTAG adapter. There's no way for it
> to discern the case which I listed: adapter supports
> it, but board does not.
So why can't/shoul
55 matches
Mail list logo
