All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huan Wang <alison.wang@nxp.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel
Date: Fri, 2 Sep 2016 05:27:06 +0000	[thread overview]
Message-ID: <DB5PR04MB2152ED42CBD6B36B18C1F98CF4E50@DB5PR04MB2152.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <57C833A3.6070503@suse.de>

> On 08/29/2016 11:29 AM, Huan Wang wrote:
> >> On 18.07.16 05:24, Huan Wang wrote:
> >>> Hi, Alex,
> >>>
> >>>
> >>>
> >>>                As there is strong objection to remove the codes
> >>> about switching to EL1, I think we have to remain it, do you agree?
> >> I agree, yes.
> >>
> >>>                  If it is remained, I think your suggestion about
> >>> **always** jumping to ep for both switching to AArch64 and AArch32
> >>> modes will make the code hard to realize and very complicated. So I
> >>> prefer to  keep the process in v4 patches. What is your opinion?
> >> I think we should still convert it to a function call based approach.
> >> You can either just convert the current flow to functions:
> >>
> >> static void enter_in_el1(...)
> >> {
> >>      call_in_el1(payload_pc, payload_bits, ...); }
> >>
> >> #ifdef ENTER_PAYLOAD_IN_EL1
> >> call_in_el2(enter_in_el1, 64bit, ...); #else call_in_el2(payload_pc,
> >> payload_bits, ...); #endif
> >>
> >> Or you could add a check in the EL1 caller if you are in EL3 that you
> >> want to go to EL2 first:
> >>
> >> long call_in_el1(...)
> >> {
> >>    if (current_el() == 3)
> >>      return call_in_el2(call_in_el1, ...);
> >>
> >>    asm_call_in_el1(...);
> >> }
> >>
> >>
> > [Alison Wang] Yes, it can work for primary core and secondary cores
> for LayerScape.
> >
> > For other ARMv8 platforms, such as
> > arch/arm/mach-exynos/soc.c,
> > void lowlevel_init(void)
> > {
> >          armv8_switch_to_el2();
> >          armv8_switch_to_el1();
> > }
> > Is there any appropriate ep we can transfer for these functions?
> 
> First off, I'd be surprised if the sequence above even works at all, as
> you also need to set up your page tables for el2/el1 if you want to get
> into those.
> 
> IMHO the best path for this case is to remove the function :). But
> double-check with the Samsung folks first. I don't see why they can't
> use the generic one.
[Alison Wang] Yes, the best way is to remove the function. Let me ask them
if we can remove it.

> 
> > Even for the common arch/arm/cpu/armv8/start.S,
> > bl      armv8_switch_to_el2
> > #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> > bl      armv8_switch_to_el1
> > #endif
> > The ep is hard to define.
> 
> It's pretty simple. Just pass a pointer to the instruction after bl into
> the switch function:
> 
>          /*
>           * All slaves will enter EL2 and optionally EL1.
>           */
>          adr    x0, lowlevel_in_el2
>          bl      asm_call_in_el2
>          b        panic
> lowlevel_in_el2:
> 
> #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
>          adr    x0, lowlevel_in_el1
>          bl      asm_call_in_el1
>          b        panic
> lowlevel_in_el1:
> #endif
> 
> Because you already save the real lr in a non-volatile register, all
> this does is waste a few bytes of stack compared to the previous code.
[Alison Wang] Yes, thanks for your advice.


Best Regards,
Alison Wang

  reply	other threads:[~2016-09-02  5:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07  6:25 [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel Alison Wang
2016-07-07 11:39 ` Ryan Harkin
2016-07-07 11:44 ` Alexander Graf
2016-07-07 17:31   ` Michal Simek
2016-07-18  3:24     ` Huan Wang
2016-07-18  6:22       ` Alexander Graf
2016-08-29  9:29         ` Huan Wang
2016-09-01 13:56           ` Alexander Graf
2016-09-02  5:27             ` Huan Wang [this message]
2016-09-02  5:32             ` Huan Wang
2016-09-05  8:24             ` Huan Wang

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=DB5PR04MB2152ED42CBD6B36B18C1F98CF4E50@DB5PR04MB2152.eurprd04.prod.outlook.com \
    --to=alison.wang@nxp.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.