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
>>>> therefore ...thanks). The last piece I was missing was something Arnim
>>>> Läuger (urjtag) already told
>>>> 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,
>>>> I updated the git and will continue working from there
>>>> until we have something decent. Many thanks to many people! specially
>>>> Dirk, Duane and Arnim!
>>>>
>>>> you can git clone git://github.com/keesj/openocd-keesj.git
>>> I tried it and can confirm: It works!
>>> Great!!
>>> Now, before (in parallel?) working on Cortex A8 support Rick
>>> mentioned, we should get recent into svn:
>>> Can we get
>>> 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?
>>
>> 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.
>>
>> 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
>> }
>>
>
> 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?
> 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.
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?
Sorry if I missed some documentation.
Best regards
Dirk
>
>
>> #jtag scan chain
>> 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
>>
>> 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"
>> }
>
> --
> 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
>
>
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
