Hi All!
Throughout the last week or so, I've been trying to get OpenOCD to work
on a new (not public yet) Cortex-A8 based SoC. Right now I feel a bit
stuck, despite having read the CoreSight docs from ARM as well as the
Cortex-A8 reference manual chapter 12...
The first thing I obviously did was to redefine OMAP3530_DEBUG_BASE
On the SoC that I'm working on, the base address (on the APB) for the
Cortex-A8 is 0x80005000.
The ROMTABLE starts at 0x80000000 and the entries are also valid, I can decode
them properly using 'dap info'. DAPSEL 0 is the AHB, where DAPSEL1 is the APB,
like on the OMAP.
The only thing special about the Coresight implementation on this SoC is that
the 0x80000000 / 0x00000000 base address is only valid on the APB. The same
addresses are mapped to 0xE0D00000 on the AHB.
However, OpenOCD does not even get to the point of creating the telnet
socket for the command interface.
In order to get the code to do anything at all, I had to manually insert a
dap_ap_select(swjdp, 1);
before the two lines
dap_ap_read_reg_u32(swjdp, 0xFC, &idreg);
dap_ap_read_reg_u32(swjdp, 0xF8, &romaddr);
in ahbap_debugport_init()
After that change was made, I can successfully get OpenOCD started, telnet in
and then use comands like dap info, dap apsel, etc.
However, the Cortex-A8 part is still not working. cortex_a8_examine() works
great, i.e. it reads the CPUID, CTYPR, TTYPR and DIDR and they all provide
reasonable results.
However, as soon as the code enters cortex_a8_poll() and calls
retval = mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, &dscr);
the implicit swjdp_transaction_endcheck(). Specifically,
SSTICKYORUN is set during the first DP_CTRL_STAT read.
The LOG_DEBUG("swjdp: status 0x%" PRIx32 "", ctrlstat); tells me that the clear
of the STICKY bit was successful. However, during the next cortex_a8_poll()
timer, the same error happens again and again.
However, I can already access system memory using "mdr" from the telnet
interface. Just anything regarding the A8 does not work.
By manually peeking around in the AHB address space, I can also read the
coresight memory range (on 0xE0D00000), including some of the A8 registers,
including the 0xE0D05000 CPUDBG_DIDR or 0xE0D05D00 CPUDBG_CPUID register.
However, if I try to read some other registers such as CPUDBG_DRCR or
CPUDBG_WFAR, I will again run into transaction problems. I'm not sure if
this is now expected, since I'm now using the AHB to access those registers.
Does anyone have a clue how to further debug this problem? By now I
unvoluntarily know way more about coresight than I ever wanted to know, so I'm
quite happy to receive high-level ideas which I can then try and/or implement.
And yes, if I get this fixed I'll obviously contribute the code as well as
the .tcl files.
Thanks in advance,
--
- Harald Welte <[email protected]> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
