I haven't looked into this, but essentially it is a database over what
worked in which version?
when should be svn #. The time the test was run isn't *that* interesting.
W.r.t. gathering these reports. It's harder to get users to run these smoketests
when everything is working fine than when
On May 19, 2009, at 10:42 PM, Zach Welch wrote:
On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote:
On Tuesday 19 May 2009, Dean Glazeski wrote:
changed all 'struct target_s' to 'target_t' to keep things
consistent.
I'd rather do away with all typedefs myself, except maybe
for int
Committed
Thanks!
Michael Fischer + you have tested it now and there is upcoming work in jtag.c,
so get this patch out of the way.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
1) This needs to be broken up into multiple patches.
2) It looked like lots of error handling was removed rather than added
3) Not sure why the mflash code is being changed to use the mg
prefix. What is mg supposed to mean?
4) Lots of gratuitous formatting changes. If we want to do these
I have OpenOCD r1836 and libftdi 0.16.
I have the atmel evaluation board AT91SAM7X-EK, equipped with sam7x256
(we develop 2 boards with sam7x128 and sam7x512).
I work with ubuntu linux 64bit:
$ uname -a
Linux lab7 2.6.27-14-generic #1 SMP Wed Apr 15 19:29:46 UTC 2009
x86_64 GNU/Linux
$
1) This needs to be broken up into multiple patches.
Good point. I know my patch contains 4 logical and 2 style changes.
That's my mistake.
I can make seperate patches but it needs painful time.
I hope to use this one. Should I seperate patches? If the answer is
yes, I'll follow.
2) It looked
Hello:
On Wednesday 20 May 2009 06:36:41 Rick Altherr wrote:
From my cursory reading, everything looks fine and straightforward.
Since you marked this as an RFC, I'll hold off committing until it is
resent to the list.
Rick
Thank you very much for your review, Rick. I asked for
On Tue, 2009-05-19 at 23:17 -0700, Rick Altherr wrote:
On May 19, 2009, at 10:42 PM, Zach Welch wrote:
On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote:
On Tuesday 19 May 2009, Dean Glazeski wrote:
changed all 'struct target_s' to 'target_t' to keep things
consistent.
I'd
Hi all,
I want to get the style guide up-to-date. Here's my plan.
Barring any objections, I will add doc/manual/style.txt by moving the
relevant bits out of openocd.texi. The style guide is for developers
working on the code; the user guide should not need to mention the code.
though that may
2) It looked like lots of error handling was removed rather than added
I only removed target memory write error handling. IMHO, checking
target's memory function (like target-type-write_memory) is too excessive.
All the mflash IO error checked by this patch.
Actually we want all return codes
what is the setup of your jumper J10 (JTAGSEL)!
Try :
- to down the JTAG speed
- to up the TRST / SRST delay
Regards,
Laurent
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Tuesday 19 May 2009, Øyvind Harboe wrote:
I'd rather do away with all typedefs myself, except maybe
for int variants. Ditto that *_t convention.
Anyone feel strongly pro-typedef?
I think that typedefs are useful when a level of indirection is
needed, it is non-trivial to define the
How does mere mortals figure out how to build doxygen docs?
The README points to openocd.texi as the auhtoritiative source
of documentation?
A developer chapter in openocd.texi?
Perhaps this should be built and posted daily like openocd.pdf?
--
Øyvind Harboe
Embedded software and hardware
Xiaofan,
After telnet connect, which monitor command produces this:
Info : accepting 'telnet' connection from 0
TapName| Enabled | IdCode ExpectedIrLen
IrCap IrMask Instr
---||-|||--|--|--|-
Magnus Lundin wrote:
The following patch combines my previous patch with most of Ben's patch.
It can use both EMU_CMD_HW_JTAG2 and EMU_CMD_HW_JTAG3
It defaults to EMU_CMD_HW_JTAG2 so it should work with all interfaces
but EMU_CMD_HW_JTAG3 is recommended by SEgger, you can change the
On Wed, May 20, 2009 at 9:25 PM, Gene Smith g...@chartertn.net wrote:
Xiaofan,
After telnet connect, which monitor command produces this:
Info : accepting 'telnet' connection from 0
TapName | Enabled | IdCode Expected IrLen
IrCap IrMask Instr
On Wed, May 20, 2009 at 10:06 PM, Gene Smith g...@chartertn.net wrote:
So I guess I must use 2.
Yes that is right. For v1/2/3/4, you have to use 2.
Still see occasional segfault on startup (still running r1833 except for
jlink.c patch).
The latest version (1857) seems to be ok, no more
Xiaofan Chen wrote:
On Wed, May 20, 2009 at 10:06 PM, Gene Smith g...@chartertn.net wrote:
So I guess I must use 2.
Yes that is right. For v1/2/3/4, you have to use 2.
Still see occasional segfault on startup (still running r1833 except for
jlink.c patch).
The latest version (1857)
On Wed, May 20, 2009 at 6:30 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
I think that you should first figure out the logic of controlling several
different targets on the same scan chain, with different demands on extra or
no extra RTI, specific numbers of transitions etc, how can they
On Wed, May 20, 2009 at 6:10 PM, Michael Bruck mbr...@digenius.de wrote:
I am all in favor for this change. But I would prefer to eliminate the
cases first where jtag_add_end_state() is called immediately before
jtag_add_*r_scan(..., TAP_INVALID).
On arm11.h:
ARM11_TAP_DEFAULT should not be
Hi
Now when we have almost got the new state table infrastructure in plaec
and working it is time to think ahead.
Shall we retire the 7 step transitions ? No ! expand the founctionallity
to allow user (target) defined state transition tables, the current code
allows that. Maybe not the
I am all in favor for this change. But I would prefer to eliminate the
cases first where jtag_add_end_state() is called immediately before
jtag_add_*r_scan(..., TAP_INVALID).
On arm11.h:
ARM11_TAP_DEFAULT should not be changed. It is used only between the
arm11 and the arm11_dbgtap layer. The
Hello list,
in case of my cygwin build under windows the version.texi
will be created. But in case of Mac OS X not. Any hints
where I can take a look at?
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
One disadvantage of having user defined transition tables is that
it would make hardware implementations of a JTAG master more
tedious. Doable, but more tedious. We have jtag_add_pathmove()
to handle the necessary cases.
What a JTAG master/interface would have to ensure is that it doesn't
go
Hi,
Other alternative to add BDM support on OpenOCD is based it on OSBDM:
http://forums.freescale.com/freescale/board/message?board.id=OSBDM08thread.id=422
This version uses a S08, but I think there is newer source code using
MCF51JM.
Best Regards,
Alan
Hello list,
even the same problem with the 1857 if I use the long tms sequence:
tms_sequence long
Regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Tue, 2009-05-19 at 22:50 -0500, Dean Glazeski wrote:
Hey all,
I ran into this during my random googlings: oocd-quickreference. I
was thinking, this might be something cool to put together as part of
the next release. I'd be willing to help kick it off, just wanted to
see what people
Hey all,
Can anyone give me insight on these files:
openocd.x86_64: E: statically-linked-binary
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: W: devel-file-in-non-devel-package
Hey all,
To one-up it (as is my wont), it would be nice to produce a set of LaTeX
documents that could produce either 1) a complete reference of the TCL
command set or 2) a quick reference, depending on the surrounding
context that the core .tex file gets applied:
Magnus Lundin wrote:
Dean Glazeski wrote:
openocd.x86_64: E: statically-linked-binary
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: W: devel-file-in-non-devel-package
Dean Glazeski wrote:
Hey all,
Can anyone give me insight on these files:
openocd.x86_64: E: statically-linked-binary
/usr/lib64/openocd/ecos/at91eb40a.elf
/usr/lib64/openocd/ecos/at91eb40a.elf
These are *TARGET* files, the package tool you have is *WRONG*HEADED*,
or mis-informed - it
Dean Glazeski wrote:
Magnus Lundin wrote:
Dean Glazeski wrote:
openocd.x86_64: E: statically-linked-binary
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section
/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: W: devel-file-in-non-devel-package
Magnus Lundin wrote:
More of us should be active on places like forum.sparkfun openocd and
really help users, get an understanding of the root problem and bring
that idea back here to the list to solve it.
One suggestion that might help is to Pin a few sticky tags on their forum
We
I'd like to know if OpenOCD support AVR32 (AP7000) processors? I was looking
a tool [1] to write the flash memory of Atmel reference design ATNGW100.
From this maillist history I saw a thread [2] discussing how to add a new
target but no further discussion.
[1]
Duane Ellis wrote:
Dean Glazeski wrote:
Hey all,
Can anyone give me insight on these files:
openocd.x86_64: E: statically-linked-binary
/usr/lib64/openocd/ecos/at91eb40a.elf
/usr/lib64/openocd/ecos/at91eb40a.elf
These are *TARGET* files, the package tool you have is
*WRONG*HEADED*, or
On Wed, 2009-05-20 at 21:43 -0500, Dean Glazeski wrote:
Duane Ellis wrote:
Dean Glazeski wrote:
Hey all,
Can anyone give me insight on these files:
openocd.x86_64: E:
statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf
/usr/lib64/openocd/ecos/at91eb40a.elf
- add doxygen comments to scan commands in jtag.c
- move jtag_add_dr_scan next to interface_jtag_add_dr_scan to keep
these function pairs together
Michael
commit-01-53b89a8.patch
Description: Binary data
___
Openocd-development mailing list
- add 'const' qualifier to function parameters in jtag.c that are not
to be modified or freed by the function
Michael
commit-02-e7704e6.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
- jtag.c: Use single 'for' statement to iterate over list of TAPs in
scan functions
Michael
commit-04-4f198db.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
- jtag.c: remove unused variable 'nth_tap' from DR scan functions
Michael
commit-05-d633f19.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
- jtag.c: consolidate all memory allocations in scan functions in one
block, add out_fields pointer to set stage for further changes
Michael
commit-03-cfc2397.patch
Description: Binary data
___
Openocd-development mailing list
-jtag.c, interface_jtag_add_ir_scan():
- use pointer 'field' instead of scan-fields[nth_tap]
- add assertion to ensure that input data has correct size for TAP's IR
Michael
commit-07-3525e31.patch
Description: Binary data
___
Openocd-development
-jtag.c, interface_jtag_add_dr_scan():
- use pointer 'field' instead of scan-fields[field_count]
- restructure the main loop to clearly separate the two cases: TAP
is not bypassed / TAP is bypassed
- add an assert that each non-bypassed TAP receives at least one field
- add an assert that
- jtag.c, interface_jtag_add_dr_out():
- use pointer 'field' instead of scan-fields[field_count]
- restructure the main loop to clearly separate the two cases: TAP
is not bypassed / TAP is bypassed
(this is to keep the function similar to interface_jtag_add_dr_scan())
- fix bug where
- jtag.c, interface_jtag_add_ir_scan() [1/2]:
- remove temporary scan_size and use tap-ir_length instead
- slight loop restructuring to reduce indentation level
Michael
commit-10-cb32fa6.patch
Description: Binary data
___
Openocd-development
- jtag.c, interface_jtag_add_ir_scan() [2/2]:
- retire variable 'found' and use goto instead
- add comments on loops
Michael
commit-11-506cef0.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Zach Welch wrote:
On Wed, 2009-05-20 at 21:43 -0500, Dean Glazeski wrote:
Duane Ellis wrote:
Dean Glazeski wrote:
Hey all,
Can anyone give me insight on these files:
openocd.x86_64: E:
statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf
On May 20, 2009, at 8:30 PM, Michael Bruck wrote:
- jtag.c, interface_jtag_add_ir_scan() [2/2]:
- retire variable 'found' and use goto instead
- add comments on loops
Michael
commit
-11-506cef0.patch___
Openocd-development mailing list
On May 20, 2009, at 8:29 PM, Michael Bruck wrote:
- add doxygen comments to scan commands in jtag.c
- move jtag_add_dr_scan next to interface_jtag_add_dr_scan to keep
these function pairs together
Michael
commit
-01-53b89a8.patch___
On Feb 23, 2009, at 2:46 AM, Holger Schurig wrote:
When I connected to my target and issue the shutdown command
via telnet, my target immediately freezes. However, I'd like to
use my target device, no matter if openOCD is debugging it or
not.
Ctrl-C doesn't send the target to nirvana,
Committed revision 1870.
On Mar 2, 2009, at 11:27 AM, Øyvind Harboe wrote:
Should a target_read/write_buffer() be a silent no-op or generate an
explicit
error?
I have reason to believe 0 sized elf sections can occur...
Index: C:/workspace/openocd/src/target/target.c
On Wed, 2009-05-20 at 22:23 -0700, Rick Altherr wrote:
On Mar 25, 2009, at 2:54 PM, joern kaipf wrote:
* autodetection if FS or HS device attachted - adapt tck max
* enable adaptive clocking if HS device attached and jtag_khz = 0 in
cfg (not
tested yet)
Note:
The HS devices are
On Thu, May 21, 2009 at 1:27 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, May 21, 2009 at 9:10 AM, Duane Ellis open...@duaneellis.com wrote:
Magnus Lundin wrote:
More of us should be active on places like forum.sparkfun openocd and
really help users, get an understanding of the root
On May 15, 2009, at 11:32 AM, David Brownell wrote:
On Thursday 14 May 2009, Zach Welch wrote:
If anyone knows of patches that have not been applied, please reply
here
with a link into the mailing list archives to the last version
posted:
54 matches
Mail list logo
