Hello,
On 07.02.2011 09:27, luca ellero wrote:
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.
It's the same for me.
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?
This should be done in arm_adi_v5.c and for maybe future changes of ap numbering the correct AP for
AHB and APB is a variable in struct adiv5_dap and not hard coded. Maybe dap->ap_ahb and dap->ap_apb.
For the first implementation/test the initialization of both should be hard coded and later this can
be done in some kind of dap auto detection. For auto detection we can use parts of the
dap_info_command function. This function walk over all AP and the connected components.
Regards,
Mathias
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
