Problem with ARM926EJS

Hi,

I’m doing some development on a chip containing an ARM926EJS core, trying to use openocd for debugging. I’ve successfully built OpenOCD from svn r203, configured to use a Xilinx DLC7 (Xilinx Parallel Cable IV), which at least as far as OpenOCD is concerned seems identical to the DLC5 (Xilinx Parallel Cable III) which OpenOCD supports out of the box.

I’ve gotten the basic configuration to work (target set to arm926ejs, scan chain configured), and I seem to be able to do some basic operations (halt, resume, reg) when the CPU is running with the MMU off. However, the goal is to set up a debugging environment for a running Linux system, and when I try to halt the processor when Linux has started, I run into one (or both) of two failure modes. I’ve run openocd with the --debug flag to get some info on what’s going on.

  1. First of all, In most cases, the following output is given, and openocd terminates, when I give the ‘halt’ command to openocd:

Debug: arm926ejs.c:328 arm926ejs_examine_debug_reason(): internal debug request

Debug: arm7_9_common.c:1047 arm7_9_debug_entry(): target entered debug from ARM state

Debug: arm7_9_common.c:1073 arm7_9_debug_entry(): target cpsr is 0x2fa68, core mode 0x8

Error: armv4_5.c:187 armv4_5_mode_to_number(): invalid mode value encountered

Error: arm7_9_common.c:1077 arm7_9_debug_entry(): cpsr contains invalid mode value - communication failure

Error: target.c:1157 handle_target(): couldn’t poll target, exiting

(additional debug texts added by me to print out the values that causes opneocd to fail).

The actual cpsr value varies; sometimes it is 0.

  1. If the above doesn’t happen , then I get the symptom that (most often, though not always) when halting the CPU with Linux running, the PC is 0x00000000. When resuming, the processor seems to run from there, which is the boot up process, although it doesn’t seem to reboot the system, possibly due to incorrect hardware initialization at this point, and just ends up in an endless loop waiting for some hardware event to occur.

In any case, I see the following when I type resume:

Debug: arm926ejs.c:105 arm926ejs_catch_broken_irscan(): caught ARM926EJ-S invalid Capture-IR result after CP15 access

Sometimes (very seldom), openocd will hang when I gi ve the halt command.

The odd time I have been able to halt and resume a booting Linux system, at least a couple of times.

I read in a post here http://www.embeddedrelated.com/groups/l … /24076.php about a problem with the ARM926EJS when accessing the CP15 register, but that was a while ago (r141) and surely the patch must have made it into the svn repository by now; indeed the message from arm926ejs_catch_broken_irscan() above indicates that the workaround mentioned in the post has been implemented.

I’ve tried setting jtag_speed to 100 to slow things down, but it doesn’t seem to make a difference. (Mostly I’ve been using jtag_speed 10).

The fact that I only seem to have problems while Linux is running - I can successfully halt and resume prior to this point - leads me to believe it has something to do with the MMU.

Does anyone have any ideas? I can’t see that there is really anything else to configure that may be target implementation-specific, or ARM926EJS-specific but of course I could be very wrong.

I’ve got more debugging output if anyone’s interested.

/Ricard

Figured out the problem after a lot of headaches. Turned out the watchdog was enabled in the Linux kernel, so once the debugger stopped, the watchdog would bite soon afterwards. Disabling the watchdog cured the problem, and it now works like a charm.

Cheers!

/Ricard

ricard:
Figured out the problem after a lot of headaches. Turned out the watchdog was enabled in the Linux kernel, so once the debugger stopped, the watchdog would bite soon afterwards. Disabling the watchdog cured the problem, and it now works like a charm.

Cheers!

/Ricard

hello,

I have the same problem when I try of re-flashing:

> flash write_binary 0 c:\uboot\uboot.bin 0x0

failed writing file c:\uboot\uboot.bin to flash bank 0 at offset 0x00000000

can’t work with this flash while target is running

wrote 458884 byte from file c:\uboot\uboot.bin to flash bank 0 at offset 0x0000

0000 in 0s 15625us (28680.250000 kb/s)

you can give some indication to me in more? Mine cpu is one marvell feroceon 88f5181.

thanks