On 07/02/2011 3.54, Aaron Carroll wrote:
On 04/02/11 17:31, Mathias K. wrote:
Hello,
On 04.02.2011 01:38, Aaron Carroll wrote:
At a high level, I think it makes sense for functions to be explicit
about selecting an AP... I don't see any advantage to a "default".
I don't know if the AP always equal in a complete architecture or is
this done at cpu vendor level. For mem read/writes we need the AP with
the CPU component. You can determine this by "dap info X" command (as
example cortex_r4/TMS570):
[snip]
If i look into the cortex_a8 sources then i think the cpu component is
in AP 0 and there is no switching needed. Can anyone send the "dap info
X" output for a cortex_a8 ?
On A8/omap35xx and A9/omap44xx, the CPU CoreSight component is on AP 0
(an APB-AP). However, for both these platforms we do memory accesses
on AP 1, which is an AHB-AP. One advantage of this is the core does
not need to be halted to access memory. The upshot is that we do need
to switch between AP's. I agree that this should be abstracted somehow,
but in the mean time A9 is broken :)
Correct me if I'm wrong but I think it's the opposite: AHB-AP is 0 and
APB-AP is 1. Furthermore, there is also a JTAG-AP which is AP 2.
See CoreSight TRM (ARM DDI 0314H).
At the moment I'm just implementing access to memory through APB (so we
can access also memory on L2). What I'm doing right now is
differentiating access based on which AP is selected. In other words if
we want to access memory through AHB we need to issue "dap apsel 0"
before, if we want to access memory through APB we need to issue "dap
apsel 1" before.
What do you think? Have you any better ideas?
regards
Luca
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
