memset hangs part way through; called from early_init

Hi All,
I'm running a V2Pro-based development board, and I'm working on a linux 2.6.15 port.
Currently, the board hangs in the early_init function. Specifically, at the following line:
memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);

This memset_io() call eventually calls memset() (from arch/ppc/lib/string.S) to zero the
region of memory. Using a BDI2000, I'm able to step through the assembly and see that
within memset, it enters a two-instruction loop where it is writing zeros to consecutive
memory locations. Everything is going fine, but after 10 or 20 iterations of the loop
(it's not consistent), everything blows up.

GDB reports the following:
------------------------------
(gdb) stepi

Program received signal SIG110, Real-time event 110.
0xc000b3e8 in memset ()
(gdb)
------------------------------

The BDI2000 reports the following:
------------------------------
*** MMU: address translation for 0xC000B3E8 failed
*** MMU: address translation for 0xC000B3E4 failed
*** MMU: address translation for 0xC000B3E8 failed
*** MMU: address translation for 0xC000B3E4 failed
*** MMU: address translation for 0xC000B3B0 failed
*** MMU: address translation for 0xDEADBEEF failed
*** MMU: address translation for 0xDEADBEEB failed
*** MMU: address translation for 0xDEADBEEF failed
*** MMU: address translation for 0xDEADBEEB failed
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xDEADBEEF failed
*** MMU: address translation for 0xDEADBEEB failed
*** MMU: address translation for 0xDEADBEEF failed
*** MMU: address translation for 0xDEADBEEB failed
*** MMU: address translation for 0x00000000 failed
------------------------------

Here is my BDI2000 configuration file:
------------------------------
[INIT]



[TARGET]

JTAGCLOCK   0                   ;use 16 MHz JTAG clock

CPUTYPE     405 		;the used target CPU type

BDIMODE     AGENT   	        ;the BDI working mode (LOADONLY | AGENT)


BREAKMODE   HARD      	        ;SOFT or HARD, HARD uses PPC hardware breakpoint

STEPMODE    HWBP                ;JTAG or HWBP, HWPB uses one or two hardware breakpoints


MMU         XLAT 0xC0000000     ;enable virtual address mode

PTBASE      0x000000f0          ;address where kernel/user stores pointer to page table

STARTUP     RESET




[HOST]

IP          192.9.200.213


FILE        ppcboot.bin

FORMAT      BIN 0xfff80000 ;0x200000

START       0xfff80000 ; 0x200000

LOAD        MANUAL              ;load code MANUAL or AUTO after reset

DEBUGPORT   2001

DUMP        dump.bin            ;Linux: dump.bin must already exist and public writable



[FLASH]

WORKSPACE   0xffffd000

CHIPTYPE    STRATAX16

BUSWIDTH    16

CHIPSIZE    0x400000


[REGS]

IDCR1	0x010	0x011	;MEMCFGADR and MEMCFGDATA

IDCR2	0x012	0x013	;EBCCFGADR and EBCCFGDATA

IDCR3	0x014	0x015	;KIAR and KIDR

FILE    reg405gp.def
------------------------------

Any ideas would be appreciated.

Regards,
Chris Dumoulin

    I have encountered one of the rare instances where I need/want more
debugging resources than an LED on an IO port.

    I am looking for some recommendations as well as understanding of
the lighter weight debugging tools that are available.
    I am dealing with a Xilinx V4 PPC405  FPGA. It is hosted in a
computer running Windows XP. Aparently there is a JTAG port
    on the device that emulates a JTAG parallel port on LPT3 on the host
side.

    I was hoping to be able to bring up gdb, download an elf file to the
target and step through a program to see where it is going off the rails.

    A bit of research suggests that there are gdbservers that bridge
between gdb and JTAG. But all the links I have found to rproxy seem to
be broken, and those for gdbproxy seem to be
    for other processors.