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 notsure 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...
so I have some questions, please help to work with me to find the root cause.
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.linar... release.git/log/?h=latest-armlt-20161001
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.
Are you using some secure firmware on these boards? Indetail, 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.