zephyr: `lpcxpresso55s69_ns` build error on `tests/arch/common/timing` about VFP register arguments
Describe the bug
This was discovered in CI where lpcxpresso55s69_ns failed to build on tests/arch/common/timing:
zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: error: bin/tfm_s.axf uses VFP register arguments, secure_fw/partitions/crypto/mbedcrypto/3rdparty/p256-m/libcrypto_service_p256m.a(p256-m_driver_entrypoints.o) does not
zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: failed to merge target specific data of file secure_fw/partitions/crypto/mbedcrypto/3rdparty/p256-m/libcrypto_service_p256m.a(p256-m_driver_entrypoints.o)
zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: error: bin/tfm_s.axf uses VFP register arguments, secure_fw/partitions/crypto/mbedcrypto/3rdparty/p256-m/libcrypto_service_p256m.a(p256-m.o) does not
zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: failed to merge target specific data of file secure_fw/partitions/crypto/mbedcrypto/3rdparty/p256-m/libcrypto_service_p256m.a(p256-m.o)
If CONFIG_FPU is disabled, this builds without any errors. So my guess is that FPU related compiler flags are not consistently used throughout the build.
To Reproduce Steps to reproduce the behavior:
- west build -p -b lpcxpresso55s69_ns tests/arch/common/timing -T arch.common.timing
Expected behavior Should build without any errors.
Impact CI failing on PRs.
Environment (please complete the following information):
- OS: Linux
- Zephyr SDK 0.16.4
- Commit 8f7e3b8123859d7d9934e438dba2cbfaffaa7a20
About this issue
- Original URL
- State: closed
- Created 5 months ago
- Comments: 39 (24 by maintainers)
Commits related to this issue
- manifest: Update trusted-firmware-m to address LPC55S69 failure A bug was introduced with the TF-M 2.0 update. Patches have been submitted to the TF-M upstream and were also applied to the Zephyr for... — committed to nxp-zephyr/zephyr by dleach02 5 months ago
- manifest: Update trusted-firmware-m to address LPC55S69 failure A bug was introduced with the TF-M 2.0 update. Patches have been submitted to the TF-M upstream and were also applied to the Zephyr for... — committed to nxp-zephyr/zephyr by dleach02 5 months ago
- manifest: Update trusted-firmware-m to address LPC55S69 failure A bug was introduced with the TF-M 2.0 update. Patches have been submitted to the TF-M upstream and were also applied to the Zephyr for... — committed to zephyrproject-rtos/zephyr by dleach02 5 months ago
- manifest: Update trusted-firmware-m to address LPC55S69 failure A bug was introduced with the TF-M 2.0 update. Patches have been submitted to the TF-M upstream and were also applied to the Zephyr for... — committed to VOGL-electronic/sw__embedded_zephyr by dleach02 5 months ago
Just to be clear here. There is no need to wait for the tf-m upstream to merge or accept the change into our tf-m repo. That’s kind of the point of our repo, so that we can fix things we need for our releases. When a future update to tf-m is made, the change will be reverted with the rest, and only applied if it didn’t make it into upstream.
So, please make a PR against zephyrproject-rtos/trusted-firmware-m that applies this patch.
Yes, base is set by SW, but ->STAT is the USART status register.
It is set statically, in the trusted-firmware-m/platform/ext/target/nxp/common/CMSIS_Driver/Driver_USART.c, line 164:
S and NS should not be signed separately. It will not work. Signed NS is not checked. MCUBoot checks only one merged image. TFM S does not check NS image, so the signing chain is not implemented. Upstream TFM+BL2 is merging S+NS to one image, and only after that signs it.
cpu1 is not used by TFM, only cpu0.