On 11/04/2016 05:34 AM, Ryan Harkin wrote: > On 4 November 2016 at 09:20, Alison Wang <alison.w...@nxp.com> wrote: >>> On 4 November 2016 at 02:26, Alison Wang <alison.w...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
