Hi all BeagleBoard + OpenOCD users,
What is the setup for Emu0 Emu1 pin :
- need both left open
- need both EMU0 EMU1 pull-down resistors
- need EMU0 pull-down resistors ...
Regards,
Laurent Gauch
http://www.amontec.com
___
Openocd-development mailin
Hi all,
I have finished committing my outstanding patches that eliminate the
redundancies in OpenOCD header file #include directives, which resulted
in the elimination of about 1000 lines of code and helped decouple
various parts of the system. Work remains to be done on this later.
Let me know
On Mon, 2009-05-11 at 00:11 +0100, Spencer Oliver wrote:
> > This one-time step comes from the addition of the
> > AC_PROG_LIBTOOL macro.
> > It will be performed automatically in the bootstrap script
> > for newly checked out working copies. Sorry for the inconvenience.
> >
>
> Been away for
> This one-time step comes from the addition of the
> AC_PROG_LIBTOOL macro.
> It will be performed automatically in the bootstrap script
> for newly checked out working copies. Sorry for the inconvenience.
>
Been away for a week and it looks like i missed a busy one !!
Just for info the min
My understanding the format of commands has changed and I'm trying to
understand how to move forward. Able to use the simple config file:
# Change the default telnet port...
telnet_port
# GDB connects here
gdb_port
# GDB can also flash my flash!
gdb_memory_map enable
gdb_flash_program
This is the first batch of USB performance regression
fixes.
This patch uses the new jtag_add_callback() scheme to perform
postprocessing later on so bigger scans can be performed.
Although this is posted as one big patch, I intend to split
it up a bit so as to allow better bisection possibilitie
Hi all,
I wanted to let everyone know that I have committed the changes required
to build libopenocd.{a,so} using libtool (part of the GNU autotools).
Obviously, this will require that all developers have the libtool
package installed, though it will probably already be present for most.
In addit
Hi all,
The offer by Martin Thomas to contribute testing feedback inspired me.
I think that it would be an incredible asset for the OpenOCD maintainers
to be able to see a current support matrix, since no one individual can
reasonably be expected to test all platforms, interfaces, and targets.
So
Hi,
I am getting some strange flash corruption when programming aduc702x
flash. (This is the first time I have done any flash programming for
this chip).
What happens is that I can program a region of flash correctly. But a
region exactly the same size but immediately following the one
programme
On Sun, 2009-05-10 at 22:31 +0200, Magnus Lundin wrote:
> >
> > So some progress, but nothing more ;)
> >
> > (all: Above error is from TCL script containing "ocd_mem2array
> > romtable_cid 32 [expr ($debugbase&0xF000) + 0xFF0] 4")
> >
> > Do you have any special patches or do I need any speci
On Fri, 2009-05-08 at 21:54 +0200, Martin Thomas wrote:
> Hello,
>
> I have tried to build SVN1676 using MinGW/msys and it failed during
> compilation of jim.c because of a already declared environment. Also
> checking for "environ in stdlib.h" at least keeps the build-process
> running here, a pa
>
> So some progress, but nothing more ;)
>
> (all: Above error is from TCL script containing "ocd_mem2array
> romtable_cid 32 [expr ($debugbase&0xF000) + 0xFF0] 4")
>
> Do you have any special patches or do I need any special configure
> option to enable (& compile) tclapi.c?
>
Standard bui
I've now typed up and committed a new postprocessing/callback
API that will be used to fix the USB performance regression in svn head.
To recap: USB needs to send large clock out/in commands to avoid
performance deterioration due to long turnaround times.
The solution that was previously used was
On Sun, 2009-05-10 at 15:20 +0200, Dirk Behme wrote:
[snip]
> As already mentioned, looking into the code: ocd_mem2array is
> registered in tclapi_register_commands() in tclapi.c. But: It seems to
> me that tclapi_register_commands() isn't called anywhere, and even
> worse, tclapi.c isn't compi
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
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++)
{
On Sunday 10 May 2009, Øyvind Harboe wrote:
> > Well, neither of these solutions seems excessively elegant ... ;)
> >
> > Thanks for the suggestions. It doesn't look quite straightforward
> > to add new "mrw" commands that return a value ... the interpreter
> > is hidden at the point you've got to
Hello list,
I have make a big smoketest with the r1606. But this is not
an original r1606, some small modifications was made.
Many thanks to Magnus Lundin to solve the problems here.
#1, problem with SAM7S and old flash driver
at91sam7_old.c, here nea
Magnus Lundin wrote:
> Dirk Behme wrote:
>> Magnus Lundin wrote:
>>> Hi
>>> Rev 1547, Added two commands that just returns values in hex, good for
>>> scripting.
>>>
>>> >dap baseaddr
>>> >dap apid
>>>
>>> Next I started playing with Tcl scripts that scans the ROM table and
>>> installed compo
My problems all were caused by a crappy USB cable.
Problem solved.
Strontium
Magnus Lundin wrote:
> Win, Linux or Mac ??
>
> I have now for a few days tested this with a flyswatter+beagleboard
> under Fedora 10.
> The serial connection stays active when I start and also when I quit
> openocd.
On Sun, May 10, 2009 at 8:37 AM, David Brownell wrote:
> 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
>> 0x000
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Sat, May 9, 2009 at 11:53 PM, Magnus Lundin wrote:
> Hi
>
> I am still waiting for any coherent analysis supporting the recent
> changes. I have been asked for, and given, arguments for keeping the basic
> openocd design, but for the changes it is still only "we will fix it, no
> analysis wha
23 matches
Mail list logo
