public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] Question re HYP mode and IRQ/FIQ stack setting
Date: Tue, 12 Nov 2013 17:53:06 +0100	[thread overview]
Message-ID: <52825CF2.3050506@linaro.org> (raw)
In-Reply-To: <CAMJs5B-BGAe4HAZ5E_+7p-h6XFxT3_VdC+RNPEAYtFe+ot8CRg@mail.gmail.com>

On 11/12/2013 05:28 PM, Christoffer Dall wrote:
> On 12 November 2013 03:41, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
>> (Cc:ing Andre and Christoffer as they have discussed HYP on the ML.)
>>
>> Hello,
>>
>> I am working on changing the way IRQ/FIQ stacks are set up, from
>> "on-the-fly in a hurry while in the handler" to "during init, so that
>> when entering the handler, the stack is already correct".
>>
>> Setting the stack then requires switching from the current mode (in
>> most cases, SVC32, 0x13) to IRQ (0x11) or FIQ (0x12) mode, in order to
>> set the right banked SP, then back into the original mode.
>>
>> However, in the first lines of reset in arch/arm/cpu/armv7/start.S, the
>> possibility of U-Boot being started in HYP mode (0x1A) is considered
>> and, if in HYP mode, no switch to SVC32 is performed.
>>
>> I understand that the problem here is, if we drop from HYP to SVC32,
>> then we cannot go back to HYP, and we want to be able to remain in HYP.

Right, that is to keep the HYP mode in case the firmware already enabled 
it. This is for instance the case on the new Calxeda Midway. Actually 
this approach will become more widespread, since it is required to 
provide proper PSCI support (which needs to run in secure state, so 
requires an even higher privilege level than HYP: EL3 in the new ARM speak).

> correct (not without setting up a trap handler in Hyp mode and
> trapping to Hyp mode)
>
>>
>> Does this also apply to dropping from HYP to IRQ or FIQ mode, i.e., if
>> we do such a drop, are we prevented from rising back from IRQ or FIQ
>> mode to HYP? I seem to remember such an issue, but I am no specialist
>> in HYP, so any help is welcome.
>
> Yes, it also applies.  Hyp is strictly more privileged (PL2) than all
> the PL1 modes (SVC, SYS, IRQ, FIQ, ABT, UND) and therefore requires a
> trap to go from PL1 to PL2 (basically this is how hardware protection
> works - just like with syscalls from user mode to PL1).

Thanks Christoffer for clarifying this, I wasn't sure about FIQ, but of 
course your explanation (EL1 vs. EL2) makes totally sense.

But I wonder what happens when we enter FIQ or IRQ due to an actual 
interrupt. Will the CPU return into HYP mode when the handler returns?
That is subject to some HYP mode register configuration, right?

> You can use MSR and MRS instructions to access the IRQ and FIQ
> registers directly from Hyp mode though.

Albert,
so does "msr sp_{fiq,irq}, r<n>" fix your problem? Or do you still need 
to actually go into one of these modes for further setup?

Regards,
Andre.

  reply	other threads:[~2013-11-12 16:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12 11:41 [U-Boot] Question re HYP mode and IRQ/FIQ stack setting Albert ARIBAUD
2013-11-12 16:28 ` Christoffer Dall
2013-11-12 16:53   ` Andre Przywara [this message]
2013-11-12 17:09     ` Christoffer Dall
2013-11-12 21:29       ` Albert ARIBAUD
2013-11-12 22:34         ` Christoffer Dall
2013-11-13  6:22           ` Albert ARIBAUD
2013-11-13 15:16             ` Christoffer Dall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52825CF2.3050506@linaro.org \
    --to=andre.przywara@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox