[U-Boot] [PATCH v7 0/2] armv8: Support loading 32-bit OS in AArch32 execution state
This series is 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.
Spin-table method is used for secondary cores to load 32-bit OS. The architecture information will be got through checking FIT image and saved in the os_arch element of spin-table, then the secondary cores will check os_arch and jump to 32-bit OS or 64-bit OS automatically.
--------------------------------------- Changes in v7: - Move the call for armv8_switch_to_el2_m into the first patch.
Changes in v6: - Modified armv8_switch_to_el1(). It will always jump to ep when switching to AArch64 or AArch32 modes. - Make other platforms compatible with the new armv8_switch_to_el2() and armv8_switch_to_el1(). - Make secondary_switch_to_el1() always jump to ep when switching to AArch64 or AArch32 modes.
Changes in v5: - Modified armv8_switch_to_el2(). It will always jump to ep when switching to AArch64 or AArch32 modes. - Make secondary_switch_to_el2() always jump to ep when switching to AArch64 or AArch32 modes.
Changes in v4: - Correct config ARM64_SUPPORT_AARCH32. - Omit arch and ftaddr arguments. - Rename "xreg5" to "tmp". - Use xxx_RES1 to combine all RES1 fields in xxx register. - Use an immediate cmp directly. - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.
Changes in v3: - Comments the functions and the arguments. - Rename the real parameters. - Use the macros instead of the magic values. - Remove the redundant codes. - Clean up all of the mess in boot_jump_linux(). - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't support AArch32 state. - Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m.
Changes in v2: - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used to switch to AArch64 EL2 or AArch32 Hyp. - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used to switch to AArch64 EL1 or AArch32 SVC. - Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m.
---------------------------------------------------------------- Alison Wang (2): armv8: Support loading 32-bit OS in AArch32 execution state armv8: fsl-layerscape: SMP support for loading 32-bit OS
arch/arm/Kconfig | 6 +++ arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 61 +++++++++++++++++++++----- arch/arm/cpu/armv8/fsl-layerscape/mp.c | 10 +++++ arch/arm/cpu/armv8/start.S | 8 ++++ arch/arm/cpu/armv8/transition.S | 8 ++-- arch/arm/include/asm/arch-fsl-layerscape/mp.h | 6 +++ arch/arm/include/asm/macro.h | 176 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------- arch/arm/include/asm/system.h | 119 ++++++++++++++++++++++++++++++++++++++++++++++++++- arch/arm/lib/bootm.c | 45 ++++++++++++++++--- arch/arm/mach-rmobile/lowlevel_init_gen3.S | 9 +++- common/image-fit.c | 19 +++++++- 11 files changed, 401 insertions(+), 66 deletions(-)
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.
Changes in v6: - Modified armv8_switch_to_el1(). It will always jump to ep when switching to AArch64 or AArch32 modes. - Make other platforms compatible with the new armv8_switch_to_el2() and armv8_switch_to_el1().
Changes in v5: - Modified armv8_switch_to_el2(). It will always jump to ep when switching to AArch64 or AArch32 modes.
Changes in v4: - Correct config ARM64_SUPPORT_AARCH32. - Omit arch and ftaddr arguments. - Rename "xreg5" to "tmp". - Use xxx_RES1 to combine all RES1 fields in xxx register. - Use an immediate cmp directly. - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.
Changes in v3: - Comments the functions and the arguments. - Rename the real parameters. - Use the macros instead of the magic values. - Remove the redundant codes. - Clean up all of the mess in boot_jump_linux(). - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't support AArch32 state.
Changes in v2: - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used to switch to AArch64 EL2 or AArch32 Hyp. - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used to switch to AArch64 EL1 or AArch32 SVC.
arch/arm/Kconfig | 6 + arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 61 +++++++-- arch/arm/cpu/armv8/start.S | 8 ++ arch/arm/cpu/armv8/transition.S | 8 +- arch/arm/include/asm/arch-fsl-layerscape/mp.h | 4 + arch/arm/include/asm/macro.h | 176 +++++++++++++++++++------- arch/arm/include/asm/system.h | 119 ++++++++++++++++- arch/arm/lib/bootm.c | 39 +++++- arch/arm/mach-rmobile/lowlevel_init_gen3.S | 9 +- common/image-fit.c | 19 ++- 10 files changed, 383 insertions(+), 66 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e63309a..f122458 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -126,6 +126,12 @@ config ENABLE_ARM_SOC_BOOT0_HOOK ARM_SOC_BOOT0_HOOK which contains the required assembler preprocessor code.
+config ARM64_SUPPORT_AARCH32 + bool "ARM64 system support AArch32 execution state" + default y if ARM64 && !TARGET_THUNDERX_88XX + help + This ARM64 system supports AArch32 execution state. + choice prompt "Target select" default TARGET_HIKEY diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index 5af6b73..782a1ea 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -13,6 +13,7 @@ #ifdef CONFIG_MP #include <asm/arch/mp.h> #endif +#include <asm/u-boot.h>
ENTRY(lowlevel_init) mov x29, lr /* Save LR */ @@ -324,11 +325,6 @@ ENTRY(secondary_boot_func) gic_wait_for_interrupt_m x0, w1 #endif
- bl secondary_switch_to_el2 -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - bl secondary_switch_to_el1 -#endif - slave_cpu: wfe ldr x0, [x11] @@ -341,19 +337,64 @@ slave_cpu: tbz x1, #25, cpu_is_le rev x0, x0 /* BE to LE conversion */ cpu_is_le: - br x0 /* branch to the given address */ + ldr x5, [x11, #24] + ldr x6, =IH_ARCH_DEFAULT + cmp x6, x5 + b.eq 1f + +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 + adr x3, secondary_switch_to_el1 + ldr x4, =ES_TO_AARCH64 +#else + ldr x3, [x11] + ldr x4, =ES_TO_AARCH32 +#endif + bl secondary_switch_to_el2 + +1: +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 + adr x3, secondary_switch_to_el1 +#else + ldr x3, [x11] +#endif + ldr x4, =ES_TO_AARCH64 + bl secondary_switch_to_el2 + ENDPROC(secondary_boot_func)
ENTRY(secondary_switch_to_el2) - switch_el x0, 1f, 0f, 0f + switch_el x5, 1f, 0f, 0f 0: ret -1: armv8_switch_to_el2_m x0 +1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(secondary_switch_to_el2)
ENTRY(secondary_switch_to_el1) - switch_el x0, 0f, 1f, 0f + mrs x0, mpidr_el1 + ubfm x1, x0, #8, #15 + ubfm x2, x0, #0, #1 + orr x10, x2, x1, lsl #2 /* x10 has LPID */ + + lsl x1, x10, #6 + ldr x0, =__spin_table + /* physical address of this cpus spin table element */ + add x11, x1, x0 + + ldr x3, [x11] + + ldr x5, [x11, #24] + ldr x6, =IH_ARCH_DEFAULT + cmp x6, x5 + b.eq 2f + + ldr x4, =ES_TO_AARCH32 + bl switch_to_el1 + +2: ldr x4, =ES_TO_AARCH64 + +switch_to_el1: + switch_el x5, 0f, 1f, 0f 0: ret -1: armv8_switch_to_el1_m x0, x1 +1: armv8_switch_to_el1_m x3, x4, x5 ENDPROC(secondary_switch_to_el1)
/* Ensure that the literals used by the secondary boot code are diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 19c771d..4f5f6d8 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -251,9 +251,17 @@ WEAK(lowlevel_init) /* * All slaves will enter EL2 and optionally EL1. */ + adr x3, lowlevel_in_el2 + ldr x4, =ES_TO_AARCH64 bl armv8_switch_to_el2 + +lowlevel_in_el2: #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 + adr x3, lowlevel_in_el1 + ldr x4, =ES_TO_AARCH64 bl armv8_switch_to_el1 + +lowlevel_in_el1: #endif
#endif /* CONFIG_ARMV8_MULTIENTRY */ diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S index 253a39b..115b6e9 100644 --- a/arch/arm/cpu/armv8/transition.S +++ b/arch/arm/cpu/armv8/transition.S @@ -11,13 +11,13 @@ #include <asm/macro.h>
ENTRY(armv8_switch_to_el2) - switch_el x0, 1f, 0f, 0f + switch_el x5, 1f, 0f, 0f 0: ret -1: armv8_switch_to_el2_m x0 +1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(armv8_switch_to_el2)
ENTRY(armv8_switch_to_el1) - switch_el x0, 0f, 1f, 0f + switch_el x5, 0f, 1f, 0f 0: ret -1: armv8_switch_to_el1_m x0, x1 +1: armv8_switch_to_el1_m x3, x4, x5 ENDPROC(armv8_switch_to_el1) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h b/arch/arm/include/asm/arch-fsl-layerscape/mp.h index e46e076..14d9fcf 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h @@ -35,4 +35,8 @@ phys_addr_t determine_mp_bootpg(void); void secondary_boot_func(void); int is_core_online(u64 cpu_id); #endif + +#define IH_ARCH_ARM 2 /* ARM */ +#define IH_ARCH_ARM64 22 /* ARM64 */ + #endif /* _FSL_LAYERSCAPE_MP_H */ diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 9bb0efa..2553e3e 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -8,6 +8,11 @@
#ifndef __ASM_ARM_MACRO_H__ #define __ASM_ARM_MACRO_H__ + +#ifdef CONFIG_ARM64 +#include <asm/system.h> +#endif + #ifdef __ASSEMBLY__
/* @@ -135,13 +140,21 @@ lr .req x30 #endif .endm
-.macro armv8_switch_to_el2_m, xreg1 - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */ - mov \xreg1, #0x5b1 - msr scr_el3, \xreg1 +/* + * Switch from EL3 to EL2 for ARMv8 + * @ep: kernel entry point + * @flag: The execution state flag for lower exception + * level, ES_TO_AARCH64 or ES_TO_AARCH32 + * @tmp: temporary register + * + * For loading 32-bit OS, x1 is machine nr and x2 is ftaddr. + * For loading 64-bit OS, x0 is physical address to the FDT blob. + * They will be passed to the guest. + */ +.macro armv8_switch_to_el2_m, ep, flag, tmp msr cptr_el3, xzr /* Disable coprocessor traps to EL3 */ - mov \xreg1, #0x33ff - msr cptr_el2, \xreg1 /* Disable coprocessor traps to EL2 */ + mov \tmp, #CPTR_EL2_RES1 + msr cptr_el2, \tmp /* Disable coprocessor traps to EL2 */
/* Initialize Generic Timers */ msr cntvoff_el2, xzr @@ -152,45 +165,90 @@ lr .req x30 * and RES0 bits (31,30,27,26,24,21,20,17,15-13,10-6) + * EE,WXN,I,SA,C,A,M to 0 */ - mov \xreg1, #0x0830 - movk \xreg1, #0x30C5, lsl #16 - msr sctlr_el2, \xreg1 + ldr \tmp, =(SCTLR_EL2_RES1 | SCTLR_EL2_EE_LE |\ + SCTLR_EL2_WXN_DIS | SCTLR_EL2_ICACHE_DIS |\ + SCTLR_EL2_SA_DIS | SCTLR_EL2_DCACHE_DIS |\ + SCTLR_EL2_ALIGN_DIS | SCTLR_EL2_MMU_DIS) + msr sctlr_el2, \tmp + + mov \tmp, sp + msr sp_el2, \tmp /* Migrate SP */ + mrs \tmp, vbar_el3 + msr vbar_el2, \tmp /* Migrate VBAR */ + + /* Check switch to AArch64 EL2 or AArch32 Hypervisor mode */ + cmp \flag, #ES_TO_AARCH32 + b.eq 1f + + /* + * The next lower exception level is AArch64, 64bit EL2 | HCE | + * SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1. + */ + ldr \tmp, =(SCR_EL3_RW_AARCH64 | SCR_EL3_HCE_EN |\ + SCR_EL3_SMD_DIS | SCR_EL3_RES1 |\ + SCR_EL3_NS_EN) + msr scr_el3, \tmp
/* Return to the EL2_SP2 mode from EL3 */ - mov \xreg1, sp - msr sp_el2, \xreg1 /* Migrate SP */ - mrs \xreg1, vbar_el3 - msr vbar_el2, \xreg1 /* Migrate VBAR */ - mov \xreg1, #0x3c9 - msr spsr_el3, \xreg1 /* EL2_SP2 | D | A | I | F */ - msr elr_el3, lr + ldr \tmp, =(SPSR_EL_DEBUG_MASK | SPSR_EL_SERR_MASK |\ + SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\ + SPSR_EL_M_AARCH64 | SPSR_EL_M_EL2H) + msr spsr_el3, \tmp + msr elr_el3, \ep + eret + +1: + /* + * The next lower exception level is AArch32, 32bit EL2 | HCE | + * SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1. + */ + ldr \tmp, =(SCR_EL3_RW_AARCH32 | SCR_EL3_HCE_EN |\ + SCR_EL3_SMD_DIS | SCR_EL3_RES1 |\ + SCR_EL3_NS_EN) + msr scr_el3, \tmp + + /* Return to AArch32 Hypervisor mode */ + ldr \tmp, =(SPSR_EL_END_LE | SPSR_EL_ASYN_MASK |\ + SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\ + SPSR_EL_T_A32 | SPSR_EL_M_AARCH32 |\ + SPSR_EL_M_HYP) + msr spsr_el3, \tmp + msr elr_el3, \ep eret .endm
-.macro armv8_switch_to_el1_m, xreg1, xreg2 +/* + * Switch from EL2 to EL1 for ARMv8 + * @ep: kernel entry point + * @flag: The execution state flag for lower exception + * level, ES_TO_AARCH64 or ES_TO_AARCH32 + * @tmp: temporary register + * + * For loading 32-bit OS, x1 is machine nr and x2 is ftaddr. + * For loading 64-bit OS, x0 is physical address to the FDT blob. + * They will be passed to the guest. + */ +.macro armv8_switch_to_el1_m, ep, flag, tmp /* Initialize Generic Timers */ - mrs \xreg1, cnthctl_el2 - orr \xreg1, \xreg1, #0x3 /* Enable EL1 access to timers */ - msr cnthctl_el2, \xreg1 + mrs \tmp, cnthctl_el2 + /* Enable EL1 access to timers */ + orr \tmp, \tmp, #(CNTHCTL_EL2_EL1PCEN_EN |\ + CNTHCTL_EL2_EL1PCTEN_EN) + msr cnthctl_el2, \tmp msr cntvoff_el2, xzr
/* Initilize MPID/MPIDR registers */ - mrs \xreg1, midr_el1 - mrs \xreg2, mpidr_el1 - msr vpidr_el2, \xreg1 - msr vmpidr_el2, \xreg2 + mrs \tmp, midr_el1 + msr vpidr_el2, \tmp + mrs \tmp, mpidr_el1 + msr vmpidr_el2, \tmp
/* Disable coprocessor traps */ - mov \xreg1, #0x33ff - msr cptr_el2, \xreg1 /* Disable coprocessor traps to EL2 */ + mov \tmp, #CPTR_EL2_RES1 + msr cptr_el2, \tmp /* Disable coprocessor traps to EL2 */ msr hstr_el2, xzr /* Disable coprocessor traps to EL2 */ - mov \xreg1, #3 << 20 - msr cpacr_el1, \xreg1 /* Enable FP/SIMD at EL1 */ - - /* Initialize HCR_EL2 */ - mov \xreg1, #(1 << 31) /* 64bit EL1 */ - orr \xreg1, \xreg1, #(1 << 29) /* Disable HVC */ - msr hcr_el2, \xreg1 + mov \tmp, #CPACR_EL1_FPEN_EN + msr cpacr_el1, \tmp /* Enable FP/SIMD at EL1 */
/* SCTLR_EL1 initialization * @@ -199,18 +257,50 @@ lr .req x30 * UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD, * CP15BEN,SA0,SA,C,A,M to 0 */ - mov \xreg1, #0x0800 - movk \xreg1, #0x30d0, lsl #16 - msr sctlr_el1, \xreg1 + ldr \tmp, =(SCTLR_EL1_RES1 | SCTLR_EL1_UCI_DIS |\ + SCTLR_EL1_EE_LE | SCTLR_EL1_WXN_DIS |\ + SCTLR_EL1_NTWE_DIS | SCTLR_EL1_NTWI_DIS |\ + SCTLR_EL1_UCT_DIS | SCTLR_EL1_DZE_DIS |\ + SCTLR_EL1_ICACHE_DIS | SCTLR_EL1_UMA_DIS |\ + SCTLR_EL1_SED_EN | SCTLR_EL1_ITD_EN |\ + SCTLR_EL1_CP15BEN_DIS | SCTLR_EL1_SA0_DIS |\ + SCTLR_EL1_SA_DIS | SCTLR_EL1_DCACHE_DIS |\ + SCTLR_EL1_ALIGN_DIS | SCTLR_EL1_MMU_DIS) + msr sctlr_el1, \tmp + + mov \tmp, sp + msr sp_el1, \tmp /* Migrate SP */ + mrs \tmp, vbar_el2 + msr vbar_el1, \tmp /* Migrate VBAR */ + + /* Check switch to AArch64 EL1 or AArch32 Supervisor mode */ + cmp \flag, #ES_TO_AARCH32 + b.eq 1f + + /* Initialize HCR_EL2 */ + ldr \tmp, =(HCR_EL2_RW_AARCH64 | HCR_EL2_HCD_DIS) + msr hcr_el2, \tmp
/* Return to the EL1_SP1 mode from EL2 */ - mov \xreg1, sp - msr sp_el1, \xreg1 /* Migrate SP */ - mrs \xreg1, vbar_el2 - msr vbar_el1, \xreg1 /* Migrate VBAR */ - mov \xreg1, #0x3c5 - msr spsr_el2, \xreg1 /* EL1_SP1 | D | A | I | F */ - msr elr_el2, lr + ldr \tmp, =(SPSR_EL_DEBUG_MASK | SPSR_EL_SERR_MASK |\ + SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\ + SPSR_EL_M_AARCH64 | SPSR_EL_M_EL1H) + msr spsr_el2, \tmp + msr elr_el2, \ep + eret + +1: + /* Initialize HCR_EL2 */ + ldr \tmp, =(HCR_EL2_RW_AARCH32 | HCR_EL2_HCD_DIS) + msr hcr_el2, \tmp + + /* Return to AArch32 Supervisor mode from EL2 */ + ldr \tmp, =(SPSR_EL_END_LE | SPSR_EL_ASYN_MASK |\ + SPSR_EL_IRQ_MASK | SPSR_EL_FIQ_MASK |\ + SPSR_EL_T_A32 | SPSR_EL_M_AARCH32 |\ + SPSR_EL_M_SVC) + msr spsr_el2, \tmp + msr elr_el2, \ep eret .endm
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h index 7b7b867..06a6624 100644 --- a/arch/arm/include/asm/system.h +++ b/arch/arm/include/asm/system.h @@ -18,6 +18,95 @@ #define CR_WXN (1 << 19) /* Write Permision Imply XN */ #define CR_EE (1 << 25) /* Exception (Big) Endian */
+#define ES_TO_AARCH64 1 +#define ES_TO_AARCH32 0 + +/* + * SCR_EL3 bits definitions + */ +#define SCR_EL3_RW_AARCH64 (1 << 10) /* Next lower level is AArch64 */ +#define SCR_EL3_RW_AARCH32 (0 << 10) /* Lower lowers level are AArch32 */ +#define SCR_EL3_HCE_EN (1 << 8) /* Hypervisor Call enable */ +#define SCR_EL3_SMD_DIS (1 << 7) /* Secure Monitor Call disable */ +#define SCR_EL3_RES1 (3 << 4) /* Reserved, RES1 */ +#define SCR_EL3_NS_EN (1 << 0) /* EL0 and EL1 in Non-scure state */ + +/* + * SPSR_EL3/SPSR_EL2 bits definitions + */ +#define SPSR_EL_END_LE (0 << 9) /* Exception Little-endian */ +#define SPSR_EL_DEBUG_MASK (1 << 9) /* Debug exception masked */ +#define SPSR_EL_ASYN_MASK (1 << 8) /* Asynchronous data abort masked */ +#define SPSR_EL_SERR_MASK (1 << 8) /* System Error exception masked */ +#define SPSR_EL_IRQ_MASK (1 << 7) /* IRQ exception masked */ +#define SPSR_EL_FIQ_MASK (1 << 6) /* FIQ exception masked */ +#define SPSR_EL_T_A32 (0 << 5) /* AArch32 instruction set A32 */ +#define SPSR_EL_M_AARCH64 (0 << 4) /* Exception taken from AArch64 */ +#define SPSR_EL_M_AARCH32 (1 << 4) /* Exception taken from AArch32 */ +#define SPSR_EL_M_SVC (0x3) /* Exception taken from SVC mode */ +#define SPSR_EL_M_HYP (0xa) /* Exception taken from HYP mode */ +#define SPSR_EL_M_EL1H (5) /* Exception taken from EL1h mode */ +#define SPSR_EL_M_EL2H (9) /* Exception taken from EL2h mode */ + +/* + * CPTR_EL2 bits definitions + */ +#define CPTR_EL2_RES1 (3 << 12 | 0x3ff) /* Reserved, RES1 */ + +/* + * SCTLR_EL2 bits definitions + */ +#define SCTLR_EL2_RES1 (3 << 28 | 3 << 22 | 1 << 18 | 1 << 16 |\ + 1 << 11 | 3 << 4) /* Reserved, RES1 */ +#define SCTLR_EL2_EE_LE (0 << 25) /* Exception Little-endian */ +#define SCTLR_EL2_WXN_DIS (0 << 19) /* Write permission is not XN */ +#define SCTLR_EL2_ICACHE_DIS (0 << 12) /* Instruction cache disabled */ +#define SCTLR_EL2_SA_DIS (0 << 3) /* Stack Alignment Check disabled */ +#define SCTLR_EL2_DCACHE_DIS (0 << 2) /* Data cache disabled */ +#define SCTLR_EL2_ALIGN_DIS (0 << 1) /* Alignment check disabled */ +#define SCTLR_EL2_MMU_DIS (0) /* MMU disabled */ + +/* + * CNTHCTL_EL2 bits definitions + */ +#define CNTHCTL_EL2_EL1PCEN_EN (1 << 1) /* Physical timer regs accessible */ +#define CNTHCTL_EL2_EL1PCTEN_EN (1 << 0) /* Physical counter accessible */ + +/* + * HCR_EL2 bits definitions + */ +#define HCR_EL2_RW_AARCH64 (1 << 31) /* EL1 is AArch64 */ +#define HCR_EL2_RW_AARCH32 (0 << 31) /* Lower levels are AArch32 */ +#define HCR_EL2_HCD_DIS (1 << 29) /* Hypervisor Call disabled */ + +/* + * CPACR_EL1 bits definitions + */ +#define CPACR_EL1_FPEN_EN (3 << 20) /* SIMD and FP instruction enabled */ + +/* + * SCTLR_EL1 bits definitions + */ +#define SCTLR_EL1_RES1 (3 << 28 | 3 << 22 | 1 << 20 |\ + 1 << 11) /* Reserved, RES1 */ +#define SCTLR_EL1_UCI_DIS (0 << 26) /* Cache instruction disabled */ +#define SCTLR_EL1_EE_LE (0 << 25) /* Exception Little-endian */ +#define SCTLR_EL1_WXN_DIS (0 << 19) /* Write permission is not XN */ +#define SCTLR_EL1_NTWE_DIS (0 << 18) /* WFE instruction disabled */ +#define SCTLR_EL1_NTWI_DIS (0 << 16) /* WFI instruction disabled */ +#define SCTLR_EL1_UCT_DIS (0 << 15) /* CTR_EL0 access disabled */ +#define SCTLR_EL1_DZE_DIS (0 << 14) /* DC ZVA instruction disabled */ +#define SCTLR_EL1_ICACHE_DIS (0 << 12) /* Instruction cache disabled */ +#define SCTLR_EL1_UMA_DIS (0 << 9) /* User Mask Access disabled */ +#define SCTLR_EL1_SED_EN (0 << 8) /* SETEND instruction enabled */ +#define SCTLR_EL1_ITD_EN (0 << 7) /* IT instruction enabled */ +#define SCTLR_EL1_CP15BEN_DIS (0 << 5) /* CP15 barrier operation disabled */ +#define SCTLR_EL1_SA0_DIS (0 << 4) /* Stack Alignment EL0 disabled */ +#define SCTLR_EL1_SA_DIS (0 << 3) /* Stack Alignment EL1 disabled */ +#define SCTLR_EL1_DCACHE_DIS (0 << 2) /* Data cache disabled */ +#define SCTLR_EL1_ALIGN_DIS (0 << 1) /* Alignment check disabled */ +#define SCTLR_EL1_MMU_DIS (0) /* MMU disabled */ + #ifndef __ASSEMBLY__
u64 get_page_table_size(void); @@ -96,8 +185,34 @@ void __asm_invalidate_icache_all(void); int __asm_flush_l3_cache(void); void __asm_switch_ttbr(u64 new_ttbr);
-void armv8_switch_to_el2(void); -void armv8_switch_to_el1(void); +/* + * Switch from EL3 to EL2 for ARMv8 + * + * @args: For loading 64-bit OS, fdt address. + * For loading 32-bit OS, zero. + * @mach_nr: For loading 64-bit OS, zero. + * For loading 32-bit OS, machine nr + * @fdt_addr: For loading 64-bit OS, zero. + * For loading 32-bit OS, fdt address. + * @entry_point: kernel entry point + * @es_flag: execution state flag, ES_TO_AARCH64 or ES_TO_AARCH32 + */ +void armv8_switch_to_el2(u64 args, u64 mach_nr, u64 fdt_addr, + u64 entry_point, u64 es_flag); +/* + * Switch from EL2 to EL1 for ARMv8 + * + * @args: For loading 64-bit OS, fdt address. + * For loading 32-bit OS, zero. + * @mach_nr: For loading 64-bit OS, zero. + * For loading 32-bit OS, machine nr + * @fdt_addr: For loading 64-bit OS, zero. + * For loading 32-bit OS, fdt address. + * @entry_point: kernel entry point + * @es_flag: execution state flag, ES_TO_AARCH64 or ES_TO_AARCH32 + */ +void armv8_switch_to_el1(u64 args, u64 mach_nr, u64 fdt_addr, + u64 entry_point, u64 es_flag); void gic_init(void); void gic_send_sgi(unsigned long sgino); void wait_for_wakeup(void); diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 53c3141..7015573 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -193,10 +193,6 @@ static void do_nonsec_virt_switch(void) { smp_kick_all_cpus(); dcache_disable(); /* flush cache before swtiching to EL2 */ - armv8_switch_to_el2(); -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - armv8_switch_to_el1(); -#endif } #endif
@@ -273,6 +269,24 @@ bool armv7_boot_nonsec(void) } #endif
+#ifdef CONFIG_ARM64 +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 +static void switch_to_el1(void) +{ + if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && + (images.os.arch == IH_ARCH_ARM)) + armv8_switch_to_el1(0, (u64)gd->bd->bi_arch_number, + (u64)images.ft_addr, + (u64)images.ep, + ES_TO_AARCH32); + else + armv8_switch_to_el1((u64)images.ft_addr, 0, 0, + images.ep, + ES_TO_AARCH64); +} +#endif +#endif + /* Subcommand: GO */ static void boot_jump_linux(bootm_headers_t *images, int flag) { @@ -292,7 +306,22 @@ static void boot_jump_linux(bootm_headers_t *images, int flag)
if (!fake) { do_nonsec_virt_switch(); - kernel_entry(images->ft_addr, NULL, NULL, NULL); + +#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 + armv8_switch_to_el2((u64)images->ft_addr, 0, 0, + (u64)switch_to_el1, ES_TO_AARCH64); +#else + if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && + (images->os.arch == IH_ARCH_ARM)) + armv8_switch_to_el2(0, (u64)gd->bd->bi_arch_number, + (u64)images->ft_addr, + (u64)images->ep, + ES_TO_AARCH32); + else + armv8_switch_to_el2((u64)images->ft_addr, 0, 0, + images->ep, + ES_TO_AARCH64); +#endif } #else unsigned long machid = gd->bd->bi_arch_number; diff --git a/arch/arm/mach-rmobile/lowlevel_init_gen3.S b/arch/arm/mach-rmobile/lowlevel_init_gen3.S index 88ff56e..11acce0 100644 --- a/arch/arm/mach-rmobile/lowlevel_init_gen3.S +++ b/arch/arm/mach-rmobile/lowlevel_init_gen3.S @@ -61,11 +61,18 @@ ENTRY(lowlevel_init) /* * All slaves will enter EL2 and optionally EL1. */ + adr x3, lowlevel_in_el2 + ldr x4, =ES_TO_AARCH64 bl armv8_switch_to_el2 + +lowlevel_in_el2: #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 + adr x3, lowlevel_in_el1 + ldr x4, =ES_TO_AARCH64 bl armv8_switch_to_el1 -#endif
+lowlevel_in_el1: +#endif #endif /* CONFIG_ARMV8_MULTIENTRY */
bl s_init diff --git a/common/image-fit.c b/common/image-fit.c index 9ce68f1..6ec5f8e 100644 --- a/common/image-fit.c +++ b/common/image-fit.c @@ -27,6 +27,7 @@ DECLARE_GLOBAL_DATA_PTR; #include <u-boot/md5.h> #include <u-boot/sha1.h> #include <u-boot/sha256.h> +#include <generated/autoconf.h>
/*****************************************************************************/ /* New uImage format routines */ @@ -1161,11 +1162,18 @@ int fit_image_check_os(const void *fit, int noffset, uint8_t os) int fit_image_check_arch(const void *fit, int noffset, uint8_t arch) { uint8_t image_arch; + int aarch32_support = 0; + +#ifdef CONFIG_ARM64_SUPPORT_AARCH32 + aarch32_support = 1; +#endif
if (fit_image_get_arch(fit, noffset, &image_arch)) return 0; return (arch == image_arch) || - (arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64); + (arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64) || + (arch == IH_ARCH_ARM64 && image_arch == IH_ARCH_ARM && + aarch32_support); }
/** @@ -1617,6 +1625,9 @@ int fit_image_load(bootm_headers_t *images, ulong addr, int type_ok, os_ok; ulong load, data, len; uint8_t os; +#ifndef USE_HOSTCC + uint8_t os_arch; +#endif const char *prop_name; int ret;
@@ -1700,6 +1711,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr, return -ENOEXEC; } #endif + +#ifndef USE_HOSTCC + fit_image_get_arch(fit, noffset, &os_arch); + images->os.arch = os_arch; +#endif + if (image_type == IH_TYPE_FLATDT && !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) { puts("FDT image is compressed");
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.
York
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.
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.
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, 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?
2. Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
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.
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.orgmailto:ryan.harkin@linaro.org> Sent: Thursday, November 3, 2016 12:17 PM To: york sun <york.sun@nxp.commailto: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.commailto:b18965@freescale.com>,agraf@suse.de,Scott Wood <scott.wood@nxp.commailto:scott.wood@nxp.com>,Stuart Yoder <stuart.yoder@nxp.commailto:stuart.yoder@nxp.com>,Leo Li <leoyang.li@nxp.commailto: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.commailto:jason.jin@nxp.com>,Alison Wang <alison.wang@nxp.commailto: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.commailto: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.commailto:ebony.zhu@nxp.com> Signed-off-by: Alison Wang <alison.wang@nxp.commailto:alison.wang@nxp.com> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.commailto: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.
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 not sure heis 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=l...
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? In detail, Iwant 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.
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.
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.
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://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.
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.
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.
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. It gets EL2 working after the 2nd set. If there is room to clarify in the commit message, please kindly suggest.
York
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.
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
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.
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set, does something break? My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
York
On 04/11/2016 16:43, york sun wrote:
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
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.
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set, does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in EL2 breaks according to Ryan.
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
That's his point :). And I concur.
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
Alex
On 4 November 2016 at 15:53, Alexander Graf agraf@suse.de wrote:
On 04/11/2016 16:43, york sun wrote:
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
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.
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set, does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in EL2 breaks according to Ryan.
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
That's his point :). And I concur.
Correct. Thanks Alex for clarifying what I'm trying to say :)
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
On 11/04/2016 09:53 AM, Alexander Graf wrote:
On 04/11/2016 16:43, york sun wrote:
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
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.
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set, does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in EL2 breaks according to Ryan.
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
That's his point :). And I concur.
Thanks for the confirmation.
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
If you are referring the trusted firmware, we are following that direction. Just not fully up yet on some platform.
It is definitely not our intention to be cumbersome. Please point out where it went sideway beside the trusted firmware.
York
On 04/11/2016 17:08, york sun wrote:
On 11/04/2016 09:53 AM, Alexander Graf wrote:
On 04/11/2016 16:43, york sun wrote:
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
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.
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set, does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in EL2 breaks according to Ryan.
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
That's his point :). And I concur.
Thanks for the confirmation.
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
If you are referring the trusted firmware, we are following that direction. Just not fully up yet on some platform.
It is definitely not our intention to be cumbersome. Please point out where it went sideway beside the trusted firmware.
Basically it boils down to the fact that you are the only platform that runs U-Boot in EL3 :).
If you want to keep the memory initialization inside of U-Boot, I think that's great. But you could either split that into SPL/EL2 or degrade yourself into EL2 as soon as possible by calling into an EL3 firmware. Whether you build that firmware as part of U-Boot (the stock one could be very trivial) or externally is not really too much of a problem.
Things like Alison's patches could then do a simple PSCI call into said EL3 firmware to call into 32bit code in EL2 for example.
Alex
On 11/04/2016 10:12 AM, Alexander Graf wrote:
On 04/11/2016 17:08, york sun wrote:
On 11/04/2016 09:53 AM, Alexander Graf wrote:
On 04/11/2016 16:43, york sun wrote:
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
> > 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.
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set, does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in EL2 breaks according to Ryan.
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
That's his point :). And I concur.
Thanks for the confirmation.
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
If you are referring the trusted firmware, we are following that direction. Just not fully up yet on some platform.
It is definitely not our intention to be cumbersome. Please point out where it went sideway beside the trusted firmware.
Basically it boils down to the fact that you are the only platform that runs U-Boot in EL3 :).
If you want to keep the memory initialization inside of U-Boot, I think that's great. But you could either split that into SPL/EL2 or degrade yourself into EL2 as soon as possible by calling into an EL3 firmware. Whether you build that firmware as part of U-Boot (the stock one could be very trivial) or externally is not really too much of a problem.
Things like Alison's patches could then do a simple PSCI call into said EL3 firmware to call into 32bit code in EL2 for example.
Basically I agree with you. U-Boot will run at EL2 as soon as we have the trusted firmware in place.
York
On 11/04/2016 10:12 AM, Alexander Graf wrote:
On 04/11/2016 17:08, york sun wrote:
On 11/04/2016 09:53 AM, Alexander Graf wrote:
On 04/11/2016 16:43, york sun wrote:
On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>> >> 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.
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set,
does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in
EL2
breaks according to Ryan.
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
That's his point :). And I concur.
Thanks for the confirmation.
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
If you are referring the trusted firmware, we are following that direction. Just not fully up yet on some platform.
It is definitely not our intention to be cumbersome. Please point
out
where it went sideway beside the trusted firmware.
Basically it boils down to the fact that you are the only platform that runs U-Boot in EL3 :).
If you want to keep the memory initialization inside of U-Boot, I think that's great. But you could either split that into SPL/EL2 or degrade yourself into EL2 as soon as possible by calling into an EL3
firmware.
Whether you build that firmware as part of U-Boot (the stock one
could
be very trivial) or externally is not really too much of a problem.
Things like Alison's patches could then do a simple PSCI call into said EL3 firmware to call into 32bit code in EL2 for example.
Basically I agree with you. U-Boot will run at EL2 as soon as we have the trusted firmware in place.
[Alison Wang] Thanks for all your comments.
For the issue about the tree would not be bisect-able, I have a solution. Actually it is the root cause that 64-bit kernel could not boot up when U-Boot is running in EL2. I will move these codes from the third patch to the first patch.
ENTRY(armv8_switch_to_el2) switch_el x5, 1f, 0f, 0f -0: ret + /* + * x3 is kernel entry point or switch_to_el1 + * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined. + * When running in EL2 now, jump to the + * address saved in x3. + */ +0: br x3 1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(armv8_switch_to_el2)
ENTRY(armv8_switch_to_el1) switch_el x5, 0f, 1f, 0f -0: ret + + /* + * x3 is kernel entry point. When running in EL1 + * now, jump to the address saved in x3. + */ +0: br x3 1: armv8_switch_to_el1_m x3, x4, x5 ENDPROC(armv8_switch_to_el1)
With this re-order, the bitsect issue will be fixed and there is not a point that kernel could not boot up.
If you all agree with this re-order, I will send out the v8 patch includes the first, second and third patches.
Best Regards, Alison Wang
Hi Alison,
On 7 November 2016 at 02:21, Alison Wang alison.wang@nxp.com wrote:
On 11/04/2016 10:12 AM, Alexander Graf wrote:
On 04/11/2016 17:08, york sun wrote:
On 11/04/2016 09:53 AM, Alexander Graf wrote:
On 04/11/2016 16:43, york sun wrote:
On 11/04/2016 09:32 AM, Ryan Harkin wrote: >>> >>> 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. >
Ryan,
Thanks for sharing your concern. I support git-bisect. It is valuable, no doubt. Let me try to understand the issue here. Without Alison's patches, everything boots OK. With her first set,
does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in
EL2
breaks according to Ryan.
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, then she needs to fix it.
That's his point :). And I concur.
Thanks for the confirmation.
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
If you are referring the trusted firmware, we are following that direction. Just not fully up yet on some platform.
It is definitely not our intention to be cumbersome. Please point
out
where it went sideway beside the trusted firmware.
Basically it boils down to the fact that you are the only platform that runs U-Boot in EL3 :).
If you want to keep the memory initialization inside of U-Boot, I think that's great. But you could either split that into SPL/EL2 or degrade yourself into EL2 as soon as possible by calling into an EL3
firmware.
Whether you build that firmware as part of U-Boot (the stock one
could
be very trivial) or externally is not really too much of a problem.
Things like Alison's patches could then do a simple PSCI call into said EL3 firmware to call into 32bit code in EL2 for example.
Basically I agree with you. U-Boot will run at EL2 as soon as we have the trusted firmware in place.
[Alison Wang] Thanks for all your comments.
For the issue about the tree would not be bisect-able, I have a solution. Actually it is the root cause that 64-bit kernel could not boot up when U-Boot is running in EL2. I will move these codes from the third patch to the first patch.
ENTRY(armv8_switch_to_el2) switch_el x5, 1f, 0f, 0f -0: ret
/** x3 is kernel entry point or switch_to_el1* if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.* When running in EL2 now, jump to the* address saved in x3.*/+0: br x3 1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(armv8_switch_to_el2)
ENTRY(armv8_switch_to_el1) switch_el x5, 0f, 1f, 0f -0: ret
/** x3 is kernel entry point. When running in EL1* now, jump to the address saved in x3.*/+0: br x3 1: armv8_switch_to_el1_m x3, x4, x5 ENDPROC(armv8_switch_to_el1)
With this re-order, the bitsect issue will be fixed and there is not a point that kernel could not boot up.
That sounds perfect.
If you all agree with this re-order, I will send out the v8 patch includes the first, second and third patches.
I haven't tried to understand this code, so I can't say if that order will work or not, but I'm very happy to test it if you produce a series like this.
Regards, Ryan.
Best Regards, Alison Wang
On 7 November 2016 at 02:21, Alison Wang alison.wang@nxp.com wrote:
On 11/04/2016 10:12 AM, Alexander Graf wrote:
On 04/11/2016 17:08, york sun wrote:
On 11/04/2016 09:53 AM, Alexander Graf wrote:
On 04/11/2016 16:43, york sun wrote: > On 11/04/2016 09:32 AM, Ryan Harkin wrote: >>>> >>>> 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. >> > > Ryan, > > Thanks for sharing your concern. I support git-bisect. It is > valuable, no doubt. Let me try to understand the issue here. > Without Alison's patches, everything boots OK. With her first > set,
does something break?
Yes, with the patches booting 64bit Linux with U-Boot running in
EL2
breaks according to Ryan.
> My understanding is 32-bit OS can boot. If existing 64-bit OS > fails, then she needs to fix it.
That's his point :). And I concur.
Thanks for the confirmation.
(btw, you guys really should start thinking about following the ARM recommended boot model. It's pretty cumbersome to do everything different just for NXP)
If you are referring the trusted firmware, we are following that direction. Just not fully up yet on some platform.
It is definitely not our intention to be cumbersome. Please point
out
where it went sideway beside the trusted firmware.
Basically it boils down to the fact that you are the only platform that runs U-Boot in EL3 :).
If you want to keep the memory initialization inside of U-Boot, I think that's great. But you could either split that into SPL/EL2
or
degrade yourself into EL2 as soon as possible by calling into an EL3
firmware.
Whether you build that firmware as part of U-Boot (the stock one
could
be very trivial) or externally is not really too much of a problem.
Things like Alison's patches could then do a simple PSCI call into said EL3 firmware to call into 32bit code in EL2 for example.
Basically I agree with you. U-Boot will run at EL2 as soon as we
have
the trusted firmware in place.
[Alison Wang] Thanks for all your comments.
For the issue about the tree would not be bisect-able, I have a solution. Actually it is the root cause that 64-bit kernel could not boot up when U-Boot is running in EL2. I will move these codes from the third patch to the first patch.
ENTRY(armv8_switch_to_el2) switch_el x5, 1f, 0f, 0f -0: ret
/** x3 is kernel entry point or switch_to_el1* if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.* When running in EL2 now, jump to the* address saved in x3.*/+0: br x3 1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(armv8_switch_to_el2)
ENTRY(armv8_switch_to_el1) switch_el x5, 0f, 1f, 0f -0: ret
/** x3 is kernel entry point. When running in EL1* now, jump to the address saved in x3.*/+0: br x3 1: armv8_switch_to_el1_m x3, x4, x5 ENDPROC(armv8_switch_to_el1)
With this re-order, the bitsect issue will be fixed and there is not
a
point that kernel could not boot up.
That sounds perfect.
If you all agree with this re-order, I will send out the v8 patch includes the first, second and third patches.
I haven't tried to understand this code, so I can't say if that order will work or not, but I'm very happy to test it if you produce a series like this.
[Alison Wang] Thanks for your support. V8 series is sent out.
Best Regards, Alison Wang
On 11/06/2016 06:21 PM, Alison Wang wrote:
[Alison Wang] Thanks for all your comments.
For the issue about the tree would not be bisect-able, I have a solution. Actually it is the root cause that 64-bit kernel could not boot up when U-Boot is running in EL2. I will move these codes from the third patch to the first patch.
ENTRY(armv8_switch_to_el2) switch_el x5, 1f, 0f, 0f -0: ret
/** x3 is kernel entry point or switch_to_el1* if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
I guess you meant EL2 here.
* When running in EL2 now, jump to the* address saved in x3.*/+0: br x3 1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(armv8_switch_to_el2)
ENTRY(armv8_switch_to_el1) switch_el x5, 0f, 1f, 0f -0: ret
/** x3 is kernel entry point. When running in EL1* now, jump to the address saved in x3.*/+0: br x3 1: armv8_switch_to_el1_m x3, x4, x5 ENDPROC(armv8_switch_to_el1)
With this re-order, the bitsect issue will be fixed and there is not a point that kernel could not boot up.
If you all agree with this re-order, I will send out the v8 patch includes the first, second and third patches.
Would it be a good idea to setup the simulator and verify booting process?
York
Spin-table method is used for secondary cores to load 32-bit OS. The architecture information will be got through checking FIT image and saved in the os_arch element of spin-table, then the secondary cores will check os_arch and jump to 32-bit OS or 64-bit OS automatically.
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 the first patch.
Changes in v6: - Make secondary_switch_to_el1() always jump to ep when switching to AArch64 or AArch32 modes.
Changes in v5: - Make secondary_switch_to_el2() always jump to ep when switching to AArch64 or AArch32 modes.
Changes in v4: - Omit arch and ftaddr arguments.
Changes in v3: - Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m.
Changes in v2: - Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m.
arch/arm/cpu/armv8/fsl-layerscape/mp.c | 10 ++++++++++ arch/arm/include/asm/arch-fsl-layerscape/mp.h | 2 ++ arch/arm/lib/bootm.c | 6 ++++++ 3 files changed, 18 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c b/arch/arm/cpu/armv8/fsl-layerscape/mp.c index df7ffb8..dd91550 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c @@ -22,6 +22,16 @@ phys_addr_t determine_mp_bootpg(void) return (phys_addr_t)&secondary_boot_code; }
+void update_os_arch_secondary_cores(uint8_t os_arch) +{ + u64 *table = get_spin_tbl_addr(); + int i; + + for (i = 1; i < CONFIG_MAX_CPUS; i++) + table[i * WORDS_PER_SPIN_TABLE_ENTRY + + SPIN_TABLE_ELEM_OS_ARCH_IDX] = os_arch; +} + int fsl_layerscape_wake_seconday_cores(void) { struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h b/arch/arm/include/asm/arch-fsl-layerscape/mp.h index 14d9fcf..55f0e0c 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h @@ -13,6 +13,7 @@ * uint64_t entry_addr; * uint64_t status; * uint64_t lpid; +* uint64_t os_arch; * }; * we pad this struct to 64 bytes so each entry is in its own cacheline * the actual spin table is an array of these structures @@ -20,6 +21,7 @@ #define SPIN_TABLE_ELEM_ENTRY_ADDR_IDX 0 #define SPIN_TABLE_ELEM_STATUS_IDX 1 #define SPIN_TABLE_ELEM_LPID_IDX 2 +#define SPIN_TABLE_ELEM_OS_ARCH_IDX 3 #define WORDS_PER_SPIN_TABLE_ENTRY 8 /* pad to 64 bytes */ #define SPIN_TABLE_ELEM_SIZE 64
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 7015573..17758d3 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -270,6 +270,10 @@ bool armv7_boot_nonsec(void) #endif
#ifdef CONFIG_ARM64 +__weak void update_os_arch_secondary_cores(uint8_t os_arch) +{ +} + #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 static void switch_to_el1(void) { @@ -307,6 +311,8 @@ static void boot_jump_linux(bootm_headers_t *images, int flag) if (!fake) { do_nonsec_virt_switch();
+ update_os_arch_secondary_cores(images->os.arch); + #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 armv8_switch_to_el2((u64)images->ft_addr, 0, 0, (u64)switch_to_el1, ES_TO_AARCH64);
participants (5)
-
Alexander Graf -
Alison Wang -
Alison Wang -
Ryan Harkin -
york sun