Beautiful work.
Harald Welte wrote:
> 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()
>
>
What happens when you do "dap info 0" from the telnet interface ?
> 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,
>
So you can read some of the registers, can you read CPUDBG_DSCR ? and
its value is?
Your problems are probably related to the DBGEN signal, this is an input
to the Cortex_A8 core and controls debug access. There is some
documentation of this in the Cortex_A8 TRM, but no way to controling it
from the debug registers defined by ARM.
On the Omap3530 this signal can be set by bit 13 in address 0x5401d030 .
This can be found in section 25.6.4 of the OMAP353x TRM but they call
the signal DBGEM which is probably a mistake.
So in the OMAP initialisation script we have the line
# set DBGEN signal
mww 0x5401d030 0x00002000
Hope this can give some help.
Best regards
Magnus
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
