We are trying to boot linux via u-boot on a Xilinx VCU118 board. There is an ARM A55 processor implemented in the FPGA. We have a ULINKpro D connected to the VCU118 board which allows us to debug our software. We have u-boot loading the linux binary over Ethernet and storing it in DRAM along with an fdt and a RAM disc filesystem. The linux boot process proceeds and gets to various points where the IDE freezes up. Most often the IDE says the processor is "running" but we cannot interrupt it; sometimes we can interrupt it, but it won't show us many of the system registers and all of virtual memory is claimed to be invalid (the MMU tab says the ttbr0 and ttbdr1 both are pointing to error. We have some visibility to internal FPGA signals and Vivado can show signal and bus activity. If we trigger the waveform capture just right, we can see the busses stop changing values even though the IDE says the processor is running. We have tried setting breakpoints on each interrupt/exception vector point and we do not see any exceptions or interrupts happening. This is base Debian linux boot code, so we are not expecting anything weird to be going on. We have inserted print statements to show how far we have made it along the set of function calls in the start_kernel routine; we typically see that we get through 27 to 30 of them before the IDE freezes up. We are having trouble identifying how we can get this freeze-up condition at different points in the process just running it several times in a row and we do not seem to be at a point in the boot process where interrupts are enabled (and we don't seem to get them). When we are single-stepping, all the linux boot code seems to be in the upper memory 0xFFFFFFC008xxxxxx and the page tables all look good. When we are able to stop the processor, all memory is not accessible along with most of the system registers. U-boot is running at el2 and invokes linux at el1.
When I interrupt the running processor and it does stop, here is a sample of what I find:
All of the TTBR0 and TTBR1 registers for all 3 EL levels show as unavailable in the IDE Registers list. That could easily explain why memory appears to be unaccessible. What makes system registers such as these show up as unavailable? This happened while stepping over one of the many calls to _printk; there is no way to find out where it was when it froze up since all of [virtual] memory is invalid without the TTBR0_EL1 and TTBR1_EL1 registers.
In another case, I continue to a breakpoint and it shows me the disassembly. I try to step the next instruction (ADRP) and the IDE says "stepping failed". Suddenly it cannot show me the next instruction and all the TTBR registers are unavailable for display. What can possibly happen trying to single step a single ADRP instruction to cause this behavior?