On Sunday 20 September 2009, Øyvind Harboe wrote:
>
> Short term(a year or so), I'd like to see robustness for
> the ARM target *much* improved
"The" ARM? :)
There are a lot of them ...
- ARMv4 chips other than ARM7TDMI ("Mr Embedded ARM")
aren't big growth targets;
- ARMv5 has many current clients (Feroceon, Xscale, and
ARM926 for starters);
- ARMv6 has a somewhat limited market
- Cortex-M3 is getting very interesting, and the M1/FPGA
and M0/micro targets are pretty compatible (& ARMv6-M)
- Cortex-A8 also getting very interesting; A9 soon
I agree that ARM + ft2232 seems to be the sweet spot
in terms of activity and value.
Right now I'm a bit more conscious of functional limits
than robustness. Reset handling isn't flexible enough;
but I have a few simple and concrete suggestions I'll
make before long.
> and the target library
> become increasingly support more targets and support
> them better.
Yes. "More targets" should be relatively easy now;
at least where the CPU support is in place.
"Support them better" is a bit trickier. In concrete
terms, I'd suggest being more visibly comparable to
commercial products -- on a task-by task basis, there
should be no major deficiencies, and that includes
GUI integration.
> OpenOCD should be the best and cheapest
> alternative (in terms of engineering & marketing effort) for
> ARM chip vendors. I'm not concerned about hardware cost
> to developers, because putting an ft2232 on an eval
> board costs $1, it doesn't get any cheaper...
Well I just priced at DigiKey, and I saw Q-1000 prices
are higher than that. Full speed, $US 3.85; high speed
is a bit cheaper (yay!) at $US 3.70 ... plus there are
a few other components. Agreed that savvy vendors are
going to do just that, and swallow some loss of sales of
higher end JTAGs in favor of universal developer access.
(At least for embedded boards.)
> Eventually I hope that we'll be able to identify some killer
> features that closed source solutions just don't offer and
> that it will become uneconomical to implement from scratch
> for each JTAG debugger. I don't really know what those
> features might be though.
I think unique features will be hard to come by; but they
aren't necessary either. Consider that while GCC isn't
the best compiler, it's still more or less a "must work"
for any modern processor; ditto GDB (which for some reason
I've never taken a shine to).
For developers who want a challenge, however...
> Some ideas:
>
> - Threads support(e.g. eCos, FreeRTOS, etc. threads)
Linux debugging support, specifically JTAG debugging of
user mode tasks instead of just kernel context. Might
require better MMU-intelligence, and support of "monitor
mode" debugging so that breakpoints are inactive unless
the right user mode task is active.
Linux kernel threads too, maybe. For Cortex-A9, SMP
intelligence will be needed. (Watch for OMAP-4...)
> - Profiling support(??) there is profiling support in OpenOCD
> now, but I haven't heard about anyone using it.
Tracing support, as with the ARM ETM module. One mode
hooks up to the ETB (on-chip trace SRAM). Xscale has some
tracing stuff too.
In fact ... ARM has a boatload of widely available debug
hardware and doodads. We barely scrape the surface of what
can be done on a fairly generic Cortex-M3.
> - Connect up to other GPL code. We're already connected
> to GDB as much as we should be... What else?
Eclipse, for starters. (That might be just instructions...)
And I'm not sure we do GDB as well as should eventually
be needed. As you've noted, the debug model there needs
work still.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
