Update CHANGELOG for 3.10.0

[jforissier]

Update CHANGELOG for 3.10.0 and collect Tested-by tags.

Signed-off-by: Jerome Forissier [email protected]

[igoropaniuk]

First one! :)

I/TC: OP-TEE version: 3.9.0-109-gbb8cd6f0 (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 Mon Aug  3 14:04:05 UTC 2020 aarch64

# xtest -l20
...
+-----------------------------------------------------
44626 subtests of which 0 failed
103 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

Tested-by: Igor Opaniuk <[email protected]> (Poplar)

[clementfaure]

Hello @jforissier !

Tested-by: Clement Faure <[email protected]> (mx6dlsabreauto)
Tested-by: Clement Faure <[email protected]> (mx6dlsabresd)
Tested-by: Clement Faure <[email protected]> (mx6qpsabreauto)
Tested-by: Clement Faure <[email protected]> (mx6ulevk)
Tested-by: Clement Faure <[email protected]> (mx6ullevk)
Tested-by: Clement Faure <[email protected]> (mx6ulzevk)
Tested-by: Clement Faure <[email protected]> (mx6sllevk)
Tested-by: Clement Faure <[email protected]> (mx7dsabresd)
Tested-by: Clement Faure <[email protected]> (mx7ulpevk)
Tested-by: Clement Faure <[email protected]> (mx8mmevk)
Tested-by: Clement Faure <[email protected]> (mx8mnevk)
Tested-by: Clement Faure <[email protected]> (mx8mqevk)
Tested-by: Clement Faure <[email protected]> (mx8qmmek)
Tested-by: Clement Faure <[email protected]> (mx8qxpmek)

[Emantor]

0c30f9e with #4021 and a build patch for YOCTO on top, no 1027 nor 1028 because the kernel is at 5.7:

root@ccbv2:~ xtest -l 15 -t regression -x 1027 -x 1028
…
+-----------------------------------------------------
44467 subtests of which 0 failed
103 test cases of which 0 failed
2 test cases were skipped
TEE test application done!

Tested-by: Rouven Czerwinski <[email protected]> (mx6ulccbv2)

Edit: rerun with -l 15, -l20 does not seem to do anything.

[jforissier]

3.9.0-131-gbc587ec0

Tested-by: Jerome Forissier <[email protected]> (QEMU)

[jforissier]

3.9.0-131-gbc587ec0

Tested-by: Jerome Forissier <[email protected]> (QEMUv8)

Found two issues, nothing critical IMO:

• A minor, known bug: Clang: ldelf fails to print mappings of shared library #3899
• A new one: QEMUv8: C++ exception test fails when TA is built with -pg (ftrace) #4022

[jforissier]

3.9.0-131-gbc587ec03

Tested-by: Jerome Forissier <[email protected]> (HiKey, GP)

[jenswi-linaro]

With #4027
Tested-by: Jens Wiklander <[email protected]> (Juno)

[jforissier]

3.9.0-131-gbc587ec03

Tested-by: Jerome Forissier <[email protected]> (HiKey960, GP)

[jenswi-linaro]

With OP-TEE/build#435
Tested-by: Jens Wiklander <[email protected]> (FVP)

[etienne-lms]

FYI, issue found when building with CFG_UNWIND=n, see OP-TEE/optee_test#440.

(edited: add info below)
Note: aside this issue, platform stm32mp1 regression tests passes successfully:

# xtest -l 15
(...)
43984 subtests of which 0 failed
105 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

However, since this platform default configures CFG_UNWIND=n, it currently does not build.

(updated)
3.10.0-rc1 + #4040:
Tested-by: Etienne Carriere <[email protected]> (stm32mp1, GP)

[grandpaul]

With 3.10.0-rc1
Tested-by: Ying-Chun Liu (PaulLiu) [email protected] (bpi0)

[lorc]

For 3.10.0-rc1:

Tested-by: Volodymyr Babchuk <[email protected]> (Rcar H3)
Tested-by: Volodymyr Babchuk <[email protected]> (Rcar H3/virtualization)

[b49020]

Firstly apologies for the late issue report as now I could find time to test on Developerbox.

I am seeing multiple xtest failures with similar error code as follows:

* regression_1006 Test Basic OS features
E/LD:  e64_relocate:538 Unknown relocation type 1031
E/TC:?? 0 init_with_ldelf:232 ldelf failed with res: 0xffff0005
E/TC:?? 0 tee_ta_open_session:728 Failed. Return error 0xffff0005
/home/sumit/build/developerbox/test/optee_test/host/xtest/regression_1000.c:546: xtest_teec_open_session(&session, &os_test_ta_uuid, ((void *)0), &ret_orig) has an unS
  regression_1006 FAILED

OP-TEE OS version:

[    8.298779] optee: probing for conduit method.
[    8.303339] optee: revision 3.10 (64df747c)
[    8.304145] optee: initialized driver

And this is seen with 64 bit TAs as Developerbox has "supported-ta-targets = ta_arm64" set. I am not sure if it makes any difference.

Toolchain: "gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu"

Any ideas about what I maybe missing?

[jforissier]

Firstly apologies for the late issue report as now I could find time to test on Developerbox.

I am seeing multiple xtest failures with similar error code as follows:

* regression_1006 Test Basic OS features
E/LD:  e64_relocate:538 Unknown relocation type 1031

Relocation type 1031 is R_AARCH64_TLSDESC.

Toolchain: "gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu"

That is the problem. I reproduced the same error with GCC 6.2, but our "default" toolchain (8.3) works fine.
My understanding is that there are several ways for a toolchains to implement thread local storage, all involve some specific relocations. When I worked on C++ support I had to implement basic TLS support, because the C++ runtime depends on it. I did that based on the requirements of GCC 8.3. Older GCC versions seem to do it differently, and require different relocation types :-/

Could you please check if GCC 8.3 works for you?

PS: this affects all the tests that load the os_test TA (1006 to 1010 I think).
PPS: more info on TLSDESC: https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-ARM.txt

[b49020]

Toolchain: "gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu"

That is the problem.

I was using this toolchain as an old debian 9 distro is installed on my Developerbox and Linux apps didn't worked when built with GCC 8+ toolchains giving following error:

$ sudo ./tee-supplicant -d
./tee-supplicant: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./tee-supplicant)

But I can very well use different toolchain to build TAs.

Could you please check if GCC 8.3 works for you?

So, yes with GCC 8.3 and GCC 9.2, it works pretty well and hence:

Tested-by: Sumit Garg <[email protected]> (Developerbox)

PS: this affects all the tests that load the os_test TA (1006 to 1010 I think).

Yes, these are the tests failing while using GCC 7.3.1 toolchain. So, do you think we need to document this limitation somewhere that OP-TEE 3.10.0 release supports only GCC 8 onward toochain releases?

[jforissier]

So, yes with GCC 8.3 and GCC 9.2, it works pretty well and hence:

Good, thanks for testing with 9.x -- I had not tried it myself 👍

Tested-by: Sumit Garg <[email protected]> (Developerbox)

PS: this affects all the tests that load the os_test TA (1006 to 1010 I think).

Yes, these are the tests failing while using GCC 7.3.1 toolchain. So, do you think we need to document this limitation somewhere that OP-TEE 3.10.0 release supports only GCC 8 onward toochain releases?

I don't think so. The issue is only with C++ TAs basically (since there is no reason a non-C++ TA would use the thread local storage hence the relocations that cause the problem with GCC < 8), and C++ was not supported before. So there is effectively no backward compatibility issue in practice, and users can keep their current toolchains.

That being said, the xtest error is annoying because it will undoubtedly raise questions from people who run regression tests with the new release. So I think we should simply ifdef-out the TLS/C++ code in the os_test TA if the compiler is GCC older than 8. The thing is experimental, we know it works with GCC 8 and 9, so it makes sense to simply restrict its use to the known working case. I will propose a PR.

[b49020]

So I think we should simply ifdef-out the TLS/C++ code in the os_test TA if the compiler is GCC older than 8. The thing is experimental, we know it works with GCC 8 and 9, so it makes sense to simply restrict its use to the known working case. I will propose a PR.

Sounds good to me.

[jforissier]

So I think we should simply ifdef-out the TLS/C++ code in the os_test TA if the compiler is GCC older than 8. The thing is experimental, we know it works with GCC 8 and 9, so it makes sense to simply restrict its use to the known working case. I will propose a PR.

Sounds good to me.

OP-TEE/optee_test#442. As mentioned in the PR I have tested on QEMU and QEMUv8 with Clang 10, GCC 8.3 and GCC 6.2. Feel free to try it with your original config.