I was worried about more fancy problems, but if those arise, then
I think at some point we'll want to let the target script be able to
reimplement the jtag validate entirely. I think it is best to postpone
the "reimplement jtag validate in target script" feature
until a problem arises that mandates
On Dec 10, 2008, at 6:36 PM, Duane Ellis wrote:
I think the idea of supporting *MULTIPLE* "-expected-id" parameters
is a good thing.
(ie: an array of tap ids in the C code). It is a *SMALL* and
reasonable price to pay.
===
Patches are welcome!
openocd-jtag-multiple-e
On Dec 10, 2008, at 6:36 PM, Duane Ellis wrote:
I think the idea of supporting *MULTIPLE* "-expected-id" parameters
is a good thing.
(ie: an array of tap ids in the C code). It is a *SMALL* and
reasonable price to pay.
Ok.
==
Here is the *SIMPLE* thin
On Dec 10, 2008, at 6:49 PM, Duane Ellis wrote:
rick> That is going to get confusing for new users.
No, it has not confused people in the past, and will not confuse
people in the future.
Adam Dunkels uses a vastly different configuration in Contiki - and
that does not confuse people.
An
Andreas Kuehn wrote
> In fact, its a timing problem. I added some LOG_DEBUG lines to the code
> and all Warnings dissapeared when running with -d1 or higher.
> Unfortunately uClibc has some drawbacks regarding timer stuff which I
> desperately need for dealing with the different processor speeds
Øyvind Harboe wrote:
> Sounds good to me.
>
Let me back up a few steps here.
There is a *SIMPLE* way to do this in TCL - it requires a couple
*SIMPLE* things be done.
{See below}
=
The original purpose of the "-expected-id" was to print a big-nasty
warning i
Sounds good to me.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openoc
On Dec 10, 2008, at 12:31 PM, Øyvind Harboe wrote:
would create a tap with 3 events available: matched-id-$_CPUTAPID,
matched-id-$_OTHERCPUTAPID, and nomatch.
This is precisely the control-inversion problem: lots of events and
yet never enough flexiblity.
My current thinking is now that we s
> would create a tap with 3 events available: matched-id-$_CPUTAPID,
> matched-id-$_OTHERCPUTAPID, and nomatch.
This is precisely the control-inversion problem: lots of events and
yet never enough flexiblity.
My current thinking is now that we should allow the entire jtag valdiation
to be written
On Dec 10, 2008, at 12:05 PM, Øyvind Harboe wrote:
That just complicates the normal case for no reason. If you leave
the
expected-id comparison in C, you can still do things like:
A shorthand for the normal case is of course a requirement.
-expected-id can be implemented in Tcl: it can at
Come to think of it...
This is precisely what we addressed with target configuration scripts
being able to implement the entire reset procedure.
Similarly the target configuration script should be able to implement
the entire JTAG validation procedure, not just a small part of it.
In theory a t
> That just complicates the normal case for no reason. If you leave the
> expected-id comparison in C, you can still do things like:
A shorthand for the normal case is of course a requirement.
-expected-id can be implemented in Tcl: it can attach a default
piece of tcl to handle the normal case.
On Dec 10, 2008, at 11:38 AM, Øyvind Harboe wrote:
Why not allow the tcl config script to implement this?
If you define the interface correctly, then this *should* be possible
to implement, entirely, inside the target config script. Otherwise,
you have not left enough control for the target sc
Why not allow the tcl config script to implement this?
If you define the interface correctly, then this *should* be possible
to implement, entirely, inside the target config script. Otherwise,
you have not left enough control for the target script. I'm using
a circular definition there, but hopefu
On Dec 10, 2008, at 11:07 AM, Øyvind Harboe wrote:
My only problem with this approach is that the assumption
that there is a single expected ID is broken.
I want it to be both straightforward to handle the normal case and
possible to handle more complex cases(multiple expected ID's).
--
Øyv
My only problem with this approach is that the assumption
that there is a single expected ID is broken.
I want it to be both straightforward to handle the normal case and
possible to handle more complex cases(multiple expected ID's).
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XS
On Dec 10, 2008, at 10:26 AM, Øyvind Harboe wrote:
On Wed, Dec 10, 2008 at 7:00 PM, Rick Altherr <[EMAIL PROTECTED]>
wrote:
On Dec 10, 2008, at 4:41 AM, Øyvind Harboe wrote:
Hm I think perhaps the "jtag -expected-id" needs rethinking.
The ID check should be in the target configuration
The alternative SVN organisation used a lot is
trunk/project
It's just a matter of convention and both are "correct".
Lets just wait for BerliOS to answer before we jump to any conclusions.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash progr
On Wed, Dec 10, 2008 at 5:28 PM, Andreas Kuehn <[EMAIL PROTECTED]> wrote:
> Well Your hints were quite useful. Even if it still buggy.
>
> Øyvind Harboe wrote:
>>
>> On Wed, Dec 10, 2008 at 11:21 AM, Andreas Kuehn <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi!
>>>
>>> I'm trying to run openocd on an
> Should we just delete these old branches to avoid confusion? They would
> still be in the repo, but wouldn't show up in the latest revisions. You
> would need to check out a specific repo revision to see them.
It gets my vote.
I see no advantage to keeping them.
--
Øyvind Harboe
http://ww
On Wed, Dec 10, 2008 at 7:00 PM, Rick Altherr <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 2008, at 4:41 AM, Øyvind Harboe wrote:
>
>> Hm I think perhaps the "jtag -expected-id" needs rethinking.
>>
>> The ID check should be in the target configuration script and not in
>> C.
>>
>
> The actual che
On Dec 10, 2008, at 7:07 AM, Spencer Oliver wrote:
I grabbed the current release from the mips branch and
compiled openocd with "./configure --enable-parport
--enable-parport_ppdev".
Please use svn trunk, the mips branch was for initial testing and is
now not
maintained.
Cheers
Spen
On Dec 10, 2008, at 4:41 AM, Øyvind Harboe wrote:
Hm I think perhaps the "jtag -expected-id" needs rethinking.
The ID check should be in the target configuration script and not in
C.
The actual check is fine being in C. There is no need to force the
retrieval of the ID and comparison
>
> Sounds like we should make a written request.
>
I have requested the src, this was my reply from freescale support:
perhaps i should have been a bit clearer!!
In reply to your Service Request SR 1-516314907:
Sorry, I do not know what is "src",could you tell me it?
Cheers
Spen
___
On Dec 10, 2008, at 2:47 AM, Øyvind Harboe wrote:
On Tue, Dec 9, 2008 at 3:13 PM, Spencer Oliver <[EMAIL PROTECTED]
soft.co.uk> wrote:
I did some minor reorganization to the subversion repository
today that should not affect anyone working on trunk. I
moved the branches and tags directories u
On Dec 9, 2008, at 12:41 PM, Spencer Oliver wrote:
Hi,
I have just stumbled across the following
http://www.freescale.com/webapp/sps/site/taxonomy.jsp?
nodeId=0127955654
included in the download is a special version of openocd.
seems they have added a ftdi config
ft2232_layout "soundbite"
Well Your hints were quite useful. Even if it still buggy.
Øyvind Harboe wrote:
> On Wed, Dec 10, 2008 at 11:21 AM, Andreas Kuehn <[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>> I'm trying to run openocd on an ARM9/uClibc system to access some
>> "client" ARMs and configure them. Therefore, I adapted
Dear Erveryone:
I wonder write a similar software as the openocd on the window
platform, and now I am reading the openocd source.
I found a piece of code in the "command.c" which is in the folder
"helper". It is just a part of function "unregister_command":
Dear Erveryone:
I wonder write a similar software as the openocd on the window platform, and
now I am reading the openocd source.
I found a piece of code in the "command.c" which is in the folder "helper". It
is just a part of function "unregister_command":
/* unregister children */
if (c->chil
>
> I grabbed the current release from the mips branch and
> compiled openocd with "./configure --enable-parport
> --enable-parport_ppdev".
>
Please use svn trunk, the mips branch was for initial testing and is now not
maintained.
Cheers
Spen
___
Hi list,
I grabbed the current release from the mips branch and compiled openocd
with "./configure --enable-parport --enable-parport_ppdev".
Openocd successfully determines my jtag device. However, I am still
getting a strange error as you can see below. How can I get rid of this
error message?
Hm I think perhaps the "jtag -expected-id" needs rethinking.
The ID check should be in the target configuration script and not in
C.
The target script can accept multiple target id's and also output
sensible target specific error messages or do whatever else
is approperiate.
at91rm9200.cfg s
Hello Duane
The ID i submitted where for a samsung 6431 and not 6410. There must
be some differences
in the ID code(the 6410 has 3d)
I will try get get the ID info on the 6410. For the moment we could
add a s3c6431 target or wait a little
so see what the 6410 returns
greetings
> Index: samsung
Kees >> (earlier a patch for a samsung part)
Kees >> [a new email with more ID codes]
Thanks - committed.
I also found 2 other CFG files with the same "variant" typo :-(
I guess I am very good at typos!
--Duane
===
bash-3.2$ svn diff
Index: imote2.cfg
===
On Wed, Dec 10, 2008 at 11:21 AM, Andreas Kuehn <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm trying to run openocd on an ARM9/uClibc system to access some
> "client" ARMs and configure them. Therefore, I adapted the at91rm9200
> interface to my hardware situation. I could verify with a Scope that the
>
On Tue, Dec 9, 2008 at 3:13 PM, Spencer Oliver <[EMAIL PROTECTED]> wrote:
>> I did some minor reorganization to the subversion repository
>> today that should not affect anyone working on trunk. I
>> moved the branches and tags directories under a new openocd
>> top-level directory to separate it
Hi!
I'm trying to run openocd on an ARM9/uClibc system to access some
"client" ARMs and configure them. Therefore, I adapted the at91rm9200
interface to my hardware situation. I could verify with a Scope that the
signals are there (TCK, TDI, TDO, TMS). Only the openocd gives me some
headache.
More over this is the output when using a s3c6431 (might help getting more id's)
Info: JTAG tap: s3c6410.unknown tap/device found: 0x2b900f0f
(Manufacturer: 0x787, Part: 0xb900, Version: 0x2)
Error: ERROR: Tap: s3c6410.unknown - Expected id: 0x, Got: 0x2b900f0f
Error: ERROR: expected:
The following patch fixes a typo in src/target/target/samsung_s3c6410.cfg
greetings
Index: src/target/target/samsung_s3c6410.cfg
===
--- src/target/target/samsung_s3c6410.cfg (revision 1201)
+++ src/target/target/samsung_s3c6410.cfg
Committed (in 2 steps)
Thank you Kees.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hello
The following patch adds a "find" element to the hammer target element.
This patch assumes that src/target/target/samsung_s2c2410.cfg gets renamed to
src/target/target/samsung_s3c2410.cfg
greetings
Index: src/target/board/hammer.cfg
==
Hi,
I have just stumbled across the following
http://www.freescale.com/webapp/sps/site/taxonomy.jsp?nodeId=0127955654
included in the download is a special version of openocd.
seems they have added a ftdi config
ft2232_layout "soundbite"
the readme states
===
> I did some minor reorganization to the subversion repository
> today that should not affect anyone working on trunk. I
> moved the branches and tags directories under a new openocd
> top-level directory to separate it from the zy1000 stuff. I
> also brought the 1.0 branch in sync with trunk
> > From: Rick Altherr <[EMAIL PROTECTED]>
> >>> +static void output_data(void)
> >>> +{
> >>> + int i;
> >>> + *gpio_data_register = output_value ^ INVERT_BITS;
> >>> + for ( i = 0; i < 10; i++ )
> >>> + ;
> >>> }
> >>>
> >>
> >> A for loop like that can't reliably be used as a delay loop.
> >
44 matches
Mail list logo
