On Saturday 27 February 2010, Mariano Alvira wrote: > > Well, "handy" doesn't seem sufficient to require everyone using this > > chip to have that. > > > > This is however also sufficiently obvious (though I'd just "halt") > > that most OpenOCD users should be able to whip that up easily. > > Nope. Only obvious if you've used OpenOCD a lot before. Most people > get a new board, plug it in/hook it up and run openocd and say "now > what?". It would be very nice to say back: "type mc1322x_run > blink.bin".
There's a business in chip-specific LED-blinking systems?? ;) To the extent that wanting to do something quickly is a common goal, I'd say such answers shouldn't be specific to any processor or board, If the docs are unclear that "load_image blink.bin" followed by "resume <address>" is a good first step, then we should fix those docs. (Including pulling the <address> out of "blink.bin".. > > Those are both issues. But more to the point, not everyone using > > OpenOCD will need or want that ... and anyone who does need it > > can easily craft their own. > > Well, we are only talking about mc13224v.cfg users here --- and I'm > pretty sure everyone of them is going to want that routine. Maybe. I really do have a hard time believing that telling them to type two lines instead of one will hurt anyone ... however, if the two lines are fully documented, but the one isn't, I think the users will learn more easily from the two-line answer. > There are similar things for loading/running uboot in sheevaplug, > openrd. What's so special about uboot.bin? The answer is that it's > handy to just type 'sheevaplug_reflash_uboot_env' and if you have a > sheevaplug that's probably something you'll want to do a lot. One thing that's different is that the Sheevaplug stuff is part of the board-specific stuff and fits into the board manufacturer's support story. Like how to upgrade it with the latest firmware. Your script on the other hand isn't updating firmware. > The same is true here. If you are working with an mc13224v you are > going to want to load an image to location 0x00400000 and run it --- a > lot. There are other things you'd want to do a lot; like making GDB do that for you. How do you know which of those things should be in scripts that *every* user sees? > But look, if it means you guys won't take it then I won't include > it. Someone else might take it ... but I won't. > If that's the case though it would be nice to have a place for > these sorts of "handy" and more UI oriented routines. I referenced the section of the User's guide which talks about such project-specific developer utilities. Most developers start to collect a set of things which fit into their particular work patterns ... and a good place for them is in "openocd.cfg" for that projet, or their own script library. - Dave > > (You could "resume 0x00400000" and that would > > be just a bit more concise.) > > Thanks. > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
