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
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
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 2
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-downloa
On Sat, 2009-05-23 at 09:54 +0800, Xiaofan Chen wrote:
[snip]
> 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 wh
On Sat, May 23, 2009 at 8:49 AM, Dylan Reid 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 jlink_get_version_info(void)
> {
>
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
> f
On Sat, May 23, 2009 at 5:59 AM, Dylan Reid 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 http://s
On Sat, 2009-05-23 at 09:35 +0800, Xiaofan Chen wrote:
> 2009/5/23 Zach Welch :
> >>
> >> 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 sho
2009/5/23 Zach Welch :
>>
>> 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 ‘handle_xsvf_comman
On Sat, 2009-05-23 at 09:12 +0800, Xiaofan Chen wrote:
> On Sat, May 23, 2009 at 6:18 AM, Magnus Lundin 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 resethan
On Sat, May 23, 2009 at 9:12 AM, Xiaofan Chen 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?
>
> xsvf.c: In functio
On Sat, May 23, 2009 at 6:18 AM, Magnus Lundin 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 differences between
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, jlink_max
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
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
https://l
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 hid
On Friday 22 May 2009, Duane Ellis wrote:
> > Actually, ".jim" sounds better ... when I consult
> > a TCL manual, I keep seeing things that I need that
> > are not found in TCL.
> >
> Like what... are they perhaps these are easy to add?
The last thing I remember noticing was that only
about a
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
> ar
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
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_M
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 (-110)
Open OCD seems to get reasonable ansvers from first two JLin
For the segfault, can you run it under gdb and get a backtrace?
Rick
On May 22, 2009, at 2:59 PM, Dylan Reid wrote:
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
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 (-110)
>
> Open OCD seems to get reasonable ansvers from first two JLink commands.
>
>
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 down
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 spe
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 offse
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, a
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 sizeof(i
Committed r1884 - r1886.
On May 22, 2009, at 3:20 AM, 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
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 svf.c
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 wha
NAND support for DaVinci-family drivers, with HW ECC support.
Declare the NAND chip on the DM355 EVM board.
Currently tested on DM355 for Linux interop using the standard
large page (2KB) chip in the EVM socket; "hwecc1" and "hwecc4"
work fine. (Using hwecc4 relies on patches that haven't quite
m
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 loo
On Friday 22 May 2009, Wookey wrote:
> > The lack of response to your query indicates to me that
> > no one can "whip out" a quick description for you, so you may have given
> > this topic more recent and considered thought than others.
>
> That's quite worrying :-) (given that I've considered exac
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 in
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 non-esse
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
+++ 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
>
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.
___
>
> Today we have found the problem why previous attempts to
> debug FA5226 failed! The reason is that arm9tdmi has
> 5 stage pipeline while FA526 6 stage one.
>
> Currently I have modified arm9tdmi_read_xpsr to do one extra
> NOP per command and CPU halted successfully!
> Since I am very new t
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 (int
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.
The main "config" scripts (interface, board, chip) should remain CFG.
they are nothing more then: "openocd configuration scripts"
T
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
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
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
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
appro
On Fri, May 22, 2009 at 11:08 AM, Michael Fischer 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 "real" changes
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 "real" changes.
But we should use the long sequence as default? In this case
we
On Fri, May 22, 2009 at 9:07 AM, Michael Fischer wrote:
> 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
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 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 day
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
https://list
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/?
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
On Thu, 2009-05-21 at 22:35 -0500, Dean Glazeski wrote:
> Hey Duane,
>
> Duane Ellis wrote:
> > 1) Rather the commit this my self, I'd like somebody to read through
> > the comments (double check my work), much of this is by just reading
> > the source code and entering doxygen text.
> This remi
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. B
Ø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 save
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
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
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 regard
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 an
62 matches
Mail list logo
