duane> I think your view is more (A), and mine is more (B).
david> Yet my example of a "flash download" tool seems more like (B) to
me. :)
Seems like we both sit at two different ends of the spectrum, you see
"de-bricking/flashing" a board as day to day I don't. That is perhaps
good, it makes one think of the other use cases.
If I where to list "use case areas of interest" - they would be:
(a) "my board is a brick - please help me reflash(recover) my board"
type GUI interface.
Be it "linux" or some other operating system - the board is dead and
must be recovered.
This is more for the "linux target board developer type".
Also WinCE types, ie: "urjtag" type solution, and is more "flash
programmer centric"
Much of this is External NOR flash,or External NAND flash.
What is not - is micro-controller based stuff which is more (d) then
(a).
Boundary scan method works (ie: the UrJTAG approach) but is slow
or the "download helper code" (the OpenOCD approach) faster.
(b) How to write a "xlinix flash programer" type solution
aka: Much like Xilinx IMPACT, or the Altera equal (I don't know the
name).
This is more "jtag centric".
I guess this is more Dick Holenbeck type centric (he wrote the xsvf
support).
(c) Boundary Scan - wiggle pins on the jtag chain.
People have asked about this... and we have talked about it
But there are no "drum beaters" eager to help.
(d) Debug & Software Development solutions.
Mostly "non-linux-kernel" micro controller centric
"uboot" debug falls into this category.
===
agree?
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
