On Nov 26, 2008, at 9:20 AM, Duane Ellis wrote:

duane>Today, OpenOCD assumes there is always a target. Perhaps it needs a "target none"? for that situation.

rick> I would assume that not having a 'target create' line in a config would be sufficient to indicate no targets. I prefer *EXPLICIT* indication of no target, thus if one finds "target none" - one can spit out errors if one accidentally to creates a target.

Rational:    Human Factors - noobs are often confused.


Sure, but any attempt to _use_ a target can easily display the error that "no targets are defined." That makes it very clear what happened and what needs to be fixed but also lets people like me run the daemon without declaring a target at the time that the daemon is launched. That way, I can create and delete targets in a single session to test syntax changes, etc.


rick> For future use, I could even see allowing multiple interfaces to be defined at one time.

I could to - but - that is the 0.01% problem. For many - 99.99% of the time people are talking to one interface.


Sadly, I tend to fall into that 0.01% frequently. I've had projects with 2 separate devices on separate JTAG chains which required 2 interfaces.

If they are talking to 2 interfaces - it is not unreasonable to request they start 2 instances of openocd.

Although it isn't technically necessary. It would be much more forward-thinking and extensible to define a way to have multiple interfaces and a way to assign targets to interfaces and then assign gdb servers to targets. If done correctly, the simple case of 1 interface with 1 target on 1 gdb server wouldn't require any additional setup.



There is a higher chance of somebody having 2 CPUs on a single JTAG chain (this exists now - ie: BeagleBoard OMAP has DSP + the ARM)
Although to day - openocd does not support the dsp debug stuff.


I'm thinking of this as a N:M:P problem where there are N gdb servers mapped onto M targets which are mapped onto P interfaces. That provides flexibility for future designs and doesn't really change the internals of OpenOCD much. We already has a pointer to the interface structure since we don't know which type of interface is in use. This just maintains a list of active interfaces and adds a config option when creating a target to specify which interface to use.

-Duane.



--
Rick Altherr
[EMAIL PROTECTED]

"He said he hadn't had a byte in three days. I had a short, so I split it with him."
 -- Unsigned



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to