| Message ID | 20210819155314.1787973-6-peter.hoyes@arm.com |
|---|---|
| State | Accepted |
| Commit | 30e5a449e8c7739965757879bb17efbd3a8f0ee2 |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | Armv8r64 + BASER_FVP board support | expand |
On 8/19/21 4:53 PM, Peter Hoyes wrote: Hi, > From: Peter Hoyes <Peter.Hoyes@arm.com> > > Use the environment variable armv8_switch_to_el1 to determine whether > to switch to EL1 at runtime. This is an alternative to the > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. This might be useful outside of the v8-R64 FVP. I cannot find CONFIG_ARMV8_SWITCH_TO_EL1 being set anywhere, which makes me wonder how this is used? Are there certain custom builds which define this somehow? In any case forcing "kernel" entry in either EL1 or EL2, and deciding this at runtime sounds useful for certain scenarios in general, and be it for debugging and testing. So shall we get rid of this compile time option at all, or shall this be retained to avoid extra code? > The environment variable will be ineffective if the ARMV8_MULTIENTRY > config is used. > > This is required by the Armv8r64 architecture, which must be able to > boot at S-EL1 for Linux but may need to boot at other ELs for other > systems. > > Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> > --- > arch/arm/lib/bootm.c | 40 +++++++++++++++++++++++++--------------- > 1 file changed, 25 insertions(+), 15 deletions(-) > > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c > index f60ee3a7e6..ea9bfe7570 100644 > --- a/arch/arm/lib/bootm.c > +++ b/arch/arm/lib/bootm.c > @@ -317,7 +317,6 @@ __weak void update_os_arch_secondary_cores(uint8_t os_arch) > { > } > > -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > static void switch_to_el1(void) > { > if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && > @@ -332,7 +331,6 @@ static void switch_to_el1(void) > ES_TO_AARCH64); > } > #endif > -#endif > > /* Subcommand: GO */ > static void boot_jump_linux(bootm_headers_t *images, int flag) > @@ -359,21 +357,33 @@ static void boot_jump_linux(bootm_headers_t *images, int flag) > > update_os_arch_secondary_cores(images->os.arch); > > -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, > - (u64)switch_to_el1, ES_TO_AARCH64); > +#ifdef CONFIG_ARMV8_MULTIENTRY > + int armv8_switch_to_el1 = -1; > #else > - if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && > - (images->os.arch == IH_ARCH_ARM)) > - armv8_switch_to_el2(0, (u64)gd->bd->bi_arch_number, > - (u64)images->ft_addr, 0, > - (u64)images->ep, > - ES_TO_AARCH32); > - else > - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, > - images->ep, > - ES_TO_AARCH64); > + int armv8_switch_to_el1 = env_get_yesno("armv8_switch_to_el1"); > #endif > +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > + if (armv8_switch_to_el1 == -1) { > + armv8_switch_to_el1 = 1; > + } > +#endif > + if (armv8_switch_to_el1 == 1) { This looks confusing. Can't we use CONFIG_IS_ENABLED() and override armv8_switch_to_el1, then use this one variable to trigger the action? Cheers, Andre > + armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, > + (u64)switch_to_el1, ES_TO_AARCH64); > + } else { > + if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && > + (images->os.arch == IH_ARCH_ARM)) > + armv8_switch_to_el2(0, > + (u64)gd->bd->bi_arch_number, > + (u64)images->ft_addr, 0, > + (u64)images->ep, > + ES_TO_AARCH32); > + else > + armv8_switch_to_el2((u64)images->ft_addr, > + 0, 0, 0, > + images->ep, > + ES_TO_AARCH64); > + } > } > #else > unsigned long machid = gd->bd->bi_arch_number; >
On Fri, Aug 20, 2021 at 05:57:51PM +0100, Andre Przywara wrote: > On 8/19/21 4:53 PM, Peter Hoyes wrote: > > Hi, > > > From: Peter Hoyes <Peter.Hoyes@arm.com> > > > > Use the environment variable armv8_switch_to_el1 to determine whether > > to switch to EL1 at runtime. This is an alternative to the > > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. > > This might be useful outside of the v8-R64 FVP. I cannot find > CONFIG_ARMV8_SWITCH_TO_EL1 being set anywhere, which makes me wonder how > this is used? Are there certain custom builds which define this somehow? Adding Michal and asking for a Kconfig migration too :) > > In any case forcing "kernel" entry in either EL1 or EL2, and deciding this > at runtime sounds useful for certain scenarios in general, and be it for > debugging and testing. So shall we get rid of this compile time option at > all, or shall this be retained to avoid extra code? > > > The environment variable will be ineffective if the ARMV8_MULTIENTRY > > config is used. > > > > This is required by the Armv8r64 architecture, which must be able to > > boot at S-EL1 for Linux but may need to boot at other ELs for other > > systems. > > > > Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> > > --- > > arch/arm/lib/bootm.c | 40 +++++++++++++++++++++++++--------------- > > 1 file changed, 25 insertions(+), 15 deletions(-) > > > > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c > > index f60ee3a7e6..ea9bfe7570 100644 > > --- a/arch/arm/lib/bootm.c > > +++ b/arch/arm/lib/bootm.c > > @@ -317,7 +317,6 @@ __weak void update_os_arch_secondary_cores(uint8_t os_arch) > > { > > } > > -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > > static void switch_to_el1(void) > > { > > if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && > > @@ -332,7 +331,6 @@ static void switch_to_el1(void) > > ES_TO_AARCH64); > > } > > #endif > > -#endif > > /* Subcommand: GO */ > > static void boot_jump_linux(bootm_headers_t *images, int flag) > > @@ -359,21 +357,33 @@ static void boot_jump_linux(bootm_headers_t *images, int flag) > > update_os_arch_secondary_cores(images->os.arch); > > -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > > - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, > > - (u64)switch_to_el1, ES_TO_AARCH64); > > +#ifdef CONFIG_ARMV8_MULTIENTRY > > + int armv8_switch_to_el1 = -1; > > #else > > - if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && > > - (images->os.arch == IH_ARCH_ARM)) > > - armv8_switch_to_el2(0, (u64)gd->bd->bi_arch_number, > > - (u64)images->ft_addr, 0, > > - (u64)images->ep, > > - ES_TO_AARCH32); > > - else > > - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, > > - images->ep, > > - ES_TO_AARCH64); > > + int armv8_switch_to_el1 = env_get_yesno("armv8_switch_to_el1"); > > #endif > > +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > > + if (armv8_switch_to_el1 == -1) { > > + armv8_switch_to_el1 = 1; > > + } > > +#endif > > + if (armv8_switch_to_el1 == 1) { > > This looks confusing. Can't we use CONFIG_IS_ENABLED() and override > armv8_switch_to_el1, then use this one variable to trigger the action? > > Cheers, > Andre > > > + armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, > > + (u64)switch_to_el1, ES_TO_AARCH64); > > + } else { > > + if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && > > + (images->os.arch == IH_ARCH_ARM)) > > + armv8_switch_to_el2(0, > > + (u64)gd->bd->bi_arch_number, > > + (u64)images->ft_addr, 0, > > + (u64)images->ep, > > + ES_TO_AARCH32); > > + else > > + armv8_switch_to_el2((u64)images->ft_addr, > > + 0, 0, 0, > > + images->ep, > > + ES_TO_AARCH64); > > + } > > } > > #else > > unsigned long machid = gd->bd->bi_arch_number; > > >
On 8/20/21 6:05 PM, Tom Rini wrote: > On Fri, Aug 20, 2021 at 05:57:51PM +0100, Andre Przywara wrote: >> On 8/19/21 4:53 PM, Peter Hoyes wrote: Hi, >>> From: Peter Hoyes <Peter.Hoyes@arm.com> >>> >>> Use the environment variable armv8_switch_to_el1 to determine whether >>> to switch to EL1 at runtime. This is an alternative to the >>> CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. >> >> This might be useful outside of the v8-R64 FVP. I cannot find >> CONFIG_ARMV8_SWITCH_TO_EL1 being set anywhere, which makes me wonder how >> this is used? Are there certain custom builds which define this somehow? > > Adding Michal ... Michal, I see that Xilinx Versal and ZynqMP have a commented "define CONFIG_ARMV8_SWITCH_TO_EL1" in their include headers. Can you say what is the use case here? From an architectural point of view it sounds useful to have this feature in general and the dynamic switch-ability on top of that for all ARM64 platforms, but I would first like to understand how this is used with those Xilink platforms. > asking for a Kconfig migration too :) That sounds reasonable. I will have a stab once we agree how to address this feature in general. Cheers, Andre > >> >> In any case forcing "kernel" entry in either EL1 or EL2, and deciding this >> at runtime sounds useful for certain scenarios in general, and be it for >> debugging and testing. So shall we get rid of this compile time option at >> all, or shall this be retained to avoid extra code? >> >>> The environment variable will be ineffective if the ARMV8_MULTIENTRY >>> config is used. >>> >>> This is required by the Armv8r64 architecture, which must be able to >>> boot at S-EL1 for Linux but may need to boot at other ELs for other >>> systems. >>> >>> Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> >>> --- >>> arch/arm/lib/bootm.c | 40 +++++++++++++++++++++++++--------------- >>> 1 file changed, 25 insertions(+), 15 deletions(-) >>> >>> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c >>> index f60ee3a7e6..ea9bfe7570 100644 >>> --- a/arch/arm/lib/bootm.c >>> +++ b/arch/arm/lib/bootm.c >>> @@ -317,7 +317,6 @@ __weak void update_os_arch_secondary_cores(uint8_t os_arch) >>> { >>> } >>> -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 >>> static void switch_to_el1(void) >>> { >>> if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && >>> @@ -332,7 +331,6 @@ static void switch_to_el1(void) >>> ES_TO_AARCH64); >>> } >>> #endif >>> -#endif >>> /* Subcommand: GO */ >>> static void boot_jump_linux(bootm_headers_t *images, int flag) >>> @@ -359,21 +357,33 @@ static void boot_jump_linux(bootm_headers_t *images, int flag) >>> update_os_arch_secondary_cores(images->os.arch); >>> -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 >>> - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, >>> - (u64)switch_to_el1, ES_TO_AARCH64); >>> +#ifdef CONFIG_ARMV8_MULTIENTRY >>> + int armv8_switch_to_el1 = -1; >>> #else >>> - if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && >>> - (images->os.arch == IH_ARCH_ARM)) >>> - armv8_switch_to_el2(0, (u64)gd->bd->bi_arch_number, >>> - (u64)images->ft_addr, 0, >>> - (u64)images->ep, >>> - ES_TO_AARCH32); >>> - else >>> - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, >>> - images->ep, >>> - ES_TO_AARCH64); >>> + int armv8_switch_to_el1 = env_get_yesno("armv8_switch_to_el1"); >>> #endif >>> +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 >>> + if (armv8_switch_to_el1 == -1) { >>> + armv8_switch_to_el1 = 1; >>> + } >>> +#endif >>> + if (armv8_switch_to_el1 == 1) { >> >> This looks confusing. Can't we use CONFIG_IS_ENABLED() and override >> armv8_switch_to_el1, then use this one variable to trigger the action? >> >> Cheers, >> Andre >> >>> + armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, >>> + (u64)switch_to_el1, ES_TO_AARCH64); >>> + } else { >>> + if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && >>> + (images->os.arch == IH_ARCH_ARM)) >>> + armv8_switch_to_el2(0, >>> + (u64)gd->bd->bi_arch_number, >>> + (u64)images->ft_addr, 0, >>> + (u64)images->ep, >>> + ES_TO_AARCH32); >>> + else >>> + armv8_switch_to_el2((u64)images->ft_addr, >>> + 0, 0, 0, >>> + images->ep, >>> + ES_TO_AARCH64); >>> + } >>> } >>> #else >>> unsigned long machid = gd->bd->bi_arch_number; >>> >> >
On Thu, Aug 19, 2021 at 04:53:13PM +0100, Peter Hoyes wrote: > From: Peter Hoyes <Peter.Hoyes@arm.com> > > Use the environment variable armv8_switch_to_el1 to determine whether > to switch to EL1 at runtime. This is an alternative to the > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. > > The environment variable will be ineffective if the ARMV8_MULTIENTRY > config is used. > > This is required by the Armv8r64 architecture, which must be able to > boot at S-EL1 for Linux but may need to boot at other ELs for other > systems. > > Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> Applied to u-boot/next, thanks!
On Thu, 2 Sep 2021 18:42:05 -0400 Tom Rini <trini@konsulko.com> wrote: Hi Tom, > On Thu, Aug 19, 2021 at 04:53:13PM +0100, Peter Hoyes wrote: > > > From: Peter Hoyes <Peter.Hoyes@arm.com> > > > > Use the environment variable armv8_switch_to_el1 to determine whether > > to switch to EL1 at runtime. This is an alternative to the > > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. > > > > The environment variable will be ineffective if the ARMV8_MULTIENTRY > > config is used. > > > > This is required by the Armv8r64 architecture, which must be able to > > boot at S-EL1 for Linux but may need to boot at other ELs for other > > systems. > > > > Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> > > Applied to u-boot/next, thanks! Sorry for keeping silent on this, we had some internal discussions here, and we don't think this is the right approach. This whole CONFIG_ARMV8_SWITCH_TO_EL1 solution is actually already questionable, as it goes somewhat against the PSCI spec, which requires secondaries to enter in the highest non-secure exception level (Section 6.1.3: "... As described in Figure 6, the return Exception level for a CPU_ON call is the highest Non secure Exception level implemented.") In any case the primary core must enter an the same exception level as the secondaries, or all hell breaks loose. The current code violates this bluntly when the dynamic method is used (as the spin table code doesn't know about this variable). So can you please revert this patch? We are looking into a different solution for getting into EL2, which wouldn't involve U-Boot at all. The other patches and the next one are fine, however we would need one small change in the next patch to live with this patch removed. If you like, I can send an amended version of 6/6 to accommodate this. Thanks! Andre
On Fri, Sep 03, 2021 at 12:07:20AM +0100, Andre Przywara wrote: > On Thu, 2 Sep 2021 18:42:05 -0400 > Tom Rini <trini@konsulko.com> wrote: > > Hi Tom, > > > On Thu, Aug 19, 2021 at 04:53:13PM +0100, Peter Hoyes wrote: > > > > > From: Peter Hoyes <Peter.Hoyes@arm.com> > > > > > > Use the environment variable armv8_switch_to_el1 to determine whether > > > to switch to EL1 at runtime. This is an alternative to the > > > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. > > > > > > The environment variable will be ineffective if the ARMV8_MULTIENTRY > > > config is used. > > > > > > This is required by the Armv8r64 architecture, which must be able to > > > boot at S-EL1 for Linux but may need to boot at other ELs for other > > > systems. > > > > > > Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> > > > > Applied to u-boot/next, thanks! > > Sorry for keeping silent on this, we had some internal discussions > here, and we don't think this is the right approach. Well, oops on my part too. > This whole CONFIG_ARMV8_SWITCH_TO_EL1 solution is actually already > questionable, as it goes somewhat against the PSCI spec, which requires > secondaries to enter in the highest non-secure exception level (Section > 6.1.3: "... As described in Figure 6, the return Exception level for a > CPU_ON call is the highest Non secure Exception level implemented.") > > In any case the primary core must enter an the same exception level as > the secondaries, or all hell breaks loose. The current code violates > this bluntly when the dynamic method is used (as the spin table code > doesn't know about this variable). > > So can you please revert this patch? We are looking into a different Should I undo just this, or the whole vexpress_aemv8r series?
Hi, On 03/09/2021 00:49, Tom Rini wrote: > On Fri, Sep 03, 2021 at 12:07:20AM +0100, Andre Przywara wrote: >> On Thu, 2 Sep 2021 18:42:05 -0400 >> Tom Rini <trini@konsulko.com> wrote: >> >> Hi Tom, >> >>> On Thu, Aug 19, 2021 at 04:53:13PM +0100, Peter Hoyes wrote: >>> >>>> From: Peter Hoyes <Peter.Hoyes@arm.com> >>>> >>>> Use the environment variable armv8_switch_to_el1 to determine whether >>>> to switch to EL1 at runtime. This is an alternative to the >>>> CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. >>>> >>>> The environment variable will be ineffective if the ARMV8_MULTIENTRY >>>> config is used. >>>> >>>> This is required by the Armv8r64 architecture, which must be able to >>>> boot at S-EL1 for Linux but may need to boot at other ELs for other >>>> systems. >>>> >>>> Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> >>> Applied to u-boot/next, thanks! >> Sorry for keeping silent on this, we had some internal discussions >> here, and we don't think this is the right approach. > Well, oops on my part too. Oops here too. > >> This whole CONFIG_ARMV8_SWITCH_TO_EL1 solution is actually already >> questionable, as it goes somewhat against the PSCI spec, which requires >> secondaries to enter in the highest non-secure exception level (Section >> 6.1.3: "... As described in Figure 6, the return Exception level for a >> CPU_ON call is the highest Non secure Exception level implemented.") >> >> In any case the primary core must enter an the same exception level as >> the secondaries, or all hell breaks loose. The current code violates >> this bluntly when the dynamic method is used (as the spin table code >> doesn't know about this variable). >> >> So can you please revert this patch? We are looking into a different > Should I undo just this, or the whole vexpress_aemv8r series? > We are still discussing how to support v8-R internally and it'll probably take a while to resolve. Please can you revert the wholeseries apart from patch 1, which isn't actually specific to the v8-R. (If preferable,I can submit a "v3" to clarify this). Peter IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Fri, Sep 03, 2021 at 11:19:28AM +0100, Peter Hoyes wrote: > > Hi, > > On 03/09/2021 00:49, Tom Rini wrote: > > On Fri, Sep 03, 2021 at 12:07:20AM +0100, Andre Przywara wrote: > > > On Thu, 2 Sep 2021 18:42:05 -0400 > > > Tom Rini <trini@konsulko.com> wrote: > > > > > > Hi Tom, > > > > > > > On Thu, Aug 19, 2021 at 04:53:13PM +0100, Peter Hoyes wrote: > > > > > > > > > From: Peter Hoyes <Peter.Hoyes@arm.com> > > > > > > > > > > Use the environment variable armv8_switch_to_el1 to determine whether > > > > > to switch to EL1 at runtime. This is an alternative to the > > > > > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. > > > > > > > > > > The environment variable will be ineffective if the ARMV8_MULTIENTRY > > > > > config is used. > > > > > > > > > > This is required by the Armv8r64 architecture, which must be able to > > > > > boot at S-EL1 for Linux but may need to boot at other ELs for other > > > > > systems. > > > > > > > > > > Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> > > > > Applied to u-boot/next, thanks! > > > Sorry for keeping silent on this, we had some internal discussions > > > here, and we don't think this is the right approach. > > Well, oops on my part too. > Oops here too. > > > > > This whole CONFIG_ARMV8_SWITCH_TO_EL1 solution is actually already > > > questionable, as it goes somewhat against the PSCI spec, which requires > > > secondaries to enter in the highest non-secure exception level (Section > > > 6.1.3: "... As described in Figure 6, the return Exception level for a > > > CPU_ON call is the highest Non secure Exception level implemented.") > > > > > > In any case the primary core must enter an the same exception level as > > > the secondaries, or all hell breaks loose. The current code violates > > > this bluntly when the dynamic method is used (as the spin table code > > > doesn't know about this variable). > > > > > > So can you please revert this patch? We are looking into a different > > Should I undo just this, or the whole vexpress_aemv8r series? > > > We are still discussing how to support v8-R internally and it'll probably > take a while to resolve. > > Please can you revert the wholeseries apart from patch 1, which isn't > actually specific to the v8-R. (If preferable,I can submit a "v3" to > clarify this). OK, I'll revert everything except the first patch. For the next go-round, I had fixed up that the defconfig wasn't listed in the board MAINTAINERS, and there was a typo in the docs that checkpatch also spotted.
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index f60ee3a7e6..ea9bfe7570 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -317,7 +317,6 @@ __weak void update_os_arch_secondary_cores(uint8_t os_arch) { } -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 static void switch_to_el1(void) { if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && @@ -332,7 +331,6 @@ static void switch_to_el1(void) ES_TO_AARCH64); } #endif -#endif /* Subcommand: GO */ static void boot_jump_linux(bootm_headers_t *images, int flag) @@ -359,21 +357,33 @@ static void boot_jump_linux(bootm_headers_t *images, int flag) update_os_arch_secondary_cores(images->os.arch); -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, - (u64)switch_to_el1, ES_TO_AARCH64); +#ifdef CONFIG_ARMV8_MULTIENTRY + int armv8_switch_to_el1 = -1; #else - if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && - (images->os.arch == IH_ARCH_ARM)) - armv8_switch_to_el2(0, (u64)gd->bd->bi_arch_number, - (u64)images->ft_addr, 0, - (u64)images->ep, - ES_TO_AARCH32); - else - armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, - images->ep, - ES_TO_AARCH64); + int armv8_switch_to_el1 = env_get_yesno("armv8_switch_to_el1"); #endif +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 + if (armv8_switch_to_el1 == -1) { + armv8_switch_to_el1 = 1; + } +#endif + if (armv8_switch_to_el1 == 1) { + armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0, + (u64)switch_to_el1, ES_TO_AARCH64); + } else { + if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && + (images->os.arch == IH_ARCH_ARM)) + armv8_switch_to_el2(0, + (u64)gd->bd->bi_arch_number, + (u64)images->ft_addr, 0, + (u64)images->ep, + ES_TO_AARCH32); + else + armv8_switch_to_el2((u64)images->ft_addr, + 0, 0, 0, + images->ep, + ES_TO_AARCH64); + } } #else unsigned long machid = gd->bd->bi_arch_number;