Through many toils and snares, we have determined that when this lockup
occurs, the actual hang is occurring on the line:

while (XSysAce_Lock(AcePtr, XFALSE) != XST_SUCCESS);

in the xsysaceblkadapter.c file in the function:
"XSysAceBlkAdapter_Init(Xuint16 DeviceId, unsigned MaxPartitions)."

It seems that disconnecting our Ethernet cable during the boot-up, makes the
problem disappear--- and I have no earthly idea how Ethernet
traffic/interrupts can affect sysACE controller. I'm guessing a timing/FPGA
build issue, but have no clue where to start on finding/isolating/fixing the
issue--if indeed it is in the FPGA place/route/timing arena.

The comments in the xsys driver code, are puzzling to me. In particular, it
says

"This function blocks waiting on a lock from the System ACE controller. If
a JTAG configuration is in process, this function will block until the
configuration process is done."

and in the comments for the XSysAce_Lock() function:

"If the user requests a forced lock, the JTAG configuration controller will
be put into a reset state in case it currently has a lock on the
CompactFlash.
This effectively aborts any operation the configuration controller had in
progress and makes the configuration controller restart its process the
next time it is able to get a lock.

A lock must be granted to the user before attempting to read or write the
CompactFlash device.

Force is a boolean value that, when set to XTRUE, will force the MPU
lock to occur in the System ACE. When set to XFALSE, the lock is
requested and the device arbitrates between the MPU request and
JTAG requests. Forcing the MPU lock resets the configuration
controller, thus aborting any configuration operations in progress.

return XST_SUCCESS if the lock was granted, or XST_DEVICE_BUSY if the lock
was
not granted because the configuration controller currently has access to the
CompactFlash.

If the lock is not granted to the MPU immediately, this function removes its
request for a lock so that a lock is not later granted at a time when the
application is (a) not ready for the lock, or (b) cannot be informed
asynchronously about the granted lock since there is no such interrupt
event."

Now this leads me to the following questions:

1) why isn't the initialize function forcing a lock? Would something bad
happen if it did?

2) I don't understand what will happen in the lock routine if force is true
when it 'releases the reset'. Does this mean it'll try to re-configure the
FPGA?

3) Should I put a timer/timeout around the while statement and if it times
out, call it again with Force=TRUE?

Has anyone else encountered problems like this? I admit is very peculiar and
troubling that adding an Ethernet core is impacting the sysACE at all.