Hi Thomas,

 

An extra logging can be enabled for QCBOR test cases:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/qcbor/non_secure/qcbor_ns_testsuite.c#n111

Could you repeat the test with enabled logs, just to know exactly which test cases are failing?

 

The QCBOR library is used for attest token creation, but only a small part of the library which is actually used. The IEEE 754 part of QCBOR is unused in TF-M. So it is not affecting TF-M code, we can temporarily disable those test cases. It is not a blocking issue for IAR support.

 

I put Laurence on cc he is the maintainer of QCBOR library, I think he will be interested in the  issue.

 

Tamas

 

 

The IAR port of TF-M is mostly done and all regression tests runs OK, with the exception of some of the QCBOR tests.

I've analyzed the issue to be the NaN tests to not follow the Arm run-time ABI.

The issue is with doubles where some of the tested NaN:s only have set bits in the lower 32 bits of the mantissa.

>From https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architecture-abi-2018q4-documentation
---

If NaNs are supported, it is only required to recognize, process, and convert those values with at least one bit set in the 20 most significant bits of the mantissa. Remaining bits should be zero and can be ignored. When a quiet NaN of one precision is converted to a quiet of the other precision, the most significant 20 bits of the mantissa must be preserved. Consequently:

• A NaN can be recognized by processing the most significant or only word of the representation. The least significant word of a double can be ignored (it should be zero).
• Each ABI-complying value has a single-precision representation, and a corresponding double-precision representation in which the least significant word is zero.
• Each ABI-complying NaN value is converted between single- and double-precision in the same way that Arm VFP VCVT instructions convert the values.

---

The IAR toolchain only checks the upper 32 bits for NaN / INF and the double precision NaN tests misinterprets some of the hand crafted NaN:s as INF.

How should TF-M handle this?

Thomas