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

[Ryan Harkin]

On 4 November 2016 at 15:08, york sun <york.sun at nxp.com> wrote:
> 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.

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.