Re: [Openocd-development] WORKS!!!! Was: OMAP3 JTAG

[Rick Altherr]

On Mar 10, 2009, at 11:40 AM, Dirk Behme wrote:

Rick Altherr wrote:

On Mar 9, 2009, at 10:33 PM, Dirk Behme wrote:

Dirk Behme wrote:

Kees Jongenburger wrote:

Hi Duane and others,

I finally managed to get this thing working (using Duane's patch

Läuger (urjtag) already told

I updated the git and will continue working from there

Dirk, Duane and Arnim!

you can git clone git://github.com/keesj/openocd-keesj.git

therefore ...thanks). The last piece I was missing was something Arnim us that the DAP apparently is added before the jcr. I am attaching an initial working config but it needs more work and needs Duane's patch, until we have something decent. Many thanks to many people! specially

I tried it and can confirm: It works!
Great!!

Can we get

Now, before (in parallel?) working on Cortex A8 support Rick mentioned, we should get recent into svn: https://lists.berlios.de/pipermail/openocd-development/2009-March/004840.html applied? Kees: Or did you any changes? If yes, could you send an updated version of Duane's patch?

Thanks

Dirk
#File omap3.cfg
#TI OMAP3 processor - http://www.ti.com

if { [info exists CHIPNAME] } {    set  _CHIPNAME $CHIPNAME
} else {    set  _CHIPNAME omap3
}

if { [info exists ENDIAN] } {    set  _ENDIAN $ENDIAN
} else {   # this defaults to a little endianness
set  _ENDIAN little
}

if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# force an error till we get a good number
set _CPUTAPID 0x0B6D602F
}

Ah, I forgot: And can we get the two necessary config files into svn, too? The two files in attachment are mainly cleaned up versions from Kees, with omap3530 renamed to simply omap3.

Is this really generic to all of the OMAP3 parts?

Who knows?

I'd expect the IDCODE to be different for each one at least.

About which ID code do you talk here? About the jrc or cpu one? Why do you think it would be different?

In general, the CPU one.

Can we guarantee that the JRC programming sequence is the same as well? If not, then we should stick with calling it omap3530.cfg.

Why? Can we guarantee that all .cfg are different? If not, you will end with omap3530.cfg, omap3503.cfg, omap3515.cfg, omap3525.cfg, same for omap34x and upcoming omap36x being most probably identical.

True, but we already have this today for things like Luminary parts.

I vote for starting with omap3.cfg expecting that all configs are the same and change it if we find something different.

From my understanding 0x0B6D602F is the ID of "ARM" (Cortex A8) TAP and why should it be different in the various OMAP3?

I thought these were different per part, but it appears they are commonly shared. If the IDs are the same and the programming is the same, then omap3 is fine.

Sorry if I missed some documentation.

Best regards

Dirk

#jtag scan chain


jtag configure $_CHIPNAME.cpu -event tap-enable {
   puts "Enabling Cortex-A8 @ OMAP3"
   irscan omap3.jrc 7 -endstate IRPAUSE
   drscan omap3.jrc 8 0x89 -endstate DRPAUSE
   irscan omap3.jrc 2 -endstate IRPAUSE
   drscan omap3.jrc 32 0xa3002108  -endstate IDLE
   irscan omap3.jrc 0x3F -endstate IDLE
   runtest 10
   puts "Cortex-A8 @ OMAP3 enabled"
}

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0x0 - expected-id $_CPUTAPID -disable jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0xf - expected-id 0x0b7ae02f

--
Rick Altherr
kc8...@kc8apf.net

-- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

--
Rick Altherr
kc8...@kc8apf.net


 -- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development