diff mbox

[U-Boot,v7,1/2] armv8: Support loading 32-bit OS in AArch32 execution state

Message ID 1475909033-8413-2-git-send-email-b18965@freescale.com
State Changes Requested
Delegated to: York Sun
Headers show

Commit Message

Alison Wang Oct. 8, 2016, 6:43 a.m. UTC
To support loading a 32-bit OS, the execution state will change from
AArch64 to AArch32 when jumping to kernel.

The architecture information will be got through checking FIT image,
then U-Boot will load 32-bit OS or 64-bit OS automatically.

Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
Signed-off-by: Alison Wang <alison.wang@nxp.com>
Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
---
Changes in v7:
- Move the call for armv8_switch_to_el2_m into this patch. 

Changes in v6:
- Modified armv8_switch_to_el1(). It will always jump to ep when switching to AArch64 or AArch32 modes.
- Make other platforms compatible with the new armv8_switch_to_el2() and armv8_switch_to_el1().

Changes in v5:
- Modified armv8_switch_to_el2(). It will always jump to ep when switching to AArch64 or AArch32 modes.

Changes in v4:
- Correct config ARM64_SUPPORT_AARCH32.
- Omit arch and ftaddr arguments.
- Rename "xreg5" to "tmp".
- Use xxx_RES1 to combine all RES1 fields in xxx register.
- Use an immediate cmp directly.
- Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.

Changes in v3:
- Comments the functions and the arguments.
- Rename the real parameters.
- Use the macros instead of the magic values.
- Remove the redundant codes.
- Clean up all of the mess in boot_jump_linux().
- Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't support AArch32 state.

Changes in v2:
- armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used
  to switch to AArch64 EL2 or AArch32 Hyp.
- armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used
  to switch to AArch64 EL1 or AArch32 SVC.

 arch/arm/Kconfig                              |   6 +
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S  |  61 +++++++--
 arch/arm/cpu/armv8/start.S                    |   8 ++
 arch/arm/cpu/armv8/transition.S               |   8 +-
 arch/arm/include/asm/arch-fsl-layerscape/mp.h |   4 +
 arch/arm/include/asm/macro.h                  | 176 +++++++++++++++++++-------
 arch/arm/include/asm/system.h                 | 119 ++++++++++++++++-
 arch/arm/lib/bootm.c                          |  39 +++++-
 arch/arm/mach-rmobile/lowlevel_init_gen3.S    |   9 +-
 common/image-fit.c                            |  19 ++-
 10 files changed, 383 insertions(+), 66 deletions(-)

Comments

York Sun Oct. 26, 2016, 4:54 p.m. UTC | #1
On 10/07/2016 11:56 PM, Alison Wang wrote:
> To support loading a 32-bit OS, the execution state will change from
> AArch64 to AArch32 when jumping to kernel.
>
> The architecture information will be got through checking FIT image,
> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>
> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
> ---
> Changes in v7:
> - Move the call for armv8_switch_to_el2_m into this patch.
>

Reviewers,

May I have your comment please? I intend to merge this set when the 
merge window opens.

York
Ryan Harkin Nov. 3, 2016, 6:17 p.m. UTC | #2
Hi York/Alison,

Sorry for not having had time to look at this earlier.


On 26 October 2016 at 17:54, york sun <york.sun@nxp.com> wrote:
> On 10/07/2016 11:56 PM, Alison Wang wrote:
>> To support loading a 32-bit OS, the execution state will change from
>> AArch64 to AArch32 when jumping to kernel.
>>
>> The architecture information will be got through checking FIT image,
>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>
>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
>> ---
>> Changes in v7:
>> - Move the call for armv8_switch_to_el2_m into this patch.
>>
>
> Reviewers,
>
> May I have your comment please? I intend to merge this set when the
> merge window opens.
>

I've just tested these two patches on ARM's FVP Foundation and AEMv8
models and ARM's Juno board.

In all cases, with this patchset, the kernel fails to start.  I see a
continuous reboot, where the kernel starts then immediately resets:

--------------------------------------------------
Starting kernel ...

resetting ...
--------------------------------------------------

So I wouldn't want to see these patches merged.

Regards,
Ryan.
York Sun Nov. 4, 2016, 2:03 a.m. UTC | #3
Alison,

Does Ryan have your 32-bit kernel image? I think kernel 32-bit doesn't support spin table. Please work with Ryan if your PSCI patch is required for the test.

York


-------- Original Message --------
From: Ryan Harkin <ryan.harkin@linaro.org>
Sent: Thursday, November 3, 2016 12:17 PM
To: york sun <york.sun@nxp.com>
Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
CC: Alison Wang <b18965@freescale.com>,agraf@suse.de,Scott Wood <scott.wood@nxp.com>,Stuart Yoder <stuart.yoder@nxp.com>,Leo Li <leoyang.li@nxp.com>,fenghua@phytium.com.cn,monstr@monstr.eu,thomas.ab@samsung.com,mk7.kang@samsung.com,u-boot@lists.denx.de,Jason Jin <jason.jin@nxp.com>,Alison Wang <alison.wang@nxp.com>


Hi York/Alison,

Sorry for not having had time to look at this earlier.


On 26 October 2016 at 17:54, york sun <york.sun@nxp.com> wrote:
> On 10/07/2016 11:56 PM, Alison Wang wrote:
>> To support loading a 32-bit OS, the execution state will change from
>> AArch64 to AArch32 when jumping to kernel.
>>
>> The architecture information will be got through checking FIT image,
>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>
>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
>> ---
>> Changes in v7:
>> - Move the call for armv8_switch_to_el2_m into this patch.
>>
>
> Reviewers,
>
> May I have your comment please? I intend to merge this set when the
> merge window opens.
>

I've just tested these two patches on ARM's FVP Foundation and AEMv8
models and ARM's Juno board.

In all cases, with this patchset, the kernel fails to start.  I see a
continuous reboot, where the kernel starts then immediately resets:

--------------------------------------------------
Starting kernel ...

resetting ...
--------------------------------------------------

So I wouldn't want to see these patches merged.

Regards,
Ryan.
Alison Wang Nov. 4, 2016, 2:26 a.m. UTC | #4
York,

                No, he don’t have my 32-bit kernel image. I am not sure he is using 32-bit kernel or 64-bit kernel.

Ryan,

                I am not familiar with the boards you tested, so I have some questions, please help to work with me to find the root cause.


1.       Are you loading 32-bit kernel or 64-bit kernel?

2.       Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?

3.       Are you using some secure firmware on these boards? In detail, I want to know which EL is running on these boards when calling armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI enabled is needed.


Best Regards,
Alison Wang

From: york sun

Sent: Friday, November 04, 2016 10:04 AM
To: ryan.harkin@linaro.org
Cc: Wang Huan <b18965@freescale.com>; agraf@suse.de; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li <leoyang.li@nxp.com>; fenghua@phytium.com.cn; monstr@monstr.eu; thomas.ab@samsung.com; mk7.kang@samsung.com; u-boot@lists.denx.de; Jason Jin <jason.jin@nxp.com>; Alison Wang <alison.wang@nxp.com>
Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state


Alison,

Does Ryan have your 32-bit kernel image? I think kernel 32-bit doesn't support spin table. Please work with Ryan if your PSCI patch is required for the test.

York


-------- Original Message --------
From: Ryan Harkin <ryan.harkin@linaro.org<mailto:ryan.harkin@linaro.org>>

Sent: Thursday, November 3, 2016 12:17 PM
To: york sun <york.sun@nxp.com<mailto:york.sun@nxp.com>>
Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
CC: Alison Wang <b18965@freescale.com<mailto:b18965@freescale.com>>,agraf@suse.de,Scott Wood <scott.wood@nxp.com<mailto:scott.wood@nxp.com>>,Stuart Yoder <stuart.yoder@nxp.com<mailto:stuart.yoder@nxp.com>>,Leo Li <leoyang.li@nxp.com<mailto:leoyang.li@nxp.com>>,fenghua@phytium.com.cn,monstr@monstr.eu,thomas.ab@samsung.com,mk7.kang@samsung.com,u-boot@lists.denx.de,Jason Jin <jason.jin@nxp.com<mailto:jason.jin@nxp.com>>,Alison Wang <alison.wang@nxp.com<mailto:alison.wang@nxp.com>>

Hi York/Alison,

Sorry for not having had time to look at this earlier.


On 26 October 2016 at 17:54, york sun <york.sun@nxp.com<mailto:york.sun@nxp.com>> wrote:
> On 10/07/2016 11:56 PM, Alison Wang wrote:

>> To support loading a 32-bit OS, the execution state will change from

>> AArch64 to AArch32 when jumping to kernel.

>>

>> The architecture information will be got through checking FIT image,

>> then U-Boot will load 32-bit OS or 64-bit OS automatically.

>>

>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com<mailto:ebony.zhu@nxp.com>>

>> Signed-off-by: Alison Wang <alison.wang@nxp.com<mailto:alison.wang@nxp.com>>

>> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com<mailto:chenhui.zhao@nxp.com>>

>> ---

>> Changes in v7:

>> - Move the call for armv8_switch_to_el2_m into this patch.

>>

>

> Reviewers,

>

> May I have your comment please? I intend to merge this set when the

> merge window opens.

>


I've just tested these two patches on ARM's FVP Foundation and AEMv8
models and ARM's Juno board.

In all cases, with this patchset, the kernel fails to start.  I see a
continuous reboot, where the kernel starts then immediately resets:

--------------------------------------------------
Starting kernel ...

resetting ...
--------------------------------------------------

So I wouldn't want to see these patches merged.

Regards,
Ryan.
Ryan Harkin Nov. 4, 2016, 9:04 a.m. UTC | #5
On 4 November 2016 at 02:26, Alison Wang <alison.wang@nxp.com> wrote:
> York,
>
>
>
>                 No, he don’t have my 32-bit kernel image. I am not sure he
> is using 32-bit kernel or 64-bit kernel.
>
>
>
> Ryan,
>
>
>
>                 I am not familiar with the boards you tested,

The FVP Foundation model is free to use from ARM.  The entire software
stack I'm using is available via ARM's portal:

https://community.arm.com/groups/arm-development-platforms


> so I have some
> questions, please help to work with me to find the root cause.
>
>
>
> 1.       Are you loading 32-bit kernel or 64-bit kernel?
>

I'm loading the "standard" 64-bit kernel.  I was using a kernel based off 4.8:

https://git.linaro.org/landing-teams/working/arm/kernel-release.git/log/?h=latest-armlt-20161001

> 2.       Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
>

I guess it is for the FVP models, if I grep for it, it's in my configs' .h file:

include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1

-------------------------------------------------------
#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
#ifndef CONFIG_SEMIHOSTING
#error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
#endif
#define CONFIG_ARMV8_SWITCH_TO_EL1
#endif
-------------------------------------------------------

But it isn't in my Juno config.


> 3.       Are you using some secure firmware on these boards? In detail, I
> want to know which EL is running on these boards when calling
> armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running in EL2
> when calling armv8_swith_to_el2, the attached patch with PSCI enabled is
> needed.
>

I'm using what ARM consider the "standard" boot flow.  I'm using ARM
Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.

I'd expect my setup to still work after you've added patches to allow
an aarch32 kernel to be booted, but I guess you're changing the boot
path for non-aarch32 kernels also.

Regards,
Ryan.

>
>
>
>
> Best Regards,
>
> Alison Wang
>
>
>
> From: york sun
> Sent: Friday, November 04, 2016 10:04 AM
> To: ryan.harkin@linaro.org
> Cc: Wang Huan <b18965@freescale.com>; agraf@suse.de; Scott Wood
> <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
> <leoyang.li@nxp.com>; fenghua@phytium.com.cn; monstr@monstr.eu;
> thomas.ab@samsung.com; mk7.kang@samsung.com; u-boot@lists.denx.de; Jason Jin
> <jason.jin@nxp.com>; Alison Wang <alison.wang@nxp.com>
>
>
> Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32
> execution state
>
>
>
> Alison,
>
> Does Ryan have your 32-bit kernel image? I think kernel 32-bit doesn't
> support spin table. Please work with Ryan if your PSCI patch is required for
> the test.
>
> York
>
>
>
> -------- Original Message --------
> From: Ryan Harkin <ryan.harkin@linaro.org>
> Sent: Thursday, November 3, 2016 12:17 PM
> To: york sun <york.sun@nxp.com>
> Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32
> execution state
> CC: Alison Wang <b18965@freescale.com>,agraf@suse.de,Scott Wood
> <scott.wood@nxp.com>,Stuart Yoder <stuart.yoder@nxp.com>,Leo Li
> <leoyang.li@nxp.com>,fenghua@phytium.com.cn,monstr@monstr.eu,thomas.ab@samsung.com,mk7.kang@samsung.com,u-boot@lists.denx.de,Jason
> Jin <jason.jin@nxp.com>,Alison Wang <alison.wang@nxp.com>
>
> Hi York/Alison,
>
> Sorry for not having had time to look at this earlier.
>
>
> On 26 October 2016 at 17:54, york sun <york.sun@nxp.com> wrote:
>> On 10/07/2016 11:56 PM, Alison Wang wrote:
>>> To support loading a 32-bit OS, the execution state will change from
>>> AArch64 to AArch32 when jumping to kernel.
>>>
>>> The architecture information will be got through checking FIT image,
>>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>>
>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
>>> ---
>>> Changes in v7:
>>> - Move the call for armv8_switch_to_el2_m into this patch.
>>>
>>
>> Reviewers,
>>
>> May I have your comment please? I intend to merge this set when the
>> merge window opens.
>>
>
> I've just tested these two patches on ARM's FVP Foundation and AEMv8
> models and ARM's Juno board.
>
> In all cases, with this patchset, the kernel fails to start.  I see a
> continuous reboot, where the kernel starts then immediately resets:
>
> --------------------------------------------------
> Starting kernel ...
>
> resetting ...
> --------------------------------------------------
>
> So I wouldn't want to see these patches merged.
>
> Regards,
> Ryan.
Alison Wang Nov. 4, 2016, 9:20 a.m. UTC | #6
> On 4 November 2016 at 02:26, Alison Wang <alison.wang@nxp.com> wrote:

> > York,

> >

> >

> >

> >                 No, he don’t have my 32-bit kernel image. I am not

> > sure he is using 32-bit kernel or 64-bit kernel.

> >

> >

> >

> > Ryan,

> >

> >

> >

> >                 I am not familiar with the boards you tested,

> 

> The FVP Foundation model is free to use from ARM.  The entire software

> stack I'm using is available via ARM's portal:

> 

> https://community.arm.com/groups/arm-development-platforms

> 

> 

> > so I have some

> > questions, please help to work with me to find the root cause.

> >

> >

> >

> > 1.       Are you loading 32-bit kernel or 64-bit kernel?

> >

> 

> I'm loading the "standard" 64-bit kernel.  I was using a kernel based

> off 4.8:

> 

> https://git.linaro.org/landing-teams/working/arm/kernel-

> release.git/log/?h=latest-armlt-20161001

> 

> > 2.       Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?

> >

> 

> I guess it is for the FVP models, if I grep for it, it's in my

> configs' .h file:

> 

> include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1

> 

> -------------------------------------------------------

> #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING

> #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING

> #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif

> -------------------------------------------------------

> 

> But it isn't in my Juno config.

> 

> 

> > 3.       Are you using some secure firmware on these boards? In

> detail, I

> > want to know which EL is running on these boards when calling

> > armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running

> > in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI

> > enabled is needed.

> >

> 

> I'm using what ARM consider the "standard" boot flow.  I'm using ARM

> Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.

> 

> I'd expect my setup to still work after you've added patches to allow

> an aarch32 kernel to be booted, but I guess you're changing the boot

> path for non-aarch32 kernels also.

[Alison Wang] Of course, although I add these patches to support aarch32
kernel, I should make sure aarch64 kernel work too.

If you are using ARM Trusted Firmware to boot u-boot, I want to know what
EL is running for your U-Boot. If it is running in EL2 or EL1, please add
the attached patch to test again.

Thanks.
> 

> Regards,

> Ryan.

> 

> >

> >

> >

> >

> > Best Regards,

> >

> > Alison Wang

> >

> >

> >

> > From: york sun

> > Sent: Friday, November 04, 2016 10:04 AM

> > To: ryan.harkin@linaro.org

> > Cc: Wang Huan <b18965@freescale.com>; agraf@suse.de; Scott Wood

> > <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li

> > <leoyang.li@nxp.com>; fenghua@phytium.com.cn; monstr@monstr.eu;

> > thomas.ab@samsung.com; mk7.kang@samsung.com; u-boot@lists.denx.de;

> > Jason Jin <jason.jin@nxp.com>; Alison Wang <alison.wang@nxp.com>

> >

> >

> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in

> > AArch32 execution state

> >

> >

> >

> > Alison,

> >

> > Does Ryan have your 32-bit kernel image? I think kernel 32-bit

> doesn't

> > support spin table. Please work with Ryan if your PSCI patch is

> > required for the test.

> >

> > York

> >

> >

> >

> > -------- Original Message --------

> > From: Ryan Harkin <ryan.harkin@linaro.org>

> > Sent: Thursday, November 3, 2016 12:17 PM

> > To: york sun <york.sun@nxp.com>

> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in

> > AArch32 execution state

> > CC: Alison Wang <b18965@freescale.com>,agraf@suse.de,Scott Wood

> > <scott.wood@nxp.com>,Stuart Yoder <stuart.yoder@nxp.com>,Leo Li

> >

> <leoyang.li@nxp.com>,fenghua@phytium.com.cn,monstr@monstr.eu,thomas.ab

> > @samsung.com,mk7.kang@samsung.com,u-boot@lists.denx.de,Jason

> > Jin <jason.jin@nxp.com>,Alison Wang <alison.wang@nxp.com>

> >

> > Hi York/Alison,

> >

> > Sorry for not having had time to look at this earlier.

> >

> >

> > On 26 October 2016 at 17:54, york sun <york.sun@nxp.com> wrote:

> >> On 10/07/2016 11:56 PM, Alison Wang wrote:

> >>> To support loading a 32-bit OS, the execution state will change

> from

> >>> AArch64 to AArch32 when jumping to kernel.

> >>>

> >>> The architecture information will be got through checking FIT image,

> >>> then U-Boot will load 32-bit OS or 64-bit OS automatically.

> >>>

> >>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>

> >>> Signed-off-by: Alison Wang <alison.wang@nxp.com>

> >>> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>

> >>> ---

> >>> Changes in v7:

> >>> - Move the call for armv8_switch_to_el2_m into this patch.

> >>>

> >>

> >> Reviewers,

> >>

> >> May I have your comment please? I intend to merge this set when the

> >> merge window opens.

> >>

> >

> > I've just tested these two patches on ARM's FVP Foundation and AEMv8

> > models and ARM's Juno board.

> >

> > In all cases, with this patchset, the kernel fails to start.  I see a

> > continuous reboot, where the kernel starts then immediately resets:

> >

> > --------------------------------------------------

> > Starting kernel ...

> >

> > resetting ...

> > --------------------------------------------------

> >

> > So I wouldn't want to see these patches merged.

> >

> > Regards,

> > Ryan.
Ryan Harkin Nov. 4, 2016, 11:33 a.m. UTC | #7
On 4 November 2016 at 09:20, Alison Wang <alison.wang@nxp.com> wrote:
>> On 4 November 2016 at 02:26, Alison Wang <alison.wang@nxp.com> wrote:
>> > York,
>> >
>> >
>> >
>> >                 No, he don’t have my 32-bit kernel image. I am not
>> > sure he is using 32-bit kernel or 64-bit kernel.
>> >
>> >
>> >
>> > Ryan,
>> >
>> >
>> >
>> >                 I am not familiar with the boards you tested,
>>
>> The FVP Foundation model is free to use from ARM.  The entire software
>> stack I'm using is available via ARM's portal:
>>
>> https://community.arm.com/groups/arm-development-platforms
>>
>>
>> > so I have some
>> > questions, please help to work with me to find the root cause.
>> >
>> >
>> >
>> > 1.       Are you loading 32-bit kernel or 64-bit kernel?
>> >
>>
>> I'm loading the "standard" 64-bit kernel.  I was using a kernel based
>> off 4.8:
>>
>> https://git.linaro.org/landing-teams/working/arm/kernel-
>> release.git/log/?h=latest-armlt-20161001
>>
>> > 2.       Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
>> >
>>
>> I guess it is for the FVP models, if I grep for it, it's in my
>> configs' .h file:
>>
>> include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1
>>
>> -------------------------------------------------------
>> #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING
>> #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
>> #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif
>> -------------------------------------------------------
>>
>> But it isn't in my Juno config.
>>
>>
>> > 3.       Are you using some secure firmware on these boards? In
>> detail, I
>> > want to know which EL is running on these boards when calling
>> > armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running
>> > in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI
>> > enabled is needed.
>> >
>>
>> I'm using what ARM consider the "standard" boot flow.  I'm using ARM
>> Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.
>>
>> I'd expect my setup to still work after you've added patches to allow
>> an aarch32 kernel to be booted, but I guess you're changing the boot
>> path for non-aarch32 kernels also.
> [Alison Wang] Of course, although I add these patches to support aarch32
> kernel, I should make sure aarch64 kernel work too.
>
> If you are using ARM Trusted Firmware to boot u-boot, I want to know what
> EL is running for your U-Boot.

I guess I'm running U-Boot at EL2.  U-Boot is BL33 and the ARM-TF docs say:

---------------------------------------------------------
BL33 (Non-trusted Firmware) execution

EL3 Runtime Software initializes the EL2 or EL1 processor context for
normal- world cold boot, ensuring that no secure state information
finds its way into the non-secure execution state. EL3 Runtime
Software uses the entrypoint information provided by BL2 to jump to
the Non-trusted firmware image (BL33) at the highest available
Exception Level (EL2 if available, otherwise EL1).
---------------------------------------------------------


> If it is running in EL2 or EL1, please add
> the attached patch to test again.

Yes, with the attached patch on top of your original 2 patches,
everything works again.  I tested on FVP Foundation and AEMv8 models
and Juno R0, R1 and R2.

I don't think it would be good to stack these three patches the way
they are presented in the upstream tree because it would not be
bisect-able.  Some re-work or re-ordering would be needed.

Note: I haven't attempted to understand what any of this code is
doing, I'm just testing it with my standard boot flow to make sure
nothing is broken for me.


> Thanks.
>>
>> Regards,
>> Ryan.
>>
>> >
>> >
>> >
>> >
>> > Best Regards,
>> >
>> > Alison Wang
>> >
>> >
>> >
>> > From: york sun
>> > Sent: Friday, November 04, 2016 10:04 AM
>> > To: ryan.harkin@linaro.org
>> > Cc: Wang Huan <b18965@freescale.com>; agraf@suse.de; Scott Wood
>> > <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>> > <leoyang.li@nxp.com>; fenghua@phytium.com.cn; monstr@monstr.eu;
>> > thomas.ab@samsung.com; mk7.kang@samsung.com; u-boot@lists.denx.de;
>> > Jason Jin <jason.jin@nxp.com>; Alison Wang <alison.wang@nxp.com>
>> >
>> >
>> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in
>> > AArch32 execution state
>> >
>> >
>> >
>> > Alison,
>> >
>> > Does Ryan have your 32-bit kernel image? I think kernel 32-bit
>> doesn't
>> > support spin table. Please work with Ryan if your PSCI patch is
>> > required for the test.
>> >
>> > York
>> >
>> >
>> >
>> > -------- Original Message --------
>> > From: Ryan Harkin <ryan.harkin@linaro.org>
>> > Sent: Thursday, November 3, 2016 12:17 PM
>> > To: york sun <york.sun@nxp.com>
>> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in
>> > AArch32 execution state
>> > CC: Alison Wang <b18965@freescale.com>,agraf@suse.de,Scott Wood
>> > <scott.wood@nxp.com>,Stuart Yoder <stuart.yoder@nxp.com>,Leo Li
>> >
>> <leoyang.li@nxp.com>,fenghua@phytium.com.cn,monstr@monstr.eu,thomas.ab
>> > @samsung.com,mk7.kang@samsung.com,u-boot@lists.denx.de,Jason
>> > Jin <jason.jin@nxp.com>,Alison Wang <alison.wang@nxp.com>
>> >
>> > Hi York/Alison,
>> >
>> > Sorry for not having had time to look at this earlier.
>> >
>> >
>> > On 26 October 2016 at 17:54, york sun <york.sun@nxp.com> wrote:
>> >> On 10/07/2016 11:56 PM, Alison Wang wrote:
>> >>> To support loading a 32-bit OS, the execution state will change
>> from
>> >>> AArch64 to AArch32 when jumping to kernel.
>> >>>
>> >>> The architecture information will be got through checking FIT image,
>> >>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>> >>>
>> >>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>> >>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>> >>> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
>> >>> ---
>> >>> Changes in v7:
>> >>> - Move the call for armv8_switch_to_el2_m into this patch.
>> >>>
>> >>
>> >> Reviewers,
>> >>
>> >> May I have your comment please? I intend to merge this set when the
>> >> merge window opens.
>> >>
>> >
>> > I've just tested these two patches on ARM's FVP Foundation and AEMv8
>> > models and ARM's Juno board.
>> >
>> > In all cases, with this patchset, the kernel fails to start.  I see a
>> > continuous reboot, where the kernel starts then immediately resets:
>> >
>> > --------------------------------------------------
>> > Starting kernel ...
>> >
>> > resetting ...
>> > --------------------------------------------------
>> >
>> > So I wouldn't want to see these patches merged.
>> >
>> > Regards,
>> > Ryan.
York Sun Nov. 4, 2016, 3:08 p.m. UTC | #8
On 11/04/2016 05:34 AM, Ryan Harkin wrote:
> On 4 November 2016 at 09:20, Alison Wang <alison.wang@nxp.com> wrote:
>>> On 4 November 2016 at 02:26, Alison Wang <alison.wang@nxp.com> wrote:
>>>> York,
>>>>
>>>>
>>>>
>>>>                 No, he don’t have my 32-bit kernel image. I am not
>>>> sure he is using 32-bit kernel or 64-bit kernel.
>>>>
>>>>
>>>>
>>>> Ryan,
>>>>
>>>>
>>>>
>>>>                 I am not familiar with the boards you tested,
>>>
>>> The FVP Foundation model is free to use from ARM.  The entire software
>>> stack I'm using is available via ARM's portal:
>>>
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.arm.com%2Fgroups%2Farm-development-platforms&data=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=sr1vyQ38lglMJPIGE1i2HaNTxJqsiPgqJtlZJpOvfHc%3D&reserved=0
>>>
>>>
>>>> so I have some
>>>> questions, please help to work with me to find the root cause.
>>>>
>>>>
>>>>
>>>> 1.       Are you loading 32-bit kernel or 64-bit kernel?
>>>>
>>>
>>> I'm loading the "standard" 64-bit kernel.  I was using a kernel based
>>> off 4.8:
>>>
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.linaro.org%2Flanding-teams%2Fworking%2Farm%2Fkernel-&data=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=N9sN8rBtRtib8gBCICvuH2EmwOswW203ERcRtA3FiFU%3D&reserved=0
>>> release.git/log/?h=latest-armlt-20161001
>>>
>>>> 2.       Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
>>>>
>>>
>>> I guess it is for the FVP models, if I grep for it, it's in my
>>> configs' .h file:
>>>
>>> include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1
>>>
>>> -------------------------------------------------------
>>> #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING
>>> #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
>>> #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif
>>> -------------------------------------------------------
>>>
>>> But it isn't in my Juno config.
>>>
>>>
>>>> 3.       Are you using some secure firmware on these boards? In
>>> detail, I
>>>> want to know which EL is running on these boards when calling
>>>> armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running
>>>> in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI
>>>> enabled is needed.
>>>>
>>>
>>> I'm using what ARM consider the "standard" boot flow.  I'm using ARM
>>> Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.
>>>
>>> I'd expect my setup to still work after you've added patches to allow
>>> an aarch32 kernel to be booted, but I guess you're changing the boot
>>> path for non-aarch32 kernels also.
>> [Alison Wang] Of course, although I add these patches to support aarch32
>> kernel, I should make sure aarch64 kernel work too.
>>
>> If you are using ARM Trusted Firmware to boot u-boot, I want to know what
>> EL is running for your U-Boot.
>
> I guess I'm running U-Boot at EL2.  U-Boot is BL33 and the ARM-TF docs say:
>
> ---------------------------------------------------------
> BL33 (Non-trusted Firmware) execution
>
> EL3 Runtime Software initializes the EL2 or EL1 processor context for
> normal- world cold boot, ensuring that no secure state information
> finds its way into the non-secure execution state. EL3 Runtime
> Software uses the entrypoint information provided by BL2 to jump to
> the Non-trusted firmware image (BL33) at the highest available
> Exception Level (EL2 if available, otherwise EL1).
> ---------------------------------------------------------
>
>
>> If it is running in EL2 or EL1, please add
>> the attached patch to test again.
>
> Yes, with the attached patch on top of your original 2 patches,
> everything works again.  I tested on FVP Foundation and AEMv8 models
> and Juno R0, R1 and R2.
>
> I don't think it would be good to stack these three patches the way
> they are presented in the upstream tree because it would not be
> bisect-able.  Some re-work or re-ordering would be needed.
>
> Note: I haven't attempted to understand what any of this code is
> doing, I'm just testing it with my standard boot flow to make sure
> nothing is broken for me.

Ryan,

I support Alison's patch order for her 32-bit patch sets. This feature 
doesn't exist before her first set. It is functional if you run U-Boot 
at EL3 after the first patch. It gets EL2 working after the 2nd set. If 
there is room to clarify in the commit message, please kindly suggest.

York
Ryan Harkin Nov. 4, 2016, 3:32 p.m. UTC | #9
On 4 November 2016 at 15:08, york sun <york.sun@nxp.com> wrote:
> On 11/04/2016 05:34 AM, Ryan Harkin wrote:
>> On 4 November 2016 at 09:20, Alison Wang <alison.wang@nxp.com> wrote:
>>>> On 4 November 2016 at 02:26, Alison Wang <alison.wang@nxp.com> wrote:
>>>>> York,
>>>>>
>>>>>
>>>>>
>>>>>                 No, he don’t have my 32-bit kernel image. I am not
>>>>> sure he is using 32-bit kernel or 64-bit kernel.
>>>>>
>>>>>
>>>>>
>>>>> Ryan,
>>>>>
>>>>>
>>>>>
>>>>>                 I am not familiar with the boards you tested,
>>>>
>>>> The FVP Foundation model is free to use from ARM.  The entire software
>>>> stack I'm using is available via ARM's portal:
>>>>
>>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.arm.com%2Fgroups%2Farm-development-platforms&data=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=sr1vyQ38lglMJPIGE1i2HaNTxJqsiPgqJtlZJpOvfHc%3D&reserved=0
>>>>
>>>>
>>>>> so I have some
>>>>> questions, please help to work with me to find the root cause.
>>>>>
>>>>>
>>>>>
>>>>> 1.       Are you loading 32-bit kernel or 64-bit kernel?
>>>>>
>>>>
>>>> I'm loading the "standard" 64-bit kernel.  I was using a kernel based
>>>> off 4.8:
>>>>
>>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.linaro.org%2Flanding-teams%2Fworking%2Farm%2Fkernel-&data=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=N9sN8rBtRtib8gBCICvuH2EmwOswW203ERcRtA3FiFU%3D&reserved=0
>>>> release.git/log/?h=latest-armlt-20161001
>>>>
>>>>> 2.       Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
>>>>>
>>>>
>>>> I guess it is for the FVP models, if I grep for it, it's in my
>>>> configs' .h file:
>>>>
>>>> include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1
>>>>
>>>> -------------------------------------------------------
>>>> #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING
>>>> #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
>>>> #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif
>>>> -------------------------------------------------------
>>>>
>>>> But it isn't in my Juno config.
>>>>
>>>>
>>>>> 3.       Are you using some secure firmware on these boards? In
>>>> detail, I
>>>>> want to know which EL is running on these boards when calling
>>>>> armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running
>>>>> in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI
>>>>> enabled is needed.
>>>>>
>>>>
>>>> I'm using what ARM consider the "standard" boot flow.  I'm using ARM
>>>> Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.
>>>>
>>>> I'd expect my setup to still work after you've added patches to allow
>>>> an aarch32 kernel to be booted, but I guess you're changing the boot
>>>> path for non-aarch32 kernels also.
>>> [Alison Wang] Of course, although I add these patches to support aarch32
>>> kernel, I should make sure aarch64 kernel work too.
>>>
>>> If you are using ARM Trusted Firmware to boot u-boot, I want to know what
>>> EL is running for your U-Boot.
>>
>> I guess I'm running U-Boot at EL2.  U-Boot is BL33 and the ARM-TF docs say:
>>
>> ---------------------------------------------------------
>> BL33 (Non-trusted Firmware) execution
>>
>> EL3 Runtime Software initializes the EL2 or EL1 processor context for
>> normal- world cold boot, ensuring that no secure state information
>> finds its way into the non-secure execution state. EL3 Runtime
>> Software uses the entrypoint information provided by BL2 to jump to
>> the Non-trusted firmware image (BL33) at the highest available
>> Exception Level (EL2 if available, otherwise EL1).
>> ---------------------------------------------------------
>>
>>
>>> If it is running in EL2 or EL1, please add
>>> the attached patch to test again.
>>
>> Yes, with the attached patch on top of your original 2 patches,
>> everything works again.  I tested on FVP Foundation and AEMv8 models
>> and Juno R0, R1 and R2.
>>
>> I don't think it would be good to stack these three patches the way
>> they are presented in the upstream tree because it would not be
>> bisect-able.  Some re-work or re-ordering would be needed.
>>
>> Note: I haven't attempted to understand what any of this code is
>> doing, I'm just testing it with my standard boot flow to make sure
>> nothing is broken for me.
>
> Ryan,
>
> I support Alison's patch order for her 32-bit patch sets. This feature
> doesn't exist before her first set. It is functional if you run U-Boot
> at EL3 after the first patch.

Which I don't do.  I follow the boot flow recommended by ARM and it
doesn't work for that setup, which I don't think is the right thing to
do.


> It gets EL2 working after the 2nd set. If
> there is room to clarify in the commit message, please kindly suggest.
>

Well, I'm not the maintainer of the tree, but I wouldn't want to have
a tree that wasn't bootable at any point in the patch sequence.
That's generally unacceptable on most projects I work on.  Keeping the
tree bisect-able to prove which commit caused a problem is considered
to be a valuable tool.

Regards,
Ryan.
York Sun Nov. 4, 2016, 3:43 p.m. UTC | #10
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>
>>> Yes, with the attached patch on top of your original 2 patches,
>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>> and Juno R0, R1 and R2.
>>>
>>> I don't think it would be good to stack these three patches the way
>>> they are presented in the upstream tree because it would not be
>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>
>>> Note: I haven't attempted to understand what any of this code is
>>> doing, I'm just testing it with my standard boot flow to make sure
>>> nothing is broken for me.
>>
>> Ryan,
>>
>> I support Alison's patch order for her 32-bit patch sets. This feature
>> doesn't exist before her first set. It is functional if you run U-Boot
>> at EL3 after the first patch.
>
> Which I don't do.  I follow the boot flow recommended by ARM and it
> doesn't work for that setup, which I don't think is the right thing to
> do.
>
>
>> It gets EL2 working after the 2nd set. If
>> there is room to clarify in the commit message, please kindly suggest.
>>
>
> Well, I'm not the maintainer of the tree, but I wouldn't want to have
> a tree that wasn't bootable at any point in the patch sequence.
> That's generally unacceptable on most projects I work on.  Keeping the
> tree bisect-able to prove which commit caused a problem is considered
> to be a valuable tool.
>

Ryan,

Thanks for sharing your concern. I support git-bisect. It is valuable, 
no doubt. Let me try to understand the issue here. Without Alison's 
patches, everything boots OK. With her first set, does something break? 
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, 
then she needs to fix it.

York
Alexander Graf Nov. 4, 2016, 3:53 p.m. UTC | #11
On 04/11/2016 16:43, york sun wrote:
> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>>
>>>> Yes, with the attached patch on top of your original 2 patches,
>>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>>> and Juno R0, R1 and R2.
>>>>
>>>> I don't think it would be good to stack these three patches the way
>>>> they are presented in the upstream tree because it would not be
>>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>>
>>>> Note: I haven't attempted to understand what any of this code is
>>>> doing, I'm just testing it with my standard boot flow to make sure
>>>> nothing is broken for me.
>>>
>>> Ryan,
>>>
>>> I support Alison's patch order for her 32-bit patch sets. This feature
>>> doesn't exist before her first set. It is functional if you run U-Boot
>>> at EL3 after the first patch.
>>
>> Which I don't do.  I follow the boot flow recommended by ARM and it
>> doesn't work for that setup, which I don't think is the right thing to
>> do.
>>
>>
>>> It gets EL2 working after the 2nd set. If
>>> there is room to clarify in the commit message, please kindly suggest.
>>>
>>
>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>> a tree that wasn't bootable at any point in the patch sequence.
>> That's generally unacceptable on most projects I work on.  Keeping the
>> tree bisect-able to prove which commit caused a problem is considered
>> to be a valuable tool.
>>
>
> Ryan,
>
> Thanks for sharing your concern. I support git-bisect. It is valuable,
> no doubt. Let me try to understand the issue here. Without Alison's
> patches, everything boots OK. With her first set, does something break?

Yes, with the patches booting 64bit Linux with U-Boot running in EL2 
breaks according to Ryan.

> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
> then she needs to fix it.

That's his point :). And I concur.

(btw, you guys really should start thinking about following the ARM 
recommended boot model. It's pretty cumbersome to do everything 
different just for NXP)

Alex
Ryan Harkin Nov. 4, 2016, 3:58 p.m. UTC | #12
On 4 November 2016 at 15:53, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 04/11/2016 16:43, york sun wrote:
>>
>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>>>
>>>>>
>>>>> Yes, with the attached patch on top of your original 2 patches,
>>>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>>>> and Juno R0, R1 and R2.
>>>>>
>>>>> I don't think it would be good to stack these three patches the way
>>>>> they are presented in the upstream tree because it would not be
>>>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>>>
>>>>> Note: I haven't attempted to understand what any of this code is
>>>>> doing, I'm just testing it with my standard boot flow to make sure
>>>>> nothing is broken for me.
>>>>
>>>>
>>>> Ryan,
>>>>
>>>> I support Alison's patch order for her 32-bit patch sets. This feature
>>>> doesn't exist before her first set. It is functional if you run U-Boot
>>>> at EL3 after the first patch.
>>>
>>>
>>> Which I don't do.  I follow the boot flow recommended by ARM and it
>>> doesn't work for that setup, which I don't think is the right thing to
>>> do.
>>>
>>>
>>>> It gets EL2 working after the 2nd set. If
>>>> there is room to clarify in the commit message, please kindly suggest.
>>>>
>>>
>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>>> a tree that wasn't bootable at any point in the patch sequence.
>>> That's generally unacceptable on most projects I work on.  Keeping the
>>> tree bisect-able to prove which commit caused a problem is considered
>>> to be a valuable tool.
>>>
>>
>> Ryan,
>>
>> Thanks for sharing your concern. I support git-bisect. It is valuable,
>> no doubt. Let me try to understand the issue here. Without Alison's
>> patches, everything boots OK. With her first set, does something break?
>
>
> Yes, with the patches booting 64bit Linux with U-Boot running in EL2 breaks
> according to Ryan.
>
>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
>> then she needs to fix it.
>
>
> That's his point :). And I concur.
>

Correct.  Thanks Alex for clarifying what I'm trying to say :)


> (btw, you guys really should start thinking about following the ARM
> recommended boot model. It's pretty cumbersome to do everything different
> just for NXP)
>
York Sun Nov. 4, 2016, 4:08 p.m. UTC | #13
On 11/04/2016 09:53 AM, Alexander Graf wrote:
>
>
> On 04/11/2016 16:43, york sun wrote:
>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>>>
>>>>> Yes, with the attached patch on top of your original 2 patches,
>>>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>>>> and Juno R0, R1 and R2.
>>>>>
>>>>> I don't think it would be good to stack these three patches the way
>>>>> they are presented in the upstream tree because it would not be
>>>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>>>
>>>>> Note: I haven't attempted to understand what any of this code is
>>>>> doing, I'm just testing it with my standard boot flow to make sure
>>>>> nothing is broken for me.
>>>>
>>>> Ryan,
>>>>
>>>> I support Alison's patch order for her 32-bit patch sets. This feature
>>>> doesn't exist before her first set. It is functional if you run U-Boot
>>>> at EL3 after the first patch.
>>>
>>> Which I don't do.  I follow the boot flow recommended by ARM and it
>>> doesn't work for that setup, which I don't think is the right thing to
>>> do.
>>>
>>>
>>>> It gets EL2 working after the 2nd set. If
>>>> there is room to clarify in the commit message, please kindly suggest.
>>>>
>>>
>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>>> a tree that wasn't bootable at any point in the patch sequence.
>>> That's generally unacceptable on most projects I work on.  Keeping the
>>> tree bisect-able to prove which commit caused a problem is considered
>>> to be a valuable tool.
>>>
>>
>> Ryan,
>>
>> Thanks for sharing your concern. I support git-bisect. It is valuable,
>> no doubt. Let me try to understand the issue here. Without Alison's
>> patches, everything boots OK. With her first set, does something break?
>
> Yes, with the patches booting 64bit Linux with U-Boot running in EL2
> breaks according to Ryan.
>
>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
>> then she needs to fix it.
>
> That's his point :). And I concur.

Thanks for the confirmation.

>
> (btw, you guys really should start thinking about following the ARM
> recommended boot model. It's pretty cumbersome to do everything
> different just for NXP)

If you are referring the trusted firmware, we are following that 
direction. Just not fully up yet on some platform.

It is definitely not our intention to be cumbersome. Please point out 
where it went sideway beside the trusted firmware.

York
Alexander Graf Nov. 4, 2016, 4:12 p.m. UTC | #14
On 04/11/2016 17:08, york sun wrote:
> On 11/04/2016 09:53 AM, Alexander Graf wrote:
>>
>>
>> On 04/11/2016 16:43, york sun wrote:
>>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>>>>
>>>>>> Yes, with the attached patch on top of your original 2 patches,
>>>>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>>>>> and Juno R0, R1 and R2.
>>>>>>
>>>>>> I don't think it would be good to stack these three patches the way
>>>>>> they are presented in the upstream tree because it would not be
>>>>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>>>>
>>>>>> Note: I haven't attempted to understand what any of this code is
>>>>>> doing, I'm just testing it with my standard boot flow to make sure
>>>>>> nothing is broken for me.
>>>>>
>>>>> Ryan,
>>>>>
>>>>> I support Alison's patch order for her 32-bit patch sets. This feature
>>>>> doesn't exist before her first set. It is functional if you run U-Boot
>>>>> at EL3 after the first patch.
>>>>
>>>> Which I don't do.  I follow the boot flow recommended by ARM and it
>>>> doesn't work for that setup, which I don't think is the right thing to
>>>> do.
>>>>
>>>>
>>>>> It gets EL2 working after the 2nd set. If
>>>>> there is room to clarify in the commit message, please kindly suggest.
>>>>>
>>>>
>>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>>>> a tree that wasn't bootable at any point in the patch sequence.
>>>> That's generally unacceptable on most projects I work on.  Keeping the
>>>> tree bisect-able to prove which commit caused a problem is considered
>>>> to be a valuable tool.
>>>>
>>>
>>> Ryan,
>>>
>>> Thanks for sharing your concern. I support git-bisect. It is valuable,
>>> no doubt. Let me try to understand the issue here. Without Alison's
>>> patches, everything boots OK. With her first set, does something break?
>>
>> Yes, with the patches booting 64bit Linux with U-Boot running in EL2
>> breaks according to Ryan.
>>
>>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
>>> then she needs to fix it.
>>
>> That's his point :). And I concur.
>
> Thanks for the confirmation.
>
>>
>> (btw, you guys really should start thinking about following the ARM
>> recommended boot model. It's pretty cumbersome to do everything
>> different just for NXP)
>
> If you are referring the trusted firmware, we are following that
> direction. Just not fully up yet on some platform.
>
> It is definitely not our intention to be cumbersome. Please point out
> where it went sideway beside the trusted firmware.

Basically it boils down to the fact that you are the only platform that 
runs U-Boot in EL3 :).

If you want to keep the memory initialization inside of U-Boot, I think 
that's great. But you could either split that into SPL/EL2 or degrade 
yourself into EL2 as soon as possible by calling into an EL3 firmware. 
Whether you build that firmware as part of U-Boot (the stock one could 
be very trivial) or externally is not really too much of a problem.

Things like Alison's patches could then do a simple PSCI call into said 
EL3 firmware to call into 32bit code in EL2 for example.


Alex
York Sun Nov. 4, 2016, 4:18 p.m. UTC | #15
On 11/04/2016 10:12 AM, Alexander Graf wrote:
>
>
> On 04/11/2016 17:08, york sun wrote:
>> On 11/04/2016 09:53 AM, Alexander Graf wrote:
>>>
>>>
>>> On 04/11/2016 16:43, york sun wrote:
>>>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>>>>>
>>>>>>> Yes, with the attached patch on top of your original 2 patches,
>>>>>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>>>>>> and Juno R0, R1 and R2.
>>>>>>>
>>>>>>> I don't think it would be good to stack these three patches the way
>>>>>>> they are presented in the upstream tree because it would not be
>>>>>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>>>>>
>>>>>>> Note: I haven't attempted to understand what any of this code is
>>>>>>> doing, I'm just testing it with my standard boot flow to make sure
>>>>>>> nothing is broken for me.
>>>>>>
>>>>>> Ryan,
>>>>>>
>>>>>> I support Alison's patch order for her 32-bit patch sets. This feature
>>>>>> doesn't exist before her first set. It is functional if you run U-Boot
>>>>>> at EL3 after the first patch.
>>>>>
>>>>> Which I don't do.  I follow the boot flow recommended by ARM and it
>>>>> doesn't work for that setup, which I don't think is the right thing to
>>>>> do.
>>>>>
>>>>>
>>>>>> It gets EL2 working after the 2nd set. If
>>>>>> there is room to clarify in the commit message, please kindly suggest.
>>>>>>
>>>>>
>>>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>>>>> a tree that wasn't bootable at any point in the patch sequence.
>>>>> That's generally unacceptable on most projects I work on.  Keeping the
>>>>> tree bisect-able to prove which commit caused a problem is considered
>>>>> to be a valuable tool.
>>>>>
>>>>
>>>> Ryan,
>>>>
>>>> Thanks for sharing your concern. I support git-bisect. It is valuable,
>>>> no doubt. Let me try to understand the issue here. Without Alison's
>>>> patches, everything boots OK. With her first set, does something break?
>>>
>>> Yes, with the patches booting 64bit Linux with U-Boot running in EL2
>>> breaks according to Ryan.
>>>
>>>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
>>>> then she needs to fix it.
>>>
>>> That's his point :). And I concur.
>>
>> Thanks for the confirmation.
>>
>>>
>>> (btw, you guys really should start thinking about following the ARM
>>> recommended boot model. It's pretty cumbersome to do everything
>>> different just for NXP)
>>
>> If you are referring the trusted firmware, we are following that
>> direction. Just not fully up yet on some platform.
>>
>> It is definitely not our intention to be cumbersome. Please point out
>> where it went sideway beside the trusted firmware.
>
> Basically it boils down to the fact that you are the only platform that
> runs U-Boot in EL3 :).
>
> If you want to keep the memory initialization inside of U-Boot, I think
> that's great. But you could either split that into SPL/EL2 or degrade
> yourself into EL2 as soon as possible by calling into an EL3 firmware.
> Whether you build that firmware as part of U-Boot (the stock one could
> be very trivial) or externally is not really too much of a problem.
>
> Things like Alison's patches could then do a simple PSCI call into said
> EL3 firmware to call into 32bit code in EL2 for example.
>

Basically I agree with you. U-Boot will run at EL2 as soon as we have 
the trusted firmware in place.

York
Alison Wang Nov. 7, 2016, 2:21 a.m. UTC | #16
> On 11/04/2016 10:12 AM, Alexander Graf wrote:
> >
> >
> > On 04/11/2016 17:08, york sun wrote:
> >> On 11/04/2016 09:53 AM, Alexander Graf wrote:
> >>>
> >>>
> >>> On 04/11/2016 16:43, york sun wrote:
> >>>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
> >>>>>>>
> >>>>>>> Yes, with the attached patch on top of your original 2 patches,
> >>>>>>> everything works again.  I tested on FVP Foundation and AEMv8
> >>>>>>> models and Juno R0, R1 and R2.
> >>>>>>>
> >>>>>>> I don't think it would be good to stack these three patches the
> >>>>>>> way they are presented in the upstream tree because it would
> not
> >>>>>>> be bisect-able.  Some re-work or re-ordering would be needed.
> >>>>>>>
> >>>>>>> Note: I haven't attempted to understand what any of this code
> is
> >>>>>>> doing, I'm just testing it with my standard boot flow to make
> >>>>>>> sure nothing is broken for me.
> >>>>>>
> >>>>>> Ryan,
> >>>>>>
> >>>>>> I support Alison's patch order for her 32-bit patch sets. This
> >>>>>> feature doesn't exist before her first set. It is functional if
> >>>>>> you run U-Boot at EL3 after the first patch.
> >>>>>
> >>>>> Which I don't do.  I follow the boot flow recommended by ARM and
> >>>>> it doesn't work for that setup, which I don't think is the right
> >>>>> thing to do.
> >>>>>
> >>>>>
> >>>>>> It gets EL2 working after the 2nd set. If there is room to
> >>>>>> clarify in the commit message, please kindly suggest.
> >>>>>>
> >>>>>
> >>>>> Well, I'm not the maintainer of the tree, but I wouldn't want to
> >>>>> have a tree that wasn't bootable at any point in the patch
> sequence.
> >>>>> That's generally unacceptable on most projects I work on.
> Keeping
> >>>>> the tree bisect-able to prove which commit caused a problem is
> >>>>> considered to be a valuable tool.
> >>>>>
> >>>>
> >>>> Ryan,
> >>>>
> >>>> Thanks for sharing your concern. I support git-bisect. It is
> >>>> valuable, no doubt. Let me try to understand the issue here.
> >>>> Without Alison's patches, everything boots OK. With her first set,
> does something break?
> >>>
> >>> Yes, with the patches booting 64bit Linux with U-Boot running in
> EL2
> >>> breaks according to Ryan.
> >>>
> >>>> My understanding is 32-bit OS can boot. If existing 64-bit OS
> >>>> fails, then she needs to fix it.
> >>>
> >>> That's his point :). And I concur.
> >>
> >> Thanks for the confirmation.
> >>
> >>>
> >>> (btw, you guys really should start thinking about following the ARM
> >>> recommended boot model. It's pretty cumbersome to do everything
> >>> different just for NXP)
> >>
> >> If you are referring the trusted firmware, we are following that
> >> direction. Just not fully up yet on some platform.
> >>
> >> It is definitely not our intention to be cumbersome. Please point
> out
> >> where it went sideway beside the trusted firmware.
> >
> > Basically it boils down to the fact that you are the only platform
> > that runs U-Boot in EL3 :).
> >
> > If you want to keep the memory initialization inside of U-Boot, I
> > think that's great. But you could either split that into SPL/EL2 or
> > degrade yourself into EL2 as soon as possible by calling into an EL3
> firmware.
> > Whether you build that firmware as part of U-Boot (the stock one
> could
> > be very trivial) or externally is not really too much of a problem.
> >
> > Things like Alison's patches could then do a simple PSCI call into
> > said
> > EL3 firmware to call into 32bit code in EL2 for example.
> >
> 
> Basically I agree with you. U-Boot will run at EL2 as soon as we have
> the trusted firmware in place.
> 
[Alison Wang] Thanks for all your comments.

For the issue about the tree would not be bisect-able, I have
a solution. Actually it is the root cause that 64-bit kernel could not boot
up when U-Boot is running in EL2. I will move these codes from the third patch
to the first patch.

ENTRY(armv8_switch_to_el2)
        switch_el x5, 1f, 0f, 0f
-0:     ret
+       /*
+        * x3 is kernel entry point or switch_to_el1
+         * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
+         * When running in EL2 now, jump to the
+         * address saved in x3.
+        */
+0:     br x3
 1:     armv8_switch_to_el2_m x3, x4, x5
 ENDPROC(armv8_switch_to_el2)

 ENTRY(armv8_switch_to_el1)
 	  switch_el x5, 0f, 1f, 0f
-0:     ret
+
+       /*
+         * x3 is kernel entry point. When running in EL1
+         * now, jump to the address saved in x3.
+        */
+0:     br x3
 1:     armv8_switch_to_el1_m x3, x4, x5
 ENDPROC(armv8_switch_to_el1)

With this re-order, the bitsect issue will be fixed and there is not a point
that kernel could not boot up.

If you all agree with this re-order, I will send out the v8 patch includes the
first, second and third patches.


Best Regards,
Alison Wang
Ryan Harkin Nov. 7, 2016, 11:14 a.m. UTC | #17
Hi Alison,

On 7 November 2016 at 02:21, Alison Wang <alison.wang@nxp.com> wrote:
>> On 11/04/2016 10:12 AM, Alexander Graf wrote:
>> >
>> >
>> > On 04/11/2016 17:08, york sun wrote:
>> >> On 11/04/2016 09:53 AM, Alexander Graf wrote:
>> >>>
>> >>>
>> >>> On 04/11/2016 16:43, york sun wrote:
>> >>>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>> >>>>>>>
>> >>>>>>> Yes, with the attached patch on top of your original 2 patches,
>> >>>>>>> everything works again.  I tested on FVP Foundation and AEMv8
>> >>>>>>> models and Juno R0, R1 and R2.
>> >>>>>>>
>> >>>>>>> I don't think it would be good to stack these three patches the
>> >>>>>>> way they are presented in the upstream tree because it would
>> not
>> >>>>>>> be bisect-able.  Some re-work or re-ordering would be needed.
>> >>>>>>>
>> >>>>>>> Note: I haven't attempted to understand what any of this code
>> is
>> >>>>>>> doing, I'm just testing it with my standard boot flow to make
>> >>>>>>> sure nothing is broken for me.
>> >>>>>>
>> >>>>>> Ryan,
>> >>>>>>
>> >>>>>> I support Alison's patch order for her 32-bit patch sets. This
>> >>>>>> feature doesn't exist before her first set. It is functional if
>> >>>>>> you run U-Boot at EL3 after the first patch.
>> >>>>>
>> >>>>> Which I don't do.  I follow the boot flow recommended by ARM and
>> >>>>> it doesn't work for that setup, which I don't think is the right
>> >>>>> thing to do.
>> >>>>>
>> >>>>>
>> >>>>>> It gets EL2 working after the 2nd set. If there is room to
>> >>>>>> clarify in the commit message, please kindly suggest.
>> >>>>>>
>> >>>>>
>> >>>>> Well, I'm not the maintainer of the tree, but I wouldn't want to
>> >>>>> have a tree that wasn't bootable at any point in the patch
>> sequence.
>> >>>>> That's generally unacceptable on most projects I work on.
>> Keeping
>> >>>>> the tree bisect-able to prove which commit caused a problem is
>> >>>>> considered to be a valuable tool.
>> >>>>>
>> >>>>
>> >>>> Ryan,
>> >>>>
>> >>>> Thanks for sharing your concern. I support git-bisect. It is
>> >>>> valuable, no doubt. Let me try to understand the issue here.
>> >>>> Without Alison's patches, everything boots OK. With her first set,
>> does something break?
>> >>>
>> >>> Yes, with the patches booting 64bit Linux with U-Boot running in
>> EL2
>> >>> breaks according to Ryan.
>> >>>
>> >>>> My understanding is 32-bit OS can boot. If existing 64-bit OS
>> >>>> fails, then she needs to fix it.
>> >>>
>> >>> That's his point :). And I concur.
>> >>
>> >> Thanks for the confirmation.
>> >>
>> >>>
>> >>> (btw, you guys really should start thinking about following the ARM
>> >>> recommended boot model. It's pretty cumbersome to do everything
>> >>> different just for NXP)
>> >>
>> >> If you are referring the trusted firmware, we are following that
>> >> direction. Just not fully up yet on some platform.
>> >>
>> >> It is definitely not our intention to be cumbersome. Please point
>> out
>> >> where it went sideway beside the trusted firmware.
>> >
>> > Basically it boils down to the fact that you are the only platform
>> > that runs U-Boot in EL3 :).
>> >
>> > If you want to keep the memory initialization inside of U-Boot, I
>> > think that's great. But you could either split that into SPL/EL2 or
>> > degrade yourself into EL2 as soon as possible by calling into an EL3
>> firmware.
>> > Whether you build that firmware as part of U-Boot (the stock one
>> could
>> > be very trivial) or externally is not really too much of a problem.
>> >
>> > Things like Alison's patches could then do a simple PSCI call into
>> > said
>> > EL3 firmware to call into 32bit code in EL2 for example.
>> >
>>
>> Basically I agree with you. U-Boot will run at EL2 as soon as we have
>> the trusted firmware in place.
>>
> [Alison Wang] Thanks for all your comments.
>
> For the issue about the tree would not be bisect-able, I have
> a solution. Actually it is the root cause that 64-bit kernel could not boot
> up when U-Boot is running in EL2. I will move these codes from the third patch
> to the first patch.
>
> ENTRY(armv8_switch_to_el2)
>         switch_el x5, 1f, 0f, 0f
> -0:     ret
> +       /*
> +        * x3 is kernel entry point or switch_to_el1
> +         * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
> +         * When running in EL2 now, jump to the
> +         * address saved in x3.
> +        */
> +0:     br x3
>  1:     armv8_switch_to_el2_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el2)
>
>  ENTRY(armv8_switch_to_el1)
>           switch_el x5, 0f, 1f, 0f
> -0:     ret
> +
> +       /*
> +         * x3 is kernel entry point. When running in EL1
> +         * now, jump to the address saved in x3.
> +        */
> +0:     br x3
>  1:     armv8_switch_to_el1_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el1)
>
> With this re-order, the bitsect issue will be fixed and there is not a point
> that kernel could not boot up.
>

That sounds perfect.


> If you all agree with this re-order, I will send out the v8 patch includes the
> first, second and third patches.
>

I haven't tried to understand this code, so I can't say if that order
will work or not, but I'm very happy to test it if you produce a
series like this.

Regards,
Ryan.


>
> Best Regards,
> Alison Wang
York Sun Nov. 7, 2016, 4:56 p.m. UTC | #18
On 11/06/2016 06:21 PM, Alison Wang wrote:
>>
> [Alison Wang] Thanks for all your comments.
>
> For the issue about the tree would not be bisect-able, I have
> a solution. Actually it is the root cause that 64-bit kernel could not boot
> up when U-Boot is running in EL2. I will move these codes from the third patch
> to the first patch.
>
> ENTRY(armv8_switch_to_el2)
>         switch_el x5, 1f, 0f, 0f
> -0:     ret
> +       /*
> +        * x3 is kernel entry point or switch_to_el1
> +         * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.

I guess you meant EL2 here.

> +         * When running in EL2 now, jump to the
> +         * address saved in x3.
> +        */
> +0:     br x3
>  1:     armv8_switch_to_el2_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el2)
>
>  ENTRY(armv8_switch_to_el1)
>  	  switch_el x5, 0f, 1f, 0f
> -0:     ret
> +
> +       /*
> +         * x3 is kernel entry point. When running in EL1
> +         * now, jump to the address saved in x3.
> +        */
> +0:     br x3
>  1:     armv8_switch_to_el1_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el1)
>
> With this re-order, the bitsect issue will be fixed and there is not a point
> that kernel could not boot up.
>
> If you all agree with this re-order, I will send out the v8 patch includes the
> first, second and third patches.
>

Would it be a good idea to setup the simulator and verify booting process?

York
Alison Wang Nov. 10, 2016, 3:06 a.m. UTC | #19
> On 7 November 2016 at 02:21, Alison Wang <alison.wang@nxp.com> wrote:
> >> On 11/04/2016 10:12 AM, Alexander Graf wrote:
> >> >
> >> >
> >> > On 04/11/2016 17:08, york sun wrote:
> >> >> On 11/04/2016 09:53 AM, Alexander Graf wrote:
> >> >>>
> >> >>>
> >> >>> On 04/11/2016 16:43, york sun wrote:
> >> >>>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
> >> >>>>>>>
> >> >>>>>>> Yes, with the attached patch on top of your original 2
> >> >>>>>>> patches, everything works again.  I tested on FVP Foundation
> >> >>>>>>> and AEMv8 models and Juno R0, R1 and R2.
> >> >>>>>>>
> >> >>>>>>> I don't think it would be good to stack these three patches
> >> >>>>>>> the way they are presented in the upstream tree because it
> >> >>>>>>> would
> >> not
> >> >>>>>>> be bisect-able.  Some re-work or re-ordering would be needed.
> >> >>>>>>>
> >> >>>>>>> Note: I haven't attempted to understand what any of this
> code
> >> is
> >> >>>>>>> doing, I'm just testing it with my standard boot flow to
> make
> >> >>>>>>> sure nothing is broken for me.
> >> >>>>>>
> >> >>>>>> Ryan,
> >> >>>>>>
> >> >>>>>> I support Alison's patch order for her 32-bit patch sets.
> This
> >> >>>>>> feature doesn't exist before her first set. It is functional
> >> >>>>>> if you run U-Boot at EL3 after the first patch.
> >> >>>>>
> >> >>>>> Which I don't do.  I follow the boot flow recommended by ARM
> >> >>>>> and it doesn't work for that setup, which I don't think is the
> >> >>>>> right thing to do.
> >> >>>>>
> >> >>>>>
> >> >>>>>> It gets EL2 working after the 2nd set. If there is room to
> >> >>>>>> clarify in the commit message, please kindly suggest.
> >> >>>>>>
> >> >>>>>
> >> >>>>> Well, I'm not the maintainer of the tree, but I wouldn't want
> >> >>>>> to have a tree that wasn't bootable at any point in the patch
> >> sequence.
> >> >>>>> That's generally unacceptable on most projects I work on.
> >> Keeping
> >> >>>>> the tree bisect-able to prove which commit caused a problem is
> >> >>>>> considered to be a valuable tool.
> >> >>>>>
> >> >>>>
> >> >>>> Ryan,
> >> >>>>
> >> >>>> Thanks for sharing your concern. I support git-bisect. It is
> >> >>>> valuable, no doubt. Let me try to understand the issue here.
> >> >>>> Without Alison's patches, everything boots OK. With her first
> >> >>>> set,
> >> does something break?
> >> >>>
> >> >>> Yes, with the patches booting 64bit Linux with U-Boot running in
> >> EL2
> >> >>> breaks according to Ryan.
> >> >>>
> >> >>>> My understanding is 32-bit OS can boot. If existing 64-bit OS
> >> >>>> fails, then she needs to fix it.
> >> >>>
> >> >>> That's his point :). And I concur.
> >> >>
> >> >> Thanks for the confirmation.
> >> >>
> >> >>>
> >> >>> (btw, you guys really should start thinking about following the
> >> >>> ARM recommended boot model. It's pretty cumbersome to do
> >> >>> everything different just for NXP)
> >> >>
> >> >> If you are referring the trusted firmware, we are following that
> >> >> direction. Just not fully up yet on some platform.
> >> >>
> >> >> It is definitely not our intention to be cumbersome. Please point
> >> out
> >> >> where it went sideway beside the trusted firmware.
> >> >
> >> > Basically it boils down to the fact that you are the only platform
> >> > that runs U-Boot in EL3 :).
> >> >
> >> > If you want to keep the memory initialization inside of U-Boot, I
> >> > think that's great. But you could either split that into SPL/EL2
> or
> >> > degrade yourself into EL2 as soon as possible by calling into an
> >> > EL3
> >> firmware.
> >> > Whether you build that firmware as part of U-Boot (the stock one
> >> could
> >> > be very trivial) or externally is not really too much of a problem.
> >> >
> >> > Things like Alison's patches could then do a simple PSCI call into
> >> > said
> >> > EL3 firmware to call into 32bit code in EL2 for example.
> >> >
> >>
> >> Basically I agree with you. U-Boot will run at EL2 as soon as we
> have
> >> the trusted firmware in place.
> >>
> > [Alison Wang] Thanks for all your comments.
> >
> > For the issue about the tree would not be bisect-able, I have a
> > solution. Actually it is the root cause that 64-bit kernel could not
> > boot up when U-Boot is running in EL2. I will move these codes from
> > the third patch to the first patch.
> >
> > ENTRY(armv8_switch_to_el2)
> >         switch_el x5, 1f, 0f, 0f
> > -0:     ret
> > +       /*
> > +        * x3 is kernel entry point or switch_to_el1
> > +         * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
> > +         * When running in EL2 now, jump to the
> > +         * address saved in x3.
> > +        */
> > +0:     br x3
> >  1:     armv8_switch_to_el2_m x3, x4, x5
> >  ENDPROC(armv8_switch_to_el2)
> >
> >  ENTRY(armv8_switch_to_el1)
> >           switch_el x5, 0f, 1f, 0f
> > -0:     ret
> > +
> > +       /*
> > +         * x3 is kernel entry point. When running in EL1
> > +         * now, jump to the address saved in x3.
> > +        */
> > +0:     br x3
> >  1:     armv8_switch_to_el1_m x3, x4, x5
> >  ENDPROC(armv8_switch_to_el1)
> >
> > With this re-order, the bitsect issue will be fixed and there is not
> a
> > point that kernel could not boot up.
> >
> 
> That sounds perfect.
> 
> 
> > If you all agree with this re-order, I will send out the v8 patch
> > includes the first, second and third patches.
> >
> 
> I haven't tried to understand this code, so I can't say if that order
> will work or not, but I'm very happy to test it if you produce a series
> like this.
[Alison Wang] Thanks for your support. V8 series is sent out.


Best Regards,
Alison Wang
diff mbox

Patch

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e63309a..f122458 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -126,6 +126,12 @@  config ENABLE_ARM_SOC_BOOT0_HOOK
 	  ARM_SOC_BOOT0_HOOK which contains the required assembler
 	  preprocessor code.
 
+config ARM64_SUPPORT_AARCH32
+	bool "ARM64 system support AArch32 execution state"
+	default y if ARM64 && !TARGET_THUNDERX_88XX
+	help
+	  This ARM64 system supports AArch32 execution state.
+
 choice
 	prompt "Target select"
 	default TARGET_HIKEY
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 5af6b73..782a1ea 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -13,6 +13,7 @@ 
 #ifdef CONFIG_MP
 #include <asm/arch/mp.h>
 #endif
+#include <asm/u-boot.h>
 
 ENTRY(lowlevel_init)
 	mov	x29, lr			/* Save LR */
@@ -324,11 +325,6 @@  ENTRY(secondary_boot_func)
         gic_wait_for_interrupt_m x0, w1
 #endif
 
-	bl secondary_switch_to_el2
-#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-	bl secondary_switch_to_el1
-#endif
-
 slave_cpu:
 	wfe
 	ldr	x0, [x11]
@@ -341,19 +337,64 @@  slave_cpu:
 	tbz     x1, #25, cpu_is_le
 	rev     x0, x0                  /* BE to LE conversion */
 cpu_is_le:
-	br	x0			/* branch to the given address */
+	ldr	x5, [x11, #24]
+	ldr	x6, =IH_ARCH_DEFAULT
+	cmp	x6, x5
+	b.eq	1f
+
+#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
+	adr	x3, secondary_switch_to_el1
+	ldr	x4, =ES_TO_AARCH64
+#else
+	ldr	x3, [x11]
+	ldr	x4, =ES_TO_AARCH32
+#endif
+	bl	secondary_switch_to_el2
+
+1:
+#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
+	adr	x3, secondary_switch_to_el1
+#else
+	ldr	x3, [x11]
+#endif
+	ldr	x4, =ES_TO_AARCH64
+	bl	secondary_switch_to_el2
+
 ENDPROC(secondary_boot_func)
 
 ENTRY(secondary_switch_to_el2)
-	switch_el x0, 1f, 0f, 0f
+	switch_el x5, 1f, 0f, 0f
 0:	ret
-1:	armv8_switch_to_el2_m x0
+1:	armv8_switch_to_el2_m x3, x4, x5
 ENDPROC(secondary_switch_to_el2)
 
 ENTRY(secondary_switch_to_el1)
-	switch_el x0, 0f, 1f, 0f
+	mrs	x0, mpidr_el1
+	ubfm	x1, x0, #8, #15
+	ubfm	x2, x0, #0, #1
+	orr	x10, x2, x1, lsl #2	/* x10 has LPID */
+
+	lsl	x1, x10, #6
+	ldr	x0, =__spin_table
+	/* physical address of this cpus spin table element */
+	add	x11, x1, x0
+
+	ldr	x3, [x11]
+
+	ldr	x5, [x11, #24]
+	ldr	x6, =IH_ARCH_DEFAULT
+	cmp	x6, x5
+	b.eq	2f
+
+	ldr	x4, =ES_TO_AARCH32
+	bl	switch_to_el1
+
+2:	ldr	x4, =ES_TO_AARCH64
+
+switch_to_el1:
+	switch_el x5, 0f, 1f, 0f
 0:	ret
-1:	armv8_switch_to_el1_m x0, x1
+1:	armv8_switch_to_el1_m x3, x4, x5
 ENDPROC(secondary_switch_to_el1)
 
 	/* Ensure that the literals used by the secondary boot code are
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 19c771d..4f5f6d8 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -251,9 +251,17 @@  WEAK(lowlevel_init)
 	/*
 	 * All slaves will enter EL2 and optionally EL1.
 	 */
+	adr	x3, lowlevel_in_el2
+	ldr	x4, =ES_TO_AARCH64
 	bl	armv8_switch_to_el2
+
+lowlevel_in_el2:
 #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
+	adr	x3, lowlevel_in_el1
+	ldr	x4, =ES_TO_AARCH64
 	bl	armv8_switch_to_el1
+
+lowlevel_in_el1:
 #endif
 
 #endif /* CONFIG_ARMV8_MULTIENTRY */
diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S
index 253a39b..115b6e9 100644
--- a/arch/arm/cpu/armv8/transition.S
+++ b/arch/arm/cpu/armv8/transition.S
@@ -11,13 +11,13 @@ 
 #include <asm/macro.h>
 
 ENTRY(armv8_switch_to_el2)
-	switch_el x0, 1f, 0f, 0f
+	switch_el x5, 1f, 0f, 0f
 0:	ret
-1:	armv8_switch_to_el2_m x0
+1:	armv8_switch_to_el2_m x3, x4, x5
 ENDPROC(armv8_switch_to_el2)
 
 ENTRY(armv8_switch_to_el1)
-	switch_el x0, 0f, 1f, 0f
+	switch_el x5, 0f, 1f, 0f
 0:	ret
-1:	armv8_switch_to_el1_m x0, x1
+1:	armv8_switch_to_el1_m x3, x4, x5
 ENDPROC(armv8_switch_to_el1)
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
index e46e076..14d9fcf 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
@@ -35,4 +35,8 @@  phys_addr_t determine_mp_bootpg(void);
 void secondary_boot_func(void);
 int is_core_online(u64 cpu_id);
 #endif
+
+#define IH_ARCH_ARM		2	/* ARM */
+#define IH_ARCH_ARM64		22	/* ARM64 */
+
 #endif /* _FSL_LAYERSCAPE_MP_H */
diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
index 9bb0efa..2553e3e 100644
--- a/arch/arm/include/asm/macro.h
+++ b/arch/arm/include/asm/macro.h
@@ -8,6 +8,11 @@ 
 
 #ifndef __ASM_ARM_MACRO_H__
 #define __ASM_ARM_MACRO_H__
+
+#ifdef CONFIG_ARM64
+#include <asm/system.h>
+#endif
+
 #ifdef __ASSEMBLY__
 
 /*
@@ -135,13 +140,21 @@  lr	.req	x30
 #endif
 .endm
 
-.macro armv8_switch_to_el2_m, xreg1
-	/* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */
-	mov	\xreg1, #0x5b1
-	msr	scr_el3, \xreg1
+/*
+ * Switch from EL3 to EL2 for ARMv8
+ * @ep:     kernel entry point
+ * @flag:   The execution state flag for lower exception
+ *          level, ES_TO_AARCH64 or ES_TO_AARCH32
+ * @tmp:    temporary register
+ *
+ * For loading 32-bit OS, x1 is machine nr and x2 is ftaddr.
+ * For loading 64-bit OS, x0 is physical address to the FDT blob.
+ * They will be passed to the guest.
+ */
+.macro armv8_switch_to_el2_m, ep, flag, tmp
 	msr	cptr_el3, xzr		/* Disable coprocessor traps to EL3 */
-	mov	\xreg1, #0x33ff
-	msr	cptr_el2, \xreg1	/* Disable coprocessor traps to EL2 */
+	mov	\tmp, #CPTR_EL2_RES1
+	msr	cptr_el2, \tmp		/* Disable coprocessor traps to EL2 */
 
 	/* Initialize Generic Timers */
 	msr	cntvoff_el2, xzr
@@ -152,45 +165,90 @@  lr	.req	x30
 	 * and RES0 bits (31,30,27,26,24,21,20,17,15-13,10-6) +
 	 * EE,WXN,I,SA,C,A,M to 0
 	 */
-	mov	\xreg1, #0x0830
-	movk	\xreg1, #0x30C5, lsl #16
-	msr	sctlr_el2, \xreg1
+	ldr	\tmp, =(SCTLR_EL2_RES1 | SCTLR_EL2_EE_LE |\
+			SCTLR_EL2_WXN_DIS | SCTLR_EL2_ICACHE_DIS |\
+			SCTLR_EL2_SA_DIS | SCTLR_EL2_DCACHE_DIS |\
+			SCTLR_EL2_ALIGN_DIS | SCTLR_EL2_MMU_DIS)
+	msr	sctlr_el2, \tmp
+
+	mov	\tmp, sp
+	msr	sp_el2, \tmp		/* Migrate SP */
+	mrs	\tmp, vbar_el3
+	msr	vbar_el2, \tmp		/* Migrate VBAR */
+
+	/* Check switch to AArch64 EL2 or AArch32 Hypervisor mode */
+	cmp	\flag, #ES_TO_AARCH32
+	b.eq	1f
+
+	/*
+	 * The next lower exception level is AArch64, 64bit EL2 | HCE |
+	 * SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1.
+	 */
+	ldr	\tmp, =(SCR_EL3_RW_AARCH64 | SCR_EL3_HCE_EN |\
+			SCR_EL3_SMD_DIS | SCR_EL3_RES1 |\
+			SCR_EL3_NS_EN)
+	msr	scr_el3, \tmp
 
 	/* Return to the EL2_SP2 mode from EL3 */
-	mov	\xreg1, sp
-	msr	sp_el2, \xreg1		/* Migrate SP */
-	mrs	\xreg1, vbar_el3
-	msr	vbar_el2, \xreg1	/* Migrate VBAR */
-	mov	\xreg1, #0x3c9
-	msr	spsr_el3, \xreg1	/* EL2_SP2 | D | A | I | F */
-	msr	elr_el3, lr
+	ldr	\tmp, =(SPSR_EL_DEBUG_MASK | SPSR_EL_SERR_MASK |\
+			SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\
+			SPSR_EL_M_AARCH64 | SPSR_EL_M_EL2H)
+	msr	spsr_el3, \tmp
+	msr	elr_el3, \ep
+	eret
+
+1:
+	/*
+	 * The next lower exception level is AArch32, 32bit EL2 | HCE |
+	 * SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1.
+	 */
+	ldr	\tmp, =(SCR_EL3_RW_AARCH32 | SCR_EL3_HCE_EN |\
+			SCR_EL3_SMD_DIS | SCR_EL3_RES1 |\
+			SCR_EL3_NS_EN)
+	msr	scr_el3, \tmp
+
+	/* Return to AArch32 Hypervisor mode */
+	ldr     \tmp, =(SPSR_EL_END_LE | SPSR_EL_ASYN_MASK |\
+			SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\
+			SPSR_EL_T_A32 | SPSR_EL_M_AARCH32 |\
+			SPSR_EL_M_HYP)
+	msr	spsr_el3, \tmp
+	msr     elr_el3, \ep
 	eret
 .endm
 
-.macro armv8_switch_to_el1_m, xreg1, xreg2
+/*
+ * Switch from EL2 to EL1 for ARMv8
+ * @ep:     kernel entry point
+ * @flag:   The execution state flag for lower exception
+ *          level, ES_TO_AARCH64 or ES_TO_AARCH32
+ * @tmp:    temporary register
+ *
+ * For loading 32-bit OS, x1 is machine nr and x2 is ftaddr.
+ * For loading 64-bit OS, x0 is physical address to the FDT blob.
+ * They will be passed to the guest.
+ */
+.macro armv8_switch_to_el1_m, ep, flag, tmp
 	/* Initialize Generic Timers */
-	mrs	\xreg1, cnthctl_el2
-	orr	\xreg1, \xreg1, #0x3	/* Enable EL1 access to timers */
-	msr	cnthctl_el2, \xreg1
+	mrs	\tmp, cnthctl_el2
+	/* Enable EL1 access to timers */
+	orr	\tmp, \tmp, #(CNTHCTL_EL2_EL1PCEN_EN |\
+		CNTHCTL_EL2_EL1PCTEN_EN)
+	msr	cnthctl_el2, \tmp
 	msr	cntvoff_el2, xzr
 
 	/* Initilize MPID/MPIDR registers */
-	mrs	\xreg1, midr_el1
-	mrs	\xreg2, mpidr_el1
-	msr	vpidr_el2, \xreg1
-	msr	vmpidr_el2, \xreg2
+	mrs	\tmp, midr_el1
+	msr	vpidr_el2, \tmp
+	mrs	\tmp, mpidr_el1
+	msr	vmpidr_el2, \tmp
 
 	/* Disable coprocessor traps */
-	mov	\xreg1, #0x33ff
-	msr	cptr_el2, \xreg1	/* Disable coprocessor traps to EL2 */
+	mov	\tmp, #CPTR_EL2_RES1
+	msr	cptr_el2, \tmp		/* Disable coprocessor traps to EL2 */
 	msr	hstr_el2, xzr		/* Disable coprocessor traps to EL2 */
-	mov	\xreg1, #3 << 20
-	msr	cpacr_el1, \xreg1	/* Enable FP/SIMD at EL1 */
-
-	/* Initialize HCR_EL2 */
-	mov	\xreg1, #(1 << 31)		/* 64bit EL1 */
-	orr	\xreg1, \xreg1, #(1 << 29)	/* Disable HVC */
-	msr	hcr_el2, \xreg1
+	mov	\tmp, #CPACR_EL1_FPEN_EN
+	msr	cpacr_el1, \tmp		/* Enable FP/SIMD at EL1 */
 
 	/* SCTLR_EL1 initialization
 	 *
@@ -199,18 +257,50 @@  lr	.req	x30
 	 * UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD,
 	 * CP15BEN,SA0,SA,C,A,M to 0
 	 */
-	mov	\xreg1, #0x0800
-	movk	\xreg1, #0x30d0, lsl #16
-	msr	sctlr_el1, \xreg1
+	ldr	\tmp, =(SCTLR_EL1_RES1 | SCTLR_EL1_UCI_DIS |\
+			SCTLR_EL1_EE_LE | SCTLR_EL1_WXN_DIS |\
+			SCTLR_EL1_NTWE_DIS | SCTLR_EL1_NTWI_DIS |\
+			SCTLR_EL1_UCT_DIS | SCTLR_EL1_DZE_DIS |\
+			SCTLR_EL1_ICACHE_DIS | SCTLR_EL1_UMA_DIS |\
+			SCTLR_EL1_SED_EN | SCTLR_EL1_ITD_EN |\
+			SCTLR_EL1_CP15BEN_DIS | SCTLR_EL1_SA0_DIS |\
+			SCTLR_EL1_SA_DIS | SCTLR_EL1_DCACHE_DIS |\
+			SCTLR_EL1_ALIGN_DIS | SCTLR_EL1_MMU_DIS)
+	msr	sctlr_el1, \tmp
+
+	mov	\tmp, sp
+	msr	sp_el1, \tmp		/* Migrate SP */
+	mrs	\tmp, vbar_el2
+	msr	vbar_el1, \tmp		/* Migrate VBAR */
+
+	/* Check switch to AArch64 EL1 or AArch32 Supervisor mode */
+	cmp	\flag, #ES_TO_AARCH32
+	b.eq	1f
+
+	/* Initialize HCR_EL2 */
+	ldr	\tmp, =(HCR_EL2_RW_AARCH64 | HCR_EL2_HCD_DIS)
+	msr	hcr_el2, \tmp
 
 	/* Return to the EL1_SP1 mode from EL2 */
-	mov	\xreg1, sp
-	msr	sp_el1, \xreg1		/* Migrate SP */
-	mrs	\xreg1, vbar_el2
-	msr	vbar_el1, \xreg1	/* Migrate VBAR */
-	mov	\xreg1, #0x3c5
-	msr	spsr_el2, \xreg1	/* EL1_SP1 | D | A | I | F */
-	msr	elr_el2, lr
+	ldr	\tmp, =(SPSR_EL_DEBUG_MASK | SPSR_EL_SERR_MASK |\
+			SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\
+			SPSR_EL_M_AARCH64 | SPSR_EL_M_EL1H)
+	msr	spsr_el2, \tmp
+	msr     elr_el2, \ep
+	eret
+
+1:
+	/* Initialize HCR_EL2 */
+	ldr	\tmp, =(HCR_EL2_RW_AARCH32 | HCR_EL2_HCD_DIS)
+	msr	hcr_el2, \tmp
+
+	/* Return to AArch32 Supervisor mode from EL2 */
+	ldr	\tmp, =(SPSR_EL_END_LE | SPSR_EL_ASYN_MASK |\
+			SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\
+			SPSR_EL_T_A32 | SPSR_EL_M_AARCH32 |\
+			SPSR_EL_M_SVC)
+	msr     spsr_el2, \tmp
+	msr     elr_el2, \ep
 	eret
 .endm
 
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 7b7b867..06a6624 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -18,6 +18,95 @@ 
 #define CR_WXN		(1 << 19)	/* Write Permision Imply XN	*/
 #define CR_EE		(1 << 25)	/* Exception (Big) Endian	*/
 
+#define ES_TO_AARCH64		1
+#define ES_TO_AARCH32		0
+
+/*
+ * SCR_EL3 bits definitions
+ */
+#define SCR_EL3_RW_AARCH64	(1 << 10) /* Next lower level is AArch64     */
+#define SCR_EL3_RW_AARCH32	(0 << 10) /* Lower lowers level are AArch32  */
+#define SCR_EL3_HCE_EN		(1 << 8)  /* Hypervisor Call enable          */
+#define SCR_EL3_SMD_DIS		(1 << 7)  /* Secure Monitor Call disable     */
+#define SCR_EL3_RES1		(3 << 4)  /* Reserved, RES1                  */
+#define SCR_EL3_NS_EN		(1 << 0)  /* EL0 and EL1 in Non-scure state  */
+
+/*
+ * SPSR_EL3/SPSR_EL2 bits definitions
+ */
+#define SPSR_EL_END_LE		(0 << 9)  /* Exception Little-endian          */
+#define SPSR_EL_DEBUG_MASK	(1 << 9)  /* Debug exception masked           */
+#define SPSR_EL_ASYN_MASK	(1 << 8)  /* Asynchronous data abort masked   */
+#define SPSR_EL_SERR_MASK	(1 << 8)  /* System Error exception masked    */
+#define SPSR_EL_IRQ_MASK	(1 << 7)  /* IRQ exception masked             */
+#define SPSR_EL_FIQ_MASK	(1 << 6)  /* FIQ exception masked             */
+#define SPSR_EL_T_A32		(0 << 5)  /* AArch32 instruction set A32      */
+#define SPSR_EL_M_AARCH64	(0 << 4)  /* Exception taken from AArch64     */
+#define SPSR_EL_M_AARCH32	(1 << 4)  /* Exception taken from AArch32     */
+#define SPSR_EL_M_SVC		(0x3)     /* Exception taken from SVC mode    */
+#define SPSR_EL_M_HYP		(0xa)     /* Exception taken from HYP mode    */
+#define SPSR_EL_M_EL1H		(5)       /* Exception taken from EL1h mode   */
+#define SPSR_EL_M_EL2H		(9)       /* Exception taken from EL2h mode   */
+
+/*
+ * CPTR_EL2 bits definitions
+ */
+#define CPTR_EL2_RES1		(3 << 12 | 0x3ff)           /* Reserved, RES1 */
+
+/*
+ * SCTLR_EL2 bits definitions
+ */
+#define SCTLR_EL2_RES1		(3 << 28 | 3 << 22 | 1 << 18 | 1 << 16 |\
+				 1 << 11 | 3 << 4)	    /* Reserved, RES1 */
+#define SCTLR_EL2_EE_LE		(0 << 25) /* Exception Little-endian          */
+#define SCTLR_EL2_WXN_DIS	(0 << 19) /* Write permission is not XN       */
+#define SCTLR_EL2_ICACHE_DIS	(0 << 12) /* Instruction cache disabled       */
+#define SCTLR_EL2_SA_DIS	(0 << 3)  /* Stack Alignment Check disabled   */
+#define SCTLR_EL2_DCACHE_DIS	(0 << 2)  /* Data cache disabled              */
+#define SCTLR_EL2_ALIGN_DIS	(0 << 1)  /* Alignment check disabled         */
+#define SCTLR_EL2_MMU_DIS	(0)       /* MMU disabled                     */
+
+/*
+ * CNTHCTL_EL2 bits definitions
+ */
+#define CNTHCTL_EL2_EL1PCEN_EN	(1 << 1)  /* Physical timer regs accessible   */
+#define CNTHCTL_EL2_EL1PCTEN_EN	(1 << 0)  /* Physical counter accessible      */
+
+/*
+ * HCR_EL2 bits definitions
+ */
+#define HCR_EL2_RW_AARCH64	(1 << 31) /* EL1 is AArch64                   */
+#define HCR_EL2_RW_AARCH32	(0 << 31) /* Lower levels are AArch32         */
+#define HCR_EL2_HCD_DIS		(1 << 29) /* Hypervisor Call disabled         */
+
+/*
+ * CPACR_EL1 bits definitions
+ */
+#define CPACR_EL1_FPEN_EN	(3 << 20) /* SIMD and FP instruction enabled  */
+
+/*
+ * SCTLR_EL1 bits definitions
+ */
+#define SCTLR_EL1_RES1		(3 << 28 | 3 << 22 | 1 << 20 |\
+				 1 << 11) /* Reserved, RES1                   */
+#define SCTLR_EL1_UCI_DIS	(0 << 26) /* Cache instruction disabled       */
+#define SCTLR_EL1_EE_LE		(0 << 25) /* Exception Little-endian          */
+#define SCTLR_EL1_WXN_DIS	(0 << 19) /* Write permission is not XN       */
+#define SCTLR_EL1_NTWE_DIS	(0 << 18) /* WFE instruction disabled         */
+#define SCTLR_EL1_NTWI_DIS	(0 << 16) /* WFI instruction disabled         */
+#define SCTLR_EL1_UCT_DIS	(0 << 15) /* CTR_EL0 access disabled          */
+#define SCTLR_EL1_DZE_DIS	(0 << 14) /* DC ZVA instruction disabled      */
+#define SCTLR_EL1_ICACHE_DIS	(0 << 12) /* Instruction cache disabled       */
+#define SCTLR_EL1_UMA_DIS	(0 << 9)  /* User Mask Access disabled        */
+#define SCTLR_EL1_SED_EN	(0 << 8)  /* SETEND instruction enabled       */
+#define SCTLR_EL1_ITD_EN	(0 << 7)  /* IT instruction enabled           */
+#define SCTLR_EL1_CP15BEN_DIS	(0 << 5)  /* CP15 barrier operation disabled  */
+#define SCTLR_EL1_SA0_DIS	(0 << 4)  /* Stack Alignment EL0 disabled     */
+#define SCTLR_EL1_SA_DIS	(0 << 3)  /* Stack Alignment EL1 disabled     */
+#define SCTLR_EL1_DCACHE_DIS	(0 << 2)  /* Data cache disabled              */
+#define SCTLR_EL1_ALIGN_DIS	(0 << 1)  /* Alignment check disabled         */
+#define SCTLR_EL1_MMU_DIS	(0)       /* MMU disabled                     */
+
 #ifndef __ASSEMBLY__
 
 u64 get_page_table_size(void);
@@ -96,8 +185,34 @@  void __asm_invalidate_icache_all(void);
 int __asm_flush_l3_cache(void);
 void __asm_switch_ttbr(u64 new_ttbr);
 
-void armv8_switch_to_el2(void);
-void armv8_switch_to_el1(void);
+/*
+ * Switch from EL3 to EL2 for ARMv8
+ *
+ * @args:        For loading 64-bit OS, fdt address.
+ *               For loading 32-bit OS, zero.
+ * @mach_nr:     For loading 64-bit OS, zero.
+ *               For loading 32-bit OS, machine nr
+ * @fdt_addr:    For loading 64-bit OS, zero.
+ *               For loading 32-bit OS, fdt address.
+ * @entry_point: kernel entry point
+ * @es_flag:     execution state flag, ES_TO_AARCH64 or ES_TO_AARCH32
+ */
+void armv8_switch_to_el2(u64 args, u64 mach_nr, u64 fdt_addr,
+			 u64 entry_point, u64 es_flag);
+/*
+ * Switch from EL2 to EL1 for ARMv8
+ *
+ * @args:        For loading 64-bit OS, fdt address.
+ *               For loading 32-bit OS, zero.
+ * @mach_nr:     For loading 64-bit OS, zero.
+ *               For loading 32-bit OS, machine nr
+ * @fdt_addr:    For loading 64-bit OS, zero.
+ *               For loading 32-bit OS, fdt address.
+ * @entry_point: kernel entry point
+ * @es_flag:     execution state flag, ES_TO_AARCH64 or ES_TO_AARCH32
+ */
+void armv8_switch_to_el1(u64 args, u64 mach_nr, u64 fdt_addr,
+			 u64 entry_point, u64 es_flag);
 void gic_init(void);
 void gic_send_sgi(unsigned long sgino);
 void wait_for_wakeup(void);
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 53c3141..7015573 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -193,10 +193,6 @@  static void do_nonsec_virt_switch(void)
 {
 	smp_kick_all_cpus();
 	dcache_disable();	/* flush cache before swtiching to EL2 */
-	armv8_switch_to_el2();
-#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-	armv8_switch_to_el1();
-#endif
 }
 #endif
 
@@ -273,6 +269,24 @@  bool armv7_boot_nonsec(void)
 }
 #endif
 
+#ifdef CONFIG_ARM64
+#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
+static void switch_to_el1(void)
+{
+	if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) &&
+	    (images.os.arch == IH_ARCH_ARM))
+		armv8_switch_to_el1(0, (u64)gd->bd->bi_arch_number,
+				    (u64)images.ft_addr,
+				    (u64)images.ep,
+				    ES_TO_AARCH32);
+	else
+		armv8_switch_to_el1((u64)images.ft_addr, 0, 0,
+				    images.ep,
+				    ES_TO_AARCH64);
+}
+#endif
+#endif
+
 /* Subcommand: GO */
 static void boot_jump_linux(bootm_headers_t *images, int flag)
 {
@@ -292,7 +306,22 @@  static void boot_jump_linux(bootm_headers_t *images, int flag)
 
 	if (!fake) {
 		do_nonsec_virt_switch();
-		kernel_entry(images->ft_addr, NULL, NULL, NULL);
+
+#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
+		armv8_switch_to_el2((u64)images->ft_addr, 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,
+					    (u64)images->ep,
+					    ES_TO_AARCH32);
+		else
+			armv8_switch_to_el2((u64)images->ft_addr, 0, 0,
+					    images->ep,
+					    ES_TO_AARCH64);
+#endif
 	}
 #else
 	unsigned long machid = gd->bd->bi_arch_number;
diff --git a/arch/arm/mach-rmobile/lowlevel_init_gen3.S b/arch/arm/mach-rmobile/lowlevel_init_gen3.S
index 88ff56e..11acce0 100644
--- a/arch/arm/mach-rmobile/lowlevel_init_gen3.S
+++ b/arch/arm/mach-rmobile/lowlevel_init_gen3.S
@@ -61,11 +61,18 @@  ENTRY(lowlevel_init)
 	/*
 	 * All slaves will enter EL2 and optionally EL1.
 	 */
+	adr	x3, lowlevel_in_el2
+	ldr	x4, =ES_TO_AARCH64
 	bl	armv8_switch_to_el2
+
+lowlevel_in_el2:
 #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
+	adr	x3, lowlevel_in_el1
+	ldr	x4, =ES_TO_AARCH64
 	bl	armv8_switch_to_el1
-#endif
 
+lowlevel_in_el1:
+#endif
 #endif /* CONFIG_ARMV8_MULTIENTRY */
 
 	bl      s_init
diff --git a/common/image-fit.c b/common/image-fit.c
index 9ce68f1..6ec5f8e 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -27,6 +27,7 @@  DECLARE_GLOBAL_DATA_PTR;
 #include <u-boot/md5.h>
 #include <u-boot/sha1.h>
 #include <u-boot/sha256.h>
+#include <generated/autoconf.h>
 
 /*****************************************************************************/
 /* New uImage format routines */
@@ -1161,11 +1162,18 @@  int fit_image_check_os(const void *fit, int noffset, uint8_t os)
 int fit_image_check_arch(const void *fit, int noffset, uint8_t arch)
 {
 	uint8_t image_arch;
+	int aarch32_support = 0;
+
+#ifdef CONFIG_ARM64_SUPPORT_AARCH32
+	aarch32_support = 1;
+#endif
 
 	if (fit_image_get_arch(fit, noffset, &image_arch))
 		return 0;
 	return (arch == image_arch) ||
-		(arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64);
+		(arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64) ||
+		(arch == IH_ARCH_ARM64 && image_arch == IH_ARCH_ARM &&
+		 aarch32_support);
 }
 
 /**
@@ -1617,6 +1625,9 @@  int fit_image_load(bootm_headers_t *images, ulong addr,
 	int type_ok, os_ok;
 	ulong load, data, len;
 	uint8_t os;
+#ifndef USE_HOSTCC
+	uint8_t os_arch;
+#endif
 	const char *prop_name;
 	int ret;
 
@@ -1700,6 +1711,12 @@  int fit_image_load(bootm_headers_t *images, ulong addr,
 		return -ENOEXEC;
 	}
 #endif
+
+#ifndef USE_HOSTCC
+	fit_image_get_arch(fit, noffset, &os_arch);
+	images->os.arch = os_arch;
+#endif
+
 	if (image_type == IH_TYPE_FLATDT &&
 	    !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
 		puts("FDT image is compressed");