Re: [Openocd-development] everything must be "used before init" ??
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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
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... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Sat, 2009-11-28 at 18:16 -0800, David Brownell wrote: > On Saturday 28 November 2009, Zach Welch wrote: > > > > Yeah, I figure there are some scripts (or users) that have not been > > sufficiently strict about CONFIG vs. EXEC modes, as that logic has been > > broken for ages > > 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. > > Nevertheless, the very design needs to be improved. > > > > Indeed, this feature presents a layering violation. Right now, the > > command layer knows too much about the state of initialization. Even a > > simple 'enable/disable' state would be a sufficient generalization of > > the intended functionality; however, many commands should be registered > > only once they can be used, which we do in very small doses today. > > And I'd like to see things that *can't* be used not even be displayed > in the "help" list ... I had a patch to do exactly this, but I think I dropped it. It's a two-liner though. > > Why not allow the user to bring up an interface once its defined? > > Specifically, the 'init' command might be a subcommand associated of a > > specific (named) interface device instance. It would give other > > commands for configuring the TAPs, devices, and targets associated with > > that interface. Naturally, this implies multiple interface support, so > > OpenOCD can support gang-programming and multi-head test applications. > > I'm not keen on that. It already supports multiple scanchains ... just > put each one in its own process. That's not something that's broken. > Not that I'd object hugely to having it; but it just seems like it would > only increase complexity, to no real benefit. Multiple processes will not allow easy synchronization when testing targets that are connected via multiple interfaces and to each other. Moreover, it's far more difficult to start two processes: you have to set their server ports manually, or they conflict. One process is the way to go for testing scenarios that require multiple interfaces. And it should eliminate 99% of the global variables in the jtag module. Proper encapsulation of that layer would be a real benefit in my eyes. > > Naturally, it should be possible to run 'init' interactively, such that > > one can startup OpenOCD without any interface defined. That change > > should be possible independently of other work in this area. I seem to > > recall the topic being discussed in the past, but I can't find anything > > relevant in my local archive after a quick search. > > > > As I see it, the notion of command modes can be eliminated entirely, > > Yes it could be. But right now we're faced with just a regression, > where adding > > -c init -c "poll off" > > to a working comand line causes things to fail. When I started to look into this, I decided to start a new series that factors the init process into several fine-grain commands. The current command does _far_ too many things under the covers, making policies when it should be offering mechanisms. For example, the gdb_init routine can be factored into routines that allows starting an GDB server associated with a target at any time. While this work can retain the current syntax, the underlying mechanisms will be prepared to switch to a more policy-neutral command language. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Sunday 29 November 2009, Zach Welch wrote: > Excellent. I came up with nearly the same patch before running out for > the evening. The difference being that I put _after_ the last possible > failure path, so it's possible to recover and try again. It has to be before, because the initialization can call board-specific handlers that talk JTAG. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
Excellent. I came up with nearly the same patch before running out for
the evening. The difference being that I put _after_ the last possible
failure path, so it's possible to recover and try again.
On Sat, 2009-11-28 at 22:43 -0800, David Brownell wrote:
> On Saturday 28 November 2009, David Brownell wrote:
> > I just pulled everything into a workspace and built it ... now it's
> > failing left and right.
>
> This makes the worst of it go away. The context mode
> is supposed to change when "init" runs ... which isn't
> necessarily going to be when main() tries to do that.
>
>
> --- a/src/openocd.c
> +++ b/src/openocd.c
> @@ -109,6 +109,8 @@ COMMAND_HANDLER(handle_init_command)
>
> atexit(exit_handler);
>
> + command_context_mode(CMD_CTX, COMMAND_EXEC);
> +
> if (target_init(CMD_CTX) != ERROR_OK)
> return ERROR_FAIL;
> LOG_DEBUG("target init complete");
> @@ -267,7 +269,6 @@ int openocd_main(int argc, char *argv[])
>
> if (ret != ERROR_COMMAND_CLOSE_CONNECTION)
> {
> - command_context_mode(cmd_ctx, COMMAND_EXEC);
> if (command_run_line(cmd_ctx, "init") != ERROR_OK)
> return EXIT_FAILURE;
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Saturday 28 November 2009, David Brownell wrote:
> I just pulled everything into a workspace and built it ... now it's
> failing left and right.
This makes the worst of it go away. The context mode
is supposed to change when "init" runs ... which isn't
necessarily going to be when main() tries to do that.
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -109,6 +109,8 @@ COMMAND_HANDLER(handle_init_command)
atexit(exit_handler);
+ command_context_mode(CMD_CTX, COMMAND_EXEC);
+
if (target_init(CMD_CTX) != ERROR_OK)
return ERROR_FAIL;
LOG_DEBUG("target init complete");
@@ -267,7 +269,6 @@ int openocd_main(int argc, char *argv[])
if (ret != ERROR_COMMAND_CLOSE_CONNECTION)
{
- command_context_mode(cmd_ctx, COMMAND_EXEC);
if (command_run_line(cmd_ctx, "init") != ERROR_OK)
return EXIT_FAILURE;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Saturday 28 November 2009, Zach Welch wrote: > > Yeah, I figure there are some scripts (or users) that have not been > sufficiently strict about CONFIG vs. EXEC modes, as that logic has been > broken for ages Broken how? It's worked as advertised, as far as I know. > Nevertheless, the very design needs to be improved. > > Indeed, this feature presents a layering violation. Right now, the > command layer knows too much about the state of initialization. Even a > simple 'enable/disable' state would be a sufficient generalization of > the intended functionality; however, many commands should be registered > only once they can be used, which we do in very small doses today. And I'd like to see things that *can't* be used not even be displayed in the "help" list ... > Why not allow the user to bring up an interface once its defined? > Specifically, the 'init' command might be a subcommand associated of a > specific (named) interface device instance. It would give other > commands for configuring the TAPs, devices, and targets associated with > that interface. Naturally, this implies multiple interface support, so > OpenOCD can support gang-programming and multi-head test applications. I'm not keen on that. It already supports multiple scanchains ... just put each one in its own process. That's not something that's broken. Not that I'd object hugely to having it; but it just seems like it would only increase complexity, to no real benefit. > Naturally, it should be possible to run 'init' interactively, such that > one can startup OpenOCD without any interface defined. That change > should be possible independently of other work in this area. I seem to > recall the topic being discussed in the past, but I can't find anything > relevant in my local archive after a quick search. > > As I see it, the notion of command modes can be eliminated entirely, Yes it could be. But right now we're faced with just a regression, where adding -c init -c "poll off" to a working comand line causes things to fail. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Saturday 28 November 2009, Zach Welch wrote: > > Maybe part of the problem is that putting the "init" on the command line > > with a bunch of other commands. Confirmed: take a working command line and add ... -c init -c "poll off" and it no longer works. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Sat, 2009-11-28 at 16:36 -0800, David Brownell wrote: > On Saturday 28 November 2009, Zach Welch wrote: > > I believe that the real problem is that the .mode initializer for those > > commands' registration records have been marked incorrectly. There may > > be others It's easy to discover which ones need to be fixed, but > > that does not sound like the only problem. > > Maybe part of the problem is that putting the "init" on the command line > with a bunch of other commands. I have startup scripts, some of which > tweak things on the command line and some of which do it in a per-board > setup.cfg file ... small sample of two shows the former breaking but not > the latter. Yeah, I figure there are some scripts (or users) that have not been sufficiently strict about CONFIG vs. EXEC modes, as that logic has been broken for ages Nevertheless, the very design needs to be improved. Indeed, this feature presents a layering violation. Right now, the command layer knows too much about the state of initialization. Even a simple 'enable/disable' state would be a sufficient generalization of the intended functionality; however, many commands should be registered only once they can be used, which we do in very small doses today. Why not allow the user to bring up an interface once its defined? Specifically, the 'init' command might be a subcommand associated of a specific (named) interface device instance. It would give other commands for configuring the TAPs, devices, and targets associated with that interface. Naturally, this implies multiple interface support, so OpenOCD can support gang-programming and multi-head test applications. Naturally, it should be possible to run 'init' interactively, such that one can startup OpenOCD without any interface defined. That change should be possible independently of other work in this area. I seem to recall the topic being discussed in the past, but I can't find anything relevant in my local archive after a quick search. As I see it, the notion of command modes can be eliminated entirely, if we are careful in how we restructure the command hierarchy. Indeed, I should have articulated this impetus in my post on the topic; however, effecting this all correctly will require tremendous amount of work. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Saturday 28 November 2009, Zach Welch wrote: > I believe that the real problem is that the .mode initializer for those > commands' registration records have been marked incorrectly. There may > be others It's easy to discover which ones need to be fixed, but > that does not sound like the only problem. Maybe part of the problem is that putting the "init" on the command line with a bunch of other commands. I have startup scripts, some of which tweak things on the command line and some of which do it in a per-board setup.cfg file ... small sample of two shows the former breaking but not the latter. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Sat, 2009-11-28 at 15:21 -0800, David Brownell wrote: > On Saturday 28 November 2009, David Brownell wrote: > > I just pulled everything into a workspace and built it ... now it's > > failing left and right. > > > > It complains about using "poll off" and "jtag_reset 1 1" after reset, > > which is when they're supposed to be usable... > > And if I disable that error check, it dies even more horribly: > > Debug: 163 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 164 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 165 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 166 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 167 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 168 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 169 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 170 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 171 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 172 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 173 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 174 899 command.c:317 register_command_handler(): registering > 'ocd_flash'... > Debug: 175 899 openocd.c:136 handle_init_command(): flash init complete > Debug: 176 899 openocd.c:140 handle_init_command(): mflash init complete > Debug: 177 899 openocd.c:144 handle_init_command(): NAND init complete > Debug: 178 899 openocd.c:148 handle_init_command(): pld init complete > Debug: 179 899 gdb_server.c:2237 gdb_init(): gdb service for target > pxa255.cpu at TCP port > Info : 180 899 tcl_server.c:165 tcl_init(): tcl port disabled > User : 181 899 command.c:782 openocd_jim_vfprintf(): Runtime error, file > "command.c", line 608: > User : 182 899 command.c:782 openocd_jim_vfprintf(): > > as in, just exits during startup. Can you figure out which command in your script is dying? I'll fix it, but I need to know where to start looking. :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Sat, 2009-11-28 at 15:10 -0800, David Brownell wrote: > I just pulled everything into a workspace and built it ... now it's > failing left and right. > > It complains about using "poll off" and "jtag_reset 1 1" after reset, > which is when they're supposed to be usable... I had tested that the patch worked for me, but clearly there are too many commands for me to verify without a test suite. Maybe that should be my next series, rather than more refactoring. :) I believe that the real problem is that the .mode initializer for those commands' registration records have been marked incorrectly. There may be others It's easy to discover which ones need to be fixed, but that does not sound like the only problem. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] everything must be "used before init" ??
On Saturday 28 November 2009, David Brownell wrote: > I just pulled everything into a workspace and built it ... now it's > failing left and right. > > It complains about using "poll off" and "jtag_reset 1 1" after reset, > which is when they're supposed to be usable... And if I disable that error check, it dies even more horribly: Debug: 163 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 164 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 165 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 166 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 167 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 168 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 169 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 170 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 171 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 172 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 173 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 174 899 command.c:317 register_command_handler(): registering 'ocd_flash'... Debug: 175 899 openocd.c:136 handle_init_command(): flash init complete Debug: 176 899 openocd.c:140 handle_init_command(): mflash init complete Debug: 177 899 openocd.c:144 handle_init_command(): NAND init complete Debug: 178 899 openocd.c:148 handle_init_command(): pld init complete Debug: 179 899 gdb_server.c:2237 gdb_init(): gdb service for target pxa255.cpu at TCP port Info : 180 899 tcl_server.c:165 tcl_init(): tcl port disabled User : 181 899 command.c:782 openocd_jim_vfprintf(): Runtime error, file "command.c", line 608: User : 182 899 command.c:782 openocd_jim_vfprintf(): as in, just exits during startup. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
