Porting to a new platform

[peter-nebe]

Hello everybody,

I'm trying to adapt the Raspberry Pi 3 porting to the RPi4 as part of a "research project". At the moment I am still working without the ARM Trusted Firmware. Nevertheless, a few difficulties arise. The following program parts hang or prevent the console output:

• set_sp (macro to set the stack)
• core_init_mmu_map (routine to initialize TEE core default memory mapping)
• malloc_lock / cpu_spin_lock_xsave (synchronization primitive)

You can see the full setup here: https://github.com/peter-nebe/optee_os The setup is probably not quite right yet. Can anyone find bugs?

Another question: How do I get diagnostic information (abort dumps, call stack)? Is there any console other than UART0?

Any help would be greatly appreciated.

[jbech-linaro]

Hi @peter-nebe , It looks like a great start, but I believe you have to sort out the TF-A side of things as well. I started doing RPi4 porting in TF-A quite some time ago, but unfortunately it looks like I've lost my branch. Note, here I mean adding real support in BL2 etc, not just jumping to the BL31 as they do in the current RPi4 port.

Another question: How do I get diagnostic information (abort dumps, call stack)? Is there any console other than UART0?

Getting the UART to work is essential. On the RPi3, I believe we've always used a single UART shared between the secure and non-secure.

[peter-nebe]

Thank you for your reply, @jbech-linaro.

Getting the UART to work is essential. On the RPi3, I believe we've always used a single UART shared between the secure and non-secure.

I get the output on the UART that I write out myself. But I also want information about segfaults, exceptions and failed assertions. The OPTEE-OS probably doesn't generate this in the first phase of booting?

I believe you have to sort out the TF-A side of things as well.

I don't think I'm at the point where TF-A is absolutely necessary yet. My hope is that OPTEE-OS will run without TF-A. Is this possible? If not, I'll take care of TF-A later. First, OPTEE-OS shouldn't get stuck when booting so early.

I will next set the TEE load address correctly.

[peter-nebe]

There are interesting things to see now:

armstub: boot optee-os
D/TC:0   console_init:53 done
F/TC:0   msg1:90 1
D/TC:0   add_phys_mem:635 ROUNDDOWN(0xFE215040, CORE_MMU_PGDIR_SIZE) type IO_NSEC 0xfe200000 size 0x00200000
D/TC:0   add_phys_mem:635 TEE_SHMEM_START type NSEC_SHM 0x08000000 size 0x00400000
D/TC:0   add_phys_mem:635 TA_RAM_START type TA_RAM 0x10800000 size 0x00800000
D/TC:0   add_phys_mem:635 VCORE_UNPG_RW_PA type TEE_RAM_RW 0x0006d000 size 0x10793000
D/TC:0   add_phys_mem:635 VCORE_UNPG_RX_PA type TEE_RAM_RX 0x00001000 size 0x0006c000
D/TC:0   add_phys_mem:635 TEE_RAM_START type TEE_RAM_RO 0x10100000 size 0xffffffffeff01000
D/TC:0   add_va_space:675 type RES_VASPACE size 0x00a00000
D/TC:0   add_va_space:675 type SHM_VASPACE size 0x02000000
E/TC:0   Panic at core/mm/core_mmu.c:1255 <init_mem_map>
E/TC:0   TEE load address @ 0x1000
E/TC:0   Call stack:
E/TC:0    0x00008924
E/TC:0    0x000133cc
E/TC:0    0x0001cd28
E/TC:0    0x00001100

This is the memory configuration from conf.mk:

$(call force,CFG_TEE_LOAD_ADDR,0x1000)
$(call force,CFG_CORE_ASLR,n)
$(call force,CFG_TEE_CORE_NB_CORE,1)

CFG_SHMEM_START ?= 0x08000000
CFG_SHMEM_SIZE ?= 0x00400000
CFG_TZDRAM_START ?= 0x10100000
CFG_TZDRAM_SIZE ?= 0x00F00000
CFG_TEE_RAM_VA_SIZE ?= 0x00700000

Obviously the size 0xffffffffeff01000 is wrong. But I don't know why.

I am thankful for every hint.

[peter-nebe]

Update: Setting CFG_CORE_RWDATA_NOEXEC=n helped.

Now I'm a small step further. However, the problem with cpu_spin_lock_xsave persists. Does anyone know a solution for this?

Thanks for your advice.

[github-actions[bot]]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.