On 4 November 2016 at 15:08, york sun <york....@nxp.com> wrote: > 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.
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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
