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?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Anyone have a chance to test on Linux?
svn head builds on my Debian box this morning.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Looking at your configuration scripts, they should *not* call init
once they are implemented correctly.
This does mean that omap3.cpu has to be enabled *before* it can be used (?)
On the other hand, in previous discussion, we had learned that init has to
be called *after* target create. But
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,
Øyvind Harboe wrote:
Looking at your configuration scripts, they should *not* call init
once they are implemented correctly.
Do you like to give any hints how to implement them correctly and what
do you think is wrong with them?
We talk about
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
Hello Øyvind,
Does svn head work if you use 1824 for ft2232.c only?
I have make a new test, copy of the 1872 do not help
only. I must use the long sequence too:
tms_sequence long
This mean, I must copy the 1824 over the 1872 and use
the long sequence to get the SAM and LPC working.
Best
On Thu, 2009-05-21 at 22:38 -0400, Duane Ellis wrote:
Zach
static inline functions should be preferred over macros, yes.
I personally despise 'static inline' functions.
One cannot never set breakpoints on them, because the debugger cannot
figure out *which* instance you want to set
I'm going to be out of the office for the next week, so I'm turning into
a pumpkin RSN.
omap3_dbginit should be made part of the reset sequence.
OpenOCD supports hot-plugging of targets. Feel free to scream, but this
is something that developers do since it saves time. If it bricks a beagleboard
Øyvind Harboe wrote:
I'm going to be out of the office for the next week, so I'm turning into
a pumpkin RSN.
omap3_dbginit should be made part of the reset sequence.
OpenOCD supports hot-plugging of targets. Feel free to scream, but this
is something that developers do since it saves
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. But that
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 Thu, 2009-05-21 at 20:23 -0700, David Brownell wrote:
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
Hi, all!
Do I miss something or OpenOCD do definitely have NAND support?
For which processorts it exists? How hard it is po port that to at91sam9260?
Thanks a lot,
S.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
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
Trying again...
My editor is screwing things up with whitespace, hence all those irrelevant
changes...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/cortex_m3.c
On Fri, May 22, 2009 at 11:08 AM, Michael Fischer fische...@t-online.de wrote:
Hello list,
I would suggest that ft2232.c 1824 is committed to trunk and
that the newest version of ft2232.c is split into a series of
patches. First commit all the harmless changes, then
try to divide thinigs into
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks that the
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a
On Fri, 2009-05-22 at 06:35 -0400, Duane Ellis wrote:
zach Also, because they are not really TCL scripts.
zach They are Jim TCL scripts, . so --
zach if anything -- they should be renamed '.jim'
-1 From me.
That suggestion was mostly in jest.
The main config scripts (interface,
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.
+++ Zach Welch [2009-05-21 15:12 -0700]:
On Thu, 2009-05-21 at 21:50 +0100, Wookey wrote:
+++ Wookey [2009-05-19 12:29 +0100]:
As described on
I like the idea for a base.cfg file, as it allows users to tweak the
defaults of their installed OpenOCD. In this light, I can see us
pushing
On May 21, 2009, at 11:38 PM, Ø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?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
On May 22, 2009, at 12:04 AM, David Brownell wrote:
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
On May 22, 2009, at 12:46 AM, David Brownell wrote:
For risk, I use the following criteria:
None - Every change has risk. This is never used.
Low - The changes either affect a small portion of the code base, are
very small but repetitious throughout the code base, or are entirely
mechanical
Committed revision 1882.
On May 21, 2009, at 11:43 AM, Rick Altherr wrote:
On May 21, 2009, at 11:24 AM, David Brownell wrote:
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
Committed revision 1883.
On May 22, 2009, at 1:31 AM, David Brownell wrote:
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
Are we waiting on testing results?
Rick
On May 21, 2009, at 7:57 AM, SimonQian wrote:
Johann,
I found the svf_check_tdo has been modified in the SVN HEAD.
Can you check it on your target?
Attachment is my patch to use buf_cmp_mask when compare data, please
check it too.
A problem in
I think we can commit this patch, it only changes svf_check_tdo function,
which is used to check tdo output with desired values.
The patch will call buf_cmp_mask function to do the comparation instead of
writing the loop code. The patch also fix a bug when data length is 32
bit(equal to
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, and the
On Fri, 22 May 2009, David Brownell wrote:
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
Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI
I am just updated to svn 1881 to use with my STM32 and jlink(yellow
v6.0). I had been using 1183, which worked every time, but was
unbearably slow. Revision 1881 is lightning fast compared with the
old revision. I am however seeing a few issues.
It takes 5 or six tries to get my program to
On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote:
Zach Welch wrote:
On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote:
Hi
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Error: J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed
Zach Welch wrote:
On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote:
Zach Welch wrote:
On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote:
Hi
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Error: J-Link command
David Brownell wrote:
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
I prefer the STRIP_CODE_COMMENTS = NO
Reason: Don't hide things. Make it all visible.
$ svn diff Doxyfile
Index: Doxyfile
===
--- Doxyfile(revision 1858)
+++ Doxyfile(working copy)
@@ -697,7 +697,7 @@
# doxygen to
On Fri, 2009-05-22 at 20:05 -0400, Duane Ellis wrote:
I prefer the STRIP_CODE_COMMENTS = NO
Reason: Don't hide things. Make it all visible.
Committed r1887.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Try this again to the whole list.
Here is the trace. I'm taking a quick look at it right now. I am
guessing that having jlink_jtag_handle = 0 is the problem, just trying
to figure out how that happened.
Dylan
(gdb) run -f ../GNUTools/openOCD/newLPM.cfg -c init -c sleep 200 -f
flashAll.script
Something strikes me as pretty broken here. Maybe I am seeing ghosts.
I put in a few prints to see what was going on, then got confused and
ran from the debugger. This is what I found:
static int jlink_get_version_info(void)
{
int result;
int len;
u32 jlink_caps,
On Sat, May 23, 2009 at 6:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
There is a set of new patches that has been tested by Michael Fischer, as
far as i know there were no problems.
There are still things that should be fixed in the resethandling in
jtag_add_reset and minimizing the
On Sat, May 23, 2009 at 9:12 AM, Xiaofan Chen xiaof...@gmail.com wrote:
I'd like to test as well for my V3 black J-link. It works well with
your previous
patch. But the latest trunk does not build under Arch Linux. It is also
pointed
out by Simon Qian. How should I modify that file?
On Sat, 2009-05-23 at 09:12 +0800, Xiaofan Chen wrote:
On Sat, May 23, 2009 at 6:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
There is a set of new patches that has been tested by Michael Fischer, as
far as i know there were no problems.
There are still things that should be fixed in
2009/5/23 Zach Welch z...@superlucidity.net:
I'd like to test as well for my V3 black J-link. It works well with
your previous
patch. But the latest trunk does not build under Arch Linux. It is also
pointed
out by Simon Qian. How should I modify that file?
xsvf.c: In function
On Sat, 2009-05-23 at 09:35 +0800, Xiaofan Chen wrote:
2009/5/23 Zach Welch z...@superlucidity.net:
I'd like to test as well for my V3 black J-link. It works well with
your previous
patch. But the latest trunk does not build under Arch Linux. It is also
pointed
out by Simon Qian. How
On Sat, May 23, 2009 at 5:59 AM, Dylan Reid dgr...@gmail.com wrote:
$ sudo /usr/local/gnu-arm/bin/openocd -f
../GNUTools/openOCD/newLPM.cfg -c init -c sleep 200 -f
flashAll.script -c reset run -c shutdown
Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
BUGS? Read
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 there should be pulled out and made available
for all
On Sat, May 23, 2009 at 8:49 AM, Dylan Reid dgr...@gmail.com wrote:
Something strikes me as pretty broken here. Maybe I am seeing ghosts.
I put in a few prints to see what was going on, then got confused and
ran from the debugger. This is what I found:
static int
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, and the
On Sat, 2009-05-23 at 00:46 +0200, Magnus Lundin wrote:
Zach Welch wrote:
On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote:
Zach Welch wrote:
On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote:
[snip]
There is a set of new patches that has been tested by
54 matches
Mail list logo
