I'm starting to read the documents Rick gave in

https://lists.berlios.de/pipermail/openocd-development/2009-April/005273.html

:)

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 such 
> wonderful documentation.
> 
> =======
> 
> 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 dap 
> thing? I'd like to ask a number of questions... what should the command 
> look like? What features/options should it have?
 >
> =======
> 
> Specifically - I'm looking at ARM IHI 0031A - Figure 2-2, page 2-9, PDF 
> page 45. There's this nice diagram that shows the 5 basic registers in 
> the DAP. I think having a command line exploration tool/command would be 
> very helpful. Any agreement?

It's my understanding that we have these commands now with

https://lists.berlios.de/pipermail/openocd-development/2009-April/005305.html

?

> Next, item is figuring out how the DAP is configured in the A8 - and 
> which 'ports' are implemented. on this beast, ie: What access points out 
> of the DAP are implemented. In the M3 - it seems nicely documented This 
> part, 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?

Looking at the TRMs, yes, it seems that it's not documented what 
access points out of the DAP are implemented for Cortex A8 (OMAP3 
ARM's part). Did I miss something or are there any news?

If not, the plan is to use the "dap" command and try to get this by 
try & error. Correct?

> It seems, that we need to look at address 0xffc - in the "rom table" and 
> work backwards from there, ie: See IHI 0031A - section 1.2.3, And - 
> section 13.2 - the CID0 to CID3 registers... should lets us "walk" the 
> register tables. however, it seems the cortex_swjdp.c - seems to be some 
> what "purpose built" for the M3. Agree? Or am I missing something?
> 
> =====
> 
> 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.

For what we have already in OpenOCD (jrc config), I still have two 
questions:

- For OMAP3 JRC we get ID code

0x0b7ae02f (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0)

and OMAP3 CPU gives

0x0B6D602F (Manufacturer: 0x017, Part: 0xB6D6, Version: 0x0)

This 0x017 doesn't seem to be ARM ID. Is there somewhere an JTAG 
manufacturer list which can be used to decode these IDs?

- We already had a short discussion about this, but I couldn't figure 
how to add

jtag tapenable omap3.cpu

to a OpenOCD instead of doing it manually, yet. Any additional hints?

Many thanks and best regards

Dirk


_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to