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

[york sun]

On 11/04/2016 05:34 AM, Ryan Harkin wrote:
> On 4 November 2016 at 09:20, Alison Wang <alison.wang at nxp.com> wrote:
>>> On 4 November 2016 at 02:26, Alison Wang <alison.wang at 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