I initially posted about an issue with connecting to the OMAP processor via JTAG. After doing some hunting, I discovered the issue was actually the result of a bug in the omap3evm.c file (and probably others as well).
If you look at the prcm_init function, one of the first things this function does is call get_osc_clk_speed. This function returns what it believes is the correct frequency for the clock, with are 38.4MHz, 26MHz, 24MHz, 19.2MHz, 13MHz, or 12MHz. We are running a 26MHz clock, but it's being reported at 24MHz. That in and of itself isn't really an issue. However, the return value of this function is sent as a parameter to get_sys_clkin_sel, along with an pointer called sys_clkin_sel. sys_clkin_sel is not initialized, probably because it's assumed that it will be set in the call to get_sys_clkin_sel. However, if you look at the function get_sys_clkin_sel, it has cases for every frequency except 24MHz, which is what our was coming out to. Because of that, and the fact that sys_clkin_sel has not initialized prior to the function call, the value of sys_clkin_sel can, and is, anything. In our case it was something around 1 million. That value is then used to determine clk_index, which is used to set several clock setting for the system. Because these values are jacked, timings are off and devices just don't talk. Eventually an illegal address is referenced and the OMAP goes into a dead loop.
I'd suggest that you change sys_clkin_sel to have an inital value, and that you also change the function get_sys_clkin_sel to handle the case of a 24MHz clock, or else take out the possibility of a 24MHz clock in the get_osc_clk_speed function. We went in and simply hard coded the values after the function calls, thereby providing us with valid values and allowing the OMAP to initialize. After than, everything runs fine. We can connect via JTAG, we can run the u-boot file and uImage files with no problems.
Anyway, hope that all made sense and hopefully this can help anyone else that might be having the same issue.