On Mon, May 8, 2017 at 6:17 PM, Akshay Bhat akshay.bhat@timesys.com wrote:
The UART issue was related to defining the UART memory space as MEM_AREA_IO_NSEC. If I change it to MEM_AREA_IO_SEC, then the messages are printed ok!
The UART1 range needs to be 0xF8020000 to 0xF8024000; however the MMU translation table sets up 1MB (0xf8000000 to 0xf80fffff).
Looking at SAMA5 datasheet the peripheral SECURAM falls under this range and the peripheral security type for it is "always secure". Could this be the reason why UART needs to be defined as MEM_AREA_IO_SEC? Does op-tee support 4k/16k mapping instead of 1MB to workaround this issue?
Closing the loop incase it helps anyone else: To resolve the above issue, SAMA5 Matrix needs be configured to allow non-secure access to UART (defaults to secure coming out of at91bootstrap).
Questions: I noticed the TTBR0/1 register contents are different between OP-TEE and Linux. Is this expected?
Yes this is expected, ARM has different copies of the above registers corresponding to secure vs. non-secure world.
Are there any platform specific support that needs to be added for the hand-off between op-tee and linux to happen correctly?
Bootloader needs to configure any memory/bus controllers (in this case SAMA5 matrix security registers) to allow access to memory/peripherals needed by normal world. Otherwise you will see weird memory errors and/or imprecise external aborts when Linux runs in normal world.
After the above changes am able to successfully run op-tee / Linux (L2 cache is still not working but that is for another day).
Thanks.