MCBSTM32F400 GCC build broken by Crtypo lib settings changes

[smaillet-ms]

The GCC build of the MCBSTM32F400 platform is broken due to recent changes involving the crypto libs. The build generates the following:

016-08-12T04:11:46.3717860Z c:/program files (x86)/gnu tools arm embedded/4.9 2015q1/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe : error : c:\vso_work\4\s\BuildOutput\THUMB2FP\GCC4.9\le\FLASH\release\MCBSTM32F400\bin\Tinybooter.axf uses VFP register arguments, Crypto.lib(rsa_zenith.obj) does not [c:\VSO_work\4\s\Solutions\MCBSTM32F400\TinyBooter\TinyBooter.proj]

[Many more similar errors...]

[Unfortunately the automated build isn't actually detecting that as a failure so it hasn't been reported - I'll be looking into why the failure isn't detected so we can have accurate reports of build status]

[cw2]

I think TinyBooter FPU has to be changed to soft-float

<PLATFORM_EMULATED_FLOATINGPOINT>true</...>

, until crypto.lib is re-compiled with the proper GCC flags (and not abusing binaries from different toolchains).

[cw2]

Well, I have been digging into this for some time now and the only result is a lot of head-scratching. I cannot figure out how it [GCC build] could work at the first place.

I was able to identify at least two problems:

1. Compiling CMSIS\CMSIS\RTOS\RTX\SRC\HAL_CM.c produces warning _"Compiler generates FPU instructions for a device without an FPU (check _FPU_PRESENT)"
2. Floating point ABI setting in GCC.targets file

<FLOATING_POINT_FLAG Condition="'$(PLATFORM_EMULATED_FLOATINGPOINT)'=='true'">-mfloat-abi=softfp -mfpu=fpv4-sp-d16

(introduced in commit b5adf76) is wrong.

ad 2) The correct value for software emulated FPU is fpu-soft, details below...

ad 1) This warning is produced in MDK build too (!?). I don't know how to fix it, the only place where __FPU_PRESENT is defined is \DeviceCode\Targets\Native\STM32F4\DeviceCode\stm32f4xx.h and I am not sure how exactly is RTX supposed to be configured - i.e. if it is ok to include SoC-specific header or not.

The RTX code explicitly uses VFP instructions (in both ...\RTX\SRC\ARM\HAL_CM4.c and ...\RTX\SRC\GCC\HAL_CM4.s), so it requires floating point support to be enabled. In terms of GCC, this implies use of either -mfpu-softfp or -mfpu-hard.

GCC has three fpu options:

1. fpu-soft - soft-calling convention (ABI), software floating point,
2. fpu-softfp - soft-calling convention, generates VFP instructions,
3. fpu-hard - FPU-specific calling convention, generates VFP instructions.

fpu-hard cannot be used, because it is incompatible with crypto.lib (produces the error in the original post, because soft and hard ABI cannot be mixed).

fpu-soft also cannot be used, because RTX requires VFP instructions, and because all projects (Tinybooter, TinyClr and TinyClr_Nonet) share and are linked with the same libraries, they have to be compiled with the same settings. Otherwise, there are linker error about not being able to merge libs.

fpu-softpf produces the warning 1) and linker errors due to missing OpenSSL symbols (I think this is because it cannot resolve what library to use based on mixed FPU setting).

IMHO there are two ways to solve the above:

• Provide crypto.lib compiled and linked with GCC using proper settings,
• Fix the RTX configuration, i.e. __FPU_PRESENT has to be set

[josesimoes]

+1 for "Provide crypto.lib compiled and linked with GCC using proper settings"

as for __FPU_PRESENT I've solved that by adding this line (after current line 22)
<CC_CPP_Defines Include="__FPU_PRESENT" />
to this settings file: DeviceCode/Targets/OS/CMSIS_RTOS/CMSIS_RTOS.settings

[smaillet-ms]

The MCBSTM32F400_NONET GCC build shouldn't be including either crypto.lib or OpenSSL. If that was changed somewhere it can be reset. This did build and run in the past so something has changed.

I'm trying to figure out how we can get a better early warning on this sort of stuff by running builds and tests against pull requests before they are merged but there's a good bit of work to make that happen.