2011/1/24 Aaron Carroll <aar...@cse.unsw.edu.au>
> This patchset adds support for the OMAP4430/Pandaboard and the ARM
> Cortex-A9 CPU. For now I have clagged the A8 code into cortex_a9.c
> to avoid breaking A8.
>
> To deal with multiple cores exposed by one DAP, I've introduced a
> '-coreid' target option, which does the obvious. At present, only
> one of the A9 cores can be connected at a time. I think the main
> impediment to connecting several A9 targets is sharing of a single
> ADIv5 instance.
>
> Note that debugging the A9's on the Pandaboard does not work with
> the usual bootloader (x-loader), because (I think) the debug clocks
> get disabled. If anyone knows how to re-enable them, please get in
> touch.
>
>
Good job Aaron!
I've been working on this issue as well, but I was stuck trying to halt the
core.
With your patch it seems to work. Anyway after issuing "halt" instruction, I
always get the following message:
target state: halted
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x60000173 pc: 0x0002dc92
MMU: disabled, D-Cache: disabled, I-Cache: enabled
I would point out that I'm using PandaBoard without any SD inserted, so only
ROM code is executed.
It seems quite strange that the target state is always Thumb and not ARM.
Even pc value is strange, I would expect someting in the range
0x40028000-0x40033FFF (which is where the ROM boot code is mapped, right?).
Am I missing something here? Thanks.
Regarding x-loader issue, I also noticed this problem. After a little
investigation I found that the problem is related to clocking (as you
correctly presume).
After executing the following function (in x-loader source,
board/omap4430panda/clock.c) OpenOCD is no more able to talk to the target:
void lock_core_dpll_shadow(void)
{
dpll_param *dpll_param_p;
/* Lock the core dpll using freq update method */
*(volatile int*)0x4A004120 = 10; //(CM_CLKMODE_DPLL_CORE)
dpll_param_p = &core_dpll_param[6];
/* CM_SHADOW_FREQ_CONFIG1: DLL_OVERRIDE = 1(hack), DLL_RESET = 1,
* DPLL_CORE_M2_DIV =1, DPLL_CORE_DPLL_EN = 0x7, FREQ_UPDATE = 1
*/
*(volatile int*)0x4A004260 = 0x70D | (dpll_param_p->m2 << 11);
/* Wait for Freq_Update to get cleared: CM_SHADOW_FREQ_CONFIG1 */
while( ( (*(volatile int*)0x4A004260) & 0x1) == 0x1 );
/* Wait for DPLL to Lock : CM_IDLEST_DPLL_CORE */
wait_on_value(BIT0, 1, CM_IDLEST_DPLL_CORE, LDELAY);
//lock_core_dpll();
return;
}
In particular the write to CM_SHADOW_FREQ_CONFIG1 (0x4A004260) is causing
the problem (before writing 0x70D the value is 0xC0C).
At the moment I'm not able to understand very well what this means (clocking
in OMAP4430 is quite complicated). However I'm still investigating... keep
in touch.
Thanks
regards
Luca Ellero
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
