Basic SoC configuration for TI DaVinci DM355 chips. No declarations
or utilities for things you need during board bringup or debricking:
setting up PLLs, enabling clocks, configuring memory controllers, or
programing NANDs using 1-bit or 4-bit HW ECC. Yet...
---
src/target/target/ti_dm355.cfg
Get rid of some compile warnings if the oocd trace is included:
the bytes_read is a size_t.
--- src/target/oocd_trace.c (revision 1625)
+++ src/target/oocd_trace.c (working copy)
@@ -98,7 +98,7 @@
if ((bytes_read = read(oocd_trace-tty_fd,
On Thursday 07 May 2009, Øyvind Harboe wrote:
Committed.
Hmm, but with DOS line ends (CRLF) ... is that
why folk are sending patches as attachments??
Thanks for merging that.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
One of the patches since the merge of the ti_dm355.cfg line-end
update seems to have broken some aspect of scan chain discovery.
See the openocd server startup transcript below, with scan_chain
command debug output. (FWIW, using with an Olimex ft2232 adapter.)
The recent TAP changes forced a
On Thursday 07 May 2009, Øyvind Harboe wrote:
On Thu, May 7, 2009 at 6:38 PM, David Brownell davi...@pacbell.net wrote:
One of the patches since the merge of the ti_dm355.cfg line-end
update seems to have broken some aspect of scan chain discovery.
See the openocd server startup transcript
On Thursday 07 May 2009, Magnus Lundin wrote:
Which suggested a potential workaround here: slow TCK down even
more. Sure enough, at 750 KHz the startup doesn't fail...
Is it possible to increase the jtag speed after the inital scan chain
identification has succeded at 750 khz?
To 1.5
On Thursday 07 May 2009, Øyvind Harboe wrote:
Can you do a bisection to figure out which version broke you?
If this were using git, I'd have done it already ... is the
magic SVN command svn switch -r REVISION? At least there's
only one development sequence, no branch merges to resolve.
On Thursday 07 May 2009, David Brownell wrote:
http://search.cpan.org/~infinoid/App-SVN-Bisect-0.8/bin/svn-bisect
Well that was a waste of a few hours. It got into a mode
where it kept producing unbuildable trees, with refs to
jtag_add_dr_scan_now() added in r1629 but not, so far as
a quick
On Thursday 07 May 2009, Zach Welch wrote:
If this were using git, I'd have done it already ... is the
magic SVN command svn switch -r REVISION? At least there's
only one development sequence, no branch merges to resolve. ;)
svn will probably do this *MUCH* slower than git with a
On Thursday 07 May 2009, Martin Panter wrote:
I never used git bisect so I don't know exactly how it works.
git bisect --help summarizes:
git bisect start
git bisect bad ... assuming current is broken
git bisect good revid ... some known-good version
Then
On Friday 08 May 2009, Anders Montonen wrote:
If I remember the USB spec correctly, the lowest achievable round-trip
time (ie. one OUT transfer followed by one IN transfer) is two
milliseconds for low- and full-speed devices.
Depends on the implementation of the host controller driver
and
On Friday 08 May 2009, Øyvind Harboe wrote:
If someone has a bug/regression that comes first though.
FYI I'm having a hard time reproducing the specific failures
I reported before. I'm not sure what's going on. The 1.5 MHz
rate seems to work, 750 KHz not needed. And the 3 MHz isn't
working
On Friday 08 May 2009, Zach Welch wrote:
http://www.unicom.com/pw/reply-to-harmful.html
That's what I was going to send. ;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Friday 08 May 2009, Rick Altherr wrote:
On May 8, 2009, at 10:06 AM, David Brownell wrote:
Might it also be appropriate to point out that some
patches get directly applied to SVN, without any
opportunity for mailing list discussion or review?
I'd rather we stop that from happening
On Friday 08 May 2009, Zach Welch wrote:
Even assuming he used a branch, there is no way for any one person can
test architectural changes in one.
Not so. The testing will be limited ... but that's a good
reason to use branches, in whatever SCM is used.
Stuff would be broken in the trunk
This is the original DaVinci chip. When you read that
the OMAP3 has some DaVinci technology, it's from here.
Bits easily seen at the JTAG level include ICEpick v3
and the C64x+ DSP ... somehow I think it'll be a long
time before that DSP gets OpenOCD support!
---
Minor whitespace fixes for ETB and ETM, mostly removal of needless
blank lines and space-at-end-of-line. A few if( -- if ( and
additions of blank lines after declaration blocks.
---
src/target/etb.c | 53 +++--
src/target/etb.h |2 +-
So there I am, trying to do basic PLL init code using TCL.
All I have to do is read a register, modify the result, and
write it back ... write a register ... read a register and
do something based on a bitfield ... etc. Not what I'd call
pretty TCL code (is there such a thing?), but workable.
On Saturday 09 May 2009, Magnus Lundin wrote:
The other to trick is to prefix openocd commands with ocd_ to tell the
tcl interpretr to grab openocd output as tcl input.
set v [ocd_mdw 0]
0x: e59ff04c
0x: e59ff04c
puts $v
0x: e59ff04c
split $v
Needed to enable builds on Ubuntu Intrepid x86_64 ...
---
src/target/arm11.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -1402,7 +1402,7 @@ int arm11_run_algorithm(struct target_s
for (size_t i = 0; i 16; i++)
{
More whitespace fixups:
- undesirable blank lines
- whitespace at end-of-line
- if(X not if (X; ditto for(X, switch(X, etc
For many of the ARM files. Clean code is happy code.
More whitespace fixups:
- undesirable blank lines
- whitespace at end-of-line
- if(X not if (X; ditto
On Monday 11 May 2009, Øyvind Harboe wrote:
I'm using a single callback function prototype w/4 arguments. Sometime
an argument is an int's other times a pointer,
Ugly...
If it has to be a pointer sometimes, make it *always* a pointer.
You can generally convert int-pointer without losing bits,
On Monday 11 May 2009, Øyvind Harboe wrote:
so I could either go with a union or these fancy games.
How about using a design that doesn't rely on type punning?
It'll be more clear to read/understand, and less fragile for
folk using other systems (e.g. 64-bit) and for developers.
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I think we should be extremely careful about defining public interfaces.
Defining is less of an issue than committing to... :)
Especially since the JTAG API still (yes still! the hard bits are done
though) needs work cleanup.
Again I'll mention
On Tuesday 12 May 2009, Øyvind Harboe wrote:
Could we make an interface driver in OpenOCD that would
be able to use the urjtag device layer?
I had similar thoughts. I thought folk more expert in
JTAG would be better to explore such things. There's
this Øyvind guy at your company, for example
On Tuesday 12 May 2009, Øyvind Harboe wrote:
Another thing I'd like to see is JTAG over TCP/IP. OpenOCD
would implement a TCP/IP server TCP/IP interface...
That may seem like a non-sequitor but JTAG over TCP/IP *is*
another interface to OpenOCD which this thread is about. Or?
JTAG over
On Tuesday 12 May 2009, Nicolas Pitre wrote:
On Tue, 12 May 2009, David Brownell wrote:
On Tuesday 12 May 2009, Nicolas Pitre wrote:
The Kirkwood bootrom expects 4-bit ECC from NAND. This adds
4-bit ECC computation to the NAND support and uses it with SheevaPlug.
Hmm, from
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I don't know when the cats can be herded into a 0.2 release
at this point, but I'm pretty sure it's a month away at least.
Hmm, if you don't know ... then who could?
The process *does* seem, for now, as if it's largely
commit patches to SVN without
On Tuesday 12 May 2009, Zach Welch wrote:
On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote:
[snip]
There seems to be no strong reason that OpenOCD should
always need to be told here's the only scan chain you
should expect to use ... when it could instead just
look at the scan
On Tuesday 12 May 2009, Rick Altherr wrote:
On May 12, 2009, at 3:36 PM, David Brownell wrote:
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I don't know when the cats can be herded into a 0.2 release
at this point, but I'm pretty sure it's a month away at least.
Hmm, if you don't
On Tuesday 12 May 2009, Magnus Lundin wrote:
David Brownell wrote:
Zack's list seemed useful in terms of having some
kind of direction be defined. But that's distinct
from defining release criteria, or merge criteria.
The old list, or the new rebuild everything into loadable
modules
Right. I think some patches should certainly be able
to fit into the keep that in the -next queue category.
Effective review is probably not easy here; who knows
JTAG well enough to contribute non-cosmetic feedback?
Actually, a fair number of us _do_ know JTAG fairly well.
That's
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I've been thinking about whether some helper fn's to
use 32 bit arrays instead of 8 bit input/output might make sense.
Why 32 bits instead of e.g. just plain unsigned long?
I know the bit vector utilities in Linux use unsigned long,
which mostly
On Wednesday 13 May 2009, Øyvind Harboe wrote:
If you have any problems please report them.
All known functional and performance regressions since 1606
are now fixed in svn head.
Current GIT head no longer starts up correctly on dm355.
It should find three TAPs: ICEpick, ARM926ejs, ETB11.
Hmm, this is quite squirrely. I had done a make clean
then rebuilt before reporting the failures ... but a build
which previously failed, has just started to work.
On Wednesday 13 May 2009, Øyvind Harboe wrote:
Current GIT head no longer starts up correctly on dm355.
It should find three
On Wednesday 13 May 2009, Øyvind Harboe wrote:
On Wed, May 13, 2009 at 11:01 PM, Nicolas Pitre n...@cam.org wrote:
On Wed, 13 May 2009, David Brownell wrote:
When I tried -d 3 it suddenly worked, and has worked
again since. Note -- this is with *NO* rebuild, and
using an executable
On Thursday 14 May 2009, Nico Coesel wrote:
Anyway, if your flash is 8 bit, then your bus must be
8 bits wide.
Not true; there *is* support, e.g. in Linux, for hooking
up two 8-bit NOR chips in parallel. I think one of the
ideas is to improve the read/write bandwidth.
It is not clear
On Thursday 14 May 2009, Paul Thomas wrote:
mww and mdw only work to for the first 32k
But I used them just today to reference an address
up around 0x01c40800, which is much higher than that.
So that can't be the issue...
I do see that BUG: unknown debug reason: a lot
(almost always with 0xF)
On Thursday 14 May 2009, Zach Welch wrote:
If you are still willing continue in this role, I would like to see you
document the release processes (perhaps in doc/manual/releases.txt?) and
inform the rest of us what we need to do to make 0.2.0 a reality.
Heck ... even if you're not willing, I
On Thursday 14 May 2009, Paul Thomas wrote:
Your a busy guy David. Last we spoke you figured out the missing bit to make
some of v4l stuff work with arm.
Nah, that was just remembering old USB discussions that
seem to have gotten dropped by V4L people. You were the
guy who finally closed that
On Thursday 14 May 2009, Zach Welch wrote:
I think that these links catapult The List
beyond a mere TODO or task list. It has started to provide references
to explain how the items got there in the first place, and I would like
to see it grow further into a means of outlining the progress of
On Thursday 14 May 2009, Zach Welch wrote:
Re Why, IMO it might suffice to say that after four or five
months, lots of bugs have been fixed and features added, so
it's just time to clean up the rough spots and declare victory
over some stable code.
I think the most pressing reason
On Thursday 14 May 2009, Zach Welch wrote:
One point to make here is the conflicting desires of a release manager
and developers. At their extremes, the former would have us making
stable releases every night, while the later would have us working madly
on the trunk (and to heck with
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:
https://lists.berlios.de/pipermail/openocd-development/2009-May/006282.html
but here's a tweaked
On Wednesday 13 May 2009, David Brownell wrote:
- Another might be that the ft2232 or JTAG code isn't
robustly initializing ... so it's inheriting some
external state that it shouldn't, and getting confused.
I think the second is most likely. I do remember poking
at the device
On Friday 15 May 2009, Rick Altherr wrote:
Attachments are annoying, but they avoid lots of odd issues that crop
up when email clients get too eager to help. Things like trailing
spaces and tab to space conversion tends to happen. Attachments are
preserved much better in general.
On Friday 15 May 2009, Dean Glazeski wrote:
What I wanted to know is if there is a need
for some one to poke through the documentation, aka openocd.texi, to
look for grammatical and spelling errors as well as places where further
explanation may be a good thing. I don't know if anyone is
On Sunday 17 May 2009, Duane Ellis wrote:
FYI - I wrote the original JimTCL memory functions here last year, sadly
my documentation level sort of sucks eh?
Documentation? Didn't even know that tcl/* stuff existed. :)
There aren't even any users of the tcl/* stuff in any of
the existing cfg
For reference, this little utility:
# mrw: memory read word, returns value of $reg
proc mrw {reg} {
set value
ocd_mem2array value 32 $reg 1
return $value(0)
}
works fine in my tree, which is still at r1793.
... and yes, I'd be all for removing that hack which
morphs cmd
On Sunday 17 May 2009, Duane Ellis wrote:
david Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example)
daviddefines a global AT91C_ID ... which strongly presumes that there's
david only one at91 family chip, since those IDs vary between chips.
In general, atmel has a single set
Doc should at least mention the ETM and ETB support found
on some ARM chips. Also include a convention about naming
the ETB tap.
NOTE that (a) I suspect this isn't widely used yet, even
though it's kind of neat, and (b) in some cases the ETM
parameters can be detected from a module query, so
Replace get_target_by_num() with get_target():
- Allows target names, not just numbers ... numbers are awkward
for config scripts, given for example a system with several
CPUs or flash chips.
- Slightly shrinks most call sites by removing strtoul() calls.
- Use the same error message
It's the faster mode that's potentially less safe,
not the slower one.
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -2591,7 +2591,7 @@ int arm7_9_register_commands(struct command_context_s *cmd_ctx)
register_command(cmd_ctx, arm7_9_cmd, dbgrq, handle_arm7_9_dbgrq_command,
On Sunday 17 May 2009, Michael Bruck wrote:
- jtag_command_t **last_cmd;
- last_cmd = jtag_get_last_command_p();
-
- *last_cmd = cmd_queue_alloc(sizeof(jtag_command_t));
- (*last_cmd)-next = NULL;
- last_comand_pointer = ((*last_cmd)-next);
-
On Sunday 17 May 2009, Rick Altherr wrote:
Rather than combine them, I'd like to see jtag_queue_command() enforce
validation of the command to be enqueued. Then the patterns would be:
cmd = cmd_queue_alloc();
cmd-type = JTAG_SCAN;
Then how about passing JTAG_* to the allocator?
Move description of the working area setup from the description
of the old deprecated syntax to go with $TARGET configure calls.
Mention that the ARM DCC download support needs working area.
Move description of the working area setup from the description
of the old deprecated syntax to go with
On Sunday 17 May 2009, Michael Bruck wrote:
I did not primarily want to compact code but separate layers. The
function wraps the queue manipulation. The data structure
initialization itself is much more code than just the type field so I
don't like the idea of tearing it apart.
I understand.
The following are some notes I put together about the nand
commands based on reading the source code.
I plan to turn them into documentation sometime later, maybe by this
time next week. I've seen no documentation on the NAND commands; that
seems like a significant omission.
Meanwhile I thought
On Sunday 17 May 2009, Strontium wrote:
Pic32 has 2 debug interfaces. 4 Wire JTAG. And a pin count compressed
version of Jtag which is serialised over 2 wires (ICSP). The protocol
is the same as JTAG, the electrical interface is the only thing that
differs. 2 wire mode should be able
On Friday 15 May 2009, Øyvind Harboe wrote:
So apply this patch?
Can anyone test?
jtagpatch.txt
It failed for me on an ft2232 device.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Monday 18 May 2009, Dean Glazeski wrote:
Do you mean the target_type_s and target_s structures? I think there may be
some others too like the arm7_9_common_s struct. I'm commenting up the
arm7_9_common_s struct as I go too.
Yes, those interfaces. Once those get properly documented,
their
Minor NAND updates:
- Comment which IDs are museum IDs: obsolete first-gen parts,
some with IDs that are reused with newer parts, 256-byte pages.
Linux doesn't support these by default, and OpenOCD rejects
the 256-byte pages.
- Recognize Micron as a NAND manufacturer.
- For nand
On Tuesday 19 May 2009, Øyvind Harboe wrote:
I don't know anything about nand, but I'll be happy to commit this if
you believe the chances of regressions are slight.
Do it, then.
___
Openocd-development mailing list
The cosmetic cleanups should IMO just merge.
On Tuesday 19 May 2009, Michael Bruck wrote:
patch 01 is a rather large one that renames the function arguments
'num_fields' and 'fields' into 'in_num_fields' and 'in_fields'
The rationale here is that almost all of these functions take some
input
On Monday 18 May 2009, Øyvind Harboe wrote:
Should we make the old tms sequences default for 0.2?
Not unless there's a complete failure of testing, or
they prove to be deeply flawed, IMO.
Plan on using the new ones, fixing them (e.g. merging the
fix Spencer sent earlier today), and getting a
On Monday 18 May 2009, Zach Welch wrote:
The tactical goal of each release should to be focus on delivering a
product with steadily increasing stability and device support (whether
host, target, or interface).
I can't quite imagine what other goals might be. ;)
So ... releases every three
On Tuesday 19 May 2009, Wookey wrote:
2) base.cfg just specifies the default port info:
-
telnet_port
gdb_port
tcl_port
-
But if I don't put this in I get warning messages about how these are
not specified- using defaults. Is that really necessary? Shouldn't it
On Tuesday 19 May 2009, Rick Altherr wrote:
We, as a community, seem to have adopted C99. As such, using C99
style declarations inside a block is fine. In some cases it can
really simplify the flow of the code.
In that case let's make the declarations stand out properly
code
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
On Monday 18 May 2009, Nicolas Pitre wrote:
The following are some notes I put together about the nand
commands based on reading the source code.
I plan to turn them into documentation sometime later, maybe by this
time next week. I've seen no documentation on the NAND commands; that
I've tripped across several bugs caused by bad printf format strings.
This is foolish, since GCC will tell about them when functions have
proper annotations.
This patch adds annotations to the key command_*() helper functions.
And then fixes the bugs that turned up. Test builds on Linux:
-
On Thursday 21 May 2009, Zach Welch wrote:
(NOTE that the armel build turned up *LOTS* of unrelated bugs, not fixed
here. Biggest: abusing u8 *ptr by *((u32 *)ptr) = ... loses badly,
since ARM doesn't guarantee unaligned reads work. That idiom is used
all over the place in JTAG buffer
On Thursday 21 May 2009, Rick Altherr wrote:
I believe the fix for
off_t should be portable, but I'm less certain of the struct timeval
fix.
The timeval fix looks like it reverses a fix I needed:
pld.c: In function ‘handle_pld_load_command’:
pld.c:194: error: format ‘%i’ expects type
On Thursday 21 May 2009, Wookey wrote:
And no-one has said anything about the important issue I wanted to get
some feedback on: how best to split up config files. Perhaps I should just
send in a patch and see what people have to say about it?
Yes please. I have some DaVinci DM355 EVM board
On Thursday 21 May 2009, Michael Fischer wrote:
It looks that these JTAG interfaces have not the same behaviour.
One point could be the RESET signals SRST and TRST. Here the
FT2232 can set both signals at the same time, which I think
is used too.
Yeah, I noticed that *sometimes* an ft2232
Add a NAND Commands section to to the TEXI docs, covering the basic
commands except for those previously discussed as being due for removal
(nand copy) or switching to use byte offsets not block numbers.
This uses the @deffn... syntax for defining commands, as somewhat
suggested by the TEXI
On Thursday 21 May 2009, Zach Welch wrote:
I feel like this is a dumb question but here goes Why [are] all
of the TCL configuration files (src/target/{target,board,interface}/*)
located in src/target/ instead of src/tcl/?
And why src instead of a toplevel config?
Why named .../*.cfg
On Thursday 21 May 2009, Rick Altherr wrote:
Yeah, given that it is an integer and of variable size, casting to
intmax_t is probably appropriate. Please try the attached patch.
The '%j' format worked on an x86_64 build. Live and learn...
I'd never heard of '%j' before! Next thing you know,
On Thursday 21 May 2009, Øyvind Harboe wrote:
You didn't talk about when you cut the branch. I don't think we want
to slow down development in svn head for much more than a week or two?
Alternatively, isn't the branch where all non-essential stuff
should be parked until head is stabilized and
On Thursday 21 May 2009, Rick Altherr wrote:
On May 21, 2009, at 5:02 PM, David Brownell wrote:
Worth IMO drawing a distinction between core support
and the rest. ...
So I'd agree it's certainly time to work on stability
for the core, no new features/functionality
Remove un-implemented and dubious nand copy command.
Doing this efficiently would mean doing the copying on
the target CPU, instead of back and forth through JTAG.
If anyone ever needs this functionality, that's what
they should implement.
Also, update on-line help for nand dump to display
its
On Friday 22 May 2009, Sergey Lapin wrote:
Do I miss something or OpenOCD do definitely have NAND support?
It has nand support. src/flash/*nand*c ... and
the current SVN finally has some documentation,
which will I suspect appear at
http://openocd.berlios.de/web/?page_id=54
within a few
On Friday 22 May 2009, Duane Ellis wrote:
The *others* - are all helpers - and are TCL scripts, they generally
do not configure something.
Actually, .jim sounds better ... when I consult
a TCL manual, I keep seeing things that I need that
are not found in TCL.
On Thursday 21 May 2009, Nicolas Pitre wrote:
On Thu, 21 May 2009, David Brownell wrote:
I also noticed that two commands (erase, check_bad) are
unusual in that they require *block* numbers as parameters,
rather than the offsets used everywhere else in OpenOCD
(and in U-Boot
On Friday 22 May 2009, Nicolas Pitre wrote:
On Fri, 22 May 2009, David Brownell wrote:
On Friday 22 May 2009, Sergey Lapin wrote:
How hard it is po port that to at91sam9260?
Shouldn't be hard to get basic soft-ecc working.
Sort of like Orion ... I think the fast-download
code
Update two oddball NAND commands to work with {offset, length}
instead of block numbers, matching the other commands as well
as usage in U-Boot and the Linux-MTD utilities.
Document them accordingly. Update the single in-tree use of
those commands (sheevaplug).
ALSO:
(a) Document the current
On Friday 22 May 2009, David Brownell wrote:
Update two oddball NAND commands to work with {offset, length}
instead of block numbers...
And FYI that pretty much sums up all the NAND function/doc patches
I expect to send for this release. There's now sane doc matching
the current code
I am also thinking that the USB timeout value may be extended a bit longer.
Right now it is 1000ms. Should be ok. But may not be ok for people
using VM or similar.
The problem with this is that it slows down the failure process when
something is actually broken. I think more
On Saturday 23 May 2009, Wookey wrote:
At least some of
the confusion could go away if there were JTAG commands to
disable signals (SRST, RTCK, etc) at various levels (target,
board, adapter).
Hmm, you mean something could declare that it doesn't pass/expose
signals. That would fit
On Saturday 23 May 2009, Zach Welch wrote:
At this point, I have a system in place to make it unlikely for me to
let any threads be forgotten,
Some Linux groups use a new tool called patchwork which monitors
mailing lists for patches...
http://ozlabs.org/~jk/projects/patchwork/
Purely FYI.
On Saturday 23 May 2009, Zach Welch wrote:
Considering that USB bulk transfers are best effort and might easily
be delayed by concurrent activity to a USB disk or webcam ... a single
second seems absurdly short. Even if the device were guaranteed to be
able to respond that quickly.
On Saturday 23 May 2009, Zach Welch wrote:
.
One point could be the RESET signals SRST and TRST. Here the
FT2232 can set both signals at the same time, which I think
is used too.
Yeah, I noticed that *sometimes* an ft2232 adapter was able
to come up OK ... but other times it
Fix a bug that joined us at the last minute, when an efficient
alloca() call got swapped out for a more portable malloc().
Also log one error, to give a clue in case it appears in the wild.
---
src/flash/davinci_nand.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Fix a bug
Make startup for the various server ports be quiet, unless
debugging is active: don't emit needless scarey messages.
Update the relevant documentation and its references:
- For these port commands ... cover the default values;
convert to @deffn syntax; include their use outside of
the
Doc (mostly) update for jtag_khz:
- switch to @deffn syntax
- add entry for jtag_rclk
- move deprecated jtag_speed into collection of deprecated calls
And for ft2232, don't be the only adapter to *log* an error if RTCK
is requested; it's already reported properly, like any other nonfatal
On Sunday 24 May 2009, David Brownell wrote:
- move deprecated jtag_speed into collection of deprecated calls
Also, I think all those deprecated calls should be issuing runtime
warnings, nudging scripts to get rid of their usage. Without such
nag messages, it won't be practical to get rid
On Saturday 23 May 2009, Zach Welch wrote:
1) library header file rework:
a) rename src/ as openocd/ (preferred)
- this will allow public #include, e.g. openocd/jtag/jlink.h
b) do not rename src, e.g. #include jtag/jlink.h
- something needs to be done; the library work is only
On Saturday 23 May 2009, Zach Welch wrote:
5) commit testing tools
- one-step smoke tests! I probably need another week for this.
- all in-tree with no new dependencies (maybe a Perl module or two)
-
http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04030.html
On Sunday 24 May 2009, Zach Welch wrote:
Also, I think all those deprecated calls should be issuing runtime
warnings, nudging scripts to get rid of their usage. Without such
nag messages, it won't be practical to get rid of those commands.
I agree. Care to submit another patch to
On Saturday 23 May 2009, Zach Welch wrote:
- others?
Areas where I'd like to see continued improvement during
the remainder of this cycle:
- Less server message spam. Servers should only log
messages when something's *seriously* wrong, and
should not rely on stdout except maybe during
1 - 100 of 1761 matches
Mail list logo
