On Mon, May 8, 2017 at 8:00 AM, Volodymyr Babchuk vlad.babchuk@gmail.com wrote:
Hello Akshay,
Have you booted OP-TEE on your board?
I havent been able to boot OP-TEE on the SAMA5D2 board yet (seems issue is either platform or Cortex A5 specific, since I have a i.MX6UL that boots fine with OP-TEE).
Currently I am seeing 2 issues (previous panic was resolved by using CFG_SECURE_TIME_SOURCE_REE as the time source instead of CFG_SECURE_TIME_SOURCE_CNTPCT. Issue 1: Serial console not working after MMU is enabled If I put a while(1) at the end of init_primary_helper then the code is stuck in the while(1) loop without any aborts. However I do not see any serial messages that should be printed after MMU gets enabled. If I try to pint the UART registers using the virtual address after halting the processor over JLink then it returns "00000002" which is incorrect data.
Serial log: DEBUG: TEE-CORE:add_phys_mem:324: CFG_SHMEM_START type NSEC_SHM 0x3e000000 size 0x00400000 DEBUG: TEE-CORE:add_phys_mem:324: CFG_TA_RAM_START type TA_RAM 0x3e500000 size 0x01b00000 DEBUG: TEE-CORE:add_phys_mem:324: CFG_TEE_RAM_START type TEE_RAM 0x3e400000 size 0x00100000 DEBUG: TEE-CORE:add_phys_mem:324: CONSOLE_UART_BASE type IO_NSEC 0xf8000000 size 0x00200000 DEBUG: TEE-CORE:add_va_space:363: type RES_VASPACE size 0x00a00000 DEBUG: TEE-CORE:dump_mmap_table:476: type TEE_RAM va 0x3e400000..0x3e4fffff pa 0x3e400000..0x3e4fffff size 0x00100000 (pgdir) DEBUG: TEE-CORE:dump_mmap_table:476: type TA_RAM va 0x3e500000..0x3fffffff pa 0x3e500000..0x3fffffff size 0x01b00000 (pgdir) DEBUG: TEE-CORE:dump_mmap_table:476: type NSEC_SHM va 0x40000000..0x403fffff pa 0x3e000000..0x3e3fffff size 0x00400000 (pgdir) DEBUG: TEE-CORE:dump_mmap_table:476: type IO_NSEC va 0x40400000..0x405fffff pa 0xf8000000..0xf81fffff size 0x00200000 (pgdir) DEBUG: TEE-CORE:dump_mmap_table:476: type RES_VASPACE va 0x40600000..0x40ffffff pa 0x00000000..0x009fffff size 0x00a00000 (pgdir) DEBUG: TEE-CORE: section map [3e400000 3e500000] MEM-RW-X-S DEBUG: TEE-CORE: section map [3e500000 40000000] MEM-RW-XN-S DEBUG: TEE-CORE: section map [40000000 40400000] MEM-RW-XN-NS DEBUG: TEE-CORE: section map [40400000 40600000] DEV-RW-XN-NS DEBUG: TEE-CORE: section map [40600000 41000000] not-mapped
Objdump <snip> 3e41e3f8: f7e7 fa02 bl 3e405800 <init_teecore> 3e41e3fc: 4603 mov r3, r0 3e41e3fe: 2b00 cmp r3, #0 3e41e400: d005 beq.n 3e41e40e <init_primary_helper+0x76> /mnt/data/irobot/tee/optee_os_master/core/arch/arm/kernel/generic_boot.c:611 3e41e402: 2300 movs r3, #0 3e41e404: 2200 movs r2, #0 3e41e406: 2100 movs r1, #0 3e41e408: 2000 movs r0, #0 3e41e40a: f7e8 fe23 bl 3e407054 <__do_panic> /mnt/data/irobot/tee/optee_os_master/core/arch/arm/kernel/generic_boot.c:612 3e41e40e: f649 5358 movw r3, #40280 ; 0x9d58 3e41e412: f6c3 6342 movt r3, #15938 ; 0x3e42 3e41e416: 9300 str r3, [sp, #0] 3e41e418: 2301 movs r3, #1 3e41e41a: 2203 movs r2, #3 3e41e41c: f44f 7119 mov.w r1, #612 ; 0x264 3e41e420: f241 30a3 movw r0, #5027 ; 0x13a3 3e41e424: f6c3 6043 movt r0, #15939 ; 0x3e43 3e41e428: f7ff fd32 bl 3e41de90 <trace_printf> /mnt/data/irobot/tee/optee_os_master/core/arch/arm/kernel/generic_boot.c:613 (discriminator 1) 3e41e42c: e7fe b.n 3e41e42c <init_primary_helper+0x94>
(gdb): mon halt target state: halted target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x3e41e42c MMU: enabled, D-Cache: enabled, I-Cache: enabled (gdb) mon mdw 0x40420000 10 0x40420000: 00000002 00000002 00000002 00000002 00000002 00000002 00000002 00000002 0x40420020: 00000002 00000002
Issue2: Hang after jumping to Linux kernel? If I remove the above while(1) and let the board boot, it appears to be stuck in the address range (physical) of the Linux kernel. I am not sure if it needs to be using virtual addresses here... (gdb) mon halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x40000093 pc: 0x22003314 MMU: enabled, D-Cache: enabled, I-Cache: enabled (gdb) mon reg
===== ARM registers (4536) r0 (/32): 0x00000055 (dirty) (4537) r1 (/32): 0xF8020000 (4538) r2 (/32): 0xF7020000 (4539) r3 (/32): 0x00000002 (4540) r4 (/32): 0x00000055 (4541) r5 (/32): 0x220042FD (4542) r6 (/32): 0x00000024 (4543) r7 (/32): 0x00000000 (4544) r8 (/32): 0x223B62F0 (4545) r9 (/32): 0x223A62F0 (4546) r10 (/32): 0x20008000 (4547) r11 (/32): 0x223A52CC (4548) r12 (/32): 0x00000020 (4549) sp_usr (/32) (4550) lr_usr (/32) (4551) pc (/32): 0x22003314 (4552) r8_fiq (/32) (4553) r9_fiq (/32) (4554) r10_fiq (/32) (4555) r11_fiq (/32) (4556) r12_fiq (/32) (4557) sp_fiq (/32) (4558) lr_fiq (/32) (4559) sp_irq (/32) (4560) lr_irq (/32) (4561) sp_svc (/32): 0x223A62C0 (4562) lr_svc (/32): 0x22000960 (4563) sp_abt (/32) (4564) lr_abt (/32) (4565) sp_und (/32) (4566) lr_und (/32) (4567) cpsr (/32): 0x40000093 (4568) spsr_fiq (/32) (4569) spsr_irq (/32) (4570) spsr_svc (/32) (4571) spsr_abt (/32) (4572) spsr_und (/32) (4573) sp (/32) (4574) lr (/32) (4575) sp_mon (/32) (4576) lr_mon (/32) (4577) spsr_mon (/32)
I just came with another idea. Can you try to zero all OP-TEE memory in u-boot before loading OP-TEE image? I have found that .bss section being zeroed up in late boot stages. That can lead to many funny issues like yours, as C code expects that all global and static variables are initialized to 0.
Good idea. I tried this but it did not resolve the above issues.
=> mw.w 0x3E000000 0x0 0x02000000
Thanks for your continued support :)