• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 347 subscribers
  • Views 7542 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

Cortex-A8 - accessing banked registers from monitor mode

Jitesh Shah
Note: This was originally posted on 20th March 2012 at http://forums.arm.com

Hi Group,
I am working on a Cortex A-8 Processor (ARMv7-a architecture). I am in the monitor mode and trying to access SP of the SVC mode.

I know two ways I can do it:

1) Using the "mrs" instruction.
eg. mrs r0, sp_svc

However, my compiler (code sourcery) says:
Error: Banked registers are not available with this architecture. -- `mrs r0,sp_svc'

My architecture manual does say that banked registers are accessible via this method, so I suppose this is a compiler issue. Anyway.

2) Changing the mode to svc, reading sp and getting back to the monitor mode.

eg. cps MODE_SVC
mov r0, sp
cps MODE_MON

where MODE_SVC = 0x13 and MODE_MON = 0x16

But, as soon as I execute "cps MODE_SVC" in monitor mode, my CPU hangs. There is no more activity.

So my question is this: Is SVC mode not accessible from Monitor mode? If thats not the case, how can I access SVC version of the registers from Monitor mode?

Thanks,
Jitesh
Parents
  • 0
    Note: This was originally posted on 21st March 2012 at http://forums.arm.com


    Have you initialized the SVC mode, and is the NS-bit configured as secure before you call cps?


    Yes. The SVC mode is initialised. Since this supposed crash happens when I am coming FROM the normal mode, the NS-bit is set to non-secure. But is that a problem? I suppose that monitor mode is always secure irrespective of the NS-bit.




    My best guess is that you've got the NS-bit set to 1 (i.e. non-secure) and you switch modes, which drops the core in to non-secure SVC mode, because the NS-bit takes effect as soon as you drop out of monitor mode. It is quite possible that the PC you are using doesn't exist in the non-secure world, so it faults, but  the non-secure exception table is also not set up, so that faults. Infinite loop of faults = hung CPU.


    Actually I am coming from the normal world so I drop out of monitor mode with NS-bit set to secure.
    So right now, the situation is like this:
    I initialize the NS-mode registers and switch to the NS-mode. NS-mode executes a few instructions (exception table NOT set, stack for NS SVC mode IS set, MMU off) and then executes an SMC call to switch back to the secure state. Thus, when I reach the SMC exception handler, the NS-bit is set to Non-secure. This is the situation in which I execute "cps MODE_SVC". Intention is to get the NS SVC mode SP and save it (so that it can be restored later). After getting the SP, I switch to monitor mode. So, the sequence of instructions inside the SMC handler is:
    cps MODE_SVC; mov r0, sp; cps MODE_MON
    Then, I flip the NS-bit so that it is now set to secure.

    Is there a problem with this methodology? Is it expected to work as intended?

    Thanks for the reply!
    Jitesh


Reply
  • 0
    Note: This was originally posted on 21st March 2012 at http://forums.arm.com


    Have you initialized the SVC mode, and is the NS-bit configured as secure before you call cps?


    Yes. The SVC mode is initialised. Since this supposed crash happens when I am coming FROM the normal mode, the NS-bit is set to non-secure. But is that a problem? I suppose that monitor mode is always secure irrespective of the NS-bit.




    My best guess is that you've got the NS-bit set to 1 (i.e. non-secure) and you switch modes, which drops the core in to non-secure SVC mode, because the NS-bit takes effect as soon as you drop out of monitor mode. It is quite possible that the PC you are using doesn't exist in the non-secure world, so it faults, but  the non-secure exception table is also not set up, so that faults. Infinite loop of faults = hung CPU.


    Actually I am coming from the normal world so I drop out of monitor mode with NS-bit set to secure.
    So right now, the situation is like this:
    I initialize the NS-mode registers and switch to the NS-mode. NS-mode executes a few instructions (exception table NOT set, stack for NS SVC mode IS set, MMU off) and then executes an SMC call to switch back to the secure state. Thus, when I reach the SMC exception handler, the NS-bit is set to Non-secure. This is the situation in which I execute "cps MODE_SVC". Intention is to get the NS SVC mode SP and save it (so that it can be restored later). After getting the SP, I switch to monitor mode. So, the sequence of instructions inside the SMC handler is:
    cps MODE_SVC; mov r0, sp; cps MODE_MON
    Then, I flip the NS-bit so that it is now set to secure.

    Is there a problem with this methodology? Is it expected to work as intended?

    Thanks for the reply!
    Jitesh


Children
No data