Rick Altherr wrote:
>
> On Dec 19, 2008, at 12:25 PM, Dirk Behme wrote:
>
>> * Thanks to Dave, Rick and I got the "TI doc" now.
>>
>
> And it has raised more questions.
>
>> * I now get
>>
>> -- cut --
>> > openocd -s lib/openocd/
>> Open On-Chip Debugger 1.0 (2008-12-19-17:38) svn:1261
>>
>> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>>
>> $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
>> jtag_speed: 1
>> Info: JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f
>> (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0)
>> Info: JTAG Tap/device matched
>> Warning:no gdb ports allocated as no target has been specified
>> Warning:no tcl port specified, using default port 6666
>> -- cut --
>>
>> This is with Flyswatter, TinCanTools' adapter and BeagleBoard. I
>> think this shows that recent svn works with Flyswatter :)
>>
>
> At least one piece of the puzzle is filled in. After a reset, the JRC
> needs 10 TCK pulses to wake up the JTAG power domain. So, the first
> DRSCAN returning 0xffffffff and the first IRSCAN seemingly having no
> effect after a reset is because the hardware turns on partway through
> the state machine. I think we can address this in the config fairly
> easily.
Does this "waiting 10 TCK fairly easily" mean there is already a
command to wait 10 TCK or does this mean it can easily implemented/added?
I'm thinking about adding something like
jtag_reset
wait 10 TCK
to omap3530.cfg script. E.g.
jtag configure $_CHIPNAME.cpu -event tap-enable {
puts "Enabling Cortex-A8 @ OMAP3"
=> jtag_reset
=> wait 10 TCK
irscan omap3530.jrc 7
drscan omap3530.jrc 8 0x89
irscan omap3530.jrc 2
drscan omap3530.jrc 32 0x81000080
drscan omap3530.jrc 32 0xa3002048
drscan omap3530.jrc 32 0x81002148
drscan omap3530.jrc 32 0xa3002148
runtest 10
puts "Cortex-A8 @ OMAP3 enabled"
}
Would this be wrong?
> The good news is that we can _possibly_ bring up the DAP and not
> attempt a second chain examination. It means the output of scan_chain
> will be wrong in some ways, but at the very least, we should be able to
> manually query the DAP. If nothing else, being able to talk to the DAP
> means that development on Cortex-A8 target support can start even if
> the JRC isn't behaving perfectly.
How would I do "we should be able to manually query the DAP"? I.e. how
would I verify that I can talk to the DAP if second scan_chain
"doesn't work"?
Currently, I get
-- cut --
> scan_chain
TapName | Enabled | IdCode Expected IrLen
IrCap IrMask Instr
---|--------------------|---------|------------|------------|------|------|------|---------
0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 |
0x01 | 0x0f | 0x3f
1 | omap3530.cpu | n | 0x00000000 | 0xffffffff | 0x04 |
0x01 | 0x00 | 0x0f
> jtag tapenable omap3530.cpu
Enabling Cortex-A8 @ OMAP3
Cortex-A8 @ OMAP3 enabled
1
> scan_chain
TapName | Enabled | IdCode Expected IrLen
IrCap IrMask Instr
---|--------------------|---------|------------|------------|------|------|------|---------
0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 |
0x01 | 0x0f | 0x3f
1 | omap3530.cpu | Y | 0x00000000 | 0xffffffff | 0x04 |
0x01 | 0x00 | 0x0f
-- cut --
Best regards
Dirk
Btw.: Any idea where the "1" at the third line from jtag tapenable
comand after "Cortex-A8 @ OMAP3 enabled" above comes from?
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
