Depending on what the kernel source is that you are using, there may be more or less display configurations enabled and/or working.
@Anjali Can you please try the 3.4.2 build for now, with the above mentioned fix for the monitor? The current code base doesn’t seem very stable so we’re planning to upgrade to Q, but it might take some time.
Thanks for the response, but I am still getting the same error with 3.4.2 tag also.
Is there any issue related to SElinux?
getenforce is giving SElinux:disabled.
Is there any possibility of getting TEEC_ERROR_STORAGE_NOT_AVAILABLE error from thread_rpc?
That shouldn’t happen. Are you sure you flashed the images properly? You can check the initial boot log for the OP-TEE version. Something like:
I/TC: OP-TEE version: 3.x.x #1 Day Mon Date HH:MM:SS UTC YYYY arch
Is there any possibility of getting TEEC_ERROR_STORAGE_NOT_AVAILABLE error from thread_rpc?
So it seems like your error is different than the OP although the error code is the same. The error is due to failure accessing secure storage at /data/vendor/tee/. Did you make any changes of your own to the build?
I don’t think that AOSP is expected to be able to boot with selinux DISABLED. Permissive, yes, but not disabled.
Keymaster and gatekeeper services are starting properly with OP-TEE version 3.4.2.
Thank you so much for the help!
Setting selinux to permissive helped, or what?
No sync was not done properly… it was still in 3.6.2 tag.
3.4.2 is working both in permissive and enforcing mode.
But is this tag is supported for hikey960?
But lunch command doesn’t include hikey960 option in 3.4.2!
But your working 3.4.2 build is for the hikey960? And you can still do lunch hikey960-userdebug manually? It should be there per vendorsetup.sh - linaro/hikey.git - [no description].
Yes. There’s a manifest for the hikey960. Haven’t you already built this tag for the 960 and it’s working? Or were you actually building for the 620 instead?
Yes… I am using optee for hikey960.
I tried lunch hikey960-userdebug and it’s working.
Hi,
I am getting error for optee_example_secure_storage binary with 3.4.2 tag in hikey960.
hikey960:/ # optee_example_secure_storage
Prepare session with the TA
optee_example_secure_storage: TEEC_Opensession failed with code 0xffff3024 origin 0x3
0xffff3024 refers to TEEC_ERROR_TARGET_DEAD
optee_example_secure_storage and its TA weren’t part of 3.4.2. They were added after the fact. Did you build optee_example_secure_storage yourself? Did you build the TA too? Which branch did you build them from? They might not be compatible with the code base if too new.
optee_android_manifest/external/optee_examples git has the secure_storage code and it is synced till the below commit.
commit 5a051771cf47edc891c736f217f9ef9e43b43d99 (HEAD, tag: 3.4.0-rc1, tag: 3.4.0, tag: m/android-9.0.0_r30)
Author: Kees Jongenburger x8-999-github@gmx.com
Date: Mon Dec 10 21:44:42 2018 +0100
IV In AES CRT mode is always 128 bits regarldless the key size
The initial vector in AES CRT mode is the first data block and
therefore has the size of block size as opposed ot the size of
the key. While Rijndael does support different block sizes AES
only supports 128 bits (16 bytes) block. Even with larger keys
sizes ( e.g. 192 or 256 bits) the block size remains 128 bits.
This change introduced a new constant AES_BLOCK_SIZE and uses
this for IV related operations.
Signed-off-by: Kees Jongenburger <x8-999-github@gmx.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
optee_android_manifest/external/optee_examples/ has one Android.mk file. I used that to build optee_example_secure_storage binary.
The source code is there but the binaries were not included in the build specifically. You can try building the TA as well and adb push it to /data/vendor/tee and run optee_example_secure_storage again to see if it works. To build the TA, change build-p-hikey960.sh to ./build.sh -v p -t hikey960 "$@" and run ./build-p-hikey960.sh f4e750bb-1437-4fbf-8785-8d3580c34994.ta.
I have tried building TA with your instructions and f4e750bb-1437-4fbf-8785-8d3580c34994.ta file is generated at vendor/lib/optee_armtz/.
With this optee_example_secure_storage is working fine without doing adb push to /data/vendor/tee.
Is it necessary to keep that .ta file at /data/vendor/tee?
You can essentially just build the TA and adb push it without having to rebuild and re-flash everything, but /vendor is read only and rather than going through the trouble of remounting it as read-write, I thought it might be easier to just put it under /data/vendor/tee. Since it sounded like you’ve just rebuilt and re-flashed the images, then better to just leave it at its original path of /vendor/lib/optee_armtz/. No need to keep it at /data/vendor/tee. You’re good to go as is.
Okay… Thank you so much for the help!
does this mean you run sync with that?
No, they are just error logs occurred in 3.6.1 branch when I ran sync.
I didn’t retry with -j1 option since I thought it would be slow. My ongoing branch is 3.4.2
