On Sat, Feb 27, 2010 at 01:29:28PM -0800, David Brownell wrote: > On Saturday 27 February 2010, Mariano Alvira wrote: > > There's a business in chip-specific LED-blinking systems?? ;)
Oh there sure is! I call it the devkit business. > > 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".. Pulling the address out of blink.bin would be great, although it probably needs to be load_elf blink.elf (which would be pretty cool). > 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. Agreed. Although I'm more thinking "customer" and not "user" --- the difference is often the "learning" part. > > 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. But my board is a dev kit and a routine like this fits into my (the manufacturer) support story. One difference here is between board and chip. But since 0x00400000 is where the flash gets mirrored, I feel this useful to anyone using the mc13224v. Anyway, that's the best case I can make. Your idea of load_image pulling the address is better anyway. > > 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? Well, to be fair, I talk to a lot of people using the mc13224v. And there aren't too many other people supporting them with OpenOCD or open source. And besides Freescale and CEL, I'm the only other one selling dev. kits. Generally I think every snippet or procedure that makes something easier should be somewhere. > > Someone else might take it ... but I won't. Ok. It's gone then. Thanks for the help, -Mar. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
