Hi,
i'm doing some experiments on Aarch64/Aarch32 using the Foundationv8 simulator.
For starting, i got the linux/bootwrapper/toolchain code from linaro, compiled the software and the linux kernel in 64 bits without any problem.
Then i started modifications to try booting on the same simulator the linux in 32 bits.
- modify the mm/kernel/proc-v7.S to add the Foundation v8 processor id (0x410fd000)
- i compiled the linux in 32 bit using the same config (vexpress_defconfig) enabling LPAE and disabling 'EL2 configuration'
- modify the boot wrapper to jump in Aarch32 mode into kernel (it is working fine)
I start the emulator. It seems i'm jumping in the kernel in Aarch32 system mode (so boot wrapper is OK). But once in the kernel i start getting issues:
- in Aarch32 i 'm not able to obtain the MIDR using the instruction (mrc p15, 0, r9, c0, c0, 0). zero is returned in r9.
- if i force the r9 value with expected one then i can continue execution but still not able to get terminal and even shell.
So my questions are:
- is Foundation v8 able to run a linux in 32 bits (CP15 MIDR register returning bad value is bug or not ) ?
- is the linux supporting execution on Foundation v8 with vexpress_defconfig ?
I'm continuing the investigation but it would be nice for me to know if the task i'm doing is acheivable .
Thanks for you help.
Seb
Is there a specific reason you want to do this? The expected use model is to use the AARCH64 kernel and have a mix of AARCH32/AARCH64 in userspace.
If you want to run a legacy v7A kernel in a system where EL3 & EL2 are AARCH64 this is possible, but potentially more troublesome than having a system where EL3 starts AARCH32.
The problem is that you cannot make the same assumptions about the AARCH32 EL1 System Register states if you reset into AARCH64 rather than AARCH32.
- When a system boots (with EL3=AARCH32) the architecture defines known values for many of the System Registers out of reset.
- When a system boots (with EL3=AARCH64) most System Registers are uninitialized and need to be configured in software.
The v8 ARM Architecture Reference Manual defines what you can guarantee about the reset state of registers.
I suspect that you will need to review all the AARCH32 EL1 System Registers to check they have safe initialized states before entering the kernel. The current AARCH64 boot-loader is written with an assumption that you are booting an AARCH64 kernel (not a v7A one) and will not perform this initialization.
I haven't checked this, but I think that Non-secure EL1 reads of MIDR, actually return a VPIDR - and this probably needs initialization. Again the ARM ARM will tell you for sure.
HI,
thanks a lot for replying. I found my mistake:
in 32 bits at early stage of Linux boot (just when MMU is enable) , the memory pages are mapped as writable even for the ones used for executing code. The mistake was that my boot wrapper was configuring from EL2 the System Control Register of EL1 and forcing WXN bit enable. This bit was causing some trap the first instruction after MMU enable. This bit is there to detect and forbid code execution fron writable pages. the problem was only present for Linux booting In AArch32 mode as the Aarch64 was completely re-written and not mapping pages as writable.
For information, we had to limit CPU number to 1 as the "kicking " mechanism was not ported to Aarch32.
i agree with you that it would be better to start from EL3 in Aarch32 but FoundationV8 doesn't allow setting pins used for that (A53/57 fast models are authorising that).
mmy goal is to port a complex environment (kernel+user side code) from 32bits to 64bits. And in such development, I wanted to start from a known state in 32 bits (I know that one is working fine) and then step by step enable 64bits support.
Nevertheless thanks a lot for replying, and i confirm to readers that FoundationV8 is able to boot a linux in EL1/0 Aarch64 and also in Aarch32.
regards,
sebastien
hi, sebastien:
could you share your compiled steps and modified linaro code files?
best wishes,
HI Sebastien
In a similar way I am trying to load a 32-bit kernel on a real board running Cortex A-53.
I have followed the below steps to boot the kernel in EL1 mode from EL2.
mrs x0, sctlr_el2
bic x0, x0, #(1 << 25) // Clear the EE bit for EL2
msr sctlr_el2, x0
mov x0, #(0 << 31) // 32-bit EL1
msr hcr_el2, x0
/* Generic timers. */
mrs x0, cnthctl_el2
orr x0, x0, #3
msr cnthctl_el2, x0
msr cntvoff_el2, xzr
/* Populate ID registers. */
mrs x0, midr_el1
mrs x1, mpidr_el1
msr vpidr_el2, x0
msr vmpidr_el2, x1
/* sctlr_el1 */
mov x0, xzr
orr x0, x0, #(0x1 << 0)
orr x0, x0, #(0x1 << 1)
orr x0, x0, #(0x1 << 5)
orr x0, x0, #(0x1 << 7)
orr x0, x0, #(0x1 << 16)
orr x0, x0, #(0x1 << 18)
orr x0, x0, #(0x1 << 29)
orr x0, x0, #(0x1 << 23)
orr x0, x0, #(0x1 << 22)
orr x0, x0, #(0x1 << 20)
orr x0, x0, #(0x1 << 11)
msr sctlr_el1, x0
/* Coprocessor traps. */
mov x0, #0x33ff
msr cptr_el2, x0
msr hstr_el2, xzr // Disable CP15 traps to EL2
mov x0, #(0x3 << 0 | 0x1 << 4 | 0x1 << 6 | 0x1 << 7)
msr spsr_el2, x0
mov x0 , #0xb000000
msr elr_el2, x0
eret
The kernel is unable to boot. Is there something wrong that I am doing.
Regards.
Suhas P K