On Sunday 25 October 2009, Magnus Lundin wrote:
> I prefer read_cp/write_cp to mrc/mcr, since we really want to read/write
> to the coprocessor registers. The fact that this is implemented using
> the mrc/mcr instructions is not important here. There are no other arm
> instructions treated like that, rather we specifiy the registers, memory
> etc. that we want to access.
Actually I think MCR/MRC is probably appropriate. When you look
at how these "coprocessor registers" are specified ... they really
boil down to fourteen bits in the MCR/MRC instructions, plus one
more stipulated by the use of MCR/MRC instead of MCR2/MRC2.
Or, for 64 bit values, MCRR{,2}/MRRC{,2} also have 15-bit register
specs. Same deal: the register is specified as an N-tuple of bits
that are parameters to the instruction: CRn, CRm, Opcode_1, Opcode_2,
and the conceptual bit indicated by e.g. MRRC vs MRRC2.
So unless you treat "read_cp" as just an instruction rename (and
maybe passing MRC-vs-MRC2 as Yet Another Parameter), you're not going
to get away from doing exactly what the mrc and mcr routines do...
> It is definitely possible that there might be a future coprocessor
> access debug component that accesses coprocessors using a coresight
> memory mapped interface.
Not persuasive. We can speculate on all kinds of things that
haven't happened yet. The *point* of the coprocessor stuff is
that it can be accessed through instructions, integrating with
the CPU pipeline. That's what distinguishes coprocessors from
random memory-mapped peripherals ... or from DSPs which are
fully independent and communicate via memory or mailboxes.
If some particular coprocessor creates a custom debug interface,
and advertises itself in the ROM table, that's another thing.
It would be a bunch of special case work to talk to it. But
that wouldn't obsolete instruction based access.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
