Re: [Openocd-development] multiple JTAG interfaces
On Monday 07 December 2009, Zach Welch wrote:
Hi all,
The following list describes the things that might still be accomplished
before the 0.4.0-rc cycle starts. These features are all mostly done
in my tree; they work fine for me in limited testing. They should all
be safe incremental steps to take.
That mostly done bothers me... we need to be winding down current
work which is almost completely merged, not starting a new merge
cycle just to get in under the wire. So I'm going to read this
instead as mostly about things which might be done in 0.5 ... and
most of which doesn't relate to $SUBJECT, for that matter!
If by $SUBJECT you mean remove JTAG-related global state from
all interfaces, I'm all for it.
But probably not for 0.4 since it's a huge change ... it would
touch *EVERYTHING* that gets anywhere near JTAG. Like for example
the TAP state logic, and SRST handling, reset_config, and more.
Such a change would need to go in phases. Maybe some of them could
fit in the remaining part of the 0.4 cycle; but not most of them.
(None of that is sanely factored; the fact that there's just one
current JTAG scan chain, TAP state, SRST etc, is *everywhere* in the
code. Even when it's not actually true, e.g. SRST is a pretty rude
signal to try using, unless there's only a single device.)
And then that would need to bubble up to the command language
too. Maybe in a different release -- but eventually. In short,
supporting multiple scan chains would be a major change, not
IMO suitable for rushing into the 0.4 release.
- generic driver/instance helper module
- struct object: root of driver-instantiated objects
- struct driver: root of driver objects (and is-a object itself)
- Allows adding 'struct module' to provide loadable drivers someday.
Any time I hear about a proposed struct object, warning
sirens start blaring loudly. They're almost never needed,
except maybe as part of enabling GC in a language runtime.
You can add the notion of a loadable module separately from
all that other stuff.
Loadable _driver_ does call for a clean framework into which
that driver plugs ... and none of our drivers are that clean:
we rely on tables, rather than ${TYPE}_driver_{add,remove}()
calls that get triggered somehow. Where TYPE could of course
be JTAG adapter, CPU/target, NOR driver, NAND driver, and more.
It ought to be easy to drop lots of drivers out of the tree,
by just not compiling and linking them -- without changing
the framework into which they plug. Then later to tweak
those frameworks to say hmm, no driver X, try modprobe
to see if it appears. The enabling comes from just having
clean register-a-driver-to-this-subsystem interfaces.
- flash driver/instance unification
- NOR tree is converted to use 'object' and 'driver' model.
- flash_banks are 'object's of flash_driver device 'driver's
- NAND tree can be converted similarly (when done with other patches).
Maybe you could start a separate thread on this subject,
showing precisely what you mean. Your single quotes prevent
me from understanding what that flash_banks are... means.
There's obvious messiness to clean up there, but I'd have to
guess what you're intending to suggest...
- multiple JTAG interface API support (internal to the JTAG module only)
- adds jtag_device (object) to instantiate jtag_interface (driver)
Seems to me the notions we need here would be:
- scan chain, associated with
* state ... collected from all over: reset config, etc
* set of TAPs ... state; some TAPs have targets
* jtag adapter ... driver, with internal state
So hook up multiple adapters, and get multiple scan chains each with
their own TAPs and each of which gets reset differently.
A jtag_device would be conceptually confusing; everything we touch
is some flavor of that. Focus instead on what role the device serves,
and make type names match the role.
- converts internal APIs: jtag_interface, driver commands, bitbang
- converts drivers to use new APIs, with dummy support many instances
- moves some global variables into structures
Hmm, I'd rather see the what (data structures) before the how do
we get there (conversion steps).
So far, the JTAG conversion has been completely internal to that module,
so it may not be desirable to introduce this support in 0.4.0 without
finishing the work. Specifically, support must be added at all levels
of the system; many of the public JTAG APIs must be updated so callers
pass the required jtag_device structure. This process of associating
all of the other parts of the system with a specific interface will take
a larger concerted effort, and it may be too late to get this done.
Even worse, we must integrate this somehow with the current commands. :/
It's way too late for 0.4, IMO.
The easy way to package such a change would be to have one telnet and
TCL port per scan chain, so the *runtime* commands don't need to change.
But that'd still
Re: [Openocd-development] multiple JTAG interfaces
I'm concerned about doing a lot more work on 0.4. I would like to see what our track record is with this amount of changes w.r.t. breakage. The changes you are proposing look *great* but I wonder if they shouldn't be spread out over 0.4, 0.5 and possibly also 0.6 to get enough feedback on the work along the way. I'm also concerned about such a major change as introducing support for multiple interfaces where I have yet to hear anybody actually needing to do such a thing in-process. It greatly improves the architecture for sure and the code will be more pleasurable to read work on, important in an open source project in itself. I would put symmetric parallel processing way above it, but I have yet to hear such requests even. When it comes to cleaning up global state(a precursor to multiple jtag interfacs), then my favorite would be to abolish jtag_set_end_state(). Even simply getting rid of jtag_set_end_state() would require a *vast* amount of regression testing on real hardware. While putting the end_state into the interface structure would work it would be lipstick on a pig, I would much rather push the end state into the target layer. Presumably there would be no need to coordinate end state across a heterogeneous JTAG chain or if there were, then I suspect a naive concept of a global end state per interface would be insufficient. What I would like to see pushed before 0.4 are sweeping changes with low risk profile, so as to make branches easier to maintain. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] multiple JTAG interfaces
On Tue, 2009-12-08 at 22:33 +0100, Øyvind Harboe wrote: I'm concerned about doing a lot more work on 0.4. I would like to see what our track record is with this amount of changes w.r.t. breakage. The changes you are proposing look *great* but I wonder if they shouldn't be spread out over 0.4, 0.5 and possibly also 0.6 to get enough feedback on the work along the way. I hereby propose that we fork a major revision, allowing these changes to go into that branch. You have described reasons to justify completely overhauling the JTAG layer in OpenOCD. I know these reasons exists, and I think that it would outright _stupid_ of us to do it in phases. We should bite the bullet and fix all of the problems at once, and _then_ do *one* round of regression testing and fixed. That sound a whole lot like a major revision to me. I do _not_ want to suffer through several minor releases, fixing one part of the problem at a time. Sincerely, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] multiple JTAG interfaces
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Øyvind Harboe Verzonden: di 12/8/09 22:33 Aan: Zach Welch CC: openocd-development Onderwerp: Re: [Openocd-development] multiple JTAG interfaces I'm also concerned about such a major change as introducing support for multiple interfaces where I have yet to hear anybody actually needing to do such a thing in-process. It greatly improves the architecture for sure and the code will be more pleasurable to read work on, important in an open source project in itself. I would put symmetric parallel processing way above it, but I have yet to hear such requests even. Good point. On my programmer project I'm using 8 independent JTAG interfaces simultaneously. I simply have 8 OpenOCD instances running from inittab. The GUI has a telnet connection to each OpenOCD instance and controls programming from there. Having the possibility to connect to multiple JTAG interfaces at the same time may not be necessary. Having the OS deal with time sharing / multitasking is also a good idea. I did some tweaking on the scheduling (sleep calls and less calls to the time checking routines) of OpenOCD to make it consume the least amount of time. Is there a good reason for OpenOCD to be able to connect to multiple JTAG interfaces at the same time? There is a lot of work involved and judging from how OpenOCD is organised now, seperate threads are the easiest way to achieve this. Paying dearly for proper cross platform mutexes, signals and thread creation though. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] multiple JTAG interfaces
On Tuesday 08 December 2009, Øyvind Harboe wrote: The changes you are proposing look *great* but I wonder if they shouldn't be spread out over 0.4, 0.5 and possibly also 0.6 to get enough feedback on the work along the way. Assuming they all get done, they'd absolutely need to be spread out over enough time to consider each proposal, and to address that feedback. When it comes to cleaning up global state(a precursor to multiple jtag interfacs), then my favorite would be to abolish jtag_set_end_state(). Even simply getting rid of jtag_set_end_state() would require a *vast* amount of regression testing on real hardware. Yeah, every time I see that I scratch my head and say WTF. It should be derived from real scan chain operations. I would much rather push the end state into the target layer. Presumably there would be no need to coordinate end state across a heterogeneous JTAG chain or if there were, then I suspect a naive concept of a global end state per interface would be insufficient. Yoicks ... that kind of interaction is sick: not being able to talk to one TAP, because another one is sniffing the JTAG state transitions! Maybe that's why there seems to have been a slowdown in the IEEE 1149.7 work ... it was originally using a zero byte scan to kick in new functionality, but I saw some alternate noise about not using TCK more recently. What I would like to see pushed before 0.4 are sweeping changes with low risk profile, so as to make branches easier to maintain. Not too many more such changes though, I hope. :) I think all the ones we planned on are now finished (many from Zach) and I think the tree is much-improved in consequence. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] multiple JTAG interfaces
Hi all, The following list describes the things that might still be accomplished before the 0.4.0-rc cycle starts. These features are all mostly done in my tree; they work fine for me in limited testing. They should all be safe incremental steps to take. - generic driver/instance helper module - struct object: root of driver-instantiated objects - struct driver: root of driver objects (and is-a object itself) - Allows adding 'struct module' to provide loadable drivers someday. - flash driver/instance unification - NOR tree is converted to use 'object' and 'driver' model. - flash_banks are 'object's of flash_driver device 'driver's - NAND tree can be converted similarly (when done with other patches). - multiple JTAG interface API support (internal to the JTAG module only) - adds jtag_device (object) to instantiate jtag_interface (driver) - converts internal APIs: jtag_interface, driver commands, bitbang - converts drivers to use new APIs, with dummy support many instances - moves some global variables into structures So far, the JTAG conversion has been completely internal to that module, so it may not be desirable to introduce this support in 0.4.0 without finishing the work. Specifically, support must be added at all levels of the system; many of the public JTAG APIs must be updated so callers pass the required jtag_device structure. This process of associating all of the other parts of the system with a specific interface will take a larger concerted effort, and it may be too late to get this done. Even worse, we must integrate this somehow with the current commands. :/ Today, the patches allow updating the internal JTAG APIs to support multiple interfaces and allow drivers to encapsulate their own state. Indeed, I have updated the 'dummy' driver to show how multiple device instances can be supported in one driver with the new interface APIs. When the high-level APIs switch away from using a global device pointer, that driver should just work as expected. Others maintainers should find it easy to update their own drivers to add this support, even though this requires removing all post-configuration global variables. Mirrored in my 'object', 'mem', and 'jtag' branches on repo.or.cz: http://repo.or.cz/w/openocd/ztw.git While I am going to continue looking at the JTAG layer, I believe that this current work would be relatively safe to push. It might be best to do this integration in stages so each phase gets good testing, but what do others think about these changes and overall strategy? Cheers, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] multiple JTAG interfaces
- multiple JTAG interface API support (internal to the JTAG module only) A particular concern for me is obviously that I do not want to see any performance degradation when there is only a single minidriver in the system. I first need to get the jtag_add_dr_out() fixes out of the door, then have a closer look at your jtag interface work to be able to determine if there are any problems in the design w.r.t. single minidriver systems low cpu power low latency systems. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
