In case someone's looking for a useful update to contribute in
the 0.5 series ...

The ARM cores currently all use a register dump protocol which
includes a bunch of Floating Point Accelerator (FPA) registers.
That floating point hardware has been obsolete for a long time;
from what I can tell, since the last ARMv3 cores.

If you have an ARM and recent GDB to test with, you could add
an "arm" subcommand to disable that usage when the GDB side is
using the "set tdesc .../arm-core.xml ..." to configure a current
non-legacy target description (using non-FPA XML config file).
Maybe "arm fp none" vs "arm fp vfp2" etc (see below).

I'm not sure I'd recommend yet having OpenOCD *produce* such a
target config on demand[1], mostly since the GDB folk don't seem
to have stabilized that yet.

Related, once you get such simple non-ancient target descriptions
to work, you could support newer hardware you may have in hand:

 - XScale with iwMMXt ... you could support those registers.
   GDB evidently understands them; use "arm-with-iwmmxt.xml".
   (I think this works with some older GDB versions.  Adding
   this support would be XScale-specific, not ARM-generic.)

 - ARM with VFP2 ... likewise.  VFP2 adds sixteen registers that
   can hold IEEE double values; use "arm-with-vfpv2.xml".

 - ARM with VFP3 ... likewise, but with thirty-two registers and
   maybe NEON support (as on Cortex-A8).  Use "arm-with-vfpv3.xml"
   or maybe "arm-with-neon.xml" target config file.

Just having a clean way to disable the FPA stuff would be useful.
Exposing those other registers gives bonus points though!

- Dave


[1] https://lists.berlios.de/pipermail/openocd-development/2008-July/002421.html
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to