This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Armv8 Foundation simulator

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

Parents
  • 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.

Reply
  • 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.

Children
No data