On Mar 23, 2009, at 7:57 PM, Duane Ellis wrote:
So - I guess the next step with OMAP - aka: CortexA8 is to figure out how the DAP interface works.The existing dap code - well - It's a bit confusing to me, and has suchwonderful documentation.
The dap code provides a layer to handle requests to the DPACC register. That's the bulk of it.
======= I'm thinking that adding a "dap" command will be helpful - for both Cortex M3 - and A8. Any objections? Who knows a lot about this dapthing? I'd like to ask a number of questions... what should the commandlook like? What features/options should it have?
Yes, a dap command would be useful. You will find that there isn't a whole lot in the dap layer before you are dealing with the AHB and APB bus ports.
=======Specifically - I'm looking at ARM IHI 0031A - Figure 2-2, page 2-9, PDFpage 45. There's this nice diagram that shows the 5 basic registers inthe DAP. I think having a command line exploration tool/command would bevery helpful. Any agreement?
Yes.
======= Next, item is figuring out how the DAP is configured in the A8 - andwhich 'ports' are implemented. on this beast, ie: What access points out of the DAP are implemented. In the M3 - it seems nicely documented Thispart, I'm a bit confused about. Are you? Anybody else? The diagram (figure 2-2 above for the M3) shows a "SELECT" register... offset 8 in the DPACC range, the output of which becomes the APSEL (access port select). Hence, my idea of having a "dap" command that lets one experiment and figure things out. Ideas/Suggestions? Objections?
ARM IHI 0031A is only the starting point for the generic ADIv5. You will probably also want DDI 0316D, IHI 0029B, and DDI 0314F. While we _could_ implement everything as specific lists of ports for a given part, the ADIv5 and CoreSight architecture provide a mechanism for autodiscovery. I'd prefer that any work on these types of devices use it.
=====It seems, that we need to look at address 0xffc - in the "rom table" andwork backwards from there, ie: See IHI 0031A - section 1.2.3, And - section 13.2 - the CID0 to CID3 registers... should lets us "walk" theregister tables. however, it seems the cortex_swjdp.c - seems to be somewhat "purpose built" for the M3. Agree? Or am I missing something?
swjdp was written to handle the M3. A more general purpose layer would be useful. To do that, you need to consult the ROM tables at the DAP and AHB/APB levels. That tells us what debugging endpoints are available.
=====My guess the "jtag-acces-port" interface is not one that is implemented,but is documented in IHI 0031A, ie: section 2.2.1 this would be used for things internal that are Jtag type devices - which don't exist.
I believe the JTAG AP is implemented, but there is no special functionality in it.
-Duane. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
