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


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

    Thanks @ttfn and @isogen
    After you guys pointed it out, it looks blatantly obvious! Going out of monitor mode via CPS would obviously bring the NS-bit back into picture.

    So anyway, I set the NS-bit to secure before doing the CPS now and everything works fine!

    Thanks for the help. I owe you guys a beer!
  • 0
    Note: This was originally posted on 20th 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?

    If you are in monitor mode when you do the "cps MODE_SVC" are you are effectively switching into SVC mode, using it's banked registers, so if you haven't initialized them you are probably going to have problems.

    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.

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

    Also worth noting ..

    [color=#222222][size=2]Intention is to get the NS SVC mode SP
    [/size][/color]
    [color=#222222][size=2]
    [/size][/color]
    [size=2]There is no such thing as a "non-secure" SVC mode. The same physical registers are used for both secure and non-secure, so the SP value is the same irrespective of what the NS bit is, unless the monitor mode decides to modify it. So you can clear the NS bit, iterate save and restore all of the modes, and then drop into the secure world.[/size]
    [size=2]
    [/size]
  • 0
    Note: This was originally posted on 21st March 2012 at http://forums.arm.com

    Basically, yes.  :-P

    As you guessed, Monitor mode is always in the Secure world.  Regardless of the value of the SCR.NS bit. 

    On entry to Monitor mode SCR.NS will reflect where you've just come from.  In your example SCR,NS=1, as you've come from the Normal world.  As Isogen said, the SCR.NS bit takes effect again immediately after you exit Monitor mode.  So when you do "CPS #Mode_Mon" you are dropping out of the Secure world into the Normal world.  Which means you;d have to trigger another exception to get back.

    Simple solution - clear the SCR.NS bit before you execute the CPS instruction.  You will need some code to check and remember what its state was as well.  I think there is an example from ARM which does this.
  • 0

    peterharris: Hi Peter,

    When we are trying to change the mode from Secure_Supervisor to NON_Secure_Supervisor, we go to Secure_monitor by invoking "SMC #0".

    As part of the Secure_monitor handler when we try to write SCR register by executing "mcr  p15, 0, r1, c1, c1, 0"instruction,  core gets hard reset. The same code is working perfectly fine in FAST model. Find the below Secure_monitor handler implementation

    Inline image 1

    Please let us know if there are any extra settings/configuration required, to work this out in hardware.

    Let us know if you need any more information regarding this issue.

    Thanks

    Nisar