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.
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.