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://community.arm.com/groups/arm-development-platforms
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://git.linaro.org/landing-teams/working/arm/kernel- 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. If it is running in EL2 or EL1, please add the attached patch to test again.
Thanks.
Regards, Ryan.
Best Regards,
Alison Wang
From: york sun Sent: Friday, November 04, 2016 10:04 AM To: ryan.harkin@linaro.org Cc: Wang Huan b18965@freescale.com; agraf@suse.de; Scott Wood scott.wood@nxp.com; Stuart Yoder stuart.yoder@nxp.com; Leo Li leoyang.li@nxp.com; fenghua@phytium.com.cn; monstr@monstr.eu; thomas.ab@samsung.com; mk7.kang@samsung.com; u-boot@lists.denx.de; Jason Jin jason.jin@nxp.com; Alison Wang alison.wang@nxp.com
Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
Alison,
Does Ryan have your 32-bit kernel image? I think kernel 32-bit
doesn't
support spin table. Please work with Ryan if your PSCI patch is required for the test.
York
-------- Original Message -------- From: Ryan Harkin ryan.harkin@linaro.org Sent: Thursday, November 3, 2016 12:17 PM To: york sun york.sun@nxp.com Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state CC: Alison Wang b18965@freescale.com,agraf@suse.de,Scott Wood scott.wood@nxp.com,Stuart Yoder stuart.yoder@nxp.com,Leo Li
leoyang.li@nxp.com,fenghua@phytium.com.cn,monstr@monstr.eu,thomas.ab
@samsung.com,mk7.kang@samsung.com,u-boot@lists.denx.de,Jason Jin jason.jin@nxp.com,Alison Wang alison.wang@nxp.com
Hi York/Alison,
Sorry for not having had time to look at this earlier.
On 26 October 2016 at 17:54, york sun york.sun@nxp.com wrote:
On 10/07/2016 11:56 PM, Alison Wang wrote:
To support loading a 32-bit OS, the execution state will change
from
AArch64 to AArch32 when jumping to kernel.
The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically.
Signed-off-by: Ebony Zhu ebony.zhu@nxp.com Signed-off-by: Alison Wang alison.wang@nxp.com Signed-off-by: Chenhui Zhao chenhui.zhao@nxp.com
Changes in v7:
- Move the call for armv8_switch_to_el2_m into this patch.
Reviewers,
May I have your comment please? I intend to merge this set when the merge window opens.
I've just tested these two patches on ARM's FVP Foundation and AEMv8 models and ARM's Juno board.
In all cases, with this patchset, the kernel fails to start. I see a continuous reboot, where the kernel starts then immediately resets:
Starting kernel ...
resetting ...
So I wouldn't want to see these patches merged.
Regards, Ryan.