Adding support for mrc/mcr interface in XScale in a sensible fashion
would require updating debug_handler.S.
Could I define a generic execute mrc/mcr command and rely on
self modifying code?
- r0 - input value
- instruction - 32 bit value with instruction to execute
- r0 - output value
That would entail self-modifying code. That seems a bit too
clever... Is there a better way?
I'm inclined to leave the code as is until someone asks for the
mrc/mcr support specifically...
See code below for how this mrc/mcr is implemented today.
write_cp_reg:
@ requested cp register
bl receive_from_debugger
mov r1, r0
@ value to be written
bl receive_from_debugger
adr r2, write_cp_table
add pc, r2, r1, lsl #3
write_cp_table:
mcr p15, 0, r0, c0, c0, 0 @ XSCALE_MAINID (0x0)
b get_command
mcr p15, 0, r0, c0, c0, 1 @ XSCALE_CACHETYPE (0x1)
b get_command
mcr p15, 0, r0, c1, c0, 0 @ XSCALE_CTRL (0x2)
b get_command
mcr p15, 0, r0, c1, c0, 1 @ XSCALE_AUXCTRL (0x3)
b get_command
mcr p15, 0, r0, c2, c0, 0 @ XSCALE_TTB (0x4)
b get_command
mcr p15, 0, r0, c3, c0, 0 @ XSCALE_DAC (0x5)
b get_command
mcr p15, 0, r0, c5, c0, 0 @ XSCALE_FSR (0x6)
b get_command
mcr p15, 0, r0, c6, c0, 0 @ XSCALE_FAR (0x7)
b get_command
mcr p15, 0, r0, c13, c0, 0 @ XSCALE_PID (0x8)
b get_command
mcr p15, 0, r0, c15, c0, 0 @ XSCALE_CP_ACCESS (0x9)
b get_command
mcr p15, 0, r0, c14, c8, 0 @ XSCALE_IBCR0 (0xa)
b get_command
mcr p15, 0, r0, c14, c9, 0 @ XSCALE_IBCR1 (0xb)
b get_command
mcr p15, 0, r0, c14, c0, 0 @ XSCALE_DBR0 (0xc)
b get_command
mcr p15, 0, r0, c14, c3, 0 @ XSCALE_DBR1 (0xd)
b get_command
mcr p15, 0, r0, c14, c4, 0 @ XSCALE_DBCON (0xe)
b get_command
mcr p14, 0, r0, c11, c0, 0 @ XSCALE_TBREG (0xf)
b get_command
mcr p14, 0, r0, c12, c0, 0 @ XSCALE_CHKPT0 (0x10)
b get_command
mcr p14, 0, r0, c13, c0, 0 @ XSCALE_CHKPT1 (0x11)
b get_command
mcr p14, 0, r0, c10, c0, 0 @ XSCALE_DCSR (0x12)
b get_command
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
