On Thu, 2009-12-03 at 15:00 -0800, David Brownell wrote:
> On Sunday 29 November 2009, Zach Welch wrote:
> > 
> > > Broken how?  It's worked as advertised, as far as I know.
> > 
> > It was allowing all commands to run during CONFIG stage, regardless of
> > whether they were marked EXEC-only.  Broken.
> 
> The key instant seems to be when JTAG starts.  Once that starts,
> there's no *techinical* reason to prevent any other command from
> working.
> 
> The current code is initializing JTAG before, for example, flash.
> Worth revisiting whether JTAG can become the *last* thing which
> gets initialized...

yeah, that should be the plan.  The creation/initialization should be
stack-like: you create something, configure it, then initialize.
The "configure it" step may involve recursive descent into this process
for objects that hang off of it.  Thus, the sequence should look like
the following:

jtag create jtag1
jtag1 configure ... (cont'd)
  target create target1
  target1 configure ...
    flash create flash1
    flash1 config
    flash1 init
  target1 configure ... (cont'd)
    flash create flash2
    flash2 config
    flash2 init
  target1 configure ... (cont'd)  (if needed)
  target1 init
jtag1 configure ... (cont'd)
  target create target2
  ....
  target2 init
jtag1 init
jtag create jtag2
.....
jtag2 init

jtag1 ...
jtag1 target2 ...
jtag2 target42 flash6x9 ...

This is by far the best conceptualization that I have produced for
explaining why the commands desperately need to be restructured, so
thanks for inspiring it.  Right there, you allow N:M:P interfaces,
targets, and flashes -- without zero pollution of command namespace.

Cheers,

Zach

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to