• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 121 subscribers
  • Views 1232 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What does it mean when a system register like TTBR0_EL1 becomes unavailable?

Brion

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?

Parents
  • +1

    Hi Brion

    My 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-a55

    TTBR0_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-0

    If 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 helps

    Stephen

Reply
  • +1

    Hi Brion

    My 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-a55

    TTBR0_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-0

    If 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 helps

    Stephen

Children