On 09/17/2010 03:08 PM, David Brownell wrote:
Presently, I would like to hear about the perceived status> of Cortex-A8,
It gets through OMAP3 bringup. The ROM table
scanning embeds various assumptions; see the
comments in the ARM ADI_V5.c file. I'm not sure
whether it's good to assume DAP 0 is used, as one
of the examples, of which MEM-AP to use. The MX51
is a bit different than OMAP. I don't know
about other chips using A8 cores... or, A9.
as one of my initial goals will be to "validate" that
support. If you
are using OpenOCD on a Cortex-A8 platform, what problems do
you face?
What features still need work? And contributors of this
support: are
there any horrible blemishes remaining in this code?
I've tried to leave comments in the code re any
open issues I observed. Historically, the A8 code
evolved from the M3 code, at least for the ROM table
scanning (not debug).
The v7a (Cortex-A) debug support is ISTR not all
there, but it's not too bad. ARM did good things
by having v6 and v7a use the same model (DPM), so
what OpenOCD needs to do is jut fill in various
missing bits. Again, read code comments.
Also, cross-check against the ARM-v7AR TRM.
________________________________________
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
Hi Zach and David,
I have been using OpenOCD for some basic debug work on the Beagleboard
xM which is a TI DM37x (similar to the OMAP3). I can run simple
programs and single step them inside OpenOCD and GDB. I have not tried
significant debugging with an application that uses the MMU yet.
There are some minor issues I have seen that do not appear to effect my
ability to debug, but are odd. For example when I initially connect to
the target I get a bunch of errors similar to the following:
$ ./openocd -f interface/flyswatter.cfg -f board/ti_beagleboard_xm.cfg
Open On-Chip Debugger 0.5.0-dev-00500-g35af12d (2010-09-06-14:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
10 kHz
Warn : dm37x.dsp: huge IR length 38
trst_only separate trst_push_pull
Info : device: 4 "2232C"
Info : deviceID: 67330064
Info : SerialNumber: FS000000 A
Info : Description: Flyswatter A
Info : clock speed 10 kHz
Info : JTAG tap: dm37x.jrc tap/device found: 0x0b89102f (mfg: 0x017,
part: 0xb891, ver: 0x0)
Info : JTAG tap: dm37x.dap enabled
Info : dm37x.cpu: hardware has 6 breakpoints, 2 watchpoints
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0
To test some basic debug operations inside OpenOCD with the MMU I let
the Linux demonstration load up. It appears that virtual to physical
memory translation works. If I single step it gives a message that
there was a timeout waiting for halt:
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> amdm37x_dbginit dm37x.cpu
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000093 pc: 0xc003cf8c
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> virt2phys 0xc003cf8c
Physical address 0x8003cf8c
> step
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x60000093 pc: 0xc003cf90
MMU: enabled, D-Cache: enabled, I-Cache: enabled
timeout waiting for target halt
Command handler execution failed
in procedure 'step'
As I mentioned earlier though if I run simple software designs that do
not use the MMU I can set breakpoints inside GDB, run to them and
examine variables along with memory just fine. I have not noticed any
oddities single stepping in those applications.
-Karl
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
