TA compilation with SPI driver #1461

deepakmnvl · 2017-04-04T12:50:54Z

Hi,
My task is to communicate with my SPI device through OP-TEE securely.
For this , as a trial , I am extending hello_world program to included spi_init() and spi loopback test api.
(copy spi_init() from optee_os to hello_world_ta.c)

I am getting many errors during TA compilation as it is not able to find headers, which are in optee_os folders.
( I have solved some by crude way of copying \optee_os\core\include\ folder to my TA folder but other errors appeared )

It would be very helpful if anybody can provide some documentation/usage/how-to tutorial of driver integration in OP-TEE ?

Thanks

etienne-lms · 2017-04-04T13:11:26Z

Hi @deepakmnvl. Remember TAs operate in userspace while optee_os/core operates in privileged land. The old application / kernel scheme.
What you could do is to create a pseudo TA (in 'core' privileged space) from where you can access your SPI driver. And make your TA (user space) to invoke your pseudo TA.

deepakmnvl · 2017-04-06T06:40:23Z

Hi @etienne-lms ,
Thanks for the reply.

I am referring to :

My setup is Android REE and OP-TEE . And I have a working SPI driver in Android for my device.
So , if I integrate my driver into TEE driver which is in linux kernel space , and I talk to my device via TA->TEE Core->Tee driver ->my SPI driver -> my device .

Is this feasible method ?
Is this secure way to communicate with a device ?

Thanks

etienne-lms · 2017-04-06T08:53:33Z

TA->TEE Core->Tee driver ->my SPI driver -> my device .

Is this feasible method ?

Yes, but implementation is not straightforward.

Is this secure way to communicate with a device ?

No. It would look better if your driver lies in the "HAL" red box of the above figure.

deepakmnvl · 2017-04-09T15:41:42Z

Hi,
I am creating a static TA and a user TA as per your suggestion in 1st comment.

For static TA, my file's path is optee\optee_os\core\tee\foo.c , optee\optee_os\core\include\tee\foo.h
Now , how to call my APIs in foo.c from user TA.

Is it the system call way ? they are defined here : optee\optee_os\core\arch\arm\tee\arch_svc.c
I picked few sys calls and tried checking their code flow, but couldn't understand.
Few calls go to tee_api_operations.c in libutee !!! Its confusing .

Can you help me with any other API which is called from user TA ?

Is it possible to call my API in "core\tee\foo.c" directly from user TA ? or should I need to route the call through some library here (optee\optee_os\lib)

Thanks

jforissier · 2017-04-09T19:36:18Z

For an example of pseudo-TA, see for instance https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/pta/interrupt_tests.c. You may call a pseudo-TA directly from a client application (normal world).

deepakmnvl · 2017-04-10T05:45:51Z

hi @jforissier ,
Thanks for the reply. But I need a mechanism to call my pseudo-TA from user TA.

I have gone through interrupt_tests.c file before.
fops is declared for static_ta_register, but not able to figure out how they are invoked from user TA .
Any input in this regard would be helpful

Thanks.

etienne-lms · 2017-04-10T07:37:41Z

hi @deepakmnvl,

A (user) TA can call another (user) TA or a pseudo TA using the GP TEE internal API:

TEE_OpenTASession(...)
TEE_InvokeTACommand(...)
TEE_CloseTASession(...)

These APIs are available to user TAs (in libutee) and already go through syscalls to reach target pseudo-TA in OP-TEE core.

deepakmnvl · 2017-04-26T10:00:16Z

Hi ,
I am now trying to attach my framework ( which are a collection of static libs ) with my user ta.
I did modifications in "aosp1\external\optee_myprog\ta\sub.mk" as below :

libdirs += include/Debug //my libs are here
libnames += test
libdeps += include/Debug/libtest.a

In out/target/product/hikey/optee/ta/external_optee_myprog_ta
I see an entry in .map file like below -
LOAD include/Debug/libtest.a

But , my .ta file size didnt change. Its same to when I didnt include my static libs

I gathered above procedure in the forums, Is this correct ?

I didnt test it yet, as I am still implementing my normal world bin, wanted to check if my method is correct ?

Thanks

etienne-lms · 2017-04-27T11:16:41Z

hello @deepakmnvl,
Look strange, especially if you see the library in the generated TA ELF file which means the TA is effectively linked with the lib.
Check that your TA really uses the library resources (functions?). Resources from libraries that are not called from the TA are not be embedded in the TA.

deepakmnvl · 2017-05-09T13:08:11Z

hi ,
Now , I managed to build my "Normal World" code to call APIs from libteec.so and subsequently access TA part of my "Secure code". But , I am facing TEEC_ERROR_BAD_FORMAT error during TEEC_OpenSession() call.
I cherry-picked commit ef53fb06 , but still problem exists.

EDIT: yes , I did clean build and updated fip.bin
Also ,
should I specifically use any compiler options to make my Binaries compatible to run on Hikey+OPTEE environment ?
If so , pls let me know where they are defined in the stack

Any help would be appreaciated.
FYI, Am using this branch : link

Also , am using uart0 for logs , and did below changes:

In device/linaro/hikey/uefi-tools/platforms.config, under the [hikey] node, uncomment the 3 lines required to use UART0. Then rebuild fip.bin.
In device/linaro/hikey/bootloader/EFI/BOOT/grub.cfg, line 6, change both ttyFIQ0 to ttyAMA0 and rebuild the image.
My build command has CFG_CONSOLE_UART=0

This is the only log appearing :

debug EMMC boot: print init OK
debug EMMC boot: send RST_N .
debug EMMC boot: start eMMC boot......
load fastboot1!
NOTICE: acpu_dvfs_set_freq: set acpu freq success!NOTICE: BL2: v1.1(release):36aa82d
NOTICE: BL2: Built : 18:02:35, May 9 2017
NOTICE: BL3-1: v1.1(release):36aa82d
NOTICE: BL3-1: Built : 18:02:35, May 9 20INFO: TEE-CORE: Initializing (2.3.0-dev #46 Tue May 9 12:32:25 UTC 2017 aarch64)
INFO: TEE-CORE: Initialized
UEFI firmware (version Alpha built at 10:33:12 on Apr 4 2017)
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
Failed to handle fs_proto
EFI stub: ERROR: Failed initrd from command line!
EFI stub: Exiting boot services and installing virtual address map...

Are there any more changes required ?

Thanks

vchong · 2017-05-11T06:52:59Z

The uart0 logging part of the question above is answered in https://discuss.96boards.org/t/android-op-tee-compile-error/1422/49.

Not sure about the TEEC_ERROR_BAD_FORMAT error but in one of your comments above, you had:

libdirs += include/Debug //my libs are here
libnames += test
libdeps += include/Debug/libtest.a

Is the above exactly the same as what you have in your actual makefile? If so, not sure if the //my libs are here comment might cause trouble so you can perhaps try removing it to be sure.

deepakmnvl · 2017-05-11T07:00:25Z

Hi ,
I added //my libs are here just in this comment .
My actual sub.mk file do not have it

deepakmnvl · 2017-05-12T05:44:38Z

Hi ,
@vchong , my OPTEE build was indeed RELEASE, changed that to DEBUG. Now , I could see more logs.
Also , now am using "CFG_TEE_TA_LOG_LEVEL=4 CFG_TEE_CORE_LOG_LEVEL=4" in my AOSP build command. Thanks for your help

Regarding my "TEEC_ERROR_BAD_FORMAT" issue , I modified my calls as
TEEC_RegisterSharedMemory --> TEEC_AllocateSharedMemory and it seems to be fixed.

Another issue now :
I need to link by prebuilt static libs to my TA . For that , I did as below :

I did modifications in "aosp1\external\optee_myprog\ta\sub.mk" as below :

libdirs += include/Debug //my libs are here
libnames += test
libdeps += include/Debug/libtest.a

In addition to above , Should I need to copy my static libs on board ?
I think am missing a step here. Can anybody please help here ??

Thanks

EDIT : Presently , am facing error in TEEC_OpenSession with "TEEC_ERROR_BAD_FORMAT" error.
I think , during TEEC_OpenSession , TA gets loaded along with its dependencies. and I am doubting loading of my static libs has some problem. Pls correct me if am wrong !!!

etienne-lms · 2017-05-12T08:07:03Z

Hello @deepakmnvl,

Your libs are statically linked with the TA so they will not appear as separated files in the REE filesystem: You will find only a single xxx.ta file that contains all the binary code/data of your TA. Note that they a no support for shared libraries for the OP-TEE TAs. Each TA is a single binary blob.

Regarding the "TEEC_ERROR_BAD_FORMAT", it looks strange. It cannot be due to a dependency issue as such issue would appear a TA build stage. Is there any error or debug trace together with the error status ?

jforissier · 2017-05-12T08:45:01Z

About TEE_ERROR_BAD_FORMAT: there are several places that set this error during TA loading, but it seems most of them are meant to detect an invalid ELF file, which is quite unlikely (I assume we can trust the toolchain to generate valid binaries).
There is one constraint specific to the OP-TEE ELF loader however: the ELF program headers must start with LOAD header. Can you please check this? Here is an example of a correct TA (note that the headers are LOAD, LOAD, LOAD and DYNAMIC in that order):

$ arm-linux-gnueabihf-readelf -l hello_world/ta/8aaaf200-2450-11e4-abe2-0002a5d5c51b.elf 

Elf file type is DYN (Shared object file)
Entry point 0x20
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x010000 0x00000000 0x00000000 0x05288 0x05288 R E 0x10000
  LOAD           0x015288 0x00005288 0x00005288 0x01a84 0x01a84 R   0x10000
  LOAD           0x017000 0x00007000 0x00007000 0x00094 0x0abe0 RW  0x10000
  DYNAMIC        0x016b50 0x00006b50 0x00006b50 0x00080 0x00080 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   00     .ta_head .text 
   01     .rodata .got .rel.got .dynamic .dynsym .dynstr .hash .rel.dyn 
   02     .data .bss 
   03     .dynamic

This won't be the case if you build some file with -funwind-tables for instance -- you would get 0x70000001, LOAD, LOAD, LOAD, DYNAMIC.

deepakmnvl · 2017-05-12T09:49:00Z

hi,
In my TA , if I just increment a number (like in hello_world), there's no error
If I make a call to an API inside my static lib , I am getting this "TEE_ERROR_BAD_FORMAT" error

I am getting error from "TEEC_OpenSession"
res = arg->ret; eorig = arg->ret_origin;

"res" being set to 0xffff0005
"eorig " being set to 0x3

@jforissier I checked on your query .
My test TA has "LOAD, LOAD, LOAD and DYNAMIC" sequence

But there is one difference , when I call my static lib , ".eh_frame" is appearing

Elf file type is DYN (Shared object file)
Entry point 0x20
There are 4 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000010000 0x0000000000000000 0x0000000000000000
0x000000000004e130 0x000000000004e130 R E 10000
LOAD 0x000000000005e130 0x000000000004e130 0x000000000004e130
0x00000000000115a0 0x00000000000115a0 R 10000
LOAD 0x0000000000070000 0x0000000000060000 0x0000000000060000
0x000000000006079c 0x000000000006b438 RW 10000
DYNAMIC 0x000000000006ee68 0x000000000005ee68 0x000000000005ee68
0x00000000000000f0 0x00000000000000f0 RW 8

Section to Segment mapping:
Segment Sections...
00 .ta_head .text
01 .eh_frame .rodata .rela.dyn .got .rela.got .dynamic .dynsym .dynstr .hash
02 .data .bss
03 .dynamic

Does this make any difference ??

Mine hikey board is 64bit arch , compiling aosp with arm-linux-androideabi-
Also , my static libs are compiled with android-ndk-r12b 64bit cross-compiler

Below are compiler flags I am using to build my static libs :

add_compile_options( -ffunction-sections )
add_compile_options( -fcrossjumping)
add_compile_options( -funwind-tables )
add_compile_options( -fno-short-enums)
add_compile_options( -fno-zero-initialized-in-bss)
add_compile_options( -fpic)
add_compile_options( -fPIC)
add_compile_options( -fPIE)
add_compile_options( -Wall)
add_compile_options( -Wno-missing-braces)
add_compile_options( -Werror)
add_compile_options( -Os)

Should I add/remove any ?

Thanks

jforissier · 2017-05-12T11:08:52Z

Try removing -funwind-tables. That's what causes the .eh_frame section to appear in the second segment. I don't really see how it could cause a problem, but still it's worth checking.
As a side note: I'm currently working on making stack unwinding work for user mode TAs (that is, dump the call stack to the console when an abort occurs while executing a TA). For this to work with 32-bit TAs, -funwind-tables is needed, and although the flag is normally not needed for 64-bit TAs I will make sure it doesn't break things at least. But in the mean time, please let me know how things work for you.

vchong · 2017-05-12T11:10:42Z

Mine hikey board is 64bit arch , compiling aosp with arm-linux-androideabi-

Shouldn't this be aarch64-linux-android-?

deepakmnvl · 2017-05-14T20:47:01Z

@jforissier I tried removing -funwind-tables and also adding -fno-unwind-tables , but , .eh_frame section doesnt go away. Strange.

@vchong yes, its aarch64- . Its copy-paste error, my bad

@etienne-lms No debug trace. I got the error code printed in my code.

I am linking around 8 static libs with the TA , could it be a memory issue.
Should I increase memory sizes for TA somewhere ?

Thanks

deepakmnvl · 2017-05-15T06:25:44Z

well , I did a small experiment .
I compiled a small static lib with my code which just returns a const value, say 72.
Now , I have linked this static lib with my TA , and viola, I can retrieve 72.

So , it really seems memory issue while loading the TA ?

I need to link around 14 static libs of total size ~ 4.5mb with my TA. Is that possible ?

etienne-lms · 2017-05-15T08:01:12Z

Try to add some traces in the core at all point where TEE_ERROR_BAD_FORMAT is set as return value in user_ta.c and elf_load.c. That could help finding out at which point the core complains about your TA, and whether it is related to the ELF format content or to OP-TEE specific expectations from the TA binary content.

deepakmnvl · 2017-05-16T04:56:07Z

hi ,
I reduced my static libs size to ~3.3mb , and now , I am able to call TA side from NW side successfully.

So , is there any limitation for memory allocated for each TA ? and any way to increase it ?
And how to increase stack and heap size in a TA ? in this file -> user_ta_header_defines.h ?

deepakmnvl · 2017-05-18T10:21:15Z

hi ,
I am not getting logs , like below :

DEBUG: [0x0] TEE-CORE:tee_ta_init_static_ta_session:160: Lookup for Static TA 1111a200-2450-11e4-abe2-0002a5d5c51b
DEBUG: [0x0] TEE-CORE:init_session_with_signed_ta:775: Load dynamic TA
DEBUG: [0x0] TEE-CORE:ta_load:506: Loaded TA at 0x8e100000
DEBUG: [0x0] TEE-CORE:ta_load:507: ELF load address 0x101000
DEBUG: [0x0] TEE-CORE:init_session_with_signed_ta:781: dyn TA : 1111a200-2450-11e4-abe2-0002a5d5c51b
FLOW: [0x0] TEE-CORE:trace_syscall:144: syscall #1 (syscall_log)
DEBUG: USER-TA: tee_user_mem_alloc:343: Allocate: link:[0x111b98], buf:[0x111ba8:16]

Infact , I never got any logs like "TEE-CORE:"

I am routing all logs to uart0.
My build cmd has "CFG_NW_CONSOLE_UART=0 CFG_SW_CONSOLE_UART=0 CFG_CONSOLE_UART=0"

Is there any other flag for this ?

Thanks

vchong · 2017-05-18T11:04:10Z

Try adding OPTEE_EXTRA_FLAGS ?= CFG_TEE_CORE_LOG_LEVEL=3 CFG_TEE_TA_LOG_LEVEL=3 DEBUG=1 to device/linaro/hikey/optee-packages.mk and rebuild fip.bin.

vchong · 2017-05-18T11:04:39Z

Add it at the top of the file please.

deepakmnvl · 2017-05-18T12:06:17Z

hey @vchong ,
the line you gave already existed
in addition , I made below changes:
device/linaro/hikey/bootloader/Makefile
--------- hardcoded as DEBUG

device/linaro/hikey/bootloade/uefi-tools/opteed-build.sh
----------- modified line as CFG_TEE_CORE_LOG_LEVEL=4
my cmd: make TARGET_TEE_IS_OPTEE=true CFG_NW_CONSOLE_UART=0 CFG_SW_CONSOLE_UART=0 CFG_CONSOLE_UART=0 DEBUG=1

Now , I am getting TEE-CORE logs :)

well, I had to do this since my TA is not getting loaded, and the logs is like this :

127|hikey:/ # DEBUG: [0x0] TEE-CORE:tee_ta_init_static_ta_session:160: Lookup for Static TA d96a5b40-c3e5-21e3-8794-1002a5d5c61b
DEBUG: [0x0] TEE-CORE:init_session_with_signed_ta:719: Load dynamic TA
DEBUG: [0x0] TEE-CORE:tee_ta_open_session:478: init session failed 0xffff0005
DEBUG: [0x0] TEE-CORE:tee_dispatch_open_session:127: => Error: ffff0005 of 3

Any help here pls ??

etienne-lms · 2017-05-18T12:23:13Z

Make sure your TA does set TA_FLAG_EXEC_DDR as well as TA_FLAG_USER_MODE. These attributes are mandatory (even if not really meaningful, there should be some cleaning about them). See the optee_test test TAs as example: i.e https://github.com/OP-TEE/optee_test/blob/master/ta/os_test/include/user_ta_header_defines.h#L37.

deepakmnvl · 2017-05-18T12:29:37Z

hi @etienne-lms
I do have #define TA_FLAGS (TA_FLAG_MULTI_SESSION | TA_FLAG_EXEC_DDR )

Also , added TA_FLAG_USER_MODE as you said. Still issue exists.

Another thing is , I removed all my static libs which are being linked with the TA , and verified with a small sample lib , and ITS WORKING FINE
I believe , this got something to do with memory for TA .

Is there any way to increase it ?

deepakmnvl · 2017-06-06T13:00:56Z

Hi @jforissier ,
Got the dump , but couldnt get symbolize.py running
When I paste my call stack in symbolize.py , nothing happens.
Then press ^d, same addresses gets print again , thats it !!!

Anyways , my crash is as below :

DEBUG: [0x0] TEE-CORE:abort_handler:684: [abort] abort in User mode (TA will panic)
ERROR: TEE-CORE:
ERROR: TEE-CORE: user TA data-abort at address 0x40d871c6 (alignment fault)
ERROR: TEE-CORE: esr 0x92000061 ttbr0 0x100003f09d000 ttbr1 0x00000000 cidr 0x0
ERROR: TEE-CORE: cpu #0 cpsr 0x20000100
ERROR: TEE-CORE: x0 0000000040d871c6 x1 0000000000000000
ERROR: TEE-CORE: x2 0000000000000006 x3 0000000000000001
ERROR: TEE-CORE: x4 0000000000000004 x5 0000000000000000
ERROR: TEE-CORE: x6 0000000040d871c6 x7 0000000000000070
ERROR: TEE-CORE: x8 0000000000000001 x9 000000003f0a90c0
ERROR: TEE-CORE: x10 00000000000000aa x11 00000000000045c7
ERROR: TEE-CORE: x12 0000000000004c66 x13 00000000406007b0
ERROR: TEE-CORE: x14 0000000000000000 x15 0000000000000000
ERROR: TEE-CORE: x16 000000003f0201c8 x17 0000000000000000
ERROR: TEE-CORE: x18 0000000000000000 x19 0000000040d87178
ERROR: TEE-CORE: x20 0000000040d871a0 x21 00000000406a4000
ERROR: TEE-CORE: x22 0000000000000007 x23 000000000000000d
ERROR: TEE-CORE: x24 0000000000000bb8 x25 0000000000000800
ERROR: TEE-CORE: x26 000000000000ffff x27 0000000000000038
ERROR: TEE-CORE: x28 0000000000000000 x29 00000000406003d0
ERROR: TEE-CORE: x30 000000004064164c elr 0000000040642714
ERROR: TEE-CORE: sp_el0 00000000406003d0
ERROR: TEE-CORE: Status of TA ec72de37-4c66-45c7-aa6a-5c6a8cfbc089 (0x3f07f150) (active)
ERROR: TEE-CORE: - load addr : 0x40601000 ctx-idr: 1
ERROR: TEE-CORE: - stack: 0x40000000 6293504
ERROR: TEE-CORE: sect 0 : va 0x40000000 pa 0x3f9b7000 0x601000
ERROR: TEE-CORE: sect 1 : va 0x40601000 pa 0x3f200000 0x7d000
ERROR: TEE-CORE: sect 2 : va 0x4067e000 pa 0x3f27d000 0x26000
ERROR: TEE-CORE: sect 3 : va 0x406a4000 pa 0x3f2a3000 0x714000
ERROR: TEE-CORE: sect 4 : va 0x40e00000 pa 0x3ee01000 0x2000
ERROR: TEE-CORE: sect 5 : va 0 pa 0 0
ERROR: TEE-CORE: sect 6 : va 0 pa 0 0
ERROR: TEE-CORE: sect 7 : va 0 pa 0 0
ERROR: TEE-CORE: Call stack:
ERROR: TEE-CORE: pc 0x0000000040642714
ERROR: TEE-CORE: pc 0x000000004062d204
ERROR: TEE-CORE: pc 0x0000000040621eb4
ERROR: TEE-CORE: pc 0x0000000040621924
ERROR: TEE-CORE: pc 0x0000000040620bfc
ERROR: TEE-CORE: pc 0x0000000040612398
ERROR: TEE-CORE: pc 0x0000000040609468
ERROR: TEE-CORE: pc 0x0000000040607858
ERROR: TEE-CORE: pc 0x00000000406075dc
ERROR: TEE-CORE: pc 0x000000004066de58
ERROR: TEE-CORE: pc 0x000000004066dee4
ERROR: TEE-CORE: pc 0x000000003f00b12c
DEBUG: [0x0] TEE-CORE:user_ta_enter:597: tee_user_ta_enter: TA panicked with code 0xdeadbeef
DEBUG: [0x0] TEE-CORE:tee_ta_invoke_command:613: => here ffff3024
DEBUG: [0x0] TEE-CORE:tee_ta_invoke_command:622: => Error: ffff3024 of 3
DEBUG: [0x0] TEE-CORE:tee_ta_invoke_command:604: Panicked !

Using aarch64-linux-android-addr2line , I get only proper value for 0x000000003f00b12c which is "optee/optee_os/core/arch/arm/kernel/thread.c:1108" in "tee.elf"

Remaining address gives "?"

I think 40*** series addresses are virtual ones ??
I am having no clue about (alignment fault) kind of issues.
Any help regarding this would be huge help

Thanks

jforissier · 2017-06-06T13:10:33Z

Hi @deepakmnvl,

It looks like you need to cherry-pick more commits, sorry for not mentioning them:

7bbee6e ("core: show user TA architecture on abort")
1bc08be ("core: cosmetic updates to the abort dumps for better consistency")

They are required because the symbolize.py script expects a specific format, which was slightly changed by the above commits. Please add them to your optee_os and the script should work.

It's not easy to use addr2line by hand because you have to subtract the load address of the TA.

Finally, note that the last address in the stack is indeed inside tee.elf, and should normally not be printed as part of the TA call stack (let's call this a minor bug in the user TA stack unwinding code ;-)).

jforissier · 2017-06-06T13:32:33Z

One more thing: assuming I have decoded esr correctly, it's a write access, unspecified size. Since the address is 0x40d871c6, which can be divided by 2 but not 4 or 8, it must be a 32- or 64-bit write. It should become obvious once you know the line in the source code (hopefully!).

deepakmnvl · 2017-06-07T06:57:59Z

After applying the above commits also , same problem with symbolize.py. Nothing gets printed after pasting call stack .
On extra thing got printed in my log dump is arch of my TA :

ERROR:   TEE-CORE: Status of TA ec72de37-4c66-45c7-aa6a-5c6a8cfbc089 (0x3f07f150) (active)
ERROR:   TEE-CORE:  arch: aarch64  load address: 0x40601000  ctx-idr: 1

deepakmnvl · 2017-06-07T12:09:28Z

Hi @jforissier ,
I used addr2line , and found out my last address in call stack points to a simple memset function in our code. ( line where fault occured : *((char*)dst + i) = c )
The code works when used in Normal world , but causing "alignment fault" in OPTEE.

Am I doing wrong in compilation steps of my library for OPTEE ? Should I add any compiler options ?

jforissier · 2017-06-07T12:42:15Z

A byte access obviously can't cause an alignment fault, so I suppose the compiler has optimized the loop and generated 32- or 64-bit writes. You could easily see that in the disassembly of your function.
Anyway, make sure you compile with -mstrict-align and the problem should go away. Another option would be disable alignment checks by clearing the A bit in SCTLR_EL1 (look for SCTLR_A in generic_entry_a64.S) but there may be drawbacks to doing so, such as not all platforms supporting this or performance issues with unaligned accesses.

deepakmnvl · 2017-06-08T04:49:16Z

I already tried -mstrict-align , but didnt work out.
And , yeah , from #1399 , I made corresponding changes and the error goes away !!!
Will do more testing and see if this hack works 100%.

Also , SCTLR_A is present twice in the file. For those who faced this problem , my changes are :

168 .section .text.cpu_on_handler
169 FUNC cpu_on_handler , :
170 mov x19, x0
171 mov x20, x1
172 mov x21, x30
173
174 adr x0, reset_vect_table
175 msr vbar_el1, x0
176 isb
177
178 mrs x0, sctlr_el1
179 mov x1, #(SCTLR_I | SCTLR_A | SCTLR_SA)
180 //orr x0, x0, x1
181 // reset values
182 bic x0, x0, x1
183 msr sctlr_el1, x0
184 isb

Thanks

jforissier · 2017-06-08T06:43:15Z

Two things:

If -mstrict-align doesn't work, it means the alignment fault is not caused by some compiler optimization but by the way the code is written instead (such as *(uint32_t *)addr = 0x1234 when addr is not 32-bit aligned etc.). The solution is to fix the code...
Your change to cpu_on_handler looks wrong to me. You're clearing the I, A and SA bits in SCTLR_EL1. I'm OK with clearing SCTLR_A (Alignment Check Enable), but you have no reason to clear SCTLR_SA ([EL1] Stack Alignment Check Enable) and SCTLR_I (Instruction Cache Enable). And, you need to change _start also otherwise the boot CPU will be configured differently.

deepakmnvl · 2017-06-08T06:48:34Z

oops , I have no knowledge in asm coding. I took the code from the other thread.
Could you pls help me with the changes also that you suggested !!!

Thanks

jforissier · 2017-06-08T06:58:56Z

I think the correct way of disabling alignment check is by replacing the mrs/msr sections in both cpu_on_handler and _start with:

mrs     x0, sctlr_el1
mov     x1, #(SCTLR_I | SCTLR_SA)
orr     x0, x0, x1
mov     x1, #SCTLR_A
bic     x0, x0, x1
msr     sctlr_el1, x0

deepakmnvl · 2017-06-08T07:12:09Z

Many thanks
Will try these changes

jforissier · 2017-06-09T07:58:38Z

@deepakmnvl As you may have seen, I have created a pull request for a cleaner solution: #1586
Would you please test it and let me know if it works for you? If it does, I'd be glad to add your "Tested-by:" (simply reply to PR 1586 with "Tested-by: Your Name your_email@some.domain"). No obligation of course. Thanks.

deepakmnvl · 2017-06-09T09:17:41Z

@jforissier Sure , will do it but after 1-2 weeks as I am reaching my deadlines

Also , I took your solution above and it is working fine !!!

jforissier · 2017-06-09T09:29:59Z

@jforissier Sure , will do it but after 1-2 weeks as I am reaching my deadlines

I hope the PR will be long merged in 2 weeks ;) but it's OK.

Also , I took your solution above and it is working fine !!!

Glad I could help.

deepakmnvl · 2017-07-10T07:11:29Z

Hi @jforissier ,
I tried your changes #1586 , and encountered alignment fault

User TA data-abort at address 0x40e00004 (alignment fault)
ERROR:   TEE-CORE:  esr 0x92000021  ttbr0 0x100003f09d080   ttbr1 0x00000000   cidr 0x0
ERROR:   TEE-CORE:  cpu #4          cpsr 0x80000100

deepakmnvl · 2017-07-10T07:35:06Z

FYI
I was able to access my spi device from android app. For that , I made below changes :


project device/linaro/hikey/
diff --git a/init.common.rc b/init.common.rc
old mode 100644
new mode 100755
index 5757a15..7175117
--- a/init.common.rc
+++ b/init.common.rc
@@ -120,3 +120,21 @@ service wpa_supplicant /system/bin/wpa_supplicant \
      class main
      disabled
      oneshot
+
+on post-fs
+    chmod 0777 /dev/tee0
+    chown system system /dev/tee0
+    chmod 0777 /dev/teepriv0
+    chown system system /dev/teepriv0
+

diff --git a/sepolicy/init.te b/sepolicy/init.te
old mode 100644
new mode 100755
index 890544a..b5cfa93
--- a/sepolicy/init.te
+++ b/sepolicy/init.te
@@ -8,3 +8,16 @@ allow init tmpfs:lnk_file create;
 allow init sysfs:dir { add_name write };
 allow init sysfs:file { create };
 allow init cgroup:file { create };
+
+allow init self:capability { sys_module };
+allow init sysfs:system { module_load };
+allow init system_file:system { module_load };
+
+
+allow tee system_data_file:dir write;
+allow tee system_data_file:dir add_name;
+allow tee system_data_file:dir create;
+#allow tee optee_data_file:dir create_dir_perms;
+#allow tee optee_data_file:file  { rename setattr getattr link create rw_file_perms create_file_perms };
+allow tee tee_data_file:file  { rename setattr getattr link create rw_file_perms create_file_perms };
+allow tee tee_data_file:dir create_dir_perms;

diff --git a/ueventd.common.rc b/ueventd.common.rc
old mode 100644
new mode 100755
index 2f82c8b..47b7f09
--- a/ueventd.common.rc
+++ b/ueventd.common.rc
@@ -4,5 +4,5 @@
 
 /dev/mali0       0666 system graphics
 
-/dev/tee0        0660   shell     shell
-/dev/teepriv0    0660   shell     shell
+/dev/tee0        0660   system     drmrpc
+/dev/teepriv0    0660   system     drmrpc

In addition to above changes, permissions should be given in "system/sepolicy/"YourAppName".te file , something like this
allow YourAppName tee_data_file:file { create_file_perms rw_file_perms};

I can also run a program at shell to access my spi device.

Hope this info will be useful for somebody :)

vchong · 2017-07-10T09:00:55Z

Great! Thanks for sharing!

deepakmnvl · 2017-07-10T09:34:35Z

@vchong Thanks to you and other members of the community who all replied patiently to my queries.

This thread can now be closed

If the expected number of packets are not received during the transmit+receive cycle, just receive the remaining data after the cycle if the Receive FIFO (SSPSR_RNE) is not empty, without depending on the busy (SSPSR_BSY) flag, else we might miss reading some data as indicated in [1]. LINK: [1] OP-TEE#1461 (comment) Signed-off-by: Victor Chong <victor.chong@linaro.org>

If the expected number of packets are not received during the transmit+receive cycle, just receive the remaining data after the cycle if the Receive FIFO (SSPSR_RNE) is not empty, without depending on the busy (SSPSR_BSY) flag, else we might miss reading some data as indicated in [1]. LINK: [1] OP-TEE#1461 (comment) Signed-off-by: Victor Chong <victor.chong@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

If the expected number of packets are not received during the transmit+receive cycle, just receive the remaining data after the cycle if the Receive FIFO (SSPSR_RNE) is not empty, without depending on the busy (SSPSR_BSY) flag, else we might miss reading some data as indicated in [1]. LINK: [1] OP-TEE#1461 (comment) Signed-off-by: Victor Chong <victor.chong@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

If the expected number of packets are not received during the transmit+receive cycle, just receive the remaining data after the cycle if the Receive FIFO (SSPSR_RNE) is not empty, without depending on the busy (SSPSR_BSY) flag, else we might miss reading some data as indicated in [1]. LINK: [1] #1461 (comment) Signed-off-by: Victor Chong <victor.chong@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

If the expected number of packets are not received during the transmit+receive cycle, just receive the remaining data after the cycle if the Receive FIFO (SSPSR_RNE) is not empty, without depending on the busy (SSPSR_BSY) flag, else we might miss reading some data as indicated in [1]. LINK: [1] OP-TEE#1461 (comment) Signed-off-by: Victor Chong <victor.chong@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

vchong mentioned this issue Apr 10, 2017

How do I control GPIO? #944

Closed

yuralty mentioned this issue Apr 26, 2017

USB access from pseudo-TA #1499

Closed

jforissier mentioned this issue Jun 8, 2017

core: arm: make alignment check configurable #1586

Merged

deepakmnvl closed this as completed Jul 10, 2017

deepakmnvl mentioned this issue Apr 16, 2018

crash while accessing SPI device #2256

Closed

vchong mentioned this issue Aug 8, 2019

How can I use SPI to get Hardware Data in TA? #3184

Closed

TA compilation with SPI driver #1461

TA compilation with SPI driver #1461

Comments

deepakmnvl commented Apr 4, 2017

etienne-lms commented Apr 4, 2017

deepakmnvl commented Apr 6, 2017

etienne-lms commented Apr 6, 2017

deepakmnvl commented Apr 9, 2017

jforissier commented Apr 9, 2017

deepakmnvl commented Apr 10, 2017

etienne-lms commented Apr 10, 2017

deepakmnvl commented Apr 26, 2017 • edited Loading

etienne-lms commented Apr 27, 2017

deepakmnvl commented May 9, 2017 • edited Loading

vchong commented May 11, 2017

deepakmnvl commented May 11, 2017 • edited Loading

deepakmnvl commented May 12, 2017 • edited Loading

etienne-lms commented May 12, 2017

jforissier commented May 12, 2017

deepakmnvl commented May 12, 2017 • edited Loading

jforissier commented May 12, 2017

vchong commented May 12, 2017

deepakmnvl commented May 14, 2017 • edited Loading

deepakmnvl commented May 15, 2017

etienne-lms commented May 15, 2017

deepakmnvl commented May 16, 2017 • edited Loading

deepakmnvl commented May 18, 2017

vchong commented May 18, 2017

vchong commented May 18, 2017

deepakmnvl commented May 18, 2017 • edited Loading

etienne-lms commented May 18, 2017

deepakmnvl commented May 18, 2017

deepakmnvl commented Jun 6, 2017

jforissier commented Jun 6, 2017

jforissier commented Jun 6, 2017

deepakmnvl commented Jun 7, 2017

deepakmnvl commented Jun 7, 2017

jforissier commented Jun 7, 2017

deepakmnvl commented Jun 8, 2017 • edited Loading

jforissier commented Jun 8, 2017 • edited Loading

deepakmnvl commented Jun 8, 2017

jforissier commented Jun 8, 2017

deepakmnvl commented Jun 8, 2017

jforissier commented Jun 9, 2017

deepakmnvl commented Jun 9, 2017

jforissier commented Jun 9, 2017

deepakmnvl commented Jul 10, 2017

deepakmnvl commented Jul 10, 2017

vchong commented Jul 10, 2017

deepakmnvl commented Jul 10, 2017

deepakmnvl commented Apr 26, 2017 •

edited

Loading

deepakmnvl commented May 9, 2017 •

edited

Loading

deepakmnvl commented May 11, 2017 •

edited

Loading

deepakmnvl commented May 12, 2017 •

edited

Loading

deepakmnvl commented May 12, 2017 •

edited

Loading

deepakmnvl commented May 14, 2017 •

edited

Loading

deepakmnvl commented May 16, 2017 •

edited

Loading

deepakmnvl commented May 18, 2017 •

edited

Loading

deepakmnvl commented Jun 8, 2017 •

edited

Loading

jforissier commented Jun 8, 2017 •

edited

Loading