rick> As my other patch shows, such a mechanism simplifies interacting
with a JTAG route controller, so the mechanism would already be in place.
duane> I missed that - where is this at?
rick> A different thread with subject "JTAG Events".
Thanks, looks good :-) Missed that in all the email that w
On Dec 11, 2008, at 5:09 PM, Duane Ellis wrote:
rick> As my other patch shows, such a mechanism simplifies
interacting with a JTAG route controller, so the mechanism would
already be in place.
I missed that - where is this at?
A different thread with subject "JTAG Events".
duane> {tap
rick> As my other patch shows, such a mechanism simplifies interacting
with a JTAG route controller, so the mechanism would already be in place.
I missed that - where is this at?
duane> {taps as objects}
rick> [name space is the real issue]
Agreed.
As for the more general "taps - as objects"
On Dec 11, 2008, at 3:55 AM, Duane Ellis wrote:
duane> ==
duane> Here is the *SIMPLE* thing that needs to happen.
duane> (1) There needs to be a new target event.
duane> This event should happen when all taps have
duane> been "re-id" aka: when the chain is valid
duane> ==
duane> Here is the *SIMPLE* thing that needs to happen.
duane> (1) There needs to be a new target event.
duane> This event should happen when all taps have
duane> been "re-id" aka: when the chain is validated.
rick> I don't think the target is the right
Rick Altherr wrote:
>
> 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
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
Ø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
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 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
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
===
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
28 matches
Mail list logo
