In debug of our Linux boot, we often find that after we single step a simple instruction such as ADD x0, x0, #0x18, we can't view any memory and the IDE suddenly shows all of the TTBRxELn registers are unavailable. What exactly does it mean for these registers to become unavailable? Given that the MMU is active, we cannot view any memory, including the location of the ADD instruction up at 0xFFFFFFC0084411D0 (approximately). Any idea what could be going on that some, but not all, system registers go away like this?
Hi BrionMy name is Stephen and I work at Arm.I assume this is a continuation of your previous question in community.arm.com/.../ide-freezing-up-trying-to-boot-linux-on-an-a55TTBR0_EL1 should always be available in AArch64, so if it is showing as "unavailable" then the Debugger has lost control of the target. This is usually due to something irrecoverable happening on the target.You said "we can see the busses stop changing values" which means the processor has probably locked-up. It's hard to tell whether the lock-up was caused by some hardware fault within the A55 in the FPGA (e.g. bus protocol conflicts), or whether the lock-up was triggered by the Debugger doing something unexpected (e.g. reading from some memory that triggered a bus error).You might be able to tell from a debug ("DAP") log where/why the debugger loses control. To generate a DAP log, see developer.arm.com/.../1-0If you need help to generate or understand the debug log, please pass it back to us. It is best to do this via a support case (see the support menu above), rather than in this public forum. Please include a link to this thread.Hope this helpsStephen
Hi Stephen, I did open a case this morning and we can pursue it there. Knowing the processor likely locked up independently of the IDE is good to know.