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
