OPTEE crashes when MMU is enabled.

[i-nevo]

Hi, I'm new to OPTEE and tasked with porting it to a new SoC. Our system uses 44 bits for Physical addresses, so it requires also 44 bits for Virtual addresses due to flat mapping of the OPTEE .text. I set the following configurations (in conf.mk of my platform):

$(call force,CFG_WITH_ARM_TRUSTED_FW,y)
$(call force,CFG_GIC,y)
$(call force,CFG_PL011,y)
$(call force,CFG_SECURE_TIME_SOURCE_CNTPCT,y)
$(call force,CFG_WITH_PAGER,n)
$(call force,CFG_WITH_LPAE,y)
$(call force,CFG_CORE_ASLR,n)
$(call force,CFG_CORE_LARGE_PHYS_ADDR,y)
$(call force,CFG_LPAE_ADDR_SPACE_BITS,44)
$(call force,CFG_CORE_ARM64_PA_BITS,44)

I also set CFG_TZDRAM_START & CFG_TZDRAM_SIZE to the physical memory space we use for the OPTEE. At first I got Panic 'can't find table for mapping' at core/arch/arm/mm/core_mmu.c:1640 and found out it was due to a hard-coded restriction in the OPTEE code. In file core_mmu_lpae.c, line 699 appeared the following:

                /* Copy bits 39:12 from tbl[n] to ntbl */
               ntbl = (tbl[n] & ((1ULL << 40) - 1)) & ~((1 << 12) - 1);

which I changed to

               ntbl = (tbl[n] & ((1ULL << CFG_LPAE_ADDR_SPACE_BITS) - 1)) & ~((1 << 12) - 1);

and the panic disappeared. However, the OPTEE crashes in routine enable_mmu (file entry_a64.S) when the MMU is enabled:

    /* Enable the MMU */
    mrs x1, sctlr_el1
    orr x1, x1, #SCTLR_M
    msr sctlr_el1, x1
    isb

The isb is the last executed instruction, the next instruction causes the following exception:

(<address of ISB instruction>:d5033fdf):         ISB      
(<address of next instruction>:--------):
                    EXC [0x000] Synchronous Current EL with SP_EL0
                    R SPSR_EL1 00000000000002c4
                    R ELR_EL1 <address of next instruction>
                    R ESR_EL1 0000000086000004
                    R FAR_EL1 <address of next instruction>
                    R CPSR 000003c5

I guess that this address space requires level 0 translation table, but OPTEE only provides levels 1-3. Is that so? If it is, how can I overcome this problem and use OPTEE on our system? If not, what could be the problem with the MMU? Thanks in advance.

[jenswi-linaro]

Our system uses 44 bits for Physical addresses, so it requires also 44 bits for Virtual addresses due to flat mapping of the OPTEE .text.

This is only needed if you're executing from such a high address.

... I guess that this address space requires level 0 translation table, but OPTEE only provides levels 1-3. Is that so?

Yes, we should have added a COMPILE_TIME_ASSERT() to catch this at build time.

If it is, how can I overcome this problem and use OPTEE on our system?

Obviously a level 0 has to be added. I expect that some corner cases will need to be handled. These comes to mind:

1. selecting a suitable level 1 entry for user space.
2. CFG_CORE_ASLR
3. CFG_VIRTUALIZATION

[i-nevo]

Thanks