We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Interesting, that does seem odd. From the context, I'm guessing execution was in Monitor mode and it moving to Hyp mode. If so, the LR and SP changing is expected - LR/r14 and SP/r13 are banked by processor mode. In Monitor mode you would be seeing/using LR_mon and in Hyp mode you'd be seeing LR_usr (see Figure B1-2 in the Armv7-A Architecture Reference Manual).
R8 through r12 changing value is odder. It would make more sense if the starting or destination mode was FIQ mode (which has private banked copies of of r8-r12). Have you checked what the actual starting and resulting modes are?
Also, how are you connecting to the target? Is this a model? Board with JTAG debug probe? Some kind of self-hosted monitor?
First, it should be noted that the connection method used was "a board with a JTAG debug probe" rather than a specific model. The scenario was as follows: when the bl2 component of TFA (Trusted Firmware-A), operating at the EL3 exception level, was running on the SoC (System-on-Chip), the execution of the instruction "cps #22" — which switches the processor mode to Monitor mode — caused the values of the registers from r8 to lr to change to 0xdeafbeef.
Additionally, is the value 0xdeadbeef considered normal? I believe that 0xdeadbeef is abnormal regardless of whether the processor is in SVC mode, HYP mode, or monitor mode on the ARMv7-A architecture.
Jempty.liang said:Additionally, is the value 0xdeadbeef considered normal?
That value is used by some tools/software to fill uninitialised memory/variables, as it's an easily recognisable pattern. That was why I asked if you were using a model, as many models have the option to set memory to some default pattern.
What I'm trying to figure out is what the start and end modes are - can you confirm those from the CPSR?
The easiest explanation for r8-r12 appearing to change on a mode switch is that you have changed to or changed from FIQ mode - as FIQ mode has it's own banked copy of those registers. Therefore if you switch into or out of FIQ mode, it'll appear as if r8-r12 changed value because you're now seeing different values. So I'm interested in what mode the processor was in when the CPS instruction get executed and what mode the processor is in after the CPS when you look at the regs in the debugger.